Plan de recette d’une application métier : prouver avant d’accepter

La livraison est annoncée pour le 12, la mise en service pour le 15. Personne, chez vous, n’a bloqué une journée pour vérifier quoi que ce soit.

Vérifier, ici, porte un nom : la recette. C’est le moment où votre équipe, et non celle qui a développé, rejoue son travail réel dans le logiciel livré et note ce qui sort. Un plan de recette est la liste écrite de ces vérifications, avec le résultat attendu de chacune.

Une recette se chiffre avant de s’écrire. Les cas se comptent à partir de vos parcours, de vos règles, de vos droits et de vos échanges avec vos autres logiciels. Les jours que votre équipe doit y passer s’en déduisent, écriture, exécution et rejeu compris. Les seuils s’écrivent en dernier. Sur le cas construit de ce guide, dont les volumes sont choisis pour l’exemple : 56 cas, 6,2 jours et 2 170 € de temps interne, sur un projet à 25 000 € hors taxes (HT).

Un taux de réussite ne décide rien : « 33 cas exécutés, 33 réussis » se lit très bien quand 23 cas n’ont jamais été joués.

Un plan de recette d’application métier tient en une liste de cas, le budget qui va avec et les seuils qu’on saura vérifier. Le nombre de cas se compte, à partir de cinq sources dénombrables sur des documents que vous avez déjà.

Six plus trente, plus sept, plus neuf, plus quatre : 56 cas. Ce total n’est pas une norme à recopier : il suit le nombre de règles. La même méthode donne 4 cas pour une saisie de congés qui tient en quatre règles sans seuil, et de 60 à 120 cas pour un calcul de commissions à soixante règles, selon celles qui portent un seuil. Ce qui se transporte d’un projet à l’autre, c’est la méthode de comptage.

D’où sortent les 19 règles du cas construit

Elles se relèvent dans le cahier des charges quand il existe, dans les courriels de spécification et les comptes rendus de réunion sinon. Une règle qui n’apparaît nulle part ne sera vérifiée par personne.

Une règle mérite un cas à la limite dès qu’elle contient un nombre, une date ou un mot comme « au-delà », « sauf si » ou « arrondi ». Sur les 19 règles, 11 répondent à ce critère : c’est de là que sortent les 30 cas de la deuxième ligne.

Aucune des valeurs ci-dessous ne sort d’une source publiée : ce sont des hypothèses de travail, posées à découvert pour que vous puissiez les remplacer par les vôtres. Écrire un cas rejouable prend 15 minutes une fois la règle connue, l’exécuter la première fois 10 minutes, le rejouer après correction 5 minutes. La journée utile vaut 7 heures, et le temps interne 350 € le jour chargé.

Pour les remplacer, chronométrez vos cinq premiers cas, de la lecture de la règle à la preuve rangée : cinq suffisent à savoir si votre moyenne d’écriture est de huit ou de vingt-cinq minutes, ce qui fait passer le budget de 5,3 à 7,6 jours. Votre contrôleuse de gestion ou votre expert-comptable sort le coût du jour chargé à partir du salaire brut, des charges et des jours réellement travaillés.

Les 17 cas rejoués par cycle correspondent à trois cas sur dix, proportion à ajuster dès la première livraison : si le premier cycle en touche la moitié, doublez la ligne avant de promettre une date. Le total, lui, arrondit la part d’exécution à la dixième de journée ; sans cet arrondi, 26 h 10 valent 3,74 jours, le total 6,24 jours et le coût 2 183 €, treize euros de plus que la ligne affichée. Dans les deux lectures, ces jours pèsent 8,7 % du budget du projet, 25 000 € HT. Ils figurent rarement sur un devis, et pour cause : ils ne sont pas vendus, ils sont à vous.

Les 6,2 jours de travail ne tiennent pas dans six jours de calendrier

Entre deux cycles, le correctif doit être développé puis redéployé chez vous. Ce délai-là appartient à l’équipe qui développe : demandez-le par écrit, cycle par cycle, avant d’arrêter une date.

La deuxième campagne coûte 56 × 5 minutes de rejeu, soit 4 h 40 contre 26 h 10 la première fois : 21 h 30 économisées. C’est là que l’écriture se rembourse, à condition que les cas soient conservés ailleurs que dans une boîte de réception.

Un critère opposable porte quatre choses : un seuil chiffré, une assiette — sur quoi on mesure —, une fenêtre — pendant combien de temps — et le nom de qui produit la mesure. Qu’il en manque une, et deux personnes de bonne foi lisent le même écran en concluant l’inverse.

