🛡️Le Gardien Inviolable · le CI qui inspecte chaque changement avant qu'il n'atteigne tes utilisateurs

Le moment · quand le besoin apparaît

Au début tu construis seul. Tu changes quelque chose, tu rafraîchis l'écran, tu vois que ça marche, et voilà. Il n'y a pas de risque : le seul qui subit une erreur, c'est toi, sur ta propre machine, et tu la répares en deux minutes. Cette étape est un paradis — et aussi un piège, parce que tu t'habitues à ce que « si ça marche sur mon écran, c'est bon ».

Le moment change le jour où quelqu'un d'autre dépend de ton app. Le premier utilisateur qui s'inscrit. Le client qui paie déjà. Le collègue qui touche aussi au code. À partir de là, chaque changement que tu publies ne te concerne plus seulement toi : il peut casser l'app de vraies personnes, ou pire, fuiter leurs données. Et voilà le problème — tu ne vois déjà plus tous les changements un par un. Tu demandes quelque chose à l'IA, elle fait 8 fichiers, tu en lis 2, tu approuves, et tu publies. Dans ces 6 que tu n'as pas lus peut se cacher le désastre.

La douleur · d'où elle vient et pourquoi elle fait si mal

La douleur n'est pas dramatique d'emblée. Ce n'est pas un film de hackers. C'est plutôt une série de petits accidents qui, mis bout à bout, te coûtent cher. Et ils naissent tous du même endroit : l'IA en mode constructeur est optimiste. Elle pense à faire fonctionner la nouvelle fonction, pas aux mille façons dont ce changement peut casser autre chose. C'est sa nature — et la tienne aussi quand tu es emballé par la construction.

L'accident le plus coûteux est la clé secrète fuitée. Tu demandes à l'IA de connecter un service, et pour « que ça marche vite » elle colle ta clé d'API directement dans un fichier. Toi tu ne le remarques pas, tu approuves, tu publies sur GitHub. Cette clé est maintenant publique. Il y a des bots qui scannent GitHub 24 heures sur 24 en cherchant exactement ça — ils peuvent la trouver en quelques minutes et commencer à dépenser ton argent ou entrer dans tes systèmes. Ce n'est pas une attaque sophistiquée : c'est une négligence que la machine d'un autre a ramassée par terre, comme on ramasse un portefeuille qui t'est tombé sans que tu t'en aperçoives.

Le deuxième est la brèche dans la base de données. Un changement qui, sans le vouloir, laisse une table de tes utilisateurs accessible à n'importe qui, ou crée une fonction avec des permissions qu'elle ne devait pas avoir. Ça ne se voit pas. L'app continue de fonctionner à l'identique. Mais tu viens de laisser une fenêtre ouverte que personne ne fermera jusqu'à ce que quelqu'un la trouve — et à ce moment-là, il est déjà trop tard.

Le troisième est le plus courant et le moins glamour : tu as cassé quelque chose qui marchait avant. Tu as réparé le bouton A et sans t'en rendre compte tu as débranché le bouton B. Dans ton test rapide tu n'as touché que le A, donc tu ne l'as pas vu. L'utilisateur qui se servait du B tombe sur l'app cassée. En programmation ça a un nom — régression — et c'est 80 % de la vraie douleur du quotidien.

Et que se passe-t-il si tu NE le fais PAS ? Rien… pendant un temps. C'est ça le piège. Ça marche sans gardien pendant des semaines, tu te fais confiance, et juste au moment où le projet commence vraiment à compter — quand il y a déjà des utilisateurs, de l'argent, ou une réputation en jeu — arrive l'accident qu'il t'aurait coûté 30 secondes d'éviter. Le gardien est une assurance bon marché contre une journée très coûteuse.

Les 7 inspecteurs · ce que chacun inspecte

Le gardien n'est pas un bloc magique : ce sont 7 vérifications concrètes qui s'exécutent automatiquement à chaque changement. Si les 7 passent, tu vois un check vert et le changement peut continuer. Si UNE seule échoue, il passe au rouge et le changement reste bloqué jusqu'à ce que tu le répares. Aussi simple, aussi strict. Allons-y une par une, dans l'ordre où elles s'exécutent.

1 · Gitleaks — as-tu glissé une clé secrète par accident ? Il scanne tout le changement à la recherche de choses qui ressemblent à des identifiants : clés d'API, mots de passe, tokens. S'il trouve quelque chose qui sent le secret, il s'arrête net. C'est l'inspecteur qui te sauve de l'accident le plus coûteux de tous, et c'est pour ça qu'il s'exécute parmi les tout premiers — avant même d'installer quoi que ce soit, sur l'arbre propre de git, pour que cette clé n'avance pas d'un pas de plus vers le dépôt public.

