Lovable, Bolt, Cursor : la liste de contrôle avant la mise en production

Comment utiliser cette liste

Répondez à chaque question par oui, non ou je ne sais pas. Les « non » sont des chantiers. Les « je ne sais pas » sont plus importants encore : ce sont les endroits où personne ne regarde, et c'est là que les problèmes s'installent.

Cette liste est une version courte de notre grille de soixante questions. Elle ne remplace pas un diagnostic, mais elle vous dira si vous en avez besoin, et par où commencer.

Ce qui vous appartient

1. Le nom de domaine, l'hébergement, la base de données et le compte de paiement sont-ils à votre nom, et pas à celui de la personne ou de l'agence qui a fait l'application ?
2. Avez-vous accès au code, aujourd'hui, sans demander à personne ? Est-il dans un dépôt (GitHub, GitLab) dont vous êtes propriétaire ?
3. Savez-vous ce que l'application vous coûte chaque mois, poste par poste (hébergement, base, e-mails, outils) ?

Les données de vos clients

4. Les règles d'accès de la base sont-elles vérifiées : un visiteur sans compte peut-il lire les données d'un client ? Notre guide Supabase : vérifier vos règles d'accès prend dix minutes.
5. Existe-t-il une sauvegarde de la base, et quelqu'un l'a-t-il déjà restaurée au moins une fois pour vérifier qu'elle fonctionne ?
6. Savez-vous quelles données personnelles vous gardez, combien de temps, et pouvez-vous les exporter ou les effacer si un client le demande ?

Qui peut entrer

7. Avez-vous vérifié qu'aucune clé secrète n'est présente dans le code envoyé au navigateur ? Voir La clé d'administration est-elle dans votre code ?.
8. L'espace administrateur est-il protégé côté serveur, et pas seulement caché dans l'écran ?
9. Qui a encore accès aux comptes (hébergement, base, dépôt, paiement) sans en avoir besoin : un ancien prestataire, un stagiaire, une agence ?

L'argent

10. Un paiement n'est-il confirmé que par le prestataire de paiement, et pas parce qu'une page de retour s'est affichée ? Voir Stripe : un paiement réussi, vraiment ?.
11. Les montants sont-ils calculés côté serveur, et pas pris dans la page ?
12. Que se passe-t-il quand un paiement échoue, ou qu'un client est remboursé : l'application le sait-elle ?

Quand quelque chose casse

13. Êtes-vous prévenu quand une erreur se produit chez un client, ou l'apprenez-vous quand il vous écrit ?
14. Existe-t-il un endroit pour essayer une modification avant qu'elle n'arrive chez vos clients ?
15. Pouvez-vous revenir à la version précédente en quelques minutes si une mise à jour casse quelque chose ?
16. Vos e-mails (confirmations, factures) arrivent-ils dans la boîte de réception, et pas en spam ?

Demain

17. L'application tiendra-t-elle à dix fois plus de clients ? Voir Votre application tiendra-t-elle à dix fois plus de clients ?.
18. Quelque chose vérifie-t-il automatiquement que l'application marche encore avant chaque mise en ligne (des tests) ?
19. Une autre personne que l'auteur saurait-elle relancer l'application à partir du code et de sa documentation ?
20. Quand vous demandez une modification à l'outil d'IA, savez-vous ce qu'il a changé ailleurs que là où vous regardiez ?

Lire vos résultats

• Que des oui : vous êtes dans une situation rare. Gardez la liste et repassez-la à chaque grosse évolution.
• Quelques non, aucun « je ne sais pas » : vous savez où vous en êtes ; traitez d'abord les questions 1, 4, 7 et 10, qui touchent l'argent et les données.
• Plusieurs « je ne sais pas », surtout dans « Les données de vos clients » ou « L'argent » : c'est le signal qu'un regard extérieur vous fera gagner du temps, avant qu'un client ne découvre le problème à votre place.

C'est ce que fait notre diagnostic : il répond à ces vingt questions et à quarante autres, preuves à l'appui, et vous dit par quoi commencer.