Complexité inutile : le prix du « au cas où »

La complexité inutile ne naît presque jamais d’une mauvaise intention. Elle naît d’une bonne : « au cas où on aurait besoin de plusieurs bases de données », « au cas où il faudrait brancher un autre prestataire », « au cas où l’équipe grossit ». Chaque « au cas où » ajoute une couche. Et chaque couche se paie — pas le jour où on l’écrit, mais tous les jours d’après.

Le coût est quotidien, le bénéfice est hypothétique

Une abstraction « au cas où » se lit à chaque debug, se contourne à chaque évolution, s’explique à chaque arrivée dans l’équipe. Le scénario qu’elle prépare, lui, n’arrive souvent jamais — ou arrive sous une forme que l’abstraction n’avait pas prévue, et il faut la défaire quand même.

Trois questions pour trier

Devant une couche existante ou une couche qu’on s’apprête à écrire : est-ce qu’un cas réel l’utilise aujourd’hui ? Si on la retirait, qu’est-ce qui casserait concrètement ? Est-ce que la personne qui lira ce code dans un an comprendra pourquoi elle existe sans qu’on lui explique ? Trois « non » = une couche à retirer.

La sobriété n’est pas la naïveté

Il ne s’agit pas d’écrire du code simpliste qui ignore les vrais besoins. Il s’agit d’attendre que le besoin existe pour le payer. Un système sobre peut accueillir de la complexité — quand elle est justifiée par un cas réel, elle s’intègre proprement. C’est la complexité spéculative qui pourrit : elle structure le code autour de scénarios imaginaires.