Un modèle public et gratuit existe. Le cahier des clauses administratives générales des marchés publics de techniques de l’information et de la communication, approuvé par l’arrêté du 30 mars 2021, sépare la vérification en deux temps à son article 32 : la vérification d’aptitude, qui contrôle que le logiciel livré peut remplir les fonctions demandées, puis la vérification de service régulier, qui l’observe en fonctionnement.

Le seuil de 2 %, et ce qu’il fait vraiment

La régularité s’observe pendant trente jours à partir de la décision positive de vérification d’aptitude, et le service est réputé régulier si l’indisponibilité cumulée sur le mois ne dépasse pas 2 % de la durée d’utilisation effective, qui s’étend de 8 h à 18 h, du lundi au vendredi, jours fériés exclus.

Le calcul part de la journée d’ouverture : 10 heures, soit 600 minutes, dont 2 % font 12 minutes. Reste à compter les jours ouvrés de la fenêtre, et ce nombre bouge : trente jours consécutifs en comptent 22 s’ils commencent un lundi, un mardi, un mercredi ou un jeudi, 21 un vendredi ou un dimanche, 20 un samedi — moins les jours fériés. Au maximum, donc : 22 × 10 = 220 heures, soit 13 200 minutes, dont 2 % font 264 minutes — 4 h 24. Du 1er au 30 mai 2027, fenêtre ouverte un samedi, il n’en reste que 20 ; l’Ascension le 6 et le lundi de Pentecôte le 17 en retirent deux, soit 18 jours ouvrés et 3 h 36. Écrivez la règle des 12 minutes par jour ouvré plutôt que ce total figé.

Une sonde qui appelle une page toutes les 60 secondes produit un point par minute, et chaque point manquant compte une minute. À cinq minutes d’intervalle, une coupure de trois minutes n’est vue que si un appel tombe pendant la coupure : sur cinq minutes de départs possibles, deux la laissent passer. L’échantillonnage fixe le grain de ce que vous pourrez démontrer.

Le CCAG-TIC parle d’indisponibilités imputables à chaque élément de matériel. Sur une application hébergée, aucun élément de matériel n’est à vous : la clause doit nommer ce qui est indisponible — l’écran de saisie, le traitement de nuit — et qui produit la mesure.

La ligne d’accessibilité demande une mise au point juridique. L’obligation française d’accessibilité numérique vient de l’article 47 de la loi du 11 février 2005 ; le décret du 24 juillet 2019 n’en fixe que le seuil. Elle vise quatre catégories : les personnes morales de droit public ; celles de droit privé délégataires d’une mission de service public ou créées pour un besoin d’intérêt général autre qu’industriel ou commercial ; celles que les précédentes constituent pour le même objet ; et les entreprises dont le chiffre d’affaires moyen annuel en France des trois derniers exercices clos dépasse 250 millions d’euros. Le critère est un chiffre d’affaires, jamais un effectif.

Le second régime, applicable depuis le 28 juin 2025, vise des produits et services destinés aux consommateurs — commerce en ligne, banque, transport de voyageurs, livre numérique. Un outil interne utilisé par vos salariés n’y figure pas. Hors de ces deux régimes, ne commandez pas d’audit de conformité pour ce projet-là : faites la traversée au clavier vous-même, deux heures suffisent à trouver les champs qu’on ne peut pas atteindre sans souris. Le W3C rappelle qu’aucun outil automatique ne détermine seul la conformité.

Une recette jouée sur vingt-huit dossiers bien formés démontre une chose : que le logiciel fonctionne sur vingt-huit dossiers bien formés. Ce qui casse en production, ce sont les situations que personne ne regarde — un client sans numéro SIRET, une commune fusionnée en 2019, un taux de taxe retiré depuis.

Les trouver ne demande pas de copier la production. Pour chaque colonne qui entre dans une règle, comptez les valeurs distinctes réellement présentes, puis gardez au moins un représentant de chaque forme. Sur le cas construit, la colonne « type de client » en contient 7 et la colonne « mode de facturation » 4. Onze valeurs à représenter, donc : sept dossiers suffisent si vous les combinez, vingt-huit s’il faut jouer chaque croisement. Le cas construit retient le croisement complet : 7 × 4 = 28 dossiers.

Cette dernière famille annule la mesure de la section 04. Vingt-huit dossiers représentent 8,2 % d’un mois réel à 340 factures. Un temps d’affichage relevé sur ce volume ne dit rien du 25 du mois, quand la liste charge tout l’historique. Chargez au moins l’équivalent d’un mois avant de mesurer un seuil de deux secondes.

