DSPy vs LangChain : 18 mois plus tard, le bilan

En octobre 2024, j'ai migré mon pipeline de génération d'articles de LangChain vers DSPy. La promesse de DSPy m'avait convaincu : « programme tes pipelines LLM comme du code, laisse l'optimiseur trouver les meilleurs prompts ». 18 mois plus tard, le bilan est plus nuancé que ce que la communauté DSPy raconte. Oui, j'ai gagné sur certains aspects. Non, je ne referais pas le même choix aujourd'hui sur tous mes projets. Voici ce qui s'est vraiment passé.

Ce qui m'avait convaincu en 2024

À l'époque, mon pipeline LangChain était devenu un cauchemar de strings de prompts hardcodées dans des PromptTemplate. Chaque fois que je voulais ajuster un prompt, je devais re-tester manuellement sur 30 exemples, noter les résultats, ajuster, retester. 3 jours pour un ajustement de prompt.

DSPy promettait de remplacer ça par un système déclaratif : je décris ce que je veux (« question + contexte → réponse en 300 mots »), je fournis quelques exemples, et un optimiseur (BootstrapFewShot, MIPRO) trouve le meilleur prompt à ma place. Séduisant.

# DSPy
class GenerateArticle(dspy.Signature):
    topic = dspy.InputField()
    context = dspy.InputField()
    article = dspy.OutputField(desc="A 1500-word article")

program = dspy.ChainOfThought(GenerateArticle)
# L'optimiseur trouve automatiquement la meilleure version du prompt
optimized = dspy.BootstrapFewShot(metric=quality_metric).compile(program, trainset=examples)

Les gains réels après 18 mois

Trois choses frappantes :

• •Le temps d'ajustement des prompts s'effondre. C'est le killer feature.
• •La qualité monte (+21% sur mes métriques subjective), parce que l'optimiseur trouve des formulations auxquelles je n'avais pas pensé.
• •Mais le coût augmente (+19%) parce que DSPy fait des appels LLM supplémentaires pendant l'optimisation, et ses prompts générés sont souvent plus longs.

Ce qui coince vraiment

Coin 1 : la doc est encore horrible

18 mois après mon passage à DSPy, la doc officielle est toujours un patchwork de tutoriels qui se contredisent. Les API changent entre les versions mineures. J'ai passé 6 heures sur une migration 2.4 → 2.5 parce qu'un signature field avait été renommé silencieusement.

LangChain, pour tous ses défauts, a au moins une doc searchable et une communauté énorme qui a déjà rencontré tous les bugs. DSPy, tu es souvent seul face à un traceback.

Coin 2 : les optimizers sont lents et imprévisibles

BootstrapFewShot sur 50 exemples prend 20-40 minutes de wall-clock time et coûte 5-15 $ en appels Anthropic. Et parfois, le prompt optimisé est moins bon que celui d'origine. La variance est élevée. Sur mes 12 optimisations en 18 mois, 3 ont produit un prompt pire que la baseline (je les ai écartés, mais j'ai payé).

MIPRO (le nouvel optimizer) est meilleur mais encore plus lent et cher.

Coin 3 : le debugging est pénible

Quand un pipeline LangChain échoue, tu peux lire la trace et voir le prompt envoyé, la réponse, le parse error. En DSPy, le pipeline est un arbre de modules compilés, et le prompt effectivement envoyé est généré à la volée. Le debug demande de plonger dans les internals du framework, ce qui n'est jamais amusant.

J'ai une conviction : DSPy est pensé pour des chercheurs, pas pour des gens qui mettent en prod. Ça se voit.

La question à 1 000 $ : est-ce que je referais le même choix en 2026 ?

Non, pas pour tous les projets. Voici ma nouvelle règle :

Pour mon pipeline de génération d'articles, DSPy reste le bon choix parce que j'ai 5 étapes qui s'enchaînent et la qualité est critique. Pour un simple chatbot catalogue, revenu aux appels directs d'Anthropic. Pour un RAG, LangGraph.

Le problème philosophique de DSPy

DSPy a une promesse implicite : « ne te soucie plus des prompts, on s'en occupe ». Mais en pratique, tu finis quand même à lire les prompts générés, à comprendre pourquoi l'optimiseur a choisi tel pattern, à écrire des métriques qualité custom. Tu as déplacé le travail, pas supprimé.

Et les métriques qualité que tu écris déterminent ce que l'optimiseur considère comme « mieux ». Si ta métrique est naïve, l'optimiseur trouve un prompt qui maximise ta métrique sans améliorer la vraie qualité. Classic overfitting.

Ce que je ferais différemment si je recommençais

1. 1.Ne pas tout migrer d'un coup. J'ai migré 100% en 3 semaines en 2024. J'aurais dû garder LangChain sur les parties stables et tester DSPy uniquement sur les pipelines où le tuning de prompt me coûtait du temps.
2. 2.Investir 2 semaines dans la métrique qualité avant de lancer le moindre optimizer. Une vraie métrique (pas un LLM-as-judge naïf) est le seul garant de l'efficacité de DSPy.
3. 3.Garder un baseline non-DSPy pour chaque pipeline. Mesurer le gain. Si gain < 10%, ça ne vaut pas le complexity tax.
4. 4.Documenter les prompts générés dans le repo pour pouvoir audit-er ce que DSPy a produit.

Ce qu'il faut retenir

1. 1.DSPy tient ses promesses sur le tuning de prompts (−89% de temps d'ajustement).
2. 2.Mais à un coût caché : +19% en facture, une doc horrible, du debug pénible.
3. 3.DSPy est un outil de chercheur, pas de dev prod — la stabilité et le tooling sont en retard.
4. 4.Ma règle 2026 : DSPy seulement sur les pipelines à 3+ étapes LLM où la qualité est critique. Ailleurs, SDK direct ou LangGraph.
5. 5.La métrique qualité est le facteur décisif — investis-y avant de toucher à un optimizer.

Pour aller plus loin sur les architectures concrètes d'agents et de pipelines LLM en Python, j'ai écrit un guide complet :

Agents LLM en Python

Des agents qui marchent. En Python.

Découvrir →