Lorsque j'étais en classe, quelque part en primaire, mais peut-être plus tard, nous avions deux styles de cahiers : le cahier de brouillon, et le cahier de textes.

Sur le cahier de brouillon étaient mises les premières épreuves, le texte à écrire avec ses fautes, ses ratures, travaillé jusqu'à ce qu'il soit dans l'état voulu.

Cette étape passée, le texte était consciencieusement reporté sur le cahier de textes, constituant l’œuvre définitive. Pas forcément exempte de fautes, ni création littéraire exceptionnelle, mais dans un état présentable, gommant les étapes de sa construction.

Une technique éprouvée

Cette technique perdure avec les années, et si la distinction entre le cahier de brouillon et le cahier de textes s'estompe, la production d'un texte se fait toujours sur le même principe. Avec le temps, ce ne sont parfois plus que des idées qui sont jetées sur la feuille de brouillon. Parfois seulement un mot dont on essaie plusieurs orthographes rapidement pour se souvenir de la bonne.

Et ce brouillon est gardé. Il ne fait pas partie des pièces rendues. Son destin est probablement d'être jeté, au grand dam des historiens futurs si jamais il était la première étape d'une œuvre majeure.

Alors on garde

Dans la production de jeux vidéo, et peut-être dans la production informatique plus élargie, le fonctionnement par itérations rapides a du succès car permet d'être réactif par rapport aux demandes du ou des clients¹.

Il entraîne aussi un mal : l'itération à base de brouillons.

Lorsqu'une « copie » est rendue en fin de sprint et évaluée, si elle correspond aux demandes du client, le sprint est validé. Et le sprint suivant démarre.

Cependant, cette review finale manque la plupart du temps d'une validation très importante : la validation technique. Le sprint est validé sur des considérations visibles, sans étudier l'invisible : la technique utilisée et son éventuelle dette contractée².

L'itération est partie d'un brouillon, puis ce brouillon a été mis à jour, amélioré, ajusté. Au final, cela reste un brouillon. Un brouillon qui fait l'affaire mais où toutes les ratures, les flèches de report, les annotations en marge,... sont là.

Elles n'apparaissent pas au premier abord, mais un peu plus tard, lorsqu'il faut tout à coup prévoir une phase de \"refactoring\" avant de pouvoir passer à la suite. Mécontentant le client qui pensait avoir terminé.

Qu'est-ce que le refactoring dans ces cas là ? Dans le meilleur et plus rare des cas, c'est une remise au propre, sur le cahier de texte. Dans le cas général, c'est une grosse rature sur une partie du brouillon, afin de continuer à avancer.

Arracher la page

Démarrer par un brouillon est une bonne chose. Cela permet d'explorer rapidement, d'essayer des pistes. Mais la satisfaction du client ne doit pas être la seule sanction d'une production pour passer à la suite.

L'auteur doit aussi s'assurer qu'il sera capable de soutenir le développement dans la durée.

Et pour cela, il vaut mieux arracher la page, la garder sur le côté. Et refaire au propre, en s'aidant de tout ce que les différents brouillons nous ont appris.

Afin de rendre une copie propre.