Comment on décide d'arrêter une fonctionnalité

On sait tous ajouter des fonctionnalités. Presque personne ne sait en enlever.

Pourtant chaque fonctionnalité inutilisée continue de coûter : elle doit être testée à chaque livraison, migrée à chaque changement de version, expliquée à chaque nouvel arrivant, et elle occupe de la place dans une interface où l’attention est le vrai budget rare.

Les trois chiffres qui décident

Le nombre d’utilisateurs distincts sur trois mois. Pas le nombre de clics : le nombre de personnes différentes. Dix mille clics d’une seule personne, c’est une automatisation déguisée, pas un usage.

La part dans les demandes de support. Une fonctionnalité peu utilisée mais qui génère 15 % des tickets est un problème double : elle sert peu et coûte cher.

Le coût qu’elle impose au reste. Combien de fois, au cours des six derniers mois, une évolution a-t-elle été compliquée par son existence ? C’est le chiffre le plus difficile à obtenir et le plus important — c’est celui qui transforme un désagrément en décision.

Mon seuil de déclenchement : moins de 2 % des utilisateurs sur trois mois, et un coût d’entretien avéré. En dessous de 2 %, on peut traiter les cas restants individuellement, ce qui coûte moins cher que de maintenir le code.

Le vrai obstacle n’est pas technique

Supprimer du code est facile. Ce qui bloque, c’est que personne n’a intérêt à le proposer.

Celui qui a demandé la fonctionnalité y voit un désaveu. Celui qui l’a développée y voit son travail jeté. Et personne, dans aucune organisation que je connaisse, n’est félicité pour avoir retiré quelque chose.

D’où deux principes que j’applique.

Ne jamais présenter une suppression comme une correction d’erreur. La fonctionnalité était probablement justifiée quand elle a été demandée. Le contexte a changé — c’est tout, et c’est normal.

Rendre le coût visible avant de proposer. « Cette fonctionnalité est utilisée par trois personnes, elle représente 12 % de notre temps de test, et elle nous a coûté quatre jours sur les deux dernières évolutions. » Le débat cesse d’être une question de goût.

Photo : JESHOOTS.com — licence CC0.

Comment je m’y prends, concrètement

Mesurer avant de proposer. Sans chiffres, la discussion se règle au rapport de force. Avec des chiffres, elle se règle en dix minutes.

Prévenir les utilisateurs concernés, nommément. Trois personnes l’utilisent : je leur parle. Neuf fois sur dix, elles ont déjà une autre façon de faire, ou leur besoin réel se traite autrement. Une fois sur dix, on découvre un usage critique que personne n’avait vu — et c’est précisément pour ça qu’on demande.

Retirer de l’interface avant de supprimer le code. On masque l’entrée pendant un ou deux mois. Si personne ne se manifeste, on supprime pour de bon. Si quelqu’un se manifeste, on réactive en une minute. Ce délai coûte peu et supprime le risque.

Écrire ce qu’on a retiré et pourquoi. Sinon, la même fonctionnalité sera redemandée dans dix-huit mois, et personne ne saura qu’elle avait déjà été retirée pour de bonnes raisons.

Ce que j’ai appris en me trompant

J’ai supprimé une fois un export utilisé par deux personnes. Les chiffres étaient sans appel.

Ces deux personnes préparaient le reporting mensuel présenté au comité de direction. L’export était marginal en usage et central en importance.

Depuis, j’ai ajouté une question à ma grille : à quoi sert ce que produit cette fonctionnalité, une fois sorti de l’application ? Le volume d’usage ne dit rien de l’enjeu, et c’est exactement le genre de nuance qu’un tableau de bord ne montrera jamais.

Photo : domaine public (CC0).

Comment éviter d’en arriver là

Le meilleur moyen de ne pas avoir à supprimer est de ne pas construire ce qui ne servira pas. Trois habitudes réduisent beaucoup le volume à retirer plus tard.

Mesurer dès la mise en service. Chaque fonctionnalité livrée est instrumentée dès le premier jour : combien de personnes distinctes l’utilisent, à quelle fréquence. Sans cette mesure prise au départ, on ne saura jamais rien — et l’on gardera par précaution.

Fixer une date de revue. Quand une fonctionnalité est demandée sans certitude, je note dans le suivi : « à réévaluer dans six mois ». Cette simple ligne transforme une décision douloureuse en rendez-vous prévu.

Proposer une alternative moins coûteuse. Souvent, un export existant ou un filtre bien placé répond au besoin pour un dixième du coût. Cette conversation doit avoir lieu avant le développement, pas deux ans après.

Photo : domaine public (CC0).

Le cas des fonctionnalités jamais terminées

Il existe une catégorie particulière : celle qui a été commencée, jamais finie, et jamais retirée. Elle est accessible dans l’interface, à moitié fonctionnelle, et tout le monde sait qu’il ne faut pas s’en servir.

C’est le pire des cas. Elle porte tous les coûts d’une fonctionnalité — tests, migrations, confusion des utilisateurs — sans en avoir aucun bénéfice. Et elle abîme la confiance dans l’ensemble du produit : un utilisateur qui tombe sur une page cassée doute de tout le reste.

Ma règle est sans nuance : soit on la termine dans le trimestre, soit on la retire. Il n’y a pas de troisième option, et laisser traîner est toujours la plus coûteuse.

Retirer sans casser

Une suppression mal menée abîme plus la confiance que la fonctionnalité ne rapportait.

Ma séquence, sur six à huit semaines. Prévenir les utilisateurs concernés nommément, pas par une annonce générale — ils sont rarement nombreux, et un message personnel change complètement la réception. Proposer ce qu’ils feront à la place, même si c’est moins confortable ; une suppression sans alternative est vécue comme un abandon. Couper l’accès pour les nouveaux utilisateurs d’abord, en laissant les usagers actuels finir leur cycle. Retirer le code ensuite, une fois que plus personne ne l’appelle.

Et un point que j’ajoute toujours : conserver les données. Retirer une fonctionnalité ne justifie pas de supprimer l’historique qu’elle a produit. Cette distinction paraît évidente et elle est régulièrement oubliée, avec des conséquences irréversibles.

Mesurer avant de pouvoir décider

Rien de tout cela n’est possible si l’on ne sait pas qui utilise quoi. Or c’est le cas le plus fréquent : la question se pose, et personne n’a de chiffre.

Le minimum utile tient en deux mesures par fonctionnalité : le nombre d’utilisateurs distincts sur les trente derniers jours, et la date du dernier usage. Deux compteurs, posés une fois, qui suffisent à rendre la conversation factuelle.

Ce que je conseille : instrumenter dès la mise en service, pas au moment où le doute apparaît. Poser la mesure après coup impose d’attendre plusieurs mois avant de disposer de données exploitables — et pendant ce temps, la fonctionnalité continue de coûter.

Ce que la suppression rapporte

Le bénéfice n’est pas le code en moins. Il est ailleurs, et il se voit vite.

Les tests tournent plus vite, donc les livraisons sont plus fréquentes. L’interface se lit plus facilement, donc les nouveaux utilisateurs se forment plus vite. Et les évolutions futures coûtent moins cher, parce qu’il y a moins de cas à préserver.

Une application qui ne fait que grossir finit toujours au même endroit : plus personne n’ose y toucher. Retirer régulièrement est ce qui permet de continuer à ajouter.