La plupart des dirigeants que j'accompagne ont franchi un cap en 2025 : ils ne se demandent plus si un agent IA peut apporter de la valeur, ils se demandent comment le faire tourner en production sans perdre le contrôle. C'est un basculement de posture. La question ne relève plus du prototypage ; elle relève de la gouvernance. Et c'est précisément là que la plupart des projets s'arrêtent — non par manque de technologie, mais par manque de cadre.

Un pilote qui marche en salle de démonstration et un agent qui tourne face à des clients, des factures ou des candidatures ne posent pas les mêmes exigences. Le premier tolère l'approximation, la variabilité, l'itération. Le second exige la traçabilité, la reproductibilité, la responsabilité. Passer de l'un à l'autre suppose un socle explicite, écrit, arbitré au niveau du comité de direction — pas une note technique laissée à la DSI. Cet article est ce socle. Il consolide les patterns communs aux trois cas d'usage traités en parallèle dans le cocon Oppchain (support client N1, back-office financier, ressources humaines) et propose la boîte à outils minimale que je considère comme non négociable avant toute mise en production.

Trois cas d'usage, un même problème de fond

Les trois articles publiés en parallèle explorent des terrains très différents. En support client de niveau 1, l'enjeu est l'allocation optimale entre traitement automatique et escalade humaine, avec un ROI mesuré par le taux de résolution automatique et la satisfaction segmentée. En back-office comptable, le débat se joue autour de la souveraineté des données et du contrôle interne face à un rapprochement bancaire ou une préparation d'écriture. En screening et onboarding RH, le régime de conformité renforcé de l'AI Act pour les systèmes à haut risque prime sur toute considération de productivité.

Trois secteurs, trois personas, trois cadres réglementaires. Et pourtant, en atelier CODIR, les mêmes questions reviennent chaque fois. Qui autorise l'agent à agir ? Sur quel périmètre ? Avec quels droits d'écriture ? Qui supervise, à quelle fréquence, avec quels indicateurs ? Que se passe-t-il quand quelque chose déraille — un ticket mal traité, une écriture incorrecte, un CV écarté à tort ? Ces questions ne dépendent pas du cas d'usage. Elles définissent le socle de gouvernance transverse dont chaque cas particulier hérite. Ne pas les traiter en amont, c'est reporter la charge sur les équipes opérationnelles au moment le plus délicat : celui où l'agent produit ses premiers effets réels et où la marge d'ajustement est la plus faible.

La suite de cet article extrait ce socle. Il n'est pas exhaustif — chaque contexte impose ses raffinements. Il est opérable, c'est-à-dire qu'il peut être mis en place par une PME ou une ETI sans dispositif juridique disproportionné et sans figer la trajectoire technologique.

Le socle gouvernance minimal — quatre briques non négociables

Le cadre décrit ci-dessous condense ce que j'observe depuis 2018 dans les dispositifs qui tiennent dans la durée. Il ne fait pas foi de doctrine générale : il fait foi de retour d'expérience terrain, croisé avec les référentiels publics ANSSI, ENISA et NIST cités en fin d'article. Comme le rappelle Cassie Kozyrkov, « Introduction to Decision Intelligence », Google Cloud, 2019, la qualité d'une décision automatisée ne se juge pas à sa précision statistique mais à la robustesse du dispositif humain qui l'entoure — position que je partage sans réserve. Chaque brique du socle se matérialise donc par un document opposable, pas par une déclaration orale.

1. Registre des agents actifs

Un document unique, versionné, tenu par un référent nommé. Pour chaque agent en production : identifiant, périmètre fonctionnel, données accessibles en lecture et en écriture, propriétaire métier, éditeur ou fournisseur technique, date de mise en service, date de dernière revue. Ce registre est le socle de toute autre discussion. Une entreprise qui ne sait pas combien d'agents elle exploite ne peut ni les auditer, ni les arbitrer, ni les stopper si besoin. En pratique, la première itération tient sur une seule feuille tableur. La formalisation vient avec la maturité.

