Qu'est-ce que l'obligation de gestion de projet dans le développement de systèmes ?

Le développement de systèmes est une tâche qui ne peut progresser qu’avec la coopération mutuelle entre l’utilisateur qui commande le travail et le fournisseur qui le reçoit.

Les projets de développement de systèmes informatiques utilisés dans les entreprises ne se déroulent que rarement comme prévu. Au contraire, ils sont souvent confrontés à de nombreux problèmes et défis, grands ou petits, et il est plus courant de progresser en surmontant ces obstacles un par un. Dans ce contexte, il est bien sûr important que les utilisateurs et les fournisseurs s’efforcent de travailler en harmonie, mais la gestion des crises en prévision des conflits est également essentielle.

D’un point de vue juridique, la première étape de la gestion des crises consiste à clarifier les obligations mutuelles et les droits que chacun peut revendiquer. Dans cet article, nous expliquerons principalement les obligations légales du fournisseur dans le cadre d’un projet, en mettant l’accent sur les obligations de gestion de projet.

Qu’est-ce que l’obligation de gestion de projet du côté du fournisseur ?

Commençons par examiner le contenu de l’obligation de gestion de projet du côté du fournisseur.

Selon la jurisprudence, le contenu de l’obligation de gestion de projet est le suivant :

– L’obligation de mener les travaux de développement conformément à l’accord, de gérer constamment l’état d’avancement, de s’efforcer de découvrir les facteurs qui entravent les travaux de développement et de traiter correctement ces facteurs.

– L’obligation de gérer correctement l’implication de l’utilisateur dans le développement et de faire en sorte que l’utilisateur, qui n’a pas de connaissances spécialisées en développement de systèmes, ne fasse rien pour entraver les travaux de développement.

Cela signifie que le fournisseur doit indiquer les problèmes et les délais pour les questions qui nécessitent une décision de l’utilisateur, montrer les problèmes qui peuvent survenir si la décision de l’utilisateur est retardée, conseiller l’utilisateur pour encourager la prise de décision, et si des demandes inacceptables sont faites en fonction de l’avancement du développement, expliquer suffisamment les raisons et refuser les demandes de l’utilisateur.

Ainsi, le fournisseur a l’obligation de promouvoir les travaux de développement tout en encourageant l’utilisateur à prendre des décisions, et de faire des efforts pour que le développement du système soit couronné de succès.

L’obligation de coopération du côté de l’utilisateur

Cependant, dans le développement de systèmes, ce n’est pas seulement le fournisseur qui assume toutes les obligations de manière unilatérale. Après tout, puisqu’il s’agit d’un système informatique à utiliser dans l’entreprise du client, le projet de développement de système ne devrait pas être une affaire d’autrui pour le client.

Même si vous utilisez des experts externes en vous fiant à leur compétence technique et organisationnelle pour développer le système, la gouvernance interne devrait s’appliquer. Sans efforts pour tirer parti des compétences des experts externes, il est impossible de livrer le produit nécessaire en le considérant comme une affaire d’autrui. Dans ce sens, l’utilisateur a également une obligation de coopérer dans le développement du système.

Les obligations de coopération que l’utilisateur doit remplir sont les suivantes :

　① L’utilisateur effectue une analyse des risques de manière proactive, coordonne correctement les opinions internes, unifie les points de vue et communique ses demandes au fournisseur.

　② Vérifier les livrables.

　③ Répondre aux demandes de coopération du fournisseur.

Il est demandé à l’utilisateur de communiquer clairement au fournisseur les fonctions qu’il attend du système et de coopérer activement dans le développement.

La gestion de projet n’est pas facile

Le fait qu’un système informatique soit constitué d’une combinaison de petites pièces peut être difficile à réaliser pour l’utilisateur qui ne voit que l’écran. Cependant, c’est très important lorsqu’on réfléchit à la difficulté de gérer un projet de développement de système. C’est précisément parce que le système informatique est de cette nature que le fournisseur est tenu de faire preuve d’une attention minutieuse et, en même temps, d’une capacité à organiser et à avoir une vue d’ensemble de l’ensemble du projet.

Il y a des difficultés dans le travail que l’on ne peut pas imaginer en regardant simplement l’écran, et cela peut aussi être la raison pour laquelle un projet “prend feu”. Il est important de comprendre ces points et de savoir que “la gestion d’un projet de développement de système informatique n’est pas une tâche facile”. C’est une précondition majeure pour apprendre à gérer les risques d’un projet.

Ce qui peut se produire en cas de violation des obligations de gestion de projet

Alors, que se passe-t-il concrètement en cas de violation des obligations de gestion de projet ?

