Quels sont les points à vérifier dans un contrat de développement de système basé sur un contrat d'entreprise ?

Le Ministère de l’Économie, du Commerce et de l’Industrie japonais (METI) propose des clauses modèles pour les contrats de développement de systèmes informatiques dans ses “Directives pour l’amélioration de la fiabilité des systèmes d’information” (Guidelines for Improving the Reliability of Information Systems). Avec la généralisation d’Internet, l’impact social des interruptions de service ou des baisses de performance dues à des défaillances des systèmes d’information ne cesse de s’aggraver. Alors que l’amélioration de la fiabilité et de la sécurité des systèmes est une question urgente, les contrats de développement de systèmes informatiques ont tendance à rendre le contenu des transactions obscur. Ces clauses visent donc à rendre ces transactions plus transparentes et à clarifier la répartition des rôles et des responsabilités. Dans cet article, nous expliquerons les points à vérifier dans les contrats de développement de systèmes informatiques, en citant les clauses du contrat modèle du METI.

Développement de systèmes et contrats d’entreprise

Qu’est-ce qu’un contrat d’entreprise?

Un contrat d’entreprise est défini comme suit dans le Code civil japonais:

Article 632
Un contrat d’entreprise prend effet lorsque une partie promet de terminer un certain travail et l’autre partie promet de payer pour le résultat de ce travail.

Dans un contrat d’entreprise, il est nécessaire de promettre de “terminer un travail” selon le texte de l’article. Par exemple, si l’objectif du contrat est de créer un certain système d’ici une certaine date, l’obligation du fournisseur est de “terminer le système d’ici la date prévue”. Si le système n’est pas terminé d’ici la date promise, le fournisseur peut être tenu responsable pour non-exécution de l’obligation en raison du retard. Cependant, si des défauts sont découverts après la livraison du système terminé à la date prévue, l’obligation du fournisseur est déjà remplie, donc la non-exécution de l’obligation n’est pas un problème, et le problème devient une question de responsabilité pour les défauts.

Différences avec le contrat de quasi-mandat

Dans un contrat d’entreprise, le fournisseur a l’obligation de terminer le travail, donc s’il y a des défauts dans le produit livré, il a la responsabilité des défauts. En revanche, dans un contrat de quasi-mandat, il n’y a pas d’obligation de terminer le travail, donc il n’y a pas de responsabilité pour les défauts comme dans un contrat d’entreprise. Cependant, si un devoir de diligence est reconnu dans le processus de traitement des affaires, il peut y avoir une responsabilité séparée pour non-exécution de l’obligation, comme des dommages-intérêts.

Modèle de clauses contractuelles et points de vérification

Assistance à la création de la définition des exigences

La définition des exigences est un processus qui consiste à rassembler les spécifications requises pour le système que l’utilisateur souhaite construire. Dans cette phase de définition des exigences, nous examinons l’orientation de la construction du système et décidons quel type de système construire. Étant donné que les résultats concrets ne peuvent pas être prévus, le contrat modèle du Ministère de l’Économie, du Commerce et de l’Industrie japonais (Japanese Ministry of Economy, Trade and Industry) est défini comme un quasi-mandat.

Création de documents de conception externe

(Mise en œuvre de la création de documents de conception externe)
Article ○ Le deuxième, après avoir conclu le contrat individuel spécifié à l’article ○, effectuera le travail de création de documents de conception externe pour le logiciel concerné, basé sur le document de définition des exigences confirmé par les dispositions de l’article ○ dans le cadre de ce travail.

2. Lors de la mise en œuvre du travail de création de documents de conception externe, le deuxième peut demander la coopération nécessaire au premier, et le premier doit répondre à cette demande en temps opportun.

La création de documents de conception externe est un travail qui élabore l’utilisation des parties liées à l’interface, telles que les écrans et les formulaires. En principe, les documents de conception externe doivent contenir toutes les informations sur lesquelles le fournisseur peut développer le programme. Bien que les documents de conception externe contiennent des détails sur l’utilisation du format, c’est le côté utilisateur qui détermine le travail et peut modifier les spécifications requises. Cependant, si le document de définition des exigences, qui est le résultat de la phase précédente du travail de création de documents de conception externe, définit clairement les besoins de l’utilisateur et le contenu du travail que le fournisseur doit accomplir, le contrat peut être conclu sous la forme d’un contrat à forfait, avec le fournisseur comme principal.

