Recette et mise en production d'un logiciel métier

Le prestataire annonce que c'est livré. Vous avez quelques jours pour dire oui ou non, et une signature à poser au bout. La plupart des guides s'arrêtent là où commence le vrai risque : ils décrivent le document à remplir, puis laissent le lecteur seul devant la bascule. Celui-ci suit la séquence entière, de la livraison à la sortie de la surveillance rapprochée, et dit à chaque étape ce qui se décide et ce qui vous engage.

✅ Qu’est-ce que la recette d’un logiciel métier ?

La recette d’un logiciel métier est la phase pendant laquelle l’entreprise qui a commandé l’outil vérifie, avant de l’ouvrir à ses équipes, que ce qui a été livré fait bien ce qui avait été demandé. Elle ne se joue pas sur la qualité du code : le prestataire l’a déjà testée de son côté. Elle se joue sur l’usage réel, processus par processus. Et elle se termine par une décision écrite qui engage les deux parties.

Le référentiel international de test, l’ISTQB, ne parle pas d’une recette mais de plusieurs. Son syllabus consacré au sujet distingue la recette utilisateur (user acceptance testing, ou UAT), la recette contractuelle, la recette réglementaire, ainsi que les phases alpha et bêta. Il mentionne une sixième forme, la recette opérationnelle (operational acceptance testing). Le syllabus l’écarte volontairement de son périmètre : elle est « généralement menée par les équipes qui exploiteront le système plutôt que par les testeurs et les analystes métier ».

Les trois recettes que vous allez réellement croiser

L’usage français a retenu une découpe plus simple que celle de l’ISTQB, et c’est celle que votre prestataire emploiera. Elle ne recouvre pas exactement la taxonomie internationale, mais elle a le mérite de dire qui fait quoi.

Un critère d’acceptation n’est pas un cas de test

Confondre les deux est l’erreur qui produit les cahiers de recette inutilisables. Un critère d’acceptation est, selon l’ISTQB, un énoncé mesurable « qui peut être vrai ou faux » et qui définit ce qu’il faut vérifier. Il ne contient pas la procédure. Les cas de test, eux, en sont dérivés : ils disent comment le vérifier, étape par étape, avec des données précises.

Concrètement : « une facture ne peut pas être validée sans numéro de TVA client » est un critère d’acceptation. « Ouvrir la facture F-2026-014, effacer le champ TVA, cliquer sur Valider, vérifier que le bouton reste inactif et qu’un message rouge apparaît sous le champ » est un cas de test. Le premier vient de votre cahier des charges, le second s’écrit au moment de préparer la recette.

👥 Qui recette, et quand faut-il le faire ?

La recette fonctionnelle revient aux personnes qui utiliseront l’outil quotidiennement, pas au service informatique et pas au prestataire. Ce principe est aussi ce qui la rend difficile à organiser dans une PME : les meilleurs testeurs sont ceux dont le temps est déjà pris. Le calendrier se pose donc bien avant la livraison. Il ne se découvre pas le jour où le prestataire annonce que c’est prêt.

Le cas d’une PME sans maîtrise d’ouvrage

La littérature sur la recette suppose presque toujours une organisation à deux têtes, une maîtrise d’ouvrage côté métier et une maîtrise d’œuvre côté technique. Dans une entreprise de vingt personnes, ces deux entités n’existent pas. Trois rôles suffisent, et ils peuvent être tenus par des gens qui font déjà autre chose.

1. Un référent par processus critique. La personne qui connaît le mieux la facturation teste la facturation. Elle n’a pas besoin de savoir écrire un cas de test : elle a besoin qu’on lui donne la liste des situations à essayer, et le droit de dire que ça ne va pas.
2. Un décisionnaire unique. Quelqu’un qui tranche quand un référent veut bloquer la mise en service pour un détail, ou quand deux services demandent l’inverse l’un de l’autre. Sans lui, la recette s’enlise en discussions.
3. Un point de contact côté prestataire. Une seule adresse où remontent les anomalies, dans un seul outil. Les retours par messages privés se perdent, et personne ne sait plus ce qui a été corrigé.

Recette en cycle en V, recette en agile

