Qu'est-ce que l'achèvement du travail dans les contrats d'entreprise pour le développement de systèmes ?

Le développement de systèmes est généralement un processus qui s’étend sur une longue période, et il arrive souvent que des modifications de spécifications ou l’implémentation de nouvelles fonctionnalités soient demandées à plusieurs reprises. Pour les fournisseurs qui acceptent ce type de travail, ils peuvent parfois se retrouver dans une situation difficile sans issue apparente. Pour ces fournisseurs, la question de “Qu’est-ce que nous devons faire et jusqu’où devons-nous aller pour considérer que notre travail est accompli ?” peut parfois devenir une source de préoccupation majeure.

De plus, le développement de systèmes est souvent réalisé dans le cadre de contrats d’entreprise, qui visent à “l’achèvement du travail”.

Dans cet article, nous allons expliquer d’un point de vue juridique, “À quel moment et jusqu’où doit-on aller dans le développement d’un système pour considérer que le travail est terminé ?”.

Qu’est-ce que la fin du développement d’un système ?

La fin du développement d’un système du point de vue d’un ingénieur

Dans le domaine du développement de systèmes, si l’on demande “quand le développement du système est-il terminé ?”, la réponse générale serait probablement “lorsque le processus de test est terminé et que les produits finis sont livrés”. En effet, le flux de développement de systèmes typique commence par la définition des exigences, qui comprend l’identification des fonctionnalités à implémenter, puis la création de divers documents de conception, l’implémentation du programme, et enfin, le processus de test pour vérifier si le système fonctionne correctement. Le processus se termine généralement par l’acceptation du système par l’utilisateur.

Par conséquent, du point de vue des ingénieurs impliqués dans les tâches concrètes, il est généralement compris que “la fin du développement du système = l’acceptation du système”.

La fin du développement d’un système du point de vue juridique

D’un autre côté, si l’on demande du point de vue juridique quand le développement du système est terminé, la question centrale devient naturellement quand les obligations légales que le fournisseur avait contractées dans le contrat ont été remplies. En premier lieu, les contrats de développement de systèmes sont généralement classés soit comme des contrats d’entreprise, soit comme des contrats de mandat.

https://monolith-law.jp/corporate/contract-and-timeandmaterialcontract[ja]

Je vais laisser l’explication des différences entre ces deux types de contrats à l’article ci-dessus, mais en ce qui concerne la fin du développement du système, c’est-à-dire l’exécution de l’obligation du fournisseur, les critères de jugement sont donnés comme suit pour chaque type de contrat :

Contrat d’entreprise : Article 632 du Code civil
Article 632
Un contrat d’entreprise prend effet lorsque l’une des parties s’engage à terminer un certain travail et que l’autre partie s’engage à payer pour le résultat de ce travail.
Contrat de mandat : Article 648 du Code civil
Article 648
1. Sauf accord contraire, le mandataire ne peut pas demander une rémunération au mandant.
2. Dans le cas où le mandataire doit recevoir une rémunération, il ne peut pas la demander avant d’avoir exécuté le mandat. Cependant, si la rémunération a été fixée en fonction d’une période, l’article 624, paragraphe 2, s’applique.
3. Si l’exécution est interrompue en cours de route pour une raison qui ne peut pas être attribuée à la faute du mandataire, ce dernier peut demander une rémunération proportionnelle à l’exécution déjà effectuée.

La fin du développement d’un système est un problème dans les contrats d’entreprise

