Expression de besoin — GOV-SYSTEM¶

1. Contexte et motivation¶

Le problème fondamental¶

ProbatioVault développe un coffre-fort numérique probatoire soumis à des exigences réglementaires strictes (NF Z42-013, ISO 14641, eIDAS). Le code produit engage la valeur probante des documents archivés — une erreur cryptographique, une faille de sécurité ou une incohérence fonctionnelle peut invalider juridiquement des preuves.

Le développement repose sur des agents IA (Claude, ChatGPT) qui produisent spécifications, code et tests. Or ces agents :

• N'ont pas de mémoire inter-sessions : chaque invocation repart de zéro, sans capitalisation.
• Ne se valident pas eux-mêmes : un LLM qui produit un document et le review ensuite a un biais de confirmation systématique.
• Produisent des artefacts incohérents si le contexte est pollué par les étapes précédentes.
• Ne respectent pas spontanément les contraintes réglementaires (NF Z42-013 §6.3, ISO 14641 §7.2) sans injection explicite.

Pourquoi un système de gouvernance¶

Un développeur humain seul face à des agents IA sans cadre produit du code qui compile mais ne prouve rien. Les premières stories ProbatioVault (PD-13 à PD-22) ont été développées sans gouvernance formelle. Le constat :

• Aucune traçabilité des décisions architecturales — impossible de justifier un choix lors d'un audit.
• Pas de validation croisée — le même LLM qui écrit la spec la valide, sans contradiction.
• Corrections tardives — les erreurs découvertes en production (ou par Sonar) au lieu d'être bloquées en amont.
• Pas de capitalisation — les mêmes erreurs se répétaient d'une story à l'autre (double-hash HSM, createVerify vs crypto.verify, ALTER TYPE ADD VALUE dans la même transaction, etc.).

L'analogie positronique¶

Le système s'inspire des cerveaux positroniques d'Isaac Asimov : des règles ancrées si profondément dans l'architecture qu'elles ne peuvent être violées, même par l'agent lui-même. Les Trois Lois de la Robotique deviennent les Articles Constitutionnels — des invariants inviolables injectés dans chaque point de contrôle.

Pourquoi 11 étapes¶

Le workflow en 11 étapes reproduit un cycle de développement industriel complet, adapté à la production IA :

1. Besoin (étape 0) : capture de l'intention humaine, préservation des tensions.
2. Spécification + Tests (étapes 1-2) : contractualisation formelle par un LLM distinct.
3. Gate Spec (étape 3) : premier point de contrôle — la spec est-elle complète, testable, sans ambiguïté ?
4. Plan (étape 4) : découpage en composants, mapping invariants → mécanismes.
5. Gate Plan (étape 5) : le plan couvre-t-il tous les invariants ? Les hypothèses sont-elles vérifiables ?
6. Implémentation (étape 6) : production multi-agents avec isolation par module.
7. Acceptabilité (étape 7) : quality gates automatisés + reviews LLM.
8. Gate Closure (étape 8) : le code produit respecte-t-il la spec ? Les invariants sont-ils couverts ?
9. REX (étape 9) : extraction des apprentissages, métriques.
10. Rétrospective (étape 10) : patterns récurrents, amélioration du processus.

Chaque gate est un point de non-retour conditionnel : on ne passe pas sans preuve de conformité.

2. Objectif¶

Fournir un cadre d'orchestration automatisé qui :

1. Sépare production et validation : aucun agent ne valide jamais son propre travail (validation croisée Claude ↔ ChatGPT).
2. Impose des quality gates mathématiques : scoring numérique non négociable (GO ≥ 8.0, RESERVE ≥ 7.0, NON_CONFORME sinon) avec plafond d'itérations et détection de stagnation.
3. Trace chaque événement : état dans Jira (source de vérité), artefacts sur disque, sessions JSONL, commentaires horodatés.
4. Capitalise les apprentissages : chaque erreur détectée en gate ou en REX alimente une base de learnings indexée par embeddings, réinjectée dans les stories suivantes.
5. Isole les contextes : chaque étape s'exécute dans un processus distinct, sans pollution inter-étapes.
6. Survit aux interruptions : le workflow peut être stoppé et repris à tout moment grâce à l'état Jira + données locales.

Le système ne développe pas — il gouverne le développement. Les agents produisent. Claude orchestre. Le PMO juge. L'humain tranche.

3. Périmètre fonctionnel¶

Lot 1 — Orchestration fondamentale (MUST-HAVE)¶

Lot 2 — Capitalisation et amélioration continue¶

Lot 3 — Intégrations¶

