Jusqu'à quel point devrait-on mettre en œuvre des fonctionnalités non spécifiées dans les spécifications de développement de systèmes en termes juridiques?

En principe, les projets de développement de systèmes informatiques utilisés dans les entreprises sont créés conformément à des spécifications prédéfinies. Cependant, si l’on considère que le fournisseur est entièrement chargé du développement en tant qu’expert en développement de systèmes, les attentes du côté utilisateur pourraient ne pas être aussi basses que de simplement mettre en œuvre mécaniquement ce qui est écrit dans les spécifications. Dans cet article, nous discuterons de la question de savoir jusqu’où l’on doit assumer l’obligation de mettre en œuvre un programme qui, bien qu’il ne soit pas mentionné dans les spécifications, doit être mis en œuvre à la lumière de l’objectif du développement.

Problèmes juridiques liés à la mise en œuvre de choses non spécifiées

La discrétion est requise dans les tâches du fournisseur

Une des grandes caractéristiques des contrats liés à un projet de développement de système et des divers problèmes juridiques qui y sont associés est que le fournisseur qui accepte le travail a une grande discrétion.

Article connexe : Qu’est-ce que l’obligation de gestion de projet dans le développement de systèmes ?[ja]

Cependant, la “discrétion” dont nous parlons ici ne s’applique pas nécessairement à toutes les étapes du développement du système. Après avoir identifié chaque étape et avancé dans le détail des tâches, il peut y avoir beaucoup de travail qui ressemble à un travail simple. Cependant, en général, plus on avance dans les tâches en amont, plus il devient difficile d’exécuter le travail sans une grande discrétion. C’est aussi pour cette raison que les contrats de quasi-mandat sont souvent bien adaptés aux tâches en amont.

Article connexe : La distinction et la différence entre les contrats d’entreprise et les contrats de quasi-mandat dans le développement de systèmes[ja]

La discrétion doit également être exercée dans un processus de développement strict

Cependant, même si le fournisseur qui développe le système a une grande discrétion, accepter les demandes du client de manière “informelle” peut causer d’énormes dommages aux étapes ultérieures. Un système informatique est constitué d’un ensemble de petites pièces, donc même un changement mineur en apparence peut nécessiter un changement significatif dans le temps de travail du côté du développeur. En outre, il existe des articles qui expliquent comment gérer les changements de spécifications dans le développement de systèmes d’un point de vue juridique. L’article ci-dessous explique comment gérer les changements, mais il discute également de l’impact considérable que les changements de spécifications peuvent avoir sur le travail du point de vue de l’ingénieur.

Article connexe : Qu’est-ce que la gestion des changements dans le développement de systèmes d’un point de vue juridique ?[ja]

Que faut-il faire en tant qu’expert, sans être limité par les spécifications ?

Pour mener à bien un projet de développement de système, il est important de définir les exigences de développement à l’avance et de progresser de manière planifiée en fonction de celles-ci. D’un autre côté, il y a des situations où vous ne pouvez pas remplir pleinement votre rôle en tant qu’expert en développement de systèmes si vous vous contentez de faire ce qu’on vous dit en fonction des exigences définies à l’avance. C’est dans ce dilemme que le problème de “ce qui n’est pas indiqué dans les spécifications, mais doit être mis en œuvre” devient apparent.

Les obligations légales sont déterminées en fonction de l'”esprit” des spécifications et des contrats

Le contenu de ce qui doit être mis en œuvre, même s’il n’est pas mentionné dans les contrats ou les spécifications, est toujours déterminé par l'”esprit” de ces contrats et spécifications, c’est-à-dire, “quelle signification ou intention a conduit à cet accord”. Examinons quelques exemples de jurisprudence ci-dessous.

Exemple de jugement où l’obligation de mise en œuvre a été niée en raison de l’absence de mention

