Un peu plus de la moitié des équipes qui construisent des agents IA les ont déjà en production : 57,3 % d'après le dernier sondage State of Agent Engineering mené par LangChain fin 2025 auprès de 1 340 personnes, et 30,4 % de plus les développent avec un calendrier de mise en production précis. Le même sondage place la qualité des réponses, hallucinations et incohérence des sorties, en tête des freins cités, devant la latence et la sécurité. Construire un agent qui répond juste en démo reste la partie facile.
Sur les projets d'agents IA livrés chez Noxcod, la panne la plus fréquente n'arrive jamais pendant la démo : elle survient quand l'agent tourne sans supervision, boucle sur le même appel d'outil faute de condition d'arrêt, ou choisit le mauvais outil parce que sa description était trop vague. Cet article détaille les décisions qui séparent un prototype qui impressionne d'un agent qui tient une charge réelle : le périmètre, le modèle et le mécanisme d'appel d'outils, la conception des outils eux-mêmes, la mémoire, l'évaluation avant déploiement, et la gouvernance une fois en production.
Agent ou workflow : la question qui se tranche avant d'ouvrir un IDE
Le mot agent recouvre des systèmes très différents. Anthropic distingue nettement les deux dans son article d'ingénierie sur la construction d'agents efficaces : un workflow orchestre des appels au modèle de langage selon un chemin de code défini à l'avance, pendant qu'un agent laisse le modèle décider lui-même, à chaque étape, quel outil appeler et dans quel ordre. Le choix a des conséquences concrètes : un workflow reste prévisible, testable et moins coûteux à faire tourner. Un agent gagne en souplesse, en échange d'une latence et d'une facture de tokens plus difficiles à borner à l'avance.
La recommandation d'Anthropic tient en une phrase : commencer par la solution la plus simple qui résout le problème, un seul appel au modèle, un enchaînement de prompts, un routeur qui classe la demande vers un traitement spécialisé, ou plusieurs sous-tâches menées en parallèle, et ne construire un agent complet que lorsque la tâche est réellement ouverte, avec un nombre d'étapes impossible à prévoir d'avance. Un enchaînement de facturation mensuelle qui suit toujours les cinq mêmes étapes se contente d'un routeur. Un agent qui doit décider seul comment répondre à un client sur un dossier qu'il découvre en direct correspond au cas où l'autonomie a un sens.
Cette question de périmètre se pose avant celle du framework ou du modèle, et elle recoupe ce qui change réellement avec l'IA agentique en entreprise : la plupart des cas d'usage vendus comme agents sur le marché restent, une fois ouverts, des workflows bien conçus. Rien de dégradant à ça : un workflow bien scopé livre plus vite et casse moins souvent qu'un agent qu'on a laissé décider seul trop tôt.
Choisir le modèle et le mécanisme d'appel d'outils
Techniquement, un agent IA repose sur un mécanisme appelé appel de fonction ou appel d'outil : à chaque tour, le modèle reçoit la liste des outils disponibles sous forme de schémas JSON, avec leur nom, leur description et leurs paramètres, et répond soit par un texte final, soit par une demande d'exécuter un outil précis avec des arguments structurés. L'application exécute alors ce tool call, renvoie le résultat au modèle sous forme de message, et la boucle continue jusqu'à ce que le modèle juge avoir assez d'informations pour répondre.
Le choix du modèle qui pilote cette boucle a un effet direct sur la fiabilité de l'ensemble : un modèle qui hallucine un nom de paramètre ou invente un outil qui n'existe pas fait échouer la boucle plus vite qu'un mauvais prompt. En pratique, la plupart des équipes ne misent plus sur un seul fournisseur : d'après le sondage LangChain, plus des trois quarts des organisations utilisent déjà plusieurs modèles en production ou en développement, l'un pour le raisonnement le plus exigeant, un autre moins cher pour les tâches d'agent plus simples ou plus fréquentes.
Deux voies existent pour implémenter cette boucle. La première consiste à l'écrire soi-même en code, avec un contrôle total sur la logique de nouvelle tentative, de délai maximal et de journalisation de chaque appel. La seconde passe par un éditeur visuel qui gère la boucle en coulisses, un canevas comme Flowise ou Dify pour un agent conversationnel autonome, ou le nœud agent IA natif de n8n quand l'agent doit surtout orchestrer des outils métier existants plutôt que raisonner longuement. Le code donne plus de contrôle sur les cas limites, l'éditeur visuel réduit le temps entre l'idée et le premier prototype testable.
Concevoir des outils que l'agent peut vraiment utiliser
La partie la plus sous-estimée d'un projet d'agent n'est pas le prompt système : ce sont les outils eux-mêmes. Anthropic appelle ça l'interface agent-machine, par analogie avec l'interface humain-machine : un outil mal documenté produit les mêmes erreurs qu'une application mal conçue pour son utilisateur, sauf que le modèle ne peut pas deviner ce qu'on attend de lui en explorant l'écran, il ne dispose que de la description textuelle du schéma.
Un outil nommé get_data avec un paramètre id sans autre précision pousse le modèle à deviner le format attendu : un e-mail, un identifiant numérique, une référence de commande, et à se tromper régulièrement selon ce qui a été vu dans le contexte. Le même outil renommé get_client_by_email, avec une description qui précise le format attendu et un exemple concret dans le schéma, réduit ces erreurs de sélection de façon nette dans la pratique. Sur les projets d'agents IA suivis chez Noxcod, retravailler uniquement la description des outils, sans toucher au prompt système, corrige souvent une bonne partie des erreurs de sélection d'outil observées en test.
Le principe qu'Anthropic recommande, rendre l'usage incorrect plus difficile que l'usage correct, se traduit concrètement par des schémas stricts : des champs obligatoires plutôt qu'optionnels quand l'information est indispensable, des formats validés côté application avant exécution, et des messages d'erreur qui expliquent au modèle ce qui a été mal formé plutôt qu'un simple rejet. Cette discipline se teste en conditions réelles, avec des entrées variées et des cas limites, avant de laisser l'agent choisir seul parmi plusieurs outils proches.
Donner de la mémoire à l'agent sans faire exploser le contexte
Un agent qui garde toute la conversation en mémoire tient bien sur les premiers échanges, puis dérive dès que l'historique s'allonge : chaque tour renvoie l'intégralité des messages précédents au modèle, ce qui fait grimper le nombre de tokens facturés à chaque appel et finit par dépasser la fenêtre de contexte du modèle sur une session longue. La mémoire courte, un simple tampon des derniers échanges, suffit pour un agent qui répond en une poignée de tours. Au-delà, il faut résumer périodiquement l'historique ou ne conserver que les éléments pertinents pour la tâche en cours.
La mémoire longue pose un problème différent : elle ne concerne plus la conversation en cours mais la connaissance que l'agent doit mobiliser, une base documentaire, un historique client, une politique interne. C'est le terrain de la récupération augmentée par recherche, où l'agent interroge une base vectorielle avant de répondre plutôt que de tout garder dans son contexte. Un agent IA d'analyse documentaire illustre bien ce cas : il ne lit pas l'intégralité d'un corpus à chaque question, il récupère les passages pertinents puis raisonne dessus.
Brancher ces sources de mémoire et ces outils externes de façon standardisée est justement le problème que résout le protocole MCP, qui expose des outils et des données selon un format commun plutôt qu'une intégration différente pour chaque source. Un agent qui doit consulter un CRM, une base documentaire et un agenda gagne à se brancher sur des serveurs MCP existants plutôt qu'à réécrire une intégration pour chacun.
Évaluer avant de déployer : jeux de test, traçage, budget de tokens
Un agent qui répond bien sur les trois exemples testés à la main pendant le développement ne dit rien de son comportement sur les mille variantes qu'un utilisateur réel va essayer. D'après le sondage LangChain, 52,4 % des équipes qui construisent des agents exécutent déjà des évaluations hors ligne sur des jeux de test fixes avant chaque déploiement, et 37,3 % ajoutent une évaluation en ligne sur le trafic réel. Chez les équipes déjà en production, la discipline monte encore : 94 % ont mis en place de l'observabilité et 71,5 % disposent d'un traçage complet de chaque appel d'outil.
Construire un jeu de test minimal ne demande pas d'outillage complexe : une vingtaine de scénarios représentatifs, avec pour chacun l'entrée attendue, la séquence d'outils que l'agent devrait appeler et le résultat final acceptable, rejoués avant chaque changement de prompt ou de modèle. Anthropic recommande la même discipline pour la conception des outils : tester les outils eux-mêmes en banc d'essai avec des entrées variées avant de les brancher sur l'agent complet, plutôt que de découvrir leurs limites une fois en production.
Le traçage sert un second objectif, moins visible en développement : donner un budget. Un agent sans limite explicite de tours ou de tokens peut, sur une entrée ambiguë, relancer le même outil en boucle en attendant une réponse qui ne viendra jamais, et faire grimper la facture en quelques minutes avant qu'un humain ne s'en aperçoive. Fixer un nombre maximal de tours et un plafond de tokens par session, avec une sortie explicite vers une réponse par défaut ou une escalade humaine, coûte quelques lignes de code et évite l'incident qui arrive presque systématiquement sans ce garde-fou.
Les pièges qui n'apparaissent qu'en production
Le sondage LangChain place la qualité, hallucinations et incohérence des réponses, en tête des freins à la production, citée par 32 à 33 % des équipes selon les segments interrogés, devant la latence à 20 % et la sécurité à 24,9 % chez les entreprises de plus de 2 000 salariés. Ces trois pièges se recoupent en pratique : un agent lent pousse à réduire le nombre d'appels d'outils pour gagner en rapidité, ce qui dégrade la qualité des réponses, et une réduction mal pensée des vérifications de sécurité pour gagner en latence ouvre la porte aux erreurs que la vérification servait justement à empêcher.
Gartner prévoit que plus de 40 % des projets d'IA agentique seront abandonnés d'ici fin 2027, pour trois raisons récurrentes : des coûts qui dérivent au-delà de l'estimation initiale, une valeur métier qui reste floue, et des contrôles de risque insuffisants une fois le prototype passé en charge réelle. Le cabinet estime aussi qu'à peine 130 fournisseurs, sur les milliers qui se présentent comme agentiques, le sont vraiment, le reste relevant de ce que Gartner appelle l'agent washing, un assistant ou un robot de traitement de tâches repeint en agent sans que le modèle décide réellement de grand-chose.
Sur les projets suivis chez Noxcod, la panne la plus fréquente reste la boucle sans condition d'arrêt : un agent qui reformule la même requête à un outil qui ne répond pas ce qu'il attend, et qui recommence indéfiniment plutôt que d'escalader vers un humain ou de renvoyer une réponse par défaut. Ce garde-fou, une poignée de lignes de code, coûte largement moins cher que les tokens brûlés par une boucle qui tourne toute une nuit sans supervision.
Industrialiser l'agent : maintenance, gouvernance, et quand appeler une agence
Un agent qui fonctionne en test ne devient un projet industrialisé qu'une fois trois questions tranchées. Qui peut modifier un prompt système ou un schéma d'outil en production, et selon quel circuit de validation, sachant qu'un changement de prompt peut casser un comportement qui fonctionnait la veille aussi sûrement qu'un changement de code. Où sont stockées les identifiants des fournisseurs de modèle et des outils connectés, chiffrés et séparés par environnement plutôt que partagés dans un fichier de configuration accessible à toute l'équipe. Comment une dérive de qualité se détecte avant qu'un utilisateur ne la signale, ce qui ramène directement au traçage et aux jeux d'évaluation rejoués à chaque changement.
Ces questions rejoignent ce qui structure plus largement l'adoption de l'IA agentique en entreprise, au-delà du seul outil choisi pour construire l'agent. Elles se posent différemment selon le point de départ : une équipe qui part d'un canevas visuel comme Flowise ou Dify hérite d'une partie de cette gouvernance en natif, une équipe qui code sa boucle d'agent en JavaScript ou en Python doit construire elle-même le traçage, les jeux de test et les limites de tours.
Sur ce type de passage à l'échelle, l'audit de sécurité des identifiants, le choix d'architecture entre framework de code et éditeur visuel, et la mise en production supervisée sont exactement le terrain où notre agence spécialisée dans les agents IA sur mesure intervient auprès de nos clients, souvent après un premier prototype construit en interne qui a validé l'idée mais pas encore sa robustesse. Un projet dont le volume d'appels ou la sensibilité des données dépasse ce qu'un prototype couvre confortablement gagne à être chiffré avant de s'engager davantage, en prenant contact pour contacter Noxcod.
Questions fréquentes
Faut-il savoir coder pour créer un agent IA ?
Non pour un premier prototype : un éditeur visuel comme Flowise, Dify ou le nœud agent IA de n8n permet de relier un modèle, des outils et une mémoire sans écrire de boucle à la main. Le code redevient nécessaire dès qu'un outil doit appeler une API métier spécifique, valider un format strict avant exécution, ou qu'un budget de tours et de tokens doit être imposé au-delà de ce que l'éditeur visuel expose par défaut.
Quel modèle choisir pour un agent avec appel d'outils ?
Il n'existe pas de modèle universel : la plupart des équipes en combinent plusieurs, un modèle de raisonnement plus coûteux pour les décisions ambiguës et un modèle plus rapide pour les tâches d'agent répétitives, une pratique déjà majoritaire selon le sondage LangChain cité plus haut. Le critère décisif reste la fiabilité de l'appel d'outil : un modèle qui invente un nom de paramètre fait échouer la boucle plus souvent qu'un modèle plus lent mais précis.
Combien de temps pour construire un premier agent IA fonctionnel ?
Un prototype qui répond correctement sur un cas d'usage borné, un seul outil, une mémoire courte, se construit en quelques jours avec un éditeur visuel. Le délai s'allonge dès que plusieurs outils proches doivent être distingués sans ambiguïté, que la mémoire longue entre en jeu, ou qu'un jeu d'évaluation et un traçage doivent être posés avant tout déploiement en production.
Un agent IA peut-il inventer un appel d'outil qui n'existe pas ?
Oui, et c'est l'une des pannes les plus fréquentes en test : un modèle qui hallucine un nom de paramètre ou tente d'appeler un outil non déclaré. Un schéma d'outil strict, des messages d'erreur explicites renvoyés au modèle plutôt qu'un simple rejet, et un budget maximal de tours réduisent nettement la fréquence de cette panne sans l'éliminer complètement.
Quelle différence entre un agent IA et un chatbot ?
Un chatbot répond dans une conversation, sans nécessairement agir sur des systèmes externes. Un agent IA appelle des outils, une base de données, une API, un agenda, et enchaîne plusieurs étapes de décision avant de répondre, avec un nombre d'étapes qui n'est pas fixé à l'avance par le développeur mais choisi par le modèle lui-même selon la situation rencontrée.
