Une route sans appelant est un bug

Il existe une catégorie de défaut qui ne déclenche rien : pas d''exception, pas de ligne dans les journaux, pas de ralentissement. Du code juste, écrit, testé — et relié à rien. C''est le plus cher à trouver, parce que l''écran a l''air normal.

Cent routes orphelines

En reprenant l''administration de Piks-l module par module, nous avons commencé par un inventaire au lieu d''écrire du neuf : pour chaque route d''API, existe-t-il quelque part une interface qui l''appelle ? La réponse a été non plus de cent fois. Des onglets entiers — clients, stock, statistiques, catalogue d''articles, corbeille, invitations — existaient côté serveur sans le moindre bouton pour y accéder.

Ce que le branchement a révélé

Brancher, c''est vérifier. Quatre défauts sont tombés dans la foulée, tous silencieux :

La liste des devis était vide en production : la route renvoyait une enveloppe que la page lisait comme un tableau. Zéro ligne affichée, zéro erreur remontée.

La création de facture perdait trois champs — étiquettes, référence de virement, conditions de règlement. Le formulaire les envoyait, le schéma de validation ne les déclarait pas, et la bibliothèque retire les clés inconnues sans rien dire. Les factures modifiées les gardaient ; seules les nouvelles les perdaient.

L''escompte pour paiement anticipé s''imprimait hors de sa fenêtre : la fonction qui vérifiait la date existait, exportée, appelée nulle part. Une facture rouverte six mois plus tard promettait encore « 2 % sous 10 jours ».

La courbe d''avancement du kanban comptait tous les tableaux : un tableau client à l''arrêt affichait l''activité de toute l''équipe. Un chiffre crédible, et faux.

La règle, maintenant écrite dans les tests

Chaque module porte désormais un test qui relit ses routes, en déduit les URL, cherche un appelant, et échoue s''il n''en trouve pas. Le calendrier va plus loin : il refuse aussi un composant monté nulle part, un réglage enregistré que personne ne relit, une touche annoncée dans l''aide et branchée sur rien.

Ce n''est pas une contrainte de style. C''est la seule façon d''éviter que « c''est développé » et « c''est utilisable » finissent par vouloir dire deux choses différentes.