Un contrôle au vert qui ne comparait rien
Pendant des semaines, un contrôle a annoncé un succès sans jamais comparer deux éléments. Le plus coûteux n’était pas la faille, mais la coche verte placée au-dessus.
Chaque modification du schéma de cette base de données arrive sous la forme d’un fichier dans le dépôt et est appliquée lors de la fusion. Pour éviter que les fichiers et la production ne divergent, un contrôle quotidien appelé « les fichiers et le registre distant correspondent » est exécuté. Pendant des semaines, il a annoncé un succès.
Il ne comparait rien. La commande exécutée affiche un tableau et se termine avec succès, quel que soit le contenu de ce tableau. Un contrôle dont le chemin d’échec ne s’exécute jamais n’est pas un contrôle — c’est une coche verte sur laquelle tout le monde s’appuie.
Ce qu’il aurait dû détecter
Lorsque le dépôt a été transféré vers une organisation, l’intégration de la base de données est restée liée à l’ancien compte. Neuf pull requests ont été fusionnées cet après-midi-là et aucune n’a atteint la base de données. Rien n’a échoué : les contrôles étaient au vert et les fusions propres. Le seul indice était la présence de 110 fichiers pour 109 lignes dans le registre.
Une migration fusionnée semble appliquée simplement parce que la fusion a réussi.
Aujourd’hui, le contrôle lit les versions appliquées via l’API de gestion, les compare aux fichiers et échoue dans trois cas : une version appliquée sans fichier, un fichier plus ancien que la dernière version appliquée mais jamais exécuté, et un fichier fusionné mais jamais appliqué. Lorsqu’il ne peut pas vérifier, il échoue au lieu d’émettre un avertissement — car un détecteur aveugle qui annonce un succès est précisément le problème qu’il doit empêcher.
Qui contrôle le contrôle
La deuxième leçon était moins confortable. Les contrôles s’exécutent à partir de l’état de la branche qu’ils évaluent. Une pull request peut donc affaiblir une garantie et réécrire dans le même diff le test qui la protège — puis être fusionnée au vert. Depuis la fin août, le plan de contrôle — workflows, scripts, configuration des tests et fichiers de dépendances — est évalué par un contrôle qui ne récupère jamais la branche et prend sa définition dans la branche principale. Toute modification de cette surface exige une étiquette ajoutée par une personne ; une étiquette ajoutée par un bot est refusée, car cela a déjà fonctionné une fois.
Six corrections ont suivi la première version, chacune issue d’une faille mesurée. Par exemple, un test d’exhaustivité comptait des noms plutôt que des objets fichier ; comme un renommage produit deux noms, le compte semblait correct alors qu’un fichier protégé passait sans être vérifié. La leçon générale est la plus importante : un étalonnage que l’on peut satisfaire avec la mauvaise quantité équivaut à l’absence d’étalonnage.
Point ouvert et consigné : ce contrôle n’est pas encore enregistré comme obligatoire. Il signale les problèmes, mais ne bloque rien. C’est un élément de la liste, pas une phrase à omettre.