Comment tester votre application avant le lancement : plan pratique

Pour tester votre application avant le lancement, listez les quelques parcours qu'un utilisateur doit pouvoir accomplir, exécutez chacun comme un nouvel utilisateur sur un ordinateur portable et un téléphone, puis essayez les façons dont il pourrait se tromper : données vides, saisies erronées, second compte, connexion lente. Testez avec un soin particulier tout ce qui touche à l'argent ou aux données privées, et répétez les parcours principaux sur l'URL en direct après la publication. Terminez en observant quelqu'un qui n'a jamais vu l'application essayer de s'en servir.

Vous n'avez pas besoin d'une équipe d'assurance qualité ni d'un cadre de test pour cela. Vous avez besoin d'une liste, d'une heure ou deux, et de la discipline de la parcourir réellement.

Étape 1 : Notez les parcours qui comptent

Un parcours est une tâche du début à la fin qu'un utilisateur vient accomplir. La plupart des applications en ont trois à six qui comptent vraiment. Pour une application de réservation :

S'inscrire et confirmer le compte
Trouver un cours et le réserver
Annuler une réservation
Payer un forfait de cours
Personnel : voir les réservations du jour

Si vous avez rédigé des récits d'utilisateur, leurs critères d'acceptation sont déjà vos cas de test. Sinon, rédigez une ligne par parcours avec ce que signifie « réussi ».

Classez-les par ordre d'importance. Les parcours qui génèrent de l'argent ou que chaque utilisateur emprunte (inscription, connexion, action centrale) sont testés en premier et le plus à fond.

Étape 2 : Testez le parcours idéal comme un nouvel utilisateur

Le « parcours idéal » est le parcours qui se déroule exactement comme prévu. Testez-le comme le vivrait un inconnu :

Utilisez une fenêtre de navigation privée, pour ne pas être connecté et ne pas avoir de données enregistrées.
Utilisez un compte tout neuf avec un vrai courriel que vous pouvez consulter.
Commencez par la page d'accueil ou un lien, et non par une page mise en signet pendant la création.

Les nouveaux utilisateurs n'ont aucune donnée. Beaucoup de bogues n'apparaissent que lorsqu'une liste est vide, qu'un profil n'a pas de photo ou que rien n'a encore été acheté. Votre propre compte, rempli de données de test, les cache.

Étape 3 : Essayez de la briser

Refaites maintenant chaque parcours et faites volontairement la mauvaise chose.

Essayez ceci	Ce que vous vérifiez
Soumettre des formulaires vides, ou avec seulement des espaces	Les champs obligatoires sont exigés, avec un message clair
Texte très long, emojis, noms avec accents	La mise en page tient, les données s'enregistrent correctement
Mauvais formats : des lettres dans un champ de téléphone, une date passée	Validation sur la page et sur le serveur
Double-clic sur le bouton de soumission	Aucune commande ou réservation en double
Bouton précédent du navigateur au milieu du parcours	Aucun état brisé ni donnée perdue
Actualiser chaque page	Les données persistent; aucune page blanche ni erreur 404
Se déconnecter, puis appuyer sur précédent	Les pages privées ne s'affichent pas
Deux onglets modifiant la même chose	La dernière sauvegarde n'efface pas silencieusement la première

L'actualisation mérite une mention spéciale : si l'application fonctionne lorsque vous cliquez, mais qu'une actualisation sur une page plus profonde affiche une erreur 404, consultez comment corriger les erreurs 404 après un déploiement.

Étape 4 : Testez les autorisations avec deux comptes

C'est le test le plus important pour toute application avec des comptes, et celui qu'on oublie le plus souvent.

Créez deux utilisateurs normaux, A et B, et (si votre application en prévoit) un administrateur.

En tant que A, créez un enregistrement. Connectez-vous comme B. B peut-il le voir, le modifier ou le supprimer? Il ne devrait pas, à moins que ce soit la conception voulue.
En tant que A, copiez l'URL d'un de vos enregistrements. Connectez-vous comme B et ouvrez directement cette URL.
En tant qu'utilisateur normal, ouvrez les pages d'administration en tapant leurs URL.
Déconnectez-vous complètement et essayez les mêmes URL.

