Recette logiciel : la check-list du dirigeant avant de signer le PV de recette

Avant de signer un procès-verbal de recette, un dirigeant doit vérifier quatre choses : que tout le périmètre du contrat a été testé avec de vraies situations métier, que les anomalies restantes sont listées en réserve avec un délai, que les livrables (code, documentation, accès) sont bien remis, et que la mise en production a un plan de retour arrière. Cette signature n'est pas une formalité : elle déclenche souvent le paiement du solde, le début de la garantie et la fin de la responsabilité du prestataire sur ce qui était visible.

Cet article explique ce qu'est la recette d'un logiciel, comment construire un cahier de recette utile, puis déroule la check-list à passer avant de signer.

La recette, en une phrase

La recette, ou recettage, est la vérification par le client qu'un logiciel livré fait ce qui avait été convenu. Le terme vient du vocabulaire des marchés de travaux et de fournitures : on « reçoit » l'ouvrage. Le prestataire teste son travail en continu ; la recette, elle, est le moment où c'est vous qui vérifiez, sur un environnement proche de la production, avec vos cas réels.

Elle compte pour une raison simple : c'est le dernier moment où vous avez un vrai levier. Avant la signature, une anomalie est une non-conformité que le prestataire doit corriger. Après, elle devient souvent une demande de maintenance, voire une évolution facturée.

Les trois niveaux de recette

Dans les marchés publics, ces étapes portent des noms précis : le CCAG-TIC, cahier des clauses administratives générales applicable aux marchés informatiques, parle de vérification d'aptitude (VA) puis de vérification de service régulier (VSR), avec des décisions et des délais encadrés. Dans un contrat privé, rien n'est imposé : c'est le contrat qui définit les étapes, les délais et les effets de chaque décision. D'où l'importance de le relire avant de commencer.

Le cahier de recette : ce qu'il doit contenir

Le cahier de recette est la liste des vérifications à mener. Il découle directement du cahier des charges ou du périmètre validé : chaque besoin exprimé doit avoir au moins un cas de test. Si vous partez d'un cahier des charges, la correspondance se fait ligne à ligne.

Un cas de test, concrètement

Un bon cas de test se lit sans connaître le logiciel. Il comporte :

• un identifiant et la fonction testée ;
• les préconditions : quel utilisateur, avec quels droits, quelles données présentes ;
• les étapes, dans l'ordre ;
• le résultat attendu, formulé de façon vérifiable ;
• le résultat obtenu, le statut (conforme, non conforme) et la gravité en cas d'échec.

Exemple pour une application de gestion des devis :

Les scénarios qu'on oublie

Les cas nominaux (tout se passe bien) sont toujours écrits. Ce sont les autres qui font les mauvaises surprises en production :

• les exceptions métier : l'avoir, l'annulation, le client sans SIRET, la commande partielle, le produit supprimé du catalogue ;
• les droits : ce qu'un profil ne doit pas pouvoir voir ou faire ;
• les volumes : la liste avec dix mille lignes, l'export de l'année entière, l'import d'un fichier mal formé ;
• les sorties : PDF, e-mails envoyés, exports vers la comptabilité ;
• les interfaces : ce qui part vers d'autres logiciels et ce qui en revient ;
• les mobiles : l'écran utilisé debout dans un entrepôt, avec un réseau médiocre.

Qui l'écrit

Le client est le mieux placé pour écrire les scénarios métier : il connaît ses cas tordus. Le prestataire aide à structurer et ajoute ses tests techniques. Un cahier de recette écrit uniquement par le prestataire vérifie sa compréhension du besoin, ce qui n'est pas la même chose que le besoin.

Classer les anomalies

Toutes les anomalies ne se valent pas. Une grille de gravité, convenue avant la recette, évite de négocier chaque ticket :

Le contrat ou le plan de recette doit dire qui qualifie la gravité, et comment on tranche un désaccord. Sans cette règle, chaque anomalie majeure devient « mineure » dans le compte rendu du prestataire.

La check-list avant de signer le PV de recette

Voici les points à vérifier vous-même, ou à faire vérifier par la personne qui pilote le projet chez vous. Chaque « non » est soit une réserve à écrire, soit une raison de reporter la signature.

Le périmètre

• Chaque fonction prévue au contrat a au moins un cas de test, et il a été exécuté.
• Les cas de test ont été joués par des utilisateurs réels, pas uniquement par le prestataire.
• Les exceptions métier listées plus haut ont été testées.
• Les écarts entre ce qui était prévu et ce qui est livré sont écrits, y compris ceux acceptés en cours de projet.

Les données et la sécurité

• La recette s'est faite sur des données réalistes. Si ce sont des données réelles, elles ont été anonymisées ou leur usage encadré, comme l'exige le RGPD.
• Chaque profil d'utilisateur a été testé, y compris ce qu'il ne doit pas voir.
• La reprise des données de l'ancien outil a été vérifiée sur un échantillon, par les personnes qui connaissent ces données.
• Les points de base de sécurité sont couverts : mots de passe, droits, journalisation des actions sensibles.