Il n’y a pas de clause claire à ce sujet, et il n’y a pas de règles établies qui disent “voici ce que sont les obligations de gestion de projet”.

Cependant, à partir des précédents judiciaires, nous pouvons déduire une certaine cohérence sur ce que l’utilisateur peut faire en cas de violation des obligations par le fournisseur.

Si le fournisseur a violé ses obligations, l’utilisateur peut réclamer des dommages et intérêts ou la résiliation du contrat. Cependant, si l’utilisateur est également en faute, le fournisseur peut être jugé non responsable, ou une compensation pour négligence peut être appliquée, réduisant ainsi le montant des dommages et intérêts.

D’autre part, si l’utilisateur a violé son obligation de coopération, le fournisseur peut réclamer à l’utilisateur un montant équivalent à la rémunération sur la base du risque d’achèvement non réalisé (Article 536, paragraphe 2, du Code civil japonais) ou de l’inexécution de l’obligation.

Exemples de jurisprudence illustrant l’obligation de gestion de projet

Il existe plusieurs exemples de jurisprudence qui illustrent l’obligation de gestion de projet.

Le cas suivant concerne un litige qui a évolué jusqu’au tribunal en raison de retards dans les délais de livraison et de demandes d’augmentation du devis initial de la part du fournisseur lors du développement d’un système. Il s’agit peut-être d’un exemple typique de ce que l’on appelle un “projet en crise”, où le conflit s’est prolongé jusqu’au tribunal sur la question de savoir comment répartir la responsabilité entre l’utilisateur et le fournisseur.

Le défendeur, en tant que professionnel du développement de systèmes, avait l’obligation de terminer le système informatique concerné d’ici la date de livraison convenue en phases, conformément au contrat de développement du système informatique et à la proposition du système informatique, en se basant sur ses connaissances et son expérience spécialisées. Par conséquent, le défendeur devrait être considéré comme ayant l’obligation de progresser dans le développement en suivant les procédures de développement, les méthodes de développement, les processus de travail, etc., présentés dans le contrat de développement du système informatique et la proposition du système informatique, de gérer constamment l’état d’avancement, de s’efforcer de découvrir les facteurs qui entravent le travail de développement et de traiter correctement ces facteurs. De plus, comme le développement du système est effectué en consultation avec le client, le défendeur devrait être considéré comme ayant l’obligation de gérer correctement l’implication du client, l’assurance nationale du demandeur, dans le développement du système et de faire en sorte que le demandeur, qui n’a pas de connaissances spécialisées en développement de systèmes, n’entrave pas le travail de développement (ci-après, ces obligations sont appelées “obligations de gestion de projet”).

Jugement du tribunal de district de Tokyo, 10 mars 2004 (année 16 de l’ère Heisei)

Il n’est pas nécessaire de déchiffrer le langage détaillé ou le déroulement complexe de l’affaire à partir du résumé du jugement ci-dessus. Le point clé est que le terme “obligation de gestion de projet” est utilisé tel quel. Bien qu’il n’y ait pas de disposition explicite, on peut voir l’attitude du tribunal qui cherche à établir des lignes directrices pour la répartition des responsabilités juridiques.

Après avoir simplifié le contenu du jugement ci-dessus, résumons-le en points. L'”obligation de gestion de projet” mentionnée ici signifie :

• Avancer le travail réel en fonction du plan préliminaire (procédures de développement, méthodes, processus, etc.)
• Gérer l’avancement pour voir si le travail réel progresse sans heurts
• Si des “facteurs d’obstruction” apparaissent qui empêchent le travail de progresser sans heurts, découvrir et prendre des mesures appropriées au fur et à mesure

De plus, en ce qui concerne les trois points ci-dessus,

• Il ne s’agit pas seulement d’efforts d’auto-assistance de la part du fournisseur, mais aussi d’efforts de communication, tels que demander la coopération nécessaire de la part de l’utilisateur au besoin

Il est possible de résumer que c’est ce qui est inclus.

En outre, le développement de systèmes est généralement conclu sous la forme d’un contrat de mandat ou d’un contrat d’entreprise en termes juridiques. Et un contrat de mandat est, pour le dire simplement, un contrat qui stipule “faire le travail avec une précision correspondant à la rémunération obtenue”, donc l’obligation de gestion de projet peut également être considérée comme un concept qui est absorbé dans la “précision, etc.” à réaliser.

Cependant, bien qu’il s’agisse d’un sujet de débat, même dans le cas d’un contrat d’entreprise, qui est un contrat pour “faire ce qui est demandé”, on pense que l’obligation de gestion de projet peut survenir. La raison, comme mentionné précédemment, est que le développement de systèmes, qu’il s’agisse d’un contrat de mandat ou d’un contrat d’entreprise, nécessite toujours une gestion de projet, et il est considéré que le fournisseur devrait le faire.

