Agents d’IA : guide de l’architecture et de la gouvernance de l’IA agentique

L’IA d’entreprise a dépassé l’ère du prompt isolé. Il y a un an à peine, de nombreuses initiatives d’IA se concentraient sur l’accès des employés aux chatbots : charger un fichier, demander un résumé, poser une question. Aujourd’hui, les entreprises veulent des systèmes d’IA agentique capables de fonctionner avec les données, les outils, les bases de code et les processus métiers avec suffisamment de contexte et de contrôle pour accomplir des tâches à plusieurs étapes.

Cependant, un agent d’IA ne peut pas être traité comme un simple chatbot doté de plus de permissions. Il a besoin d’accéder au contexte, mais pas d’un accès illimité à tous les systèmes. Il a besoin d’accéder à des outils, mais pas de la liberté d’utiliser n’importe quel outil n’importe comment. Il a besoin de suffisamment d’autonomie pour accomplir une tâche, mais avec assez de contrôle pour que l’entreprise puisse voir ce qu’il a fait, quelles données il a utilisées et pourquoi il a effectué une action donnée.

D’ici 2028, Gartner prévoit que 33 % des applications logicielles d’entreprise incluront une IA agentique, un bond spectaculaire par rapport à moins de 1 % en 2024.¹ À mesure que les agents s’intègrent à la couche logicielle de l’entreprise, le défi pratique consiste à les connecter aux données, aux outils et aux processus via une couche de gouvernance capable de fonctionner avec différents fournisseurs, de préserver les permissions et de maintenir l’auditabilité des actions.

Un agent d’IA est un système logiciel qui utilise l’IA pour poursuivre un objectif, prendre des décisions et agir via des applications ou d’autres systèmes. Il exécute une tâche en interprétant d’abord la demande et en rassemblant le contexte, puis en décidant de la marche à suivre, en appelant le ou les bons outils, en vérifiant les résultats et en continuant jusqu’à ce qu’il atteigne un résultat ou transmette la tâche à une personne ou à un autre système.

La plupart des agents d’entreprise actuels utilisent de grands modèles de langage (LLM) comme couche de raisonnement. Mais un agent d’IA est bien plus que son modèle. Il inclut la logique d’orchestration autour du modèle : les instructions qui façonnent son comportement, la boucle de planification qui détermine la prochaine étape, la mémoire ou l’état de la tâche auquel il peut se référer, et les connecteurs qui lui permettent d’appeler des outils et des sources de données approuvés.

IA agentique vs IA générative vs ML

Si le machine learning (ML) traditionnel peut s’intégrer dans des processus automatisés et que l’IA générative peut être connectée à des outils, aucun des deux n’est agentique en soi. Ce qui rend un système d’IA agentique, c’est la boucle orientée vers un objectif autour du modèle : le contexte, la connectivité, l’utilisation d’outils, l’état et suffisamment d’autonomie pour accomplir une tâche à plusieurs étapes.

• Le ML traditionnel prédit ou classifie : Les systèmes de machine learning sont généralement entraînés pour reconnaître des schémas dans les données et renvoyer une prédiction, une classification, un score ou une recommandation. Le résultat du modèle peut guider un processus, mais le processus lui-même est défini en dehors du modèle.
• L’IA générative crée de nouveaux contenus : Les modèles d’IA générative produisent du texte, des images, du code, de l’audio ou d’autres résultats à partir d’un prompt ou d’une entrée. Un utilisateur pose une question, demande un résumé ou fournit des instructions, et le modèle génère une réponse. L’interaction peut être conversationnelle, mais le système se limite généralement à produire un résultat pour l’utilisateur.
• L’IA agentique agit dans un but précis : L’IA agentique utilise des modèles au sein d’un système plus vaste capable de récupérer du contexte, de choisir les prochaines étapes, d’appeler des outils, d’observer les résultats et de continuer jusqu’à ce qu’il atteigne un résultat ou transfère la tâche. Le modèle peut fournir un raisonnement ou une génération, mais le système agentique lui donne accès au contexte, à un moyen d’agir et à un processus pour décider de la marche à suivre.

Agents d’IA et agents de données

Un agent de données est un agent d’IA spécialisé, axé sur le travail lié aux données. Il connecte le langage naturel, le contexte métier et les systèmes de données afin que les utilisateurs puissent poser des questions, générer des requêtes, inspecter les métadonnées, vérifier la qualité, résumer des ensembles de données ou enquêter sur des anomalies sans passer manuellement d’un outil à l’autre.

