# Les 6 choses que je vérifie avant de mettre une app construite avec l'IA en production
Mik Bry · 2026-07-22 · lecture ~10 min · IA · Sécurité
Votre app tourne. Les pages s'affichent, l'inscription fonctionne, le paiement apparaît et la démo est convaincante.
C'est déjà beaucoup. Mais ce n'est pas la même chose qu'être prêt pour la production.
Dès qu'il y a de vrais utilisateurs, de l'argent et des données réelles, les questions changent. Je ne regarde plus seulement si le parcours prévu fonctionne. Je regarde ce qui se passe quand on change un numéro dans une URL, quand un paiement échoue à moitié, quand un script crée des centaines de comptes, quand une clé privée devient visible pour les visiteurs ou quand l'interface affiche « succès » alors qu'en réalité rien ne s'est passé derrière.
L'IA n'a pas inventé ces problèmes. J'ai fait certaines des mêmes erreurs bien avant qu'elle écrive du code pour moi. Ce qu'elle change, c'est la vitesse : on arrive beaucoup plus vite à un produit crédible, y compris dans des zones que personne n'a encore vraiment mises à l'épreuve.
Voici les six choses que je regarde en premier.
Les six vérifications
1. [Le paiement marche… sur le chemin prévu](#s1)
2. [Le serveur fait trop confiance au navigateur](#s2)
3. [Rien ne freine les abus](#s3)
4. [Des secrets se retrouvent là où ils ne devraient pas](#s4)
5. [La base de données ne protège pas forcément un client d'un autre](#s5)
6. [Un échec ressemble à un succès](#s6)
01 — Le paiement marche… sur le chemin prévu
Un écran de paiement peut donner l'impression que tout est terminé alors que le système ne l'est pas.
Les vérifications évidentes restent indispensables : êtes-vous en mode test ou en production ? La confirmation du prestataire de paiement revient-elle bien vers votre app ? L'application enregistre-t-elle correctement le résultat final ?
Mais je ne m'arrête pas à l'écran Stripe.
Je cherche aussi toutes les autres façons dont l'app peut considérer un compte comme payé, créer ou modifier un abonnement, ouvrir un accès ou changer son statut de facturation. Une intégration Stripe propre ne sert pas à grand-chose si un autre chemin caché dans l'app peut produire le même résultat sans les mêmes contrôles.
Premier test · sans risque
Ouvrez le tableau de bord de votre prestataire de paiement et vérifiez l'environnement utilisé. En mode test, utilisez ses cartes de test et vérifiez que l'application traite correctement les paiements réussis **et** les échecs. Si vous êtes déjà en production, planifiez un petit paiement remboursable plutôt que d'improviser avec une vraie transaction client.
Passer ce test ne prouve pas que le système de paiement est sûr. Il confirme simplement que le chemin le plus évident est correctement branché.
Référence :Stripe — checklist de mise en production couvre notamment le passage test/production, les webhooks de production, les événements retardés ou dupliqués, les clés API et les cas limites.
02 — Le serveur fait trop confiance au navigateur
L'interface sait quelle facture, quel projet ou quel compte vous regardez. Ça ne veut pas dire que le serveur a vérifié que vous aviez le droit d'y accéder.
Le cas classique est simple : vous ouvrez `/facture/42`, vous remplacez `42` par `41`, et l'application vous renvoie la facture de quelqu'un d'autre.
L'app ne doit jamais considérer qu'une information est fiable simplement parce qu'elle vient du navigateur du visiteur. Ce que le navigateur envoie peut être modifié.
Premier test · sans risque
Créez deux comptes de test que vous contrôlez. Connectez-vous avec le premier et essayez d'ouvrir une donnée appartenant au second en changeant le numéro ou le code visible dans l'URL. Une application correctement protégée refuse. Si elle renvoie les données de l'autre compte, arrêtez-vous là : vous avez déjà trouvé le problème.
Référence :OWASP — Insecure Direct Object Reference Prevention recommande précisément ce type de test : utiliser deux comptes et vérifier que l'un ne peut pas accéder aux objets de l'autre en modifiant une référence.
03 — Rien ne freine les abus
Un formulaire qui fonctionne une fois peut parfois être appelé dix mille fois.
L'inscription est le cas évident, mais le même problème existe pour la récupération de mot de passe, les invitations, l'envoi de fichiers, les e-mails, les codes de connexion à usage unique et les fonctions reliées à un fournisseur d'IA.
Ce dernier cas mérite une attention particulière. Si votre app envoie des requêtes à OpenAI, Anthropic, Mistral ou un autre service en utilisant votre compte, un attaquant peut parfois se servir de votre app comme relais et déclencher des requêtes payantes à vos frais. Une fonction IA mal protégée peut donc transformer un abus en vraie facture.
Sans protection qui ralentit ou bloque les usages répétitifs et suspects, une fonctionnalité anodine en démo peut devenir très coûteuse.
Premier test · sans risque
Utilisez uniquement des comptes et adresses que vous contrôlez et répétez plusieurs fois la même action. Est-ce qu'une limite apparaît ? Une confirmation ? Un délai ? Un refus face à une répétition évidente ? Si rien ne freine jamais, ça mérite une vraie revue — surtout pour une fonction qui vous coûte de l'argent à chaque utilisation.
Référence :OWASP API Security — Unrestricted Resource Consumption recommande de limiter la fréquence des appels et de configurer des limites de dépense chez les fournisseurs, car des appels répétés peuvent consommer des ressources payantes et avoir un impact business.
04 — Des secrets se retrouvent là où ils ne devraient pas
Une clé privée copiée par erreur dans des fichiers partagés avec le code. Un mot de passe de base de données qui apparaît dans des journaux techniques. Une clé de paiement de production envoyée au navigateur de chaque visiteur.
Ce sont des erreurs simples à créer et presque invisibles tant que l'app fonctionne.
Les outils d'IA peuvent connecter des services très vite. Ça ne garantit pas qu'ils rangent toujours les clés privées au bon endroit.
Premier test · sans risque
Demandez où sont stockées les clés utilisées pour les paiements, la base de données, l'e-mail ou les services d'IA, et si certaines sont envoyées au navigateur d'un visiteur ou incluses dans des fichiers accessibles à d'autres personnes.
Vous pouvez aussi regarder ce que reçoit votre navigateur, ou demander à quelqu'un de technique de le faire. Ne rien trouver ne prouve pas que tout est sûr : ce test sert seulement à repérer les erreurs les plus évidentes.
Références :OWASP — Secrets Management explique pourquoi les clés API et identifiants de base de données ne doivent pas être écrits en clair dans le code ou dispersés dans des fichiers de configuration. GitHub — Secret scanning documente les risques liés aux clés, mots de passe et jetons exposés dans un dépôt.
05 — La base de données ne protège pas forcément un client d'un autre
Une interface propre peut cacher un problème sérieux : l'écran ne montre que vos données, mais le système derrière peut malgré tout laisser passer celles de quelqu'un d'autre.
Des services comme Supabase permettent d'imposer directement une règle du type : « ce client ne peut lire que ses propres données ». D'autres systèmes appliquent la même protection ailleurs.
La technologie utilisée n'est pas le plus important. Ce qui compte, c'est que cette protection existe à un endroit que le visiteur ne peut pas contourner.
Premier test · sans risque
Ouvrez la partie sécurité de votre base de données ou de votre hébergeur et regardez s'il signale des problèmes d'accès aux données clients. Si vous utilisez Supabase, son Security Advisor et les règles de sécurité au niveau des lignes sont de bons points de départ. Ensuite, faites un test avec deux comptes que vous contrôlez : l'un ne doit jamais pouvoir lire les données de l'autre.
> **Mon conseil :** des outils comme Supabase sont très pratiques pour construire vite. Ils regroupent la base de données, la connexion des utilisateurs, le stockage de fichiers et d'autres services au même endroit.
>
> Pour un produit qui a vocation à durer et à grossir, je préfère généralement garder la base de données plus indépendante du reste. Concrètement, cela peut vouloir dire utiliser un service PostgreSQL managé comme Neon ou AWS, et laisser l'application y accéder via son propre serveur.
>
> Pourquoi ? Parce que si le produit fonctionne, vous voudrez peut-être changer la gestion des comptes, déplacer une partie de l'application, ajouter d'autres services ou simplement mieux maîtriser le coût de la base. Garder cette brique indépendante donne plus de liberté pour la suite.
>
> Cela ne veut **pas** dire que Supabase est un mauvais choix ou qu'il sera toujours plus cher. C'est souvent un excellent outil pour construire un MVP. Mon point est simplement que la simplicité du départ peut devenir une dépendance plus tard, donc je préfère faire ce choix en connaissance de cause.
Références :Supabase — Row Level Security indique que la RLS est activée par défaut pour les tables créées avec le Table Editor du Dashboard, mais qu'elle doit être activée explicitement pour les tables créées en SQL ou via le SQL Editor. Supabase recommande aussi d'activer la RLS sur les tables des schémas exposés. Sa checklist de production recommande de vérifier le Security Advisor et les politiques RLS avant la mise en production.
06 — Un échec ressemble à un succès
C'est un problème facile à rater parce que l'interface peut être parfaite.
Le paiement affiche « succès », mais rien n'a été enregistré. Le formulaire devient vert, mais le message n'est jamais parti. L'upload se termine, mais le fichier n'existe pas. L'animation est finie, alors que l'opération réelle derrière a échoué.
Dans les apps construites avec l'IA que je relis, les échecs sont souvent beaucoup moins testés que le parcours normal qui fonctionne.
Premier test · sans risque
Utilisez des valeurs invalides mais sans conséquence et des situations prévues pour échouer. Envoyez un fichier vide. Saisissez une valeur négative là où elle n'a aucun sens. Faites un paiement de test prévu pour être refusé. L'app doit refuser clairement, sans laisser derrière elle des données à moitié enregistrées.
Un message vert n'est pas une preuve que l'opération a réussi.
Références :OWASP — Input Validation recommande de vérifier à la fois la forme des données et leur cohérence métier. OWASP — Error Handling recommande de traiter explicitement les cas d'échec afin de ne pas laisser l'application dans un état imprévisible.
## Avant de mettre en production
Posez-vous six questions simples :
- **Paiements :** l'état réel du paiement a-t-il été vérifié, y compris les échecs et les chemins adjacents qui peuvent ouvrir un accès payant ?
- **Accès :** un compte de test peut-il ouvrir les données d'un autre ?
- **Abus :** qu'est-ce qui empêche un script de répéter une opération sensible ou coûteuse — notamment une fonction qui appelle un service d'IA que vous payez ?
- **Secrets :** savez-vous où sont stockées vos clés de production et qui peut les lire ?
- **Données :** existe-t-il une règle, hors du contrôle du visiteur, qui sépare réellement les données de chaque client ?
- **Échecs :** quand une opération échoue, le produit échoue-t-il vraiment proprement au lieu de seulement changer l'interface ?
Si une réponse est « je ne sais pas », vous avez trouvé quelque chose à vérifier. Pas forcément une catastrophe.
La nuance est importante.
Si vous voulez aller plus loin
Je relis des applications construites avec l'IA ou en vibe coding avant leur mise en production.
Commencer ici
Trust Report
Une revue automatisée de votre app et de son code, réalisée avec mes outils d'analyse. Vous obtenez les principaux risques, ce qui mérite l'attention avant le lancement et ce qui peut attendre. Si vous souhaitez parcourir les résultats ensemble, une revue avec moi est disponible en option.
Architecture, paiements, accès, données clients, garde des clés de déploiement, logiciels tiers, et une recommandation de mise en production documentée par un CTO humain.
Les six vérifications ci-dessus constituent un bon premier filtre. Elles peuvent faire ressortir des problèmes évidents, mais elles ne peuvent pas vous montrer ce que vous ne savez pas encore qu'il faut tester.
Si l'app s'apprête à gérer de vrais utilisateurs, de l'argent ou des données sensibles, c'est précisément là qu'un regard technique expérimenté devient utile.