Avant d'élargir l'accès à une app construite avec l'IA, dix points doivent être vérifiés : les clés d'API côté serveur, les règles d'accès sur la base, une authentification complète, des sauvegardes testées, un domaine à ton nom, des dépendances à jour, un monitoring, la conformité RGPD, un test du parcours critique et un plan de reprise. Les voici dans l'ordre où on les vérifie, avec, pour chacun, qui peut s'en charger.
Cette liste prolonge la checklist des bases : les bases servent à garder la main pendant la construction, celle-ci sert à ouvrir les portes sans mauvaise surprise.
Les 10 points, dans l'ordre
1. Les clés d'API côté serveur
Ouvre ton app dans le navigateur, affiche le code source, cherche « key », « secret », « sk_ ». Si une clé secrète apparaît, elle est publique : n'importe qui peut consommer tes services (et ton budget) à ta place. Les clés se déplacent côté serveur. Difficulté : demande un dev.
2. Les règles d'accès sur la base
La base répond-elle uniquement aux requêtes légitimes ? Sur Supabase, ce sont les règles RLS (explication complète ici). Le test de cinq minutes existe, la correction demande de comprendre ton modèle de données. Difficulté : le test est à ta portée, la correction demande un dev.
3. Une authentification et des autorisations complètes
Mot de passe oublié, expiration de session, protection des routes côté serveur, suppression de compte et séparation des rôles. Teste chaque cas avec plusieurs profils. Difficulté : le test est à ta portée.
4. Des sauvegardes testées
Définis une fréquence adaptée à l'activité et teste une restauration au moins une fois. Une sauvegarde jamais restaurée reste une hypothèse. Difficulté : le contrôle est à ta portée, la restauration peut demander un développeur.
5. Le domaine et les comptes à ton nom
Domaine, base, clés, hébergement : chaque compte critique à ton email, avec un mot de passe fort et la double authentification. C'est le cœur de la checklist des bases. Difficulté : à ta portée, aujourd'hui.
6. Des dépendances à jour
Le code généré embarque des dizaines de briques logicielles, et certaines ont des mises à jour de sécurité en attente. Un audit de dépendances les liste en une commande. Difficulté : demande un dev.
7. Un monitoring qui prévient
Quand ton app casse un samedi soir, qui le sait en premier : toi, ou ton meilleur client ? Un outil de monitoring gratuit qui t'envoie un email au premier plantage change la réponse. Difficulté : à ta portée avec un tutoriel.
8. La conformité RGPD
Mentions légales et politique de confidentialité qui disent la vérité, données localisées en Europe, suppression de compte possible. Pour une app raisonnable, c'est un après-midi bien cadré. Difficulté : à ta portée avec un modèle sérieux.
9. Le parcours critique testé de bout en bout
Le parcours qui fait vivre ton app (s'inscrire, payer, obtenir le service) doit être testé du début à la fin, sur mobile, avec un compte neuf. Pas « ça devrait marcher » : testé. Difficulté : à ta portée, et personne ne le fera mieux que toi.
10. Un plan de reprise écrit
Si l'app tombe : qui fait quoi, dans quel ordre, avec quels accès ? Une page suffit. L'écrire avant l'incident prend vingt minutes ; pendant l'incident, tout coûte dix fois plus. Difficulté : à ta portée, ce soir.
Le bilan
Plusieurs contrôles sont accessibles sans écrire de code : propriété des comptes, parcours visibles, alertes et documentation. Les clés, règles d'accès, autorisations et dépendances demandent une lecture technique : c'est notamment le périmètre du Scan, qui les vérifie tous, chiffre ce qui coince, et te laisse décider de la suite. Ton app vient de Lovable, Bolt ou v0 ? Chaque plateforme a aussi ses vérifications spécifiques, détaillées sur sa page.