Problèmes juridiques liés à la transition depuis l'ancien système dans le développement de systèmes

Créer un nouveau système informatique pour une entreprise est une tâche typique d’un ingénieur en informatique. Cependant, lorsqu’on parle de “créer un nouveau système”, cela implique souvent également le processus de “suppression de l’ancien système”. Dans cet article, nous allons reconsidérer le projet de développement d’un nouveau système du point de vue de la “suppression de l’ancien système” et expliquer les divers problèmes juridiques qui y sont associés.

Qu’est-ce que cela signifie de passer à un nouveau système ?

La durée de vie d’un système informatique n’est pas éternelle

Un système informatique utilisé dans une entreprise n’est pas quelque chose qui, une fois créé, peut être utilisé indéfiniment. De plus, il n’est pas toujours bon de continuer à utiliser précieusement quelque chose d’ancien. Bien qu’il y ait naturellement des variations selon l’entreprise et l’utilisation du système, en règle générale, une décision de gestion est souvent prise pour remplacer un système par quelque chose de nouveau après environ dix ans d’utilisation continue.

En dix ans, les performances des ordinateurs disponibles sur le marché peuvent changer considérablement. Par exemple, un programme qui n’était pas réalisable en raison de contraintes telles que la vitesse de traitement de l’ordinateur il y a dix ans (bien qu’il soit simple et bien conçu du point de vue humain) peut maintenant être mis en œuvre. De plus, si vous avez continué à utiliser un système pendant dix ans depuis sa création, le flux de travail de l’entreprise et les règles internes peuvent avoir beaucoup changé pendant cette période. Le code qui a été mis en œuvre après coup pour répondre à ces changements dans l’environnement de gestion interne et externe de l’entreprise peut avoir une structure complexe et enchevêtrée qui n’est pas reconnaissable depuis l’écran. Dans ce cas, même si l’utilisateur veut ajouter une fonction, il se peut que la situation devienne telle que l’ajout d’une mise en œuvre est désormais impossible du point de vue du développeur.

Un système obsolète peut progressivement générer beaucoup de “travail manuel” pour les ingénieurs informatiques (par exemple, l’émission de requêtes pour extraire des données individuellement). Ironiquement, le système lui-même, en vieillissant, tend à “personnaliser” le travail. Lorsqu’on tente de mettre en place des mesures de “systématisation” pour les tâches liées au système qui sont devenues trop anciennes et personnalisées, un projet de “développement d’un nouveau système pour la transition à partir de l’ancien système” est mis en place.

Le développement du nouveau système progresse avec l’abolition de l’ancien système

Comme mentionné précédemment, bien que tous les projets de développement de systèmes ne soient pas ainsi, un projet de développement de système comporte souvent l’aspect de la transition de l’ancien système. Le système lui-même change souvent de manière discontinue à partir d’un certain jour.

Cependant, la progression du travail quotidien doit être continue du passé au présent, et du présent à l’avenir. Tout en conservant les données passées nécessaires, sans entraver la progression du travail actuel, et en proposant des concepts de “systémisation” supérieurs pour l’avenir, il y a souvent de nombreux défis associés à la transition vers le nouveau système. En raison de ces circonstances combinées, le développement du nouveau système et les opérations et la maintenance du système existant sont complexement liés, et il peut y avoir des cas où ils deviennent indissociables.

Quels sont les étapes de transition vers un nouveau système ?

Lors de la transition d’un système existant à un nouveau système, il est particulièrement important de transférer correctement les données. Les étapes de transfert de données suivent généralement la procédure suivante :

1. Clarifier quels sont les données stockées par l’ancien système qui doivent être transférées vers le nouveau système → Il est nécessaire de distinguer quelles sont les données qui doivent être facilement recherchables depuis l’écran du nouveau système, et quelles sont les données qui n’ont pas besoin d’être recherchables depuis l’écran (par exemple, pour des audits), mais qui doivent être disponibles si nécessaire.
2. Exporter les données identifiées à l’étape 1, qui doivent être importées dans le nouveau système, sous forme de fichier CSV ou similaire.
3. Importer les données extraites à l’étape 2 dans le nouveau système.
4. Vérifier si les données importées à l’étape 3 sont reflétées dans le nouveau système, et confirmer si la transition a été correctement effectuée. → Les résultats de la vérification de la transition correcte sont généralement conservés comme preuves par l’affichage sur l’écran ou l’impression de documents (le soi-disant processus de test).

La transition vers un nouveau système est difficile en termes de clarification des rôles des utilisateurs et des fournisseurs

Dans les étapes de migration de données mentionnées précédemment, le problème qui se pose souvent est de savoir jusqu’à quel point les utilisateurs doivent considérer cela comme un problème interne à leur entreprise et le gérer en conséquence. Pour une explication générale de l’obligation de coopération des utilisateurs dans les projets de développement de systèmes en général, pas seulement en matière de migration de données, veuillez consulter l’article ci-dessous.

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

