Jusqu’où faut-il laisser les agents IA agir seuls

Un agent d’IA peut disposer de suffisamment d’informations pour déterminer qu’un dossier client doit être modifié tout en n’ayant pas l’autorité nécessaire pour effectuer cette modification. Cette distinction devient opérationnelle à mesure que les agents d’entreprise franchissent les frontières entre applications. Le partenariat élargi entre Salesforce et Google Cloud, annoncé le 15 septembre, en est un exemple : les entreprises connectent leurs plateformes d’IA afin que les agents puissent utiliser un contexte métier partagé et agir via des applications d’entreprise, en étendant les données Salesforce, les workflows et la logique métier à des interfaces d’IA tierces. Les deux entreprises commercialisent les plateformes d’IA et cloud concernées, et bénéficient donc commercialement à mesure que les entreprises adoptent ce type d’intégration.

L’architecture qui en résulte sépare la capacité de l’autorité. ERP, CRM et d’autres applications peuvent rester des systèmes d’enregistrement, c’est-à-dire les applications désignées pour conserver les enregistrements métier faisant autorité, tandis que les agents collectent des informations et coordonnent le travail entre elles. Pour les responsables technologiques en entreprise, l’autonomie devient une question au niveau de la transaction : quelles données faisant autorité étayent une action, qui l’autorise, quels risques et quelles politiques encadrent son exécution, et comment l’organisation peut se rétablir lorsqu’un problème survient.

La capacité d’action d’un agent est distincte de son autorité

Cette question au niveau de la transaction est importante, car identifier une action appropriée n’accorde pas l’autorisation de l’exécuter. Un agent peut raisonner à partir de données CRM, d’enregistrements ERP et d’autres éléments de contexte métier, et déterminer correctement ce qui doit se passer ensuite. L’exécution doit néanmoins passer par les contrôles de l’entreprise qui régissent la transaction, notamment l’autorité des données, les autorisations, le risque, la politique et les exigences de reprise.

Ces contrôles modifient ce que les DSI et les architectes doivent décider lorsqu’ils discutent de l’autonomie des agents. Demander si un agent « a un accès en écriture » condense plusieurs décisions de gouvernance en une seule autorisation technique. Un modèle d’entreprise plus utile consiste à se demander si des informations faisant autorité étayent chaque action proposée, si l’agent et la tâche sont autorisés à l’exécuter, si le risque est acceptable, si le résultat est auditable et récupérable, et si les cas non résolus doivent être remontés.

L’autorité des données précède l’exécution

La première question de contrôle se pose avant l’exécution : quelles informations sont autorisées à gouverner la décision ? Supposons qu’un agent récupère des informations client depuis le CRM, des informations de facturation depuis l’ERP et un contexte supplémentaire depuis une plateforme de données. Lorsque ces enregistrements sont en désaccord, l’accès à l’ensemble d’entre eux apporte davantage d’éléments, mais n’établit pas quel fait contradictoire doit prévaloir pour piloter une modification.

Lian Jye Su, analyste en chef chez Omdia, une société d’Informa TechTarget, affirme que les entreprises devraient établir une matrice des systèmes d’enregistrement qui associe explicitement différents types de données à des sources faisant autorité. L’agent peut alors suivre des règles d’autorité prédéfinies lorsque les enregistrements sont en conflit, au lieu de décider lui-même quel enregistrement semble correct. La matrice transforme l’autorité des données en politique d’entreprise plutôt qu’en inférence faite lors de l’exécution d’un agent individuel.

Cette matrice peut nécessiter des distinctions plus fines, car l’autorité peut varier au sein d’un même objet métier. Kash Mehdi, vice-président et field CTO chez Reltio, explique que l’autorité peut se situer au niveau de chaque attribut. L’ERP peut gouverner le statut de facturation, le CRM les préférences commerciales, tandis qu’une autre plateforme contient l’identité client la plus fiable ; ainsi, un même dossier client peut tirer ses attributs faisant autorité de plusieurs sources. Reltio commercialise une technologie de gestion des données d’entreprise, ce qui donne à l’entreprise un intérêt commercial à ce que les organisations considèrent les données gouvernées et l’identité comme centrales dans les opérations des agents.

