La relation entre le retard de livraison du développement de système et le retard d'exécution en droit

Un projet de développement de système est, en un sens, toujours une lutte contre les délais. Du point de vue juridique, on peut examiner les “risques qui se manifestent en cas de non-respect des délais” dans le développement de systèmes.

Cet article explique dans quels cas un “retard de livraison” est considéré comme un retard d’exécution et entraîne une responsabilité juridique pour non-exécution de l’obligation, etc.

Qu’est-ce que le délai de livraison dans le développement de systèmes ?

Le délai de livraison en général

En général, le “délai de livraison” fait référence à la date limite pour livrer un produit demandé par un client. Même dans le domaine du développement où des problèmes imprévus peuvent survenir, le respect des délais de livraison est souvent strict. Dans les cas où il y a une différence de pouvoir entre le fournisseur et le client, la tendance à respecter les délais de livraison est encore plus marquée. Par exemple, si le délai de livraison est dépassé, il peut y avoir des cas où une réduction est accordée en fonction de l’excédent, ou où le travail supplémentaire n’est pas facturé et est offert gratuitement. Quoi qu’il en soit, le délai de livraison est généralement considéré comme important pour maintenir une relation de confiance avec le client.

Qu’est-ce que le délai de livraison d’un point de vue juridique ?

D’un point de vue juridique, dès qu’un contrat est conclu entre le fournisseur et l’utilisateur, le fournisseur a l’obligation (la dette) de livrer le système. Le délai de livraison est une restriction sur le moment où cette obligation doit être remplie. En d’autres termes, un retard dans le délai de livraison est considéré comme un type de non-exécution de l’obligation, ou un retard dans l’exécution. Par conséquent, si le délai de livraison est retardé en raison de l’intention ou de la négligence du fournisseur, il sera responsable de la non-exécution de l’obligation due au retard dans l’exécution (Article 412 du Code civil japonais).

1. Lorsqu’il y a une date limite fixe pour l’exécution d’une obligation, le débiteur est responsable du retard à partir du moment où cette date limite est atteinte.
2. Lorsqu’il y a une date limite incertaine pour l’exécution d’une obligation, le débiteur est responsable du retard à partir du moment où il a connaissance de l’atteinte de cette date limite.
3. Lorsqu’aucune date limite n’a été fixée pour l’exécution d’une obligation, le débiteur est responsable du retard à partir du moment où il a reçu une demande d’exécution.

Article 412 du Code civil japonais

La “responsabilité” mentionnée dans cet article se réfère à la responsabilité de l’indemnisation des dommages.

Lorsque le débiteur ne remplit pas son obligation conformément à son objet principal, le créancier peut demander une indemnisation pour les dommages causés. Il en va de même lorsque le débiteur est incapable de remplir son obligation en raison d’une cause qui lui est imputable.

Article 415 du Code civil japonais

De plus, si l’utilisateur a fixé un “délai raisonnable” et a demandé au fournisseur de livrer d’ici cette date, mais que le fournisseur n’a pas livré, l’utilisateur peut résilier le contrat.

Lorsqu’une partie ne remplit pas son obligation, l’autre partie peut fixer un délai raisonnable et demander l’exécution de cette obligation. Si l’obligation n’est pas remplie dans ce délai, l’autre partie peut résilier le contrat.

Article 541 du Code civil japonais

Tous les retards de livraison ne constituent pas un manquement contractuel en droit

Cependant, le fait superficiel de “ne pas avoir respecté le délai de livraison” ne signifie pas nécessairement un retard d’exécution en tant que manquement contractuel. Pour qu’une simple situation de retard de livraison devienne un retard d’exécution en droit, il faut remplir plusieurs conditions, comme indiqué ci-dessous.

Étant donné que le développement de systèmes est généralement un projet qui implique des obligations pour l’utilisateur et le vendeur, il est possible que les deux parties soient reconnues comme ayant violé leurs obligations et que les dommages-intérêts soient compensés.

