Mon article en bref
Le feature creep, ou dérive fonctionnelle, est l’accumulation progressive de fonctionnalités jusqu’au point où elles dégradent l’usage du produit. Le phénomène ne vient pas d’une mauvaise décision, mais d’une longue série de bonnes décisions prises isolément.
Voici les points essentiels à retenir :
- Définition : un produit devenu difficile à utiliser à force d’ajouts, chacun défendable, l’ensemble non.
- Le mécanisme : le bénéfice d’un ajout est immédiat et attribuable, son coût est différé et partagé par tous.
- Le coût caché : chaque option ajoutée renchérit toutes les autres, y compris pour ceux qui ne s’en serviront jamais.
- À ne pas confondre : le scope creep gonfle le périmètre d’un projet, le feature creep alourdit un produit version après version.
- Le geste rare : retirer une fonctionnalité. Presque aucune équipe ne le fait, et c’est pourtant le seul mouvement qui inverse la pente.
- Le réflexe utile : décider dès l’ajout à quelle condition on retirera.
Le feature creep, ou dérive fonctionnelle, désigne l’accumulation progressive de fonctionnalités dans un produit jusqu’au point où elles nuisent à son usage. Chaque ajout paraît justifié pris isolément ; c’est leur empilement qui rend le produit confus, long à apprendre et coûteux à faire évoluer.
Cet article regarde la dérive du côté du produit : le mécanisme qui fait qu’un produit ne rétrécit jamais, ce que chaque option coûte à ceux qui ne s’en servent pas, et le geste que presque personne n’ose — retirer une fonctionnalité. Le volet organisationnel (allocation des budgets, évaluation des équipes au débit de livraison, mesure de l’impact) relève d’une notion voisine, la feature factory, et se traite à part.
Sommaire
Feature creep : définition et traduction
Le terme se traduit par dérive fonctionnelle ou surcharge fonctionnelle, et l’anglais connaît une variante plus ancienne, creeping featurism. Le verbe to creep, « ramper », dit l’essentiel : la dérive progresse assez lentement pour qu’aucune version ne paraisse déraisonnable, et suffisamment longtemps pour que le produit finisse méconnaissable.
Le résultat, lui, porte plusieurs noms en français. L’Office québécois de la langue française recense logiciel mémorivore, inflagiciel et obésiciel pour désigner un logiciel qui accumule une quantité importante de fonctions disparates et consomme des ressources hors de proportion avec son usage réel. La dérive fonctionnelle est le processus ; l’obésiciel en est le produit fini.
Feature creep ou scope creep : quelle différence ?
Le scope creep est la dérive du périmètre d’un projet : on ajoute des demandes en cours de route, les délais et le budget dérapent. Le feature creep est la dérive du produit : il s’alourdit version après version, sur plusieurs années, sans qu’aucun projet particulier n’ait dérapé.
| Feature creep | Scope creep | |
|---|---|---|
| Ce qui grossit | Le produit, version après version | Le périmètre d’un projet, en cours de route |
| Horizon | La vie du produit, souvent plusieurs années | La durée du projet, quelques mois |
| Symptôme visible | Une interface surchargée, un produit long à apprendre | Des délais qui glissent, un budget dépassé |
| Qui le constate | L’utilisateur, souvent avant l’équipe | L’équipe et le commanditaire |
| Le remède | Arbitrer, refuser, retirer | Cadrer, tracer et négocier les changements |
Les deux se cumulent volontiers, mais leurs remèdes n’ont rien à voir : le scope creep se traite par le cadrage, la dérive fonctionnelle par des arbitrages répétés tout au long de la vie du produit.
Pourquoi un produit ne rétrécit jamais
La dérive fonctionnelle fonctionne comme un cliquet : le produit peut grossir, il ne peut pratiquement pas maigrir. Ce n’est pas une question de discipline, mais d’asymétrie entre ce que rapporte un ajout et ce qu’il coûte — asymétrie qui explique pourquoi des équipes très sérieuses aboutissent à un produit illisible.
Chaque ajout est défendable, l’ensemble ne l’est plus
- Le bénéfice est immédiat, le coût est différé — la fonctionnalité débloque une vente cette semaine ; la complexité qu’elle ajoute se paiera dans deux ans, sur des sujets sans rapport apparent.
- Le bénéfice est attribuable, le coût est partagé — quelqu’un a demandé cet ajout et pourra s’en réclamer. Le coût se répartit sur toute l’interface : personne n’en est propriétaire, donc personne ne le défend.
- Ajouter se décide, retirer se négocie — un ajout se justifie par une demande. Un retrait doit affronter les quelques utilisateurs qui se manifesteront, et eux seuls se manifesteront.
- Le refus est plus coûteux que l’acceptation — dire non demande d’argumenter, de décevoir, parfois d’assumer un arbitrage devant un client important. Dire oui ne demande rien.
- Aucun processus ne prévoit la sortie — les rituels produit savent tous faire entrer une idée dans le backlog produit. Presque aucun ne prévoit d’en faire sortir une fonctionnalité déjà livrée.
Ces cinq forces poussent toutes dans le même sens, et aucune ne pousse dans l’autre : un produit livré à lui-même n’a aucune raison de se simplifier. S’y ajoute la nature des demandes entrantes, où le client bruyant pèse structurellement plus lourd que le silence des autres. Un dispositif de voice of customer sert précisément à corriger ce biais, en ramenant le besoin exprimé à sa fréquence réelle.
Un produit ne devient jamais complexe par une grande décision. Il le devient par cinquante petites, toutes raisonnables au moment où elles ont été prises.
Quand l’organisation elle-même évalue ses équipes sur le nombre de livraisons plutôt que sur l’effet obtenu, la dérive cesse d’être une pente pour devenir une consigne. Ce cas de figure porte un nom — la feature factory — et relève d’un tout autre registre de correctifs, du côté des budgets et des objectifs. Le reste de cet article se tient au niveau du produit.
Le coût d’usage : chaque option renchérit les autres
Le feature creep est le plus souvent réduit à un problème de coût de développement. C’est surtout un problème de coût d’usage : une fonctionnalité ajoutée ne s’additionne pas aux précédentes, elle les rend toutes un peu plus difficiles à trouver et à comprendre.
La huitième des dix heuristiques d’utilisabilité de Jakob Nielsen, Aesthetic and Minimalist Design, le formule sans détour : chaque élément d’information supplémentaire dans une interface entre en concurrence avec les éléments pertinents et diminue leur visibilité relative. Autrement dit, le coût d’un ajout n’est pas payé par lui : il est prélevé sur tout ce qui existait déjà.
Le temps de décision croît avec le nombre de choix
Le second mécanisme est cognitif. La loi de Hick, établie en 1952 par les psychologues William Edmund Hick et Ray Hyman, énonce que le temps nécessaire pour prendre une décision augmente avec le nombre et la complexité des choix proposés. Un menu de quatre entrées ne se parcourt pas quatre fois plus vite qu’un menu de seize : il se parcourt sans y penser.
Le coût est payé par tous, le bénéfice par quelques-uns
C’est la conséquence la plus contre-intuitive, et celle qui devrait suffire à trancher la plupart des arbitrages. Une fonctionnalité utilisée par une petite partie des utilisateurs impose une charge à la totalité d’entre eux :
- Dans l’interface — un élément de plus à écarter du regard, un libellé de plus à interpréter avant de trouver le bon.
- À la prise en main — un parcours d’accueil qui s’allonge, ou qui sacrifie l’essentiel pour ne pas s’allonger.
- Dans le support — des pages d’aide qui se multiplient, et une question récurrente : « où est passée la fonction que j’utilisais ? ».
- Dans les tests — les combinaisons d’états à vérifier croissent bien plus vite que le nombre de fonctionnalités, ce qui ralentit chaque livraison suivante.
- Dans les décisions futures — chaque nouveau chantier doit rester compatible avec l’existant, y compris avec ce dont personne ne se sert.
Cacher n’est pas retirer
La divulgation progressive — n’afficher une option qu’au moment où elle devient utile — est une bonne pratique d’ergonomie et Nielsen la recommande explicitement. Elle règle le coût visuel, pas les autres. Une fonctionnalité reléguée dans un menu « Avancé » continue d’être testée, maintenue, documentée et prise en compte dans les décisions suivantes. Le menu « Avancé » d’un produit ancien est rarement une salle d’attente : c’est un cimetière.
Retirer une fonctionnalité : le geste que personne ne fait
Si la dérive fonctionnelle est un cliquet, il n’existe qu’une manière de l’inverser : retirer. Pas reporter, pas masquer, pas refactoriser — supprimer la fonctionnalité, son interface et son code. C’est une opération courante dans les produits en bonne santé, et pratiquement inexistante partout ailleurs.
Pourquoi le retrait n’arrive jamais
Trois raisons reviennent systématiquement. L’asymétrie des réactions, d’abord : ceux qui utilisaient la fonctionnalité écriront, ceux qui bénéficient de sa disparition ne diront jamais merci, faute de savoir ce qu’ils ont gagné. Le coût déjà engagé, ensuite — l’équipe a passé des semaines à la construire, la retirer ressemble à un aveu. Et la plus banale : personne ne pense que la laisser coûte quelque chose, puisqu’elle fonctionne. Cette dernière croyance est la seule vraiment fausse. Une fonctionnalité inutilisée prélève sa dîme sur chaque parcours, chaque test et chaque décision d’architecture.
Comment retirer proprement
- Mesurer l’usage réel — nombre d’utilisateurs actifs distincts sur une période représentative, jamais le nombre de clics cumulés depuis le lancement, qui est une vanity metric typique.
- Regarder qui l’utilise, pas combien — deux comptes stratégiques valent plus d’attention que deux cents comptes d’essai. Le volume seul ne décide pas.
- Annoncer avant de couper — une période de dépréciation annoncée, avec une date, un message dans le produit et une alternative nommée. La colère vient presque toujours de la surprise, pas du retrait.
- Éteindre progressivement — désactiver d’abord pour les nouveaux comptes, puis par cohortes, en gardant la possibilité de revenir en arrière le temps de vérifier qu’aucun usage critique n’a été manqué.
- Supprimer le code — l’étape que l’on saute, et sans laquelle rien n’a été gagné : le coût de maintenance et de test reste entier tant que le code est là.
💡 Le critère de sortie, décidé à l’entrée — au moment de valider une fonctionnalité, écrivez la condition qui justifierait de la retirer : « si moins de tant de comptes l’utilisent après deux trimestres, on la supprime ». Cela ne coûte rien sur le moment et transforme un débat d’ego en simple vérification.
C’est, à mon avis, la seule pratique qui distingue durablement une équipe produit d’une équipe qui empile. Elle rejoint le principe que Basecamp résume dans Half, Not Half-Assed : mieux vaut livrer la moitié d’un produit qu’un produit à moitié fait. Ce qui vaut au lancement vaut ensuite à chaque version.
Comment éviter le feature creep
Aucune méthode ne supprime la pression d’ajout : elle est légitime et vient de partout. En revanche, plusieurs pratiques rétablissent l’équilibre entre le coût et le bénéfice au moment où la décision se prend, c’est-à-dire avant que la fonctionnalité existe.
- Formuler un problème, pas une solution — une demande arrive presque toujours sous forme de solution. La ramener au problème qu’elle prétend résoudre élimine une bonne part des ajouts, souvent en révélant que le produit y répond déjà : c’est l’objet de la product discovery.
- Écrire ce que la fonctionnalité ne fera pas — la spec produit gagne à comporter une section « hors périmètre » explicite. Un non écrit tient ; un non oral revient au sprint suivant.
- Trancher avec une méthode assumée — la priorisation MoSCoW force à ranger dans « Won’t have », le scoring ICE oblige à estimer l’impact avant de s’engager. Leur mérite n’est pas la précision du calcul : c’est de rendre le refus discutable sur des critères plutôt que sur un rapport de force.
- Sortir en version réduite — la logique du MVP reste valable après le lancement : livrer la version la plus simple qui résout le problème, puis n’enrichir que si l’usage le réclame.
- Dessiner avant de construire — un wireframe révèle ce qu’une spécification masque : si le nouvel élément ne trouve plus de place lisible dans l’écran, la question n’est pas où le mettre, mais ce qu’il faut en retirer.
- Tenir un budget de complexité — s’obliger à un retrait pour un ajout dans une même zone du produit. La contrainte paraît artificielle ; elle est le seul contrepoids symétrique à la pression d’ajout.
⚠️ L’erreur classique — traiter la dérive fonctionnelle comme un problème de rangement. Réorganiser les menus, ajouter une recherche interne ou un parcours d’accueil soulage les symptômes et achète douze mois. Le nombre de fonctionnalités, lui, n’a pas bougé, et la dérive reprend exactement là où elle s’était arrêtée.
Une dernière remarque, moins méthodologique. Un produit simple n’est pas un produit pauvre : c’est un produit dont quelqu’un a payé le prix des refus. La dérive fonctionnelle est confortable précisément parce qu’elle évite toutes les conversations difficiles — avec un client, un commercial, un dirigeant, parfois avec sa propre équipe.
FAQ — Tout savoir sur le feature creep
Feature creep : que veut dire cette expression en français ?
Elle se traduit par « dérive fonctionnelle » ou « surcharge fonctionnelle » et désigne l’accumulation progressive de fonctionnalités jusqu’au point où elles dégradent l’usage du produit. Le logiciel qui en résulte est parfois appelé obésiciel ou inflagiciel.
Quelle différence entre feature creep et scope creep ?
Le scope creep est la dérive du périmètre d’un projet, qui gonfle en cours de route et fait déraper délais et budget. Le feature creep est la dérive du produit, qui s’alourdit version après version sur plusieurs années sans qu’aucun projet n’ait dérapé.
Quelles sont les causes du feature creep ?
Une asymétrie de décision : le bénéfice d’un ajout est immédiat et attribuable à quelqu’un, son coût est différé et réparti sur tout le produit. S’y ajoute le fait qu’aucun processus produit ne prévoit de faire sortir une fonctionnalité déjà livrée.
Comment savoir si mon produit souffre de feature creep ?
Trois signaux suffisent : le parcours d’accueil s’allonge à chaque version, le support reçoit des questions du type « où est passée la fonction que j’utilisais ? », et personne ne sait dire quelle fonctionnalité pourrait être retirée sans gêner qui que ce soit.
Faut-il vraiment supprimer une fonctionnalité peu utilisée ?
Souvent oui, car son coût est payé par tous les utilisateurs alors que son bénéfice ne touche qu’une minorité. La décision se prend sur l’usage réel et sur le profil des comptes concernés, avec une période de dépréciation annoncée et une alternative proposée.
Le feature creep concerne-t-il seulement les logiciels ?
Non. Le mécanisme apparaît partout où l’on peut ajouter sans retirer : télécommandes, tableaux de bord de voiture, appareils électroménagers, formulaires administratifs. Le logiciel le rend simplement plus visible, parce qu’on peut y ajouter presque sans limite.