2. Périmètre d'autonomie explicite et signé

Pour chaque agent : ce qu'il peut faire seul, ce qu'il doit soumettre à validation humaine, ce qu'il ne fait jamais. Ce document, souvent appelé politique d'usage, est signé conjointement par le responsable métier propriétaire et par le référent gouvernance. Il est revu à cadence trimestrielle et à chaque évolution significative du modèle sous-jacent. C'est le contrat qui fonde la responsabilité en cas d'incident : sans lui, la question « qui a autorisé cela ? » reste sans réponse défendable.

3. Kill switch opérable en une action

Chaque agent en production doit disposer d'un mécanisme d'arrêt d'urgence activable par une personne clairement identifiée, sans dépendre de l'éditeur externe. Un simple feature flag côté application peut suffire tant que sa désactivation prend effet immédiatement et coupe tous les canaux de sortie de l'agent (envoi d'emails, écriture Firestore, appels API). Le mécanisme doit être testé à cadence semestrielle — un kill switch jamais actionné n'est pas un kill switch éprouvé. La procédure d'activation et le nom de l'astreinte sont documentés dans le registre.

4. Journal d'audit et rétention

Toute action de l'agent (input reçu, décision prise, sortie produite, horodatage, identifiant du modèle et de sa version) doit être journalisée. La rétention minimale conseillée est de treize mois glissants, alignée sur les cycles de contrôle interne annuel. Le journal doit être requêtable par un humain sans passer par le fournisseur — c'est le seul moyen d'auditer un incident sans dépendre du bon vouloir d'un tiers. Ce point recoupe très directement la piste d'audit comptable exigée sur le back-office (article US-503) et l'obligation de traçabilité de l'AI Act sur les systèmes à haut risque (article US-504) : le même mécanisme couvre les deux exigences.

Sécurité opérationnelle — les risques que les guides fonctionnels oublient