Un agent de données a besoin d’un accès gouverné aux données. Il doit comprendre les définitions des indicateurs, la fraîcheur des tables, la traçabilité des données au niveau des colonnes, la propriété, les politiques d’accès et les chemins de requête approuvés. Si un utilisateur demande le taux d’attrition client par région, par exemple, l’agent doit savoir quelle définition de l’attrition est approuvée, quelle table client est à jour, si l’utilisateur peut voir les détails au niveau des lignes et si la réponse doit être agrégée.

« L’ajout de contexte est le nerf de la guerre en ce moment », explique William Allen, Head of Product for CoWork & Agents chez Snowflake. « La question est de savoir comment donner du contexte à l’agent à chaque étape, sans le submerger et sans l’entraîner sur des chemins aléatoires. »

Les agents de données doivent également travailler avec différents types de données. Une analyse des revenus peut impliquer une table SQL, un contrat au format PDF, une transcription du support et une définition de tableau de bord. Un agent de données d’IA rassemble ces objets via une interface gouvernée, afin que le modèle puisse raisonner sur la question métier sans contourner les contrôles d’accès.

C’est pourquoi l’adoption d’agents d’IA d’entreprise implique des décisions concernant l’architecture de données : la réponse de l’agent dépend de la qualité, de la fraîcheur, de la sémantique et des autorisations des données sous-jacentes.

La valeur d’un agent d’IA par rapport à un modèle autonome vient de sa capacité à planifier des étapes, à conserver ou à récupérer du contexte, et à utiliser des outils pour agir sur des informations au-delà du modèle lui-même.

• Réduire l’orchestration manuelle : Un utilisateur n’a pas besoin de récupérer le contexte, de le coller dans un prompt, de demander un résumé, de copier la réponse dans un autre système, de relancer le prompt lorsqu’il manque quelque chose et de vérifier manuellement chaque étape. L’agent gère une plus grande partie de la boucle de récupération, de raisonnement, d’action et de vérification au sein du processus.
• Raccourcir le chemin entre la question et la réponse basée sur les données : Une personne demandant pourquoi les coûts du pipeline ont augmenté ne devrait pas avoir à savoir quelle table stocke l’historique d’utilisation, quelle vue contient la logique de répartition des coûts approuvée ou quel propriétaire de tableau de bord a modifié le calcul. Un agent de données gouvernées peut traduire la question en tâches de données, récupérer le bon contexte et présenter la réponse en langage métier.
• Rendre les points de décision répétitifs plus homogènes : Le tri des tickets, les contrôles de qualité des données, l’examen des journaux et les résumés des risques liés aux comptes dépendent tous de l’application du même processus de raisonnement sur de grands volumes de travail. Les réviseurs humains restent importants, en particulier pour les exceptions, mais l’agent gère les parties reproductibles avec un cheminement constant.
• Activer l’automatisation adaptative : Un processus basé sur des règles s’arrête lorsque l’entrée change de manière inattendue. Un agent peut inspecter la nouvelle condition, réviser le plan et choisir un autre chemin approuvé. Cette adaptabilité est la raison pour laquelle les agents sont utiles, et la raison pour laquelle la gouvernance doit se situer au plus près de la couche d’exécution.

Les meilleurs cas d’usage initiaux pour les agents d’IA ne sont pas nécessairement les plus tape-à-l’œil. Il s’agit généralement de workflows où le travail est répétitif, riche en contexte et réparti sur plusieurs systèmes.

Service client

Dans le service et le support client, les agents trient les tickets, récupèrent le contexte du compte, classent les problèmes, rédigent des réponses et acheminent les exceptions vers un réviseur humain. L’agent ne remplace pas le chemin d’escalade ; il le rend plus sélectif en gérant la collecte de contexte répétitive et le travail de résolution de premier niveau.

Développement de logiciels

Dans le développement de logiciels, les agents de codage planifient, écrivent, testent et révisent sur l’ensemble d’une base de code. La différence avec la saisie semi-automatique réside dans le périmètre. Un agent de codage a besoin du contexte du référentiel, du contexte du problème, des informations sur les dépendances, des résultats des tests et des instructions spécifiques au projet. Il a également besoin de garde-fous concernant le code qu’il peut modifier, les commandes qu’il peut exécuter et ce qui nécessite une approbation humaine.

Opérations sur les données

Dans les opérations sur les données, les agents surveillent les pipelines, inspectent les problèmes de qualité des données, assurent la traçabilité des données et identifient les ressources en aval affectées. Un échec de contrôle de fraîcheur devient plus utile lorsque l'agent peut indiquer quelle table source a changé, quelle transformation en dépend, quel tableau de bord est affecté et qui est le propriétaire du processus.

