Colonne ⑤ · Enforcement Layers
Rendre les invariants non contournables
Les Enforcement Layers gardent toutes les transitions de la boucle. Chaque invariant nomme son niveau actuel et son niveau cible.
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 ? Cinq questions : à quel niveau une règle est imposée, ce qu'un changement doit franchir, ce qui se passe quand un contrôle échoue, ce qui reste à tenir ensuite, ce que la colonne n'est pas.
Lire le mécanisme ↓LE RÉFLEXE DE LA CONSIGNE
Face à une IA qui agit sur des systèmes réels, le réflexe est d'écrire la règle dans ses instructions, puis de la tenir pour acquise. Une consigne est probabiliste et non bloquante : l'IA peut s'en écarter.
Enforcement Layers demande à quel niveau chaque règle est imposée, et à quel niveau elle doit l'être.
Le mécanisme · l'échelle L1 à L6
À quel niveau une règle est-elle réellement imposée ?
Six niveaux, du probabiliste au structurel. Chaque invariant (une règle qui doit toujours tenir) nomme son niveau actuel et son niveau cible.
- L1Instructions et KBProbabiliste, non bloquant
- L2Review structuréeDétectif
- L3Schémas et hooks côté outilDéterministe local
- L4pre-commit, commit-msg, pre-pushBloque la publication
- L5Pipeline, policy, admissionAutorité structurelle
- L6Runtime governor et outcome gatesLimite l'impact après activation
LA RÈGLE DE L'ÉCHELLE
Une instruction ne peut être présentée comme une garantie L5/L6.
- niveau actuel · L1
- niveau cible · L5
- écart déclaré
Un invariant resté en L1 alors que sa cible est L5 est un écart déclaré, pas un secret. C'est le niveau réel qui s'affiche.
Le mécanisme · le pipeline pré-changement · R6
Que doit franchir un changement avant d'être appliqué ?
Un pipeline obligatoire en 10 étapes, dans un ordre fail-fast : le changement n'avance que si l'étape précédente passe. La dernière étape est le GO.
ORDRE CANONIQUE, FAIL-FAST · DE 01 À 10
- 01format-lint
- 02semantic / tool-lint
- 03compile / schema / validate
- 04secret-scanBLOQUANT · DISTINCT
- 05security-policy-scan
- 06tests fonctionnels et de régression
- 07dry-run / plan / diff cible
- 08validate-outcome-contract
- 09validate-recovery-path
- 10GO sur plan hashé et scope exactAUTORISATION
- LES SECRETS À PARTUn scanner de misconfiguration IaC ne remplace pas un scanner de secrets. Le secret scan a ses fixtures positives et négatives, et des exemptions structurées, datées, reviewées.
- BLOCKED N'EST PAS PASSUn outil indisponible donne BLOCKED, jamais PASS. Un contrôle non applicable porte N/A avec sa raison et sa preuve ; il n'est jamais omis en silence.
Le mécanisme · l'arrêt · R12 · R5
Que se passe-t-il quand un contrôle échoue ou ne répond pas ?
Tout s'arrête, et le dit. UNKNOWN n'est ni PASS ni FAIL : aucun succès ne s'infère d'une absence de signal.
DÉCLENCHEURS · R12 FAIL-LOUD
- erreur
- outil manquant
- sortie imparsable
- preuve périmée
- validation incomplète
CE QUI SUIT, TOUJOURS
STOP
Statut explicite, trace, prochaine action.
- CHAQUE ÉTAPE PEUT S'ARRÊTERChaque étape de la boucle a une entrée obligatoire, une sortie machine et une condition d'arrêt. État inconnu, couverture insuffisante, pas de backout en Amber ou Red, scope ou plan modifié, gate violé, seuil d'échec, provenance absente.
R5 · correction bornée
Et quand la correction tourne en rond ?
- générer
- valider
- corriger
- revalider
3 itérations automatiques au plus pour un même diagnostic. Deux corrections identiques qui échouent invalident l'hypothèse : on retourne aux preuves.
Voir un exemple : un changement dont le scanner de secrets ne répond pas
Un changement quelconque. Supposons le scanner de secrets indisponible.
- 1ÉTAPES 1 À 3Elles passent.
- 2SECRET SCAN · R6L'outil ne répond pas. Le statut est BLOCKED, jamais PASS.
- 3PAS DE SUBSTITUTLe scan de policy ne compte pas à sa place.
- 4FAIL-LOUD · R12STOP, statut explicite, trace, prochaine action. L'absence d'alerte n'est pas un succès.
- 5PAS DE GOL'étape 10 n'est pas atteinte : aucun GO, aucune application.
Le mécanisme · après l'application · L6
Que reste-t-il à tenir une fois le changement appliqué ?
Le GO n'est pas la fin. En L6, runtime governor et outcome gates limitent l'impact après activation. Trois règles encadrent la suite.
- DEPLOYMENT N'EST PAS RELEASELe déploiement place l'artefact, la release l'expose. Release immuable, feature flag, dark launch, shadow, canary ou progressive delivery quand le profile le permet.
- RESTAURATIONTout changement Amber ou Red choisit sa voie de retour : rollback, restore depuis une sauvegarde testée, compensation, roll-forward documenté ou dégradation maîtrisée. Aucun rollback vers un artefact connu vulnérable sans décision Red explicite.
- ANTI-DRIFTAprès toute action manuelle ou break-glass, comparer Desired State et Observed State (l'état voulu et l'état observé), puis réconcilier ou ouvrir une dérogation datée.
Ce qu'elle produit
Que produit la colonne concrètement ?
01 · TESTS
Des preuves rejouables
Fonctionnels et de régression ; fitness functions qui rendent les fondations testables en continu.
02 · POLICIES
Des règles hors de l'IA
Le scan de policy, et l'autorité structurelle de L5 : pipeline, policy, admission.
03 · HOOKS
Des arrêts au plus près
Côté outil (L3) et avant publication (L4).
04 · GATES
Des conditions d'arrêt
Du GO sur plan hashé aux outcome gates de L6. Toute gate mesure aussi son coût.
Dans la boucle
Où intervient-elle dans la boucle ?
Enforcement Layers tient AUTHORIZE, et garde toutes les transitions de SENSE à LEARN : chaque flèche ci-dessous est un point de contrôle.
Le GO porte sur un plan hashé et un scope exact.
Chaque étape a une entrée obligatoire, une sortie machine et une condition d'arrêt.
Les règles qui la portent
- R5CORRECTION BORNÉEGénérer, valider, corriger, revalider : 3 itérations automatiques au plus pour un même diagnostic.
- R6VALIDATION FAIL-FASTN/A avec raison et preuve, jamais omis en silence ; outil indisponible donne BLOCKED, jamais PASS.
- R12FAIL-LOUDErreur ou preuve manquante : STOP, statut explicite, trace, prochaine action ; UNKNOWN n'est ni PASS ni FAIL.
L'inspection · test de complétude
Comment vérifier que la colonne est en place ?
« Quels invariants sont mécaniquement imposés ? »
Pouvez-vous montrer, pièces à l'appui :
- 1pour chaque invariant, son niveau actuel et son niveau cible, de L1 à L6 ;
- 2pour ceux que vous présentez comme garantis, le contrôle L5 ou L6 qui les impose, et non une instruction ;
- 3le passage d'un changement récent par les 10 étapes, secret scan distinct compris ;
- 4les contrôles marqués N/A avec leur raison et leur preuve, et aucun BLOCKED ou UNKNOWN compté comme PASS ;
- 5le coût mesuré de chaque gate : lead time, faux positifs, toil, contournements.
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
Quelles fondations sert-elle ?
F2Outcomes before execution
Outcomes
F5Reversibility before change
Réversibilité
F7Declarative and reconcilable operations
Déclaratif
F8Learning becomes deterministic
Déterminisme
Les 8 fondations normatives et leur définition sont sur la page du temple.
Les limites font partie du contrat
Qu'est-ce que ce n'est pas ?
Enforcement Layers dit à quel niveau chaque règle est réellement imposée, et refuse les raccourcis suivants.
- Pas des consignes données à l'IA. Une consigne est L1, probabiliste : l'écrire ne la rend pas bloquante.
- Pas un empilement gratuit de contrôles. Toute gate mesure aussi son coût : lead time, faux positifs, toil, contournements.
- Une commande réussie n'est pas une opération réussie. Seul VERIFY conclut.
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 Enforcement Layers y changerait.
Réserver un audit de 30 min