DSPy Flex : laisser l'IA écrire le code de vos agents

Réponse directe : dspy.Flex est un nouveau module de DSPy qui donne à un optimiseur comme GEPA accès au code de votre programme, pas seulement à ses instructions. Sur un benchmark de résolution d'entités, il passe de 90,4% de précision à 95,0% en coûtant 28% moins cher et en tournant 40% plus vite que le programme de départ. Moins d'appels LLM, c'est aussi moins de données envoyées à des API tierces, donc une surface RGPD plus réduite pour les entreprises.

Qu'est-ce que DSPy Flex exactement ?

DSPy part d'un principe : définir une tâche une fois, d'une manière qui permette de la ré-implanter à mesure que l'écosystème IA évolue. L'histoire de ces ré-implantations suit l'histoire des modèles. En 2022, les modèles devaient voir à quoi ressemblait une tâche, donc les optimiseurs comme BootstrapFewShot automatisèrent le choix des exemples. Les modèles sont ensuite devenus de bons rédacteurs de prompts, donc MIPROv2 et GEPA améliorèrent les programmes en réécrivant leurs instructions. Aujourd'hui, les modèles sont devenus d'excellents programmeurs. Flex exploite cette capacité pour réécrire le code lui-même, pas seulement le prompt.

Concrètement, dspy.Flex(YourSignature) se substitue à dspy.Predict. Voici la transformation :

my_signature = "question -> answer"
my_program = dspy.Predict(my_signature)
 
my_program = dspy.Flex(my_signature)

Avant optimisation, Flex se comporte exactement comme un module Predict (ou RLM si vous fournissez des outils). La différence apparaît quand on le confie à un optimiseur : Flex expose son code, en plus de ses instructions. Le modèle de réflexion peut alors décomposer le programme, écrire des fonctions d'aide, implémenter de la logique de routage, et réécrire les prompts.

Comment optimiser un programme Flex avec GEPA ?

L'exemple officiel optimise une signature avec GEPA. Un petit modèle sert pendant l'inférence, un gros modèle écrit le code :

program = dspy.Flex(SamePlace)        # était: dspy.Predict(SamePlace)
 
dspy.configure(lm=dspy.LM("anthropic/claude-haiku-4-5"))
 
big_lm = dspy.LM("anthropic/claude-opus-5")
 
optimized = dspy.GEPA(
    metric=make_metric(penalty=0.2),
    reflection_lm=big_lm,
    max_metric_calls=400,
).compile(program, trainset=train, valset=val)

Après optimisation, optimized.save("program.json") persiste le source, et dspy.Flex(SamePlace).load(...) le restaure. Le résultat est un fichier que vous pouvez ouvrir, lire, diff et analyser.

Deux phénomènes en découlent. Parfois le programme optimisé ne fait aucun appel au modèle, parce qu'il a trouvé un cas qu'il peut trancher en code pur. Et quand il appelle le modèle, l'appel est mieux ciblé, car le module a déjà fait le parsing et la comparaison. Résultat : moins d'appels, de meilleurs appels, et un programme qui surpasse celui d'origine.

Flex est-il sûr pour la production ?

Le code écrit par un modèle reste du code non vérifié. Par défaut, il ne s'exécute jamais dans votre process. Flex lance le source généré dans un interpréteur sandboxé. Seuls les appels de prédiction et les outils que vous avez explicitement fournis font le pont vers le process hôte, et une limite max_predictor_calls borne le nombre de traversées par passage en avant.

Cette isolation a un double intérêt pour les entreprises : elle limite le risque de code malveillant ou défectueux, et elle garde l'exécution dans votre environnement. Combiné à des modèles open source hébergés en Europe, c'est une brique qui s'inscrit dans une approche freelance IA orientée conformité.

Le benchmark de résolution d'entités

Le cas d'usage présenté est une tâche de conflation géospatiale : à partir de deux listes de lieux, décider s'il s'agit du même endroit physique. C'est piégeux dans la queue de distribution. KIN CAFE et KIN à la même adresse sont le même lieu. CONCESSION #2 KEN MERCER SPORTS PARK et KEN MERCER SPORTS PARK à la même adresse ne le sont pas.

Le protocole : 1 029 paires étiquetées, évaluées sur 240 enregistrements retenus (classés équilibrés, donc 50% correspond au hasard). Les caches sont désactivés, les chiffres correspondent donc au trafic de production à froid. Le modèle d'exécution est claude-haiku-4-5, le modèle de réflexion claude-opus-5.

Deux enseignements. Même avec les appels gratuits (λ=0), l'optimiseur a écrit du code : il a routé 75% des enregistrements vers du Python déterministe et atteint 95,0%, plus précis que le modèle appelé à chaque fois (90,4%, McNemar p=0,019). À λ=0,4, le programme a appelé le modèle une seule fois sur 240 enregistrements, pour une précision de 92,1% statistiquement indistinguable de la baseline, à environ un centième du coût et un trentième de la latence.

Pourquoi l'optimisation prompt seule coûte plus cher ?

