On a buildé trop vite. Voilà ce qu’on a appris

Il y a un an, on était fiers. On venait de livrer sept produits digitaux pour Dropcolis en quelques mois. Un website, une app mobile pour les clients, une autre pour les Droppeurs, une plateforme B2B, un backoffice, une documentation API complète et un support IA intégré. Tout était en ligne, tout tournait. On avait l’impression d’avoir fait quelque chose de solide.

Sauf qu’on avait surtout fait quelque chose de complexe.

Les premiers mois, on maintenait une infrastructure pensée pour scale, pour un trafic qui n’existait pas encore. Des queues de messages, un monitoring bien configuré, des pipelines CI/CD, de l’over-engineering dans tous les sens. Chaque semaine, il fallait gérer des mises à jour de dépendances sur sept surfaces différentes. Des bugs remontaient ici et là. Des incidents mineurs qu’on traitait sérieusement parce qu’on avait des systèmes sérieux, mais pour des dizaines d’utilisateurs actifs. Le ratio effort sur impact était mauvais et on le savait.

Ce qu’on avait raté, c’est l’évidence : on avait résolu des problèmes qu’on n’avait pas encore. On avait anticipé une complexité qui n’était pas là. Et pendant ce temps, la vraie question, celle de l’acquisition, du bon client, du bon marché, on l’avait mis de côté parce qu’on pensait que la tech allait parler d’elle-même.

Elle n’a pas parlé.

On a pris une décision difficile. Freeze complet sur le développement. Plus de nouvelles features, plus de refacto, plus d’amélioration produit sauf si c’était critique. Toute l’énergie basculée vers les clients, les vrais, ceux qui avaient un besoin concret que Dropcolis pouvait résoudre. C’est inconfortable quand tu es développeur de lâcher le clavier et d’aller sur le terrain. Mais c’est ce qu’il fallait faire.

Six mois après, les clients étaient là. Et quelque chose d’intéressant s’est passé : leurs besoins réels ne correspondaient pas exactement à ce qu’on avait buildé. Certaines features qu’on avait soignées n’intéressaient personne. D’autres choses simples, qu’on avait négligées parce qu’elles semblaient triviales, bloquaient des workflows entiers. On a désactivé des modules. On en a reconstruit d’autres from scratch, plus simples, plus directs. La prod nous a appris ce qu’aucune réunion de conception n’aurait pu anticiper.

Aujourd’hui on travaille différemment. Une feature n’entre pas dans le backlog si elle ne vient pas d’un besoin client explicite ou d’une friction observée en production. On a arrêté de builder pour ce que le produit pourrait devenir et on build pour ce que les clients ont besoin maintenant. Ça paraît basique dit comme ça. Mais quand tu as la tête dans le code, dans l’architecture, dans les bonnes pratiques, il est très facile de perdre ce fil.

Ce qu’on a retenu de cette année, c’est que la technologie n’est pas une proposition de valeur en soi. C’est un outil pour délivrer de la valeur. Une belle stack, une archi propre, des tests bien écrits, ça n’intéresse pas le client final. Ce qui l’intéresse, c’est est-ce que son colis arrive, est-ce que le Droppeur est fiable, est-ce que le service tient ses promesses. Le reste, c’est notre affaire interne.

On n’a pas tout bien fait. On a perdu du temps, de l’énergie, probablement de l’argent. Mais on a appris quelque chose qu’on n’aurait pas appris autrement : valider avant de builder, comprendre avant d’optimiser, et toujours se demander pour qui on code vraiment.

TakkJokk,