De la modification des prompts aux boucles de rétroaction : DSPy, GEPA et Claude Code

Pendant des années, la solution par défaut pour un résultat médiocre d’un LLM était simple : modifier le prompt et réessayer. Avec les systèmes agents, le prompt n’est souvent pas l’élément qui nécessite des ajustements.

Imaginez un bug en environnement de production qui ne se manifeste qu’après un changement de configuration. Transmettez-le à deux systèmes d’IA différents. Le premier obtient le traceur d’erreurs ainsi qu’une instruction soigneusement formulée et fournit un correctif. Le second peut ouvrir le répertoire de code, lire les règles du projet, reproduire l’erreur, modifier le code, exécuter les tests, identifier ce qui a causé le problème et recommencer le processus.

Le modèle est important dans les deux cas. Ce que possède le deuxième système et que n’a pas le premier, c’est un cycle de feedback exécutable.

Lorsque ce cycle existe, la formulation des prompts n’est plus qu’un des nombreux paramètres à ajuster. Vous pouvez également modifier la manière dont la tâche est divisée, ce qui est récupéré, quels outils sont disponibles, les exemples, les procédures de vérification, les règles de tentative répétée, le mode de mise en sandbox de l’exécution, ainsi que l’outil d’évaluation qui détermine si le travail est effectivement correct.

C’est le fil conducteur qui relie la recherche de Stanford sur DSPy, MIPRO, STORM et GEPA aux travaux en production d’Anthropic sur Claude Code et le Model Context Protocol. Il ne s’agit pas d’une seule architecture ; l’idée commune qui les unit est la suivante : l’ingénierie de l’IA évolue en passant du simple affinage d’un prompt à la création de systèmes capables d’agir, d’évaluer les résultats et d’améliorer le programme associé au modèle.

Le prompt n’est plus qu’un paramètre

Une application à utilisation unique dispose de très peu de paramètres de contrôle :

Task → Prompt → Model → Result

C’est acceptable pour des tâches simples et bien délimitées. Le système devient fragile dès que la tâche nécessite plusieurs étapes, des informations externes, des effets secondaires réels, des vérifications, ou une récupération suite à une mauvaise décision en cours de route.

Un système conçu pour le environnement de production ressemble plutôt à ceci :

 Task
  ↓
Program / Planner
  ↓
Context + Retrieval
  ↓
Tools + Environment
  ↓
Execution Trace
  ↓
Evaluator
  ↓
Retry, Repair, or Optimize
  ↓
Result

Un résultat médiocre peut avoir de nombreuses causes possibles. Le modèle pourrait ne pas être suffisamment puissant. La récupération des informations a pu sélectionner le mauvais contexte. Le planificateur a peut-être mal divisé les tâches. Un outil a pu fournir des données obsolètes. Le vérificateur a peut-être accepté une réponse invalide. Ou bien les instructions ont réellement besoin d’être corrigées.

Ainsi, l’ingénierie des prompts ne disparaît pas ; elle devient simplement une partie d’un problème plus large de débogage et d’optimisation.

DSPy : rendre le programme explicite

La première grande idée de DSPy a été de cesser de considérer un pipeline de LM comme un ensemble de chaînes de prompts ajustées manuellement. Le papier original modélise les applications LM comme des graphes computationnels de modules déclaratifs et ajoute un compilateur qui optimise ces modules en fonction d’une métrique. La documentation actuelle l’exprime plus simplement : définir des signatures et des modules structurés, fournir des exemples ainsi qu’une fonction de notation, puis compiler le programme au lieu d’ajuster manuellement chaque prompt.

Un petit programme DSPy ressemble à ceci :

import dspy

class Diagnose(dspy.Signature):
    """Identify the most likely root cause from an issue and repository evidence."""
    issue: str = dspy.InputField()
    evidence: str = dspy.InputField()
    diagnosis: str = dspy.OutputField()

program = dspy.ChainOfThought(Diagnose)

optimizer = dspy.GEPA(
    metric=score_diagnosis,
    auto="medium",
)

optimized = optimizer.compile(
    program,
    trainset=historical_incidents,
)

