Qu'est-ce que l'obligation de coopération imposée à l'utilisateur qui commande le développement de systèmes ?

Le travail de développement de systèmes nécessite un nombre important de personnes et d’heures de travail, surtout lorsque le système à développer est de grande envergure. Par conséquent, non seulement le fournisseur qui prend en charge le développement, mais aussi l’utilisateur qui commande le développement du système, ont une certaine obligation de coopération.

Ceci est différent de la relation habituelle entre le donneur d’ordre et le preneur d’ordre. Par exemple, lorsqu’un client (utilisateur) commande la création d’un costume sur mesure à un tailleur, il n’a pas de “devoir” particulier. Le “devoir” incombe principalement au tailleur (fournisseur). C’est précisément parce que le système informatique nécessite beaucoup de main-d’œuvre et de temps que l’utilisateur doit également “coopérer” avec le fournisseur.

Dans cet article, nous expliquerons quelles sont les obligations légales de l’ordonnateur dans le cadre du développement de systèmes, qui ne peut pas être laissé entièrement à la charge du fournisseur.

Il ne suffit pas de tout “déléguer” simplement parce qu’il s’agit de votre propre système

Même dans un seul projet de développement de système, il est courant que de nombreuses personnes et organisations soient impliquées. Il ne suffit pas d’avoir des ingénieurs et des programmeurs doués en codage, le rôle du chef de projet est également crucial pour rassembler les contributions de ces personnes en un seul résultat.

Cependant, même si le fournisseur possède une grande compétence technique et organisationnelle, le développement du système ne peut pas être accompli uniquement par les efforts du fournisseur. Par exemple, il n’y a aucun moyen pour le fournisseur de connaître des termes spécifiques utilisés uniquement à l’intérieur de l’entreprise ou des connaissances opérationnelles spécifiques à l’entreprise par ses propres efforts unilatéraux. Plus le système à développer est grand, plus il est probable que l’entreprise qui l’utilisera est une grande entreprise avec de nombreuses personnes et opérations. Pour mener à bien un projet de développement de système, il est souvent nécessaire de clarifier la logique commerciale avant même de commencer le travail informatique.

Par conséquent, au lieu de rester passif en disant “Je ne suis pas un expert en technologie de l’information”, le côté utilisateur peut en fait faciliter la progression du projet en fournissant activement des informations. En ce sens, le rôle que joue le côté utilisateur dans un projet de développement de système n’est en fait pas du tout mineur.

Qu’est-ce que l’obligation de coopération de l’utilisateur basée sur la jurisprudence ?

Alors concrètement, qu’est-ce que l’obligation de coopération de l’utilisateur dans un projet de développement de système ? De nombreux indices sur ce point sont laissés dans la jurisprudence passée.

Dans un procès, le retard de livraison du côté du fournisseur (défendeur) a été contesté, et l’existence d’une obligation de coopération de l’utilisateur dans le développement, en raison du retard dans la prise de décision de l’utilisateur (demandeur), a été un point de litige. Sur ce point, le tribunal a reconnu une violation de l’obligation de coopération de l’utilisateur et a nié la responsabilité du fournisseur pour non-exécution de l’obligation. (Bien que la résiliation du contrat ait été reconnue, une compensation de 60% pour la faute a également été reconnue.)

Dans le cas du contrat de développement de système informatique en question, qui est un contrat de développement de système sur mesure, il n’est pas possible pour le fournisseur (vendeur) seul de terminer le système. Par conséquent, le client (utilisateur) doit jouer un rôle dans le processus de développement, en coordonnant efficacement les opinions internes, en unifiant les points de vue, en communiquant clairement au fournisseur quelles fonctionnalités il souhaite, en examinant avec le fournisseur les fonctionnalités souhaitées, en décidant finalement des fonctionnalités, en décidant également des écrans et des formulaires, et en acceptant les produits finis.

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

Ce jugement, en plus d’indiquer que le développement du système lui-même est un travail conjoint avec l’utilisateur, donne des indications très suggestives sur le point de savoir “sur quels points spécifiques nous devrions coopérer”.

Essayons de traduire les termes du jugement ci-dessus en termes informatiques de développement de systèmes.

Nous pouvons organiser ces éléments de cette manière. Tous ces éléments ne peuvent pas être réalisés seuls, quelle que soit l’expertise du système informatique, sans la coopération de l’utilisateur. Les fonctionnalités requises et la disposition de l’écran sont fondamentalement des éléments que l’utilisateur doit clarifier, et seul l’utilisateur peut vérifier si ce qui a été demandé a été réalisé ou non.

De plus, tout comme l’obligation de gestion de projet est imposée au fournisseur, l’obligation de coopération est également imposée à l’utilisateur. Par conséquent, si l’utilisateur viole son obligation de coopération dans le processus ci-dessus, il est possible que le fournisseur puisse demander à l’utilisateur des dommages-intérêts pour non-exécution de l’obligation ou pour acte illicite.

Comment sont interprétées les demandes de modification des spécifications après coup ?

De plus, si l’on part du principe que le projet de développement de système est un travail conjoint entre l’utilisateur et le fournisseur, la discussion évolue vers un débat plus avancé. Il s’agit de la question de savoir qui est responsable lorsque, par exemple, l’utilisateur demande après coup l’ajout ou la modification de fonctionnalités, rendant difficile le respect des délais de livraison.

