À retenir
- Il est facile de rendre une démo d’agent impressionnante, mais un système en production exige de la fiabilité, des traces, des évaluations et une bonne gestion des échecs.
- Après une démo locale, la vraie question est la suivante : comment savoir si elle a fonctionné, pourquoi elle a échoué et ce qui a changé après une correction?
- L’ingénierie de l’IA agentique porte sur tout le système qui entoure l’autonomie, pas seulement sur la capacité d’un modèle à appeler un outil.
Je reçois souvent cette question depuis quelque temps. « Ok, j’ai construit un agent. Il fonctionne localement. Et maintenant? » Et ce que les gens veulent généralement dire, c’est qu’il fonctionne plus ou moins, mais qu’ils ne lui font pas confiance. Ou pire, ils l’ont déployé et ne savent pas comment le déboguer. Cette tension me reste en tête depuis un bon moment.
Depuis 2022, j’ai une vision très claire : construire la ressource la plus complète pour les ingénieurs qui veulent travailler avec de vrais systèmes d’IA. Pas des astuces de prompting. Pas des notebooks jouets. Pas « regardez, il appelle un outil ». De vrais systèmes. Le genre qui survit à la production. Après neuf mois à construire, briser, reconstruire et tester sous pression, Agentic AI Engineering est enfin en ligne. Mais le cours n’est vraiment que la surface. La vraie histoire, c’est pourquoi nous l’avons construit.
Pendant les dernières années, j’ai toujours gardé un plan B qui avançait discrètement en parallèle. Un doctorat. Des services-conseils indépendants. Du travail à temps partiel chez EY. Quelque chose de stable. Quelque chose de sécuritaire. Il n’avait jamais complètement disparu. Cette année, j’y ai mis fin. Complètement. Pour la première fois, je m’engage entièrement à construire Towards AI avec mon partenaire Louie Peters et notre incroyable équipe. Aucun filet de sécurité. Et ce cours est probablement le signal le plus clair de cette décision. Il ne suit pas une mode. Il ne repose pas sur le hype. Il est assumé et très axé sur l’ingénierie. Il reflète ce qui compte réellement selon nous.
Ce qui me dérangeait, c’est la vitesse à laquelle le domaine est passé de « les LLMs peuvent compléter du texte » à « tout le monde construit des agents ». Les ingénieurs peuvent maintenant construire des démos d’agents impressionnantes en une fin de semaine. Des systèmes multi-agents, des appels d’outils, de la mémoire, de la recherche Web, des boucles autonomes. En surface, c’est incroyable. Et honnêtement, ça l’est. Surtout quand on considère que les LLMs ne font *que* générer des tokens. Mais dès que ces systèmes touchent à la production, quelque chose change. Ils deviennent instables. Ils ne se trouvent plus dans un environnement contrôlé. Et, pour être honnête, les utilisateurs ne se comportent jamais comme prévu. Ce n’est pas parce que le modèle est idiot. Ce n’est pas parce que l’autonomie est impossible. C’est parce que l’architecture n’a pas été conçue pour de vraies contraintes. Il n’y a aucun framework d’évaluation. Aucune observabilité. Aucun monitoring. Aucun raisonnement clair sur les situations où l’autonomie est justifiée et celles où elle n’est qu’un théâtre de complexité. Aucune discipline de déploiement. Personne n’enseignait l’écart entre « ça roule » et « on peut le livrer de façon fiable ». Et cet écart, c’est tout.
Nous l’avons ensuite ouvert à 180 testeurs alpha pendant neuf mois. De mai 2025 à… aujourd’hui. C’est là que les choses sont devenues intéressantes. Ils ont poussé le système dans des directions que nous n’avions pas explorées. Ils ont construit par-dessus. Ils ont essayé différents environnements de déploiement. Ils ont forcé des edge cases. Et chaque fois que quelque chose brisait, nous nous demandions : est-ce un problème d’outil, de framework ou de raisonnement? La plupart du temps, c’était un problème de raisonnement. En gros, la partie difficile n’est pas d’appeler des outils. C’est de prendre des décisions rigoureuses sur l’architecture, la validation, les limites de l’autonomie et l’évaluation.
Voici une courte vidéo qui donne plus de contexte sur le cours :
Dans le cours, vous construisez deux agents. Mais ce n’est pas vraiment le point. Le point, c’est comment et pourquoi ils sont construits de cette façon. Vous construisez un agent de recherche qui exécute de vraies boucles itératives, intègre de vrais outils, produit des artefacts structurés et prend en charge des points de contrôle humains avec des conditions d’arrêt claires. Vous construisez ensuite un agent de workflow de rédaction qui transforme cette recherche en outputs structurés et multimodaux à l’aide de patterns évaluateur-optimiseur, d’orchestration, de gestion des versions et d’état. Et vous ne faites pas que les faire fonctionner une fois. Vous les évaluez. Vous concevez des datasets. Vous implémentez des juges LLM. Vous ajoutez de l’observabilité avec des traces. Vous conteneurisez le tout. Vous le déployez dans le cloud. Vous branchez le CI/CD. Vous ajoutez l’authentification. Vous gérez l’état dans une base de données. Parce que le prompting est la partie la plus facile. La fiabilité est le vrai travail.
Un choix que je fais très consciemment consiste à ne pas trop adapter le cours au framework à la mode ce trimestre. LangGraph peut évoluer. CrewAI peut évoluer. Les APIs vont certainement évoluer. Et… les agents nous remplaceront pour gérer tout cela. Une chose que vous devez conserver et qui ne devrait pas « régresser » avec votre utilisation de Claude Code, c’est votre jugement d’ingénieur. Quand faut-il utiliser un workflow plutôt qu’un agent? Quand l’autonomie ajoute-t-elle de la valeur et quand ajoute-t-elle seulement de la latence et des coûts? Combien d’outils peut-on ajouter avant que la sélection se dégrade? Quand faut-il répartir le travail entre plusieurs agents et quand ne fait-on que créer un surplus de coordination? Comment concevoir des agents légers et des outils qui font le gros du travail? Comment construire des boucles de validation qui renvoient un feedback exploitable au lieu de scores de qualité vagues? Comment réfléchir à l’observabilité avant que les choses tournent mal, plutôt qu’après? Voilà les questions qui comptent réellement.
Ce contenu ne s’adresse pas aux débutants. Vous devriez être à l’aise avec Python. Vous avez déjà utilisé des APIs de LLMs. Vous comprenez Docker et les concepts de base du cloud. Déboguer des choses qui n’échouent pas proprement ne vous fait pas peur. Vous allez transpirer un peu. C’est intentionnel. L’ingénierie de production n’est pas passive.
Nous avons livré plus de 20 applications d’IA. Nous avons formé des centaines de milliers d’ingénieurs grâce à Towards AI. Nous avons écrit Building LLMs for Production. Paul a écrit The LLM Engineer’s Handbook. Et malgré tout, nous voyions encore des gens coincés dans ce que j’appelle le purgatoire des démos. Des prototypes impressionnants. Aucune discipline de production. Ce cours est notre réponse. Pas « les agents remplaceront tout l’an prochain ». Pas « des entreprises entièrement autonomes ». Seulement une position très pragmatique : si vous construisez des agents, construisez-les correctement.
Nous l’avons d’abord ouvert discrètement à notre communauté proche et 75 places sont déjà parties. Nous lançons les 100 premières places à tarif de lancement à 449 $ avant que le prix augmente. Vous obtenez un accès à vie, les mises à jour continues, un accès à Discord, des appels d’introduction en direct et une garantie de remboursement de 30 jours si vous parcourez les premiers contenus et réalisez que le cours ne correspond pas à vos besoins. Sans friction.
Si vous construisez des agents en ce moment et que vous avez ressenti cette subtile instabilité, ce petit sentiment de « j’espère que ça ne plantera pas en production », c’est exactement ce que ce cours vise à résoudre. Arrêtons de tout optimiser pour les démos. Construisons des systèmes qui survivent à la production.
Inscrivez-vous maintenant et débloquez un accès à vie, avec toutes les futures mises à jour : https://academy.towardsai.net/courses/agent-engineering?ref=1f9b29
FAQ
Pourquoi arrêter de construire des démos d’agents?
Les démos cachent les parties difficiles : l’évaluation, le débogage, le déploiement, le monitoring, les coûts, les permissions et la confiance des utilisateurs.
Qu’est-ce qui rend un agent prêt pour la production?
Il lui faut des objectifs clairs, des outils bien délimités, des logs, des évaluations, une gestion des échecs, des approbations humaines lorsque nécessaire et une façon de s’améliorer en toute sécurité.
Qu’est-ce que le piège de la démo d’agent?
Le piège consiste à prendre une exécution réussie dans le scénario idéal pour un système capable de survivre aux vrais utilisateurs et aux edge cases du monde réel.
Que faut-il évaluer avant de faire confiance à un agent?
Testez l’exécution de la tâche, la sélection des outils, la récupération après un échec, les permissions, la latence, les coûts et le comportement devant des inputs adversariaux ou incomplets.
Pourquoi construire un système que l’équipe utiliserait réellement?
Une utilisation réelle expose les contrôles manquants et les frictions du workflow qu’une démo soigneusement préparée pendant une fin de semaine peut facilement cacher.