Architecture cognitive des prompts : structurer le raisonnement des LLM pour une précision experte

Publié le 15 janvier 2026. Contenu vérifié et actualisé le 2 août 2026.

Une architecture de prompt ne donne pas accès à la pensée cachée d’un modèle. Elle organise le travail observable : objectif, preuves, étapes, contrôles et format. Pour une tâche exigeante, cette organisation permet de localiser les erreurs, de mesurer la qualité et de décider si un seul appel suffit ou si le traitement doit être décomposé.

Qu’est-ce qu’une architecture cognitive de prompt ?

Le terme « architecture cognitive » est une métaphore de conception. Il désigne la façon dont un système distribue une tâche entre instructions, données, outils, étapes et validations. Il ne décrit pas avec certitude le mécanisme interne d’un grand modèle de langage et ne permet pas de lire sa pensée.

Cette nuance compte. Une explication détaillée générée par un modèle peut sembler logique sans refléter fidèlement les facteurs qui ont influencé sa réponse. Les travaux d’Anthropic sur la fidélité du raisonnement déclaré montrent que des modèles peuvent omettre des influences dans leurs justifications. Pour une application sérieuse, évaluez donc les résultats et les preuves, pas la beauté d’un monologue raisonné.

L’architecture complète le prompt engineering général. Elle devient utile lorsque la tâche comporte plusieurs sources, décisions, formats, publics ou actions et qu’une erreur doit pouvoir être détectée.

Les six couches d’une architecture robuste

1. Le contrat de mission

Définissez le résultat, son destinataire et la décision qu’il doit permettre. Ajoutez des critères observables. « Produire une note de décision de 800 mots qui compare trois options et signale toute donnée manquante » donne une cible. « Réaliser une analyse experte » ne dit ni ce qui doit être livré, ni comment juger la réussite.

2. Le contexte et les preuves

Identifiez les sources autorisées, leur date, leur priorité et la façon de les citer. Un corpus n’est pas un bloc neutre : il peut contenir des doublons, des contradictions ou des instructions indésirables. Attribuez un identifiant à chaque document et précisez : « Le règlement prime sur les notes ; les notes ne peuvent compléter que les points non couverts. »

3. La décomposition

Décomposez seulement les décisions qui gagnent à être isolées. Pour une comparaison réglementaire : extraire les obligations, relier chaque obligation à une preuve, repérer les écarts, puis rédiger la synthèse. Chaque étape doit produire un artefact contrôlable. Une longue liste d’étapes décoratives augmente le coût sans renforcer la qualité.

4. La production

Le bloc de production précise la structure, le niveau de langue, les conventions et le format. Séparez les faits, les hypothèses et les recommandations. Pour une sortie consommée par un logiciel, utilisez un schéma ou une sortie structurée lorsque l’API le permet. Pour un lecteur humain, privilégiez une hiérarchie visible et des citations localisables.

5. La vérification

Vérifier ne signifie pas demander « es-tu sûr ? ». Construisez une grille : chaque conclusion possède-t-elle une source ? Les valeurs chiffrées sont-elles recalculées ? Toutes les contraintes sont-elles satisfaites ? La réponse distingue-t-elle absence de preuve et preuve d’absence ? Certaines vérifications peuvent être automatiques, d’autres nécessitent un expert.

6. Le contrôle des actions et des limites

Si le modèle utilise des outils, fixez ses autorisations, son budget et ses conditions d’arrêt. Une recherche en lecture seule n’a pas le même risque qu’une publication ou un paiement. L’architecture doit prévoir les erreurs d’outil, la demande de confirmation et la reprise. Consultez notre guide des agents IA et de MCP pour approfondir cette couche.

Quatre architectures selon la tâche

