Ship Fast par les outils, pas par les raccourcis

« On livre vite. » Cette phrase décrit deux pratiques opposées, et c'est ce qui la rend dangereuse.

Dans le premier cas, une équipe a construit son outillage. Elle génère ce qui est générable, elle vérifie automatiquement ce qui est vérifiable, et il lui reste du temps pour le travail qui demande vraiment un cerveau. Elle va vite parce qu'elle a payé d'avance.

Dans le second, une équipe saute des étapes. Elle va vite aujourd'hui et elle empruntera demain — sans jamais avoir signé le contrat de prêt, ni lu le taux.

Les deux se ressemblent pendant environ trois mois. Ensuite, elles divergent définitivement.

Le test qui sépare l'outil du raccourci

La distinction n'a pas besoin d'être compliquée. Une seule question suffit :

Est-ce que ce geste sera moins cher la prochaine fois, ou plus cher ?

Un outil rend le geste suivant moins cher. Un générateur de tests, un script de déploiement, un modèle de projet, un contrôle automatique en amont du commit : chacun coûte quelque chose une fois, puis rembourse à chaque usage.

Un raccourci rend le geste suivant plus cher. Une validation désactivée « en attendant », une valeur écrite en dur pour aller plus vite, une couche sautée parce qu'elle « ne sert à rien ici ». Ça marche. Ça marche même très bien — jusqu'au jour où quelqu'un doit modifier ce code sans savoir ce qui a été sauté.

C'est ce qui rend le raccourci si difficile à combattre : il tient toutes ses promesses à court terme. Il livre. Il ferme le ticket. Il fait plaisir. La facture arrive dans un autre sprint, souvent sur le bureau de quelqu'un d'autre.

Ce que « dette technique » voulait vraiment dire

L'expression vient de Ward Cunningham, et sa métaphore d'origine est plus précise que l'usage courant.

Une dette n'est pas une erreur. C'est un emprunt délibéré : on livre avec une compréhension imparfaite du problème, on encaisse la valeur maintenant, et on rembourse en refactorant quand on aura appris. Cunningham insistait sur ce point : la dette n'est saine que si on la rembourse.

Ce qu'on appelle « dette technique » aujourd'hui, la plupart du temps, ce n'est pas ça. C'est du code qu'on n'a pas compris en l'écrivant et que personne n'a l'intention de reprendre. Ce n'est pas un emprunt, c'est un découvert non déclaré.

La différence pratique est simple : une dette assumée a une date de remboursement écrite quelque part. Si elle n'en a pas, ce n'est pas de la dette, c'est un défaut qu'on a décidé de ne pas voir.

Les abstractions qui fuient

Joel Spolsky a formulé la loi la plus utile du métier : toute abstraction non triviale finit par fuir. Elle vous cache la complexité — jusqu'au jour où elle vous la rend d'un coup, au pire moment, et sans mode d'emploi.

Le scénario est toujours le même. Un outil résout 90 % du besoin en dix minutes. On l'adopte. Six mois plus tard, les 10 % restants deviennent le cœur du produit — et l'outil ne les fait pas. Il ne les fera jamais. Et comme on ne l'a jamais compris, on ne peut ni l'étendre ni le remplacer.

L'authentification est l'exemple canonique. Elle est triviale à brancher et redoutable à sortir : elle touche les sessions, les permissions, la facturation, les données personnelles, la conformité. Ce qui a pris dix minutes à installer prend deux mois à démonter.

Deux questions avant d'adopter quoi que ce soit :

Est-ce que je comprends ce que cet outil fait pour moi ?
Est-ce que je pourrais le remplacer si nécessaire ?

Deux fois « non » ? Ce n'est pas un outil, c'est une dépendance dont vous ignorez le prix de sortie. Ce n'est pas une raison de refuser — c'est une raison de le savoir avant, pas pendant l'incident.

Le code généré par IA n'a pas changé l'équation

