Agents autonomes LLM : du prototype à la production

L'année 2024 a été celle des démos spectaculaires et des déceptions en production. Les agents AutoGPT et autres boucles ouvertes ont fasciné Twitter, puis échoué dès qu'on leur a confié des tâches réelles avec un budget et un SLA. Le constat est net : un agent qui s'arme d'objectifs vagues, boucle sans garde-fou et consomme 200 K tokens pour répondre à un mail, ce n'est pas un produit. C'est une expérience de laboratoire.

Trois motifs ont pourtant survécu à la réalité. D'abord le pattern ReAct (raisonner, agir, observer), qui structure la pensée du modèle en étapes explicites et reste la fondation de la plupart des agents sérieux. Ensuite le tool use structuré, avec function calling natif chez OpenAI et tool use chez Anthropic — la capacité pour un modèle d'invoquer une fonction typée de façon fiable a transformé la qualité perçue. Enfin, le couplage agent + RAG, où la retrieval devient un outil parmi d'autres plutôt qu'un pré-traitement figé.

En revanche, la coordination multi-agents à grande échelle (trois à dix agents qui se parlent) s'est cassé la figure en production. Latence cumulée, coûts qui explosent, boucles de confirmation interminables : sur nos cas clients, un schéma à trois agents coûtait 4 à 6 fois plus cher qu'un agent unique bien orchestré, pour une qualité inférieure. La leçon retenue : un seul agent bien outillé vaut dix agents qui se concertent.

Le point de bascule est arrivé fin 2024 avec Claude 3.5 Sonnet puis GPT-4o, qui ont rendu le tool use suffisamment fiable (taux de succès > 95 % sur des schémas JSON stricts) pour oser la production. À mi-2025, Claude Sonnet 4.5 et Opus 4.5 ont poussé ce seuil au point où l'agent n'est plus le maillon faible — c'est l'orchestration autour qui l'est.

L'écosystème s'est consolidé autour de quatre briques. LangGraph s'est imposé comme le standard des graphes d'orchestration : nœuds typés, transitions explicites, état persisté, checkpoints. On peut enfin dessiner un agent comme on dessine un state machine, le tester, le rejouer, l'inspectuer. C'est verbeux, mais c'est ce qui tient en production. En parallèle, les SDK éditeurs (Claude Agent SDK, OpenAI Assistants v2) proposent une intégration plus courte quand on accepte le lock-in.

Anthropic a ajouté une couche importante avec Computer Use : un modèle qui voit l'écran et clique. Prometteur pour l'automatisation de legacy sans API, mais à réserver à des contextes très encadrés — un agent qui bouge la souris en production reste un risque. Pour les cas classiques (requêter une base, appeler une API, écrire un fichier), un agent outillé classique reste plus rapide, plus traçable, moins cher.

Côté exécution durable, Temporal et Restate sont devenus les compagnons naturels des agents. La promesse : survivre à un crash processus, un timeout réseau, une mise à jour de l'orchestrateur. Un agent qui tourne 12 minutes, qui appelle 8 outils et qui tombe au 9e appel à cause d'un redéploiement doit pouvoir reprendre — pas tout recommencer. Temporal fait ça avec une maturité d'entreprise ; Restate, plus léger, séduit par sa simplicité de déploiement.

La stack cible que nous déployons chez nos clients en 2025 : LangGraph pour le graphe, Temporal ou Restate pour la durabilité, un cache sémantique en façade (GPTCache ou Helicone caching), et une couche d'observabilité dédiée (Langfuse ou Arize). C'est verbeux, mais chaque brique répond à un échec de production réel que nous avons constaté au moins une fois.

Le tool use est devenu le primitive qui sépare les démos des systèmes. Deux avancées concrètes l'ont fait basculer : les sorties structurées par schéma JSON (OpenAI structured outputs, Anthropic tool use avec JSON schema strict) et les appels d'outils parallèles. Le modèle ne se contente plus de proposer un appel, il propose cinq appels en parallèle quand la tâche le permet, ce qui divise par trois la latence p95 sur les workflows de recherche.