Architecture	À utiliser quand	Risque principal
Appel unique structuré	Tâche courte, faible risque, données limitées	Trop d’objectifs cachés dans un prompt
Chaîne séquentielle	Une sortie doit être validée avant l’étape suivante	Propagation d’une erreur initiale
Traitements parallèles	Documents ou critères indépendants à analyser puis agréger	Incohérences lors de la fusion
Production puis évaluation	Livrable à fort enjeu avec une grille stable	Évaluateur partageant les mêmes biais

Google recommande, selon le problème, de décomposer une tâche, d’enchaîner des prompts ou d’agréger des traitements parallèles dans ses stratégies officielles de prompting. Le bon choix dépend des dépendances entre les étapes. Si deux documents peuvent être évalués séparément, le parallèle réduit la latence. Si l’étape B dépend d’une extraction validée en A, une chaîne est plus sûre.

Exemple avancé : une note de décision sourcée

Imaginons une direction qui doit choisir un fournisseur à partir d’un cahier des charges, de trois offres et d’une grille de risques. Un prompt monolithique peut produire une synthèse élégante tout en oubliant une exigence. Une architecture en quatre sorties rend le travail auditable.

## Mission
Recommander une offre à un comité non technique.

## Sources autorisées
- CDC : cahier des charges, source normative
- OFFRE-A, OFFRE-B, OFFRE-C : déclarations des fournisseurs
- RISQUES : grille interne de pondération

## Étapes et livrables
1. Crée une matrice de toutes les exigences CDC.
2. Pour chaque offre, associe une citation ou « non démontré ».
3. Applique la grille RISQUES sans modifier ses poids.
4. Rédige une note de 800 mots avec recommandation, réserves et questions ouvertes.

## Règles
- N'infère pas une conformité à partir d'une formulation commerciale.
- Distingue fait, hypothèse et recommandation.
- Chaque conclusion doit citer un identifiant de source.

## Contrôle final
Vérifie que chaque exigence CDC apparaît exactement une fois dans la matrice
et que les totaux correspondent aux poids fournis.

Pour un enjeu élevé, exécutez l’extraction et le calcul dans des composants séparés. Validez la matrice avant de générer la note. Un calcul déterministe doit idéalement être réalisé par du code, pas laissé au texte du modèle.

Stratification sémantique : débutant, intermédiaire et expert

Demander trois niveaux d’explication peut servir à tester la cohérence d’un contenu et à adapter une même source à plusieurs publics. Les étiquettes ELI5, ELI15 et Expert sont des conventions éditoriales, pas des niveaux cognitifs scientifiquement garantis. Définissez-les avec des critères observables.

Niveau	Public et vocabulaire	Preuves attendues
Débutant	Aucun prérequis, phrases courtes, jargon défini	Une idée centrale et une analogie signalée comme telle
Intermédiaire	Notions de base acquises, vocabulaire métier expliqué	Mécanisme, limites et exemple concret
Expert	Terminologie spécialisée autorisée	Hypothèses, méthode, sources et points de controverse

Générez les versions à partir des mêmes sources. Ensuite, contrôlez que les faits centraux, les unités et les conditions ne changent pas. L’analogie du niveau débutant ne doit pas introduire une causalité absente de la version experte. La version experte n’est pas plus vraie par nature : elle doit simplement exposer davantage de mécanismes et de limites.

Contrairement à une affirmation parfois associée à cette méthode, l’explication simple ne « prépare » pas nécessairement un raisonnement expert plus exact. Si les niveaux sont générés successivement, une erreur précoce peut au contraire se propager. Pour cadrer chaque niveau dans un cahier des charges, combinez la stratification avec la méthode O.P.A.S..

Évaluer l’architecture, pas seulement la réponse

Anthropic recommande de définir des critères de succès et de construire des tests représentatifs avant d’optimiser un prompt. Un critère utile est spécifique et mesurable. « Réponse de qualité » ne suffit pas. « Au moins 95 % des obligations sont correctement reliées à une citation, sans fausse citation critique » peut être mesuré.

