DSPy et la Programmation Déclarative de LLM : Guide Pratique 2026

Table des Matières

1 Introduction : au-delà du prompt engineering

Depuis l'avènement des grands modèles de langage (LLM), le prompt engineering s'est imposé comme la discipline centrale pour exploiter ces systèmes. Des ingénieurs consacrent des heures à reformuler manuellement des instructions, à ajuster le ton, à ajouter des exemples few-shot, à expérimenter avec des techniques de chain-of-thought -- le tout dans un processus fondamentalement artisanal. En 2026, cette approche atteint ses limites structurelles. Les prompts sont fragiles : un changement de modèle, une mise à jour d'API ou une simple modification du system prompt peut dégrader dramatiquement les performances d'un pipeline entier. La maintenance de centaines de prompts interdépendants dans une application en production relève du cauchemar opérationnel.

DSPy (Declarative Self-improving Language Programs) propose une rupture paradigmatique avec cette situation. Développé par Omar Khattab et l'équipe de Stanford NLP, DSPy transpose au domaine des LLM les principes fondamentaux du génie logiciel moderne : séparation des préoccupations, abstraction, modularité et optimisation automatique. Plutôt que d'écrire des prompts, le développeur déclare ce que le programme doit accomplir -- les entrées attendues, les sorties souhaitées, les contraintes à respecter -- et laisse le framework compiler automatiquement les prompts optimaux pour le modèle cible.

L'analogie avec l'évolution des langages de programmation est éclairante. Le passage de l'assembleur au C, puis du C au Python, a successivement élevé le niveau d'abstraction tout en déléguant l'optimisation de bas niveau aux compilateurs et interpréteurs. DSPy opère la même transition pour les LLM : le prompt est le code assembleur de l'IA générative, et DSPy en est le compilateur. Le développeur définit des signatures déclaratives et des modules composables ; l'optimizer (anciennement appelé teleprompter) se charge de trouver les prompts, exemples few-shot et paramètres qui maximisent une métrique définie sur un jeu de données d'entraînement.

Ce guide propose une exploration approfondie de l'écosystème DSPy en 2026. Nous détaillerons son architecture interne -- signatures, modules et optimizers -- avant d'aborder la compilation de prompts, l'intégration avec les systèmes RAG, les stratégies d'évaluation, et une comparaison structurée avec LangChain et LlamaIndex. Des cas pratiques concrets illustreront chaque concept pour permettre une mise en oeuvre immédiate.

2 Architecture DSPy : signatures, modules et optimizers

L'architecture de DSPy repose sur trois abstractions fondamentales qui interagissent de manière cohérente : les signatures qui définissent les contrats entrée-sortie, les modules qui encapsulent la logique de traitement, et les optimizers qui compilent le tout en prompts optimisés. Cette séparation des responsabilités constitue la force distinctive du framework.

Les Signatures : contrats déclaratifs

Une signature DSPy est l'équivalent d'une signature de fonction en programmation classique, mais appliquée à une tâche de traitement du langage naturel. Elle déclare les champs d'entrée et de sortie, accompagnés de descriptions optionnelles qui guident le modèle. La syntaxe la plus concise utilise une notation inline : "question -> answer" définit une signature qui prend une question en entrée et produit une réponse. Pour des cas plus complexes, on définit une classe héritant de dspy.Signature avec des champs typés via dspy.InputField() et dspy.OutputField(). Chaque champ accepte une description en langage naturel qui sera intégrée au prompt compilé. Par exemple, un champ answer = dspy.OutputField(desc="une réponse concise de 2-3 phrases") contraint la sortie sans recourir à du prompt engineering explicite. Les signatures supportent également des champs multiples et des types structurés : on peut définir une signature qui prend un document et une question en entrée et produit un raisonnement intermédiaire, une réponse et un score de confiance en sortie.

Les Modules : blocs de construction composables