En cycle en V, la recette est un bloc situé après le développement : le logiciel est livré complet, testé complet, accepté d’un coup. L’avantage est la lisibilité contractuelle. L’inconvénient est le risque concentré : tout se découvre à la fin, y compris ce qui aurait dû être arbitré six semaines plus tôt.

En agile, la validation se fait au fil des itérations, chaque lot livré étant vérifié dès qu’il arrive. Les mauvaises surprises sont plus petites et arrivent plus tôt. Cela ne supprime pas la recette finale : il reste à vérifier les enchaînements de bout en bout, la reprise des données et les échanges avec vos autres outils, que personne n’a pu tester lot par lot.

Quand une recette allégée suffit

Toutes les livraisons ne méritent pas la procédure complète, et prétendre le contraire serait vous faire perdre du temps. Un outil interne utilisé par trois personnes, sans donnée sensible, sans intégration et sans obligation réglementaire, se valide très bien en une séance de prise en main avec un compte rendu écrit. Ce qui déclenche la procédure complète, ce n’est pas la taille du budget : c’est l’existence d’au moins un de ces quatre éléments : des données personnelles, de l’argent, une obligation réglementaire, ou un processus qui arrête l’activité s’il tombe.

🧰 Ce qu’il faut réunir avant de commencer

Une recette qui démarre sans préparation produit des retours inexploitables : « ça bugue », « ce n’est pas ce que j’imaginais », des captures d’écran sans contexte. Ce qui suit se prépare avant la livraison, pendant que le prestataire développe. Réuni et écrit, cet ensemble porte un nom : c’est le cahier de recette, le document qui dit ce qui sera vérifié, par qui, sur quelles données, et à quelles conditions le logiciel sera accepté. Deux listes, selon qui produit quoi.

Ce que vous rassemblez en interne

1. La liste des processus critiques à couvrir. Pas toutes les fonctionnalités : celles dont l’arrêt coûte de l’argent ou bloque le travail. C’est cette liste qui détermine le périmètre testé, et ce qui en est explicitement exclu.
2. Un jeu de données de test réaliste. Assez varié pour contenir les cas tordus de votre activité : le client sans numéro de TVA, la commande à zéro euro, le dossier vieux de sept ans. Ce sont ces cas-là qui cassent les logiciels, pas les cas moyens.
3. La disponibilité des testeurs, bloquée dans les agendas. Une recette n’entre pas dans les interstices d’une semaine chargée. Les créneaux se posent avant, avec l’accord du responsable de chaque testeur.
4. Un décisionnaire nommé et joignable. Y compris pendant les congés, si la recette tombe en été. Une décision qui attend trois jours coûte trois jours.

Il existe une exception, et elle est encadrée. La CNIL reconnaît que « les tests menés sur les données fictives ou anonymisées ne sont parfois pas suffisants ». Tester en pré-production avec des données réelles devient alors possible, à deux conditions cumulatives : que cet environnement soit « configuré et sécurisé au même niveau que l’environnement de production », et que le service ait « déjà subi l’ensemble des tests (unitaires, d’intégration et fonctionnels) dans les environnements de développement et de test ». Autrement dit, la copie de la base de production sur le poste d’un testeur, pratique courante, ne remplit aucune des deux.

Ce que le prestataire doit fournir

1. Un environnement de recette isolé, avec son adresse et ses comptes d’accès. Distinct de la production, et distinct de l’environnement où les développeurs travaillent : sinon vos tests changent sous vos pieds pendant que vous les déroulez.
2. Les comptes de test correspondant à vos rôles réels. Un administrateur, un utilisateur standard, un profil restreint. Recetter uniquement en administrateur ne prouve rien sur ce que verra l’équipe.
3. La procédure de retour en arrière, écrite et déjà testée. Pas la promesse qu’un retour est possible : la description de ce qui se passe, en combien de temps, et ce qui est perdu au passage.
4. Un canal unique pour remonter les anomalies, avec un modèle de signalement : ce que je faisais, ce que j’attendais, ce qui s’est produit, une capture d’écran.

🛠️ De la recette à la mise en production : la procédure

La séquence complète tient en huit étapes qui se suivent sans se chevaucher. Les cinq premières relèvent de la recette proprement dite, la sixième acte la décision, les deux dernières concernent la mise en production. La plupart des guides s’arrêtent à la sixième. C’est précisément entre la signature et l’ouverture aux utilisateurs que les projets déraillent.

