Évaluation et optimisation des agents : comparaison de DSPy, TextGrad, Reflexion et OPRO

Les équipes n’adoptent que rarement directement une évaluation et une optimisation automatisées des agents. La démarche habituelle est progressive : on commence par une instruction astucieuse et quelques expériences ponctuelles, puis des mesures reproductibles, suivies d’un ajustement ciblé, et enfin une confiance suffisante pour déployer les modifications sous contrôle.

Cela commence généralement par un agent disposant d’une instruction système solide, de quelques outils et d’une démonstration impressionnante. C’est un bon point de départ, mais cela ne suffit pas à long terme. À mesure que davantage de personnes dépendent de l’agent, les questions deviennent plus pratiques : quels flux de travail tiennent le choc et lesquels échouent à grande échelle ? Que se passe-t-il avec le comportement de l’agent lorsque le modèle sous-jacent est mis à jour ? L’agent performe-t-il bien sur les cas les plus importants pour les opérations, le contrôle des risques ou les clients ?

L’ingénierie des prompts est une première compétence précieuse, mais la maturité provient du fait d’insérer l’agent dans un cycle d’amélioration structuré. Un agent qui peut être évalué de manière systématique peut être amélioré de la même façon, et un agent qui peut être amélioré systématiquement peut être géré avec beaucoup plus de confiance. Ainsi, le véritable avantage dépasse les simples prompts améliorés : il s’agit d’un cycle d’apprentissage contrôlé pour les systèmes de modèles linguistiques — définir ce qu’est la qualité, mesurer le comportement en fonction de cette définition, appliquer une optimisation ciblée, et conserver suffisamment d’informations pour avoir confiance dans les résultats.

Cinq approches partagent cette idée : DSPy avec ses optimiseurs MIPRO et COPRO, TextGrad, Reflexion et OPRO. Leurs mécanismes, leur niveau de maturité et leur adaptabilité opérationnelle diffèrent, mais chacune répond à une même question : comment un agent peut-il passer de la modification manuelle des prompts à des améliorations répétables basées sur des métriques ?

L’évaluation occupe le centre de chaque cycle

La manière la plus simple de considérer ces méthodes comme une même famille est de les voir comme des recherches différentes portant sur le comportement de l’agent. Toutes supposent les mêmes quatre éléments.

• Quelque chose de modifiable : un programme d’agent, une instruction, un flux de travail ou une politique de décision.
• Un ensemble de tâches, un ensemble d’évaluation, qui représente ce que l’agent doit faire.
• Un critère d’évaluation, qu’il s’agisse d’une métrique, d’une grille de notation, d’une récompense ou d’une règle de succès, permettant de distinguer les meilleurs résultats des moins bons.
• Un optimiseur, explicite ou implicite, qui propose des modifications en fonction des scores obtenus précédemment.

Vues de cette façon, ces techniques concernent davantage l’optimisation en boucle fermée que les instructions à donner à l’agent. Au sein d’une entreprise, créer une instruction améliorée n’est que rarement la partie difficile. Trouver un moyen reproductible d’améliorer le comportement dans de nombreuses tâches l’est, car chaque avantage a un coût ailleurs :

• précision par rapport à la latence

qualité par rapport aux coûts

couverture contre le surajustement

autonomie par rapport au contrôle

généralité étendue par rapport à un ajustement spécifique à la tâche

une amélioration locale par rapport à la fiabilité du système dans son ensemble

Ces bibliothèques doivent donc être considérées comme des positions au sein d’un espace de conception visant à améliorer les agents, et non comme des astuces concurrentes pour générer des réponses.

Pourquoi la pression augmente

Les premiers projets d’agents dans les entreprises reposent généralement sur l’intuition des experts. Un professionnel qualifié réécrit les instructions, ajuste les descriptions des outils, ajoute des exemples et refait des tests jusqu’à ce que le résultat paraisse acceptable. Pour un ou deux cas d’usage, cela suffit.

