Je n’ai pas de chapelles. J’ai cinq fatigues.

Depuis 10 ans que je code, je n’ai pas de chapelle technique. Pas de guerre sainte sur les hooks, pas de décret anti-Redux, pas de manifeste CSS-in-JS. J’ai toujours pris ce que le contexte imposait.

Je croyais que c’était une absence d’opinion. En y regardant de plus près, j’ai cinq fatigues qui reviennent, et elles disent toutes la même chose.

Le contraire de la rigueur n’est pas la négligence. C’est le mimétisme.

Voici cinq endroits où je l’ai vu se déployer. Y compris là où je l’ai laissé passer, et parfois là où je l’ai écrit moi-même.

1. La réunion qui mime la coordination

Certaines réunions sont faites pour décider. La plupart sont faites pour que quelqu’un se sente moins seul sur sa charge mentale.

Le test est simple : je lis le ticket avant la réu, je le relis après la réu. Si les deux lectures sont identiques, la réu n’a rien produit. Elle a juste aligné des visages sur Slack.

45 minutes fois 8 personnes, c’est 6 heures de dev. Si ce coût n’achète pas au moins une décision actée, c’est du théâtre facturé sur le calendrier de tout le monde.

J’ai aussi organisé ces réus. Pas toujours pour décider. Parfois parce que je n’arrivais pas à formaliser où j’en étais par écrit. La réu, c’était l’exfiltration de ma charge mentale vers celle des autres. Ça me soulageait, moi. Ça ne produisait rien, pour personne.

2. Le théâtre de la code review

Tu connais la review où 400 lignes sont passées, et le seul commentaire bloquant porte sur handleClick vs onClick. On l’a tous vue. On l’a tous subie. On l’a peut-être tous écrite.

La rigueur théâtrale est la plus trompeuse parce qu’elle copie visuellement la rigueur réelle. Même page, même thread, même ton professionnel. Mais la cognition derrière est radicalement différente. Comprendre 400 lignes prend une heure. Commenter un naming prend 30 secondes. Le reviewer qui fait 30 secondes de travail à 90% des PR fait un job visible au coût minimal. C’est rentable pour lui. Coûteux pour l’équipe.

Le pinaillage sur le naming a un cousin : le collègue qui met son nez dans toutes les reviews, sur tous les projets, même ceux qu’il ne suit pas. Pas par malice. Par réflexe. Ce sont les deux faces du même pattern. L’un cherche à contribuer sans prendre la charge cognitive. L’autre cherche à exister dans toutes les conversations sans porter la responsabilité d’aucune. Deux postures, un même théâtre.

Je l’ai fait moi aussi. En junior, en mid, je laissais passer du code que je ne comprenais pas. Je compensais par un commentaire sur un naming. C’était la part de la review que je savais faire. Et je faisais semblant que c’était assez.

Une vraie review coûte cher. C’est ça le signal. Si une review est fluide à écrire, rapide à poser, confortable à lire, il y a de fortes chances qu’elle n’ait rien reviewé.

3. Le cargo cult du useCallback

Dans certaines codebases, le useCallback est devenu une habitude. Pas le résultat d’une mesure de perf, pas la conclusion d’un profiling. Juste une convention qui s’est installée sans qu’on sache bien à quel moment. Les nouveaux arrivants s’y conforment par mimétisme, parce que toutes les PR en contiennent. Chaque PR renforce la convention. Chaque convention renforcée devient plus invisible.

La React team le répète depuis des années : useCallback est une optimisation, pas une précaution. Les équipes font l’inverse. Le pire cas, c’est un useCallback avec un deps array mal calé : il re-génère à chaque render ET porte le coût du wrapper. Tu paies pour du code qui ne fait rien. Et parfois qui fait pire.

Oui, le React Compiler rend ce débat partiellement caduc sur les codebases qui l’ont adopté. La plupart tournent encore sans. Et surtout, le pattern culturel dépasse useCallback.

Je n’ai pas lutté dans ce genre de codebase. C’est plus rapide d’ajouter un useCallback que de désapprendre une convention d’équipe. C’est exactement comme ça que le théâtre se perpétue : personne ne l’a vraiment voulu, personne ne le défend vraiment, et tout le monde continue. Y compris moi.