Concrètement, entre un agent Claude Sonnet 4.5 et un agent GPT-4o sur le même benchmark interne (analyse d'un dossier client, 7 outils disponibles, 50 cas) : Sonnet 4.5 termine 88 % des cas en moins de 12 étapes, contre 74 % pour GPT-4o, avec un taux d'outil invalide de 1,2 % contre 3,8 %. Opus 4.5 pousse à 94 % de réussite mais triple le coût token. Le bon compromis, sur nos cas B2B français, est aujourd'hui Sonnet 4.5 par défaut, avec escalade vers Opus sur les tâches longues à fort enjeu.

Trois règles nous ont beaucoup servi. D'abord, typer chaque outil avec un JSON schema strict — pas de champ optionnel flou, pas de description courte. Le modèle lit la description comme un contrat. Ensuite, exposer des outils petits et composables plutôt qu'un méga-outil polymorphe : un `searchUsers`, un `getUserById`, un `updateUserStatus` valent mieux qu'un `manageUsers(action, payload)`. Enfin, renvoyer des erreurs structurées (`{ error_code, message, retryable }`) plutôt qu'une chaîne — le modèle se trompe beaucoup moins sur un code typé.

Le piège classique reste le sur-outillage. Plus un agent a d'outils, plus il choisit mal. Au-delà de 12 outils exposés, le taux de sélection du bon outil chute de 15 à 20 points. La parade : faire précéder l'agent d'un routeur léger (un petit LLM ou un classifieur) qui sélectionne un sous-ensemble pertinent d'outils selon l'intention, puis laisse l'agent principal travailler dans un espace réduit.

Un agent en production sans observabilité dédiée est un agent que vous allez débugger au téléphone avec un client mécontent. Les outils classiques d'APM (Sentry, Datadog) ne suffisent pas : ils voient l'erreur finale, pas le cheminement. Il faut une couche agent-aware qui trace chaque étape, chaque appel d'outil, chaque token.

Langfuse est devenu notre référence open-source : traces arborescentes, coûts par run, latence par nœud, comparaison de prompts. Arize et Helicone jouent dans la même cour, avec des angles différents (évaluation automatique chez Arize, proxy de cache chez Helicone). Le minimum syndical : tracer chaque appel modèle (prompt, complétion, modèle, tokens, latence, coût), chaque appel d'outil (entrée, sortie, statut), et chaque transition de graphe.

Les métriques qui comptent en production d'agent ne sont pas celles des démos. Le taux de réussite global est presque inutile — il masque les dérives. Ce qu'il faut suivre : le nombre moyen d'étapes par tâche (un agent qui passe de 8 à 14 étapes sur deux semaines dérive), le coût token par tâche réussie (et non par tâche tentée), le taux d'outil invalide par modèle, et surtout le taux de tâches interrompues par l'utilisateur (signe que l'agent part dans le mur).

Concrètement, sur un agent de support interne déployé chez un client, nous avons vu le coût par ticket grimper de 0,18 € à 0,47 € en trois semaines sans que personne ne s'en plaigne. Les réponses étaient toujours correctes, mais l'agent était devenu bavard, multipliait les vérifications inutiles et appelait deux fois le même outil par sécurité. Sans observabilité dédiée, le drift aurait été détecté au prochain renouvellement de budget — trop tard. La règle que nous appliquons : toute alerte sur coût ou étapes anormales doit déclencher une revue humaine sous 48 h.

La règle absolue, non négociable, doit être gravée dans le code : un agent n'exécute jamais une action destructive sans approbation humaine explicite. Supprimer un enregistrement, envoyer un mail à un client, débiter une carte, modifier un schéma de base — toute action irréversible passe par une porte de confirmation. Ce n'est pas une option de configuration, c'est un invariant du système.