Cela échoue lorsque plusieurs équipes développent des agents en même temps, lorsque les prompts varient d’un environnement à l’autre, lorsque les données d’évaluation se retrouvent dispersées, lorsque les équipes ont des définitions différentes de la qualité, lorsque la mise à jour d’un modèle modifie le comportement de manière imprévisible, ou lorsque les traces d’audit et le niveau de confiance des versions acquièrent de l’importance réelle.

Alors, une discipline similaire aux MLOps est nécessaire, adaptée aux systèmes basés sur des modèles de langage. Les tests logiciels ordinaires sont indispensables mais insuffisants, et l’évaluation classique des modèles d’apprentissage automatique est utile sans couvrir tous les aspects. Les agents ajoutent leurs propres éléments dynamiques : prompts, appels d’outils, comportements de récupération, structures de planification, mémoire, tentatives de réessai et sensibilité au modèle spécifique. L’évaluation et l’optimisation automatisées fournissent des outils pratiques pour maîtriser cette variabilité.

Les quatre techniques principales

DSPy avec MIPRO et COPRO : optimisation du programme

Parmi ces outils, DSPy va le plus loin en rendant le comportement des modèles programmable plutôt que improvisé. Les prompts ne sont plus de simples chaînes de caractères, et les pipelines sont déclarés de manière structurée, ce qui offre une base solide sur laquelle travailler pour améliorer les performances.

MIPRO et COPRO sont les optimiseurs automatisés de cet écosystème. MIPRO ajuste les prompts, les instructions et les démonstrations à quelques exemples en fonction d’une métrique, et convient aux équipes dont la définition des tâches est assez stable et qui souhaitent que des recherches trouvent des paramétrages de prompts meilleurs que ceux qu’un humain pourrait choisir manuellement. COPRO affine les prompts et les programmes selon des principes similaires. L’idée fondamentale est commune : le programme devient un objet qui peut être compilé, ajusté et réévalué, et non simplement modifié manuellement.

Dans la pratique, cela permet une compilation automatique des prompts, un choix d’exemples de type few-shot, un ajustement des instructions, une amélioration guidée par des métriques, ainsi qu’une séparation plus claire entre la logique de la tâche et le prompt finalement optimisé. Les avantages sont la reproductibilité, une base plus solide pour l’évaluation hors ligne, une moindre dépendance à la création manuelle des prompts, et une optimisation qui ressemble davantage à de l’ingénierie qu’à une pratique empirique.

Pour une entreprise souhaitant disposer d’un processus d’optimisation interne sérieux plutôt que d’une pile de prompts créés manuellement, DSPy fait partie des solutions les plus pertinentes, en particulier pour les tâches qui s’adaptent à des modules reproductibles et à des métriques stables. Cependant, il présente une limite : il fonctionne le mieux lorsque la tâche est suffisamment structurée pour que des ensembles d’évaluation guident la recherche, et il n’est pas aussi miraculeux qu’il en a l’air. Avec un signal faible, partiel ou mal aligné, l’optimiseur ne fait que s’améliorer dans la mauvaise direction.

TextGrad : la critique en tant que gradient

TextGrad emprunte une approche plus audacieuse. Au lieu de gradients numériques, il s’appuie sur des critiques écrites et des signaux d’actualisation pour améliorer les prompts ainsi que les composants similaires aux prompts. La logique est élégante : si un modèle peut indiquer ce qui ne va pas dans une sortie et comment y remédier, ces commentaires peuvent servir de signal d’optimisation.

Il permet un affinage répété du texte du prompt, des mises à jour de type optimiseur, ainsi que le travail sur des prompts système, des grilles d’évaluation, des plans ou même des instructions d’évaluation. L’optimisation devient ainsi un processus itératif plutôt qu’une recherche unique. Il convient aux cas où les retours appropriés sont plus faciles à exprimer en mots qu’en chiffres, et il peut améliorer à la fois la grille d’évaluation de l’évaluateur et le prompt de la tâche.

