La gouvernance de l’IA change lorsque l’IA peut agir
Un agent IA qui rédige un message client produit un contenu à examiner. Un agent qui envoie ce message, modifie une campagne, déclenche un workflow ou accède à un système d’entreprise soulève une question d’autorité. Les dirigeants doivent savoir ce que l’agent est autorisé à faire, aux systèmes et aux données auxquels il peut accéder, à quel moment une personne doit intervenir et qui est responsable du résultat. Ces questions deviennent partie intégrante du processus métier lorsque le logiciel peut agir avec une intervention humaine limitée.
L’exactitude, les contrôles contre les hallucinations et la revue des résultats restent importants, car ils déterminent si un système d’IA produit un contenu fiable. L’autonomie crée un risque distinct : une erreur de jugement peut directement déclencher une action qui atteint un client ou modifie un workflow avant toute revue humaine. Pour les directeurs marketing, les CDO (Chief Digital Officers) et les responsables de l’expérience client, la gouvernance devient un élément du design opérationnel. Le périmètre de la prise de décision déléguée doit être clair avant que les workflows autonomes ne changent d’échelle.
L’écart de préparation est déjà visible
Une étude de la plateforme de gouvernance de l’IA Optro suggère un écart entre la confiance affichée et les garde-fous dédiés. Optro indique que 58 % des dirigeants estiment que leurs contrôles de gouvernance évoluent au même rythme que l’adoption de l’IA, tandis que seuls 18 % déclarent avoir mis en place des garde-fous dédiés aux risques liés à l’IA. Les deux chiffres diffèrent de 40 points de pourcentage. Comme Optro vend une technologie de gouvernance de l’IA, l’entreprise a un intérêt commercial à mettre en avant le besoin d’une gouvernance plus forte.
Optro indique également qu’une organisation sur trois utilise déjà l’IA dans des workflows critiques de résilience, tandis que 30 % n’ont jamais testé les défaillances potentielles de l’IA agentique. Cela soulève une question pratique : celle de savoir si les contrôles ont été testés là où l’IA intervient dans des activités critiques. Optro signale aussi des problèmes plus larges liés à l’IA, même si ces constats n’établissent pas que des agents autonomes ont causé ces événements ou dépassé l’autorité qui leur était accordée.
| Problème signalé | Organisations l’ayant signalé |
|---|---|
| Résultats d’IA trompeurs au cours de l’année écoulée | 40% |
| Violations de données liées à l’IA | 27% |
| Examen réglementaire lié à leur usage de l’IA | 26% |
Cette distinction change la réponse en matière de contrôle. Les résultats trompeurs appellent des contrôles d’exactitude et une revue. Les violations de données appellent des contrôles de sécurité de l’information, tandis que l’examen réglementaire appelle une supervision juridique et de conformité. Les contrôles fondés sur l’autorité répondent à une capacité différente : un logiciel capable d’exécuter des actions après être parvenu à une conclusion.
Un projet en tête ?
Planifiez un appel de 30 minutes avec nous.
Des experts senior pour vous aider à avancer plus vite : produit, tech, cloud & IA.
La gouvernance doit définir l’autorité déléguée
Les processus d’approbation traditionnels confient les décisions importantes à des personnes. L’IA agentique modifie cette chaîne lorsqu’un système peut passer de la recommandation d’une action au déclenchement d’un workflow ou à l’interaction avec un client avec une intervention humaine limitée. La revue du contenu généré ne couvre alors qu’une partie du processus. Les dirigeants doivent aussi définir quelles actions le système est autorisé à exécuter.
Guru Sethupathy, GM of AI Governance chez Optro, explique que les systèmes autonomes nécessitent un modèle de gouvernance différent. « La réalité aujourd’hui, c’est que l’adoption de l’IA agentique dépasse de loin la gouvernance. Pour exploiter son potentiel de manière responsable, les dirigeants doivent reconnaître que les modèles de gouvernance conçus pour des processus manuels statiques ne peuvent pas suivre le rythme de systèmes d’action autonomes. » Optro tire un bénéfice commercial lorsque les organisations investissent dans la gouvernance de l’IA, de sorte que la déclaration de Sethupathy reflète la position d’un fournisseur plutôt qu’une preuve indépendante de l’ampleur des défaillances de gouvernance.
L’expression de Sethupathy, « systèmes d’action », résume bien le changement. Lorsque l’IA génère une recommandation de campagne qu’un marketeur doit évaluer, c’est le marketeur qui décide d’agir ou non. Lorsqu’un agent peut exécuter une activité de campagne ou communiquer avec des clients, le logiciel reçoit une part d’autorité décisionnelle. La gouvernance doit préciser le périmètre et les conditions de cette délégation.
Mark Taylor, Director of Information Security Risk Management chez Newell Brands, présente le sujet sous l’angle du comportement et de l’accès. « Les équipes qui réussiront la conformité agentique construiront des frameworks de gouvernance et de responsabilité sur la manière dont un agent se comporte et sur ce à quoi il peut accéder. Mettre cette structure en place de manière proactive permet aux organisations de faire évoluer l’IA en toute sécurité, de prévenir de futurs incidents et d’opérer avec des humains in the loop ou on the loop lorsque cela est approprié. » Son insistance sur ce qu’un agent peut « toucher » donne aux dirigeants une manière concrète d’examiner les autorisations.
Quatre dimensions rendent cette autorité explicite. L’autorité autorisée couvre les décisions et les actions qu’un agent peut exécuter sans approbation supplémentaire. Son périmètre d’accès et d’action couvre les données, les systèmes, les canaux, les workflows et les changements accessibles via les autorisations prévues. Ensemble, ces choix définissent quelles actions métier l’organisation expose délibérément à une exécution autonome.
L’intervention humaine constitue la troisième dimension. Un humain « in the loop » participe au processus de décision. Un humain « on the loop » supervise un système capable d’opérer et intervient dans des circonstances définies. Les dirigeants doivent choisir entre ces modèles en fonction des conséquences d’une action et du niveau de discrétion délégué à l’agent, puis définir ce qui déclenche une escalade.
La responsabilité constitue la quatrième dimension. Lorsque le logiciel sélectionne ou exécute une action, l’organisation a toujours besoin d’un responsable des conséquences métier. Ce responsable doit avoir l’autorité nécessaire pour modifier le workflow, restreindre les autorisations ou arrêter l’exploitation lorsque les contrôles se révèlent insuffisants. Pour un agent en contact avec les clients, cela signifie préciser quels clients il peut contacter, quelles informations il peut utiliser, quelles communications il peut envoyer de manière autonome et dans quelles conditions une escalade est obligatoire.
Une autonomie encadrée rend le compromis explicite
Exiger une approbation humaine pour chaque action importante limite fortement l’autorité déléguée. L’autonomie encadrée propose un design différent : un agent opère de manière indépendante dans le cadre d’autorisations définies et déclenche une escalade lorsque des conditions prédéfinies surviennent. Un agent marketing, par exemple, pourrait accéder à des données approuvées et à des canaux clients spécifiés tout en restant limité à des actions définies. Les actions à plus haut risque pourraient exiger une intervention humaine en fonction de leurs conséquences.
Ce design oblige les dirigeants à décider quelles activités ils sont prêts à déléguer. Ils doivent définir les autorisations de l’agent, les conditions d’escalade et le responsable humain des décisions en dehors de ces limites. Ils doivent aussi choisir à quels endroits une personne participe directement à une décision et où une supervision suffit. Ces choix établissent le degré réel d’autonomie du système.
Le compromis est concret. Des autorisations plus larges exposent davantage d’actions à une exécution autonome, tandis que des autorisations plus strictes envoient davantage de situations en escalade ou empêchent l’agent d’agir. La gouvernance rend ce choix explicite avant le déploiement. Les responsables métier peuvent alors vérifier si les autorisations prévues et la marge de manœuvre accordée correspondent à ce qu’ils ont approuvé.
La gouvernance des agents est un problème de modèle opérationnel
Un workflow agentique peut franchir des frontières que les organisations attribuent souvent à des fonctions distinctes. Un workflow client peut combiner des objectifs marketing, l’expérience client, des systèmes IT, des contrôles de sécurité, des obligations juridiques et des décisions de risque dans une seule chaîne d’actions. Chaque fonction a une question distincte à trancher sur l’autorité déléguée. La gouvernance doit relier ces décisions en règles applicables au comportement de l’agent.
Les responsables marketing et expérience client peuvent définir le résultat client visé et les actions qu’ils sont prêts à déléguer. L’IT et la sécurité peuvent définir les systèmes, identités et accès aux données autorisés. Les équipes juridiques et risque peuvent fixer des contraintes lorsque des obligations ou des conséquences exigent une escalade. Cette répartition du travail transforme une demande générale de « gouvernance de l’IA » en droits de décision précis.
La participation transverse exige néanmoins une responsabilité claire. Un comité qui examine un workflow ne détermine pas à lui seul qui peut approuver le déploiement, modifier les autorisations, fixer les seuils d’intervention ou arrêter l’exploitation. Ces droits de décision doivent être attribués à des responsables nommés. Sinon, plusieurs fonctions peuvent participer tandis que la responsabilité de la conduite de l’agent reste floue.
La gouvernance des agents va donc au-delà des processus de conformité et des systèmes techniques d’autorisation. Les contrôles de sécurité peuvent faire respecter des accès définis, tandis que les processus de conformité peuvent évaluer des obligations définies. Les dirigeants doivent malgré tout décider de l’ampleur de l’autorité métier que l’organisation déléguera au logiciel et dans quelles conditions. Cette décision opérationnelle détermine ce que les contrôles techniques et de conformité doivent faire respecter.
Points clés à retenir pour les dirigeants
- Gouverner les actions : À mesure que les agents IA passent de la génération de contenu à l’exécution d’actions, les dirigeants ont besoin de contrôles sur ce que les agents peuvent faire, sur les systèmes auxquels ils peuvent accéder et sur le moment où des personnes doivent intervenir.
- Tester la gouvernance face au risque réel de l’IA : Les écarts signalés entre l’adoption de l’IA et les garde-fous dédiés suggèrent que les dirigeants devraient vérifier que les contrôles fonctionnent dans les workflows critiques plutôt que de se fier uniquement à leur confiance dans la gouvernance.
- Définir l’autorité déléguée avant le déploiement : Fixez des limites explicites pour les autorisations de l’agent, l’accès, l’intervention humaine, l’escalade et la responsabilité. Chaque workflow autonome devrait aussi avoir un responsable désigné capable de le restreindre ou de l’arrêter.
- Utiliser une autonomie encadrée pour gérer le risque : Donnez aux agents de l’indépendance uniquement dans le cadre d’autorisations définies et imposez une escalade pour les actions à plus haut risque. Une autonomie plus large doit refléter une décision métier explicite sur les conséquences acceptables.
- Traiter la gouvernance des agents comme une décision de modèle opérationnel : Les équipes marketing, CX, IT, sécurité, juridique et risque peuvent toutes contribuer aux contrôles des agents, mais les droits de décision doivent rester clairs. En dernier ressort, ce sont les dirigeants qui déterminent l’ampleur de l’autorité métier accordée au logiciel.
Un projet en tête ?
Planifiez un appel de 30 minutes avec nous.
Des experts senior pour vous aider à avancer plus vite : produit, tech, cloud & IA.


