Quand supprimer une fonctionnalité SaaS ?

Supprimer une fonctionnalité SaaS devient raisonnable quand elle coûte plus au produit qu'elle ne lui apporte. Mais un bouton peu utilisé ne suffit pas pour trancher. Il faut savoir qui s'en sert, quel revenu il protège, ce que les contrats promettent et ce que sa présence complique ailleurs. Parfois, mieux vaut garder, simplifier ou renégocier. L'enjeu consiste à empêcher une ancienne décision de ralentir celles qui comptent aujourd'hui, pas à faire le ménage pour le plaisir.

Je me souviens d'une mission d'un an pour une PME en 2023. L'application gérait des millions d'articles, des règles métier complexes et cinq API de fournisseurs externes. Chaque semaine, le porteur de projet m'appelait avec de nouvelles demandes.

Nous en livrions plusieurs par semaine. Le client voyait le périmètre avancer et il était satisfait. Moi aussi. Je recommandais pourtant de réserver du temps à la stabilisation, mais les demandes continuaient d'arriver. La pause que j'attendais n'est jamais venue.

Au bout d'un an, le budget a commencé à manquer. Il ne restait plus assez de temps pour reprendre proprement ce qui s'était accumulé. Avec le recul, stabiliser n'était qu'une partie de la réponse. Nous aurions aussi dû décider plus tôt quelles demandes méritaient d'entrer dans le produit et lesquelles pouvaient attendre.

Le problème commence quand le produit dit toujours oui

Une fonctionnalité utile le jour de sa livraison ne le reste pas forcément. Le besoin peut disparaître, le client concerné peut partir ou un autre parcours peut rendre l'ancienne option inutile. Pourtant, les produits savent très bien ajouter et beaucoup moins bien retirer.

Cette logique est difficile à contrer. Une nouveauté se montre pendant une démonstration. Une suppression déclenche des questions et peut donner l'impression que le produit régresse. La roadmap favorise donc ce qui entre, même lorsque personne ne vérifie ce qui sert encore.

Au début, rien ne casse franchement. L'interface accumule une variante par rôle. Le support doit demander quel ancien parcours le client utilise. La recette couvre des comportements dont plus personne ne connaît la raison. Puis une petite modification des permissions se transforme en enquête.

Le code peut être propre et le problème rester entier. Une fonctionnalité bien développée occupe tout de même une place dans les tests, la documentation et les décisions futures. Martin Fowler appelle cela le « cost of carry », le coût de ce que le logiciel continue de porter. Réécrire le même comportement plus proprement ne répond pas à la question qui compte. Mérite-t-il encore d'exister ?

J'ai déjà détaillé le coût réel d'une fonctionnalité avant et après sa livraison. Ici, je pars d'un SaaS déjà en place. Il ne s'agit plus d'estimer une nouvelle fonction, mais de décider ce qui mérite de rester dans le produit.

Les fonctions inutiles bloquent les fonctions utiles

Une fonctionnalité peu utilisée coûte des heures de maintenance et prend de la place dans les arbitrages. Dès qu'une évolution touche les données, les permissions ou la facturation, l'équipe doit vérifier si l'ancien comportement doit suivre.

L'équipe paie ce coût sans toujours le voir. Une amélioration centrale attend parce qu'une variante promise autrefois à un seul compte complique la mise en production. Le backlog montre la nouvelle demande en retard. Il ne montre pas l'ancienne décision qui l'a ralentie.

Le support paie aussi cette accumulation. Plus le produit contient de chemins différents, plus un problème demande de contexte avant d'être reproduit. La personne qui répond doit connaître l'historique des options, les droits associés et parfois la version particulière négociée avec le client. L'ancienneté dans l'équipe devient alors une dépendance.

Les ventes finissent par le sentir. Une démonstration devient plus difficile à raconter. Le commercial hésite entre plusieurs façons de répondre au même besoin. Lorsqu'un prospect demande une adaptation, personne ne sait si elle complète le produit ou ajoute une exception de plus.

Recruter un développeur supplémentaire ne règle pas ce problème. La nouvelle personne doit apprendre pourquoi chaque comportement existe avant de pouvoir le modifier sans risque. J'aborde cette dépendance dans l'article consacré à la codebase qui doit grandir avec l'équipe. Ajouter de la capacité aide seulement si le produit sait aussi réduire ce qu'il demande à l'équipe de préserver.

Mesurez l'usage avant de décider

Quand je mène ce type de revue, je commence par les fonctions qui reviennent dans les estimations, les incidents ou les questions du support. Une analyse exhaustive du SaaS prendrait des semaines et finirait probablement dans un document oublié. Quelques zones pénibles donnent déjà une bonne liste de départ.

