Cadrer avant de coder

La tentation, quand on sait construire, c'est de construire tout de suite. Un ticket arrive, on ouvre l'éditeur, on tape. C'est gratifiant : on voit quelque chose bouger en quelques minutes. Et c'est souvent une erreur. Le code le plus coûteux n'est pas celui qui est mal écrit — c'est celui qui n'aurait jamais dû être écrit.

De mes années en tant que Product Owner, j'ai gardé un réflexe que je ne lâche plus : avant de coder, je cadre. Je m'oblige à formuler le problème en une phrase, à nommer l'utilisateur, à décrire ce qui change pour lui si je réussis. Tant que je n'y arrive pas, je ne touche pas au clavier. Ce n'est pas de la bureaucratie : c'est l'étape qui évite de construire vite la mauvaise chose.

Le problème avant la solution

La plupart des demandes arrivent déjà habillées en solution. « Il faut ajouter un bouton ici. » « Il nous faut un dashboard. » Derrière chaque solution, il y a un problème non dit, et c'est lui qui compte. Le bouton, c'est peut-être une notification. Le dashboard, c'est peut-être une seule métrique envoyée par email. Cadrer, c'est déshabiller la demande jusqu'au problème, puis choisir la solution la plus petite qui le règle.

Cette discipline a un effet secondaire précieux : elle réduit la quantité de code. Le meilleur produit n'est pas celui qui a le plus de fonctionnalités, c'est celui qui en a le moins pour le même résultat. Moins de code, c'est moins de bugs, moins de maintenance, moins de surface à faire évoluer. Cadrer en amont, c'est s'offrir le luxe de construire peu.

Penser n'est pas ralentir

On oppose souvent la réflexion et la vitesse, comme si cadrer faisait perdre du temps. C'est l'inverse. Une heure passée à comprendre le problème en économise dix sur l'implémentation, et bien plus sur ce qu'on n'aura pas à défaire. La vraie lenteur, c'est de coder trois semaines une fonctionnalité que personne n'utilisera, puis de la maintenir pendant deux ans.

Cadrer ne veut pas dire tout spécifier à l'avance. Je ne crois pas aux documents de cinquante pages qui prétendent prévoir le futur. Cadrer, c'est s'assurer qu'on attaque le bon problème, puis avancer par petites itérations vérifiables. On garde la vitesse — on l'oriente. Construire reste la finalité ; penser, c'est juste viser avant de tirer.