Le vibe coding est-il sûr ? Les vrais risques et ce qu'il faut vérifier avant de publier

Le vibe coding est sûr pour les outils personnels et les prototypes, et il peut l'être pour de vraies applications avec de vrais utilisateurs, à condition d'ajouter les contrôles que le « décrivez-le et voyez si ça marche » laisse de côté. Les problèmes dangereux sont invisibles à l'écran : des utilisateurs qui peuvent ouvrir les données des autres, des clés secrètes présentes dans le navigateur, des formulaires publics sans limite. Ce guide explique les risques qui causent réellement des problèmes, la gestion des secrets, le niveau de relecture nécessaire, et un contrôle de 30 minutes à effectuer avant de publier.

Pour la liste technique complète, consultez notre liste de contrôle de sécurité pour les applications construites avec l'IA. Cette page est la version courte et pratique, destinée aux personnes qui ne lisent pas le code.

Pourquoi le vibe coding a ses propres risques

En vibe coding, vous jugez l'application en l'utilisant. Cela permet de repérer les boutons cassés et les mises en page laides. Cela ne permet pas de voir les problèmes qui n'apparaissent que lorsqu'une personne utilise l'application différemment de vous : un inconnu, un robot, un utilisateur curieux qui modifie une adresse web.

Les modèles d'IA écrivent du code plausible, et la plupart est correct. Mais ils optimisent ce que vous avez demandé — « fais afficher mes projets dans le tableau de bord » — et peuvent ne pas ajouter la protection que vous n'avez pas demandée — « et seulement les miens ». La solution n'est pas d'arrêter le vibe coding. Elle consiste à demander explicitement ces protections, puis à les tester.

Quel est le niveau de risque de votre application ? Une échelle rapide

Soyez honnête sur la ligne qui vous correspond. Beaucoup d'applications commencent dans la première ligne et glissent vers la troisième sans que personne ne l'ait décidé.

Les risques qui causent réellement des problèmes

1. Les utilisateurs peuvent voir les données des autres

C'est le problème sérieux le plus fréquent dans les applications construites avec l'IA. La page n'affiche à chaque utilisateur que ses propres enregistrements, donc tout semble correct. Mais le serveur renverra n'importe quel enregistrement si quelqu'un modifie l'identifiant dans la barre d'adresse ou dans une requête. Comme vous testez toujours en tant que vous-même, vous ne le voyez jamais.

Comment vérifier : créez deux comptes. Connectez-vous avec l'utilisateur A, ouvrez un enregistrement de A et notez l'adresse. Connectez-vous avec l'utilisateur B dans une fenêtre privée et collez cette adresse. Vous devez voir « introuvable », jamais les données de A.

Prompt :

Vérifie chaque point d'accès côté serveur qui lit, modifie ou supprime des données utilisateur. Chacun doit confirmer que l'utilisateur connecté a le droit d'accéder à cet enregistrement précis. Liste les points d'accès, indique comment chacun effectue cette vérification, et corrige ceux qui ne la font pas.

2. Des secrets au mauvais endroit

Un secret est tout ce qui donne accès : une clé d'API pour un service d'IA ou d'e-mail, un mot de passe de base de données, une clé secrète d'un prestataire de paiement. S'il se trouve dans du code exécuté dans le navigateur, n'importe qui peut ouvrir les outils de développement et le copier. S'il est versionné dans un dépôt public, des robots le trouvent en quelques heures.

Comment vérifier : demandez à l'IA.

Liste chaque clé d'API, jeton et mot de passe utilisé par cette application. Pour chacun, indique où il est stocké et s'il est déjà envoyé au navigateur. Déplace vers des secrets côté serveur ceux qui se trouvent dans le code ou côté interface.

3. Des formulaires et des points d'accès publics sans limite

Les formulaires de contact, les inscriptions et les fonctions d'IA sont repérés par des robots. Sans limites, vous obtenez du spam, de faux comptes, ou une facture importante car une API d'IA est appelée des milliers de fois.

Prompt :

Ajoute des limites de requêtes à l'inscription, à la connexion, au formulaire de contact et à chaque point d'accès qui appelle un service d'IA. Ajoute un champ piège (honeypot) aux formulaires publics. Indique-moi les limites que tu as choisies.

4. Faire confiance au navigateur

Tout ce que décide le navigateur peut être modifié par l'utilisateur : prix, remises, réponses à un quiz, indicateurs « est administrateur ». Les règles importantes doivent être appliquées côté serveur.

Prompt :

Repère chaque endroit où le navigateur décide quelque chose qui devrait relever du serveur : prix, totaux, droits, rôles, scores. Déplace ces contrôles côté serveur.

5. Pas de retour possible

Une mauvaise modification, ou une personne malveillante, peut supprimer des données. Sans sauvegarde ni moyen de revenir en arrière, une petite erreur devient définitive. Assurez-vous que votre outil propose des points de sauvegarde pour le code et des sauvegardes pour la base de données. Voir comment sauvegarder la base de données de votre application.

Bien gérer les secrets

Les secrets causent plus de dégâts évitables que tout le reste. Voici les règles réunies :

