Avant le lancement d’une application, la recette doit vérifier les parcours qui engagent le métier, les droits, les données et la continuité de service. Partez des conséquences d’un échec, écrivez des scénarios reproductibles et fixez à l’avance les anomalies qui bloquent la mise en ligne. Les tests techniques du prestataire restent nécessaires, mais ils ne remplacent pas l’acceptation par les personnes qui connaissent le travail réel.
Méthode vérifiée en septembre 2026. Les exemples de cet article sont illustratifs et ne décrivent pas un client de Klaapp.
La recette d’application accepte un risque, pas l’absence de tout défaut
La recette d’application sert à décider si une version précise peut être ouverte à ses utilisateurs dans des conditions maîtrisées. Elle ne prouve pas que le logiciel ne contient aucun défaut. Elle apporte une preuve plus utile : les opérations prioritaires ont été exécutées dans un environnement représentatif, leurs résultats ont été comparés aux attentes et les écarts restants sont connus.
Cette distinction évite deux extrêmes. « Cliquer partout » produit beaucoup d’activité sans dire ce qui a réellement été vérifié. Attendre une application parfaite bloque la sortie sans définir de seuil observable. La bonne question est : quel problème rendrait le lancement inacceptable pour l’utilisateur ou pour l’entreprise ?
Pour une application de réservation, un alignement imparfait peut attendre une correction. Un paiement débité sans confirmation, une réservation attribuée au mauvais compte ou une équipe incapable de retrouver l’opération doivent normalement bloquer. La priorité vient de la conséquence, pas de la difficulté technique du correctif.
Quelle différence entre tests techniques, recette métier et test utilisateur ?
Les tests techniques, la recette métier et le test utilisateur répondent à trois questions différentes. Les fusionner dans une seule colonne « testé » masque les responsabilités et laisse des risques sans propriétaire.
| Contrôle | Question posée | Responsable principal | Preuve attendue |
|---|---|---|---|
| Tests techniques | Le code se comporte-t-il comme prévu, y compris après une modification ? | Équipe de développement | résultats automatisés, journaux, rapport de sécurité ou de performance selon le risque |
| Recette métier | Le produit permet-il d’accomplir les opérations promises avec les bonnes règles ? | Référent métier ou product owner, accompagné par le prestataire | scénarios exécutés, résultats constatés, anomalies classées et décision signée |
| Test utilisateur | Des personnes représentatives comprennent-elles le parcours et réussissent-elles la tâche ? | Équipe produit ou UX avec des utilisateurs ciblés | observations, difficultés, contexte des participants et décisions de conception |
Un test automatisé peut confirmer qu’une annulation recalcule un solde selon une règle. Le responsable métier doit encore confirmer que cette règle correspond au fonctionnement attendu. Un test utilisateur peut révéler que le bouton d’annulation n’est pas compris, sans démontrer à lui seul la conformité technique ou l’accessibilité de l’ensemble.
Le W3C recommande de combiner l’évaluation avec des utilisateurs et les contrôles de conformité pour l’accessibilité. Une personne peut révéler un obstacle concret ; son expérience ne permet pas de généraliser à tous les handicaps ni de remplacer un audit fondé sur les standards (W3C WAI).
Comment choisir les scénarios à tester avant la mise en ligne ?
Choisissez les scénarios de recette à partir des risques, puis couvrez le parcours nominal, ses limites et ses interruptions. Une liste d’écrans classe l’interface ; une liste de risques protège l’activité.
Commencez par cinq familles :
- Action principale. L’utilisateur peut-il terminer la tâche qui justifie l’application ?
- Argent et engagement. Un paiement, une commande, une signature ou une réservation produit-il le bon état, y compris après un refus ou une interruption ?
- Droits et confidentialité. Chaque rôle voit-il et modifie-t-il uniquement ce qu’il est autorisé à traiter ?
- Données et reprise. Les informations importées, calculées, synchronisées ou exportées restent-elles complètes et rapprochables ?
- Exploitation. L’équipe peut-elle retrouver une opération, aider un utilisateur, corriger une erreur et comprendre un incident ?
Pour chaque risque, écrivez au moins un scénario normal, un cas à la limite et un échec réaliste. Si un envoi doit résister à une coupure réseau, ne testez pas seulement le formulaire rempli correctement : coupez la connexion avant la confirmation, rouvrez l’application et vérifiez si l’utilisateur sait ce qui a été enregistré.
Que doit contenir une fiche de recette exploitable ?
Une fiche de recette doit permettre à une autre personne de reproduire le contrôle et d’aboutir au même verdict. Six champs suffisent souvent pour commencer.
| Champ | Contenu attendu | Exemple concis |
|---|---|---|
| Version testée | identifiant immuable du build ou de la révision | build Android 2.4.0 (184) |
| Préconditions | rôle, appareil, données et état initial | chauffeur connecté, tournée fictive téléchargée, mode avion désactivé |
| Action | étapes observables, sans deviner l’interface | ouvrir la tournée, passer hors ligne, confirmer une livraison |
| Résultat attendu | état visible et effet métier | la preuve reste en attente locale, sans créer deux livraisons |
| Résultat constaté | fait observé, capture ou journal utile | confirmation locale visible ; synchronisation unique au retour du réseau |
| Verdict | accepté, écart non bloquant ou échec | accepté sur la version et l’appareil indiqués |
Évitez les résultats comme « cela fonctionne ». Nommez l’état final. Un scénario de création de compte doit préciser si le compte existe, si le message est envoyé, si un second clic duplique l’opération et ce que voit l’équipe dans son outil.
La version testée compte autant que le scénario. Une correction livrée après la recette modifie le produit accepté, même si le changement paraît petit. Rejouez les contrôles touchés et quelques parcours de non-régression avant de déplacer le verdict vers la nouvelle version.
Exemple rempli : préparer la recette d’une application de tournées
Prenons une entreprise fictive de livraison locale. Dix-huit chauffeurs utilisent des téléphones Android fournis par l’entreprise. Deux personnes préparent les tournées depuis une interface web. La couverture réseau est irrégulière et l’ancien outil sera arrêté un mardi soir. La première version permet d’importer une tournée, de confirmer une livraison avec une photo et de synchroniser le résultat au retour du réseau.
Trois options sont discutées : tester toutes les pages de manière uniforme, confier la recette au développeur ou concentrer d’abord l’équipe sur les opérations qui peuvent perdre ou dupliquer une livraison. L’entreprise retient la troisième option, puis complète par les contrôles techniques et visuels adaptés. Le référent exploitation valide les règles ; deux chauffeurs exécutent les scénarios sur les appareils de la flotte ; le prestataire fournit la version, les données fictives et les journaux utiles.
| Risque | Scénario de recette | Décision avant test | Conséquence attendue |
|---|---|---|---|
| Mauvaise tournée | importer deux fichiers contenant le même identifiant de tournée | le second import doit être refusé et expliqué | aucun doublon dans le planning |
| Perte hors ligne | confirmer une livraison, fermer l’application puis retrouver le réseau | la preuve doit rester visible en attente | synchronisation ultérieure sans nouvelle saisie |
| Double envoi | toucher deux fois la confirmation pendant une connexion instable | une seule livraison doit être enregistrée | aucun double statut ni double notification |
| Mauvais droit | connecter un chauffeur d’une autre agence | les tournées de l’agence testée doivent rester invisibles | séparation effective des agences |
| Reprise impossible | corriger une adresse depuis le web après le téléchargement mobile | la règle de priorité doit être documentée | l’équipe sait quelle valeur sera livrée au chauffeur |
Le test fait apparaître un conflit sur la correction d’adresse. Il n’est pas raisonnable de demander aux chauffeurs de deviner quelle version est la bonne. Deux décisions sont possibles : bloquer les modifications après téléchargement, ou afficher et synchroniser la correction avec une alerte. L’équipe choisit temporairement le blocage, car les changements sont rares et peuvent être gérés par téléphone pendant le premier lancement.
Cette décision n’idéalise pas la première version. Elle rend le risque visible, définit une procédure manuelle et donne une condition de révision : si les corrections deviennent fréquentes ou si le volume augmente, la synchronisation bidirectionnelle devra entrer dans le périmètre. La recette produit donc une décision d’exploitation, pas seulement une liste de bugs.
Quelles anomalies doivent bloquer le lancement ?
Les règles de sortie doivent être fixées avant la campagne de recette. Sinon, la date cible finit par redéfinir la gravité des anomalies à la dernière minute.
| Niveau | Critère de décision | Exemple | Décision possible |
|---|---|---|---|
| Bloquant | empêche l’action principale, compromet un droit, l’argent, une donnée ou la reprise | un utilisateur voit les dossiers d’une autre entreprise | corriger et rejouer avant lancement |
| Majeur | dégrade fortement un parcours, avec une solution temporaire sûre et assumée | export indisponible, mais extraction manuelle fiable pendant une semaine | reporter seulement avec responsable, délai et procédure écrits |
| Mineur | gêne sans altérer le résultat ni tromper l’utilisateur | espace visuel incohérent sur un appareil secondaire | consigner, planifier et surveiller |
Un contournement n’est acceptable que s’il est sûr, compris par l’équipe et compatible avec le volume. « Le support corrigera à la main » n’est pas une réponse si personne n’a le droit, l’information ou le temps nécessaire. Notez qui agit, sous quel délai et comment l’utilisateur est informé.
La décision de lancement doit aussi lister les zones non testées. Une fonction absente du plan de recette n’est pas implicitement validée. Elle peut être retirée, masquée, limitée à un groupe ou acceptée comme risque, mais elle doit rester visible dans le compte rendu.
Faut-il tester sur une version de production et de vrais appareils ?
Testez la version distribuable dans un environnement aussi proche que nécessaire des conditions d’usage, sans confondre proximité et copie incontrôlée de la production. Les différences de signature, de configuration, de permissions ou de services tiers peuvent rendre un build de développement trompeur.
Apple recommande de tester un build de release dans plusieurs conditions proches de celles des utilisateurs avant la soumission ou la distribution (Apple Developer). TestFlight permet ensuite de distribuer une version bêta et de recueillir des retours avant publication (Apple TestFlight). Google Play distingue des canaux internes, fermés et ouverts ; le test interne sert aux premiers contrôles, puis un groupe fermé peut fournir des retours ciblés avant une diffusion plus large (Aide Console Play).
Le choix des appareils vient de l’usage réel : systèmes pris en charge, tailles d’écran, navigateurs, réseau, permissions et accessoires nécessaires. Une matrice courte fondée sur le parc attendu vaut mieux qu’une longue liste d’appareils choisis au hasard. Pour une application web interne, le navigateur géré par l’entreprise et les règles de connexion peuvent compter davantage que le dernier téléphone grand public.
Quelles données utiliser pendant la recette ?
Utilisez des données fictives représentatives, puis rapprochez séparément les mécanismes qui devront traiter les données réelles. La CNIL indique que les données personnelles réelles de production ne doivent pas servir aux phases de développement et de test ; elle recommande des jeux fictifs et, lorsqu’une configuration existante est nécessaire, l’anonymisation des données personnelles qu’elle peut contenir (CNIL).
Un jeu fictif doit néanmoins reproduire les formes qui mettent le produit à l’épreuve : champs absents, noms longs, doublons, dates limites, pièces jointes lourdes, caractères accentués et relations entre objets. Remplacer toute la base par trois comptes parfaits protège la confidentialité, mais ne teste pas la reprise.
Si une migration fait partie du lancement, définissez des contrôles de rapprochement distincts : nombre d’objets attendus, champs obligatoires, totaux métier, liens entre enregistrements, rejets et échantillons validés. L’équipe peut ainsi vérifier la méthode sans ouvrir largement les données de production dans l’environnement de recette.
Quand la recette peut-elle se terminer ?
La recette peut se terminer lorsque les scénarios prévus ont un verdict, les anomalies bloquantes sont corrigées et rejouées, les écarts acceptés ont un responsable et le plan de lancement est prêt. La date seule n’est pas un critère de sortie.
Avant de donner le feu vert, vérifiez :
- l’identifiant exact de la version acceptée ;
- les scénarios exécutés, leurs appareils et leurs données ;
- les zones non couvertes et la raison de cette limite ;
- les anomalies restantes, leur contournement et leur échéance ;
- les accès, sauvegardes, alertes et procédures nécessaires au lancement ;
- le moyen de désactiver, corriger ou revenir en arrière si un risque se réalise ;
- les signaux à observer pendant les premières heures et les personnes joignables.
Après la mise en ligne, vérifiez les opérations réelles sans fabriquer un second plan improvisé : création de compte, action principale, messages, paiement éventuel, journaux d’erreur et capacité du support à retrouver un dossier. Un lancement progressif peut réduire l’exposition, mais il ne répare pas un parcours qui n’a jamais été accepté.
Que demander au prestataire avant d’ouvrir la recette ?
Demandez un périmètre testable, pas une promesse générale de qualité. Le prestataire doit pouvoir fournir la version candidate, les accès, les données fictives, les scénarios déjà couverts, les limites connues, la procédure de signalement et le délai de traitement selon la gravité.
Reliez cette demande au cahier des charges de l’application : les parcours, règles et exceptions préparés avant le devis deviennent la matière de la recette. Puis vérifiez que la proposition commerciale définit bien les responsabilités de test et d’acceptation, comme dans notre grille pour comparer deux devis de développement.
Klaapp accompagne la création de logiciels, d’applications mobiles et de sites web. Un premier échange peut servir à identifier les parcours dont l’échec aurait le plus d’impact, répartir les responsabilités et transformer vos règles métier en scénarios vérifiables. Si un outil existant couvre déjà ces besoins et ses tests, le bon choix peut aussi être de l’adopter plutôt que de développer.
Questions fréquentes
Qui doit rédiger le cahier de recette d’une application ?
Le prestataire peut préparer la structure et les scénarios techniques, mais le référent métier doit valider les résultats attendus et les priorités. La meilleure version est généralement coécrite : l’équipe produit décrit le risque et la règle, l’équipe technique rend le scénario reproductible et fournit les preuves observables.
Combien de temps prévoir pour la recette avant lancement ?
Il n’existe pas de durée universelle. Estimez le travail à partir du nombre de parcours critiques, des rôles, des appareils, des intégrations et du volume de corrections à rejouer. Réservez aussi du temps aux personnes métier : une semaine inscrite au planning ne produit aucune validation si les testeurs ne sont pas disponibles.
Des tests automatisés peuvent-ils remplacer la recette métier ?
Non. Les tests automatisés vérifient rapidement des comportements connus et protègent contre des régressions. La recette métier confirme que ces comportements correspondent encore au besoin, avec les bons droits, données et conséquences opérationnelles. Automatisez ensuite les scénarios stables et répétés, sans supprimer la décision humaine de lancement.
Sources
- CNIL — Tester vos applications
- Apple Developer — Testing a release build
- Apple Developer — TestFlight
- Aide Console Play — Configurer un test ouvert, fermé ou interne
- W3C WAI — Involving Users in Evaluating Web Accessibility
Thomas R. est cofondateur de Klaapp. Il porte les choix techniques et relie le développement, la fiabilité et les conditions de lancement aux contraintes concrètes du projet. Découvrir le studio Klaapp.