DREPS transforme un lab en preuve vérifiable.

Structure DREPS

DREPS signifie Doctrine Runtime Evidence Pack System. Dans Doctrine Lab, DREPS est le format public qui transforme un lab local en ensemble de preuves lisibles, vérifiables et transmissibles. L'objectif est simple : ne plus dire seulement « le projet semble correct », mais produire des éléments observables, hashés, validés et reliés à un scénario.

À quoi sert réellement DREPS ?

DREPS sert à rendre un audit local reproductible. Le format donne un langage commun entre un débutant qui veut comprendre, un développeur qui veut corriger, un DevOps qui veut industrialiser, un formateur qui veut enseigner, et un auditeur qui veut produire une restitution vérifiable.

Lecture débutant : comprendre sans jargon

Imagine un lab comme une expérience scientifique. Le scénario dit ce que l'on veut tester. Les scripts exécutent l'expérience. Les artefacts montrent les éléments utilisés. Les événements runtime montrent ce qui s'est passé. Les findings expliquent ce que l'on a appris. Le rapport rend tout cela lisible.

• Scénario : ce que le lab veut démontrer.
• Artefact : fichier ou sortie qui sert de preuve.
• Hash SHA-256 : empreinte qui permet de vérifier qu'un fichier n'a pas changé.
• Finding : constat vérifiable, pas simple opinion.
• Control mapping : lien entre le constat et une règle ou un objectif de qualité.
• Report : version lisible pour humain.

Lecture DevOps / Ops : industrialiser sans usine à gaz

Doctrine Lab reste volontairement léger : Node.js, JSON, Markdown, HTML statique, Git et CI. Pas de base de données obligatoire, pas de Docker obligatoire, pas de framework lourd, pas de tracking caché. Cela permet de l'utiliser comme brique de diagnostic, de formation ou de standardisation sans imposer une plateforme entière.

Cas d'usage professionnels

Golden paths : transformer les écarts en trajectoire

Un golden path n'est pas une simple checklist punitive. C'est une trajectoire recommandée. Il décrit ce que devrait contenir un projet pour être exploitable, transmissible, testable, observable et maintenable.

• ci-baseline : validation minimale, artefacts, rapport, score et CI bloquante.
• docker-service-baseline : image reproductible, user non-root, healthcheck, ports documentés, pas de secrets intégrés.
• technical-debt-baseline : dette objectivée par preuve, impact, risque, effort et priorité.

Une équipe peut créer ses propres golden paths sans dépendre de Doctrine Platform. La valeur premium apparaît quand plusieurs labs, clients, historiques, scores avancés et politiques d'audit doivent être gouvernés ensemble.

Dette technique : passer de l'opinion à la preuve

Doctrine Lab peut aider à formuler la dette technique comme une décision actionnable. Au lieu de dire « le projet est fragile », on peut dire : voici les écarts, voici les preuves, voici les impacts, voici les risques, voici l'ordre recommandé de correction.

Clean room : auditer sans aspirer la propriété intellectuelle

Le mode clean room est une philosophie de prudence : lecture seule, preuves minimales, redaction des secrets, chemins normalisés, hashes plutôt que contenu brut, aucun upload automatique. Cela permet de produire un diagnostic sans exposer inutilement du code privé.

• pas de télémétrie cachée ;
• pas de collecte silencieuse ;
• pas de secret dans les rapports ;
• pas d'appel externe par défaut ;
• consentement explicite avant tout partage.

Lien avec Doctrine Platform

Doctrine Lab est la brique open source. Il permet de produire localement des preuves et des rapports. Doctrine Platform est une couche premium distincte qui peut ingérer, comparer, historiser, scorer plus finement, gouverner, signer ou certifier des packs selon des politiques contrôlées.

Cette page ne documente volontairement aucune information critique ou sensible de Doctrine Platform. Elle décrit seulement l'interface publique et saine : un lab peut produire un evidence pack ; une plateforme premium peut, avec accord explicite, analyser ce pack et proposer des améliorations.

Optimisation consentie par Doctrine Platform

