Est-il possible d'augmenter le montant estimé du développement de système après coup ?

Le travail de développement de systèmes, impliquant à la fois le côté utilisateur qui passe la commande et le côté fournisseur qui la reçoit, nécessite l’implication de nombreuses personnes. Par conséquent, il n’est pas facile de faire avancer un projet en synchronisant les efforts de tous. Il va sans dire que la planification est extrêmement importante dans ce type de travail, mais en réalité, l’utilisateur qui passe la commande n’est pas toujours en mesure de rassembler les informations appropriées et de les communiquer clairement au fournisseur. À un certain stade du processus de développement, si des modifications de spécifications ou des ajouts de fonctionnalités sont demandés après coup, la question de savoir si il est possible de facturer en plus du devis initial est une préoccupation majeure pour ceux qui acceptent le travail.

Quels sont les droits reconnus par la loi dans de tels cas ? Et comment est déterminé le montant de la rémunération pour le développement supplémentaire et la correction des fonctionnalités ? Cet article vise à clarifier ces diverses questions.

Quand peut-on parler de développement supplémentaire ou de modification de fonctionnalités ?

Dans un projet de développement de système, le type de contrat que l’on conclut lorsqu’on accepte un travail est généralement un contrat d’entreprise ou un contrat de mandat. Dans ces types de contrats, ce que le côté qui accepte le travail doit faire (c’est-à-dire son obligation) et la rémunération qui y est associée (c’est-à-dire son droit) sont indiqués ensemble dans le contrat. Par conséquent, si un travail qui n’est pas inclus dans le travail qui sert de base à cette rémunération est ajouté plus tard, on peut dire qu’il s’agit d’un développement supplémentaire ou d’une modification de fonctionnalités. Inversement, si un travail est inclus, il sera traité comme étant conforme aux spécifications initiales (c’est-à-dire dans le cadre du contrat existant).

Cependant, si l’on dit que tout, y compris les ajustements mineurs de la police d’écriture affichée à l’écran, est un développement supplémentaire à moins qu’il ne soit spécifié à l’avance, cela pourrait également entraver considérablement les transactions commerciales fluides. Par conséquent, lorsque l’on prend en compte ces discussions détaillées sur les spécifications, il n’est pas facile de tracer une ligne uniforme. Cependant, si l’on devait donner une directive générale, on pourrait dire que :

• Si on vous ordonne d’ajouter d’autres fonctionnalités après que les spécifications ont été finalisées
• Si on vous ordonne de modifier un programme qui a déjà été mis en œuvre

Il est probable que ces arguments aient une certaine validité juridique.

Exemples de litiges où la question était de savoir s’il s’agissait d’un développement supplémentaire ou d’une correction de fonctionnalité

Exemple affirmatif : Cas où les spécifications de la conception de base ont été modifiées a posteriori

Le cas suivant concerne une modification des spécifications qui a eu lieu a posteriori.

Le développement de logiciels passe par les étapes de ① définition des exigences, ② conception externe, ③ conception interne, ④ création du programme source (conception du programme, codage), ⑤ divers tests (tests unitaires, tests de combinaison, tests système) (omis)… Il s’agit de réaliser les spécifications initiales (omis) par le travail de conception interne et suivant, et cela est considéré comme étant dans le cadre du travail lié au droit de réclamer une rémunération sur la base du présent contrat de développement. La proposition de modification des spécifications est juridiquement interprétée comme une nouvelle demande de contrat de travail qui dépasse le cadre du travail basé sur le contrat initial par le client, et si le contractant ne présente pas le montant des frais de travaux supplémentaires et termine le travail lié à la nouvelle commande sans accord sur le montant des frais supplémentaires, il est raisonnable de comprendre qu’un nouveau contrat de travail sans montant fixé a été conclu entre le client et le contractant, et qu’une obligation de payer des frais de développement supplémentaires appropriés est née.

Jugement du tribunal de district d’Osaka du 29 août 2002

Les mots clés tels que “relation de contrepartie” et “nouveau contrat” seront la clé pour approfondir votre compréhension de ce jugement.

En outre, il est intéressant de noter que le jugement ci-dessus a également indiqué un autre point très intéressant. Il s’agit du fait que les ajustements très détaillés, tels que l’emplacement des boutons et la police des caractères, ne sont pas considérés comme des modifications de spécifications dans ce contexte. La partie pertinente est la suivante :

Cependant, dans le développement de logiciels, compte tenu du fait que, par nature, les détails tels que la police des caractères à afficher sur l’écran et l’emplacement des boutons ne sont pas déterminés à l’étape de la conception externe, et que les détails sont généralement modifiés dans une certaine mesure par des discussions entre les parties après la confirmation des spécifications, il ne serait pas approprié de considérer que même les demandes de détail des spécifications sont des modifications de spécifications.

Jugement du tribunal de district d’Osaka du 29 août 2002

Le jugement utilise le terme intéressant de “détail des spécifications”.

