Similarités entre la vérification des contrats et le débogage expliquées par un avocat ancien ingénieur IT

Le cœur de l’activité d’un avocat-conseil d’entreprise, communément appelé « avocat d’entreprise », consiste à vérifier et à modifier les contrats que l’entreprise conclut quotidiennement avec ses clients et ses partenaires commerciaux. Et ces vérifications et modifications ne peuvent être effectuées de manière adéquate que par une personne qui connaît à la fois le droit et le domaine d’activité concerné. Nous allons expliquer pourquoi c’est le cas.

Cependant, l’explication suivante peut être difficile à comprendre pour ceux qui ne sont pas ingénieurs ou qui n’ont pas d’expérience en programmation. Le cabinet d’avocats Monolith est dirigé par un ancien ingénieur en informatique qui a également une expérience en gestion d’entreprise. Il s’agit donc d’un article expliquant la vérification et la modification des contrats, destiné aux dirigeants qui ont une expérience en ingénierie ou en programmation, et présenté par un cabinet d’avocats dirigé par un ancien ingénieur en informatique et gestionnaire d’entreprise.

Et sur cette base, la vérification et la modification des contrats sont des tâches similaires à ce que l’on appelle le « débogage ».

1. Qu’est-ce qu’un « bug » en premier lieu ?
2. Qu’est-ce que le « débogage » ?
3. Comment un contrat définit-il un algorithme ?
4. Qu’est-ce que la modification d’un contrat ?

Nous commencerons par des points qui peuvent sembler évidents pour les ingénieurs, mais nous expliquerons dans l’ordre ci-dessus.

Qu’est-ce que les “bugs” et le “débogage” ?

Un “bug” n’est pas une “panne de PC”

Quand on parle de “bug”, certains peuvent imaginer une situation où de la fumée sort de la machine pendant qu’ils travaillent sur leur PC et l’écran affiche quelque chose d’étrange… Cependant, en principe, un PC ne fait que “suivre les instructions”. C’est également le cas lorsqu’un bug se produit. En d’autres termes, un “bug” est une situation où :

• Le PC suit les instructions qui lui sont données, mais
• Pour l’utilisateur, cette action est un “comportement inattendu”

C’est ce phénomène.

Pourquoi les “comportements inattendus” se produisent-ils ?

Par exemple, considérons le bug de “traversée de mur” dans un jeu d’action de type Mario.

Le saut de Mario est une fonction quadratique. Accélération, vitesse, coordonnées. Cependant, dans un jeu vidéo, le temps ne peut pas être divisé à l’infini, comme c’est le cas pour une fonction quadratique classique. L’écran ne change que 30 fois par seconde (par exemple). Par conséquent, en quelque sorte, Mario “se téléporte” 30 fois par seconde.

Sur cette base, par exemple, dans le cas où “Mario saute et rebondit sur un mur en haut”, c’est le cas lorsque :

1. Un instant avant, Mario était en l’air, mais
2. Au moment suivant, les coordonnées de Mario sont à l’intérieur du mur

C’est ce cas.

Dans ce cas, on peut juger que “Mario a heurté un mur en haut pendant son saut”. Par conséquent, en langage naturel,

Si les coordonnées de Mario sont à l’intérieur du mur, effectuer un traitement de rebond (※1)

En écrivant un programme comme celui-ci, on peut réaliser le traitement “Mario saute et rebondit sur un mur en haut”.

※1 semble correct tel qu’il est écrit ci-dessus. Et en effet, sous “certaines conditions”, ce traitement est correct.

Cependant, si on y réfléchit bien, il y a aussi des cas comme celui-ci (※2).

Dans ce cas, il n’y a pas de moment où “les coordonnées de Mario sont à l’intérieur du mur”, donc aucun traitement de rebond n’est effectué, et Mario finit par traverser le mur.

C’est un exemple de “bug”. Même si un “bug de traversée de mur” se produit pour cette raison, ce n’est pas que le PC est en panne. Le PC ne fait que suivre les instructions qui lui sont données, et c’est l’homme qui évalue ce comportement comme étant “inattendu” ou “un bug”. Et ce “bug” se produit parce que l’algorithme n’est pas approprié.

Examiner si des “comportements inattendus” peuvent se produire

Cependant, il n’est pas clair si le “traversée de mur” mentionné ci-dessus se produira réellement pendant le jeu, simplement en y réfléchissant de manière abstraite. Que le “traversée de mur” puisse se produire ou non dépend de :

• La force de saut de Mario (vitesse initiale), y a-t-il des objets comme un power-up de saut ?
• Quelle est l’épaisseur minimale du mur ?

Cela dépend de ces conditions. Selon que le cas ※2 est possible ou non. Si le cas ※2 n’est pas possible, alors le programme ※1 n’a pas de problème.

