Mental Model #1 — Pourquoi les développeurs anticipent trop tôt
Une leçon d’ingénierie que j’ai apprise : construire pour aujourd’hui vaut souvent mieux que préparer un futur hypothétique.
Une grande partie de la complexité dans les systèmes logiciels ne vient pas des besoins réels.
Elle vient des besoins que nous avons anticipés “au cas où”.
Avec le temps, j’ai remarqué que beaucoup de décisions techniques commencent par une phrase familière :
“Et si jamais dans le futur…”
C’est souvent là que la complexité commence.
Une petite anticipation… qui a duré plus de deux ans
Sur un projet, nous avons développé une fonctionnalité qui reposait sur une capacité présente dans l’API de nos clients.
Lors de l’implémentation, nous nous sommes dit :
“Et si jamais un futur client n’avait pas cette fonctionnalité dans son API ?”
Par prudence, nous avons rendu le comportement paramétrable par client.
Sur le moment, cela semblait être une bonne idée.
Un peu plus flexible.
Plus générique.
Prêt pour le futur.
Deux ans plus tard, nous avons fait un constat simple.
Le paramètre était activé pour tous les clients.
Tous les clients avaient bien cette fonctionnalité dans leur API.
Et nous maintenions du code inutile depuis deux ans.
Une petite anticipation avait introduit de la complexité… pour un besoin qui n’est jamais arrivé.
Évidemment, ce besoin pourrait apparaître un jour.
Mais nous maintenons depuis plus de deux ans du code qui aurait pu être ajouté en une journée le jour où le besoin se présenterait réellement.
Si tu t’intéresses à l’ingénierie logicielle, au product thinking et aux modèles mentaux utilisés pour construire des systèmes simples, tu peux t’abonner pour recevoir les prochains articles.
Le vrai coût de l’anticipation
Anticiper les besoins paraît souvent être une bonne pratique.
En réalité, cela introduit un coût immédiat.
Chaque abstraction anticipée augmente :
le temps de développement
le temps de review
la difficulté d’onboarding
la surface de bugs potentiels
la complexité du debugging
la quantité de tests nécessaires
Et surtout :
le besoin anticipé peut ne jamais arriver.
Mais même si ce besoin arrive un jour, un autre problème apparaît.
La solution que nous avons imaginée n’est peut-être pas la bonne.
C’est souvent ce qui arrive lorsque nous pensons une solution (hypothétique) à un besoin (hypothétique) sans avoir toutes les données.
Et parce que la solution existe déjà partiellement, nous avons tendance à vouloir la réutiliser.
Pas parce qu’elle est optimale, mais parce qu’elle est déjà là.
Et souvent, nous préférons adapter une solution imparfaite plutôt que de repartir de zéro.
Cette logique apparaît partout
Cette anticipation se retrouve dans beaucoup de projets.
Les abstractions prématurées
Une autre forme d’anticipation est l’abstraction prématurée.
On écrit un composant ou une interface générique pour des cas futurs qui n’existent pas encore.
Par exemple :
une interface pour plusieurs implémentations hypothétiques
un système de stratégie pour un seul comportement
une hiérarchie de classes pour un seul cas d’usage
Le résultat est souvent un code plus difficile à lire.
Alors qu’une implémentation simple aurait suffi.
Et le jour où un second cas arrive, on se rend compte que l’abstraction a mal été pensée, et qu’il faut passer une troisième fois à la caisse.
La configuration inutile
Une autre forme fréquente d’anticipation est la configuration excessive.
On ajoute des paramètres pour rendre un comportement configurable :
variables d’environnement
flags
options en base de données
Mais si toutes les instances utilisent la même valeur, cette configuration n’apporte aucune flexibilité.
Elle ajoute simplement une couche de complexité supplémentaire.
Le modèle mental : construire pour aujourd’hui
Avec le temps, j’ai adopté un principe simple.
Coder uniquement ce qui est nécessaire pour répondre au besoin du moment.
L’objectif est de garder la codebase aussi simple que possible.
Une base simple est plus facile à :
comprendre
maintenir
faire évoluer
Et surtout, elle permet d’itérer rapidement lorsque les besoins changent.
Une règle simple que j’essaie d’appliquer
Lorsque je développe et que je me surprends à penser :
“Et si jamais dans le futur…”
je me pose une question simple.
Quel problème réel est-ce que je résous aujourd’hui ?
Si la réponse est :
“Aucun pour l’instant”
alors la meilleure décision est souvent… de ne rien ajouter.
Simplicité ne veut pas dire rigidité
Cela ne veut pas dire écrire du code rigide.
Un bon système doit rester ouvert à l’extension (le fameux “O” de SOLID).
Mais il y a une différence importante entre :
concevoir un code facile à faire évoluer
et implémenter des évolutions hypothétiques
L’objectif est d’avoir un code propre, testé, simple mais strictement limité au périmètre du besoin actuel.
Pour finir
C’est l’un des modèles mentaux qui influence le plus ma manière de développer aujourd’hui.
Avec le temps, j’ai réalisé que beaucoup de complexités techniques ne viennent pas des besoins réels.
Elles viennent des besoins que nous avons anticipés trop tôt.
Et une règle simple revient souvent :
La simplicité aujourd’hui vaut souvent mieux qu’une flexibilité hypothétique.
Si cet article t’a plu
Je partage ici ce que j’apprends au quotidien sur le métier d’ingénieur logiciel :
Modèles mentaux d’ingénierie logiciel
Réflexion produit
Si ces sujets t’intéressent, tu peux t’abonner pour recevoir les prochains articles directement par email.