En général, dans un projet de développement de système, il est vrai que le fournisseur est souvent supérieur à l’utilisateur en termes de savoir-faire spécialisé pour le développement de système (ou plutôt, c’est souvent la raison pour laquelle il est chargé de cette tâche). Cependant, d’un autre côté, il est souvent le cas que seul l’utilisateur peut discuter de ce que devrait être son système.

Compte tenu de ces points, on pourrait envisager une clarification des rôles où l’utilisateur effectue les étapes 1 et 4 mentionnées précédemment. Pour le dire autrement, lors de la migration de données, la “définition des exigences” des données à migrer et l'”acceptation” de savoir si les données ont été migrées conformément aux exigences pourraient être considérées comme des obligations de coopération de l’utilisateur. Ou, comme autre façon de clarifier, si l’utilisateur a une personne avec une connaissance approfondie du système ancien, il pourrait être envisagé de faire de cette personne l’utilisateur responsable de l’étape 2.

Si l’on peut gérer l’ancien système en interne sans avoir à externaliser, on pourrait envisager de passer commande en pensant à externaliser uniquement le nouveau système au fournisseur. De cette manière, dans le travail de migration de données, la clarification des rôles entre l’utilisateur et le fournisseur peut parfois devenir floue. Pour une explication générale sur les rôles attendus du fournisseur et les obligations légales qui lui incombent lorsque l’utilisateur externalise les travaux liés au développement de systèmes au fournisseur, veuillez également consulter l’article ci-dessous.

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

Précédents judiciaires liés à la transition vers un nouveau système

Il existe des cas réels où des problèmes sont survenus lors de projets de développement de systèmes visant à passer à un nouveau système, conduisant à des litiges. Le cas cité dans le jugement ci-dessous concerne un échec lors de la migration des données, entraînant plusieurs incohérences et bugs dans le nouveau système, ainsi que des retards dans les délais de livraison. Les divers problèmes ont soulevé la question des obligations respectives du fournisseur et de l’utilisateur envers le projet. En conclusion, le tribunal a déterminé que le fournisseur avait manqué à son devoir de diligence, comme indiqué ci-dessous.

Le défendeur, dans le cadre de ses obligations contractuelles de migration de données, avait non seulement pour tâche de simplement transférer les données de l’ancien système vers le nouveau, mais aussi de faire fonctionner le nouveau système avec les données transférées. Plus précisément, avant de commencer la migration des données, il devait enquêter et analyser les données à migrer sur l’ancien système, comprendre la nature et l’état des données, examiner si ces données pourraient entraver le fonctionnement du nouveau système une fois transférées, et si c’était le cas, décider quand et comment corriger ces données. Ensuite, il devait entreprendre la migration des données (conception de la migration, développement d’outils de migration, migration des données), et finalement, il avait l’obligation de faire fonctionner le nouveau système avec les données transférées de l’ancien système.

Il est juste de reconnaître que dans ce cas, lors de la migration des données, il avait l’obligation de corriger et de résoudre les incohérences de données.

Jugement du tribunal de district de Tokyo, 30 novembre 2016 (Heisei 28)

Ce cas impliquait que l’utilisateur prenait en charge les étapes 1 et 4, tandis que le fournisseur prenait en charge les étapes 2 et 3. En d’autres termes, le fournisseur avait accepté d’extraire les données de l’ancien système une fois. Par conséquent, le tribunal a jugé que si le fournisseur avait accepté d’extraire les données, il aurait dû être en mesure d’examiner à l’avance si cette extraction de données pourrait se dérouler sans encombre.

Cependant, que se serait-il passé si l’étape 2 (c’est-à-dire l’extraction des données) avait été définie comme une tâche de l’utilisateur lors de la répartition initiale des rôles, et que l’extraction des données avait échoué dans ce contexte ? Dans ce cas, il est possible que l’utilisateur, ayant négligé d’enquêter à l’avance sur la possibilité d’une extraction de données sans encombre, aurait pu être accusé d’avoir violé son obligation de coopération, entraînant un retard dans les délais de livraison.

De plus, ces jugements sont basés non seulement sur le contrat, mais aussi sur des preuves telles que les procès-verbaux adaptés à l’avancement du développement du système. L’importance des procès-verbaux est expliquée en détail dans l’article ci-dessous.

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

Résumé

Un projet de développement de système implique que les utilisateurs et les fournisseurs assument mutuellement de nombreuses obligations et avancent en communiquant minutieusement. Par conséquent, même dans les cas de jurisprudence mentionnés précédemment, avec seulement de légères variations dans les conditions préalables, la responsabilité peut facilement basculer entre l’utilisateur et le fournisseur.

Étant donné la possibilité qu’un système puisse contenir une quantité énorme de données et une structure complexe qui ne peuvent être imaginées à partir de l’apparence de l’écran, et que la direction finale du jugement judiciaire peut changer considérablement en raison de légères différences dans les prémisses, il est important de considérer de manière globale la gestion des risques du projet de développement du nouveau système, y compris l’élimination de l’ancien système.