Sur les problèmes juridiques associés à la base de données des systèmes IT

Lorsque vous cherchez à comprendre les problèmes juridiques liés aux systèmes informatiques, il est nécessaire d’avoir une connaissance systématique du droit. Cependant, il est également important de comprendre les composants d’un système informatique. Dans cet article, nous allons expliquer comment les systèmes informatiques sont constitués de différentes pièces, comment ces pièces interagissent pour fonctionner, et nous allons discuter des problèmes juridiques particulièrement liés aux bases de données, qui sont souvent difficiles à percevoir du côté de l’utilisateur.

Un système IT est composé d’une “interface” et d’une “logique”

Qu’est-ce que l'”interface” d’un système IT ?

Lorsque l’on cherche à comprendre la structure d’un système IT, ce qui saute le plus aux yeux est l’apparence de l’interface. En effet, dans le processus de développement de systèmes typiques, après la définition des exigences, où l’on identifie les fonctionnalités, vient généralement la conception de l’interface et l’organisation de la navigation. Ces aspects visibles de l’interface sont naturellement remarqués par les utilisateurs qui commandent le développement du système, et c’est aussi le domaine où la communication entre l’utilisateur et le fournisseur est la plus active. Dans l’article ci-dessous, nous expliquons l’obligation de coopération que l’utilisateur doit au fournisseur pour atteindre les objectifs du projet tout au long du processus de développement du système.

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

Cet article explique principalement que l’utilisateur a une obligation de coopération dans le développement du système, notamment lors de la phase de conception de base (c’est-à-dire l’interface), où il doit travailler en collaboration avec le fournisseur.

L'”interface” d’un système IT est généralement décrite en respectant les règles des langages informatiques tels que HTML et CSS. Lorsque l’on parle de l'”interface” d’un système IT, on utilise divers termes tels que “front-end”, “UI (User Interface)”, etc., mais le principal point de discussion est la “facilité d’utilisation” et la “lisibilité” du point de vue de l’utilisateur.

Qu’est-ce que la “logique” d’un système IT ?

Cependant, si un système IT est basé uniquement sur une “interface”, il ne serait qu’une simple “interface” sans aucune “action” ou “changement”. Même si l’interface est utilisée pour recevoir les entrées de l’utilisateur et afficher les sorties, ce processus implique des “calculs”.

Ces calculs et contrôles complexes sont effectués par des composants qui sont, pour ainsi dire, “derrière” le système et qui ne sont pas visibles par l’utilisateur. Les opérations telles que la recherche de données à partir de l’interface, la modification des données, l’ajout ou la suppression de données ne sont possibles que grâce à une base de données préalablement construite. Les différentes opérations sur les informations de la base de données sont généralement effectuées avec un langage informatique appelé SQL.

Le fait de créer un chemin depuis un bouton ou autre élément placé sur l’interface jusqu’à l’exécution de la requête SQL nécessaire permet de compléter l’image globale d’un système doté de mouvements et de changements.

Notez que les discussions concernant l’assemblage de diverses logiques qui ne sont pas visibles depuis l'”interface” sont parfois appelées “back-end”.

Le risque de ne discuter que de l’aspect « visuel » d’un système

Les explications jusqu’à présent constituent la base de la structure d’un système IT (prévu pour fonctionner sur le web). La compréhension de ces questions a une grande importance pour les discussions juridiques, la prévention des conflits de projets, la gestion des crises, etc. Plus précisément, il est possible que des malentendus surviennent entre les utilisateurs qui se concentrent uniquement sur l’aspect « visuel » à l’écran et les fournisseurs qui gèrent de nombreuses tâches importantes du côté « logique » invisible.

Le risque que les points d’intérêt des utilisateurs et des fournisseurs soient complètement différents

Par exemple, les utilisateurs qui parlent principalement de l’aspect « écran » d’un système IT ont tendance à être indifférents à la complexité de sa structure interne. C’est pourquoi ils peuvent ne pas comprendre à quel point une « petite addition de fonctionnalité » ou un « léger changement de spécification » peut affecter de nombreux processus. L’article suivant explique les problèmes juridiques courants lors de la suppression d’un système existant dans le cadre d’un projet de développement d’un nouveau système.