Le premier paragraphe stipule que le fournisseur est le principal responsable de l’exécution du travail, car ce processus est de type contractuel. Cependant, même dans le cas d’un contrat de type contractuel, la conception externe a une grande influence sur la détermination du contenu du travail de l’utilisateur, il est donc nécessaire que l’utilisateur s’implique activement. Par conséquent, le deuxième paragraphe précise que le fournisseur peut demander la coopération de l’utilisateur pour examiner et décider des spécifications du système, et que l’utilisateur doit y répondre en temps opportun, ce qui indique clairement que l’examen des spécifications du système est un travail conjoint entre le fournisseur et l’utilisateur.

(Conclusion d’un contrat individuel concernant la création de documents de conception externe)
Article ○ Le premier et le deuxième, concernant la création de documents de conception externe, décideront des conditions de transaction mentionnées à l’article ○, paragraphe ○, après discussion, et concluront un contrat individuel concernant la création de documents de conception externe.

La portée, etc. du travail de création de documents de conception externe est déterminée par un contrat individuel conformément aux conditions de transaction établies dans la clause précédente.

(Réunion de discussion sur la conception externe)
Article ○ Le deuxième, afin de clarifier ou de confirmer les questions nécessaires à la création de documents de conception externe, tiendra une réunion de discussion sur la conception externe (ci-après dénommée “réunion de discussion sur la conception externe” dans cette section) à une fréquence jugée nécessaire, conformément à l’article ○, et le premier y participera.

2. Le premier, lorsqu’il juge nécessaire de créer des documents de conception externe, peut organiser une réunion de discussion sur la conception externe, et le deuxième y participera.

3. Si le premier souhaite modifier le contenu du document de définition des exigences à la suite des discussions, etc. lors de la réunion de discussion sur la conception externe, et si cela nécessite de modifier les conditions du contrat individuel, telles que la durée du travail et les frais de commission, cela sera fait conformément à la procédure de l’article 33 (Modification du contenu de ce contrat et du contrat individuel).

La collaboration entre l’utilisateur et le fournisseur est essentielle pour créer des documents de conception externe qui déterminent l’interface telle que les écrans et les formulaires. Comme ce processus est de type contractuel, le premier paragraphe stipule que le fournisseur organise la réunion de discussion et que l’utilisateur y participe. Toutes les clarifications ou confirmations nécessaires à la création de documents de conception externe sont effectuées lors de la réunion de discussion sur la conception externe, et le fournisseur et l’utilisateur sont liés par les résultats de la discussion lors de la réunion.

Le deuxième paragraphe stipule que l’utilisateur peut également organiser une réunion de discussion sur la conception externe si nécessaire pour la mise en œuvre du travail de création de documents de conception externe.
Le troisième paragraphe stipule que si l’utilisateur souhaite modifier le contenu du document de définition des exigences à la suite des discussions, etc., et si cela a un impact sur la durée du travail, les frais de commission, etc. spécifiés dans le contrat individuel, il doit suivre la méthode de modification du contenu de ce contrat et du contrat individuel stipulée dans une autre clause.

(Livraison des documents de conception externe)
Article ○ Le deuxième livrera au premier les documents de conception externe et la demande d’acceptation des documents de conception externe (également un bon de livraison) avant la date limite spécifiée dans le contrat individuel.

Comme ce processus est de type contractuel, le fournisseur doit livrer les documents de conception externe, etc. en tant que produits finis.

(Approbation et confirmation des documents de conception externe)
Article ○ Le premier, dans le délai spécifié dans le contrat individuel (ci-après dénommé “période d’inspection des documents de conception externe”), inspectera si les documents de conception externe sont conformes aux documents de définition des exigences confirmés par l’article ○ et aux décisions prises lors de la réunion de discussion sur la conception externe spécifiée à l’article ○, et s’il n’y a pas d’erreur logique, et approuvera que les documents sont conformes et qu’il n’y a pas d’erreur logique en signant et en apposant son sceau sur le document d’approbation de la conception externe par les responsables du premier et du deuxième. Cependant, si, à la suite de l’inspection, il est découvert que les documents de conception externe ne sont pas conformes aux documents de définition des exigences confirmés par l’article ○ et aux décisions prises lors de la réunion de discussion sur la conception externe, ou s’il y a une erreur logique, le deuxième créera une version corrigée dans le délai convenu après discussion et la présentera au premier, et le premier effectuera à nouveau l’inspection et la procédure d’approbation mentionnées ci-dessus.