Il convient de le considérer comme une solution primitive prometteuse et non comme une réponse finale pour les entreprises. Il est utile lorsque les équipes souhaitent affiner les instructions, les plans et les critères d’évaluation grâce à des retours basés sur le langage, mais il ne constitue pas une solution par défaut évidente à l’échelle de toute l’organisation. Sa principale force est également son principal danger : le signal d’actualisation est lui-même du langage, généré par un modèle. Sans un mécanisme d’évaluation structuré, cela peut rendre l’optimisation moins stable, moins interprétable et plus difficile à auditer.

Réflexion : apprendre des échecs

Réflexion diffère des deux méthodes précédentes. La compilation hors ligne des instructions n’en est pas le point central. Il s’agit d’une amélioration continue en temps réel, motivée par la réflexion sur les échecs. Après une tentative infructueuse, l’agent rédige une critique, et cette réflexion mémorisée guide les tentatives ultérieures. Le résultat est un cycle d’apprentissage simple qui ne nécessite pas de retouche du modèle.

Celui-ci permet de réessayer en s’auto-critiquant, en se souvenant des modes d’échec antérieurs, en corrigeant la trajectoire de l’agent et en s’adaptant au cours des tentatives. De nombreux problèmes liés aux agents ne sont pas du tout des problèmes de réponse immédiate ; ce sont des problèmes d’exécution, tels que des étapes de raisonnement insuffisantes, un usage incorrect des outils ou des vérifications omises, et la réflexion aide à se remettre de ces problèmes. Il rapproche également l’apprentissage des conditions opérationnelles réelles plus que ne le peuvent seuls les benchmarks hors ligne.

Pour les agents qui fonctionnent comme des flux de travail plutôt que comme des générateurs à interaction unique, la réflexion est très pertinente, surtout lorsque les tentatives de correction sont possibles et que l’identification des schémas d’échec récurrents apporte de la valeur. Elle se manifeste généralement sous forme de schéma implémenté en code, et non comme une bibliothèque unique, ce qui oblige une entreprise à la considérer comme un modèle de conception à standardiser au sein de sa couche d’orchestration, et non comme une décision imposée par un fournisseur. Le risque réside dans le bruit : une autocritique sans limite entraîne des retards, des coûts supplémentaires et de l’incohérence. La réflexion doit être guidée par des politiques, déclenchée de manière sélective et évaluée comme n’importe quel autre comportement.

OPRO : un modèle en tant qu’optimiseur

OPRO, abréviation de Optimization by PROmpting, fait du modèle linguistique l’optimiseur. Il propose de meilleurs candidats pour les prompts en s’appuyant sur l’historique des scores précédents, permettant ainsi à un modèle de rechercher parmi les instructions adaptées pour un autre modèle ou programme.

Celui-ci couvre la recherche rapide, la génération et le classement de candidats, ainsi que l’amélioration itérative. Sa logique repose sur le fait que les modèles de langage sont doués pour proposer des formulations alternatives, ce qui permet d’obtenir rapidement un espace de recherche diversifié et d’adapter cette approche à de nombreux types de tâches.

OPRO présente un intérêt stratégique, bien qu’il appartienne souvent plus au kit d’outils expérimentaux qu’à la pile de plateformes par défaut. On le trouve généralement dans du code de type recherche ou des boucles personnalisées, et non dans une bibliothèque de production standardisée. Son utilisation optimale pourrait consister en un composant de recherche contrôlée au sein d’un service d’optimisation plus large, et non en une primitive autonome proposée directement aux développeurs.

Deux manières de trier les options

Ces techniques peuvent être organisées selon deux axes : l’endroit où a lieu l’optimisation et ce qui est optimisé.

Par emplacement :