Un assistant écrit maintenant en quelques secondes ce qui prenait une heure. Ça déplace beaucoup de choses. Ça n'en déplace pas une seule : quelqu'un reste responsable de ce qui part en production.

Le code généré est un accélérateur redoutable pour ce que vous savez relire. Il devient une machine à produire de la dette au kilomètre pour ce que vous ne savez pas relire — parce qu'il est plausible, bien formé, et faux d'une manière qu'un humain pressé ne voit pas.

La règle qui tient : ne pas fusionner ce qu'on ne saurait pas déboguer à trois heures du matin. Elle n'a rien d'anti-IA. Elle était déjà vraie pour le copier-coller depuis un forum. La génération n'a fait qu'augmenter le débit — donc l'enjeu de la relecture.

Les tests ne sont pas un coût, c'est un système d'alerte

L'argument « on n'a pas le temps d'écrire des tests » suppose que les tests servent à prouver que le code marche. Ce n'est pas leur fonction principale.

Leur fonction, c'est de vous prévenir quand il cesse de marcher — six mois plus tard, dans un module que vous ne regardiez pas, à cause d'un changement sans rapport apparent. Sans eux, personne ne vous prévient. Vos utilisateurs le font, plus tard, et moins gentiment.

Un point qu'on oublie souvent : un test qui ne peut pas échouer ne teste rien. Un taux de couverture élevé mesure les lignes exécutées, pas les défauts attrapés. La bonne question n'est pas « quel pourcentage est couvert ? » mais « si je casse volontairement cette fonction, est-ce que quelque chose rougit ? ». Si la réponse est non, ce test vous endort au lieu de vous garder — et un vérificateur qui endort est pire qu'un vérificateur absent.

La règle du scout, appliquée à l'outillage

« Laisser le campement plus propre qu'on ne l'a trouvé. » Appliquée au code, cette règle a une version plus exigeante et plus rentable :

La deuxième fois qu'un geste manuel se répète, il devient un outil.

Pas la première — la première fois, on ne sait pas encore si le besoin est réel. Pas la cinquième — à ce stade, la douleur est devenue normale et plus personne ne la voit. La deuxième. C'est le moment où l'on sait que ça reviendra, et où le coût de l'automatiser est encore petit.

C'est là que se joue la différence entre les deux équipes du début. Ce n'est pas une question de talent, ni de discipline morale. C'est un choix d'investissement, répété des centaines de fois, sur une décision qui prend chaque fois trente secondes.

Ce que ça donne, concrètement

Chez OmniRealm, cette doctrine n'est pas une affiche au mur — elle est câblée.

Les tests ne s'écrivent pas à la main quand une machine peut en générer la structure. Les vérifications ne dépendent pas de la vigilance de qui commite : elles s'exécutent toutes seules, avant que le code ne parte. Les décisions structurantes ne vivent pas dans la mémoire d'une personne, mais dans des documents qu'un outil relit et fait respecter.

Et surtout : quand une erreur se produit, la question n'est jamais « qui a oublié ? » mais « quel mécanisme aurait dû l'attraper, et pourquoi n'existait-il pas ? ». Une règle qu'on se contente d'écrire est un vœu. Une règle qu'un mécanisme fait respecter est une garantie. L'écart entre les deux est exactement l'écart entre les deux équipes.

Ce n'est pas gratuit. Ça se paie en temps, en amont, sur des semaines où l'on a l'impression de ne rien livrer. C'est précisément l'investissement que le raccourci refuse de faire — et c'est pour ça qu'il finit toujours par coûter plus cher.

À faire dans les 24 heures

Repérez un outil que vous utilisez sans savoir ce qu'il fait pour vous. Un seul.

Puis tranchez : l'apprendre, ou le remplacer.

Ne laissez pas la troisième option se produire par défaut — celle où vous découvrez la réponse un vendredi soir, en production, quand l'abstraction fuit enfin.

Ce sujet existe aussi en épisode audio : Ship Fast par les outils, pas par les raccourcis.