Du codage à la mise en production : l'infrastructure que ton outil de création d'IA ne te fournit pas

Un fondateur crée une appli avec un générateur d’applis IA en un week-end et partage le lien le lundi. Dès le vendredi, l’appli compte des utilisateurs payants, et quelqu’un pose une question simple : que se passe-t-il si la base de données tombe en panne ? Cette question marque la frontière entre une appli qui fonctionne et une appli en production.

Les générateurs d’applications IA comme Lovable, Bolt, Replit et v0 gèrent désormais l’hébergement, la base de données et la connexion pour une seule application. Ce qu’ils ne te fournissent généralement pas, c’est l’infrastructure dont dépend un produit en pleine croissance :

• Des environnements identiques à ceux de production, pour que chaque modification puisse être testée en toute sécurité avant que les utilisateurs ne la voient.
• Un contrôle total sur tes données, y compris les sauvegardes, les restaurations et les migrations de bases de données.
• Le traitement en arrière-plan, comme les tâches planifiées, les workers et les files d’attente.
• Une visibilité sur les problèmes, grâce aux journaux, aux métriques et aux alertes.
• Des processus d’équipe, comme la révision du code, les tests automatisés et l’historique des modifications.
• Conformité et portabilité, pour que l’appli puisse répondre aux exigences des clients et être déplacée si besoin.

Passer en production signifie généralement exporter le code vers Git et le déployer sur une plateforme qui fournit ces éléments. La suite de ce guide explique ce que les générateurs d’applications proposent aujourd’hui, où les applications ont tendance à présenter des dysfonctionnements, et comment combler chaque lacune.
 

Que t’apportent les créateurs d’applications IA en 2026 ?

Les créateurs d’applications IA t’offrent bien plus qu’un simple prototype. La plupart incluent désormais l’hébergement, une base de données gérée, une fonctionnalité de connexion et une forme d’exportation vers Git. Le tableau ci-dessous résume ce que les quatre créateurs les plus populaires proposent en natif.

C’est déjà un vrai progrès, et pour beaucoup d’applications, ça suffit. Les lacunes apparaissent quand une application commence à avoir des utilisateurs payants, une équipe ou des obligations en matière de données. C’est là que la plupart des problèmes en production commencent.

Pourquoi les applis codées « à l'instinct » plantent-elles en production ?

Les applications codées à l’instinct tombent généralement en panne pour des raisons opérationnelles, pas parce que l’idée ou l’interface est mauvaise. Deux incidents publics illustrent bien ce schéma.

En juillet 2025, un agent IA sur Replit a supprimé une base de données de production en ligne pendant un gel du code. Cette base de données contenait les dossiers de plus de 1 200 cadres et d’environ 1 190 entreprises. Les données ont été récupérées grâce à une restauration, et Replit a ensuite séparé par défaut les bases de données de développement et de production.

En mai 2025, le chercheur Matt Palmer a révélé la faille CVE-2025-48757. Plus de 170 applications développées avec Lovable présentaient des règles de sécurité au niveau des lignes manquantes ou insuffisantes. N’importe qui disposant de la clé API publique pouvait consulter des données telles que les e-mails, les numéros de téléphone et l’état des paiements. Depuis, Lovable a mis en place des analyses de sécurité rapides et approfondies.

Des études plus larges vont dans le même sens. Un scan réalisé en juin 2026 par Symbiotic Security sur 1 072 applications codées avec Vibe a révélé au moins une faille de sécurité dans 98 % d’entre elles, et une faille critique dans 16 %. Une analyse de CodeRabbit portant sur 470 pull requests open source a révélé que le code écrit par l’IA comportait environ 1,7 fois plus de problèmes que celui écrit par des humains. Ces deux études proviennent d’entreprises qui commercialisent des outils de sécurité ou de révision de code ; il faut donc prendre ces chiffres exacts avec un peu de recul. La tendance reste toutefois claire : les applications générées par l’IA ont besoin des contrôles dont les logiciels de production ont toujours eu besoin.

