DSPy

DSPy est un framework Python permettant de programmer des modèles de langage plutôt que de rédiger leurs prompts manuellement. Conçu à Stanford NLP par Omar Khattab et publié en open source sous licence Apache 2.0, il est issu de recherches publiées à ICLR 2024 et a depuis atteint plus de 34 000 étoiles sur GitHub et environ 5,25 millions de téléchargements mensuels sur PyPI en avril 2026. Le problème fondamental que DSPy résout est la fragilité des chaînes de prompts créées manuellement : lorsque vous changez de modèle, modifiez votre pipeline ou découvrez que votre prompt rédigé à la main ne fonctionne que dans des conditions spécifiques, vous devez tout recommencer. DSPy remplace ce flux de travail par un compilateur qui traite l'optimisation des prompts comme un problème de recherche basé sur une métrique.

Le framework fournit trois primitives interconnectées : les Signatures (spécifications d'entrée-sortie typées, écrites en langage naturel, qui déclarent ce que vous voulez obtenir, et non comment l'obtenir), les Modules (unités composables telles que ChainOfThought, ReAct, Refine, ProgramOfThought, BestOfN et Parallel qui appliquent des stratégies de raisonnement), et les Optimizers (BootstrapFewShot pour la synthèse few-shot, MIPROv2 pour l'ajustement conjoint des instructions et des démonstrations via l'optimisation bayésienne, et BootstrapFinetune pour la mise à jour des poids). Vous définissez une métrique, fournissez un petit jeu de données étiqueté, exécutez l'optimiseur et obtenez en retour un programme de prompts compilé. DSPy 3.0, lancé lors du Databricks Data + AI Summit en juin 2025 et suivi de la version 3.2.0 en avril 2026, a ajouté l'intégration de MLflow pour l'observabilité, le fine-tuning basé sur l'apprentissage par renforcement (RL), l'optimiseur d'évolution de prompt réflexif GEPA, ainsi que des outils renforcés pour la production développés à partir de l'utilisation interne de Databricks.

Ce que fait réellement DSPy en avril 2026

La version actuelle est DSPy 3.2.0, qui intègre une interface de chaînage d'optimiseurs (BetterTogether) vous permettant de séquencer les optimiseurs selon des stratégies personnalisées : par exemple, l'optimisation des prompts, puis le fine-tuning, puis la ré-optimisation (un cycle "p -> w -> p"). Elle a également rendu LiteLLM optionnel plutôt que requis, ce qui réduit la taille de l'installation et élimine un conflit de dépendance transitive qui frustrait de nombreux utilisateurs dans les versions précédentes. La validation des champs d'entrée avertit désormais lorsque les valeurs ne correspondent pas aux types de signature déclarés, et la primitive dspy.Reasoning (introduite dans la version 3.1.0) expose le raisonnement natif des modèles de raisonnement tels que o3 et Claude Sonnet sans configuration supplémentaire.

La bibliothèque de modules couvre la plupart des modèles de raisonnement prêts à l'emploi. ChainOfThought suscite une justification avant la réponse finale. ReAct entrelace les étapes de raisonnement avec les appels d'outils pour les boucles d'agents. ProgramOfThought passe par un interpréteur de code pour les problèmes à forte composante mathématique. BestOfN échantillonne plusieurs complétions et les évalue par rapport à une métrique. Parallel exécute des modules simultanément pour les pipelines sensibles à la latence. Tous les modules acceptent des backends LLM arbitraires via l'interface LiteLLM, de sorte que passer de GPT-4o à Claude 3.7 Sonnet ou à un modèle Llama exécuté localement ne nécessite qu'une seule ligne de configuration, l'optimiseur étant réexécuté pour dériver de nouveaux prompts adaptés au style du nouveau modèle.

Le système d'optimisation distingue DSPy de tous les autres outils d'orchestration LLM sur le marché. BootstrapFewShot génère des démonstrations étiquetées en exécutant votre programme sur un ensemble d'entraînement et en ne conservant que les exemples où la sortie valide votre métrique. MIPROv2 va plus loin : il propose des instructions candidates, les évalue sur des mini-lots à l'aide de l'optimisation bayésienne, et effectue une recherche conjointe sur le texte des instructions et les ensembles de démonstrations pour chaque module de votre pipeline simultanément. Selon l'article de ICLR 2024, ces optimiseurs produisent des pipelines qui surpassent les références basées sur des prompts manuels de plus de 25 % sur GPT-3.5 et de plus de 65 % sur Llama 2 13B sur des tâches représentatives. L'optimiseur GEPA (introduit dans la version 3.0) applique une évolution réflexive, où le modèle critique ses propres instructions proposées et itère.