• Cas où ce qui était supposé être décidé a été renversé par la suite
• Cas où, pour des choses qui peuvent être décidées en cours de route, on a délibérément choisi de ne pas décider et de continuer

Il est possible de dire qu’il a montré une pensée selon laquelle le traitement juridique devrait être différent en conséquence.

Autres exemples affirmatifs

En outre, parmi les cas qui ont été reconnus comme des développements supplémentaires ou des corrections de fonctionnalités, on trouve :

• Un cas où le nombre de programmes livrés a augmenté d’environ deux fois par rapport au plan initial (Jugement du tribunal de district de Tokyo du 22 avril 2009)
• Un cas où la période de travail a été prolongée d’environ trois fois (Jugement du tribunal de district de Tokyo du 22 janvier 2010)

En résumé, il semble que l’extension de la période de travail soit également considérée comme un développement supplémentaire au sens large, et qu’une certaine protection juridique soit accordée.

“L’accord sur le développement supplémentaire et l’augmentation de la rémunération” et “la conclusion du contrat initial” sont deux problèmes différents

Un point important à noter à propos de ces problèmes est que :

1. La question de savoir si un contrat concernant le développement du système (contrat initial) a été officiellement conclu entre les deux entreprises en premier lieu
2. Une fois que le développement du système a été officiellement conclu, la question de savoir si un contrat concernant le développement supplémentaire a été conclu en plus

Les critères de jugement du tribunal sont différents. Pour le dire simplement, le tribunal a tendance à :

• Être strict sur le point 1 (il est rare qu’il reconnaisse la conclusion d’un contrat en l’absence de contrat écrit)
• Être relativement indulgent sur le point 2 (même en l’absence de contrat écrit concernant le développement supplémentaire, il est prêt à reconnaître une augmentation de la rémunération, etc.)

Exemple négatif : Cas où il a été traité comme étant inclus dans le même contenu de commande en termes juridiques

Cependant, il y a aussi des exemples de jugements où l’augmentation de la rémunération n’a pas été reconnue. Dans le cas du jugement cité ci-dessous, la question était de savoir si une augmentation de la rémunération pouvait être reconnue en raison du fait que le contenu du travail avait été modifié après la conclusion d’un contrat de développement de système.

Le point en litige dans cette affaire est (1) quel était le contenu du travail confié à la demanderesse dans le présent contrat, (2) si un accord a été conclu entre la demanderesse et le défendeur pour augmenter l’échelle et augmenter le prix pour le travail confié, (omis), etc. (omis).

Tout d’abord, le présent contrat est un contrat de sous-traitance qui a convenu de fixer le prix du contrat comme une contrepartie définitive pour le travail confié à la demanderesse, et le nombre de étapes, le prix unitaire, etc. du travail confié sont simplement des documents internes utilisés pour calculer le montant du prix du contrat à l’interne de la demanderesse, et l’augmentation du nombre d’étapes, etc. n’a rien à voir avec le prix du contrat. (omis)

Comme indiqué ci-dessus, le travail confié à la demanderesse a été modifié le 25 février 1987, et la gestion du système, le calcul des coûts de construction sous contrat et une partie seulement des utilitaires ont été limités, et le reste a été pris en charge par le défendeur, mais le travail de la demanderesse après le changement est toujours dans le cadre du travail de développement conformément à l’article 6 du contrat initial, et la contrepartie pour ce travail est couverte par le montant du contrat de sous-traitance qui a été convenu comme une contrepartie définitive au moment du contrat initial.

Jugement du tribunal de district de Tokyo du 12 juin 1995

Dans ce jugement, même si le contenu du travail confié au vendeur a été modifié, il a été jugé que ce développement était toujours dans le cadre du contenu du contrat initial et que la rémunération pour ce travail devrait être couverte par la rémunération qui avait été promise initialement.

En fin de compte, il semble que l’approche consiste à considérer que les travaux qui ne sont pas inclus dans la rémunération, qui a été déterminée en tenant compte de quels travaux seront effectués, devraient être soumis à une demande de rémunération supplémentaire.

Et la question de savoir quels travaux étaient la contrepartie de la rémunération initiale n’est pas nécessairement déterminée uniquement par le contrat, mais aussi par des preuves telles que les procès-verbaux.

Comment est déterminé le montant de la rémunération pour le développement supplémentaire et la correction des fonctionnalités ?

Dans le domaine du développement de systèmes, il n’est pas rare que les spécifications qui semblaient avoir été définies changent par la suite. Chaque fois que cela se produit, il n’est pas réaliste de préparer un nouveau contrat écrit et de procéder à la conclusion du contrat. Comment devrait-on calculer le montant de la rémunération dans les cas où le projet a été interrompu sans pouvoir effectuer ces procédures, même si on peut conclure un mémorandum ou autre en réaffirmant le contenu des spécifications pour les éléments à ajouter ou à corriger ?

Le texte de loi qui peut servir de référence dans de tels cas est l’article 512 du Code de commerce japonais (les parties soulignées ont été soulignées par l’auteur).