Ce que la CNIL demande, et ce que « anonymiser » veut dire

Les deux fiches de la CNIL convergent : environnements de développement, de test et de production distincts, jeu de données fictif ou anonymisé, et anonymisation des données personnelles contenues dans les configurations importées. Cette contrainte décide de la forme du jeu d’essai, donc du planning de la section 03.

Anonymiser ne consiste pas à remplacer les noms par « Dupont » : les identifiants, les adresses, les numéros de compte et les commentaires libres portent autant d’information, et un croisement peut suffire à réidentifier une personne dans un fichier de 340 lignes. Une bibliothèque de génération de données factices fait ce travail — c’est la ligne « préparer le jeu de données » du tableau, et elle se sous-traite au développeur qui connaît le schéma de la base.

Les trois incidents ci-dessous prolongent le cas construit de Nadia et de Karim — ce ne sont pas des dossiers clients. Deux valeurs y sont choisies pour l’exemple, en plus des hypothèses de la section 03 : la part de factures touchées par l’erreur d’arrondi, fixée à 12 %, et l’écart moyen sur chacune, fixé à 34 €. Le reste se déduit des nombres déjà posés.

La règle d’arrondi jamais jouée : 4 182 € d’avoirs et 700 € de reprise

Le prorata kilométrique n’a été testé que sur des distances entières, parce que le jeu d’essai n’en contenait pas d’autres. À 12 % des factures, l’erreur en touche 41 des 340 émises chaque mois, avec un écart moyen de 34 € dans le même sens. Elle passe inaperçue jusqu’au troisième mois : 41 × 34 × 3 font 4 182 € d’avoirs à émettre. S’y ajoute la reprise des 123 factures concernées, une journée pour la responsable facturation et une journée pour la contrôleuse de gestion, soit 2 jours-personne et 700 € de temps interne. Un cas à la limite, écrit en quinze minutes, l’aurait attrapé.

Personne ne notifie la décision : 7 500 € de levier perdus

La campagne se termine un vendredi. Personne n’écrit de décision, et l’application entre en service parce qu’il faut bien facturer. En marché public, le CCAG-TIC organise ce silence à son article 33, et une seule fois : si l’acheteur ne notifie pas sa décision dans les sept jours qui suivent la vérification de service régulier, les prestations sont réputées admises. Le délai de trente jours, lui, ne suit pas la vérification d’aptitude : il la couvre, court à compter de l’écrit du titulaire annonçant les prestations prêtes à être vérifiées ou du procès-verbal de mise en ordre de marche, et n’emporte aucune admission tacite — décision positive, ajournement ou rejet. Un contrat privé ne reprend cette mécanique que s’il l’écrit ; à défaut, seuls vos documents signés disent ce que produit le silence. Ce qui est perdu est concret : la tranche de 7 500 € cesse d’être un levier tant qu’aucune décision n’est écrite.

La testeuse n’a pas eu ses jours : 23 cas sur 56 jamais joués

Sur les 6,2 jours du tableau de la section 03, la part de Nadia est de 3,7 jours : l’écriture, l’exécution et le rejeu. Le reste va au développeur pour le jeu de données, à la relecture croisée et à la réunion de décision. Elle a obtenu deux jours, parce que la clôture comptable du mois est tombée la même semaine. Deux jours de 7 heures font 840 minutes, et un cas écrit puis exécuté en coûte 25 : elle joue 33 cas, tous conformes, et le compte rendu annonce « 33 cas exécutés, 33 réussis ». Le chiffre est exact et ne veut rien dire : parmi les 23 cas restants figurent quatre des six parcours critiques et les neuf cas de flux. L’export comptable rejette 62 écritures à la première clôture ; la contrôleuse de gestion et le comptable y passent trois quarts de journée chacun, soit 1,5 jour-personne et 525 €, et la clôture sort avec quatre jours de retard.

Un taux de réussite mesure l’exécution. Deux autres nombres se calculent avec ce que vous avez déjà : l’un dit ce que la campagne a couvert, l’autre ce qu’elle a laissé passer.

Couverture des règles
  règles couvertes par au moins un cas ÷ règles réellement identifiées
  cas construit : 19 ÷ 26 = 73 %

Taux d’échappement
  anomalies trouvées en production sur 60 jours
  ÷ (anomalies trouvées en recette + anomalies trouvées en production)
  cas construit : 8 ÷ (37 + 8) = 17,8 %

