AI_GOVERNANCE.md¶

Gouvernance de l’usage des intelligences artificielles¶

1. Objet du document¶

Ce document définit les règles de gouvernance applicables à l’utilisation des intelligences artificielles (IA) dans le cadre du développement du projet.

Il vise à garantir :

la traçabilité des décisions,
la conformité technique et réglementaire,
l’absence de dérive décisionnelle automatisée,
la responsabilité humaine explicite,
l’auditabilité interne et externe.

Les IA sont considérées comme des outils d’assistance, jamais comme des autorités de décision.

2. Périmètre d’application¶

Ce document s’applique à :

la rédaction des spécifications,
la conception technique,
l’implémentation logicielle,
la validation,
la documentation,
les retours d’expérience.

Il couvre l’ensemble du cycle de vie des fonctionnalités.

3. Principes fondamentaux¶

La spécification fait loi.
Toute règle doit être testable.
Aucune IA ne valide son propre travail.
Toute décision engageant le produit est validée par un humain.
Les IA n’introduisent jamais de règles implicites.
Toute hypothèse formulée par une IA est explicitement documentée.
Les outils de pilotage (ex. JIRA) ne sont jamais des sources canoniques.
Les tests contractuels font partie intégrante de la norme. Les scénarios de tests définis dans PD-XX-tests.md constituent le socle minimal de preuve de conformité. Ils sont distincts des tests ajoutés à des fins de qualité logicielle.

4. Rôles des agents IA¶

4.1 Agent A — ChatGPT¶

Rôle principal

Normatif
Audit
Validation
Acceptabilité

Responsabilités

Rédaction des spécifications canoniques contractuelles
Pré-acceptabilité des spécifications
Validation des plans d’implémentation
Acceptabilité initiale et revues d’acceptabilité post-correction

Interdictions

Produire du code final
Modifier une spécification après son gel
Valider un artefact qu’il a lui-même produit
Arbitrer une ambiguïté métier sans validation humaine

4.2 Agent B — Claude¶

Rôle principal

Implémentation
Exécution technique
Retour d’expérience

Responsabilités

Rédaction des plans d’implémentation
Implémentation du code
Rédaction des retours d’expérience
Corrections techniques suite aux revues d’acceptabilité

Interdictions

Modifier une spécification
Valider la conformité finale
Décider du périmètre fonctionnel
Justifier une déviation contractuelle

5. Human-in-the-loop (responsabilité humaine)¶

Aucune IA ne peut :

geler une spécification,
autoriser une mise en production,
modifier un invariant,
accepter un écart contractuel.

Ces décisions relèvent exclusivement de la responsabilité humaine.

6. Workflow officiel gouverné¶

Le workflow suivant est obligatoire pour toute fonctionnalité critique :

Expression de besoin (humain)
Spécification canonique contractuelle + tests contractuels minimaux (ChatGPT)
Pré-acceptabilité de la spécification (ChatGPT)
Plan d’implémentation détaillé (Claude)
Validation du plan d’implémentation (ChatGPT)
Implémentation (Claude)
Acceptabilité initiale (ChatGPT)
Corrections / itérations techniques (Claude)
Revue d’acceptabilité post-correction (ChatGPT)
Retour d’expérience (Claude)

Aucune étape ne peut être sautée sans justification documentée. Les tests contractuels (PD-XX-tests.md) définissent le minimum opposable requis pour toute implémentation. Ils ne limitent pas l’ajout de tests techniques supplémentaires lors de l’implémentation.

7. Description détaillée des étapes du workflow¶

Cette section décrit de manière normative chacune des étapes du workflow officiel défini en section 6.

Diagramme de workflow (vue synthétique)¶

