En 2026, on peut lancer un site fonctionnel dans la journée : un prompt bien tourné dans un outil no-code ou un assistant de « vibe coding », et une interface apparaît, déjà connectée à une base de données, à une API de paiement, parfois à un CRM. C'est une vraie révolution pour la rapidité de mise en marché. Mais un site généré vite est un site testé vite, documenté vite — et souvent sécurisé pas du tout. La sécurité n'est jamais le sujet spontané d'un prompt : elle doit être explicitement demandée, vérifiée, puis auditée. Sans cette étape, trois risques reviennent sans cesse sur les sites créés ou modifiés avec l'IA : du code vulnérable, des clés API qui traînent en clair, et des conversations qui finissent, malgré vous, indexées par Google.

Le code généré par l'IA n'est pas sécurisé par défaut

Un modèle de langage génère le code le plus probable compte tenu de votre prompt — pas le code le plus sûr. Si vous demandez « un formulaire de contact qui envoie un email », vous obtiendrez un formulaire qui fonctionne. Vous n'obtiendrez pas, sauf à le demander explicitement, la validation des champs côté serveur, la protection contre les injections, ou la limitation du taux d'envoi contre le spam.

Les failles les plus fréquentes qu'on retrouve dans du code généré par IA et jamais relu :

  • Injections SQL et XSS : des entrées utilisateur insérées telles quelles dans une requête ou affichées sans échappement, ouvrant la porte à l'exécution de code malveillant.
  • Validations manquantes ou côté client seulement : facilement contournables, elles ne protègent rien puisque n'importe qui peut envoyer une requête directement au serveur.
  • Dépendances non vérifiées : l'IA installe des librairies tierces (npm, pip, composer) sans vérifier leur popularité, leur maintenance réelle ou leurs vulnérabilités déjà connues et publiées.
  • Réglages par défaut trop permissifs : CORS ouvert à tous les domaines, mode debug laissé actif en production, comptes d'administration avec des identifiants par défaut, droits de fichiers trop larges.

Rien de tout cela n'est une critique de l'IA en tant qu'outil : c'est un rappel que le code généré doit être relu par un humain avant de partir en production, exactement comme n'importe quel code livré par un développeur pressé.

Les clés API : la fuite la plus courante

C'est, de loin, la faille la plus fréquente qu'on retrouve en auditant des sites conçus avec l'aide de l'IA. Une clé API — celle de Stripe, OpenAI, Google Maps, SendGrid, Supabase... — permet à votre site de dialoguer avec un service tiers. Elle doit rester secrète. Trois erreurs reviennent sans cesse :

  • Collée en dur dans le code front-end : elle apparaît en clair dans le code source de la page, visible par n'importe qui via l'inspecteur du navigateur, en quelques secondes.
  • Poussée sur un dépôt GitHub public : des robots scannent en permanence les dépôts publics à la recherche de clés oubliées dans un commit, parfois en quelques minutes après la mise en ligne.
  • Copiée telle quelle depuis une réponse de l'IA : un exemple de code fourni par l'assistant, collé sans y penser dans un fichier, un email ou un ticket, contient encore votre clé.

Les conséquences sont concrètes, pas théoriques. Une clé Stripe ou OpenAI exposée peut être exploitée par un tiers pour générer des appels facturés directement sur votre compte — certains développeurs ont vu leur facture cloud grimper de plusieurs milliers d'euros en quelques heures. Une clé de base de données exposée donne un accès direct à vos données clients. Une clé mal restreinte peut même permettre de modifier ou de supprimer des ressources à votre place.

Règle d'or : une clé API ne doit jamais se trouver côté client (dans le code que le navigateur télécharge), ni dans un dépôt de code public — même un dépôt privé un jour, rendu public par erreur le lendemain.

Vos conversations avec l'IA peuvent finir sur Google

Moins connu, mais tout aussi réel : ce que vous tapez dans un assistant IA peut, dans certains cas, devenir public. Des milliers de conversations partagées via la fonction « Partager » de ChatGPT se sont retrouvées indexées par Google et consultables par n'importe qui via une simple recherche — parce que les utilisateurs avaient généré un lien de partage sans réaliser qu'il pouvait être exploré et référencé par les moteurs de recherche. Des conversations contenant des données personnelles, des extraits de code interne, parfois des identifiants, sont ainsi devenues publiques du jour au lendemain.

La leçon dépasse largement ChatGPT. Dès qu'un outil IA propose de « partager » ou d'« exporter » une conversation via un lien, ce lien peut être découvert, indexé, archivé — parfois durablement, même après suppression du côté de l'utilisateur. Et au-delà du partage volontaire, tout ce que vous collez dans un prompt (extrait de base de données, clé API « pour debugger plus vite », mot de passe pour tester un accès) entre dans les journaux d'un service tiers dont vous ne maîtrisez ni la rétention exacte ni toutes les conditions d'utilisation.

