Un contrat de développement de système peut-il être conclu sans contrat écrit ?

Dans le domaine du développement de systèmes, il n’est pas rare que les développeurs commencent à travailler avant la création d’un contrat. Cependant, ce processus est en réalité “dangereux”. Si aucun contrat n’a été créé, il y a un risque que le client dise plus tard “le contrat n’a pas encore été conclu, donc il n’est pas nécessaire de payer une rémunération” en cas de problème. Dans les litiges réels liés au développement de systèmes, il n’est pas rare que la conclusion du contrat soit contestée et qu’une décision défavorable soit prise à l’égard du développeur. En tant que développeur, il y a un risque de ne pas être payé si le client décide d’arrêter le projet ou de passer à une autre entreprise. De plus, comme nous le verrons plus loin, même si un contrat a été créé, il peut arriver que la conclusion du contrat soit niée.

Ici, nous expliquerons la réussite ou l’échec du contrat de développement de système, ainsi que la structure juridique pour demander de l’argent si la conclusion du contrat n’est pas reconnue.

Formation du contrat

En principe, un contrat est conclu lorsque les deux parties s’accordent sur les éléments du contrat (concordance entre l’expression de l’intention de proposer et l’expression de l’intention d’accepter).

Une fois le contrat conclu, les deux parties sont liées par celui-ci et si l’une des parties ne réalise pas le contenu du contrat, l’autre partie peut, par voie judiciaire, forcer l’exécution ou demander des dommages-intérêts pour inexécution. Les “éléments du contrat” doivent être spécifiés ou concrets au point de pouvoir être utilisés pour forcer l’exécution et reconnaître l’inexécution.

Formation du contrat de développement de système

La nature du contrat de développement de système est principalement celle d’un contrat d’entreprise et d’un contrat de mandat. Un contrat d’entreprise est une promesse de réaliser un travail et de payer pour celui-ci. Un contrat de mandat rémunéré est une promesse d’exécuter une tâche et de payer pour celle-ci.

https://monolith-law.jp/corporate/contract-and-timeandmaterialcontract[ja]

Par conséquent, si les parties s’accordent sur les “éléments du contrat” que sont le “contenu du travail ou de la tâche” et le “montant de la rémunération”, le contrat est considéré comme conclu.

Il convient de noter qu’un simple accord verbal est suffisant pour conclure un contrat, et qu’un contrat écrit n’est pas obligatoire.

Demande de paiement en cas d’annulation après la conclusion du contrat de développement de système

Si un contrat de développement de système a été conclu et que l’utilisateur annonce unilatéralement son annulation, cela est juridiquement considéré comme une notification de résiliation du contrat.

Si un contrat d’entreprise a été conclu, le vendeur peut être résilié par l’utilisateur à tout moment avant l’achèvement du travail, mais il est stipulé qu’il a le droit à des dommages-intérêts en cas de résiliation (Article 641 du Code civil japonais). Par conséquent, si l’utilisateur ne verse pas de dommages-intérêts, le vendeur peut demander des dommages-intérêts pour le “préjudice” égal au montant des frais engagés par le vendeur jusqu’à ce moment et du montant de la rémunération qui aurait pu être obtenue, moins les frais économisés en raison de l’exemption de l’achèvement du système.

En outre, si un contrat de mandat a été conclu, le mandataire peut demander une rémunération proportionnelle à l’exécution lorsque le mandat se termine en cours d’exécution (Article 648, paragraphe 3, du Code civil japonais modifié). Par conséquent, le vendeur peut demander le paiement pour le travail déjà effectué.

Succès ou échec du contrat de développement de système

Spécificité du contenu du système

En général, les transactions entre entreprises, en particulier les contrats de grande valeur, sont réalisées par écrit. Par conséquent, si un contrat a été rédigé, il est plus facile de reconnaître la conclusion du contrat.

Le système à développer se concrétise progressivement à travers divers processus. Par conséquent, la spécificité du contenu du système, qui est un élément du contrat de sous-traitance, est considérée comme suffisante si l’étendue et le résumé du système à systématiser sont compréhensibles.

Dans un cas jugé, il n’y avait pas de litige sur la conclusion du contrat de base et du contrat de confidentialité, et le contrat de base stipulait que “le soutien technique pour l’entreprise de commerce électronique, le soutien à la construction de sites Web et les tâches associées” étaient confiés. Cependant, la conclusion du contrat a été niée car le contenu spécifique de l’entreprise de commerce électronique, l’étendue des tâches confiées et l’étendue du développement et de la conception en tant que système n’étaient pas explicitement indiqués.

Même si vous créez un contrat de base pour le développement de systèmes, si le travail ou le contenu du travail est abstrait et non spécifique, il sera difficile de reconnaître la conclusion du contrat. La conclusion du contrat peut être reconnue par des contrats qui décrivent spécifiquement le contenu du travail ou du travail et le montant de la rémunération, au point de pouvoir forcer l’exécution et reconnaître le non-respect.

De plus, les points à noter dans les contrats entre les ingénieurs individuels et les entreprises sont expliqués en détail dans l’article ci-dessous.

