Est-il sûr de publier du code écrit par une IA ? Clés, fichiers .env et ce qui devient public

En bref

Chaque fichier que vous publiez peut être lu par toute personne qui peut ouvrir le site, et un code d’accès ne change pas ce qui y a sa place. Gardez les clés, les mots de passe et les données clients en dehors.
Pas de serveur ne veut pas dire pas de risque. Méfiez-vous des clés collées, des scripts extérieurs et du texte inséré avec innerHTML.
Si une clé fuite, révoquez-la d’abord. Supprimer le fichier ne suffit pas.

Ce qui devient public

C’est la règle à retenir. Quand vous publiez un site web, chaque fichier qu’il contient peut être téléchargé par toute personne qui connaît l’adresse. Cela inclut les fichiers vers lesquels aucune page ne renvoie. Cacher du code par « minification » ou « obfuscation » le rend plus difficile à lire, pas secret.

Type de fichier	Public ?	Exemple
HTML, CSS, JavaScript	Oui	Une clé d’API saisie dans `script.js`
Images, PDF, téléchargements	Oui	Un PDF de tarifs vers lequel aucune page ne renvoie
Fichiers de configuration	Oui	`config.json` avec un jeton à l’intérieur
Fichiers `.env`	Oui, s’ils sont envoyés	Des clés rangées à côté de votre projet
Source maps (`.map`)	Oui, s’ils sont envoyés	Des copies lisibles de votre code d’origine
Le dossier `.git`	Oui, s’ils sont envoyés	Un ancien historique contenant des clés « supprimées »
Des fichiers que vous n’avez pas publiés	Non	Notes, brouillons, le reste de votre projet

Où se cachent les clés secrètes

Les outils d’IA sont doués pour faire fonctionner les choses. Parfois, le plus rapide est de coller une clé directement dans le code. Cherchez ceci :

Des clés dans le JavaScript. Un widget de chatbot qui appelle un service d’IA directement depuis la page, avec la clé dans le code. N’importe qui peut copier cette clé et faire grimper votre facture.
Les fichiers .env. Les projets gardent leurs clés dans un fichier appelé .env. Il devrait rester sur votre ordinateur, mais il est envoyé si vous publiez tout le dossier du projet.
Les fichiers de configuration et de compilation. Les fichiers de paramètres, les source maps et les fichiers de test oubliés peuvent contenir des clés ou des chemins que vous ne vouliez pas partager.
Le dossier .git. Ce dossier caché contient tout l’historique de votre projet, y compris des clés « supprimées » il y a longtemps.

Les clés publiques ne posent pas de problème

Certaines clés sont conçues pour figurer dans une page web : une clé publique Stripe (pk_...), une clé de cartes limitée à votre domaine, un identifiant d’analyse. La documentation du service indique si une clé est sûre pour le navigateur. Si elle dit « secrète » ou « côté serveur uniquement », ou commence par sk_, elle ne doit jamais figurer dans votre site.

Si une fonctionnalité a besoin d’un secret

Si une fonctionnalité ne marche qu’avec une clé secrète, un simple site web ne peut pas le faire en toute sécurité tout seul. Vos options :

Utilisez un service conçu pour ça : un service de formulaires pour les formulaires de contact, un outil de réservation pour les rendez-vous, un paiement hébergé pour les paiements. Ils gardent les secrets pour vous.
Placez le secret derrière une petite fonction serveur, chez un hébergeur qui en propose, et faites appeler cette fonction par votre page.
Renoncez à la fonctionnalité pour l’instant. Un lien e-mail clair vaut mieux qu’une clé divulguée.

Demandez directement à votre IA : « Ce site contient-il des clés secrètes ? Si oui, comment faire sans mettre de secret dans le navigateur ? » Elle repère généralement le problème dès qu’on le lui demande.

Les scripts chargés depuis ailleurs

Beaucoup de pages créées par IA chargent des scripts d’autres sites : un chargeur de polices, un pack d’icônes, des statistiques, un widget de chat. Chacun s’exécute sur votre page avec tous les pouvoirs. Il peut lire ce que les visiteurs saisissent et changer ce qu’ils voient. Si cet autre site est piraté, votre page l’est aussi.

Utilisez-en moins. Demandez : « Cette page a-t-elle vraiment besoin de chaque script externe ? »
Figez la version. Utilisez library@1.2.3, pas « latest », pour que le fichier ne puisse pas changer sans que vous le sachiez.
Ajoutez un contrôle d’intégrité lorsque la bibliothèque en publie un. Le navigateur refuse alors un fichier qui a été modifié. Cela ressemble à ceci :

Script avec contrôle d’intégrité

<script src="https://cdn.example.com/lib@1.2.3/lib.min.js" integrity="sha384-..." crossorigin="anonymous"></script>

Vérifiez les widgets. Les widgets de statistiques, de chat et de réservation ajoutent souvent aussi des cookies et du suivi. Sachez ce que fait chacun et dites-le dans votre page de confidentialité.

Mettre du texte sur la page en toute sécurité

