Une première version qui tourne en quelques semaines, pas en un an

Combien de temps avant de voir tourner une application construite pour votre entreprise ? Quelques semaines, pour un premier usage qui fonctionne vraiment, pas un an de cahier des charges avant la première ligne de code. Mais cette réponse courte cache une méthode qu'il faut comprendre pour y croire.

Pourquoi un projet logiciel traîne, d'habitude#

Le réflexe le plus répandu est de vouloir tout maîtriser avant de signer : un cahier des charges de plusieurs mois, chaque écran décrit, chaque règle posée sur le papier. L'idée se défend, mais elle part d'un principe faux : que quelqu'un puisse décrire un outil qu'il n'a jamais utilisé.

Le conducteur de travaux découvre à la livraison que l'écran demande six champs là où il en remplit deux sur le chantier. Le négociant s'aperçoit que le circuit de validation prévu sur le papier ne correspond pas à celui que ses équipes suivent réellement. Chaque écart devient un avenant, et c'est ce qui fait gonfler les délais, pas la difficulté technique.

Ce qu'on regarde avant d'écrire une ligne de code#

Avant de construire, nous passons un à deux jours avec l'entreprise : ce qu'on appelle l'audit. Il ne produit pas un document de plusieurs mois. Il répond à trois questions :

• Quel est le problème le plus coûteux aujourd'hui ? Celui qui fait perdre le plus de temps, ou celui qui fait perdre le plus d'argent.
• Qui s'en servira, et dans quelles conditions ? Debout sur un chantier, assis au bureau, entre deux livraisons.
• Quels outils existants faut-il raccorder dès le premier jour ? La paie, la comptabilité, un logiciel qui doit rester en place.

Ce travail court n'a pas besoin d'être long pour être utile : son but n'est pas de tout décrire, mais de savoir précisément quoi construire en premier.

Choisir le bon point de départ#

Le premier bloc construit n'est jamais choisi au hasard, ni par facilité technique. Il répond à une règle simple : commencer par ce qui rapporte le plus, pas par ce qui se code le plus vite.

Pour une entreprise de rénovation, ce premier bloc est souvent le suivi des devis. Pour un négociant, la réception des marchandises. Le choix se fait avec l'entreprise, pas à sa place.

Je ne sais pas combien vous êtes derrière, ni combien de temps vous allez mettre.

C'est une question légitime, et la réponse tient justement à ce découpage : on ne demande pas de croire sur parole à un planning de douze mois. On montre un premier bloc qui tourne, sur un vrai cas, en quelques semaines.

Ce qui change avec une application construite bloc par bloc#

Au lieu d'un grand projet livré d'un coup, l'application se construit par blocs successifs, chacun remplaçant un outil existant plutôt que de s'y ajouter.

Concrètement :

• le premier bloc est en service pendant que le suivant se prépare, et il rend déjà service au quotidien ;
• les remarques des équipes arrivent sur un outil qu'elles utilisent chaque jour, pas sur un compte rendu de réunion ;
• chacun voit ce qui le concerne : le dirigeant son chiffre du jour, le responsable son équipe, le terrain sa liste de tâches ;
• vous voyez l'application et le code à tout moment, sans attendre un point d'avancement.

Un exemple de ce découpage est visible sur notre démonstration pour une entreprise de rénovation, et la démarche complète est décrite sur la page votre application.

Ce qu'une première version ne fait pas encore#

Une première version ne couvre pas tout, et ce n'est pas un défaut. Elle laisse volontairement de côté les usages secondaires, les cas rares, les raccordements qui ne sont pas encore nécessaires. Les ajouter trop tôt reviendrait à refaire l'erreur du cahier des charges complet : deviner, avant d'avoir vu l'outil fonctionner.

Ce qui compte, dans les premières semaines, n'est pas la liste des fonctions livrées, mais le fait qu'une personne s'en serve réellement, sur un vrai cas, à la place de ce qu'elle faisait avant.

Une première version en quelques semaines : ce qu'il faut retenir#

Un projet sur mesure n'a pas besoin de durer un an pour être fiable. Il a besoin d'un audit court qui identifie le bon point de départ, puis d'un premier bloc construit pour ce seul usage et mis en service rapidement.

Si un projet chez vous a déjà pris plus de temps que prévu sans que rien ne tourne, la question à poser n'est pas « quand sera-ce fini », mais « que puis-je voir fonctionner cette semaine ». Les causes les plus fréquentes d'un projet qui dérape partent presque toujours de l'absence de réponse à cette question.