Les modules DSPy sont des unités de traitement réutilisables qui encapsulent une stratégie d'interaction avec le LLM. Le module le plus simple, dspy.Predict, effectue un appel direct au modèle en suivant la signature fournie. dspy.ChainOfThought ajoute automatiquement une étape de raisonnement avant la réponse finale, sans que le développeur ait à formuler manuellement un prompt de type "Let's think step by step". dspy.ProgramOfThought génère du code Python intermédiaire pour résoudre des problèmes nécessitant du calcul. dspy.ReAct implémente le pattern Reasoning + Acting pour les tâches nécessitant l'utilisation d'outils externes. dspy.MultiChainComparison génère plusieurs chaînes de raisonnement et les compare pour sélectionner la meilleure réponse.

La puissance des modules réside dans leur composabilité. Un module DSPy est une classe Python standard qui peut instancier d'autres modules dans son constructeur et les orchestrer dans sa méthode forward(). Cette approche permet de construire des pipelines complexes de manière modulaire. Par exemple, un module de question-answering multi-hop peut combiner un module de décomposition de question, un module de recherche, et un module de synthèse, chacun avec sa propre signature et sa stratégie de raisonnement. Les modules maintiennent un état interne -- les paramètres appris par l'optimizer -- ce qui les rend analogues aux couches d'un réseau de neurones dans PyTorch.

Les Optimizers : le compilateur de prompts

Les optimizers constituent le coeur algorithmique de DSPy. Ils prennent en entrée un programme DSPy (composé de modules et de signatures), un jeu d'entraînement et une métrique d'évaluation, puis optimisent automatiquement les paramètres du programme pour maximiser cette métrique. L'optimizer BootstrapFewShot sélectionne automatiquement les meilleurs exemples few-shot parmi le jeu d'entraînement en exécutant le programme et en retenant les traces qui satisfont la métrique. BootstrapFewShotWithRandomSearch ajoute une exploration stochastique pour éviter les optima locaux. MIPRO (Multi-prompt Instruction Proposal Optimizer) optimise simultanément les instructions textuelles et les exemples few-shot en utilisant un processus bayésien. BootstrapFinetune va plus loin en générant des données de fine-tuning à partir des traces optimales pour entraîner un modèle spécialisé plus petit et moins coûteux.

Le processus d'optimisation fonctionne de manière itérative. L'optimizer exécute le programme sur le jeu d'entraînement, collecte les traces d'exécution (inputs, raisonnements intermédiaires, outputs), évalue chaque trace avec la métrique fournie, et ajuste les paramètres -- prompts, exemples few-shot, instructions -- pour améliorer les performances. Ce processus peut être vu comme une forme de méta-apprentissage : le LLM n'est pas fine-tuné au sens classique (les poids du modèle ne changent pas), mais le programme qui l'entoure est optimisé pour en tirer le meilleur parti.

• ▹Signatures : contrats déclaratifs entrée-sortie avec descriptions en langage naturel, équivalents aux interfaces de programmation
• ▹Modules : blocs de traitement composables (Predict, ChainOfThought, ReAct) analogues aux couches d'un réseau de neurones
• ▹Optimizers : compilateurs automatiques qui optimisent prompts, exemples few-shot et instructions via des métriques quantitatives

3 Compilation de prompts

La compilation de prompts est le mécanisme central qui distingue DSPy de toutes les autres approches d'orchestration de LLM. Le concept est fondamentalement simple mais ses implications sont profondes : un développeur écrit un programme déclaratif, et le compilateur DSPy transforme ce programme en un ensemble de prompts optimisés pour un modèle et une tâche donnés. Ce processus élimine le travail manuel de prompt engineering tout en produisant des résultats systématiquement supérieurs aux prompts artisanaux.

Le processus de compilation étape par étape

Le processus de compilation DSPy se déroule en plusieurs phases. Lors de la phase de bootstrapping, l'optimizer exécute le programme non optimisé sur chaque exemple du jeu d'entraînement. Pour chaque exécution, il collecte la trace complète : les inputs fournis, les raisonnements intermédiaires générés par les modules ChainOfThought, et les outputs produits. La métrique d'évaluation est ensuite appliquée à chaque trace pour déterminer si le résultat est satisfaisant. Les traces réussies sont stockées comme des demonstrations candidates -- des exemples few-shot potentiels que le compilateur pourra insérer dans les prompts finaux.