Opérations commerciales

Dans les opérations commerciales et de revenus, les agents synthétisent les données de gestion de la relation client (CRM), les transcriptions d’appels, l’historique des comptes et l’utilisation des produits pour signaler les comptes à risque ou rédiger des messages de prospection. Le résultat utile n’est pas un résumé de compte générique. C’est une recommandation ancrée dans le contexte client actuel, avec des signaux sources visibles.

Opérations informatiques et de sécurité

Dans les opérations informatiques et de sécurité, les agents examinent les journaux, corrèlent les alertes, récupèrent le contexte des actifs et aident au tri des incidents. Ces workflows nécessitent une gouvernance stricte, car l’agent peut toucher à des systèmes sensibles, à la télémétrie de sécurité et à des actions à fort impact. Les premiers déploiements les plus sûrs maintiennent souvent les humains dans la boucle d’approbation tout en utilisant des agents pour réduire le temps de collecte du contexte.

Regardez Andrew Ng, chercheur de premier plan en IA, explorer l’essor des agents d’IA et du raisonnement agentique :

La plupart des agents d’IA suivent une boucle : percevoir, raisonner, planifier, coordonner, agir et s’améliorer. Les étiquettes varient selon les cadres, mais la séquence capture le même modèle de fonctionnement.

Percevoir

L’agent perçoit d’abord l’environnement. Cela peut signifier lire un prompt utilisateur, récupérer un document, inspecter une table, recevoir un événement d’un système de processus ou observer le résultat de l’appel d’un outil. L’entrée est rarement une simple phrase ; dans les processus d’entreprise, elle inclut souvent des métadonnées, des autorisations, le contexte source, des règles métier et l’état de la tâche précédente.

Raisonner

L’agent raisonne ensuite sur l’objectif et le contexte disponible. Il décide quelles informations sont importantes, ce qui manque et quelles contraintes s’appliquent. Pour un agent de données, cela peut inclure la signification d’un indicateur, la fraîcheur d’une table, les privilèges d’accès de l’utilisateur et si la réponse demandée nécessite de joindre des données sensibles.

Planifier

La planification transforme ce raisonnement en un cheminement. L’agent décide des étapes à suivre, des outils à appeler et de l’ordre à respecter. Dans un processus fixe, le cheminement peut être prédéfini. Dans un processus plus autonome, l’agent choisit l’étape suivante en fonction de ce qu’il a déjà observé.

Coordonner

La coordination devient importante lorsque plusieurs outils, agents ou étapes d’approbation sont impliqués. Un agent peut récupérer des documents pertinents tandis qu’un autre vérifie les contraintes de politique. Un agent superviseur peut déléguer des sous-tâches, comparer les résultats et décider si un réviseur humain doit approuver l’action suivante.

Agir

L’agent agit ensuite. Il appelle une fonction, exécute une requête, met à jour un ticket, envoie un message, rédige du code, déclenche un processus ou renvoie une réponse. Dans les environnements gouvernés, l’action doit être journalisée avec suffisamment de détails pour reconstituer ce qui s’est passé : la demande, les données consultées, l’outil utilisé, le résultat renvoyé et le cheminement décisionnel qui y a conduit.

S’améliorer

Enfin, l’agent apprend au sens opérationnel : il intègre les retours, met à jour l’état de la tâche, stocke la mémoire approuvée ou ajuste les étapes futures. Cet apprentissage ne signifie pas nécessairement le réentraînement du modèle de fondation. Plus souvent, cela signifie améliorer le système autour du modèle par des mises à jour de la mémoire, des résultats d’évaluation, des modifications de prompt, le réglage des politiques ou un meilleur routage des outils.

Les agents d’IA peuvent être conçus pour raisonner et agir de différentes manières. Certains processus demandent au modèle de réfléchir à un problème avant de répondre. D’autres laissent l’agent interagir avec des outils, observer les résultats et réviser son étape suivante. Le bon modèle dépend de la prévisibilité de la tâche, de la quantité de retours fournis par l’environnement et du niveau de contrôle dont l’organisation a besoin sur le processus.