2 · Barrière de sécurité (Supabase advisors) — ce changement a-t-il ouvert une brèche dans la base de données ? C'est l'inspecteur chef, et c'est pour ça qu'il s'exécute en premier parmi ceux qui inspectent ton code. Il demande directement à Supabase : une table d'utilisateurs est-elle restée sans son verrou (RLS) ? quelqu'un a-t-il créé une fonction avec des permissions dangereuses ? un accès qu'il ne fallait pas a-t-il été accordé ? Si la réponse est oui, il bloque. C'est celui qui protège les données de tes utilisateurs d'une négligence silencieuse.

3 · Type-check — les types s'accordent-ils ? Dans la programmation moderne, chaque donnée a un « type » (ceci est un nombre, ceci est un texte, ceci est une date). Cet inspecteur confirme que tu n'es pas en train, par exemple, d'additionner un texte avec une date. Il attrape une énorme famille de bugs avant même que l'app ne démarre — des erreurs qui, sinon, apparaîtraient au visage de l'utilisateur au pire moment.

4 · Lint — le code est-il propre ? Le linter est l'inspecteur des mauvaises habitudes : des variables qui se déclarent et ne s'utilisent jamais, du code mort, des schémas qu'on sait causer des problèmes. Ce n'est pas de l'esthétique par caprice — le code sale est là où se cachent les bugs. Un linter oblige à garder la maison rangée pour qu'on voie la vraie saleté.

5 · Format — le formatage est-il cohérent ? Que tout le code se présente pareil : mêmes espaces, mêmes guillemets, même style. Ça sonne comme une manie, mais c'est un langage commun. Quand plusieurs personnes (ou plusieurs sessions d'IA) touchent au même projet sans un format convenu, chaque changement mêle ce que tu as fait à un essaim de guillemets déplacés et d'indentations réordonnées — et tu ne distingues plus l'idée du bruit. L'inspecteur impose le même dialecte pour tous, une fois pour toutes, ainsi personne n'a jamais à en discuter.

6 · Tests — ce qui marchait avant marche-t-il encore ? C'est celui qui attrape les régressions, la douleur nº 3 ci-dessus. Ce sont des tests automatiques qui vérifient que les fonctions clés donnent toujours le bon résultat. Tu as réparé le bouton A ; les tests confirment que le B, le C et le D marchent toujours. C'est l'inspecteur qui te laisse faire de gros changements sans peur, parce que tu sais que si tu casses quelque chose, il te prévient à l'instant.

7 · Build — est-ce que ça compile vraiment ? Le dernier inspecteur assemble l'app depuis zéro, comme si elle allait être publiée. Parce qu'une chose est que « ça marche sur ton ordinateur » et une autre qu'on puisse la construire proprement depuis le départ. Si le build échoue ici, à la porte, c'est infiniment mieux que d'échouer en production avec des utilisateurs qui fixent un écran blanc.

Le coût · pourquoi c'est pratiquement gratuit

On s'attendrait à ce qu'un gardien de niveau entreprise coûte de l'argent. Non. Celui-ci coûte ~$0 et ajoute environ ~15 secondes par inspection. Décomposition honnête : les advisors de Supabase sont gratuits. GitHub Actions (le moteur qui exécute les inspecteurs) te donne 2.000 minutes gratuites par mois dans les dépôts privés — et c'est illimité et gratuit dans les dépôts publics. Une inspection des 7 prend quelques secondes, donc avec 2.000 minutes tu fais des milliers d'inspections par mois sans payer un centime.

Le repo · ce que tu vas copier

Tu n'as rien à inventer. Tout le gardien est empaqueté dans un dépôt public, vérifié, prêt à copier. Ce sont 4 fichiers qu'on emporte dans ton projet, plus un guide d'installation en espagnol pas à pas. C'est écrit en JavaScript pur et ça ne dépend de rien de bizarre.

Le protocole d'installation · une seule fois, pour toujours

Voilà la bonne partie : tu l'installes une fois et il veille sur toi pour toujours. Il n'y a pas de maintenance quotidienne, pas besoin de se souvenir de l'exécuter. Il vit dans ton dépôt et se déclenche tout seul à chaque changement. L'installation, ce sont 6 étapes, et le prompt maître plus bas les colle à ton IA pour qu'elle les fasse avec toi. Regarde d'abord la carte complète pour comprendre ce qui va se passer.

// Paso 3: el script que añades a tu package.json (en la sección "scripts")
{
  "scripts": {
    "db:advisors:gate": "node scripts/supabase-advisors-gate.mjs"
  }
}

# Los 2 secrets del paso 5 se crean en GitHub, NO en el código:
# Repositorio → Settings → Secrets and variables → Actions → New secret
#
#   SUPABASE_PROJECT_REF   → el ref de tu proyecto (cambia por proyecto)
#   SUPABASE_ACCESS_TOKEN  → tu token de cuenta (el mismo para todos tus proyectos)
#
# El gate está hecho para saltarse solo (con aviso) si estos secrets faltan,
# así que nunca rompe un proyecto que aún no los tiene configurados.

