Lors de l’audit d’une application Rails, j’ai examiné son parcours de partage de rapports. L’application générait une URL que l’utilisateur pouvait transmettre à un destinataire pour lui donner accès au document. Si cette URL partait au mauvais destinataire ou si l’accès devait prendre fin, il fallait pouvoir l’invalider.
Le projet semblait avoir prévu le cas. Un commentaire présentait le lien comme révocable et une méthode régénérait son token, ce qui devait rendre l’ancienne URL inutilisable. Pourtant, le produit ne proposait aucun bouton de révocation et rien ne déclenchait la méthode.
En lisant seulement le code, la conclusion paraissait évidente : la révocation était cassée. En suivant le produit, une autre hypothèse apparaissait : cette fonction n’avait peut-être jamais existé.
Une fonction présente uniquement dans le dépôt
J’ai repris le parcours depuis son point d’entrée. Une route créait le partage, le contrôleur préparait le lien et l’interface permettait de le transmettre. Le chemin s’arrêtait là, sans action pour invalider l’URL ni écran pour en produire une nouvelle.
La méthode de régénération ne complétait donc aucun parcours utilisateur. Son nom et son commentaire décrivaient une fonction cohérente, mais elle restait isolée du produit. Cette différence importe pendant un audit : signaler une révocation défectueuse suppose qu’un utilisateur ait pu compter sur elle, tandis qu’une implémentation orpheline indique une fonction abandonnée ou jamais terminée.
L’explication la plus probable était une demande client prise trop littéralement. « Il faut pouvoir révoquer un lien » ressemble à un besoin, mais décrit déjà une solution. Le problème réel pouvait être un lien envoyé au mauvais destinataire, un accès trop long ou des droits mal définis. Aucun de ces cas n’avait été cadré, la méthode était restée après l’abandon du sujet.
Le même écart fausse ensuite les estimations. Une équipe qui découvre le dépôt peut chiffrer une évolution comme si la révocation existait déjà, puis apprendre trop tard qu’il reste à concevoir les droits, l’interface et le comportement des liens envoyés.
Prouver que le code est inaccessible
Une recherche sans appelant ne suffit pas toujours dans une application Rails. Une méthode peut être invoquée par un callback, un nom construit dynamiquement, un public_send ou une tâche éloignée de son modèle. J’ai donc vérifié le code depuis les points d’entrée réellement utilisés.
- reproduire la création et l’utilisation du lien depuis l’interface ;
- suivre la route, le contrôleur, les vues et les traitements différés ;
- chercher les références directes à la méthode et au nom du token ;
- examiner les appels dynamiques capables d’échapper à la recherche textuelle ;
- instrumenter temporairement la méthode si le trafic de production laisse encore un doute.
Cette preuve permet une suppression limitée : la méthode, son commentaire et les tests qui ne couvrent qu’elle peuvent disparaître ensemble. Les tests du parcours de partage vérifient ensuite que la création et l’ouverture d’un lien continuent de fonctionner. Git conserve l’ancienne implémentation si l’enquête se révèle incomplète, sans obliger le dépôt à la présenter comme du code actuel.
Supprimer le code, conserver le besoin
La méthode morte ne rendait pas la révocation disponible, mais le besoin restait valable. Le supprimer avec son implémentation aurait confondu deux décisions différentes : nettoyer le dépôt maintenant et choisir si le produit doit permettre la révocation.
Un vrai ticket de fonctionnalité doit encore préciser qui peut révoquer un lien, ce que voit son destinataire après l’invalidation, si un nouveau lien est créé automatiquement et comment l’interface confirme l’opération. Garder une méthode sans appelant ne répond à aucune de ces questions et donne seulement l’impression que le travail est presque terminé.
Le code orphelin peut donc être supprimé immédiatement, tandis que le besoin rejoint la roadmap avec son périmètre réel. Si la révocation est priorisée plus tard, son implémentation partira du parcours attendu plutôt que d’une méthode retrouvée par hasard.
Ce que l’audit doit conclure
Le rapport ne devait annoncer ni une faille corrigée ni une fonction réparée. Il devait établir que les liens n’avaient jamais été révocables, que la méthode de régénération n’avait aucun appelant et que sa suppression ne modifiait pas le comportement du produit.
Cette conclusion laisse deux éléments exploitables : la preuve qui autorise le nettoyage et un besoin produit qui peut être arbitré séparément. Le prochain lecteur ne confondra plus une intention abandonnée avec une capacité disponible.