L’autorité au niveau des attributs impose alors aux entreprises d’établir comment les enregistrements sont rapprochés, comment les écarts sont traités et quelles informations les agents peuvent utiliser. Comme le dit Mehdi, « Un agent ne devrait pas décider de l’autorité simplement en fonction du système qu’il a interrogé en dernier ou de l’enregistrement qui semble le plus complet. » Un résultat qui paraît exhaustif au modèle ne constitue pas un fondement suffisant pour une modification en entreprise lorsque les règles de l’organisation attribuent l’autorité ailleurs.

Une fois ces règles en place, elles peuvent aussi définir où l’agent a une marge d’action. Mehdi explique que les agents peuvent résoudre les conflits de manière autonome lorsqu’une organisation les a explicitement autorisés à appliquer des politiques établies, tandis que les écarts ambigus ou à haut risque devraient être transmis à des gestionnaires de données humains. Su met de même en garde contre le fait de laisser les agents sélectionner indépendamment le système faisant autorité lorsque de mauvaises informations pourraient conduire à une décision métier lourde de conséquences.

Ces règles d’autorité restent pertinentes même lorsque le rôle des applications d’entreprise évolue. Su s’attend à ce que l’IA devienne une couche d’orchestration et de décision au-dessus des applications d’entreprise conventionnelles, tandis que l’ERP, le CRM et d’autres applications continueront à servir de systèmes d’enregistrement officiels. Un agent peut donc coordonner une décision à travers plusieurs applications tout en laissant à ces applications leur rôle de référentiels faisant autorité.

Cette séparation crée deux formes d’autorité que l’architecture d’entreprise a souvent traitées ensemble. Un système d’enregistrement établit quelles informations gouvernent une décision, tandis que les contrôles de transaction déterminent si un agent peut agir sur la base de ces informations. Comme l’autorité des données peut être plus fine que les frontières entre applications, ni l’application qui détient un enregistrement ni l’agent capable de le lire ne peuvent, à eux seuls, trancher qui est autorisé à le modifier.

L’autorité transactionnelle exige des autorisations explicites et leur mise en application

Une fois les informations faisant autorité établies, l’exécution pose une question de contrôle distincte. Mehdi résume directement cette distinction : « L’autorité de décision ne doit pas être confondue avec le système qui exécute ou stocke la transaction. » Un agent peut recommander ou initier une modification à l’aide d’informations provenant de plusieurs applications, tandis que les politiques d’entreprise, les autorisations déléguées, les contrôles de workflow et l’application cible déterminent indépendamment si la transaction peut se poursuivre.

Ces autorisations deviennent plus précises lorsqu’elles décrivent la transaction proposée au lieu d’accorder à un agent un accès large et permanent. Mehdi explique que l’autorisation doit être cadrée en fonction de l’identité de l’agent, de sa tâche, des données concernées et de l’action qu’il tente d’effectuer. Un agent peut lire les informations requises pour une mission, recommander des modifications dans certaines applications et écrire des mises à jour à faible risque dans d’autres, chaque niveau d’accès étant lié à sa tâche.

Ce périmètre au niveau de la tâche doit néanmoins tenir compte des conséquences. Su affirme que les décisions relatives à l’autorité d’écriture doivent prendre en compte le risque métier, y compris les effets possibles sur la continuité d’activité et la conformité réglementaire. Une même opération technique peut nécessiter un traitement différent lorsque ses conséquences diffèrent, en particulier lorsqu’une modification erronée est difficile à annuler.

Ces conséquences peuvent aussi apparaître entre le raisonnement et l’exécution. Un agent peut s’appuyer sur des informations obsolètes, soumettre la même transaction plus d’une fois, ou effectuer une modification qui déclenche d’autres mises à jour dans plusieurs applications connectées. L’accès au système cible dit donc peu de choses sur le fait qu’une écriture proposée reste sûre au moment où l’exécution commence.

Pour évaluer l’écriture à cet instant, Mehdi propose un point de contrôle d’application des politiques entre le raisonnement de l’agent et l’exécution. Avant d’autoriser une transaction, ce point de contrôle valide les autorisations de l’agent, vérifie que les informations sous-jacentes sont à jour et examine leur provenance, c’est-à-dire leur origine. Il teste également l’action au regard des règles métier et n’autorise la transaction que lorsque ces conditions sont réunies.

Parce que ce point de contrôle évalue une action individuelle, l’autonomie peut varier au sein d’une même application. L’entreprise peut se demander quel agent agit, quelle tâche a autorisé la demande, quelles données l’étayent, quelle opération va avoir lieu et quel niveau de risque l’accompagne. Un agent peut donc avoir l’autorité pour une écriture tout en étant empêché d’effectuer une autre opération sur la même application.

