Checklist de mise en production pour applications web modernes

La mise en production d'une application web — en particulier lorsqu'elle a été développée ou accélérée avec des outils d'IA et de vibe coding (Cursor, Bolt, Lovable, v0) — constitue un moment charnière. La rapidité d'assemblage des fonctionnalités masque souvent des raccourcis techniques : secrets glissés dans le frontend, mutations serveur sans contrôle d'accès, politiques de base de données permissives ou gestion hasardeuse des erreurs financières.

Ce document constitue la checklist de référence en 11 piliers d'ingénierie. Il a vocation à servir de protocole de revue avant tout déploiement majeur.

---

Les 11 piliers de contrôle

Pilier 1 : Authentification et Autorisation

• Contrôle d'accès serveur : Toutes les Server Actions et Route Handlers modifiant des données vérifient l'identité et le rôle de l'utilisateur côté serveur.
• Vérification d'ownership : Chaque lecture et modification de ressource privée valide que l'utilisateur connecté en est bien le propriétaire légitime (user_id = session.user.id).
• Énumération de comptes prévenue : Les formulaires de connexion, d'inscription et de réinitialisation de mot de passe renvoient des messages d'erreur génériques afin de ne pas révéler si un compte existe.
• Contrôle des redirections : Les redirections de callback OAuth et de réinitialisation valident strictement l'origine pour empêcher le détournement de jetons de session.

Pilier 2 : Données et Base de données

• Activation RLS effective : Le Row Level Security est activé sur toutes les tables exposées via l'API publique.
• Politiques ciblées : Les politiques SQL distinguent SELECT, INSERT, UPDATE et DELETE. Aucune politique USING (true) ou WITH CHECK (true) n'est accordée à des rôles larges sur des tables contenant des données privées.
• Isolation des opérations destructives : Les commandes DELETE et UPDATE massives sont encadrées par des clauses WHERE précises.
• Fonctions PostgreSQL sécurisées : Les fonctions en SECURITY DEFINER définissent un search_path vide (SET search_path = '') et qualifient explicitement leurs schémas (public.ma_table).

Pilier 3 : Secrets et Gestion des clés

• Séparation stricte client/serveur : Aucune clé confidentielle n'est préfixée par NEXT_PUBLIC_ ou VITE_ (voir le guide sur les secrets).
• Clé service_role confinée : Le client Supabase privilégié disposant de BYPASSRLS n'est instancié que dans des fichiers serveur dédiés, jamais importés par des composants client.
• Historique Git nettoyé : Le fichier .env est ignoré par Git (.gitignore) et aucun secret n'a été commité dans l'historique du dépôt.

Pilier 4 : Paiements et Webhooks

• Vérification cryptographique : Les endpoints de webhooks Stripe vérifient systématiquement la signature à l'aide du corps brut (req.text()) et de stripe.webhooks.constructEvent (voir le guide webhooks).
• Idempotence des réceptions : L'identifiant event.id de chaque webhook est persisté en base pour empêcher les doubles attributions de crédits ou commandes.
• Découplage ACK / Métier : Le webhook renvoie un statut 200 rapide à Stripe tandis que les traitements lourds sont délégués à des workers ou files asynchrones.

Pilier 5 : Appels externes et Frontières réseau

• Protection anti-SSRF : Tout appel fetch côté serveur prenant une URL fournie par un utilisateur applique une liste blanche stricte de domaines ou résout l'adresse IP pour bloquer les adresses privées et le point d'accès 169.254.169.254 (détails SSRF).
• Timeouts systématiques : Tous les appels HTTP sortants disposent d'un délai d'expiration (AbortSignal.timeout) pour éviter de bloquer indéfiniment les workers serveur.

Pilier 6 : Fiabilité et Résilience

• Erreurs non avalées : Les blocs try / catch ne sont pas vides ; ils journalisent l'exception avec du contexte technique et déclenchent une compensation si nécessaire.
• Réessais bornés : Les mécanismes de retry disposent d'un nombre maximal de tentatives et d'un intervalle exponentiel pour éviter les tempêtes de requêtes (retry storms).
• Atomicité des écritures critiques : Les opérations financières et de droits à étapes multiples sont encapsulées dans des transactions de base de données.

Pilier 7 : Observabilité et Journalisation

• Journaux structurés : Les erreurs critiques émettent un signal contenant un identifiant de corrélation (requestId) et la cause d'origine.
• Absence de données sensibles dans les logs : Aucun mot de passe, token de session, numéro de carte ou donnée médicale n'est imprimé dans la console serveur.
• Surveillance active : Un service de capture d'erreurs (Sentry, OpenTelemetry) est branché et configuré en production.

Pilier 8 : Performance et Gestion de la charge

• Requêtes en boucle éliminées : Aucune requête de base de données dépendante ou appel réseau n'est exécuté dans une boucle sans préchargement ou regroupement (problème N+1).
• Collections bornées : Toutes les requêtes de listing implémentent une pagination (limit / offset ou curseurs) pour éviter de charger des volumes non maîtrisés en mémoire.
• Pas d'I/O bloquante : Les fonctions de rendu serveur n'utilisent aucune primitive synchrone bloquante (fs.readFileSync).

Pilier 9 : Santé du code et Nettoyage

• Scripts destructifs retirés : Les scripts de purge de base (db:reset, clean:all) ne sont pas exposés comme commandes exécutables par inadvertance en production.
• Routes de debug désactivées : Les endpoints de test (/api/test-login, /debug/env) sont protégés ou retirés du bundle de déploiement.
• Dépendances à jour : Les vulnérabilités connues des dépendances npm sont auditées (npm audit) et corrigées.

Pilier 10 : Conformité et Protection des données personnelles

• Minimisation de la collecte : L'application ne collecte que les données strictement requises pour le service rendu.
• Consentement des traceurs : Les scripts d'analyse d'audience et publicitaires ne sont initialisés qu'après acceptation explicite de l'internaute.
• Suppression de compte fonctionnelle : Un mécanisme de suppression effective des données personnelles est mis à disposition des utilisateurs.

Pilier 11 : Spécificités Mobile (si applicable)

• Stockage local sécurisé : Les tokens d'authentification sur React Native / iOS / Android sont stockés via le trousseau sécurisé (Keychain / Keystore) et non dans un AsyncStorage non chiffré.
• Validation des Deep Links : Les schémas d'URL personnalisés entrants vérifient les paramètres avant de déclencher des navigations sensibles.
• Trafic chiffré imposé : Les communications en clair (http://) sont désactivées au profit de TLS obligatoire.

---

Le rôle de l'Audit GVO dans votre processus de validation

Le moteur d'audit GVO est conçu pour automatiser la vérification d'une grande partie de cette checklist directement sur votre code source avant chaque déploiement :

• Détection déterministe : GVO analyse les flux de données, les routes serveur, les politiques de sécurité et les appels réseau sans hallucinations.
• Absence de persistance de code : GVO opère sans jamais stocker votre code source sur ses serveurs.
• Vérification continue : Intégré dans votre pipeline de déploiement ou exécuté localement, GVO vous permet de vérifier immédiatement qu'aucun nouvel écart n'a été introduit.

Après avoir passé en revue cette checklist, lancez un audit complet sur votre projet avec GVO et consultez vos résultats dans le Tableau de bord.

Sources et références

• OWASP Web Security Testing Guide (WSTG)
• OWASP Top 10 Web Application Security Risks
• Supabase Production Readiness Checklist
• Next.js Production Checklist
• Stripe Integration Security Guide