# D2 · Decomposing Work into Steps Découper une tâche en étapes inspectables à l’aide des schémas séquentiel, fan-out/fan-in, brouillon puis critique et extraire puis transformer, et éviter le mode de défaillance du méga-prompt. import { Accordions, AccordionItem, Tabs, TabItem } from '@prosefly/astro-components'; Ce domaine pèse **18 %** de l’examen blanc — environ **9 items sur 50** et la deuxième section la plus lourde. Il teste la compétence unique qui sépare le plus un prompteur compétent de quelqu’un qui construit des workflows fiables : prendre une tâche qui *ressemble* à une seule instruction et la découper en étapes nommées que vous pouvez inspecter, tester et corriger indépendamment. Le méchant récurrent ici est le **méga-prompt** — une instruction énorme qui tente de tout faire d’un coup et échoue de manières que vous ne pouvez pas diagnostiquer. ## Ce qu’il faut savoir La décomposition est l’acte de transformer « fais toute cette chose » en une séquence d’étapes plus petites, chacune avec une mission claire, de sorte que qualité, coût et défaillance soient tous visibles. Quatre schémas couvrent presque tous les workflows : **séquentiel** (l’étape B consomme la sortie de l’étape A), **fan-out/fan-in** (découper en morceaux parallèles, puis combiner), **brouillon puis critique** (produire, puis une passe distincte relit et révise), et **extraire puis transformer** (extraire des données structurées, puis agir sur la structure). Le mode de défaillance à reconnaître est le méga-prompt : il marche sur la démo, cache où il a échoué, et ne peut pas être amélioré parce que vous ne pouvez pas voir les jointures. Une bonne décomposition rend chaque étape assez petite pour être vérifiée et assez peu coûteuse pour tourner sur la capacité la plus légère qui convient. ## Objectifs d’apprentissage À la fin de cette page, vous devriez être capable de : 1. **Décomposer** une tâche composée en étapes nommées avec des entrées et sorties claires. 2. **Sélectionner** le bon schéma de décomposition — séquentiel, fan-out/fan-in, brouillon puis critique, extraire puis transformer — pour une tâche donnée. 3. **Diagnostiquer** le mode de défaillance du méga-prompt et expliquer pourquoi une seule étape échoue de façon opaque. 4. **Décider** de la bonne granularité : quand découper une étape davantage et quand découper ajoute un surcoût inutile. 5. **Router** chaque étape vers une capacité et un relecteur appropriés selon sa mission. --- ## 2.1 Pourquoi décomposer Un seul méga-prompt demande au modèle de garder de nombreux sous-objectifs à l’esprit d’un coup et de produire une réponse unique et mélangée. Trois choses tournent mal. | Problème du méga-prompt | Conséquence | | --- | --- | | Les sous-objectifs se disputent l’attention | Le modèle fait bien les faciles et abandonne ou bâcle les difficiles | | La défaillance est opaque | Quand la sortie est fausse, vous ne pouvez pas dire *quel* sous-objectif a échoué | | Rien n’est testable indépendamment | Vous ne pouvez pas corriger une partie sans réexécuter et revérifier l’ensemble | | Aucune place pour la revue | Un point humain doit se placer avant ou après tout le bloc, pas à l’étape risquée | La décomposition corrige les quatre : chaque étape a une mission (bien faite), une sortie visible (pour voir où ça a cassé), un test indépendant (pour la corriger isolément), et une place naturelle pour un point de revue. :::tip[Signal d’évaluation] Les énoncés décrivant une sortie « parfois juste, parfois avec une section manquante », « difficile à déboguer », ou « marche en démo mais pas en production » pointent vers un méga-prompt. La bonne réponse est presque toujours « le découper en étapes », pas « écrire un prompt plus long » ni « utiliser un modèle plus gros ». ::: ## 2.2 Les quatre schémas de décomposition ```text SÉQUENTIEL A ─► B ─► C chaque étape consomme la sortie de la précédente FAN-OUT / FAN-IN A ─┬─► B1 ─┐ découper en morceaux parallèles… ├─► B2 ─┼─► C …puis les combiner └─► B3 ─┘ BROUILLON PUIS Brouillon ─► Critique ─► Réviser une passe distincte relit le brouillon CRITIQUE EXTRAIRE PUIS Extraire la structure ─► Transformer sur la structure TRANSFORMER ``` | Schéma | À utiliser quand | Exemple | | --- | --- | --- | | **Séquentiel** | Le travail ultérieur dépend réellement du travail antérieur | Plan → brouillon → resserrer | | **Fan-out/fan-in** | Le travail se découpe en morceaux indépendants | Résumer 10 documents séparément, puis synthétiser un brief | | **Brouillon puis critique** | La qualité nécessite une relecture à l’œil neuf que le modèle rédacteur ne se donnera pas | Rédiger une politique → passe de critique distincte selon une check-list → réviser | | **Extraire puis transformer** | Vous avez besoin d’une structure fiable avant d’agir | Extraire des champs de factures → catégoriser les enregistrements structurés | ## 2.3 Décomposition séquentielle Le cas par défaut. La sortie de chaque étape est l’entrée de la suivante, donc une mauvaise étape précoce empoisonne tout l’aval — ce qui est exactement pourquoi le découpage aide : vous interceptez le mauvais plan avant de rédiger 2 000 mots dessus. **Exemple travaillé — une proposition prête pour le client :** ```text Rédige une proposition client complète pour le projet de migration CRM incluant périmètre, calendrier, tarification, risques, bios de l’équipe et un résumé exécutif, le tout cohérent avec nos conditions standard et cette transcription d’appel de découverte. ``` Un seul jet, six sous-objectifs. La tarification et le calendrier se désynchronisent ; le résumé exécutif résume une version qui n’existe plus ; vous ne pouvez pas dire quelle partie est fausse sans tout relire. ```text Étape 1 De la transcription, extraire périmètre, contraintes et dates → une liste à puces. Étape 2 De la liste de périmètre, produire un calendrier et un tableau de tarification. (CONTRÔLE : totaux) Étape 3 Rédiger les sections du corps à partir des étapes 1–2. Étape 4 Écrire le résumé exécutif EN DERNIER, à partir du corps terminé. Étape 5 Vérifier l’ensemble contre la check-list des conditions standard. ``` Chaque étape est inspectable ; le résumé exécutif est écrit en dernier pour qu’il corresponde ; le contrôle de tarification a lieu là où les chiffres sont produits. ## 2.4 Fan-out / fan-in Quand les morceaux sont indépendants, faites-les séparément et combinez. Cela relève la qualité (chaque morceau reçoit toute l’attention) et permet de paralléliser, mais l’étape **fan-in** est là où la cohérence est imposée. **Exemple.** Résumer douze rapports de ventes régionaux en un seul brief national. - **Fan-out :** résumer chaque rapport selon un mini-gabarit fixe (région, chiffre d’affaires, risque principal, un point fort). - **Fan-in :** synthétiser les douze mini-résumés en un brief national ; réconcilier terminologie et totaux ici. Le piège est de sauter la discipline du fan-in : douze résumés agrafés ensemble ne sont pas un brief. L’étape fan-in doit *réconcilier* (dédupliquer, totaliser, résoudre les contradictions), pas seulement concaténer. :::tip[Signal d’évaluation] « Dix documents indépendants », « plusieurs branches », « combiner les résultats » pointent vers fan-out/fan-in. Si l’énoncé insiste sur le fait que le résultat combiné doit être *cohérent*, la bonne réponse nomme la réconciliation faite au fan-in, pas les résumés parallèles. ::: ## 2.5 Brouillon puis critique Un modèle qui relit son propre brouillon *dans la même passe* tend à le défendre. Séparer la rédaction de la critique vous donne une relecture à l’œil neuf — idéalement contre une check-list explicite pour que la critique soit objective, pas au ressenti. ```text BROUILLON ─► produire le livrable CRITIQUE ─► une étape DISTINCTE note le brouillon contre des critères nommés (complétude, ton, affirmations factuelles signalées, items de check-list) RÉVISER ─► appliquer la critique ; éventuellement re-critiquer une fois ``` **Exemple — une réponse de support.** Rédiger la réponse ; puis une étape de critique vérifie : répond-elle à chaque question posée par le client ? le ton est-il conforme à la marque ? des affirmations factuelles sur le compte sont-elles non vérifiées ? Puis réviser. L’étape de critique est *aussi* le foyer naturel d’un point de revue humaine sur les réponses à plus fort enjeu. ## 2.6 Extraire puis transformer Quand une tâche doit *agir sur des données enfouies dans de la prose*, extraire d’abord les données en une structure fiable, puis transformer. Faire les deux dans un seul prompt fait que l’erreur d’extraction et l’erreur de transformation se confondent. **Exemple — traitement des dépenses :** ```text EXTRAIRE Lire chaque reçu → { vendor, date, amount, currency, category_guess } (travail de classe Luna : clair, répétable, structuré) TRANSFORMER Sur les enregistrements structurés → appliquer les règles de politique, signaler les cas atypiques, produire le tableau de remboursement. ``` Maintenant l’extraction est vérifiable indépendamment (le JSON correspond-il au reçu ?) et la transformation est une logique de politique déterministe que vous pouvez tester. Regroupées, un total erroné pourrait être un montant mal lu *ou* une règle mal appliquée — vous ne pouvez pas dire. ## 2.7 Choisir la granularité — quand est-ce trop petit La décomposition a un coût : chaque étape est un passage de relais, et les relais ajoutent de la latence et des endroits où perdre le contexte. Découpez une étape quand cela vaut la peine ; arrêtez quand ce n’est pas le cas. | Découper davantage quand… | Arrêter de découper quand… | | --- | --- | | L’étape a deux missions distinctes qui échouent séparément | Chaque étape a déjà exactement une mission | | Vous avez besoin d’une revue ou d’un contrôle *entre* deux parties | Le découpage ajoute un relais mais aucun nouveau point d’inspection | | Différentes parties veulent des capacités/modèles différents | Les deux parties veulent de toute façon la même capacité | | Une partie est réutilisée par d’autres workflows | L’étape est triviale et jamais réutilisée | L’objectif est des **étapes inspectables, à mission unique** — pas le nombre maximal d’étapes. Dix étapes qui font chacune un cinquième d’une mission sont leur propre anti-schéma. ## 2.8 Composer les schémas Les workflows réels combinent les schémas. La proposition du 2.3 est séquentielle dans l’ensemble, mais le contrôle des conditions de l’étape 5 est une *critique* ; un brief national est du *fan-out/fan-in* dont le fan-in est un *brouillon puis critique*. Nommez d’abord le schéma de premier niveau, puis le schéma à l’intérieur de chaque étape. ```text BRIEF NATIONAL (fan-out/fan-in) fan-out : extraire puis transformer sur chaque rapport régional fan-in : brouillon puis critique pour synthétiser + réconcilier ``` --- ## Cadre de décision **Le test SPLIT** — décider s’il faut découper une tâche et comment. Posez cinq questions dans l’ordre ; le premier « oui » vous indique le schéma. | # | Question | Si oui → | | --- | --- | --- | | **S** — Sous-objectifs | La tâche a-t-elle 2+ sous-objectifs distincts pouvant échouer séparément ? | Décomposer ; passer au choix du schéma | | **P** — Pipeline | Chaque partie dépend-elle de la sortie de la précédente ? | **Séquentiel** | | **L** — Lanes (voies) | Des morceaux indépendants tournent-ils en parallèle puis se combinent ? | **Fan-out/fan-in** (concevoir la réconciliation du fan-in) | | **I** — Inspecter | La qualité nécessite-t-elle une passe de relecture à l’œil neuf ? | **Brouillon puis critique** (écrire la check-list) | | **T** — Transformer les données | Devez-vous agir sur des données enfouies dans de la prose ? | **Extraire puis transformer** | Si **S** est « non » — une seule petite mission — gardez-la en une seule étape ; la décomposition n’ajouterait que du surcoût. La plupart des tâches réelles répondent « oui » à S puis à *deux ou plus* de P/L/I/T, ce qui explique pourquoi les schémas se composent. ## Erreurs fréquentes | Erreur | Pourquoi elle se produit | Que faire à la place | | --- | --- | --- | | Écrire un méga-prompt pour une tâche multi-objectifs | Ça marche dans la démo rapide | Découper en étapes nommées à mission unique inspectables | | Corriger un workflow défaillant en allongeant le prompt | L’instruction semble incomplète | Trouver quel sous-objectif échoue ; l’isoler, ne pas rembourrer le bloc | | Se tourner vers un modèle plus gros pour des défaillances opaques | La capacité semble être le levier | Décomposer d’abord ; souvent un modèle moins cher par étape suffit alors | | Agrafer les résultats du fan-out comme « le brief » | La concaténation ressemble à de la synthèse | Faire réconcilier, dédupliquer et totaliser l’étape fan-in | | Laisser le modèle critiquer son brouillon en une passe | C’est plus rapide | Utiliser une étape de critique distincte contre une check-list explicite | | Mélanger extraction et transformation | Un seul prompt paraît plus simple | Extraire d’abord en structure, puis transformer la structure | | Sur-découper en une douzaine d’étapes triviales | On suppose « plus d’étapes = plus robuste » | Découper seulement là où une étape a deux missions ou nécessite un contrôle entre les parties | | Écrire le résumé exécutif en premier | C’est la partie qui vous tient à cœur | Écrire résumés et abrégés *en dernier*, à partir du contenu terminé | ## Mise en situation **Situation.** Dan dirige les opérations marketing. Il a construit un workflow ChatGPT qui prend un brief produit et « produit un kit de lancement » : un article de blog, trois variantes sociales, un e-mail, une FAQ et un résumé d’une ligne — le tout dans un seul long prompt avec le brief collé dedans. La démo était superbe. En usage réel, c’est peu fiable : parfois la FAQ manque, les posts sociaux contredisent parfois une affirmation du blog, et une fois l’e-mail a cité un prix qui n’apparaît nulle part ailleurs. Quand la sortie est fausse, Dan ne peut pas dire quelle partie a cassé, alors il continue d’ajouter des phrases au prompt (« assure-toi que la FAQ est incluse », « garde les prix cohérents ») et cela empire. Son coéquipier suggère de passer au modèle le plus capable. **Trace de raisonnement expert.** 1. **Nommer le mode de défaillance.** C’est un méga-prompt d’école : cinq livrables distincts, des sous-objectifs concurrents, des défaillances opaques (FAQ manquante = sous-objectif abandonné ; affirmations contradictoires = aucune source de vérité partagée ; prix fantôme = fait halluciné sans endroit pour l’intercepter). Ajouter des phrases, c’est rembourrer le bloc — l’anti-schéma exact. 2. **Rejeter le réflexe du modèle plus gros.** Un modèle plus capable pourrait masquer certains abandons, mais il ne rend pas la défaillance *visible* ni *testable*, et il coûte plus cher par exécution pour une tâche à fort volume. La capacité n’est pas l’ingrédient manquant ; la structure l’est. 3. **Choisir le schéma de premier niveau.** Les cinq actifs sont largement indépendants → **fan-out/fan-in**. Mais ils doivent être *cohérents avec un ensemble de faits partagé*, donc le fan-in ne peut pas être de la concaténation. 4. **Concevoir d’abord la source de vérité partagée (extraire puis transformer).** Étape 0 : extraire les faits canoniques du brief — nom du produit, prix, trois affirmations clés, date de lancement — dans une « fiche de faits » structurée. Chaque actif en aval est généré *à partir de la fiche de faits*, pas du brief brut, ce qui tue à la racine les bugs d’affirmations contradictoires et de prix fantôme. 5. **Faire le fan-out des actifs.** Générer blog, social, e-mail, FAQ, résumé chacun comme sa propre étape, chacune consommant la fiche de faits. Une FAQ manquante est désormais impossible à cacher — c’est une étape nommée qui a tourné ou non. 6. **Faire le fan-in avec une critique.** Une étape finale brouillon puis critique vérifie chaque actif contre la fiche de faits (aucune affirmation en dehors ; le prix correspond) et contre une check-list de complétude (les cinq présents). Écrire le résumé d’une ligne *en dernier*, à partir du blog terminé. 7. **Router les capacités.** L’extraction est un travail structuré de classe Luna ; la rédaction est un modèle de milieu de gamme ; la critique est une passe de check-list. Moins cher par exécution *et* plus fiable que le méga-prompt unique sur le modèle haut de gamme. **La décision :** remplacer le méga-prompt par **extraire puis transformer (fiche de faits) → fan-out (cinq actifs) → fan-in brouillon puis critique (cohérence + complétude)**, pas un prompt plus long ni un modèle plus gros. Chaque défaillance que Dan a vue correspond à une étape désormais visible et testable : FAQ abandonnée (étape de fan-out), contradictions et prix fantôme (fiche de faits partagée + critique). ## Pièges de l’évaluation | Piège | Pourquoi c’est tentant | Le discriminant | | --- | --- | --- | | « Ajouter plus d’instructions au prompt pour corriger les abandons » | Le prompt semble sous-spécifié | Rembourrer un méga-prompt l’aggrave ; isoler le sous-objectif défaillant dans sa propre étape | | « Passer au modèle le plus capable » | La capacité semble le remède à la qualité | Un modèle plus gros cache les défaillances ; il ne les rend ni visibles ni testables | | « Concaténer les résumés parallèles en brief » | Les morceaux sont déjà écrits | Le fan-in doit réconcilier et totaliser, pas agrafer | | « Faire relire son brouillon par le modèle dans la même réponse » | C’est une étape de moins | L’auto-relecture en même passe défend le brouillon ; utiliser une étape de critique distincte | | « Faire l’extraction et le calcul dans un seul prompt » | Plus simple à écrire | Les erreurs mélangées sont indiagnosticables ; extraire en structure, puis transformer | | « Le découper en autant d’étapes que possible » | Plus d’étapes semble plus robuste | Le sur-découpage ajoute des relais sans nouvelle inspection ; découper seulement là où cela vaut la peine | | « Écrire le résumé exécutif en premier, c’est la priorité » | C’est ce que la direction lit | Les résumés dérivent du contenu écrit après eux ; les écrire en dernier | ## Questions d’entraînement Chaque item indique combien de réponses sélectionner. Décidez avant de dévoiler. A. Ajouter des phrases au prompt insistant pour que chaque section apparaisse B. Passer au modèle le plus capable C. Le décomposer en étapes nommées à mission unique de sorte que chaque section soit une étape inspectable D. Baisser la température **Réponse : C.** Les sections abandonnées et une sortie indéboguable sont la signature du méga-prompt ; décomposer fait de chaque section une étape qui a visiblement tourné ou non. Rembourrer le prompt (A) aggrave le bloc. Un modèle plus gros (B) cache les défaillances au lieu de les exposer. La température (D) ne traite pas la structure. A. Fan-out/fan-in B. Séquentiel C. Brouillon puis critique D. Extraire puis transformer **Réponse : B.** Un pipeline où B consomme A et C consomme B est séquentiel par définition. Le fan-out/fan-in (A) exécute des morceaux en parallèle. Brouillon puis critique (C) est un schéma de revue. Extraire puis transformer (D) est une forme spécifique en deux étapes, pas la chaîne de dépendance générale. A. Séquentiel ; l’étape critique est le premier résumé B. Fan-out/fan-in ; l’étape critique est la réconciliation du fan-in qui totalise et déduplique C. Brouillon puis critique ; l’étape critique est le brouillon D. Extraire puis transformer ; l’étape critique est l’extraction **Réponse : B.** Des morceaux indépendants combinés en une seule sortie, c’est du fan-out/fan-in, et la cohérence est imposée au fan-in, qui doit réconcilier plutôt que concaténer. Le séquentiel (A) ne convient pas à un travail indépendant. Brouillon puis critique (C) et extraire puis transformer (D) sont les mauvaises formes de premier niveau ici. A. Elle utilise moins de tokens B. Une auto-relecture en même passe tend à défendre le brouillon ; une passe distincte donne une relecture à l’œil neuf, idéalement contre une check-list C. Elle est toujours plus rapide D. Elle supprime le besoin de toute revue humaine **Réponse : B.** Relire dans la même passe porte le raisonnement qui a produit le brouillon ; une étape de critique distincte (surtout pilotée par check-list) est plus objective. Ce n’est pas une question de nombre de tokens (A) ni de vitesse (C). Elle ne supprime pas la revue humaine (D) — souvent l’étape de critique est là où vit le point humain. A. Brouillon puis critique B. Extraire puis transformer : extraire d’abord les champs structurés, puis appliquer les règles à la structure C. Un seul prompt plus détaillé D. Fan-out/fan-in sur les factures **Réponse : B.** Séparer l’extraction de la transformation basée sur des règles rend chacune vérifiable indépendamment, de sorte qu’un total erroné soit traçable à la lecture ou à la logique. Brouillon puis critique (A) relit de la prose, pas ceci. Un seul prompt détaillé (C) garde les erreurs mélangées. Le fan-out (D) parallélise mais mélange encore extraction et transformation par facture. A. Jamais — plus d’étapes est toujours plus robuste B. Quand chaque étape a déjà une mission et qu’un découpage supplémentaire ajoute un relais mais aucun nouveau point d’inspection C. Après exactement trois étapes D. Quand le prompt devient long **Réponse : B.** Le découpage vaut la peine seulement quand il sépare des missions distinctes ou ajoute un contrôle nécessaire ; au-delà, il ajoute de la latence et de la perte de contexte. « Plus est toujours mieux » (A) et un nombre fixe (C) sont faux. La longueur du prompt (D) n’est pas le critère. A. Rien — c’est ce que signifie le fan-in B. Le fan-in doit réconcilier, dédupliquer et totaliser, pas concaténer ; des résumés agrafés ne sont pas une synthèse C. Il devrait y avoir onze résumés D. L’étape fan-out devrait être séquentielle **Réponse : B.** Le fan-in est une étape de synthèse qui résout les contradictions et totalise les chiffres ; la concaténation saute le vrai travail de combinaison. La concaténation n’est pas du fan-in (A). Le nombre (C) est sans rapport. Le fan-out étant parallèle est correct (D). A. Écrire le résumé exécutif en premier pour qu’il donne la direction B. Écrire le résumé exécutif en dernier, généré à partir du corps terminé C. Écrire le résumé et le corps dans le même prompt D. Sauter le résumé **Réponse : B.** Un résumé doit décrire un contenu terminé, donc il est écrit en dernier dans la séquence. L’écrire en premier (A) garantit une dérive à mesure que le corps change. La génération dans le même prompt (C) est le piège du méga-prompt. Le sauter (D) échoue à l’exigence. A. Le modèle cher est interdit B. La décomposition rend les défaillances visibles et testables et laisse souvent des modèles moins chers gérer chaque étape ; un modèle plus gros ne fait que cacher les abandons à coût plus élevé C. Les modèles moins chers sont toujours plus précis D. La décomposition supprime le besoin de revue **Réponse : B.** Le problème est structurel, pas de capacité ; décomposer expose et isole les défaillances et permet de router les étapes vers des modèles plus légers. Le modèle cher n’est pas interdit (A). Les modèles moins chers ne sont pas toujours plus précis (C). La décomposition ne supprime pas la revue (D). A. La tâche doit agir sur des faits enfouis dans de la prose ou des documents B. La sortie doit être cohérente sur dix branches parallèles C. Vous avez besoin de données structurées fiables avant d’appliquer des règles ou des calculs D. Une passe de relecture à l’œil neuf est le principal levier de qualité E. Chaque étape dépend uniquement de l’heure de la journée **Réponse : A et C.** Extraire puis transformer s’applique quand vous devez extraire une structure de la prose puis agir sur cette structure de façon fiable. La cohérence sur des branches parallèles (B) pointe vers fan-out/fan-in. Une passe de relecture (D) pointe vers brouillon puis critique. L’heure de la journée (E) n’est pas un signal de décomposition. A. Dire au modèle de garder les prix cohérents B. Générer chaque actif à partir d’une unique « fiche de faits » extraite (extraire puis transformer) afin que tous les actifs partagent une seule source de vérité C. Générer les actifs deux fois et garder le lot le plus long D. Utiliser un modèle plus gros **Réponse : B.** Les contradictions viennent de ce que chaque actif invente ses propres faits ; une fiche de faits extraite et partagée donne une seule source de vérité dont tous les actifs tirent. Lui dire d’être cohérent (A) rembourre le prompt. Générer deux fois (C) double le coût sans corriger la cause. Un modèle plus gros (D) ne crée pas de source de vérité partagée. A. Résumé exécutif → corps → tarification → contrôle B. Extraire périmètre/dates → produire calendrier et tarification (contrôler les totaux) → rédiger le corps → écrire le résumé en dernier → contrôle des conditions C. Un seul prompt produisant tout d’un coup D. Tarification → résumé → périmètre → corps **Réponse : B.** Extraire d’abord, produire les chiffres avec un contrôle là où ils sont créés, rédiger à partir de ceux-ci, résumer en dernier, puis vérifier contre les conditions — chaque étape inspectable et le résumé correspondant au corps final. Le résumé en premier (A) dérive. Un seul prompt (C) est le méga-prompt. La tarification avant le périmètre (D) n’a aucune entrée à tarifer. A. Le sur-découpage a ajouté des relais sans nouveaux points d’inspection B. La tâche n’aurait jamais dû être décomposée du tout C. Les étapes devraient être fusionnées là où elles partagent une mission et ne nécessitent aucun contrôle entre elles D. Un modèle plus gros supprimerait les relais E. Les relais ne causent jamais de perte de contexte **Réponse : A et C.** La décomposition est un outil qui a un coût ; découper au-delà du point des missions distinctes ajoute latence et perte de contexte, donc le remède est de fusionner les étapes qui partagent une seule mission et ne nécessitent aucun contrôle intermédiaire. La tâche avait besoin de *quelque* décomposition (B). Un modèle plus gros (D) ne supprime pas les relais. Les relais causent bien une perte de contexte (E). A. Séquentiel seulement, un rapport après l’autre B. Fan-out (extraire puis transformer chaque rapport) → fan-in (brouillon puis critique pour synthétiser et réconcilier) C. Brouillon puis critique sur les douze rapports bruts d’un coup D. Un seul méga-prompt avec les douze collés dedans **Réponse : B.** Des rapports indépendants font le fan-out (chacun extrait en une mini-structure), et le fan-in synthétise avec une critique qui réconcilie termes et totaux — schémas composés pour convenir. Le séquentiel pur (A) ignore l’indépendance. Critiquer les douze bruts (C) saute la structure par rapport. Un seul méga-prompt (D) est l’anti-schéma. ## À retenir - La décomposition transforme « tout faire » en **étapes nommées à mission unique** individuellement inspectables, testables et peu coûteuses à exécuter. - Le **méga-prompt** échoue de façon opaque : sous-objectifs concurrents, parties abandonnées, aucune place pour contrôler ou relire. Son remède est la structure, pas un prompt plus long ni un modèle plus gros. - Quatre schémas couvrent l’essentiel du travail : **séquentiel**, **fan-out/fan-in**, **brouillon puis critique**, **extraire puis transformer** — et ils se **composent**. - Le **fan-in doit réconcilier**, pas concaténer ; la **critique doit être une passe distincte**, idéalement contre une check-list ; l’**extraction doit précéder la transformation** pour que les erreurs soient traçables. - Donner à chaque étape **une mission** ; une « fiche de faits » extraite et partagée est le remède à la cause racine des contradictions entre actifs. - Choisir la granularité délibérément : découper là où une étape a deux missions ou nécessite un contrôle entre les parties ; **arrêter** quand un découpage ajoute un relais mais aucune inspection. - Écrire les **résumés et abrégés en dernier**, à partir du contenu terminé. - Router chaque étape vers la **capacité la plus légère** qui fait sa mission — la décomposition rend souvent des modèles moins chers suffisants par étape.