Quelles sont les obligations de support incombant au fournisseur après la fin du développement du système?

Dans le domaine du développement de systèmes, il est bien connu que les fournisseurs spécialisés dans le développement de systèmes, appelés “vendeurs”, ont une “obligation de gestion de projet”. Cependant, un concept similaire mais distinct existe légalement, connu sous le nom de “devoir de support”. Dans cet article, nous allons expliquer ce “devoir de support”, en tenant compte des précédents judiciaires.

Qu’est-ce que l’obligation de soutien ?

Présentation de l’obligation de soutien

Dans le cadre des obligations qu’un fournisseur doit à un utilisateur, l’obligation de gestion de projet est l’une des plus représentatives. C’est une notion qui a été établie à travers de nombreux précédents judiciaires, et qui englobe les obligations que le fournisseur, en tant qu’expert en développement de systèmes, doit à l’ensemble du projet.

L’obligation de gestion de projet est un terme juridique très connu en matière de développement de systèmes, et il ne fait aucun doute qu’il s’agit de l’une des principales obligations que le fournisseur assume. Cependant, certains précédents judiciaires reconnaissent l’existence d’une obligation différente de l’obligation de gestion de projet, appelée “obligation de soutien”.

L’obligation de soutien devient un problème en termes de soutien opérationnel à l’utilisateur

Alors, qu’est-ce que l’obligation de soutien ? Et pourquoi est-elle appelée par un nom différent de l’obligation de gestion de projet ? L’obligation de soutien devient généralement un problème après la fin du développement du système. Un projet de développement de système, étant un “projet de développement”, se termine en principe une fois que le système à créer est terminé. C’est-à-dire que le projet de développement de système commence par la clarification de ce que doit être le système à créer (c’est-à-dire la définition des exigences) et se termine par la vérification de sa réalisation (c’est-à-dire le test ou l’acceptation).

Cependant, même si un projet de développement de système est compris comme étant le processus de développement lui-même qui crée un nouveau système, il est évident que le système développé sera ensuite utilisé dans les opérations. En d’autres termes, il serait irréfléchi de ne pas se soucier du tout de la manière dont le système sera utilisé après son développement, et de dire que “tant que je suis en charge du développement, il suffit de le créer” pourrait conduire à une grande irrationalité. En tenant compte de ces points, il a été question dans les précédents judiciaires d’imposer également au fournisseur, qui est en charge du développement du système, une certaine obligation de soutien opérationnel. C’est-à-dire qu’il faut se demander si l’obligation de soutien opérationnel après le développement ne devrait pas être incluse dans les obligations que le fournisseur doit assumer dans le cadre du contrat de développement de système. Comme le soutien opérationnel n’est pas en soi une partie du processus de développement, on pense qu’il a été appelé “obligation de soutien” pour le distinguer de l’obligation de gestion de projet.
　

Qu’est-ce qu’un cas de jurisprudence où l’obligation de soutien a été un problème ?

Un cas où l’activité de l’utilisateur a été entravée à l’étape du test du système

Dans le cas du jugement cité ci-dessous, lors du test du système effectué avant le démarrage du système, l’utilisateur n’a pas pu utiliser le système comme prévu initialement, et en conséquence, l’utilisateur a dû abandonner le fonctionnement du système lui-même. Ce cas concerne un problème survenu lors du démarrage de l’exploitation par l’utilisateur, et la question était de savoir comment justifier la responsabilité du fournisseur à partir du contrat d’entreprise conclu au préalable pour le développement du système. En conclusion, la demande de dommages-intérêts de l’utilisateur a été reconnue, et la “violation de l’obligation de soutien” a été citée comme base.

I Violation de l’obligation de soutien
(A) Le représentant du demandeur a demandé à la défenderesse le 14 juillet de l’année 1997, “Je veux que vous preniez soin de moi jusqu’à la fin, pas seulement de créer le système, mais aussi de le faire fonctionner correctement.“, “Nous sommes des amateurs, donc si nous payons beaucoup d’argent, je veux que vous le fassiez fonctionner jusqu’à la fin.“. En réponse à cela, la défenderesse a expliqué qu’elle pouvait construire un système capable d’atteindre l’objectif d’introduction du demandeur, et a promis de soutenir jusqu’à ce qu’il puisse être utilisé correctement. Par conséquent, un accord a été conclu entre le demandeur et la défenderesse pour que la défenderesse soutienne jusqu’à ce que le demandeur puisse utiliser correctement le système en question.
Il est clair que la défenderesse a une obligation de soutien envers le demandeur, car elle a comptabilisé un coût de 1 726 000 yens pour “l’aide à l’introduction du package” en tant que prix du contrat d’entreprise, et dans le devis, il est écrit “maintenance gratuite pendant six mois après l’introduction” pour les frais de maintenance mensuels, et dans le document intitulé “Sur le soutien SE à l’avenir (document de réunion interne)”, il est confirmé que le soutien SE peut être reçu pour “la création du processus d’introduction (plan)” et “le travail de vérification des données/opérations” pour les commandes de produits frais.

