Beaucoup de projets logiciels se jouent sur leurs dernières semaines, et pas dans le bon sens. Le développement est fini, tout le monde veut mettre en ligne, et la recette se réduit à un « ça a l’air de marcher » de cinq minutes. Trois semaines plus tard, l’outil casse sur un cas que personne n’avait testé, en pleine production, avec des vrais utilisateurs devant.
La recette n’est pas une formalité de clôture. C’est le moment qui décide si votre logiciel est prêt, ou seulement s’il en a l’air. Voici comment la mener pour qu’elle vous protège.
La recette commence dans le cahier des charges
On ne peut pas recetter ce qu’on n’a pas défini. Les critères de recette, cette liste de conditions vérifiables qui disent « c’est fait », doivent être écrits au moment de cadrer le projet, pas inventés à la fin. C’est le lien direct avec un bon cahier des charges : sans critères convenus à l’avance, la recette devient une négociation sans fin sur le sens du mot « terminé ».
Si ces critères existent, la recette est simple : on les passe un par un, chacun donne un oui ou un non. Le flou disparaît.
Ce qu’un plan de tests doit couvrir
Le parcours normal. Le cas où tout se passe bien, pour chaque type d’utilisateur. C’est la base, et c’est la partie facile : elle marche presque toujours.
Les cas d’erreur et les bords. C’est là que se cache la robustesse. Que se passe-t-il si un client annule après paiement, si un fichier importé est corrompu, si deux personnes modifient la même fiche en même temps, si une connexion tombe au milieu d’une opération ? Ces situations ne se voient pas dans une démo. Elles se produisent en vrai, et un logiciel sérieux les gère proprement.
Les données réelles. Tester sur trois enregistrements propres ne prouve rien. Il faut passer un volume réaliste, avec la vraie diversité de vos données, y compris les cas historiques bancals. Beaucoup de bugs n’apparaissent qu’au contact de données réelles.
Les connexions à l’existant. Chaque intégration à un autre outil doit être testée dans les deux sens, y compris quand l’autre système est lent ou indisponible. Une intégration qui marche quand tout va bien et plante au premier hoquet n’est pas terminée.
La performance sous charge, si c’est un enjeu. Un logiciel qui répond bien pour cinq utilisateurs peut s’effondrer à cinq cents. Si la montée en charge fait partie du besoin, elle fait partie de la recette.
Qui teste, et pourquoi ça compte
Les meilleurs tests viennent de ceux qui utiliseront l’outil tous les jours. Le prestataire vérifie la technique et les cas qu’il a prévus ; le client apporte les situations tordues que seul son terrain connaît. Une recette menée uniquement côté prestataire rate systématiquement les cas métier réels. Une recette menée uniquement côté client rate les cas techniques. Il faut les deux.
La recette conditionne la mise en production, pas l’inverse
L’ordre compte. On ne met pas en production pour recetter ensuite. On recette, on corrige ce qui bloque, et la mise en production devient la conséquence d’une recette réussie, pas un pari. C’est cette discipline qui fait qu’une mise en ligne se passe sans surprise, et qu’un retour arrière reste possible et propre si un imprévu survient malgré tout. À l’inverse, sauter la recette, c’est prendre le risque du site en ligne mais cassé, découvert par les utilisateurs avant vous.
Comment on l’intègre à nos missions
Sur un développement au forfait à scope fermé, la recette n’est pas une option en fin de parcours, elle est engagée dès le contrat : les critères sont écrits au cadrage, le plan de tests en découle, et la mise en production n’a lieu qu’une fois la recette passée. Et parce qu’un logiciel vit après sa livraison, on peut prolonger la surveillance avec un filet de sécurité qui garde un œil sur ce qui a été livré, sans usine à tickets.
Tester ce qui compte avant que ça casse coûte toujours moins cher que de réparer en production, sous le regard des utilisateurs.
Pour aller plus loin
- Rédiger un cahier des charges : d’où viennent les critères de recette
- Développement de logiciel sur-mesure : recette engagée au contrat
- Rollback d’une mise en production à 23h : quand le retour arrière sauve la nuit
- Filet de sécurité : la surveillance après la mise en production