Du prototype à la production : concevoir des agents autonomes avec Agent DLC
Les équipes d'entreprise qui déploient des agents d'IA fondés sur des grands modèles de langage, capables d'appeler des outils, d'orchestrer des API et de répondre à des questions sur des connaissances internes, se heurtent à une question que la démonstration ne tranche pas : l'agent est-il prêt pour la production ? Dans un billet consacré à l'Agent Development Lifecycle (Agent DLC), AWS propose un cycle de vie à deux boucles, adossé à un standard explicite pour juger chaque modification. Ce standard, appelé « gold standard », désigne un ensemble de critères vérifiables, leurs seuils et les exemples approuvés par les responsables métier. Pour l'illustrer, les auteurs ont construit une implémentation de référence : un assistant interne répondant à des questions de politique RH à partir d'une base documentaire. Trois questions de référence y sont évaluées selon cinq mesures : ancrage des réponses dans les sources, précision des fragments récupérés au niveau du fragment entier puis au niveau de chaque fait, couverture de la récupération et précision de la réponse. Au premier tour, la précision au niveau du fragment vaut 1,00 pour les trois questions. Mais la précision au niveau des faits tombe à 0,59 pour l'évaluation de performance, 0,53 pour l'inscription aux avantages sociaux et 0,09 pour le certificat d'arrêt maladie. Cette dernière question échoue, avec un ancrage de 0,39 et une couverture de récupération nulle : environ neuf faits sur dix dans les documents récupérés n'ont aucun rapport avec la demande.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
L'enjeu est pratique. Une barrière de mise en production fondée uniquement sur la précision au niveau du fragment aurait validé les trois réponses, y compris celle dont aucun fragment récupéré ne répond réellement à la question. Le choix des métriques détermine donc ce que l'équipe voit, et un indicateur agrégé flatteur peut masquer un défaut de couverture. Pour les décideurs, cela signifie qu'une approbation doit reposer sur des preuves multiples et ventilées, et non sur un score unique. Les auteurs précisent que ces résultats proviennent d'une implémentation de référence, ni d'un cas client ni d'un benchmark, et que les scores peuvent varier d'une exécution à l'autre. Le dépôt AWS Samples associé fournit le déploiement de l'infrastructure, l'agent RH, des évaluateurs personnalisés et des scripts de référence (09-run-eval.sh et 10-optimize-prompt.sh), ainsi que des contrôles optionnels de répétabilité du juge, de comparaison de modèles, de coût et de latence.
Ce cadre répond au fait que les tests unitaires et les chaînes CI/CD, toujours nécessaires, ne suffisent plus face à trois propriétés des agents. D'abord, le non-déterminisme : des entrées identiques peuvent produire des sorties et des trajectoires différentes, d'où la recommandation d'exécuter chaque exemple k fois et de juger sur le taux de réussite et la distribution des échecs. Ensuite, les prompts, descriptions d'outils, paramètres de récupération et configurations de mémoire se comportent comme du code source, mais leur effet ne se lit pas dans le texte : chaque changement doit être versionné avec une évaluation attachée et un historique conservé. Enfin, les points d'accès aux modèles, les bases de connaissances et les API externes évoluent indépendamment du dépôt, ce que l'épinglage de versions ne détecte pas ; il faut donc rejouer le standard à intervalle régulier et alerter en cas d'écart par rapport à la référence. Cette approche s'inscrit dans le passage des agents de l'exploration à l'ingénierie en entreprise, où la reproductibilité et le coût de l'évaluation deviennent des critères de décision à part entière.
Les équipes européennes qui déploient des agents d'IA en entreprise peuvent s'appuyer sur ce cadre d'évaluation pour documenter la fiabilité de leurs systèmes avant leur mise en production.