"Le prompt engineering est fragile, ce sont des 'modèles' codés en dur qui ne se généralisent pas, et ce n'est tout simplement pas scalable." - vincirufus, Hacker News, août 2025

Où se situe DSPy par rapport à LangChain et LlamaIndex

LangChain est un framework d'orchestration : il vous offre des abstractions de chaînes composables, la gestion de la mémoire, plus de 100 intégrations d'outils prédéfinies et des exécuteurs d'agents qui routent entre les outils via l'analyse de chaînes de caractères ou l'appel de fonctions. Le modèle fondamental est impératif : vous écrivez une chaîne de prompt, l'intégrez dans une chaîne d'exécution, et itérez en modifiant le texte. Il n'y a pas d'optimiseur. Lorsque vous souhaitez que le prompt s'améliore par rapport à une métrique, vous devez écrire cette logique vous-même. LangChain compte environ 90 000 étoiles sur GitHub et possède le plus grand écosystème d'intégration de tous les frameworks LLM, mais sa gestion des prompts est entièrement manuelle et les chaînes imposent une surcharge d'environ 10 ms par appel (contre environ 3,5 ms pour DSPy selon les benchmarks de Morph LLM, 2025). La comparaison se résume à ceci : LangChain optimise la rapidité avec laquelle vous pouvez construire quelque chose de fonctionnel ; DSPy optimise la fiabilité avec laquelle cette chose s'améliore et reste fonctionnelle à mesure que les modèles évoluent.

LlamaIndex est une infrastructure RAG : sa principale différenciation est la couche d'indexation, avec plus de 10 types d'index (VectorStore, SummaryIndex, KnowledgeGraph, SQL, etc.), des pipelines sophistiqués de découpage (chunking) et d'intégration (embedding), une recherche hybride combinant BM25 et recherche sémantique, ainsi que le réordonnancement (re-ranking). Si votre problème est "comment ingérer et récupérer des documents à grande échelle", LlamaIndex dispose d'outils spécialement conçus pour cela. Ses agents de moteur de requête enveloppent cette couche de récupération dans une boucle ReAct. Ce que LlamaIndex n'a pas, c'est un optimiseur : une fois que vous avez défini votre pipeline RAG, la qualité des prompts reste un problème d'itération manuelle. DSPy peut en fait être utilisé par-dessus la récupération de LlamaIndex en traitant le récupérateur (retriever) comme un module compatible DSPy, un modèle documenté dans les cas d'usage de la communauté DSPy et disponible via des intégrations comme LlamaIndex lui-même.

Une perspective utile de la communauté des ingénieurs : les utilisateurs combinent souvent l'optimisation de DSPy avec l'étendue des intégrations de LangChain, ou utilisent DSPy pour générer des prompts optimisés qui sont ensuite déployés dans un pipeline LangChain. Pour l'observabilité et le traçage des exécutions de DSPy en production, l'intégration Databricks s'associe à MLflow, tandis que des outils tiers comme Langfuse prennent également en charge le traçage de DSPy de manière native. Pour les équipes créant des applications LLM nécessitant une flexibilité quant au fournisseur de modèles, LiteLLM est le routeur auquel DSPy délègue en arrière-plan. Pour les charges de travail fortement axées sur les agents, où la coordination multi-agents importe plus que l'optimisation des prompts, AutoGen et CrewAI adoptent des approches architecturales différentes qui méritent d'être comparées.

"Loi de Khattab : Tout système d'IA suffisamment complexe contient une implémentation ad hoc, spécifiée de manière informelle et truffée de bugs de la moitié de DSPy." - Skylar Payne, blog d'ingénierie IA, 2024

À quoi ressemble la réalité du flux de travail DSPy

Démarrer avec DSPy nécessite un investissement initial plus important que LangChain, mais qui s'avère payant de différentes manières. Le flux de travail comporte quatre étapes : définir votre signature, écrire la composition de vos modules, définir votre métrique et exécuter l'optimiseur. Un exemple de fonctionnement minimal ressemble à ceci : écrivez `class QA(dspy.Signature): question: str -> answer: str`, instanciez `cot = dspy.ChainOfThought(QA)`, écrivez une métrique qui vérifie l'exactitude de la réponse, appelez `optimizer.compile(cot, trainset=examples)`. Le programme compilé met en cache les prompts optimisés et les démonstrations qui peuvent être enregistrés sur disque, versionnés et reproduits à l'identique.

