Les applications développées avec Vibe peuvent-elles évoluer ? Qu'est-ce qui change après l'arrivée de tes premiers vrais utilisateurs ?

Une appli développée en « vibe coding » donne souvent l’impression d’être terminée le jour de son lancement. Puis les vrais utilisateurs arrivent, les données s’accumulent, et une page qui se chargeait instantanément commence à ralentir. C’est ce moment-là qui soulève la question au cœur de ce blog.

Le « vibe coding », c’est créer un logiciel en décrivant ce que tu veux à un outil d’IA et en acceptant le code qu’il génère, souvent sans le relire ligne par ligne. C’est Andrej Karpathy qui a inventé ce terme en février 2025.

Oui, la plupart des applications codées « à l’instinct » peuvent évoluer. Elles rencontrent rarement des difficultés parce qu’elles ont été écrites par une IA. Elles se heurtent aux mêmes goulots d’étranglement que n’importe quelle autre application, et le « vibe coding » rend ces goulots d’étranglement plus probables, car personne n’a vérifié les modèles. Les problèmes apparaissent généralement dans cet ordre :

1. Les requêtes de base de données et les règles d’accès ralentissent à mesure que les tables grossissent.
2. Les connexions à la base de données s’épuisent lors des pics de trafic.
3. Les tâches en arrière-plan bloquent les requêtes web.
4. Les problèmes passent inaperçus, car il n’y a pas de surveillance.
5. Les coûts liés à l’API d’IA augmentent à chaque nouvel utilisateur.
6. Les changements au sein de l'équipe deviennent risqués sans revues de code ni environnements de test.

La plupart de ces problèmes ont des solutions ciblées. Une réécriture complète est rarement la première étape.

Pourquoi les applis développées à l'instinct atteignent-elles leurs limites plus vite ?

Les outils d’IA écrivent du code qui fonctionne sur les données qu’ils ont sous les yeux. Une base de données de test avec 50 lignes cache les problèmes qui apparaissent à 500 000 lignes. Ce sont toujours les mêmes quelques schémas qui causent la plupart des soucis :

• Des index manquants. Les requêtes parcourent des tables entières au lieu d’aller directement aux bonnes lignes.
• Une requête par élément. Une page charge une liste, puis exécute une requête distincte pour chaque élément de cette liste.
• Filtrage dans le navigateur. L’appli télécharge un gros ensemble de données et le filtre sur l’appareil de l’utilisateur.
• Des règles d’accès qui s’appliquent à chaque ligne. Les politiques de sécurité au niveau des lignes appellent une fonction pour chaque ligne qu’elles vérifient.
• Pas de pool de connexions. Les fonctions sans serveur ouvrent une nouvelle connexion à la base de données à chaque requête.
• Tâches lentes au sein des requêtes. Les e-mails, le traitement de fichiers et les appels à l’IA s’exécutent pendant que l’utilisateur attend.

Aucun de ces schémas n’est propre à l’IA. Un développeur humain peut tous les écrire. La différence, c’est qu’une personne relit souvent le code avant sa mise en production, alors qu’une appli codée à l’instinct peut être déployée sans cette relecture. Pour ce qui est de l’aspect sécurité du même problème, consulte le guide sur la mise en production d’une appli codée à l’instinct.

Qu’est-ce qui change après l’arrivée de tes premiers vrais utilisateurs ?

La mise à l’échelle n’est pas un événement ponctuel. C’est une série de « premières fois », et chacune d’entre elles met en évidence une faiblesse différente. Le tableau résume l’ordre habituel.

1. Premiers utilisateurs réels : tes données sont-elles en sécurité ?

Les vrais utilisateurs génèrent de vraies données, et les erreurs ont désormais des conséquences sur de vraies personnes. Teste chaque règle d'accès en te connectant en tant que deuxième utilisateur et en essayant de consulter les données du premier utilisateur. Ensuite, planifie des sauvegardes et restaure-en une, car une sauvegarde non testée risque d'échouer quand tu en auras besoin.

2. Premier pic de trafic : pourquoi les pages ralentissent-elles ?

Le ralentissement des pages vient généralement de la base de données, pas du serveur. Les propres tests de Supabase montrent à quel point les gains peuvent être importants. L’ajout d’un index à la colonne utilisée dans une règle d’accès a permis de réduire le temps d’exécution d’une requête de 171 ms à moins de 0,1 ms. La réécriture de auth.uid() en (select auth.uid()) dans une politique a permis d’en réduire une autre de 179 ms à 9 ms.

Les connexions constituent la deuxième limite. Chaque base de données accepte un nombre fixe de connexions. Les fonctions sans serveur peuvent ouvrir simultanément de nombreuses connexions de courte durée ; Supabase recommande donc d’utiliser un gestionnaire de pool de connexions pour celles-ci.

3. Premiers clients payants : tu sauras quand quelque chose ne fonctionne plus ?

Les clients payants s’attendent à ce que l’appli fonctionne, et ils remarquent vite les pannes. Déplace les e-mails, le traitement des fichiers et les appels IA hors des requêtes web vers des tâches en arrière-plan, pour qu’une tâche lente ne bloque pas l’utilisateur. Ajoute ensuite des alertes d’erreur qui parviennent à quelqu’un, pour que tu sois au courant des pannes avant les clients.

4. Première facture liée aux fonctionnalités d’IA : combien coûte chaque utilisateur ?

Si ton appli appelle une API de modèle, chaque utilisateur actif génère des coûts. Les gros utilisateurs peuvent coûter bien plus cher que les petits. Fixe une limite d’utilisation par utilisateur, mets en cache les réponses aux questions récurrentes et utilise un modèle plus petit quand la qualité le permet. Suis le coût par utilisateur, pas seulement le total mensuel.

