Colonne ③ · Control Plane

Orchestrer identités, capacités et exécution

Le Control Plane transforme un plan autorisé en action bornée. Il ne laisse jamais le modèle convertir une intention en privilège.

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 : qui a le droit de faire quoi, ce qui autorise une exécution, ce qui la borne encore, ce qui change en urgence, comment le prouver.

Lire le mécanisme ↓

LE RÉFLEXE DU SANDBOX

Face à une IA qui exécute sur des systèmes réels, le réflexe est de lui donner des droits et de compter sur un sandbox pour contenir le reste. Le sandbox réduit l'impact sur l'hôte ; il ne remplace ni IAM, ni egress control, ni validation du plan.

Le Control Plane sépare qui propose, qui autorise et qui exécute, et lie chaque exécution à un mandat précis et daté.

Le mécanisme · les six principals · R11

Qui a le droit de faire quoi ?

Six principals (les identités qui agissent), chacun avec une autorité et un interdit. L'interdit compte autant que l'autorité : c'est lui qui empêche un rôle d'absorber les autres.

  • Author

    AUTORITÉ

    Propose code, plan, hypothèses.

    INTERDIT

    Ne s'accorde pas son propre mandat.

  • Approver

    AUTORITÉ

    Accepte un plan ou un scénario précis.

    INTERDIT

    N'approuve pas un scope qu'il ne voit pas.

  • Orchestrator

    AUTORITÉ

    Ordonne gates, locks et transitions.

    INTERDIT

    N'invente pas de décision technique.

  • Executor

    AUTORITÉ

    Exécute les capacités du mandat.

    INTERDIT

    Ne modifie ni plan, ni cible, ni permission.

  • Verifier

    AUTORITÉ

    Mesure l'outcome (le résultat obtenu) indépendamment.

    INTERDIT

    Ne masque pas un FAIL ou un UNKNOWN.

  • Incident Commander

    AUTORITÉ

    Tient priorités et autorité en mode Incident.

    INTERDIT

    Ne conserve pas le break-glass après Recovery.

  • UNE PERSONNE, PLUSIEURS RÔLESDans une petite structure, un acteur humain peut tenir plusieurs rôles. Identités, jetons, traces et transitions restent séparés.
  • SÉPARATION MÉCANIQUEUne instance solo peut cumuler les responsabilités humaines, mais l'autorisation et l'exécution restent séparées mécaniquement.

Le mécanisme · le mandat d'exécution

Qu'est-ce qui autorise une exécution, et jusqu'à quand ?

Un mandat d'exécution. Il lie en un seul objet ce qui est autorisé, où, par qui, jusqu'à quand, et comment revenir en arrière. Il porte une expiration.

  • QUOIQuel plan, quel artefact, quelles capacités ?
    • plan_hash
    • artifact_digest
    • commit_sha
    • capabilities
    • mode
    • lane
  • OÙSur quel périmètre exactement ?
    • environnement
    • targets
    • inventory
    • limit
    • tags
  • QUIQui a autorisé, dans quelle transaction ?
    • approver
    • trace_id
  • JUSQU'À QUANDPour combien de temps et de ressources ?
    • émission
    • expiration
    • budget de coût
    • rate limit
  • COMMENT REVENIRPar où repartir si l'action échoue ?
    • recovery_ref

CE QUI INVALIDE LE MANDAT

Toute modification du plan_hash, de l'artefact, de l'environnement, des targets, du limit, des tags ou des capacités invalide le mandat.

Le GO n'est ni une variable de session globale, ni une chaîne auto-déclarée par l'IA. Il existe dans le mandat, lié à ce plan et à ce périmètre, ou il n'existe pas.

Voir le mandat complet, champ par champ 
# mandat d'exécution : les champs du canon, valeurs fixées par votre instance
trace_id:        <identifiant de la transaction>
plan_hash:       <empreinte du plan autorisé>
artifact_digest: <digest de l'artefact>
commit_sha:      <commit de référence>
mode:            <mode actif>
lane:            <Green | Amber | Red>
environment:     <environnement cible>
targets:         [<cibles>]
inventory:       <inventaire>
limit:           <sous-ensemble autorisé>
tags:            [<tags>]
capabilities:    [<capacités autorisées>]
cost_budget:     <budget de coût>
rate_limit:      <limite de débit>
approver:        <identité de l'Approver>
issued_at:       <émission>
expires_at:      <expiration>
recovery_ref:    <chemin de retour>

Le framework fixe ces champs, pas leur format ni leurs valeurs : chaque instance les exprime avec ses propres outils.

Voir un exemple : un plan approuvé, du mandat à la preuve

Un seul plan, sans nom ni outil : un changement que l'IA propose d'exécuter.

  1. 1AUTHORL'IA propose le plan. Elle ne s'accorde pas son propre mandat.
  2. 2APPROVER · R11Un Approver accepte ce plan précis, dont il voit tout le scope.
  3. 3MANDATLe mandat est émis : il lie le plan_hash, l'environnement, les targets, les capacités, l'approver, l'expiration et le recovery_ref.
  4. 4EXECUTOR · R9L'Executor exécute les capacités du mandat, sous le governor. Un trace_id couvre la transaction, chaque étape produit un span_id.
  5. 5CIBLE AJOUTÉEEn cours de route, le plan devrait toucher une cible de plus. Le mandat est invalidé : l'Executor ne modifie pas la cible de lui-même.
  6. 6VERIFIERLe Verifier mesure l'outcome indépendamment. Un FAIL ou un UNKNOWN reste visible.
  7. 7PROVENANCE · R9Le commit porte ses trailers ; le gate les compare à l'Evidence Plane et échoue bruyamment s'ils manquent ou divergent.