Article 512 du Code de commerce japonais : Lorsqu’un commerçant agit pour le compte d’autrui dans le cadre de son activité commerciale, il peut demander une rémunération appropriée.

La question est de savoir combien représente cette “rémunération appropriée” mentionnée dans cet article, dans des situations concrètes. En examinant les précédents judiciaires, il semble que l’approche adoptée est que le coût doit être supporté proportionnellement au nombre d’heures de travail, à la quantité de travail ou à la durée. Cela est probablement dû au fait que le développement de systèmes est en soi une sorte de service et que le coût principal est essentiellement le coût de la main-d’œuvre.

Par conséquent, malgré le degré d’abstraction de l’expression “rémunération appropriée” dans le Code de commerce, estimer le prix du marché pour le montant de la rémunération supplémentaire dans ce contexte n’exige pas de calculs particulièrement difficiles. Examinons quelques exemples de jugements.

Cas 1 : Un exemple où une rémunération supplémentaire proportionnelle à l’augmentation du temps de travail a été reconnue

Le temps de développement basé sur le changement de spécifications dans ce cas est raisonnablement considéré comme étant de 257,5 jours/personne au total, et si on le convertit en coût de développement par jour/personne au même taux que le contrat de développement délégué dans ce cas, soit 32 500 yens (dans le document A3, le taux unitaire est de 650 000 yens par mois/personne, et si on considère qu’il y a 20 jours de travail par mois, le coût de développement par jour/personne est de 32 500 yens), le coût de développement supplémentaire basé sur la demande de changement de spécifications dans ce cas est raisonnablement de 8 368 750 yens.

Jugement du tribunal de district d’Osaka du 29 août 2002

Le mot-clé ici est “par jour/personne”. Cela indique que le temps de travail est utilisé comme base pour le calcul de la rémunération supplémentaire.

Cas 2 : Un exemple où une rémunération supplémentaire proportionnelle au nombre de programmes a été reconnue

En examinant le montant de la rémunération appropriée, y compris la partie supplémentaire dans ce cas, compte tenu du fait que la majeure partie du coût de développement d’un système informatique est le coût de la main-d’œuvre des techniciens et que ce coût est généralement proportionnel à la quantité de programmes à créer, il est approprié de diviser le montant initial du contrat, soit 23 250 000 yens, par le nombre de programmes terminés jusqu’à la deuxième inspection, soit 206, et de multiplier ce prix unitaire par programme par le nombre de programmes passés par la troisième inspection, soit 414, pour obtenir un montant de 46 725 728 yens.

Jugement du tribunal de district de Tokyo du 22 avril 2005

Il y a beaucoup de chiffres, mais si vous lisez calmement, vous verrez qu’il ne s’agit pas d’un calcul difficile. Sur la base du contrat initial, ils ont confirmé “combien ils estimaient le prix unitaire par programme” et ont simplement fait une multiplication simple de “prix unitaire x quantité”.

Cas 3 : Un exemple où une rémunération supplémentaire proportionnelle à la durée a été reconnue

Étant donné que dans le contrat A3, une somme de 60 000 000 yens a été fixée comme contrepartie pour le travail effectué par le demandeur en tant que quasi-mandataire pendant une période de trois mois de janvier à mars 2005, et que le travail effectué après avril de la même année comprend du travail effectué gratuitement, mais aussi du travail dont le volume a augmenté en raison du début du semestre scolaire en avril, où le système d’inscription aux cours, etc., a été mis en service, il est approprié de considérer que la rémunération pour le travail effectué par le demandeur pendant une période de six mois d’avril à septembre 2005 est de 120 000 000 yens, sur la base des 60 000 000 yens fixés comme contrepartie pour le travail effectué pendant une période de trois mois.

Jugement du tribunal de district de Tokyo du 22 janvier 2010

Le jugement ci-dessus indique que la rémunération supplémentaire est calculée sur la base d’un calcul proportionnel simple pour la période prolongée.

Résumé

Comme nous l’avons vu avec plusieurs exemples de jugements, il semble que nous puissions discerner certaines régularités et points communs dans le traitement juridique des rémunérations supplémentaires pour le travail des programmeurs et des ingénieurs. En principe, on peut voir une tendance à calculer de manière aussi simple que possible, sur la base d’indicateurs relativement objectifs tels que le temps de travail investi, le volume de travail formel (comme les programmes livrés), et le temps ou la durée de travail.

Il peut sembler quelque peu insipide de dire que des rémunérations supplémentaires sont générées uniquement en fonction du temps investi, du volume de travail formel accompli, ou du temps passé, surtout si l’on considère que ces développements supplémentaires et ces corrections de fonctionnalités sont le résultat d’échecs dans l’estimation précise du temps de travail ou la formalisation des procédures. Cependant, du point de vue du contractant, même si l’objectif est de prioriser les intérêts du client tout en accomplissant le travail, le fait qu’il y a une probabilité que ces droits soient reconnus par la loi pourrait avoir un sens en termes de gestion des risques.