MONOLITH LAW OFFICE+81-3-6262-3248Jours ouvrables 10:00-18:00 JST[English Only]

MONOLITH LAW MAGAZINE

IT

Quelles sont les mesures à prendre si un défaut du système est découvert après l'acceptation ?

IT

Quelles sont les mesures à prendre si un défaut du système est découvert après l'acceptation ?

En termes généraux, le développement de systèmes consiste à mettre en œuvre un programme conformément au contenu décidé lors de la phase de définition des exigences. Finalement, il est vérifié par l’utilisateur et le fournisseur pour s’assurer qu’il est conforme aux spécifications, et le projet est considéré comme terminé une fois qu’il a passé l’inspection.

Cependant, en réalité, il est tout à fait possible que des bugs ou des problèmes qui n’ont pas été détectés lors des tests ou de l’inspection soient découverts lors des phases d’exploitation ultérieures. Si vous avez déjà accepté la livraison, que pouvez-vous légalement demander ?

Il n’est pas surprenant qu’il reste des bugs après l’acceptation ou les phases de test

D’un point de vue technique, il n’est pas rare que divers bugs et problèmes se manifestent après la fin des différentes phases de test du côté du fournisseur et après l’acceptation du côté de l’utilisateur. Habituellement, ce que l’utilisateur fait lors de la phase d’acceptation est principalement de vérifier les entrées et sorties qu’il peut voir à l’écran. Cependant, un système IT a souvent une structure complexe et détaillée dans la base de données en arrière-plan et dans les parties du programme qui contrôlent divers calculs et contrôles, au-delà de l’apparence à l’écran que l’utilisateur peut vérifier. Par conséquent, il y a des limites à ce qui peut être vérifié à partir de la vérification des entrées et sorties à l’écran du point de vue de l’utilisateur. Par conséquent, il n’est pas réaliste de vérifier exhaustivement toutes les possibilités de problèmes qui pourraient survenir lors de la phase d’exploitation suivante lors de la vérification.

La même chose peut être dite du point de vue du fournisseur qui est en charge du développement. Par exemple, la phase de test est celle où l’on vérifie s’il y a des bugs ou des problèmes dans le contenu du programme mis en œuvre. Cependant, même lors de la phase de test, il n’est pas toujours possible de vérifier toutes les possibilités de bugs et de problèmes. Même après que le système développé a commencé à être utilisé activement dans les opérations, il peut y avoir des opérations que le fournisseur n’avait pas prévues, ou de grandes quantités de données peuvent commencer à être enregistrées, ou plusieurs utilisateurs peuvent commencer à accéder en même temps. Créer un système qui continue à fonctionner sans problème dans de telles situations nécessite une excellente compétence technique.

Il faut d’abord comprendre que dans les phases d’acceptation et de test, il n’est pas réaliste de découvrir tous les bugs et problèmes, et que divers problèmes peuvent se manifester une fois que vous commencez à l’utiliser. C’est ce qu’est un système IT.

Il est généralement admis que la dette elle-même est considérée comme ayant été exécutée

Il est souvent difficile de tenir le vendeur responsable des problèmes survenus après avoir commencé à utiliser le programme.

Alors, comment devriez-vous gérer ces problèmes lorsqu’ils se produisent réellement ? Nous allons organiser cela en suivant l’ordre juridique.

Tout d’abord, si divers bugs ou problèmes sont découverts après coup, l’utilisateur voudra probablement tenir le vendeur responsable de quelque manière que ce soit, car il a commandé le travail jusqu’à présent. Cependant, généralement, si la livraison a déjà été complétée et que l’inspection a été réussie, il est souvent difficile de poursuivre la responsabilité basée sur le non-respect de l’obligation.

En premier lieu, à moins qu’un accord spécial ne soit préparé, les dispositions relatives à l’implémentation du programme dans le contrat de développement de système sont celles qui s’appliquent en vertu des dispositions du contrat de travail du Code civil japonais.

Et dans le contrat de travail, “l’achèvement du travail” est une condition d’exécution de l’obligation.

Dans ce texte, nous expliquons que dans les précédents judiciaires, “l’achèvement du travail” dans un contrat de travail signifie la fin de toutes les étapes du processus de développement dans le contexte du développement de systèmes. Et nous expliquons que les problèmes tels que les bugs et les défauts après la fin de tout le processus de développement sont une question de responsabilité de garantie des défauts dans le contrat de travail.

En résumé, une fois que la livraison a été acceptée et que l’inspection a été réussie, il est généralement admis que l’obligation elle-même a déjà été exécutée, et la question est de savoir si la garantie de qualité ultérieure, c’est-à-dire la poursuite de la responsabilité de garantie des défauts, est possible.

La voie à suivre pour poursuivre la responsabilité basée sur la garantie des défauts