Le point clé de la discussion est que l’on ne peut pas simplement dire que “ne pas respecter le délai de livraison = manquement contractuel.” Même si on parle de retard de livraison, les raisons peuvent varier, que ce soit à cause du vendeur ou de l’utilisateur. Il y a une grande différence entre le “retard de la date limite” en tant que fait formel et le “retard d’exécution” qui constitue une violation substantielle de l’obligation.

Jugements concernant les retards d’exécution

Examinons ci-dessous un cas de jugement où il a été débattu si la responsabilité de non-exécution de la dette due à un retard de livraison peut être poursuivie ou non. Bien qu’il s’agisse d’un litige concernant le délai de livraison, l’essentiel est que l’organisation des affaires sur la base des fondamentaux du développement de systèmes, tels que “l’obligation de coopération de l’utilisateur” et “l’obligation de gestion de projet”, est importante, tout comme dans d’autres litiges.

Cas où le retard d’exécution a été compensé par la violation de l’obligation de coopération de l’utilisateur

Dans le jugement cité ci-dessous, l’utilisateur a intenté une action en justice parce que le délai de livraison du fournisseur était en retard. Cette plainte a été partiellement acceptée par le tribunal, mais en même temps, il a été indiqué que l’absence de coopération appropriée de la part de l’utilisateur était également une cause, et que 40% des dommages dus au retard de livraison étaient de la responsabilité de l’utilisateur.

Après examen, il est possible de dire que l’utilisateur plaignant n’a pas pris de décisions en temps opportun et appropriées, comme ne pas résoudre les problèmes en suspens demandés par le défendeur avant la date limite. Cependant, en ce qui concerne l’allégation du défendeur de violation de l’obligation de coopération en raison des demandes d’ajout et de modification de fonctions de l’utilisateur plaignant, bien qu’il soit reconnu que l’utilisateur plaignant a fait des demandes qui ont entraîné des ajouts et des modifications du contenu du développement prévu dans le présent document de conception de base, il n’est pas possible de dire que cela constitue une violation de l’obligation de coopération de l’utilisateur plaignant, et l’allégation du défendeur est sans fondement. De plus, en ce qui concerne l’allégation du défendeur de violation de l’obligation de coopération en raison des demandes excessives de l’utilisateur plaignant, il n’est pas reconnu que l’utilisateur plaignant a fait des demandes excessives par rapport aux frais de commission du présent contrat de développement de système informatique, etc., et il n’y a pas de raison. Au contraire, il est possible de dire qu’il y avait des points inappropriés dans la gestion de projet du défendeur, comme le fait qu’il ait pris connaissance du nombre de traitements (le nombre de “traitements” à la date de juillet ou août de la même année) après janvier de l’année 11 (1999), et qu’il ait fait une proposition de réduction des traitements et de prise en charge des frais de commission supplémentaires inappropriés après le 31 mai de la même année.

Jugement du tribunal de district de Tokyo du 10 mars de l’année 16 (2004)

Le jugement ci-dessus a reconnu le retard d’exécution dû au retard de livraison du fournisseur, mais a également indiqué que l’une des causes était que l’utilisateur n’avait pas résolu les problèmes soulevés par le fournisseur, et a accepté la demande de l’utilisateur en “coupant” 60% des dommages revendiqués par l’utilisateur. Il s’agit d’un traitement de “compensation pour négligence”, comme dans le cas d’un accident de la circulation où la victime est également en faute.

Dans ce jugement, le terme “obligation de coopération” apparaît plus de 40 fois dans le texte complet, y compris la table des matières. Du point de vue juridique, on pourrait dire que l’essentiel était plutôt de distinguer l’obligation de gestion de projet du fournisseur et l’obligation de coopération de l’utilisateur.

Cas où le retard d’exécution a été entièrement reconnu

Le jugement cité ci-dessous est un cas où la responsabilité du fournisseur a été entièrement prouvée en ce qui concerne le retard de livraison, et la responsabilité de non-exécution de la dette due au retard d’exécution a été reconnue. Dans ce cas, l’utilisateur a résilié le contrat juste avant l’achèvement du système, et le fournisseur a intenté une action en justice, mais l’utilisateur a contesté en disant que le retard de livraison en était la cause.