La syntaxe n’est pas l’essentiel. Ce qui compte, c’est que quatre éléments qui étaient normalement mélangés dans une seule instruction sont désormais séparés : ce que la tâche doit produire, la manière dont elle est exécutée, les exemples qui la guident, et la façon dont le succès est évalué.

Cela change le travail de l’ingénieur. Au lieu de gaspiller tout le budget d’itération à débattre du fait que « être concis » devrait devenir « réfléchir soigneusement avant de répondre », on peut poser une question plus pertinente : quel comportement doit s’améliorer, et comment allez-vous le mesurer ?

Sans une métrique significative, l’optimisation automatique ne fait que rendre le système meilleur pour le mauvais objectif.

MIPRO : ajuster de nombreuses étapes relève d’un problème de recherche

Les choses deviennent plus complexes lorsque le programme comporte plusieurs modules. Prenons un processus de correction de bogues incluant le diagnostic, la génération de correctifs et leur revue, où le test final échoue. Quel module en est la cause ? Quelle instruction doit être modifiée ? L’un des exemples utilisés est-il trompeur ? Une étape de diagnostic améliorée pourrait-elle nuire à la génération des correctifs ?

Il s’agit d’un problème d’affectation de crédits, et c’est précisément ce que vise MIPRO. La publication sur MIPRO va au-delà de la simple modification d’une seule instruction. Elle ajuste conjointement les instructions écrites et les exemples utilisés dans chaque module, en combinant des propositions d’instructions tenant compte à la fois du programme et des données, des évaluations sur de petits ensembles de données, ainsi qu’un modèle de substitution qui oriente la recherche vers des combinaisons prometteuses.

En résumé :

Bootstrap useful demonstrations
          ↓
Propose task-grounded instructions
          ↓
Search instruction + demo combinations
          ↓
Evaluate the whole program

Avec Llama-3-8B, l’optimiseur a surpassé ses références sur cinq des sept programmes à plusieurs étapes, le meilleur résultat atteignant une amélioration de 13 % selon la métrique d’exactitude indiquée.

C’est une affirmation moins forte que « les prompts automatiques surpassent les humains ». La leçon principale est de nature structurelle : une fois que les instructions et les démonstrations deviennent des paramètres d’un programme à plusieurs étapes, son amélioration consiste en une recherche au sein du système plutôt qu’en une simple tâche d’écriture d’une seule chaîne de texte.

STORM : la structure précède l’optimisation

Aucun optimiseur ne peut sauver un flux de travail mal conçu. STORM de Stanford en est un bon exemple, car son focus porte sur la manière dont le processus est organisé, et non sur le prompt le plus efficace.

Un seul modèle qui effectue toutes les recherches et toute la rédaction en une seule fois représente la version naïve ; STORM sépare la phase de préparation en étapes distinctes. Il cherche différentes perspectives sur le sujet, les utilise pour formuler des questions fondées sur des sources, organise ce qu’il a recueilli en un plan, et n’écrivait qu’ensuite.

Par rapport à une méthode de récupération basée sur un plan, l’étude indique une amélioration absolue de 25 points de pourcentage en termes d’organisation et de 10 points en termes d’ampleur. Le dépôt STORM est tout aussi clair quant à ses limites : les articles générés ne sont pas prêts à être publiés et nécessitent souvent de nombreuses modifications.

La leçon à retenir n’est pas « ajouter plus d’agents ». C’est que la décomposition permet de contrôler séparément le contexte, les preuves, la gestion des échecs et l’évaluation. Avant d’optimiser un flux de travail, assurez-vous que ses étapes correspondent aux modes réels d’échec.

GEPA : apprenez de ce qui s’est réellement passé

Un seul score peut vous indiquer qu’une performance était médiocre. Il ne peut généralement pas vous expliquer pourquoi. Une exécution réelle laisse derrière elle des preuves bien plus riches :

input
  ↓
retrieval choice
  ↓
reasoning
  ↓
tool call
  ↓
tool result
  ↓
constraint failure
  ↓
final output