(B) Et l’obligation de soutien que la défenderesse doit au demandeur est, concrètement, au moins jusqu’à ce que le demandeur atteigne le fonctionnement principal du système en question, la défenderesse doit, envers le demandeur, ① fournir des conseils appropriés sur la méthode d’exploitation du système, ② répondre aux problèmes du système survenus lors du test d’exploitation, ③ améliorer le système en fonction des résultats du test d’exploitation, ④ effectuer une formation d’introduction pour l’opérateur
Cependant, même si de nombreux problèmes se sont posés lors du test d’exploitation, la défenderesse n’a pas répondu sérieusement à ces problèmes, en les attribuant à la compétence de l’opérateur, et n’a fait que demander des frais de formation d’introduction pour l’opérateur, sans fournir aucun soutien approprié au demandeur en vue du fonctionnement principal.

Jugement du tribunal de district de Hachioji à Tokyo, 5 novembre de l’année 2003

Dans ce jugement, le mot “soutien” apparaît environ 30 fois dans l’ensemble du jugement, y compris la table des matières. On peut voir que c’était une conclusion après avoir visé une résolution équitable tout en considérant assez concrètement le déroulement de l’affaire, comme le fait que la voix de l’utilisateur demandant un soutien approprié est directement inscrite dans le jugement. Les points particulièrement notables pour comprendre ce cas sont :

• La violation de l’obligation de soutien est traitée comme un “non-exécution de l’obligation”, de sorte que des dommages-intérêts ont été ordonnés pour les dommages résultant de celle-ci
• Le terme “obligation de gestion de projet” n’est utilisé à aucun moment dans l’ensemble du jugement

On peut voir une attitude qui tente de traiter cela comme une obligation contractuelle incluse dans le contrat de développement de système, bien qu’il s’agisse d’un concept différent de la gestion de projet.

Comment devons-nous interpréter la nature de l’obligation de soutien ?

L’obligation de soutien n’est pas encore un concept clair

En somme, le précédent judiciaire indique que le fournisseur qui a développé le système doit également fournir le soutien nécessaire pour que l’utilisateur puisse commencer à l’exploiter. Cependant, l’obligation de soutien n’est pas aussi bien établie que l’obligation de gestion de projet, et il n’y a pas beaucoup d’indices pour comprendre sa réalité. En particulier, le terme “soutien” lui-même comprend le problème qu’il n’est pas clair ce qu’il doit faire concrètement.

L’obligation de soutien n’est pas reconnue sans limites

De plus, le jugement qui a reconnu la violation de l’obligation de soutien du fournisseur a également indiqué un point très important.

Le défendeur est considéré comme ayant l’obligation de fournir un certain soutien nécessaire pour que le demandeur puisse exploiter le système qu’il a construit et livré sur la base du présent contrat d’entreprise. Cependant, son contenu n’est pas considéré comme étant, comme le prétend le demandeur, de fournir tout soutien gratuit jusqu’à ce que le demandeur soit effectivement en mesure d’exploiter le système en question, sans limite de temps.

Jugement du 5 novembre 2003 (2003) du tribunal de district de Hachioji à Tokyo

Si le principal travail accepté est le “développement” du système, il est probable qu’il y ait également des contraintes sur ce qui doit être fait en tant que soutien pour l’exploitation ultérieure. Dans ce jugement, il y a plusieurs points caractéristiques, tels que le fait de citer la voix des utilisateurs demandant du soutien dans le texte du jugement, de mentionner le contenu de l’estimation préalable, et de toucher à l’existence ou non d’une clause spéciale pour fournir du soutien. En d’autres termes, en tenant compte du fait que si le concept de l’obligation de soutien s’étend indéfiniment, cela imposerait un fardeau important au fournisseur, il est probable que l’intention était d’être relativement prudent dans la reconnaissance de la violation de l’obligation.

La réalité de l’obligation de soutien doit être examinée en conjonction avec l’obligation de coopération de l’utilisateur

En fin de compte, la question est de savoir comment l’utilisateur et le fournisseur partagent la charge de travail dans les premières étapes de l’exploitation du développement du système. Cela comprend certainement le problème quelque peu complexe de savoir quelle est l’obligation légale du fournisseur au moment du démarrage de l’exploitation, à partir du contrat relatif au “développement”. En même temps, il est indéniable qu’il y a une forte tendance à exiger un jugement basé sur des circonstances individuelles.

Cependant, il est possible que la réalité de l’obligation de soutien que le fournisseur doit assumer devienne plus certaine en comprenant également l’obligation de coopération que l’utilisateur doit assumer.

Après tout, l’effort pour améliorer les opérations grâce à un nouveau système a un aspect de travail conjoint entre le fournisseur, qui est un expert en technologie, et l’utilisateur, qui a une connaissance des opérations internes. Par conséquent, en ce qui concerne cette obligation de soutien, il est souvent possible de définir sa portée en précisant ce que l’utilisateur doit résoudre par ses propres efforts dans le cadre de l’exécution de son “obligation de coopération”.

Résumé

Dans cet article, nous avons organisé une discussion sur l’obligation de soutien, qui peut être considérée comme une dérivée du management de projet, tout en tenant compte des bases de ce dernier. Bien qu’il reste encore de nombreux points ambigus dans le concept de l’obligation de soutien, nous pensons que les éléments fondamentaux tels que l’obligation de gestion de projet et l’obligation de coopération sont toujours importants pour sa compréhension.