La recette informatique, c'est le moment où l'on vérifie qu'un logiciel fait ce qu'on attend de lui avant de l'ouvrir à ses vrais utilisateurs. Sur le papier, tout le monde est d'accord. En pratique, c'est la phase qu'on comprime quand le planning glisse, celle où chacun teste un peu son coin, et celle qu'on regrette la semaine suivant la mise en ligne.
J'en parle parce que j'ai mené des recettes jusqu'à la mise en production, notamment sur une intégration entre un ERP et un site marchand, et parce que je passe une bonne partie de mon temps à construire des contrôles automatiques pour mes machines de contenu. Les deux se ressemblent plus qu'on ne croit. Voici comment j'organise une recette aujourd'hui : un cahier que les gens lisent, des parcours testés de bout en bout, une vérification faite comme un visiteur, et une checklist qui dit clairement quand on peut ouvrir.
01Ce qu'on appelle recette, et ce qu'elle n'est pas
Le mot recouvre plusieurs choses. La page Wikipédia sur le test d'acceptation distingue la recette usine, menée par le fournisseur avant livraison, la recette utilisateur (VABF), menée par le client et sa maîtrise d'ouvrage, puis la vérification de service régulier, en production, avec des données réelles, souvent sur un site pilote.
Cette distinction évite un malentendu fréquent. Les tests du prestataire ne sont pas la recette du client. Ils disent que le logiciel fonctionne comme il l'a compris. La recette métier dit s'il fonctionne comme vous en avez besoin, ce qui n'est pas la même chose, surtout quand la spécification a beaucoup bougé. C'est d'ailleurs pour ça que je versionne une spécification d'intégration : la recette se fait contre une version précise, pas contre le souvenir de la dernière réunion.
Je garde aussi en tête ce que dit le Scrum Guide de la définition de « terminé » : une description formelle de l'état attendu, et ce qui ne la respecte pas ne se livre pas. La recette, c'est l'endroit où cette définition devient concrète.
02Le cahier de recette que les gens lisent vraiment
Un cahier de recette de quarante pages que personne n'ouvre ne sert à rien. Le mien tient dans un tableur, une ligne par scénario, avec peu de colonnes :
- le parcours concerné et l'étape testée ;
- les données de départ (quel client, quel produit, quel compte) ;
- l'action à faire, en une phrase ;
- le résultat attendu, écrit avant le test ;
- le résultat obtenu, la date et la personne qui a testé ;
- le statut : passé, anomalie bloquante, anomalie mineure.
Si vous ne soignez qu'une colonne, prenez le résultat attendu. Quand elle est vide, le testeur décide sur le moment si « ça a l'air bon », et deux personnes ne décident pas pareil. L'écrire avant oblige à relire la spécification et fait souvent apparaître des trous dedans, ce qui est déjà un bon résultat.
En tête du document, une page de plan de recette : qui teste quoi, sur quel environnement, à quelles dates, et surtout la liste des cas qui bloquent la mise en production. Cette liste s'écrit avec le métier, avant de commencer.
Trois niveaux, décidés avant de tester
Pour mes machines de contenu, j'ai un contrôle qui relit chaque article avant publication et rend un verdict à trois niveaux. Rouge : un seul point suffit à bloquer. Orange : c'est peut-être légitime, mais l'article ne part qu'avec une justification écrite de chaque point. Vert : on publie. Je détaille ce fonctionnement dans la note sur ma machine de contenu IA.
J'applique la même grille au statut d'un scénario de recette. Rouge, c'est l'anomalie bloquante de la liste. Orange, c'est l'anomalie qu'on accepte d'emporter en production, avec une phrase qui dit pourquoi et qui la suit. Sans cette phrase, l'orange devient du vert par défaut, et c'est exactement comme ça qu'une liste de « mineures » grossit jusqu'au jour de l'ouverture.
03Recetter le parcours entier, pas les écrans un par un
Sur une intégration entre un ERP et un site marchand, raccordés par API temps réel et par flux batch, tester chaque écran séparément ne disait presque rien. Ce qu'il fallait vérifier, c'était qu'une commande passée d'un côté arrive juste de l'autre, avec les bonnes données, au bon moment, y compris quand le flux de nuit passe après une modification faite dans la journée.
La documentation d'Odoo sur les montées de version dit la même chose avec ses mots : tester autant de flux métier que possible, de l'achat à la facturation, ainsi que les intégrations avec les logiciels externes et les actions automatisées. Elle rappelle aussi que la base de test est neutralisée (e-mails, paiements et actions planifiées désactivés). C'est rassurant, mais cela veut dire que certains comportements de production ne se voient pas en test.
Comment j'écris un scénario de bout en bout
- Partir d'un cas réel du métier, pas d'un cas inventé pour la démo.
- Suivre la donnée d'un système à l'autre : création, transmission, réception, document final.
- Vérifier le résultat là où il est utilisé (la facture, le stock, l'écran du client), pas seulement là où il a été saisi.
- Rejouer le même scénario après le passage des flux batch.
- Noter l'écart exact quand il y en a un, avec la donnée de départ, pour que la personne qui corrige puisse le reproduire.
Recetter les données, pas seulement les écrans
J'ai appris à recetter les données de référence, pas seulement les écrans. Un mélange d'unités entre deux outils, des centimètres d'un côté et des millimètres de l'autre, peut déformer tout un rendu sans qu'aucun test d'écran le voie : chaque écran affiche une valeur plausible. La seule parade, c'est une donnée de référence explicite, et un contrôle qui la compare de bout en bout.
Quand un calcul compte, je vais plus loin. Chez Moonworkers, qui fait de la paie pour les petites entreprises britanniques, on a écrit un « oracle » à partir des textes du HMRC, indépendant du code testé, et on lui a fait rejouer 896 cas de cotisations. Il a trouvé quatre erreurs d'un penny, toutes dues à une règle d'arrondi. Aucun testeur ne les aurait vues à l'œil, et pourtant une fiche de paie fausse d'un penny reste une fiche de paie fausse.
04Vérifier comme un visiteur, pas comme l'équipe
Un site peut sembler normal à l'équipe connectée et être cassé pour les visiteurs. Je l'ai vu : l'équipe, connectée à l'administration, ne recevait pas la même page que les visiteurs, à cause du cache. Votre équipe voit le site connectée, vos clients non. Depuis, je vérifie un site comme un visiteur : navigation privée, sans session, sur un téléphone, depuis un réseau qui n'est pas celui du bureau.
C'est devenu une étape fixe de mes machines de contenu : après publication, je vérifie la page publique, pas le formulaire du CMS. Réponse 200, image et texte alternatif, intertitres, liens internes qui répondent. Un formulaire peut garder le contenu injecté alors que rien n'est parti en ligne.
Pour les pages publiques, j'ajoute un regard extérieur de plus. Le test de l'URL en ligne de l'outil d'inspection d'URL de la Search Console affiche une capture de la page telle que Google la rend et la liste des ressources chargées. Si une feuille de style ou un script ne passe pas, cela se voit là, et ce n'est pas l'équipe connectée qui l'aurait remarqué.
05La checklist de mise en production
La veille, et le jour même, je reprends la même liste. Je vous la donne telle quelle, à adapter à votre projet. Elle doit beaucoup à la documentation d'Odoo, qui recommande de répéter entièrement la procédure la veille et prévient qu'une fois la montée de version lancée, on ne revient pas en arrière, et à la page du GOV.UK Service Manual sur le passage en live, qui demande notamment de pouvoir surveiller la disponibilité du service et d'avoir formé les équipes de support.
- Les cas bloquants de la liste sont tous passés, et la décision d'ouvrir est écrite, avec le nom de qui la prend.
- Chaque anomalie emportée en production a sa justification écrite et son responsable.
- Un test qui n'a pas pu être fait compte comme un échec, pas comme un succès.
- La procédure a été répétée de bout en bout sur une copie récente de la production.
- On sait ce qui se passe si on doit revenir en arrière, ou on sait qu'on ne peut pas, et tout le monde l'a entendu.
- Les saisies en production sont gelées pendant la bascule, et les utilisateurs savent quand.
- Les flux et les tâches planifiées désactivés en test sont réactivés et vérifiés.
- Quelqu'un regarde les premières commandes, les premières factures et les premiers échanges de flux.
- Les personnes qui répondent aux utilisateurs savent ce qui change et à qui remonter un problème.
- Une vérification en visiteur est faite juste après l'ouverture.
La troisième ligne vient directement de mes outils. Le piège d'un contrôle, c'est le vert par défaut quand il n'a pas tourné : un environnement indisponible, un testeur absent, un scénario « qu'on fera après ». Sur ma machine la plus stricte, une vérification qui n'a pas eu lieu donne un rouge. En recette, je fais pareil.
06Ce que la recette ne vous dira pas
Une recette bien menée réduit les surprises, elle ne les supprime pas, et je préfère le dire avant la date plutôt qu'après. Les volumes réels, les habitudes de saisie des utilisateurs et les comportements des partenaires ne se reproduisent jamais complètement en test, et la documentation d'Odoo le dit à sa façon quand elle explique ce qui est désactivé dans une base de test.
Elle coûte aussi du temps aux gens du métier, qui ont déjà leur travail. Si personne ne peut se libérer, je préfère le dire tôt et décaler, plutôt que de faire recetter par l'équipe projet ce qu'elle a elle-même construit. Et je ne fais pas tout tester : je choisis les parcours qui coûtent cher quand ils cassent, et j'accepte de découvrir le reste en production, avec quelqu'un qui regarde.
Un oracle comme celui de Moonworkers a aussi ses limites : il ne vaut que ce que vaut sa lecture des textes officiels. S'il se trompe de la même façon que le code, il ne voit rien. C'est pour ça qu'il doit être écrit à partir de la source, par quelqu'un qui n'a pas écrit le code testé.
07Par où commencer la semaine prochaine
Si votre mise en production approche, commencez par deux choses : écrire avec le métier la liste des cas qui bloquent l'ouverture, et choisir trois parcours de bout en bout à recetter en entier, données comprises. Le tableur peut attendre une heure, ces deux décisions non.
C'est le genre de chantier que je mène dans mes missions de direction de projet et de direction technique. Si vous êtes à quelques semaines d'une mise en production, on peut en parler.