Colonne ① · Decision-as-Code

Transformer un choix en actif révisable et traçable

Une décision relie une question, des options, des preuves, une autorité, un résultat attendu et une condition de révision. L'ADR en est le journal, le DN le graphe navigable : l'un sans l'autre ne forme pas un arbre réutilisable.

AIDO est un cadre, pas un outil. Cette page décrit ce que cette colonne doit garantir. Vous l'appliquez avec vos propres outils, vos seuils et vos règles.

Vous laissez l'IA agir sur vos opérations IT ?

Lire le mécanisme ↓

LA DÉCISION ÉCRITE APRÈS COUP

Le réflexe courant : décider, agir, puis documenter, dans une page que l'on retouche au fil de l'eau. Le résultat attendu s'écrit alors une fois le résultat connu, et le choix d'origine se perd dans les retouches.

Decision-as-Code inverse l'ordre : le contrat de résultat est écrit avant d'agir, et une décision ne se réécrit pas, elle se supersede.

Le mécanisme · le nœud et le journal

Que doit contenir une décision ?

Deux objets qui se répondent. Le Decision Node (DN), nœud de décision, pose la question et ses options. L'ADR acte le choix et en garde l'historique.

Decision Node

Le graphe navigable

CE QUE LE NŒUD PORTE

id
un identifiant qualifié
phase
normal, change, incident, recovery ou foundation
question
une seule question décisionnelle
context
les variables qui changent le choix
options
bénéfices, coûts, risques, condition de recommandation, sources
default
l'option par défaut
adr_generated
l'ADR que le nœud a produit
review_trigger
un déclencheur de révision mesurable
owner
celui qui répond du nœud

ADR

Le journal