flowchart TB
    A["1. Expression de besoin<br>Humain"] --> B["2. Spécification<br>ChatGPT"]
    B --> C["3. Acceptabilité spec<br>ChatGPT"]
    C -- valide --> D["4. Plan d’implémentation - Claude"]
    C -- invalide --> B
    D --> E["5. Validation du plan<br>ChatGPT"]
    E -- valide --> F["6. Implémentation<br>Claude"]
    E -- invalide --> D
    F --> G["7. Acceptabilité initiale<br>ChatGPT"]
    G -- Écarts détectés --> H["8. Corrections techniques - Claude"]
    H --> I["9. Revue d’acceptabilité<br>post-correction - ChatGPT"]
    I -- OK --> J["10. Retour d’expérience<br>Claude"]
    I -- KO --> H
    G -- Accepté --> I
    B -- Rédige --> K["PD-XX-specification.md"]
    B -- Rédige --> Q["PD-XX-tests.md"]
    D -- Rédige --> L["PD-XX-plan.md"]
    G -- Rédige --> M["PD-XX-acceptability.md"]
    I -- Rédige --> M
    J -- Rédige --> N["PD-XX-rex.md"]
    O["Doc<br>cadrage"] -- Lit --> B
    P["Code Source"] -- Lit --> C & D & E & G & I & J
    F -- Ecrit --> P
    H -- Ecrit --> P

    A@{ shape: manual-input}
    K@{ shape: card}
    Q@{ shape: card}
    L@{ shape: card}
    M@{ shape: card}
    N@{ shape: card}
    O@{ shape: card}
    P@{ shape: card}
    style A fill:#C8E6C9
    style B fill:#FFE0B2
    style C fill:#FFE0B2
    style D fill:#FFF9C4
    style E fill:#FFE0B2
    style F fill:#FFF9C4
    style G fill:#FFE0B2
    style H fill:#FFF9C4
    style I fill:#FFE0B2
    style J fill:#FFF9C4
    style K fill:#BBDEFB
    style Q fill:#BBDEFB
    style L fill:#BBDEFB
    style M fill:#BBDEFB
    style N fill:#BBDEFB
    style O fill:#FFCDD2
    style P fill:#FFCDD2
    linkStyle 0 stroke:#2962FF,fill:none
    linkStyle 1 stroke:#2962FF,fill:none
    linkStyle 2 stroke:#00C853,fill:none
    linkStyle 3 stroke:#D50000,fill:none
    linkStyle 4 stroke:#2962FF,fill:none
    linkStyle 5 stroke:#00C853,fill:none
    linkStyle 6 stroke:#D50000,fill:none
    linkStyle 7 stroke:#2962FF,fill:none
    linkStyle 8 stroke:#D50000,fill:none
    linkStyle 9 stroke:#2962FF,fill:none
    linkStyle 10 stroke:#00C853,fill:none
    linkStyle 11 stroke:#D50000,fill:none
    linkStyle 12 stroke:#00C853,fill:none

Étape 1 — Expression de besoin (humain)¶

But : formuler un besoin fonctionnel explicite, sans décider de la solution.

Entrées : contexte produit / contrainte business / risque identifié.

Sorties (artefacts) :

une expression de besoin textuelle exploitable (titre + objectifs + périmètre attendu) ;
la référence de l’EPIC cible ;
la liste (même incomplète) des contraintes non négociables connues.

Interdictions :

proposer une implémentation ;
geler des invariants sans justification ;
accepter une déviation contractuelle.

Critère de sortie : le besoin est suffisamment clair pour produire une spécification testable ; sinon, il doit être explicitement marqué « incomplet ».

Étape 2 — Spécification canonique contractuelle (ChatGPT)¶

But : produire une spécification normative qui fait loi.

Entrées : expression de besoin (étape 1) + documentation d’architecture disponible.

Sorties (artefacts) :

PD-XX-spec.md (versionnée), incluant : périmètre/hors périmètre, définitions, invariants, flux, erreurs, critères d’acceptation, scénarios Given/When/Then, hypothèses explicites, points à clarifier.

Contraintes :

aucune hypothèse implicite ;
toute règle doit être testable, sinon marquée « hors périmètre ».

Interdictions :

proposer une implémentation ;
trancher une ambiguïté métier sans validation humaine.

Critère de sortie : la spécification est complète au sens contractuel, ou bien les manques sont listés en « points à clarifier ».

Étape 3 — Pré-acceptabilité de la spécification (ChatGPT)¶

But : auditer la spécification comme un document contractuel.

Entrées : PD-XX-spec.md.

Sorties (artefacts) :

un rapport de pré-acceptabilité listant uniquement : ambiguïtés, contradictions, règles non testables, hypothèses dangereuses, risques sécurité/conformité.

Interdictions :

améliorer / réécrire la spécification ;
ajouter de nouvelles règles.

Critère de sortie : les problèmes sont identifiés et exploitables par un humain (pour arbitrage) ou par une itération de rédaction.

Étape 4 — Plan d’implémentation détaillé (Claude)¶

But : décrire le chemin technique d’implémentation strictement dérivé de la spécification.

Entrées : PD-XX-spec.md + arbitrages humains éventuels.

Sorties (artefacts) :

PD-XX-plan.md (versionné), découpé en tâches, contrôles et dépendances.

Contraintes :

couverture complète des invariants et scénarios de test.