Lors de la phase de sélection, l'optimizer choisit parmi les demonstrations candidates celles qui maximisent les performances globales du programme. Cette sélection n'est pas triviale : il ne suffit pas de prendre les exemples avec les meilleurs scores individuels. L'optimizer doit tenir compte de la diversité des exemples (pour couvrir un maximum de cas d'usage), de leur compatibilité (certaines combinaisons d'exemples fonctionnent mieux que d'autres), et des contraintes de contexte (le nombre total de tokens ne doit pas dépasser la fenêtre de contexte du modèle). Les optimizers avancés comme MIPRO vont plus loin en optimisant simultanément les instructions textuelles du prompt : ils proposent différentes formulations des instructions, les évaluent sur le jeu de validation, et retiennent la combinaison instruction-examples la plus performante.

Portabilité entre modèles

L'un des avantages les plus significatifs de la compilation de prompts est la portabilité entre modèles. Un programme DSPy peut être recompilé pour un nouveau modèle sans modification du code source. Si une organisation décide de migrer de GPT-4o vers Claude Opus, ou de passer à un modèle open-source comme Llama 3 pour des raisons de coût ou de souveraineté des données, il suffit de relancer la compilation avec le nouveau modèle cible. L'optimizer ajustera automatiquement les prompts, les exemples et les stratégies de raisonnement aux spécificités du nouveau modèle. Cette propriété élimine le vendor lock-in qui affecte les applications reposant sur des prompts manuellement optimisés pour un modèle spécifique. En pratique, les équipes qui utilisent DSPy rapportent une réduction de 80 à 90 % du temps consacré aux migrations de modèles.

4 Retrieval-augmented modules

L'intégration entre DSPy et les systèmes de Retrieval-Augmented Generation (RAG) constitue l'un des cas d'usage les plus puissants du framework. Là où les pipelines RAG traditionnels (LangChain, LlamaIndex) reposent sur des prompts statiques pour guider l'utilisation des documents récupérés, DSPy permet d'optimiser conjointement la stratégie de récupération et la stratégie de génération. Le module dspy.Retrieve encapsule l'interaction avec un retriever -- qu'il s'agisse de ColBERTv2, Pinecone, Weaviate, Qdrant, Milvus ou tout autre moteur de recherche vectorielle -- et expose les documents récupérés comme des champs utilisables par les modules en aval.

RAG multi-hop avec DSPy

Le pattern RAG multi-hop illustre parfaitement la puissance de la composabilité de DSPy. Pour répondre à des questions complexes nécessitant la synthèse d'informations provenant de plusieurs documents, un module DSPy multi-hop effectue itérativement des recherches guidées par le raisonnement intermédiaire du modèle. À chaque hop, le module génère une sous-question basée sur le contexte accumulé, récupère les documents pertinents via le retriever, et intègre les nouvelles informations dans sa chaîne de raisonnement. Le programme dspy.Baleen, inclus dans les exemples officiels de DSPy, implémente ce pattern et démontre des performances supérieures aux pipelines RAG single-hop sur des benchmarks comme HotPotQA et MultiRC.

L'optimisation conjointe du retrieval et de la génération est possible grâce aux assertions DSPy (dspy.Assert et dspy.Suggest). Ces mécanismes permettent de définir des contraintes programmatiques sur les résultats intermédiaires. Par exemple, une assertion peut vérifier que les documents récupérés contiennent effectivement des informations pertinentes pour la question, qu'une réponse est cohérente avec les sources citées, ou qu'un raisonnement intermédiaire ne contient pas d'hallucinations factuelles. Lorsqu'une assertion échoue, DSPy peut automatiquement réessayer avec un backtracking, reformulant la requête de recherche ou ajustant le raisonnement jusqu'à satisfaire la contrainte.

Intégration avec les bases vectorielles

DSPy s'intègre nativement avec les principales bases vectorielles du marché. Le retriever model de DSPy supporte ColBERTv2 (intégré par défaut), mais des adaptateurs existent pour Pinecone, Weaviate, Qdrant, Milvus, ChromaDB et Faiss. L'avantage de cette intégration par rapport à une implémentation manuelle réside dans le fait que l'optimizer peut ajuster la stratégie de récupération -- nombre de documents à récupérer (k), reformulation de requêtes, filtrage des résultats -- en fonction des performances mesurées sur le jeu de validation. Dans un pipeline RAG classique, ces paramètres sont fixés manuellement et rarement réévalués. Avec DSPy, ils deviennent des hyperparamètres optimisables au même titre que les prompts et les exemples few-shot.

