La plupart des projets d’agents IA n’échouent pas parce que le prototype était mauvais. Ils échouent parce que l’équipe a choisi un framework qui fonctionnait bien dans un Jupyter notebook et a découvert ses lacunes trois mois après le début d’un build en production — quand le coût du changement est élevé et la pression de livraison encore plus forte.
LangGraph, CrewAI, AutoGen (désormais en mode maintenance — Microsoft redirige les nouveaux projets vers le Microsoft Agent Framework), Mastra, VoltAgent, Smolagents — chacun a une histoire légitime, une communauté grandissante et des démos convaincantes. Le problème, c’est que les démos ne sont pas la bonne unité d’évaluation. La bonne unité est : ce framework tiendra-t-il sous une charge réelle, face à de vrais scénarios d’échec, au sein d’une organisation qui doit auditer, gouverner et maintenir le système ?
Voici les huit critères que nous appliquons à chaque mission client avant de nous engager sur un framework. Parcourez-les et vous pourrez éliminer la plupart des candidats faibles en une après-midi.
Pourquoi la production readiness des frameworks est une discipline à part entière
Un modèle de langage qui appelle une fonction n’est pas un agent. Un agent est un système automatisé qui perçoit un état, choisit des actions, appelle des outils et itère — parfois pendant plusieurs minutes, parfois sur plusieurs étapes, parfois avec de l’argent ou des données en jeu. L’écart entre « ça fonctionne en démo » et « sûr à exécuter de façon autonome à grande échelle » est plus large que la plupart des équipes ne l’anticipent.
La production readiness couvre des aspects que les tutoriels ignorent : que se passe-t-il quand un appel LLM expire en plein milieu d’une boucle ? Qui audite les décisions de l’agent ? Où réside l’état de la conversation si le container plante ? Ce ne sont pas des cas limites — ce sont les conditions de fonctionnement normales de tout système qui tourne à volume.
La checklist en huit critères
1. Observabilité : pouvez-vous voir ce que l’agent a réellement fait ?
C’est le premier point à examiner, et le plus souvent sous-développé.
Un agent en production a besoin de traces structurées et exportables : des enregistrements au niveau de chaque étape montrant quel outil a été appelé avec quels arguments, ce que le LLM a retourné, combien de temps chaque étape a pris, et où la boucle a bifurqué. Sans cela, déboguer une défaillance devient de l’archéologie.
Questions à poser :
- Le framework émet-il nativement des traces compatibles OpenTelemetry, ou faut-il les ajouter manuellement ?
- Peut-on rejouer une exécution spécifique pour une analyse post-mortem ?
- Les comptages de tokens et la latence sont-ils suivis au niveau de l’étape ?
Les frameworks qui traitent le logging comme une réflexion après coup vous obligent à tout instrumenter vous-même — cela coûte généralement un sprint entier sur tout déploiement sérieux.
2. Gestion des erreurs : ce qui cède proprement et ce qui explose
Les appels LLM échouent. Les API retournent des erreurs de rate limit. Les outils lancent des exceptions. La question n’est pas de savoir si des défaillances surviennent, mais si le framework y répond de façon raisonnée.
Cherchez :
- Des politiques de retry avec un backoff configurable, distinguant les défaillances récupérables des défaillances terminales
- La reprise sur exécution partielle — un workflow interrompu peut-il reprendre depuis son dernier état valide, ou redémarre-t-il de zéro ?
- La propagation des erreurs des outils — l’agent reçoit-il un signal utile, ou entre-t-il silencieusement dans un état erroné ?
Un framework sans logique de retry et sans checkpointing d’état provoquera des incidents en production à 2h du matin.
3. Persistance de l’état et de la mémoire : qui détient le contexte ?
Les agents de démo sont sans état. Les agents réels ne le sont pas.
Pour tout ce qui s’étend sur plusieurs tours de conversation, sessions utilisateur ou tâches longues, vous devez comprendre exactement où réside l’état de l’agent :
- Est-il en mémoire dans le processus (perdu au redémarrage), dans une base de données ou dans un store externe ?
- Qui gère les migrations de schéma quand la forme de l’état de l’agent change ?
- L’état peut-il être inspecté et corrigé manuellement si un agent est bloqué ?
Certains frameworks utilisent par défaut un état en mémoire sans couche de persistance. C’est acceptable pour le prototypage. Pour un agent en contact avec les clients gérant des tickets de support ou des demandes commerciales, cela signifie perdre le contexte à chaque déploiement — ou construire une couche de persistance depuis zéro.
À noter : dans les architectures multi-agents, la coordination de l’état partagé devient un problème à part entière. Vérifiez si le framework propose un pattern documenté pour cela, ou si cela vous est entièrement délégué. Voir Orchestration d’agents IA : faire fonctionner les agents comme un système pour un traitement approfondi.
4. Outillage d’évaluation : comment savoir si le système s’améliore ?
C’est le critère qui sépare les équipes qui livrent des agents fiables de celles qui « le surveillent manuellement. »
Les agents en production ont besoin de tests de régression — la capacité d’exécuter une suite définie d’entrées et de vérifier que les sorties respectent un niveau de qualité. Cela s’appelle les evals, et c’est loin d’être trivial à construire de zéro.
Demandez :
- Le framework fournit-il des outils d’eval, ou suppose-t-il que vous intégrerez un outil externe ?
- Peut-on exécuter des evals localement avant un déploiement ?
- Existe-t-il un format de dataset pour capturer de bons/mauvais exemples issus de la production et les réintégrer dans les tests ?
Sans infrastructure d’eval, chaque mise à jour du framework ou modification de prompt devient un coup de dé. Voir Tester les agents IA : comment les evals maintiennent la fiabilité de l’automatisation pour un traitement approfondi.
5. Posture de sécurité : exécution des outils et injection de prompt
Les agents exécutent du code, appellent des API et écrivent dans des bases de données. La surface d’attaque est fondamentalement différente de celle d’un chatbot.
Points critiques à vérifier :
- Permissions des outils — peut-on restreindre quels outils un agent peut appeler selon le contexte ou le rôle ? Ou chaque outil dispose-t-il du même niveau d’accès ?
- Sanitisation des entrées — existe-t-il une protection contre les attaques par injection de prompt, où un contenu hostile dans un document récupéré détourne le comportement de l’agent ?
- Gestion des secrets — les clés API et les identifiants sont-ils gérés au niveau du framework, ou chaque développeur les gère-t-il de façon ad hoc ?
Un framework sans concept de permissions au niveau des outils n’est pas adapté à un workflow où un agent touche des données clients ou des systèmes externes avec accès en écriture.
6. Hooks de gouvernance : l’humain dans la boucle quand c’est nécessaire
Toutes les décisions ne devraient pas être autonomes. Votre équipe de gouvernance — et à terme les régulateurs — voudra des points documentés où un humain pourrait intervenir ou réviser.
Cherchez :
- Des mécanismes d’interruption/pause — l’agent peut-il soumettre une décision à un opérateur humain avant d’entreprendre une action au-dessus d’un seuil de risque défini ?
- Des workflows d’approbation — existe-t-il un pattern intégré pour la validation humaine sur des appels d’outils spécifiques (ex. envoyer un email, émettre un remboursement) ?
- Un journal d’audit — existe-t-il un enregistrement immuable de ce que l’agent a décidé et pourquoi, avec une granularité suffisante pour un examen de conformité ?
La gouvernance est de plus en plus une exigence contractuelle pour les clients enterprise et une obligation réglementaire concrète sous l’EU AI Act, en vigueur depuis août 2024 avec plusieurs tranches déjà contraignantes. Voir Gouvernance des agents IA : un guide pratique pour les PME pour le tableau d’ensemble.
7. Santé de la communauté et trajectoire de maintenance
Les frameworks open source ne sont durables qu’autant que les communautés qui les soutiennent. Avant de vous engager, vérifiez :
- La fréquence des commits — le dépôt est-il activement maintenu ou perd-il de l’élan ?
- Le temps de réponse aux issues — combien de temps avant qu’un mainteneur accuse réception d’un rapport de bug ?
- La politique sur les breaking changes — le projet documente-t-il la stabilité de l’API et les chemins de migration ?
- La dépendance au sponsor — s’agit-il d’un projet mono-entreprise où un pivot stratégique peut mettre fin au support ?
Un framework qui était en vogue sur GitHub il y a six mois avec une vélocité de contribution en baisse est un risque à intégrer avant de dépenser des mois de temps d’ingénierie dessus.
8. Coût de sortie : à quoi ressemblerait une migration ?
C’est la question que presque personne ne pose lors de la sélection et que tout le monde pose dix-huit mois plus tard.
Si vous devez quitter ce framework — parce qu’il n’est plus maintenu, parce que vos besoins l’ont dépassé, ou parce qu’une meilleure option est apparue — quel en est le coût ?
Considérez :
- Quelle part de votre logique métier est dans des constructs spécifiques au framework plutôt qu’en Python/TypeScript portable ?
- Vos définitions d’outils sont-elles réutilisables en dehors du framework ?
- Le schéma d’état de votre agent est-il dans un format que vous maîtrisez, ou est-il opaque au framework ?
Les frameworks avec une haute abstraction et des internals opaques tendent à avoir des coûts de sortie élevés. Ce n’est pas automatiquement rédhibitoire, mais cela devrait être intégré dans le calcul. Voir Lock-in des plateformes agents IA : les risques que personne ne chiffre pour un traitement détaillé.
Comment évaluer rapidement un framework
Appliquez chaque critère sur une échelle à trois points :
| Score | Signification |
|---|---|
| 2 | Natif, documenté, fonctionne directement |
| 1 | Possible avec une intégration ou du code personnalisé |
| 0 | Absent — vous le construisez vous-même |
Un total inférieur à 10 sur 16 est un signal d’alerte. En dessous de 8, c’est un refus ferme pour tout ce qui est orienté client ou sensible à la conformité. Les zéros spécifiques comptent plus que le total — un zéro sur la posture de sécurité est un bloquant quelle que soit la note globale.
À quoi ressemble concrètement une session de vetting de framework
Appliquez les huit critères à votre shortlist lors d’une session structurée. Deux frameworks sont éliminés rapidement parce qu’ils manquent de mécanismes d’interruption/approbation. L’un obtient un bon score sur la gouvernance mais a un historique de maintenance mince — il est signalé comme risque de dépendance. Le candidat restant atteint 13/16 avec un chemin de migration clair. C’est sur lui qu’on construit.
Les critères sont les mêmes quelle que soit la composition de votre shortlist. Pour un contexte plus large sur ce qui passe généralement la sélection, voir Choisir un framework open source pour agents IA : la shortlist du CTO et CrewAI vs LangGraph : choisir le bon framework agent.
Quand faire appel à un regard extérieur
Si votre équipe est sur le point d’engager un budget sur un framework d’agents sans évaluation structurée, c’est le moment où l’effet de levier d’une expertise externe est le plus fort. Le choix du framework influence votre posture de sécurité, votre documentation de conformité, votre charge opérationnelle et votre coût futur de migration — pas seulement votre vélocité de sprint.
Chez Orange ITS, cette évaluation fait partie de chaque engagement de développement d’agents IA. Nous avons vu des frameworks qui semblent excellents en démo et s’effondrent sous une charge réelle, et des frameworks qui démarrent en douceur mais restent solides à grande échelle. Cette reconnaissance de patterns, c’est ce qu’apporte un bon partenaire d’évaluation.
Prêt à mettre votre shortlist de frameworks à l’épreuve avant le début du build ? Réservez un appel de 30 minutes avec Orange ITS — nous évaluerons vos candidats selon ces critères et vous dirons honnêtement lesquels nous utiliserions pour construire.