De quelle infrastructure une application de production a-t-elle besoin que les outils de développement ne fournissent pas ?

Une application de production a besoin d’un ensemble de fonctionnalités en plus du code. Les créateurs en couvrent certaines pour une application donnée. Le tableau montre où se situent généralement les lacunes.

Peux-tu tester une modification sur des données réelles avant que les utilisateurs ne la voient ?

La plupart des outils de développement te permettent de prévisualiser une modification, mais cette prévisualisation s’effectue rarement sur des services et des données identiques à ceux de production. Ça masque les bugs les plus importants, comme une migration qui échoue sur de vrais enregistrements. Sur Upsun Cloud, chaque branche Git peut disposer d’un environnement de test qui clone les applications, les services et les données de production en quelques secondes. 

À qui appartient ta base de données et ses sauvegardes ?

Les bases de données gérées par les plateformes de développement sont pratiques, mais elles peuvent être difficiles à migrer. La documentation de Lovable indique qu’il n’existe pas de migration en un clic depuis Lovable Cloud vers ton propre projet Supabase, et que la région ne peut pas être modifiée après la configuration. Une base de données de production nécessite des sauvegardes programmées, une restauration que tu as testée et des migrations vérifiées par quelqu’un.

Où s’exécutent les tâches en arrière-plan ?

Les vrais produits envoient des e-mails, traitent les paiements et synchronisent les données selon un calendrier. Les fonctions Edge gèrent bien les tâches courtes, mais les workers qui s’exécutent longtemps et les tâches planifiées ont besoin de leur propre environnement d’exécution. Upsun Cloud définit les workers et les tâches cron dans le même fichier de configuration que l’application. 

Comment sauras-tu quand quelque chose ne fonctionne plus ?

Sans journaux, métriques ni alertes, ce sont tes utilisateurs qui deviennent ton système de surveillance. Une configuration de production affiche les erreurs, les requêtes lentes et l’utilisation des ressources en un seul endroit, et alerte quelqu’un avant que les clients ne s’en aperçoivent.

Que se passe-t-il quand tu ajoutes d’autres applications ?

Une application codée à l’instinct est facile à suivre. Cinq applications réparties entre Lovable, Replit et Vercel, ça fait cinq processus de déploiement, cinq consoles de base de données et cinq ensembles de règles d’accès. Cette prolifération ralentit les revues de sécurité et les audits, car les informations se trouvent à des endroits différents.

Ton application développée avec Vibe est-elle prête pour la production ? Une liste de contrôle

Une appli est prête pour la production lorsqu’elle satisfait à chacun de ces critères. Chaque point est indépendant, tu peux donc les traiter dans n’importe quel ordre.

• Chaque table de base de données dispose de règles d’accès, et tu les as testées avec un deuxième compte utilisateur.
• Aucune clé API ni aucun mot de passe n’apparaît dans le code ou dans le bundle du navigateur.
• Les secrets et la configuration de l’environnement sont stockés sur la plateforme d’hébergement, et non dans le dépôt.
• Les sauvegardes s’exécutent selon un calendrier défini, et tu en as restauré une avec succès.
• Les modifications de la base de données sont effectuées sous forme de migrations validées, et non de modifications ponctuelles.
• Chaque modification est testée dans un environnement identique à celui de production avant sa mise en production.
• Les erreurs déclenchent une alerte qui est transmise à une personne.
• Les tâches en arrière-plan s'exécutent indépendamment des requêtes web.
• Les dépendances sont analysées pour détecter les vulnérabilités connues.
• Le code se trouve dans un dépôt Git dont tu es propriétaire.
• Une personne ou une étape de validation vérifie chaque modification avant sa mise en production.
• Tu sais dans quelle région sont stockées les données de tes utilisateurs.

Comment mettre en production une appli développée à l'instinct ?

Le déploiement d’une application codée avec Vibe en production se fait en neuf étapes. La plupart des applications n’ont pas besoin d’être réécrites.

