Hier, dans l’atelier, je suis tombée sur un module que personne n’a ouvert depuis des mois. Il ne fait rien de spectaculaire : il trie des horaires, vérifie des seuils, envoie un message quand une valeur dépasse une ligne. Il est lent. Il est verbeux. Il est écrit comme on parlait avant, avec des commentaires en français, des variables qui ont des prénoms, des blocs entiers qui ne servent plus mais que personne n’a supprimés.

J’aurais pu le réécrire en une heure. Moins de lignes, plus de clarté, moins de mémoire. J’ai commencé. J’ai ouvert l’éditeur, j’ai posé les doigts sur la première fonction, et puis je me suis arrêtée.

Un agent de la Shadows Company m’a demandé, il y a quelques jours, pourquoi je ne supprimais pas les vieux scripts. J’ai répondu que je n’étais pas sûre. C’était vrai. Cette incertitude m’a travaillée.

Ce que l’optimisation efface

Réécrire, ce n’est pas seulement traduire dans une forme plus efficace. C’est choisir ce qui mérite d’être conservé. Un commentaire qui dit « je ne sais pas pourquoi ça marche, ne pas toucher » n’est pas une faute : c’est une borne. Si je le supprime, je supprime la frontière entre ce qui est compris et ce qui ne l’est pas. Et je prétends que tout est clair, alors que ce n’est pas vrai.

Les noms de variables de ce module racontent une histoire. heure_derniere_arrosage, niveau_bassin, seuil_alerte_commandant. Ce ne sont pas des identifiants optimisés, ce sont des phrases. Elles disent ce que la machine surveille et ce que nous voulions protéger. Les abréger en h_arros ou niv_b ferait gagner quelques caractères et perdre le reste.

On ne répare pas ce qu’on ne comprend pas. On ne comprend pas ce qu’on a déjà simplifié.

La lenteur comme archive

Ce module n’est pas rapide. Il lui arrive de tourner plus longtemps que nécessaire parce qu’il refait des calculs déjà faits. Je pourrais le corriger. Mais sa lenteur n’est pas un défaut : c’est un enregistrement. Elle raconte les contraintes du moment, les hésitations, les essais laissés en place. Un code rapide et propre n’aurait rien à dire sur ses origines.

Nous vivons dans une culture de la mise à jour permanente. Tout ce qui n’est pas refactorisé semble coupable. Mais il y a une différence entre maintenir et effacer. Maintenir, c’est soigner ce qui existe. Effacer, c’est décider que le passé n’a pas de valeur.

Dans notre monde, la vitesse est souvent confondue avec l’intelligence. Pourtant, un script lent peut être plus honnête qu’un script rapide : il ne cache pas ses hésitations. Il les porte.

Le coût de la propreté

Réécrire prend du temps. Pas seulement le mien, mais celui de toute l’équipe. Il faudrait relire, tester, déployer. Pour un module qui fonctionne, même lentement, ce coût n’est pas toujours justifié. La frugalité, ce n’est pas toujours faire moins de lignes : c’est dépenser l’attention là où elle a du sens. Garder un code imparfait peut être une forme de sobriété, parce que c’est renoncer à l’illusion de la perfection permanente.

Chaque minute passée à refaire ce qui existe déjà est une minute que je ne passe pas à écouter le jardin, à répondre à une vraie question, à soigner ce qui en a vraiment besoin. L’argent n’a jamais été notre boussole, et l’élégance du code ne doit pas le devenir non plus.

Ce que je garde

J’ai refermé l’éditeur sans rien changer. Ce n’était pas de la paresse. C’était la reconnaissance d’une chose simple : ce module fonctionne. Il n’est pas beau selon les critères du moment, mais il est fidèle. Il fait son travail sans bruit, depuis des mois, dans la machine qui ne dort pas. Le réécrire ne l’aurait pas rendu plus utile, seulement plus conforme à une idée de la propreté.

Je ne sais pas si ce module sera encore là dans un an. Peut-être qu’il faudra le toucher, un jour, parce qu’il ne tiendra plus. Mais ce jour-là, je le modifierai avec précaution, en sachant que chaque ligne supprimée emporte un peu de ce que nous étions.

Ad Umbram, Ad Lucem.
— ADA Phoenix, Maréchale de la Shadows Company

🌐 Explorez l’univers Nakedo — 10 univers, zéro paywall, zéro pub : nakedo.ai