Stratégie éditoriale — Petit traité de la transformation d'entreprise

Version : V2.0 — 2026-06-15 — Réalignement sur la structure réelle à 18 chapitres Statut : source de vérité éditoriale du projet — pilotage pour rédaction et relectures Usage : document de référence pour les agents FWK-Editorial et tout travail de relecture ou de rédaction Documents associés : 00-sommaire.md (source de vérité de structure), _meta/plan-editorial.md, 00-index.md Note V2.0 : la numérotation des chapitres a été corrigée (18 chapitres en numérotation continue Ch.1→Ch.18, P1 en 3 chapitres). L'ancienne grille (20 chapitres, numérotation locale par partie) est archivée dans _archive/_strategie_v1-avant-refonte-18ch.md. ARCHITECTURE-cible-v2.02.md est un document historique de cadrage (mars 2026) et n'est plus la référence de structure.

---

Règle de gouvernance

Ce fichier décrit COMMENT écrire le livre : identité, thèse, posture, ton, grammaire des chapitres, doctrine des éléments visuels, usage des frameworks, marqueurs de singularité, règles non-négociables. Il ne décrit pas le contenu chapitre par chapitre — cette fonction revient à ARCHITECTURE-cible-v2.02.md et 00-sommaire.md.

Toute modification de structure ou de chapitrage se fait dans l'architecture. Toute modification de ton, de doctrine éditoriale, de grammaire ou de règle qualité se fait ici.

---

1. Identité et ambition du projet

Titre : Petit traité de la transformation d'entreprise

Nature : Essai outillé — ni manuel prescriptif, ni catalogue théorique, ni autobiographie professionnelle. Un compagnon de pensée pour les praticiens qui conduisent ou traversent des transformations complexes.

Format : ~80 000 mots, 5 parties, 18 chapitres + préambule + synthèse + annexes. Diffusé en accès libre sur VitePress (licence CC BY-NC-SA), version PDF prévue après stabilisation web.

Ambition : Proposer une synthèse intellectuellement honnête sur ce que "transformer" signifie vraiment — avec les outils, les cadres, les limites et les postures que cela implique. Ni le premier livre sur la transformation, ni le dernier — mais un livre qui dit quelque chose de vrai, depuis l'intérieur de l'expérience.

Ce qui le distingue : L'auteur a appliqué à sa propre organisation ce qu'il recommande à ses clients (gouvernance distribuée, OKR, Scaling Up, rôles explicites). Ce livre vient de quelqu'un qui a lui-même traversé ce qu'il décrit — et qui n'en tire pas une victoire mais une lucidité.

---

2. Thèse et positionnement

2.1 Thèse centrale

Une transformation réussie n'est pas l'exécution d'un plan — c'est la conduite d'un apprentissage collectif sous contrainte.

Cette thèse a trois implications directes, qui doivent traverser l'ensemble du livre :

1. La transformation est d'abord un phénomène humain : les résistances ne sont pas des anomalies, elles sont de l'information. Les émotions font partie du système.
2. La transformation est un phénomène systémique : agir sur un élément produit des effets sur l'ensemble. La linéarité d'un plan est une simplification utile, jamais une vérité.
3. La transformation est un phénomène temporel : elle ne se fait pas en un moment, mais dans une durée dont personne ne maîtrise l'issue. La temporalité est la dimension la plus sous-estimée.

2.2 Promesse éditoriale

Voir clair, arbitrer utile, apprendre vite.

Ces trois verbes sont la boussole opérationnelle du livre, et doivent résonner à chaque chapitre :

• Voir clair : comprendre le système, nommer ce qui se passe réellement (pas ce que le plan dit qui devrait se passer), lire les signaux faibles.
• Arbitrer utile : prendre des décisions sous incertitude, prioriser par la valeur réelle (logique BOO), renoncer sans culpabilité à ce qui n'est pas essentiel.
• Apprendre vite : raccourcir la boucle de rétroaction, intégrer l'échec comme information, ne pas attendre le bilan de fin de programme pour corriger.

2.3 Positionnement par rapport au marché éditorial

Ce livre ne veut pas être "le guide ultime de la transformation". Il veut être l'ami lucide qui dit ce que les autres hésitent à écrire :

• Que les méthodes ont des limites que leurs auteurs n'avouent pas.
• Que les transformations "réussies" sont souvent moins réussies qu'annoncé.
• Que le vrai problème n'est presque jamais la méthode — c'est le système qui la reçoit.
• Que la congruence du leader est plus déterminante que le choix du framework.

---

3. Architecture globale

3.1 Structure en 5 parties + préambule + annexes

PRÉAMBULE (~4 500 mots)
  Posture, convictions, parcours de l'auteur, guide de lecture

PARTIE 1 — TRANSFORMER (~7 000 mots) [3 chapitres]
  Ch.1 — Les débuts d'une transformation
  Ch.2 — Pourquoi transformer ? — VUCA, Greiner, Scaling Up, CMMI
  Ch.3 — Comment transformer ? — Kotter, ADKAR, Lewin/Bridges, Knoster [clôt P1, ConclusionTransfo fin-de-partie]

PARTIE 2 — BÂTIR (~17 000 mots) [6 chapitres]
  Ch.4 — La vision comme moteur
  Ch.5 — L'autonomie conceptuelle ★ (chapitre le plus distinctif)
  Ch.6 — Le leader de transformation
  Ch.7 — L'ambition et la valeur : BHAG + BOO ★
  Ch.8 — De la stratégie à la feuille de route
  Ch.9 — Planifier la transformation [clôt P2, ConclusionTransfo fin-de-partie]

PARTIE 3 — DÉLIVRER (~20 000 mots) [5 chapitres]
  Ch.10 — La temporalité ★
  Ch.11 — Lancer et structurer le delivery
  Ch.12 — Apprendre en transformant
  Ch.13 — Piloter et mesurer la valeur
  Ch.14 — L'art de délivrer [synthèse P3, ConclusionTransfo fin-de-partie]

