Parcourez la première session du client
Créez un compte frais dans l'environnement que vous prévoyez de publier. Suivez la vérification ou les callbacks fournisseur, rechargez l'application, modifiez un profil et déconnectez-vous. Répétez le parcours sur un écran étroit au clavier. Votre session de développement habituelle peut masquer des étapes de configuration manquantes et un état périmé.
Vérifiez les messages qui expliquent quoi faire ensuite. Un écran vide doit proposer une action utile. Une requête en échec doit expliquer comment réessayer sans laisser croire que le travail a réussi. Utilisez le langage du produit réel dans ces messages et assurez-vous que les liens de compte et de support mènent à de vraies destinations.
Répétez le parcours une fois par méthode de connexion. Les callbacks OAuth de Google et de GitHub portent chacun leurs propres redirections et modes d'échec (le guide de configuration OAuth couvre leur paramétrage), et l'écran de consentement de test d'un fournisseur se comporte différemment de celui de production.
- La création de compte et la restauration de session fonctionnent.
- La déconnexion révoque l'accès et efface la présentation de l'utilisateur précédent.
- Les états vide, chargement et erreur restent compréhensibles sur mobile.
- Chaque fournisseur OAuth boucle son callback sur le vrai domaine.
- Les e-mails de vérification et de réinitialisation arrivent, se lisent clairement et pointent vers le bon environnement.
- L'expérience de première utilisation dit au nouvel utilisateur quoi faire ensuite.
Prouvez l'accès payant côté serveur
Le checkout est la moitié facile. Parcourez tout le cycle de vie dans le sandbox du fournisseur : achat, webhook reçu et vérifié, droit d'accès persisté, fonctionnalité payante débloquée — puis renouvellement, annulation et remboursement. Chaque transition doit changer un état possédé par le serveur, pas seulement un drapeau client. Le guide de facturation montre où supastack conserve cet état.
Testez ensuite les événements que vous espérez ne jamais voir : un webhook livré deux fois, un paiement en échec, un abonnement qui expire au milieu d'une tâche. Un droit d'accès répond à « est-ce permis maintenant » au moment de la requête ; un badge de tableau de bord, non.
- Un achat en sandbox aboutit et débloque la fonctionnalité payante.
- Les livraisons de webhook en double sont sûres — le traitement est idempotent.
- L'annulation et le remboursement révoquent l'accès à la frontière serveur.
- Les limites par siège ou par usage, si elles existent, rejettent au-delà de leurs conditions.
Vérifiez les frontières avec de vraies dépendances
Utilisez deux comptes indépendants pour vérifier l'appartenance. Essayez de lire et de modifier l'enregistrement d'un compte depuis l'autre, y compris le statut de tâche et les URL de reprise. Vérifiez l'accès payant à la frontière de l'action serveur, pas seulement en cachant un bouton dans l'interface.
Les enregistrements rattachés à un espace de travail sont la colonne vertébrale d'un produit multi-tenant — l'article sur les frontières d'espace de travail explique le modèle. Quelle que soit votre stack, la question de lancement est la même : chaque lecture et écriture dérive-t-elle l'appartenance du contexte authentifié du serveur, sans qu'aucun ID d'enregistrement ni espace envoyé par le client ne soit accepté comme preuve ?
- Les lectures et écritures entre espaces sont rejetées.
- Les URL de reprise et de tâche ne donnent pas accès par elles-mêmes.
- Les vues liste et détail appliquent le même périmètre.
- Les clés API et webhooks, s'ils existent, portent aussi le périmètre d'espace.
Exercez les chemins d'échec exprès
Le travail en arrière-plan échoue de deux façons distinctes, et chacune exige son propre test. Un dispatch en échec laisse le client incertain sur la mise en file du travail — une clé d'idempotence bornée à la tâche et une soumission sauvegardée permettent à la reprise de réutiliser la requête originale au lieu de la dupliquer. Une fin en échec signifie que le travail a tourné mais que le résultat n'est jamais arrivé — les retries et l'interrogation de statut doivent combler cet écart sans seconde génération.
Appliquez le même raisonnement aux fournisseurs : un timeout du fournisseur IA, un e-mail qui rebondit, une erreur de l'API de facturation. Chacun doit aboutir à un état précis et explicable plutôt qu'à un demi-résultat silencieux. Le guide de reprise de tâches documente comment le chemin de production du kit gère cela.
- Un retry après un timeout de soumission ne duplique ni travail ni coût.
- Une fin en échec est visible et récupérable, pas une perte silencieuse.
- Les erreurs fournisseur parviennent à l'utilisateur comme des états honnêtes, pas comme des crashs génériques.
Préparez-vous au premier échec
Assurez-vous que quelqu'un puisse trouver une erreur, la relier à la tâche concernée et aider l'utilisateur à reprendre sans exposer les secrets fournisseur. Confirmez quels journaux et enregistrements d'audit existent, combien de temps vous les conservez et comment un opérateur y accède.
Décidez avant le lancement à quoi ressemble « quelque chose ne va pas » : livraisons de jobs en échec, erreurs de vérification de webhook, montée soudaine de la dépense fournisseur. Une alerte que personne ne reçoit n'est pas du monitoring — la configuration de l'observabilité couvre le câblage de ces signaux.
Traitez les sauvegardes comme un exercice opérationnel : une sauvegarde configurée n'est pas une sauvegarde restaurée. Exécutez la restauration une fois, sur des données qui ressemblent à la production, avant le jour où vous en aurez besoin.
- Une erreur peut être retracée jusqu'à la requête, l'utilisateur et la tâche qui l'ont causée.
- Les journaux et enregistrements d'audit ont un responsable, une politique de rétention et des règles d'accès.
- Une sauvegarde a été restaurée, pas seulement configurée.
- Les jobs en échec et les erreurs de webhook déclenchent une alerte qu'une personne reçoit.
Vérifiez les surfaces autour du produit
Les surfaces légales et de communication font partie du lancement, pas du polissage : des pages de confidentialité et de conditions qui décrivent ce que le produit fait réellement, une adresse de support qui atteint une personne, et un domaine d'expédition vérifié pour que l'e-mail transactionnel arrive depuis une adresse qui vous appartient.
Lisez chaque e-mail automatisé comme le ferait un client. Les messages de vérification, de réinitialisation, de reçu et de fin doivent porter le nom du produit, des liens vers le bon environnement et un chemin de réponse qui n'est pas une adresse noreply morte.
- Les pages de confidentialité et de conditions décrivent le produit que vous exploitez réellement.
- L'e-mail transactionnel part d'un domaine vérifié qui vous appartient.
- Les questions de support et de facturation ont une destination joignable.
Rendez la décision de lancement explicite
Assemblez le dossier de version : la révision du build, l'environnement cible, ce qui a été testé et comment, et ce qui reste non vérifié. Une checklist avec des lacunes assumées vaut mieux qu'un résumé confiant — c'est dans les lacunes que vit généralement le premier incident.
Décidez le chemin de retour en arrière avant d'en avoir besoin : comment annuler le déploiement, ce qu'il advient des données écrites entre-temps, et qui tranche. Lancez ensuite la plus petite version de l'offre que vous pouvez pleinement supporter, puis élargissez-la délibérément.
Questions fréquentes sur le lancement
Les checklists de lancement échouent à des endroits prévisibles. Voici les questions qui en attrapent la plupart.
- Qu'oublient la plupart des lancements SaaS ? — Les extrémités des flux : une déconnexion qui révoque vraiment, une annulation qui retire vraiment l'accès, et un exercice de restauration pour la sauvegarde qui existe sur le papier.
- De combien de comptes de test ai-je besoin ? — Au moins deux, dans l'environnement cible. L'isolation des données et les flux d'invitation ne se vérifient pas avec un seul.
- Tester en sandbox ou en production ? — Les deux. Le sandbox prouve la logique du cycle de vie ; une petite transaction réelle prouve que clés, domaines et webhooks sont câblés au bon endroit.
- Quand peut-on lancer en sécurité ? — Quand chaque élément qui protège les données ou l'argent des clients est vérifié, et que les éléments non vérifiés sont écrits avec des responsables — pas quand la liste de fonctionnalités paraît complète.
- Qu'est-ce qui change après le lancement ? — Gardez le dossier de version, surveillez les alertes d'échec que vous avez configurées, et ré-exécutez la checklist après tout changement notable d'auth, de facturation ou de périmètre.