Pourquoi la montée en charge casse les apps vibecodées

Ce que c'est et pourquoi ça compte

Une app faite avec Claude Code marche très bien avec vous et trois amis. Puis cent personnes arrivent en même temps et les pages mettent une éternité à charger, ou ne s'ouvrent plus du tout.

La raison, ce n'est généralement pas un petit serveur. C'est la façon dont l'app parle à la base de données. Avec peu de données et peu d'utilisateurs, chaque gaspillage coûte des millisecondes. Avec beaucoup de données et beaucoup de monde en même temps, tout s'additionne.

Le test de charge sert à le voir avant : vous simulez beaucoup de personnes en même temps, vous mesurez le temps de chaque page et vous découvrez ce qui casse. Vous d'abord, avant vos utilisateurs.

Règle numéro un, sans exception : le test se fait sur une copie du projet ou sur l'environnement de test (staging), avec de fausses données. Jamais sur la base avec les vraies données, jamais sur le site en production. Un test de charge, c'est une petite attaque : sur le vrai site, vous ralentissez ou faites tomber l'app pour ceux qui l'utilisent.

1. Préparez le bon endroit

Avant d'écrire le prompt, je vérifie trois choses.

1. J'ai une copie séparée : un environnement de test, ou le projet sur mon ordinateur avec sa propre base de données.
2. J'ai fait un commit avec git, pour pouvoir revenir en arrière.
3. Je sais quels services externes l'app utilise (paiements, e-mails, notifications, API d'autres acteurs). Pendant le test, il ne faut pas les appeler pour de vrai.

Sur le dernier point : un test de charge contre un site ou une API qui ne vous appartient pas peut enfreindre leurs conditions d'utilisation. Testez uniquement votre propre environnement de test. Pour commencer, je demande à Claude de vérifier :

Avant tout, vérifie à quelle base de données et à quels services externes le projet est connecté en ce moment. Si quelque chose pointe vers les vraies données ou vers la production, arrête-toi et dis-le-moi. Je veux faire le test uniquement sur une copie, avec de fausses données, et avec les services externes remplacés par de fausses versions.

2. Le test avec mille faux utilisateurs

Ensuite, dans Claude Code, j'écris ceci :

Fais un test avec mille faux utilisateurs et dis-moi ce qui casse. Remplis la base de test avec de fausses données réalistes, écris un script qui simule mille personnes sur les pages principales en même temps (utilise un outil gratuit et open source, par exemple k6, Locust ou Artillery) et mesure le temps de chaque page. Donne-moi les trois pages les plus lentes, la raison et la correction que tu proposes. Ne touche pas au code tant que je ne t'ai pas dit ok.

Ce qui se passe, concrètement. Claude remplit la base de test avec beaucoup de fausses lignes, mais crédibles : utilisateurs, commandes, produits. Ça compte plus qu'on ne le croit : avec dix lignes, tout est rapide ; les problèmes n'apparaissent qu'avec des volumes réalistes.

Ensuite, il écrit un script qui envoie des requêtes aux pages principales comme si beaucoup de personnes le faisaient en même temps. k6, Locust et Artillery sont trois outils gratuits et open source qui font exactement ça : laissez Claude choisir en fonction du projet.

La dernière phrase est la plus importante : d'abord je veux comprendre, ensuite je décide. Le script de test et les fausses données, il doit les créer ; le code de l'app, non.

Pour une garantie de plus pendant qu'il propose les corrections, utilisez le plan mode : Shift+Tab jusqu'à voir « plan mode on » en bas, ou /plan au début du message. Là, Claude lit et propose, mais ne modifie aucun fichier tant que vous n'avez pas approuvé le plan. Pour le test lui-même, restez-en dehors : il doit créer le script et les fausses données.

Mille d'un coup ou par paliers

Mille personnes en même temps, c'est beaucoup, même pour l'ordinateur qui génère le test. Mieux vaut monter par paliers et voir à partir de quand les pages ralentissent. Et l'environnement de test est souvent plus petit que le vrai : ce qui compte, c'est l'avant et l'après, pas le chiffre absolu.

Fais le test par paliers : d'abord 50 utilisateurs, puis 200, puis mille. Pour chaque palier, donne-moi le temps moyen, le temps des requêtes les plus lentes et à partir de quand les erreurs commencent.

Une correction à la fois

Quand il vous donne la liste des trois pages les plus lentes, ne lui demandez pas de tout corriger d'un coup. Écrivez :

