Recette d'un logiciel : tester avant de payer

La recette d'un logiciel est la période où vous vérifiez, avec vos propres cas de travail, que ce qui a été livré correspond à ce qui était commandé. Elle se termine par une décision écrite : vous acceptez la livraison, vous l'acceptez avec des réserves, ou vous la refusez. Quand le contrat lie le paiement à cette décision, vous ne payez que ce que vous avez vu fonctionner.

Le mot vient de l'industrie, où l'on « recette » une machine avant de la mettre en production. En informatique, il désigne la même chose : un contrôle par le client, distinct des tests que le prestataire fait de son côté.

Ce que recouvre une recette

Il faut séparer deux contrôles. Le prestataire teste son travail avant de le livrer : il vérifie que chaque écran s'affiche, que les calculs donnent le bon résultat, que rien n'a cassé ailleurs. Ensuite vient votre recette, faite par les personnes qui utiliseront l'outil, sur des situations tirées de leur quotidien.

Quelques termes reviennent dans les contrats :

• Cahier de recette : la liste des cas à tester, avec pour chacun le résultat attendu. Par exemple : « Je crée un devis pour un client exonéré de TVA, le PDF n'affiche pas de TVA. »
• Anomalie : un écart entre le résultat obtenu et le résultat attendu. On les classe en général par gravité.
• Procès-verbal de réception : le document signé qui constate la fin de la recette et sa conclusion. C'est souvent lui qui déclenche la facture et le début de la garantie.
• Réserves : les défauts constatés qui n'empêchent pas d'accepter, mais que le prestataire s'engage à corriger dans un délai donné.

Une recette ne sert pas à découvrir de nouveaux besoins. Si vous vous apercevez en testant qu'il manque une fonction jamais demandée, c'est une évolution à chiffrer à part. D'où l'intérêt d'une expression des besoins précise avant le développement : elle sert de référence pendant la recette.

Un modèle utile : la vérification dans les marchés publics

Les marchés publics informatiques qui s'y réfèrent suivent un cahier des clauses administratives générales, le CCAG-TIC. Une entreprise privée n'est pas tenue de l'appliquer, mais il décrit une procédure de vérification claire, dont un contrat entre PME peut s'inspirer.

Source : Légifrance, arrêté du 30 mars 2021 portant approbation du CCAG-TIC (articles 2, 32, 33, 34 et 36), consulté le 22 octobre 2026.

Deux idées sont à reprendre telles quelles dans un contrat privé. D'abord, la recette se fait en deux temps : un premier contrôle sur les fonctions, puis une période d'usage réel où l'on vérifie que l'outil tient au quotidien. Ensuite, chaque étape a un délai, et le silence a une conséquence écrite. Sans cette règle, une recette peut s'éterniser, ce qui n'arrange ni le client ni le prestataire.

Préparer sa recette avant la livraison

Une recette efficace se prépare pendant le développement. Attendre la livraison pour se demander quoi tester fait perdre du temps au moment où tout le monde attend une décision.

1. Choisir les testeurs. Deux ou trois personnes qui utiliseront vraiment l'outil, avec du temps réservé dans leur agenda. Un dirigeant seul passe à côté des cas que ses salariés rencontrent tous les jours.
2. Écrire les cas de test. Partir des situations réelles : la commande urgente, le client qui paie en trois fois, l'avoir après une erreur de facture. Une vingtaine de cas bien choisis couvrent en général l'essentiel de l'usage quotidien.
3. Préparer les données de test. La CNIL recommande de travailler sur un jeu de données fictives qui ressemble aux données réelles, et rappelle que les données réelles de production ne doivent pas être utilisées pendant les phases de développement et de test.
4. Prévoir où tester. Un environnement séparé de l'outil en service, souvent appelé « préproduction ». Selon la CNIL, si des tests sur données réelles sont indispensables, ils se font dans un environnement configuré et sécurisé au même niveau que la production.

Sources : CNIL, tester vos applications ; CNIL, encadrer les développements informatiques, consultés le 22 octobre 2026.

Ces précautions comptent dès que l'outil manipule des données de salariés, de clients ou de patients. La page sur le RGPD et le logiciel métier détaille les autres obligations.

Classer les anomalies et décider

Toutes les anomalies ne se valent pas, et les traiter de la même façon bloque le projet. Un classement simple, écrit dans le contrat, évite les discussions sans fin.

• Bloquante : une tâche essentielle est impossible (on ne peut pas enregistrer une commande, la facture affiche un mauvais total). La livraison ne peut pas être acceptée.
• Majeure : la tâche est possible avec un contournement pénible. On peut accepter avec réserve, à condition d'un délai de correction court.
• Mineure : un libellé, un alignement, un tri peu pratique. Elle se corrige plus tard sans retarder la réception.

Pour chaque anomalie, notez le cas de test, ce que vous avez fait, ce que vous attendiez et ce que vous avez obtenu, avec une capture d'écran. Un signalement précis se corrige vite ; un « ça ne marche pas » oblige à des échanges pour comprendre de quoi il s'agit.

Lier la recette au paiement

Le moyen le plus simple de rendre une recette sérieuse est d'y attacher l'argent. Si une étape se règle à sa validation, le prestataire a intérêt à livrer quelque chose de testé, et vous gardez un moyen de pression légitime tant que la livraison n'est pas conforme.

Le calendrier de paiement reste encadré par la loi. Entre professionnels, le délai de paiement est par défaut de 30 jours après la réalisation de la prestation, sauf accord différent dans les limites légales. D'où l'intérêt d'écrire noir sur blanc que la prestation d'une étape est réalisée à la signature de son procès-verbal de réception.

Source : Entreprendre.service-public.gouv.fr, délais de paiement entre professionnels, consulté le 22 octobre 2026.

C'est ainsi que je fonctionne : le prix est fixe et découpé en étapes, et vous réglez une étape une fois livrée, testée et validée par vous. Vous pouvez arrêter après n'importe laquelle, avec le code source et les accès de ce qui a été payé. La mécanique complète est décrite sur la page consacrée au paiement par étapes, et les repères de prix sur la page prix d'un logiciel métier sur mesure.

Un mot d'honnêteté : un prestataire qui doit acheter des licences ou bloquer plusieurs semaines de travail peut légitimement demander une part à la signature. Le risque apparaît quand presque tout est payé avant la moindre recette.

Ce que le devis doit prévoir

Avant de signer, relisez le devis avec cette liste. Beaucoup de devis parlent de « recette » sans dire qui la fait ni comment elle se termine. La page pour lire un devis de développement complète ces points.

• La recette est-elle mentionnée comme une étape, avec une durée prévue de votre côté ?
• Qui rédige le cahier de recette : vous, le prestataire, ou les deux ?
• Le délai pour valider ou refuser une livraison est-il écrit, et que vaut l'absence de réponse ?
• Le classement des anomalies et les délais de correction sont-ils définis ?
• Un environnement de test séparé est-il prévu, avec des données fictives ?
• Le paiement de chaque étape est-il lié à la signature d'un procès-verbal ?
• La garantie après réception est-elle précisée : durée, point de départ, ce qu'elle couvre ?
• Ce qui relève de la maintenance après la garantie est-il distingué des corrections dues ?