Tests smoke post-déploiement que les fondateurs peuvent exécuter en 10 minutes

Ce qu'est un smoke test (et pourquoi il compte après un déploiement)

Un smoke test est une vérification rapide que vous lancez juste après une release pour répondre à une question : le produit fonctionne-t-il encore sur les points qui comptent le plus ? Il ne s'agit pas de trouver tous les bugs. C'est une validation rapide oui/non qui attrape d'abord les pannes que rencontrent les vrais utilisateurs.

Pensez-y comme à l'ensemble minimal d'actions qu'un client ferait : se connecter, accomplir l'action principale (créer ou mettre à jour quelque chose), recevoir un e-mail important, et (si vous facturez) finaliser un paiement. Si l'une de ces étapes casse, vous voulez le savoir en quelques minutes, pas après une avalanche de tickets support.

Les smoke tests ne remplacent pas la QA complète. Ils ne supplantent pas les tests automatisés, les vérifications poussées des cas limites, les revues d'accessibilité ou les tests de sécurité. Et ils ne doivent pas prendre une heure. Si votre checklist de release nécessite un tableur et une réunion, elle sera sautée. L'idée est la rapidité et la répétabilité.

Beaucoup d'erreurs n'apparaissent qu'après le déploiement parce que la production se comporte différemment que votre poste de dev. Les causes sont souvent banales mais brutales : variables d'environnement incorrectes (clés API, réglages d'e-mail, webhooks de paiement), secrets tournés, différences de permissions, migrations appliquées mais incompatibles avec le code attendu, ou comportement de cache/CDN qui modifie des routes, cookies ou en-têtes.

Ceci est particulièrement utile pour les fondateurs qui livrent vite avec de petites équipes, et pour quiconque s'appuie sur du code généré par l'IA ou des prototypes rapides. Quand on va vite, un smoke test simple et constant peut faire la différence entre un lancement calme et une alerte générale.

Avant de commencer : 2 minutes de préparation

Un smoke test de 10 minutes marche mieux quand vous n'improvisez pas. Passez deux minutes à préparer un petit « kit de test » pour que les résultats soient clairs et reproductibles.

D'abord, choisissez les comptes exacts avec lesquels vous testez. Utilisez un compte utilisateur normal et un compte admin (ou les rôles que votre app a). Assurez-vous que ces comptes sont dans un état propre : pas d'onboarding à moitié fait, pas d'essai expiré, pas de profil verrouillé.

Ensuite, confirmez où vous testez. Notez l'environnement déployé (production, staging ou preview) et l'URL exacte. Beaucoup de « bugs » viennent du fait qu'on teste au mauvais endroit ou qu'on mélange deux versions.

Enfin, assurez-vous de pouvoir valider les deux choses qu'on ne voit pas toujours depuis l'UI : les e-mails et les paiements. Ayez une boîte de réception ouverte pour l'utilisateur de test (vérifiez spam/promotions). Si votre app facture, confirmez que vous êtes en bon mode (test vs live) et que vous pouvez accéder à l'endroit où vérifier une charge réussie.

Gardez une note simple ouverte et enregistrez les résultats au fur et à mesure. Ne comptez pas sur la mémoire.

Gardez prêts ces éléments :

• Identifiants du compte test et de l'admin
• Nom de l'environnement et URL testée
• Accès à la boîte de réception de test (et moyen de la rechercher)
• Où vérifier les résultats de paiement (si applicable)

Si quelque chose casse plus tard, ces notes (et une capture d'écran si nécessaire) économisent des heures d'échanges.

Les 10 minutes : le flux étape par étape

Lancez un minuteur de 10 minutes et suivez toujours le même parcours. L'objectif n'est pas de prouver que tout fonctionne. C'est de détecter les pannes qui empêchent les vrais utilisateurs d'avancer juste après le déploiement.

Utilisez une fenêtre de navigation privée pour ne pas obtenir un faux succès à cause d'une session en cache.

L'ordre fixe (n'improvisez pas)

Effectuez les vérifications dans une séquence stricte. Ainsi, vous pourrez comparer les résultats entre les releases et repérer précisément où ça a cassé.

1. Ouvrez l'app comme le ferait un nouvel utilisateur (page d'accueil vers l'app).
2. Connectez-vous (ou inscrivez-vous) et confirmez que vous arrivez sur l'écran attendu.
3. Réalisez l'action centrale de votre produit (créer, mettre à jour, et consulter l'entité principale).
4. Déclenchez une notification sur laquelle les utilisateurs comptent (e-mail ou in-app).
5. Si vous facturez, exécutez un petit flux de paiement de bout en bout en mode test.

