Récemment, j'ai arrêté un développement en plein milieu. Pas parce qu'il était bogué : il marchait très bien. Je l'ai arrêté parce que j'ai réalisé que sa seule raison d'exister, c'était une phrase que je m'étais dite à moi-même : « ça pourrait être vachement utile, cette fonctionnalité. » Et cette phrase, chez moi, est presque toujours le début des ennuis.
J'aime coder. Plus exactement, j'aime résoudre des problèmes avec du code, c'est ce qui me fait palpiter. Au quotidien, c'est un avantage. C'est aussi un poison : si mon plaisir est de résoudre des problèmes, alors quelque part, j'aime les problèmes. Et comme beaucoup de devs, il m'arrive de jouer au pompier pyromane, en créant moi-même ceux que je résoudrai ensuite. Pas des bugs, ça n'aurait pas de sens. Des fonctionnalités.
Après tout, qui pourrait me reprocher d'ajouter des fonctionnalités ? C'est toujours bien, une fonctionnalité de plus, non ? Eh bien non. La plupart du temps, non.
Ce que coûte une feature que personne n'a demandée
Une fonctionnalité, ce n'est jamais juste du code. C'est de la conception, du code, des tests, de la doc, souvent de la refacto pour l'intégrer, et un risque de régression sur tout ce qui marchait avant. Ça prend du temps, ça prend de l'énergie, et ça peut foutre le bazar dans un projet sain. Tout ça pour une idée dont la seule justification est qu'elle serait « excitante à développer ».
La vraie question, à chaque fois, c'est : est-ce que le jeu en vaut la chandelle ? Ou plus honnêtement : est-ce que cette fonctionnalité a un intérêt réel, autre que nourrir mon envie de coder ? Dès que la réponse traîne, il y a une embrouille en approche. Pour me tenir, je m'appuie sur deux garde-fous un peu radicaux.
YAGNI
You ain't gonna need it. Pourquoi ajouter ce dont tu n'auras pas besoin ? L'idée est de se limiter aux fonctionnalités vraiment nécessaires. C'est radical, mais c'est une cure de désintox, parce qu'il est bien question de toxicité : le développement pour l'auto-satisfaction consomme du temps, introduit des régressions, alourdit la dette. Il apporte plus de galères qu'autre chose.
Le test tient en une question : mon projet peut-il vivre sans cette feature ? S'il le peut, elle n'est pas nécessaire. Elle attend, ou elle dégage.
La philosophie UNIX
Fais une seule chose, et fais-la bien. Un programme doit rester dans son domaine et ne pas déborder. ls liste le contenu d'un répertoire, point, même s'il a mille options. ssh ouvre une connexion, rien d'autre. Tu veux copier un fichier à travers SSH ? scp est là pour ça, ce n'est pas le boulot de ssh. La force de ces outils, c'est précisément ce qu'ils refusent de faire.
Attendre le besoin, est-ce arrêter d'anticiper ?
C'est le piège inverse, et c'est là que la tentation de recréer des features non sollicitées revient. Sauf qu'ici, pas d'acronyme, pas de règle. Juste se faire confiance : à son expérience, à sa connaissance du produit. YAGNI et les autres ne sont pas des dogmes à appliquer aveuglément, ce sont des outils pour apprendre à se maîtriser soi-même.
Ce que l'IA change
Et elle change beaucoup, ici. Avant, l'envie de coder une feature inutile se heurtait au moins à son coût : des jours de boulot, ça refroidit. L'IA vient de faire sauter ce garde-fou. Elle te génère la fonctionnalité tentante en quelques minutes, presque gratuitement. Le frein naturel a disparu. Ce qui veut dire que la seule chose qui protège encore ton projet de l'accumulation, c'est ta décision de ne pas la construire. Savoir dire non à une feature n'a jamais autant compté que depuis qu'il est devenu si facile de dire oui.
Le meilleur commit est parfois celui qu'on ne fait pas
Le meilleur code que j'aie écrit récemment, c'est celui que je n'ai pas écrit. La prochaine fois qu'une idée te fait de l'œil juste parce qu'elle serait sympa à développer, pose-toi la seule question qui compte : le projet en a-t-il vraiment besoin ? Si tu hésites, tu as ta réponse. Foutre la feature à la poubelle, c'est parfois le meilleur commit de la journée.