• Ne collez jamais une vraie clé dans le chat. Les conversations sont conservées, partagées et capturées en image. Placez les clés dans les secrets ou les variables d'environnement de votre outil. (Ce que sont les variables d'environnement et les secrets.)
• Appelez les services payants depuis le serveur. Le navigateur demande à votre serveur ; votre serveur appelle le service d'IA ou de paiement avec la clé.
• Utilisez des clés distinctes pour les tests et la production, pour qu'une clé de test divulguée ne puisse rien toucher de réel.
• Fixez des plafonds de dépenses dans les tableaux de bord des fournisseurs d'IA et d'e-mail.
• Changez une clé immédiatement si vous pensez qu'elle a fuité. Créez-en une nouvelle, mettez à jour le secret, puis supprimez l'ancienne.

Sur Mythex, les secrets sont stockés dans les paramètres du projet, hors du code, et l'agent peut les utiliser sans que leurs valeurs n'apparaissent dans le chat. Notre guide sur la protection des clés d'API couvre davantage de fournisseurs.

Quel niveau de relecture du code faut-il ?

Le vibe coding signifie que vous ne lisez pas chaque ligne. Vous n'en avez pas besoin. Mais pour certaines lignes, quelqu'un doit le faire.

• Outils personnels : rien de plus que les contrôles décrits ici.
• Applications avec comptes utilisateurs : relisez le fonctionnement de la connexion et des accès aux données. Vous pouvez le faire en demandant à l'IA de l'expliquer simplement et en vérifiant que l'explication correspond à ce que vous attendez.
• Applications avec paiements ou données sensibles : faites examiner l'authentification, les droits, la gestion des paiements et tout ce qui stocke des données personnelles par un développeur. Cela représente quelques heures de son temps, pas une réécriture.

Un prompt utile, même sans développeur :

Explique-moi simplement comment cette application détermine qui est l'utilisateur et ce qu'il a le droit de voir. Indique les fichiers concernés. Liste ensuite ce qu'un relecteur de sécurité devrait examiner.

Notre guide sur comment relire du code généré par l'IA explique ce que regardent les relecteurs, et vous pouvez le transmettre à la personne qui fera la relecture. Si votre outil permet d'exporter le code ou de le synchroniser avec GitHub, organiser cette relecture est facile ; sur Mythex, les deux font partie de l'offre Pro.

Le contrôle de 30 minutes avant publication

Effectuez-le avant de partager le lien avec des personnes extérieures à votre cercle.

Accès (10 minutes)

1. Deux comptes, deux navigateurs : le compte B peut-il ouvrir les fiches de A en tapant l'adresse ? Il ne le doit pas.
2. Déconnectez-vous et visitez directement l'adresse de chaque page. Les pages privées doivent vous renvoyer vers la connexion.
3. En tant qu'utilisateur normal, essayez d'ouvrir les adresses d'administration. Elles doivent être refusées.

Secrets (5 minutes)

1. Demandez à l'IA où se trouve chaque clé, avec le prompt ci-dessus.
2. Ouvrez l'application, affichez le code source de la page et recherchez « key », « secret » et « token ».

Formulaires et abus (5 minutes)

1. Envoyez chaque formulaire vide, avec un texte très long, et deux fois de suite rapidement.
2. Vérifiez que des limites de requêtes existent sur l'inscription, la connexion et toute fonction d'IA.

Données et récupération (5 minutes)

1. Sachez où se trouvent les données et comment les restaurer.
2. Vérifiez que vous pouvez revenir à une version du code qui fonctionnait.

Aspects juridiques et bases (5 minutes)

1. Si vous collectez des données personnelles, ajoutez une politique de confidentialité et indiquez ce que vous collectez. Voir comment rédiger des conditions d'utilisation et une politique de confidentialité.
2. Vérifiez que l'application publiée utilise HTTPS. La plupart des créateurs, Mythex compris, s'en chargent pour vous.

Si tout est validé, vous êtes bien préparé pour un lancement précoce. Répétez les étapes 1 à 5 après chaque changement important touchant à la connexion, aux rôles ou aux données.

Ce que les plateformes de vibe coding protègent et ne protègent pas

Une bonne plateforme prend en charge une grande partie de l'infrastructure : HTTPS, espaces de travail isolés, une base de données par projet, stockage des secrets, sauvegardes et retour arrière. Mythex donne à chaque projet son propre espace de travail privé et sa base de données, garde les secrets hors du code et enregistre un point de sauvegarde après chaque modification réussie, pour que vous puissiez l'annuler.

Ce qu'aucune plateforme ne peut faire, c'est connaître les règles de votre application. Vous seul savez que les clients ne doivent pas voir les factures des autres, ou qu'un code promo ne doit fonctionner qu'une fois. Ces règles doivent figurer dans vos prompts et être confirmées par vos tests.

La réponse courte

Le vibe coding est aussi sûr que les contrôles que vous ajoutez. Pour un outil personnel, gardez les clés hors du code et profitez-en. Pour tout ce qui contient les données d'autres personnes, effectuez le contrôle de 30 minutes ci-dessus avant chaque lancement, et faites examiner par un développeur les paiements et les données sensibles. Pour voir ces risques dans de vrais projets, lisez nos exemples de vibe coding ; pour construire avec ces contrôles dès le départ, suivez comment construire une application avec le vibe coding.

Questions