Que faire quand quelque chose casse

Considérez la première panne sérieuse comme un panneau STOP. Ne continuez pas à cliquer « pour collecter plus d'infos ». Vous mélangerez les symptômes et perdrez du temps.

Rédigez une petite note de bug qui facilite la reproduction : ce que vous avez cliqué, ce que vous attendiez, ce qui s'est passé, et tout message d'erreur. Une capture d'écran aide, mais les étapes comptent davantage.

Après un correctif, retestez d'abord la zone cassée en suivant les mêmes étapes. Si ça passe, continuez dans l'ordre. Redétester de manière aléatoire crée de la confusion et masque les causes racines.

Décision Go/No-Go en une minute

Avant de déployer, décidez ce qui doit passer. Gardez la liste courte : la connexion fonctionne, le flux principal créer/éditer/consulter fonctionne, les e-mails critiques arrivent, et les paiements réussissent (si applicable). Si un élément « must-pass » échoue, c'est un no-go même si le reste a l'air OK.

Vérifications de connexion et d'authentification

La plupart des smoke tests commencent par l'auth, car une petite modification peut verrouiller tout le monde hors du système. Utilisez une fenêtre privée (ou un navigateur différent) pour ne pas utiliser une session en cache.

Les 5 vérifications qui attrapent la plupart des pannes d'auth

Exécutez ces étapes rapidement, dans l'ordre, et arrêtez-vous dès que quelque chose paraît anormal :