Un agent IA est un système applicatif ordinaire branché sur un modèle probabiliste. Il hérite des risques de sécurité applicative classiques et il en ajoute trois qui lui sont propres : la manipulation par entrée (l'injection de prompt), la fuite de données par contexte partagé et la latéralité d'accès. Ces trois risques sont documentés dans le référentiel OWASP Top 10 for LLM Applications, qui constitue aujourd'hui la meilleure grille de lecture opérationnelle pour un RSSI.

L'injection de prompt reste la première menace observée en 2026. Un utilisateur — client, candidat, collaborateur — glisse dans son message une instruction qui détourne l'agent de sa mission initiale. Le contre-mesure est double : cloisonnement strict entre instructions système et contenu utilisateur, et filtrage de sortie avant toute action sensible. Aucun modèle actuel n'est immunisé par construction ; la défense se fait en périphérie.

La fuite par contexte partagé apparaît dès qu'un agent traite les données de plusieurs utilisateurs ou tenants dans le même processus. Une fuite d'information d'un ticket client A vers un ticket client B est possible si la mémoire de conversation n'est pas correctement isolée. La règle est simple : un contexte par transaction, journalisé, purgé. Toute mutualisation doit faire l'objet d'un test de séparation explicite avant mise en production.

La latéralité d'accès est la plus insidieuse. Elle survient quand un agent, conçu pour une fonction limitée, se voit accorder des droits API trop larges — par facilité d'intégration ou par méconnaissance du principe du moindre privilège. Un agent de support qui a accès en écriture au CRM peut, en théorie, modifier des données qui ne relèvent pas de son périmètre. Le contrôle passe par une revue formelle des scopes API à chaque déploiement, alignée sur les recommandations de l'ANSSI en matière de gestion des identités techniques.

Conformité — cartographier avant de coder

Le cadre européen s'est structuré : Règlement UE 2024/1689 (AI Act) pour les systèmes d'IA, RGPD pour les données personnelles, Directive UE 2016/943 pour le secret des affaires, NIS 2 pour les entités essentielles et importantes. Ces textes ne se substituent pas les uns aux autres : ils s'empilent. Le premier réflexe utile n'est pas de choisir un fournisseur, c'est de produire une cartographie écrite du cas d'usage, des données mobilisées, des flux, et des textes applicables. Cette cartographie n'a pas besoin d'être longue : trois pages suffisent pour un premier agent. Elle est le préalable à toute décision d'achat.

Cette cartographie s'appuie utilement sur deux référentiels publics complémentaires : le NIST AI Risk Management Framework, qui propose une taxonomie des risques applicable à tous types de systèmes IA, et le cadre de bonnes pratiques cybersécurité IA de l'ENISA, qui décline les mesures par couche technique. Aucun des deux ne remplace un avis juridique local, mais l'un et l'autre structurent la conversation entre DPO, DSI et direction métier au moment du cadrage.

Depuis juillet 2025, le General-Purpose AI Code of Practice publié par la Commission européenne offre aux fournisseurs de modèles à usage général une voie volontaire de démonstration de conformité au règlement UE 2024/1689, structurée en trois chapitres — transparence, droit d'auteur, sécurité. Pour un dirigeant qui déploie un agent IA, ce document éclaire ce que l'on peut raisonnablement exiger de son fournisseur de modèle sous-jacent, et sert de grille de lecture des engagements contractuels à obtenir en amont de la mise en service.

Le point que je répète systématiquement en atelier : la conformité n'est pas un contrôle de sortie, c'est un contrôle d'entrée. Un déploiement conforme est un déploiement qui a été pensé conforme dès la première ligne du cahier des charges. Une remise en conformité effectuée après coup coûte, en règle générale, entre deux et cinq fois le budget initial du projet — et cela sans compter le coût organisationnel de la remédiation.

Ce que le pilote ne montre pas

La responsabilité du dirigeant ne se réduit pas à valider un business case. Elle inclut la question de savoir ce que devient l'entreprise le jour où l'agent est retiré, remplacé, ou tombe en panne pendant huit heures. Un déploiement bien mené prévoit un mode dégradé humain testé au moins une fois par trimestre. Sans cela, l'organisation développe une dépendance silencieuse dont elle mesure le coût au premier incident majeur — souvent trop tard pour l'absorber sans perturbation externe visible.

Le pilote montre le gain. Il ne montre ni la dépendance qui s'installe, ni la charge cognitive nouvelle qui pèse sur les équipes de supervision, ni la trajectoire budgétaire des trois années suivantes. C'est au comité de direction, et non à la DSI seule, de tenir cette perspective.

Le cocon complet — par où commencer

Cet article ferme un cocon de quatre publications parallèles chez Oppchain. Pour situer le sujet dans le cadre stratégique large — opportunités, ROI, feuille de route et conduite du changement —, notre article pilote IA agentique en entreprise : opportunités, ROI et feuille de route pour les dirigeants pose les repères transverses. Pour l'entrée sectorielle, revenez aux trois cas d'usage détaillés : agent IA en support client N1, agent IA finance et back-office comptable, agent IA en RH — screening et onboarding sans biais.

Pour ancrer la gouvernance des agents dans une pratique de dirigeant — pas seulement de RSSI ou de DPO —, la formation Oppchain IA et gestion des risques pour les décideurs outille les comités de direction sur l'arbitrage des projets IA et la construction de leur socle de contrôle. Pour les dirigeants qui souhaitent piloter la transformation IA au-delà de la première itération, Leadership IA — piloter la transformation traite la conduite du changement et la construction d'une culture de supervision durable.

Sources publiques recommandées

À propos de l'auteur

Frédéric Michel dirige Oppchain, cabinet spécialisé en agents IA et organisme de formation Qualiopi. Il conçoit et audite depuis 2018 des dispositifs de gouvernance IA agentique pour PME, ETI et directions métiers. Ce texte ferme un cocon de trois cas d'usage (SAV, finance, RH) publiés en parallèle ; il en extrait le socle commun et les choix d'architecture qu'il recommande à ses clients.