Plan de test d’application mobile : le modèle Excel et 25 cas rédigés
Un plan de test est le document qui liste, avant la mise en production, les cas à vérifier un par un, la façon de les exécuter et le résultat attendu de chacun.
Page mise à jour le 12 septembre 2026. Modèle relu et remis à jour à chaque millésime.
Le moment où une application se casse la figure n’est presque jamais celui qu’on redoutait. Ce n’est pas la fonctionnalité complexe qui lâche, c’est le retour dans l’application après trois heures en arrière-plan, le paiement relancé sur un réseau qui vacille, le clavier qui recouvre le champ sur un modèle qu’on n’avait pas. Un plan de test sert à écrire ces situations avant de les découvrir en production.
Ce que contient un plan de test, et ce qu’il ne contient pas
Un plan de test tient en une feuille de calcul et deux pages de texte. La feuille porte les cas, une ligne chacun. Les deux pages portent le cadre : ce qu’on teste, sur quels appareils, avec quelles données, qui exécute, et à quelles conditions on accepte de mettre en production. Ce cadre s’écrit une fois et resservira à chaque version.
Ce que le document ne contient pas : le code des tests automatisés, le détail de l’architecture, la liste des anomalies. Les anomalies vivent dans votre outil de suivi et le plan ne porte que leur identifiant. Mélanger les deux produit un fichier que personne ne tient à jour au bout de trois semaines.
La distinction utile est celle du cas et du scénario. Un scénario décrit un parcours complet, par exemple commander et retirer. Un cas vérifie une assertion précise à l’intérieur de ce parcours, par exemple qu’un créneau devenu complet pendant la saisie ne fait pas perdre le panier. Un scénario se raconte, un cas se coche. C’est le cas qu’on écrit dans le tableur.
Le lien avec les user stories est direct et il fait gagner un temps considérable : chaque critère d’acceptation écrit sous la forme « étant donné … lorsque … alors … » est déjà un cas de test. Les trois morceaux donnent respectivement les conditions initiales, les étapes et le résultat attendu. Une équipe qui a écrit ses critères avant le développement n’écrit pas son plan de test, elle le recopie.
Écrire un cas qui se rejoue sans poser de question
Le test qui compte n’est pas celui que son auteur exécute, c’est celui qu’une autre personne rejoue trois mois plus tard sans rien demander. Cette exigence commande toute la rédaction : pas de « vérifier que ça marche », pas de « tester le panier », pas d’étape implicite.
- Un identifiant stable. CT-014 ne se réutilise jamais, même après suppression du cas. C’est lui qu’on cite dans un écart et dans une décision de mise en production.
- Les conditions initiales. Quel compte, quelles données, quel état de départ. « Un compte avec trois commandes passées et 120 points de fidélité » vaut mieux que « un compte client ».
- Les étapes numérotées. Une action par ligne, à l’impératif, avec ce sur quoi on appuie. Trois à sept étapes ; au-delà, le cas en cache deux.
- Le résultat attendu, unique et observable. Un montant, un écran, un message, un délai. « Le panier est conservé et le message indique les deux créneaux suivants » se constate ; « le comportement est correct » ne se constate pas.
- La criticité. Bloquant, majeur, mineur. C’est elle qui décide de l’ordre d’exécution et de la décision de mise en production, pas l’ordre du tableau.
- L’appareil et la version du système. Un écart sans cette information n’est pas reproductible, et la moitié des écarts mobiles en dépendent.
Le résultat obtenu se remplit à l’exécution, et il mérite mieux qu’une croix. Écrire ce qui s’est réellement passé, même en quatre mots, épargne l’aller-retour où le développeur répond « je n’arrive pas à reproduire ». Le modèle réserve une colonne pour cela, à côté du statut.
Une dernière habitude qui paye : tester la version qui partira réellement, celle qui est signée et distribuée, pas celle qui tourne sur le poste de développement. Beaucoup d’écarts n’apparaissent que sur la version distribuée, parce que le code y est optimisé et les droits différents.
Ce qu’il faut vérifier sur mobile et nulle part ailleurs
Un plan de test repris d’un projet web laisse passer les trois quarts de ce qui casse une application. Les cas ci-dessous n’existent que sur téléphone, et ils reviennent projet après projet.
- La coupure de réseau en cours d’action. Pendant la saisie du panier, pendant le paiement, pendant l’envoi. Le cas critique est le paiement : au retour du réseau, l’utilisateur doit savoir sans ambiguïté si son argent est parti.
- Le retour d’arrière-plan. L’application est mise de côté trois heures, le système la purge, l’utilisateur y revient. Session expirée, données périmées, écran restauré au mauvais endroit : trois cas distincts.
- Les permissions refusées. Localisation, notifications, appareil photo. Refuser une permission doit laisser l’application utilisable, et le chemin de rattrapage doit exister quand l’utilisateur change d’avis dans les réglages du téléphone.
- Le clavier et les tailles de police. Le clavier qui recouvre le champ en cours de saisie, et la police système agrandie qui tronque un bouton. Deux cas, deux appareils, cinq minutes, et ils évitent des avis négatifs.
- La montée de version. Installer l’ancienne version, s’en servir, installer la nouvelle par-dessus. Les données locales doivent survivre. Ce cas ne se teste jamais sur une installation neuve, et c’est pour cela qu’il casse.
- Les interruptions. Appel entrant pendant le paiement, batterie faible, rotation de l’écran, notification système. Rares individuellement, fréquentes cumulées.
Le choix du parc d’appareils mérite deux minutes de réflexion plutôt qu’un réflexe. Prenez les deux modèles les plus représentés chez vos utilisateurs réels, la version de système la plus ancienne que vous annoncez supporter, un appareil à petit écran et un appareil à grand écran. Cinq combinaisons suffisent à couvrir l’essentiel, et elles se décident avant la campagne, pas pendant.
Les tests automatisés ne remplacent pas ce plan, ils le déchargent. Une fois qu’un cas est automatisé, il quitte la liste manuelle et rejoint la campagne automatique. Le plan reste la référence de ce qui doit être vérifié ; la façon de le vérifier peut changer.
Mener une campagne de tests avant une mise en production
- Constituer la liste des cas. Reprenez les critères d’acceptation de chaque user story livrée. Un critère donne un cas, avec son identifiant, son module et sa criticité.
- Définir le parc d’appareils. Choisissez cinq combinaisons appareil et version de système qui couvrent votre audience réelle, la plus ancienne version supportée comprise. Écrivez-les dans le plan avant de commencer.
- Exécuter les cas bloquants d’abord. Jouez les cas de criticité haute sur tous les appareils, les autres sur deux appareils. Notez le résultat obtenu, pas seulement « OK » ou « KO ».
- Qualifier chaque écart. Un écart porte son identifiant de cas, sa criticité, l’appareil, la version de l’application et les étapes exactes qui le reproduisent. Sans ces cinq éléments, il repart en aller-retour.
- Rejouer après correction. Rejouez le cas corrigé et les cas voisins du même module. Une correction sur trois casse autre chose, c’est le principal intérêt d’avoir la liste écrite.
- Prononcer la décision de mise en production. Zéro cas bloquant ouvert, les cas majeurs tracés avec une date de correction, le tableau de bord joint à la décision. C’est le document qu’on relit six mois plus tard.
Le document
Les fichiers ci-dessous sont libres d’usage, y compris pour un projet commercial. Ils portent le nom du site en pied de page, rien d’autre : ni logo imposé, ni mention à conserver. Le formulaire plus haut sert à les recevoir par courriel, le téléchargement direct fonctionne sans rien laisser.
Un exemple rempli : le cas fictif Rondo
Extrait du plan de test du cas d’école fictif Rondo, une application inventée pour la démonstration : commande à l’avance et fidélité pour un réseau de soixante-deux boulangeries indépendantes. Le tableur contient vingt-cinq cas complets. En voici six, dans leur forme exacte.
- CT-004 · Commande · bloquant
- Conditions : boutique ouverte, panier à 2 produits, créneau de 8 h 15 disponible. Étapes : 1. sélectionner le créneau, 2. valider le panier, 3. confirmer. Attendu : commande confirmée, numéro de retrait affiché, créneau décompté d’une unité côté boutique. Appareils : les 5 du parc.
- CT-007 · Commande · bloquant
- Conditions : panier à 2 produits, créneau de 8 h 15 rempli par un autre client pendant la saisie. Étapes : 1. valider le panier, 2. confirmer. Attendu : message indiquant que le créneau n’est plus disponible, les deux créneaux suivants proposés, panier intact. Appareils : 2.
- CT-011 · Paiement · bloquant
- Conditions : paiement en cours, réseau coupé à l’instant de la validation. Étapes : 1. valider le paiement, 2. couper le réseau, 3. rétablir le réseau, 4. rouvrir l’application. Attendu : un seul débit, statut de la commande affiché sans ambiguïté, aucun double paiement. Appareils : les 5.
- CT-016 · Fidélité · majeur
- Conditions : compte avec 120 points, application en arrière-plan depuis plus de 3 heures. Étapes : 1. rouvrir l’application. Attendu : le solde affiché date de moins de 5 minutes, ou porte la mention de sa date de mise à jour si le réseau est absent. Appareils : 3.
- CT-019 · Compte · bloquant
- Conditions : compte connecté, aucune commande en cours. Étapes : 1. ouvrir les réglages, 2. demander la suppression du compte, 3. confirmer. Attendu : compte désactivé immédiatement, message indiquant le délai d’effacement, déconnexion. Appareils : 2.
- CT-023 · Technique · majeur
- Conditions : version précédente installée et utilisée, 2 commandes dans l’historique. Étapes : 1. installer la nouvelle version par-dessus, 2. ouvrir l’application. Attendu : session conservée, historique intact, aucune demande de reconnexion. Appareils : 2.
Remarquez que CT-011 et CT-023 ne testent aucune fonctionnalité nouvelle. Ils testent des situations. Ce sont pourtant les deux cas de cette liste qui, dans un projet réel, rattrapent le plus d’argent : un double paiement se rembourse et se raconte, une montée de version qui efface l’historique se paye en désinstallations.
Les erreurs qui coûtent le plus cher
- Un plan écrit après le développement. Écrit après, il décrit ce qui a été fait. Écrit à partir des critères d’acceptation, avant, il décrit ce qui était attendu. C’est la même différence qu’entre un contrôle et une justification.
- Des cas non reproductibles. « Vérifier que le panier fonctionne » n’est pas un cas. Conditions initiales, étapes numérotées, un seul résultat attendu observable : sans ces trois éléments, le cas ne se rejoue pas et il ne sert qu’une fois.
- Un seul appareil de test. Tester sur le téléphone du chef de projet donne une couverture illusoire. Cinq combinaisons choisies à l’avance, dont la version de système la plus ancienne supportée, coûtent une demi-journée et attrapent la majorité des écarts d’affichage.
- Les cas d’interruption jamais joués. Réseau coupé, retour d’arrière-plan, permission refusée, montée de version : ces quatre familles représentent une part importante des écarts réels et zéro pour cent des plans repris d’un projet web.
- Aucune règle de décision écrite. Sans critère annoncé à l’avance, la mise en production se décide à l’ambiance un vendredi soir. Écrivez-le une fois : zéro cas bloquant ouvert, cas majeurs tracés avec une date. Cela clôt la discussion.
Plan de test et devis : ce que le prestataire en fait
La campagne de validation est un poste de devis à part entière, et c’est l’un des premiers que les propositions serrées rabotent. Un plan de test joint à la consultation rend ce poste visible : l’agence chiffre un nombre de cas et un parc d’appareils, pas une intention de « bien tester ». Vous pouvez alors comparer deux devis sur cette ligne comme sur les autres.
C’est aussi le document qui définit la fin. Tant que personne n’a écrit ce qu’on vérifie et à quelles conditions on accepte, la livraison se discute indéfiniment. Un plan validé des deux côtés avant le développement transforme cette discussion en constat.
Pour la suite, notre guide du cahier des charges d’application mobile décrit le périmètre à tester, et la grille de lecture d’un devis d’application mobile explique poste par poste ce que vous devez retrouver en face, campagne de validation comprise.
Les autres modèles de la rubrique
Ce que contient chaque ligne du tableur
| Colonne | Ce qu’on y met | Le piège à éviter |
|---|---|---|
| Identifiant | CT-001, stable, jamais réutilisé | Renuméroter après une suppression casse toutes les références |
| Conditions initiales | Compte, données, état de départ | « Un compte client » : trop vague pour être rejoué |
| Étapes | 3 à 7 actions numérotées, à l’impératif | Au-delà de 7, le cas en cache deux |
| Résultat attendu | Un seul, observable et chiffré si possible | « Le comportement est correct » ne se constate pas |
| Criticité | Bloquant, majeur, mineur | Tout classer bloquant vide la colonne de son sens |
| Appareil et version | Modèle et version du système | Sans elle, la moitié des écarts mobiles ne se reproduisent pas |
| Résultat obtenu | Ce qui s’est passé, en clair | Une croix seule déclenche l’aller-retour « je ne reproduis pas » |
Plan de test : questions fréquentes
Qu’est-ce qu’un plan de test ?
C’est le document qui liste, avant une mise en production, les cas à vérifier un par un, avec pour chacun les conditions de départ, les étapes exactes, le résultat attendu et l’appareil sur lequel il a été joué. Il fixe aussi le cadre : parc d’appareils, données de test, et les conditions auxquelles on accepte de livrer.
Comment écrire un cas de test ?
En six éléments : un identifiant stable, les conditions initiales décrites précisément, trois à sept étapes numérotées à l’impératif, un résultat attendu unique et observable, une criticité, et l’appareil avec sa version de système. Le test réussi est celui qu’une autre personne rejoue trois mois plus tard sans poser de question.
Quelle différence entre un scénario et un cas de test ?
Le scénario décrit un parcours complet, par exemple commander puis retirer sa commande. Le cas vérifie une assertion précise à l’intérieur de ce parcours. Un scénario se raconte, un cas se coche. C’est le cas qu’on écrit dans le tableur, parce que c’est lui qui se rejoue à l’identique.
Sur combien d’appareils faut-il tester une application mobile ?
Cinq combinaisons bien choisies suffisent dans la plupart des projets : les deux modèles les plus représentés chez vos utilisateurs réels, la version de système la plus ancienne que vous annoncez supporter, un petit écran et un grand écran. Ce choix se fait avant la campagne et s’écrit dans le plan.
Qui exécute le plan de test, le client ou l’agence ?
Les deux, sur des périmètres différents. L’agence vérifie que le produit fait ce qui est écrit, en continu pendant le développement. Le client vérifie que le produit répond à son besoin métier, sur les données et les cas d’usage qu’il est seul à connaître. Le même tableur sert aux deux, avec une colonne pour dire qui a joué le cas.
Les tests automatisés remplacent-ils un plan de test ?
Non, ils le déchargent. Le plan reste la liste de ce qui doit être vérifié ; l’automatisation change seulement la façon de le vérifier. Quand un cas est automatisé, il quitte la liste manuelle et rejoint la campagne automatique, mais il continue de figurer au plan avec sa criticité.
Un avis technique sur votre périmètre en trente minutes ?
Décrivez votre application en quinze minutes : vous repartez avec un avis technique sous 48 h. Périmètre, technologies pertinentes et ordre de grandeur budgétaire. Sans engagement.
Ou par téléphone 06 32 64 24 80
Les modèles de documents de projet
Expression de besoin, note de cadrage, user stories, matrice de priorisation, roadmap produit : les documents s’enchaînent, et le même cas d’école fictif les traverse tous.