Nous avons audité une application fintech « vibe-codée » — voici ce que nous avons trouvé

Pourquoi nous avons réalisé cet audit

Les outils d'IA comme Lovable ou Replit Agent permettent à des fondateurs non techniques de créer une application fonctionnelle en quelques jours au lieu de plusieurs mois. C'est réellement utile — mais dans le secteur fintech, « ça fonctionne » et « c'est sûr à lancer » sont deux exigences très différentes. Un fondateur nous a confié un MVP d'application de finance personnelle généré par IA, pour une revue avant son lancement en bêta. Ce que nous avons trouvé correspond à un schéma que nous observons désormais dans la majorité des produits fintech vibe-codés.

Ce que nous avons trouvé

Aucune protection CSRF. L'application ne disposait d'aucune protection contre les attaques de type Cross-Site Request Forgery sur les points d'entrée modifiant l'état des données — un attaquant aurait pu déclencher des actions au nom d'un utilisateur connecté, à son insu.

Absence d'en-têtes de sécurité. Des en-têtes standards comme Content-Security-Policy ou X-Frame-Options étaient absents, exposant l'application à des risques d'injection et de clickjacking.

Clés secrètes exposées côté client. Les clés API des fournisseurs de données financières tierces étaient intégrées directement dans le code frontend, visibles par quiconque ouvrait les outils de développement du navigateur.

Gestion de session fragile. Les jetons de session ne se renouvelaient pas lors des changements de privilèges, et aucun mécanisme n'invalidait les sessions après une réinitialisation de mot de passe — un contrôle basique mais essentiel pour toute application manipulant de l'argent.

Aucune validation des montants de transaction. Le backend faisait confiance aux valeurs envoyées par le client sans revalidation côté serveur — l'une des failles les plus courantes exploitées dans les applications financières.

Rien d'inhabituel pour du code généré par IA. Ce n'est pas que les outils soient mauvais : ils sont optimisés pour la rapidité et le bon fonctionnement, pas pour anticiper ce qu'un utilisateur malveillant pourrait tenter.

Ce que nous avons fait

Nous n'avons pas reconstruit l'application depuis zéro. La majeure partie de l'interface et de la logique métier générées par IA était de bonne qualité, et tout réécrire aurait annulé l'avantage de rapidité obtenu grâce au vibe coding. Nous avons plutôt :

Ajouté une validation côté serveur sur chaque point d'entrée lié aux transactions financières Implémenté des jetons CSRF et les en-têtes de sécurité appropriés Déplacé toutes les clés secrètes vers un environnement backend uniquement, avec une couche proxy pour les appels API tiers Reconstruit la gestion des sessions avec rotation et invalidation appropriées Réalisé un test d'intrusion complet avant validation finale

Le fondateur a respecté son calendrier initial. Il a simplement lancé un produit capable de résister au contact avec de vrais utilisateurs et de l'argent réel.

Une tendance plus large

Ce n'est pas un cas isolé. Des analyses récentes d'applications vibe-codées en production révèlent que la majorité présente de réelles failles de sécurité, notamment des secrets exposés et l'absence de protection CSRF, à des taux nettement supérieurs à ceux du développement traditionnel. Pour une simple application de liste de tâches, c'est un bug. Pour une application fintech, c'est une brèche en attente.

Si vous avez construit un MVP avec des outils d'IA et que vous vous apprêtez à gérer de vraies données utilisateur ou de l'argent réel, faites-le auditer avant le lancement. Cela représente une fraction du coût d'une faille de sécurité — et souvent même une fraction du coût de développement initial.