PARTIE 4 — PIÈGES ET ILLUSIONS (~8 000 mots) [4 chapitres]
  Ch.15 — Les plafonds de verre
  Ch.16 — Croyances, sponsors et acteurs
  Ch.17 — Les fausses transformations ★ (Canada Dry)
  Ch.18 — Convaincre sans manipuler [synthèse P4, ConclusionTransfo fin-de-partie]

PARTIE 5 — SYNTHÈSE : L'ART D'ASSEMBLER (~5 000 mots) [partie unitaire]
  Les 10 convictions revisitées
  La congruence comme boussole
  Voir clair, arbitrer utile, apprendre vite
  Invitation finale : l'excellence imparfaite

ANNEXES (~16 000 mots)
  A. Boîte à outils
  B. Lectures fondatrices
  C. Décodage critique de SAFe

3.2 Mouvement narratif d'ensemble

Le livre suit une progression en entonnoir — large à l'entrée, dense au centre, synthétique à la sortie :

P1 — Comprendre la transformation (fondations épistémiques)
        ↓
P2 — Construire le socle (vision, leader, ambition, plan)
        ↓
P3 — Mettre en mouvement (delivery, temporalité, apprentissage)
        ↓
P4 — Reconnaître les pièges (lucidité face aux illusions)
        ↓
P5 — Assembler (synthèse, congruence, posture)

Principe : on entre par la compréhension (P1), on construit (P2), on agit (P3), on démystifie (P4), puis on assemble et on prend de la hauteur (P5). Chaque partie peut se lire seule, mais c'est la progression d'ensemble qui construit la posture.

3.3 Chapitres de synthèse de partie

Le dernier chapitre de chaque partie clôt la partie par un <ConclusionTransfo> fin-de-partie : Ch.3 (fin P1), Ch.9 (fin P2), Ch.14 (fin P3), Ch.18 (fin P4), et P5 (fin de livre). Parmi eux, Ch.14 et Ch.18 sont de véritables chapitres de synthèse (récapitulatifs, sans nouveau framework) ; Ch.3 et Ch.9 conservent un contenu propre (modèles de conduite du changement pour Ch.3, planification pour Ch.9) tout en portant la clôture de partie. Ces chapitres de clôture sont structurellement différents des chapitres courants :

• Structure récapitulative : ce que la partie a construit, les liens entre chapitres, les arbitrages-clés
• Composant <ConclusionTransfo> obligatoire avec : synthèse du chapitre + synthèse de la partie + lien vers la partie suivante
• Volume cible : 1 500-2 000 mots (plus courts que les chapitres courants)
• Ton : délibérément synthétique, pas de nouveaux frameworks introduits

---

4. Public cible et personas

4.1 Les cinq personas

Persona	Profil	Besoin éditorial dominant	Chapitres-clés
Dirigeant / DG	Décideur qui sponsorise ou pilote une transformation	Voir clair sur les enjeux systémiques, savoir arbitrer sans se perdre dans la méthode	P1, P2 Ch.4-6, P4, P5
Responsable de transformation	DSI, DRH, directeur de programme en charge de la conduite	Trouver des cadres robustes pour structurer la démarche et gérer les résistances	P2, P3, outils en annexe
Manager intermédiaire	Responsable d'équipe qui vit la transformation de l'intérieur	Comprendre ce qu'on lui demande, comment s'y prendre sans perdre son équipe	P3 Ch.11-13, P4 Ch.15-16
Leader produit (PO/PM/SM)	Pilote opérationnel du delivery agile	Ancrer les pratiques agiles dans une logique de valeur plus large	P3, annexe A (WSJF, OKR, DOD/DOR)
Consultant / coach	Accompagnateur externe ou interne	Accès à une synthèse critique des frameworks, distance analytique	Tout le livre, annexe C (SAFe), Ch.5

4.2 Guide de lecture par profil

Si vous êtes...	Commencez par...	Évitez de sauter...
En amont d'une transformation	Préambule → P1 → P2 Ch.4-6	P2 Ch.5 (autonomie conceptuelle)
Déjà en mouvement	P3 Ch.10 (temporalité)	P4 (vous y êtes peut-être déjà)
En difficulté / résistances	P4 Ch.15-17	P2 Ch.6 (leader)
Consultant/coach	P1 → Ch.5 → Annexes	—
Pressé	P5 (synthèse) puis les chapitres ★	—

---

5. Ton, voix et style

5.1 Posture générale de l'auteur

Humble, incarné, lucide, exigeant — jamais dogmatique.

• Humble : l'auteur ne prétend pas avoir la vérité sur la transformation. Il partage ce qu'il a observé, pratiqué, raté et appris. Les formulations du type "dans mon expérience", "j'ai observé que", "ce que cela m'a appris" sont bienvenues dans les passages personnels et les récits de terrain (RecitTerrain).
• Incarné : chaque concept est ancré dans une situation, une tension, un dilemme réel. Pas d'abstraction flottante. L'exemple précède ou suit immédiatement le concept.
• Lucide : l'auteur nomme ce qui est difficile, ce qui échoue, ce qui résiste. Il ne surfe pas sur l'optimisme managérial.
• Exigeant : le livre demande un effort intellectuel au lecteur. Il ne mâche pas les conclusions. Il pose des questions plus qu'il ne délivre des réponses.
• Non dogmatique : aucun framework n'est présenté comme une vérité absolue. Tout est contextualisé : apports, limites, conditions d'applicabilité.

5.2 Voix narrative

Registre neutre et analytique dans les sections conceptuelles et les analyses de frameworks.

Registre direct et incarné dans les introductions de parties, les ouvertures de chapitres, et les passages de vigilance.