Il ne peut être nié que le défendeur a donné diverses instructions de modification pour le système de design, et que cela a retardé la finition à un certain degré. En particulier, le défendeur a donné des instructions finales de modification le 23 juin de l’année 17 (2005), il est donc reconnu que la fonction de “calcul automatique pour les éléments détaillés des pierres de bordure” basée sur ces instructions n’est pas terminée, et cela ne peut pas être attribué à la faute du demandeur. Cependant, les autres modifications demandées par le défendeur ont été faites jusqu’au début du mois d’avril de la même année, et il n’est pas reconnu qu’il y ait des circonstances qui devraient être interprétées comme ayant modifié le calendrier de finition du système de design (à l’exception de la partie due aux instructions de modification du 23 juin de la même année par le défendeur). Il n’est pas reconnu que le demandeur avait terminé le système de design à un niveau où il pouvait être effectivement exploité à la fin du mois de juin de la même année, à l’exception de la partie due aux instructions de modification du 23 juin de la même année, et il est reconnu que des parties importantes du système, comme l’affichage des images et le fonctionnement de la fonction de recherche, n’étaient pas terminées. (Omission) Il est suggéré que le demandeur n’a pas suffisamment géré les procédures de travail associées au développement du système. Par conséquent, il n’est pas reconnu que la principale raison pour laquelle le demandeur n’a pas pu respecter le délai de livraison est due aux instructions du défendeur, et il n’est pas reconnu qu’il n’y a pas de raison qui devrait être attribuée à la faute du demandeur.

Jugement du tribunal de district de Tokyo du 16 février de l’année 19 (2007)

Dans ce jugement, il a été indiqué que la partie non terminée due aux instructions de modification données par l’utilisateur une semaine avant le délai de livraison ne peut pas être attribuée à la faute du fournisseur. Cependant, en tenant compte des points suivants :

• Le fait que les instructions de modification données plusieurs mois auparavant n’ont pas encore été suivies
• Le fait qu’après ces instructions, le fournisseur a envoyé un courriel indiquant la date prévue d’achèvement
• Le fait que les parties non terminées sont des parties importantes du système, comme l’affichage des images et l’implémentation de la fonction de recherche, et que le fait de ne pas y répondre est un élément qui soutient la violation de l’obligation de gestion de projet

La responsabilité de non-exécution de la dette due au retard d’exécution a été reconnue.

Ce que nous pouvons apprendre des deux jugements

En tenant compte des deux jugements, on peut dire que le problème du “délai de livraison” dans le développement de systèmes est finalement une question de comment tracer la frontière entre l’obligation de coopération de l’utilisateur et l’obligation de gestion de projet du fournisseur. En d’autres termes, du point de vue juridique, le retard d’exécution, qui est une forme de responsabilité de non-exécution de la dette, devient nécessairement un point de litige quant à savoir si le fournisseur a commis une violation de l’obligation ou non. Et pour examiner si le fait de dommage qui s’est manifesté en conséquence (c’est-à-dire la perte de l’utilisateur due au retard de livraison) peut être attribué au fournisseur ou non, il est également nécessaire d’examiner comment interpréter l’obligation de coopération de l’utilisateur en même temps.

Résumé

Le terme “retard d’exécution” peut sembler, à première vue, être simplement une autre façon de dire “retard de livraison” en raison de sa connotation. Cependant, le retard d’exécution est une forme de non-exécution d’une obligation. Par conséquent, il serait plus approprié de le comprendre comme une “violation de l’obligation de gestion de projet”.

La question des “délais de livraison” dans les projets de développement de systèmes ne doit pas se limiter à la simple question de savoir si la livraison est en avance ou en retard. Il est important de reconsidérer cette question en termes de l’obligation de gestion de projet du fournisseur et de l’obligation de coopération de l’utilisateur.