MVP construit par IA : ce qui casse à 1 000 utilisateurs

Vous avez décrit un produit, un outil IA l'a construit, et ça marche. Ce n'est ni un hasard ni de la triche — c'est le plus grand bond de productivité de notre métier depuis dix ans. Si vous avez livré quelque chose de réel en une semaine, vous avez fait le bon choix.

Puis viennent les utilisateurs. Pas un million. Mille. Et le comportement devient étrange : des pages instantanées qui prennent quatre secondes, l'application qui tombe chaque mardi à midi, un client qui voit les données d'un autre, et personne pour expliquer pourquoi.

Ce n'est pas une critique des outils. C'est la conséquence prévisible de ce que vous avez demandé. L'IA vous emmène à 60 % — un parcours nominal qui fonctionne. La production, c'est les 40 % restants, et ces 40 % concernent surtout la charge, les utilisateurs malveillants et le temps. Personne ne les a demandés, donc personne ne les a construits.

Voici ce qui casse, à peu près dans l'ordre.

1. La base de données cède en premier

Presque toujours. Le code généré interroge de la manière la plus évidente possible, ce qui convient pour dix lignes et devient discrètement catastrophique pour cent mille.

Les trois classiques :

• Aucun index. Chaque recherche parcourt toute la table. À 100 lignes personne ne le remarque ; à 500 000, la même requête prend six secondes.
• Requêtes N+1. La page de liste récupère 50 éléments, puis lance une requête supplémentaire par élément pour obtenir son propriétaire. Soit 51 allers-retours pour afficher une page.
• SELECT * partout. Vous transférez chaque colonne, y compris les plus lourdes que vous n'affichez jamais, sur le réseau, à chaque fois.

Le signe distinctif : des temps de réponse qui augmentent avec vos données plutôt qu'avec votre trafic. Si l'application a ralenti en trois mois à nombre d'utilisateurs constant, c'est la base de données.

2. Vous épuisez les connexions

Fonctions serverless et base de données traditionnelle forment un piège bien connu. Chaque invocation simultanée ouvre sa propre connexion, et les bases plafonnent le nombre de connexions — souvent à 100 ou moins. Vingt utilisateurs simultanés peuvent l'épuiser.

Le symptôme est reconnaissable et angoissant : l'application fonctionne parfaitement, puis à un certain seuil de trafic tout échoue d'un coup avec des erreurs de connexion, avant de se rétablir une minute plus tard. Un pooler de connexions règle cela en un après-midi. Ne pas en avoir ne règle rien et ressemble à une panne totale.

3. Tout se passe dans la requête

Le code généré exécute le travail là où il est décrit. Ainsi l'envoi de l'e-mail de bienvenue, le redimensionnement d'un fichier, l'appel à une API tierce et la génération d'un PDF se produisent tous pendant que le navigateur de l'utilisateur attend.

Cela tient jusqu'au jour où le fournisseur d'e-mails ralentit : votre endpoint d'inscription prend alors 30 secondes et expire. L'utilisateur voit un échec sur une action qui a en réalité réussi, il réessaie, et vous voilà avec des doublons.

Tout ce qui n'est pas nécessaire pour rendre la réponse doit passer en tâche de fond. C'est le refactoring le plus rentable de cette liste.

4. Les autorisations — celle qui fait vraiment mal

C'est le point sérieux, et il mérite une deuxième lecture.

La plupart des applications générées gèrent correctement l'authentification : elles vérifient que vous êtes connecté. Beaucoup moins gèrent correctement l'autorisation : vérifier que cet utilisateur précis a le droit de toucher cet enregistrement précis.

Le bug ressemble à ceci : un endpoint reçoit un identifiant, récupère l'enregistrement et le renvoie — après avoir vérifié que votre session est valide, mais jamais que l'enregistrement vous appartient. Changez l'identifiant dans l'URL et vous lisez les données de quelqu'un d'autre.

Cette famille de failles (autorisation au niveau des objets) est régulièrement classée premier risque de sécurité des API, et c'est le défaut sérieux le plus fréquent que nous trouvons dans les bases de code générées par IA. Elle ne se manifeste pas pendant les tests, car lorsque vous naviguez, chaque enregistrement vous appartient légitimement.

Testez-le en 60 secondes : connectez-vous avec un compte, ouvrez n'importe quelle page de détail, et remplacez l'identifiant dans l'URL par celui d'un enregistrement appartenant à un autre compte. Si vous le voyez, arrêtez cette lecture et corrigez-le aujourd'hui.

5. Personne ne sait que quelque chose ne va pas

La dernière lacune n'est pas du code, c'est de l'exploitation. Il n'y a généralement ni suivi des erreurs, ni supervision de disponibilité, ni alertes, ni logs structurés, ni restauration de sauvegarde testée.

Autrement dit, votre boucle de retour sur les incidents de production, c'est un client qui vous écrit — en supposant qu'il prenne cette peine, ce que la plupart ne feront pas. Ils partiront, simplement. Vous pouvez perdre une part mesurable de vos inscriptions à cause d'un parcours cassé pendant des semaines sans rien voir d'autre qu'un taux de conversion un peu décevant.

La checklist des 1 000 utilisateurs

Avant de dépenser en acquisition, mettez ceci en place :

1. Des index sur chaque colonne filtrée ou jointe, et les requêtes N+1 éliminées.
2. Un pooler de connexions entre votre application et votre base de données.
3. Les traitements lents (e-mails, fichiers, appels tiers) déplacés en tâches de fond.
4. Un contrôle de propriété sur chaque endpoint qui accepte un identifiant.
5. Un suivi des erreurs et des alertes de disponibilité, dirigés là où vous les verrez.
6. Des sauvegardes automatiques — et une restauration réellement effectuée pour prouver qu'elles fonctionnent.
7. Une limitation de débit sur l'authentification et les endpoints coûteux.
8. Des secrets dans des variables d'environnement côté serveur, jamais dans le bundle client.

Cette liste est volontairement courte. Ce n'est pas une réécriture. Pour la plupart des MVP construits avec l'IA, cela représente une à trois semaines de travail concentré, et c'est la différence entre une démo et une entreprise.

Dans quel ordre corriger

Si vous ne pouvez en faire qu'une partie : la sécurité d'abord, puis la stabilité, puis la vitesse. Une application lente agace. Une application qui laisse fuiter les données d'un client vers un autre met fin à l'entreprise. Faites le point 4 cette semaine.

Et gardez ce que vous avez construit. Le réflexe, après avoir découvert de tels problèmes, est de déclarer la base de code irrécupérable et de tout reprendre — c'est généralement l'erreur coûteuse. Un produit qui fonctionne avec des défauts corrigeables vaut bien plus qu'une réécriture à trois mois du lancement. Nous expliquons quand ce calcul s'inverse dans le coût réel d'un MVP SaaS, et le chemin complet dans du prototype IA à la production.

Si vous préférez ne pas mener cet audit vous-même, c'est notre métier : consolider les produits construits avec l'IA pour qu'ils supportent de vrais utilisateurs. Découvrez notre approche du développement SaaS, ou envoyez-nous le dépôt et nous vous dirons ce que nous corrigerions en premier.