Les best practices sont un excellent point de départ. Elles représentent l'expérience distillée de milliers de développeurs qui ont rencontré les mêmes problèmes que vous et trouvé des solutions qui fonctionnaient pour eux — dans leur contexte, avec leurs contraintes. C'est véritablement précieux.
Mais voici où ça dérape : les développeurs s'arrêtent à « c'est une best practice » et ne demandent jamais « est-ce la meilleure pratique pour nous ? » Ils traitent les best practices comme des règles au lieu de ce qu'elles sont réellement — des recommandations de personnes qui ne connaissent pas votre codebase, votre équipe, vos utilisateurs ni vos contraintes.
Le sophisme de l'appel à l'autorité
Quand je débats d'architecture ou d'implémentation avec des ingénieurs, j'entends régulièrement : « On devrait le faire comme ça parce que c'est une best practice. » Ce n'est pas un argument. En logique formelle, ça s'appelle un appel à l'autorité — l'idée que quelque chose est correct parce qu'une autorité l'a dit, plutôt qu'à cause du raisonnement derrière.
Les best practices ne sont rien d'autre que l'expérience d'autres développeurs qui ont exprimé ce qui avait du sens pour eux dans leur contexte. La plupart du temps, leur contexte recouvrira le vôtre. Mais pas toujours. Et quand ce n'est pas le cas, les suivre aveuglément n'est pas de l'ingénierie — c'est du cargo culting.
La solution est simple : chaque fois que quelqu'un dit « best practice », demandez « pourquoi ? » Si la réponse est « parce que la doc le dit » ou « parce que tout le monde fait comme ça », c'est un signal d'alerte. Si la réponse est une raison technique concrète qui s'applique à votre situation, parfait — maintenant vous avez un vrai argument, pas un appel à l'autorité.
Le désastre du panier Next.js
J'ai vu cela se produire chez un grand détaillant suisse. Quand j'ai rejoint l'équipe, elle construisait des applications e-commerce et avait adopté Next.js avec une approche stricte « server-first » — parce que c'est ce que la documentation Next.js recommandait. Tout rendre côté serveur. Utiliser les Server Components partout. Minimiser le JavaScript côté client.
Le problème ? Ils ont appliqué cela à tout le parcours panier et checkout. Chaque action du panier — ajouter un article, changer la quantité, appliquer un coupon — déclenchait un aller-retour serveur. Tout le checkout était rendu côté serveur.
Sur le papier, ça suivait les « best practices ». En pratique, c'était une terrible adéquation. Nous ne servions que le marché suisse. Chaque panier est unique à chaque utilisateur — il n'y a aucun bénéfice à mettre en cache l'état du panier côté serveur. L'approche server-first ajoutait de la latence à chaque interaction sans rien nous donner en retour. Aucun bénéfice SEO (Google n'indexe pas votre panier). Aucun bénéfice de cache (chaque panier est différent). Juste une UX plus lente sans raison.
C'était difficile de convaincre l'équipe au début. « Mais la doc Next.js dit que les server components sont le défaut » était un vrai argument que j'ai entendu plusieurs fois. L'appel à l'autorité était profondément ancré. Mais une fois que nous avons déplacé le panier et le checkout entièrement côté client, l'expérience utilisateur s'est améliorée dramatiquement. Les interactions sont devenues instantanées. Le code est devenu plus simple. Et nous n'avons perdu aucun avantage que le rendu serveur était censé nous donner.
Adaptez à votre contexte
La leçon n'est pas « ignorez les best practices ». La leçon est : traitez-les comme un point de départ, puis adaptez-les à votre contexte spécifique. Demandez-vous :
Quel problème cette pratique résout-elle ? Mon projet a-t-il réellement ce problème ? Quels sont les compromis dans ma situation spécifique ? La recommandation est-elle basée sur des hypothèses qui ne tiennent pas pour nous ?
Le rendu côté serveur est excellent quand vous avez besoin de SEO, quand vous servez du contenu identique pour beaucoup d'utilisateurs, quand vous voulez des chargements rapides sur des connexions lentes. C'est du overhead inutile quand vous rendez du contenu personnalisé et interactif derrière une authentification qu'aucun moteur de recherche ne verra jamais.
L'équipe Next.js n'a pas tort. Leur recommandation est solide pour la majorité des cas d'usage pour lesquels elle a été conçue. Mais ils ne savent pas que votre checkout est uniquement suisse, que votre panier est toujours unique, et que vos utilisateurs sont sur des connexions internet suisses rapides. Seul vous connaissez votre contexte. Et seul vous pouvez décider quelle pratique convient réellement.
Certaines pratiques sont presque universelles
Toutes les best practices n'ont pas besoin d'une forte contextualisation. Certaines sont si fondamentales qu'elles s'appliquent presque partout. YAGNI plutôt que DRY — n'abstraire que quand c'est nécessaire — est une que je n'ai jamais vu échouer dans aucun contexte. La séparation des smart et dumb components — garder la logique métier hors des composants UI — fonctionne que vous construisiez une app bancaire ou un site e-commerce.
La différence ? Ces pratiques sont enracinées dans des principes fondamentaux de conception logicielle — séparation des préoccupations, évitement de l'abstraction prématurée — pas dans des recommandations spécifiques à un framework. Plus une « best practice » est liée à un outil ou framework spécifique, plus il est probable qu'elle doive être adaptée à votre contexte.
Construisez votre propre playbook
Les meilleures équipes que j'ai dirigées ne suivent pas les best practices — elles ont leurs propres pratiques, informées par les best practices mais adaptées à leur réalité. Elles ont pris le temps de comprendre pourquoi une recommandation existe, testé si elle s'applique, et documenté ce qui fonctionne réellement pour elles.
C'est ce que je veux dire par « inventez les vôtres ». Pas que vous devriez ignorer la sagesse collective de l'industrie. Mais que vous devriez la traiter à travers votre propre jugement d'ingénieur au lieu de l'accepter comme un évangile. Lisez la doc. Comprenez le raisonnement. Puis décidez — avec des arguments, pas avec l'autorité — si ça convient.
Les ingénieurs qui font cela construisent de meilleurs logiciels. Pas parce qu'ils sont plus intelligents, mais parce qu'ils réfléchissent au lieu de suivre.