Sécuriser un développement IA-augmenté : le contrôle qui tient est imposé, pas supervisé

Une précédente publication de cette série a posé une limite nette : faire relire le code d’une IA par une autre IA déplace le contrôle sans le refermer. Deux modèles proches partagent des angles morts, et le dernier maillon fiable reste un regard humain.

La suite logique semble être d’ajouter de l’intelligence au-dessus, un agent superviseur plus capable, chargé de rattraper ce que les autres laissent passer. L’intuition est répandue, et elle se trompe de niveau. Un superviseur qui relit des conclusions valide surtout les erreurs les mieux argumentées. Ce qui fait tenir une chaîne où l’IA produit une part croissante du code se joue ailleurs : dans une architecture de contrôle que le système impose et qu’aucun agent ne peut contourner.

La distinction est concrète. Un contrôle qu’un agent choisit d’exécuter dépend de l’état de cet agent, de son contexte, de ses instructions, de sa charge. Un contrôle que le système exécute ne dépend d’aucun de ces facteurs. Toute la fiabilité d’un développement IA-augmenté se joue dans cet écart.

Relire un raisonnement n’est pas le mesurer

Un raisonnement se relit, un effet se mesure. Ce sont deux opérations différentes, et les confondre fonde l’illusion du superviseur.

Prenons une opération de maintenance conduite sur un parc de sites. Le script rapporte un succès : chaque serveur répond, le code de statut attendu remonte, le contrôle de sortie est vert. Sauf que le signal observé, la réponse du serveur, est aveugle au dégât réel. Sur plusieurs sites, l’application a perdu le droit d’écrire sur son propre système de fichiers. Le contrôle mesurait une chose, le serveur répond, en croyant en mesurer une autre, l’opération a réussi.

Quelques heures plus tard, l’incident remonte par un utilisateur. Une session d’analyse, sans le contexte de l’opération d’origine, reconstruit une cause plausible et cohérente. Elle est fausse. Ce qui la renverse n’est ni un raisonnement plus fin ni une relecture par une instance plus capable, mais un fait daté, relevé sur le système, la date de modification d’un fichier de configuration, qui contredit l’hypothèse.

Un superviseur qui se serait contenté de relire cette analyse l’aurait validée. Elle était bien construite. Ce qui l’a tuée, c’est une mesure, pas une autorité. Empiler de l’intelligence au-dessus d’une chaîne ne transforme jamais une relecture de raisonnement en vérification de fait. Un contrôle qui lit vaut moins qu’un contrôle qui mesure.

Le contrôle qui tient n’est pas celui qu’un agent choisit d’appliquer

Admettons cette limite et posons la vraie question : quel contrôle tient quand l’agent censé l’appliquer est lui-même faillible ?

Un agent de revue, même bien instruit, reste quelque chose qu’une session invoque. Il partage la condition de toute session : il peut être lancé sans le bon contexte, sur des instructions incomplètes, ou simplement omis parce que l’opération semblait bénigne. Sa protection dépend de la discipline de celui qui l’appelle. C’est un contrôle par convention, et une convention se saute. Elle se saute d’autant plus facilement que rien, dans l’exécution, ne la rend obligatoire : elle vit dans les instructions données à un agent, pas dans le mécanisme qui exécute ses actions.

Le contrôle qui tient est d’une autre nature. C’est celui que le système exécute, pas celui qu’un agent décide d’exécuter. Dans une chaîne agentique, cette couche existe : l’environnement qui encadre les agents peut refuser une commande avant qu’elle parte, indépendamment de ce que l’agent a compris de la situation. Une règle de ce type ne s’oublie pas, ne se contourne pas, et ne dépend pas de l’état d’une session. Elle s’applique, point.

L’écart entre les deux se mesure vite sur une configuration réelle. Prenons une chaîne d’agents dotée de plusieurs centaines de règles d’autorisation et d’aucune règle d’interdiction. La lecture est trompeuse : cela ressemble à un dispositif riche. En pratique, une commande irréversible sur le répertoire de production, un changement de propriétaire récursif, une suppression en masse, passe sans le moindre frottement, dans n’importe quelle session, à n’importe quelle heure. L’absence de règles d’interdiction n’est pas un détail de configuration, c’est le trou par lequel l’incident arrive.

Ce que reconnaît immédiatement une direction technique, c’est le principe sous-jacent : moindre privilège, et contrôles non contournables. Aucun des deux ne relève de l’intelligence des agents. Tous deux relèvent de ce que le système leur permet, et de ce qu’il leur refuse. La question de savoir qui, dans l’organisation, décide de ces règles et en répond appartient à un autre plan, celui de la gouvernance des agents autonomes. Le présent propos reste sur le mécanisme : ce que la machine autorise, et ce qu’elle bloque, avant toute décision humaine.

