Quelles sont les mesures à prendre lorsque le développement du système est interrompu en raison des circonstances de l'utilisateur?

Le travail de développement de systèmes est souvent un projet qui s’étend sur une longue période. Que peut faire le fournisseur si, après avoir commencé à travailler sur le développement d’un système, l’utilisateur déclare unilatéralement qu’il n’a plus besoin de ce système et qu’il n’est plus nécessaire de le créer ?

Dans cet article, nous allons expliquer les caractéristiques spécifiques des contrats de développement de systèmes et les mesures à prendre dans de tels cas.

La signification de la réflexion sur l’interruption due à la convenance de l’utilisateur

Le contrat de développement de système présente plusieurs caractéristiques notables lorsqu’il est considéré en tant que contrat. L’une d’elles est que la durée de travail est généralement longue, et que le fournisseur, en tant qu’obligation de gestion de projet, assume une grande responsabilité avec une grande discrétion. Le contenu global de l’obligation de gestion de projet que le fournisseur assume est expliqué en détail dans l’article ci-dessous.

https://monolith-law.jp/corporate/project-management-duties[ja]

Une autre caractéristique est que l’utilisateur, bien qu’il soit un client, a une large obligation de coopérer avec les activités du fournisseur. Comme il s’agit d’un système utilisé en interne, il ne suffit pas de le “jeter” au fournisseur. Il y a une obligation de coopérer de manière appropriée afin que le fournisseur puisse exercer son expertise dans son travail, même à partir de l’intérieur de l’entreprise. Ceci est expliqué en détail dans l’article ci-dessous.

https://monolith-law.jp/corporate/user-obligatory-cooporation[ja]

En résumant brièvement le contenu ci-dessus, il y a une relation de contrepartie entre le fournisseur et l’utilisateur, où le fournisseur est un “prestataire externe” qui développe le système et le client est un “client” qui paie une rémunération, mais en même temps, il y a aussi un aspect de “collègues” qui devraient collaborer vers un objectif commun de réalisation du projet. Cette complexité des relations n’est généralement pas présente chez un simple tailleur de costumes sur mesure, et est une caractéristique majeure des contrats liés au développement de systèmes. Les conflits liés au développement de systèmes sont souvent compliqués et tendus en raison de cette complexité des relations, et une fois qu’ils sont enchevêtrés, il est souvent difficile de déterminer comment organiser légalement les relations entre les deux parties.

Il est également significatif de réfléchir à la question de savoir comment comprendre les relations de droits et d’obligations entre les deux parties lorsque l’utilisateur change d’avis et dit soudainement : “Finalement, nous n’avons plus besoin de ce système, donc nous n’avons plus besoin de poursuivre le projet”. En un sens, cela donne un exemple de la façon de penser juridiquement face à une relation contractuelle complexe. Ci-dessous, nous organiserons les questions à examiner par la suite en supposant un tel cas.

Tout d’abord, clarifiez les raisons de la résiliation

Du point de vue du fournisseur, il peut y avoir des cas où l’utilisateur veut unilatéralement interrompre le projet, mais cette perception n’est pas nécessairement partagée avec l’utilisateur. Par exemple, supposons un cas où un projet a été lancé pour développer un système de gestion du personnel pour les employés travaillant à l’étranger, mais plus tard, le plan d’expansion à l’étranger lui-même a été retiré, rendant le développement du système inutile. En effet, à partir de cette explication seule, on pourrait interpréter cela comme un changement d’avis unilatéral de la part de l’utilisateur.

Cependant, que se passerait-il si, dans le contexte de cette décision, il y avait des problèmes du côté du fournisseur, comme des retards dans chaque étape et des violations des obligations de gestion de projet, et que les difficultés de progression du développement lui-même étaient également une des causes du changement de politique de l’entreprise?

Comme mentionné précédemment, le développement de systèmes est une tâche où le fournisseur et l’utilisateur partagent de nombreuses obligations et avancent en étroite collaboration. Par conséquent, même si l’utilisateur a exprimé son désir d’interrompre le projet et que le fournisseur considère cela comme une résiliation pour des raisons personnelles, il faut être conscient du risque que le fournisseur puisse être accusé de manquement à ses obligations et que la résiliation ou la résiliation mutuelle soit revendiquée sur la base de la non-exécution des obligations.

La distinction entre une résiliation pour des raisons personnelles, une résiliation basée sur la non-exécution des obligations, ou une résiliation mutuelle, dépend souvent du progrès du projet et de l’historique des négociations, et tend à être jugée individuellement pour chaque cas. Par conséquent, si le fournisseur avance avec le traitement postérieur en supposant qu’il s’agit d’une résiliation pour des raisons personnelles de l’utilisateur, il est important de laisser un enregistrement clair de cela dans les procès-verbaux des réunions, etc., afin d’éviter tout conflit sur ce point plus tard.

Vérification des dispositions légales pour les demandes de rémunération et d’indemnisation

En tenant compte des points mentionnés ci-dessus, si nous pouvons procéder à une résiliation à l’initiative de l’utilisateur, nous devons ensuite examiner si le fournisseur peut demander à l’utilisateur une rémunération proportionnelle à l’achèvement du travail ou une indemnisation pour dommages et intérêts.

Les dispositions légales à consulter varient en fonction du type de contrat. Les contrats de développement de systèmes peuvent être largement classés en contrats d’entreprise et contrats de mandat.

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

Et pour les contrats de mandat et les contrats d’entreprise, le Code civil japonais (loi japonaise) stipule ce qui suit :

