La recette : comment la préparer pour qu'elle serve à quelque chose

La recette est la phase que tout le monde sait indispensable et que personne ne prépare. Elle arrive en fin de projet, quand le budget est entamé et le planning tendu, et on demande à des gens déjà surchargés de « tester l’application » pendant deux semaines.

Le résultat est prévisible : quelques remarques sur les libellés, une validation par lassitude, et les vrais problèmes découverts en production trois semaines plus tard.

Ce qui ne va pas dans une recette improvisée

Personne n’a de temps. Les personnes désignées ont un métier à plein temps. « Tester quand tu peux » se traduit par une heure le vendredi après-midi, dans le désordre.

On teste ce qu’on a sous les yeux. Sans scénarios, on clique au hasard sur ce qu’on comprend. Les parcours complexes — ceux qui échouent — sont justement ceux qu’on n’ose pas essayer.

Les données sont trop propres. Un jeu de test créé par l’équipe de développement contient des clients bien renseignés et des dossiers cohérents. La production contient des noms en majuscules avec des espaces en trop, des adresses vides et des dossiers ouverts en 2014.

On confond recette et démonstration. Une démonstration montre que ça marche. Une recette cherche là où ça casse. Ce ne sont pas les mêmes gestes, ni le même état d’esprit.

Préparer la recette avant de développer

Je prépare la recette au moment du cadrage, pas à la fin. Trois éléments, chacun décidé au début.

Des personnes nommées, avec du temps bloqué

Pas « le service comptabilité » : deux prénoms, avec des créneaux réellement inscrits dans leur agenda et validés par leur responsable.

C’est la partie politique du travail, et c’est celle qui détermine tout le reste. Un jour de recette non planifié n’aura pas lieu — c’est une règle sans exception.

Ordre de grandeur : comptez un jour de recette pour cinq à sept jours de développement. Sur un projet de trois mois, cela représente une bonne dizaine de jours, à répartir.

Des scénarios, écrits à partir de situations réelles

Pas une liste de fonctionnalités à cocher. Des histoires : « Un client appelle pour modifier une commande déjà validée mais pas encore expédiée. Faites la modification et vérifiez que la facture est corrigée. »

Ces scénarios traversent l’application comme un utilisateur réel, et ils sortent des sentiers prévus par les développeurs. Ce sont les métiers qui les écrivent — ils connaissent les situations qui posent problème, y compris celles qu’ils n’ont jamais mentionnées parce qu’elles leur paraissent évidentes.

Une dizaine de scénarios bien choisis vaut mieux qu’une grille de deux cents cases.

Un jeu de données qui ressemble au réel

Idéalement, un extrait anonymisé de la production. À défaut, un jeu construit délibérément avec les cas tordus : le client sans adresse, le nom avec une apostrophe, le montant à zéro, le dossier au statut incohérent hérité de l’ancien système.

C’est le point qui fait la plus grande différence sur le nombre d’anomalies trouvées, et de loin.

Photo : Kristin Hardwick — licence CC0.

Pendant la recette

Recetter en continu, pas à la fin. Chaque lot livré est recetté dans les jours qui suivent. Une anomalie trouvée deux semaines après l’écriture du code coûte bien moins cher qu’une anomalie trouvée trois mois après — le développeur a encore le sujet en tête.

Classer les anomalies dès leur ouverture. Bloquant, majeur, mineur. Sans cette qualification, tout arrive avec la même urgence et l’équipe passe la dernière semaine sur des détails cosmétiques pendant qu’un problème sérieux attend.

Distinguer l’anomalie de l’évolution. « Ça ne marche pas comme prévu » et « en fait je préférerais autrement » sont deux choses différentes. La première se corrige dans le forfait, la seconde s’arbitre. Ne pas faire cette distinction est le meilleur moyen de faire déraper la fin de projet.

Le critère de sortie, décidé à l’avance

C’est le point que je fixe systématiquement au cadrage : à quelles conditions met-on en production ?

Ma formulation habituelle : zéro anomalie bloquante, zéro anomalie majeure non contournable, et les anomalies mineures listées et planifiées.

Sans ce critère écrit à l’avance, la décision de mise en production se prend sous pression, à l’appréciation de qui parle le plus fort ce jour-là. Avec lui, elle devient factuelle — et personne n’a besoin d’arbitrer dans l’urgence.

Photo : rawpixel — licence CC0.

Photo : domaine public (CC0).

Faire recetter des gens qui n’ont pas l’habitude

La plupart des recetteurs ne sont pas testeurs de métier. Ils font leur travail, et on leur demande soudain de chercher des défauts — ce qui n’est pas naturel.

Trois choses aident réellement.

Expliquer qu’on cherche les problèmes. Beaucoup de gens n’osent pas signaler un défaut, par crainte de paraître négatifs ou de vexer l’équipe. Je le dis explicitement en ouverture : une recette sans anomalie remontée n’est pas une bonne nouvelle, c’est un signal d’alerte.

Donner un canal unique et simple. Un formulaire, un tableau partagé, peu importe — mais un seul. Les retours dispersés entre des e-mails, des messages et des notes manuscrites se perdent, et le recetteur qui voit son signalement ignoré cesse d’en faire.

Répondre à chaque remontée. Même par « c’est le comportement attendu, voici pourquoi ». Une anomalie sans réponse enseigne que ça ne sert à rien de remonter, et la recette s’éteint en quelques jours.

Ce que la recette révèle sur le projet

Au-delà des anomalies, la recette est un bon indicateur de santé.

Beaucoup d’anomalies mineures et aucune majeure : le cadrage était bon, le développement solide. C’est la situation normale.

Peu d’anomalies mais des remarques du type « ce n’est pas ce qu’on attendait » : le problème est en amont. Il faut arrêter la recette et reprendre l’arbitrage plutôt que d’ouvrir des tickets.

Beaucoup d’anomalies bloquantes sur des cas simples : le développement n’a pas été testé avant livraison. La bonne réaction n’est pas de recetter plus fort, c’est de traiter la cause — la recette n’est pas là pour remplacer les tests de l’équipe.

Consigner une anomalie utilement

La qualité des remontées détermine le temps que prendra la correction, et elle s’améliore avec trois consignes très simples.

Ce que j’ai fait, étape par étape, à partir de l’écran d’accueil. Ce que j’attendais. Ce que j’ai obtenu, avec une capture d’écran. Trois lignes suffisent.

À cela j’ajoute deux informations que les testeurs oublient toujours : l’heure exacte — elle permet de retrouver la trace côté serveur en quelques secondes — et le compte utilisé, parce qu’une anomalie liée aux droits ne se reproduit pas avec un autre profil.

Une remontée du type « ça ne marche pas sur la page devis » coûte en moyenne deux allers-retours avant même de commencer à chercher. C’est le poste de temps perdu le plus évitable de toute la phase de recette.

Ce que la recette n’est pas

Ce n’est pas le moment de découvrir le besoin. Si un utilisateur dit en recette « ah mais ce n’est pas du tout ce qu’il me faut », le problème n’est pas la recette : c’est le cadrage, et il a échoué trois mois plus tôt.

C’est d’ailleurs pour cela que je fais valider des maquettes et des versions intermédiaires très tôt. La recette doit vérifier que ce qui a été construit fonctionne — pas découvrir ce qu’il fallait construire.