Guide conformité et gouvernance des agents IA en entreprise

Un agent IA n'est pas seulement un générateur de texte. C'est un système capable d'agréger des données, d'appeler des outils, d'enchaîner des étapes et de produire un effet métier visible. C'est pour cela que la gouvernance intéresse directement la direction générale. Cinq questions structurent immédiatement le sujet. Quel est le périmètre exact de l'agent. Quelles données peut-il utiliser. Avec quelles permissions opère-t-il. À quel moment un humain doit-il intervenir. Quelles preuves restent disponibles si une décision doit être expliquée ou contestée. Tant que ces réponses ne sont pas formalisées, la performance apparente masque souvent un risque structurel. En pratique, la conformité IA évite trois dettes très coûteuses, dette réglementaire, dette de confiance et dette technique. Elle n'est donc pas un supplément documentaire. Elle devient une condition de passage à l'échelle et de pilotage managérial.

Le bon réflexe consiste à raisonner par usage, pas par fascination technologique. Le Règlement (UE) 2024/1689, appelé AI Act, organise les obligations autour du risque et prévoit une application progressive entre 2025 et 2027. Un agent qui prépare des synthèses internes n'appelle pas le même niveau de vigilance qu'un système qui influence un recrutement, une décision financière ou l'accès à un service sensible. L'entreprise doit donc cartographier chaque cas d'usage, identifier son rôle, fournisseur, intégrateur, deployer ou sous traitant, puis documenter limites, surveillance humaine, incidents et performances attendues. La transparence devient également non négociable. Dès qu'un agent répond à un client, transforme une information ou prépare une décision, l'organisation doit pouvoir expliquer où l'IA intervient et selon quelles règles. Le sujet n'est plus théorique. Il structure déjà les déploiements crédibles en 2026.

Un projet d'agent IA conforme au RGPD repose sur quatre décisions fondamentales. Premièrement, clarifier les rôles, responsable de traitement, sous traitant, intégrateur, hébergeur, fournisseur de modèle et autres briques de la chaîne. Deuxièmement, limiter les données à la finalité utile. Un agent SAV n'a pas besoin d'accéder aux dossiers RH. Troisièmement, gouverner prompts, outputs, évaluations et logs comme de véritables traitements de données. Quatrièmement, vérifier si le projet exige une analyse d'impact ou s'il touche le champ de l'article 22 sur les décisions automatisées produisant des effets significatifs. Cette lecture rejoint les principes classiques du RGPD, finalité, minimisation, base légale, sécurité et droits des personnes. Dans le contexte agentique, elle devient plus concrète encore, car la qualité de la conformité dépend directement du design opérationnel du système et du rôle réellement laissé à l'humain.

Dans un projet d'agents IA, la chaîne technique est souvent plus longue que prévu. Une requête peut naître dans un front, passer par un backend, être enrichie par une base vectorielle, être traitée par un modèle, déclencher un tool call, consulter ensuite un CRM puis être loggée dans un outil d'observabilité. Chacune de ces briques possède potentiellement sa propre localisation, sa propre politique de conservation et ses propres sous traitants. C'est pourquoi la résidence réelle des données est une propriété d'architecture, pas un argument marketing isolé. Une entreprise sérieuse doit demander des éléments précis, régions utilisées, mécanismes de transfert, clauses contractuelles types si nécessaire, politique d'opt out pour l'entraînement, durée de conservation, capacité de suppression et liste de sous traitants. Cette discipline évite deux excès coûteux, tout bloquer sans discernement, ou tout envoyer hors périmètre au seul motif que le gain métier semble immédiat.

Les journaux d'un agent IA remplissent plusieurs fonctions en même temps. Ils servent à la conformité parce qu'ils démontrent le mécanisme de contrôle. Ils servent à la sécurité parce qu'ils révèlent les dérives de permissions ou les usages inattendus. Ils servent enfin à l'amélioration continue parce qu'ils expliquent pourquoi une erreur se répète. Un audit trail utile doit donc lier l'exécution à une configuration précise, version du modèle, du prompt, des outils, des permissions et des règles métier. Il doit aussi enregistrer l'origine de la requête, les sources consultées, les actions déclenchées, le résultat final, le coût d'exécution et les validations humaines éventuelles. L'erreur fréquente consiste à tout conserver sans stratégie. Un bon journal n'est pas une poubelle de données. Il est minimisé, protégé, segmenté et gouverné par une durée de conservation claire, faute de quoi la trace devient à son tour un risque.

La meilleure manière de penser la supervision humaine consiste à raisonner par mode opératoire. Un agent peut être en mode assistance, et ne produire que des brouillons. Il peut être en mode draft avec validation avant envoi. Il peut être en mode exécution bornée pour mettre à jour une fiche interne dans des limites strictes. Il peut enfin toucher un mode critique, où toute action RH, financière, juridique ou commerciale engageante exige un contrôle humain explicite. Cette gradation évite deux dérives opposées, la sous surveillance et la sur surveillance. Elle suppose également que le réviseur humain dispose d'un contexte lisible, source utilisée, recommandation, règle appliquée, portée de l'action et possibilité de corriger. Sans cela, la validation devient symbolique. Une organisation croit garder la main alors qu'elle n'exerce qu'un contrôle apparent. La supervision crédible n'est donc pas un bouton, c'est une mécanique opérationnelle.

La sécurité d'un agent IA repose sur quelques contrôles très concrets. Les accès suivent le principe du moindre privilège. Les secrets ne transitent jamais en clair. Les environnements de test et de production sont séparés. Les outils appelés par l'agent sont limités à ceux qui sont vraiment nécessaires. Les journaux d'exécution sont protégés et relus. Un mécanisme de kill switch permet d'arrêter rapidement le système ou de le repasser en mode manuel. Enfin, les équipes doivent tester les abus plausibles, données mal formées, demandes contradictoires, escalade d'outils, exfiltration potentielle et contournement des règles. Cette approche rejoint les recommandations de cybersécurité publiées par des acteurs comme l'ENISA et les bonnes pratiques internes de sécurité applicative. Elle rappelle surtout une chose simple, plus un agent peut agir, plus l'entreprise doit être capable de limiter, tracer et interrompre cette action.