Ce qu’un fondateur doit vérifier avant de lancer un SaaS construit avec l’IA

L’IA a rendu la première version rapide. La preview fonctionne, la démo convainc, les premiers retours sont bons. La question qui reste avant d’ouvrir les portes est plus prosaïque : que se passe-t-il quand un inconnu s’inscrit, paie, se trompe, ferme l’onglet et revient le lendemain ? Voici ce que je vérifie avant un lancement, avec, pour chaque domaine, un test que vous pouvez faire vous-même.

« Ça marche » n’est pas « c’est prêt »

Une démo prouve le chemin heureux : un compte, un paiement de test, des données propres. La production ajoute ce que la démo n’a jamais vu — deux utilisateurs en même temps, une carte refusée, un webhook livré deux fois, un email qui n’arrive pas, un lien ouvert trois jours plus tard. Les outils d’IA produisent souvent un code qui fonctionne sur le chemin heureux ; ce qui manque est fréquemment ce qui ne se voit pas à l’écran : les contrôles côté serveur, les règles d’accès, les cas d’échec. Pas toujours. Mais assez souvent pour le vérifier plutôt que le supposer.

Huit domaines, un test chacun

Chaque domaine compte des dizaines de vérifications possibles. Voici celle que je ferais en premier : elle se fait sans outil, et un « non » change la décision de lancement.

Paiements : la page « merci » ne prouve rien

L’accès doit suivre l’état du paiement que Stripe confirme au serveur par un webhook signé — pas le retour du navigateur sur la page de succès, que n’importe qui peut ouvrir sans payer. Stripe peut aussi livrer le même événement plusieurs fois : le traitement doit produire le même résultat la deuxième fois que la première. Testez enfin la carte refusée et le remboursement : l’accès doit suivre dans les deux sens. Avant d’activer les clés live, ces trois tests en mode test valent plus qu’une relecture du code.

Données : le test des deux comptes

Avec Supabase, la protection des données repose souvent sur les règles RLS. Une table exposée sans RLS, ou avec une règle trop large, peut laisser un utilisateur lire les lignes d’un autre. Le test ne demande aucun outil : deux comptes, deux navigateurs, et l’identifiant d’un objet de l’un tenté depuis l’autre. Faites-le aussi en appelant l’API directement, pas seulement par l’interface : une interface peut masquer ce que l’API laisse passer.

Exploitation : les secrets et le retour arrière

Une clé privée placée dans une variable préfixée NEXT_PUBLIC_ finit dans le JavaScript envoyé au navigateur. Relisez la liste des variables de déploiement et l’historique Git. Puis posez-vous une question concrète : si le dernier déploiement casse l’inscription à 22 h, que faites-vous ? La réponse attendue tient en deux lignes — revenir au déploiement précédent, et savoir quoi faire d’une migration de base déjà passée.

Déclarer n’est pas vérifier

Quand vous cochez « oui » sur une checklist, vous déclarez. C’est utile — ça oriente — mais ce n’est pas une preuve. Dans mes rapports, chaque constat porte l’un de ces quatre niveaux :

• Déclaré : vous le dites ; personne ne l’a contrôlé.
• Observé par un outil : un scan, un test automatisé ou un inspecteur l’a relevé ; à confirmer dans le contexte réel.
• Vérifié par un expert : reproduit, testé ou inspecté par la personne qui signe le rapport, avec la preuve décrite.
• Non vérifié : dans le périmètre, mais pas contrôlé (accès, temps, environnement) — dit comme tel, jamais supposé correct.

Cette distinction évite la pire situation avant un lancement : croire qu’un point est vérifié parce que quelqu’un a répondu oui. L’auto-évaluation de Launch Rescue ne produit que des déclarations, et elle le dit.

Ce qu’est un stop-ship

Un stop-ship est un point à corriger — correction vérifiée — avant d’ouvrir à de vrais clients, parce que son échec touche directement l’argent, les données d’un autre utilisateur ou la possibilité d’entrer dans le produit. Un accès qui ne suit pas le paiement en est un ; un texte mal aligné sur mobile n’en est pas un. Le reste se range en « avant le lancement », « après le lancement » ou « facultatif », chaque fois avec une raison. Classer ainsi, c’est ce qui rend un lancement possible sans attendre une perfection qui n’existe pas.

Ce que les outils peuvent dire, et ce qu’ils ne peuvent pas

Un scan de code repère des motifs : une table sans instruction RLS, une variable publique qui ressemble à une clé, un fichier de webhook sans vérification de signature visible. C’est rapide et précieux. Mais un scan lit des fichiers. Il ne voit ni la configuration réellement déployée, ni les règles actives dans la base, ni ce qui se passe quand Stripe rejoue un événement. « Rien trouvé » veut dire « rien trouvé dans ce que l’outil sait lire », pas « rien à trouver ». Les outils accélèrent une revue ; ils ne la remplacent pas.

Quand demander de l’aide

Si vous pouvez répondre oui, preuve à l’appui, aux huit tests ci-dessus, vous êtes déjà plus loin que beaucoup de lancements. Sinon, trois options selon la situation :

• Un premier tour, gratuit, en dix contrôles : ShipCheck.
• Une revue de préparation au lancement, avec des constats prouvés, un plan priorisé et une recommandation sur le périmètre vérifié : Launch Rescue.
• Un seul défaut précis et confirmé à corriger : Code Rescue.

Pour une remédiation plus large, au-delà d’un lancement, il y a AI Product Rescue (page en anglais). Dans tous les cas, la bonne question n’est pas « mon application est-elle parfaite ? » — aucune ne l’est — mais « qu’est-ce que je sais vraiment, et qu’est-ce que je suppose ? ».