L'optimisation du prompt a un seul levier : l'instruction. GEPA a donc écrit une instruction beaucoup plus longue, et chaque enregistrement paie ces tokens supplémentaires à l'inférence. Résultat : 92,5% de précision, mais $2,88 pour mille enregistrements, soit 2,9 fois la baseline, et 48% de latence en plus. Flex donne un second levier à l'optimiseur : le code du module. En optimisant le prompt et le code ensemble, Flex produit un programme 28% moins cher et 40% plus rapide que la baseline, tout en étant plus précis.

Comment la métrique pilote le compromis ?

Une métrique GEPA renvoie un score plus un retour en langage naturel. Avec Flex, elle peut aussi voir combien d'appels LLM le programme généré a effectués sur chaque enregistrement. On peut utiliser cette valeur pour pénaliser le retour :

score = max(0.0, correct - PENALTY * n_llm_calls)

À PENALTY = 0, les appels sont gratuits, l'optimiseur ne chasse que la précision. Quand la pénalité λ augmente, chaque appel LLM doit racheter plus de précision qu'il n'en coûte, et l'optimiseur est poussé à trancher les cas en Python et à réserver le modèle aux vraies ambiguïtés. Au-delà de λ = 1,0, un appel ne peut jamais s'amortir, ce qui revient à ne jamais appeler le modèle.

La pénalité est aussi un instrument de conformité. Chaque appel LLM est un transfert de données potentiel vers une API tierce. Pénaliser les appels revient à réduire mécaniquement les données envoyées à l'extérieur, ce qui va dans le sens de la minimisation voulue par le RGPD. Pour une entreprise soumise à des contraintes de localisation, c'est un paramètre de conception autant qu'un paramètre de coût.

Que fait réellement le code écrit par l'IA ?

À λ=0,4, le programme contient environ deux cents lignes de Python écrites par le modèle de réflexion. L'architecture suit trois étapes. Normalisation : les noms sont mis en majuscules, débarrassés des numéros de franchise, des suffixes légaux (LLC, INC) et d'une quarantaine de mots génériques (CAFE, RESTAURANT, MARKET, GRILL), et les adresses sont parsées en numéro de rue et noyau de rue. Comparaison : les tokens distinctifs sont notés avec une similarité floue et classés en trois catégories. Décision : chaque catégorie a ses règles combinant nom, adresse et distance. Seul le cas où aucune règle ne se déclenche part au modèle, avec l'analyse déjà calculée comme entrée supplémentaire.

Le commentaire en tête, écrit par l'optimiseur sur sa propre architecture, résume l'approche : "le LLM est un secours de dernier recours".

Flex peut-il dépasser le simple benchmark ?

Une expérience pilote sur SWE-bench Pro, un benchmark de coding à partir d'issues GitHub, donne un aperçu. Avec claude-haiku-4-5, le programme de départ résout 0 issue sur 12 échantillonnées. Après optimisation GEPA sur le programme Flex, avec max_metric_calls limité à 60, il en résout 4 sur 12, en concevant un workflow qui mélange Python et appels LLM pour rechercher, rédiger, évaluer, réparer et soumettre une réponse. C'est une pilote, mais elle montre un harness qui évolue en quelques passes vers 4/12, contre les 39% rapportés pour Haiku dans un harness mature et fait main.

Quatre mouvements reviennent systématiquement quand GEPA réécrit des programmes : la décomposition (donner une implémentation à chaque étape), le choix de méthode (code déterministe ou appel modèle par étape), le routage (cas clairs sur le chemin bon marché, cas ambigus vers le juge), et l'évolution (affiner signatures, instructions et code une fois la structure stable).

Ce que ça change pour un projet d'entreprise

Un harness écrit à la main ne s'adapte pas aux nouveaux modèles, jeux de données ou tactiques, sauf à être réécrit. Avec Flex, on compile le harness en continu. Concrètement, pour un projet d'automatisation IA, vous pouvez faire balayer les modèles et ajuster la métrique pour trouver l'équilibre optimal entre coût, latence et précision, sans réécrire la logique à chaque changement de modèle.

Le même instinct traverse les agents de coding, qui écrivent de plus en plus un script Python pour faire le travail plutôt que de le faire token par token. Flex industrialise ce réflexe en le confiant à un optimiseur.

TL;DR

DSPy Flex laisse le modèle écrire le code de votre programme, pas seulement ses instructions. Sur la résolution d'entités, il atteint 95,0% de précision en coûtant 28% moins cher et en tournant 40% plus vite que la baseline, avec 75% d'appels LLM en moins. Le code généré s'exécute dans un interpréteur sandboxé, et une métrique pénalisée permet de piloter finement le compromis coût, latence, précision. Moins d'appels vers des API tierces, c'est aussi moins de données qui sortent de votre environnement, un point utile pour les contraintes RGPD et de souveraineté.

Pour affiner le coût réel de vos déploiements d'agents, le calculateur de coûts RAG estime le budget tokens et embeddings. Et si vous hésitez entre architectures, la comparaison agents IA vs pipelines LLM peut vous éclairer.

Vous construisez des agents IA et voulez réduire leurs coûts sans sacrifier la qualité, ou garder vos données en Europe ? Parlons-en.