Tuer une feature : l’acte de courage produit que vous repoussez pendant que la dette s’accumule

Une startup B2B que j’accompagnais avait 34 fonctionnalités documentées dans son onboarding. En regardant les données d’usage, sept d’entre elles n’avaient pas été touchées par un seul client actif en six mois. Elles étaient toujours là, toujours maintenues, toujours testées à chaque release. Personne ne s’en servait, mais personne n’osait les retirer non plus.

C’est le paradoxe le plus banal du produit : on sait tous ajouter des fonctionnalités, on célèbre même le fait de le faire. Mais retirer quelque chose déclenche une paralysie collective. Et cette paralysie a un coût — sur votre vélocité, sur votre runway, et sur la clarté même de votre produit.

Pourquoi ajouter est facile et retirer est tabou

Ajouter une feature, c’est raconter une histoire de croissance. C’est une ligne dans le changelog, une case cochée sur la roadmap, un argument commercial de plus. Retirer une feature, c’est admettre une erreur passée — ou pire, décevoir un client qui l’utilise encore, même marginalement.

Cette asymétrie psychologique produit un biais systématique. Chaque trimestre, votre surface produit grossit. Or chaque fonctionnalité que vous conservez n’est pas gratuite après son lancement : elle continue de consommer des ressources longtemps après. Il faut la maintenir quand une dépendance change, la tester à chaque déploiement, la documenter, la supporter quand un client bloque dessus, et surtout la prendre en compte dans chaque nouvelle décision d’architecture. Un module que trois clients utilisent devient une contrainte que vous traînez sur toutes vos migrations futures.

Le pattern est reconnaissable : la startup qui empile les features pour fermer des deals, jusqu’au jour où plus personne dans l’équipe ne sait exactement ce que fait le produit. Le nouvel arrivant met trois semaines à comprendre le périmètre. La roadmap devient impossible à prioriser parce que tout est « déjà là » et qu’on ne veut rien casser. C’est le moment où votre produit cesse d’être un actif et devient un passif que vous administrez.

Le vrai coût d’une feature qu’on garde « au cas où »

Le coût invisible d’une fonctionnalité peu utilisée se paie sur trois plans qui se renforcent mutuellement.

Sur le plan technique, chaque feature vivante est un point de couplage. Elle a des tables en base, des routes API, des cas particuliers dans votre logique métier. Le jour où vous voulez migrer votre système d’authentification, refondre votre modèle de données ou changer de provider de paiement, ces recoins oubliés remontent à la surface — et ce sont précisément eux qui font exploser l’estimation. La dette n’est pas dans le code que vous écrivez, elle est dans le code que vous n’osez pas supprimer.

Sur le plan produit, une surface trop large dilue l’expérience. Chaque option dans un menu, chaque champ dans un formulaire, chaque écran secondaire augmente la charge cognitive de l’utilisateur et rend l’onboarding plus long. Vos meilleurs clients ne veulent pas plus de boutons, ils veulent que les trois choses qui comptent pour eux fonctionnent parfaitement. Une feature morte n’est pas neutre : elle vole de l’attention.

Sur le plan stratégique, enfin, garder tout empêche de choisir. Une startup pre-seed ou seed n’a pas les ressources pour maintenir vingt directions de produit à la fois. Chaque euro de runway dépensé à maintenir une feature fantôme est un euro qui ne sert pas à approfondir ce qui crée réellement de la valeur. Le focus n’est pas qu’un discours de fondateur inspiré ; c’est une allocation de ressources, et cette allocation inclut ce que vous décidez d’arrêter.

Comment décider ce qui doit mourir

La bonne nouvelle, c’est que cette décision peut être instrumentée au lieu d’être un débat émotionnel. Encore faut-il regarder les bonnes données.

Le premier réflexe est de mesurer l’usage réel, pas l’usage supposé. Combien de comptes actifs ont touché cette fonctionnalité dans les 90 derniers jours ? Pas « est-ce que quelqu’un l’utilise », mais « combien, à quelle fréquence, et avec quelle valeur associée ». Une feature utilisée par un seul client qui représente 40 % de votre revenu n’est pas la même conversation qu’une feature utilisée par quinze comptes gratuits qui ne convertiront jamais.