Qu’est-ce que le “débogage” ?

Par conséquent, pour effectuer le “débogage”, c’est-à-dire pour trouver et corriger les bugs, il faut :

1. Lire et comprendre l’algorithme du programme (le ※1 ci-dessus est en langage naturel, mais en réalité, le programme est écrit dans un langage propre, donc la lecture en elle-même est difficile)
2. Examiner dans quelles conditions ce programme fonctionne (rechercher la force de saut et l’épaisseur du mur)
3. Examiner si un comportement inattendu peut se produire dans ces conditions

C’est pourquoi ce processus est nécessaire.

Qu’est-ce que la vérification d’un contrat ?

La vérification d’un contrat est une tâche similaire. Un contrat est, en soi, un document qui prévoit les événements futurs pour les parties concernées, définissant les droits et obligations qui en découlent, et comment les deux parties agiront en conséquence. En ce sens, on peut dire qu’un contrat est un “programme qui régit le monde réel”. Par exemple,

En cas de survenue de la situation ●●, la partie A doit indemniser la partie B à hauteur de 1 million de yens.

Un contrat qui établit de telles règles définit les conditions et les effets des événements futurs.

Et la tâche de vérifier s’il y a des problèmes avec ce “programme qui régit le monde réel”, et de le corriger si nécessaire, est inévitablement similaire au “débogage”.

Le contrat ne décrit pas l’ensemble de l’algorithme

Cependant, il y a un point dans le “contrat” qui est difficile à comprendre pour ceux qui ne sont pas spécialisés en droit, mais qui est extrêmement important. Le contrat est un document qui définit seulement une “partie” de l’algorithme qui régit les relations entre les parties. En d’autres termes, en lisant simplement le contrat, on ne peut pas comprendre l’ensemble de l’algorithme qui régit les relations entre soi et l’autre partie.

Par exemple, lorsqu’on achète un CD d’occasion dans un magasin, le magasin et le client ne concluent pas un “contrat de vente” en tant que tel, mais si le CD acheté a une rayure qui le rend illisible sur un lecteur, on voudrait se plaindre au magasin, et on s’attendrait à ce que le magasin y réponde. Ce n’est pas seulement une question de “service”, mais théoriquement :

1. Un contrat de vente est conclu même sans contrat écrit
2. Le Code civil japonais (le “Code civil”) stipule que le vendeur a une responsabilité de garantie pour les défauts dans le cas d’un contrat de vente d’un “bien spécifique” comme un CD d’occasion
3. Par conséquent, l’algorithme défini par le Code civil est en cours d’exécution entre le magasin et le client, et le magasin a une responsabilité de garantie pour les défauts

Voilà la logique. Et le “contrat” est un document qui modifie l’algorithme défini par le Code civil et d’autres lois. Par exemple, si un contrat ou un document similaire stipulant que “le magasin n’accepte aucune réclamation pour tout défaut du CD” a été échangé entre le magasin et le client, alors :

1. Un contrat de vente a été conclu
2. Le Code civil stipule que le vendeur a une responsabilité de garantie pour les défauts dans le cas de ce contrat
3. Cependant, en vertu des dispositions du contrat, le principe 2 est modifié, et le magasin n’a pas de responsabilité de garantie pour les défauts

Voilà comment cela fonctionne.

Un contrat est un document qui “réécrit” les principes du Code civil japonais

Cela est également vrai pour les contrats conclus entre entreprises, comme ceux de développement de systèmes. Par exemple, si un contrat de développement de système sous-traité est conclu entre les parties A et B,

1. Le fait de conclure ce contrat confirme explicitement qu’un contrat de sous-traitance a été conclu
2. Dans le cas d’un contrat de sous-traitance, la partie contractante est responsable de la garantie des défauts conformément aux dispositions du Code civil japonais
3. Si le contrat contient une clause de garantie des défauts, cette clause “réécrit” le principe du Code civil japonais mentionné en 2. Par exemple, si une clause de garantie des défauts pour une période plus longue que celle prévue par le Code civil japonais est incluse, cette période est valide

C’est la structure. En d’autres termes, même si le contrat ne contient pas de clause spécifique concernant la garantie des défauts, la responsabilité de la garantie des défauts existe.

Ceci n’est pas limité à la sous-traitance ou au développement de systèmes, mais est une théorie générale concernant tous les contrats conclus par une entreprise, tels que le transfert d’actions, le financement par dette (prêt à la consommation), l’emploi, l’émission d’actions, etc.

