IA qui génère du code : ce qui marche, ce qui casse
Lovable, Bolt, v0, Replit Agent, Cursor Composer : depuis 2024, une nouvelle génération d'outils permet à n'importe qui de générer une application web fonctionnelle en quelques heures. Le marketing parle de "vibe coding" et promet de rendre le développement accessible à tous.
Il y a du vrai. Ces outils sont impressionnants et ont leur place dans le paysage 2026. Il y a aussi un décalage entre ce qu'ils livrent et ce qu'un projet d'entreprise attend : sécurité, conformité, fiabilité, maintenabilité. Ce guide fait le point sur ce qu'ils font bien, où ils lâchent, et pourquoi les experts n'ont jamais été aussi indispensables.
Ce que ces outils font vraiment bien
Avant les critiques, la reconnaissance. Ces outils changent réellement certains usages et on les utilise nous-mêmes quand le contexte s'y prête.
Prototypage rapide
Une idée d'application à montrer à un investisseur, à tester auprès de 10 utilisateurs, à valider avant d'engager un budget : Lovable ou Bolt livrent en 2 à 4 heures ce qui aurait pris 1 à 2 semaines à un développeur classique. Le gain est réel et assumable si on sait qu'on jettera le code après la validation.
Outils internes sans enjeu critique
Un formulaire de collecte, un tableau de bord interne, un convertisseur, un outil RH utilisé par 20 personnes en interne. Les enjeux de sécurité sont limités, les données ne sortent pas, la tolérance à l'imperfection est élevée. Ce sont des cas où le temps gagné par l'IA compense largement la dette technique.
Squelette de projet pour développeur
Un développeur expérimenté peut utiliser Bolt ou Cursor pour générer un squelette de projet (structure, setup, dépendances), puis le retravailler à la main. Le gain de temps est modeste (10 à 25%) mais réel pour éviter le travail répétitif de configuration.
Exploration technique
Tester une nouvelle lib, explorer une intégration d'API, prototyper un algorithme : le cycle itératif avec une IA est plus rapide qu'avec la documentation seule. Nos équipes les utilisent quotidiennement dans ce cadre.
Là où ça casse : la sécurité
Ce n'est pas une opinion. Plusieurs études indépendantes ont quantifié les failles structurelles du code AI-généré. Les chiffres qui suivent viennent d'audits de sécurité menés par des chercheurs et des sociétés spécialisées en 2025 et début 2026.
(CVE-2025-48757, scan mai 2025)
(Veracode 2025)
(analyse Beesoul)
(The Register, fév. 2026)
CVE-2025-48757 : 170 applications Lovable exposées
Publié le 29 mai 2025 par le chercheur Matt Palmer après un cycle de divulgation coordonnée de 45 jours. Sur un échantillon de 1 645 applications Lovable mises en avant par la plateforme, 170 (environ 10%) exposaient des données sensibles d'utilisateurs : noms, emails, numéros de téléphone, informations de paiement, clés d'API de services IA payants, tokens Google Maps. Sur ces applications, 303 endpoints Supabase laissaient passer les requêtes sans vérification de permissions, parce que le module Row Level Security n'était pas correctement configuré.
45% du code AI-généré échoue aux tests de sécurité
Source : Veracode 2025 GenAI Code Security Report, plus grande étude systématique à ce jour sur le sujet. 100+ modèles testés sur 80 tâches de codage dans 4 langages (Java, JavaScript, Python, C#). 45% des échantillons de code introduisaient au moins une vulnérabilité du top 10 OWASP : cross-site scripting, clés d'API codées en dur, injections SQL, authentification sans vérification. En Java, le taux d'échec monte à 72%.
70% des apps Lovable shipées avec RLS désactivé
Le Row Level Security est le mécanisme qui, dans Supabase, empêche un utilisateur de lire ou modifier les données d'un autre. Il se configure manuellement, table par table. Selon une analyse de Beesoul sur des projets Lovable en production, environ 70% des applications ont au moins une table avec RLS désactivé. Une personne authentifiée peut alors accéder à toutes les données de toute la base via une requête simple.
Février 2026 : 18 697 utilisateurs exposés sur une seule app
Le chercheur Taimur Khan a analysé une application mise en avant sur la page Discover de Lovable et y a trouvé 16 vulnérabilités, dont 6 critiques. La fuite a concerné 18 697 enregistrements d'utilisateurs, incluant 14 928 adresses email uniques, des identifiants étudiants, des comptes entreprise, et plusieurs centaines d'identités complètes. Affaire rapportée par The Register le 27 février 2026. L'application était en production depuis plusieurs mois.
Pourquoi ça arrive
Les modèles de langage génèrent du code qui "ressemble" à du code correct, en moyenne. Sur les patterns de sécurité (RLS, CSRF, CORS, sanitization), ils sont statistiquement corrects mais structurellement naïfs. Ils ne raisonnent pas sur la surface d'attaque. Ils ne connaissent pas le contexte métier qui définit ce qui est sensible. Le code passe les tests fonctionnels, pas les tests de sécurité.
De plus en plus de clients nous sollicitent avec une application générée sur Lovable ou Bolt, à passer en production. On y retrouve systématiquement les mêmes failles : RLS absent, clés d'API exposées dans le frontend, aucun test automatisé. Le gain de temps initial se paie toujours à l'arrivée, et c'est nous qui sommes appelés pour corriger et sécuriser.
Adrien Weiser, directeur technique AdevWeb
Au-delà de la sécurité : les autres dettes invisibles
La sécurité est le problème le plus médiatisé, mais ce n'est pas le seul. Un code livré par IA arrive généralement sans plusieurs couches considérées comme standard dans un projet professionnel.
Conformité RGPD
Un site ou une application qui traite des données personnelles en Europe doit implémenter : un bandeau de consentement aux cookies, une politique de confidentialité conforme, un registre des traitements, des mécanismes de suppression de données (droit à l'oubli), une gestion des sous-traitants. L'IA ne génère rien de tout ça spontanément. Sur une app Lovable typique, zéro ligne de ces obligations est présente.
Accessibilité RGAA
Depuis juin 2025, les entreprises privées sont soumises à des obligations d'accessibilité numérique. Un code généré par IA ne respecte les 106 critères RGAA que par accident : contrastes insuffisants, labels absents, navigation clavier cassée, focus non visible, ARIA mal utilisé. Nous n'avons jamais vu un projet Lovable ou Bolt livré accessible RGAA sans une reprise manuelle substantielle.
Tests automatisés
Le code de production sérieux comporte des tests unitaires, des tests d'intégration, parfois des tests end-to-end. Ces tests sont ce qui permet de modifier le code sans casser les fonctionnalités existantes. Les AI code builders ne génèrent quasiment pas de tests. Sans tests, chaque évolution du code est une prise de risque.
Observabilité et monitoring
En production, on a besoin de savoir quand un service tombe, quand une requête prend 10 secondes, combien d'erreurs sortent par heure. Cela demande une configuration de logs structurés, de métriques, d'alertes. Ces couches ne sont pas générées par l'IA. Un incident sur une app Lovable qui n'a pas été instrumentée, c'est la découverte trois jours après par un client qui appelle.
Architecture et évolutivité
Un prompt génère du code qui marche pour le besoin décrit. Il ne pense pas à ce que deviendra l'application quand elle aura 10 000 utilisateurs au lieu de 10, quand il faudra ajouter un second langue, quand il faudra intégrer un CRM externe. Chaque ajout de fonctionnalité sur une base générée par IA ressemble à un Jenga : on ne sait pas si la prochaine brique fera tout tomber.
CI/CD et déploiement reproductible
Les plateformes comme Lovable hébergent directement l'application, mais sur leur infrastructure, dans un environnement peu contrôlable. Dès qu'il faut sortir de ce cadre (déployer chez soi, passer en HA, scaler horizontalement), on découvre qu'aucun pipeline de déploiement n'existe, que les variables d'environnement sont mal gérées, que les migrations de base de données ne sont pas versionnées.
Quand c'est OK d'utiliser ces outils
Une grille de décision honnête. Si tous les critères suivants sont vrais, y aller sans hésiter.
- Le projet est un prototype, un POC ou une démo jetable
- Aucune donnée personnelle sensible n'est traitée
- L'application n'est pas facturée ou critique pour des clients
- Le nombre d'utilisateurs final est limité (moins de 50 personnes)
- Le code peut être jeté dans 3 à 6 mois sans conséquence
- Aucun paiement ni intégration bancaire n'est impliqué
Si un seul de ces critères bascule, il faut un regard expert sur le code avant de mettre quoi que ce soit en production.
Quand il faut un expert avant la mise en ligne
Voici les scénarios où un code généré par IA sans revue d'expert représente un risque significatif : juridique, financier, réputationnel ou de sécurité.
- Le projet traite des données personnelles de clients ou utilisateurs
- Il y a des paiements, même via Stripe ou PayPal intégré
- L'application sera utilisée par le grand public ou par plus de 100 personnes
- Des identifiants ou mots de passe sont stockés
- Le projet doit être conforme RGAA ou RGPD
- Il y a des intégrations avec des systèmes tiers (CRM, ERP, API métier)
- La disponibilité du service est un enjeu business
- Le code devra évoluer pendant plusieurs années
- L'image de marque dépend de la fiabilité de l'application
Comment nous utilisons l'IA chez AdevWeb
L'IA fait partie de notre outillage quotidien depuis 2023. Nous ne sommes pas un collectif anti-IA. Nous sommes un collectif qui sait où l'IA accélère et où elle crée des risques.
Dans nos projets clients
On utilise Claude Code, Cursor, Copilot pour la génération de squelettes, la rédaction de tests, la documentation technique, le debugging initial. On estime que l'IA nous fait gagner 10 à 20% de temps sur la production, parfois plus sur les tâches répétitives. Le code passe systématiquement par une revue humaine et par nos standards de sécurité avant déploiement.
On ne prescrit pas ce qu'on ne contrôle pas
Nous n'utilisons pas Lovable, Bolt ou v0 pour produire du code client. Pas par dogmatisme, mais parce que notre responsabilité c'est de livrer du code qu'on comprend, qu'on sécurise et qu'on peut maintenir sur plusieurs années. En revanche, on audite et on reprend régulièrement du code issu de ces outils - c'est ce qui nous permet de connaître précisément leurs angles morts, et d'aider les clients qui ont démarré là-dessus.
Audit de code IA existant
De plus en plus de clients nous contactent avec une application déjà générée par Lovable ou Bolt qui doit passer en production. Notre prestation d'audit couvre : analyse des failles de sécurité (OWASP top 10), configuration RLS côté base, audit RGPD, mise en conformité RGAA, ajout de tests, migration vers une infrastructure maîtrisée. Budget typique : 3 000€ à 15 000€ selon le périmètre.
Développement sur base IA
Pour les projets où le client veut démarrer vite avec une base générée, on peut récupérer le code, en faire l'audit, et construire la vraie application par-dessus. C'est souvent plus économique qu'un développement from scratch. Budget typique : 10 000€ à 40 000€ selon la complexité.
Pour aller plus loin
Combien coûte un site internet en 2026
Fourchettes de prix réelles, ce qui fait vraiment le coût, et pourquoi la maintenance est le vrai sujet.
IA et automatisation pour PME
Cas concrets d'IA en production, ROI mesuré, et les 4 options de protection des données pour rester conforme.
Checklist accessibilité (RGAA + RAWeb)
Obligations RGAA et EAA depuis juin 2025, sanctions, points à vérifier. Ce qu'une app Lovable ne couvre jamais.
Choisir son prestataire web
Les questions à poser pour évaluer le sérieux technique d'un prestataire - y compris sur ses pratiques IA.
Questions fréquentes
Une app générée par IA à sécuriser ?
Parlons-en.