Il faut ensuite croiser cet usage avec le coût de maintenance. Une fonctionnalité peu utilisée mais totalement isolée, qui ne bloque aucune migration et ne casse jamais, peut rester en paix. Le vrai problème, ce sont les features à faible usage et fort couplage : celles qui apparaissent dans chaque estimation, chaque bug transverse, chaque refonte. Ce sont elles qu’il faut cibler en priorité.

Le troisième critère est stratégique : cette feature sert-elle encore votre ICP d’aujourd’hui, ou celui que vous visiez il y a dix-huit mois ? Les startups pivotent, affinent leur cible, montent en gamme. Le produit, lui, garde souvent les traces de toutes les cibles passées. Une fonctionnalité conçue pour un segment que vous ne poursuivez plus est une candidate évidente, même si elle marche techniquement bien.

Attention à un piège fréquent : ne confondez pas « feature peu utilisée » et « feature mal découverte ». Parfois, une fonction précieuse est simplement enterrée dans l’interface et personne ne la trouve. Avant de tuer, demandez-vous si le problème est l’inutilité ou l’exposition. La réponse change radicalement l’action.

Déprécier proprement, sans casser la confiance

Décider de retirer une feature ne veut pas dire la supprimer du jour au lendemain. La dépréciation est un processus, pas un interrupteur — et la manière dont vous le menez détermine si vous perdez des clients ou si vous gagnez en clarté.

Commencez par arrêter le sang : coupez la découverte. Retirez la feature de l’onboarding, de la documentation mise en avant, des parcours par défaut. Ceux qui l’utilisent déjà y accèdent encore, mais vous cessez d’en recruter de nouveaux utilisateurs. Cette étape ne casse rien et réduit immédiatement votre exposition future.

Ensuite, identifiez nominativement qui l’utilise encore. Sur un produit early-stage, cela représente souvent une poignée de comptes que vous pouvez contacter individuellement. Un message honnête — « nous concentrons nos efforts sur X, cette fonction sera retirée le [date], voici l’alternative » — vaut mille pop-ups automatiques. Les clients pardonnent presque tout sauf d’être pris par surprise. Une dépréciation annoncée trois mois à l’avance avec un chemin de sortie clair passe très bien ; une fonction qui disparaît sans prévenir déclenche des tickets furieux et parfois des résiliations.

Fixez une date de fin ferme et tenez-la. La dépréciation la plus dangereuse est celle qui reste éternellement en « on va bientôt le retirer » : vous cumulez alors le pire des deux mondes, la feature ne recrute plus mais vous continuez de la maintenir. Le gain technique n’arrive qu’au moment de la suppression effective du code. Tant que vous n’avez pas supprimé les tables, les routes et la logique associée, vous n’avez rien économisé.

Un dernier point souvent négligé : documentez la décision. Pourquoi cette feature a été retirée, à quelle date, quelle alternative existe. Sur le marché francophone où les cycles B2B sont longs, un prospect peut redécouvrir votre produit un an plus tard et poser exactement la question à laquelle vous avez déjà répondu. Une trace écrite évite de refaire le débat à chaque fois.

Ce qu’il faut retenir

Retirer une fonctionnalité n’est pas un aveu d’échec, c’est un signe de maturité produit. Les équipes qui savent tuer proprement sont celles qui gardent une vélocité élevée et un produit lisible, parce qu’elles refusent de laisser leur passé dicter leur roadmap.

Concrètement, instaurez une revue de dépréciation régulière — un point trimestriel où vous croisez usage réel, coût de maintenance et alignement avec l’ICP actuel. Coupez d’abord la découverte des candidates évidentes, prévenez nominativement les utilisateurs restants, fixez une date ferme, et n’estimez le gain qu’au moment où le code disparaît vraiment.

La question à vous poser n’est pas « quelle est la prochaine feature à construire ? ». C’est : si vous démarriez votre produit aujourd’hui, avec ce que vous savez de vos clients réels, laquelle de vos fonctionnalités actuelles ne reconstruiriez-vous pas ? Celle-là mérite votre attention avant la suivante.