L'expérience de débogage s'est considérablement améliorée dans la version 3.x. La fonction `inspect_history()` affiche chaque appel LLM effectué au cours de la session avec les prompts et les réponses complets. L'intégration de MLflow (pour les utilisateurs de Databricks) consigne chaque essai d'optimisation avec les entrées, les sorties et les scores de métriques, ce qui permet d'auditer pourquoi l'optimiseur a choisi des démonstrations spécifiques. Les avertissements de validation de type dans la version 3.2.0 signalent les incohérences de signature avant qu'elles ne deviennent des échecs silencieux. Néanmoins, déboguer un pipeline multi-modules où l'optimiseur a fait des choix avec lesquels vous n'êtes pas d'accord nécessite de comprendre ce que la recherche optimisait, ce qui exige plus de connaissances contextuelles que le débogage d'un prompt écrit manuellement.

Les coûts d'optimisation varient considérablement selon l'optimiseur et la taille du jeu de données. Une exécution rapide de BootstrapFewShot sur 50 exemples avec GPT-4o-mini comme enseignant coûte environ 1 à 3 $. Une exécution complète de MIPROv2 avec génération d'instructions candidates sur 200 exemples peut coûter de 10 à 50 $ selon le choix du modèle. La documentation donne une estimation de 2 $ pour une "exécution simple typique". Les équipes qui ont exécuté MIPROv2 sans lire les conseils sur les coûts début 2024 ont signalé des factures d'API surprenantes, un problème que la documentation aborde désormais plus explicitement.

À qui s'adresse DSPy

DSPy est particulièrement puissant pour les ingénieurs ML et les chercheurs qui raisonnent en termes de systèmes plutôt que de chaînes de caractères. Si vous disposez de données étiquetées, d'une métrique mesurable et d'un pipeline qui doit rester maintenable à mesure que les modèles évoluent, la boucle d'optimisation de DSPy offre une valeur qu'aucune quantité de création manuelle de prompts ne peut égaler. Des équipes au sein d'entreprises telles que Google, IBM, VMware et Databricks ont signalé que DSPy rend le changement de modèle considérablement moins coûteux : lorsqu'un nouveau modèle sort, il suffit de réexécuter l'optimiseur plutôt que de réécrire chaque prompt. Le framework est particulièrement précieux dans les domaines scientifiques et à forte intensité de données où les pipelines augmentés par la récupération (RAG) nécessitent une mesure systématique de la qualité. Les chercheurs publiant des expériences LLM reproductibles bénéficient des programmes compilés sérialisables de DSPy qui peuvent être partagés avec le code de leurs articles.

Le framework n'est pas adapté au prototypage rapide sous la pression des délais. Le coût initial lié à la rédaction des métriques d'évaluation, à la préparation des exemples d'entraînement et à la compréhension des abstractions de l'optimiseur est bien réel. Comme l'a noté l'analyse d'un praticien, les équipes "adoptent DSPy directement, ou elles peuvent emprunter ses modèles intentionnellement dès le premier jour, plutôt que de les reconstruire péniblement plus tard". Les produits sans critère de succès programmable (chatbots ouverts, assistants de création littéraire) ne peuvent pas tirer parti de l'optimiseur, ce qui supprime le principal différenciateur de DSPy. Python est le seul environnement d'exécution de premier ordre, bien qu'un portage Go maintenu par la communauté soit apparu en 2025.

Ce que DSPy n'est pas

DSPy n'est pas un remplaçant pour l'intégralité de LangChain ou LlamaIndex. Il n'intègre pas plus de 100 connecteurs prédéfinis, il ne gère pas la mémoire de conversation pour les applications de chat à tours multiples, et il ne fournit pas d'interface utilisateur, de terrain de jeu (playground) ou de service hébergé. C'est une bibliothèque Python. Vous l'installez, vous écrivez du Python, vous appelez des API LLM (via LiteLLM, qui prend en charge OpenAI, Anthropic, Gemini, Cohere, les modèles locaux via Ollama, et la plupart des autres fournisseurs). Le déploiement, la mise à disposition (serving) et la surveillance sont hors du périmètre de DSPy lui-même, et sont gérés par votre propre infrastructure ou par la stack de Databricks si vous faites partie de cet écosystème.

Ce n'est pas non plus un framework pour les utilisateurs qui veulent éviter complètement de penser aux prompts. DSPy vous fait passer de la rédaction manuelle de prompts à la rédaction de signatures et de métriques, mais vous devez toujours comprendre à quoi ressemble une bonne sortie afin de définir la métrique. L'optimiseur est une recherche dans l'espace des prompts, et non un oracle qui devine votre cas d'usage à partir de zéro. La distinction est importante : DSPy automatise l'itération fastidieuse et rend le processus systématique et reproductible, mais il ne remplace pas l'expertise métier.