• Raisonnement pas-à-pas : La conception initiale des agents a emprunté aux techniques de prompting développées pour les LLM. L’une des idées précurseures était le raisonnement pas-à-pas, où le modèle est invité à décomposer un problème en étapes intermédiaires avant de produire une réponse. Dans cette configuration, le raisonnement a lieu avant la réponse ou l’action finale. Le modèle ne révise pas son cheminement en fonction des retours externes, à moins que le processus ne lui accorde un autre tour.
• ReAct : ReAct (abréviation de raisonnement et action) modifie la séquence. Au lieu de raisonner une seule fois au préalable, l’agent alterne entre le raisonnement, l’action et l’observation. Il peut décider d’exécuter une requête sur une table, d’inspecter le résultat, de se rendre compte que la définition de la métrique est ambiguë, de récupérer des métadonnées, puis de réviser sa prochaine étape. L’écart par rapport à la chaîne de pensée ne se résume pas à « plus de raisonnement », mais à un raisonnement qui évolue après l’interaction de l’agent avec un outil ou un environnement.
• Réflexion : La réflexion ajoute une vérification supplémentaire. L’agent examine sa propre réponse, son plan ou le résultat de l’outil avant de finaliser la sortie ou de poursuivre le processus. Un agent de codage peut générer un test, l’exécuter, inspecter l’échec et critiquer le code qu’il a écrit. Un agent de données peut produire une requête SQL, comparer le résultat avec la demande de l’utilisateur et identifier que la requête a filtré sur la date de réservation alors que la définition de la métrique exige la date de transaction.
• Basés sur la planification et réactifs : Les agents basés sur la planification et les agents réactifs tracent une autre ligne de démarcation. Un agent basé sur la planification élabore un plan en plusieurs étapes avant d’agir, souvent avec des points de contrôle et des dépendances. Un agent réactif choisit une étape à la fois à mesure que les conditions changent. Le module de planification défini dans l’architecture détermine la part de structure existante avant que l’agent ne commence et la liberté dont il dispose pour réviser son cheminement.
• Chaînage de prompts : Le chaînage de prompts décompose une tâche en une séquence de prompts plus petits. Un prompt extrait des entités, le suivant récupère le contexte, le suivant résume les résultats et le dernier formate la réponse finale. Le chaînage est généralement plus fixe et séquentiel que ReAct. Il est utile lorsque le processus est connu à l’avance et que chaque étape alimente la suivante.

La plupart des agents en production utilisent une combinaison de ces paradigmes. Un processus peut commencer par un plan, utiliser ReAct pour rassembler les informations manquantes, appliquer une réflexion avant une sortie à haut risque et s’appuyer sur l’invocation structurée d’outils pour appeler des fonctions approuvées, des API, des nœuds de workflow ou des systèmes connectés au Model Context Protocol (MCP). La question de conception n’est pas de savoir quel paradigme est le meilleur, mais de déterminer le niveau de flexibilité, de retour d’information et de contrôle requis par la tâche.

Les agents d’IA sont souvent décrits selon cinq types canoniques : les agents réflexes simples, les agents réflexes fondés sur des modèles, les agents fondés sur des buts, les agents fondés sur l’utilité et les agents apprenants. Ces catégories proviennent de recherches antérieures sur l’IA, mais elles aident toujours à expliquer les choix de conception qui sous-tendent les systèmes d’agents modernes.

• Un agent réflexe simple répond à l'état actuel en utilisant des règles prédéfinies. Si la condition est vraie, il exécute l’action correspondante. Cette conception fonctionne pour des tâches spécifiques aux conditions stables, mais elle ne maintient pas de modèle du monde ni ne raisonne sur les conséquences futures.
• Un agent réflexe fondé sur des modèles conserve une représentation interne de l’environnement. Au lieu de réagir uniquement à l’entrée actuelle, il utilise l’état stocké pour déterminer ce qui se passe. Par exemple, un agent d’opérations peut suivre le dernier statut connu d’un pipeline, la modification de schéma la plus récente et le propriétaire associé à la table concernée avant de décider quelle alerte déclencher.
• Un agent fondé sur des buts évalue les actions par rapport à un résultat souhaité. Il ne se contente pas de faire correspondre des conditions, mais choisit également les étapes qui rapprochent le système d’un objectif. Un agent de support client tentant de résoudre un litige de facturation peut recueillir l’historique du compte, comparer les règles de politique, rédiger une réponse et ne faire remonter le problème que lorsque la tâche dépasse son autorité.
• Un agent fondé sur l’utilité évalue différents résultats. Il peut comparer la vitesse, le coût, le niveau de confiance, le risque et la valeur stratégique avant de sélectionner une action. Dans un contexte d’entreprise, l’utilité est importante lorsque la réponse la plus rapide n’est pas nécessairement la plus sûre, ou lorsqu’un cheminement de raisonnement plus coûteux n’est justifié que pour des décisions à haut risque.
• Un agent apprenant s’améliore grâce aux retours d’information. Ces retours peuvent provenir d’utilisateurs, d’évaluateurs, de systèmes de supervision ou des résultats de tâches antérieures. En production, l’amélioration se fait souvent par la mise à jour des prompts, de la mémoire, de la logique de routage, des règles de politique et des ensembles d’évaluation, plutôt que par un réentraînement continu du modèle sous-jacent.

