La boucle OODA pour le prompt engineering : ce que cinq échecs m'ont appris

La boucle OODA du colonel John Boyd a été développée pour la prise de décision des pilotes de chasse dans les années 1960, où le pilote qui complétait le cycle observer-orienter-décider-agir le plus rapidement obtenait un avantage décisif, indépendamment des capacités de l’appareil. J’ai découvert que le même principe s’applique au prompt engineering — après que cinq échecs coûteux m’ont appris que la rédaction du prompt est l’étape la moins importante.¹

TL;DR

La boucle OODA (Observer, Orienter, Décider, Agir) fournit un cadre systématique pour le prompt engineering qui prévient le mode d’échec le plus courant : agir (rédiger un prompt) avant d’observer (comprendre le contexte complet). Après avoir construit 44 skills — chacun étant un prompt structuré avec une logique d’activation automatique — j’ai appris que le prompt lui-même ne représente qu’environ 20 % du résultat. Les 80 % restants relèvent de l’observation (de quel contexte le modèle a-t-il besoin ?), de l’orientation (quel type de tâche est cette tâche ?) et de la décision (quel pattern de prompt correspond au type de tâche ?). Le constructeur interactif ci-dessous vous guide à travers le cycle OODA complet. Le résultat : des prompts qui réussissent dès la première tentative plutôt que de nécessiter un raffinement itératif.

Le prompt qui a échoué cinq fois

Avant d’apprendre à observer avant d’agir, je rédigeais des prompts comme un développeur écrit du code : foncer directement vers la solution.

Échec n° 1 : l’évaluateur de blog. Ma première tentative de prompt d’évaluation de qualité pour un article de blog : « Évalue cet article de blog et attribue-lui une note de 1 à 10. » Le modèle a renvoyé un paragraphe vague avec « 7/10 » et aucun retour actionnable. J’ai itéré quatre fois avant de réaliser que le problème ne venait pas de la formulation du prompt — le problème était que je n’avais pas défini ce que signifiait « qualité ».

La correction OODA : J’ai passé 30 minutes à observer mon propre processus d’évaluation. J’ai identifié six dimensions spécifiques qui m’importaient : la valeur pour le lecteur (25 %), la précision technique (20 %), la qualité pédagogique (20 %), la qualité rédactionnelle (15 %), l’intégrité factuelle (15 %) et l’efficacité SEO (5 %). La grille pondérée est devenue le skill blog-evaluator, et chaque évaluation depuis a produit des scores cohérents et actionnables.²

Échec n° 2 : le réviseur de code. Mon premier prompt de revue : « Révise ce code pour détecter les bugs et les failles de sécurité. » Le modèle a renvoyé 15 observations, dont 12 étaient des remarques stylistiques mineures. Le rapport signal/bruit rendait la revue inutilisable.

La correction OODA : J’ai orienté la tâche en trois sous-tâches distinctes (correction, sécurité, conventions) et j’ai construit trois sous-agents réviseurs dédiés, chacun avec un accès restreint aux outils et des critères d’évaluation spécifiques. Le réviseur de correction ne signale que les erreurs de logique. Le réviseur de sécurité ne signale que les vulnérabilités OWASP. Le réviseur de conventions ne signale que les écarts par rapport aux patterns établis. Le bruit est tombé à quasi zéro parce que chaque prompt est étroitement ciblé sur une seule dimension.³

Échec n° 3 : le prompt de traduction. « Traduis cet article de blog en coréen. » Le modèle a traduit mais a perdu tout le formatage markdown, supprimé les références de notes de bas de page et réécrit les termes techniques qui auraient dû rester en anglais.

La correction OODA : J’ai observé ce que « traduire » signifiait réellement pour mon cas d’usage : préserver la structure markdown, préserver la numérotation des notes de bas de page, ne pas traduire les blocs de code, conserver les noms propres en anglais, adapter les expressions idiomatiques plutôt que de les translittérer. La liste de contraintes est devenue plus longue que l’instruction de traduction elle-même. Chaque contrainte a éliminé un mode d’échec que « traduis ceci » aurait produit.⁴

La boucle OODA appliquée au prompting

Phase 1 : Observer

