Où le schéma de la base vit réellement

Tout ce que fait ce service est en gestion de versions. Le code, du moins. La base sur laquelle il tourne, ce sont 32 tables, et 15 d’entre elles n’ont de définition nulle part dans le dépôt — pas de CREATE TABLE, pas de fichier de schéma, rien. Une sauvegarde restitue les 32 avec leur forme intacte ; ce que le dépôt ne contient pas, c’est une seconde copie indépendante de cette forme.

Ces chiffres viennent d'une comparaison entre la base en service et 736 fichiers, 5 671 710 caractères de dépôt. Ce ne sont pas des estimations.

Comment la moitié d'un schéma disparaît

Ce n'est pas de la négligence, et c'est ce qui vaut la peine d'être noté. Chaque étape prise isolément était raisonnable.

Les tables créées avant le code actuel n'ont jamais été écrites, parce qu'à l'époque elles étaient simplement là. Les tables ajoutées depuis sont arrivées par des scripts de migration, et ceux-là sont dans le dépôt — d'où les 17 définitions. Les colonnes ajoutées plus tard sont arrivées par un ALTER TABLE d'une ligne tapé dans un terminal, parce que le taper allait plus vite qu'écrire un script pour un changement d'une seconde.

Les index sont le pire cas. Un index s'ajoute quand quelque chose est lent, au moment où c'est lent, et cela règle le problème sur-le-champ. Il ne reste aucun artefact, rien à relire, rien qui échoue en cas d'oubli. Onze des trente-deux index secondaires d'ici existent exactement pour cette raison et ne sont consignés nulle part.

La table où se trouvent les compteurs eux-mêmes, 166 438 lignes, fait partie des quinze sans définition dans le dépôt.

Ce qui casse vraiment

Pas grand-chose, jusqu'à un moment précis : quand la base est restaurée depuis une sauvegarde.

Une sauvegarde emporte la structure, une restauration directe se passe donc bien. Le danger, c'est tout chemin qui reconstruit une table au lieu de la restaurer — un déménagement vers une autre machine, l'import de tables choisies, la recréation depuis un script. Les données reviennent, les index silencieusement non. Rien n'échoue. Les requêtes renvoient les bonnes réponses. Elles mettent seulement plus de temps, et la cause est invisible, car le seul enregistrement de ce qu'était l'index se trouve sur la machine qui ne l'a plus.

C'est le mode de défaillance à nommer : un index manquant ne produit pas d'erreur, il produit une bonne réponse plus lente. Aucun test ne l'attrape, puisque les tests passent.

Ce que nous faisons en attendant

Le schéma n’est pas dans le dépôt aujourd’hui, et c’est la description exacte de l’état. Ce qui est en place est plus étroit qu’une correction complète et couvre le cas qui coûte réellement quelque chose :

Une sauvegarde avant toute opération destructrice, gardée hors de la racine web. Une restauration réellement effectuée au moins une fois, plutôt que supposée. Et une courte liste, vérifiée après chaque restauration, des index connus pour n'exister que dans la base en service — car la machine sait répondre quels index elle a, et cette réponse se compare à celle de la dernière fois.

La version générale vaut pour plus que les bases de données. Si une partie du système n’existe que dans le système en service, il n’en existe pas de seconde copie. La question qui vaut la peine d’être posée pour n’importe quelle infrastructure n’est pas de savoir si elle est sauvegardée, mais ce qui ne pourrait pas être reconstruit depuis le dépôt si la machine disparaissait. Ici la réponse est quinze tables et onze index, l’établir a pris un après-midi, et c’est une liste plutôt qu’une inconnue.

Mise à jour : septembre 2026

Cinq jours après ce billet, le répertoire de travail a été versé dans le dépôt : 26 fichiers et 4058 lignes, dont onze scripts de migration écrits entre le 28 août et le 1er septembre qui jusque-là n’existaient que sur la machine en service. C’était la moitié facile — du code écrit mais jamais consigné.

Le 1er septembre 2026, la mesure a été refaite de la même façon : la base en service face à tout ce que git connaît.

Tables	46	30 avec un CREATE TABLE dans le dépôt, 16 sans
Index secondaires	43	32 créés par du code du dépôt, 11 seulement dans la base en service
Scripts de migration	109	sous gestion de version

Le chiffre qui compte n’a pas bougé. Le 27 août, onze index secondaires n’existaient nulle part ailleurs que dans la base en service. Le 1er septembre, ils sont toujours onze. Entre-temps onze autres index sont arrivés, et chacun est venu avec un script de migration : l’habitude a changé, pas la dette.

Les onze reposent sur cinq tables — les compteurs, les langues, les référents, la liste d’exclusion et le journal des événements. Toutes cinq sont antérieures au code actuel, et c’est précisément pour cela que rien n’a jamais été noté à leur sujet. Écrire un fichier maintenant reviendrait à reconstituer, depuis un serveur en service, ce qui a été tapé à une invite il y a des années.

La position d’août reste donc valable. Le schéma n’est toujours pas dans le dépôt, et une restauration qui reconstruit une table au lieu de la rétablir perdrait encore onze index sans un mot. Ce qui a changé est plus étroit : tout ce qui s’est ajouté depuis a laissé un fichier.