https://monolith-law.jp/corporate/engineer-joint-enterprise-contract[ja]

Le vendeur présente un devis et un cahier des charges, et l’utilisateur approuve et passe commande

En général, les transactions entre entreprises sont réalisées par écrit, donc si un contrat n’a pas été rédigé, il est difficile de reconnaître la conclusion du contrat. Dans le développement de systèmes, il est courant de commencer à travailler avant la rédaction du contrat, mais comment pense-t-on à la réussite ou à l’échec du contrat dans ce cas?

Dans un jugement (jugement du tribunal de district de Nagoya du 28 janvier 2004 (année Heisei 16)), la conclusion du contrat de sous-traitance pour le développement de systèmes est décrite comme suit:

• Après des négociations sur la confirmation des spécifications, etc. entre le vendeur et l’utilisateur,
• Le vendeur présente un cahier des charges et un devis,
• Ceux-ci sont approuvés par l’utilisateur et la commande est passée.

Dans ce jugement, le vendeur a été chargé par l’utilisateur, une municipalité, d’introduire un système de comptabilité financière, etc. Une RFP intitulée “Demande de soumission de proposition pour l’introduction du système d’information administratif général” a été présentée, et en réponse à cela, le vendeur a présenté une proposition et un devis, et l’utilisateur a soumis un “avis d’adoption”. Le vendeur n’a pas suffisamment examiné le contenu du travail de l’utilisateur, etc. en discutant avec l’utilisateur, et il n’a pas été reconnu que le contenu et le coût de la personnalisation ont été spécifiquement examinés à l’intérieur de l’utilisateur, et le contenu de la proposition du vendeur n’était pas spécifique, et il n’était pas clair ce que l’utilisateur avait approuvé, et la conclusion du contrat n’a pas été reconnue.

Je vais expliquer en détail la conclusion du contrat mentionnée dans le jugement, en tenant compte d’autres jugements, etc.

Après des négociations sur la confirmation des spécifications, etc. entre le vendeur et l’utilisateur

Comme il est dit “après des négociations”, si le contenu du système et le montant de la rémunération, qui sont des éléments du contrat, sont “en cours de négociation”, il est difficile de reconnaître la conclusion du contrat car il n’y a pas encore d’accord.

Cependant, dans le contrat de sous-traitance, il est possible de fixer le prix à la valeur marchande, donc si l’utilisateur a approuvé le contenu du système et le “montant approximatif” de la rémunération, etc., il a été reconnu dans un jugement que le contrat de sous-traitance a été conclu à un prix équivalent à la valeur marchande.

Pour pouvoir dire “après des négociations”, le vendeur devrait enregistrer le fait qu’il a suffisamment examiné le contenu du travail de l’utilisateur, le contenu du système, etc. en discutant avec l’utilisateur, etc. dans des e-mails, des procès-verbaux, etc.

Le vendeur présente un cahier des charges et un devis, et ceux-ci sont approuvés par l’utilisateur et la commande est passée

• Si l’utilisateur émet un bon de commande ou un bon de commande, il est plus facile de reconnaître la conclusion du contrat. Si le vendeur soumet une lettre de demande ou effectue des travaux basés sur un bon de commande, etc., il sera plus facile de reconnaître la conclusion du contrat en supposant qu’il y a un “accord”.
• Les lettres internes de l’utilisateur sont souvent du contenu prévu pour la conclusion du contrat à l’avenir, et il est difficile de reconnaître la conclusion du contrat. Cependant, si cette mention n’est pas incluse et que le contenu du développement du système et le montant de la rémunération, qui sont des éléments du contrat, sont décrits aussi spécifiquement que possible, cela favorisera la reconnaissance de la conclusion du contrat.
• Il est difficile de reconnaître la conclusion du contrat si le mémorandum, l’accord, la lettre de confirmation sont basés sur l’hypothèse de la conclusion du contrat à l’avenir ou si le contenu est abstrait.
• Si le sceau n’est pas apposé sur le projet de contrat, l’apposition du sceau signifie la conclusion, et il est difficile de reconnaître la conclusion du contrat.
• Le devis est une preuve pour reconnaître le montant de la rémunération convenu entre les parties.

De plus, dans le développement de systèmes, lorsque le processus a progressé jusqu’à un certain point et que des changements de spécifications ultérieurs ou l’ajout de fonctions sont demandés, des détails tels que la possibilité de facturer en plus du montant estimé initial sont expliqués en détail dans l’article ci-dessous.

https://monolith-law.jp/corporate/increase-of-estimate[ja]

Accord de liquidation

Si vous effectuez des travaux sur instruction de l’utilisateur dans l’hypothèse de la conclusion d’un contrat, en cas d’arrêt des travaux, il peut être reconnu qu’un “accord de liquidation” pour régler la rémunération pour les travaux effectués jusqu’à présent est conclu. Pour faciliter la reconnaissance de cet accord, il serait bon d’obtenir une description écrite de la méthode de liquidation de la rémunération en cas de non-conclusion du contrat de l’utilisateur, ou d’obtenir l’approbation d’une personne autorisée de l’utilisateur pour le document rédigé par le vendeur.

