Quelle est la loi en cas de non-paiement pour le développement de systèmes ?

Pour les fournisseurs qui prennent en charge le développement de systèmes, le risque le plus important pourrait être que “malgré la livraison, l’utilisateur ne paie pas la récompense”. Les coûts de développement de systèmes sont souvent liés à des ressources humaines qualifiées, comme les programmeurs, ce qui entraîne souvent des coûts de main-d’œuvre élevés. Le retard dans la récupération des ventes peut parfois devenir une question de vie ou de mort. Dans cet article, nous discuterons des points que le fournisseur devrait examiner du point de vue juridique, en supposant que l’utilisateur ne répond pas au paiement de la récompense.

Tout d’abord, vérifiez si vous êtes en mesure de demander une rémunération

• Le fournisseur a livré le produit au client, mais le client refuse de l’accepter, ce qui retarde le processus de facturation.
• Malgré la perception que l’inspection était terminée, il y a un certain décalage avec la perception du client, qui refuse de payer la rémunération.

Ces situations peuvent tout à fait se produire dans la réalité.

En outre, dans le jargon du développement de systèmes, l’inspection des spécifications du système terminé par le client et l’acceptation de la livraison sont appelées “inspection”. L’importance de cette “inspection” et les points à considérer lorsque son avancement n’est pas satisfaisant sont expliqués en détail dans l’article ci-dessous.

Article connexe : Quand appliquer la clause d’inspection estimée dans le développement de systèmes[ja]

Bien que l’explication globale de l’inspection elle-même soit laissée à l’article ci-dessus, il est nécessaire d’examiner, en tenant compte des dispositions de la “clause d’inspection estimée”, si l’inspection du client peut être considérée comme terminée d’un point de vue juridique.

Avec cela à l’esprit, les points à examiner en premier lieu lorsqu’on envisage un cas où le client ne paie pas la rémunération sont les suivants :

1. Le travail est-il terminé ou est-il encore inachevé ?
2. La responsabilité de garantie des défauts (Article 635 du Code civil japonais) peut-elle être appliquée ou non ?

La raison pour laquelle il faut vérifier ces deux points en premier lieu est que, si le travail n’est pas terminé et que la responsabilité de garantie des défauts (Article 635 du Code civil japonais) n’est pas applicable, même si vous intentez une action en justice, vous ne pouvez pas vous attendre à être payé.

Alors, concrètement, que doit rechercher le responsable du côté du fournisseur pour examiner ces deux points ? Examinons ci-dessous quels sont les documents à vérifier.

Documents à vérifier pour déterminer l’admissibilité d’une demande de rémunération

Par ailleurs, nous avons rédigé un autre article détaillé sur la manière de gérer les modifications des spécifications du système à développer et sur la méthode de rédaction des documents de gestion des modifications.

Article connexe : Comment gérer les changements dans le développement de systèmes du point de vue juridique[ja]

Ensuite, vérifiez combien vous pouvez facturer

En principe, le montant que vous pouvez facturer est indiqué dans le contrat. Cependant, il est possible que des modifications de spécifications aient été effectuées après coup et qu’il n’y ait pas de contrat approprié (ou un document équivalent). La méthode de recalcul du devis basée sur des raisons postérieures telles que des modifications de spécifications ou des ajouts de fonctionnalités est expliquée en détail dans l’article ci-dessous.

Article connexe : Est-il possible d’augmenter le montant du devis pour le développement de systèmes après coup ?[ja]

La méthode de recalcul du devis est comme indiqué dans cet article, mais surtout si l’on considère la possibilité d’augmenter le montant de la facture,

1. La présence et le contenu du devis pour le développement supplémentaire et la correction des fonctionnalités
2. La réaction de l’utilisateur au devis
3. La présence d’un accord sur la situation qui a conduit au développement supplémentaire et à la correction des fonctionnalités inscrites dans la liste de gestion des problèmes, et sur le montant correspondant

Il s’agit des points principaux à examiner. En d’autres termes, il s’agit de vérifier si l’on peut dire qu’il y a eu un accord avec l’utilisateur sur le point de “passer commande pour le travail à ce prix” (c’est-à-dire si l’on peut dire qu’un contrat a été conclu).

Enfin, examinons les problèmes en suspens en cas de litige réel

Faites attention à la possibilité d’une contre-poursuite

Dans le développement de systèmes, lorsqu’un utilisateur ou un fournisseur intente une action en justice contre l’autre, il n’est pas rare que l’autre partie réponde par une contre-poursuite. En d’autres termes, il y a souvent une raison pour laquelle l’utilisateur ne paie pas la rémunération.

Le développement de systèmes implique certaines obligations de coopération de la part de l’utilisateur, mais il ne faut pas oublier que le fournisseur, en tant qu’expert en développement de systèmes, a une grande discrétion et une grande responsabilité. Nous avons expliqué en détail les obligations de gestion de projet que le fournisseur a envers le développement de systèmes dans l’article ci-dessous.

Article connexe : Qu’est-ce que l’obligation de gestion de projet dans le développement de systèmes ?[ja]

En d’autres termes, il est nécessaire d’examiner à l’avance si l’utilisateur qui ne paie pas unilatéralement la rémunération peut être tenu responsable. En regardant les précédents judiciaires, il y a de nombreux cas où le fournisseur a initialement intenté une action en justice pour demander une rémunération, mais l’utilisateur a ensuite fait une demande de réparation du préjudice ou de restitution à l’état d’origine.

Il faut également examiner s’il y a vraiment un avantage commercial

Même si les arguments du fournisseur sont acceptés et qu’il est reconnu en justice que la rémunération peut être réclamée, si la situation se complique au point de nécessiter un procès, il est prévisible que la poursuite des transactions sera difficile en pratique. De plus, même si vos arguments sont acceptés lors d’un procès, vous devez être prêt à ce que cela prenne beaucoup de temps avant de pouvoir recevoir la rémunération. Si vous prenez en compte le temps et les coûts associés à un procès, il est souvent préférable de faire des efforts pour trouver un compromis.

Résumé

Si un utilisateur refuse de payer une récompense, l’examen juridique de ce problème nécessite la vérification de plusieurs types de documents. De plus, il ne suffit pas simplement d’avoir une bonne gestion des documents, il faut également examiner quels risques et inconvénients organisationnels peuvent survenir si vous décidez finalement d’intenter une action en justice.

Il est vrai que la gestion rigoureuse des documents au quotidien est généralement une tâche au niveau opérationnel. Cependant, si vous décidez d’intenter une action en justice sur la base des documents et des informations stockés, cela pourrait devenir une décision de gestion majeure. Il est important de comprendre tout le processus, en tenant compte du fait que c’est précisément dans ces situations irrégulières que la cohésion et la force organisationnelle entre le terrain et la direction sont mises à l’épreuve.