• Créez un compte tout neuf (si l'inscription est activée) et confirmez que vous arrivez sur la page prévue.
• Déconnectez-vous, puis reconnectez-vous avec le même utilisateur.
• Ouvrez une page protégée en étant déconnecté (par exemple l'URL du tableau de bord) et confirmez que vous êtes bloqué·e ou redirigé·e vers la page de connexion.
• Utilisez « mot de passe oublié » et complétez la réinitialisation. Confirmez que l'e-mail arrive et que le lien de reset fonctionne dans une fenêtre privée.
• Après la réinitialisation, reconnectez-vous et confirmez que vous restez connecté·e après un rafraîchissement.

Gardez le niveau simple. Vous vérifiez que l'app peut créer une session, la maintenir, et protéger les pages privées.

Une panne courante en production : après un déploiement, les cookies sont définis pour le mauvais domaine ou marqués « secure » d'une façon qui casse l'environnement. Le symptôme ressemble à « la connexion marche », mais chaque rafraîchissement vous déconnecte.

Si votre app supporte Google/GitHub, faites un test rapide avec eux aussi, mais ne laissez pas l'auth sociale remplacer la vérification e‑mail/mot de passe. L'auth sociale peut réussir alors que la gestion des sessions interne est cassée.

Quand une étape échoue, notez l'écran exact et le message que vous avez vu.

Flux CRUD principaux en moins de 3 minutes

CRUD signifie créer, lire, mettre à jour, supprimer. Si l'un de ces points casse après un déploiement, les utilisateurs le ressentent immédiatement. Le but n'est pas un test parfait, mais un signal rapide que l'app reste utilisable.

Choisissez un « objet » central de votre produit (un projet, une tâche, un client, une facture, une annonce). Utilisez un compte test et lancez la même boucle à chaque fois.

La boucle CRUD en 3 minutes

Allez vite et restez simple :

• Créez un nouvel enregistrement avec un nom court et unique comme « Smoke 2026-01-16 10:05. » Confirmez qu'il s'enregistre et que vous arrivez là où attendu.
• Retrouvez-le depuis la liste principale (ou le tableau de bord). Si la recherche ou les filtres sont importants, utilisez-les une fois.
• Éditez un champ évident (renommez). Vérifiez deux endroits où la valeur doit apparaître (page détail + vue liste).
• Supprimez-le. Confirmez qu'il a bien disparu après rafraîchissement, et pas seulement masqué.
• Testez une « mauvaise saisie » rapidement : laissez un champ requis vide, collez un texte très long, ou incluez des caractères spéciaux. Vous attendez des messages d'erreur clairs, lisibles par un humain.

Si quelque chose casse, notez précisément ce que vous avez fait et ce que vous avez vu. « Clic Sauvegarder -> spinner infini » est bien plus utile que « CRUD cassé. »

À quoi ressemble une bonne gestion d'erreur

Une bonne app bloque la mauvaise saisie avec un message court comme « Le nom est requis. » Une mauvaise app affiche une page blanche, du texte d'erreur brut, ou jette silencieusement les changements.

Si vous renommez un enregistrement et que la page détail se met à jour mais que la liste affiche encore l'ancien nom après rafraîchissement, c'est souvent un signe de cache, d'une mise à jour en arrière-plan qui a échoué, ou d'un déploiement partiel.

Vérifications d'e-mails et de notifications

Les e-mails sont souvent l'endroit où « tout avait l'air OK dans l'app » devient « les utilisateurs pensent que c'est cassé ». Un contrôle rapide des e-mails est l'une des parties les plus utiles d'un smoke test parce qu'il détecte les clés manquantes, les templates erronés et l'envoi bloqué.

Déclenchez un e-mail transactionnel réel depuis le produit (pas depuis un outil admin). De bons choix : reset de mot de passe, invitation, ou reçu.

Concentrez la vérification :

• Confirmez que l'e-mail arrive en quelques minutes.
• Vérifiez que l'adresse de l'expéditeur semble correcte (pas un placeholder).
• Parcourez pour détecter des problèmes de template évidents (par exemple {{name}} qui s'affiche).
• Cliquez sur le bouton principal et confirmez que vous arrivez sur la bonne page et que l'action fonctionne.

Surveillez les signes qui apparaissent souvent après un déploiement même quand l'UI a l'air OK : délais longs (workers/queues), doublons (retries sans idempotence), variables manquantes, branding/liens d'environnement erronés, ou liens qui s'ouvrent mais échouent à l'étape finale.

Si vous envoyez des e-mails d'invitation, faites un run complet : envoyez une invitation, ouvrez-la depuis un autre navigateur (ou fenêtre privée), acceptez-la, et confirmez que vous arrivez dans le bon workspace/compte.

Exemple : vous testez le reset de mot de passe, l'e-mail arrive, mais le bouton ouvre une page « token invalide ». C'est souvent une mismatch d'URL d'app, de domaine de cookie, ou de clés secrètes entre environnements.

Vérifications paiements et facturation

Les paiements échouent de façon prévisible après un déploiement : le checkout plante, le callback de succès n'atteint jamais votre app, ou l'utilisateur paye mais reste non payé. Un passage rapide sur les paiements est l'une des vérifications les plus précieuses.

Un paiement réussi

Choisissez le plan le moins cher (ou un article de test à 1$) et réalisez un achat complet : du pricing au reçu.

• Démarrez le checkout et confirmez le montant, la devise et le nom du plan.
• Finalisez le paiement et vérifiez que vous arrivez sur une page de succès claire.
• Rafraîchissez l'app et confirmez que l'état utilisateur a changé (plan actif, accès débloqué, crédits ajoutés, selon ce que vous vendez).
• Ouvrez l'écran compte/facturation et confirmez que le statut correspond à l'achat.

Si vous utilisez un webhook, c'est souvent là que les problèmes apparaissent. Échec courant : le paiement réussit mais l'accès n'est jamais mis à jour parce que le secret du webhook, l'endpoint ou la variable d'environnement a changé.

Chemins échoués, annulations et remboursements

Faites un run « mauvais » volontairement (annulez au checkout, utilisez une carte qui échoue, ou déclenchez un mode d'échec supporté par votre fournisseur). Les utilisateurs doivent voir un message normal, pas un spinner infini.

• Annulez ou faites échouer le paiement et confirmez que l'app explique ce qui s'est passé et que faire ensuite.
• Confirmez que l'utilisateur n'est pas marqué comme payé (pas d'accès, pas de crédits ajoutés).
• Si vous supportez les remboursements ou l'annulation d'abonnement, testez ce flux une fois et confirmez que le statut se met à jour après rafraîchissement.

Enfin, vérifiez ce que votre app affiche et envoie. L'UI et les e-mails ne doivent pas afficher de numéros de carte complets, codes de sécurité, clés API ou dumps d'erreur bruts. Règle simple : si vous ne le colleriez pas dans un chat support, ne l'affichez pas au client.

Checklist rapide (copiez et réutilisez)

Copiez ceci dans vos notes de release pour exécuter les mêmes vérifications à chaque fois. Restez cohérent. L'objectif est d'attraper les pannes usuelles du type « ça marchait hier » juste après le déploiement.

Release : __________ Date/heure : __________ Environnement : __________

Ce qui a changé dans cette release (1–2 lignes) :

Si quelque chose échoue, écrivez le plus petit détail utile pour déboguer : l'étape exacte, l'e-mail utilisateur utilisé, et le texte d'erreur.

Go/No-Go : ________ Responsable : ________ Si No-Go, rollback ? ________ Ticket(s) suivi : ________

Erreurs fréquentes qui font manquer de vraies pannes avec un smoke test

Le piège principal est de tester l'app que vous souhaiteriez avoir, pas celle que les utilisateurs obtiennent réellement. Un smoke test doit être un peu contraignant : session navigateur fraîche, domaine réel, données réelles, et mêmes permissions qu'un utilisateur normal.

Une erreur courante est de rester connecté·e en tant que développeur ou admin. Ça peut masquer des permissions cassées, des étapes d'onboarding manquantes, et des pages qui fonctionnent uniquement parce que vous avez des données préremplies. Utilisez une fenêtre incognito et un compte basique, ou créez-en un nouveau à chaque fois.

Un autre défaut est de tester le mauvais environnement. Si vous cliquez dans une preview alors que les clients utilisent la production, vous pouvez rater exactement les choses qui cassent après déploiement : variables d'environnement incorrectes, migrations manquantes, ou URL de callback mal configurée.

L'e-mail est particulièrement sournois. Il fonctionne souvent en local avec une boîte dev, puis échoue en production parce qu'une clé de fournisseur manque, un domaine d'envoi n'est pas vérifié, ou les messages atterrissent en spam. Traitez chaque déploiement comme si l'e-mail pouvait être cassé jusqu'à preuve du contraire.

L'auth est un autre point fréquent. Si vous ne testez que « la connexion marche », vous pouvez livrer un logout cassé, un reset de mot de passe HS, ou une expiration de session défaillante.

Quelques habitudes augmentent la valeur de votre smoke test :

• Testez en tant que nouvel utilisateur et en tant qu'utilisateur existant normal (pas seulement admin).
• Testez dans l'environnement réellement déployé, pas seulement local ou preview.
• Vérifiez qu'un e-mail réel arrive (et que le lien à l'intérieur fonctionne).
• Incluez toujours la déconnexion et la réinitialisation de mot de passe.
• Si quelque chose échoue, changez une seule chose, retestez, et notez ce qui a changé.

Ne sous-estimez pas « c'est juste lent aujourd'hui ». Les utilisateurs subissent les timeouts, cliquent deux fois, et rafraîchissent en plein chargement. Si une page est instable durant votre check de 10 minutes, c'est souvent le premier vrai bug en production.

Exemple : attraper une panne post-déploiement en quelques minutes

Maya gère un petit SaaS. Elle déploie un changement un vendredi qui « ne touche que l'UI ». Avant d'annoncer, elle lance son smoke test dans une fenêtre privée.

Tout a l'air OK jusqu'à la réinitialisation du mot de passe. Le formulaire accepte son e-mail et affiche un message de succès, mais aucun e-mail de reset n'arrive.

Plutôt que de deviner, elle explore vite. Elle crée un compte test tout neuf pour déclencher l'e-mail de bienvenue. Celui-ci arrive. Puis elle teste le changement d'e-mail (si l'app envoie une confirmation). Celui-ci arrive aussi. Donc ce n'est pas « tous les e-mails sont cassés ». C'est spécifiquement le parcours de reset.

Cela indique une panne post-déploiement courante : un template, un endpoint ou un job background qui échoue tandis que le reste du système semble sain. Dans le cas de Maya, le template du reset avait été déplacé vers un nouvel ID, mais la variable d'environnement en production pointait encore sur l'ancien.

Elle prend alors une décision simple :

• Si les utilisateurs ne peuvent plus se connecter, rollback d'abord, puis réparer.
• Si seuls les resets sont affectés et que la correction est sûre, pousser un hotfix.
• Dans tous les cas, poster une courte note de statut pour que le support ne soit pas surpris.

Elle choisit le hotfix, met à jour l'ID du template, redéploie, et relance le test reset. L'e-mail arrive en moins d'une minute.

Enfin, elle met à jour sa checklist pour la prochaine fois : « déclencher reset mot de passe et confirmer réception » et « vérifier le template/worker spécifique, pas seulement l'envoi général ».

Prochaines étapes quand quelque chose casse (et comment FixMyMess peut aider)

Quand un smoke test échoue, considérez-le comme un panneau STOP, pas une simple bosse. Si la même panne revient deux fois, bloque les inscriptions ou les paiements, ou ressemble à un problème de sécurité (données exposées, accès admin bizarre, clés fuitées), arrêtez la release et rollbackez si possible.

Règle simple : si les utilisateurs ne peuvent plus se connecter, créer des données, ou payer, vous n'êtes plus en train de tester — vous avez livré un produit cassé.

Capturez un petit paquet d'infos avant de demander une correction. Ça économise des heures et accélère la réparation :

• Étapes exactes que vous avez faites (1, 2, 3) depuis un onglet neuf
• Ce que vous attendiez vs ce qui s'est passé (inclure le texte d'erreur)
• Capture d'écran ou courte vidéo
• Horodatage et fuseau horaire
• Détails d'environnement (production vs staging, navigateur, e-mail du compte)

Puis transformez la checklist en habitude. Lancez-la juste après le déploiement, et encore après tout hotfix. Si vous suivez les incidents, taguez-les de façon cohérente (login, CRUD, e-mail, paiements) pour faire ressortir les tendances.

Si votre app a été générée par des outils comme Lovable, Bolt, v0, Cursor, ou Replit, les pannes post-déploiement sont souvent les symptômes de problèmes plus profonds : auth cassée, secrets exposés, architecture en désordre, ou requêtes DB dangereuses. Dans ce cas, patcher uniquement le message d'erreur n'est parfois pas suffisant.

Si vous héritez d'une base générée par l'IA qui plante constamment après déploiement, FixMyMess (fixmymess.ai) peut réaliser un audit de code gratuit puis corriger les causes racines, de la réparation d'auth et de logique à la sécurisation et la préparation au déploiement.