Cependant, que ce soit dans le contexte du développement de systèmes ou non, le moment où “le travail est terminé” est généralement un problème dans les contrats d’entreprise. Dans le cas des contrats de mandat, plutôt que de considérer l’obligation comme remplie en apportant un certain résultat ou produit, il s’agit d’un type de contrat qui met l’accent sur le fait que le mandataire, en tant que professionnel, fait ce qu’il doit faire avec un certain degré de discrétion (quel que soit le résultat). Dans les contrats de mandat, même si le produit final n’est pas comme prévu, si le processus de gestion a été correctement mené, il est possible de demander une rémunération (article 648, paragraphe 2), et si l’exécution a été interrompue en cours de route pour une raison qui ne peut pas être attribuée à la faute du mandataire, il est possible de demander une rémunération proportionnelle à l’exécution déjà effectuée (article 648, paragraphe 3). On pourrait dire que les contrats d’entreprise mettent l’accent sur le “résultat”, tandis que les contrats de mandat mettent l’accent sur le “processus”.

Par conséquent, dans les contrats de mandat, c’est plutôt l'”obligation de diligence” dans le processus de réalisation du mandat qui est susceptible de poser problème sur le plan juridique. En d’autres termes, la question est de savoir quand on peut poursuivre une violation de l’obligation de diligence dans un contrat de mandat, en supposant qu’il y a une grande confiance.

D’un autre côté, ce qui est important dans les contrats d’entreprise, c’est la “fin du travail”. Si le travail qui doit être terminé n’est pas terminé, l’obligation du fournisseur ne peut pas être remplie et il ne peut pas demander de rémunération. Cependant, si le travail est terminé, il n’y a pas de raison de remettre en question les détails du processus. Par conséquent, la question de “quand le projet de développement du système est-il terminé ?” peut être reformulée comme une question d’interprétation juridique de l’expression “fin du travail” dans les contrats d’entreprise.

Quand considère-t-on un travail comme terminé dans le développement de systèmes ?

Alors, quand devrions-nous considérer concrètement que le “travail est terminé” ? Examinons les précédents judiciaires à ce sujet.

Précédents judiciaires concernant la fin du travail

Dans le précédent judiciaire cité ci-dessous, il s’agit d’un cas où des problèmes tels que la vitesse de traitement et les coûts de communication sont apparus plus tard dans le système livré par le fournisseur. Malgré la découverte de ces problèmes, tous les processus de développement étaient terminés, et il a été débattu de savoir si l’on pouvait dire que le “travail était terminé”. En fin de compte, il a été indiqué que la fin du travail était reconnue.

Les articles 632 et 633 du Code civil japonais stipulent que le moment du paiement de la rémunération à l’acheteur par le contractant est lorsque le contractant a terminé le travail et a livré l’objet du travail à l’acheteur, tandis que l’article 634 du même code stipule que si l’objet du travail a des défauts, le contractant est responsable de la garantie envers l’acheteur (paragraphe 1), et que l’acheteur a le droit de défense de l’exécution simultanée en ce qui concerne le paiement de la rémunération jusqu’à ce que le contractant ait rempli sa responsabilité de garantie en ce qui concerne les défauts de l’objet du travail (paragraphe 2). Selon ces dispositions du Code civil japonais, la loi distingue entre les cas où le résultat du travail est incomplet, c’est-à-dire les cas où l’objet du travail a des défauts et les cas où le travail n’est pas terminé, et il est interprété que même si l’objet du travail a des défauts, qu’ils soient cachés ou apparents, cela ne signifie pas que le travail n’est pas terminé.
Par conséquent, pour déterminer si le contractant a terminé le travail ou non, il faut se baser sur le fait que le travail a été terminé jusqu’à la dernière étape prévue dans le contrat initial, et il est approprié de comprendre que l’acheteur ne peut pas refuser de payer le prix du contrat simplement parce que l’objet du travail a des défauts, lorsque le contractant a terminé la dernière étape du travail et a livré l’objet.

Dans le jugement ci-dessus, il a été jugé que la “fin du travail” est satisfaite tant que la dernière étape du développement du système est terminée. En ce qui concerne les mesures de secours lorsque des défauts (souvent appelés “défauts” en termes juridiques) sont trouvés dans le système que le fournisseur a créé, il existe un système de responsabilité de garantie des défauts séparé.