5 Évaluation et métriques

Le système d'évaluation de DSPy est indissociable de son processus de compilation. Contrairement aux frameworks concurrents où l'évaluation est un afterthought -- une étape optionnelle ajoutée après le développement -- DSPy place la métrique au centre du processus de développement. Sans métrique, pas de compilation possible. Cette contrainte architecturale force les développeurs à adopter une approche rigoureuse et quantitative dès le début du projet, ce qui se traduit par des systèmes plus robustes et plus fiables en production.

Types de métriques

DSPy supporte trois catégories de métriques. Les métriques programmatiques sont des fonctions Python classiques qui comparent la sortie du programme à la réponse attendue : exact match, F1 score, inclusion de mots-clés, validation de format. Elles sont rapides à évaluer et parfaitement reproductibles. Les métriques basées sur LLM utilisent un modèle de langage comme juge pour évaluer la qualité, la pertinence ou la fidélité d'une réponse. DSPy fournit un module dspy.evaluate.SemanticF1 intégré qui évalue la similarité sémantique entre la réponse produite et la réponse de référence. Les métriques composites combinent plusieurs critères pondérés : par exemple, 40 % de fidélité factuelle, 30 % de complétude, 20 % de concision et 10 % de qualité linguistique. Cette approche multi-critères reflète la réalité des systèmes en production où la qualité d'une réponse ne se réduit jamais à une seule dimension.

La fonction dspy.Evaluate fournit un framework d'évaluation structuré qui exécute le programme compilé sur un jeu de test, agrège les résultats par métrique, et génère des rapports détaillés incluant les cas d'échec pour le diagnostic. Les résultats peuvent être exportés au format compatible avec des outils de suivi d'expériences comme MLflow ou Weights & Biases. En 2026, DSPy intègre également des métriques spécifiques à la sécurité -- détection d'hallucinations, conformité aux guardrails, résistance aux injections -- qui permettent d'évaluer la robustesse d'un programme compilé et pas uniquement sa performance fonctionnelle.

6 DSPy vs LangChain vs LlamaIndex

La comparaison entre DSPy, LangChain et LlamaIndex est essentielle pour choisir le bon outil selon le contexte de chaque projet. Ces trois frameworks adressent le même problème fondamental -- orchestrer des LLM pour construire des applications -- mais adoptent des philosophies radicalement différentes qui se traduisent par des compromis distincts en termes de contrôle, d'optimisation et de complexité opérationnelle.

LangChain : orchestration impérative

LangChain est un framework d'orchestration impérative qui fournit des composants préfabriqués (chains, agents, retrievers, memory) que le développeur assemble manuellement. Les prompts sont écrits explicitement par le développeur, et toute optimisation repose sur l'itération manuelle. LangChain excelle dans la construction rapide de prototypes grâce à son écosystème riche (plus de 700 intégrations) et sa documentation abondante. Cependant, les prompts codés en dur rendent les applications fragiles face aux changements de modèles, et l'absence d'optimisation automatique signifie que la qualité du système dépend entièrement de l'expertise du développeur en prompt engineering. LangChain Expression Language (LCEL) améliore la composabilité mais ne résout pas le problème fondamental de l'optimisation manuelle des prompts.

LlamaIndex : spécialiste du RAG

LlamaIndex se positionne comme le framework spécialisé dans l'indexation et l'interrogation de données. Son écosystème d'ingestion de données (connecteurs pour PDF, bases de données, APIs, fichiers audio/vidéo), ses index sophistiqués (vector store, knowledge graph, tree index) et ses query engines optimisés en font le choix naturel pour les applications centrées sur la recherche documentaire. Cependant, comme LangChain, LlamaIndex repose sur des prompts statiques pour la phase de génération. Les response synthesizers utilisent des templates de prompts que le développeur peut personnaliser mais pas optimiser automatiquement. L'introduction de LlamaIndex Workflows améliore l'orchestration mais n'apporte pas d'optimisation systématique.