Le prompt maître · colle-le à ton IA et qu'elle te l'installe

C'est le seul prompt dont tu as besoin. Tu le colles à ton agent de code (Claude Code, Cursor, ou celui que tu utilises) placé à l'intérieur de ton projet, et il te guide à travers les 6 étapes, en ajustant les 3 données pour toi et en t'expliquant chaque mouvement. Remplis les [crochets] avec tes infos avant de l'envoyer.

Je veux monter dans ce projet un gardien d'intégration continue (CI) qui inspecte chaque changement avant qu'il n'arrive en production. Le modèle est dans le repo public github.com/MentexDev/NeuralOS-CI-Blindaje et apporte 7 inspecteurs : Gitleaks (secrets), barrière de sécurité de Supabase advisors (qui s'exécute EN PREMIER parmi ceux qui inspectent le code), type-check, lint, format, tests et build. Si UN échoue, le changement se bloque.

Contexte de mon projet :
- Base de données : Supabase.
- Gestionnaire de paquets : [npm / pnpm / yarn].
- Nom de mon paquet (le "name" de package.json) : [nombre].

Guide-moi pas à pas, sans que je doive savoir programmer, et dans cet ordre :

1. Apporte les 4 fichiers du modèle (backend-ci.template.yml, gitleaks.toml.template, scripts/supabase-advisors-gate.mjs et scripts/supabase-advisors-allowlist.json) et place-les où ils vont. Le workflow doit se retrouver dans .github/workflows/ SANS le suffixe .template.

2. Cherche dans les fichiers les 3 marqueurs <<<CAMBIAR>>> et remplace-les par les vraies données de mon projet (dossier, chemins, nom du paquet). Montre-moi exactement ce que tu as changé dans chacun.

3. Ajoute à mon package.json le script "db:advisors:gate": "node scripts/supabase-advisors-gate.mjs" sans effacer mes scripts existants.

4. Explique-moi EXACTEMENT où je trouve mon PROJECT_REF dans Supabase, et comment je génère mon ACCESS_TOKEN de compte.

5. Dis-moi pas à pas comment créer les 2 secrets dans GitHub (SUPABASE_PROJECT_REF et SUPABASE_ACCESS_TOKEN). Rappelle-moi qu'ils ne doivent JAMAIS aller à l'intérieur d'un fichier du projet, seulement dans les Secrets de GitHub.

6. Rappelle-moi d'activer "Leaked Password Protection" dans Supabase (Auth → Settings).

À la fin :
- Donne-moi la commande exacte pour faire commit et push de ces fichiers, et dis-moi ce que je devrais voir dans l'onglet des checks de GitHub (les 7 inspecteurs s'exécutant, et lequel s'exécute en premier).
- Si un inspecteur passerait au rouge avec mon projet tel qu'il est maintenant (par exemple, je n'ai pas de tests, ou mon code a des erreurs de type), préviens-moi AVANT et dis-moi la façon la plus simple de le mettre au vert honnêtement, sans désactiver l'inspecteur.

L'habitude · où ça vit dans ton quotidien

La beauté du gardien, c'est qu'il n'exige pas de discipline de ta part. Ce n'est pas une habitude que tu dois te rappeler comme « boire de l'eau » ou « faire de l'exercice ». Une fois installé, il se déclenche tout seul chaque fois que tu publies un changement. Ton seul travail est de regarder la couleur : vert, tu continues ; rouge, tu répares ce que l'inspecteur signale avant de poursuivre.

Le moment où tu le vis est justement en publiant un changement sur GitHub (ou en ouvrant une « pull request », si tu travailles avec des branches — voir la ressource des branches parallèles). Là GitHub lance les 7 inspecteurs automatiquement. En quelques secondes tu as le verdict. Si tu travailles avec l'IA, c'est le point où son optimisme de constructeur rencontre un auditeur qui ne s'emballe pas : la machine inspecte à froid ce que l'IA a construit à chaud.

Les chemins les plus faciles · ce que tu fais toi et ce que fait la machine

Pour que ce soit hyper clair où tu mets la main et où tu ne la mets pas : l'installation, tu la fais UNE fois (avec le prompt ci-dessus, ton IA t'accompagne). Après, tout est automatique. Voici la vraie répartition de l'effort.

Clôture · un gardien qui ne dort pas

Construire avec l'IA est rapide et addictif, et cette vitesse est justement ce qui la rend dangereuse : tu vas si vite que tu ne vois pas tout ce qui est publié. Le gardien ne te freine pas — il te laisse aller vite avec un filet en dessous. Chaque changement passe par 7 inspecteurs en quelques secondes, et si quelque chose sent mauvais, il s'arrête avant de toucher un seul utilisateur. Ça coûte zéro, ça se monte une fois, et ça te donne quelque chose que l'argent n'achète normalement pas : dormir tranquille en sachant que rien de cassé n'arrive en production par négligence.