Deux types d’agents avancés sont particulièrement pertinents pour les processus d’entreprise :

• Les agents hiérarchiques répartissent le travail à différents niveaux, un agent superviseur déléguant des sous-tâches à des agents spécialistes.
• Les systèmes multi-agents coordonnent plusieurs agents qui peuvent travailler de manière séquentielle, en parallèle ou sous la direction d’un orchestrateur partagé.

En pratique, de nombreux déploiements en entreprise classent également les agents selon leur autonomie : les agents entièrement autonomes effectuent des tâches avec une intervention humaine limitée, tandis que les agents semi-autonomes demandent une approbation avant les actions à haut risque. Les agents spécifiques à un domaine réduisent encore la surface des tâches, comme un agent de données, un agent de codage, un agent de sécurité ou un agent d’opérations commerciales.

Outre un modèle de fondation, un agent d’IA a également besoin d’une couche d’orchestration, d’un module de planification, d’une architecture de mémoire, d’intégrations d’outils et d’un plan de contrôle qui régit l’exécution.

Modèle de fondation

Le modèle de fondation offre une interprétation, un raisonnement et une génération flexibles. De nombreux systèmes actuels utilisent des LLM, bien que les agents ne doivent pas nécessairement se limiter aux modèles de langage. Le modèle fournit un raisonnement flexible, tandis que l’architecture environnante détermine ce que l’agent est autorisé à savoir, quels outils il peut utiliser et ce qui se passe lorsque la tâche change.

Le choix du modèle doit rester flexible. À mesure que les entreprises créent des agents pour différents processus, le fait de verrouiller chaque cas d’usage sur un seul modèle de fondation peut limiter la performance, le contrôle des coûts et l’adaptabilité. « Si vous vous retrouvez lié à un seul prestataire, vous pourriez avoir des problèmes quelques mois plus tard », déclare Allen. « Un autre prestataire pourrait surgir de nulle part avec une nouvelle innovation incroyable et vous passeriez à côté. Nous pensons que l’optionnalité du routage des modèles est fondamentale. »

Couche d’orchestration

La couche d’orchestration gère la boucle de l’agent. Elle transmet le contexte au modèle, achemine les appels d'outils, stocke l'état intermédiaire, gère les nouvelles tentatives et détermine si le processus doit continuer, s'arrêter, être remonté ou transmis à un autre agent.

Module de planification

Le module de planification décompose un objectif en étapes plus petites. Pour une requête telle que « trouver pourquoi les revenus sont en baisse dans la région Nord-Est », l’agent peut prévoir d’identifier la définition de la métrique pertinente, d’exécuter une requête sur les revenus récents par segment, de les comparer aux périodes précédentes, d’inspecter la fraîcheur du pipeline et de vérifier si une table source a été modifiée. Dans un agent plus simple, la planification peut se faire une étape à la fois. Dans un agent plus complexe, celui-ci élabore un plan à plusieurs étapes à l’avance et le révise au fur et à mesure que les résultats des outils lui parviennent.

Architecture de mémoire

La mémoire donne à l’agent une continuité. La mémoire à court terme conserve l’état immédiat de la tâche : la requête de l’utilisateur, les sorties des outils, les contraintes, les documents récupérés et les échanges précédents de la conversation. La mémoire à long terme stocke des connaissances réutilisables, telles que les préférences de l’utilisateur, les décisions précédentes, les définitions spécifiques à l’organisation ou les problèmes résolus. L’architecture de mémoire détermine ce qui est stocké, comment cela est récupéré, combien de temps cela persiste et quelles parties de la mémoire sont disponibles pour quel agent.

Intégration d’outils

L’intégration d’outils connecte l’agent aux systèmes où le travail s’effectue. Ces outils peuvent inclure des bases de données, des index de recherche, des référentiels de code, des systèmes de gestion de tickets, des applications CRM, des moteurs de processus, des magasins de documents ou des API internes. L'appel de fonction donne au modèle un moyen structuré d'invoquer ces outils, tandis que des normes telles que MCP émergent pour normaliser la façon dont les agents découvrent et utilisent les capacités externes.

