Imaginez un vendredi, 17 h. Le nouveau logiciel de gestion passe en production, tout le monde est content, on se souhaite un bon week-end. Le lundi à 8 h, la première réservation tombe en double, le deuxième devis part sans la remise convenue, et personne ne sait dire si le problème vient du logiciel, de l'import des anciennes données ou d'un mauvais réglage. Ce scénario n'a rien d'exceptionnel. Il arrive presque toujours quand on a livré sans avoir sérieusement testé.
En bref
Pour tester un logiciel métier avant la mise en production, il faut un cahier de recette écrit à l'avance, des utilisateurs réels qui déroulent leurs vrais parcours, un environnement et des données proches de la réalité, puis une validation écrite. Les développeurs ne peuvent pas remplacer vos équipes dans cette étape.
Pourquoi on teste presque toujours trop tard
La recette est la dernière étape avant la livraison, celle où l'on vérifie que l'application respecte le cahier des charges et qu'elle est opérationnelle. C'est aussi, selon un article de Solutions Numériques consacré à la recette, une phase régulièrement sous-estimée, avec à la clé des dysfonctionnements qui coûtent cher : retards de livraison, ruptures de stock, erreurs de facturation.
La raison est humaine. En fin de projet, le calendrier est serré, tout le monde veut voir l'outil en service, et la recette ressemble à une formalité qui retarde la joie. Pourtant, un article du Journal du Net sur les tests logiciels rappelle qu'une erreur corrigée à la conception coûte très peu face à la même erreur corrigée en production, avec un rapport d'environ 1 à 100. Le texte date de 2011 et ce ratio est un ordre de grandeur, pas une mesure sur votre projet, mais le sens ne change pas : un défaut trouvé tôt se corrige vite, un défaut trouvé par un client se paie en confiance.
Mon avis est simple. Le test n'est pas une étape qu'on ajoute à la fin si le budget le permet. C'est la moitié du travail de livraison, et il faut le prévoir dans le calendrier dès le départ.
Les quatre familles de tests, et ce qui vous revient
Quand on parle de tests, on mélange souvent des choses très différentes. Le consultant Eric Kimberling, dans un guide de Third Stage Consulting sur les tests avant mise en service, distingue trois niveaux : les tests unitaires, les tests d'intégration de bout en bout, puis les tests d'acceptation utilisateur. Solutions Numériques ajoute les tests de non-régression, qui vérifient qu'une nouvelle fonctionnalité n'abîme pas ce qui marchait déjà.
| Famille de tests | Ce qu'on vérifie | Qui s'en charge | Votre rôle |
|---|---|---|---|
| Unitaires | Chaque fonction isolée fait ce qu'elle doit | Le développeur | Aucun |
| Intégration | Les flux entre logiciels (paiement, calendrier, comptabilité) | Le développeur, avec vos accès | Fournir les accès et les cas réels |
| Non-régression | Rien de l'existant n'a été cassé | Le développeur | Signaler ce qui vous semble critique |
| Recette utilisateur | L'outil répond à votre métier, pas seulement au cahier des charges | Vous et vos équipes | Tout le travail |
Ce tableau dit une chose que les prestataires n'aiment pas toujours rappeler : les trois premières lignes sont de notre responsabilité, la dernière est la vôtre. Un logiciel peut passer tous les tests techniques et rester inutilisable parce qu'un écran impose six clics là où votre équipe en fait deux. Seule une personne qui fait le métier le voit.
Écrire le cahier de recette avant la fin du développement
Un cahier de recette est une liste de scénarios. Chaque scénario décrit ce que la personne fait, ce qu'elle doit obtenir, et à quelle condition on considère le test réussi. Solutions Numériques insiste sur ce point : il faut définir à l'avance les critères de réussite, et partir du cahier des charges initial. Si vous n'en avez pas, notre article sur le cahier des charges d'une application métier explique comment en construire un utile.
Un bon scénario ressemble à une journée réelle, pas à une démonstration. Par exemple, pour un institut ou un gîte : une cliente réserve un soin pour deux personnes, paie un acompte, puis modifie la date trois jours plus tard. Vérifie-t-on que le créneau initial est libéré, que l'acompte suit, que le message de confirmation part avec la bonne date ? Voilà un scénario. Un test qui se contente de « créer une réservation » ne prouve presque rien.
Je recommande de prévoir trois types de scénarios :
- les parcours qui se produisent tous les jours, qui doivent être fluides ;
- les cas limites, comme un nom avec accent, une annulation tardive, un champ laissé vide ;
- les erreurs volontaires, comme un paiement refusé ou une connexion coupée en cours de saisie.
La règle du « 3×3 » citée par Third Stage Consulting, tester chaque élément trois fois et recommencer après chaque modification, est une consigne pratique plus qu'une loi. Retenez surtout l'idée : un test réussi une fois ne dit rien d'une modification faite le lendemain.
Choisir les bons testeurs
C'est l'erreur que je vois le plus souvent : demander au développeur de « bien vérifier » et de considérer que la recette est faite. Le développeur connaît le chemin que le logiciel attend, donc il le suit sans le savoir. Un guide de Marker.io sur la liste de contrôle d'une recette utilisateur le dit clairement : les développeurs peuvent soutenir le processus, mais ne remplacent pas les utilisateurs réels dans la validation.
Dans une TPE, cela veut dire deux ou trois personnes, pas davantage : quelqu'un qui connaît le métier de bout en bout, quelqu'un qui n'est pas à l'aise avec l'informatique (c'est lui qui trouvera ce qui est confus), et la personne qui décidera de la mise en production. Il faut leur libérer du temps réel, une demi-journée par exemple, pas dix minutes entre deux appels.
Un environnement et des données qui ressemblent à la vraie vie
Un test dans un environnement irréaliste ne détecte pas les problèmes réels. Third Stage Consulting le range parmi les pièges principaux, avec la tentation de ne tester que le scénario idéal. L'environnement de test doit donc ressembler à celui de production : même version, mêmes connexions aux services tiers, des volumes de données comparables.
Reste la question des données. Il est tentant de copier les vraies fiches clients pour que le test soit plus fidèle. Je vous le déconseille tel quel : des données personnelles réelles dans un environnement de test, souvent moins protégé que la production, posent un problème de conformité avec le RGPD. Deux solutions propres : des données fictives mais réalistes (noms variés, cas tordus, doublons), ou des données réelles anonymisées. Au moindre doute sur votre situation, c'est un sujet à vérifier avec un conseil juridique.
Les parcours qui coûtent cher quand ils cassent
Tous les écrans ne se valent pas. Le Journal du Net recommande de concentrer l'effort sur les processus critiques, ceux dont une défaillance bloque l'activité, en fixant un seuil de défauts toléré selon leur criticité. Je transpose cela à une règle de bon sens : testez d'abord ce qui touche à l'argent, au calendrier et aux données des clients.
Sur Simply Spa, notre logiciel de réservation et de gestion pour spas et instituts, ce sont les premiers points que je regarde : le paiement, la synchronisation des calendriers, et le risque de réservation en double. Un écran de réglages mal aligné se corrige en une heure sans conséquence. Un créneau vendu deux fois, lui, se retrouve face à deux clients au même moment. Le même raisonnement vaut pour Postwa ou Geko : on commence par ce qui a une conséquence concrète pour la personne qui s'en sert.
Et soyons honnêtes sur la limite : aucune recette ne garantit zéro défaut en production. Je ne le promets à personne. Ce qu'elle garantit, c'est que les défauts qui restent sont mineurs, connus et documentés, et qu'aucun ne vous prendra par surprise un lundi matin.
Critères de validation et décision de mise en production
La recette se termine par une décision, pas par une impression. Avant de commencer, mettez-vous d'accord sur ce qui bloque et ce qui se tolère : un défaut bloquant (impossible de payer, impossible de se connecter) empêche la mise en ligne, un défaut mineur (une faute dans un libellé) se planifie dans une version suivante.
Marker.io insiste sur deux éléments que je reprends à mon compte. D'abord, une validation documentée : un accord par message dans une conversation n'est pas une approbation. Un document signé ou un courriel clair, avec la liste des défauts acceptés, protège les deux parties. Ensuite, un plan de retour arrière : si la mise en production tourne mal, comment revient-on à l'état précédent, et en combien de temps ? Si la réponse est « on ne sait pas », la mise en ligne n'est pas prête.
Après la mise en ligne : la recette ne s'arrête pas
Les premiers jours de production sont une extension de la recette. Solutions Numériques recommande un suivi après déploiement, et c'est la bonne pratique : surveiller les erreurs, recueillir les retours des premiers utilisateurs, corriger vite. Prévoir une période de suivi rapproché, quelques semaines, évite que les petits défauts s'accumulent. Ensuite vient le régime normal décrit dans notre article sur la maintenance d'une application métier.
Ce que cela change sur le calendrier
Si votre projet est un premier produit, comptez le test dans le délai dès le départ. Un MVP bien cadré se construit en environ 1 mois, et la recette en fait partie : ne la traitez pas comme un supplément. Notre article sur la manière de développer un MVP d'application métier détaille ce que contient ce premier mois. Pour une vue d'ensemble de notre façon de travailler, la page sur le développement de SaaS sur mesure rassemble nos approches.
Mon verdict
Tester un logiciel métier avant la mise en production demande moins de technique que de rigueur. Écrivez les scénarios avant la fin du développement, faites tester par ceux qui feront tourner l'outil, utilisez des données réalistes mais pas imprudentes, et exigez une validation écrite. Si un prestataire vous propose de passer directement en production « pour gagner du temps », demandez-lui qui supportera le premier lundi matin.
Questions fréquentes
Qui doit réaliser la recette d'un logiciel métier ?
Les utilisateurs réels, pas le développeur. Le prestataire exécute les tests techniques, mais seule une personne qui fait le métier peut dire si l'outil convient. Deux ou trois testeurs, dont un moins à l'aise avec l'informatique, suffisent pour une TPE.
Combien de temps prévoir pour tester un logiciel avant sa mise en production ?
Cela dépend du nombre de parcours et d'intégrations. Pour un premier produit bien cadré, la recette se prépare pendant le développement puis occupe quelques jours dédiés à la fin. L'essentiel est de la planifier dès le départ.
Peut-on utiliser les vraies données clients pour tester ?
Il vaut mieux l'éviter. Des données personnelles réelles dans un environnement de test posent un risque de conformité au RGPD. Préférez des données fictives réalistes ou anonymisées, et vérifiez votre situation avec un conseil juridique.
Que faire si un défaut apparaît après la mise en ligne ?
Évaluez s'il est bloquant. S'il l'est, appliquez le plan de retour arrière ou un correctif d'urgence. Sinon, documentez-le, planifiez-le dans la version suivante et informez les utilisateurs concernés.
Pour conclure
Tester un logiciel métier avant la mise en production évite le lundi matin décrit plus haut. Si vous préparez la livraison d'un outil et voulez cadrer votre recette, vous pouvez nous écrire via la page contact, nous regarderons ensemble vos parcours critiques.
Photo : Vitaly Gariev sur Unsplash
