Agents IA : du démo qui brille à la production qui tient
Le blog de Varick Agents dresse la liste de ce qui sépare un agent qui impressionne en réunion d'un agent qui survit à de vrais utilisateurs, et c'est surtout du génie logiciel.
In breve
Suite de « AI Agents 101 », ce guide explique pourquoi la plupart des projets d'agents meurent entre la démo et la production. Il propose six piliers d'ingénierie, une méthode d'évaluation volontairement simple, une infrastructure de connaissances versionnée, des patterns multi-agents et une checklist de mise en production.
🍺 Versione da bancone
En démo, ton agent est comme un candidat à un entretien d'embauche : il répond aux questions qu'il a préparées, devant quelqu'un qui le surveille. En production, il bosse seul, la nuit, face à des clients qui écrivent n'importe comment, et personne ne regarde quand il commence à faire n'importe quoi. Le guide dit en gros : valide ce qui entre, note tout ce qu'il fait, plafonne ce qu'il dépense, et teste-le sur une centaine de vrais cas avant de le lâcher. Bref, l'IA a besoin des mêmes garde-fous que n'importe quel logiciel, sauf qu'elle peut te coûter des milliers de dollars avec beaucoup plus d'assurance.
Da ricordare
- 1
Les démos masquent quatre réalités de la production : des entrées imprévisibles, l'absence de supervision humaine, les edge cases et l'accumulation de contexte sur de longues sessions.
- 2
Six piliers structurent un agent fiable : validation et normalisation des entrées, dégradation gracieuse, timeouts et retries, checkpoints d'état, limites de ressources et audit logging.
- 3
Les retries doivent distinguer les échecs transitoires (rate limit), traités par backoff exponentiel, des échecs permanents (identifiants invalides).
- 4
Un golden dataset d'environ 100 exemples réels suffit pour un agent au périmètre étroit, à condition de documenter entrée, sortie attendue, justification et métadonnées.
- 5
Un score d'accuracy unique est trompeur : 90 % peut cacher un échec total sur les 10 % de cas complexes, précisément ceux où l'agent devrait apporter de la valeur.
- 6
Les évals doivent tourner dans la CI/CD et bloquer le merge d'une pull request si les scores passent sous un seuil.
- 7
La connaissance de l'agent doit être externalisée du code et versionnée, pour diagnostiquer et annuler les changements de comportement.
Pourquoi les démos mentent
En démo, on choisit les entrées qui fonctionnent. En production, les utilisateurs envoient des formulations ambiguës, des informations incomplètes, des demandes hors périmètre qui cassent la logique de parsing.
En démo, on regarde l'agent travailler et on intervient au moindre écart. En production, il tourne seul : les erreurs s'accumulent dans les logs jusqu'à ce que les clients se plaignent, avec parfois des centaines de mauvaises décisions à nettoyer à la main.
Les edge cases, qu'on évite en démo parce qu'ils alourdissent le récit, sont justement là où un agent prouve son intelligence ou révèle sa fragilité. Les cas simples relèvent souvent d'une automatisation classique.
Enfin, les longues sessions font de la gestion d'état un sujet critique : la fenêtre de contexte se remplit et impose de choisir ce qu'on garde, l'une des décisions les plus importantes selon l'auteur.
Six piliers, beaucoup de génie logiciel
Les entrées doivent être validées et normalisées avant que l'agent ne les voie : formats acceptés explicites, rejet avec message d'erreur, gestion des fautes de frappe, abréviations et variations de casse. En cas d'impossibilité, l'agent doit soit rendre un résultat partiel clairement signalé, soit demander une clarification. Le pire scénario : produire silencieusement des déchets.
Les dépendances externes tombent : il faut des timeouts et des retries avec backoff exponentiel pour les échecs transitoires. Des checkpoints sauvegardés à chaque étape significative (entrées, décisions prises, travail restant) permettent de reprendre après un crash plutôt que de tout recommencer.
Côté coûts, un agent qui appelle une API en boucle peut générer des milliers de dollars de facture. D'où des limites explicites : appels par minute, écritures en base par tâche, tokens par session, temps d'exécution par workflow, avec alertes à l'approche des seuils.
Dernier pilier, l'audit logging : pour chaque action, consigner l'état d'entrée, les données récupérées, le raisonnement, l'action et ses paramètres, le résultat et les erreurs, dans un format requêtable.
Des évals simples mais systématiques
L'auteur identifie deux écueils : tester « aux vibes » sans méthode, ou construire une infrastructure d'évaluation si complexe qu'elle se désynchronise de la réalité.
Une bonne éval répond à trois questions : l'agent agit-il correctement quand il doit agir ? S'abstient-il quand il ne doit pas agir ou manque d'informations ? Performe-t-il sur les cas qui comptent pour les utilisateurs et le business ?
La base est un golden dataset construit à partir d'interactions réelles, environ 100 exemples pour un premier agent au périmètre étroit. Les métriques doivent être ventilées par type de cas, et les évals intégrées à la CI/CD pour bloquer toute régression.
Connaissances et orchestration multi-agents
La connaissance (produits, politiques internes, expertise métier) se répartit selon les usages : bases vectorielles pour la recherche sémantique, bases relationnelles ou documentaires pour les faits structurés, fichiers de configuration pour les règles explicites. Tout changement doit être versionné.
Quand un workflow dépasse ce qu'une fenêtre de contexte peut contenir, on passe à plusieurs agents au contexte isolé, au prix de davantage de points de défaillance à évaluer.
Deux architectures dominent : le pipeline séquentiel (classification, traitement métier, mise en forme) et le parallèle, où par exemple des agents juridique, financier et technique examinent simultanément un même dossier avant fusion des résultats.
La checklist avant de déployer
Le guide se conclut sur sept vérifications : gestion des entrées, modes de défaillance, gestion des ressources, observabilité, évaluation, connaissances et supervision humaine.
Ce dernier point mérite attention : des critères d'escalade définis, et des escalades qui transmettent assez de contexte pour qu'un humain tranche rapidement.
“Demos and production have different requirements; that transition is where most agent projects die.”
“The worst possible outcome is an agent that silently produces garbage when something goes wrong.”
“An agent that makes API calls in a loop without rate limits can generate thousands of dollars in charges.”
Perché conta
Ce texte ne révèle rien de révolutionnaire, et c'est précisément son intérêt : il rappelle que l'essentiel de la fiabilité d'un agent ne vient pas du modèle mais de l'ingénierie qui l'entoure, validation, idempotence, observabilité, tests de non-régression. À l'heure où le discours marketing vend des agents « autonomes », ce rappel au génie logiciel est salutaire, notamment la critique de l'accuracy agrégée et l'insistance sur l'abstention comme comportement à évaluer. Il faut toutefois le lire pour ce qu'il est : un contenu d'acquisition d'une agence qui vend des audits, volontairement survolé, sans chiffres de terrain ni retour d'expérience précis. Une excellente porte d'entrée et une checklist utile, pas un manuel.
Per te
Falla lavorare sulle tue fonti.
Gratis: un mese di articoli e tre fonti tue. Pro: tutto l'archivio e le tue fonti, da 8 €/mese.
Per il tuo team
La stessa macchina, sui vostri temi.
Uno spazio con i vostri colori, i vostri angoli di monitoraggio, i vostri curatori. Pilota aperto a tre aziende.