Le piège de la première mesure tient dans son dénominateur, qui ne contient que les règles déjà écrites. Sur le cas construit, sept règles apparaissent pendant l’exécution — un plafond de remise, un traitement des livraisons hors France, une règle d’arrondi non écrite. Le dénominateur passe de 19 à 26, et la couverture tombe à 73 %. Ce 73 % date du jour où ces sept règles sont apparues ; ce n’est pas le verdict de la campagne. Chaque règle découverte rejoint le cahier des charges, puis un cas, avant la décision : 7 × 25 minutes, soit 2 h 55 à ajouter au budget de la section 03.

La seconde mesure demande d’attendre 60 jours d’usage. Huit anomalies remontées en production contre 37 trouvées en recette donnent 17,8 % : quatre anomalies sur cinq ont été attrapées avant. Ce nombre ne dit rien de leur gravité : lisez les deux séries séparément. Il n’existe pas de seuil de référence publiable : la seule comparaison honnête est celle de votre campagne suivante, sur le même produit.

Relire un cas avant de le compter dans la campagne

L’atelier ci-dessous ne calcule aucune moyenne et ne stocke rien : huit points de relecture, dix compteurs de campagne, sept issues classées dans un ordre fixe. Un blocage de préparation passe devant une information manquante, qui passe devant un cas critique non prouvé. Vous n’y saisissez aucun contenu métier.

La personne qui peut accepter, refuser ou accepter sous réserve se nomme avant la campagne. Sur le cas construit, c’est Karim, directeur d’exploitation. Le testeur constate ; le décideur tranche. Cette séparation empêche une testeuse fatiguée de valider à 18 heures un dossier qui engage 7 500 €.

Tenez quatre statuts. Réussi pour un cas joué et conforme. Échoué pour un cas joué et non conforme. Bloqué pour un cas qu’on n’a pas pu jouer. Non exécuté pour un cas qui n’a pas été tenté. Les deux derniers se confondent facilement dans un compte rendu, et ce sont eux qui ont produit le troisième incident. Le syllabus de l’ISTQB distingue de la même façon la gravité d’une anomalie, qui décrit son effet, et sa priorité, qui décrit l’ordre de traitement retenu : gardez les deux champs.

RELEVÉ DE FIN DE CAMPAGNE

Version exacte testée et environnement :
Ce qui était inclus, ce qui a été laissé de côté :
Cas — réussis / échoués / bloqués / non exécutés :
Parcours critiques prouvés, et ceux qui ne le sont pas :
Anomalies ouvertes — gravité, priorité, responsable, échéance :
Réserves acceptées et date de revue :
Preuves et endroit où elles sont rangées :
Ce que la campagne n’a pas démontré :
Décideur, décision, date :

Ce relevé se juge à sa relisibilité dans six mois, quand une facture fausse remontera. ISO/IEC/IEEE 29119-3:2021 propose des modèles de documentation de test, ISO/IEC 25010:2023 aide à ouvrir la liste des critères au-delà des seules fonctions ; ni l’une ni l’autre ne fixe de seuil à la place de votre contrat.

Ce qui change le lendemain de l’acceptation

Ce que devient une correction demandée après l’acceptation dépend de vos documents : garantie écrite au marché, garantie légale, ou demande traitée au contrat de maintenance avec son délai et son coût. Réglez ce point par écrit avant la décision. Vos 56 cas, eux, deviennent un actif : la version suivante se vérifie en 4 h 40 de rejeu au lieu de 26 h 10, à condition de les avoir rangés dans un endroit partagé.

Deux vérifications restent en dehors de cette campagne : ce que chaque rôle ne doit pas pouvoir faire, et la restauration d’une sauvegarde réellement testée. Les contrôles de sécurité d’une application métier les détaillent. Pour faire relire votre décompte de cas avant la livraison, vous pouvez décrire votre projet.

Transparence. Hagnéré Code développe des applications métier sur mesure et perçoit des honoraires si vous nous confiez un projet — y compris celui que cette page vous apprend à vérifier. Rien ici n’exige de passer par nous : le décompte des cas, le budget en jours, la réécriture des seuils et les deux mesures se refont avec vos propres nombres, et la section 03 conclut qu’en dessous d’un certain budget cette campagne est une erreur. Les sources citées ont été rouvertes une à une le 30 août 2026 et portent chacune sa date ; deux n’ont pas répondu et le disent. Elles sont à revérifier tous les douze mois. Aucun délai, aucun coût et aucun résultat ne sont garantis par cette page : seul un devis signé engage.