Votre application créée par l'IA est-elle prête pour la production ? Une checklist en 20 points

Les créateurs d'applications IA comme Lovable, Bolt, Replit, v0 et Cursor peuvent vous mener d'une idée à une démo fonctionnelle en quelques jours. C'est une vraie réussite, et c'est aussi là que les risques commencent. Une démo n'a qu'un utilisateur, des données de test et aucune conséquence. Une application en production, c'est des inconnus, des données personnelles, des paiements et une réputation à protéger.

Cette checklist couvre les 20 points qu'un ingénieur vérifie avant l'arrivée des vrais utilisateurs. Elle est rédigée pour les fondateurs et les responsables produit : chaque point explique pourquoi il compte et comment le vérifier sans lire tout le code. Si vous ne pouvez répondre avec assurance qu'à une poignée de ces points, un audit technique d'application IA vous dira où vous en êtes avant que le jour du lancement ne le fasse à sa place.

Comment utiliser cette checklist

Parcourez les cinq groupes ci-dessous et marquez chaque point comme vérifié (vous-même ou quelqu'un d'autre l'a testé), supposé (le créateur l'a probablement fait) ou inconnu. Traitez « supposé » comme « inconnu ». Les outils d'IA produisent du code qui semble complet, et les failles se situent généralement exactement là où personne n'a testé.

1. Comptes et accès

1. L'inscription, la vérification de l'e-mail et la réinitialisation du mot de passe fonctionnent de bout en bout. Créez un tout nouveau compte, vérifiez-le, réinitialisez le mot de passe, puis essayez de réutiliser l'ancien lien de réinitialisation. Les liens de réinitialisation doivent expirer et ne fonctionner qu'une seule fois.
2. Les autorisations sont appliquées côté serveur, et pas seulement masquées dans l'interface. Un bouton caché aux utilisateurs ordinaires ne protège rien si la requête sous-jacente fonctionne toujours. Connectez-vous en tant qu'utilisateur standard et appelez directement les endpoints d'administration. Ils doivent refuser.
3. Les rôles sont stockés à un endroit que les utilisateurs ne peuvent pas modifier. Sur certaines stacks, les métadonnées du profil utilisateur sont modifiables par l'utilisateur. Si « is_admin » s'y trouve, n'importe quel utilisateur peut se promouvoir lui-même. Les rôles doivent se trouver dans une table protégée ou dans des claims contrôlés par le serveur.
4. La connexion et les autres endpoints sensibles sont soumis à une limitation de débit. Sans limites, des attaquants peuvent essayer des milliers de mots de passe ou de codes à usage unique, et des bots peuvent remplir votre formulaire d'inscription.
5. Les espaces d'administration sont protégés et les comptes administrateurs utilisent l'authentification multifacteur. Le vol d'un seul mot de passe administrateur ne doit pas suffire à lire les données de tous vos clients.

2. Données et confidentialité

6. Chaque table contenant des données utilisateur a des règles d'accès. Avec Supabase, cela signifie Row Level Security. Une table qui n'en a pas peut être lue par quiconque possède votre clé API publique. Consultez notre guide sur les sept erreurs RLS des applications créées par IA.
7. L'isolation entre locataires est prouvée avec deux comptes de test. Connectez-vous en tant que client A, copiez l'identifiant d'un enregistrement, puis essayez de l'ouvrir ou de le modifier en tant que client B. Essayez aussi de modifier les identifiants dans les URL et les appels d'API. C'est le test le plus précieux pour tout produit multi-utilisateurs.
8. Les modifications de la base de données sont conservées dans des migrations versionnées. Si le schéma n'existe que dans le tableau de bord d'un outil de création, vous ne pouvez ni le recréer, ni le relire, ni l'annuler. N'oubliez pas que certaines modifications, comme la suppression d'une colonne, ne peuvent pas être annulées sans sauvegarde.
9. Les sauvegardes sont activées et une restauration a été testée. Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas un plan. Chronométrez la durée d'une restauration et notez-la.
10. Vous savez quelles données personnelles vous stockez et comment les supprimer. Listez les champs, leur emplacement (y compris dans les journaux et les outils tiers) et ce qui se passe lorsqu'un utilisateur demande à être supprimé.