• L’optimisation hors ligne couvre DSPy avec MIPRO et COPRO, TextGrad et OPRO.
• L’adaptation en temps de exécution ou par épisode est le domaine de Reflexion.
• Une utilisation hybride est également possible, puisque les signaux issus des exécutions de Reflexion peuvent être collectés hors ligne et intégrés dans des boucles de type DSPy-, TextGrad- ou OPRO.

Par cible :

• Le texte de l’instruction et les directives sont gérés par MIPRO, COPRO, TextGrad et OPRO.
• Les exemples à faible quantité d’exemples sont ajustés par MIPRO et COPRO.
• La structure du programme et les composants de la chaîne de traitement relèvent de l’écosystème plus large de DSPy.
• Les trajectoires d’exécution et la récupération en cas d’erreur relèvent du domaine de Reflexion.

Le schéma commun à ces deux tableaux est que ces méthodes se complètent mutuellement, à condition qu’elles fassent partie de l’architecture de contrôle appropriée.

Poursuivez les mesures et les améliorations en tant que couches distinctes

La plus coûteuse des erreurs architecturales consiste à adopter l’optimisation avant l’existence d’une pratique d’évaluation fiable. Avec une évaluation insuffisante, l’optimisation devient dangereuse, car l’outil d’optimisation améliorera tout proxy qui lui est fourni, y compris ceux qui n’ont aucun rapport avec la véritable valeur commerciale. Une conception solide sépare ces deux niveaux.

Le cadre d’évaluation définit et exécute les mesures. Il doit contenir des ensembles de données de référence et des tâches représentatives, des métriques et des critères spécifiques à chaque tâche, des traces des trajectoires des agents, des indicateurs de coût, de latence et de fiabilité, une analyse au niveau des sous-populations ou des modes de défaillance importants, ainsi que des points de validation avec détection des régressions.

Le tissu d’optimisation prend en compte les résultats d’évaluation et propose puis valide des améliorations. Son champ d’action comprend l’ajustement des prompts, le choix des exemples, la définition de politiques de réflexion en temps de exécution, la génération et la recherche de candidats potentiels, le suivi parallèle des expériences, ainsi que des règles de promotion qui déterminent quand un candidat prometteur devient la version par défaut approuvée.

Cette séparation est importante car l’évaluation constitue une capacité de gouvernance tandis que l’optimisation est un mécanisme de changement. Une entreprise a besoin des deux, et les confondre est une erreur.

Une liste restreinte

Dans le cadre d’une stack d’entreprise pratique, contrairement à une approche académique, la liste des candidats doit être fortement réduite. Toute idée de recherche prometteuse ne mérite pas forcément d’être une dépendance de premier plan pour la plateforme.

DSPy en tant que cadre d’optimisation principal. Il offre la structure la plus solide pour traiter les programmes de modèles comme des artefacts pouvant être optimisés. MIPRO et COPRO correspondent directement à un ajustement pratique des prompts et des exemples, et toute cette approche convient mieux aux workflows internes reproductibles qu’aux prompts ad hoc. Son rôle est d’être le moteur par défaut pour les tâches stables, la base pour la compilation hors ligne des prompts, ainsi que l’abstraction principale pour les équipes souhaitant obtenir des améliorations reproductibles basées sur des métriques.

La réflexion en tant que pattern de temps de exécution standard. Il n’est pas nécessaire qu’il s’agisse d’une dépendance indépendante. Il vise un problème différent de DSPy, à savoir la récupération pendant l’exécution, et il aide les agents utilisant des outils ainsi que les workflows à plusieurs étapes. Il s’intègre dans des couches d’orchestration telles que LangGraph ou des exécuteurs Python classiques. Son rôle : une politique de tentative répétée sélective accompagnée de réflexion pour les agents de workflow, une source de données structurées sur les échecs permettant des ajustements ultérieurs hors ligne, et une méthode standard pour effectuer une autocorrection ciblée.

