Qu'est-ce que la gestion des changements dans le développement de systèmes du point de vue juridique ?

Dans les projets de développement de systèmes, il arrive souvent que le contenu expliqué à l’avance par l’utilisateur soit modifié au fur et à mesure de l’avancement du travail. Par conséquent, même en tant que fournisseur acceptant le travail, il peut être nécessaire de répondre aux modifications du contenu du contrat qui a été conclu une fois.

Cet article explique comment gérer le phénomène de “modification” qui se produit après coup, d’un point de vue juridique, face à des projets de développement de systèmes qui ne progressent pas comme prévu.

Pourquoi les projets de développement de systèmes sont-ils souvent « modifiés » après coup ?

Le développement de systèmes est un travail collaboratif entre le fournisseur et l’utilisateur

En général, le développement de systèmes passe par une phase de planification et de proposition, puis les exigences de développement sont définies et un contrat est conclu. Une fois le contrat signé, le processus suit généralement une série d’étapes comprenant diverses conceptions, la mise en œuvre conformément à ces conceptions, et enfin des tests avant la conclusion. Dans l’ensemble du processus, il est bien entendu que le fournisseur, en tant qu’expert en développement de systèmes, assume une large gamme de responsabilités, mais l’utilisateur a également certaines obligations de coopération. En particulier, la coopération de l’utilisateur est importante dans les processus tels que l’identification des fonctions que le système doit avoir (c’est-à-dire la définition des exigences), l’apparence et la sensation de l’interface utilisateur (c’est-à-dire la conception de base), et la vérification que les exigences ont été satisfaites (c’est-à-dire les tests ou l’acceptation). Pour une explication générale des obligations que l’utilisateur assume dans le développement de systèmes, veuillez consulter l’article ci-dessous.

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

Malgré l’obligation de coopérer, les utilisateurs demandent souvent des modifications

Cependant, il n’est pas toujours possible pour l’utilisateur, qui n’est pas un expert en développement de systèmes, de transmettre de manière exhaustive et sans lacunes toutes les informations nécessaires au développement du système. En réalité, en raison de la nature détaillée et précise du travail, il est souvent difficile pour l’utilisateur de prévoir quelles informations auront une importance cruciale dans les étapes ultérieures. Ironiquement, il est donc possible que les informations les plus importantes soient révélées progressivement. Pour cette raison, bien que l’idéal soit de “passer en continu de l’amont à l’aval” dans les projets réels, il est important de savoir comment gérer les “changements” qui peuvent survenir après coup, en supposant que diverses modifications peuvent être apportées après coup.

Qu’est-ce qu’un document de gestion des modifications ?

Quand utilise-t-on un document de gestion des modifications ?

Un document de gestion des modifications est un document utilisé par l’utilisateur pour demander au fournisseur de modifier les spécifications ou d’ajouter des fonctionnalités par rapport à ce qui a été expliqué précédemment. Comme mentionné précédemment, lors des phases de définition des exigences et de conception de base, l’utilisateur a également l’obligation de coopérer avec le travail du fournisseur, mais il est tout à fait possible que des demandes différentes soient faites ultérieurement.

Par exemple, un document de gestion des modifications peut être nécessaire dans les situations suivantes :

• Si une omission est constatée lors de la définition des exigences ou de la conception de base, et qu’une fonctionnalité supplémentaire est demandée après coup.
• Si une révision de la politique d’entreprise est effectuée en cours de développement, nécessitant une modification des spécifications.

Ces situations sont envisageables.

En ce qui concerne les sujets tels que l’ajout de fonctionnalités et la modification des spécifications, ce qui préoccupe le plus ceux qui acceptent le travail est de savoir si la modification du montant estimé est légalement autorisée. Nous expliquons ce point en détail dans un autre article.

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

Le document de gestion des modifications sert de base pour évaluer la validité de l’estimation lors de l’augmentation de celle-ci après coup. Lorsqu’une facture est émise sur la base d’une estimation augmentée ultérieurement, la création d’un document de gestion des modifications est importante pour éviter les conflits avec l’autre partie (et pour donner du poids à votre argument en cas de conflit).

Contenu du document de gestion des modifications

Alors, quels sont les éléments qui doivent être inclus dans un document de gestion des modifications du point de vue juridique ? L’utilisation d’un document de gestion des modifications pour répondre aux modifications des spécifications et à l’ajout de fonctionnalités est déjà largement reconnue. Par conséquent, en vérifiant les modèles de clauses contractuelles proposés par les agences gouvernementales, comme le contrat modèle du ministère de l’Économie, du Commerce et de l’Industrie, on peut avoir une idée générale de ce qui doit être conservé comme enregistrement.