Par conséquent, la simple lecture d’un contrat ne permet pas de comprendre l’ensemble de l'”algorithme” qui régit la relation entre l’autre partie et votre entreprise. Pour comprendre l’ensemble, il est nécessaire de comprendre l'”algorithme par défaut” défini par des lois telles que le Code civil japonais. Un contrat n’est qu’un document qui “réécrit” cet “algorithme par défaut”.

Il est impossible de “déboguer” sans anticiper les événements futurs

De plus, comprendre un algorithme ne suffit pas pour vérifier si “aucun comportement imprévu ne se produira avec cet algorithme”. Tout comme pour les “bugs” dans les jeux, un algorithme est en fin de compte une chose abstraite, et si vous ne prévoyez pas quels événements pourraient se produire à l’avenir, vous ne pouvez pas vérifier si “un tel événement ne conduira pas à un comportement imprévu”.

C’est particulièrement problématique pour les nouveaux produits tels que les applications et les services, ainsi que pour les nouveaux modèles d’affaires. Quand vous développez une entreprise avec de tels produits ou modèles, vous devez vous demander ce qui pourrait arriver à l’avenir. C’est difficile à prévoir sans connaissances dans le domaine concerné. De plus, dans le cas des contrats entre entreprises, les deux parties agissent sous une certaine rationalité économique. Par conséquent, pour prévoir les événements futurs et les actions de l’autre partie qui les provoqueront, une réflexion basée sur la théorie des jeux en gestion d’entreprise est également nécessaire.

La question de “l’imprévu” est également basée sur le jugement de gestion

De plus, tout comme c’est à l’homme et non à l’ordinateur de juger si un événement est un “bug”, la question de savoir si une certaine conséquence d’un contrat est “imprévue” n’est pas seulement une question de droit pur, mais aussi une question de jugement de gestion.

Par exemple, il est tout à fait possible qu’un algorithme “selon les principes du droit civil japonais” soit inacceptable pour une certaine entreprise dans une certaine activité. C’est un peu différent de ce dont nous avons parlé jusqu’à présent, mais par exemple, le droit civil japonais stipule par défaut que la sous-traitance par le mandataire est une violation du contrat. Cependant, il peut y avoir des cas où “pour une certaine entreprise, il est prévu que certaines activités utilisent naturellement des sous-traitants”. Dans de tels cas, il devrait être impossible d’accepter un contrat qui rend la sous-traitance impossible, c’est-à-dire

• rien n’est spécifié concernant la possibilité de sous-traitance (dans ce cas, comme mentionné ci-dessus, les principes du droit civil japonais s’appliquent)
• il est clairement stipulé que la sous-traitance est impossible

Même si cela est “conforme aux principes du droit civil japonais”, il devrait être impossible de l’accepter.

De plus, dans la gestion, il y a toujours le risque d’être tenu responsable si certaines circonstances se produisent. Il n’existe pas de contrat qui n’implique pas de “risque” pour l’entreprise. Que ce risque soit accepté ou non est finalement une question de jugement de gestion. Ce sont les gestionnaires qui prennent les décisions de gestion, pas les avocats-conseils ou autres consultants, mais les consultants doivent fournir aux gestionnaires les informations nécessaires et suffisantes pour prendre des décisions de gestion, telles que

• les risques qui n’ont pas besoin d’être soulignés à chaque fois
• les risques qui nécessitent une décision importante de l’entreprise, et qui peuvent nécessiter une réunion ou autre

Il est nécessaire de les souligner avec des nuances. Pour établir ces “nuances”, l’avocat qui vérifie le contrat doit également avoir un certain sens de la “gestion”, tout comme dans le cas des consultants dans d’autres domaines.

Résumé

Ainsi, la vérification et la modification des contrats peuvent être largement décrites comme les tâches suivantes :

1. Comprendre comment les principes du Code civil japonais et autres sont réécrits par le contrat, et quel algorithme en résulte
2. Examiner quels événements pourraient se produire à l’avenir sous cet algorithme
3. Examiner si des comportements imprévus peuvent se produire

Et chacun de ces points est :

1. Une tâche difficile sans une compréhension du droit
2. Une tâche difficile sans une compréhension du contenu de l’entreprise que le contrat régit, comme une application ou un service web, et du schéma commercial
3. Une tâche difficile sans une certaine compréhension du contenu de l’entreprise ou de l’activité, et du sens des affaires

Voilà pourquoi.

La vérification et la modification des contrats sont donc très “spécialisées” pour ces raisons.

Présentation de la création et de la révision de contrats par notre cabinet

Le cabinet d’avocats Monolis, spécialisé dans le droit de l’IT, de l’Internet et des affaires, propose divers services tels que la création et la révision de contrats à nos clients et entreprises conseillées.

Si vous êtes intéressé, veuillez consulter les détails ci-dessous.

https://monolith.law/contractcreation[ja]