2. Si le premier ne soulève pas d’objection pour une raison spécifique par écrit pendant la période d’inspection des documents de conception externe, il est considéré comme ayant approuvé les documents de conception externe à l’expiration de la période d’inspection des documents de conception externe.

3. L’approbation du premier conformément aux deux paragraphes précédents est considérée comme une confirmation des documents de conception externe.

Dans le processus de conception externe, les exigences nécessaires pour effectuer des travaux tels que la création de documents de conception interne sont confirmées, mais si la confirmation des exigences reste vague, des problèmes peuvent survenir dans le développement ultérieur. Cet article stipule la procédure pour inspecter les documents de conception externe, qui sont la base des travaux de développement ultérieurs, par l’utilisateur et les confirmer par l’approbation de l’utilisateur.

Le premier paragraphe stipule que l’utilisateur inspectera si les documents de conception externe sont conformes aux documents de définition des exigences confirmés par une autre clause et aux résultats de la discussion lors de la réunion de discussion sur la conception externe, et s’il n’y a pas d’erreur logique. Il peut y avoir des cas où il est jugé nécessaire de corriger lors de l’inspection pour l’approbation des documents de conception externe, et la clause de réserve stipule la procédure dans ce cas.
Le deuxième paragraphe est une disposition qui stipule que même si l’approbation de la signature et du sceau n’est pas terminée, si l’utilisateur ne soulève pas d’objection pour une raison spécifique dans un certain délai, il est considéré comme ayant approuvé les documents de conception externe. Il est prévu d’éviter les problèmes qui pourraient survenir plus tard en laissant l’approbation de l’utilisateur ambiguë et en entrant dans la conception interne.

Et le troisième paragraphe stipule que les documents de conception externe sont confirmés par l’approbation de l’utilisateur.

(Responsabilité pour les défauts)
Article ○ Après la confirmation de l’article précédent, si une incohérence entre les documents de conception externe et les documents de définition des exigences et les décisions prises lors de la réunion de discussion sur la conception externe spécifiée à l’article ○, ou une erreur logique (ci-après dénommée “défaut” dans cet article) est découverte, le premier peut demander au deuxième de corriger ce défaut, et le deuxième doit corriger ce défaut. Cependant, le deuxième n’est responsable de cette correction que si le premier en fait la demande dans les ○ mois suivant la confirmation de l’article précédent.

2. Nonobstant le paragraphe précédent, si le défaut est mineur et que la correction des documents de conception externe nécessite des coûts excessifs, le deuxième n’est pas responsable de la correction spécifiée au paragraphe précédent.

3. Les dispositions du paragraphe 1 ne s’appliquent pas lorsque le défaut est dû à des documents fournis par le premier ou à des instructions données par le premier. Cependant, cela ne s’applique pas si le deuxième savait que ces documents ou instructions étaient inappropriés et ne l’a pas signalé.

Cet article stipule la responsabilité pour les défauts concernant les documents de conception externe. La période de garantie des défauts est déterminée par une période qui est considérée comme appropriée en tenant compte de l’échelle du système d’information, du prix, etc., par la discussion entre les parties.

Le premier paragraphe définit l’incohérence entre les documents de conception externe et les documents de définition des exigences et les décisions prises lors de la réunion de discussion sur la conception externe, et l’erreur logique dans les documents de conception externe comme un défaut.

Le deuxième paragraphe protège le fournisseur en stipulant que même si le défaut est mineur, le fournisseur n’est pas responsable de la correction sans frais si la correction des documents de conception externe nécessite des coûts excessifs, conformément à l’article 634, paragraphe 1, du Code civil.

Le troisième paragraphe est une disposition qui stipule que, conformément à l’article 636 du Code civil, si le défaut est dû à des instructions ou à des documents fournis par l’utilisateur, le fournisseur n’est pas exempté de sa responsabilité de garantie, sauf s’il a signalé que ces documents ou instructions étaient inappropriés tout en sachant qu’ils l’étaient.

Veuillez noter que la responsabilité de garantie des défauts est une disposition facultative, et si une telle disposition n’est pas mise en place, elle sera traitée conformément aux principes généraux du Code civil. La responsabilité de garantie des défauts est un domaine qui sera grandement affecté par la révision du Code civil qui entrera en vigueur en avril 2020, et après l’entrée en vigueur de la révision du Code civil, la façon de traiter ce domaine changera.

Services de développement de logiciels