En général, le développement de systèmes commence par la définition des exigences, puis suit un ordre de conception de base, de conception détaillée, de fabrication (implémentation du programme) et de test, avec pour objectif d’éviter autant que possible les retours en arrière (ce que l’on appelle généralement le modèle en cascade). Cependant, il arrive souvent dans la réalité que des retours en arrière se produisent dans le processus pour diverses raisons, comme la découverte d’un défaut dans le processus précédent.

Comment devrions-nous envisager la situation si nous ne parvenons pas à respecter les délais dans de tels cas ? En interprétant les précédents jugements, il semble que la conclusion varie en fonction du moment où le travail supplémentaire est apparu.

Si le travail supplémentaire a eu lieu avant la clarification des spécifications de la conception externe, etc.

Le jugement précédent indique que si une demande de développement supplémentaire a été reçue de l’utilisateur pendant la conception de base (avant l’étape de mise en œuvre du programme), il n’est pas nécessairement considéré comme une violation de l’obligation de coopération de faire une telle demande.

Il est naturel que l’utilisateur fasse diverses demandes au fournisseur concernant le système à construire pendant le travail de conception de base, comme dans le cas présent, et de plus, il est difficile pour l’utilisateur, qui n’a pas de connaissances spécialisées, de juger correctement si ces demandes nécessitent des frais supplémentaires ou un report de la date de livraison, ou si elles entravent le processus de travail. Par conséquent, on ne peut pas dire que l’utilisateur aurait dû se retenir de faire des demandes qui entraînent des frais supplémentaires ou un report de la date de livraison. Au contraire, si l’utilisateur a fait des demandes qui nécessitent des frais supplémentaires ou un report de la date de livraison, le défendeur, qui a l’obligation de gérer le projet, aurait dû informer l’utilisateur de ce fait et demander des discussions sur le retrait de la demande ou le report de la date de livraison, afin d’éviter tout problème dans le travail de développement.

Jugement du tribunal de district de Tokyo du 10 mars 2004

Dans ce jugement, il a été indiqué que l’utilisateur a également une certaine obligation de coopération, mais qu’il faut tenir compte du fait que l’utilisateur n’est pas un expert en développement de systèmes. En d’autres termes, l’utilisateur qui passe la commande n’est pas un expert en développement de systèmes, donc il n’est pas surprenant qu’il fasse des commandes en petits morceaux jusqu’à ce que le contenu du système à développer soit clairement défini (il peut même ne pas être habitué à passer des commandes), et il est encore moins surprenant qu’il doive se rendre compte par lui-même que le contenu de la commande nécessite une révision des délais de livraison, etc.

Cependant, l’obligation imposée au fournisseur ici est essentiellement de faire des efforts de communication, comme demander un report de la date de livraison (ou, si la date de livraison ne peut pas être déplacée, de proposer de retirer la demande supplémentaire). Par conséquent, il ne faut pas comprendre que cela inclut l’obligation de livrer tout en acceptant toutes les demandes de l’utilisateur à la date initialement prévue. Il est donc important de faire attention à ce point.

Si le travail supplémentaire a eu lieu après la confirmation des spécifications de la phase de fabrication ou de test

Si l’on inverse le contenu du jugement ci-dessus, on peut prédire dans une certaine mesure quelle aurait été la conclusion si le développement supplémentaire avait eu lieu après la confirmation des spécifications. Dans ce cas, il serait plus difficile d’accepter de telles demandes. Certes, le niveau de compréhension du travail de développement diffère grandement entre l’utilisateur et le fournisseur, que les spécifications soient confirmées avant ou après.

Cependant, changer ou ajouter du contenu à la commande après la confirmation des spécifications est susceptible de forcer la répétition du travail. Il serait souvent difficile de défendre le fait que “c’est naturel pour un client de faire toutes sortes de demandes” dans le cas où un retard de livraison se produit même dans de telles circonstances. De plus, si de nombreux changements de spécifications et ajouts de fonctionnalités se produisent après coup, cela soulève la question de savoir s’il n’y avait pas déjà une violation de l’obligation de coopération de l’utilisateur dans les processus en amont, comme la conception de base, qui aurait dû être terminée avant.

De ce point de vue, il n’est pas réaliste de considérer que le fournisseur est responsable du retard de livraison causé par un changement de spécifications effectué après la confirmation de celles-ci. Il est raisonnable de lire le jugement précédent dans ce sens également.

De plus, ce jugement est souvent basé non seulement sur le contrat, mais aussi sur des procès-verbaux adaptés à l’avancement du développement du système.

En résumé : Il est essentiel de ne pas oublier que la définition des exigences est un processus du côté de l’utilisateur

La définition des exigences est certes une occasion pour le fournisseur de montrer son savoir-faire, mais il est important de garder à l’esprit qu’il s’agit avant tout d’une tâche du côté de l’utilisateur. Même si le système est développé avec l’aide d’experts externes, il est présumé en droit que la gouvernance de votre propre entreprise s’étend à ce domaine.

Si le côté utilisateur n’est pas coopératif dans le processus de développement, il faut être conscient que même si le projet échoue, le tribunal peut très bien adopter une position sévère à l’égard de l’utilisateur. Il est donc important de reconnaître ce point dès le départ.