Trois empreintes pour un même fichier : la dérive silencieuse d’un code partagé
Deux sites, un dépôt censé faire référence, plusieurs fichiers dont l’empreinte ne coïncide plus. Aucune alerte nulle part : les deux sites fonctionnaient.
Deux sites tournent sur le même plugin et le même thème, avec un seul dépôt local censé faire référence. Avant d’ouvrir un chantier dessus, nous avons relevé l’empreinte md5 des fichiers concernés en trois points : le dépôt local, le premier site, le second. Plusieurs fichiers rendaient trois empreintes différentes.
Aucune alerte nulle part. Aucun message d’erreur, aucun avertissement dans l’administration, aucune anomalie visible. Les deux sites fonctionnaient parfaitement, chacun avec sa version divergente d’un code supposé identique.
Comment un dépôt cesse d’être la référence
La cause est banale et se reconstitue en une phrase : des correctifs posés en urgence directement en production, par une commande d’écriture distante, et jamais remontés dans le dépôt.
Vous lisez la suite le mardi
Chaque semaine, la lettre reprend une série publique : la valeur, sa date, sa source. Quatre minutes, le mardi matin.
En validant, vous acceptez de recevoir la lettre. Désinscription en bas de chaque envoi.
Chacun de ces gestes est défendable pris isolément : un site en panne, un correctif court, une commande qui écrit le fichier corrigé sur le serveur, le service revient. Le problème n’est pas le geste, c’est qu’il ne laisse aucune trace. Une écriture distante ne dit rien de ce qu’elle écrase, ne journalise rien, ne demande rien. Le lendemain, le dépôt local contient toujours l’ancienne version, et plus personne ne se souvient laquelle des deux est bonne.
Sur un hébergement mutualisé, il n’y a ni intégration continue ni déploiement automatisé pour rattraper ça. Le décalage s’installe, silencieux, jusqu’au jour où quelqu’un déploie le dépôt « à jour » sur la production et réintroduit le bug corrigé entre-temps. Ce jour-là, la panne semble venir de nulle part.
L’empreinte est le seul instrument
Sans versionnage, la seule chose qui prouve qu’un fichier est bien celui qu’on croit, c’est son empreinte. Pas sa date de modification, qui est réécrite par n’importe quelle copie. Pas sa taille, qui ne bouge pas d’un octet quand on change un chiffre. L’empreinte, et rien d’autre.
Nous en avons fait la première étape de tout travail sur cette base, avant même d’ouvrir un éditeur : relever les trois empreintes de chaque fichier concerné. Si elles ne coïncident pas, on resynchronise d’abord, on modifie ensuite. La discipline vraiment coûteuse est là, la vérification d’après déploiement, tout le monde la fait ; celle d’avant modification, presque personne, alors que c’est elle qui empêche d’écraser un correctif qu’on ne connaissait pas.
Le contrôle d’après reste en place, sous une autre forme : après chaque écriture distante, empreinte du fichier sur le serveur et vérification de syntaxe du langage sur place. Un fichier PHP qui ne se parse pas rend une page blanche, et une page blanche sur un site qui vit du référencement se paye en positions perdues.
La différence assumée doit être écrite
Un fichier est volontairement différent entre les deux sites : la feuille de style, chaque site ayant sa charte. C’est un cas où la parité ne doit pas exister.
Ce genre d’exception mérite d’être notée noir sur blanc, avec l’empreinte attendue de chaque côté. Sinon, elle produit exactement le même effet qu’une dérive accidentelle : un doute. Six mois plus tard, face à deux empreintes qui divergent, on ne sait plus si c’est une intention ou un accident, et on perd une heure à relire les deux fichiers pour trancher. Une exception non documentée n’est pas une exception, c’est une anomalie de plus.
Ce que ça vaut au-delà du cas
La leçon n’est pas « mettez tout sous versionnage ». C’est vrai, tout le monde le sait, et ça ne décrit pas la réalité d’un parc de petits sites hébergés en mutualisé où la correction se fait souvent à chaud.
La leçon est plus étroite et plus applicable : dès qu’un même code tourne sur plusieurs sites sans mécanisme de déploiement, il dérive. Ce n’est pas un risque, c’est une certitude,. La seule question qui vaut, c’est de savoir si vous disposez d’un instrument capable de vous le dire avant que ça vous coûte quelque chose. Une comparaison d’empreintes sur trois points suffit. Encore faut-il les lancer avant d’éditer, pas après avoir cassé la production.
La lettre du mardi
Une fois par semaine, le mardi : une série publique de la Banque mondiale ou de la BCE, ce qu’elle dit, avec sa date et sa source. Quatre minutes de lecture.
En validant, vous acceptez de recevoir la lettre. Désinscription en bas de chaque envoi.