Une fois la transaction exécutée, le contrôle suivant concerne les preuves qu’elle laisse derrière elle. Mehdi explique que les actions lourdes de conséquences devraient créer un enregistrement auditable contenant l’identité de l’agent, les informations qu’il a utilisées, les règles et autorisations appliquées, ainsi que les modifications qui en ont résulté. Ces enregistrements permettent à l’entreprise de reconstituer à la fois le fondement d’une décision et l’autorité au titre de laquelle la modification a été autorisée.

Cet enregistrement soutient également la reprise, qui doit être conçue avec le même niveau de précision transactionnelle. Les entreprises ont besoin d’historiques de transactions et de mécanismes permettant d’annuler les modifications lorsque c’est possible, selon Mehdi, ainsi que de transactions compensatoires, qui neutralisent une modification antérieure lorsqu’un retour arrière simple n’est pas possible. La réversibilité influe sur le niveau de risque acceptable pour accorder une autorité d’écriture, car une erreur qui peut être proprement annulée n’a pas les mêmes conséquences opérationnelles qu’une erreur dont les effets en aval nécessitent une réparation.

Avec ces contrôles en place, l’accès en écriture devient une décision d’exécution plutôt qu’une mesure permanente de l’autonomie. La récupération établit ce qu’un agent peut savoir, tandis que l’exécution ajoute des exigences concernant l’actualité des informations, leur provenance, la protection contre les doublons, les effets en aval, l’auditabilité et la reprise. Une transaction donnée ne devient autonome que lorsqu’elle satisfait à ces exigences.

Une autonomie encadrée peut préserver le contrôle humain sur les décisions lourdes de conséquences

Les contrôles au niveau de la transaction offrent une alternative à l’obligation de faire approuver chaque action d’un agent par une personne. Les déploiements actuels restent souvent proches d’une approbation quasi universelle : Su indique que la plupart des agents d’entreprise n’ont pas encore d’autorité d’écriture indépendante, les organisations s’appuyant sur une vérification et une autorisation humaines avant d’élargir ce que les agents peuvent faire. Ces mêmes contrôles créent une voie pour déléguer certaines actions à mesure que les organisations se familiarisent avec leurs conséquences.

Su s’attend à ce que l’accès en écriture s’élargisse à mesure que les entreprises déploient davantage d’agents, en commençant par des applications moins critiques pour l’activité, où les erreurs ont des conséquences plus faciles à gérer. Cette séquence fait dépendre l’autonomie des conséquences plutôt que de traiter toutes les écritures de la même manière. Les transactions dotées d’une autorité prédéfinie et de modes de défaillance tolérables peuvent évoluer plus tôt vers une exécution autonome, tandis que les transactions lourdes de conséquences peuvent conserver des contrôles plus stricts.

La résolution des conflits montre comment cette frontière peut fonctionner au niveau des données. Mehdi autorise une résolution autonome lorsque les organisations ont explicitement autorisé les agents à appliquer des politiques prédéfinies, tandis que les écarts ambigus ou à haut risque sont remontés à des gestionnaires de données humains. Su affirme qu’un agent qui détecte des écarts dans des enregistrements faisant autorité devrait alerter l’utilisateur et le service métier responsable plutôt que d’effectuer de manière indépendante des corrections lourdes de conséquences.

Ces règles d’escalade font dépendre l’intervention humaine du degré de certitude et des conséquences. Un écart clair couvert par une règle explicite peut être résolu dans le cadre d’une autorité déléguée. Un écart ambigu, une action sensible du point de vue de la conformité ou une modification à fort impact franchit un autre seuil et est transmis à une personne responsable de la décision.

La même frontière apparaît à mesure que les entreprises introduisent l’IA agentique, c’est-à-dire des systèmes d’IA conçus pour poursuivre des tâches et entreprendre des actions avec un certain degré d’autonomie. Su explique que l’automatisation des processus d’entreprise implique encore une intervention manuelle importante des employés, ce qui fait que le modèle actuel relève davantage du human-in-the-loop, où les personnes participent directement au processus, que du human-on-the-loop, où elles supervisent principalement un fonctionnement autonome. L’augmentation des capacités des agents peut donc précéder tout transfert d’autorisation finale.

