Pourquoi l'IA agentique a besoin d'un plan de contrôle

Le modèle n'est plus le système

Les quatre chapitres précédents ont ajouté, un par un : la génération, la boucle, la connaissance, les mains. Chacun était un progrès. Mis bout à bout, ils produisent quelque chose que personne n’a conçu d’un seul geste.

Croissance

Dix-huit mois plus tard

Le premier système Le même système, en production

Agents: 3 20
Capacités appelables: 8 74
Sources de données: 4 11
Approbations humaines: 2 2

Aucune de ces additions n'était une erreur. C'est leur somme qui a changé de nature.

Actionnez l'interrupteur. Rien de ce qui apparaît n'est déraisonnable pris isolément.

Version textuelle

Le premier système compte 3 agents, 8 capacités appelables, 4 sources de données et 2 approbations humaines. Dix-huit mois plus tard : 20 agents, 74 capacités, 11 sources — et toujours 2 approbations humaines.

Regardez la dernière ligne. Tout a été multiplié, sauf le nombre d’endroits où quelqu’un décide. Ce n’est pas une négligence : personne n’a jamais pris la décision de ne pas en ajouter. Il n’y a simplement pas eu de moment où la question se posait.

Six questions sans destinataire

Arrêtons l’image sur un appel, au hasard, dans ce système.

L'appel figé

Appel en cours ajuster_seuil_alerte(ligne="L3", seuil=82.5)

Qui a demandé cela ? Qui peut répondre Personne. La requête part avec l'identité du service, pas celle d'une personne.
Qu'est-ce qui est tenté, exactement ? Qui peut répondre Le journal du système cible l'enregistrera après coup.
Pourquoi cet outil plutôt qu'un autre ? Qui peut répondre Personne. Le raisonnement qui l'a choisi n'a été conservé nulle part.
Sur quelles données la décision s'appuie-t-elle ? Qui peut répondre Personne. Le contexte a été assemblé puis jeté.
Qui a autorisé cet appel ? Qui peut répondre Personne. Aucune autorisation n'a été demandée — donc aucune n'a été refusée.
Que s'est-il réellement produit ensuite ? Qui peut répondre Une ligne d'horodatage et un code 200. Rien sur l'effet.

Une seule de ces six questions a une réponse, et c'est la moins utile le jour où quelque chose se passe mal.

Six questions ordinaires. La colonne de droite dit qui, dans ce système, peut y répondre aujourd'hui.

Version textuelle

Six questions sur un appel en cours : qui a demandé, ce qui est tenté, pourquoi cet outil, sur quelles données, qui a autorisé, ce qui s’est réellement produit. Une seule a une réponse — ce qui est tenté, que le système cible enregistrera. Les cinq autres n’ont aucun destinataire.

Ces six questions ne sont pas des exigences réglementaires. Ce sont les questions que n’importe qui pose le lendemain d’un incident, et elles définissent, à elles seules, ce qu’une couche de contrôle doit produire.

Une couche entre la décision et l'effet

Un plan de contrôle ne remplace ni le modèle ni les outils. Il se place entre les deux, à l’endroit exact que le chapitre précédent a laissé vide : là où une proposition devient un appel.

Le plan de contrôle

En amont

Agent

Plan de contrôle

Identité Qui demande, et au nom de qui. L'identité de la personne survit jusqu'au bout de la chaîne.
Politique Ce qui est permis, à qui, dans quelles limites — écrit hors du prompt, et vrai même si le prompt change.
Permissions Le régime de chaque outil : interdit, soumis à approbation, ou automatisé.
Approbation humaine Le point où une personne décide, avec assez de contexte pour que ce soit une vraie décision.
Trace La suite des décisions, pas seulement la suite des appels.
Preuve Ce qui reste après coup, et qui permet de reconstituer sans faire confiance au récit.

En aval

Outils
Systèmes
Équipements

Chacune de ces fonctions répond à l'une des six questions de la scène précédente. Ce n'est pas une coïncidence : c'est le cahier des charges.

Ce n'est pas une boîte ajoutée à côté du système. C'est un passage obligé.

Version textuelle

Un plan de contrôle s’intercale entre l’agent et les outils. Il porte six fonctions : identité, politique, permissions, approbation humaine, trace et preuve — chacune répondant à l’une des six questions restées sans destinataire.

Une action rencontre une politique

Voyons ce que cela donne sur un cas concret. Un agent de supervision propose une modification sur une ligne de production.

Porte de politique

Action proposée ajuster_temperature_fermentation(cuve="F-12", delta="+3°C") Demandeur agent-supervision-03, pour marie.l@exemple.fr