Le périmètre n’a pas disparu, il a changé de couche

Ce raisonnement a un précédent, et le nommer aide à le situer. Pendant vingt ans, la sécurité applicative s’est jouée au périmètre : un pare-feu, des règles réseau, une frontière que rien de ce qui tournait à l’intérieur ne pouvait discuter. Le contrôle était déterministe et imposé par construction. Personne ne demandait à une machine si elle acceptait de respecter le pare-feu.

L’ancre de cette série a posé le déplacement en cours : le risque a quitté le réseau pour entrer dans le code, parce que la fabrique du logiciel produit désormais, via l’IA, une part de ce code sans qu’un humain l’ait écrit ligne à ligne. La conclusion qu’on en tire trop vite est qu’il faudrait donc du discernement à l’intérieur, une intelligence capable de juger ce qui se produit. C’est reproduire l’erreur du superviseur, une couche plus bas.

La bonne conclusion est que la logique de contrôle suit le même déplacement que le risque. Elle ne s’abandonne pas au profit d’une supervision « intelligente », elle change de couche. Ce qui était imposé au réseau doit l’être à la couche d’exécution des agents : ce qu’un agent peut lire, écrire, déclencher, et surtout ce qu’il ne peut pas. Le pare-feu ne jugeait pas les intentions, il appliquait une règle. La couche agentique appelle le même genre de règle, au plus près de l’action.

Un dernier trait du modèle réseau mérite d’être gardé : le contrôle portait sur un fait, pas sur une déclaration. Une opération agentique a besoin du même ancrage. Vérifier qu’un serveur répond ne dit pas que l’opération a réussi ; vérifier que l’application peut effectivement écrire là où elle doit écrire, oui. Le critère de succès doit porter sur l’effet réel, pas sur un signal qui lui ressemble. C’est le point de contact avec le réel sans lequel un contrôle, aussi automatisé soit-il, ne produit que des validations plausibles.

Ce point mérite d’être tenu fermement, parce que l’automatisation le fragilise. Plus une chaîne enchaîne d’étapes sans jamais toucher un fait, plus elle produit vite des conclusions cohérentes et invérifiées. Un contrôle branché sur le réel ne va pas plus vite, il va plus juste : il arrête la chaîne quand l’effet attendu n’est pas là, au lieu de la laisser filer sur un signal qui rassure. La vitesse d’une chaîne agentique n’a de valeur que si quelque chose, quelque part, vérifie qu’elle avance dans la bonne direction.

Concevoir le contrôle avant de renforcer l’intelligence

De tout cela se dégage un ordre de priorité, et c’est là que se situe la décision.

On ne fiabilise pas une chaîne agentique en posant une IA plus intelligente à son sommet. On la fiabilise en concevant d’abord l’architecture qui la contraint. Cette architecture tient en trois pièces, dont aucune ne repose sur la capacité des modèles. Des garde-fous déterministes, exécutés par l’environnement qui encadre les agents et non par les agents eux-mêmes, qui rendent les opérations irréversibles impossibles sans validation explicite. Des critères de succès branchés sur l’effet réel plutôt que sur un signal indirect. Une mémoire des opérations partagée entre les sessions, pour que la leçon tirée d’une opération soit lisible par les suivantes, même lorsqu’elle arrive après coup.

Ces trois pièces ont un trait commun : chacune est un endroit où la chaîne rencontre un fait plutôt qu’une déclaration. Le garde-fou impose une règle, le critère mesure un effet, la mémoire transmet une leçon vérifiée. C’est cette accumulation de points de contact avec le réel, et non la finesse d’un superviseur, qui tient l’ensemble.

Dans cette architecture, une IA de supervision a une place, mais une place précise. Elle n’est utile que si sa mission est d’aller vérifier le réel, pas de relire un raisonnement. Un agent chargé de recouper un journal d’opérations avec l’état constaté d’un parc produit de la valeur, parce qu’il confronte deux faits. Un agent chargé de valider les conclusions d’un autre agent ne fait que ce que ferait n’importe quel relecteur de texte : il valide du texte. La différence n’est pas dans l’intelligence du superviseur, elle est dans ce qu’on lui donne à examiner.

Reste alors une seule question à se poser devant une chaîne de développement IA-augmentée, qu’elle soit interne ou fournie par un tiers. Non pas : le modèle est-il assez intelligent pour ne pas se tromper. Mais : qu’est-ce que le système impose qu’aucune session ne peut contourner, et à quel moment chaque opération est-elle confrontée à un fait mesuré plutôt qu’à sa propre déclaration de succès. La réponse à cette question dit la solidité réelle de la chaîne. L’intelligence des modèles, elle, ne la dit pas.