C’est le scénario catastrophe du développeur consciencieux. Vous avez identifié une faille logique, un "comportement non voulu" qui traîne dans le code depuis six mois. Vous lancez un fix propre, fier de votre rigueur... et le lendemain, le support explose.
« Pourquoi avoir supprimé cette fonction ? » « C'était plus pratique avant ! » « Vous avez cassé ma façon de travailler. »
Bienvenue dans la réalité de la Loi de Hyrum.
La Loi de Hyrum : l'interface invisible
Hyrum Wright, un ingénieur chez Google, a formulé une observation devenue célèbre :
"Avec un nombre suffisant d'utilisateurs, peu importe ce que vous promettez dans votre documentation : tous les comportements observables de votre système seront utilisés par quelqu'un."
Cela signifie que vos bugs ne sont pas seulement des erreurs. Ce sont des interfaces implicites. Si votre application est un peu lente à un endroit précis, un utilisateur a peut-être appris à utiliser ce délai pour vérifier une autre information. Si un champ accepte par erreur des caractères spéciaux, quelqu'un s'en sert peut-être pour trier ses dossiers.
Le bug comme "Workaround" (contournement)
L’humain est une machine à s'adapter. Si votre logiciel a un comportement étrange mais prévisible, l’utilisateur va construire un contournement. Avec le temps, ce contournement devient son chemin par défaut.
Dans l'histoire de l'informatique, des bugs célèbres sont devenus des piliers :
- Space Invaders : Le fait que les ennemis accélèrent quand ils sont moins nombreux était un bug (le processeur gérait mieux la charge). C'est devenu le cœur du gameplay.
- Unix : Le fait que les fichiers commençant par un point soient "cachés" était à l'origine un raccourci de programmation paresseux dans le code de
ls. C'est aujourd'hui un standard mondial.
Pourquoi la correction brutale est une erreur de produit
Pour vous, c'est un "fix". Pour l'utilisateur, c'est une menace sur sa compétence. Il a mis du temps à maîtriser vos défauts. En les supprimant sans prévenir, vous le rendez "débutant" sur son propre outil.
Stratégie : la migration, pas la destruction
Si vous devez corriger un bug auquel les gens tiennent, ne soyez pas un soldat du code parfait. Soyez un stratège.
- L'audit d'usage : Avant de supprimer, mesurez. Si 40% de vos utilisateurs utilisent ce "bug", ce n'est plus un bug, c'est une demande de fonctionnalité non formulée.
- Le "Feature Parity" : On ne retire jamais une béquille à quelqu'un sans lui avoir donné de nouvelles chaussures. Si les utilisateurs utilisaient un bug pour filtrer, créez un vrai bouton de filtre performant avant de supprimer le bug.
- La dépréciation douce : Annoncez le changement. "Nous avons remarqué que vous utilisez [X]. C'est ingénieux ! Nous allons l'intégrer proprement dans la version 2.0 pour que ce soit plus stable."
Conclusion : La maturité, c'est l'empathie technique
Un bon développeur sait écrire du code propre. Un excellent développeur sait quand laisser traîner un code "sale" pour préserver l'humain, le temps de préparer la suite.
Ne réparez pas pour le plaisir de la perfection. Réparez pour améliorer la vie de ceux qui utilisent votre code.