Évaluation

Identité de l'agent agent-supervision-03, agissant pour un utilisateur identifié.
Site et périmètre La cuve F-12 fait partie du périmètre déclaré de cet agent.
Plage autorisée La politique du site plafonne l'ajustement automatique à +1,5 °C. La demande porte sur +3 °C.
Approbation humaine Au-delà de la plage, l'action devient soumise à approbation. Une personne habilitée est sollicitée.

L'action est suspendue. Elle ne s'exécutera pas d'elle-même, et elle ne s'annulera pas d'elle-même non plus.

Trois contrôles passent, un échoue, un quatrième escalade. À vous de décider — et regardez ce qui est enregistré dans chaque cas.

Version textuelle

Un agent propose d’ajuster la température d’une cuve de +3 °C. L’identité et le périmètre passent ; la plage autorisée échoue, la politique du site plafonnant l’ajustement automatique à +1,5 °C ; l’action devient soumise à approbation humaine. Qu’elle soit approuvée ou refusée, l’enregistrement contient le même socle — identifiant de run, demandeur, action, politique appliquée, décision humaine et motif — et diffère seulement sur ce qui a suivi.

Deux choses méritent d’être remarquées. La politique n’a pas dit non : elle a dit pas tout seul. Et le refus produit un enregistrement aussi complet que l’approbation, parce qu’un système qui n’enregistre que ce qu’il a fait ne permet jamais d’expliquer ce qu’il n’a pas fait.

Un journal n'est pas une explication

« Nous avons des logs » est la réponse la plus fréquente à tout ce qui précède. Mettons-la à l’épreuve d’une question réelle.

Journal et trace

La question, le lendemain Pourquoi la température de la cuve F-12 a-t-elle été modifiée hier après-midi ?

Ce que le journal contient

14:07:41 POST /v1/chat 200 1243ms
14:07:49 POST /mcp/tools/call 200 180ms
14:07:52 POST /equip/setpoint 200 94ms
14:07:53 POST /v1/chat 200 870ms
14:19:03 GET /equip/state 200 31ms

Aucune de ces lignes ne dit qui, ni pourquoi, ni qui a accepté. On sait que quelque chose s'est produit et que ça n'a pas échoué.

Ce que la trace contient

Objectif reçu : rattraper la dérive thermique du lot 2411 demandé par marie.l@exemple.fr
Contexte assemblé : 3 relevés capteurs, consigne du lot, politique du site références conservées, pas de copie
Action proposée : +3 °C sur F-12 agent-supervision-03
Politique évaluée : dépassement de la plage automatique plage-fermentation v7
Approbation demandée puis accordée thomas.b@exemple.fr — motif enregistré
Exécution, puis effet observé sur l'équipement +2,9 °C à 14:19:03

Chaque maillon a un auteur, une raison et un horodatage. La question du lendemain trouve sa réponse sans avoir à croire qui que ce soit sur parole.

Une limite à énoncer clairement : une trace enregistre des décisions observables — entrées, sorties, appels, politiques appliquées, choix humains, effets constatés. Elle ne reconstitue pas ce qui s'est passé à l'intérieur du modèle. Personne ne sait le faire, et un produit qui le promet vous ment.

Le même run, enregistré de deux façons. Les deux sont exacts.

Version textuelle

Le journal contient cinq lignes de requêtes HTTP avec leurs codes et leurs durées : on sait que quelque chose s’est produit sans échouer. La trace contient l’objectif et son demandeur, le contexte assemblé, l’action proposée, la politique évaluée, l’approbation accordée avec son motif, puis l’exécution et l’effet constaté.

Ce qu'un run laisse derrière lui

Une trace utile n’est pas un fichier de plus. C’est un dossier constitué pendant l’exécution, parce qu’il ne peut pas l’être après.

Dossier de preuve

Enregistré pendant le run

run_id: r-8f3a20e1
identité: marie.l@exemple.fr via agent-supervision-03
modèle et version: local · gguf q4 · empreinte du poids
référence de contexte: 3 relevés + politique v7 (références, non copies)
appel demandé: ajuster_temperature_fermentation(F-12, +3°C)
décision de politique: hors plage automatique → approbation requise
décision humaine: approuvée · thomas.b@exemple.fr · motif
résultat de l'appel: accusé équipement, consigne acceptée
horodatages: proposition, décision, exécution, effet constaté
chaînage: condensat de l'entrée précédente

Ce que cela rend traitable