Interdictions :

modifier la spécification ;
justifier une déviation contractuelle.

Critère de sortie : chaque exigence testable de la spec est couverte par au moins une étape du plan.

Étape 5 — Validation du plan d’implémentation (ChatGPT)¶

But : auditer le plan pour garantir l’absence de dérive vis-à-vis de la spec.

Entrées : PD-XX-spec.md + PD-XX-plan.md.

Sorties (artefacts) :

un rapport d’audit du plan (écarts / trous de couverture / risques).

Interdictions :

proposer une implémentation ;
« optimiser » le plan ;
introduire des exigences nouvelles.

Critère de sortie : plan jugé conforme (OK) ou liste d’écarts à corriger dans le plan.

Étape 6 — Implémentation (Claude)¶

But : produire le code conforme à la spec en suivant le plan validé.

Entrées : plan validé + spec.

Sorties (artefacts) :

code source + tests + migrations + configuration (selon le périmètre de la US).

Contraintes :

pas de déviation contractuelle sans arbitrage humain documenté.

Interdictions :

modifier la spécification ;
valider la conformité finale.

Critère de sortie : code compilable/exécutable, tests pertinents en place, prêt pour acceptabilité.

Étape 7 — Acceptabilité initiale (ChatGPT)¶

But : constater la conformité de l’implémentation à un instant T.

Entrées : PD-XX-spec.md + code source + tests.

Sorties (artefacts) :

PD-XX-acceptability.md contenant :
un verdict courant (REFUSÉ / ACCEPTÉ AVEC RÉSERVES / ACCEPTÉ) ;
une liste d’écarts constatés, classés : BLOQUANT / MAJEUR / MINEUR ;
des justifications factuelles (observables).

Contraintes :

l’acceptabilité est un registre de décision, pas un document de design.
Le verdict d’acceptabilité est fondé exclusivement sur l’exécution et le résultat des tests contractuels (PD-XX-tests.md).
Les tests additionnels sont hors périmètre décisionnel.

Interdictions :

proposer des solutions de code ;
modifier la spécification.

Critère de sortie : verdict initial émis et écarts actionnables.

Étape 8 — Corrections / itérations techniques (Claude)¶

But : corriger les écarts relevés lors de l’acceptabilité initiale.

Entrées : PD-XX-acceptability.md (écarts) + code.

Sorties (artefacts) :

commits de correction ;
mise à jour des tests associés.

Interdictions :

modifier la spécification ;
requalifier un écart (cela relève de l’audit).

Critère de sortie : corrections prêtes à être revérifiées ; références (commit / PR) disponibles.

Étape 9 — Revue d’acceptabilité post-correction (ChatGPT)¶

But : vérifier factuellement la résolution des écarts existants.

Entrées : PD-XX-acceptability.md + code corrigé + références de commits.

Sorties (artefacts) :

mise à jour append-only de PD-XX-acceptability.md :
mise à jour de statut des écarts existants (OUVERT / PARTIEL / RÉSOLU) ;
mise à jour du verdict courant si justifié ;
historique conservé.

Interdictions :

ajouter de nouveaux écarts (ils feront l’objet d’une acceptabilité distincte) ;
réécrire l’historique ;
modifier la spécification.

Critère de sortie : verdict courant stabilisé ou boucle de correction déclenchée.

Étape 10 — Retour d’expérience (Claude)¶

But : capitaliser les enseignements et tracer la dette.

Entrées : décisions prises, écarts rencontrés, arbitrages, limites.

Sorties (artefacts) :

PD-XX-rex.md append-only, incluant : décisions, dettes, risques, axes d’amélioration.

Interdictions :

réécrire l’historique ;
modifier la spécification gelée.

Critère de sortie : REX publié et versionné.

8. Auditabilité et preuves¶

Chaque fonctionnalité doit disposer des artefacts suivants :

Spécification canonique versionnée
Plan d’implémentation versionné
Code source
Rapport d’acceptabilité
Historique des revues d’acceptabilité
Retour d’expérience

Les IA sont utilisées comme outils de transformation et d’analyse, jamais comme autorités de décision.

10. Politique d’évolution¶

Toute évolution :

du workflow IA,
des rôles des agents,
des règles de gouvernance,

fait l’objet :

d’une mise à jour explicite de ce document,
d’une validation humaine,
d’un historique de modification traçable.

11. Statut du document¶

Ce document est normatif. Il prévaut sur toute pratique informelle ou usage non documenté.

Toute déviation doit être explicitement justifiée et tracée.