Qu'est-ce que la loi concernant l'incendie" des projets de développement de systèmes ?"

Un projet de développement de système n’est pas quelque chose qui peut être accompli du jour au lendemain. Il nécessite l’investissement de nombreuses ressources, y compris un grand nombre de personnes et d’organisations, des fonds considérables et une longue période de développement. Dans cet article, nous expliquerons comment le phénomène de “flambée” dans un projet de développement de système peut être organisé dans le cadre juridique, et nous résumerons les lignes directrices pour les solutions.

Pourquoi un projet “prend-il feu” ?

Un système informatique, même s’il ne s’agit pas d’un projet de grande envergure, ne peut fonctionner correctement que grâce à l’accumulation de nombreux fichiers de programmes et de codes sources. Il est souvent beaucoup plus détaillé et précis qu’on ne pourrait l’imaginer à partir de la simplicité de l’interface utilisateur (ou, au contraire, plus l’interface utilisateur d’un système informatique est simple et concise, plus il est probable qu’il soit complexe).

• Seul le délai de livraison est fixé, tandis que les spécifications et les exigences restent floues au fil du temps
• Les membres sont trop préoccupés par les problèmes politiques internes, et beaucoup d’entre eux abandonnent en cours de route à cause du stress des relations interpersonnelles
• Il y a un manque de compétences de négociation au niveau de la gestion, y compris le chef de projet, et les membres ne sont pas invités à faire des rapports, des communications et des consultations appropriés

Les raisons spécifiques pour lesquelles un projet “prend feu” varient d’un projet à l’autre. Cependant, d’un point de vue juridique, les raisons pour lesquelles un projet “prend feu” peuvent être relativement simplement organisées en plusieurs types.

Type d’incendie 1 : Lorsqu’un projet échoue en cours de route

Dans le processus de développement de systèmes, un manque de communication entre l’utilisateur et le fournisseur est souvent cité comme une raison typique pour laquelle un projet peut échouer en cours de route. Après tout, un projet de développement de systèmes nécessite non seulement l’expertise technique et organisationnelle du fournisseur, mais aussi la coopération de l’utilisateur final qui utilisera le système.

Par conséquent, si un projet progresse sans une compréhension claire des rôles que chacun doit jouer, et si une sorte de “passage de responsabilités” se produit, cela peut entraver la progression fluide du projet. Pour une analyse juridique des obligations de l’utilisateur et du fournisseur, veuillez consulter les articles ci-dessous.

https://monolith-law.jp/corporate/project-management-duties[ja]

https://monolith-law.jp/corporate/user-obligatory-cooporation[ja]

Le point clé ici est que dans un projet de développement de système, l’utilisateur et le fournisseur ont chacun une certaine responsabilité. En termes généraux, les tribunaux ont reconnu que l’utilisateur a une obligation de coopérer dans les domaines qui ne peuvent pas être achevés sans lui, tels que la définition des exigences, la conception de l’apparence de l’écran (c’est-à-dire la conception de base) et l’acceptation.

D’autre part, le fournisseur, après avoir reçu la coopération de l’utilisateur dans les domaines mentionnés ci-dessus (et en même temps, après avoir fait des efforts pour communiquer et demander cette coopération), a une obligation globale d’assurer la progression fluide du projet et de découvrir et d’éliminer les obstacles à cette progression.

Sur la base de cette façon de penser, les tribunaux ont montré une attitude de traiter équitablement tous les conflits, en indiquant que l’utilisateur a l’obligation de mettre en place une gouvernance interne et que le fournisseur a l’obligation de faire preuve d’expertise et de compétence technique en tant que spécialiste externe.

De plus, les “échecs” sont souvent susceptibles de se produire lors de l’acceptation. Pour une explication détaillée de l’acceptation, veuillez consulter l’article ci-dessous.

https://monolith-law.jp/corporate/estimated-inspection-of-system-development[ja]

Dans de tels cas, une fois qu’un conflit se produit, l’évolution des projets passés, le contenu des discussions lors des réunions, et d’autres preuves vérifiables objectivement sont souvent valorisées. Par conséquent, les documents qui ont été enregistrés à l’avance ont souvent une grande importance. Pour ne pas désavantager votre position, il est important de bien gérer les documents. Pour une explication détaillée de l’importance de la gestion des documents dans le développement de systèmes, veuillez consulter l’article ci-dessous.

https://monolith-law.jp/corporate/the-minutes-in-system-development[ja]

Type d’incendie 2 : Annulation pour des raisons personnelles de l’utilisateur