5. Premier coéquipier : peux-tu modifier l’appli en toute sécurité ?

Une seule personne peut garder toute l’appli en tête. Deux personnes, non. Mets en place une révision du code, lance des tests automatisés et teste chaque modification dans un environnement de test avant la mise en production. Les mêmes règles s’appliquent lorsque des agents IA écrivent le code ; des outils comme Upsun Dispatch ajoutent des étapes de validation humaine à ce processus. 

6. Premier client professionnel : peux-tu prouver que l’appli est sécurisée ?

Les gros clients envoient des questionnaires de sécurité. Ils demandent où les données sont stockées, qui peut y accéder et comment les modifications sont validées. Pour y répondre, il faut des pistes d’audit, une localisation claire des données et un hébergeur disposant de certifications reconnues.

Faut-il réécrire une appli codée à la va-vite pour la faire évoluer ?

En général, non. La plupart des problèmes de mise à l’échelle se situent au niveau de quelques requêtes, paramètres ou fonctions, et il est plus rapide et plus sûr de les corriger que de repartir de zéro. Utilise les indications ci-dessous pour te décider.

Méfie-toi des conseils qui te poussent directement à tout refaire. Une refonte prend des mois, et la nouvelle version risque de reproduire les mêmes erreurs si elle n’est pas accompagnée de tests rigoureux. Commence par la correction qui élimine le goulot d’étranglement actuel, puis réévalue la situation.

Comment repérer les limites avant que tes utilisateurs ne le fassent ?

Tu identifies les limites en effectuant des tests avec un trafic et des données réalistes. Trois étapes suffisent pour la plupart des applications :

1. Teste avec des données de taille réelle. Les requêtes lentes n’apparaissent que lorsque les tables sont volumineuses. Un environnement de test avec une poignée de lignes passera tous les contrôles.
2. Effectue un test de charge. Des outils open source comme k6 et Locust simulent de nombreux utilisateurs à la fois. Commence par les pages que les vrais utilisateurs consultent le plus.
3. Surveille les requêtes les plus lentes. L’extension pg_stat_statements de PostgreSQL répertorie les requêtes qui prennent le plus de temps. Corrige les plus importantes, puis refais un test.

La première étape est souvent la plus difficile, car copier les données de production dans un environnement de test demande du travail. Certaines plateformes automatisent cette opération. 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, ce qui permet d’effectuer un test de charge sur le même volume de données que celui généré par les utilisateurs. 

Où Upsun Cloud trouve-t-il sa place ?

Upsun Cloud convient aux applications développées de manière informelle qui ont dépassé le stade d’une configuration simple et doivent désormais évoluer de manière contrôlée. Il t’aide à plusieurs étapes décrites ci-dessus :

• Évolutivité : la tarification est basée sur les ressources, tu peux donc allouer plus de CPU et de mémoire à l’appli ou au service qui en a besoin, et tu paies à l’heure pour ce que tu provisionnes.
• Tests : les environnements de test clonent les données de production, ce qui permet aux tests de performance de refléter les conditions réelles.
• Visibilité : chaque projet inclut 30 jours de métriques d’infrastructure et un profilage continu.
• Conformité : la plateforme est certifiée ISO 27001, SOC 2 Type 2 et PCI DSS Niveau 1.

Pour une petite appli statique, un hébergement plus simple suffit. La comparaison des plateformes d’hébergement pour les applis développées avec Vibe explique quand chaque option est la plus adaptée.  
 

Foire aux questions

C'est quoi, le « vibe coding » ?

Le « vibe coding », c'est créer un logiciel en décrivant ce que tu veux à un outil d'IA et en acceptant le code qu'il génère. Des outils comme Lovable, Bolt, Replit, v0, Cursor et Claude Code sont couramment utilisés pour ça.

Une application Lovable peut-elle gérer des milliers d’utilisateurs ?

Oui, si la base de données est conçue pour ça. Les applications Lovable stockent les données dans un backend basé sur Supabase ; la capacité dépend donc principalement des index, des règles d’accès et du forfait de base de données. Fais des tests avec des données de taille réelle avant un lancement ou une campagne.

Est-ce que Supabase est évolutif ?

Supabase fonctionne sur PostgreSQL, qui gère bien les charges de travail importantes. Faire évoluer une application Supabase implique généralement d’optimiser les requêtes et les règles d’accès, d’utiliser un pool de connexions et de passer à une instance plus puissante si nécessaire.

Le code généré par l’IA est-il plus lent que celui écrit par un humain ?

Pas forcément. Le risque, c’est la qualité, pas la vitesse. Une analyse de CodeRabbit portant sur 470 pull requests a révélé environ 1,7 fois plus de problèmes dans le code écrit par l’IA, et les problèmes de performances en font partie.

Combien ça coûte de faire évoluer une appli codée avec Vibe ?

Les coûts dépendent du trafic, du volume de données et de l’utilisation de l’IA. Les augmentations les plus importantes proviennent généralement de la capacité de la base de données et des appels à l’API du modèle. Les plateformes proposant une tarification basée sur les ressources te permettent de payer uniquement pour les ressources réellement utilisées par chaque partie de l’appli.

Quand faut-il faire appel à un développeur ?

Fais appel à un développeur lorsque le même problème réapparaît après plusieurs corrections, lorsque l’appli gère des paiements ou des données personnelles, ou avant de signer un contrat avec un gros client.

Est-ce que je peux continuer à coder « à l’instinct » après le lancement ?

Oui. Continue à utiliser les outils d’IA, mais ajoute des revues de code, des tests automatisés et des environnements de test, pour que chaque modification soit vérifiée avant que les utilisateurs ne la voient.