Si votre code prend du texte dans la barre d’adresse, un champ de formulaire ou chez un visiteur et le place sur la page avec innerHTML, un attaquant peut y glisser du code qui s’exécute dans le navigateur d’autres personnes. Cela s’appelle le cross-site scripting, ou XSS. La bonne habitude est d’insérer du texte brut avec textContent, qui ne s’exécute jamais comme du code.

Repérer la gestion risquée du texte

Find every use of innerHTML, document.write and eval in my site. For each one, say where the text comes from. If it can come from the URL, a form or a visitor, change it to use textContent instead. Tell me what you changed.

Un chatbot sur votre page

Un chat qui parle à une IA a besoin d’une clé pour appeler le service d’IA. Cette clé doit être sur un serveur, jamais dans votre page. Deux autres choses à savoir :

L’injection de prompt. Les visiteurs peuvent saisir des instructions destinées à tromper le bot pour qu’il ignore les vôtres. Vous ne pouvez pas l’empêcher complètement.
Limitez donc les dégâts. Ne donnez au bot ni secret ni action. S’il ne répond qu’à partir de textes publics, une astuce ne peut pas faire grand mal.

Formulaires et données personnelles

Ne collectez que le nécessaire. Un nom et un e-mail suffisent souvent. Chaque champ en plus est une chose de plus à protéger.
Dites où vont les données. Votre page de confidentialité doit dire qui reçoit les messages et pourquoi.
Ne créez pas votre propre stockage. Une simple page ne peut pas stocker des messages en toute sécurité. Utilisez un service de formulaires ou celui intégré à votre hébergeur.

Sur Page Lemon, demandez à votre IA « Ajoute un formulaire de contact à mon site ». Les messages vous sont envoyés par e-mail et conservés dans votre compte, sans service de formulaires séparé. Les formulaires sont inclus dans les forfaits payants. Voir Formulaires de contact.

Licences et exactitude

Vérifiez les licences. Les bibliothèques, polices, icônes et images venues de l’extérieur ont des conditions. Certaines exigent une mention, d’autres interdisent l’usage commercial. Demandez à votre IA de lister ce que vous utilisez et d’où cela vient.
Vérifiez les faits. L’IA peut inventer des prix, des avis et des affirmations. C’est vous qui les avez publiés.
Qui possède une œuvre écrite par une IA dépend du pays et n’est pas encore tranché. Ceci n’est pas un conseil juridique. Si cela compte, demandez à un professionnel.

Ce qu’il ne faut pas coller dans votre IA

Votre site est public, mais votre chat n’est pas censé l’être. N’y collez pas :

des listes de clients, des commandes ou des messages, sauf si vous savez comment votre service d’IA traite ces données ;
des mots de passe, des clés d’API ou des codes de connexion, car l’IA pourrait les écrire dans le site ;
tout ce que vous n’imprimeriez pas sur un prospectus.

Utilisez des noms fictifs et « example@example.com » pendant la création. Remplacez-les vous-même par les vraies coordonnées.

Une vérification de cinq minutes avant de partager le lien

Cochez ces points. Ou confiez la partie vérification à votre IA avec le prompt ci-dessous.

0 sur 6 faits

Publiez le résultat, pas le projet. S’il y a une étape de compilation, publiez le dossier qu’elle produit (souvent dist ou build). Sinon, créez un nouveau dossier avec seulement ce dont le site a besoin.
Cherchez les fichiers cachés. Sur Mac, appuyez sur Cmd+Maj+. dans le Finder ; sous Windows, activez « Éléments masqués ». Supprimez .env, .git et tout ce que vous ne reconnaissez pas.
Cherchez les clés. Cherchez dans le dossier key, secret, token et sk_. Vérifiez chaque résultat.
Listez les scripts extérieurs. Connaissez chaque script chargé depuis un autre site, et ne gardez que ceux dont vous avez besoin.
Voyez ce que voit un visiteur. à faire par vous Ouvrez le site publié, utilisez « Afficher la source » et parcourez les fichiers qu’il charge.
Vérifiez les données personnelles. à faire par vous Supprimez les données de test, les vrais noms de clients et les numéros de téléphone privés.

Audit en lecture seule

List every external script, key-like string, innerHTML use, form action and personal detail in my site, with the file and line for each. Don't change anything.

Quand tout est propre, parcourez la liste de contrôle de lancement du site.

Si une clé est devenue publique

Ce que fait Page Lemon pour vous aider

Les sites créés par IA sont souvent publiés par des personnes qui n’ont jamais eu à y penser, il y a donc quelques filets de sécurité :

Les fichiers .env, .git, node_modules, les source maps et les fichiers de clés privées sont ignorés et jamais servis.
Les envois sont contrôlés pour détecter les types connus de clés secrètes et de clés privées. Si l’une est trouvée, rien de cet envoi n’est publié, et on vous dit quel fichier et quelle ligne corriger.

Ces contrôles attrapent les erreurs courantes, pas tous les secrets. Choisir ce que vous publiez reste le meilleur moyen de protéger vos secrets. Plus de détails dans Sécurité et confiance et Publier un site.