Site créé avec l’IA : la checklist sécurité avant la mise en ligne

L’IA vous a sorti un site ou une application qui fonctionne, et c’est une vraie réussite. Mais « ça marche » et « c’est sûr » sont deux choses différentes. Un outil d’IA optimise pour le résultat visible à l’écran, pas pour fermer les portes qu’un visiteur mal intentionné pourrait pousser.

Avant de mettre en ligne, surtout si votre projet gère des comptes, des données clients ou des paiements, passez cette checklist. C’est le volet sécurité de la fiabilisation d’un projet créé avec l’IA, et c’est souvent là que se cachent les surprises.

Pourquoi un projet généré par IA est vulnérable par défaut

Quand vous demandez à l’IA « crée-moi un formulaire de connexion », elle répond à cette demande, pas à « crée-moi un formulaire de connexion qui résiste aux attaques ». Elle s’inspire d’exemples publics, souvent simplifiés pour être pédagogiques, parfois obsolètes. Résultat : le code compile, la démo est impeccable, mais les protections sont absentes ou désactivées « pour que ça marche ». Ce n’est pas un défaut de votre projet, c’est une étape que personne n’a encore faite.

La checklist sécurité avant la mise en ligne

Huit points, du plus fréquent au plus technique. Pour chacun : ce que c’est, comment vérifier, comment corriger.

1. Les clés et secrets exposés

Clés d’API, jetons d’accès, mots de passe écrits en dur dans le code ou envoyés au navigateur. C’est le problème numéro un des projets générés par IA.

• Vérifier : ouvrez votre site, appuyez sur F12 (outils développeur), onglet « Sources » ou « Réseau », et cherchez des chaînes du type sk_live, api_key, secret. Vérifiez aussi l’historique de votre dépôt Git.
• Corriger : déplacez tout secret dans des variables d’environnement côté serveur, jamais dans le code envoyé au navigateur. Et révoquez puis régénérez toute clé déjà exposée : une clé qui a fuité doit être considérée comme compromise.

2. L’accès à la base de données

Les bases modernes (Supabase, Firebase, etc.) sont parfois ouvertes en lecture et écriture par défaut. Sans règles de sécurité, n’importe qui peut lire ou modifier toutes vos données directement via l’API, sans passer par votre interface.

• Vérifier : regardez si les règles de sécurité (RLS sur Supabase, Security Rules sur Firebase) sont activées. Tentez d’appeler l’API sans être connecté : si vous récupérez des données, c’est ouvert.
• Corriger : activez les règles et appliquez le principe du moindre privilège : chacun n’accède qu’à ce qui le concerne, et rien de plus.

3. L’authentification et les autorisations

Cacher un bouton « Admin » dans l’interface n’empêche personne d’appeler l’action correspondante. Si la vérification du « qui a le droit » se fait uniquement côté navigateur, elle se contourne en quelques secondes.

• Corriger : toute autorisation sensible doit être revérifiée côté serveur, à chaque requête. Le client décide de ce qu’on affiche, le serveur décide de ce qu’on autorise.

4. La validation des données entrantes

Tout ce qu’un utilisateur saisit peut être malveillant ou simplement malformé. Sans contrôle, on s’expose aux injections et aux données corrompues qui pourrissent la base sur le long terme.

• Corriger : validez chaque entrée côté serveur (format, longueur, type), pas seulement avec le contrôle du navigateur, qui n’est qu’un confort d’affichage.

5. Les routes d’API non protégées

L’IA crée volontiers des points d’accès qui renvoient des données sans vérifier qui appelle. Une URL devinée peut alors exposer la liste de vos clients ou de vos commandes.

• Vérifier : listez vos routes d’API et demandez- vous, pour chacune, « est-ce normal qu’une personne non connectée y accède ? ».

6. Les données personnelles

Dès que vous collectez un email, un nom ou un numéro de téléphone, vous manipulez des données personnelles, avec des obligations à la clé.

• Minimum vital : HTTPS partout, accès restreint aux données, et ne stockez que ce dont vous avez réellement besoin. Le volet conformité (RGPD, mentions légales) mérite son propre passage en revue, j’y reviendrai dans un guide dédié.

7. Les dépendances obsolètes

Un projet s’appuie sur des dizaines de briques tierces. Certaines ont des failles connues et corrigées… dans une version que vous n’avez pas.

• Vérifier : lancez npm audit (ou l’équivalent de votre outil) pour lister les vulnérabilités connues.
• Corriger : mettez à jour, en testant que rien ne casse au passage.

8. La configuration de mise en production

Le mode « développement » laissé actif en ligne expose des messages d’erreur détaillés, une mine d’or pour un attaquant.

• Corriger : séparez nettement les réglages de test et de production, désactivez le mode debug en ligne, et ajoutez les en-têtes de sécurité de base.

Si la checklist révèle des trous

Pas de panique : c’est le cas de la grande majorité des projets sortis vite, et ça se corrige sans tout refaire. La sécurité se rattrape par retouches ciblées sur l’existant, pas par une reconstruction. C’est exactement le premier volet d’une fiabilisation de projet.

Un doute sur l’état de votre projet ? Décrivez-moi votre situation via le formulaire de projet ou la page contact, je vous dis franchement où vous en êtes.