Votre site a été créé par une IA en trois jours. Qui a vérifié ce qu'il expose ?

Le vibecoding, en deux phrases

Vous décrivez ce que vous voulez, en français, dans une fenêtre de discussion. L'intelligence artificielle écrit l'application, la met en page, la connecte à une base de données, et vous obtenez un site en ligne. On appelle cela le vibecoding, et cela fonctionne réellement.

Des dirigeants qui n'ont jamais écrit une ligne de code lancent aujourd'hui un site vitrine en un week-end. Des services métier créent leur propre outil de suivi sans passer par l'informatique. Des startups sortent un premier produit en quelques jours au lieu de quelques mois.

Ce n'est ni une mode passagère ni un problème en soi. C'est même une bonne nouvelle pour la vitesse. Le problème est ailleurs, et il est plus subtil qu'on ne le croit.

Le code fonctionne, et c'est exactement ce qui trompe

Quand une IA produit une application, le résultat s'affiche correctement, le formulaire envoie bien les messages, le paiement passe. Tout ce que vous pouvez observer fonctionne.

Ce que vous ne pouvez pas observer, c'est le reste. Que le mot de passe de la base de données soit écrit en clair dans un fichier accessible depuis internet ne se voit pas. Qu'un espace d'administration soit ouvert sans authentification ne se voit pas non plus, tant que personne ne tape la bonne adresse. Qu'un composant utilisé par l'application ait une faille publiée depuis dix-huit mois ne change rien à l'apparence du site.

Le plus instructif est ailleurs. Ce taux est identique à celui mesuré par la même équipe en juillet 2025, malgré deux générations de modèles entre-temps. Les IA sont devenues bien meilleures pour écrire du code qui marche, avec plus de 95 % de production syntaxiquement correcte. Elles ne sont pas devenues meilleures pour écrire du code sûr.

Le détail de l'étude est encore plus parlant. Sur les injections de base de données, une faille célèbre depuis vingt ans, le code généré passe les tests dans 82 % des cas. Sur les failles d'affichage, celles qui permettent d'injecter du contenu piégé dans une page vue par vos visiteurs, il ne passe que dans 15 % des cas. Sur la journalisation, 13 %. Autrement dit, l'IA a bien appris les risques dont tout le monde parle, et pas ceux qui ne font pas les gros titres.

Le langage compte aussi. Le code Python généré passe les tests de sécurité dans 62 % des cas, le JavaScript dans 57 %, et le Java dans 29 % seulement. Vous n'avez pas à retenir ces chiffres. Retenez la conclusion : la qualité de sécurité varie fortement selon la technologie choisie, et personne ne vous le dira au moment de lancer le projet.

Ce que l'IA oublie presque systématiquement

Vous n'avez pas besoin de comprendre techniquement ces points. Il suffit de savoir qu'ils existent, et qu'ils ne se voient pas.

Trois situations que nous rencontrons

Le point commun de ces trois cas n'est pas la négligence. C'est l'absence de moment de contrôle. Quand un projet passe par une équipe technique, il y a une mise en production, donc une occasion de vérifier. Quand il sort d'une fenêtre de discussion, ce moment n'existe pas.

Qui est responsable si ça tourne mal ?

C'est la question que les dirigeants posent en dernier, et c'est souvent celle qui déclenche la décision.

Sur les données personnelles, la réponse est écrite dans le RGPD. Le responsable de traitement, c'est l'entreprise qui décide pourquoi et comment les données sont collectées. Ni l'outil d'intelligence artificielle, ni l'hébergeur, ni le prestataire qui a cliqué sur le bouton. Si un formulaire de votre site expose des candidatures, c'est votre nom qui figure sur la notification à la CNIL.

La bonne nouvelle est que cette responsabilité se gère avec très peu de choses : savoir quelles applications existent, savoir ce qu'elles exposent, et pouvoir le montrer.

Vous n'avez pas à juger le code

C'est le point où beaucoup de dirigeants se sentent démunis, et où ils ont tort de l'être.

Vous ne savez pas lire du code. Personne ne vous demande de l'apprendre. Vous ne savez probablement pas non plus démonter un système de freinage, et cela ne vous empêche pas de faire passer le contrôle technique à votre véhicule. Le principe est le même : un tiers regarde, selon une méthode connue, et vous remet un compte rendu compréhensible.

Pour une application web, ce contrôle s'appelle un examen depuis l'extérieur. On regarde ce que votre site expose comme le ferait quelqu'un de mal intentionné : quels fichiers sont accessibles, quelles pages d'administration répondent, quels composants sont dépassés, comment les données circulent, ce que révèlent les messages d'erreur.

Cinq questions à poser avant de mettre en ligne

Que le site soit produit par une IA, par un prestataire ou par votre équipe, ces cinq questions font le tri. Posez-les, et écoutez la précision des réponses autant que leur contenu.

• Où sont stockés les mots de passe et les clés d'accès ? La bonne réponse mentionne des variables d'environnement ou un coffre-fort de secrets. Une réponse floue est déjà une réponse.
• Qui peut accéder à l'espace d'administration, et comment ? Il doit exister une liste de personnes, une authentification à deux facteurs, et une procédure quand quelqu'un part.
• Quelles données personnelles sont collectées, où sont-elles hébergées, combien de temps sont-elles conservées ? Question RGPD, et question de bon sens.
• Qui met à jour les composants, et à quelle fréquence ? S'il n'y a ni nom ni rythme, la réponse est personne et jamais.
• Que se passe-t-il si le site tombe ou si les données sont perdues ? Une sauvegarde jamais restaurée n'est pas une sauvegarde.

Ce que ça change pour vos projets

Le vibecoding ne supprime pas le besoin de contrôle. Il le déplace.

Avant, la lenteur du développement laissait naturellement du temps pour les revues, les tests, les mises en production planifiées. Aujourd'hui, une idée devient une application en ligne dans la même journée. Le contrôle doit donc devenir un geste volontaire, court, systématique.

Une deuxième règle, encore plus simple, évite la majorité des mauvaises surprises : tenez la liste de vos applications en ligne. Une ligne par application, avec son adresse, la personne qui l'a créée, les données qu'elle contient et la date du dernier contrôle. Un tableur suffit. Ce document de dix lignes est souvent le premier livrable utile d'une démarche de sécurité, et c'est aussi le premier que vous demandera un auditeur.

Loin de freiner la vitesse, c'est ce qui permet d'aller vite sans découvrir six mois plus tard qu'on a construit sur du sable.

Où en est votre site aujourd'hui ?

Si votre site ou votre application a été produit rapidement, avec ou sans IA, la question n'est pas de savoir si le travail était bien fait. C'est de savoir ce qu'il expose aujourd'hui, en ligne, à cet instant.

C'est une réponse qui s'obtient en quelques minutes, et qui vaut mieux que l'intuition. Sortez du flou.