La chronologie, vue de haut

Étapes 1 à 3 : préparer la campagne

1. Figer le périmètre testé. Écrire ce qui sera vérifié et, tout aussi important, ce qui ne le sera pas. Un périmètre non écrit se dilate. Un testeur essaie une fonctionnalité hors sujet, trouve un défaut mineur, et bloque le lancement pour un écran que personne n’utilisera avant six mois.

2. Écrire les cas de test. Un cas de test se juge à un seul critère : quelqu’un qui n’a pas participé au projet doit pouvoir le rejouer à l’identique sans rien interpréter. Cela suppose trois choses : des données nommées précisément, une seule fonctionnalité par cas, et un résultat attendu formulé de façon vérifiable : « un message de confirmation apparaît en haut de l’écran », et non « ça marche ».

3. Préparer les jeux de données et les accès. Charger le jeu de test dans l’environnement de recette, vérifier que chaque testeur peut se connecter avec le bon profil, et confirmer que l’environnement ne sera pas modifié pendant la campagne.

Étapes 4 et 5 : dérouler, qualifier, arbitrer

4. Exécuter les cas et consigner. Chaque cas ressort avec un statut sans ambiguïté : conforme, non conforme, non testé. Un cas « à moitié passé » n’existe pas. Les anomalies partent dans le canal unique, avec le même modèle de signalement pour tout le monde.

5. Qualifier chaque anomalie, puis arbitrer. Trois niveaux suffisent, et c’est la conséquence métier qui décide, pas la difficulté technique de la correction.

• Bloquant : le processus ne peut pas se faire, ou une donnée est fausse. On ne met pas en service
• Majeur : le processus se fait, mais avec un contournement pénible. On met en service si le contournement est documenté et la correction datée
• Mineur : gêne cosmétique ou de confort. On met en service, on corrige plus tard

L’arbitrage le plus délicat n’est pas là. Il porte sur la distinction entre une anomalie, quand le logiciel ne fait pas ce que le périmètre prévoyait, et une évolution, quand il fait exactement ce qui était prévu mais que l’usage réel montre qu’il faudrait autre chose. La seconde est légitime et fréquente. Elle ne se traite pas dans la recette : elle se chiffre à part. Ce départage devient simple quand le périmètre a été écrit noir sur blanc en amont.

Étape 6 : le procès-verbal, et ce que la signature déclenche

6. Acter la décision par écrit. Le procès-verbal de recette n’est pas une formalité administrative : c’est le document qui fait basculer la responsabilité. Il consigne ce qui a été testé, les résultats, les réserves éventuelles, et la décision.

Le cadre le plus documenté en France est celui des marchés publics. Le cahier des clauses administratives générales applicable aux marchés informatiques organise la séquence en étapes distinctes : opérations de vérification, vérifications quantitatives puis qualitatives, décision après vérification, puis admission, l’acheteur pouvant aussi ajourner, appliquer une réfaction ou rejeter. Et surtout, la décision d’admission « vaut constatation de service fait et constitue le point de départ des délais de garantie ».

Retenez ce mécanisme, même si votre contrat est privé : la signature ne dit pas seulement « je suis content », elle déclenche des compteurs. En contrat privé, ce qu’elle déclenche exactement (solde à payer, durée de garantie, passage en maintenance) dépend entièrement de ce que votre contrat prévoit. C’est le moment de le relire, pas après.

Étapes 7 et 8 : la bascule, puis la surveillance rapprochée

7. Décider, basculer, vérifier tout de suite. La mise en production, ou « go-live », se prépare comme une opération minutée : qui fait quoi, dans quel ordre, à quelle heure. Trois éléments méritent d’être fixés à froid, avant le jour J.

• La décision d’ouverture, prise collectivement. Chaque responsable dit oui ou non, explicitement. Un silence n’est pas un oui
• L’heure limite au-delà de laquelle on ne bascule plus. Passé ce point, si tout n’est pas en place, on annule et on recommence une autre fois. Cette heure se fixe la veille, jamais dans le feu de l’action
• Le contrôle immédiat après bascule. Une courte liste de vérifications sur les processus vitaux, déroulée dans les minutes qui suivent l’ouverture : se connecter, créer une pièce, l’enregistrer, la retrouver