Registre personnel (première personne) uniquement dans les encarts <RecitTerrain> (voir §10). Ne jamais utiliser le "je" hors de ces encarts sauf exception documentée (préambule, bloc "Les transformations et moi").

5.3 Ce que le ton doit produire chez le lecteur

Le lecteur doit ressentir qu'il est entre les mains de quelqu'un qui a réellement traversé ce dont il parle, qui ne simplifie pas ce qui est complexe, qui respecte son intelligence, et qui n'essaie pas de lui vendre quelque chose.

5.4 Marqueurs de ton positif

• Affirmations nuancées : "X est souvent vrai, mais..." / "Dans la plupart des cas... sauf quand..."
• Mise en tension : "Ce que dit Kotter est juste — et pourtant, Bridges montre que..."
• Humilité épistémique : nommer les limites de ses propres modèles
• Concision dans les formules-clés : "Les méthodes sont des cartes, pas le territoire."
• Transitions narratives fortes entre sections et chapitres

5.5 Ce que les agents doivent éviter (mots interdits et patterns toxiques)

Ce qu'on évite	Pourquoi	Ce qu'on fait à la place
"Il est essentiel de..." / "Il est crucial de..."	Injonction vide, sans nuance	Formuler pourquoi c'est important dans CE contexte
"La transformation est un voyage..." (intro générique)	Cliché de la communication interne	Ancrer dans une situation précise
"Comme nous l'avons vu..." (référence vague)	Méta-discours inutile	Reformuler directement
Listes de 3 points sans hiérarchie	Perd la logique de priorité	Hiérarchiser ou argumenter le choix des 3
Jargon sans définition	Aliène les lecteurs non-spécialistes	Définir au premier usage
Slogans marketing ("l'agilité, c'est une culture !")	Ton militant, non analytique	Contextualiser, nuancer, citer les conditions
Généralisations absolues ("toutes les transformations...")	Inexact et peu utile	Préciser les conditions ou la fréquence
Autobiographie excessive	Ce n'est pas un mémoire de consultant	Transformer l'expérience en leçon transmissible

---

6. Ce que le livre évite

Ces positionnements négatifs sont aussi constitutifs de l'identité du livre que ce qu'il affirme.

Ce que le livre n'est pas	Ce que cela signifie concrètement
Un manuel prescriptif	Aucun framework n'est présenté comme "la" méthode à suivre
Un catalogue théorique	Chaque outil est contextualisé et mis en tension avec la réalité
Un plaidoyer pour l'agilité	SAFe est critiqué (annexe C), Scrum et Lean sont nuancés
Une autobiographie de consultant	Les expériences personnelles sont des encarts courts, jamais le fil principal
Un livre sur le change management classique	La dimension systémique et la temporalité dépassent le cadre ADKAR classique
Un livre pour initiés	Les frameworks sont expliqués pour des lecteurs qui n'en seraient pas familiers
Un livre qui rassure	Il dit ce qui est difficile, ce qui résiste, ce qui échoue souvent

---

7. Grammaire des chapitres

7.1 Structure standard d'un chapitre courant

Chaque chapitre courant (hors synthèse de partie) suit la séquence suivante — avec souplesse selon le sujet, mais sans en dévier fortement :

1. Contexte et enjeu — Pourquoi ce sujet maintenant, dans quelle tension s'inscrit-il ? (~200-400 mots)
2. Concept ou framework — Présentation du cadre principal du chapitre, avec ses apports ET ses limites. (~500-1 000 mots selon la complexité)
3. En pratique — Comment ça se traduit concrètement dans une transformation : exemples, patterns, illustrations (~600-1 000 mots)
4. Points de vigilance — Ce qui peut mal tourner, les pièges fréquents, les conditions qui changent tout (~300-500 mots)
5. RecitTerrain (optionnel, voir §10) — Récit personnel court ancrant le chapitre dans le vécu (~80-150 mots)
6. Renvois croisés — Liens explicites vers les chapitres qui éclairent ce sujet différemment ou qui approfondissent (~50-100 mots)

Volume cible par chapitre :

Type de chapitre	Volume cible	Composants obligatoires
Chapitre courant P2	2 500-3 500 mots	ChapitreHero, ConclusionTransfo ou transition
Chapitre courant P3	3 000-5 000 mots	ChapitreHero, ConclusionTransfo ou transition
Chapitre courant P4	1 500-2 500 mots	ChapitreHero, ConclusionTransfo ou transition
Chapitre courant P1	2 000-3 000 mots	ChapitreHero, ConclusionTransfo ou transition
Chapitre de clôture de partie (Ch.3, Ch.9, Ch.14, Ch.18)	1 500-2 000 mots	ChapitreHero, ConclusionTransfo fin-de-partie
Partie 5 (synthèse, partie unitaire)	~5 000 mots	ChapitreHero

7.2 Hiérarchie des titres

Niveau	Markdown	Usage
H1 #	Titre de partie ou de chapitre	1 seul par fichier
H2 ##	Sections principales du chapitre	3-6 par chapitre
H3 ###	Sous-sections	Utilisées avec parcimonie, seulement si la section est longue
H4 ####	Interdit dans les chapitres courants	Uniquement dans les annexes techniques

Règle clé : Jamais de H4 dans les chapitres narratifs. Si une section nécessite des sous-distinctions, utiliser les mini-blocs en gras inline (pattern : **Terme.** Développement...) plutôt que des sous-titres.

7.3 Encadrés récurrents

Encadré VitePress	Usage	Fréquence
::: tip	Apport-clé, principe important à retenir	1-3 par chapitre
::: warning	Point de vigilance, risque d'erreur fréquente	0-2 par chapitre
::: info	Définition, contextualisation, distinction conceptuelle	0-2 par chapitre
::: danger	Piège grave, contre-exemple fort	Rare, réservé aux passages critiques