L'exploitation

• Une sauvegarde a été restaurée au moins une fois, pas seulement programmée.
• La supervision est en place : quelqu'un est prévenu quand l'application tombe.
• La mise en production a une date, un responsable et un plan de retour arrière si elle échoue.
• Les performances ont été observées avec un volume proche du réel.

Les livrables

• Le code source est déposé là où le contrat le prévoit, et vous savez y accéder.
• L'hébergement, le nom de domaine et les comptes des services tiers sont à votre nom ou vous sont accessibles.
• La documentation existe : installation, déploiement, règles métier, guide utilisateur.
• Les utilisateurs ont été formés, ou la formation est planifiée.
• Les droits sur le code et les livrables correspondent à ce que prévoit le contrat ; sur ce point, notre article sur la propriété du code source détaille ce qu'il faut regarder.

Le procès-verbal lui-même

• Il identifie la version exacte recettée (numéro, date de livraison).
• Chaque réserve est précise, rattachée à un cas de test, avec un délai de correction.
• Il dit ce qui se passe si une réserve n'est pas levée dans le délai.
• Vous savez ce que la signature déclenche : paiement, début et durée de la garantie, début du contrat de maintenance.
• La personne qui signe en a le pouvoir dans votre entreprise.

Le procès-verbal de recette : trois issues possibles

L'acceptation sans réserve. Le logiciel est conforme. C'est l'issue souhaitable, à condition que la check-list ait été passée honnêtement.

L'acceptation avec réserves. Le logiciel peut être mis en production, mais des anomalies non bloquantes restent à corriger. C'est l'issue la plus fréquente, et elle n'a rien d'un échec. Ce qui compte, c'est la précision des réserves : « quelques bugs d'affichage » ne protège personne ; « cas DEV-07 : la remise n'est pas reportée sur la facture, correction sous dix jours ouvrés » est opposable.

Le refus. Des anomalies bloquantes subsistent, ou le périmètre n'est pas couvert. Le refus doit être écrit, motivé et rattaché aux cas de test en échec. Le prestataire corrige et livre une nouvelle version, qui repasse en recette, au moins sur les cas concernés et sur un échantillon de cas déjà validés, pour vérifier que la correction n'a rien cassé ailleurs.

Les pièges qui coûtent cher

La recette tacite. De nombreux contrats prévoient qu'un silence au-delà d'un délai, ou une mise en production, vaut acceptation. Lisez cette clause avant de commencer, notez la date limite, et ne mettez pas en production un logiciel que vous n'avez pas formellement accepté sans l'écrire.

La recette sans les utilisateurs. Le dirigeant ou le chef de projet valide les écrans en réunion, puis les équipes découvrent l'outil le jour du lancement. Les anomalies trouvées ensuite sont les plus chères à faire corriger.

Les testeurs non libérés. La recette se fait « en plus » du travail habituel, donc à moitié. Bloquez du temps dans les agendas, comme pour une formation.

Les évolutions déguisées en anomalies. Une demande nouvelle, découverte en recette, n'est pas une non-conformité. La mélanger aux anomalies crée un conflit inutile avec le prestataire. Notez-la à part : elle alimentera la suite.

Tout recetter à la fin. Sur un projet de plusieurs mois, une recette unique en fin de parcours concentre tous les risques. Une recette par lot, au fil de l'eau, fait apparaître les malentendus quand ils coûtent encore peu. C'est l'un des principes de l'agilité au forfait.

Combien de temps prévoir

Aucune durée standard ne vaut pour tous les projets. Le calcul honnête est simple : le nombre de cas de test, multiplié par le temps d'exécution de chacun, plus la rédaction des fiches d'anomalie, plus au moins un second passage après corrections. Ajoutez la disponibilité réelle des testeurs, qui est presque toujours le facteur limitant. Pour la vérification en service régulier, la durée est celle que fixe le contrat ; elle doit couvrir au moins un cycle complet de votre activité (une clôture mensuelle, par exemple, si le logiciel la touche).

Après la signature

La recette ne clôt pas la vie du logiciel. Les premières semaines en production font remonter des cas que personne n'avait imaginés. Le contrat doit prévoir comment ils sont traités : correction au titre de la garantie quand il s'agit d'une non-conformité, maintenance ou évolution sinon. Notre article sur la maintenance d'une application métier décrit cette période, et celui sur les clauses d'un contrat de développement ce qu'il faut avoir écrit avant.

Une recette commence avant le développement

La meilleure recette est celle où rien ne surprend, parce que le client a vu le logiciel avant qu'il soit construit. Un périmètre rendu visible, écran par écran, devient la référence commune : le cahier de recette s'en déduit, et les désaccords sur « ce qui était prévu » disparaissent presque.

C'est le rôle du prototype visuel gratuit que LPR Studio présente en visio sous 5 jours ouvrés, avant tout engagement. Au forfait, il sert ensuite de base au périmètre, puis à la recette.