LES 11 ÉLÉMENTS MINIMAUX

  1. ID qualifié et statut
  2. Le DN de rattachement, ou one_shot: true
  3. Contexte et problème
  4. Basis / Inputs / Assumptions : bases, entrées, hypothèses
  5. Options et trade-offs (arbitrages)
  6. Décision et autorité
  7. Conséquences et blast radius (rayon d'impact)
  8. outcome_contract, ou justification not_applicable
  9. Réversibilité et backout (retour arrière)
  10. Review trigger et owner
  11. Journal append-only des transitions : on ajoute, on n'efface pas
  • LE GRAPHE ET LE JOURNALL'un sans l'autre ne forme pas un arbre réutilisable. Le DN génère l'ADR ; l'ADR référence son DN, ou se déclare one_shot.
  • DES IDENTIFIANTS QUALIFIÉSDN-FW-*, ADR-FW-*, DN-INFRA-*, ADR-INFRA-*. Une référence par chemin relatif est canonique ; l'ID seul est un label.
Le format du Decision Node dans le canon 
decision_node:
  id: DN-INFRA-XXX
  phase: normal | change | incident | recovery | foundation
  question: question décisionnelle unique
  context: [variables qui changent le choix]
  options:
    - id / name
      benefits / costs / risks
      recommended_when: condition
      sources: ["KB/doc#section"]
  default: A
  adr_generated: ../ADR/ADR-INFRA-XXX.md
  review_trigger: événement mesurable
  owner: rôle / personne

Format de référence : chaque organisation instancie les valeurs.

Le mécanisme · l'outcome contract · R14

Comment saura-t-on que le choix était bon ?

En l'écrivant avant d'agir. Toute action runtime porte son outcome contract avant le GO (l'accord d'exécuter) : ce qu'on attend, comment on le mesure, ce qu'on fait si ça échoue.

CE QUE LE CONTRAT DÉCLARE

  • résultat attenduQue doit produire ce choix ?
  • signauxQu'observe-t-on ?
  • seuil de succèsÀ partir de quand est-ce réussi ?
  • fenêtre d'observationPendant combien de temps regarde-t-on ?
  • seuil d'échecÀ partir de quand est-ce un échec ?
  • réponseRollback ou autre, fixée d'avance
  • référence de restaurationVers quoi revient-on ?

ET SANS ACTION RUNTIME ?

L'ADR porte alors une justification not_applicable. L'absence de contrat se justifie, elle n'est jamais implicite. Pour une décision Amber ou Red, le linter exige le lien vers l'outcome et le backout.

Le mécanisme · l'immutabilité opératoire

Que se passe-t-il quand la décision change ?

Elle ne se réécrit pas. Elle se supersede : un nouvel ADR prend le relais de l'ancien.

  • Le choix, le périmètre ou l'autorité changentUn nouvel ADR, qui supersede le précédent
  • Une preuve, une précision ou une conséquence s'ajoute, sans changer la décisionUne entrée au journal
  • Un renvoi « X fait foi » pointe vers un fichier mutableNe remplace pas la décision
  • Un ADR en supersede un autreLe DN est mis à jour dans la même transaction

LE LINTER DE CONFORMITÉ VÉRIFIE

  • unicité des IDs
  • résolution DN ↔ ADR
  • schéma requis
  • statut et review trigger
  • lien outcome / backout pour Amber et Red
  • cohérence des supersede

Échouent : un DN sans review trigger, une décision Amber ou Red sans lien vers son outcome et son backout.

Le mécanisme · progressive disclosure

Toute décision laisse une trace. Quand devient-elle un nœud ?

Dès le premier choix, un ADR garde l'historique : les options envisagées et leurs compromis, l'option retenue, qui l'a décidée et pourquoi. Quand la même question revient, ou qu'elle doit devenir une règle, elle devient un Decision Node : un arbre réutilisable qui guide les choix suivants, et chaque nouvel ADR s'y rattache.

  1. 1ER CAS RÉELUn ADR (one-shot) : options, choix, autorité
  2. 2E CAS RÉELLa question devient un Decision Node ; les ADR s'y rattachent
  3. DÉCISION DEVENUE RÈGLEUn Decision Node naît

LE REGISTRE

Le registre reste un index léger ; chaque nœud a son fichier, chargé à la demande. Un parcours qui traverse plusieurs nœuds laisse un Workflow State lisible par machine, clos en fin de transaction et conservé comme Evidence (preuve).

Voir un exemple : la vie d'une décision qui revient

Une question d'exploitation, sans nom ni outil, qui revient.

  1. 1PREMIER CASUn ADR one_shot: true, outcome contract écrit avant d'agir.
  2. 2PLANLa lane se calcule sur le plan issu du choix ; le mandat vient de Risk Lanes et du Control Plane, pas de l'ADR.
  3. 3PREUVEUne observation s'ajoute sans changer la décision : une entrée au journal, pas un nouvel ADR.
  4. 4DEUXIÈME CASLa question revient : un Decision Node naît, avec options, défaut, review trigger et owner.
  5. 5RÉVISIONLe déclencheur survient, l'autorité change : un nouvel ADR supersede le premier, le DN suit dans la même transaction.
  6. 6CONTRÔLELe linter vérifie l'unicité des IDs, la résolution DN ↔ ADR et la cohérence du supersede.

Ce qu'elle produit

Trois pièces, pour chaque décision

01 · LE DECISION NODE

Le choix, ses options, ses trade-offs

Une question, son contexte, des options sourcées, un owner.

02 · L'ADR

La décision actée et sa raison

Onze éléments minimaux et un journal qu'on complète sans réécrire.

03 · L'OUTCOME CONTRACT

Le résultat attendu, avant d'agir

Signaux, seuils et réponse à l'échec, déclarés avant le GO.

Dans la boucle

Où intervient-elle dans la boucle ?

À l'étape DECIDE. Elle y pose le choix ; les étapes suivantes s'appuient sur lui.

SENSE
⑥
GROUND
④
DECIDE
①②
AUTHORIZE
②⑤
ACT
③
VERIFY
⑥
LEARN
⑦

① en surbrillance · les autres badges mènent aux colonnes sœurs

DECIDE

Question, options sourcées, autorité, résultat attendu, condition de révision.

ENSUITE

La lane se calcule sur le plan issu du choix (②), le mandat s'appuie sur le plan hashé (③), VERIFY compare le réel à l'outcome contract (⑥).

Les règles qui la portent

  • R14OUTCOME CONTRACTToute action runtime porte son contrat avant GO.
  • R9PROVENANCELe DN et l'ADR font partie de la chaîne tracée par le même trace_id.

L'inspection · test de complétude

Comment vérifier qu'elle est en place ?

« Pourquoi ce choix ? »

Prenez une décision récente qui a conduit l'IA à agir sur un système réel. Pouvez-vous montrer, pièces à l'appui :

  1. 1la question posée, les options écartées et leurs sources ;
  2. 2qui a décidé, et avec quelle autorité ;
  3. 3l'outcome contract, écrit avant d'agir ;
  4. 4le chemin de retour : réversibilité, backout, référence de restauration ;
  5. 5ce qui la fera réviser, qui en est l'owner, et le journal de ses transitions.

Si vous ne pouvez pas répondre avec preuve, la colonne n'est pas encore en place. Ce n'est pas un jugement : une cartographie honnête est exactement le point de départ.

Le socle

Les fondations qu'elle sert

Les 8 fondations normatives et leur définition sont sur la page du temple.

Les limites font partie du contrat

Ce qu'elle n'est pas

Elle explique un choix ; elle ne donne pas le droit d'agir.

  • Une décision n'autorise pas une action. Le mandat effectif est émis par Risk Lanes et le Control Plane, sur le plan hashé et l'état runtime courant. La lane appartient au plan concret issu du choix, pas à l'option seule.
  • Pas une documentation a posteriori. L'outcome contract est écrit avant d'agir.
  • Pas un wiki modifiable. Une décision ne se réécrit pas, elle se supersede.

La visite guidée

Voyons comment l'appliquer chez vous

30 minutes en visio, sur votre contexte : vos opérations, vos outils, la place de l'IA aujourd'hui, et ce que Decision-as-Code y changerait.

Réserver un audit de 30 min

30 minutes · visio · créneau à choisir en ligne