Quels sont les problèmes juridiques liés au serveur et à l'infrastructure de développement de systèmes ?

Les systèmes informatiques utilisés dans les entreprises sont, en un sens, créés en rédigeant des spécifications et des plans, et en écrivant du code source correspondant à ces contenus. Cependant, un système ne fonctionne réellement que s’il y a non seulement cet aspect logiciel, mais aussi un ordinateur physique, c’est-à-dire une infrastructure. Dans cet article, nous allons discuter des problèmes juridiques étroitement liés au domaine de l’infrastructure dans les projets de développement de systèmes.

Qu’est-ce que l’infrastructure dans un système informatique ?

Les techniciens qui développent des systèmes sont appelés ingénieurs systèmes (SE). Et un projet de développement commence par les étapes en amont, comme la création de cahiers des charges et de plans, et se poursuit par la mise en œuvre du programme et la réalisation de tests. C’est le flux général. Cependant, on peut dire qu’un ingénieur système (SE) au sens large est un technicien qui assume toutes les tâches nécessaires à ces processus, mais selon l’entreprise ou le lieu de travail, les tâches et les domaines de responsabilité peuvent être encore plus précisément distingués par des noms différents. Le terme “ingénieur infrastructure” désigne un technicien qui, dans le cadre des tâches liées au développement et à l’exploitation des systèmes informatiques, est particulièrement chargé de préparer l’environnement de fonctionnement physique de l’ordinateur. Les systèmes informatiques utilisés dans les entreprises et les lieux de travail sont, en un sens, des constructions abstraites composées de combinaisons de codes sources. Cependant, pour que ces systèmes remplissent le rôle qui leur est initialement attribué, il est indispensable de construire un environnement autour de l’infrastructure, y compris les serveurs et les réseaux. La pratique du développement de systèmes progresse sur deux fronts : la mise en œuvre du code source du programme et la préparation de l’environnement autour de l’infrastructure qui soutient cet environnement de fonctionnement. Il est considéré comme important d’avoir ce point de vue pour prévenir l’apparition de problèmes imprévus.

Scénarios concrets où les problèmes d’infrastructure peuvent mettre un projet en péril

Dans les projets de développement de systèmes, il peut arriver que l’on se concentre uniquement sur la conception de programmes abstraits et de codes sources, en négligeant l’aspect de la maintenance de l’infrastructure. Cependant, une situation où ces deux éléments ne sont pas en phase peut parfois entraîner un risque de défaillance du projet.

Comment une erreur de dimensionnement du serveur peut provoquer un conflit

Par exemple, il est possible qu’après la fin de l’implémentation du programme et des tests, on découvre finalement que la capacité de traitement du serveur est insuffisante et que le système n’est pas utilisable en pratique. Il est à noter que l’anticipation de la charge que le système peut subir lors de son exploitation et la mise en place d’une infrastructure adaptée à la taille du système est appelée “dimensionnement”. Des cas où une erreur de dimensionnement du serveur a conduit à des problèmes ont effectivement eu lieu dans le passé. (Bien que résolus par un accord à l’amiable, vous pouvez vous référer à ce cas célèbre.) Pour plus d’informations sur la résolution des conflits entre les deux parties par le biais d’un “accord”, veuillez consulter l’article ci-dessous.

https://monolith-law.jp/corporate/disputes-related-to-system-development[ja]

Le fait que le conflit ait été résolu par un accord signifie simplement que le conflit a été résolu par des “discussions” entre les deux parties. Par conséquent, contrairement à un jugement rendu par un tribunal, le contenu de cet accord n’est pas accumulé comme un précédent judiciaire, mais est généralement très spécifique.

L’essence du problème est la portée de l’obligation du fournisseur de répondre à des spécifications ambiguës

Cependant, on peut penser que l’essence de ces conflits est la question de savoir “jusqu’où le fournisseur doit-il assumer la responsabilité des éléments qui ne sont pas explicitement spécifiés dans les spécifications”. En tenant compte de ce point, vous pouvez obtenir de nombreux indices à partir du contenu de l’article ci-dessous.

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

