Application créée avec l'IA : 20 points à vérifier avant la mise en production

Pourquoi cette liste

Une application créée avec une IA fonctionne souvent dès la première semaine. Ce qui manque ne se voit pas à l'écran : sécurité, sauvegardes, tests, déploiement. Cette liste de vingt points est celle que j'utilise comme point de départ d'un diagnostic. Vous pouvez la parcourir vous-même en une heure et noter ce que vous ne savez pas vérifier.

Secrets et accès

1. Aucune clé ni aucun mot de passe dans le code ou l'historique Git. Cherchez les mots « key », « secret » et « token » dans le dépôt, et regardez les fichiers chargés par le navigateur.
2. Les clés d'API sont stockées côté serveur et limitées au strict nécessaire.
3. Une clé a déjà été renouvelée au moins une fois, ce qui prouve que le renouvellement est possible sans tout casser.

Authentification et droits

1. Réinitialisation du mot de passe, verrouillage et vérification de l'e-mail fonctionnent.
2. Chaque utilisateur ne voit que ses données. Testez avec deux comptes différents.
3. Les règles d'accès de la base sont actives et testées (RLS sur Supabase, règles Firebase).
4. Les actions sensibles (suppression, export) sont contrôlées côté serveur, pas seulement masquées dans l'interface.

Données

1. Des sauvegardes automatiques sont actives.
2. Une restauration a été testée au moins une fois.
3. Les données personnelles sont identifiées : lesquelles, pourquoi, pendant combien de temps.

Qualité et tests

1. Les parcours critiques sont testés : inscription, paiement, import, envoi.
2. L'utilisateur ne voit jamais de trace technique en cas d'erreur.
3. Des limites de débit protègent les routes sensibles (connexion, envoi d'e-mails, appels payants).

Déploiement

1. Deux environnements distincts : développement et production.
2. Un déploiement automatisé avec un retour arrière possible.
3. Les dépendances sont à jour, sans faille connue.
4. Des journaux et des alertes préviennent en cas de panne.

Plateforme, coûts et savoir

1. Les coûts de la plateforme et des API sont connus et plafonnés.
2. La dépendance à l'outil d'origine est mesurée : export du code, migration envisageable.
3. Une documentation minimale existe : comment lancer, déployer et restaurer.

Pour un site, ajoutez : titres et descriptions de chaque page, rendu des pages pour les moteurs de recherche, vitesse sur mobile. Le sujet est détaillé sur la page refonte de site créé avec l'IA.

Comment lire le résultat

Ces seuils sont des repères, pas une norme :

• Moins de cinq points non cochés : des corrections ciblées suffisent, vous pouvez souvent les traiter avec l'outil.
• De cinq à dix points non cochés : un diagnostic est recommandé avant d'exposer l'application à davantage d'utilisateurs.
• Plus de dix points non cochés, ou un point de sécurité (1 à 7) non validé : ne pas ouvrir l'application plus largement avant d'avoir un plan.

Aller plus loin

Le diagnostic de 3 jours passe en revue ces vingt points sur votre application, avec un rapport écrit, une décision et un plan chiffré. Pour décider entre corriger et reconstruire, lisez reprise ou refonte d'une application. Pour le cadre général, voir du vibe coding à la production.