Si vous trouvez un problème ici, ne lancez pas tant qu'il n'est pas corrigé. La vérification doit se faire sur le serveur, et non seulement en cachant un bouton. Notre liste de contrôle de sécurité pour applications créées par IA va plus loin.

Étape 5 : Testez sur de vrais appareils

Ouvrez l'application sur un vrai téléphone, et non seulement dans une fenêtre de navigateur étroite.

Pouvez-vous toucher chaque bouton sans zoomer?
Le clavier cache-t-il le champ dans lequel vous écrivez?
Les tableaux et le contenu large défilent-ils ou se replient-ils, plutôt que de pousser la page latéralement?
Le texte est-il lisible sans pincer l'écran?

Essayez au moins un iPhone (Safari) et un téléphone Android (Chrome), si vous pouvez en emprunter. Safari, en particulier, a ses propres particularités avec les dates, les vidéos et les éléments à position fixe.

Étape 6 : Testez l'argent et le courriel de bout en bout

Tout ce qui débite des cartes ou envoie des courriels exige un essai complet.

Paiements. Utilisez le mode test de votre fournisseur de paiement et ses numéros de carte de test. Vérifiez un paiement réussi, une carte refusée et un paiement annulé. Confirmez que la commande ou l'abonnement apparaît dans votre application après le paiement, et pas seulement dans le tableau de bord du fournisseur. Si votre application dépend de webhooks (messages que le fournisseur de paiement envoie à votre serveur), vérifiez qu'ils arrivent sur l'application publiée, et pas seulement en développement. Ensuite, avant le lancement, passez aux clés réelles et effectuez un petit achat réel que vous remboursez.

Courriels. Inscrivez-vous avec de vraies adresses chez deux ou trois fournisseurs différents. Vérifiez que les courriels arrivent, ne tombent pas dans les pourriels, et que chaque lien pointe vers le domaine en direct, et non vers une adresse de prévisualisation.

Étape 7 : Vérifiez la vitesse et les erreurs

Ouvrez les outils de développement du navigateur (clic droit → Inspecter) et regardez l'onglet Console sur chaque page principale. Les erreurs en rouge valent la peine d'être corrigées, même si rien ne semble brisé.
Chargez le site sur un téléphone avec les données cellulaires, et non le Wi-Fi. Si le premier écran prend plusieurs secondes, vérifiez d'abord la taille des images.
Exécutez un audit gratuit comme Lighthouse dans les outils de développement de Chrome pour une lecture rapide de la performance et de l'accessibilité.

Étape 8 : Testez l'application publiée, et non seulement l'aperçu

Un aperçu et une application publiée ne sont pas le même environnement. Avant d'annoncer le lancement, reprenez les parcours principaux sur l'URL en direct :

Toutes les variables d'environnement et tous les secrets sont-ils définis pour l'application publiée?
Utilise-t-elle la bonne base de données, avec les données attendues?
Les redirections de connexion et les liens de courriel utilisent-ils le domaine en direct?
Une actualisation sur une page profonde charge-t-elle correctement?

Étape 9 : Observez quelqu'un d'autre l'utiliser

Donnez à une ou deux personnes un objectif (« réserver un cours de yoga pour samedi »), et non des instructions. Observez sans aider, et notez où elles hésitent. C'est le moyen le plus rapide de repérer une formulation confuse et des boutons cachés. Pour une version plus poussée de cet exercice, consultez comment mener un test bêta.

Lorsqu'elles rencontrent un bogue, notez-le correctement, avec les étapes, le résultat attendu et le résultat réel. Notre guide sur la rédaction d'un bon rapport de bogue présente le format.

Utiliser l'IA pour vous aider à tester

Si vous créez avec l'IA, vous pouvez lui demander d'aider à planifier et à exécuter les tests :