Par conséquent, même si le concept de “fin du travail” est interprété de manière un peu large, cela ne signifie pas que l’utilisateur final est traité de manière injuste. Pour résumer, c’est comme suit :

【Obligation dans le contrat d’entreprise = Fin du travail = Achèvement de toutes les étapes】
========
Si le travail n’est pas terminé…
↓
【Responsabilité pour non-exécution de l’obligation】
========
Si le travail est terminé mais qu’il y a des défauts…
↓
【Reconnaissance de l’exécution de l’obligation, problème de responsabilité de garantie des défauts】

Le précédent judiciaire ci-dessus montre comment diviser les problèmes.

Cependant, en ce qui concerne le point de la “fin du travail”, on peut également examiner le point de vue de “l’acceptation de l’utilisateur”. Les problèmes juridiques lorsque l’acceptation de l’utilisateur ne progresse pas sont expliqués dans un autre article.

https://monolith-law.jp/corporate/estimated-inspection-of-system-development[ja]

Ce que signifie l’achèvement d’un travail sur le plan juridique

Dans le développement de systèmes, si l’achèvement du travail est reconnu, cela signifie que l’obligation a été remplie, donc il n’y a plus de risque d’être poursuivi pour “non-exécution” de l’obligation. Dans un contrat d’entreprise, si le travail n’est pas considéré comme terminé, il n’est pas possible de demander une rémunération, et même si des accords spéciaux ont été conclus pour des paiements anticipés, ceux-ci doivent généralement être remboursés. D’un autre côté, si le fait que le travail est terminé est reconnu, le fournisseur doit assumer les problèmes de garantie des défauts et de garantie de qualité contractuelle.

Le fait que le fournisseur soit libéré de la responsabilité de non-exécution de l’obligation signifie que la possibilité de résiliation du contrat par l’utilisateur est grandement réduite. C’est parce que la résiliation du contrat basée sur la responsabilité de garantie des défauts est limitée aux cas où l’objectif du contrat ne peut pas être atteint. Si le contrat est résilié, le fournisseur perd également le droit de demander une rémunération (en d’autres termes, il ne reçoit plus de rémunération), ce qui rend les conflits autour de “l’achèvement du travail” plus fréquents dans la pratique.

En ce qui concerne la “résiliation” d’un contrat dans le développement de systèmes, une explication détaillée est donnée dans l’article ci-dessous.

https://monolith-law.jp/corporate/cancellation-of-contracts-in-system-development[ja]

Notes relatives à l’achèvement du travail

Comment envisager les modifications de spécifications et le développement supplémentaire

Il est possible que le fournisseur se retrouve dans une situation où, bien qu’il ait déjà réussi à répondre aux spécifications initialement demandées, il se voit demander des modifications de spécifications ou l’ajout de fonctionnalités, rendant difficile la conclusion du projet. Dans de tels cas, des problèmes tels que “le moment de terminer le développement du système” peuvent survenir. Nous expliquons en détail ce point dans l’article ci-dessous.

https://monolith-law.jp/corporate/increase-of-estimate[ja]

Attention également à la réforme du Code civil japonais

De plus, les dispositions relatives à la responsabilité de garantie des défauts basées sur le contrat d’entreprise sont un domaine fortement influencé par la réforme du Code civil japonais, en raison de la complexité et de la difficulté de comprendre les liens entre les articles précédents. Dans le contexte de la réforme du Code civil japonais, nous expliquons en détail comment interpréter ce qu’est un “défaut” dans l’article ci-dessous.

https://monolith-law.jp/corporate/defect-warranty-liability[ja]

Résumé

Dans cet article, nous avons expliqué le chemin à suivre pour relier un projet de développement de système, qui peut souvent se retrouver dans une situation où “on ne voit pas la sortie”, à la notion juridique de “fin du travail”. La sortie de chaque projet dépendra des exigences de développement, mais il n’est pas rare que le concept juridique de “fin du travail” serve de fil conducteur en cas de litige sur ces points.