Votre entreprise a développé une application, installé un progiciel ou réalisé une migration. Les accès ont été remis, les utilisateurs ont effectué des tests, parfois le client a confirmé que certaines fonctions marchaient. Pourtant, le procès-verbal de recette reste sans signature et la facture demeure impayée. Pour le prestataire, la question est concrète : comment établir ce qui a été livré et obtenir le paiement sans transformer un désaccord technique en rupture incontrôlée du projet ?
L’absence de procès-verbal signé ne suffit pas, à elle seule, à régler le litige dans un sens ou dans l’autre. Le contrat, les preuves de réalisation et les objections précises du client doivent être examinés ensemble. La cour d’appel de Douai a ainsi accordé une provision à un prestataire après avoir analysé les tests validés et les prestations effectivement fournies, dans un dossier où les procès-verbaux prévus au contrat n’avaient pas été régularisés (18 juin 2026, n° 25/03610).
Cette analyse concerne les relations entre professionnels : développeur, intégrateur ou prestataire de migration, d’une part, entreprise cliente, d’autre part. Elle porte sur l’exécution et le prix des prestations informatiques. Les questions de propriété intellectuelle, de conformité des traitements de données et de litige de consommation appellent leurs propres vérifications. Pour réclamer utilement le prix, il faut d’abord reconstituer le contrat, puis présenter une preuve lisible, traiter les réserves et choisir une demande adaptée.
I. Établir ce que le client devait accepter et ce que le prestataire a réellement fourni
A. Relier chaque facture au contrat, au livrable et au mécanisme de recette
Le premier document à examiner n’est pas la relance comptable. C’est le contrat, avec ses annexes : proposition commerciale acceptée, cahier des charges, spécifications, bons de commande, conditions générales, avenants et procédure de recette. L’article 1103 du Code civil donne force obligatoire aux contrats légalement formés. Le prestataire doit donc identifier ce que les parties ont effectivement convenu, plutôt que s’appuyer sur sa procédure habituelle ou sur celle d’un autre client.
La remise d’un accès, l’achèvement d’un développement, la réussite des tests, la mise en production et la signature d’un procès-verbal sont des événements distincts. Le contrat peut les articuler de différentes manières. Il peut prévoir une facturation par lot, un paiement lié à une validation, ou des redevances correspondant à des services séparés. Pour chaque montant réclamé, la question est la même : quel événement contractuel permet d’en demander le paiement, et quelle pièce démontre cet événement ? Cette méthode découle de la force obligatoire du contrat et de la charge de la preuve définie par l’article 1353 du Code civil.
Une entreprise qui réclame le solde d’un développement ne présente pas le même dossier que celle qui demande une redevance de maintenance. Le développement peut être soumis à des tests fonctionnels ; la maintenance peut reposer sur une prestation forfaitaire définie séparément. L’analyse doit également distinguer le logiciel préexistant, son paramétrage, les interfaces, la reprise des données et la formation. Regrouper toutes ces prestations sous une seule formule, comme une livraison globale, empêche souvent de comprendre ce qui est réellement contesté.
Lorsque deux documents semblent se contredire, il faut identifier leur articulation contractuelle et les accords intervenus. L’article 1188 du Code civil commande de rechercher la commune intention des parties plutôt que de s’arrêter au sens littéral des termes ; si cette intention ne peut être décelée, le contrat s’interprète selon le sens que lui donnerait une personne raisonnable placée dans la même situation. Cela n’autorise pas à réécrire une clause gênante. Cela invite à conserver les documents qui éclairent l’engagement effectivement accepté.
Prenons une situation illustrative : un devis distingue un module de facturation, une interface comptable et une formation. Le client accepte le module, signale une anomalie sur l’interface et n’a pas encore participé à la formation. Le dossier doit faire apparaître ces trois situations, avec le prix correspondant à chacune. Il serait aussi imprécis de présenter l’ensemble comme intégralement accepté que de traiter toute la commande comme entièrement inexécutée. La possibilité de réclamer séparément une somme dépend toutefois du découpage et des conditions de paiement réellement convenus.
Les demandes apparues en cours de projet doivent aussi être documentées. L’article 1193 du Code civil prévoit que les contrats ne peuvent être modifiés ou révoqués que du consentement mutuel des parties, ou pour les causes que la loi autorise. Une nouvelle fonctionnalité ne devient donc pas une prestation supplémentaire facturable par la seule volonté du prestataire. Inversement, le fournisseur doit pouvoir expliquer, pièces à l’appui, pourquoi une demande excède le périmètre initial.
Pour replacer ces vérifications dans l’ensemble du projet, la page consacrée au contrat d’intégration logicielle et à la recette informatique présente le cadre général. Le problème traité ici est plus étroit : constituer, du côté du prestataire créancier, le dossier permettant de justifier le prix réclamé.
B. Construire une preuve de réalisation sans confondre courriel, usage et procès-verbal
La facture constitue une pièce du dossier, mais elle ne décrit pas nécessairement les tests effectués, les accès remis et les fonctions disponibles. L’article 1353 du Code civil énonce : « Celui qui réclame l’exécution d’une obligation doit la prouver. » Le prestataire doit organiser les éléments qui soutiennent sa demande, et pas seulement accumuler les factures émises.
Un ensemble de preuves exploitable rapproche chaque engagement d’un élément vérifiable. Pour une interface, il peut s’agir du scénario d’échange, de son résultat et de la version testée. Pour une migration, du périmètre concerné, du rapport d’exécution et des contrôles réalisés. Pour une formation, de son contenu et des éléments attestant sa tenue. Ces exemples constituent une méthode de préparation : leur valeur dans le litige dépend du contrat, de leur authenticité et des contestations auxquelles ils répondent.
Le courriel du client doit être conservé dans son contexte. Un message validant une connexion ne démontre pas nécessairement la validation du calcul des factures. Une approbation concernant un environnement de test ne décrit pas automatiquement l’environnement de production. Le nom et la fonction de l’expéditeur, les échanges précédents, la version du logiciel et le périmètre exact de la réponse permettent de comprendre ce qui a été reconnu. Un extrait isolé est moins explicite qu’un échange complet accompagné des pièces auxquelles il renvoie.
L’article 1366 du Code civil reconnaît à l’écrit électronique la même force probante que l’écrit sur papier, sous réserve de l’identification de son auteur et de conditions d’établissement et de conservation garantissant son intégrité. Il est donc utile de préserver les messages d’origine et leurs pièces jointes. Une capture d’écran peut aider à expliquer un événement ; elle ne dispense pas d’examiner l’origine, l’intégrité et la portée de ce qu’elle montre.
Le silence du client demande une vigilance particulière. L’article 1120 du Code civil, relatif à l’acceptation, prévoit : « Le silence ne vaut pas acceptation, à moins qu’il n’en résulte autrement de la loi, des usages, des relations d’affaires ou de circonstances particulières. » Ce texte ne crée pas, à lui seul, une recette automatique pour tout projet informatique. Dans l’exécution du projet, il faut examiner le mécanisme de validation effectivement convenu et les circonstances établies, sans inventer après coup une clause de recette tacite.
L’arrêt de la cour d’appel de Douai du 18 juin 2026, n° 25/03610, illustre précisément la nécessité de distinguer les questions. Le contrat prévoyait des procès-verbaux et excluait la recette tacite. La cour a relevé qu’aucun des procès-verbaux envisagés n’avait été régularisé. Elle n’a pourtant pas arrêté son analyse à ce seul constat lorsqu’elle a examiné les demandes de paiement.
Pour une prestation de migration, les pièces établissaient une phase de tests satisfaisante et la possibilité de lancer la solution en production, que le client avait choisi d’ajourner pour des raisons non imputables au prestataire. La cour a jugé non sérieuse la contestation selon laquelle la prestation n’aurait pas été fournie et a accordé une provision au titre de cette facture. Elle a également examiné séparément les autres postes réclamés (même arrêt, motifs sur la provision).
L’enseignement pratique reste circonscrit. Cet arrêt n’autorise pas à remplacer systématiquement un procès-verbal contractuel par un courriel, ni à déclarer tout logiciel accepté dès qu’il a été testé. Il montre qu’une demande de paiement doit être examinée prestation par prestation, au regard de ses preuves propres. Le prestataire a intérêt à conserver aussi les éléments expliquant un report de mise en production : changement d’organisation, choix d’un autre outil ou impossibilité technique alléguée ne décrivent pas la même situation.
La preuve du travail réalisé doit, en particulier, être distinguée de la condition contractuelle de paiement. Si le contrat subordonne expressément le solde à la signature d’un procès-verbal, présenter des tests réussis ne permet pas de supprimer cette stipulation. Il faut examiner sa portée et la situation des parties au regard de la force obligatoire du contrat et de son interprétation, prévues par les articles 1103 et 1188 du Code civil. Le prestataire peut documenter les démarches entreprises pour organiser la validation et les réponses reçues. Mais il doit annoncer clairement ce qu’il demande : le paiement d’un poste déjà justifié, la discussion d’une condition contestée ou la régularisation des opérations de recette. Ces demandes ne reposent pas nécessairement sur le même raisonnement.
Une présentation utile tient dans un dossier indexé : engagement contractuel, livrable identifié, preuve de mise à disposition, résultat des tests, réponse du client et facture correspondante. Chaque pièce doit répondre à une question précise. L’objectif est que le juge, comme le client, puisse suivre le raisonnement sans devoir reconstruire lui-même plusieurs années de messages et de tickets techniques.
II. Traiter les objections du client et présenter une demande de paiement défendable
A. Répondre aux réserves et mesurer la portée réelle d’une validation
Réclamer une signature sans examiner les anomalies signalées peut renforcer le désaccord. L’article 1104 du Code civil impose la bonne foi dans la négociation, la formation et l’exécution du contrat. Pour le prestataire, cela implique notamment de confronter sa position aux objections documentées, plutôt que de qualifier toute demande du client de prétexte au non-paiement.
La méthode consiste à distinguer trois catégories : la fonction promise qui ne donne pas le résultat convenu, la difficulté liée à un élément extérieur qu’il faut identifier, et la demande nouvelle. Cette classification doit rester ouverte à la discussion. Une anomalie ne devient pas mineure parce que le fournisseur la nomme ainsi ; une demande ne devient pas contractuelle parce que le client la présente comme indispensable. Le cahier des charges, les échanges de cadrage et les résultats de tests permettent de soutenir chaque position.
Pour chaque réserve, une fiche courte peut préciser le scénario, le résultat attendu, le résultat observé, les conséquences sur l’usage, la réponse technique et la pièce qui la justifie. Si le prestataire invoque une configuration modifiée par le client, il doit expliquer quelle modification produit quel effet. S’il soutient qu’une correction a été livrée, il doit identifier la version concernée et les éléments de vérification. Une simple mention interne indiquant qu’un ticket est fermé ne permet pas toujours de comprendre si le client a pu constater la correction.
Le refus de payer peut reposer sur une exception d’inexécution. L’article 1219 du Code civil permet à une partie de refuser d’exécuter son obligation, même exigible, si l’autre n’exécute pas la sienne et si cette inexécution est suffisamment grave. Le débat porte donc aussi sur la réalité et la gravité du manquement invoqué. Un simple désaccord de vocabulaire entre les équipes ne résout pas cette question.
Dans l’arrêt de la cour d’appel de Rennes du 9 septembre 2025, n° 24/03931, plusieurs documents de recette ont été examinés. Certains n’étaient pas signés ; le dernier l’était, sans réserve. La cour a également relevé la présence d’une clause contractuelle opposable et l’absence des signalements circonstanciés attendus au titre de la maintenance. Elle a rejeté l’exception d’inexécution et condamné le client au paiement de 8 475,67 euros en principal.
La portée de cet arrêt dépend de cet ensemble de circonstances. Il ne signifie pas que tout défaut de réserve ferait disparaître une anomalie ultérieure, ni que le prestataire pourrait se dispenser de répondre aux demandes d’assistance. Il invite le fournisseur à réunir les preuves de la réception, mais aussi l’historique des interventions et des réponses. Dans cette affaire, la cour a notamment examiné ce que les pièces permettaient réellement d’établir sur les dysfonctionnements invoqués (même décision).
L’arrêt de la cour d’appel de Paris du 22 mars 2024, n° 21/16505, montre une autre configuration. Un document intitulé procès-verbal de recette définitive comportait de nombreuses réserves. La cour a considéré qu’il ne valait pas acceptation définitive de la solution. Elle a aussi retenu que l’usage du logiciel et le paiement de factures ne suffisaient pas, dans les circonstances du dossier, à écarter les dysfonctionnements établis : le client expliquait avoir utilisé la solution pour poursuivre son activité, faute d’alternative immédiatement disponible.
Le prestataire doit donc éviter de tirer une conclusion absolue d’une seule pièce. La présence du logiciel dans l’entreprise cliente peut être un élément du dossier ; elle ne répond pas nécessairement à la question de sa conformité. Inversement, le refus d’utiliser une version testée n’établit pas automatiquement une inexécution. La comparaison entre les arrêts de Paris et de Douai montre pourquoi la preuve du périmètre, des tests et des raisons du comportement du client est décisive.
Si une inexécution est établie, l’article 1217 du Code civil ouvre plusieurs sanctions, dont la suspension de sa propre obligation, l’exécution forcée, la réduction du prix, la résolution et la réparation des conséquences de l’inexécution, selon leurs conditions respectives. Le fournisseur doit en tenir compte dans l’évaluation du dossier. Une demande de paiement peut rencontrer une défense technique, mais aussi une demande indemnitaire qu’il faut examiner sur ses preuves et son fondement.
B. Chiffrer la créance, formaliser la demande et choisir entre provision et débat au fond
Avant d’adresser une nouvelle demande, le prestataire devrait préparer un décompte vérifiable. Il doit distinguer les factures, les prestations auxquelles elles se rapportent, les paiements reçus et les éventuels avoirs. Les sommes reconnues par le client doivent être identifiées séparément des postes litigieux. Cette présentation ne préjuge pas de l’issue du procès ; elle permet de justifier précisément la créance invoquée conformément à l’article 1353 du Code civil.
Une facture de développement et une redevance annuelle ne doivent pas être additionnées sans expliquer leurs bases respectives. Dans l’arrêt de Douai du 18 juin 2026, la cour a examiné les prestations de migration puis les redevances de maintenance. Pour ces dernières, elle a notamment retenu le caractère forfaitaire du service prévu au contrat et les conditions précises dans lesquelles les prestations avaient été mises à disposition. Cette motivation ne peut pas être appliquée à un autre abonnement sans lire son contrat.
La demande adressée au client gagne à suivre un ordre simple : rappeler l’engagement accepté, identifier ce qui a été réalisé, répondre aux réserves puis exposer le calcul du montant demandé. Elle peut proposer une réunion de vérification ciblée ou une régularisation des documents de recette, sans présenter comme acquis ce qui reste contesté. Les demandes nouvelles peuvent faire l’objet d’une discussion distincte. L’enjeu est de rendre les positions comparables, et non d’obtenir une signature portant sur des éléments que les équipes n’ont pas vérifiés.
Pour la mise en demeure de payer, l’article 1344 du Code civil prévoit une sommation ou un acte portant interpellation suffisante, ou, si le contrat le prévoit, la seule exigibilité de l’obligation. La rédaction doit donc être adaptée au contrat et à la créance. Une formule générale réclamant tout le budget du projet, sans déduction des paiements reçus ni explication sur les livrables, ne remplace pas un décompte justifié.
L’arrêt de la cour d’appel de Paris du 22 mars 2024 fournit un avertissement concret sur la facturation. La cour a rejeté une demande relative à des licences correspondant à une période antérieure à l’installation de la solution, faute d’explication du prestataire justifiant ces factures. Ce rejet ne pose pas une interdiction générale de toute facturation préparatoire. Il montre l’importance d’expliquer pourquoi le contrat autorise le poste demandé et comment les pièces en établissent le bien-fondé.
Si la demande relève d’une juridiction commerciale compétente, l’article 873, alinéa 2, du Code de procédure civile permet au juge des référés d’accorder une provision lorsque l’existence de l’obligation n’est pas sérieusement contestable. Cette condition doit être examinée au regard des objections effectives : portée d’une validation, prestation non réalisée, réserves techniques ou décompte discuté. La présence d’un contrat et d’une facture ne dispense pas de cet examen.
Dans l’arrêt de Douai du 18 juin 2026, n° 25/03610, le dispositif accorde 63 408,08 euros à titre provisionnel, correspondant à plusieurs postes retenus par la cour. Il s’agit d’une provision accordée en référé, pas d’un barème applicable aux litiges informatiques ni d’une décision au fond sur toutes les questions possibles du contrat. Le montant du dossier d’un autre prestataire dépendra de sa créance et de ses preuves.
Lorsque le désaccord suppose de déterminer l’origine d’un dysfonctionnement ou de départager des analyses techniques, la stratégie peut nécessiter un débat au fond et une préparation probatoire plus approfondie. L’article 145 du Code de procédure civile, dans sa version en vigueur, permet de demander avant tout procès une mesure d’instruction légalement admissible s’il existe un motif légitime de conserver ou d’établir la preuve de faits dont pourrait dépendre la solution d’un litige. Une expertise n’est donc pas automatique ; son objet et son utilité doivent être justifiés.
Dans le dossier jugé à Douai, la demande d’expertise a précisément été rejetée faute de motif légitime au regard des pièces examinées par la cour (arrêt du 18 juin 2026). Un prestataire ne doit pas davantage supposer qu’une expertise lui serait toujours défavorable ou toujours favorable. Il doit préparer les éléments permettant de tester les hypothèses : versions, configuration, interventions, scénarios et résultats, en organisant la protection des informations confidentielles.
Enfin, le recouvrement du prix et une demande de dommages-intérêts doivent être distingués. L’article 1231-1 du Code civil régit la responsabilité pour inexécution ou retard, sous la réserve qu’il énonce concernant la force majeure. Une indemnisation exige une analyse de ses conditions et de ses preuves ; elle ne se confond pas avec l’addition des factures. De même, toute suspension technique du service demande une analyse propre : le conflit sur la signature du procès-verbal ne constitue pas, à lui seul, une instruction opérationnelle autorisant à couper les accès.
Conclusion
Pour le prestataire confronté à un refus de signature de la recette informatique, la démarche utile commence par une distinction : ce que le contrat exige, ce que les tests démontrent et ce que le client conteste. Les arrêts examinés montrent que l’absence de procès-verbal, la présence de réserves et l’utilisation du logiciel prennent leur sens dans l’ensemble du dossier. Aucun de ces éléments ne devrait être isolé pour présenter artificiellement une livraison comme parfaite ou une créance comme inexistante.
Le dossier doit permettre de relier chaque somme à un engagement accepté, à une prestation identifiable et à des preuves conservées. Les anomalies méritent une réponse technique ; les demandes supplémentaires, une discussion contractuelle distincte. Une fois cette préparation accomplie, le prestataire peut évaluer une demande de régularisation, de paiement ou de provision selon les conditions exposées. La solidité de cette démarche repose sur la précision du contrat, du décompte et des preuves, plutôt que sur la répétition des relances.