Agents IA
Des systèmes qui décident et agissent — et qui échouent proprement quand ils décident mal.
Un agent est une boucle : le modèle choisit un outil, quelque chose se produit dans le monde, le résultat revient dans le contexte, et on recommence jusqu’à terminaison. C’est toute l’idée — d’où le fait qu’un agent soit trivial à prototyper et brutal à exploiter. Chaque itération compose l’erreur, dépense de l’argent, et pose quelque part une action peut-être irréversible. Ce parcours est bâti autour de cette réalité. Vous commencez par écrire la boucle vous-même, sans framework, pour voir exactement où réside le contrôle et ce que le modèle décide vraiment. Viennent ensuite les outils, qui sont un problème de conception d’API déguisé : un outil au nom vague et à la description floue sera appelé au mauvais moment, et aucun prompt ne répare une mauvaise interface. Puis ce que personne ne montre en démo — une mémoire qui ne devient pas une décharge, une planification qui survit à une étape ratée, et la discipline de supposer que l’agent finira par faire une bêtise, parce qu’il la fera. Une phase entière est consacrée à l’échec : retries, boucles infinies, plafonds de budget, validations humaines. En production, le plafond d’un agent n’est pas son intelligence, c’est l’élégance avec laquelle il casse. Les architectures multi-agents arrivent en dernier, avec un avertissement : la plupart des équipes s’y précipitent pour éviter de réparer un agent unique qu’elles n’ont jamais instrumenté.
Ce que vous allez apprendre
Prérequis
- Python ou TypeScript solide, async compris
- Avoir déjà construit quelque chose sur une API LLM
- Comprendre le RAG et la sortie structurée
- De la patience pour déboguer des systèmes non déterministes
Débouchés
- Ingénieur agents IA
- Architecte d’automatisation
- Ingénieur IA appliquée
- Lead technique sur des produits à base d’agents
Phases
Phase 1 — La boucle et ses outils
Écrire la boucle agentique à la main, puis concevoir des outils qu’un modèle sait réellement utiliser.
Durée estimée · 8-10 semainesÉcrire la boucle soi-même
La boucle fait environ quatre-vingts lignes : envoyer le contexte, lire l’appel d’outil, l’exécuter, ajouter le résultat, recommencer. L’écrire soi-même n’est pas un exercice de pureté : c’est le seul moyen de savoir où vit votre bug quand l’agent se met à divaguer à la septième itération. Vous affronterez aussi les conditions d’arrêt, plus difficiles qu’il n’y paraît : un agent qui ne sait pas qu’il a fini dépensera volontiers votre budget à le prouver.
Sujets couverts
Ce que vous allez construire
- Écrire une boucle d’agent fonctionnelle en moins de 100 lignes sans framework d’agent — trois outils, un plafond d’itérations strict, et une transcription lisible
- Provoquer volontairement une boucle infinie, puis la corriger par une condition d’arrêt plutôt qu’un plafond plus bas
- Afficher le contexte exact envoyé à chaque itération et trouver le moment où il a cessé d’avoir du sens
Concevoir un outil, c’est concevoir une API
Le modèle est un développeur junior qui lit votre documentation, et rien d’autre. Il ne peut pas demander à un collègue, il ne lira pas votre code source, et il prend votre description au pied de la lettre. Noms ambigus, outils qui se recouvrent et messages d’erreur qui disent juste « échec » produisent des agents qui s’agitent en vain. Réécrire une description d’outil bat généralement la réécriture du system prompt, pour une fraction du travail.
Sujets couverts
Ce que vous allez construire
- Mesurer le taux d’appels au mauvais outil sur 50 tâches, réécrire uniquement les descriptions, et rapporter l’écart
- Réécrire chaque erreur d’outil en message actionnable et montrer que l’agent se relève d’un échec sur lequel il bouclait avant
- Éclater un outil surchargé en trois outils ciblés et prouver que le taux de succès a bougé
Phase 2 — Mémoire et planification
Donner à l’agent un état et une stratégie sans le noyer dans son propre historique.
Durée estimée · 8-10 semainesUne mémoire qui ne devient pas une décharge
Le design naïf empile tout indéfiniment, et il échoue deux fois : le coût croît linéairement pendant que la qualité chute, car un contexte bourré de vingt sorties d’outils périmées enterre les trois qui comptent. La mémoire est un problème de budget. La compétence, c’est décider quoi oublier volontairement — et presque personne n’écrit cette règle, d’où un agent qui se dégrade sur une longue session sans que personne sache pourquoi.
Sujets couverts
Ce que vous allez construire
- Faire tourner un agent sur 50 itérations et tracer coût et qualité par étape jusqu’à voir le point de dégradation
- Ajouter la compaction et maintenir la qualité constante en réduisant la croissance du contexte à une fraction du linéaire
- Écrire une politique d’éviction explicite, trouver la tâche qu’elle casse, puis la défendre ou la réviser
Planification, décomposition et reprise
Le plan-puis-agir a l’air discipliné et vole en éclats à la première surprise. La réactivité pure, elle, erre. La réponse utile est un échafaudage déterministe autour d’étapes non déterministes : vous décidez la forme du travail en code, le modèle en décide le contenu. La replanification après un échec est là où l’agent justifie son existence — et l’autocritique aide moins qu’on ne le prétend : un modèle qui vient de se tromper est mal placé pour s’en apercevoir.
Sujets couverts
Ce que vous allez construire
- Prendre une tâche d’agent et la reconstruire en workflow fixe — mesurer les deux, puis argumenter par écrit lequel doit partir en production
- Injecter un outil défaillant à la troisième étape et faire replanifier l’agent au lieu de réessayer à l’identique
- Ajouter une étape de vérification après chaque écriture et compter les mauvaises actions attrapées sur 30 exécutions
Phase 3 — Échec, garde-fous, multi-agents
Supposer que l’agent fera une bêtise. La rendre survivable, observable et peu coûteuse.
Durée estimée · 8-12 semainesGarde-fous et rayon d’explosion
La sécurité des agents n’est pas un prompt qui dit « sois prudent ». C’est le moindre privilège, des sandboxes et des validations sur tout ce qui est irréversible. La surface d’attaque que la plupart des équipes ratent, c’est le résultat d’outil : un document récupéré par votre agent peut contenir des instructions, et votre agent les lit avec la même confiance que les vôtres. Traitez toute sortie d’outil comme une entrée hostile — un jour, l’une le sera.
Sujets couverts
Ce que vous allez construire
- Planter une charge d’injection dans un document récupéré par l’agent, le voir obéir, concevoir la mitigation et prouver qu’elle tient
- Poser une validation humaine sur chaque action irréversible et mesurer la fréquence des refus — si elle est nulle, votre garde-fou est du théâtre
- Construire un kill switch fonctionnel et arrêter un agent en plein appel d’outil sans corrompre son état
Observabilité, évaluation et multi-agents
On ne débogue pas ce qu’on ne peut pas rejouer. Tracez chaque étape, chaque appel d’outil, chaque token, et rendez une exécution passée reproductible — sinon chaque incident devient du folklore. Évaluez les trajectoires, pas seulement la réponse finale : un agent qui atteint le bon résultat via six appels gaspillés et un appel dangereux ne fonctionne pas. Le multi-agents arrive ici, à la fin, parce qu’il multiplie tout ce qui précède.
Sujets couverts
Ce que vous allez construire
- Construire un visualiseur de traces permettant de rejouer toute exécution pas à pas, le confier à un collègue qui débogue un échec sans vos explications
- Noter 30 exécutions sur la qualité de trajectoire, pas seulement le résultat, et trouver au moins une exécution « réussie » que vous refuseriez de livrer
- Scinder un agent en deux, mesurer coût et succès face à la référence mono-agent, et écrire le verdict honnête même s’il est négatif
Questions
Faut-il utiliser un framework d’agents ?
À terme oui — mais pas en premier. Écrivez la boucle à la main une fois, car un framework ne supprime pas la difficulté, il la déplace : votre agent boucle toujours, brûle toujours du budget, appelle toujours le mauvais outil, sauf que le code qui le fait appartient désormais à quelqu’un d’autre. Les ingénieurs partis d’un framework sortent une démo le premier jour, puis calent des semaines sur un bug invisible, parce que les décisions intéressantes sont derrière une abstraction. Une fois la vôtre écrite, adoptez un framework pour ce qu’il apporte réellement — retries, tracing, concurrence, intégrations — avec la capacité de lire ce qu’il fait et de le remplacer quand il cesse de convenir.
Pourquoi les agents marchent en démo et s’effondrent en production ?
Parce qu’une démo est un chemin heureux et la production, une distribution. Les erreurs se composent : une étape juste à 95 % est juste à environ 60 % après dix étapes, et la démo ne vous a montré que l’exécution qui a marché. Les pièces manquantes sont toujours les trois mêmes : des erreurs d’outils que le modèle ne peut pas exploiter, donc il réessaie à l’identique ; aucun plafond de budget ou d’itérations, donc un agent perdu dépense de l’argent réel en rond ; et une évaluation limitée à la réponse finale, qui masque les trajectoires chanceuses. Rien de tout cela ne se règle avec un meilleur modèle. Ça se règle en instrumentant la boucle et en regardant les chiffres en face.
Quand une architecture multi-agents en vaut-elle vraiment la peine ?
Moins souvent que les schémas ne le laissent croire. Deux raisons tiennent : le parallélisme réel, quand des sous-tâches indépendantes tournent en même temps et que vous gagnez du temps horloge ; et la séparation réelle, quand des sous-travaux exigent des outils ou des permissions différents et que vous voulez scinder le rayon d’explosion. Le reste est généralement un agent unique jamais instrumenté, déguisé en organigramme. Ajouter des agents ajoute une taxe de coordination : les passations perdent du contexte, le débogage s’étale sur plusieurs transcriptions, et le coût se multiplie en silence. Réparez d’abord l’agent unique : meilleures descriptions d’outils, politique de mémoire, évaluations de trajectoire. S’il échoue encore, scindez délibérément et mesurez face à la référence mono-agent.
Parcours liés
Envie de suivre ce parcours avec un coach et une cohorte ?
Découvrir la 212AY Academy →