La règle est simple : ne collez jamais de mot de passe, de clé API, de donnée client ou de secret d'entreprise dans un assistant IA grand public, même pour une question qui semble anodine. Si vous avez besoin d'aide sur du code sensible, anonymisez-le avant de le partager, ou passez par un environnement IA d'entreprise sous contrat de confidentialité.

Comment sécuriser vos créations assistées par IA

Utiliser l'IA pour construire plus vite n'est pas le problème — l'absence de vérification l'est. Quelques réflexes suffisent à fermer la majorité des risques :

  • Clés API côté serveur uniquement, chargées via des variables d'environnement ou un fichier .env explicitement exclu du dépôt (.gitignore) — jamais dans le code exécuté par le navigateur.
  • Rotation immédiate de toute clé qui a pu être exposée, même brièvement : révoquez-la et régénérez-en une nouvelle, ne vous contentez pas de la retirer du code.
  • Revue humaine du code généré par l'IA avant mise en production, en particulier sur les formulaires, l'authentification et les accès aux données.
  • HTTPS sur l'intégralité du site, sans exception, y compris les sous-domaines et les environnements de test.
  • Permissions limitées au strict nécessaire pour chaque clé, chaque compte de service, chaque accès base de données — le principe du moindre privilège.
  • Jamais de secret dans un prompt envoyé à une IA publique : mots de passe, clés, données personnelles ou informations clients restent en dehors des conversations.
  • Conformité RGPD vérifiée dès la conception : quelles données sont collectées, où sont-elles hébergées, combien de temps sont-elles conservées.

Ces réflexes s'appliquent à tous les projets, qu'ils soient sous WordPress, un autre CMS ou un développement sur mesure — voir notre article sur la cybersécurité WordPress, CMS et projets maison. Si votre site est déjà en ligne, un audit de sécurité serveur permet de vérifier concrètement ce qui a été oublié. Et pour garder cette vigilance dans la durée, notre offre de maintenance & infogérance inclut la surveillance et la mise à jour continue de vos composants.

Votre site créé (ou modifié) avec l'IA a-t-il des failles ?

Notre audit de sécurité vérifie précisément ce que l'IA a laissé passer : clés API exposées, en-têtes de sécurité manquants, vulnérabilités connues sur vos dépendances, configuration serveur, conformité RGPD. Vous repartez avec la liste exacte de ce qui doit être corrigé — et dans quel ordre.

Demander mon audit de sécurité gratuit

FAQ

Un site fait avec l'IA est-il moins sûr qu'un site codé classiquement ?

Pas intrinsèquement : le code généré par l'IA n'est ni plus ni moins sûr par nature, il reflète simplement ce qui a été demandé. Le problème vient de la vitesse : on met en production du code jamais relu, avec des réglages par défaut trop permissifs et des dépendances non vérifiées. Une relecture humaine et un audit avant mise en ligne suffisent à corriger la majorité des risques.

Comment savoir si ma clé API a fuité ?

Vérifiez le code source de vos pages (Ctrl+U dans le navigateur) à la recherche de chaînes ressemblant à des clés, cherchez votre nom de domaine ou vos identifiants sur GitHub, et surveillez vos factures et tableaux d'usage chez chaque fournisseur d'API pour repérer une consommation anormale. En cas de doute, révoquez et régénérez la clé : c'est la seule vérification vraiment fiable.

Mes conversations avec ChatGPT sont-elles publiques ?

Pas par défaut, mais dès que vous utilisez une fonction de partage de lien, ce lien peut être indexé par les moteurs de recherche : c'est arrivé à des milliers de conversations ChatGPT partagées, retrouvées sur Google. Ne partagez jamais un lien de conversation contenant des données sensibles, et vérifiez les réglages de confidentialité de l'outil IA que vous utilisez.

Que faire si j'ai exposé une clé API par erreur ?

Révoquez immédiatement la clé chez le fournisseur et régénérez-en une nouvelle : retirer la clé du code ne suffit pas, elle peut rester visible dans l'historique Git ou avoir déjà été copiée. Vérifiez ensuite les journaux d'usage pour détecter un abus, et retirez toute trace de la clé de vos dépôts, y compris dans les anciens commits.

Que contient l'audit de sécurité de Webee Solutions ?

L'audit vérifie les clés et secrets exposés côté client ou dans le code source, les en-têtes de sécurité HTTP, les vulnérabilités connues sur vos dépendances et votre CMS, la configuration serveur et HTTPS, et votre conformité RGPD. Vous recevez un rapport clair avec les failles trouvées et un plan d'action priorisé.