Application créée avec l’IA :
de la démo qui impressionne à l’outil qui tient en production
Votre application créée avec Lovable, Bolt, Cursor ou Replit fonctionne à l’écran. Reste à savoir si elle est prête pour de vrais utilisateurs : accès protégés, données sécurisées, code que quelqu’un sait reprendre. Mink, agence web et IA à Bordeaux, audite votre code, corrige ce qui doit l’être et le met en production, sans repartir de zéro quand ce n’est pas nécessaire.
Application créée avec l’IA ou vibe coding :
de quoi parle-t-on ?
On parle de vibe coding quand une application est générée à partir d’instructions en langage naturel, avec des outils comme Lovable, Bolt, Cursor, Replit ou v0. Le résultat s’obtient vite et se présente bien à l’écran. Ce qui se trouve dessous (droits d’accès, mots de passe, dépendances, tests) n’a souvent été ni pensé, ni vérifié.
Une étude Veracode publiée en juillet 2025 a testé plus de 100 modèles d’IA sur 80 tâches de code : 45 % des implémentations contenaient une faille de sécurité.
Un prototype généré par l’IA n’est donc pas une application prête pour la production. C’est un très bon point de départ, à condition de savoir ce qu’il contient.
Prototype généré ou application en production :
quelle différence ?
Un prototype montre que l’idée fonctionne. Une application en production doit tenir face à de vrais utilisateurs et de vraies données.
Droits d’accès
Masqués dans l’interface
Mots de passe et clés
Parfois laissés dans le code
Bibliothèques utilisées
Ajoutées sans contrôle
Données personnelles (RGPD)
Non traitées
Tests
Aucun
Sauvegardes et suivi
Absents
Reprise par une équipe
Code peu lisible, difficile à reprendre
Droits d’accès
Vérifiés côté serveur
Mots de passe et clés
Stockés hors du code
Bibliothèques utilisées
Vérifiées et suivies
Données personnelles (RGPD)
Cartographiées, hébergées en France si sensibles
Tests
Sur les parcours clés
Sauvegardes et suivi
En place
Reprise par une équipe
Documentée
Pour un outil personnel sans donnée sensible, le prototype peut suffire. Pour un outil utilisé par des clients ou des salariés, il faut aller plus loin.
Quand une application créée
avec l’IA devient un risque
Le bouton
caché
Les mots de passe
dans le code
Les bibliothèques
inconnues
Les corrections
qui cassent
Le code que personne
ne comprend
La mise en ligne
repoussée
Comment on travaille,
de l’audit au suivi
Votre application est-elle prête ?
10 points à vérifier avant la mise en production
- Les droits d’accès sont vérifiés côté serveur, pas seulement masqués dans l’interface.
- Les règles d’accès à la base de données (RLS sur Supabase, par exemple) sont actives sur chaque table.
- Aucune clé secrète n’est présente dans le code ni visible depuis le navigateur.
- Les dépendances sont à jour et sans faille connue.
- L’authentification est solide : mots de passe, sessions, récupération de compte.
- Les saisies des utilisateurs sont filtrées (failles XSS, injections).
- Les parcours clés (inscription, paiement) sont couverts par des tests.
- Les sauvegardes existent et la restauration a été testée.
- Les erreurs sont enregistrées et quelqu’un est alerté en cas de problème.
- Les données personnelles sont cartographiées (RGPD, hébergement, cookies) et quelqu’un sait expliquer le code.
Si la réponse est non à l’un de ces points, un audit permet de mesurer l’écart.
Cas client :
un outil de suivi financier créé avec Lovable pour un cabinet d’architectes
Un cabinet d’architectes a développé lui-même, avec Lovable, une application de suivi financier de chantier. Elle couvre 13 rubriques métier, de l’estimation au décompte général définitif, génère une trentaine de types de documents (certificats de paiement, DGD, PV, avenants) et offre un espace partagé au maître d’ouvrage, sans création de compte. L’outil sert déjà au quotidien. Le cabinet veut maintenant l’ouvrir à d’autres cabinets.
Sécurité
Une faille dans le parcours d’invitation permet de prendre le contrôle d’un compte existant. C’est critique, même pour un usage interne.
Dépendance technique
L’hébergement, les e-mails, la conversion Word et l’IA reposent sur des services Lovable. Le cabinet dépend d’un outil qu’il ne maîtrise pas.
Confidentialité
Les données ne sont pas cloisonnées entre cabinets. Il est donc impossible d’ouvrir l’outil à des confrères.
Fiabilité des données
Des modifications simultanées peuvent entraîner une perte de données, un incident déjà constaté.
Exactitude des montants
Certains écrans recalculent leurs propres montants : une même retenue de garantie s’affiche différemment selon l’écran. Le risque d’erreur financière est réel.
Ce qui fait la valeur de l’application est conservé : c’est son socle technique qui évolue. La première étape tient en trois interventions d’un jour chacune. Sécuriser l’existant : correction de la faille, export du code dans un dépôt Git maîtrisé, sauvegarde complète avec test de restauration. Inventorier et rationaliser : fonctions à garder, dépendances à Lovable, règles de calcul à tester. Spécifier la cible dans des spécifications fonctionnelles validées ensemble, qui servent ensuite de référence pour le développement et la recette.
La suite prévue : une reconstruction hors de Lovable sur Laravel et Filament, un socle multi-cabinet, la fiabilisation des calculs financiers et la mise en place d’abonnements.
Questions fréquentes sur les applications créées avec l'IA
Votre application est-elle prête
pour de vrais utilisateurs ?
Décrivez-nous votre outil en 30 minutes : l’outil utilisé pour le créer, ce qu’il fait, qui s’en sert. On vous dit honnêtement si un audit s’impose et si oui, par où commencer.
« * » indique les champs nécessaires