Peut-on lancer sans risque une application vibe-codée ? La checklist de mise en production

Oui, avec une réserve qui décide de l'essentiel de la réponse : tout dépend de qui déploie le code. Un assistant IA qui vous remet un dossier de fichiers vous laisse la charge des serveurs, des secrets et du pipeline de déploiement. Une plateforme qui construit et exécute l'application sur une infrastructure gérée écarte plusieurs de ces risques avant même que vous n'écriviez quoi que ce soit. Cette checklist sépare les deux, pour que vos vingt minutes de relecture portent sur les parties qui vous appartiennent vraiment.

Est-ce que l'IA qui l'a construite change quelque chose ?

Plus que n'importe quel autre facteur. Le rapport 2026 de GitGuardian a relevé un taux de fuite de secrets de 3,2 % dans les commits assistés par IA, contre une référence de 1,5 % sur l'ensemble des commits publics GitHub, soit environ le double. Lisez ce chiffre attentivement, car il mesure des assistants de code : des développeurs qui génèrent du code dans leur propre dépôt et le déploient eux-mêmes. C'est un constat sur une manière de travailler, pas sur l'IA en tant que telle. Changez la manière de travailler et le chiffre change avec elle, puisqu'une plateforme qui ne vous remet jamais une clé brute à égarer supprime l'occasion au lieu de vous rappeler d'être prudent.

Le code généré par IA est-il sécurisé par défaut ?

Non, et aucune plateforme honnête ne vous dira le contraire. L'IA écrit du code plausible, pas nécessairement du code sûr. Elle peut sauter une validation, exposer des données qui devraient rester privées, coder en dur un identifiant pour faire marcher une fonctionnalité, ou importer un paquet qui n'existe pas. Traitez le résultat comme le premier jet d'un développeur junior rapide mais livré à lui-même : souvent bon, parfois dangereux, toujours à relire.

Pourquoi l'IA se trompe-t-elle si souvent sur la sécurité ?

Parce que les défaillances de sécurité sont invisibles à l'exécution. Un modèle optimise pour du code qui marche, et « marche » veut dire que la fonctionnalité s'exécute quand vous cliquez. Un contrôle de permission manquant ne lève aucune erreur, il renvoie tranquillement les données. Un mot de passe stocké en clair permet de se connecter parfaitement. Votre application peut passer tous les tests auxquels vous avez pensé et rester ouverte, et c'est pour cela qu'il s'agit d'une étape de relecture plutôt que d'une étape de test.

Quels risques une plateforme gérée supprime-t-elle ?

Construisez sur une infrastructure que vous configurez vous-même et chacun des risques de cette page vous revient. Construisez sur une plateforme gérée et plusieurs d'entre eux cessent d'exister, parce qu'il ne reste nulle part où loger l'erreur.

• Le stockage des secrets. Des clés conservées dans un coffre chiffré et injectées à l'exécution ne traînent jamais dans votre code en attendant d'être commitées. Modulify fonctionne ainsi, et c'est le réglage par défaut le plus précieux de tous, puisque les secrets divulgués sont de loin la défaillance la plus fréquente.
• L'hébergement et le HTTPS. Aucun serveur à durcir, aucun certificat à oublier, aucune machine de préproduction à moitié configurée qui sert discrètement de vraies données. Modulify inclut l'hébergement, donc publier ne veut pas dire configurer une infrastructure.
• L'accès à la base de données. Une base gérée interrogée à travers la plateforme utilise des requêtes paramétrées par défaut, ce qui ferme la porte à l'injection SQL sans que vous ayez à auditer chaque requête.
• Le pipeline de déploiement. Rien à mal configurer quand vous appuyez sur publier au lieu de câbler un déploiement.

Cela ne revient pas à dire que votre application est sécurisée, et méfiez-vous de quiconque l'affirme. Cela veut dire qu'il y a moins d'endroits où se tromper, ce qui rend ceux qui restent dignes d'une vraie attention.

Quels risques restent les vôtres ?

Ceux-ci reviennent à celui qui a construit l'application, sur n'importe quelle plateforme, que le code ait été écrit par un humain ou par une IA. Voici la liste qui vaut vingt minutes.

