Selon une étude du Standish Group, 64 % de toutes les fonctionnalités logicielles sont rarement ou jamais utilisées. Ce n'est pas une anecdote ; c'est un schéma structurel. La plupart des solutions n'ont pas été conçues pour créer de la valeur, mais pour ne manquer aucune exigence. Résultat : des systèmes gonflés qui peuvent beaucoup faire et qui bougent peu.
Comment nous trouvons les deux ou trois leviers qui comptent vraiment, pourquoi « épuré » est finalement plus rapide et moins cher, et ce qu'une solution ciblée déplace concrètement : c'est l'objet de cette partie.
Le réflexe fonctionnalités — et pourquoi il coûte cher
Quand un processus accroche, le premier réflexe est de vouloir couvrir le maximum : chaque exception, chaque cas particulier, chaque « on en aura peut-être aussi besoin ». Le résultat est un système qui peut tout faire et ne fait rien correctement. Et la complexité n'est pas gratuite : chaque fonctionnalité supplémentaire est un point de défaillance de plus, un sujet de formation de plus, quelque chose qui freine les utilisateurs dans leur travail quotidien plutôt que de les soutenir. Ce qui est rarement utilisé est aussi rarement maîtrisé.
Les chiffres sur ce réflexe sont peu encourageants. Dans une analyse souvent citée du Standish Group, environ 64 % des fonctionnalités d'une application d'entreprise typique sont utilisées « rarement » ou « jamais » ; seuls environ 20 % sont utilisés fréquemment ou toujours. La plus grande partie de ce qui est construit ne génère donc jamais de valeur.
Mais ce lest n'est pas gratuit pour autant. Chaque fonctionnalité que vous construisez doit aussi être maintenue, testée et portée : une fois à la construction, durablement dans la maintenance. Construire épuré ne signifie donc pas faire des économies. Cela signifie se concentrer sur ce qui est efficace et laisser délibérément le reste de côté.