DSPy : l'approche déclarative et compilée

DSPy se différencie fondamentalement par son approche déclarative et son processus de compilation. Le développeur ne manipule jamais directement les prompts : il déclare des signatures, compose des modules, définit des métriques, et laisse l'optimizer compiler le programme. Cette approche présente des avantages mesurables : les programmes DSPy compilés surpassent systématiquement les prompts manuels de 10 à 40 % selon les benchmarks (Khattab et al., 2024), la portabilité entre modèles est native, et la maintenance est simplifiée car les changements de spécification se propagent automatiquement lors de la recompilation. En contrepartie, DSPy demande un investissement initial plus important -- définition rigoureuse des métriques, constitution de jeux d'entraînement, temps de compilation -- et son écosystème d'intégrations est moins étendu que celui de LangChain.

• ▹LangChain : prototypage rapide, vaste écosystème, mais prompts fragiles et optimisation manuelle
• ▹LlamaIndex : excellence en indexation et RAG, mais génération limitée par des prompts statiques
• ▹DSPy : optimisation automatique et portabilité native, mais courbe d'apprentissage et investissement initial plus élevés
• ▹Approche hybride : combiner LlamaIndex pour l'ingestion de données et DSPy pour l'optimisation de la génération est une stratégie de plus en plus adoptée en 2026

7 Cas pratiques

Pour passer de la théorie à la pratique, examinons trois cas d'usage concrets où DSPy apporte une valeur ajoutée mesurable par rapport aux approches traditionnelles de prompt engineering.

Cas 1 : Classification de vulnérabilités CVE

Un SOC (Security Operations Center) traite quotidiennement des centaines de bulletins CVE et doit les classifier par criticité, pertinence pour l'infrastructure et urgence de remédiation. Avec un prompt manuel, l'équipe obtient une précision de classification de 72 % sur leur jeu de test interne. En migrant vers DSPy, ils définissent une signature "cve_description, infrastructure_context -> severity, relevance, remediation_priority, justification" et un module ChainOfThought. L'optimizer BootstrapFewShotWithRandomSearch, alimenté par 200 CVE historiques classifiées manuellement, compile un programme qui atteint 89 % de précision -- une amélioration de 17 points sans écrire une seule ligne de prompt. Le programme compilé est ensuite recompilé pour un modèle Llama 3 70B hébergé localement, éliminant la dépendance à une API externe et les risques liés à la confidentialité des données d'infrastructure.

Cas 2 : Analyse multi-documents pour la conformité réglementaire

Un cabinet de conseil en cybersécurité doit analyser la conformité de ses clients par rapport au référentiel NIS2, en croisant les politiques de sécurité internes (documents PDF), les résultats d'audits précédents, et les exigences réglementaires. Un pipeline DSPy multi-hop combine un module de décomposition des exigences NIS2 en points de contrôle, un module RAG qui recherche les preuves de conformité dans les documents clients, et un module de synthèse qui produit un rapport structuré avec un statut de conformité par article. Les assertions DSPy vérifient que chaque point de contrôle est soutenu par au moins une preuve documentaire. Après compilation avec MIPRO, le système produit des rapports de conformité dont la qualité est jugée équivalente à celle d'un auditeur junior par un panel d'experts, tout en réduisant le temps de production de 5 jours à 3 heures.

Cas 3 : Chatbot technique multilingue

Une entreprise industrielle déploie un chatbot d'assistance technique pour ses clients internationaux. Le chatbot doit répondre en français, anglais, allemand et espagnol, en s'appuyant sur une base de connaissances technique de 15 000 documents. Le programme DSPy utilise un module de détection de langue, un module de reformulation de requête (pour standardiser les questions techniques indépendamment de la langue), un module RAG avec recherche multilingue, et un module de génération dans la langue détectée. Chaque module est optimisé avec des métriques spécifiques : précision de la détection de langue (99,2 %), pertinence des documents récupérés (NDCG@5), exactitude technique de la réponse (validée par des experts métier), et fluidité linguistique. Le programme compilé réduit le taux d'escalade vers le support humain de 45 % à 18 %, avec une satisfaction client mesurée à 4.3/5 sur les quatre langues.