Un modèle sain est possible : l'utilisateur garde son lab local, choisit d'exporter un DREPS pack, puis autorise une analyse Doctrine Platform pour obtenir des recommandations. Cette autorisation doit être explicite, limitée, documentée et révocable.

• Local-only par défaut : aucun échange externe automatique.
• Opt-in : l'utilisateur choisit d'activer une connexion.
• Scope limité : seulement le pack ou les métadonnées acceptées.
• Révocable côté utilisateur : désactivation locale possible.
• Révocable côté plateforme : Doctrine Platform peut retirer une capacité ou une reconnaissance si elle n'est plus conforme.
• Traçable : toute optimisation doit laisser une trace lisible.

Validation

La chaîne minimale de validation reste volontairement lisible. Un utilisateur doit pouvoir comprendre ce que chaque commande produit.

node scripts/dreps/export-dreps.mjs
node scripts/dreps/validate-dreps.mjs
node scripts/dreps/score-public.mjs
node scripts/report/generate-report.mjs
node scripts/report/validate-report.mjs

Interopérabilité

Doctrine Lab ne remplace pas OpenSSF Scorecard, SLSA, in-toto ou DefectDojo. Il crée des ponts pédagogiques : Scorecard pour l'idée de checks et remédiations, SLSA pour la provenance, in-toto pour la transparence des étapes, DefectDojo pour la logique de findings. Les exports restent mapping-only ou example-only tant qu'aucune intégration explicite n'est activée.

Ce que cette page garantit

• Doctrine Lab est utilisable comme template open source.
• Un débutant peut comprendre le rôle de DREPS.
• Un DevOps peut y voir une méthode de standardisation.
• Un ops peut y voir un outil de diagnostic terrain.
• Un formateur peut y voir un support pédagogique.
• Un expert peut y voir une interface publique vers des systèmes plus avancés.
• Doctrine Platform reste distincte, premium, non cannibalisée et activable uniquement par consentement.

Centre de téléchargement

Cette page donne accès aux principaux fichiers produits par Doctrine Lab. Les liens locaux servent le site statique GitHub Pages. Les releases GitHub fournissent aussi une archive versionnée, un manifest et des checksums.

Parcours de lecture recommandé

Architecture conceptuelle

Doctrine Lab repose sur une séparation nette : le lab produit des preuves locales ; les rapports rendent ces preuves lisibles ; les golden paths donnent une cible ; les mappings relient les findings à des contrôles ; les ponts écosystème rendent le projet compréhensible par les communautés DevOps, supply chain, sécurité et audit.

• Templates : nano, micro, mini, full.
• Générateur : création d'un lab en une commande.
• DREPS : export et validation des preuves.
• Scoring public : score pédagogique et remédiations.
• Rapports : Markdown, HTML, summary JSON.
• CI multi-forges : GitHub Actions, Forgejo Actions, GitLab CI.
• Site statique : documentation lisible sans dépendance à une forge unique.
• Frontière premium : Doctrine Platform reste distincte, gouvernée et activable uniquement par consentement.

Ce que Doctrine Lab ne fait pas

Doctrine Lab ne prétend pas être une certification réglementaire officielle, un scanner offensif, un outil de collecte de secrets ou un remplacement complet de Doctrine Platform.

• Il ne collecte pas silencieusement les utilisateurs.
• Il ne transmet pas automatiquement les packs à une plateforme externe.
• Il ne donne pas de certification Doctrine Platform.
• Il ne remplace pas un audit professionnel complet.
• Il ne doit pas être utilisé pour scanner des tiers sans autorisation.

Open Toolbox

Doctrine Lab contient maintenant une toolbox open source généreuse : packs CI, dette technique, clean room, Mailpit local, résilience Icare, portfolio evidence, Vocalendar, orchestration Zarathustra et adaptateurs multi-langages.

Toolbox deep documentation

La toolbox dispose maintenant d'une documentation détaillée : usages indépendants, usages combinés, limites, frontières premium, parcours développeur, parcours DevOps, parcours formateur et cas d'usage professionnels.