Corrige la première, refais le test et donne-moi les temps avant et après.

Et ainsi de suite avec la deuxième et la troisième. Si vous corrigez tout d'un coup et qu'ensuite quelque chose s'améliore, ou empire, vous ne savez pas ce qui l'a causé.

3. Les trois choses qu'il corrige presque toujours

Quand une page est lente, la raison est presque toujours l'une de ces trois.

Cent questions au lieu d'une

Une page affiche 100 produits. Le code demande d'abord à la base la liste des produits, puis, pour chacun, le prix. Total : 101 questions à la base de données pour une seule page. On appelle ça le « problème N+1 » : une question pour la liste, plus une par élément.

Seul, vous ne le remarquez pas. Avec mille personnes, ça fait cent mille questions, et la base de données sature. Et souvent le code a l'air propre : le problème est derrière.

La correction consiste à tout demander ensemble : une seule question qui récupère produits et prix, ou deux au maximum (la liste, puis tous les prix d'un coup). Demandez :

Trouve les requêtes dans une boucle et transforme-les en une seule.

Des tables sans index

Pensez à l'index à la fin d'un livre. Sans lui, pour trouver un mot, vous feuilletez toutes les pages. La base de données fait pareil : sans index, pour trouver les commandes d'un utilisateur, elle les lit toutes, une par une. Avec l'index, elle va droit au but.

En général, l'id principal de chaque table a déjà son index. Les colonnes qui servent à chercher, filtrer et relier les tables, souvent pas. Demandez :

Ajoute des index sur les colonnes que tu utilises pour chercher, filtrer et trier (id de l'utilisateur, e-mail, date).

Mais les index ne sont pas gratuits : ils prennent de la place et ralentissent un peu les écritures, parce qu'à chaque nouvelle donnée la base met aussi à jour l'index. On n'en met que là où ils servent. Je demande toujours la preuve :

Pour chaque index que tu ajoutes, dis-moi quelle page ou requête l'utilise et montre-moi le temps avant et après. Si un index ne sert à rien, ne l'ajoute pas.

Des données rechargées à chaque fois

Une grille de prix ou un menu qui change une fois par jour, inutile de le demander à la base à chaque visite. On le garde en mémoire quelques minutes : c'est le cache.

Mets en cache les données qui changent rarement et dis-moi au bout de combien de temps elles se mettent à jour.

Le cache a un prix lui aussi : les données peuvent être périmées. Si vous changez un prix et que le cache dure dix minutes, pendant dix minutes quelqu'un voit l'ancien. C'est pour ça que vous devez savoir au bout de combien de temps il se met à jour. Et les données personnelles d'un utilisateur ne doivent pas finir dans un cache partagé, sinon quelqu'un d'autre risque de les voir.

Vérifie que le cache ne contient pas de données personnelles d'un utilisateur qu'un autre utilisateur pourrait voir.

Attention si l'app tourne sur un hébergement serverless : là, le code s'exécute sur de nombreuses instances qui démarrent et s'arrêtent toutes seules. La mémoire d'une instance n'est pas partagée avec les autres et se vide souvent, donc un cache gardé là ne sert pas à grand-chose. Il faut un cache partagé, par exemple Redis. Demandez à Claude lequel votre hébergeur propose :

L'app tourne-t-elle sur un hébergement serverless ? Si oui, dis-moi quel cache partagé mon hébergeur propose et utilise-le à la place de la mémoire du serveur.

Les erreurs les plus courantes

• Faire le test sur le vrai site ou sur la base avec les vraies données. Toujours sur une copie ou sur l'environnement de test, avec de fausses données.
• Tester avec une base presque vide. Remplissez-la de fausses données en quantité réaliste.
• Tout corriger d'un coup. Une correction à la fois, avec les temps avant et après.
• Mettre des index sur toutes les colonnes. Seulement sur celles qui servent à chercher, filtrer et trier.
• Un cache sans durée de vie claire. Décidez au bout de combien de temps il se met à jour et gardez-en les données personnelles à l'écart.

Check-list

• Je travaille sur une copie ou sur l'environnement de test, pas en production
• La base de test contient de fausses données en quantité réaliste
• Pendant le test, les services externes sont factices
• J'ai la liste des trois pages les plus lentes, avec raison et correction
• J'ai corrigé une chose à la fois, avec les temps avant et après
• Je sais au bout de combien de temps chaque cache se met à jour

Questions fréquentes