Construire un produit rapidement, c'est souvent vital pour convaincre les clients ou les investisseurs. Mais la vitesse n'est pas incompatible avec la qualité : il faut juste décider ce qu'on accepte de repousser, documenter pourquoi et s'assurer qu'on rattrape ensuite.
Raccourcis conscients
Je distingue les raccourcis tactiques des raccourcis dangereux. Un prototype rapide peut se permettre une API simplifiée, des composants peu stylés ou un logging minimal. Mais ces décisions sont prises avec un ticket clair : "Nous reviendrons sur ce module à J+14". Les raccourcis invisibles, comme des validations manquantes ou un modèle de données incohérent, sont bien plus coûteux, car ils rongent la confiance des équipes et des utilisateurs.
Outillage serré
Pour contrôler la dette, j'arme les projets d'outils : TypeScript et l'ESLint strict encadrent la qualité, les tests ciblent le cœur métier, et les pipelines automatisés empêchent les commits bruyants. Les revues sont plus rapides lorsque le code respecte les attentes de lint et de formatting. Même sur des MVP, j'exige des contrats clairs et des migrations versionnées.
Décisions architecturales sensées
Les choix de structure orientent la dette technique future. Un modèle monolithique lisible est préférable à une microarchitecture prématurée. Un code modulaire, avec des domaines métier identifiés, permet d'isoler la dette et de l'adresser par zone.
Je prends un temps initial pour vérifier ce que chaque cas d'utilisation demande : quelles données sont persistées, quelles actions doivent être atomiques, quels évènements déclenchent d'autres systèmes. Ces discussions amènent des décisions qui évitent d'empiler des quick fixes impossible à remplacer plus tard.
Expériences concrètes
J'ai vu des produits qui croissaient vite, mais où personne ne comprenait plus comment fonctionnait la base de données ou comment lancer localement un service. Les équipes finissaient par refondre tout de zéro. J'interviens en prévention : je documente, j'organise les fichiers, j'impose des tests critiques et je créé une routine de « tech debt retro » pour qu'on rappelle régulièrement les choix faits et les dettes à rembourser.
Lorsque les startups me demandent d'accélérer, je livre un pipeline où la dette est visible, suivie et traitée. La vitesse n'est pas qu'une pression, c'est un rythme que l'on garde en contrôlant la qualité.