Une grande banque dépositaire fournit un exemple concret d’automatisation substantielle avec autorisation humaine. Mehdi a appris lors d’une table ronde de dirigeants que des agents de cette banque effectuent la réparation des paiements, un travail auparavant assuré par des employés des opérations. Des humains valident toujours les corrections générées par l’IA avant le règlement, de sorte que l’agent accomplit un travail opérationnel significatif tandis qu’une étape financière lourde de conséquences conserve un contrôle humain.

Le cas de la banque montre comment le travail délégué et l’autorisation conservée peuvent occuper différentes étapes d’un même processus. L’extension attendue par Su vers des applications moins critiques pour l’activité et les politiques prédéfinies de Mehdi fournissent d’autres conditions pour déléguer l’autorité. Les cas ambigus, à haut risque et lourds de conséquences continuent d’impliquer des personnes, créant une autorité graduée tout au long du travail d’un agent.

La gouvernance du DSI doit couvrir les agents, les applications, les workflows et les personnes

Cette autorité graduée modifie le problème d’architecture du DSI à mesure que les agents coordonnent l’activité entre les applications. Les dirigeants d’entreprise doivent définir où se situe l’autorité parmi les sources de données faisant autorité, les identités des agents, les politiques métier, les applications, les workflows et les employés. Une autorisation générale d’écriture ne peut pas exprimer ces frontières, car chaque transaction peut impliquer des données, des conséquences et des parties responsables différentes.

Les risques opérationnels rendent cette architecture lourde de conséquences. Une mauvaise action peut perturber la continuité d’activité ou créer des problèmes réglementaires ; elle peut aussi s’appuyer sur des informations obsolètes, dupliquer une transaction existante ou déclencher des modifications dans des applications en aval. Ces risques expliquent pourquoi les entreprises refusent souvent une autorité d’écriture indépendante, exigent une vérification et une autorisation humaines, transmettent les conflits ambigus ou à haut risque à des gestionnaires de données, et signalent les écarts aux utilisateurs et aux services responsables.

Le processus de paiement de la banque dépositaire applique la même architecture à un workflow financier : l’automatisation va jusqu’à la réparation des paiements tandis que la validation humaine reste attachée au règlement. Les workflows critiques pour l’activité, sensibles du point de vue de la conformité ou autrement lourds de conséquences peuvent conserver une vérification, une autorisation ou une escalade là où une autonomie plus large créerait une exposition inacceptable. La transaction et ses conséquences fixent la frontière.

Pour les DSI, chaque catégorie de transaction constitue donc l’unité pratique de gouvernance. L’architecture doit préciser quelles informations font autorité, quel agent et quelle tâche peuvent les utiliser, quelle opération est autorisée, quelle politique doit être respectée, quelles preuves sont enregistrées, comment l’échec est annulé ou compensé, et à quel moment une personne doit prendre le relais. Cette conception permet à un même agent d’opérer avec différents niveaux d’autonomie à mesure que son travail passe d’une application à l’autre, d’une transaction à l’autre et d’un niveau de risque à l’autre.

Points clés à retenir pour les dirigeants

• Établir l’autorité des données avant l’exécution : les DSI et les responsables des données peuvent cartographier les sources faisant autorité jusqu’au niveau de l’attribut afin que les agents sachent quelles données gouvernent chaque décision. Les conflits ambigus ou à haut risque peuvent alors être transmis à des gestionnaires humains responsables.
• Appliquer l’autorité au niveau de la transaction : les équipes d’architecture et de sécurité peuvent cadrer les autorisations des agents selon l’identité, la tâche, les données, l’action et le risque. Des points de contrôle des politiques doivent vérifier l’actualité et la provenance des données tout en préservant les pistes d’audit et les mécanismes de reprise.
• Adapter l’autonomie aux conséquences : les responsables de processus peuvent déléguer des actions à faible risque couvertes par des politiques explicites tout en conservant une approbation humaine pour les transactions lourdes de conséquences, ambiguës ou sensibles du point de vue de la conformité. Cela crée une autonomie graduée au sein d’un même workflow d’agent.
• Gouverner l’ensemble du workflow des agents : les DSI peuvent définir l’autorité entre agents, applications, workflows et personnes pour chaque catégorie de transaction. La gouvernance doit préciser les données faisant autorité, les actions autorisées, les contrôles de politique, les preuves d’audit, les procédures de reprise et les voies d’escalade.