Corrigez votre application vibe-codée et rendez-la prête pour de vrais utilisateurs

Une application vibe-codée est un logiciel écrit en grande partie par un modèle d'IA à partir d'instructions en langage naturel, où la personne qui la construit accepte le code généré sans le lire ni le relire en détail. La corriger signifie qu'un développeur relit ce code, le sécurise et le rend maintenable.

Les constructeurs d'IA excellent pour faire apparaître une idée à l'écran. Les ennuis commencent lorsque la démo rencontre de vrais utilisateurs : un paiement échoue en silence, un utilisateur voit les données de quelqu'un d'autre, l'application ralentit à mesure que la base de données grossit, ou chaque instruction qui corrige un bug en casse un autre. Rien de tout cela ne signifie que l'idée ou le travail ont été inutiles. La plupart des applications vibe-codées ont un cœur utilisable ; elles ont besoin d'un développeur expérimenté pour trouver ce que l'IA a mal fait, garder ce qu'elle a bien fait et poser les fondations manquantes en dessous.

Un modèle d'IA écrit du code qui satisfait l'instruction qu'il a sous les yeux. Si l'instruction demande un tableau de bord qui affiche les commandes, il affiche les commandes ; il demande rarement de lui-même de qui sont ces commandes, depuis quel appareil et ce qui se passe quand quelqu'un modifie la requête. La sécurité, la gestion des erreurs et les règles de données se trouvent dans les questions que personne n'a tapées.

Des recherches indépendantes vont dans le même sens. L'étude 2025 de Veracode portant sur plus de 100 modèles de langage a constaté que le code généré contenait une faille de sécurité dans 45 % des tâches de test, et que les modèles plus récents et plus grands n'étaient pas systématiquement plus sûrs. En 2025, un chercheur a aussi signalé que 170 applications de la vitrine publique d'un constructeur d'IA exposaient des tables de base de données parce que les règles d'accès n'avaient jamais été activées (CVE-2025-48757).

C'est un problème de relecture et non une raison d'arrêter d'utiliser l'IA. La solution est celle que les équipes ont toujours utilisée : quelqu'un qui comprend l'ensemble du système lit le code, le teste et met en place des garde-fous avant qu'il ne traite de vraies données.

Oui, et nous le recommandons généralement. Les outils d'IA sont productifs lorsqu'ils travaillent dans des garde-fous. Nous mettons en place un dépôt avec des branches et des pull requests, des tests automatisés exécutés à chaque modification, des variables d'environnement hors du code, et des fichiers de règles de projet pour Cursor ou Claude Code qui décrivent l'architecture, pour que les nouvelles instructions suivent la structure au lieu d'en inventer une nouvelle à chaque fois.

Si vous préférez, nous pouvons rester comme relecteurs : vous ou votre équipe continuez à donner des instructions, et nous relisons les changements avant qu'ils n'atteignent la production.