Dans un projet Finance ou SI, la recette fonctionnelle est censée démontrer que la solution répond au besoin métier et que le processus peut fonctionner dans les conditions prévues.
Pourtant, de nombreux cahiers de recette ressemblent davantage à des modes opératoires : ouvrir un écran, saisir une donnée, cliquer sur un bouton, puis passer à l’étape suivante.
Ces instructions peuvent aider le testeur à parcourir l’application. Elles ne permettent pas nécessairement de conclure que le comportement observé est conforme.
Sans résultat attendu explicite, le testeur sait ce qu’il doit faire, mais pas précisément ce qu’il doit vérifier. Il peut réussir à terminer le scénario alors qu’une règle de gestion, un statut, une écriture comptable ou une transmission de données est incorrecte.
Un cas de test utile ne décrit donc pas seulement une manipulation. Il relie une situation métier, une règle, une action, un résultat observable et une preuve.
Pourquoi une suite d’actions ne suffit-elle pas ?
Prenons une instruction fréquemment rencontrée :
Ouvrir une facture, modifier le montant, puis cliquer sur Valider.
Plusieurs questions restent sans réponse :
- Quel profil utilisateur réalise l’opération ?
- Quel est le statut initial de la facture ?
- La facture est-elle rattachée à une commande ?
- Quel contrôle doit être appliqué au nouveau montant ?
- Une approbation supplémentaire est-elle attendue ?
- Quel statut doit être obtenu après validation ?
- Une écriture comptable doit-elle être générée ?
- Une information doit-elle être transmise à une autre application ?
- Quelle trace doit être conservée ?
Le test peut être exécuté sans erreur technique tout en laissant ces dimensions non contrôlées.
La différence est importante : une manipulation vérifie que le parcours est possible. Un cas de test vérifie que le système produit le comportement attendu dans un contexte défini.
Les cinq composants d’un cas de test probant
1. La situation initiale
Le scénario doit préciser les conditions nécessaires à son exécution :
- environnement utilisé ;
- profil et habilitations du testeur ;
- données de référence ;
- statut initial de l’objet ;
- paramétrage ou règle applicable ;
- dépendances avec les autres systèmes.
Sans ces prérequis, deux testeurs peuvent exécuter le même scénario dans des conditions différentes et obtenir des résultats incompatibles sans comprendre pourquoi.
2. La règle métier contrôlée
Le cas doit être relié à une exigence ou à une règle identifiable.
Dans un projet Finance, cette règle peut porter sur :
- un seuil d’approbation ;
- une séparation des tâches ;
- un contrôle de doublon ;
- un rapprochement entre commande, réception et facture ;
- une condition de comptabilisation ;
- une règle de TVA ;
- une période comptable ;
- une modalité de relance ou de blocage.
Cette traçabilité permet de vérifier que les exigences importantes sont réellement couvertes par la recette.
3. L’action réalisée
Les étapes doivent être suffisamment précises pour être reproductibles, sans transformer le scénario en documentation inutilement lourde.
L’objectif n’est pas de documenter chaque déplacement de souris. Il est d’indiquer les actions susceptibles d’influencer le résultat : donnée saisie, fichier déposé, statut sélectionné, validation réalisée ou événement reçu depuis une interface.
4. Le résultat attendu
Le résultat attendu doit être observable et non ambigu.
« Le traitement fonctionne » n’est pas suffisamment précis.
Il faut indiquer, selon le cas :
- le message affiché ;
- le statut final ;
- la valeur calculée ;
- la personne destinataire d’une tâche ;
- le fichier ou le flux généré ;
- l’écriture comptable produite ;
- le rejet déclenché ;
- la donnée inscrite dans le journal d’audit.
Un bon résultat attendu permet à deux testeurs indépendants d’aboutir à la même conclusion.
5. La preuve et la décision
Une exécution doit produire une preuve adaptée à l’enjeu : capture d’écran, identifiant de transaction, journal technique, fichier échangé, écriture comptable, statut d’une interface ou rapport de contrôle.
La preuve ne sert pas uniquement à documenter un succès. Elle permet aussi de comprendre une anomalie, de reproduire le problème et de sécuriser la décision finale d’acceptation.
Le scénario doit enfin comporter une conclusion claire : réussi, échoué, bloqué ou réussi avec réserve, selon les règles définies par le projet.
Exemple sur un processus P2P
Un scénario trop faible pourrait être rédigé ainsi :
Créer une facture sans commande et la transmettre pour validation.
Une version plus robuste préciserait :
- le fournisseur et son statut dans le référentiel ;
- le profil de l’utilisateur ;
- l’absence de commande associée ;
- le montant et le seuil de contrôle utilisé pour le test ;
- la règle de gestion applicable ;
- le statut attendu après transmission ;
- le circuit d’approbation déclenché ;
- l’absence ou la présence attendue d’une écriture comptable ;
- la notification attendue ;
- la trace à retrouver dans le journal ;
- la preuve à joindre au procès-verbal de recette.
Le test ne consiste alors plus à vérifier que la facture peut être saisie. Il démontre que l’exception « facture sans commande » est détectée et traitée conformément à la règle retenue par l’entreprise.
La recette Finance doit couvrir plusieurs niveaux
Le comportement de l’écran
Les champs, boutons, messages et contrôles de saisie doivent fonctionner comme prévu.
Ce premier niveau est nécessaire, mais il ne couvre qu’une partie du processus.
Le workflow et les responsabilités
Il faut vérifier que la tâche est adressée au bon acteur, avec la bonne information et selon les seuils ou délégations applicables.
Les profils d’habilitation doivent également empêcher une personne de réaliser une action incompatible avec son rôle.
Les interfaces et les données
Une opération réussie dans l’application source ne garantit pas que la donnée a été correctement transmise, transformée puis intégrée dans le système cible.
Le test doit suivre les informations importantes de bout en bout : identifiants, montants, taxes, axes analytiques, statuts et références de rapprochement.
L’impact comptable
Lorsqu’un processus produit une comptabilisation, la recette doit vérifier le journal, les comptes, les dates, les montants, les axes analytiques et les conditions de génération ou de blocage.
Un écran peut afficher un statut correct alors que l’écriture produite en aval est erronée.
Les contrôles et la piste d’audit
Le projet doit tester les alertes, rejets, traces, horodatages et historiques nécessaires au contrôle interne.
Il faut pouvoir comprendre qui a réalisé l’action, quand, sur quelle donnée et selon quel circuit.
Tester le nominal, les exceptions et les limites
Une recette composée uniquement de cas nominaux confirme surtout que la démonstration standard fonctionne.
Les risques opérationnels se trouvent souvent dans les situations moins confortables :
- donnée obligatoire absente ;
- doublon potentiel ;
- fournisseur ou client inactif ;
- montant exactement égal à un seuil, puis juste au-dessus ;
- période comptable clôturée ;
- utilisateur sans habilitation ;
- fichier rejeté ;
- interface indisponible ;
- avoir supérieur à la facture d’origine ;
- changement de référentiel en cours de traitement.
Les cas limites sont particulièrement utiles pour vérifier comment les règles ont été traduites dans le paramétrage.
La recette doit donc être construite à partir des risques métier, et pas seulement à partir des menus de l’application.
Des données représentatives sans exposer inutilement les données réelles
La qualité de la recette dépend directement des jeux de données utilisés.
Un jeu trop simple ne révèle pas les problèmes liés aux volumes, aux formats, aux doublons, aux arrondis ou aux cas d’exception. Mais copier librement des données de production dans un environnement de test crée d’autres risques.
La CNIL recommande d’effectuer les tests dans un environnement distinct de la production et d’utiliser autant que possible des données fictives ou anonymisées.
Elle précise également que, lorsque des données réelles sont exceptionnellement nécessaires en préproduction, cet environnement doit être sécurisé au même niveau que la production et intervenir après les tests menés dans les environnements prévus à cet effet. Recommandations officielles de la CNIL
L’AMOA doit donc contribuer à concevoir des jeux représentatifs sur le plan métier, pendant que la DSI et les responsables concernés garantissent leur protection et leurs conditions d’utilisation.
Définir les critères de sortie avant la campagne
Une campagne de recette ne devrait pas se terminer simplement parce que la date de mise en production approche.
Les critères de sortie doivent être définis avant l’exécution :
- taux de scénarios exécutés ;
- couverture des exigences critiques ;
- nombre et gravité des anomalies encore ouvertes ;
- traitement des anomalies bloquantes ;
- exécution des tests de non-régression ;
- validation des interfaces et impacts comptables ;
- disponibilité des preuves ;
- acceptation des risques résiduels par l’autorité compétente.
La CNIL recommande également de définir conjointement les métriques acceptables avant le développement et de maintenir des tests adaptés lors des mises à jour. CNIL — Tester vos applications
La décision de mise en production doit ainsi reposer sur une vision partagée de la couverture, des anomalies et des risques, et pas uniquement sur un pourcentage global de tests réussis.
Le rôle de l’AMOA dans la recette fonctionnelle
L’AMOA ne remplace ni les utilisateurs métiers ni les équipes techniques.
Elle construit le lien entre les différents niveaux de preuve :
- rattacher les tests aux besoins et aux règles métier ;
- identifier les processus et risques prioritaires ;
- organiser les jeux de données ;
- faire couvrir les cas nominaux, les exceptions et les limites ;
- coordonner les métiers, la DSI et l’intégrateur ;
- suivre les anomalies et leurs corrections ;
- préparer les arbitrages ;
- consolider les preuves nécessaires à l’acceptation.
Cette organisation permet d’éviter deux dérives opposées : une recette purement technique qui ne prouve pas la conformité métier, ou une recette métier qui vérifie l’écran sans contrôler les interfaces, les écritures et la traçabilité.
Une recette doit produire une preuve, pas seulement une impression
Un utilisateur peut trouver un parcours fluide et intuitif tout en passant à côté d’un écart de calcul ou d’une mauvaise alimentation comptable.
Inversement, une anomalie visuelle mineure ne présente pas le même risque qu’un défaut de séparation des tâches, un doublon de paiement ou une écriture erronée.
La recette fonctionnelle doit donc permettre de conclure avec précision :
- quelle règle a été testée ;
- dans quelles conditions ;
- avec quelles données ;
- quel résultat a été observé ;
- quelle preuve a été conservée ;
- quelle décision en découle.
Avant de valider un scénario, la bonne question n’est pas seulement :
« Le testeur a-t-il pu aller jusqu’au bout ? »
Elle devient :
« Avons-nous démontré que le processus produit le résultat métier attendu, y compris dans ses exceptions ? »
BAZIRE CONSULTING accompagne les directions Finance, les métiers et les DSI dans le cadrage de la recette, la formalisation des scénarios, la gestion des anomalies et la sécurisation des mises en production de leurs projets Finance & SI.