Dans l’exemple de jugement cité ci-dessous, un conflit a éclaté lorsque le système développé par le vendeur a atteint le stade de fonctionnement provisoire, mais il a été demandé de résilier le contrat car les fonctionnalités nécessaires étaient insuffisantes. L’utilisateur a soutenu que la “fonction de mise à jour automatique des données” était insuffisante, et il a été soutenu que c’était un point de vente clé du système en question, mais le tribunal n’a pas reconnu cette obligation de mise en œuvre.

Comme reconnu ci-dessus, il n’y a aucune mention dans le contrat en question, le document de conception de base et le document de conception détaillée qui indique que la fonction ③ est l’objet du développement du système en question.

Le demandeur soutient que la fonction ③ était un point de vente clé du système en question pour le défendeur, et souligne la nécessité de cette fonction, mais si son argument est correct, cela devrait être clairement indiqué dans le contrat en question, etc., et il est difficile de penser que le développement de cette fonction a été convenu en l’absence de cela.

Jugement du tribunal de district de Tokyo, 18 février 2009 (Heisei 21)

Certainement, si l’on ne prend que la conclusion de ce jugement, on pourrait dire que “si ce n’est pas mentionné dans le document de conception, il n’est pas nécessaire de créer ce qui n’existe pas”. Cependant, pour être plus précis, il ne s’agit pas d’un fait formel comme si c’était mentionné dans le document de conception, mais plutôt d’un jugement basé sur “l’intention” de la mention dans le document de conception/contrat. En d’autres termes, “si l’on considère la raison pour laquelle il n’a pas été mentionné dans le document de conception ou le contrat, il est raisonnable de penser qu’il n’y avait pas non plus d’accord correspondant à cette mention”.

Exemples de jugements affirmant l’obligation de mise en œuvre même en l’absence de mention

D’un autre côté, il existe des cas de jurisprudence qui ont affirmé l’obligation de mise en œuvre même si elle n’était pas mentionnée dans le contrat ou le cahier des charges. L’exemple de jugement cité ci-dessous concerne le développement d’un système pour gérer l’historique de la prise de médicaments. L’utilisateur a résilié le contrat car il n’a pas pu transférer les données de l’ancien système vers le nouveau système, et n’a donc pas pu utiliser le nouveau système. Cependant, le vendeur a contesté, affirmant que le transfert de données n’était pas dans le champ de ses responsabilités.

Le développement d’un nouveau système implique souvent l’abandon de l’ancien système et le transfert des données. Nous avons expliqué en détail l’importance de ces tâches et les problèmes juridiques qui y sont associés dans l’article ci-dessous.

Article connexe : Problèmes juridiques liés à la transition depuis l’ancien système dans le développement de systèmes[ja]

Plus de 50 000 données de patients étaient déjà stockées dans l’ancien système, et le plaignant utilisait ces données pour améliorer l’efficacité de son travail. Il est évident que si les données des patients ne peuvent pas être transférées du système existant au système en question, cela causera des problèmes dans la dispensation des médicaments en pharmacie, et il est présumé que le représentant du plaignant était bien conscient de cela. De plus, avant la conclusion du contrat en question, le représentant du plaignant a posé des questions au représentant du défendeur sur la possibilité de transférer les données, ce que le représentant du défendeur reconnaît également (omis), et il est difficile de penser que le représentant du plaignant a décidé d’introduire le système en question tout en reconnaissant qu’il y avait une forte probabilité qu’il devrait entrer manuellement les données de plus de 50 000 patients. De plus, comme indiqué ci-dessus (1) (i), le défendeur n’a pas pu transférer les données de l’historique des médicaments du système existant au système en question, et a donc imprimé ces données sur papier et les a intégrées dans un fichier PDF, etc. Il est difficile de penser que le défendeur a effectué ce travail laborieux en tant que service, même si le transfert de données n’était pas prévu dans le contrat en question.

Jugement du tribunal de district de Tokyo, 18 novembre 2010 (Heisei 22)