Avant d’écrire un seul mot du prompt, observez l’espace du problème :

Quelle est la tâche réelle ? Pas la demande de surface, mais le besoin sous-jacent. « Résume ce document » signifie peut-être en réalité « extrais les trois décisions prises lors de cette réunion afin que je puisse assurer le suivi des actions à mener ».

Que doit savoir le modèle ? Énumérez le contexte requis pour une réponse correcte. Un contexte manquant produit des hallucinations. Un contexte excessif gaspille des tokens et peut distraire le modèle.

À quoi ressemble la sortie ? Définissez le format, la longueur, le ton et la structure de la sortie souhaitée avant de rédiger le prompt. Des attentes vagues sur la sortie produisent des sorties vagues.⁵

Liste de vérification d’observation : - [ ] Tâche réelle (pas la demande de surface) identifiée - [ ] Contexte requis énuméré - [ ] Format de sortie défini - [ ] Critères de succès spécifiés - [ ] Modes d’échec anticipés

Phase 2 : Orienter

Orientez la tâche dans l’espace des capacités du modèle :

Classification du type de tâche. La tâche est-elle une extraction (tirer des informations d’un texte fourni), une génération (créer du nouveau contenu), une transformation (convertir entre des formats), une analyse (évaluer et raisonner sur du contenu), ou une classification (catégoriser une entrée) ?⁶

Chaque type de tâche possède des patterns de prompt établis. Mes 44 skills reflètent ce pattern : le skill blog-evaluator utilise des patterns d’analyse (grille pondérée, notation structurée). Le skill blog-writer-core utilise des patterns de génération (règles de style, listes de contraintes, exemples de structures). Le skill citation-verifier utilise des patterns d’extraction (extraire les affirmations, les confronter aux sources).

Évaluation de la complexité. La tâche peut-elle être accomplie en un seul prompt, ou nécessite-t-elle une décomposition ? Règle empirique : si la tâche requiert plus de trois opérations cognitives distinctes, décomposez.

Mon système de délibération pousse la décomposition plus loin : lorsque la confiance est faible (score inférieur à 0,70), le système lance plusieurs agents pour explorer le problème indépendamment, puis classe leurs réponses par qualité. Les seuils de complexité pour un prompt unique varient, mais je décompose toute tâche qui mélange recherche, analyse et génération.

Cartographie des contraintes. Quelles contraintes s’appliquent ? Limites de tokens, exigences de format de sortie, besoins de précision factuelle, exigences de ton, considérations d’audience. Chaque contrainte devient une instruction explicite dans le prompt.

Phase 3 : Décider

Sur la base de l’observation et de l’orientation, décidez de l’architecture du prompt :

Sélection du pattern de prompt :

Attribution de rôle. Les rôles fonctionnent lorsque la tâche bénéficie d’une perspective particulière. Mon sous-agent security-reviewer reçoit le rôle « ingénieur sécurité senior révisant le code pour les vulnérabilités OWASP Top 10 » — le rôle concentre la sortie sur les préoccupations de sécurité. Les rôles échouent lorsque le rôle contredit la tâche (« Vous êtes un écrivain créatif » pour une tâche d’analyse factuelle).⁷

Phase 4 : Agir

Rédigez le prompt en utilisant les décisions de la phase 3. Le prompt suit une structure cohérente :

[ROLE] (if applicable)
[CONTEXT] (the information the model needs)
[TASK] (the specific instruction)
[FORMAT] (the expected output structure)
[CONSTRAINTS] (restrictions and requirements)
[EXAMPLES] (if using few-shot)

La structure n’est pas un modèle à remplir mécaniquement. La structure est une liste de vérification : les phases d’observation, d’orientation et de décision ont-elles produit suffisamment de clarté pour rédiger chaque section ? Si une section est floue, retournez à la phase antérieure appropriée.⁸

Ma bibliothèque de prompts : 44 skills comme prompts structurés

Mon système de skills Claude Code est essentiellement une bibliothèque de prompts organisée par type de tâche. Chaque skill suit la structure OODA :

---
description: FastAPI backend development patterns and conventions
allowed-tools: [Read, Grep, Glob, Edit, Write, Bash]
---
# FastAPI Development Expertise

