RSS Amplifier

Produit sans Filtre · Aug 20, 2026

Une feature ne vieillit pas comme une API

0
Sign in to vote or save

Julien Brionne · Produit sans Filtre

Je continue ma série d’été avec un sujet qui me fascine : les vieux produits.

Pas forcément les produits techniquement vieux.

Ceux qui ont vécu.

Ceux sur lesquels on tombe sur un champ bizarre et où un dev commence sa réponse par :

« Alors, historiquement… »

En général, la suite est intéressante.

On parle beaucoup de dette technique. Mais à force de travailler sur des produits qui ont quelques années derrière eux, je trouve le terme un peu fourre-tout.

Tout ne vieillit pas de la même manière.

Une feature, par exemple, vieillit souvent en accumulant des cas particuliers.

Au départ, elle fait une chose.

Puis arrive un gros client qui a besoin d’une variante.
Un pays avec une règle différente.
Un cas qu’on n’avait pas prévu.
Une option qu’on garde « au cas où ».

Rien de dramatique pris séparément.

C’est cinq ans plus tard que ça devient amusant, quand quelqu’un propose de simplifier la feature et que la réunion commence par :

« Attends, je crois qu’on a encore des utilisateurs qui font ça. »

Personne ne sait vraiment lesquels.

Une API, c’est différent.

Elle peut traîner pendant des années une décision prise en vingt minutes.

Un nom de champ pas terrible.
Une structure qu’on aurait dessinée autrement aujourd’hui.
Une première version qu’on ne peut plus vraiment supprimer.

Et c’est normal : des gens ont construit dessus.

J’aime bien regarder les APIs comme une collection de vieilles promesses.

Certaines sont toujours importantes.

Pour d’autres, on continue simplement de payer parce que personne ne sait plus à qui on les a faites.

Les dashboards ont encore une autre façon de prendre de l’âge.

Eux, ils grossissent.

J’ai rarement vu quelqu’un organiser une réunion pour supprimer trois métriques d’un dashboard.

Pour en ajouter trois, en revanche…

Résultat : certaines boîtes ont des dashboards qui ressemblent à des cockpits d’Airbus.

Tout est vrai.
Tout est mesuré.
Tout a probablement été important à un moment.

Mais demandez :

« Si cette courbe passe au rouge demain, qu’est-ce qu’on fait différemment ? »

Et parfois, la réponse est : rien.

C’est généralement un bon indice qu’elle peut prendre sa retraite.

Les workflows, eux, me font souvent penser aux chemins qu’on crée dans un parc.

Il y a le chemin officiel.

Et puis il y a celui que tout le monde prend vraiment.

Un incident a ajouté une validation.
Un client important a créé une procédure spéciale.
Une urgence a créé un raccourci.
Quelqu’un a quitté la boîte, mais son étape est restée.

Au bout d’un moment, la documentation décrit une organisation théorique.

Et les gens ont développé la vraie à côté.

C’est souvent assez instructif de demander :

« Pourquoi on fait encore cette étape ? »

Si la réponse commence par le prénom de quelqu’un qui a quitté la boîte il y a trois ans, je creuse.

Et puis il y a le modèle de données.

Celui-là est probablement mon préféré.

Parce qu’il raconte la manière dont l’entreprise pensait son métier au moment où elle a construit le produit.

Un utilisateur appartient à un compte.

Évidemment.

Jusqu’au premier utilisateur qui doit appartenir à deux comptes.

Une commande a un client.

Évidemment.

Jusqu’au moment où celui qui paie, celui qui utilise et celui qui reçoit deviennent trois personnes différentes.

Le produit doit alors trouver un moyen de faire rentrer la nouvelle réalité dans l’ancien modèle.

Puis une autre.

Puis une autre.

Quelques années plus tard, vous trouvez un champ au nom incompréhensible utilisé dans douze endroits.

Et quelqu’un vous dit :

« Historiquement… »

Nous y voilà.

C’est probablement ce qui m’intéresse le plus dans les produits qui ont vécu.

Ils ne deviennent pas complexes d’un seul coup.

Ils gardent des petites traces de tout ce qui leur est arrivé.

Un client important dans une feature.
Une vieille promesse dans une API.
Une priorité de 2022 dans un dashboard.
Un incident dans un workflow.
Une ancienne vision du métier dans le modèle de données.

Et toutes ces traces ne méritent pas forcément d’être supprimées.

Mais de temps en temps, ça vaut le coup de demander si la raison pour laquelle elles existent… existe encore.

Question de vacances :

c’est quoi le meilleur « historiquement… » que vous avez découvert dans un produit ?

Aucun post

Read the original on produitsansfiltre.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.