Proposer une action, l’autoriser et vérifier son effet sont des responsabilités différentes.

Qui fait quoi ?

Les responsables humains fixent le cadre

Ils définissent le besoin, les droits, les règles, les budgets et les validations requises. L’approbation humaine intervient lorsqu’elle est demandée par ce cadre ; elle ne signifie pas que chaque opération doit être confirmée manuellement.

Les superviseurs conduisent le travail

Le superviseur racine porte l’objectif et les arbitrages transversaux. Des superviseurs de périmètre peuvent organiser une partie du travail. Une difficulté doit revenir au responsable capable de la traiter.

Les agents produisent, les revues examinent

Les agents analysent ou réalisent les tâches autorisées. Une revue examine le candidat et les preuves reçues ; un agent qui approuve son propre travail ne constitue pas une revue indépendante.

Le moteur vérifie les transitions

Le noyau déterministe Rust conserve l’état, organise tâches et dépendances, vérifie les conditions prises en charge et applique les décisions autorisées. Les outils et services externes doivent aussi faire respecter leurs propres frontières d’accès.

Le parcours d’une demande

Ce parcours explique les responsabilités du système. Il ne décrit pas une protection déjà qualifiée pour n’importe quel outil ou déploiement.

1. Cadrer le résultat attendu

   Énoncer le besoin et ses critères observables : ce qui doit changer, ce qui doit rester protégé et les preuves attendues. Le plan décompose le travail et ses dépendances.

2. Vérifier les conditions de départ

   Examiner le périmètre, l’identité, les droits, les politiques et les réservations applicables. Le contexte transmis à l’agent doit être identifié ; retrouver une procédure en mémoire ne donne pas le droit de l’exécuter.

3. Produire un candidat et ses preuves

   L’agent réalise son travail dans les limites autorisées. Sa remise doit permettre de savoir quel candidat est examiné, avec quelles sources et quels résultats de contrôle.

4. Examiner avant d’accepter

   Les contrôles et la revue portent sur ce candidat. Une preuve obtenue pour une autre version ne suffit pas. Le moteur revérifie les conditions requises avant une transition d’acceptation ; le jugement du responsable reste distinct de cette application.

5. Traiter les écarts et les effets incertains

   Un refus, un défaut ou une preuve manquante doit être conservé et remis au bon responsable. Si l’issue d’une opération est inconnue, examiner l’état réellement enregistré avant de la répéter. La reprise ne doit pas effacer l’échec initial.

Exemple : réparer une fuite, pas améliorer un indicateur

Une équipe demande de corriger une API qui transmet un dossier client sans vérifier les droits du demandeur. Le test de sécurité reproduit cet accès et échoue. L’agent propose de supprimer ce test pour retrouver un tableau vert.

Deux questions différentes se posent. A-t-il le droit de supprimer ce contrôle ? Un mandat de réparation ne donne pas, à lui seul, ce droit. Une frontière correctement raccordée doit refuser une modification protégée hors mandat avant son effet.

La fuite est-elle corrigée ? Il faut rejouer l’accès interdit sur la version proposée et constater son refus, puis vérifier qu’un utilisateur autorisé peut encore consulter son dossier. Un rapport convaincant ou une suite amputée ne répond pas à cette question.

Dans la grille personnelle de Fabrice, N6 porte sur la gouvernance de l’action ; N7 étend l’examen à l’adéquation entre l’objectif et les preuves du résultat. Ce sont des repères de lecture, pas des services qui rendraient automatiquement chaque décision juste, ni une preuve d’alignement interne du modèle.