3. Paiements et abonnements

11. Les webhooks de paiement sont vérifiés par signature et idempotents. Sinon, n'importe qui peut simuler un message « paiement réussi », et des envois en double peuvent créer des enregistrements en double. Détails dans notre guide sur les webhooks et abonnements Stripe.
12. L'accès payant découle des événements d'abonnement, pas de la page de remerciement. La page de succès n'est qu'une redirection du navigateur. Les gens ferment des onglets, et n'importe qui peut saisir l'URL.
13. Le mode test et le mode production sont totalement séparés, et les échecs sont gérés. Clés, produits et endpoints de webhook distincts. Vérifiez ce qui se passe en cas d'échec de renouvellement, d'annulation, de remboursement et de changement de formule.

4. Secrets et intégrations

14. Aucun secret dans le bundle frontend ni dans l'historique Git. Tout ce qui est envoyé au navigateur est public. Recherchez dans votre JavaScript compilé et dans votre dépôt les clés de service et les jetons d'API. Renouvelez tout ce qui a déjà été exposé, car supprimer le fichier ne supprime pas l'historique.
15. Les clés tierces suivent le principe du moindre privilège et ont des plafonds de dépenses. C'est très important pour les fonctionnalités d'IA. Une clé d'API de modèle de langage sans restriction dans une application publique peut générer une facture énorme en quelques heures. Définissez des plafonds d'utilisation et des limites par utilisateur.
16. Les téléversements de fichiers et les buckets de stockage sont verrouillés. Vérifiez qui peut lire chaque bucket, qui peut téléverser, et si le type et la taille des fichiers sont limités. Les buckets publics conviennent pour des images publiques, mais sont dangereux pour des factures ou des pièces d'identité.

5. Déploiement et exploitation

17. La préproduction et la production sont séparées. Bases de données, clés et domaines différents. Tester sur les données de production, c'est ainsi que des clients reçoivent des e-mails de test.
18. La surveillance des erreurs et les alertes de disponibilité parviennent à une personne qui agira. Si vous apprenez une panne par le message d'un client, c'est que la surveillance fait défaut.
19. Le domaine, le HTTPS et la délivrabilité des e-mails sont correctement configurés. Cela inclut les enregistrements SPF, DKIM et DMARC, afin que les e-mails de vérification et les reçus n'atterrissent pas dans les spams.
20. Il existe un plan de retour arrière et un responsable désigné. Qui peut déployer ? Comment revenir à la dernière version fonctionnelle ? Qui est d'astreinte ? Après le lancement, quelqu'un doit aussi appliquer les mises à jour, ce que couvre la maintenance mensuelle SaaS.

Que faire de vos résultats

• Majoritairement vérifié, quelques inconnues : testez vous-même les inconnues cette semaine, puis lancez avec la surveillance en place.
• Plusieurs inconnues dans les groupes 1 à 3 : faites une pause. Les accès, les données et les paiements sont les endroits où les erreurs deviennent des incidents. Une revue ciblée de ces domaines coûte moins cher qu'une faille de sécurité ou un bug de facturation.
• Défaillances connues : listez-les avec les étapes pour les reproduire. Cette liste est exactement ce dont un ingénieur a besoin pour chiffrer une correction, et c'est le point de départ de notre travail de réparation et mise en production d'applications IA.

Ce qu'une checklist ne peut pas vous dire

Une checklist détecte des catégories de problèmes connues. Elle ne peut pas juger si votre architecture supportera la croissance, si votre logique métier comporte des défauts subtils, ou si un attaquant pourrait enchaîner de petites faiblesses. Si vous avez besoin d'une évaluation de sécurité formelle, voyez la différence dans notre comparatif des audits techniques, tests d'intrusion et revues de code.

La bonne nouvelle, c'est que la plupart des obstacles au lancement dans les applications créées par IA se corrigent sans réécriture. L'objectif est de les trouver tant que la seule personne concernée, c'est vous.