Pourquoi une V1 finit-elle par freiner la boîte ?

Votre V1 vous a amené ici. Elle a fait le travail : des clients, du chiffre, une équipe. Mais elle a été construite pour prouver, pas pour porter.

Le plus troublant, c’est que rien ne casse. Le produit tourne, les clients paient, et pourtant chaque décision prend un peu plus de temps que la précédente. Personne ne sait dire quand ça a basculé, parce que ça n’a pas basculé : ça a glissé.

À quoi sert une V1, exactement ?

Une V1 a un seul métier : obtenir la preuve la moins chère possible qu’un problème vaut de l’argent. Tout ce qui l’éloigne de cette preuve est du temps perdu. On choisit vite, on fige des hypothèses, on prend des raccourcis, et c’est la bonne décision. Un raccourci qui vous fait gagner trois mois sur une hypothèse fausse vous a fait économiser trois mois.

Ces raccourcis ont des noms très concrets. Un seul type d’utilisateur, parce qu’au début il n’y a qu’un métier. Le prix écrit en dur, parce qu’il n’y a qu’une offre. Les données de chaque client rangées à côté de celles des autres, parce qu’il n’y en a que trois et qu’on les connaît par leur prénom. Rien de tout cela n’est une faute. Ce sont des paris de vitesse, et ils ont été gagnés.

Pourquoi ce qui a marché finit-il par bloquer ?

Parce que la preuve est faite, et que l’objectif a changé sans que personne ne le dise à voix haute. Il ne s’agit plus de vérifier une hypothèse : il s’agit de porter des clients qui paient. Or un raccourci ne se comporte pas de la même façon dans ces deux mondes.

Dans une V1, un raccourci est une ligne droite. Dans un produit qui grandit, c’est une dépendance : chaque nouveau client s’assied dessus, chaque fonctionnalité s’y appuie. Le deuxième métier arrive, il faudrait un deuxième type d’utilisateur, sauf que le premier est supposé partout. La deuxième offre arrive, et le prix est écrit en dur à chaque endroit où il a fallu l’afficher. Le premier client sérieux demande qui peut voir quoi, et la réponse n’a jamais eu à être écrite.

Rien de tout ça ne déclenche d’alerte. C’est bien le problème : la courbe ne casse pas, elle s’aplatit. Et comme le produit marche, personne n’ose arrêter pour consolider.

Comment sait-on qu’on est passé de « ça tient » à « ça freine » ?

Pas par le code. On le sait par le calendrier et par les ventes, deux endroits où vous regardez déjà. Les signaux qu’on retrouve dans presque tous les audits, et ce qu’ils coûtent réellement :

• Chaque évolution prend plus de temps que la précédente. « Une fonctionnalité qui prenait 2 jours il y a six mois en prend maintenant 10. » Les dates promises aux clients glissent.

• Chaque correction en fait apparaître deux autres. « Chaque déploiement était une angoisse. » Les journées passent en réparations, pas en nouveautés.

• Ça ralentit à mesure que les clients arrivent. « Les clients commençaient à se plaindre des lenteurs. » Des abonnements s’arrêtent sans motif écrit.

• Une seule personne sait où sont les choses. « Personne n’ose toucher au code de peur de tout casser. » Vos délais dépendent d’un agenda.

• Les grands comptes posent des questions sans réponse. « Des auditeurs entreront dans le code. » Des contrats attendent, puis vont ailleurs.

Un signal isolé ne veut rien dire : tous les produits en vie en présentent un. Trois signaux ensemble ne parlent déjà plus de technologie, ils parlent de vitesse commerciale. C’est à ce moment-là que la question devient la vôtre et non celle de votre développeur.

Est-ce le code qui coûte cher, ou la décision qu’on repousse ?

Le prix d’une refonte se voit : il est écrit sur un devis, en une fois, et il fait mal au moment où on le lit. Le prix de l’attente ne se voit pas. Il est réparti sur une année entière, en journées de développement qui n’ont rien produit de neuf, en dates repoussées, en contrats qu’on n’a pas signés. Personne ne l’additionne jamais, et c’est précisément pour ça qu’il gagne.