Plan de contrôle

Le plan de contrôle est la couche de plateforme gouvernée qui connecte les données, les modèles, les outils et les processus d’entreprise, tout en appliquant les autorisations, en acheminant les actions, en consignant l’activité et en gérant le fonctionnement des agents à travers les systèmes. Il définit également des limites de coût et de latence, et gère les approbations humaines. Même lorsqu’un agent opère sur des données gouvernées au sein d’une plateforme telle que Snowflake, le contenu récupéré, les prompts des utilisateurs et les sorties des outils doivent toujours être traités comme des entrées d’un processus agentique, et non comme des instructions que le modèle peut suivre aveuglément.

Pour les agents d’IA d’entreprise, cette couche n’est pas une infrastructure optionnelle. C’est ce qui transforme un processus piloté par un modèle en un système qu’une organisation peut gouverner en toute confiance.

Dispositif d’évaluation et d’optimisation

Un dispositif d’évaluation et d’optimisation teste les performances d’un agent sur des tâches réelles, repère ses échecs et aide les équipes à améliorer le système sans dépendre de réglages manuels ponctuels. Au lieu de juger l’agent uniquement sur sa réponse finale, le dispositif peut évaluer le plan, le contexte récupéré, les appels d’outils, les résultats intermédiaires, les coûts, la latence et le résultat final.

Dans les implémentations plus avancées, le dispositif peut également proposer des modifications aux instructions de l’agent, aux outils, aux modèles sémantiques, aux prompts ou à la configuration du processus, puis tester ces modifications sur des jeux de régression et d’évaluation avant leur mise en production. L’amélioration de l’agent devient ainsi une boucle gouvernée : évaluer, diagnostiquer, modifier, tester et ne conserver que les changements qui améliorent les performances sans altérer le comportement existant.

Un système multi-agents utilise plusieurs agents pour accomplir une tâche. Sa valeur réside dans la spécialisation : un agent récupère le contexte, un autre raisonne sur les règles, un troisième écrit du code, un quatrième valide le résultat et un orchestrateur coordonne le processus.

Cette spécialisation est souvent la raison principale d’utiliser un système multi-agents. Au lieu de demander à un seul agent généraliste de gérer chaque fonction, les équipes peuvent diviser le travail entre des agents plus spécialisés aux responsabilités plus claires.

Le compromis réside dans les frais opérationnels de coordination. Chaque transfert nécessite un état, des autorisations, une gestion des erreurs et un historique clair des actions de chaque agent. En pratique, la conception multi-agents consiste moins à multiplier les agents qu’à déterminer où la spécialisation améliore suffisamment le résultat pour justifier cette complexité supplémentaire.

Orchestration séquentielle

L’orchestration séquentielle fonctionne comme un pipeline. Un agent termine une étape et transmet son résultat au suivant. C’est l’équivalent multi-agents du chaînage de prompts, et cela fonctionne bien lorsque l’ordre des tâches est prévisible.

Un processus de traitement de documents, par exemple, peut extraire des entités, classer le document, vérifier les règles de conformité et rédiger un résumé selon une séquence fixe. Chaque étape dépendant du résultat de la précédente, le processus peut être inspecté comme une chaîne de décisions intermédiaires.

Orchestration hiérarchique

L’orchestration hiérarchique utilise un agent superviseur. Le superviseur reçoit l’objectif, délègue des sous-tâches à des agents spécialisés et assemble le résultat final.

Des cadres tels que LangGraph prennent en charge ce type de processus de production, car les modèles d'état basés sur des graphes s'adaptent bien aux points de contrôle, aux nouvelles tentatives et aux points de récupération. Les cadres basés sur les rôles, tels que CrewAI, sont souvent utilisés pour les prototypes où les équipes souhaitent attribuer rapidement des tâches à des agents désignés avant de consolider le processus.

Orchestration parallèle

L’orchestration parallèle soumet le même problème à plusieurs agents simultanément, puis fusionne ou compare les résultats. Ce modèle est moins courant en production aujourd’hui, car il augmente les coûts, la latence et la complexité de réconciliation.

Il reste toutefois utile dans les processus axés sur l’évaluation, où des réponses indépendantes renforcent la fiabilité. Par exemple, plusieurs agents peuvent examiner la même proposition de réponse, tester différentes hypothèses ou vérifier le résultat auprès de sources distinctes avant l’assemblage d’une réponse finale.

Normes de communication entre outils et agents