8 Conclusion et perspectives

DSPy représente un changement de paradigme dans la manière dont nous construisons des applications basées sur des LLM. En remplaçant le prompt engineering manuel par une programmation déclarative compilée, le framework résout les trois problèmes majeurs qui freinent l'industrialisation de l'IA générative : la fragilité des prompts face aux changements de modèles, l'impossibilité de mesurer et d'optimiser systématiquement la qualité des outputs, et la dépendance excessive à l'expertise individuelle en formulation de prompts.

L'écosystème DSPy continue de s'enrichir en 2026. L'intégration avec DSPy Agents étend le framework aux systèmes agentiques avec gestion automatique des outils et des boucles de raisonnement. Le support des modèles multimodaux permet de définir des signatures acceptant des images, de l'audio ou de la vidéo en entrée. Les optimizers distribués réduisent le temps de compilation pour les programmes complexes en parallélisant les évaluations sur plusieurs GPU. La communauté open-source, forte de plusieurs milliers de contributeurs actifs, publie régulièrement de nouveaux modules, métriques et adaptateurs pour les bases vectorielles et les fournisseurs de modèles.

Pour les organisations qui développent des applications LLM en production, l'adoption de DSPy n'est plus une option avant-gardiste mais une nécessité opérationnelle. La capacité à recompiler automatiquement un programme pour un nouveau modèle élimine le vendor lock-in. L'optimisation basée sur des métriques garantit une qualité mesurable et reproductible. La modularité du code facilite la maintenance et l'évolution des systèmes. Et la séparation entre la logique applicative et l'implémentation des prompts permet aux équipes de se concentrer sur la valeur métier plutôt que sur la mécanique du prompt engineering.

• 1.Adopter l'approche déclarative pour tous les nouveaux pipelines LLM : définir signatures et métriques avant d'écrire le moindre prompt
• 2.Constituer des jeux d'évaluation de qualité : la compilation DSPy est aussi bonne que les métriques et les données qui la guident
• 3.Utiliser les assertions DSPy pour encoder les contraintes métier et garantir la fiabilité des outputs en production
• 4.Recompiler régulièrement à chaque mise à jour de modèle ou évolution des données d'entraînement pour maintenir les performances
• 5.Combiner DSPy avec LlamaIndex pour les pipelines RAG complexes : LlamaIndex pour l'ingestion, DSPy pour l'optimisation de la génération
• 6.Versionner les programmes compilés avec leurs métriques et leurs jeux de données pour assurer la traçabilité et la reproductibilité
• 7.Investir dans la formation des équipes : DSPy demande un changement de mindset du prompt engineering vers le génie logiciel déclaratif

À Propos de l'Auteur

Ayi NEDJIMI • Expert Cybersécurité & IA

Ayi NEDJIMI est un expert senior en cybersécurité offensive et intelligence artificielle avec plus de 20 ans d'expérience en développement avancé, tests d'intrusion et architecture de systèmes critiques. Spécialisé en rétro-ingénierie logicielle, forensics numériques et développement de modèles IA, il accompagne les organisations stratégiques dans la sécurisation d'infrastructures hautement sensibles.

Expert reconnu en expertises judiciaires et investigations forensiques, Ayi intervient régulièrement en tant que consultant expert auprès des plus grandes organisations françaises et européennes. Son expertise technique couvre l'audit Active Directory, le pentest cloud (AWS, Azure, GCP), la rétro-ingénierie de malwares, ainsi que l'implémentation de solutions RAG et bases vectorielles (Milvus, Qdrant, Weaviate) pour des applications IA d'entreprise.

20+Ans d'expérience

100+Missions réalisées

150+Articles & conférences

Conférencier et formateur reconnu en cybersécurité, Ayi anime régulièrement des conférences techniques et participe activement au développement de modèles d'intelligence artificielle pour la détection de menaces avancées. Auteur de plus de 150 publications techniques, il partage son expertise de haut niveau pour aider les RSSI et architectes sécurité à anticiper les cybermenaces émergentes et déployer des solutions IA de nouvelle génération.

Tous ses articles Demander un audit LinkedIn