Ce que ça vous coûte

Trois nombres à écrire avec vos données, pas avec les nôtres : le délai moyen d’une évolution aujourd’hui, comparé au même délai il y a un an ; la part de vos journées de développement qui part en corrections plutôt qu’en nouveautés ; les contrats qui attendent une réponse que le produit ne sait pas donner. Tant que ces trois nombres ne sont pas posés sur une feuille, « refonte ou pas » reste une impression. Nous ne citerons pas de pourcentage tant que la source ne sera pas vérifiée et datée : un chiffre approximatif dans un article sert l’article, jamais la décision.

Faut-il réparer, refaire une partie, ou tout reprendre ?

Trois réponses sont possibles, et la plus spectaculaire est la plus rare.

Réparer suffit quand les signaux sont isolés et que le produit fait déjà ce qu’on lui demandera dans deux ans. C’est de l’entretien : on stabilise, on documente, on remet des garde-fous. Peu cher, peu visible, souvent la bonne réponse.

Refaire une partie est le cas le plus fréquent, et de loin. La base de données tient, les paiements tiennent, mais les écrans, les droits d’accès ou la facturation ont été écrits pour une entreprise qui n’existe plus. On garde ce qui porte, on refait ce qui bloque, et le budget est divisé par rapport à la page blanche.

Tout reprendre ne se justifie que lorsque les fondations elles-mêmes empêchent le prochain palier : quand chaque correction ouvre deux chantiers, quand plus personne ne peut prédire l’effet d’une modification. C’est un choix rare, et il se démontre. Il ne se décrète pas parce qu’une nouvelle équipe préférerait repartir de zéro.

Ce qu’on ferait

On commence par regarder, pas par proposer. Cinq jours d’audit sur le produit tel qu’il tourne, sans y toucher, pour séparer ce qui tient de ce qui coûte, et pour mettre un ordre de priorité sur ce qui bloque la vente. Ensuite seulement, une refonte par lots : les designs avant la signature, un prix fixe pour un périmètre écrit, et une mise en production progressive. Vos clients ne voient pas les travaux, et vous gardez le droit de vous arrêter à chaque jalon.

Quand faut-il s’en occuper ?

Le pire moment est celui où le produit vous y oblige : une panne devant un grand compte, un audit de sécurité avant une levée, un développeur qui part avec la seule carte du territoire. À ce moment-là, vous ne choisissez plus ni le calendrier, ni le budget, ni le prestataire.

Le bon moment arrive plus tôt qu’il n’y paraît, et il a une signature très reconnaissable : le jour où une décision commerciale commence à dépendre d’un délai technique. Vous renoncez à une offre parce qu’elle « demanderait trop de travail ». Vous repoussez un client parce qu’il faudrait des droits d’accès qui n’existent pas. Ce jour-là, la V1 ne vous ralentit plus : elle décide à votre place.

Les fondateurs qui l’ont fait le disent tous de la même façon : leur seul regret est de ne pas s’y être mis plus tôt.

Questions fréquentes

Une refonte, ça veut dire tout jeter ?

Non, et c’est même l’exception. Dans la plupart des cas, une partie du produit tient très bien : les données, les paiements, parfois toute la mécanique métier. La question n’est jamais « tout ou rien », elle est « quoi, et dans quel ordre ». C’est ce que l’audit tranche, avant qu’on parle de budget.

Peut-on continuer à vendre pendant les travaux ?

Oui. La refonte se livre par lots et se met en production progressivement, l’ancien et le nouveau cohabitant le temps de la bascule. Vous ne fermez pas boutique pendant les travaux, et vos clients n’ont rien à réapprendre du jour au lendemain.

Et si le problème venait de mon équipe plutôt que du produit ?

Ça arrive, et on le dit quand on le voit. Un audit regarde le produit, mais il montre aussi comment les décisions se prennent : qui peut intervenir, ce qui est écrit, ce qui ne l’est pas. Si la bonne réponse est d’organiser plutôt que de reconstruire, vous l’entendrez avant de signer quoi que ce soit.