Quelle est la signification juridique des objectifs de gestion et des objectifs chiffrés dans les projets de développement de systèmes?

Les projets de développement de systèmes sont souvent étroitement liés à des améliorations majeures des opérations d’entreprises ou de lieux de travail. Dans ce contexte, on peut parfois exiger une attitude contribuant à la résolution des problèmes de gestion de l’entreprise du côté de l’utilisateur, ou à l’atteinte d’objectifs chiffrés. Cependant, est-ce vraiment une obligation légale de s’engager envers ces objectifs de gestion ? La question se pose quant à la signification juridique des objectifs chiffrés et des objectifs de gestion. Dans cet article, nous allons expliquer les problèmes juridiques associés à divers “objectifs” et “buts” liés au développement de systèmes.

Pourquoi les objectifs et les buts du développement de systèmes deviennent-ils une source de conflit ?

Parce que c’est un problème qui se situe entre l’obligation de coopération de l’utilisateur et la discrétion limitée du fournisseur

Si l’on considère la manière dont les transactions commerciales sont menées, il y a plusieurs points qui peuvent être considérés comme caractéristiques des projets de développement de systèmes. L’un d’eux est que le projet de développement de systèmes par le fournisseur ne peut pas être réalisé par le fournisseur seul, mais nécessite la coopération de l’utilisateur. Cette obligation est clairement établie dans la jurisprudence sous le nom d'”obligation de coopération”. Principalement, l’utilisateur est également appelé à coopérer dans le développement du système lors des phases de définition des exigences, de conception de base et d’acceptation des livrables.

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

Un autre point est que le fournisseur est généralement appelé à exercer une grande discrétion dans l’exécution de ses tâches. Il existe un terme juridique qui englobe ce que le fournisseur doit faire dans l’ensemble du projet de développement de systèmes, appelé “obligation de gestion de projet”. Nous expliquons cela en détail dans l’article ci-dessous.

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

En résumant ce qui précède, nous pouvons souligner deux points importants ici.

• L’utilisateur est appelé à fournir les informations nécessaires au fournisseur au fur et à mesure et à coopérer avec le travail de développement du fournisseur.
• Le fournisseur est appelé à comprendre les objectifs et les buts du projet pour l’utilisateur et à prendre des mesures qui correspondent à ceux-ci.

En raison de ces deux points, la question de savoir dans quelle mesure l’atteinte des objectifs de gestion et des objectifs chiffrés, tels qu’expliqués par l’utilisateur à l’avance, peut devenir une obligation du fournisseur en vertu de la loi devient également un problème. En d’autres termes, bien qu’il y ait un aspect selon lequel il est de la responsabilité de l’utilisateur de résumer ce que le fournisseur doit faire (non pas en termes vagues comme des objectifs, mais en termes de spécifications) et de le présenter, il y a aussi un aspect selon lequel le fournisseur, en tant que professionnel, a l’obligation de fournir ce que l’utilisateur demande essentiellement (non pas simplement en faisant ce qu’on lui dit de faire, mais en fournissant ce que l’utilisateur demande). C’est cette collision entre les deux parties qui est caractéristique des conflits autour des “objectifs” et des “buts” du développement de systèmes. De plus, du point de vue de la loi, il est un défi pratique de fournir des directives pour la résolution des conflits qui sont équitables pour les deux parties.

Scénarios concrets où les objectifs de l’utilisateur influencent le projet

Les projets de développement de systèmes sont souvent liés à des mesures d’amélioration et d’efficacité des opérations à grande échelle dans les entreprises et les lieux de travail, et il est souvent question d’entendre parler des problèmes de gestion et des objectifs de gestion dès la phase de planification et de proposition. À ce stade, on peut envisager des échanges sur le rapport coût-efficacité du développement du système et des échanges à travers divers objectifs chiffrés.

• Réduction des coûts de personnel grâce à l’automatisation
• Augmentation des ventes et des revenus
• Réduction du temps de travail

Par exemple, si les éléments ci-dessus sont l’objectif final du projet, le fournisseur peut expliquer l’effet de l’investissement dans le développement du système à l’avance, comme un consultant, et envisager de faire des ventes.