## Project Structure
[CONTEXT: expected file layout, naming conventions]

## Route Patterns
[CONSTRAINTS: response format, error handling, dependency injection]

## Database Patterns
[CONSTRAINTS: SQLAlchemy 2.0+ async, Pydantic v2 models]

La description du skill gère l’observation (quand le skill doit-il s’activer ?). Le champ allowed-tools gère l’orientation (de quelles capacités la tâche a-t-elle besoin ?). Le corps gère la décision et l’action (quels patterns le modèle doit-il suivre ?).⁹

Le skill blog-writer-core encode 14 règles de style obligatoires — des contraintes que j’ai découvertes à travers des échecs :

1. Voix active uniquement (« Les ingénieurs ont installé » et non « a été installé par »)
2. Jamais de « ceci » comme sujet (toujours spécifier le référent)
3. Chaque affirmation citée avec une note de bas de page
4. Blocs de code étiquetés avec des identifiants de langage
5. Pas de tirets cadratins (utiliser des virgules ou des points-virgules)

Chaque règle existe parce que j’ai publié un article qui l’enfreignait. La règle n° 1 est née du hook blog-quality-gate qui a détecté 7 phrases à la voix passive. La règle n° 3 est née de la publication d’une affirmation non sourcée sur une statistique McKinsey. La phase d’observation OODA a identifié l’échec ; la contrainte dans le prompt empêche la récurrence.¹⁰

La boucle d’itération

La boucle OODA est intrinsèquement itérative. Après avoir agi (envoyé le prompt) et observé le résultat :

1. Observez la sortie : qu’est-ce qui est correct ? Qu’est-ce qui est erroné ? Qu’est-ce qui manque ?
2. Orientez l’écart : le problème relève-t-il du contexte (information manquante), du format (mauvaise structure), ou de la capacité (tâche trop complexe pour un seul prompt) ?
3. Décidez de la correction : ajoutez du contexte, ajustez les instructions de format, ou décomposez la tâche.
4. Agissez avec le prompt révisé.

Chaque cycle d’itération ne doit modifier qu’une seule variable. Modifier simultanément plusieurs éléments du prompt rend impossible l’identification de quel changement a produit quel effet.¹¹

Mon workflow d’évaluation de blog suit la boucle d’itération complète :

1. Lint (deterministic) → fix structural issues
2. Evaluate (LLM) → score on 6 dimensions
3. Critique (LLM) → identify specific improvements
4. Fix (LLM) → apply surgical improvements
5. Re-evaluate → verify score improved

Chaque étape utilise un prompt différent optimisé pour son type de tâche. L’étape de lint utilise l’extraction (trouver les violations). L’étape d’évaluation utilise l’analyse (noter selon la grille). L’étape de critique utilise la génération (produire des suggestions d’amélioration). L’étape de correction utilise la transformation (appliquer les modifications en préservant la structure). L’enchaînement produit de meilleurs résultats qu’un prompt monolithique unique du type « améliore cet article ».¹²

Points clés à retenir

Pour les ingénieurs qui construisent des fonctionnalités IA : - Appliquez le cycle OODA complet avant de rédiger des prompts ; 5 minutes d’observation et d’orientation économisent 30 minutes de raffinement itératif du prompt - Classifiez le type de tâche (extraction, génération, transformation, analyse, classification) avant de sélectionner un pattern de prompt ; chaque type possède des patterns établis qui surpassent le prompting générique - Construisez une bibliothèque de prompts organisée par type de tâche ; mes 44 skills représentent des patterns de prompts validés que je réutilise d’un projet à l’autre

Pour les équipes produit utilisant l’IA au quotidien : - Lorsqu’une sortie IA déçoit, diagnostiquez si l’échec se situe dans l’observation (mauvaise identification de la tâche), l’orientation (mauvaise approche), la décision (mauvais pattern de prompt) ou l’action (mauvaise formulation du prompt) ; la correction diffère selon la phase - Les contraintes préviennent davantage d’échecs que la formulation astucieuse des prompts ; les 14 règles obligatoires de mon rédacteur de blog produisent une qualité plus constante que n’importe quel « veuillez bien écrire »

Références