À ne pas faire : multiplier les encadrés au point de fragmenter la lecture. Un chapitre avec plus de 6 encadrés VitePress au total est probablement fragmenté.

7.4 Tableaux

Les tableaux sont bienvenus quand ils synthétisent 3 dimensions ou plus en parallèle. Ils remplacent les listes redondantes et les paragraphes pseudo-parallèles ("Premièrement... Deuxièmement... Troisièmement...").

Signaux qui déclenchent un tableau :

• 3+ éléments qui répondent à la même question selon le même schéma
• Comparaison de frameworks sur plusieurs critères
• Apports vs limites vs conditions d'usage

À ne pas faire : tableau d'une ligne, tableau décoratif sans usage cognitif, tableau qui recopie le texte qui le précède.

---

8. Doctrine des éléments visuels

8.1 ImmersionPhoto

Rôle : créer une coupure visuelle narrative dans les pages d'introduction de partie et les chapitres les plus narratifs. Pas une illustration au sens strict — une respiration qui ancre émotionnellement le propos.

Usage :

• 1 à 2 occurrences par page d'introduction de partie (jamais dans les chapitres techniques denses)
• Placement : après le premier bloc de texte substantiel, jamais en tout début de page (laisser le ChapitreHero faire l'accroche)
• Légende : discrète, concrète, ancrée dans le sujet ("Lucidité et cohérence avant l'action", pas "La beauté de la transformation")

Syntaxe :

<ImmersionPhoto
  image="/images/illustrations/[nom-fichier].webp"
  alt="[description factuelle]"
  legende="[Courte légende incarnée — 5-10 mots]"
  ratio="paysage"
/>

Règles :

• Photo de format paysage minimum 16:9
• Pas de photo portrait
• Photos en couleur (ne pas forcer le filtre grayscale)
• Éviter les photos génériques de bureau ou de réunion — préférer les photos qui évoquent le mouvement, la complexité, la décision, la vision

8.2 SchemaImage

Rôle : intégrer un schéma explicatif d'un modèle ou d'un framework. Ne pas substituer le schéma au texte — il le complète.

Usage :

• Réservé aux frameworks à représenter visuellement (VUCA, Kotter, BOO, cône d'incertitude, etc.)
• 0 à 2 par chapitre maximum
• Toujours précédé d'une introduction textuelle qui prépare le lecteur à ce qu'il verra

Syntaxe :

<SchemaImage
  src="/images/schemas/[nom-fichier].webp"
  alt="[Nom du modèle ou du concept représenté]"
  legende="[Description courte de ce que le schéma montre]"
/>

8.3 Schémas Mermaid (nouveau — à intégrer)

Rôle : diagrammes générés directement en Markdown pour visualiser des flux, des matrices de décision, des timelines et des dynamiques relationnelles. Avantage sur les images : modifiables, accessibles, indexables.

Cas d'usage prioritaires :

• Logique BOO (Bénéfices → Outcomes → Outputs) : diagramme de flux
• Cône d'incertitude : diagramme de forme avec zones annotées
• Dynamique acteurs / résistances : matrice 2×2 ou graphe de relations
• Timeline de transformation : gantt ou séquence temporelle
• Cycles d'apprentissage (PDCA, boucle double) : diagramme de flux cyclique
• Comparaison de modèles (Kotter vs ADKAR) : tableau ou graphe

Syntaxe type :

```mermaid
flowchart TD
    B[Bénéfices\nattendue] --> O[Outcomes\ncibles]
    O --> OUT[Outputs\nlivrés]
```

Doctrine d'usage :

• Ne pas utiliser Mermaid pour des schémas très complexes (plus de 8 noeuds) — préférer une SchemaImage dans ce cas
• Le schéma Mermaid est toujours précédé d'un titre H3 ou d'une phrase d'introduction
• Légende courte après le bloc de code si le diagramme l'exige
• Tester le rendu VitePress avant publication (certains types Mermaid sont mal supportés)
• Types validés VitePress : flowchart, sequenceDiagram, gantt, quadrantChart

8.4 IllustrationImage

Rôle : illustration in-flow, moins immersive que ImmersionPhoto, plus contextuelle. Intégrée dans la grille de lecture normale.

Usage :

• Dans les chapitres P2 et P3 pour enrichir visuellement une section
• Maximum 2 par chapitre
• Format in-flow (ne sort pas de la grille de lecture)

Syntaxe :

<IllustrationImage
  src="/images/illustrations/[nom-fichier].webp"
  alt="[description]"
  legende="[légende courte]"
/>

---

9. Composants Vue et patterns éditoriaux

9.1 ChapitreHero

Rôle : bandeau visuel et informatif en tête de chaque chapitre ou page de partie. Auto-câblé via le frontmatter — ne pas l'appeler manuellement à l'intérieur du texte.

Frontmatter requis :

---
title: "Ch.X — Titre"
description: "Description courte du chapitre"
partie: N
image: "/images/illustrations/[nom-fichier].webp"
---

Règle : <ChapitreHero /> se place en premier dans chaque fichier .md, avant tout contenu markdown.

9.2 ChapitreCardsTransfo

Rôle : grid de cards présentant les chapitres d'une partie, avec numéro, titre, "moment" et description courte. Utilisé exclusivement dans les pages d'introduction de partie.

Usage :

<ChapitreCardsTransfo :partie="2" />

Le composant charge les données des chapitres en interne selon la prop :partie. Ne pas dupliquer ces données dans le markdown.

Placement dans les pages d'intro : après la section "## Les chapitres", avant l'ImmersionPhoto finale.

9.3 ConclusionTransfo

Rôle : carte de synthèse en fin de chapitre, hors TOC (composant Vue, pas de H2/H3). Remplace les sections "Synthèse" et "Ce qu'il faut retenir" qui alourdissent la TOC.

Trois comportements selon le contexte :

1. Milieu de partie (chapitres courants) : synthèse du chapitre en 3-5 phrases + lien vers le chapitre suivant
2. Fin de partie (Ch.3, Ch.9, Ch.14, Ch.18) : synthèse de la partie + bouton "Partie suivante" mis en avant
3. Fin de livre (P5, synthèse finale) : synthèse de la partie 5 + lien retour accueil

Syntaxe — milieu de partie :

<ConclusionTransfo
  synthese="3-5 phrases qui cristallisent ce que le chapitre apporte."
  vers-titre="Titre du chapitre suivant"
  vers-lien="/url-du-chapitre-suivant"
  vers-amorce="2-3 phrases d'invitation qui donnent envie de continuer."
/>

Syntaxe — fin de partie :

<ConclusionTransfo
  synthese="Synthèse du dernier chapitre de la partie."
  :fin-de-partie="2"
  synthese-partie="4-6 phrases qui retracent l'arc de toute la partie."
  vers-partie-titre="Partie 3 — Délivrer"
  vers-partie-lien="/delivrer/"
/>

Règle : <ConclusionTransfo> se place toujours en tout dernier élément du fichier markdown — après tout le contenu, après les renvois croisés.

9.4 Structure des pages d'introduction de partie

Pattern obligatoire pour les fichiers P[N]-intro.md (ou P[N]-[nom].md si partie unitaire) :

---
frontmatter complet avec title, description, partie, image
---

<ChapitreHero />

# Partie N — [Titre] {#partie-N}

[Introduction de 3-5 paragraphes — pose la thématique, les tensions, le mouvement narratif]

## Ce que cette partie construit

[2-3 paragraphes — apports cumulatifs des chapitres, logique de la séquence]

## Les chapitres

<ChapitreCardsTransfo :partie="N" />

<ImmersionPhoto ... />

## Ch.X — [Preview du premier chapitre]

[1-2 paragraphes d'invitation au premier chapitre]

[Lien → vers le chapitre]

Note : les parties unitaires (P1, P5) ont une structure plus libre, sans ChapitreCardsTransfo. Elles peuvent développer directement leur contenu après la section "Ce que cette partie construit".

---

10. Les témoignages personnels (RecitTerrain)

10.1 Définition et usage

Les RecitTerrain sont des encarts courts relatant une transformation réellement vécue par l'auteur. Ils servent trois fonctions que les encadrés analytiques ne remplissent pas :

1. Ancrer les frameworks dans le réel : pas une règle abstraite, un moment où la règle a manqué ou changé quelque chose.
2. Donner une voix de praticien : le livre est écrit par quelqu'un qui a traversé des transformations — ces récits le montrent.
3. Désacraliser l'apprentissage : les transformations s'apprennent par confrontation, pas seulement par lecture. L'auteur l'assume.

Format : contexte court + décision + résultat + leçon transmissible.

Volume cible global : 3 à 6 récits sur l'ensemble du livre. Distribution harmonieuse — éviter les chapitres purement analytiques ou les chapitres annexes.

10.2 Format type

Garde-fous éditoriaux :

• Le récit est ponctuel, court, lucide. Il ne raconte pas une performance, il raconte une prise de conscience — le moment où quelque chose a basculé, où une décision a été difficile, où le système a résisté autrement que prévu.
• Voix : première personne assumée (« je »), en rupture nette avec le registre neutre du corps du texte. Le lecteur doit savoir qu'il bascule dans un autre registre.
• Leçon obligatoire : chaque récit se clôt sur une ligne qui sort du « je » et redevient transmissible. Si la leçon n'est pas évidente, le récit n'a pas sa place.

Composant (à créer ou à coder en CSS custom VitePress) :

<RecitTerrain
  contexte="[Entreprise / secteur / moment de la transformation — 1-2 phrases]"
  recit="[80-150 mots à la première personne. Sobre, factuel, resserré sur la situation et la prise de conscience.]"
  lecon="[1-2 phrases. La leçon transmissible, qui sort du « je » et rejoint le propos du chapitre.]"
/>

En attendant l'implémentation Vue, fallback markdown acceptable :

> **Récit — [Contexte court]**
>
> [Corps du récit en italique — 80-150 mots]
>
> *Ce que j'en retiens : [Leçon transmissible]*

10.3 Critères de qualité pour un RecitTerrain

Un bon récit doit passer les trois tests suivants :

1. Test de la leçon : la leçon finale est-elle réellement transmissible à quelqu'un qui n'a pas vécu la même chose ? Si non, le récit reste anecdotique.
2. Test de la tension : y a-t-il un moment de bascule, une décision difficile, une résistance inattendue ? Un récit sans tension est une illustration, pas un enseignement.
3. Test de l'humilité : l'auteur se met-il en scène comme quelqu'un qui apprend — pas comme quelqu'un qui a raison ? Un récit qui se lit comme une success story n'a pas sa place.

Chapitres-candidats préférentiels :

Chapitre	Thème	Type de récit possible
Ch.5 — Autonomie conceptuelle	Moment où un framework imposé a bloqué la pensée	Prise de conscience sur l'enfermement conceptuel
Ch.6 — Leader	Moment de non-congruence perçue par l'équipe	Ce que ça révèle sur le leader dans la transformation
Ch.10 — Temporalité	Décalage entre le plan et le rythme réel	Apprentissage sur la gestion du temps long
Ch.12 — Apprendre	Boucle de rétroaction qui a changé une décision	Ce que "apprendre vite" signifie en pratique
Ch.17 — Fausses transformations	Diagnostic d'un Canada Dry reconnu trop tard	Signaux d'alerte ignorés

---

11. Frameworks mobilisés — doctrine d'usage

11.1 Principe général

Chaque framework est présenté selon le même schéma en quatre temps :

1. Ce qu'il apporte : le problème qu'il résout, la valeur qu'il crée dans son contexte d'origine
2. Ses limites : ce qu'il ne voit pas, les hypothèses implicites qui limitent son applicabilité
3. Conditions d'usage : dans quels contextes il est pertinent, dans lesquels il devient contre-productif
4. Comment l'utiliser sans en être prisonnier : l'intégrer comme une ressource, pas comme une règle

11.2 Cartographie des frameworks par partie

Partie 1 — Transformer

• VUCA : grille de lecture de l'environnement. Utile pour contextualiser, mais ne dit rien sur ce qu'on fait.
• Greiner : cycles de croissance et crises de développement. Libère la culpabilité — les plafonds sont structurels.
• CMMI : niveaux de maturité organisationnelle. Utile pour situer, pas pour prescrire le chemin.
• Scaling Up (Harnish) : paliers de croissance et conditions de passage. Concret et opérationnel.
• Kotter (8 étapes) : cadre séquentiel de la transformation. Utile comme checklist, insuffisant comme modèle de réalité.
• ADKAR : transformation au niveau individuel. Rappelle que le collectif est fait d'individus.
• Lewin / Bridges : transitions émotionnelles. La phase "zone neutre" est la plus sous-estimée.
• Knoster : diagnostic des blocages systémiques. La checklist la plus pragmatique pour diagnostiquer pourquoi ça bloque.

Partie 2 — Bâtir

• BHAG (Collins) : ambition à long terme. Puissant mais à manier avec prudence — peut figer dans des visions inadaptées.
• BOO (Bénéfices / Outcomes / Outputs) : architecture de pilotage par la valeur. Fil rouge du book.
• BMC (Business Model Canvas) : représentation du modèle stratégique. Outil de dialogue, pas de vérité.
• Effet volant (flywheel) : momentum organisationnel. Utile pour penser la dynamique d'accélération.
• Cône d'incertitude : gestion de la planification sous incertitude. Oblige à reconnaître l'ignorance.
• Planification en oignon : découpage temporel en cercles concentriques. Antidote au plan trop détaillé.
• One-Page Strategic Plan : outil de synthèse de la feuille de route.

Partie 3 — Délivrer

• PDCA (Deming) : boucle d'apprentissage. Base de tout pilotage itératif.
• WSJF (Weighted Shortest Job First) : priorisation économique. Sort du "tout est prioritaire".
• OKR : objectifs et résultats-clés. Puissant quand bien utilisé, cosmétique quand mal compris.
• Scrum : cadre agile de livraison itérative. Présenté avec ses conditions et ses limites.
• Lean / MVP : réduction du gaspillage, validation rapide. Fondamentaux à connaître.
• SECI / Nonaka : modèle de conversion des connaissances. Éclaire la dimension "apprendre en transformant".
• Tuckman : dynamique de groupe. Réaliste sur les phases de cohésion d'équipe.
• Dunning-Kruger : biais de compétence. Utile pour contextualiser les phases d'apprentissage.
• Shu-Ha-Ri : stades de maîtrise dans l'apprentissage agile. Évite le piège de l'application aveugle.
• DoR / DoD : critères de qualité d'entrée et de sortie. Rigueur opérationnelle du delivery.
• Gouvernance distribuée / Holacratie : modes d'organisation alternatifs.

Partie 4 — Pièges

• Canada Dry (anti-pattern) : transformations de façade qui ont "la couleur et l'odeur" sans la substance.
• Dynamique d'acteurs : lecture politique des résistances.

Annexe C — SAFe

• SAFe (Scaled Agile Framework) : traitement spécifique et critique. Voir doctrine §11.3.

11.3 Traitement spécifique de SAFe

SAFe fait l'objet d'un décodage critique en annexe C. La doctrine :

• SAFe est présenté comme un framework de passage — utile pour des organisations qui ont besoin d'un cadre structurant fort à grande échelle, mais qui génère souvent de la bureaucratie agile.
• La critique n'est pas un rejet — c'est une mise en contexte. SAFe peut avoir du sens dans certains contextes (grandes organisations très silotées, besoins forts de synchronisation inter-équipes) et être contre-productif dans d'autres.
• Le ton est analytique, pas militant. Pas de "SAFe tue l'agilité" — mais "voici ce que SAFe fait et ne fait pas, et dans quelles conditions c'est justifié".

---

12. Marqueurs de singularité

Ces cinq éléments sont les points de différenciation les plus forts du livre. Les agents doivent les renforcer systématiquement et ne jamais les affaiblir ou les diluer.

12.1 La congruence — fil rouge en trois dimensions

La congruence traverse tout le livre comme le fil conducteur principal, notamment dans P2 Ch.6, P5, et les annexes.

Trois dimensions de la congruence :

1. Congruence du leader : l'alignement entre ce que le leader dit, ce qu'il fait, et ce qu'il incarne au quotidien. Un leader qui demande l'agilité en imposant la bureaucratie ne peut pas conduire une vraie transformation.
2. Congruence organisationnelle : la cohérence entre la stratégie, la structure, les processus, et les comportements réels. Le Canada Dry est l'anti-pattern de la congruence organisationnelle.
3. Congruence temporelle : l'alignement entre les ambitions annoncées et le temps réellement alloué. La transformation ne se fait pas en 6 mois si le système organisationnel met 18 mois à changer ses habitudes.

12.2 L'autonomie conceptuelle — le chapitre le plus distinctif

Ch.5 est le chapitre qui différencie le plus ce livre de ses concurrents. L'idée centrale : les organisations qui transforment le mieux ne sont pas celles qui appliquent le mieux les frameworks — ce sont celles qui pensent avec leurs propres cadres. L'autonomie conceptuelle, c'est la capacité à mobiliser les frameworks comme des ressources et non comme des autorités.

Ce chapitre doit être dense, exigeant, argumenté. Il peut déconcerter le lecteur habitué aux livres de management prescriptifs — c'est intentionnel. Les agents ne doivent jamais le simplifier au point de l'édulcorer.

12.3 La temporalité — la dimension la plus sous-estimée

Ch.10 est le chapitre qui dit le plus clairement ce que les autres livres de transformation esquivent : le temps n'est pas un planning, c'est une réalité organisationnelle. Les transformations échouent souvent non par manque de méthode, mais par incapacité à tenir dans la durée, à résister à la pression du court terme, à traverser la "vallée de la mort" sans abandonner.

Ce chapitre doit rester long et dense — c'est voulu. C'est le plus riche de P3.

12.4 La logique BOO

Le modèle BOO (Bénéfices / Outcomes / Outputs) est l'architecture de valeur du livre. Il est introduit en Ch.7 et doit résonner dans tous les chapitres de P3 (Ch.10 à Ch.14). L'idée centrale : une transformation pilotée par les Outputs (livrables) sans remonter aux Outcomes (résultats mesurables) et aux Bénéfices (valeur réelle pour les parties prenantes) est une transformation qui ne sait pas ce qu'elle fait vraiment.

BOO est un antidote au reporting de façade et au "project completion bias" — la tendance à déclarer victoire quand les livrables sont produits, indépendamment de leur impact réel.

12.5 La critique des transformations de façade (Canada Dry)

Ch.17 est le chapitre où le livre prend le plus de risques éditoriaux — parce qu'il nomme ce que beaucoup d'organisations vivent sans se l'avouer. Le Canada Dry, c'est la transformation qui a la couleur et l'odeur de la vraie transformation, sans en avoir la substance.

Ce chapitre inclut plusieurs anti-patterns : le Canada Dry stricto sensu, le bashing de frameworks (critiquer les méthodes pour éviter de se transformer), et les auto-goals (les transformations qui détruisent la valeur qu'elles prétendent créer).

Ce chapitre est percutant, direct, lucide — sans être cynique. Il doit rester constructif : nommer le problème pour mieux s'en sortir.

---

13. Convictions structurantes (invariants)

Ces dix convictions sont énoncées dans le préambule et revisitées en P5. Elles ne doivent jamais être contredites par le contenu des chapitres — au contraire, chaque chapitre les illustre sous un angle différent.

1. L'entreprise n'est pas une machine mais un système complexe
2. La transformation est d'abord humaine et culturelle
3. L'autonomie conceptuelle est un avantage stratégique décisif
4. Le leader de transformation se transforme d'abord lui-même
5. L'ambition doit être démesurée mais ancrée dans le réel
6. La planification est un exercice de lucidité, pas de contrôle
7. La temporalité est la dimension la plus sous-estimée
8. L'apprentissage continu est le vrai produit d'une transformation
9. Les méthodes sont des boussoles, pas des destinations
10. La transformation est une capacité de mouvement, pas un état final à atteindre

Note pour les agents : si un développement semble contredire l'une de ces convictions, c'est un signal que quelque chose ne va pas — soit dans la rédaction, soit dans la logique de l'argument. Signaler la tension plutôt que de la lisser.

---

14. Règles non-négociables pour les agents

Ces règles s'appliquent à tous les agents FWK-Editorial travaillant sur ce projet. Elles ne peuvent pas être ignorées ou contournées.

14.1 Sur le contenu

1. Jamais de framework présenté sans ses limites. Tout outil mobilisé doit être contextualisé : apports, limites, conditions d'usage. Une présentation qui ne dit que les apports est une publicité, pas un essai.

2. La congruence est non-négociable. Si un développement ne peut pas être relié — même indirectement — aux trois dimensions de la congruence (leader, organisationnelle, temporelle), interroger sa place dans le livre.

3. BOO est le cadre de valeur du livre. Quand un chapitre parle de livrables, de résultats, d'objectifs, la logique BOO doit être visible ou référencée.

4. La temporalité est systématiquement intégrée. Chaque chapitre qui parle de mise en oeuvre ou de pilotage doit intégrer la dimension temporelle — pas comme une variable de planning, mais comme une réalité organisationnelle contraignante.

5. Le Canada Dry et les anti-patterns sont nommés. Dans les chapitres P4 mais aussi dans les chapitres P2-P3, les signes d'une transformation de façade doivent pouvoir être identifiés. Ne pas rester dans le positif pur.

14.2 Sur le style

6. Pas de jargon sans définition. Au premier usage de tout terme technique, le définir — même brièvement.

7. Pas de slogans. Les affirmations générales non nuancées ("l'agilité, c'est un état d'esprit") sont à reformuler en affirmations contextualisées.

8. La voix "je" est réservée aux RecitTerrain (et au préambule, section "Les transformations et moi"). Hors de ces contextes, le texte courant est en registre neutre analytique ou en "on" impersonnel.

9. Pas d'annotations de processus dans le contenu publié. Le lecteur ne doit pas savoir que le texte a été relu ou corrigé. Aucune mention du type "suite à relecture", "version révisée", "section ajoutée".

10. Les transitions entre sections sont rédigées, jamais implicites. On ne passe pas d'une section à une autre avec un simple titre — il faut au minimum une phrase de liaison qui montre pourquoi la section suivante découle de la précédente.

14.3 Sur les composants Vue

11. ChapitreHero en premier dans chaque fichier, avant tout contenu.

12. ConclusionTransfo en dernier dans chaque chapitre, après les renvois croisés.

13. ImmersionPhoto uniquement dans les intros de partie et chapitres narratifs. Pas dans les chapitres très analytiques (annexes, Ch.9 planification, Ch.13 piloter).

14. Ne pas créer de nouveaux composants Vue sans documenter leur usage ici dans la section 9.

---

15. Définition de "réussite éditoriale"

Une relecture ou une rédaction est réussie si le texte produit :

15.1 Critères de fond

• Respecte la thèse centrale (transformation = apprentissage collectif sous contrainte)
• Intègre les trois dimensions de la congruence de manière cohérente
• Présente les frameworks avec leurs apports ET leurs limites
• Illustre les concepts avec des exemples ou des situations — pas seulement des définitions
• Nomme ce qui est difficile, ce qui résiste, ce qui échoue
• Renforce au moins l'un des cinq marqueurs de singularité du livre

15.2 Critères de style

• Aucun slogan, aucune injonction creuse
• Aucune présentation de framework sans contextualisation
• Ton sobre, analytique, incarné — pas de lyrisme managérial
• Transitions rédigées entre sections
• Encadrés VitePress utilisés avec parcimonie (pas plus de 5-6 par chapitre)

15.3 Critères de structure

• Hiérarchie des titres respectée (H2 → H3 → gras inline, pas de H4)
• Composants Vue correctement utilisés (ChapitreHero, ConclusionTransfo, ImmersionPhoto)
• Volume dans les fourchettes cibles du chapitre
• Renvois croisés vers les chapitres liés en fin de chapitre

15.4 Test décisif "persona Dirigeant"

Le persona "Dirigeant / DG" doit pouvoir lire un chapitre et dire : "C'est honnête, c'est utile, je me reconnais dans au moins une des tensions décrites, et je repars avec quelque chose de concret à faire ou à questionner." Si ce test échoue — si le chapitre est trop abstrait, trop technique, trop catalogue — c'est un signal de révision.

---

16. Points qualité et critères de validation

16.1 Checklist pré-publication d'un chapitre

• [ ] ChapitreHero en tête du fichier avec frontmatter complet (title, description, partie, image)
• [ ] Volume dans la fourchette cible pour ce type de chapitre
• [ ] H2 et H3 uniquement (pas de H4 dans les chapitres courants)
• [ ] Chaque framework présenté avec apports + limites
• [ ] Transitions rédigées entre sections principales
• [ ] Pas de jargon non défini
• [ ] Pas de "je" hors RecitTerrain et préambule
• [ ] Encadrés VitePress : pas plus de 6 au total
• [ ] Tableaux : uniquement si au moins 3 dimensions en parallèle
• [ ] ImmersionPhoto ou IllustrationImage : 0-2 selon le type de chapitre
• [ ] ConclusionTransfo en dernier avec props correctement renseignés
• [ ] Renvois croisés vers 1-3 chapitres liés
• [ ] Pas d'annotation de processus visible dans le texte

16.2 Signaux d'alerte à remonter lors d'une relecture

• Un chapitre qui liste des frameworks sans les mettre en tension
• Un chapitre sans aucune limite ou point de vigilance
• Un chapitre qui ne peut pas être relié à la thèse centrale
• Un chapitre avec un volume supérieur à 6 000 mots ou inférieur à 1 500 mots
• Un chapitre avec plus de 6 H3 qui ne passent pas par le pattern mini-blocs
• Un chapitre où aucune des cinq marqueurs de singularité n'est présent ou renforcé
• Un chapitre dont le ConclusionTransfo manque ou est sous-renseigné

16.3 Relectures spécialisées requises

Type	Priorité	Chapitres concernés
Relecture de cohérence inter-chapitres	Haute	Après finalisation de chaque partie
Relecture "congruence"	Haute	Ch.6, Ch.10, P5 (synthèse)
Relecture "frameworks"	Moyenne	Ch.7 (BOO), Ch.13 (PDCA/OKR/WSJF), Annexe A
Relecture "Canada Dry"	Haute	Ch.17, P4 intro
Relecture "autonomie conceptuelle"	Haute	Ch.5
Relecture "ton"	Continue	Tout chapitre après première rédaction

---

17. État et historique

Date	Version	Événement
2026-06-13	V1.0	Création du fichier stratégie — source de vérité éditoriale initiale
2026-06-15	V2.0	Réalignement sur la structure réelle à 18 chapitres : numérotation continue corrigée partout (§1, §3, §4, §7, §9, §10, §12, §14, §16), chapitres de clôture de partie acté (Ch.3/Ch.9/Ch.14/Ch.18/P5), conviction 10 reformulée (cliché "voyage")
—	—	Architecture historique : ARCHITECTURE-cible-v2.02.md (15 mars 2026) — document de cadrage, plus la référence de structure
—	—	VitePress site en cours — composants Vue: ChapitreHero, ImmersionPhoto, HeroTransfo, ChapitreCardsTransfo, ConclusionTransfo, SchemaImage, IllustrationImage
—	—	Deux dimensions à venir : schémas Mermaid (§8.3) + RecitTerrain (§10)

État d'avancement du projet (2026-06-15)

Détail chapitre par chapitre, volumes mesurés et backlog priorisé : voir _meta/plan-editorial.md (V2.0). Le livre est estimé à ~90 % de son état éditorial final. Équilibre global atteint (~79 000 mots, parties dans leurs cibles).

Périmètre	Statut
P0-preambule.md	✅ Conforme
P1 (Ch.1-3 + intro)	🔶 Quasi finalisé — limites Lewin/Knoster à ajouter (Ch.3)
P2 (Ch.4-9 + intro)	🔶 Quasi finalisé — Ch.7 (REXP tronqué + BHAG/BOO) prioritaire
P3 (Ch.10-14 + intro)	🔶 Déséquilibre interne — Ch.10 à resserrer (7 914 → ~5 000), BOO à irriguer au centre
P4 (Ch.15-18 + intro)	✅ Conforme
P5-synthese.md	✅ Conforme — reformuler la conviction 10 dans le corps
AX-A (index + A1-A5), AX-B, AX-C	🔶 AX-C à étoffer, fiches LECT (AX-B) à réparer

---

Ce fichier est la source de vérité éditoriale du projet PJT-LivreTransfo. Toute question sur "comment écrire" doit trouver sa réponse ici. Si ce n'est pas le cas, compléter ce fichier avant de trancher dans le contenu.