GEPA, abréviation de Genetic-Pareto et publié en juillet 2025, utilise ce signal. Il prend en échantillon les trajectoires d’exécution, les analyse en langage naturel, propose des modifications des prompts, évalue les candidats et maintient une frontière de Pareto afin que les stratégies complémentaires ne soient pas écartées.

Une limite est particulièrement importante en environnement de production. GEPA optimise en se basant sur des trajectoires déjà observées. Cela ne signifie pas qu’un agent en ligne puisse se réécrire après chaque demande d’utilisateur. Avant que tout candidat optimisé ne soit mis en service, il doit être versionné, évalué sur des cas sur lesquels il n’a jamais été entraîné, rester dans un budget d’optimisation fixe, et passer par une étape de promotion explicite contre un ensemble d’évaluation soigneusement sélectionné. C’est là la frontière entre un auto-amélioration utile et une auto-modification incontrôlée.

Claude Code : la boucle dans un environnement réel

DSPy aborde le problème du côté de l’optimisation des programmes. Claude Code le traite du côté du temps d’exécution. Selon la conception d’Anthropic, il s’agit d’un agent qui vit dans votre répertoire : il récupère les instructions propres au projet, modifie des fichiers, exécute des commandes shell et des suites de tests, et continue d’ajuster ses actions en fonction des résultats. Ses documents détaillés sur les modèles avancés parlent de la répartition du travail entre des sous-agents, de l’exécution de fonctions d’intégration entre les étapes, ainsi que de l’intégration de services internes à l’entreprise via MCP.

L’architecture n’est pas un « chat avec un développeur plus intelligent ». Elle ressemble plutôt à ceci :

Repository + Project Rules + Task
              ↓
            Model
       ↙      ↓      ↘
     Read    Edit   Execute
       ↘      ↓      ↙
      Tests / Runtime Evidence
              ↓
         Next Decision

Ces preuves en temps réel modifient ce que le modèle peut faire. Un test échoué constitue un retour d’information plus utile que le message « veuillez reconsidérer ». Une erreur de compilateur vaut mieux qu’un modèle évaluant lui-même sa propre correction. Il est possible de vérifier mécaniquement si une différence reste dans les limites prévues, sans avoir à demander à un autre modèle si l’évolution est suffisamment ciblée.

Les chiffres internes d’productivité d’Anthropic sont intéressants mais facilement interprétés de manière excessive. Son rapport d’analyse pour 2026 indique qu’au deuxième trimestre de cette année, chaque ingénieur génère environ huit fois plus de lignes de code par jour par rapport aux périodes précédentes, et l’entreprise met en garde explicitement contre le fait que ces lignes de code surestiment la véritable productivité. Cette période correspond également à de grands changements tant dans les modèles que dans Claude Code, de sorte que ce chiffre ne montre pas que seule l’orchestration a permis cette amélioration. Le signal plus clair est que les systèmes de codage modernes continuent de transformer les sorties des modèles en actions, en observations, puis en nouvelles décisions.

MCP relie les outils ; il ne les orchestre pas

MCP est souvent confondu avec les agents, l’utilisation d’outils et l’orchestration, comme s’il s’agissait de la même chose. Ce n’est pas le cas. L’architecture MCP est une spécification client-serveur : une application d’IA se connecte aux serveurs pour découvrir quels outils, ressources et instructions ils mettent à disposition, puis les appelle de manière uniforme. L’hôte coordonne les clients et reste responsable des permissions, de la gestion du contexte, de la politique de sécurité ainsi que de la manière dont le LLM est intégré.

Ainsi, MCP couvre un seul niveau d’une stack plus large :

Model                  capability envelope
Program / graph         task decomposition
Context / state         what the model can see
Tools / MCP             what the system can access or do
Runtime / harness       where actions execute
Evaluator               what counts as success
Optimizer               how the program improves
Observability           why a run succeeded or failed

Aucun framework ne possède tout cela, et c’est précisément pour cette raison que penser en termes de systèmes est avantageux.

Optimisez le cycle de correction des bugs, pas le prompt

Revenons au bug depuis le début. Au lieu d’une instruction disant « trouver le problème et le corriger », décrivez en détail le flux de travail :

  Issue + Repository
        ↓
    Diagnosis
        ↓
      Patch
        ↓