La rigueur, ici, ce serait d’ouvrir react-scan ou le Profiler React DevTools avant de wrapper. Ça prend 2 minutes. Presque personne ne le fait.

4. Le flaky test qu’on skippe

Le cycle est toujours le même. Test qui flake. Retry. Re-flake. Ticket créé. Skip « temporaire ». Sprint suivant. Le ticket traîne. Skip permanent. 6 mois plus tard, le test est supprimé sans que personne ne se rappelle ce qu’il vérifiait.

Chaque skip est un bug porteur qui se déguise en bruit d’infra. Tu ne sais plus si tu skippes une race condition réelle ou un timer mal calé. La charge cognitive pour faire la différence est élevée. Alors on ne la fait pas.

La vraie fonction d’une CI n’est pas d’être verte. Sa vraie fonction est d’être un oracle fiable. Un flaky skippé retire une ligne à l’oracle. Dix flaky skippés, l’oracle devient une suggestion. Vingt, tu ne regardes plus le résultat de la CI. Tu merges sur la foi de ton diff local.

J’ai signé des PR qui skippaient sans exiger un ticket de suivi. C’est une complicité par fatigue. Et c’est exactement ce qui transforme un oracle en suggestion.

La différence n’est pas entre skipper ou ne pas skipper. La différence est entre un skip mesuré, tracé, assumé, et un skip subi. Un skip éditorialisé, ça existe. Ce n’est juste pas ce que je vois dans la plupart des CI.

5. Le process ajouté par réflexe

Dans beaucoup de boîtes, le réflexe face à un incident n’est pas « qu’est-ce qu’on a appris ? » mais « quel process on ajoute ? ». Un bug en prod, on met un process de revue plus strict. Un ticket mal rédigé, on oblige un template. Un malentendu en réunion, on rédige une charte de communication. Chaque incident devient une règle. Les règles s’empilent. Personne ne les retire jamais.

La vraie dette d’un process n’est pas l’effort de l’écrire. C’est l’impôt qu’il prélève sur toute l’équipe, tout le temps, ensuite. Une règle qui coûte 15 minutes à chaque dev sur chaque PR, à 20 devs, sur 52 semaines, c’est 260 heures par an. Si la règle ne prévient pas au moins l’équivalent en incidents évités, elle est nette négative. Dans les équipes où ce calcul est fait, ça se voit. C’est rare, et c’est la marque d’une équipe qui pense son outillage.

Le process devrait être le résultat d’une mesure, pas une réponse par réflexe. La rigueur, c’est de dire « on a eu cet incident, on regarde combien il nous aurait coûté d’éviter, combien ça coûterait de le prévenir demain, et on tranche ». Le mimétisme, c’est de dire « on a eu cet incident, on ajoute un process ». C’est plus rapide. C’est plus visible. Et c’est plus coûteux à long terme.

J’ai proposé des process moi aussi après un incident. Un template de PR, une checklist pre-release, un canal Slack dédié. Je ne les ai jamais réévalués 6 mois plus tard pour voir s’ils payaient leur coût. Personne ne le fait. Ajouter un process est facile. Le retirer demande d’admettre qu’on l’a ajouté pour rien.

Le fil

Le fil qui traverse ces cinq fatigues n’est pas technique. Il est culturel.

La rigueur coûte. Elle demande de refuser une réu parce que l’écrit suffit, demande de lire 400 lignes avant de commenter, demande de mesurer avant de wrapper un callback, demande d’investiguer un flaky plutôt que le skip, demande de retirer un process autant qu’on en ajoute.

Le mimétisme, lui, ne coûte rien. Et il ressemble à la rigueur juste assez pour tenir, parfois pendant des années.

Le test est simple, et j’essaie de me l’appliquer avant de le proposer aux autres. Sans toujours y arriver. Pour chaque pratique qu’on met en place, est-ce qu’on sait dire ce qu’elle achète, et à quel prix ? Si la réponse est floue des deux côtés, on est probablement dans le théâtre.

Et le théâtre est fatigant, même quand on le joue soi-même sans s’en rendre compte.