Si l’outil remplace un système existant, la reprise des données est le point le plus risqué de la journée, et elle se répète à blanc avant le jour J. Le sujet a ses propres règles, détaillées dans notre guide sur la migration d’Excel vers un logiciel métier.

8. Surveiller de près, puis sortir de la surveillance. Les premiers jours demandent un support renforcé et une relecture régulière des journaux techniques. Cette période s’arrête à des conditions décidées à l’avance : plus aucune anomalie bloquante ouverte, volume d’activité redevenu normal, équipe autonome sur les processus courants. Jamais à une date arbitraire. Chez OTTOPILOTE, elle est couverte par les 30 jours de corrections offerts après livraison, annoncés sur la page forfaits ; au-delà, le suivi mensuel est optionnel et sur devis, et vous restez propriétaire à 100 % du projet, des accès et de la documentation.

💶 Ce que la recette vous coûte vraiment

La recette a un coût, et il ne figure sur aucun devis : c’est du temps pris à vos équipes. Aucune source publique ne le chiffre. Les fourchettes qui circulent (un pourcentage du temps de développement, un nombre de semaines par type de projet) proviennent toutes de blogs d’agences ou d’éditeurs, sans étude nommée derrière. Plutôt que de recopier un chiffre invérifiable, voici comment calculer le vôtre.

Calculer votre charge, poste par poste

Le calcul se fait à partir de trois nombres que vous connaissez : le nombre de processus critiques retenus au périmètre, le nombre de cas de test par processus, et le nombre de testeurs mobilisés.

Ce qui fait exploser la note

Deux mécanismes, et un seul est évitable. Le premier : la recette repoussée en fin de projet, préparée au moment de la livraison au lieu de l’être pendant le développement. Les cas de test s’écrivent alors dans l’urgence, mal, et les campagnes se multiplient. Le second : la reprise découverte après la mise en production, quand l’équipe refuse l’outil parce que personne ne l’a fait tester à ceux qui l’utiliseront. Le coût n’est plus celui de la recette, mais celui d’une partie du projet à refaire, et il s’ajoute au temps déjà consommé par le développement.

⚖️ Ce que la recette permet, et ce qu’elle ne permet pas

Une recette bien menée protège réellement, mais pas de tout. Savoir où s’arrête sa portée évite deux erreurs symétriques : la traiter comme une formalité, ou lui demander de rattraper ce qui s’est mal joué en amont.

🚧 Les pièges les plus fréquents

Six situations reviennent projet après projet. Aucune n’est une fatalité technique : toutes se préviennent par une décision prise en amont.

Ces six pièges ont un point commun : ils se règlent tous par une décision prise avant la livraison. C’est aussi ce qui distingue un projet qu’on subit d’un projet qu’on pilote. C’est le raisonnement appliqué au calcul du retour sur investissement d’un logiciel métier, qui se prépare lui aussi bien avant la mise en service.

🎯 En résumé

Pour cadrer un projet de logiciel métier de bout en bout, recette et mise en production comprises, décrivez votre besoin en quelques phrases : le devis arrive sous 24 h ouvrées, et le cadrage est la semaine 1 du projet. Si vous en êtes encore à choisir entre un outil du marché et un développement dédié, commencez plutôt par notre comparatif CRM, ERP ou EOS, ou par le guide complet du développement logiciel sur mesure.

📚 Sources

• ISTQB, Certified Tester Foundation Level Specialist Syllabus — Acceptance Testing, version 1.0 du 21 juin 2019 : formes de recette et définition des critères d’acceptation
• Légifrance, arrêté du 30 mars 2021 portant approbation du CCAG des marchés publics de techniques de l’information et de la communication : séquence des vérifications, admission et point de départ de la garantie
• CNIL, Guide de la sécurité des données personnelles, fiche « Encadrer les développements informatiques », mise à jour du 14 mars 2024 : données de test et conditions de la pré-production
• CNIL, « L’anonymisation de données personnelles » : familles de techniques d’anonymisation
• OTTOPILOTE, page forfaits : 30 jours de corrections offerts après livraison, propriété du code et des accès, suivi mensuel en option