Tests + Lint + Runtime Checks
        ↓
    Diff Review
        ↓
  Accept or Revise

Chaque étape produit désormais des preuves : les journaux de fonctionnement indiquent quels fichiers ont été lus, quels commandes ont été exécutées, quels correctifs ont échoué, les résultats des tests ainsi que la différence finale.

Les vérifications déterministes couvrent ce qui peut être prouvé de manière mécanique : les tests requis réussissent, le linteur ne signale aucune erreur, les fichiers interdits ne sont pas modifiés, et le correctif reste dans son champ d’application autorisé. Le jugement du modèle est réservé aux questions véritablement sémantiques, comme la question de savoir si le diagnostic explique la cause probable du problème.

Au fil du temps, les cas passés deviennent un ensemble d’évaluation. MIPRO peut rechercher des instructions et des démonstrations dans les modules de diagnostic et de réparation. GEPA peut prendre en compte les trajectoires échouées ainsi que les retours des évaluateurs pour proposer un texte de programme amélioré. Mais l’optimisation relève de la phase post-lancement :

Production traces
      ↓
Curated evaluation set
      ↓
Offline optimizer
      ↓
Candidate program
      ↓
Held-out validation
      ↓
Controlled promotion

C’est ici que la recherche et la production se rencontrent enfin. L’environnement de exécution de l’agent génère des actions et des traces. L’évaluateur transforme ces traces en preuves. L’optimiseur propose un programme amélioré. Le processus de déploiement décide s’il est sûr de le lancer.

Que cela signifie pour les ingénieurs en IA

Les prompts ne sont pas devenus insignifiants. Vous avez simplement davantage d’occasions utiles d’intervenir. Lorsqu’un flux de travail ne fonctionne pas correctement, ne commencez pas par réfléchir à la formulation par réflexe. Déterminez plutôt quel niveau a échoué :

• Le modèle de base peut-il effectivement gérer la tâche ?
• La récupération des informations a-t-elle fourni le contexte adéquat ?
• La tâche a-t-elle été divisée en parties logiques ?
• Les outils ont-ils fourni des preuves fiables ?
• L’exécution a-t-elle été isolée et observable ?
• L’évaluateur mesure-t-il le comportement qui vous intéresse réellement ?
• L’optimiseur améliore-t-il la qualité sur les données non utilisées, ou se contente-t-il d’ajuster les résultats sur l’ensemble de développement ?

En examinant l’ensemble du système, on découvre également des compromis que le discours enthousiaste a tendance à ignorer. Envelopper un modèle faible dans un graphe ne fait pas de lui un modèle de pointe. Une métrique inadaptée favorise des comportements erronés. Plus d’outils signifie davantage de voies d’échec et une surface de sécurité plus grande. Chaque exécution d’optimisation consomme des tokens et du temps d’évaluation. Le pire, c’est qu’un agent qui se modifie lui-même, sans historique des versions ni cas de test intacts, peut devenir de plus en plus instable, tout en semblant plus indépendant sur le papier.

Ainsi, la leçon à retenir n’est pas que le modèle a cessé d’être important. La qualité du modèle fixe la limite des capacités possibles. La conception du système détermine dans quelle mesure ces capacités se traduisent par des résultats fiables.

C’est là le véritable lien entre la recherche de Stanford et les outils d’Anthropic. Avec DSPy, le programme cesse de se cacher à l’intérieur des chaînes de prompts. MIPRO permet de rechercher des instructions et des exemples à travers les différentes étapes. STORM rappelle que la structure du flux de travail est primordiale. GEPA analyse les traces d’exécution complètes afin d’identifier des améliorations. Claude Code place le modèle au sein d’un cadre technique fonctionnel, tandis que MCP standardise l’une des frontières avec les capacités externes. Des projets différents à différents niveaux, tous orientés dans la même direction.

La prochaine fois qu’un système d’IA échouera, « quel prompt devrais-je essayer ensuite ? » ne devrait pas être la seule question à se poser. Demandez plutôt quelle partie du système a défailli et quels éléments pourraient vous aider à la réparer.