Ce qui est important ici aussi, c’est l’objectif du contrat et l'”intention” des clauses du contrat. Si les deux parties ont conclu le contrat en reconnaissant que le transfert de données n’était pas dans le champ de leurs responsabilités, le tribunal a souligné que cela signifierait que l’utilisateur et le vendeur ont conclu le contrat avec une intention anormale. En d’autres termes, l’utilisateur aurait accepté un énorme volume de travail manuel, et le vendeur aurait abordé le projet en sachant qu’il causerait des problèmes dans le travail de l’utilisateur à l’avenir, ce qui serait une histoire très irrationnelle.

Ce que nous pouvons comprendre des deux jugements

En ce qui concerne la migration des données, même si elle n’est pas mentionnée dans le contrat ou le cahier des charges, l’obligation de mise en œuvre a été affirmée. Cela est probablement dû en partie au fait qu’il s’agissait d’une question concernant les “données”, qui ne sont pas visibles à l’écran. Le “manque de fonctionnalités essentielles” mentionné précédemment est quelque chose qui apparaît directement sur l’écran du système. Par conséquent, même pour un novice en développement de systèmes, il n’est pas très difficile de détecter une omission dans le cahier des charges. En revanche, le problème de la migration des données a la particularité d’être difficile à comprendre pour un novice en développement de systèmes, en termes d’importance du processus, de difficulté de la tâche et de temps nécessaire. Par conséquent, il est probable qu’il y avait aussi une situation où il était facile de traiter cela comme une question que le fournisseur devrait gérer en douceur avec son expertise.

Si l’on considère cela, l’omission dans le cahier des charges ou le contrat est également étroitement liée à l'”obligation de coopération” de l’utilisateur. En d’autres termes, il s’agit de la question de savoir si l’utilisateur a vraiment “rempli son obligation de coopération” en vue de la conclusion du contrat et de la rédaction du cahier des charges. Pour une explication générale des obligations légales que l’utilisateur doit remplir dans un projet de développement de système, veuillez consulter l’article ci-dessous.

Article connexe : Quelle est l’obligation de coopération de l’utilisateur, qui est le commanditaire du développement du système ?[ja]

Si vous vérifiez également l’article ci-dessus, vous comprendrez naturellement que la demande de coopération de l’utilisateur, comme l’identification des écrans et des fonctionnalités essentielles, est importante, et que l’omission de considérer la migration des données est une question très différente.

Comment devrions-nous considérer la rémunération pour le développement non spécifié dans le cahier des charges ?

Une autre question qui pourrait vous intéresser en relation avec le sujet de cet article est de savoir si, en cas de création de quelque chose qui n’est pas spécifié dans le cahier des charges, il est légalement possible de demander une rémunération supplémentaire. Nous expliquons en détail dans l’article ci-dessous la question de savoir si une augmentation de la rémunération est possible et, si oui, comment calculer le montant de l’estimation.

Article connexe : Est-il possible d’augmenter le montant estimé après le développement du système ?[ja]

Dans l’article ci-dessus, nous expliquons qu’il est important de déterminer s’il y a eu des tâches qui dépassent le champ d’application du travail en relation avec la rémunération. En d’autres termes, en relation avec cet article, si le fournisseur accepte de développer quelque chose qui n’est pas inclus dans les spécifications initiales (dans cet article, l’exemple négatif), il est possible d’accepter une demande de rémunération supplémentaire.

Résumé

Dans le développement de systèmes, le rôle que le fournisseur doit jouer est déterminé, d’une part, en fonction du contenu du contrat et du cahier des charges. Cependant, compte tenu du fait qu’ils sont confiés avec une grande confiance en tant qu’experts, il est clair que leur réalité n’est pas déterminée uniquement par la forme. Néanmoins, pour comprendre cette réalité, il est important de comprendre que le droit joue un rôle majeur.