Voici enfin le dernier chapitre. Jusqu'ici, vous êtes arrivé à comprendre la structure d'un agent, construire votre premier, connecter des outils, répartir à plusieurs, mesurer par l'évaluation et protéger par des garde-fous. Il reste un thème — en faire un « système de production qui tourne chaque jour ». Ce chapitre traite du choix d'un framework, des deux voies pour construire avec Claude, et des points clés d'exploitation : déploiement, supervision, coût et fiabilité. La conception défensive apprise au chapitre précédent, garde-fous et sécurité, porte ici ses fruits en exploitation.
L'objectif : « transformer un prototype en agent de production qui tourne de façon stable »
Faire soi-même, ou avec un framework
« Faut-il construire un agent avec un framework, ou écrire soi-même la boucle ? » — c'est la question qui déroute tout le monde au début. La réponse est simple : tant que c'est petit, faire soi-même pour apprendre les mécanismes ; quand ça grandit, monter la productivité avec un SDK ou un framework. Monter la configuration minimale à la main au chapitre 2, c'était précisément cette étape « d'abord comprendre en faisant soi-même ». Si l'intérieur vous est visible, vous pourrez plus tard basculer sur un framework tout en gardant la maîtrise de ce qui se passe. À l'inverse, tout déléguer à un framework sans connaître les mécanismes vous laisse démuni au moindre blocage.
💡 Le repère de décision. Quand écrire soi-même boucle, appels d'outils et gestion d'état devient un fardeau, c'est le signe d'adopter un framework. À l'inverse, si vous êtes encore petit et au stade expérimental, un code maison léger est plus rapide et fait mieux comprendre. Adoptez-le non « parce que c'est pratique » mais « parce que ça réduit la duplication ».
Comment choisir un framework
Les frameworks sont nombreux, mais avant de courir après les noms et les dernières versions, il importe d'avoir une règle de mesure : « sur quels critères choisir ». Les outils passent, mais ces angles de vue restent utiles longtemps. Évaluez les candidats selon les 5 suivants.
Plus il est élevé, moins il faut de code pour tourner, mais moins on voit ce qui se passe à l'intérieur. Choisir en équilibrant apprentissage et débogage.
Peut-on y glisser sa propre boucle ou son propre contrôle ? Plus les exigences sont poussées, plus une conception souple avec des échappatoires compte.
Richesse des composants d'intégration, de la doc, des exemples et de la communauté. Trouver de l'info en cas de souci pèse en pratique.
Dispose-t-il de traces, logs et évaluation ? Soutient-il d'origine la « mise en visibilité » apprise au chapitre 5 ?
N'enferme-t-il pas trop dans un modèle ou une plateforme donnés ? Facilité de migration et commodité du verrouillage sont un compromis.
Organiser grossièrement les exemples représentatifs par catégorie clarifie la vue. L'orchestration généraliste (les bibliothèques du genre LangChain qui assemblent des traitements LLM en chaînes ou en graphes), le multi-agent (les frameworks axés sur la répartition et la coordination de plusieurs agents), et les SDK officiels des éditeurs (les kits de développement, publiés par le fournisseur du modèle, optimisés pour ce modèle). Dans bien des cas, ils ne sont pas exclusifs et se combinent.
📊 Choisir par « angle de vue » plutôt que par nom précis. La carte des forces des frameworks bouge vite, et le standard de l'an dernier ne l'est pas forcément cette année. C'est justement pourquoi le plus sûr est de confronter à vos exigences les 5 angles ci-dessus comme règle de mesure. Pour les noms concrets et les usages par catégorie, vérifiez le casting le plus récent dans Comparatif des frameworks d'agents IA.
Deux options pour construire avec Claude
Cette formation s'est articulée autour de Claude. Pour mettre un agent Claude en production, il y a globalement deux voies. Toutes deux sont des options réelles, et leur différence essentielle est « qui héberge la boucle de l'agent et la sandbox ».
Le kit pour faire tourner boucle, exécution d'outils et gestion d'état de l'agent dans votre environnement (serveur ou conteneur). Le contrôle est fin et l'intégration profonde dans un système existant.
Quand l'utiliser : quand on veut un couplage étroit avec son environnement, ses outils et ses données propres.
Le mode où la boucle et la sandbox (l'environnement d'exécution isolé) de l'agent sont hébergées côté serveur par Anthropic. La charge d'exploitation de l'infrastructure d'exécution diminue, et l'on tourne dans un environnement isolé et sûr.
Quand l'utiliser : quand on veut réduire la corvée de l'environnement d'exécution et démarrer vite et en sécurité.
En gros, se repérer sur l'axe « pour contrôler finement soi-même, le SDK ; pour déléguer la corvée d'exploitation, le managé » est le plus clair. Les deux s'appuient sur les capacités de Claude, et l'on peut y réutiliser tel quel tout ce qu'on a appris — connexion d'outils, évaluation, garde-fous. La configuration concrète et la couverture pouvant évoluer, on renvoie les détails aux articles explicatifs et à la doc officielle.
💡 D'abord le concept, les détails à la source primaire. « Faire tourner la boucle soi-même (SDK) » ou « la faire héberger (managé) » — garder ce seul contraste en tête suffit. Pour la marche à suivre d'implémentation, voyez Le SDK Claude Agent, pour débuter ; pour l'approche du mode managé, Que sont les agents managés Claude. Les spécifications évoluant, le plus sûr est de finir par se référer à la doc officielle comme source primaire.
Les points clés de l'exploitation en production
La différence entre prototype et production réside dans le saut de « ça marche une fois » à « ça continue de marcher ». Une démo tient si elle réussit quelques fois ; la production est exposée chaque jour à des entrées massives et variées. Maîtrisons en 6 cases les points clés qui pèsent ici.
Gérer les clés par variables d'environnement, séparer configuration et code. Publier sous une forme reproductible (conteneur, etc.) et pouvoir revenir en arrière à tout moment.
Brancher l'observabilité du chapitre 5 en production. Surveiller en continu trace de chaque étape, taux de réussite et latence, pour repérer vite les anomalies.
Rendre visible la consommation de tokens, régler des alertes de plafond. Élaguer les réexécutions inutiles et les contextes trop longs, et doser les modèles selon l'usage.
Anticiper limites d'API et échecs temporaires, persévérer par backoff exponentiel (réessayer en espaçant). Éviter les nouvelles tentatives infinies, fixer un plafond.
Sauvegarder et restaurer en sécurité l'état intermédiaire de la conversation ou du travail. Une conception qui reprend là où elle s'est arrêtée soutient les tâches longues.
Les mises à jour de modèle ou de SDK : d'abord vérifier le comportement sur le jeu d'évaluation. Comparer avant/après pour ne pas manquer un changement de qualité silencieux.
⚠️ Le coût se décide « par la conception ». Comme un agent appelle le modèle plusieurs fois par tâche, sa structure fait vite bondir les coûts. Renvoyer les étapes qu'un modèle bon marché suffit à faire vers ce modèle, ne passer du contexte qu'en quantité nécessaire — ces efforts modestes paient. Pour des méthodes de réduction concrètes, L'optimisation des coûts du codage IA est pratique et s'applique tel quel à l'exploitation d'agents.
Concevoir pour ne pas s'effondrer
Un agent de production rencontrera un jour ou l'autre, inévitablement, une entrée imprévue, une panne d'API externe, un caprice du modèle. L'important n'est pas de « ne jamais échouer » mais de monter les choses de sorte qu'en cas d'échec les dégâts ne s'étendent pas et qu'il se rétablisse discrètement. Achevons les garde-fous du chapitre précédent en mécanisme d'exploitation.
Ne pas tout ouvrir d'un coup ; partir de quelques utilisateurs ou d'une fraction du trafic. Élargir si tout va bien, revenir aussitôt en arrière sinon.
Quand un outil ou un modèle ne répond pas, se replier sur un chemin alternatif ou une réponse par défaut sûre. Choisir la dégradation partielle plutôt que l'arrêt total.
Intercaler une confirmation humaine avant une opération irréversible ou à fort impact (voir chapitre 6). Fixer la limite où il faut préférer la sécurité à la vitesse.
Ce n'est pas fini une fois réussi. Les tendances des entrées et le modèle changent. Faire tourner régulièrement le jeu d'évaluation pour détecter la dégradation de qualité.
✅ Concevoir le « se répare discrètement ». Un bon système de production ne provoque pas de branle-bas quand un ennui survient. Le déploiement progressif garde l'impact petit, le repli assure une dégradation partielle, la porte de validation prévient le coup fatal, et la réévaluation devance la dégradation. Ce n'est que lorsque les quatre s'emboîtent qu'on « ne s'effondre pas ».
Apprendre pour la suite
Pour finir, un mot sur l'avenir proche. L'écosystème des agents — frameworks, SDK, modèles, standards de connexion — continuera de bouger à une vitesse folle. La solution optimale d'aujourd'hui ne le sera pas forcément l'an prochain. C'est justement pourquoi ce qu'il faut poursuivre, ce n'est pas le nom des outils à la mode, mais les fondamentaux qui ne changent pas.
📊 Ce qui devient un actif, ce sont les fondamentaux. Les 4 composants (cerveau, outils, mémoire, boucle) du chapitre 1, l'évaluation et l'observabilité du chapitre 5, la conception de sécurité du chapitre 6 — voilà un socle valable quel que soit le framework à la mode. À chaque nouvel outil, vous saurez déceler vite, avec cette règle de mesure, « ce qu'il abstrait ». Les outils passent, les fondamentaux restent. La compréhension bâtie jusqu'ici est votre premier actif.
Ensuite, aussi petit soit-il, mettez-en réellement un en production. Le faire tourner, mesurer, corriger — l'expérience de faire tourner cette boucle sur votre propre projet vaut mieux que n'importe quel support de cours.
- Tant que c'est petit, apprendre en faisant soi-même ; quand ça grandit, monter la productivité avec un framework. L'adopter non pour « la commodité » mais pour « réduire la duplication ».
- Choisir un framework sur 5 angles — abstraction, liberté, écosystème, observabilité, dépendance à l'éditeur. Une règle de mesure plutôt qu'un nom précis.
- Pour construire avec Claude : le Claude Agent SDK à boucle maison, ou les agents managés hébergés. Choisir entre contrôle et simplicité.
- Points clés de production : déploiement, supervision, coût, nouvelles tentatives, gestion d'état, mises à jour. Et ne pas s'effondrer grâce à déploiement progressif, repli, porte de validation, réévaluation.
- L'écosystème bouge vite. Ce sont les fondamentaux — 4 composants, évaluation, sécurité — qui deviennent un actif durable.
Bravo pour ces 7 chapitres. Vous avez parcouru tout le chemin — concevoir, construire, connecter, multiplier, mesurer, protéger et exploiter un agent. À partir d'ici, c'est à vous de mettre les mains dans votre propre produit.
Pour qui veut, en reculant d'un pas côté construction, affûter aussi le regard sur l'usage de l'IA au travail.
Vers la formation L'IA au travail →Pour qui veut maîtriser des outils de codage comme Claude Code.
Vers la formation Coder avec l'IA →Pour qui veut faire grandir l'agent construit en un produit de dev solo à lancer dans le monde.
Vers la formation Dev solo avec l'IA →