(Mise en œuvre des services de développement de logiciels)
Article 〇 Le deuxième parti, après avoir conclu un contrat individuel spécifié à l’article 25, effectuera les services de développement de logiciels allant de la conception interne aux tests du système, en fonction des spécifications du système déterminées par les sections précédentes.

2. Lors de la mise en œuvre des services de développement de logiciels, le deuxième parti peut demander la coopération nécessaire au premier parti, et le premier parti doit répondre à cette demande en temps opportun.

Dans ce qui suit, nous définissons les clauses pour le cas où le développement de logiciels est effectué par le fournisseur sur une base contractuelle. Dans le processus de conception interne du système, il est courant que les objets de développement et les spécifications soient définis par le travail effectué jusqu’à l’étape précédente, donc dans le contrat modèle du ministère de l’Économie, du Commerce et de l’Industrie, il est défini comme un contrat.

(Conclusion d’un contrat individuel concernant les services de développement de logiciels)
Article 〇 Le premier et le deuxième parti détermineront les conditions de transaction mentionnées à l’article 〇, paragraphe 〇, après discussion, et concluront un contrat individuel concernant les services de développement de logiciels.

La portée des services de développement de logiciels, etc., sera déterminée par un contrat individuel conformément aux conditions de transaction définies précédemment.

(Livraison des livrables)
Article 〇 Le deuxième parti livrera au premier parti les livrables spécifiés dans le contrat individuel, accompagnés d’une demande d’inspection (également une note de livraison), avant la date limite définie dans le contrat individuel.
2. Si une livraison a lieu, le premier parti effectuera une inspection conformément aux spécifications d’inspection de l’article suivant, conformément aux dispositions de l’article 〇 (Acceptation du logiciel concerné).
3. Lors de la livraison des livrables, le deuxième parti peut demander la coopération nécessaire au premier parti, et le premier parti doit répondre rapidement à cette demande.
4. Le risque de perte, de dommage, etc. des livrables sera supporté par le deuxième parti avant la livraison et par le premier parti après la livraison.

Comme ce processus est contractuel, le logiciel terminé, etc., sera livré comme un livrable qui sera l’objet de l’inspection. Le premier paragraphe stipule que les livrables doivent être livrés avec une demande d’inspection (également une note de livraison).

Le deuxième paragraphe stipule la mise en œuvre de l’inspection par l’utilisateur.
Le troisième paragraphe stipule l’obligation de coopération de l’utilisateur pour la livraison à l’endroit spécifié dans le contrat individuel, car il peut y avoir des cas où la coopération de l’utilisateur est nécessaire (par exemple, lorsque la livraison est effectuée en apportant les biens au bureau de l’utilisateur, lorsque la livraison est effectuée dans un état où il peut fonctionner dans l’environnement de fonctionnement réel de l’utilisateur).
Le quatrième paragraphe est une clause concernant le risque de perte ou de dommage des livrables, et le moment du transfert du risque est divisé par le transfert du contrôle physique.

(Acceptation du logiciel concerné)
Article 〇 Pour le logiciel concerné parmi les livrables, le premier parti doit inspecter, dans le délai spécifié dans le contrat individuel (ci-après dénommé “période d’inspection”), en fonction des spécifications d’inspection de l’article précédent, si les spécifications du système et le logiciel concerné correspondent.

2. Si le logiciel concerné est conforme à l’inspection du paragraphe précédent, le premier parti doit signer et estampiller le certificat d’inspection et le remettre au deuxième parti. De plus, si le logiciel concerné ne passe pas l’inspection du paragraphe précédent, le premier parti doit rapidement remettre au deuxième parti un document indiquant les raisons spécifiques de l’échec, et demander des corrections ou des compléments, et lorsque les raisons de l’échec sont reconnues, le deuxième parti doit corriger sans frais et livrer au premier parti dans le délai déterminé après discussion, et le premier parti doit effectuer à nouveau l’inspection spécifiée dans le paragraphe précédent dans la mesure nécessaire.

3. Même si aucun certificat d’inspection n’est remis, si le premier parti ne fait pas de réclamation en indiquant des raisons spécifiques par écrit pendant la période d’inspection, le logiciel concerné sera considéré comme ayant passé l’inspection spécifiée dans cet article.

4. L’acceptation du logiciel concerné sera considérée comme terminée avec l’approbation de l’inspection spécifiée dans cet article.

Comme ce processus est contractuel, cet article stipule la procédure d’acceptation pour le logiciel livré.