Incident Reconstituer la séquence exacte sans dépendre de ce dont les gens se souviennent.
Cause racine Distinguer une politique mal réglée d'un agent qui a mal choisi, et d'un équipement qui a mal réagi.
Audit Montrer que la règle en vigueur ce jour-là a été appliquée, et par qui l'exception a été assumée.
Amélioration Voir où les approbations s'accumulent, et décider ce qui peut légitimement s'automatiser.

Le journal est à altération détectable : chaque entrée est chaînée à la précédente, de sorte qu'une modification postérieure se voie. Détectable, et non impossible — la nuance est le seul énoncé honnête, et c'est déjà ce qui permet de se disputer sur des faits plutôt que sur des souvenirs.

À gauche ce qui est enregistré, à droite les questions que cela rend traitables.

Version textuelle

Le dossier enregistre pendant le run : identifiant, identité du demandeur, modèle et version, références du contexte, appel demandé, décision de politique, décision humaine avec son motif, résultat, horodatages et chaînage des entrées. Cela rend traitables quatre choses : l’analyse d’incident, la recherche de cause racine, l’audit, et l’amélioration des règles.

Un humain partout serait un humain nulle part

L’erreur symétrique de l’absence de contrôle, c’est le contrôle uniforme. Une organisation qui doit approuver chaque lecture de capteur cesse d’approuver quoi que ce soit au bout d’une semaine : les gens cliquent, et la validation devient un rituel vide.

Le curseur du chapitre 02 revient, mais il ne porte plus sur l’autonomie du système. Il porte sur le risque de l’action.

Régime par niveau de risque

Sans effet Irréversible

Lire
Préparer
Ajuster
Engager
Arrêter

Modifier un seuil d'alerte, changer un paramètre réversible dans une plage connue.

Régime approprié

Automatique dans la plage déclarée
Approbation dès qu'on en sort
Alerte si la fréquence sort de l'ordinaire

Déplacez le curseur. Ce n'est pas la compétence du système qui change, c'est ce que l'action peut casser.

Version textuelle

Cinq niveaux de risque, du sans-effet à l’irréversible. Lire et préparer sont automatiques mais enregistrés. Ajuster est automatique dans une plage déclarée et soumis à approbation dès qu’on en sort. Engager exige une approbation systématique et une séparation entre demandeur et approbateur. Arrêter exige une approbation humaine explicite, jamais déléguée.

Un contrôle bien placé se remarque peu. C’est précisément parce qu’il est rare qu’il reste une décision.

Ce qui peut mal tourner

Ce qu'un plan de contrôle ne fait pas

Il ne rend pas le modèle plus juste. Un agent qui se trompe se trompera toujours ; il se trompera devant témoin, dans des limites, et de façon reconstituable. C’est beaucoup, et ce n’est pas la même chose.

Il n’explique pas le modèle. La trace enregistre ce qui est observable : entrées, sorties, appels, politiques, décisions, effets. L’intérieur du modèle reste hors de portée, et aucun outil ne changera cela.

Une politique mal écrite est appliquée fidèlement. Le contrôle déplace la question — de « qu’a fait l’agent » vers « qu’avons-nous autorisé ». C’est un meilleur endroit pour la poser, ce n’est pas une réponse.

Un contrôle qu’on contourne ne protège rien. S’il ralentit sans discernement, les équipes trouveront le chemin qui l’évite, et c’est ce chemin qui deviendra le système réel. Doser les régimes n’est pas du confort : c’est ce qui décide si le dispositif tient.

Là où nous travaillons

Vous venez de parcourir cinq couches. Le modèle engendre. L’agent agit. Le contexte informe. Le protocole donne accès. Et la dernière couche décide de ce qui est permis, le fait décider par quelqu’un quand il le faut, et en garde de quoi rendre des comptes.

C’est celle-là que nous construisons. SwarmForge est un orchestrateur d’agents qui s’installe sur votre infrastructure, exécute ses modèles localement, gouverne les appels d’outils par une politique tenue hors du prompt, fait passer les actions sensibles par une personne identifiée, et écrit un journal à altération détectable de ce qui a été demandé, décidé et fait.

Deux choses que nous ne dirons pas. Nous ne sommes titulaires d’aucune certification, et la documentation de conformité que nous produisons — RGPD, AI Act, secret professionnel — est documentée, non certifiée : elle outille votre démarche, elle ne s’y substitue pas. Et rien de tout cela ne rendra un agent infaillible ; l’objet est qu’une erreur reste dans des limites, devant témoin, et reconstituable.

Si vous construisez une IA agentique qui touche à des opérations réelles, la conversation qui nous intéresse commence exactement ici.

Vous êtes ici

Vous êtes arrivé à la couche de contrôle. Ce qui suit ne se lit plus, ça se conçoit.