Le cadrage que je livre avant la première ligne de code
Avant d'écrire du code sur Grimoire, je pose un document de cadrage : périmètre strict, lots, critères de validation. Voici ce qu'il contient, et deux fois où il m'a manqué.
Le premier livrable, ce n'est pas du temps, c'est de la clarté
On imagine souvent qu'un développement commence par du code. Dans ma façon de travailler, il commence par un document de cadrage écrit, que j'appelle un PREDEV. Il tient sur quelques pages et il est validé avant que la moindre ligne soit écrite.
Son rôle est simple : verrouiller une lecture commune du projet pendant que c'est encore gratuit de se tromper. Une fois le code écrit, un malentendu ne se corrige plus dans un document, il se corrige dans une migration de base de données. C'est plus cher.
Sur Grimoire Culinaire, chaque lot du MVP a eu son PREDEV avant d'être développé. Quatorze lots, quatorze documents de cadrage.
Ce que contient un PREDEV
Le document n'est pas une liste d'intentions. C'est une série de blocs vérifiables. Concrètement, un PREDEV Grimoire contient toujours les mêmes sections.
- Le contexte : ce qui est déjà en place, ce que ce lot ajoute.
- Le périmètre strict, en deux colonnes : ce qui entre, et surtout ce qui n'entre pas.
- Les décisions techniques prises, avec leur justification.
- La liste des fichiers à créer, à modifier, et ceux qu'on ne touche pas.
- L'ordre d'implémentation et les critères de vérification finale.
Un lot bien borné : l'exemple de l'auth
Le lot 8 de Grimoire, c'était l'authentification améliorée. Pas la consigne floue « faire l'auth », mais un bloc précis : écran de connexion unifié, Google OAuth via le flow PKCE de Supabase, mode « explorer sans compte », vérification d'email avec un bonus de 200 muffins à la clé.
Ce qui rend ce lot borné, ce n'est pas la liste de ce qu'il fait. C'est la liste de ce qu'il ne fait pas, écrite noir sur blanc dans le périmètre : la config Google Cloud côté dashboard, l'Apple Sign-In, les animations Lottie sont explicitement hors scope, renvoyées à d'autres lots. Résultat mesurable : 23 tests ajoutés, 282 tests au vert à la clôture.
Un autre lot, l'ajout de huit actions IA sur la fiche recette, listait dans son cadrage 19 fichiers à créer, 5 à modifier et une quarantaine de tests attendus avant même la première ligne. Ce niveau de détail, c'est exactement ce qui permet de dire « c'est fini » sans débat.
Deux fois où le cadrage m'a manqué
Un article de méthode qui ne montre que des réussites ment. Sur Grimoire, le cadrage a raté deux fois, et les deux m'ont coûté du re-travail.
Premier raté : un lot trop gros. J'avais prévu un seul lot « +14 actions IA ». Impossible à valider d'un bloc. J'ai dû le redécouper en cours de route en un lot d'infrastructure, puis 15a, 15b-1, 15b-2. Le premier découpage était simplement faux, et je ne l'ai vu qu'en essayant de le formuler proprement.
Deuxième raté, plus cher : un périmètre incomplet sur les tout premiers lots. Les champs difficulty, visibility, imageUrl et servings manquaient dans les modèles de données. Personne ne les avait cadrés. Je les ai découverts le 12 mars à un audit de compatibilité, et il a fallu les rattraper par des migrations correctives de la base (Drift v2 vers v3). Un cadrage incomplet ne disparaît pas : il ressort plus tard, en re-travail.
Ce que ça change concrètement
Le bénéfice principal, c'est la prévisibilité. On voit où va le projet, dans quel ordre, et sur quelle base valider chaque livraison. Le scope creep devient visible parce qu'il faut l'écrire quelque part pour l'ajouter.
Les discussions budget et délai deviennent plus concrètes : on parle d'unités de livraison, pas de ressenti. Et quand un lot est mal taillé, comme mes deux ratés, ça se voit à l'étape du cadrage plutôt qu'à l'étape du bug.
Ce que je retiens
Le cadrage ne garantit rien : il rend juste les erreurs visibles plus tôt, quand elles sont encore bon marché. Mes deux ratés sur Grimoire sont passés par le cadrage, pas par la production, et c'est précisément pour ça qu'ils ont été rattrapables.
Le document ne disparaît pas quand le dev commence, il évolue. À l'arrivée, le MVP a fait 14 lots, et le projet était monté à 635 tests le jour de la livraison, pour un schéma de base en version 11. Il en compte plus de 700 aujourd'hui. Ce que je garde de tout ça, ce n'est pas le code : c'est un projet resté lisible du premier lot au dernier.