Chapitre 12.5 — Les checklists de l’architecte

⏱️ TL;DR — La posture condensée en gestes. Voici les checklists à garder sous la main : kickoff d’un projet, nouvelle feature, fin de session, avant merge/PR, et quand ça dérape. Elles ne remplacent pas le jugement — elles t’évitent d’oublier un geste sous la pression. Imprime-les, colle-les, adapte-les. (Une version copiable est aussi dans le Cookbook.)

🎯 Objectifs

Disposer de checklists actionnables pour chaque moment clé.
Ancrer la posture d’architecte dans des gestes concrets.
Savoir quoi vérifier avant de merger et en fin de session.

Checklist — Kickoff d’un projet (P2-P4)

Les 4 décisions posées et écrites : problème/périmètre (dont exclus), stack, design, conventions.
Lancé en plan mode + modèle fort ; plan lu et corrigé avant tout code.
CLAUDE.md graine créé (court, priorisé, tranchable) + « ce qu’on n’utilise pas ».
Tokens sémantiques posés + exposés (design system minimal).
Un composant-modèle exemplaire (tokens, types, a11y).
settings.json de projet : permissions de base, hooks (format/lint/test), garde-fous.
Repo git initialisé, branche de travail, premier commit vert.

Checklist — Nouvelle feature (P5)

Brief en 3 ingrédients : objectif (+ pourquoi), ancrages (fichiers-modèles), critère vérifiable.
Plan mode si l’enjeu/l’ambiguïté est élevé ; plan corrigé.
Découpée en tranches vérifiables.
Chaque tranche ancrée sur l’existant (conventions, primitives).
Chaque tranche conclue par une preuve (test + flux exercé / rendu vu).
Contexte net (une intention ; /clear si on change de sujet).

Checklist — Fin de session (P6)

Le code build, tests et lint verts.
Un commit propre marque l’avancement (message qui porte le pourquoi).
Si inachevé : /handoff ou note « next steps ».
Mémoire à jour (si une convention a changé, CLAUDE.md/skills mis à jour).
Rien de cassé laissé en plan : état reprenable.

Checklist — Avant merge / PR (P11)

Diff relue (cœur métier + fichier-modèle) : hors-périmètre ? contournement ? cas manquant ? complexité ?
/code-review passé (effort selon l’enjeu) ; findings triés, pas gobés.
Sécurité : /security-review si ça touche à l’auth / aux entrées externes / aux données.
CI verte (la porte partagée).
Je comprends ce que je merge (sinon, je demande le pourquoi avant).
PR : description qui explique le pourquoi, pas juste le diff.

Checklist — Quand ça dérape (P12.3)

Nommer le piège (vibe-coding ? contexte pollué ? culte du prompt ? croire ≠ vérifier ?).
Contexte pollué → /clear + prompt net, ou déléguer à un subagent.
Consigne répétée → la cristalliser (CLAUDE.md / hook / skill / modèle).
Deux corrections vagues sans progrès → stop, repartir propre avec un feedback ciblé.
Ça déraille sur l’archi → plan mode, reprendre le jugement.
Doute sur « est-ce que ça marche ? » → exiger la preuve (observer).

La méta-checklist : les 5 modèles

Si tu ne devais retenir qu’une chose, ces cinq questions (12.1) diagnostiquent presque tout :

💡 Réflexe d’architecte — Ces checklists ne sont pas des rituels bureaucratiques : ce sont des garde-fous cognitifs. Sous la pression (deadline, fatigue), c’est précisément là que tu sautes un geste (« je merge sans relire », « je laisse en plan »). Une checklist visible te rattrape aux moments où ton jugement flanche. Les pilotes d’avion, les chirurgiens, les ingénieurs sérieux en utilisent — pas par manque de compétence, mais par respect de la faillibilité humaine.

✏️ Exercices

Exercice 1 — Adapte tes checklists. Prends les cinq checklists et taille-les à ton contexte (ta stack, ton équipe). Retire ce qui ne s’applique pas, ajoute tes spécificités. Colle-les où tu les verras.

✅ Solution

Une checklist utile est la tienne : courte, spécifique, visible. Adapte les items à ta stack (tes commandes de test/build), à ton flux (mono-repo ? PR obligatoire ?). Une checklist générique qu’on ne lit pas ne sert à rien ; une checklist personnalisée qu’on suit vaut de l’or.

Exercice 2 — Une semaine avec. Utilise la checklist « fin de session » pendant une semaine. Combien de fois t’a-t-elle rattrapé (un commit oublié, une mémoire à mettre à jour, un état cassé) ?

✅ Solution

Presque tout le monde se fait rattraper plusieurs fois la première semaine : un « je finirai demain » évité, une convention mise à jour à temps, un build laissé vert. C’est la preuve que la checklist comble un vrai trou — pas un manque de compétence, mais un manque d’attention aux moments de fatigue.

🧠 Quiz de révision

1. À quoi servent ces checklists, au fond ?

Ce sont des garde-fous cognitifs : elles t’évitent d’oublier un geste sous la pression (fatigue, deadline), là où le jugement flanche. Elles ne remplacent pas le jugement, elles le protègent de la faillibilité humaine.

2. Cite trois items de la checklist « fin de session ».

Par exemple : build/tests/lint verts ; commit propre qui porte le pourquoi ; /handoff ou note si inachevé. Aussi : mémoire à jour, état reprenable.

3. Que vérifier « avant merge » côté compréhension ?

Que tu comprends ce que tu merges (sinon, demander le pourquoi avant). Plus : diff relue (cœur métier), /code-review trié, /security-review si sensible, CI verte, PR qui explique le pourquoi.

4. Premier réflexe « quand ça dérape » ?

Nommer le piège (vibe-coding, contexte pollué, culte du prompt, croire ≠ vérifier) : le remède associé est déjà connu. Nommer, c’est déjà commencer à corriger.

5. Quelles sont les cinq questions de la méta-checklist ?

Membre d’équipe (contexte+conventions) ? Terrain > prompt ? Délègue l’exécution, garde le jugement ? Cristallise le volatil ? Vérifie par l’observation ? Elles diagnostiquent presque toute difficulté.

Fin de la Partie 12 — le cœur de ta demande. Tu as la posture d’architecte. Petit détour découverte : Partie 13 — Claude Cowork.