Alors, comment devriez-vous procéder si vous voulez demander au vendeur de prendre des mesures basées sur la garantie des défauts ? Examinons cela dans l’ordre ci-dessous.

Vérifiez d’abord la gravité et la sévérité des bugs et des dysfonctionnements

Lorsque des bugs ou des dysfonctionnements sont découverts après coup et que vous demandez une sorte de garantie en tant que “défaut” juridique, la gravité de ces bugs ou dysfonctionnements devient un problème. Les problèmes de défauts juridiques sont, en premier lieu,

  1. Il peut s’agir de bugs ou de dysfonctionnements, mais ils sont mineurs et ne peuvent pas être considérés comme des “défauts” juridiques.
  2. Il s’agit d’un “défaut” juridique, mais l’objectif du contrat peut être atteint.
  3. Il s’agit d’un “défaut” juridique, et l’objectif du contrat ne peut pas être atteint.

Il y a trois modèles. Ce qui distingue la possibilité de poursuivre la responsabilité basée sur la garantie des défauts est la ligne entre 1 et 2, et ce qui distingue la possibilité de résilier le contrat basé sur la garantie des défauts est la ligne entre 2 et 3.

Article 634

1. Lorsqu’il y a un défaut dans l’objet du travail, le client peut demander à l’entrepreneur de réparer ce défaut dans un délai raisonnable. Cependant, cela ne s’applique pas si le défaut n’est pas important et que sa réparation nécessite des coûts excessifs.

2. Le client peut demander une indemnisation pour dommages à la place de, ou en plus de, la réparation du défaut. Dans ce cas, les dispositions de l’article 533 s’appliquent.

Article 635

Lorsqu’il y a un défaut dans l’objet du travail et que, à cause de cela, il est impossible d’atteindre l’objectif du contrat, le client peut résilier le contrat. Cependant, cela ne s’applique pas aux bâtiments ou autres structures terrestres.

Ensuite, clarifiez ce que vous devriez demander au vendeur

Ensuite, vous devez clarifier ce que vous devez demander à l’autre partie. Si vous voulez résilier le contrat, il ne suffit pas de prouver que c’est un défaut, vous devez prouver que c’est quelque chose qui “empêche l’atteinte de l’objectif du contrat”. Les éléments importants pour juger de cet “objectif” sont les procès-verbaux des réunions tenues au début du projet de développement du système et les éléments inscrits dans les spécifications. Comme il est possible que des bugs ou des dysfonctionnements soient découverts après l’acceptation, il est important de conserver tous les documents même après la fin du projet de développement.

En plus de la résiliation, les autres choses que vous pouvez demander en vertu de la garantie des défauts comprennent les demandes d’indemnisation pour dommages et les demandes de réparation des défauts.

Autres points à noter

Il est important de comprendre le flux de gestion des documents et des procédures juridiques jusqu’à la fin du projet.

Faites attention à la manière dont vous procédez lorsque vous effectuez des actes juridiques tels que la résiliation d’un contrat

Si vous devez résilier un contrat dans le cadre de la responsabilité de garantie des vices cachés (la responsabilité de garantie des défauts en français), vous devriez également apprendre comment effectuer les procédures administratives juridiques nécessaires pour la résiliation.

Il est préférable de résoudre les problèmes par la négociation plutôt que par le conflit

De plus, ces discussions juridiques ne sont pas seulement pertinentes lorsque des litiges surviennent. La résolution des conflits par les tribunaux est très coûteuse pour les deux parties. Au contraire, ces connaissances juridiques devraient être largement utilisées même à l’étape de la négociation avant le procès.

Il faut distinguer entre les bugs et les défauts, et le manque de fonctionnalités

La discussion diffère selon qu’il y a des bugs ou des défauts dans les fonctionnalités ou les spécifications que vous avez mises en œuvre, ou si les fonctionnalités nécessaires ne sont pas disponibles en premier lieu. Si les fonctionnalités nécessaires ne sont pas toutes disponibles, il se peut que l’achèvement du travail dans le contrat d’entreprise ne soit pas reconnu, et que l’exécution de l’obligation ne soit pas reconnue.

De plus, même si les fonctionnalités ou les spécifications nécessaires ne sont pas disponibles, si le côté utilisateur n’a pas fourni les informations appropriées lors de la définition des exigences, il se peut qu’il ne soit pas approprié de considérer cela comme une partie du contenu du contrat en premier lieu.

Résumé

Les problèmes qui surviennent au cours d’un projet peuvent se manifester pendant le déroulement du projet ou après, lors de la phase d’exploitation. Même si toutes les étapes du projet sont terminées sans encombre, il n’est pas nécessairement rassurant. Cette caractéristique des projets de développement de systèmes est symbolisée par le système de “responsabilité de garantie des vices cachés”. Il est important de comprendre ce processus et de veiller à une gestion rigoureuse des documents qui prend en compte la période après la fin du projet de développement du système.

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Retourner En Haut