Ces (fausses) bonnes idées qui minent nos projets : l'art de dire 'non' au syndrome de l'objet brillant

Ah, le développement web. Un monde en perpétuel mouvement, où chaque semaine apporte son lot de frameworks révolutionnaires, de bibliothèques magiques et de pratiques qui promettent de nous transformer en ninjas du code. Et nous, développeurs passionnés, on est souvent les premiers à tomber dans le panneau, n'est-ce pas ? On voit une nouvelle techno, on lit un article élogieux, et BOUM ! L'idée germe : « Et si on refaisait ce module avec X ? Ce serait tellement plus performant/moderne/scalable ! » On appelle ça le syndrome de l'objet brillant, et croyez-moi, j'en ai des cicatrices.

Je me souviens d'un projet, il y a quelques années, où l'on devait refondre une partie d'un CMS maison. L'équipe était super motivée, on avait identifié les points faibles, les axes d'amélioration. Puis, un matin, un collègue arrive, les yeux brillants : « J'ai découvert Svelte ! C'est incroyable, pas de Virtual DOM, des bundles minuscules, on devrait l'utiliser pour la nouvelle interface d'admin ! » L'idée était séduisante, sur le papier. Mais le projet était déjà bien avancé avec React, l'équipe connaissait bien, on avait des composants existants, une CI/CD rodée. Bref, une base solide. Mais la promesse de la performance ultime, la « coolitude » du nouveau framework, ça nous a un peu aveuglés.

Le chant des sirènes de la nouveauté : quand la curiosité nous coûte cher

On a fait quelques POCs, on a passé des heures à essayer de justifier ce choix. Et le résultat ? Un retard considérable, une courbe d'apprentissage abrupte pour certains, et finalement, un retour à la raison : on a continué avec React. Le coût de la transition aurait été bien trop élevé pour les bénéfices réels que Svelte aurait apportés dans ce contexte précis. Est-ce que Svelte est un mauvais framework ? Absolument pas ! C'est un excellent outil, mais pas pour ce projet, à ce moment-là.

Ce n'est pas la seule fois que ça m'est arrivé. Combien de fois ai-je vu des équipes se lancer dans une refonte complète d'une API REST existante pour passer au GraphQL, alors que le besoin n'était pas là ? Ou migrer une base de données parfaitement fonctionnelle vers un NoSQL parce que « c'est plus moderne », sans véritable justification technique ? Le problème, ce n'est pas la technologie en elle-même, c'est notre incapacité collective à évaluer froidement les gains par rapport aux coûts et aux risques.

« La meilleure technologie est celle qui résout votre problème, pas celle qui fait le plus de bruit sur Twitter. »

L'art subtil de dire 'non' (et de ne pas se faire lyncher)

Alors, comment on fait pour résister à ces sirènes ? Comment on dit « non » à une idée qui, sur le papier, semble géniale, mais qui risque de torpiller le projet ? Ce n'est pas facile, surtout quand l'enthousiasme est palpable. Mais j'ai appris quelques trucs au fil des années.

D'abord, la question fondamentale : « Quel problème est-ce que cette nouvelle approche résout réellement pour notre projet actuel ? » Si la réponse est vague, du genre « ça va être plus scalable à l'avenir » ou « c'est plus propre », c'est un signal d'alarme. Un vrai problème, c'est « notre base de données actuelle ne gère pas X millions de requêtes par jour et ça nous coûte Y en performance » ou « notre système de déploiement est tellement complexe qu'il nous faut Z heures pour une mise en production ».

Ensuite, l'évaluation des coûts cachés. On pense souvent au temps de développement initial, mais il y a aussi :

La courbe d'apprentissage de l'équipe.
L'intégration avec l'écosystème existant.
La maintenance à long terme (y a-t-il une communauté active ? Des mises à jour régulières ?).
Le recrutement (sera-t-il facile de trouver des développeurs connaissant cette techno ?).
Le risque de nouveaux bugs ou de régressions.

J'ai testé les frameworks CSS-in-JS il y a quelques années, avec l'idée d'avoir un contrôle total sur le styling, de ne plus avoir de classes CSS globales qui se marchent dessus. Super idée, n'est-ce pas ? Sauf que mon équipe n'était pas du tout à l'aise avec la syntaxe, le débuggage devenait un enfer avec des noms de classes générés aléatoirement, et la performance du runtime n'était pas toujours au rendez-vous. J'ai dû admettre mon erreur et revenir à une approche plus classique avec SASS et des conventions BEM. Le coût de cette expérimentation a été un temps précieux perdu et une frustration palpable dans l'équipe.

Le courage de la simplicité et la force de l'existant

Mon point de vue, c'est que la vraie maturité en développement ne vient pas de la maîtrise de toutes les dernières technologies, mais de la capacité à choisir la bonne technologie pour le bon problème, et surtout, à savoir quand ne pas changer. Parfois, la solution la plus simple, la moins glamour, celle qui est déjà en place et que tout le monde maîtrise, est la meilleure. Elle ne fera pas la une des blogs tech, mais elle livrera de la valeur, et c'est ça qui compte à la fin.

Le développeur expérimenté sait que chaque ajout, chaque changement, même le plus insignifiant en apparence, a un coût. Et il sait que la dette technique n'est pas seulement due à du code mal écrit, mais aussi à des choix technologiques mal avisés, motivés par l'envie de « faire bien » plutôt que de « faire juste ».

Alors, la prochaine fois qu'une nouvelle technologie vous fait de l'œil, prenez un instant. Respirez. Et posez-vous ces questions. Est-ce vraiment ce dont nous avons besoin ? Ou est-ce juste un autre objet brillant qui risque de nous égarer ? Notre métier est aussi un art de la sobriété technique, une capacité à résister à la tentation du superflu. Et si, finalement, la vraie performance et la vraie robustesse venaient de cette discipline ?

Divers