Recetter un outil interne et signaler les anomalies
En bref
La recette est la vérification, par le client, que l'outil livré correspond à la demande. Préparez des cas de test tirés de dossiers réels, y compris des cas limites, et faites-les jouer par les futurs utilisateurs. Notez chaque écart avec ce que vous faisiez, ce que vous attendiez et ce qui s'est produit. Classez les anomalies par gravité, puis validez formellement ce qui fonctionne.
La recette est l'étape où vous vérifiez que ce qui a été livré correspond à ce qui a été demandé. Elle ne consiste pas à parcourir l'outil pour voir s'il semble fonctionner, mais à dérouler des situations précises et à comparer le résultat obtenu au résultat attendu.
Préparer les cas de test avant la livraison
Les cas de test se préparent pendant le développement, à partir des besoins écrits. Chaque cas décrit une situation, les données utilisées et le résultat attendu.
- Les cas courants : le déroulement normal, du début à la fin d'un dossier.
- Les cas limites : un dossier sans pièce jointe, une valeur nulle, une date dans le passé, un nom très long.
- Les cas interdits : ce qui doit être refusé, et le message affiché en retour.
- Les droits : chaque rôle voit-il exactement ce qu'il doit voir, et rien d'autre ? Ce point rejoint la gestion des droits d'accès.
- Les enchaînements : ce qui se passe après une validation, une notification, une écriture dans un autre logiciel.
Utilisez des dossiers réels anonymisés plutôt que des données inventées : ils contiennent les irrégularités que personne n'imagine.
Qui doit recetter ?
| Participant | Ce qu'il vérifie |
|---|---|
| Utilisateurs quotidiens | Le déroulement des tâches courantes et la lisibilité des écrans. |
| Référent métier | Les règles, les calculs et les cas particuliers. |
| Encadrement | Les validations, les suivis et les états produits. |
| Administrateur | La création des comptes, les droits, les paramétrages. |
La recette se fait sur un environnement distinct de la production, avec des données de test, pour qu'une erreur n'ait aucune conséquence.
Rédiger un signalement exploitable
Un signalement flou coûte plusieurs allers-retours. Un bon signalement tient en quelques lignes et contient toujours :
- Ce que vous faisiez, étape par étape, avec le dossier concerné.
- Ce que vous attendiez comme résultat.
- Ce qui s'est réellement produit, avec le message affiché s'il y en a un.
- La date, l'heure et le compte utilisé.
- L'appareil et le navigateur, si le problème d'affichage en dépend.
- Une capture d'écran, qui vaut souvent mieux qu'une description.
Indiquez aussi si le problème se reproduit à chaque fois ou seulement parfois : une anomalie intermittente se cherche différemment.
Classer par gravité, pas par ordre d'arrivée
- Bloquant : la tâche ne peut pas être réalisée, aucun contournement.
- Majeur : le travail est possible mais dégradé, avec un contournement acceptable un temps.
- Mineur : gêne limitée, défaut d'affichage, formulation à revoir.
- Évolution : ce n'est pas un défaut, c'est une demande nouvelle. À traiter séparément.
Cette dernière distinction évite les tensions. Une demande qui n'était pas dans le besoin écrit relève de la maintenance évolutive, pas de la correction due au titre de la livraison.
Organiser les échanges
Rassemblez tous les signalements au même endroit, visible des deux côtés, avec pour chacun un état : reçu, en cours, corrigé, à revérifier, clos. Après chaque correction, la personne qui a signalé le problème le revérifie et ferme la ligne. Sans cette boucle, la même anomalie est signalée plusieurs fois par des personnes différentes.
Prononcer la recette
La recette se conclut par une décision écrite : ce qui est accepté, ce qui reste à corriger avant la mise en service, ce qui est reporté après le lancement. Une recette qui traîne sans conclusion laisse le projet dans un état indéfini, où chacun attend l'autre. Les vérifications techniques complémentaires avant l'ouverture sont listées dans l'article sur les tests avant mise en ligne.
NexSecure organise la recette des applications qu'elle livre, dans le cadre de son offre de développement web sur mesure.
Questions fréquentes
Qu'est-ce que la recette d'une application ?
C'est l'étape où le client vérifie, avant la mise en service, que chaque fonction livrée correspond à la demande. Elle se prononce par une décision écrite d'acceptation.
Faut-il tout recetter à chaque livraison ?
Vérifiez les nouveautés, puis rejouez un petit ensemble de cas essentiels déjà validés. Une correction peut en effet perturber une fonction qui marchait.
Qui décide si un écart est une anomalie ou une évolution ?
Le besoin écrit tranche. Si le comportement attendu y figure, c'est une anomalie ; sinon, c'est une demande nouvelle à prioriser séparément.
Combien de temps prévoir pour la recette ?
Assez pour dérouler les cas préparés avec les utilisateurs concernés, sans empiéter sur leur activité. Une recette bâclée reporte les problèmes après la mise en service.
Service lié
Articles liés
Rédigé par l'équipe NexSecure. Responsable de la publication : Yohann Toumine. Dernière mise à jour le 11 septembre 2026.
Une question sur votre situation ? Parler de votre projet