Le recettage (recette fonctionnelle) : définition et déroulé

Définition

Le recettage, ou recette fonctionnelle, est la phase de vérification qui précède la mise en ligne d'un site ou d'une application. Elle confronte le produit livré au besoin exprimé, cas de test par cas de test, sur un environnement de préproduction. Elle se conclut par une décision explicite : le livrable est accepté, ou il repart en correction.

Le verbe vient du vocabulaire des marchés : recetter un livrable, c'est l'accepter formellement après vérification. Dans un projet digital, celui qui recette est le client, jamais celui qui a développé. Un prestataire qui vous annonce que « la recette est faite » a fait ses tests ; la recette, elle, vous appartient.

À quoi sert le recettage

Un recettage tient quatre engagements à la fois.

• Prouver la conformité. Chaque exigence du cahier des charges doit trouver sa vérification. C'est ce qui vous permet de refuser une livraison sans que la discussion tourne au ressenti.
• Protéger le lancement. Les dégâts coûteux se jouent sur quelques points précis : un formulaire qui n'envoie rien, un tunnel de paiement qui bloque, des redirections oubliées. Je les traite en priorité absolue.
• Déclencher les suites contractuelles. La signature du procès-verbal de recette fait souvent courir la garantie et libère le solde. Une recette floue laisse ces deux sujets en suspens.
• Faire entrer les équipes métier. Ceux qui utiliseront l'outil au quotidien découvrent le produit avant les clients, et repèrent des incohérences qu'aucun développeur ne peut voir.

Comment se déroule un recettage

Le déroulé que j'applique tient en six temps, et je ne saute aucun des deux premiers.

1. Écrire le cahier de recette avant la livraison, à partir des exigences fonctionnelles.
2. Geler une version sur un environnement de préproduction identique à la production, avec des données réalistes.
3. Dérouler les cas de test, un testeur par périmètre, en notant le résultat obtenu et pas seulement un verdict.
4. Qualifier chaque anomalie par sa sévérité, ce qui détermine si elle bloque la mise en ligne.
5. Corriger, livrer une nouvelle version, puis retester les cas concernés et ceux qu'ils touchent.
6. Prononcer la recette, avec la liste des réserves acceptées et leur date de résolution.

La qualification des anomalies est le point où les projets se disputent. Je la pose par écrit avant la campagne, avec trois niveaux seulement.

Les erreurs que je vois le plus souvent

• Recetter sur la production. Les tests polluent les données réelles et les visiteurs voient passer des versions instables.
• Tester à l'œil. Trois personnes qui cliquent au hasard pendant une heure ne remplacent pas une liste de cas écrite ; elles voient toutes la même page d'accueil.
• Oublier les redirections. Sur une refonte, le plan de redirection 301 se teste sur un échantillon représentatif avant la bascule, pas le lendemain.
• Ne pas budgéter le temps de correction. Une campagne de recette produit des anomalies ; si le planning ne prévoit rien après, la recette devient décorative.

Recettage, tests, VABF : les termes voisins

Le mot recouvre plusieurs réalités selon l'interlocuteur, et la confusion coûte des jours de planning.

• Tests unitaires et d'intégration. Ils sont écrits et joués par les développeurs, sur le code. Ils précèdent le recettage sans le remplacer.
• Recette technique. Elle porte sur la performance, la sécurité et l'infrastructure, pas sur le comportement fonctionnel.
• VABF et VSR. La vérification d'aptitude au bon fonctionnement se fait avant la mise en service ; la vérification de service régulier observe le produit en usage réel pendant une période convenue.

Pour la version longue, avec les sept familles de tests et l'organisation d'une campagne, j'ai détaillé tout cela dans mon guide sur la recette d'une refonte. Et si vos exigences ne sont pas écrites sous une forme testable, le problème se règle en amont, au moment d'écrire les user stories et leurs critères d'acceptation.

À propos de l'auteur

Laurent Tulpan

Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il pilote les campagnes de recette de ses clients et refuse les mises en ligne qui ne sont pas couvertes par un cahier de test. Découvrir son approche.