Dans l’article ci-dessus, nous expliquons jusqu’où le fournisseur doit exercer son pouvoir discrétionnaire et assumer l’obligation de mise en œuvre pour les éléments qui ne sont pas mentionnés dans les spécifications. Ici, nous expliquons que l’histoire est très différente entre les éléments “côté écran” qui peuvent être facilement visualisés dans des documents tels que les spécifications des exigences et les plans de conception de base (c’est-à-dire le domaine “front-end”) et les “côté logique” tels que la migration des données (c’est-à-dire le domaine “back-end”, “base de données”). En d’autres termes, il est probable que le client/utilisateur, qui n’a généralement pas de connaissances spécialisées sur le projet de développement de système, sera plus facilement tenu responsable des problèmes de spécifications qui peuvent être facilement vérifiés du “côté écran”. D’autre part, il est probable que les problèmes du “côté logique” seront plus facilement attribués au fournisseur. En tenant compte de ces points, on peut penser que les problèmes de dimensionnement du serveur sont principalement dans un domaine où il est difficile de reconnaître l’emplacement du problème sans être un expert en technologie, et qu’ils sont donc plus susceptibles d’être attribués au fournisseur. Par conséquent, si vous devez vraiment contester ce point devant un tribunal, à moins qu’il n’y ait des circonstances actives pour exonérer le fournisseur de sa responsabilité, il est prévisible que le jugement sera souvent défavorable au fournisseur.

Mesures pour prévenir les problèmes dus à des erreurs de dimensionnement des serveurs

Pour prévenir les problèmes mentionnés précédemment, il est important de coordonner les tâches telles que l’implémentation du programme et la rédaction du code source avec la préparation de l’environnement autour de l’infrastructure. Les mesures spécifiques qui peuvent être envisagées sont les suivantes :

Clarifier la responsabilité du dimensionnement des serveurs dans le contrat

Non seulement dans ces cas, mais aussi dans de nombreux litiges liés aux projets de développement de systèmes, on constate souvent que les rôles n’étaient pas clairement définis entre le fournisseur, expert en développement de systèmes, et l’utilisateur, qui connaît bien la situation interne de l’entreprise. Il va sans dire qu’une étroite collaboration entre les deux parties est nécessaire pour le bon déroulement du projet, mais il est souhaitable de clarifier autant que possible les rôles et les responsabilités dans le contrat à l’avance.

Concrétiser les exigences de développement et gérer parfaitement les changements

De plus, si les exigences fonctionnelles à réaliser sont vagues, le risque de conflit augmente. Cela concerne à la fois la clarification des spécifications lors de la phase de définition des exigences initiales et la gestion des changements en cours de projet. Pour savoir comment gérer les changements de spécifications en cours de projet, veuillez consulter l’article ci-dessous.

https://monolith-law.jp/corporate/howto-manage-change-in-system-development[ja]

Choisir un modèle de développement adapté à la nature du projet

En outre, en relation étroite avec les deux points de mesure mentionnés ci-dessus, il est important de choisir un modèle de développement approprié en fonction de la nature et de l’échelle du projet de développement de système. En général, pour le développement de systèmes d’une certaine taille où le dimensionnement des serveurs peut devenir important, il est considéré comme bénéfique d’adopter le modèle en cascade, qui est adapté pour clarifier les spécifications et les responsabilités. Pour plus de détails sur la sélection d’un modèle de développement approprié en fonction de la nature du projet, veuillez consulter l’article ci-dessous.

https://monolith-law.jp/corporate/legal-merits-and-demerits-of-development-model[ja]

Résumé

Les problèmes qui émergent de la préparation de l’environnement autour de l’infrastructure pour le bon déroulement d’un projet de développement de système sont souvent négligés. Il est compréhensible que la surveillance des problèmes d’infrastructure puisse être une charge non négligeable pour ceux qui ne sont pas des experts en technologie. Cependant, les mesures préventives contre ces problèmes peuvent être considérées comme une extension de mesures de base telles que “la clarification des spécifications / la gestion rigoureuse des changements”, “la clarification des rôles / des domaines de responsabilité”, et “la sélection d’un modèle de développement adapté à l’échelle et au budget du projet”. Ce que ceux qui travaillent dans le droit des affaires devraient comprendre en premier lieu, c’est que les principes de base de la prévention juridique peuvent être pleinement appliqués aux problèmes d’infrastructure. De plus, pour les ingénieurs en informatique, il est important de comprendre que les problèmes d’infrastructure peuvent devenir un risque sérieux pour le projet et de gérer efficacement leurs tâches.