Quels sont les cas de litige où les objectifs de gestion énoncés par l’utilisateur ont posé problème ?

Cependant, le fournisseur est généralement un expert en développement de systèmes. Si toute la responsabilité repose sur lui en ce qui concerne les objectifs de gestion de l’utilisateur, cela pourrait être considéré comme excessif.

Le cas où l’amélioration de la vitesse des opérations a été énoncée comme objectif

En relation avec ce sujet, dans le cas cité dans le jugement ci-dessous, les objectifs et les buts du projet de développement de système étaient inscrits dans le plan d’affaires créé au début du projet. Cependant, une fois le système achevé et mis en service, il n’a pas été possible d’atteindre ces objectifs et buts, ce qui a conduit à un litige. Le plan initial indiquait que, une fois le système achevé et effectivement utilisé, il visait à réaliser les conditions suivantes :

• Réduire de 50% le temps de saisie manuelle
• Permettre l’achèvement des tâches administratives utilisant le système IT concerné dans un délai déterminé

L’utilisateur a tenté de poursuivre le fournisseur pour non-exécution de ses obligations et responsabilité pour défauts, car il n’a pas pu réaliser ces objectifs. Cependant, le tribunal n’a pas accepté cet argument (les parties soulignées et en gras ont été ajoutées par l’auteur).

Et donc, (omis) selon l’ensemble des arguments, ① l’objectif de cette affaire est “l’amélioration de l’efficacité des opérations”, “la création d’une base de CRM”, “la gestion visible”, etc., qui sont des choses abstraites, et les objectifs sont “augmenter les points de contact avec les clients”, “répartir l’effort des employés administratifs entre le contrôle interne et le soutien aux ventes”, “pouvoir faire des prévisions de ventes plus précises”, “réduire les remises excessives sur les ventes”, etc., qui sont en grande partie abstraites, et “réduire le temps de saisie de 50%”, “réduire le temps de création de devis de 50%”, “être capable de faire des divulgations légales dans les délais légaux”, etc., sont des objectifs qui dépendent de la manière dont le défendeur gère et opère après l’introduction de SBO, et ce n’est pas quelque chose que le demandeur, une entreprise de développement de systèmes qui soutient l’introduction de logiciels packagés, peut s’engager à réaliser, ② dans le procès-verbal de la réunion après le coup d’envoi de ce projet, il n’y a pas de mention d’une discussion spécifique sur la réalisation de cet objectif et de ces objectifs, ③ dans le plan de projet de ce projet, des expressions comme “devenir une entreprise cotée”, qui ne sont pas en soi de nature contractuelle, sont utilisées, (omis) en tenant compte de ces circonstances, il est reconnu que le demandeur a créé la description de cet objectif dans le plan de projet de cette affaire sur la base de l’explication du défendeur, afin d’éviter l’échec de ce projet, pour obtenir une compréhension commune de l’objectif et des résultats de ce projet, et il n’est pas possible de reconnaître que le défendeur a confié au demandeur le développement d’un système pour réaliser cet objectif. (omis) Par conséquent, il n’est pas possible de reconnaître que le demandeur a accepté de développer un système pour réaliser cet objectif de la part du défendeur, (omis) il n’y a aucune raison pour les allégations de responsabilité pour non-exécution des obligations et de garantie des défauts.

Jugement du tribunal de district de Tokyo, 28 décembre 2010 (Heisei 22)

Quelle est la signification juridique des objectifs de gestion et des objectifs chiffrés que l’on peut tirer des précédents judiciaires ?

Comme mentionné dans ce jugement, la question de savoir si les objectifs du développement de systèmes, ou les objectifs quantifiés en chiffres, peuvent être atteints dépend généralement de divers facteurs tels que les efforts de gestion de l’utilisateur qui utilise le système. Par conséquent, il convient de considérer que le seuil de responsabilité du côté du fournisseur est très élevé. En premier lieu, si la responsabilité du fournisseur pour non-exécution des obligations ou pour défauts est reconnue, cela signifie que la réalisation des “objectifs” ou des “buts” faisait partie du contenu du contrat. Cependant, dans ce cas, les “objectifs” et les “buts” :

