Pourquoi j'écris sur les agents LLM (l'histoire de la facture à $847)
Tout a commencé un mardi soir, à 23h47.
Mon agent de test tournait depuis 6 heures. Je ne m'en étais pas rendu compte --- j'étais passé à autre chose, confiant. « L'agent gère », me disais-je. Quand j'ai vérifié ma console le lendemain matin, la facture API affichait $847. Huit cent quarante-sept dollars. Pour une nuit.
J'avais oublié de mettre une limite d'itérations. L'agent cherchait la « meilleure » solution à un problème d'optimisation de code et ne s'arrêtait jamais. Chaque boucle coûtait quelques centimes --- un appel GPT-4 ici, un appel d'outil là. Multiplié par des milliers d'itérations sur 6 heures, ça fait $847 de tokens partis en fumée.
Ce matin-là, en regardant le dashboard OpenAI, j'ai pris deux décisions. La première : ne plus jamais lancer un agent sans garde-fous. La deuxième : écrire un livre qui documente toutes ces erreurs pour que d'autres développeurs ne les commettent pas.
Le catalogue des catastrophes : mes erreurs les plus coûteuses
La facture de $847 n'était pas un incident isolé. C'était le point culminant d'une série de catastrophes plus ou moins spectaculaires. Laisse-moi te raconter les meilleures --- ou les pires, selon le point de vue.
L'agent qui « nettoyait » les fichiers inutiles
J'avais construit un agent de maintenance de codebase. Sa mission : analyser un repository, identifier les fichiers obsolètes, et proposer leur suppression. Le problème, c'est que je lui avais donné l'outil file_delete sans contrainte suffisante.
Un mardi après-midi, l'agent a décidé que mon fichier .env était « un artefact de développement non versionné, probablement inutile ». Supprimé. Mon docker-compose.yml ? « Configuration redondante avec le Dockerfile ». Supprimé. Le requirements.txt ? « Les dépendances sont déjà déclarées dans setup.py ». Supprimé aussi.
Heureusement, Git m'a sauvé. Mais j'ai perdu deux heures à comprendre pourquoi mon déploiement avait cassé.
Le RAG qui retournait les mauvaises dépendances
Celui-là m'a coûté deux jours complets de debug. J'avais un agent avec un système RAG (Retrieval-Augmented Generation) pour répondre aux questions sur un projet Python. Le problème : mon index vectoriel mélangeait la documentation de requests 2.x et httpx 1.x, deux bibliothèques HTTP aux APIs similaires mais incompatibles.
Quand un développeur junior de l'équipe a demandé « Comment faire un POST avec authentification ? », l'agent a renvoyé un mélange de code requests et httpx. Le code semblait correct, passait la revue visuelle, mais crashait en runtime avec des erreurs d'import incompréhensibles.
Deux jours. Deux jours pour réaliser que le problème n'était pas le code, mais le contexte RAG qui mélangeait les sources.
Le cache mal configuré qui a trahi un client
Mon agent de support client utilisait un cache Redis pour éviter de rappeler l'API à chaque requête similaire. Bonne idée en théorie. En pratique, j'avais mis un TTL (Time-To-Live) de 24 heures sur les réponses.
Problème : un client a signalé un bug à 9h. Mon équipe l'a corrigé à 10h. Mais l'agent continuait de servir la réponse cachée « Nous avons identifié le problème et travaillons dessus » pendant encore 23 heures. Le client a rappelé trois fois, obtenu la même réponse automatique à chaque fois, et a fini par écrire un post furieux sur Twitter.
Coût : la confiance d'un client. Plus cher que $847.
Ce que ces erreurs m'ont appris : les patterns qui marchent
Chaque catastrophe m'a laissé une leçon. Et en les compilant, j'ai réalisé qu'elles formaient un corpus cohérent --- pas une collection d'anecdotes, mais un système de patterns et d'anti-patterns pour la construction d'agents LLM.
Pattern 1 : Le budget d'exécution. Tout agent doit avoir un budget --- en tokens, en itérations, en temps, et en argent. Pas une limite théorique. Un hard stop. Mon agent à $847 avait une « soft limit » de 50 itérations qui loggait un warning. Il fallait un max_iterations=50 qui lève une exception.
# Anti-pattern : soft limit
if iterations > 50:
logger.warning("Beaucoup d'itérations...") # L'agent s'en fiche
# Pattern : hard stop
if iterations > 50:
raise BudgetExhaustedError(
f"Agent arrêté après {iterations} itérations. "
f"Coût: ${total_cost:.2f}"
)Pattern 2 : Le principe du moindre privilège. Un agent ne doit avoir accès qu'aux outils strictement nécessaires à sa tâche, avec des contraintes explicites sur chaque outil. L'agent de maintenance n'avait pas besoin de file_delete --- il avait besoin de suggest_deletion qui crée une PR.
Pattern 3 : La séparation des sources RAG. Chaque source documentaire doit être indexée séparément avec des métadonnées explicites (bibliothèque, version, date). Le retriever doit filtrer par source avant le ranking sémantique, pas après.
Pattern 4 : Le cache invalidable. Un cache de réponses d'agent doit être invalidable manuellement et automatiquement sur certains événements (déploiement, correction de bug, changement de données).
51 pièges, 17 chapitres : la structure du livre
Ces patterns sont devenus le squelette du livre. J'ai catalogué 51 pièges répartis en 17 chapitres, organisés par couche architecturale :
- •Couche orchestration (chapitres 1-4) : boucles infinies, explosion de coûts, gestion d'état, retry storms
- •Couche outils (chapitres 5-8) : injection de prompt via outils, permissions excessives, erreurs silencieuses, timeouts manquants
- •Couche RAG (chapitres 9-12) : contamination d'index, chunking inadapté, re-ranking défaillant, hallucinations sourcées
- •Couche mémoire (chapitres 13-15) : cache empoisonné, mémoire qui diverge, perte de contexte
- •Couche production (chapitres 16-17) : observabilité, testing, déploiement progressif
Chaque chapitre suit le même format :
- 1.Le Problème --- l'erreur classique, avec un scénario concret
- 2.La Solution Rapide --- du code qui fonctionne en 30 secondes
- 3.Le Deep Dive --- pourquoi ça marche, les mécanismes sous-jacents
- 4.Les Edge Cases --- 3 pièges supplémentaires par chapitre
- 5.L'Optimisation --- les patterns de production
Trois livres, trois angles : pourquoi pas un seul ?
En écrivant, j'ai réalisé qu'un seul livre ne pouvait pas couvrir tous les profils de lecteurs. Le développeur senior qui veut du code ne veut pas lire des explications pédagogiques. Le développeur junior qui découvre les agents ne veut pas être noyé dans du code avancé sans contexte.
Alors j'ai écrit trois versions :
Agent LLM Python --- la version code-first. 51 pièges, 17 chapitres, du code à chaque page. Pour le développeur senior qui veut des réponses concrètes, vite. C'est le livre que j'aurais voulu avoir avant ma facture de $847.
Agent LLM Pratique --- la version atelier. Même contenu technique, mais structuré comme un workshop. Tu construis un agent complet (Analys-Bot) chapitre après chapitre, en ajoutant une couche à chaque étape : orchestration, outils, RAG, mémoire, sécurité.
Agent LLM Narratif --- la version pédagogique. L'histoire de Maya, développeuse junior qui rejoint une startup et découvre les agents LLM. Chaque chapitre est une journée de Maya, avec un problème réel, un mentor qui explique, et du code qui fonctionne. Pour ceux qui apprennent mieux avec une histoire.
La meilleure façon d'apprendre : sur les erreurs des autres
Il y a une phrase que j'ai entendue dans un talk de John Carmack : « Si tu veux apprendre vite, étudie les post-mortems, pas les tutoriels ». Les tutoriels te montrent le chemin doré. Les post-mortems te montrent les falaises de chaque côté.
C'est exactement l'approche de ces livres. Pas de théorie abstraite sur les architectures agentiques. Des bugs réels, des factures réelles, des solutions testées en production. Chaque piège documenté est un piège dans lequel je suis tombé --- ou dans lequel j'ai vu quelqu'un tomber.
Et le sujet de la mémoire --- comment un agent se souvient de ses conversations passées, de ses erreurs, de son contexte --- était tellement riche qu'il a mérité son propre livre.
Parce que la mémoire est le talon d'Achille des agents LLM. Un agent sans mémoire refait les mêmes erreurs. Un agent avec une mémoire mal conçue hallucine des souvenirs. Et un agent avec une bonne mémoire... change tout. C'est la différence entre un stagiaire qui recommence à zéro chaque matin et un collègue qui se souvient de tes préférences, de tes décisions passées, et du contexte de ton projet.
Depuis la nuit du $847, j'ai dépensé $12 000+ en APIs LLM. Mais je n'ai plus jamais eu de facture surprise. Pas parce que je suis devenu meilleur --- mais parce que j'ai appris à mettre des garde-fous avant de lancer l'agent, pas après.
Si tu construis des agents LLM ou si tu envisages de t'y mettre, ces erreurs vont t'arriver. La seule question est : tu préfères les découvrir dans un livre à 20 euros ou sur ta facture API ?