Il est également possible qu’un projet soit interrompu en cours de route à la demande de l’utilisateur. Par exemple, supposons qu’une entreprise a commencé à développer un système informatique pour gérer toutes les ressources humaines, y compris celles de ses filiales à l’étranger, mais que la stratégie d’expansion à l’étranger de l’entreprise a été abandonnée. Dans ce cas, le développement du système qui a été commencé pourrait devenir inutile pour l’utilisateur.

En premier lieu, la question de savoir comment un système informatique doit être construit dans une entreprise ne peut être séparée de la question de savoir quel type de travail existe d’abord dans cette entreprise. Par conséquent, il est tout à fait possible que les exigences d’un système nécessaire (ou devenu inutile) changent après coup en raison de changements majeurs dans l’organisation ou la réorganisation des divisions commerciales, ou d’une révision radicale de la stratégie.

En raison de ces circonstances, l’interruption d’un projet en cours peut également entraîner divers problèmes juridiques. Dans ce cas, comme il s’agit généralement d’une question de convenance personnelle de l’utilisateur, le fournisseur a également certains droits juridiques, tels que la possibilité de demander une rémunération proportionnelle à l’achèvement du travail. Selon le type de contrat qui a été conclu, les dispositions sur lesquelles se baser peuvent varier, mais le contenu peut être organisé comme suit :

・Dans le cas d’un contrat d’entreprise : Article 641 du Code civil japonais
Article 641 du Code civil japonais
→Tant que l’entrepreneur n’a pas terminé le travail, le client peut à tout moment résilier le contrat en indemnisant les dommages.
・Dans le cas d’un contrat de mandat : Article 648, paragraphe 3 du Code civil japonais (selon les circonstances, une demande d’indemnisation pour dommages peut également être basée sur l’article 651 du Code civil japonais)
Article 648 du Code civil japonais
→Si le mandat se termine en cours d’exécution pour une raison qui ne peut être attribuée à la faute du mandataire, ce dernier peut demander une rémunération proportionnelle à l’exécution déjà effectuée.
Article 651 du Code civil japonais
→1. Le mandat peut être résilié à tout moment par chaque partie.
→2. Si l’une des parties résilie le mandat à un moment défavorable pour l’autre partie, cette partie doit indemniser l’autre partie pour les dommages. Cependant, cela ne s’applique pas s’il y a une raison inévitable.

Type de crise 3 : Lorsque des défauts dans le système livré sont découverts ultérieurement

Les utilisateurs ont souvent tendance à évaluer la qualité d’un système en fonction de son interface utilisateur. Cependant, du point de vue de ceux qui réalisent le travail, les aspects les plus complexes sont souvent la conception de la base de données et l’identification des éléments de test en tenant compte de toutes les méthodes d’opération possibles.

En d’autres termes, même si un système semble fonctionner correctement au début,

• La vitesse de traitement peut ralentir à mesure que le volume de données enregistrées augmente
• Un système qui semble fonctionner correctement dans les opérations quotidiennes de base peut présenter des bugs lors d’opérations spéciales qui se produisent tous les quelques mois ou années
• Même si les résultats semblent être correctement générés en surface, la logique sous-jacente peut être incorrecte. Par exemple, même si “2” est correctement affiché en réponse à l’entrée “1+1” de l’utilisateur, cela ne signifie pas nécessairement que le calcul a été effectué correctement. Il est possible que n’importe quelle formule de calcul renvoie “2”. Ces erreurs de logique sont souvent difficiles à détecter par une simple manipulation de l’écran. Dans ce sens, une certaine “compétence technique” est requise dans le processus de test.

Ces problèmes peuvent réellement se produire. Si nous devions analyser ces cas d’un point de vue juridique, ils pourraient être considérés comme une violation des obligations de gestion de projet du fournisseur, c’est-à-dire un problème d’exécution incomplète en vertu du droit civil japonais.

En l’absence de dispositions spéciales dans le contrat, les dispositions relatives aux contrats d’entreprise s’appliquent généralement.

Les points à examiner dans ce cas peuvent être résumés comme suit :

https://monolith-law.jp/corporate/defect-warranty-liability[ja]

Voilà comment les choses peuvent être organisées.

Résumé

Chaque projet de développement de système progresse à travers diverses et multiples complexités. Cependant, lorsque nous parlons de “flambée” d’un projet sur le plan juridique, le cadre présenté dans cet article peut servir de carte de référence. Les problèmes juridiques liés au développement de systèmes comprennent certainement une grande variété de thèmes.

Tout comme le travail de développement de systèmes nécessite une capacité de réflexion constructive, la gestion des risques qui y est associée peut également être menée de manière plus constructive en ne perdant pas de vue l’image globale du domaine. N’est-ce pas?