Le mécanisme · le break-glass · R16

Que devient l'autorité en urgence ?

Elle ne disparaît pas. L'urgence passe par un break-glass (accès d'urgence), qui est lui-même un mandat.

  • UN MANDAT D'URGENCERaison, incident, capacités, scope, approver, TTL (durée de validité), alerte et journalisation immédiate. Rien n'y est implicite.
  • LA PREUVE CONTINUELe break-glass ne désactive pas la preuve. L'action d'urgence est tracée comme les autres.
  • RECOVERY REFERMERecovery révoque l'accès et réconcilie. L'Incident Commander ne conserve pas le break-glass après Recovery.

Le mécanisme · governor et containment

Un mandat valide suffit-il pour tout exécuter ?

Non. Même avec un mandat valide, un governor limite la vitesse et le rayon d'impact, et ce qui entre dans l'exécution reste traité comme non fiable.

Borner l'impact

Governor et containment

  • Quotas et budgets
  • Maximum de ressources affectées par fenêtre
  • Canary et progressive rollout
  • Circuit breakers et bulkheads
  • Concurrency locks
  • Kill switch et révocation
  • Egress default-deny, endpoints allowlistés
  • Sandbox isolant hôte, filesystem et credentials

Le sandbox réduit l'impact sur l'hôte ; il ne remplace ni IAM, ni egress control, ni validation du plan.

Contrôler ce qui entre

Secrets et supply chain

  • Secrets externalisés et injectés au runtime, jamais dans le prompt, l'image ou le log
  • Credentials JIT (émis juste à temps), scopés, révoqués après usage
  • Artefacts identifiés par digest, provenance vérifiée
  • SBOM ou ML-BOM quand le type d'artefact l'exige
  • Tout outil, plugin ou modèle externe traité comme supply chain non fiable

Ce qu'elle produit · R9

Comment prouver ce qui a été exécuté ?

La colonne produit un plan autorisé et des spans d'exécution : chaque action tracée dans son périmètre.

01 · LE PLAN AUTORISÉ

Qui peut exécuter quoi, où, combien de temps

Le mandat, lié au plan_hash et à son périmètre, avec son approver et son expiration.

02 · LES SPANS

Une trace par étape

Un trace_id couvre la transaction, chaque étape produit un span_id. Secrets et données sensibles sont redacted (masqués) avant persistance.

03 · LA PROVENANCE

Des commits qui se vérifient

Des trailers parsables : AI-Source, KB-Grounded, Risk-Lane, Trace-Id. Un gate les compare à l'Evidence Plane et échoue bruyamment en cas d'absence ou de divergence.

Dans la boucle

Où intervient-elle dans la boucle ?

Dans la boucle canonique, le Control Plane tient un temps : ACT.

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

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

EN ENTRÉE

Un plan hashé et sa lane, autorisés en amont, deviennent un mandat scopé et expirant.

ACT

L'Executor n'a aucune discrétion hors du mandat, et produit les preuves de l'action.

Les règles qui la portent

  • R9PROVENANCE TRANSACTIONNELLEUn trace_id par transaction, un span_id par étape, des trailers comparés à l'Evidence Plane.
  • R11SÉPARATION DES AUTORITÉSAutorisation et exécution séparées mécaniquement, même quand une personne tient plusieurs rôles.
  • R16MODESLe break-glass est un mandat d'urgence ; Recovery révoque l'accès et réconcilie.

L'inspection · test de complétude

Qui peut exécuter quoi, où et combien de temps ?

Prenez une exécution récente de l'IA sur un de vos systèmes réels. Pouvez-vous montrer, pièces à l'appui :

  1. 1qui a proposé le plan, qui l'a autorisé, et que ce n'était pas la même identité ;
  2. 2le mandat : plan_hash, environnement, targets, capacités, approver ;
  3. 3son expiration, et que l'exécution n'est pas sortie de son périmètre ;
  4. 4le trace_id de la transaction et un span_id par étape, secrets redacted ;
  5. 5les trailers du commit, concordants avec l'Evidence Plane.

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 ?

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 ?

Le Control Plane borne une exécution déjà autorisée. Il refuse les raccourcis suivants.

  • Pas un orchestrateur qui décide. L'Orchestrator ordonne gates, locks et transitions ; il n'invente pas de décision technique.
  • Pas une confiance dans le sandbox seul. Il réduit l'impact sur l'hôte ; IAM, egress control et validation du plan restent nécessaires.
  • Pas d'exception silencieuse. Une instance sans orchestrateur L5 peut fonctionner en Amber-HITL uniquement, par un ADR daté qui dit ce qui n'est pas garanti, les contrôles compensatoires, l'owner et la date de graduation.

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 Control Plane y changerait.

Réserver un audit de 30 min

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