Exemple de jugement illustrant l’obligation de gestion de projet imposée avant la conclusion d’un contrat

Il est également considéré que l’obligation de gestion de projet peut être imposée même avant la conclusion d’un contrat. L’exemple de jugement cité ci-dessous indique que l’obligation de gestion de projet incombe au fournisseur même avant la conclusion du contrat, c’est-à-dire lors de la présentation de diverses propositions et plans.

Le cas suivant concerne un projet qui a échoué en cours de route, et la question était de savoir s’il était possible de reconnaître une obligation de gestion de projet en raison de lacunes dans la planification et la proposition avant la conclusion du contrat, ainsi que dans les estimations et les explications à l’utilisateur lors de la phase de proposition. Généralement, comme les tâches de planification et de proposition sont celles de la phase précédant la conclusion du contrat, la question était de savoir s’il était juridiquement possible de reconnaître une telle obligation. Cependant, le tribunal a reconnu cette obligation.

La façon dont l’obligation de gestion de projet est envisagée dans l’exemple de jugement cité ci-dessus s’étend également à la phase précédant la conclusion du contrat, comme on peut le voir ci-dessous.

Au stade de la planification et de la proposition, les grandes lignes des questions liées à la conception du projet et à sa faisabilité, telles que la définition des objectifs du projet, le coût du développement, la portée du développement et la durée du développement, sont définies, et en conséquence, les risques associés au projet sont également déterminés. Par conséquent, la planification du projet et l’analyse des risques exigées du fournisseur à ce stade sont indispensables pour mener à bien le développement du système. Ainsi, le fournisseur doit, même au stade de la planification et de la proposition, examiner et vérifier les fonctions du système qu’il propose, le degré de satisfaction des besoins de l’utilisateur, la méthode de développement du système, l’organisation du développement après la commande, etc., et expliquer à l’utilisateur les risques prévus. Cette obligation du fournisseur en matière de vérification et d’explication peut être considérée comme une obligation en vertu du droit des délits basée sur le principe de bonne foi dans le processus de négociation en vue de la conclusion d’un contrat, et l’appelant, en tant que fournisseur, doit assumer cette obligation (l’obligation relative à la gestion de projet à ce stade).

Jugement de la Haute Cour de Tokyo du 26 septembre 2013 (année 25 de l’ère Heisei)

Il convient de noter que, non seulement dans le contexte des projets IT, mais aussi dans toutes les transactions commerciales et les négociations impliquant le droit, il existe déjà une idée selon laquelle certaines obligations légales sont imposées à l’autre partie même avant la conclusion d’un contrat.

Plus la transaction est importante, plus le processus de “rapprochement” menant à l’objectif du contrat a tendance à être long. Même dans ce processus, il est bien compris, du moins moralement, qu’il faut être sincère envers l’autre partie. Pour le dire simplement, cette idée n’est pas seulement une émotion morale subjective, mais a également un sens juridique. (Le texte de la loi est cité ci-dessous. Les soulignements sont ajoutés par l’auteur.)

Article 1, paragraphe 2, du Code civil japonais
L’exercice des droits et l’exécution des obligations doivent être effectués avec bonne foi et sincérité.

Le mot-clé “principe de bonne foi” dans le jugement illustre succinctement le contenu ci-dessus.

Il convient de noter que l’exemple de jugement présenté dans cet article a également une certaine signification en tant que “guide pour délimiter la frontière entre l’obligation de coopération de l’utilisateur et l’obligation de gestion de projet du fournisseur”.

Conclusion : En cas de problème lié à une violation des obligations de gestion de projet, consultez un avocat

Dans cet article, nous avons tenté de faire un ordre général sur ce que l’on appelle l’obligation de gestion de projet dans le développement de systèmes. Le développement de systèmes comporte divers défis et problèmes, mais ce qui semble important lorsque vous êtes confronté à une telle situation est la “base” qui est commune à tous les scénarios de conflit. Il y a certainement une infinité de variations sur la façon dont chaque situation irrégulière se produit.

Cependant, l’importance de se demander “Qui avait initialement assumé quelle obligation légale ?” face à de telles situations a une certaine universalité qui dépasse l’individualité de chaque cas.

Plutôt que de se limiter à une résolution de problèmes ad hoc, il semble que les indices pour viser une résolution par la segmentation constructive des problèmes se trouvent également dans la loi et les précédents judiciaires.

En cas de problème lié à une violation des obligations de gestion de projet, consultez immédiatement un avocat.