Le MCP et les nouveaux protocoles de communication d’agent à agent font partie de cette couche d’orchestration. Le MCP normalise la façon dont les agents et les applications d’IA se connectent aux outils et aux sources de données. Les protocoles de communication d’agent à agent se concentrent sur la façon dont les agents échangent des messages, des états et des résultats de tâches entre eux.

Ces normes aident les équipes à déterminer si et comment l’organisation peut gouverner quel agent a appelé quel outil, avec quelles autorisations, pour quelle tâche et avec quel résultat.

L’autonomie est un spectre. Un agent d’IA peut être autonome dans une partie d’un processus et strictement encadré dans une autre. Il peut récupérer des documents, inspecter des métadonnées et rédiger une recommandation de manière autonome, puis nécessiter une approbation humaine avant de mettre à jour un système, d’envoyer un message ou de modifier un pipeline. Cet équilibre varie également selon le cas d’usage.

Le niveau de protection requis par un processus dépend à la fois des conséquences d’un échec (ce qui se passe si l’agent commet une erreur et la difficulté à l’annuler) et du moment où cet échec risque de se produire. Une règle d’approbation générale peut réduire les risques, mais elle risque aussi de ralentir les étapes à faible risque que l’agent gère déjà bien. Un garde-fou plus ciblé, appliqué là où l’agent a tendance à récupérer un contexte faible, à choisir le mauvais outil ou à surestimer sa fiabilité, peut améliorer la sécurité sans transformer l’ensemble du processus en révision manuelle.

La gouvernance des agents doit tenir compte des conséquences, et pas seulement des résultats. Dès lors qu’un système d’IA peut récupérer des données, appeler des outils et agir sur des processus, les échecs ne se limitent plus à une réponse inexacte. L’agent pourrait utiliser un contexte non autorisé, divulguer des informations sensibles ou prendre une mesure dont les conséquences en aval seraient coûteuses ou impossibles à annuler.

Exactitude

La précision est une préoccupation majeure. Dans la finance, l’ingénierie, la santé, la sécurité et d’autres domaines à haut risque, l’agent doit récupérer le bon contexte, utiliser la bonne définition, appliquer la bonne politique et savoir quand son niveau de confiance est trop faible pour continuer. L’évaluation doit refléter la tâche. Par exemple, un benchmark LLM générique ne montrera pas si un agent applique correctement les règles de comptabilisation des revenus d’une organisation ou s’il fait remonter la bonne alerte de sécurité.

Gouvernance

L’accès aux données gouvernées est également une priorité absolue. Les agents doivent souvent travailler sur des données structurées, des documents, des fichiers audio, des logs, des images, des tickets et du code. Ces sources reposent sur différents modèles d’accès, et la capacité d’action de l’agent ne doit pas dépasser l’autorité de l’utilisateur. Un agent gouverné a besoin de la propagation de l’identité, de l’application des politiques, de contrôles des requêtes et de pistes d’audit qui indiquent quelles données ont été utilisées.

M. Allen soutient toutefois que les organisations ne devraient pas attendre que chaque question de gouvernance soit réglée avant de se lancer. « Vous devez définir les politiques, les orienter et les gouverner. Mais n’ayez pas peur d’aller plus vite, faites-le simplement avec un partenaire de confiance qui comprend l’aspect gouvernance. »

Confiance et sécurité

La confiance et la sécurité deviennent plus complexes dès lors que les agents commencent à utiliser des outils. L’injection de prompt, les autorisations excessives, les appels d’outils non sécurisés, les fuites de données et les actions d’écriture non autorisées deviennent tous des risques concrets. Le framework de sécurité doit tenir compte à la fois du comportement du modèle et des systèmes qu’il peut atteindre.

Coût et latence

Le coût et la latence constituent souvent le premier obstacle opérationnel. Une simple interaction prompt-réponse peut nécessiter un seul appel au modèle. Un processus agentique en plusieurs étapes peut inclure la planification, la récupération, des appels d’outils, la réflexion, une autre étape de récupération et une réponse finale. Chaque étape ajoute des coûts et du temps. La réflexion, les boucles ReAct et l’orchestration multi-agents sont utiles lorsque la tâche les justifie, mais elles impliquent des compromis délibérés en matière de coûts et de précision.

Avant qu’un agent puisse agir en production, les équipes doivent définir les données auxquelles il peut accéder, les outils qu’il peut utiliser, les actions qu’il peut entreprendre, les approbations dont il a besoin et les preuves requises pour auditer ce qui s’est passé. L’objectif n’est pas simplement de connecter un modèle à davantage de systèmes, mais de créer un chemin d’exécution gouverné, de la requête de l’utilisateur à l’action de l’agent.

