Pourquoi on cadre toujours avant de coder

Écrire du code avant d’avoir cadré, c’est peindre avant d’avoir dessiné les murs. On perd une semaine à cadrer, on en gagne deux ensuite à produire sans tâtonner.

Chez nous, chaque projet démarre par une semaine passée à écrire plutôt qu’à coder. On en sort un périmètre figé, des maquettes, des critères de réussite. Ensuite, la production n’a plus à deviner.

Coder sans cadrer, ce que ça coûte

Le code mal cadré ne se voit pas tout de suite. Il se paie plus tard, par petites touches.

On développe un écran, on le montre au client, et on découvre que ce n’était pas la bonne version. On recommence. Chaque aller-retour, c’est du temps payé deux fois.

Il y a aussi ces fonctionnalités qui paraissaient simples et qui cachent une règle métier compliquée. Découverte trop tard, celle-là fait exploser le budget, ou fait baisser la qualité pour tenir la date.

Et puis il y a les décisions qu’on prend à votre place. Sans spécification, le développeur tranche seul, au moment où il code, sur des questions auxquelles vous auriez dû répondre tranquillement.

Et sans périmètre écrit, le projet ne se termine jamais vraiment. Il reste toujours une idée de plus à caser.

Un client nous avait demandé « un espace pour gérer ses réservations » — le genre d’application interne qu’on construit souvent. On partait sur un calendrier, des formulaires, une gestion de créneaux. Trois jours plus tard, on finit par comprendre qu’il voulait surtout que ses clients réservent seuls, sans passer par un appel. La moitié du travail était à jeter, non pas parce qu’elle était mauvaise, mais parce qu’elle répondait à la mauvaise question.

Ces coûts-là n’apparaissent sur aucun devis. Ils apparaissent en semaines de retard. Une semaine passée à cadrer coûte presque toujours moins cher que deux semaines de reprises.

La semaine, concrètement

Cinq jours de cadrage, mais rarement cinq jours de réunion. La semaine suit un déroulé simple, avec un livrable à chaque étape.

Le lundi, on parle du problème et des utilisateurs : pourquoi ce projet, pour qui, et à quoi ressemble une réussite. On liste les personnes concernées (visiteur, client, administrateur) et ce que chacune doit pouvoir faire.

Le mardi, on passe aux écrans et au parcours. On les liste tous, puis on les relie entre eux. C’est là que sortent les oublis habituels : que se passe-t-il après l’inscription ? où atterrit un utilisateur qui se trompe ? Ces questions prennent une minute au cadrage et une journée en production.

Le mercredi et le jeudi, on maquette les écrans importants, pas tous. On ne cherche pas un design parfait, on fige les fonctions et les contenus : les champs, les boutons, les informations affichées. On parle d’un écran réel, pas d’une idée.

Le vendredi, on tranche. Ce qui entre dans la v1, ce qui attend. On écrit aussi les critères de réussite, chiffrés. En fin de journée, tout le monde repart avec le même document.

Le lundi suivant, le projet est cadré. La production n’a plus qu’à exécuter.

Ce qu’on laisse sur la table

Tout le travail de la semaine tient dans un document court.

On y trouve la liste des écrans avec leurs utilisateurs, le périmètre exact de la v1 et, surtout, ce qui en est exclu. La liste des exclusions rend souvent plus de services que celle des inclusions.

On y trouve aussi les critères de réussite, écrits de façon vérifiable. On préfère « créer un compte et générer un devis en moins de trois minutes » à « un site agréable ».

Et puis les maquettes des écrans clés, assez précises pour être développées sans deviner, plus la liste des questions qu’on n’a pas encore tranchées.

Le document n’a rien d’administratif. C’est l’outil de travail de la production, et la base de toute discussion sur le délai et le prix.

Ce que ça nous évite

Le cadrage nous épargne l’essentiel des frictions d’un projet, à commencer par les allers-retours sur « ce n’était pas ça qu’on voulait ». Quand le périmètre est écrit, chacun sait ce qui est livré, et ce qui ne l’est pas.

Sur les décisions tardives, l’écart est net. Trancher au cadrage coûte une phrase ; trancher après trois jours de développement coûte une refonte.

Il y a un bénéfice moins visible : le projet ne dépend plus d’une seule personne. Écrit, il se transmet et se vérifie. Il vit sur le papier, pas seulement dans la tête de quelqu’un.

Et si on change d’avis ?

On change. Mais on chiffre. Toute modification de périmètre après le cadrage est listée, estimée, et validée avant d’être développée.

Cadrer ne grave pas le projet dans le marbre. Chaque changement reste possible, à condition d’être chiffré et validé, plutôt que glissé en douce.

Un projet sans cadrage change aussi. Simplement, personne ne mesure le prix de ces changements. Il avance par petits renoncements, jusqu’au jour où le délai et le budget ne tiennent plus. Un projet cadré peut changer autant ; la différence, c’est que chaque virage est décidé, pas subi.

Pour finir

Beaucoup voient le cadrage comme une formalité avant le vrai travail. En réalité, une semaine passée à écrire le périmètre, les écrans et les critères est ce qui rend les semaines de production prévisibles.

Tant que le projet n’est pas cadré, on ne code pas. Si ça protège votre délai et votre budget, tant mieux ; c’est surtout notre façon de travailler.

Envie de voir à quoi ressemblerait le cadrage de votre projet ? Qu’il s’agisse d’un MVP ou d’un site internet, parlons-en. En une heure, on vous dit ce qui tient en deux semaines et ce qui doit attendre.