Configuration légale pour réclamer de l’argent en cas de non-reconnaissance de la conclusion d’un contrat

Négligence dans la conclusion d’un contrat

Lorsque les négociations en vue de la conclusion d’un contrat commencent, les parties ont l’obligation, en vertu du principe de bonne foi (Article 1, paragraphe 2 du Code civil japonais), de s’efforcer de ne pas porter atteinte à la propriété de l’autre partie. Si le contrat n’est pas conclu, vous pouvez demander des dommages-intérêts si vous avez violé cette obligation en raison de circonstances objectives qui ont fait espérer à l’autre partie que la conclusion du contrat était certaine et de votre responsabilité. C’est ce qu’on appelle la négligence dans la conclusion d’un contrat.

Voici un aperçu des cas où la négligence dans la conclusion d’un contrat a été reconnue par la jurisprudence.

• Le vendeur a terminé la définition des exigences à la demande de l’utilisateur et a également mis en œuvre une partie de la conception de base et de la conception détaillée. Cependant, l’utilisateur a expliqué que l’acte d’inviter d’autres entreprises à soumissionner n’était qu’une formalité pour obtenir l’approbation du président, mais juste avant la conclusion du contrat, une autre entreprise a été choisie et le contrat n’a pas été conclu.
• Le vendeur a avancé les travaux à la demande de l’utilisateur pour respecter le délai de livraison, et la date prévue pour la conclusion du contrat était également proche. Cependant, l’utilisateur avait avancé les préparatifs pour le développement en interne, mais cela avait été caché, et le contrat n’a pas été conclu.
• Le vendeur a été informé par l’utilisateur qu’il avait été choisi comme constructeur, et il n’y avait pas de questions sur le devis, et il a effectué des travaux tels que la confirmation des spécifications sur la base des réunions avec l’utilisateur, et l’utilisateur était conscient des dépenses. Cependant, le contrat a été refusé pour la raison que le montant du devis n’a pas pu être convenu.

En revanche, parmi les exemples de jurisprudence où la négligence dans la conclusion d’un contrat n’a pas été reconnue, il y a des cas où la possibilité de choisir une autre entreprise et les conditions pour conclure un contrat ont été explicitement indiquées.

Si vous avez avancé les travaux à la demande de l’utilisateur, mais que la possibilité de choisir une autre entreprise et les conditions d’accord n’ont pas été explicitement indiquées, et que les négociations contractuelles ont été brusquement rompues pour ces raisons, vous pouvez être autorisé à demander des dommages-intérêts.

Il n’y a pas de dispute sur le fait que les frais engagés jusqu’à présent sont inclus dans la “perte” dans ce cas. En plus de cela, il y a des exemples de jurisprudence où le profit du travail effectivement effectué a été inclus. De plus, si vous pouvez présenter des preuves que vous avez subi une perte équivalente au profit que vous auriez pu obtenir si vous aviez refusé une offre d’une autre entreprise et continué à travailler par la suite, cela peut également être inclus.

Article 512 du Code de commerce japonais

Si le vendeur a agi en relation avec le développement du système pour l’utilisateur, il peut demander une rémunération raisonnable en vertu de l’article 512 du Code de commerce japonais.

Une fois que vous commencez à négocier le développement du système, il est préférable de laisser des preuves qui reconnaissent que les circonstances qui font penser que la conclusion du contrat est certaine et que les éléments du contrat ont été concrétisés, en utilisant des e-mails, des procès-verbaux, etc., pour reconnaître mutuellement le contenu du système et le montant de la rémunération.

En fait, même si le paiement est refusé pour des raisons telles que l’absence de contrat écrit, il est possible de réclamer de l’argent comme indiqué ci-dessus.

Résumé

Comme nous l’avons vu, en l’absence de contrat écrit, les tribunaux ont tendance à adopter une position plutôt “négative” par rapport à la perception de l’entreprise mandatée en ce qui concerne la relation contractuelle. Du point de vue de l’entreprise mandatée, on pourrait vouloir dire : “J’ai commencé à travailler en premier lieu, en supposant que le contrat serait conclu par la suite, donc le contrat est en place”. Cependant, cet argument n’est pas toujours accepté.

De plus, si la conclusion d’un contrat est refusée, il peut y avoir des cas où l’on peut demander de l’argent en vertu de la loi, comme une négligence dans la conclusion du contrat ou l’article 512 du Code de commerce japonais, mais cela n’est pas non plus une “certitude”.

Si vous devez commencer à travailler avant la conclusion d’un contrat, vous devez :

• Reconnaître que c’est une action risquée et décider si vous devez consacrer du temps à ce projet en tenant compte de ce risque (en particulier pour les petites et moyennes entreprises et les startups, il peut y avoir des situations où vous devez prendre une décision de gestion pour “agir en premier” afin d’obtenir des antécédents commerciaux avec une grande entreprise. Si le risque est pris en compte, c’est une décision de gestion possible.)
• Examiner la possibilité de conclure un accord de liquidation ou autre en prévision de l’éventualité où le contrat ne serait pas conclu

Il est nécessaire de réfléchir à ces points.