Le problème est né d’un succès. En quelques mois, les métiers avaient créé plus de 2 000 agents, y compris par des utilisateurs non techniques. Les faire passer un par un devant la conformité, la sécurité, le juridique et la DSI aurait annulé le bénéfice du déploiement.

J’avais d’abord rédigé la charte IA puis encadré, sur les plans contractuel et opérationnel, le déploiement de la première plateforme de création d’agents, ainsi que ses contenus de formation. Lorsque le registre AI Act et la qualification du parc sont devenus nécessaires, j’ai produit un premier modèle complet puis réuni les fonctions de contrôle et les équipes techniques autour d’une doctrine commune. AIR a servi à l’appliquer et à l’éprouver sur le parc réel.

Le registre ne suffit pas à contrôler l’action

Un registre décrit ce qui existe. Il reste indispensable pour connaître le responsable d’un système, sa finalité et les données qu’il utilise. Mais un agent peut changer de comportement dès qu’on lui donne un nouvel outil, une nouvelle source ou davantage d’autonomie.

Deux agents construits sur la même plateforme peuvent donc porter des risques très différents. L’un résume des documents déjà accessibles. L’autre sélectionne des candidats, consulte un outil RH et déclenche une action. Le modèle est identique. La finalité, les données, les droits et les conséquences ne le sont pas.

La bonne unité de contrôle n’est plus seulement le projet déclaré. C’est l’action, dans son contexte.

Transformer des politiques dispersées en doctrine commune

Au départ, les règles vivaient dans des politiques rédigées par des équipes différentes. Chaque nouveau cas relançait les mêmes questions. Nous les avons ramenées à un cadre versionné, lisible par les experts et exploitable par une IA.

Le modèle structure les faits nécessaires à la qualification. Des règles explicites les confrontent aux obligations internes, à la sécurité et au droit applicable. Les cas clairs passent automatiquement. Les experts instruisent les exceptions et contrôlent régulièrement des échantillons. Le contrôle humain reste réel, sans recréer un guichet devant chaque usage.

01

Doctrine

La règle, sa source, son périmètre et sa version.

02

Faits

Les informations nécessaires pour qualifier le système.

03

Décision et preuves

Le résultat, les règles déclenchées et leur justification.

04

Points d’application

Le registre, les plateformes, les connecteurs et les contrôles.

Ce que la doctrine a changé dans le programme

Appliquée au parc via AIR, la doctrine qualifie plus de 2 000 agents et systèmes IA en une dizaine de minutes. Selon la version active, 96 à 97 % du parc suit la voie verte. Les experts peuvent consacrer leur temps aux rares cas qui demandent une instruction.

Lorsqu’une règle évolue, l’équipe mesure son effet sur tout le parc avant de la publier. Les résultats alimentent le registre AI Act et servent de référence aux solutions de gouvernance appelées à prendre le relais, notamment la future AI Gateway. AIR est le véhicule interne de cette démarche. La valeur réutilisable réside dans la manière de formaliser les règles avec les experts, de les rendre applicables et de produire une décision traçable.

Le cas de gouvernance à l’échelle présente le programme, les responsabilités et les résultats avec davantage de contexte.

La démarche ne s’arrête pas à AIR. J’ai aussi conçu des agents, des moteurs d’analyse et des skills réutilisables pour l’investissement et les contrats. L’assistant de référence, aujourd’hui le plus utilisé de la plateforme, aide les métiers à créer leurs propres agents, vérifie leur cadre d’usage et ajoute les garde-fous adaptés à partir de cette bibliothèque.

Le contrôle humain ne consiste pas à tout approuver

Faire confirmer chaque décision peut annuler une grande partie du gain de l’automatisation. Dans le programme, les cas conformes passent automatiquement. Les experts traitent les exceptions et revoient des échantillons à intervalles réguliers.

Le niveau de contrôle dépend de la conséquence possible. Une recherche documentaire peut être journalisée. Un envoi externe peut demander une confirmation. Une décision qui affecte une personne peut nécessiter une revue explicite et un recours. La réversibilité, la sensibilité des données et la capacité à détecter une erreur comptent autant que le modèle utilisé.

Journaliser

Conserver l’action, son origine, le contexte et la règle appliquée.

Échantillonner

Revoir régulièrement des décisions automatisées, même conformes.

Escalader

Confier aux experts les cas ambigus ou sensibles.

Bloquer

Empêcher une action ou un accès qui sort du cadre autorisé.

Le contrôle doit aussi descendre jusqu’aux connecteurs

Le risque change dès qu’un agent peut agir sur un système extérieur : lire une donnée, envoyer un message, modifier un dossier ou déclencher une opération. Il faut alors savoir au nom de qui l’action est exécutée, utilisateur, service ou agent, avec quels droits et dans quel périmètre.

Pour les futurs connecteurs, l’architecture MCP offre un cadre dans lequel les décisions d’autorisation et les politiques de sécurité restent du côté de l’hôte. Les travaux de l’ OWASP sur les systèmes agentiques couvrent aussi le détournement d’objectif, l’usage des outils, la mémoire et les interactions entre agents. Le registre reste nécessaire, mais une partie du contrôle doit aller jusqu’au moment de l’action.

Le calendrier réglementaire bouge, pas le problème opérationnel

Le règlement (UE) 2026/1744 a reporté l’application d’une partie des exigences concernant les systèmes à haut risque à décembre 2027 ou août 2028 selon leur catégorie. Il n’a pas supprimé le besoin de gérer les risques, les journaux et la supervision dans le temps. Construire une doctrine commune reste utile avant même qu’une obligation devienne applicable.

Le test que j’utilise maintenant

Avant d’ajouter un contrôle, je pose quatre questions. Où peut-il être appliqué sans être contourné ? Sur quelle information prend-il sa décision ? Quelle preuve conserve-t-il ? Que se passe-t-il quand la règle change ?

Si personne ne peut répondre, le contrôle existe probablement sur le papier seulement. C’est là que commence le travail d’architecture et d’organisation.

Références de travail : règlement (UE) 2024/1689, règlement (UE) 2026/1744, architecture MCP et OWASP Top 10 for Agentic Applications 2026.