(Procédure de gestion des modifications)
Article 37 Si A ou B reçoit une proposition de modification basée sur l’article 34 (Modification des spécifications du système, etc.), l’article 35 (Approbation des documents intermédiaires par l’utilisateur), l’article 36 (Traitement des éléments non définis), il doit, dans les ○ jours suivant la date de réception, remettre à l’autre partie un document écrit (ci-après dénommé “document de gestion des modifications“) contenant les éléments suivants. A et B discuteront de l’acceptation ou non de cette modification lors du conseil de communication prévu à l’article 12.
① Nom de la modification
② Responsable de la proposition
③ Date
④ Raison de la modification
⑤ Détails de la modification, y compris les spécifications concernées
⑥ Si la modification nécessite des coûts, leur montant
⑦ Calendrier des travaux de modification, y compris la période d’examen
⑧ Autres impacts de la modification sur les conditions du présent contrat et du contrat individuel (durée des travaux ou date de livraison, honoraires, clauses contractuelles, etc.)

En lisant directement l’article, vous pouvez vérifier les éléments qui sont recommandés pour être inclus. Il n’est pas nécessaire d’expliquer davantage. Pour éviter les problèmes de “j’ai dit, je n’ai pas dit” plus tard, il est nécessaire de consigner en détail et de manière concrète le déroulement des modifications.

En précisant ces éléments et en les associant à la signature ou au sceau du responsable ou du décideur du fournisseur et de l’utilisateur, ils auront la même signification qu’un contrat en tant que preuve, même en cas de litige.

Les choses à savoir concernant la gestion des changements

La gestion des changements est généralement effectuée en tandem avec la gestion des problèmes

La raison de la création d’un document de gestion des changements est de guider le projet vers l’accomplissement en gérant l’historique des changements, ou d’éviter une responsabilité injuste en cas d’échec. Dans la pratique, la création d’un document de gestion des changements est souvent effectuée en tandem avec la création et la mise à jour de la liste de gestion des problèmes. En d’autres termes, une fois l’historique des changements géré dans le tableau de gestion des changements, les éléments de changement convenus sont intégrés dans la liste de gestion des problèmes comme des problèmes à traiter à l’avenir.

Il est préférable de réglementer également la manière de mener les discussions sur les changements

Non seulement la manière de gérer les changements, mais aussi la manière de mener les discussions sur les changements devraient être réglementées pour assurer une gestion fluide des changements. C’est particulièrement important dans le cas de méthodes de développement comme le développement agile, où de nombreux changements sont prévus après coup. Dans la pratique, il est courant de stipuler quand l’autre partie doit répondre à une demande de discussion sur la gestion des changements.

Discussion sur les changements et obligation de bonne foi

Lorsqu’il s’agit de modifier un contrat sur lequel les deux parties se sont déjà mises d’accord, cela revient à conclure un nouveau contrat. En principe, le vendeur n’a pas l’obligation de consentir à un contrat de modification. Cependant, si l’on insiste trop sur cet aspect des droits, il est à craindre que le projet de développement du système ne progresse pas de manière fluide.

Par conséquent, il est courant dans la pratique de stipuler explicitement dans le contrat une “obligation de répondre de bonne foi aux discussions sur les changements”. Il existe également des cas où le contrat stipule que si le vendeur ne répond pas de bonne foi aux changements, il est possible de demander des dommages et intérêts.

Un exemple de formulation serait le suivant (cité du “Modèle de contrat de base/individuel” créé officiellement par l’Institut indépendant de promotion du traitement de l’information du Japon) :

Article 4, paragraphe 3 : Dans les discussions sur les changements, les deux parties examineront de bonne foi l’objet du changement, la possibilité du changement, l’impact du changement sur le prix et le délai de livraison, et décideront de procéder ou non au changement.

Réglementation sur la méthode de changement

Comme mentionné précédemment, il est “sûr” d’un point de vue juridique de tenir une discussion sur chaque changement. Cependant, pour les petits projets, il peut ne pas être nécessaire de définir la manière de mener les discussions sur les changements. Dans ce cas, au lieu de stipuler des règles pour les discussions, vous pouvez décider que les changements ne seront effectués qu’après que le responsable de l’utilisateur et du vendeur a signé et apposé son sceau sur le document de gestion des changements. Si vous permettez des changements facilement sur la base d’un accord verbal uniquement, il peut être difficile de déterminer si des changements ont été effectués, ce qui peut entraîner de gros problèmes plus tard. Il est donc essentiel de gérer soigneusement les documents.

Cependant, il peut être trop lourd de préparer des documents séparés pour chaque gestion des changements, et vous pouvez vouloir privilégier une approche flexible. Dans ce cas, une solution pourrait être de documenter les questions relatives aux changements dans le procès-verbal de la réunion. Pour plus de détails sur la manière de conserver les procès-verbaux des réunions dans le développement de systèmes, veuillez consulter l’article ci-dessous.

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

Résumé

Dans les environnements où les changements de spécifications sont fréquents, il est vrai que le risque de problèmes et de conflits est souvent à portée de main. Cependant, même dans de tels environnements où une flexibilité est requise, il est souvent difficile de mettre en œuvre des mesures réalistes en insistant simplement sur l’importance de la gestion de manière rigide.

La question de savoir comment concilier le sens de la vitesse requis en affaires et la préparation à une éventualité est souvent différente selon la situation de l’entreprise et le contenu du projet. Tout en tenant compte du contenu de cet article, il est important d’avoir une attitude de recherche de la meilleure méthode pour chaque entreprise et chaque projet.