a.) Dans le cas d’un contrat de mandat
Demande de rémunération : Article 648, paragraphe 3 du Code civil japonais (loi japonaise)
Si le mandat se termine en cours d’exécution pour une raison qui ne peut être attribuée à la faute du mandataire, ce dernier peut demander une rémunération proportionnelle à l’exécution déjà effectuée.
Demande d’indemnisation : Article 651 du Code civil japonais (loi japonaise)
1. Le mandat peut être révoqué à tout moment par chaque partie.
2. Si l’une des parties révoque le mandat à un moment défavorable pour l’autre partie, cette partie doit indemniser l’autre partie pour les dommages subis. Cependant, cela ne s’applique pas en cas de circonstances inévitables.

b.) Dans le cas d’un contrat d’entreprise
Demande d’indemnisation : Article 641 du Code civil japonais (loi japonais)
Tant que l’entrepreneur n’a pas terminé le travail, le client peut à tout moment résilier le contrat en indemnisant les dommages.

Il convient de noter que la portée de l’indemnisation basée sur l’article 641 du Code civil japonais (loi japonaise) est considérée comme incluant non seulement les coûts déjà engagés, mais aussi les “profits qui auraient été réalisés si le contrat n’avait pas été résilié”. Cela reflète l’idée qu’il est inutile pour la loi de forcer l’achèvement du travail qui est devenu inutile du point de vue du client, et qu’il est plutôt rationnel de garantir le profit du côté du fournisseur en payant une compensation équivalente dans de tels cas.

Cependant, il n’est pas rare que l’indemnisation basée sur l’article 641 du Code civil japonais (loi japonaise) soit exclue dans les contrats individuels entre le fournisseur et l’utilisateur. Dans de tels cas, l’accord individuel conclu entre les parties (c’est-à-dire le contrat) prévaut, et il est possible que les dispositions du Code civil japonais (loi japonaise) ne s’appliquent pas, donc une attention particulière est nécessaire.

Poursuivre la preuve du volume de travail et des dommages

Dans le cas d’une résiliation due à la convenance personnelle de l’utilisateur, il est courant que le contrat stipule que l’on peut réclamer des frais de commission pour le volume de travail (c’est-à-dire la partie terminée) et des dommages-intérêts. Par conséquent, il est généralement nécessaire pour le côté du vendeur de fournir des preuves concernant le volume de travail et les dommages afin de réclamer des dommages-intérêts.

Cependant, la preuve de ce volume de travail, c’est-à-dire du pourcentage d’achèvement, peut s’avérer être une tâche très ardue si elle est effectuée en réalité. C’est parce qu’il est prévu que le volume de travail, tel que l’audition pour vérifier l’avancement, sera considérable si elle est effectuée en réalité, en particulier lorsque plusieurs sous-traitants sont impliqués. De plus, si vous devez créer des documents pour soutenir les résultats de l’audition, et même documenter le contenu de l’audition lui-même, le travail sera énorme. Il y a aussi de nombreux inconvénients, comme le risque d’être dit que la preuve est insuffisante malgré tous ces efforts, rendant le travail investi dans la préparation de la preuve futile.

Compte tenu de ces points, une mesure possible serait de stipuler dès le début du contrat que si le contrat est résilié en cours de route, il sera calculé au prorata en fonction du nombre de jours jusqu’au moment de la résiliation, afin de simplifier le calcul. De plus, étant donné que la preuve du volume de travail est laborieuse, une autre méthode pourrait être d’abandonner la réclamation pour le volume de travail lui-même et de réclamer les coûts engagés pour le développement de la partie déjà terminée. Si les coûts de développement sont internes, il n’est pas rare de pouvoir les calculer facilement avec une formule simple comme “temps de travail x taux unitaire”. Surtout pour les projets à faible marge de profit, en privilégiant les réclamations basées sur les coûts plutôt que sur le volume de travail, il est possible d’espérer compenser les pertes tout en mettant l’accent sur la facilité de recouvrement des créances, ce qui peut souvent être une mesure de secours plus réaliste.

Quels sont les points à considérer du côté de l’utilisateur ?

Tout d’abord, il y a des points à considérer pour l’utilisateur qui souhaite résilier le contrat de sa propre initiative. Il s’agit de vérifier à l’avance le montant approximatif des dommages-intérêts à payer au fournisseur. Lorsque nous parlons de “montant approximatif”, il s’agit de donner une idée générale pour guider le déroulement des négociations futures (il serait contre-productif de retarder l’expression de l’intention de résilier, donc un montant précis n’est pas nécessaire).

Si le montant approximatif vérifié semble injustement élevé, il convient de demander une explication. Cependant, si vous essayez de négocier de manière excessive pour réduire le montant à payer, cela pourrait entraîner des litiges inutiles et aggraver la situation. Si les négociations entre les deux parties semblent difficiles, il pourrait être judicieux de consulter un avocat.

En passant, dans cet article, nous avons expliqué en supposant qu’un contrat de développement de système a été conclu. Cependant, dans la réalité du développement de systèmes, il n’est pas rare que la question de savoir si un contrat a été effectivement conclu soit contestée. Nous expliquons cela en détail dans l’article ci-dessous.

https://monolith-law.jp/corporate/system-development-contract[ja]

Résumé

Dans cet article, nous avons expliqué le processus de gestion d’un cas où un projet est interrompu en raison de circonstances de l’utilisateur. Cependant, le point le plus important de cet article est de se demander si l’on peut vraiment dire que c’est dû à des circonstances personnelles de l’utilisateur et si le fournisseur n’a vraiment commis aucune faute.

Le développement de systèmes est un projet où le fournisseur et l’utilisateur assument tous deux de grandes responsabilités. Par conséquent, si vous ne considérez pas soigneusement à l’avance si vous pouvez vraiment attribuer la responsabilité à l’autre partie, vous risquez d’aggraver la situation. Il est important d’être conscient de ce point.