FEATURE BLOAT · Produit et méthode
Plus de fonctionnalités = plus de désordre
Personne ne s'assoit un matin pour décider de construire un système compliqué. Compliqué, c'est ce qui arrive après avoir dit oui trente fois de suite à des demandes qui, prises une à une, semblaient petites et raisonnables. Et quand quelqu'un ouvre le système le matin sans savoir par où commencer, la dernière fonction ajoutée n'est pas la coupable. C'est la somme qui l'est.
« Juste un petit bouton de plus »
Presque tous les systèmes surchargés le sont devenus de bonne foi. Quelqu'un a demandé un rapport supplémentaire, quelqu'un d'autre un champ de plus dans le formulaire, et à la réunion suivante est née l'idée d'un écran qui réunirait les deux. Aucune de ces demandes n'est absurde, et derrière chacune il y a une personne réelle avec un besoin réel.
Le problème, c'est que chaque demande est jugée isolément, et que personne ne juge la somme. La question posée est : « combien de temps pour le construire ? » — et quand la réponse est « deux jours », la demande est acceptée. La question que personne ne pose est : « qu'est-ce que cela fait au système déjà en place ? », et c'est celle-là qui coûte cher.
Car une fonctionnalité n'est pas un article que l'on pose sur une étagère à côté des autres. Elle entre dans quelque chose qui existe déjà, y déplace des éléments et s'y raccorde. Ajoutez-la à un système déjà chargé, et ce qui casse n'est pas la nouvelle fonction — c'est la capacité à retrouver les anciennes.
Les quatre prix d'une seule fonctionnalité
La place à l'écran. Un écran est une ressource finie. Chaque nouveau bouton diminue le rapport entre « ce que je fais tous les jours » et « ce qu'on peut faire ici ». À un moment, l'action quotidienne ne saute plus aux yeux, et celui qui ouvre l'écran doit la chercher. Il ne dira pas que le système est chargé ; il dira qu'il est compliqué.
La décision. Toute option affichée a un coût, y compris pour ceux qui ne la choisissent jamais. Plus la liste d'options est longue, plus la décision prend du temps — un principe connu en conception d'interfaces sous le nom de loi de Hick. Trois secondes d'hésitation sur un geste répété quarante fois par jour, ce n'est pas rien ; et surtout, cela finit par donner le sentiment que le système pèse.
Les bugs. Les fonctionnalités ne s'additionnent pas — elles se multiplient. Deux interrupteurs indépendants créent quatre états possibles ; dix en créent plus de mille. Aucune équipe ne teste mille états après chaque modification : plus il y a de capacités, plus le risque augmente qu'un changement dans un coin casse quelque chose dans un autre. C'est pourquoi, dans les systèmes anciens, « chaque correctif en entraîne un autre ».
La maintenance. Un code écrit une fois se maintient toujours. Il doit continuer à fonctionner après une mise à jour du système d'exploitation, après un changement chez un service externe, après un changement de prestataire de paiement. L'écran construit « au cas où » et jamais ouvert est toujours testé, toujours mis à jour et toujours payé — un sujet que nous avons détaillé dans l'article sur le coût d'exploitation d'un site ou d'une application.
Le désordre n'est pas dans le code — il est chez l'utilisateur
Le vrai prix d'un système surchargé n'est pas technique. Il s'entend ainsi : « je ne suis pas doué avec les ordinateurs ». C'est presque toujours faux. Celui qui le dit se sert d'un téléphone, prend rendez-vous en ligne et vire de l'argent depuis une application : il est simplement tombé sur une interface qui lui demande de se souvenir au lieu de lui montrer.
Et cela retombe précisément sur ceux à qui le système est le plus utile. Le salarié ancien qui connaît la maison par cœur, la personne qui tient l'agenda, l'artisan qui veut finir sa journée et non apprendre un logiciel : ce sont les premiers à décrocher à mesure que l'on ajoute. Ils ne se plaignent pas ; ils contournent. Apparaissent alors un tableur parallèle, un groupe WhatsApp, un post-it sur l'écran. Et dès qu'un contournement existe, le système ne détient plus la vérité — exactement le problème qu'il devait résoudre, comme nous l'avons décrit dans l'article sur le moment de remplacer Excel par un système.
La surcharge se mesure aussi là où on l'attend moins. Sur les sites et les applications web, chaque capacité supplémentaire se traduit par du code que le navigateur doit télécharger et traiter ; les données du Web Almanac montrent que le poids moyen d'une page continue de croître d'année en année. L'utilisateur vit cela comme de la lenteur, pas comme un excès de fonctions.
| Ce que l'on demande | Comment cela sonne en réunion | Ce que cela coûte vraiment |
|---|---|---|
| Un champ de plus dans le formulaire | « C'est un champ, une minute de travail » | Une question de plus pour chaque utilisateur, chaque jour ; un formulaire plus long, donc moins souvent terminé |
| Un rapport de plus | « Autant l'avoir, au cas où » | Un menu de rapports où il faut chercher ; un rapport que personne n'ouvre et que tout le monde maintient |
| Un réglage que l'on peut désactiver | « Que chacun choisisse ce qui lui convient » | Deux modes différents à supporter, à tester et à expliquer au téléphone |
| Un écran « d'administration » de plus | « Par sécurité, tout le monde n'y entrera pas » | Des droits, des tests et de la maintenance pour quelque chose que l'on ouvre deux fois par an |
| Une connexion à un autre système | « Ils ont une API, c'est rapide » | Une dépendance à un tiers qui se met à jour sans prévenir ; un nouveau point de rupture |
Comment décider de ce qui n'entrera pas
Écouter le problème, pas la solution. Une demande de fonctionnalité est presque toujours une frustration que quelqu'un a déjà traduite en remède dans sa tête. Il vaut la peine de revenir en arrière : quand en avez-vous eu besoin la dernière fois, et que faites-vous aujourd'hui à la place. Souvent, la frustration se règle par une petite modification d'un écran qui existe déjà.
Demander combien de fois par mois. Une action quotidienne mérite une place centrale. Une action mensuelle mérite une place que l'on cherche. Une action annuelle ne mérite pas de logiciel du tout — mieux vaut la faire à la main une fois par an que d'entretenir un écran pour elle à jamais.
Décider de ce qui sort. La règle la plus utile : toute fonction qui entre sur un écran doit désigner ce qui en sort. Cela oblige à hiérarchiser, et cela révèle très vite que certaines demandes ne sont tout simplement pas assez importantes face à ce qui est déjà là.
Mesurer avant d'élargir. Si le système est déjà en service, on peut savoir au lieu de deviner : ce qui s'ouvre, ce qui ne s'ouvre pas, et où les gens se bloquent. Une extension fondée sur la mesure est presque toujours plus petite qu'une extension fondée sur une réunion.
Et un système déjà surchargé ?
On ne reconstruit pas. C'est le réflexe le plus répandu et le plus cher, et il produit presque toujours un nouveau système qui se surchargera exactement de la même façon — parce que le problème n'a jamais été la technologie, mais les décisions.
On commence par mesurer : ce qui sert vraiment, et à quelle fréquence. Ensuite on masque au lieu de supprimer — on retire de l'écran principal ce à quoi on ne touche presque jamais, en le laissant accessible par un menu secondaire. On attend un mois. Ce que personne n'est allé chercher peut être retiré sans risque ; ce que quelqu'un a cherché retrouve sa place.
Le résultat surprend le plus souvent : le même système, les mêmes capacités, et soudain les gens s'en sortent sans formation. Rien n'a été ajouté — le système a simplement cessé de se cacher lui-même.
Comment nous travaillons là-dessus. Chez appotto, nous construisons pour des gens qui n'aiment pas la technologie : dire « non » fait donc partie du service. Au cadrage, nous demandons combien de fois par mois chaque demande sert vraiment, et ce qui sort de l'écran si elle y entre. L'application de suivi que nous avons construite pour un père de soixante-dix ans, qui l'ouvre tous les jours depuis deux ans, tient précisément parce que nous avons refusé d'y ajouter la moitié de ce que nous avions imaginé. Le même principe est derrière tout ce que nous avons construit : un écran compris immédiatement, et un devis fixé d'avance, sans surprise.
Vous avez un système que vos équipes contournent, ou un cadrage qui commence à enfler ? Écrivez-nous en quelques lignes ce que les gens font réellement chaque jour — et nous vous dirons honnêtement ce qui est superflu.
Questions fréquentes
Pourquoi plus de fonctionnalités nuisent-elles au système ?
Parce que chaque capacité ajoutée se paie à quatre endroits à la fois : elle occupe de la place à l'écran et repousse ce que les gens font vraiment chaque jour, elle ajoute une décision de plus à prendre, elle multiplie le nombre d'états à tester après chaque modification, et elle reste en maintenance tant que le système est en vie. Ces coûts s'empilent les uns sur les autres : un système à cinquante capacités n'est donc pas cinq fois plus utile qu'un système à dix.
Comment savoir qu'un système est devenu trop lourd ?
Le premier signe, c'est que les gens se demandent entre eux où cliquer, au lieu de simplement cliquer. Le deuxième, c'est que le système exige des formations répétées : un nouveau salarié ne s'en sort pas seul, et celui qui revient de deux semaines d'absence est perdu. Le troisième, c'est l'apparition de contournements — un tableur parallèle, un groupe WhatsApp, un post-it sur l'écran — parce que passer par le système demande trop d'étapes. Le quatrième, c'est que chaque petit changement en casse un autre.
Que faire quand les équipes réclament sans cesse de nouvelles fonctions ?
Écouter le problème, pas la solution qu'elles proposent. Une demande de fonctionnalité décrit presque toujours une frustration, et pas nécessairement le bon remède. Demandez quand cela s'est produit la dernière fois, combien de fois par mois cela arrive, et ce que l'on fait aujourd'hui à la place. Souvent, la demande se règle par une petite modification d'un écran existant ; parfois, elle se révèle nécessaire deux fois par an — et il vaut alors mieux traiter le cas à la main que maintenir un écran entier pour lui.
La simplicité, n'est-ce pas simplement un système pauvre ?
Non. Un système pauvre ne fait pas ce qu'il faut ; un système simple fait exactement ce qu'il faut et n'affiche pas le reste. Retirer des lignes d'une liste est facile ; décider de ce qui reste et de la façon dont cela tient sur un seul écran, c'est le vrai travail d'ingénierie. Les systèmes qui paraissent simples de l'extérieur sont en général ceux qui ont demandé le plus de réflexion.
Peut-on retirer des fonctionnalités d'un système déjà en place ?
Oui, et sur un système ancien c'est souvent l'investissement le plus rentable. Mesurez d'abord ce qui sert réellement, masquez ce que presque personne ne touche plutôt que de le supprimer tout de suite, et attendez un mois pour voir si quelqu'un se plaint. Ce que personne n'est allé chercher peut être retiré sans risque. Le système reste le même, mais il redevient utilisable sans formation.
Sources
- Nielsen Norman Group — la loi de Hick — l'explication professionnelle de l'allongement du temps de décision à mesure que le nombre d'options présentées augmente, et ce que cela implique pour la conception d'interfaces.
- HTTP Archive — Web Almanac, chapitre sur le poids des pages — des données annuelles sur la quantité de code que les sites et les applications web chargent réellement, et sur la tendance au fil des ans.
Un système que personne n'a envie d'ouvrir ?
Dites-nous ce que les gens font réellement chaque jour. Nous vous dirons ce qui est superflu, ce qui manque et ce que l'on peut masquer — avec un devis fixé d'avance. Premier échange gratuit.
Écrivez-nous