Pourquoi ton audit DB trouve toujours plus que ton inventaire ne disait

Le ticket disait deux

Vendredi premier mai, début d'après-midi. J'ouvre un ticket de resync baseline qui annonce, sur la foi d'un diagnostic CI honnête, « au moins deux objets manquants » entre la prod et le schéma local. Je commence comme on commence ces choses, en itération. Je trouve le premier en cinq minutes, je le rejoue dans une migration, je passe au suivant. Au cinquième, la défiance arrive, parce que je ne suis plus en train de corriger une liste finie, je suis en train de la découvrir, un patch à la fois, sans savoir combien il en reste.

Première itération : un rôle Postgres agent_readonly absent du repo. Deuxième : une colonne stripe_customer_id posée un soir pour brancher un webhook. Troisième : un doublon d'horodatage de migration. Quatrième : un DROP CASCADE manquant. Cinquième : une table de domaine entière. À ce point j'arrête de patcher au coup par coup. Je vide les catalogues, je comm -23 par catégorie, je sors la liste exhaustive en dix minutes.

Le mécanisme

Une base de données qui a vécu plusieurs mois cumule du drift silencieusement. Un rôle ajouté un lundi via le studio web pour débloquer une analyse, une colonne posée un soir pour brancher Stripe, un trigger réécrit en hotfix qui n'a jamais été reporté dans une migration. Chaque opération paraît anodine au moment où elle est posée. Aucune ne laisse de trace lisible côté repo. La mémoire de l'opérateur tient peut-être les deux ou trois derniers gestes ; au-delà, elle confabule ou oublie. Le seul moyen de connaître l'écart réel entre la prod et le repo est de le mesurer, frontalement, contre les catalogues système.

Le tracker supabase_migrations.schema_migrations confirme l'ampleur. Cinquante-huit versions côté repo, cent soixante-dix-huit côté prod, zéro ligne en commun. Trois mois d'opérations SQL passées par le studio web sans être reportées dans une migration. Le ticket disait deux. La cartographie en a renvoyé plus de cent. Ordre de grandeur : cinquante.

Le protocole

L'audit en bloc tient en une boucle, par catégorie d'objet. On dump la liste prod depuis les catalogues système, on dump la liste repo depuis les fichiers de migration, on prend la différence avec comm -23. On répète pour tables, colonnes, vues, fonctions, triggers, policies, indexes, rôles. Dix minutes en tout.

# Audit DB en bloc — par catégorie d'objet
psql "$PROD_URL" -tAc \
  "SELECT tablename FROM pg_tables WHERE schemaname='public' ORDER BY 1" \
  > /tmp/prod-tables.txt

grep -hE '^CREATE TABLE ' supabase/migrations/*.sql \
  | sed -E 's/.*TABLE [^.]*\.?([a-z_]+).*/\1/' | sort -u \
  > /tmp/repo-tables.txt

comm -23 /tmp/prod-tables.txt /tmp/repo-tables.txt
# → tables présentes en prod, absentes du repo. Boucler par
#   catégorie : columns, policies, indexes, triggers, functions.

Une fois la liste posée, on patche dans l'ordre de dépendance, les rôles d'abord, puis les tables, les colonnes, les indexes, les policies, les triggers. Plus de surprise, et le scope du chantier est connu avant qu'on touche au premier objet.

La règle

Au-delà de trois ou quatre drifts trouvés en itération coup-par-coup, basculer en audit en bloc. Le coût est forfaitaire, environ trente minutes pour cartographier l'ensemble des catégories. Le bénéfice est de connaître le scope exact avant de patcher, plutôt que de découvrir le sixième drift après avoir corrigé les cinq premiers. La règle ne dépend pas de la taille de la base, elle dépend du temps qui sépare la prod de son inventaire.

Clôture

Un inventaire qui dit deux et un audit qui trouve cent ne se contredisent pas. L'inventaire dit ce dont l'opérateur se souvient, l'audit dit ce que la base contient.

Script d'audit en bloc complet (8 catégories) et probe de synchronisation tracker, pseudonymisés :
github.com/michelfaure/rembrandt-samples/tree/main/db-audit-vs-inventory