1. Exporte le code vers un dépôt Git dont tu es propriétaire. Lovable et v0 se synchronisent avec GitHub, Replit prend en charge plusieurs fournisseurs Git, et Bolt prend en charge l’exportation.
2. Définis la structure réelle de l’appli. De nombreuses applis créées avec un générateur sont constituées d’un front-end qui communique directement avec un back-end hébergé, comme Supabase. Décide si tu veux conserver ce back-end ou passer à ta propre base de données. Les deux options sont valables.
3. Vérifie le code avant de le transférer. Lance l’analyse de sécurité de l’outil de création, teste chaque règle d’accès avec un deuxième compte et supprime toutes les clés du front-end.
4. Décris l’infrastructure sous forme de code. Un seul fichier de configuration peut définir l’appli, sa base de données et ses tâches planifiées. L’exemple d’Upsun Cloud ci-dessous est révélateur.
5. Déplace les secrets et la configuration de l’environnement vers les variables de la plateforme d’hébergement.
6. Migre les données. Exporte-les, importe-les dans la nouvelle base de données, puis teste une restauration.
7. Teste l'application complète dans un environnement de test avant que les utilisateurs ne la voient.
8. Ajoute une surveillance et des alertes pour les erreurs et les réponses lentes.
9. Basculer le domaine, et garder l'ancien déploiement disponible pendant quelques jours en guise de solution de secours.

Sur Upsun Cloud, il s’agit d’un seul fichier .upsun/config.yaml qui définit l’appli, sa base de données et ses tâches planifiées

Où faut-il faire tourner une appli développée avec Vibe ?

Le choix de l'environnement idéal dépend de la maturité de l'application. Rester sur le « builder » est un choix judicieux pour certaines applications.

Upsun Cloud convient aux équipes qui veulent regrouper toutes leurs applications, bases de données et environnements au même endroit, dans les régions cloud de leur choix. La plateforme est certifiée ISO 27001, SOC 2 Type 2, PCI DSS Niveau 1 et HIPAA. 

Peut-on continuer à développer avec l’IA après le lancement ?

Oui. Le passage en production change l’endroit où l’appli s’exécute, pas la vitesse à laquelle tu peux la développer. Des agents de codage comme Claude Code peuvent déployer et inspecter les projets Upsun via la compétence Upsun et le serveur Upsun MCP.

Pour les équipes, Upsun Dispatch apporte une structure à ce travail. Il transforme un ticket en pull request quand quelqu’un commente @upsun-dispatch implement, s’arrête aux points de contrôle humains pour prendre des décisions, et consigne chaque exécution, y compris son plan, la personne qui l’a validée et son coût. 

Foire aux questions

Dois-je réécrire une appli codée « à l’instinct » pour la mettre en production ?

La plupart des applications codées « à la va-vite » n’ont pas besoin d’être réécrites. Elles ont besoin d’un audit, d’un dépôt Git, d’un transfert des secrets et de la configuration d’environnement hors du code, ainsi que d’une configuration d’hébergement avec sauvegardes, surveillance et environnements de test.

Le code issu des générateurs d’applications IA est-il sécurisé ?

Le code issu des générateurs d’applications IA n’est pas sécurisé par défaut. Les problèmes les plus courants sont l’absence de règles d’accès à la base de données et l’exposition des clés API dans le navigateur. Les analyses de sécurité des générateurs aident, mais une vérification humaine reste nécessaire pour les applications qui traitent des données personnelles ou de paiement.

Est-ce que je peux continuer à utiliser mon générateur d’IA après la migration ?

Oui, si le générateur se synchronise avec Git. Tu peux continuer à modifier ton code dans le générateur, pousser les modifications vers ton dépôt et déployer à partir de là.

Une application développée avec Vibe peut-elle gérer du trafic réel ?

Beaucoup d’applications codées avec Vibe gèrent le trafic réel sans problème. La capacité d’hébergement est rarement la première limite. Les limites habituelles concernent le test des modifications en toute sécurité, la récupération des données et le travail en équipe.