Le premier paragraphe stipule que pour le logiciel concerné, une inspection doit être effectuée en fonction des spécifications d’inspection pendant la période d’inspection, et il doit être vérifié si les spécifications du système et le logiciel concerné correspondent.
Le deuxième paragraphe oblige le fournisseur à corriger et à livrer la version corrigée à l’utilisateur si il est constaté que le logiciel concerné ne correspond pas aux spécifications du système.
Le troisième paragraphe est destiné à prévenir le retard de l’acceptation dû à la commodité de l’utilisateur en stipulant une acceptation présumée.
Le quatrième paragraphe stipule explicitement que l’acceptation du logiciel concerné est considérée comme terminée avec l’approbation de l’inspection.

(Responsabilité de garantie des défauts)
Article 〇 Après l’inspection terminée de l’article précédent, si une incohérence (y compris les bugs, ci-après dénommée “défaut”) avec les spécifications du système est découverte pour les livrables, le premier parti peut demander au deuxième parti de corriger ce défaut, et le deuxième parti doit corriger ce défaut. Cependant, le deuxième parti ne sera responsable de cette correction que si une demande est faite par le premier parti dans les ○ mois suivant l’achèvement de l’acceptation de l’article précédent.
2. Nonobstant le paragraphe précédent, si le défaut est mineur et que la correction des livrables nécessite des coûts excessifs, le deuxième parti n’est pas tenu de corriger comme stipulé au paragraphe précédent.
3. Les dispositions du paragraphe 1 ne s’appliquent pas lorsque le défaut est dû à des documents fournis par le premier parti ou à des instructions données par le premier parti. Cependant, cela ne s’applique pas si le deuxième parti n’a pas signalé que ces documents ou instructions étaient inappropriés alors qu’il le savait. 　

Comme ce processus est contractuel, cet article stipule la responsabilité de garantie des défauts pour les livrables. Il est difficile en pratique de déterminer la frontière entre la responsabilité pour non-exécution de l’obligation lorsque l’exécution n’a pas été effectuée (le travail n’est pas terminé) et la responsabilité de garantie des défauts après que l’exécution a été effectuée en principe (le travail est terminé). Il existe un précédent judiciaire (jugement du tribunal de district de Tokyo, 22 avril 2002) qui stipule que si un système est considéré comme terminé dans le développement de systèmes, il doit être basé sur le fait que le travail est terminé jusqu’à la dernière étape prévue dans le contrat initial. Si un défaut est découvert après la livraison et l’approbation de l’inspection du logiciel, la responsabilité de garantie des défauts s’appliquera en principe.

Le premier paragraphe définit l'”incohérence avec les spécifications du système” qui se produit dans les services de développement de logiciels comme un défaut. Les insuffisances fonctionnelles, etc., qui se produisent à l’étape de la conception externe sont déterminées par la responsabilité de garantie des défauts, etc., à l’étape de la conception externe, et non par cet article. La période de garantie des défauts doit être déterminée en tenant compte de la taille du système d’information, du prix, etc., et en déterminant une période qui est considérée comme appropriée par discussion entre les parties.

Le deuxième paragraphe prévoit une disposition similaire à l’article 634, paragraphe 1, du Code civil, stipulant que même si le défaut est mineur, si la correction des livrables nécessite des coûts excessifs, il est cruel de demander une correction gratuite au fournisseur.

Le troisième paragraphe est une disposition similaire à l’article 636 du Code civil, stipulant que le fournisseur n’est pas responsable de la garantie si le défaut est dû aux instructions ou aux documents fournis par l’utilisateur, mais si le fournisseur sait que ces documents ou instructions sont inappropriés et ne le signale pas, il ne peut pas échapper à la responsabilité de la garantie.

Assistance à la préparation et à la transition de l’exploitation du logiciel

Au stade de l’acceptation et de l’implémentation du système, il est courant que l’utilisateur agisse de manière proactive. Dans le contrat modèle du Ministère de l’Économie, du Commerce et de l’Industrie japonais (METI), il est stipulé que l’utilisateur est le principal acteur, et que le fournisseur soutient cette démarche sous la forme d’un quasi-mandat.

Détermination de la nature du contrat

Pour déterminer la nature d’un contrat, il faut examiner l’ensemble du contrat et son objectif, que ce soit pour « fournir un produit fini » ou pour que le vendeur « exécute raisonnablement ses tâches ». Un bon indicateur est de savoir si le contenu du produit à réaliser a été défini de manière assez concrète et si le projet a progressé en conséquence.