Concrètement, chaque outil est annoté avec un niveau de risque (`read`, `write_reversible`, `irreversible`). Les outils `irreversible` sont wrappés dans un gate qui suspend l'exécution, notifie un humain (Slack, e-mail, interface dédiée), et attend une confirmation signée. Temporal gère élégamment cette suspension : le workflow dort, l'état persiste, l'humain répond quand il veut. Si l'humain ne répond pas sous 24 h, la tâche est annulée — pas exécutée par défaut.

Le second pilier est l'exécution sandboxée des outils. Un agent qui peut exécuter du code (parce qu'il doit, par exemple, transformer un fichier CSV) tourne dans un bac à sable : conteneur Docker éphémère, gVisor pour l'isolation kernel, réseau coupé par défaut sauf allowlist explicite, filesystem en lecture-seule sauf un répertoire de travail. La sortie du bac à sable est validée par schema avant d'être réinjectée dans l'agent. Le coût marginal est réel (~300 ms de démarrage de conteneur) mais la sécurité l'emporte.

Côté audit, chaque exécution d'agent est journalisée : utilisateur initiateur, objectif, étapes, outils invoqués, paramètres (anonymisés si PII), sorties, décision finale. La trace est conservée 12 mois minimum et peut être rejouée. Sur un incident réel (un agent qui a failli envoyer un mauvais template de relance à 200 clients), c'est cette trace qui a permis de comprendre en 20 minutes ce qui s'était passé et de blinder la garde-fou pour l'avenir.

Le Model Context Protocol (MCP) d'Anthropic, annoncé fin 2024, commence à s'imposer comme la couche d'interopérabilité manquante. Un serveur MCP expose des outils, des ressources et des prompts selon un protocole standardisé ; n'importe quel client MCP-compatible (Claude Desktop, Cursor, IDE, runtime d'agent) peut les consommer. Pour la première fois, écrire un outil pour un agent devient aussi indépendant du runtime qu'écrire une route HTTP. En 2026, notre pari est que la plupart des éditeurs SaaS B2B exposeront un serveur MCP natif, comme ils exposent une API REST aujourd'hui.

La communication agent-to-agent standardisée est le second chantier. Aujourd'hui, faire collaborer deux agents d'éditeurs différents demande du collage ad hoc. Les travaux autour d'A2A Protocol (Google) et des extensions MCP visent à définir un vocabulaire commun : comment un agent déclare ses capacités, comment un autre le sollicite, comment les résultats sont typés. Nous y voyons le futur des architectures événementielles : un agent orchestrateur, des agents spécialistes joignables à la demande, contrats typés entre eux. Mais la maturité n'est pas là avant mi-2026 au mieux.

La convergence avec les outils traditionnels de BPM et d'orchestration (Camunda, Temporal, n8n entreprise) s'accélère. Les workflows métier historiquement codés en BPMN vont pouvoir intégrer des étapes agentiques : un nœud LLM qui négocie avec un fournisseur, qui rédige une proposition commerciale, qui classifie une réclamation. Ce qui semblait être deux mondes (orchestration déterministe d'un côté, agent probabiliste de l'autre) converge vers une discipline hybride où l'on choisit, pour chaque étape, entre règle explicite et délégation à un modèle.

Surtout, l'agent ops devient le nouveau MLOps. Comme le MLOps a absorbé la discipline de mise en production des modèles (évaluation, drift, A/B, monitoring), l'agent ops devra absorber la spécificité des systèmes agents : tracing multi-étapes, contrôle qualité par simulation, garde-fous d'action, auditabilité, escalade humaine. Les équipes qui ont investi dans un MLOps sérieux en 2023-2024 ont un an d'avance — et celles qui l'ont négligé devront rattraper les deux blocs d'un coup. Le plan 2026 que nous recommandons à nos clients : outiller l'agent ops avant de scaler le nombre d'agents. Un agent bien observé vaut dix agents opaques.