DSPy : « programmer » ses LLM au lieu de les prompter — l’idée derrière le slogan

TL;DR — DSPy en une minute

• Ce que c’est : un framework Python de Stanford NLP (MIT, ~37 000 étoiles) pour construire des applications LLM en les programmant plutôt qu’en écrivant des prompts à la main.
• L’idée : tu déclares ce que tu veux (entrée → sortie), et DSPy fabrique et optimise les prompts à ta place.
• Le slogan « programmer, pas prompter » n’est pas creux : c’est la vraie devise du projet, avec des travaux de recherche à l’appui.
• Le catch : « auto-optimisé » ne veut pas dire gratuit — la phase d’optimisation lance beaucoup d’appels au modèle (donc des tokens, donc de l’argent), et il faut coder en Python.
• Notre verdict : Bookmark — comprends le concept maintenant, installe-le si tu construis de vraies applis LLM (RAG, agents, classifieurs).

Le reel est catégorique : « arrête de prompter, programme tes modèles ». Pour une fois, ce n’est pas un compte hype qui invente un slogan — programmer, pas prompter est la vraie devise de DSPy, un framework né à Stanford. Reste la question que le reel n’aborde jamais : qu’est-ce que ça veut dire concrètement, et est-ce que c’est pour toi ?

Le problème : le prompt écrit à la main, c’est fragile

Quand tu construis une application autour d’un LLM, tu finis toujours par bricoler de longs prompts : des instructions, des exemples, des « réponds en JSON », des rustines pour chaque cas qui déraille. Ça marche… jusqu’à ce que tu changes de modèle (le prompt calé pour GPT ne réagit plus pareil sur Claude), ou que tu ajoutes une étape au pipeline. Tu passes alors ton temps à re-régler des chaînes de caractères à la main. C’est artisanal, et ça casse au premier courant d’air.

L’idée de DSPy : tu décris le QUOI, il gère le COMMENT

DSPy renverse la logique. Au lieu d’écrire le prompt, tu déclares une intention, et le framework fabrique le prompt pour toi. Trois briques, en clair :

• Les signatures : tu décris juste l’entrée et la sortie attendues (« question → réponse », « document → résumé »). C’est comme une signature de fonction, pas un paragraphe d’instructions.
• Les modules : des composants réutilisables qui implémentent une façon de raisonner (par exemple une « chaîne de pensée », ou une boucle d’agent). Tu les assembles comme des Lego.
• Les optimizers (anciennement « teleprompters ») : c’est là qu’est la magie. Tu fournis quelques exemples et une métrique (ce qu’est une « bonne » réponse), et l’optimizer teste automatiquement des variantes de prompt et d’exemples pour trouver la meilleure combinaison. Tu ne rédiges plus le prompt : tu le laisses se compiler.

En clair : tu programmes la logique de ton système, et DSPy s’occupe de la formulation — y compris quand tu changes de modèle sous le capot.

« Auto-optimisé » ne veut pas dire « gratuit » (le vrai catch)

Voilà ce que le slogan cache. Cette optimisation automatique n’a rien de magique : pour trouver le meilleur prompt, l’optimizer lance beaucoup d’appels au modèle. Les optimizers avancés (MIPROv2, GEPA) « coûtent des rollouts » — traduction : ils enchaînent des dizaines, parfois des centaines d’appels LLM pendant la phase de compilation. Concrètement :

• Ça consomme des tokens = de l’argent, à chaque fois que tu (ré)optimises.
• La recommandation officielle est d’ailleurs de commencer par l’optimizer le plus léger (BootstrapFewShot) avant de sortir l’artillerie (MIPROv2, GEPA).

Ce n’est pas rédhibitoire — c’est un coût maîtrisable et ponctuel, en amont — mais il faut le savoir avant de croire au « gratuit et automatique ».

Et l’autre condition, tout aussi importante : DSPy, c’est du Python. Ce n’est pas un outil pour l’utilisateur de ChatGPT ; c’est un framework pour qui code des systèmes LLM.

Pour qui c’est vraiment utile

• Tu construis de vraies applications LLM en Python — RAG, classifieurs, boucles d’agents — et tu en as assez de re-régler des prompts à la main : c’est exactement pour toi.
• Tu veux que ton système reste robuste quand tu changes de modèle (Claude, GPT, open source) : DSPy recompile au lieu de te faire tout réécrire.
• Tu as une métrique claire de ce qu’est une bonne réponse : sans elle, l’optimisation n’a rien sur quoi « s’auto-améliorer ».

À l’inverse : si tu veux juste mieux prompter ChatGPT ou Claude au quotidien, DSPy est très surdimensionné. Le concept est passionnant à comprendre, mais l’installer n’a de sens que si tu écris du code.

Notre verdict : Bookmark

DSPy est l’un des rares frameworks qui méritent leur buzz : sérieux (Stanford, recherche à l’appui), massivement adopté, et porteur d’une vraie idée — traiter la construction d’applis LLM comme du génie logiciel, pas comme du bricolage de prompts. Pour tout entrepreneur ou dev qui veut comprendre où va l’ingénierie LLM, le concept est à connaître dès maintenant.

De là à l’installer tout de suite ? Seulement si tu bâtis des systèmes LLM en Python. Sinon, mets-le en favori : tu sauras exactement quand le sortir — le jour où tes prompts artisanaux deviendront ingérables. Vu comme ça, « programmer plutôt que prompter » n’est pas un slogan, c’est une direction — et DSPy est la meilleure porte d’entrée pour la comprendre.

Points de vigilance

• C’est du Python, pas une appli clic-bouton : réservé à qui code.
• L’optimisation coûte des appels LLM (tokens/€) : commence par BootstrapFewShot, garde MIPROv2/GEPA pour quand c’est justifié.
• Il te faut une métrique de qualité : sans elle, pas d’auto-optimisation possible.
• Concept avant urgence : à comprendre maintenant, à installer quand tu construis vraiment des systèmes LLM.