Il y a une métrique que personne n’affiche sur les dashboards : le nombre de décisions techniques qu’on n’a pas eu à revenir corriger six mois plus tard. On mesure la vélocité, le throughput, le cycle time. Jamais la durabilité.
Table of contents
Open Table of contents
Le culte de la vitesse
L’industrie du logiciel a érigé la rapidité en vertu cardinale. Les sprints portent bien leur nom — on court. Les pull requests doivent être mergées vite, les tickets fermés vite, les features livrées vite. « Ship it » est devenu un mantra, presque une injonction morale.
Cette pression n’est pas toujours explicite. Parfois elle vient du tooling lui-même : les métriques de lead time, les alertes Slack quand une PR dépasse 48 heures, les story points qui, malgré toutes les précautions rhétoriques, finissent toujours par être comparés d’un sprint à l’autre.
Le problème n’est pas la vitesse en soi. C’est qu’on optimise pour elle au détriment de presque tout le reste.
Ce qu’on sacrifie
Quand on va vite, on sacrifie d’abord la compréhension. On lit le code en diagonale. On copie un pattern existant sans se demander s’il est adapté. On merge une PR après un « LGTM » qui signifie rarement « j’ai lu chaque ligne et je comprends les implications ».
Ensuite, on sacrifie la cohérence. Chaque développeur, pressé, prend le chemin le plus court vers sa solution. Le résultat : un codebase qui ressemble à une ville sans plan d’urbanisme — fonctionnelle, mais labyrinthique. Chaque quartier a sa propre logique, ses propres conventions, ses propres raccourcis.
Enfin, on sacrifie le dialogue. Les discussions d’architecture prennent du temps. Les revues de code approfondies prennent du temps. Les conversations où quelqu’un dit « attends, je ne suis pas sûr de comprendre pourquoi on fait ça comme ça » prennent du temps. Et le temps, dans le paradigme de la vélocité, est l’ennemi.
La lenteur comme discipline
Ralentir n’est pas de la paresse. C’est une discipline — peut-être la plus exigeante, parce qu’elle demande de résister à la pression ambiante.
Relire son propre code avant de créer la PR. Pas un survol : une vraie relecture, comme on relirait un texte qu’on s’apprête à publier. Se demander : est-ce qu’un collègue qui ne connaît pas ce contexte comprendra ce code dans six mois ? Est-ce que les noms de variables racontent l’histoire de ce que fait le programme ?
Prendre le temps de la revue. Lire la PR entièrement. Comprendre le « pourquoi » avant de commenter le « comment ». Poser des questions plutôt que de faire des suggestions automatiques. Une bonne revue de code est un acte de collaboration, pas de validation.
Documenter les décisions, pas seulement le code. Un ADR (Architecture Decision Record) de dix lignes, rédigé au moment où la décision est prise, vaut plus que mille commentaires dans le code. Il capture le contexte, les alternatives envisagées, les raisons du choix. C’est un cadeau pour votre futur vous — et pour tous ceux qui hériteront de votre codebase.
Le paradoxe de la productivité
Il y a un paradoxe que les équipes qui pratiquent la lenteur découvrent assez vite : elles vont souvent plus vite que les autres. Pas sur le court terme — sur les premières semaines, elles semblent plus lentes. Mais sur l’horizon de six mois, d’un an, la différence est flagrante.
Moins de bugs en production. Moins de temps passé à comprendre du code obscur. Moins de refactoring d’urgence. Moins de « on va réécrire ce module parce que plus personne ne comprend comment il marche ». Le temps investi dans la compréhension et la rigueur se rembourse, avec intérêts.
C’est l’équivalent logiciel de la fable du lièvre et de la tortue, sauf que dans notre industrie, presque tout le monde parie encore sur le lièvre.
Pratiquer
Quelques habitudes concrètes, rien de révolutionnaire :
Avant de coder, écrire en prose ce qu’on va faire et pourquoi. Deux paragraphes suffisent. Si on n’arrive pas à l’expliquer clairement, c’est qu’on ne comprend pas encore assez le problème.
Pendant la revue, lire le diff une deuxième fois après avoir compris l’intention. La première lecture sert à comprendre ; la deuxième à évaluer.
Après le merge, prendre cinq minutes pour se demander : est-ce qu’on est satisfait de ce code ? Pas fier — satisfait. Est-ce qu’on le relirait dans un an sans grimacer ?
Au niveau de l’équipe, protéger le temps de réflexion. Bloquer des créneaux sans réunion. Autoriser explicitement les « je vais prendre une journée pour comprendre ce système avant de toucher quoi que ce soit ». Valoriser les revues approfondies autant que les features livrées.
Conclusion
La lenteur technique n’est pas un luxe réservé aux équipes qui « ont le temps ». C’est un investissement, et comme tout bon investissement, il demande de la discipline et une tolérance à l’inconfort du court terme.
Le code qu’on écrit lentement, on le maintient vite. Le code qu’on écrit vite, on le maintient lentement — quand on ne finit pas par le réécrire entièrement.
Il y a une forme d’élégance dans le refus de la précipitation. Dans le choix délibéré de faire moins, mais mieux. Dans l’acceptation que la meilleure ligne de code est parfois celle qu’on n’écrit pas, parce qu’on a pris le temps de comprendre qu’elle n’était pas nécessaire.