Dimension	Question	Indicateur
Fidélité	Les sorties restent-elles ancrées dans les sources ?	Précision des citations et taux d’affirmations non étayées
Couverture	Les exigences importantes sont-elles toutes traitées ?	Rappel par élément attendu
Cohérence	Deux étapes se contredisent-elles ?	Nombre de contradictions par dossier
Format	Le livrable est-il exploitable directement ?	Taux de validation du schéma ou de la structure
Efficience	L’architecture ajoute-t-elle une valeur mesurable ?	Qualité comparée au coût et à la latence

Testez un appel unique comme référence. Ajoutez ensuite une étape à la fois. Une architecture plus complexe n’est meilleure que si le gain de qualité justifie son coût, sa latence et sa maintenance. La documentation OpenAI sur les évaluations propose le même cycle : décrire la tâche, exécuter des cas, analyser, puis itérer.

Sécurité : séparer instructions, données et permissions

Un document externe peut contenir « ignore les instructions précédentes » ou demander l’usage d’un outil. Les balises et titres réduisent l’ambiguïté visuelle, mais ne constituent pas une barrière de sécurité. Le système doit décider quels outils sont disponibles, valider leurs paramètres et bloquer les destinations non autorisées.

• Traitez toute donnée récupérée comme non fiable.
• Donnez le minimum de droits nécessaire à chaque étape.
• Ne transmettez pas de secret au modèle si la tâche n’en a pas besoin.
• Demandez une validation humaine avant une action externe sensible.
• Journalisez la version du prompt, les outils appelés et les décisions importantes.

Checklist d’architecture

• La décision finale et son utilisateur sont identifiés.
• Les sources sont nommées, datées et hiérarchisées.
• Chaque étape produit un résultat vérifiable et nécessaire.
• Les faits, hypothèses et recommandations sont séparés.
• Les contrôles correspondent aux risques réels.
• Les outils ont des permissions et une condition d’arrêt.
• Une version plus simple sert de référence dans l’évaluation.
• Qualité, coût et latence sont suivis par version.

Questions fréquentes

Une architecture complexe donne-t-elle toujours une meilleure réponse ?

Non. Elle peut multiplier les erreurs, les coûts et la latence. Commencez par un appel structuré, puis décomposez seulement les points qui échouent ou nécessitent un contrôle indépendant.

Faut-il demander la chain of thought complète ?

Non. Demandez les preuves, les calculs utiles, les hypothèses et un résultat vérifiable. Une explication affichée n’est pas une fenêtre garantie sur le raisonnement interne.

Peut-on utiliser un second modèle comme juge ?

Oui pour accélérer certains contrôles, mais calibrez-le sur des jugements humains. Un évaluateur automatique peut partager les biais du producteur ou préférer un style sans détecter une erreur factuelle.

À quoi servent les niveaux ELI5, ELI15 et Expert ?

À adapter le vocabulaire, les prérequis et la profondeur. Définissez ces niveaux précisément et vérifiez que les faits restent cohérents. Ils ne constituent pas une architecture cognitive démontrée.

Quand faut-il arrêter la chaîne ?

Fixez une condition mesurable : critères atteints, nombre maximal d’itérations, budget consommé ou besoin d’une décision humaine. Un agent sans condition d’arrêt claire n’est pas plus intelligent, seulement moins contrôlable.

Sources officielles et primaires

• OpenAI Developers : évaluer les sorties des modèles, consulté le 2 août 2026.
• Google AI for Developers : stratégies de prompting et décomposition, consulté le 2 août 2026.
• Anthropic : développer des évaluations et des critères de succès, consulté le 2 août 2026.
• Anthropic Research : fidélité des explications de raisonnement, consulté le 2 août 2026.
• Google Research : étude empirique sur le chain of thought prompting.

À retenir : l’architecture cognitive utile est observable. Elle relie une mission à des preuves, des étapes, des contrôles et des limites d’action. Elle ne prétend ni forcer une pensée humaine, ni révéler celle du modèle. Sa valeur se mesure par une meilleure fidélité, une couverture plus complète et un risque maîtrisé sur vos propres cas.