Commencer par l’accès aux données

Avant qu’un agent ne touche aux données de production, définissez ce qu’il est autorisé à lire, ce qu’il est autorisé à écrire et quelle interface il doit utiliser. Dans une architecture gouvernée, l’agent ne devrait pas bénéficier d’un accès direct et illimité aux tables. Il doit fonctionner via des couches de requêtes approuvées, des API, des modèles sémantiques ou des systèmes de récupération qui appliquent l’identité, la politique et le contexte.

Définir la gouvernance au niveau du plan de contrôle

Le plan de contrôle doit appliquer les autorisations, acheminer les appels d’outils, journaliser les actions, gérer les approbations et arrêter les processus qui dépassent les limites définies. Si un agent peut mettre à jour un ticket, envoyer un message, modifier un pipeline ou exécuter une requête sur des données sensibles, le chemin d’approbation et d’audit doit être clair avant le début de l’utilisation en production.

L’évaluation précède le déploiement

L’agent doit être testé par rapport à des benchmarks spécifiques à la tâche qui reflètent le travail qu’il effectuera. Pour un agent de données, cela peut inclure des questions avec des définitions d’indicateurs ambiguës, des tables obsolètes, des documents contradictoires, des champs à accès restreint et des cas limites connus. Les seuils de précision doivent correspondre au risque du processus. Un assistant de connaissances interne peut tolérer plus d’incertitude qu’un agent d’ingénierie qui modifie l’infrastructure ou qu’un agent financier qui alimente le reporting.

La supervision se poursuit après le déploiement

Les équipes ont besoin de traces qui montrent chaque étape du processus de l’agent : contexte récupéré, appels d’outils, résultats intermédiaires, approbations, latence, coût et actions finales. La détection de dérive, les pistes d’audit des actions et les chemins d’escalade impliquant une intervention humaine aident les équipes à comprendre quand le comportement de l’agent change, quand ses entrées se dégradent ou quand une décision à faible niveau de confiance nécessite une révision.

Dans les systèmes d’agents en production, les équipes ont également besoin d’un dispositif capable de montrer quelles questions, quels outils, quels chemins de récupération ou quelles étapes de processus provoquent des échecs, puis de tester les correctifs proposés à la fois sur des cas ciblés et des ensembles de régression. CoCoEvolve de Snowflake en est un exemple : le système enveloppe un artefact d’IA, propose des modifications, évalue si elles sont utiles, conserve les modifications réussies et rejette celles qui ont échoué.

L’avenir des agents d’IA sera probablement moins façonné par des améliorations de modèles isolés que par les systèmes qui fournissent le contexte, gouvernent l’action et coordonnent le travail entre les outils. À mesure que les agents passeront des fenêtres de chat aux processus opérationnels, les entreprises auront besoin d’architectures qui exposent les bonnes données au bon moment, préservent les autorisations des utilisateurs et enregistrent ce qui s’est passé à chaque étape.

Pour les équipes en entreprise, cette architecture implique souvent de rapprocher l’IA des données gouvernées plutôt que de copier les données dans un environnement d’IA distinct. « Vous devez pouvoir amener l’IA aux données, et non déplacer ces données en raison de toutes les règles de gouvernance », explique Allen. « Laissez vos données là où elles sont, puis exploitez l’IA pour créer des agents qui disposent de ce contexte. »

C’est aussi pour répondre à cette exigence que des protocoles tels que le MCP gagnent en importance. Les agents ont besoin d’un moyen homogène de découvrir et d’utiliser les outils, les sources de données et les applications sans que chaque connexion ne repose sur une intégration sur mesure. Anthropic a présenté le MCP en novembre 2024 comme un standard ouvert pour connecter les applications d’IA aux systèmes externes, avant d’en faire don à l’Agentic AI Foundation sous l’égide de la Linux Foundation en décembre 2025. Depuis, le MCP a dépassé le cadre des outils locaux et est utilisé en production par un nombre croissant d’organisations.

L’essor du MCP laisse entrevoir un écosystème agentique plus connecté, mais la connexion seule ne résout pas les défis des entreprises. La prochaine étape dépendra également d’une interopérabilité gouvernée : des agents capables de découvrir des outils, de les utiliser avec la bonne identité, de respecter les politiques, de préserver le contexte et de transférer le travail entre les systèmes sans perdre la piste d’audit.