TextGrad en tant qu’option avancée et expérimentale. Il propose un primitif de refinement innovant adapté aux prompts, aux grilles d’évaluation ou aux plans qui bénéficient d’une itération guidée par des critiques. Il est préférable de l’ajouter une fois qu’un outil d’évaluation stable existe. Son rôle est d’être un outil spécialisé destiné aux équipes d’optimisation, utilisé lorsque les retours écrits sont plus riches qu’un simple score.

OPRO, priorité plus faible en tant que norme de plateforme. Il est souvent préférable en tant que mode d’optimisation interne plutôt qu’en tant que choix de bibliothèque centrale. Beaucoup de ses idées peuvent être reproduites à l’aide de boucles de recherche personnalisées autour d’un cadre d’évaluation plus solide, et il ne constitue pas un choix par défaut naturel pour les développeurs ordinaires. S’il est utilisé, il devrait servir de stratégie de recherche au sein d’un service d’optimisation central, ou comme outil d’expérimentation pour les équipes de plateforme.

Sur quoi construire

Les développeurs ne devraient pas avoir à assembler ces techniques à partir de bibliothèques brutes pour chaque projet. La plupart des équipes n’ont pas besoin de cinq paradigmes d’optimisation au niveau de l’application. Elles ont besoin d’un framework interne plus simple qui définit, mesure, améliore et favorise la qualité des agents. La solution la plus judicieuse consiste en une plateforme interne légère mais bien structurée, construite à partir d’un ensemble sélectif de bibliothèques. Celle-ci doit cacher la complexité accidentelle tout en standardisant les contrôles importants.

1. Un SDK d’évaluation. Une méthode commune pour définir les tâches des agents, les ensembles de données et les métriques. Il standardise le schéma des cas de test, les résultats attendus ou les grilles d’évaluation, le format du journalisation des traces, la capture des coûts et de la latence, la versionnement des ensembles de données ainsi que les lignes de base pour les tests de régression. L’objectif : une équipe peut décrire son agent, son ensemble d’évaluation et sa mesure de succès sans avoir à écrire un outil personnalisé.

Un service d’optimisation. Un service contrôlé exécute des tâches d’optimisation afin que les équipes n’aient pas à mettre en place leurs propres boucles. Il prend en charge l’ajustement des prompts et des exemples basé sur DSPy, un affinage optionnel via TextGrad, une recherche inspirée d’OPRO, la comparaison d’expériences avec des rapports au format classement, ainsi que des workflows d’approbation des candidats. Un développeur peut demander l’ajustement d’un agent sur une version de dataset fixée, dans le respect de limites définies en termes de temps de réponse et de coûts, et recevoir des candidats pouvant être comparés directement.

Une couche de politique de réflexion en temps de exécution. Le comportement similaire à la réflexion devient une configuration plutôt qu’un code personnalisé dans chaque agent. Les politiques déterminent quand les tentatives de réessai sont autorisées, quand la réflexion s’active, combien de tentatives sont permises, quelles informations sur les échecs précédents doivent être conservées, et quand il convient de faire appel à un humain ou à un flux de travail de secours. Les équipes disposent ainsi d’une auto-correction encadrée grâce à des modèles, évitant de devoir créer eux-mêmes une logique de réessai incohérente.

Un registre des prompts et des politiques. Les prompts, les critères d’évaluation et les artefacts d’optimisation sont considérés comme des actifs gérés : stockage versionné, traçabilité du prompt jusqu’à l’expérience puis à la mise en production, notes sur la compatibilité avec les modèles, support de rollback et archives d’approbation pour les variantes en production. Les prompts fonctionnent alors comme des configurations déployables, et non comme du texte copié entre des notebooks ou des répertoires.

Intégration au plan de contrôle de l’entreprise. Le framework se connecte aux points de contrôle CI/CD, aux outils d’observabilité, aux catalogues de modèles, à la gestion des secrets et des environnements, aux contrôles de gouvernance des données ainsi qu’aux workflows d’approbation pour les utilisations à haut risque. Cette connexion permet de distinguer une bibliothèque technique d’une capacité d’entreprise.