1. Les accès sont vérifiés côté serveur. Chaque requête qui renvoie des données privées revérifie qui la demande. Testez-le : connectez-vous en tant qu'un utilisateur et remplacez l'identifiant d'enregistrement dans l'URL par celui d'un autre utilisateur. Si ses données s'affichent, vous avez la vulnérabilité d'application web la plus répandue qui soit. Masquer un bouton n'est pas de la sécurité.
2. Les entrées sont validées côté serveur. La validation côté client est un confort pour l'utilisateur, pas une défense. N'importe qui peut envoyer une requête qui contourne entièrement votre formulaire.
3. Les sessions vivent dans des cookies HTTP-only. Pas dans le stockage local du navigateur, où n'importe quel script de la page peut les lire et transformer un petit bug de scripting en prise de contrôle complète du compte.
4. Les mots de passe sont hachés. Si votre application stocke elle-même les mots de passe, utilisez bcrypt ou argon2 et rien de maison. Si vous pouvez lire le mot de passe d'un utilisateur dans votre base de données, quiconque en obtient une copie le peut aussi.
5. Les erreurs ne divulguent pas de détails. Les utilisateurs voient un message clair. Les traces d'exécution, les chemins de fichiers et les erreurs de base de données restent dans vos journaux, parce qu'ils sont un plan de votre application pour qui la sonde.
6. Tout ce qui a déjà été exposé est renouvelé. Un coffre protège les clés à partir de maintenant, il ne peut pas rappeler celle que vous avez collée dans une conversation le mois dernier. Le même rapport a constaté que plus de 64 % des identifiants confirmés valides en 2022 l'étaient encore en 2026 : une exposition n'expire pas d'elle-même.
7. Le code et les paquets ajoutés sont vérifiés. Dès l'instant où vous ajoutez votre propre code ou intégrez une bibliothèque, c'est de nouveau à vous de le relire. Vérifiez que chaque paquet existe réellement et qu'il est maintenu.

Que voit réellement le navigateur ?

Tout ce que vous lui envoyez, ce qui prend constamment les gens au dépourvu dans les applications web, parce que la frontière entre votre code et le public n'est pas là où on l'imagine. Toute clé utilisée dans du JavaScript côté client est visible par quiconque ouvre les outils de développement : un appel à une API payante a donc sa place côté serveur, avec la clé conservée là-bas. Servez l'application entière en HTTPS, pas seulement la page de connexion. Et si vous avez élargi le partage cross-origin pour faire marcher quelque chose pendant la construction, resserrez-le avant le lancement, car sur un endpoint authentifié cela invite d'autres sites à envoyer des requêtes au nom de vos utilisateurs connectés.

Quelles fonctionnalités font le plus monter les enjeux ?

Trois, et chacune mérite une attention supplémentaire parce que chacune tend un levier à un inconnu.

• Les envois de fichiers. Validez le type et la taille, gardez les fichiers dans un stockage objet plutôt qu'à côté de votre code, et ne faites jamais confiance au nom de fichier qu'on vous donne.
• Les paiements. Confiez les données de carte à un prestataire de paiement et laissez-le les conserver. Votre application ne devrait jamais voir un numéro de carte.
• Tout ce qui envoie des e-mails. Appliquez une limitation de débit, sinon un formulaire de contact ouvert devient un relais de spam avec la réputation de votre domaine en jeu.

Qu'est-ce que le slopsquatting et faut-il s'en inquiéter ?

Le slopsquatting, c'est quand des attaquants publient des paquets malveillants sous des noms que les modèles d'IA ont tendance à halluciner, en attendant que quelqu'un en installe un sur la recommandation d'un assistant. Si votre application intègre un paquet suggéré par l'IA, vérifiez qu'il est réel, largement utilisé et maintenu avant de lui faire confiance. Trente secondes de vérification évitent une compromission de la chaîne d'approvisionnement très difficile à démêler ensuite.

Ai-je besoin d'une revue de sécurité pour un site simple ?

Un site vitrine sans comptes ni données présente un risque faible. Lancez-vous. Dès l'instant où vous ajoutez des connexions, des paiements, des envois de fichiers ou des données personnelles, déroulez la liste. Le risque dépend de ce que l'application peut atteindre, pas de la façon dont elle a été construite. Une application écrite à la main avec un contrôle de permission manquant est exactement aussi exposée qu'une application écrite par une IA.

À quelle fréquence faut-il repasser cette liste ?

À chaque fois que vous ajoutez quelque chose qui touche aux données, pas une seule fois avant le lancement. Construire de cette manière rend les changements peu coûteux, ce qui veut dire que la forme de votre application évolue plus vite que l'idée que vous vous en faites. La liste est courte exprès, pour que la relancer reste réaliste.

Le point de vue de Modulify

La question utile n'a jamais été de savoir si l'on peut confier l'écriture du code à une IA. Elle est de savoir quels risques votre configuration supprime et lesquels elle vous laisse. Des secrets, un hébergement et des bases de données gérés effacent toute une catégorie d'erreurs avant même que vous commenciez, et Modulify est conçu ainsi délibérément. Ce qu'aucune plateforme ne peut faire, c'est décider qui devrait avoir le droit de voir tel enregistrement : cette partie-là reste une courte revue que vous menez vous-même. Pour le contexte plus large, commencez par ce qu'est réellement le vibe coding, puis associez ceci à Du prototype à la production. Construisez sur une plateforme aux réglages par défaut sécurisés.