Chaque feature a un coût que tu ne verras jamais

Une fonctionnalité estimée à deux jours peut engager une équipe pendant des années.

Les deux jours servent à l’écrire, la tester et la livrer. Ensuite, il faudra préserver son comportement, répondre aux utilisateurs qui s’en servent et en tenir compte dans les évolutions du produit. Le ticket sera fermé depuis longtemps.

Je trouve qu’une partie des discussions sur le coût du logiciel s’arrête beaucoup trop tôt. L’estimation répond à « combien de temps pour l’ajouter ? », puis sert à décider si l’ajout en vaut la peine. Entre les deux, toute la vie de la fonctionnalité a disparu du calcul.

Le plus difficile à voir, ce sont les choses qui n’existeront pas parce qu’il faudra continuer à s’occuper de celle-ci.

Deux jours pour l’ajouter. Combien pour la garder ?

Prenons un cas simple : un export CSV sur une page de résultats. Le bouton reprend les données déjà affichées. L’implémentation semble limitée, le besoin est compréhensible et la démonstration tient en un clic.

Supposons maintenant qu’un client branche son propre traitement sur ce fichier. L’ordre des colonnes lui importe. Le nom des champs aussi. Le format des dates, qui semblait être un détail de présentation, devient une entrée attendue par un autre système.

Lorsqu’il faudra faire évoluer les données, l’équipe devra choisir : conserver l’ancien format, proposer plusieurs versions ou accompagner le client dans une migration. Même une modification utile pourra désormais casser un usage qui vit hors de l’application.

Le bouton n’a pas grossi. L’engagement, si.

Ce scénario n’exige ni code bâclé ni mauvaise architecture. L’export peut être propre, testé et parfaitement conforme au besoin initial. C’est son utilisation qui crée une dépendance, donc du travail futur.

Ce travail peut valoir largement la peine. Mais l’estimation de départ ne dit presque rien de son ampleur.

Ce que Bastiat permet de regarder

Dans Ce qu’on voit et ce qu’on ne voit pas, Bastiat invite à examiner les conséquences d’une décision au-delà de son premier effet visible. Certains effets arrivent plus tard. D’autres demandent un effort pour être anticipés.

J’y retrouve une question très concrète pour un backlog : à quoi cette décision va-t-elle prendre du temps ?

La maintenance est une partie de la réponse. L’autre, c’est l’usage alternatif de ce temps : améliorer la recherche, corriger un parcours pénible, remplacer une dépendance vieillissante ou travailler sur un besoin encore sans solution.

C’est le coût d’opportunité. Le temps consacré à une chose n’est plus disponible pour une autre.

Dans notre exemple, une migration du format CSV pourra avoir son ticket, son estimation et sa ligne dans le planning. L’amélioration de la recherche, repoussée pour lui faire de la place, laissera une trace moins nette. Et le besoin auquel personne n’aura eu le temps de réfléchir n’en laissera aucune.

Le coût ne disparaît pas parce qu’il n’a pas de ticket.

La maintenance finit par décider de la suite

Une équipe peut avoir une liste de nouvelles fonctionnalités parfaitement raisonnables et ne plus trouver le temps de les construire. Une partie de sa capacité est déjà engagée par ses décisions précédentes.

Reprenons l’export. Un nouveau modèle de données demande de préserver son format. Un changement dans les droits d’accès impose de revoir les données qu’il expose. Une refonte de la page doit conserver un point d’entrée pour les clients qui l’utilisent.

Chaque évolution arrive avec du travail supplémentaire. À mesure que ces obligations s’accumulent, certaines améliorations deviennent trop coûteuses pour le bénéfice attendu. Elles sont réduites, reportées ou abandonnées.

Une fonctionnalité peut ainsi limiter les choix futurs sans jamais provoquer de bug spectaculaire.

Personne n’ouvrira un incident pour signaler que le produit aurait pu être plus simple. Le système continuera à fonctionner. L’équipe fera seulement moins de choses avec le même temps, parce que chaque changement devra préserver davantage de comportements.

Je veux pouvoir discuter de ce coût même lorsque le code est bon. Sinon, le débat retombe sur « il fallait mieux développer », et la décision d’ajouter la fonctionnalité échappe à toute réévaluation.

Le visible arrive avec une démonstration

Une fonctionnalité livrée se montre. Le bouton existe, le parcours fonctionne, le client peut s’en servir. Son bénéfice a un visage.

Le choix de ne pas l’ajouter est beaucoup plus difficile à présenter. Pas de capture avant-après. Aucun utilisateur pour remercier l’équipe d’avoir évité une dépendance dont il n’aura jamais connaissance. Le bénéfice apparaîtra peut-être au moment d’une évolution future, parce qu’elle sera restée simple.

L’asymétrie est forte. Celui qui propose un ajout peut décrire un besoin immédiat. Celui qui questionne son coût futur doit défendre des possibilités qui n’existent pas encore.

Il serait pourtant absurde de ne compter que ce qui se montre. Cela favoriserait systématiquement l’accumulation, jusqu’au moment où l’équipe se retrouve à expliquer pourquoi tout prend désormais plus longtemps.

J’ai déjà décrit un mécanisme proche dans mes cinq fatigues : les process ajoutés après un incident, puis jamais réévalués. J’en ai proposé moi-même. Ajouter une règle donnait une réponse visible au problème. Revenir vérifier ce qu’elle coûtait six mois plus tard avait manifestement moins de succès dans mon calendrier.

Une fonctionnalité mérite le même examen. Le fait qu’elle ait justifié son existence au départ ne règle pas la question pour toujours.

Décider aussi de ce qu’on accepte d’entretenir

Je ne cherche pas une estimation miraculeuse du coût total sur cinq ans. Personne ne connaît tous les usages à venir. Mais cette incertitude laisse de la place à des questions très concrètes.

Pour l’export CSV : est-ce un téléchargement ponctuel ou une interface sur laquelle des clients vont construire leurs outils ? Quel comportement promet l’équipe ? Comment pourra-t-elle le faire évoluer ?

Les réponses peuvent changer le périmètre dès le départ. Proposer un format unique, documenter ce qui est stable, prévoir la migration si des usages automatisés sont attendus. Ce sont des décisions de produit autant que des décisions techniques.

Et après la livraison, je veux pouvoir réexaminer l’engagement. Qui utilise encore cette fonctionnalité ? Pour quel bénéfice ? Que coûte sa présence dans les changements récents ? Que demanderait son retrait aux utilisateurs ?

Une fonctionnalité peu utilisée peut être essentielle à quelques clients. Une autre peut être devenue remplaçable. Il faut regarder les usages pour trancher, puis accepter que retirer demande aussi du travail : prévenir, accompagner, migrer.

Tout garder par défaut est déjà une décision. Elle réserve du temps futur sans toujours nommer ce qu’elle évince.

La prochaine fois qu’une fonctionnalité paraît peu chère, je veux donc prolonger la discussion au-delà de sa livraison.

Deux jours pour l’ajouter, d’accord. Qu’est-ce qu’on accepte de ne plus faire pour la garder ?