Pour la plupart des développeurs, cela se résume à quatre idées : définir le contrat de l’agent, fournir des cas d’évaluation, choisir un mode d’optimisation, et examiner le candidat retenu avec son rapport de déploiement. Au fond, n’importe laquelle des quatre techniques peut être utilisée, mais ce que voient les développeurs doit rester simple. Le problème de l’échelle n’est que rarement dû à un manque d’algorithmes ; il provient plutôt de la dispersion de boucles d’amélioration sur mesure et incohérentes au sein des équipes.

Un déploiement en étapes

Étape un : évaluation de la discipline. Avant toute optimisation approfondie, mettez en place des schémas d’évaluation partagés, des ensembles de données de référence soigneusement sélectionnés, un système de capture et de rejouement des trajectoires, ainsi que des valeurs de référence pour le coût, la latence et la qualité des tâches.

Étape deux : optimisation hors ligne avec DSPy. Faites de DSPy, associé à MIPRO et COPRO, l’outil principal pour les classes de tâches stables, en couvrant la compilation des instructions, le choix des exemples, l’ajustement des directives et une comparaison reproductible des expériences.

Étape trois : réflexion pendant l’exécution avec des contraintes. Intégrez des politiques de type Reflexion pour les agents dont les échecs peuvent souvent être corrigés par des tentatives répétées accompagnées d’analyses critiques, des tentatives sélectives, une mémoire de réflexion structurée et des diagnostics au niveau de la trajectoire.

Étape quatre : modes avancés, avec prudence. Ajoutez TextGrad et des recherches similaires à OPRO uniquement lorsque c’est vraiment nécessaire et que l’évaluation est suffisamment mature pour les gérer. Cela devrait généralement rester une fonctionnalité réservée aux équipes de plateforme avant d’être mise à disposition des développeurs en général.

Où cela échoue

• Surajustement des métriques. Un benchmark étroit ou obsolète apprend à l’optimiseur ce dernier plutôt que la tâche réelle.
• Rubriques fragiles. Si l’évaluation repose sur des juges de modèle faibles ou incohérents, l’optimisation suit les particularités de ces évaluateurs.
• Gains locaux, pertes globales. Ajuster une sous-tâche peut augmenter discrètement les coûts ou ralentir d’autres étapes, ou modifier le comportement du reste du flux de travail.
• Réflexion bruyante. Une réflexion sans contraintes de politique génère plus de tokens et plus de retards pour un gain réel minime.

Fragmentation organisationnelle. Lorsque chaque équipe choisit ses propres bibliothèques d’optimisation et conventions d’évaluation, l’entreprise perd la capacité de comparaison et le contrôle.

Tout cela mène à la même conclusion : l’optimisation n’est aussi efficace que les méthodes d’évaluation et de gouvernance qui l’entourent.

La forme de la solution

Ce qui unit DSPy, MIPRO, COPRO, TextGrad, Reflexion et OPRO, ce n’est pas le fait que chacun améliore les prompts. Chacun cherche à transformer l’amélioration des agents en un système de feedback. La démarche stratégique consiste non pas à exposer chaque idée à tous les développeurs, mais à créer un cadre interne contrôlé où l’évaluation est standardisée, l’optimisation est sélective, la réflexion en temps de exécution suit des politiques définies, et les variantes de prompts sont gérées comme des actifs de production.

Pour une recommandation plus précise, la meilleure approche consiste à laisser DSPy, associé à MIPRO et COPRO, gérer l’optimisation hors ligne, à adopter Reflexion comme modèle de temps de exécution partagé pour une autocorrection contrôlée, à réserver TextGrad aux équipes spécialisées, et à considérer OPRO principalement comme une technique de recherche interne plutôt que comme une dépendance destinée aux développeurs. Les agents les plus performants au sein des entreprises seront déterminés par la qualité du cycle de feedback qui les entoure, la ruse immédiate ayant beaucoup moins d’importance.