Liste les principaux parcours utilisateur de cette application et, pour chacun, les cas limites les plus susceptibles de briser : états vides, saisies invalides, autorisations et actualisation. Présente-les sous forme de liste de vérification que je peux parcourir.

Connecte-toi avec deux utilisateurs de test différents et vérifie si l'utilisateur B peut voir ou modifier quoi que ce soit créé par l'utilisateur A, y compris en ouvrant directement les URL des enregistrements de A. Signale ce que tu trouves avant de corriger quoi que ce soit.

Considérez le rapport de test de l'IA comme une première passe. Parcourez quand même vous-même les parcours d'argent et d'autorisations.

Tester dans Mythex

Dans Mythex, la commande /test lance le test d'application : l'agent pilote un navigateur sur votre aperçu en direct, parcourt les pages, capture des images d'écran et signale les parcours brisés dans le clavardage. Elle fonctionne mieux avec un parcours précis, comme « tester l'inscription et la réservation d'un cours ». Corrigez ce qu'elle trouve avec /fix ou un message normal, puis relancez /test. Le test d'application utilise l'aperçu; vérifiez donc vous-même les parcours principaux sur l'URL publiée après la publication. Voir Tests d'application dans la documentation, et notre guide sur le débogage d'une application créée par IA pour quand quelque chose échoue.

Erreurs courantes

Tester seulement en tant que vous-même. Votre compte administrateur rempli de données cache les bogues d'état vide et d'autorisations.
Tester seulement sur un ordinateur portable. La plupart des visiteurs de nombreux sites arrivent sur un téléphone.
Sauter le second compte. Les données qui fuient entre utilisateurs sont le bogue le plus grave avec lequel une application puisse être lancée.
Faire confiance à l'aperçu. L'application en direct a des paramètres différents; testez-la aussi.
Corriger des bogues sans retester les zones voisines. Une correction dans un formulaire peut en briser un autre qui partage le même code.

Liste de vérification avant le lancement

Parcours principaux listés et classés
Chaque parcours réussit comme nouvel utilisateur dans une fenêtre privée
Saisies vides, invalides, longues et en double gérées
L'actualisation fonctionne sur chaque page
Les utilisateurs ne peuvent pas voir ni modifier les données des autres, même par URL
Pages d'administration bloquées pour les utilisateurs normaux et les visiteurs non connectés
Fonctionne sur un vrai iPhone et un vrai téléphone Android
Paiements testés : réussite, refus, annulation, et l'application se met à jour ensuite
Les courriels arrivent, évitent les pourriels et pointent vers le domaine en direct
Aucune erreur rouge dans la console sur les pages principales
Parcours principaux repris sur l'URL publiée
Au moins une personne extérieure l'a essayée pendant que vous observiez

Questions

Combien de tests une petite application a-t-elle besoin avant le lancement?

Assez pour être certain que les parcours principaux fonctionnent pour un nouvel utilisateur sur un téléphone et un ordinateur portable, que les utilisateurs ne peuvent pas voir les données des autres, et que tout ce qui touche à l'argent fonctionne de bout en bout. Pour la plupart des petites applications, cela représente quelques heures ciblées, et non des semaines.

Ai-je besoin de tests automatisés pour un MVP?

Pas nécessairement. Les tests manuels des parcours essentiels détectent la plupart des bogues qui bloqueraient le lancement. Les tests automatisés deviennent rentables lorsque vous modifiez souvent l'application et voulez savoir rapidement si vous avez brisé quelque chose qui fonctionnait auparavant.

Dois-je tester sur l'aperçu ou sur l'application en direct?

Les deux. Testez à fond dans l'aperçu, puis reprenez les parcours principaux sur l'application publiée, car des variables d'environnement manquantes, une autre base de données ou des paramètres de routage peuvent faire fonctionner la version en direct différemment.

Qui devrait tester mon application en plus de moi?

Au moins une personne qui ne l'a jamais vue. Donnez-lui un objectif, et non des instructions, puis observez sans aider. Les créateurs évitent inconsciemment les chemins qui brisent.