Lot 4 — Cohérence et traçabilité¶

4. Contraintes¶

4.1 Contraintes réglementaires¶

• Le code produit via ce workflow DOIT être conforme NF Z42-013 (archivage électronique) et ISO 14641 (gestion des documents).
• Les preuves cryptographiques DOIVENT respecter eIDAS (signatures qualifiées, horodatage RFC 3161).
• La traçabilité DOIT être suffisante pour un audit externe (AFNOR, commissaire aux comptes).

4.2 Contraintes organisationnelles¶

• Développeur unique : le workflow est conçu pour un développeur assisté par des agents IA, pas pour une équipe.
• PO = développeur : l'humain qui tranche les RESERVE et ESCALADE est aussi celui qui développe.
• Budget LLM : le prompt caching (cache-first) est une contrainte économique, pas un luxe.

4.3 Contraintes techniques¶

• Claude Code (extension VSCode) est le runtime principal. Les skills .claude/commands/ sont le point d'entrée.
• OpenCode est le seul accès à ChatGPT (pas de copier-coller). Sandbox filesystem impose la capture en variable.
• claude -p ne peut pas être lancé depuis une session Claude Code sans unset CLAUDECODE.
• Jira Team-managed : le workflow n'est pas exposé via l'API classique. Les TIDs sont découverts empiriquement.
• Ollama sur serveur local (2× RTX 5090) : embeddings BGE-M3, modèles qwen3.5:35b-a3b et llama3.3:70b.

4.4 Contraintes temporelles¶

• Le workflow complet d'une story prend 8 à 24 heures selon la complexité.
• Les gates itératives (v1 → v2 → v3) doivent être exécutées rapidement (< 5 min entre appels) pour bénéficier du prompt caching.
• Le REX DOIT être lancé APRÈS que le pipeline GitLab soit vert.

5. Scénarios d'échec et résultats inacceptables¶

6. Tensions et conflits non résolus¶

T-01 : Autonomie des agents vs. contrôle constitutionnel¶

Les agents IA sont plus efficaces quand ils ont de la latitude. Mais le domaine réglementaire exige un contrôle strict. La tension se manifeste dans : - Les agents step 6b qui voudraient refactorer du code existant mais sont limités aux fichiers autorisés. - Les gates qui parfois sur-pénalisent des choix techniques valides mais non documentés dans la spec.

Non résolu : le calibrage entre "laisser l'agent s'exprimer" et "imposer la conformité" est empirique, ajusté story par story.

T-02 : Coût du prompt caching vs. complétude du contexte¶

Le cache-first impose de mettre le contenu statique en tête. Mais parfois, le contexte le plus pertinent pour l'agent est dynamique (corrections de l'itération précédente, écarts spécifiques). Injecter ce contexte en premier casserait le cache.

Non résolu : le compromis actuel (dynamique en queue) est acceptable mais sous-optimal pour les gates itératives complexes.

T-03 : Développeur unique vs. séparation des pouvoirs¶

L'Art. II impose que l'auteur ne valide jamais son propre travail. Mais avec un développeur unique, c'est le même humain qui guide tous les agents. La séparation se fait entre LLM (Claude vs. ChatGPT), pas entre humains.

Non résolu : la validation croisée inter-LLM est un proxy imparfait pour la vraie séparation des pouvoirs. Un audit externe humain périodique renforcerait le dispositif.

T-04 : Traçabilité exhaustive vs. volume de données¶

Chaque événement est logué (session JSONL, commentaires Jira, métriques). Sur 30+ stories, le volume de données devient significatif. Les dashboards sont en batch (pas temps réel), les learnings nécessitent un reindex.

Non résolu : le passage à l'échelle (100+ stories) nécessiterait une base structurée (PostgreSQL ?) au lieu de fichiers JSONL.

T-05 : Jira source de vérité vs. latence réseau¶

Jira est la source de vérité, mais chaque appel API prend 200-500ms. Sur un workflow avec 20+ transitions, ça représente 10+ secondes de latence pure. Le fallback .gov-local.json est un mode dégradé, pas un remplacement.

Non résolu : acceptable pour un développeur unique, problématique si multi-sessions parallèles.

7. Questions ouvertes¶

8. Hors périmètre¶

9. Risques identifiés¶

10. Dépendances¶

Annexe — Learnings injectés¶

Les learnings suivants, issus de 30+ stories gouvernées, ont directement façonné le système :

Ces learnings démontrent le mécanisme d'auto-amélioration du système : chaque erreur détectée en gate ou en REX modifie les templates, les rules ou les procedures pour empêcher sa récurrence.