15 juillet 2026
La recette est le moment le plus mal aimé des projets informatiques. Programmée à la fin, confiée à des équipes déjà débordées, sur des données de test irréalistes. Puis tout le monde s'étonne que les vrais problèmes apparaissent en production, sous les yeux des clients.
Une recette efficace ne se joue pas à la fin du projet. Elle se prépare dès le cadrage. La méthode qui suit a été éprouvée sur le terrain.
Partir des situations réelles, pas des fonctionnalités
Le réflexe habituel est de tester écran par écran : « la fiche client s'ouvre, le bouton enregistre ». C'est nécessaire, et très insuffisant. Ce qui casse en production, ce sont les parcours complets avec leurs cas tordus : la commande modifiée après facturation partielle, l'avoir sur une facture de l'exercice précédent, le client présent en double.
Construisez vos scénarios à partir du quotidien : « une journée de l'ADV », « une clôture mensuelle », « un retour client ». Les cas vicieux, ce sont les personnes qui font le travail qui les connaissent. Pas le prestataire, et pas le chef de projet.
Écrire des scénarios qu'on peut vraiment dérouler
Un bon scénario de recette tient en trois colonnes : la situation de départ, les actions, le résultat attendu, décrit avec précision. « Vérifier la facturation » n'est pas un scénario. « Créer une commande de 3 lignes avec remise, livrer partiellement, facturer : la facture reprend les 2 lignes livrées avec la remise » en est un. Si le résultat attendu n'est pas écrit, chaque testeur décidera seul de ce qui est « normal ».
Préparer les données avant le premier jour
Une recette sur trois clients de démonstration ne prouve rien. Il faut un jeu de données réaliste, anonymisé si nécessaire, qui contient vos vrais cas : les clients à conditions particulières, les produits composés, l'historique qui fâche. Préparer ce jeu de données prend du temps. C'est précisément pour cette raison qu'on s'y prend tôt.
Qualifier les anomalies avant d'en débattre
Définissez la grille avant la première anomalie, pas pendant la dispute : bloquant (empêche l'activité, interdit la mise en production), majeur (contournable temporairement, correction planifiée), mineur (n'empêche rien, traité au fil de l'eau). Sans grille commune, chaque anomalie déclenche une négociation, et la relation avec le prestataire s'use vite.
Donner du temps aux testeurs, pour de vrai
Le grand mensonge des plannings de recette : « les utilisateurs testeront en plus de leur travail ». Ils ne le feront pas, et ce n'est pas un problème de motivation. Réservez des demi-journées bloquées, remplacez les personnes sur leur poste si nécessaire. Une recette bâclée par manque de temps coûte toujours plus cher que le temps qu'elle a semblé faire gagner.
Conclure par une décision, pas par un soupir
La recette se termine par un document qui dit trois choses : ce qui a été testé, ce qui est accepté, ce qui reste en réserve avec une échéance de correction. Ce procès-verbal n'est pas une formalité administrative. C'est lui qui déclenche la mise en production en connaissance de cause, et il protège les deux parties en cas de désaccord ultérieur.
Un dernier chiffre pour la route. Une anomalie trouvée en recette se corrige tranquillement, en environnement de test. La même anomalie en production se corrige en urgence, avec des données réelles à réparer et des utilisateurs à rassurer. L'écart de coût est couramment d'un facteur dix. La recette n'est pas la fin du projet : c'est elle qui décide si le projet finit bien.