Le cout caché des features : pourquoi je dis non plus souvent qu'avant

Au début de ma carrière, dire oui était mon avantage compétitif. Une nouvelle feature ? Oui. Un petit ajout pour ce client-là ? Oui. On peut la caser dans ce sprint ? Oui. Je livrais vite, les gens étaient contents, et je croyais sincèrement que la vélocité, c'était tout le métier.

Sept ans et plusieurs startups plus tard, je dis non, ou plus précisément "pas comme ça", plus que jamais. Pas parce que je suis devenu plus lent ou plus précieux. Parce que j'ai fini par comprendre ce qu'une feature coûte vraiment, et que presque rien de ce cout ne tient au build.

L'étiquette de prix que personne n'écrit

Quand on estime une feature, le chiffre sur le ticket est le cout de construction : trois jours, deux semaines, peu importe. Voici ce qui n'est pas sur le ticket :

La rente de maintenance. Chaque feature est un petit paiement récurrent, pour toujours : des dépendances à mettre à jour, des edge cases à patcher, un comportement à préserver à travers chaque refactor. Une feature construite en trois jours et maintenue en vie pendant quatre ans n'était pas une feature de trois jours. J'ai maintenu des "quick wins" dont l'entretien cumulé a dépassé plusieurs fois leur cout de construction.

La taxe de surface sur tout le reste. Chaque feature rend chaque feature future légèrement plus chère. Plus d'états à considérer, plus d'interactions à tester, plus de chemins de migration à préserver. Ça se compose en silence. La codebase où livrer prenait deux jours en année un et deux semaines en année quatre n'a pas hérité de moins bons ingénieurs : elle a accumulé de la surface.

Le piège combinatoire. Les pires coupables sont les features qui se multiplient les unes par les autres. Permissions x formats d'export x préférences de notification : chacune était raisonnable seule ; ensemble, elles ont créé une matrice de tests que personne ne couvre vraiment et des bugs qui n'apparaissent que pour le seul client qui utilise les trois. Quand j'évalue une feature aujourd'hui, la première question n'est pas "combien de temps pour la construire ?" mais "avec quoi est-ce que ça se multiplie ?"

Le problème de la suppression. Le code est facile à ajouter et politiquement couteux à retirer. La feature utilisée par 2% des comptes ne peut pas être tuée parce que l'un d'eux est un logo phare. J'ai vu des produits trainer des années de ça : une longue traine de fonctionnalités à peine utilisées qui contraignent chaque refonte. Livrer est réversible en théorie. En pratique, presque rien ne sort avec une politique de retour.

Le cout de focus. Le plus subtil. Chaque feature réclame une part du modèle mental de l'équipe et une part de celui de l'utilisateur. Les produits ne meurent généralement pas de features manquantes. Ils meurent obèses : lents à changer, durs à apprendre, impossibles à positionner.

Ce qui a changé dans ma façon de travailler

Le basculement n'a pas été d'apprendre à refuser. Ça a été de changer ce que je demande avant de construire. Quelques questions qui méritent leur place :

"Qu'est-ce qui se passe si on ne construit pas ça ?" Étonnamment souvent, la réponse honnête est "le client râle et s'adapte" ou "on perd un deal qu'on aurait perdu de toute façon." Si le scénario sans-build est survivable, c'est la barre que la feature doit franchir, en incluant tous ses couts cachés, pas seulement son estimation de build.

"Peut-on acheter l'apprentissage moins cher ?" La moitié des features qu'on me demande de construire sont en réalité des expériences déguisées en feature : quelqu'un veut savoir si les clients utiliseraient X. Une expérience peut être un processus concierge, une fake door, un tableur et un canal Slack. Construis l'apprentissage, pas la feature. Si l'apprentissage dit oui, alors construis la feature, proprement.

"Quelle est la plus petite version qui reste honnête ?" Pas un MVP qui fait tout mal, mais une réduction de scope délibérée qui fait une chose complètement. La discipline, c'est d'écrire ce qui est explicitement exclu, pour que la coupe soit une décision plutôt qu'un accident que l'équipe support découvre.

"Qui maintient ça dans 18 mois ?" Si la réponse est "personne en particulier", la feature est orpheline à la naissance. Les features orphelines, c'est là que naissent les incidents de production.

Et un changement de comportement qui a compté plus que n'importe quel framework : mettre les couts cachés dans la conversation, par écrit, au moment de la décision. Pas pour bloquer, mais pour donner un prix. "On peut le faire ; voici le build, voici le pari de maintenance, voici avec quoi ça se multiplie, voici ce qu'on ne fait pas à la place." C'est remarquable de voir combien de demandes de features s'évaporent quand leur vrai prix devient visible, et à quel point celles qui survivent sont meilleures.

La version freelance de ce problème

En tant que freelance, ça devient plus tranchant, parce que dire non semble contredire le modèle économique : je suis littéralement payé pour construire. Mais l'incitation pointe en réalité dans l'autre sens. Un consultant qui construit tout ce qu'on lui demande livre un produit plus lourd et un résultat plus mince, et le client finit par remarquer lequel des deux il a payé. Les clients qui sont revenus, d'après mon expérience, sont ceux que j'ai dissuadés de faire quelque chose.

Le livrable qu'un ingénieur senior apporte, c'est du jugement avec du code attaché. N'importe qui peut produire la partie code aujourd'hui, et c'est de plus en plus littéral vu ce que les agents peuvent générer. Ce qui ne peut pas être généré, c'est le moment où quelqu'un regarde une roadmap et dit : cette ligne-ci va te coûter le triple de ce qu'elle annonce, et cette autre ligne ne devrait pas exister.

Ce que je dirais à moi-même au départ

La vélocité est la chose la plus lisible chez un ingénieur, donc tot tu l'optimises : je l'ai fait, et c'était probablement juste à l'époque. Mais les ingénieurs dont j'ai le plus appris n'étaient pas les plus rapides à construire. C'étaient les meilleurs à refuser : des gens capables de voir le cout sur quatre ans d'un ticket de trois jours et de le dire, gentiment, avec des chiffres, avant que le oui ne soit donné.

Les features sont des emprunts. La vélocité de build, c'est la vitesse à laquelle tu peux emprunter. Et les équipes qui avancent le plus vite en année quatre sont celles qui ont emprunté avec prudence en année un.