Un agent IA d’entreprise n’est pas un modèle de langage doté d’un long prompt. C’est une boucle fermée : le modèle reçoit un objectif, choisit une action, appelle un outil externe, lit le résultat et décide de l’étape suivante — jusqu’à ce que l’objectif soit atteint, jusqu’à ce qu’il se bloque, ou jusqu’à épuisement du budget d’étapes. Sous le capot il n’y a que quatre composants : modèle, outils, mémoire et contrôle. Dans l’enquête McKinsey de novembre 2025 (1 993 répondants dans une centaine de pays) environ 62 % des organisations expérimentaient des agents mais seulement 23 % environ les avaient passés à l’échelle, et Gartner prévoit que plus de 40 % des projets d’IA agentique seront annulés d’ici fin 2027. Cet écart ne se situe presque jamais dans le modèle.
Ce qui distingue vraiment un agent d’un chatbot
La différence n’est pas la qualité des réponses. C’est qui décide de l’ordre des opérations. Dans un chatbot, c’est l’humain : il pose une question, reçoit du texte et décide quoi en faire. Dans l’automatisation classique, c’est le développeur, et à l’avance : le processus est écrit sous forme d’organigramme et chaque branche a été définie au moment de la construction. Dans un agent, cette décision se déplace vers l’exécution — le modèle choisit quel outil appeler, dans quel ordre, et quand s’arrêter.
C’est la seule différence qui compte, et c’est aussi la source de tous les risques. Dès lors que l’ordre des opérations n’est pas fixé à l’avance, vous ne pouvez plus tester le système comme un logiciel ordinaire, et vous ne pouvez plus compter sur le fait que l’exécution réussie d’hier suivra le même chemin aujourd’hui.
| Propriété | Chatbot | Automatisation classique | Agent |
|---|---|---|---|
| Qui fixe l’ordre des opérations | L’utilisateur | Le développeur, au moment de la construction | Le modèle, au moment de l’exécution |
| Accès aux systèmes | En général aucun | Fixe et prédéfini | Dynamique, via une couche d’outils |
| Comportement en cas d’échec | Renvoie une réponse fausse | S’arrête et signale une erreur | Continue et amplifie l’erreur |
| Ce que vous testez avant le lancement | La qualité de la formulation | Les chemins connus | La distribution des résultats sur plusieurs exécutions |
La phrase clé : une automatisation qui casse s’arrête. Un agent qui casse continue de travailler. C’est pour cela que le contrôle est un composant du système, et non quelque chose que l’on ajoute à la fin.
La boucle d’exécution : planifier, agir, observer
Quel que soit le fournisseur, le langage ou le framework, tout agent exécute la même boucle. Le modèle reçoit l’objectif et l’état actuel du monde, produit une décision sur l’étape suivante, émet un appel vers un outil externe, récupère un résultat — puis se relance lui-même avec ce résultat intégré à son contexte. La boucle s’arrête quand le modèle déclare avoir terminé, quand un outil renvoie une erreur bloquante, ou quand un mécanisme externe l’interrompt.
Le mot important ici est observer. L’agent ne sait rien du monde en dehors de ce que les outils lui renvoient sous forme de texte. Si le CRM renvoie un champ vide, alors du point de vue de l’agent le client n’a réellement pas de numéro de téléphone. La qualité de l’observation est donc une variable d’ingénierie de premier ordre, pas un détail technique.
| Étape de la boucle | Ce qui se passe réellement | Mode d’échec typique |
|---|---|---|
| Réception de l’objectif | L’objectif devient le contexte initial, aux côtés des instructions système | Un objectif flou qui produit un chemin différent à chaque exécution |
| Planification de l’étape | Le modèle sélectionne un outil et ses arguments | Le bon outil avec le mauvais argument — l’échec le plus fréquent |
| Exécution | La couche d’outils lance l’appel contre le système réel | Une permission trop large qui autorise une action destructrice |
| Observation | Le résultat revient dans le contexte | Une réponse trop longue qui chasse des informations critiques antérieures |
| Décision | Continuer ou s’arrêter | Une boucle sans fin qui consomme le budget jusqu’au plafond |
Les quatre composants dont tout agent est fait
Démontez un agent et vous obtenez quatre composants. Trois d’entre eux ne sont pas le modèle, et c’est là que se concentre l’essentiel du travail d’ingénierie et la quasi-totalité des échecs.
| Composant | Son rôle | Ce qui casse quand il est faible |
|---|---|---|
| Modèle | Produit la décision sur l’étape suivante | Une formulation élégante avec un raisonnement défaillant ; changer de modèle ne répare pas les autres composants |
| Outils | La seule interface de l’agent avec la réalité | Une description d’outil imprécise mène à un mauvais usage, même avec un excellent modèle |
| Mémoire et contexte | Ce que l’agent sait au moment de décider | Des informations critiques évincées, ou un contexte pollué qui entraîne l’agent sur la mauvaise piste |
| Contrôle | Limites, permissions, budget d’étapes et points d’approbation | Aucun moyen d’arrêter une erreur avant qu’elle n’atteigne un client ou un système |
Dans les projets que nous voyons, la première réaction quand quelque chose ne fonctionne pas est presque toujours de changer de modèle. Dans la plupart des cas, ce n’est pas là qu’est le problème. Des descriptions d’outils précises, une sortie structurée plutôt que du texte libre et une condition d’arrêt claire améliorent le taux de réussite plus que n’importe quelle montée en gamme de modèle.
La couche d’outils : ce que MCP a réellement changé
Jusqu’à récemment, chaque connexion entre un modèle et un système d’entreprise était écrite de zéro : une intégration sur mesure pour chaque combinaison de modèle et de système. Model Context Protocol a remplacé cela par une couche uniforme — un serveur qui déclare des outils, et un client qui les appelle.
La révision stable de la spécification, datée du 28 juillet 2026, est la plus importante révision du protocole depuis son lancement. Les sessions au niveau du protocole et l’en-tête Mcp-Session-Id ont été retirés du transport Streamable HTTP ; la poignée de main initialize a été supprimée ; et les listes d’outils, de ressources et de prompts ne varient plus d’une connexion à l’autre, ce qui les rend cachables. Sont arrivées en parallèle les requêtes à plusieurs allers-retours, le routage par en-têtes, un cadre formel d’extensions et une autorisation durcie. Un serveur qui a besoin d’état entre deux appels le reçoit désormais via un identifiant explicite émis par le serveur et transmis comme un argument d’outil ordinaire.
Pourquoi cela compte pour ceux qui n’écrivent pas de code : un protocole sans état peut être déployé derrière un répartiteur de charge standard, mis à l’échelle horizontalement et supervisé avec des outils ordinaires. Autrement dit, la couche d’outils a cessé d’être un projet de recherche pour devenir une infrastructure que l’on peut budgéter, exploiter et auditer. Si vous prévoyez de faire tourner cette couche sur votre propre infrastructure, le modèle de coût complet se trouve dans notre guide sur l’hébergement d’agents sur votre propre matériel.
Le contexte est un budget, pas un entrepôt
L’erreur de conception la plus fréquente consiste à traiter la fenêtre de contexte comme un espace de stockage. Ce n’en est pas un. C’est un budget consommé à chaque étape, et que vous payez de nouveau à chaque appel. Un agent qui exécute vingt étapes paie vingt fois son propre historique.
Trois décisions de conception en découlent. Renvoyer depuis les outils une sortie structurée et compacte plutôt que des documents entiers. Compresser l’historique en un résumé d’état après un nombre d’étapes fixé. Récupérer la connaissance de l’entreprise à l’exécution au lieu de la précharger. Le versant financier de ces décisions est traité dans notre guide pour réduire le coût de l’inférence.
Où cela casse en pratique
Trois causes expliquent la plupart des échecs que nous rencontrons.
Erreurs cumulatives. Dans une boucle, une erreur commise à l’étape trois ne reste pas à l’étape trois. Elle entre dans le contexte et alimente à partir de là toutes les décisions suivantes. La défaillance visible apparaît donc loin de l’endroit où elle a été créée, et c’est pourquoi déboguer un agent exige de tracer une exécution complète plutôt que d’inspecter une seule réponse.
Mesure optimiste. La métrique de réussite courante demande si l’agent a réussi une fois, dans des conditions favorables. En production, ce qui compte est la stabilité : même tâche, cent exécutions, combien se terminent correctement. L’écart entre ces deux chiffres est l’écart entre une démonstration impressionnante et un système sur lequel on peut compter. Le combler est le sujet de notre guide sur l’évaluation des agents.
Agent washing. Gartner estime que sur les milliers de fournisseurs qui commercialisent une capacité agentique, seuls 130 environ proposent la chose réelle ; les autres rebaptisent des assistants existants, du RPA et des chatbots. La question qui filtre le plus vite lors d’un rendez-vous commercial : quels outils cet agent peut-il invoquer, et qui décide du moment où il les invoque.
La même note Gartner contient l’autre versant de l’histoire : d’ici 2028, environ 15 % des décisions de travail quotidiennes seront prises de façon autonome et 33 % des applications logicielles d’entreprise intégreront une capacité agentique, contre moins de 1 % en 2024. La direction est claire ; ce qui casse, c’est le calendrier et les attentes.
Une checklist avant votre premier agent
- Définissez une tâche qui se termine. Une tâche dotée d’une condition d’achèvement sans ambiguïté, et non un domaine de responsabilité ouvert.
- Comptez les outils. Si un premier agent dispose de plus de dix outils, vous avez probablement cartographié un intitulé de poste plutôt qu’une tâche.
- Écrivez les descriptions d’outils comme des contrats. Ce qui entre, ce qui sort, ce qui se passe en cas d’échec, et quand l’outil ne doit pas être utilisé.
- Fixez un budget d’étapes et un budget de tokens. Un plafond ferme qui arrête la boucle même quand le modèle est convaincu d’être sur la bonne voie.
- Marquez les actions irréversibles. Envoyer un e-mail, débiter, supprimer, mettre à jour un statut visible par le client — toutes ces actions exigent un point de validation humaine.
- Définissez les permissions avant d’écrire un prompt. C’est le modèle de permissions qui limite les dégâts, pas la formulation des instructions. Le traitement complet se trouve dans notre guide sur les limites de l’agent.
- Enregistrez chaque exécution. Sans journal complet des appels et des résultats, il n’y a ni débogage ni amélioration.
Si vous préférez partir d’un état des lieux structuré, commencez par nos domaines d’expertise. Si vous savez déjà ce que vous voulez déployer, parlons-en directement depuis notre page de contact.
Questions fréquentes
Quelle est la différence entre un agent IA et une automatisation ordinaire ?
Dans l’automatisation, l’ordre des opérations est fixé à l’avance par un développeur. Dans un agent, le modèle choisit ses actions à l’exécution, en fonction de l’objectif et de ce qu’il observe. L’automatisation se teste donc le long de chemins connus, tandis qu’un agent se teste par la distribution des résultats sur des exécutions répétées.
Faut-il un modèle particulièrement puissant pour construire un agent ?
Dans la plupart des cas, non. Le taux de réussite dépend davantage de la qualité des descriptions d’outils, de la gestion du contexte et des conditions d’arrêt que du choix du modèle. Un modèle plus puissant masque un temps les problèmes de conception, mais il rend aussi chaque étape de la boucle plus coûteuse.
Qu’est-ce que MCP et pourquoi tout le monde en parle ?
Model Context Protocol est un protocole uniforme pour connecter des modèles à des outils et à des sources de données. La révision stable du 28 juillet 2026 l’a rendu sans état : plus de sessions au niveau du protocole, des listes d’outils cachables et une autorisation durcie. En pratique, cela permet de déployer une couche d’outils comme une infrastructure ordinaire plutôt que comme un projet ponctuel.
Combien de temps faut-il pour mettre un premier agent en production ?
Une tâche unique avec trois à cinq outils et un point de validation humaine atteint généralement la production en quatre à huit semaines. L’essentiel de ce temps ne va pas à la construction de la boucle ; il va à une intégration propre des systèmes, à la conception des permissions et à la constitution de la suite de tests.
Quel est le signe qu’un agent n’est pas adapté à une tâche ?
Si vous pouvez écrire le processus sous forme d’organigramme complet, sans décision ambiguë, vous n’avez pas besoin d’un agent — l’automatisation sera moins chère, plus rapide et testable. Un agent devient rentable quand l’espace des possibles est trop vaste pour être écrit à l’avance.