Pour chaque fonction, cherchez qui l'utilise réellement. Un compte activé ne prouve rien. Regardez la fréquence, le nombre d'utilisateurs concernés et la dernière utilisation. Si vous ne disposez pas encore de ces données, ajoutez une mesure avant de décider. Supprimer à l'intuition peut coûter un grand compte pour un gain dérisoire.

Reliez cet usage à la valeur. La fonction protège-t-elle un revenu identifiable ? Figure-t-elle dans un contrat ou dans un engagement commercial ? Aide-t-elle à vendre le cœur du produit, ou sert-elle surtout à rassurer pendant les démonstrations ? Une option rarement utilisée peut rester décisive si elle répond à une obligation précise.

Regardez aussi ce qu'elle impose autour d'elle. Combien de demandes récentes ont dû la prendre en compte ? Combien de tickets de support lui sont liés ? Qui sait encore expliquer ses règles ? Une fonction stable et isolée peut rester peu coûteuse. Une option discrète qui touche les permissions, les exports et la facturation peut ralentir chaque évolution voisine.

N'essayez pas d'en tirer un score parfait. Produit, vente, support et technique ne voient pas la même partie de la fonction. Mettez ces points de vue autour de la table. La décision devient fragile dès qu'une seule équipe prétend connaître toute sa valeur.

Un CTO à temps partiel peut cadrer cette revue lorsque les dépendances ne sont plus lisibles, mais l'arbitrage reste une décision d'entreprise. La technique explique le coût et le risque. Le produit et la direction choisissent ce qui mérite encore d'être porté.

Gardez, simplifiez, renégociez ou supprimez

Garder une fonctionnalité demande une décision explicite. Si elle est utilisée, liée au revenu et cohérente avec la promesse du SaaS, protégez-la. Clarifiez ses règles, automatisez les vérifications importantes et refusez les variantes qui l'éloigneraient de son usage principal.

Parfois, le besoin reste réel mais le produit propose trop de chemins pour y répondre. Plusieurs écrans, options ou règles peuvent être ramenés à un parcours commun. Vous retirez alors de la complexité sans retirer la valeur recherchée par le client.

Une fonction utilisée par peu de monde peut protéger un contrat sensible. Ne la supprimez pas en silence. Proposez une autre façon de répondre au besoin, préparez une migration ou discutez du coût d'un maintien spécifique. Cette conversation vaut mieux qu'une promesse marginale qui ralentit toute la roadmap.

La suppression se justifie quand l'usage est faible, la valeur introuvable et le coût récurrent. Procédez par étapes. Identifiez les comptes concernés, prévenez-les et proposez une alternative si le besoin existe encore. Annoncez une date d'arrêt, puis observez les réactions avant de retirer les données ou le code associés.

Mettez cette revue dans la roadmap. Pour une petite équipe, un rendez-vous trimestriel suffit souvent. Choisissez une fonction qui gêne vraiment l'équipe et prenez une décision. Sans ce rendez-vous, l'ajout redevient le choix par défaut et le produit s'alourdit sans bruit.

Ce qu'il faut retenir

Ne supprimez pas une fonctionnalité parce que son bouton reçoit peu de clics. Comparez son usage, le revenu ou l'engagement qu'elle protège et ce qu'elle complique ailleurs. Une fonction rare peut être indispensable. Une fonction visible peut être devenue inutile.

Vous pouvez garder, supprimer, mais aussi simplifier ou renégocier. Ces deux dernières options enlèvent parfois plus de complexité avec moins de risque. Un SaaS avance mieux quand son équipe décide aussi sérieusement de ce qu'elle retire que de ce qu'elle ajoute.

Questions fréquentes

Comment savoir si une fonctionnalité est vraiment inutilisée ?

Mesurez son utilisation sur une période cohérente avec le rythme de vos clients, puis vérifiez les contrats et les usages indirects. Une fonction annuelle peut sembler inactive pendant onze mois. Croisez les données avec le support et les équipes commerciales avant de conclure.

Peut-on supprimer une fonctionnalité demandée par un client ?

Oui, mais pas sans vérifier l'engagement pris et le besoin qui se cache derrière la demande. Proposez une alternative ou une transition si ce besoin reste légitime. Pour une fonction spécifique à un seul compte, la discussion peut aussi porter sur le coût de son maintien.

À quelle fréquence faut-il revoir les fonctionnalités existantes ?

Une revue trimestrielle suffit souvent pour une petite équipe SaaS. Commencez par les zones qui génèrent du support ou compliquent régulièrement les estimations. Chaque session doit aboutir à une décision concrète sur une fonction, sans rouvrir tout le produit.

Conclusion

Réservez un échange de 30 minutes pour identifier les fonctions que votre SaaS doit garder, simplifier, renégocier ou supprimer.