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

Le vibe coding est sécuritaire pour les outils personnels et les prototypes, et il peut l'être pour de vraies applications avec de vrais utilisateurs, à condition d'ajouter les vérifications que « décrire ce qu'on veut et voir si ça marche » laisse de côté. Les problèmes dangereux ne se voient pas à l'écran : des utilisateurs qui peuvent ouvrir les données des autres, des clés secrètes qui traînent dans le navigateur, des formulaires publics sans limites. Ce guide explique les risques qui causent réellement des problèmes, la gestion des secrets, le niveau d'examen nécessaire et une vérification de 30 minutes à faire avant de publier.

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

Pourquoi le vibe coding comporte ses propres risques

Quand vous faites du vibe coding, vous jugez l'application en l'utilisant. Cela permet de repérer les boutons brisés et les mises en page laides. Mais cela ne détecte pas les problèmes qui n'apparaissent que lorsqu'une personne utilise l'application autrement que 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é — « faire 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. C'est de demander explicitement ces protections, puis de les tester.

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

Soyez honnête sur la ligne où vous vous situez. 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 grave le plus courant dans les applications créées par IA. La page n'affiche à chaque utilisateur que ses propres dossiers, donc tout semble correct. Mais le serveur renverra n'importe quel dossier si quelqu'un modifie l'identifiant dans la barre d'adresse ou dans une requête. Comme vous testez toujours en vous connectant comme vous-même, vous ne le voyez jamais.

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

Invite :

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 à ce dossier précis. Liste les points d'accès, explique comment chacun vérifie, et corrige ceux qui ne le font pas.

2. Des secrets au mauvais endroit

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

Comment vérifier : demandez-le à l'IA.

Liste chaque clé API, jeton et mot de passe que cette application utilise. Pour chacun, dis-moi 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 dans l'interface.

3. Formulaires publics et points d'accès sans limites

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

Invite :

Ajoute des limites de fréquence à 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 invisible aux formulaires publics. Dis-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, rabais, réponses à un questionnaire, indicateurs « est administrateur ». Les règles qui comptent doivent être appliquées sur le serveur.

Invite :

Trouve tous les endroits où le navigateur décide quelque chose que le serveur devrait décider : prix, totaux, permissions, rôles, pointages. Déplace ces vérifications vers le serveur.

5. Aucun moyen de revenir en arrière

Un mauvais changement, ou une personne malveillante, peut supprimer des données. Sans sauvegarde ni moyen de revenir en arrière, une petite erreur devient permanente. Assurez-vous que votre outil dispose de points de contrôle pour le code et de 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 dommages évitables que tout le reste. Voici donc les règles, réunies en un seul endroit :

• Ne collez jamais une vraie clé dans le clavardage. Les conversations sont conservées, partagées et capturées en image. Placez plutôt 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 pour la production, afin 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 de courriel.
• Changez une clé immédiatement si vous soupçonnez qu'elle a fuité. Créez-en une nouvelle, mettez à jour le secret, puis supprimez l'ancienne.

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

Quel niveau d'examen du code faut-il?

Le vibe coding signifie que vous ne lisez pas chaque ligne. Vous n'êtes pas obligé. Mais pour certaines lignes, quelqu'un devrait le faire.

• Outils personnels : rien de plus que les vérifications de cette page.
• Applications avec comptes d'utilisateurs : examinez le fonctionnement de la connexion et de l'accès aux données. Vous pouvez le faire en demandant à l'IA de l'expliquer en termes simples, puis en vérifiant que l'explication correspond à ce que vous attendez.
• Applications avec paiements ou données sensibles : faites examiner par un développeur l'authentification, les permissions, la gestion des paiements et tout ce qui stocke des données personnelles. C'est quelques heures de son temps, pas une réécriture.

Une invite utile, même sans développeur :

Explique-moi, en termes simples, comment cette application détermine qui est l'utilisateur et ce qu'il a le droit de voir. Indique les fichiers. Ensuite, liste ce qu'un examinateur de sécurité devrait regarder.

Notre guide sur comment examiner le code généré par IA explique ce que regardent les examinateurs, et vous pouvez le remettre à la personne qui fera l'examen. Si votre outil permet d'exporter le code ou de le synchroniser avec GitHub, organiser cet examen est facile; sur Mythex, les deux sont inclus dans le forfait Pro.

La vérification de 30 minutes avant publication

Faites-la avant de partager le lien avec quiconque en dehors de votre cercle.

Accès (10 minutes)

1. Deux comptes, deux navigateurs : le compte B peut-il ouvrir les dossiers de A par l'adresse? Il ne devrait pas le pouvoir.
2. Déconnectez-vous et visitez directement l'adresse de chaque page. Les pages privées devraient vous renvoyer à la connexion.
3. En tant qu'utilisateur ordinaire, essayez d'ouvrir les adresses d'administration. Elles devraient être refusées.

Secrets (5 minutes)

1. Demandez à l'IA où se trouve chaque clé, en utilisant l'invite 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. Soumettez chaque formulaire vide, avec un très long texte, et deux fois de suite rapidement.
2. Confirmez que des limites de fréquence existent pour 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 précédente fonctionnelle du code.

Juridique et bases (5 minutes)

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

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

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

Une bonne plateforme prend en charge beaucoup d'infrastructure : HTTPS, espaces de travail isolés, une base de données par projet, stockage des secrets, sauvegardes et retour en arrière. Mythex donne à chaque projet son propre espace de travail et sa propre base de données privés, garde les secrets hors du code et enregistre un point de contrôle après chaque changement réussi, afin 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 devraient pas voir les factures des autres, ou qu'un coupon ne devrait fonctionner qu'une fois. Ces règles doivent figurer dans vos invites et être confirmées par vos tests.

La réponse courte

Le vibe coding est aussi sécuritaire que les vérifications 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, faites la vérification de 30 minutes ci-dessus avant chaque lancement, et obtenez le regard d'un développeur pour 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 vérifications dès le départ, suivez comment créer une application par vibe coding.

Questions