• En ce qui concerne les choses abstraites et vagues, il est difficile de les considérer comme faisant partie du contenu du contrat, car elles ne correspondent pas à la nature des obligations juridiques.
• En ce qui concerne les choses qui nécessitent des efforts d’auto-assistance de la part de l’utilisateur, en particulier du côté de la gestion, il est inapproprié de les attribuer au fournisseur, car elles sont hors de son contrôle, et il est difficile de les considérer comme faisant partie des obligations contractuelles.

Il a été jugé que ces évaluations étaient juridiquement acceptables.

Autres points à retenir de ce jugement

Ce jugement contient également plusieurs autres points intéressants.

• Le fait que le tribunal ait pris en compte le fait que le partage des “objectifs” et des “buts” d’un projet de développement de système peut simplement être un effort de communication pour obtenir une “compréhension commune” entre l’utilisateur et le fournisseur.
• Le fait que le tribunal ait pris en compte les procès-verbaux des réunions, entre autres, pour déterminer à quel point ces “objectifs” et “buts” étaient des éléments essentiels dans le cadre du projet.

Par ailleurs, pour les problèmes juridiques liés au développement de systèmes, nous avons expliqué l’importance de la gestion des documents et des procès-verbaux dans l’article suivant.

https://monolith-law.jp/corporate/the-minutes-in-system-development[ja]

Précautions juridiques concernant les objectifs de gestion et les objectifs chiffrés

Cependant, concernant ces “objectifs” et “buts”, il est important de prendre en compte les points supplémentaires suivants.

Le fait que le consulting soit payant ou gratuit peut changer la donne

Si vous avez non seulement un projet de développement de système, mais aussi un contrat de consulting payant, la situation peut changer considérablement. Si, par exemple, un plan d’exécution peu réalisable a été établi sans tenir compte des ressources de gestion dont dispose l’utilisateur, il est possible que l’utilisateur soit tenu responsable de l’inexécution du contrat de consulting payant.

Les défauts du produit final, les incohérences des fonctionnalités et des spécifications sont des problèmes distincts

De plus, si le projet de “développement” lui-même est défectueux, c’est-à-dire si des bugs ou des problèmes sont identifiés dans le produit final, ces problèmes doivent être compris séparément. Dans ce cas, il n’est pas nécessaire de parler des “objectifs” et des “buts” de la gestion, mais plutôt de la cohérence entre le produit final et les fonctionnalités et spécifications requises. Par exemple, nous expliquons dans l’article suivant les mesures que l’utilisateur peut prendre si un défaut est découvert dans le système après coup.

https://monolith-law.jp/corporate/system-flaw-measure-after-acceptance[ja]

Il y a aussi des sujets connexes, comme le fait que certaines choses peuvent être reconnues comme ayant l’obligation d’être mises en œuvre à la discrétion du vendeur, même si elles ne sont pas incluses dans les exigences. Nous expliquons cela en détail dans l’article suivant.

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

Dans tous les cas, il convient de comprendre que les conflits autour des “objectifs” et des “buts” sont similaires mais différents.

Une compréhension fondamentale des thèmes tels que la responsabilité et le contrat est requise

Nous avons donc expliqué les problèmes juridiques liés aux “objectifs” et aux “cibles” du développement de systèmes. Dans les conflits concernant ces points, il est généralement admis que les tribunaux comprennent bien que les efforts de communication sont souvent partagés entre les utilisateurs et les fournisseurs afin de coordonner leurs actions. Cependant, même si la validité de la conclusion elle-même peut être pleinement comprise grâce à l’intuition pratique en tant que professionnel, une compréhension fondamentale des choses telles que la “responsabilité” et le “contrat” est requise dans le processus pour y parvenir. Nous expliquons ces points dans l’article ci-dessous.

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

Il est important de comprendre que la responsabilité légale est différente de la responsabilité morale vague, et que l’accord clair des “intentions” des deux parties est ce qui génère la responsabilité contractuelle. Il est important d’obtenir une compréhension plus essentielle en tenant compte de ces points.