Mettre en ligne une app Lovable, Bolt ou Cursor : la checklist

Votre application fonctionne, vous voulez l'ouvrir à de vrais utilisateurs. Avant de partager le lien, prenez le temps de passer cette checklist : la plupart des mauvaises surprises d'un lancement viennent de points qu'on pouvait vérifier la veille.

Pourquoi une checklist

Un pilote d'avion connaît son appareil, et il déroule quand même sa liste avant chaque décollage. Pas par manque de confiance : parce que, sous la pression, on oublie. Une mise en ligne, c'est le même moment. Tout semble prêt, l'envie d'avancer est forte, et c'est là qu'on saute une étape.

Une application montrée à quelques amis pardonne beaucoup. Une application ouverte au public pardonne peu : des données personnelles circulent, de l'argent peut passer, et un incident abîme la confiance.

La checklist

Les données et la sécurité

1. Les règles d'accès à la base sont en place. Chaque utilisateur ne voit que ses données. Testez avec deux comptes. Voir les règles d'accès à une base de données.
2. Aucune clé secrète n'est visible dans le code envoyé au navigateur. Voir les clés API exposées.
3. Les pages d'administration exigent une connexion et un rôle. Essayez leur adresse une fois déconnecté.
4. Les mots de passe sont conservés de façon sûre, jamais en clair (voir le hachage).

La fiabilité

5. Il existe une sauvegarde, et vous savez la restaurer. Une sauvegarde jamais testée est une hypothèse, pas une sécurité.
6. Vous avez un environnement de test séparé de la production. On essaie les changements sur une copie, jamais directement devant les utilisateurs. Voir staging et production.
7. Vous pouvez revenir en arrière. Si une mise à jour casse quelque chose, vous retrouvez la version précédente en quelques minutes plutôt qu'en plusieurs heures de panique.
8. Vous serez prévenu d'une erreur. Sans suivi des erreurs, l'application peut cesser de fonctionner pour certains utilisateurs et vous l'apprendrez par leurs messages.

Le cadre

9. Le site est en HTTPS (le cadenas dans le navigateur), sur votre propre nom de domaine, avec des e-mails d'envoi qui n'arrivent pas en courrier indésirable.
10. Les obligations légales sont couvertes : mentions légales, politique de confidentialité, consentement quand il est nécessaire. Un point à faire valider si vous traitez des données de particuliers.

Un test que personne ne fait

Avant le lancement, parcourez le chemin complet comme un inconnu : créez un compte avec une adresse neuve, réalisez l'action principale de votre produit, déconnectez-vous, reconnectez-vous, demandez un mot de passe oublié. Ce parcours révèle souvent plus que la lecture du code. Pour le rendre répétable, c'est le rôle des tests automatiques.

Quand on n'a pas le temps de tout vérifier

Priorité à trois choses : qui voit quoi, où sont les clés, comment on restaure. Ce sont celles dont les conséquences sont les plus lourdes et les plus difficiles à rattraper. Le reste peut se corriger après le lancement, dans les jours qui suivent, sans drame.

À retenir

Avant d'ouvrir au public, vérifiez les accès aux données, les clés, la sauvegarde et la possibilité de revenir en arrière. Vérifier avant le lancement coûte moins cher que réparer après.

Et pour votre produit ?

Si vous préférez qu'une personne extérieure déroule cette liste à votre place, notre audit est fait pour cela : il part de votre application telle qu'elle est, et vous rend les points à corriger avant le lancement, par ordre d'importance. Parlons-en lors d'un échange de 30 minutes.