La fiche delta

Votre plan va changer. Une précision du CEO, une découverte dans le code, un blocage : chaque fois, vous ajustez, et vous laissez une trace. Cette trace, c’est la fiche delta. L’ensemble de vos fiches, dans l’ordre, raconte comment le projet a réellement avancé, et c’est ce qui est lu au jour 3.

Le format

Un fichier Markdown par fiche, dans un dossier deltas/ à la racine de votre fork, numéroté dans l’ordre : deltas/01-perimetre-bureau-graphique.md, deltas/02-.... Quatre rubriques, quelques lignes chacune :

# Delta 01 : titre court

**Date** : J1, 14h30

## Ce qui change
Le plan disait X. Il dit maintenant Y.

## Pourquoi
Ce qu'on a vu, entendu ou constaté. Une réponse du CTO, un fichier dans le code,
un test qui a échoué. Citez la source.

## Ce que ça coûte ou libère
Temps gagné ou perdu, périmètre retiré ou ajouté, risque nouveau ou levé.

## Décidé avec qui
Le groupe seul, ou après validation du CEO / du CTO. Si le client est impliqué,
dites ce qu'il a répondu exactement.

Quand en écrire une

• Ce que vous allez livrer sur une exigence change
• Une hypothèse de départ s’avère fausse après lecture du code
• Un choix technique est fait ou défait
• Une réponse du CEO ou du CTO change ce que vous allez faire

Pas de fiche pour une correction de bug ou un détail d’implémentation : la fiche trace les changements de plan, pas le travail courant.

Ce qu’elle n’est pas

Ce n’est pas une justification écrite après coup. Une fiche datée du jour 3 qui explique une décision du jour 1 se voit. Écrivez-la au moment où la décision se prend, même en trois lignes ; vous pourrez la compléter ensuite.