https://monolith-law.jp/corporate/the-transition-from-the-oldsystem[ja]

Ici, nous expliquons que des problèmes surviennent souvent lors de la migration des données vers un nouveau système lors de la suppression de l’ancien système. En d’autres termes, la complexité des mécanismes de calcul et de contrôle internes, qui sont inimaginables à partir de l’apparence, peut être une source de problèmes inattendus pour les utilisateurs. De plus, si les utilisateurs ne comprennent pas les sentiments des fournisseurs qui créent le système, il est possible que des modifications soient apportées progressivement après coup.

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

En prévision de tels cas où des modifications de spécifications ou des ajouts de fonctionnalités sont ordonnés après coup, la question de savoir s’il est possible d’augmenter la rémunération après coup peut parfois devenir un problème sérieux.

https://monolith-law.jp/corporate/increase-of-estimate[ja]

Le risque que les utilisateurs soient indifférents à la « logique » en arrière-plan

De plus, il arrive souvent que les parties qui ne peuvent pas être observées par les utilisateurs deviennent de grands incidents lorsqu’un problème est découvert. Voici un exemple.

Risque de problèmes en matière de maintenance et de sécurité

Cela inclut des situations où il est impossible d’implémenter des fonctionnalités supplémentaires, où le système devient progressivement plus lent à utiliser et finit par cesser de fonctionner.

Il existe également une technique d’attaque de sécurité appelée « injection SQL », qui exploite les failles du code implémenté du côté de l’écran pour extraire des informations personnelles et confidentielles qui ne devraient pas être affichées à l’écran. L’article suivant traite en détail d’un cas qui a dégénéré en un conflit grave à la suite de cette attaque.

https://monolith-law.jp/corporate/risks-of-libraryuse-and-measures[ja]

Le thème principal de cet article est le risque associé à l’utilisation de frameworks et de bibliothèques, mais l’exemple de jugement présenté concerne une attaque exploitant une vulnérabilité à l’aide d’une injection SQL.

Risque que la gouvernance ne s’étende pas au travail des opérateurs

Le fait que les utilisateurs d’un système IT soient indifférents à la « logique » en arrière-plan peut également conduire à un problème où il est difficile d’étendre la gouvernance au travail des opérateurs du système. L’article suivant traite de l’importance du travail impliquant des bases de données sur le thème de la « perte de données due à la négligence de l’opérateur ».

https://monolith-law.jp/corporate/dataloss-risk-and-measures[ja]

Risque que la logique soit incorrecte même si le système semble fonctionner correctement

Le fait que la discussion sur le système ne se limite pas à l’« écran » signifie qu’il est possible que la « logique » soit incorrecte même si le système semble fonctionner correctement en surface. Cela peut être révélé de manière inattendue lors de tâches irrégulières telles que « une fois tous les six mois » ou « une fois par an », même si cela n’est pas évident dans les tâches quotidiennes de base.

Dans de tels cas, il s’agit d’un problème de responsabilité pour les défauts (et non d’inexécution de l’obligation) en droit, en ce qui concerne un système qui a été livré une fois et où des défauts ont été découverts après coup.

https://monolith-law.jp/corporate/defect-warranty-liability[ja]

Si un défaut est découvert après l’acceptation, les mesures à prendre sont expliquées en détail dans l’article suivant.

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

Résumé

Comprendre systématiquement le développement de systèmes et les affaires juridiques

Il est important de comprendre quel composant du système IT est à l’origine du problème pour identifier les points de discussion juridiques liés au développement de systèmes. Que ce soit un problème juridique ou un problème de système IT, dans les conflits qui surviennent lors des projets de développement de systèmes, il est particulièrement important de ne pas perdre de vue l’image globale et de faire tout son possible pour collaborer entre différents secteurs.