La config SaaS que tu ne peux pas `git diff` : un audit de 30 secondes avant tout `update`

#devops #vercel #supabase #stripe

Le grep dans le mauvais système

Vendredi 8 mai, fin de session. Je veux activer l'Ignored Build Step de Vercel pour cesser de consommer un build credit à chaque push doc-only. Je greppe vercel.json à la racine du repo. Rien. Je conclus à l'absence de config et lance un updateProject avec ma valeur cible. Le push suivant, tout se passe normalement. Trois jours plus tard, en répondant à une question méthodo sur le commandForIgnoringBuildStep, je retombe sur la valeur précédente. Elle existait. Elle vivait côté Vercel, pas dans le repo. Mon update venait de retirer .claude/ de sa whitelist, sans diff, sans alerte, sans trace.

Deux régimes, un seul réflexe

Une partie de la config de production vit dans le repo. Elle est versionnée, son histoire est lisible dans git log, un mauvais merge se rattrape par revert. L'autre partie vit côté plateforme. Elle est stockée chez le fournisseur, mutable par API ou Console, et ton git diff ne la voit pas. Aucun des deux régimes n'est marqué dans le code que tu lis — tu dois savoir, a priori, où chaque réglage habite.

La cartographie est familière une fois nommée. Vercel : commandForIgnoringBuildStep, environment variables, redirects projet. Supabase : politiques RLS, custom claims, Auth hooks SECURITY DEFINER. Stripe : destinations de webhooks, restricted keys, OAuth Connect settings. GitHub : branch protection rules, secrets de dépôt, rulesets. Aucun de ces réglages n'a son équivalent versionné dans le repo qui les consomme.

Le piège n'est pas l'asymétrie, c'est le réflexe. Tu greppes le repo, tu ne trouves rien, tu conclus à l'absence — alors que la règle existe ailleurs, en silence, et que ton prochain update va l'écraser sans diff.

Trente secondes, quatre commandes

# Audit avant tout updateProject / updateConfig SaaS — 30 secondes
# 1. Lire la config actuelle complète (ex. vercel projects get)
CURRENT=$( $PLATFORM_CLI projects get --json )

# 2. Comparer avec la cible
diff <(echo "$CURRENT" | jq .config) target-config.json

# 3. Lister les champs qui régressent (présents avant, absents après)
jq -n --argjson c "$CURRENT" --slurpfile t target-config.json \
   '($c.config | keys) - ($t[0] | keys)'

# 4. Confirmation explicite avant PATCH
read -p "Régressions ci-dessus acceptées ? (y/N) " ok && [ "$ok" = "y" ] && \
   $PLATFORM_CLI projects update --config @target-config.json

Le coût est forfaitaire, trente secondes. Le bénéfice est binaire — soit ta cible complète la config existante (et tu pousses), soit elle en régresse un champ (et tu reformules avant de pousser). Pas de zone grise. C'est l'équivalent d'un git diff sur ce que git n'indexe pas.

La règle, en une phrase étrangère

Mon CLAUDE.md porte une ligne que j'avais lue cent fois sans la voir frapper, jusqu'au 08 mai.

Investigate before deleting or overwriting, as it may represent the user's in-progress work.

Vercel, Supabase, Stripe, GitHub : la même règle, formulée pour un agent IA, vaut pour la main humaine sur la Console.

Ce qui ne se voit pas n'a pas disparu.

Protocole audit-protocol.sh et deux instances concrètes (Vercel Ignored Build Step, Supabase RLS / Auth hooks), pseudonymisés :
github.com/michelfaure/rembrandt-samples/tree/main/saas-config-platform-vs-repo