1. Introduction : Situation juridique du développement Agile au Japon

Le développement Agile est largement adopté au Japon en raison de sa flexibilité. Contrairement au développement traditionnel en cascade (Waterfall), il se caractérise par une approche itérative. Les spécifications détaillées ne sont pas figées dès le début du développement.

Cette particularité offre des avantages majeurs aux prestataires (fournisseurs). Ils peuvent répondre avec souplesse aux besoins des clients et faire avancer le développement rapidement. Cependant, d’un point de vue juridique, cela crée également de nouveaux défis et risques.

Dans cet article, nous analyserons les risques de litige auxquels les prestataires sont confrontés dans le développement Agile. Nous expliquerons également les mesures pratiques pour réduire ces risques.

1-1. Difficultés spécifiques au développement logiciel

L’asymétrie d’information crée une situation défavorable pour le prestataire

Le développement logiciel nécessite une expertise technique. Il est donc difficile à comprendre pour les juges et les utilisateurs. C’est là que naît l’« asymétrie d’information ».

Par conséquent, une situation défavorable au prestataire a tendance à se produire. Même si le contrat semble avantageux pour le prestataire, le juge peut prendre le parti de l’utilisateur. Il rendra un jugement sévère à l’encontre du prestataire en raison de cet écart d’information.

Certains juges considèrent le développement comme des travaux de construction classiques. Ils pensent à tort qu’il peut être achevé sans dialogue avec l’utilisateur. Cependant, le développement Agile est totalement différent de la construction. Le terme « Agile » s’est répandu, mais il est douteux qu’il soit correctement compris.

Différences fondamentales avec le modèle en cascade

Le développement logiciel n’est pas comme des travaux standardisés. Il implique toujours une personnalisation. Par conséquent, modifier la définition des exigences une fois décidée est très difficile. Un changement entraîne un retour en arrière (rework) important et il est impossible de revenir en arrière.

Cependant, les utilisateurs ne veulent pas figer les spécifications dès le départ. La raison principale est qu’ils « n’ont pas une image concrète ». Dans le développement en cascade, de tels retours en arrière ne sont pas autorisés.

Penser qu’il n’y a pas de retour en arrière avec l’Agile est une erreur. En réalité, des retours en arrière peuvent se produire. L’Agile est un mécanisme qui minimise le risque de retour en arrière en répétant le développement par petits incréments.

L’attitude requise tant du prestataire que de l’utilisateur

Le développement Agile a une structure qui facilite les conflits. Il n’est pas rare que l’utilisateur fournisse une grande quantité de documents après le début du projet. Par conséquent, à moins de travailler avec un utilisateur bienveillant et méticuleux, les conflits seront inévitables.

Il est courant que les projets fonctionnent par renouvellement de contrats à court terme. C’est aussi un moyen pour l’utilisateur d’évaluer la compatibilité avec le prestataire. Le prestataire doit tenir des registres détaillés de son travail. Ce qui a été fait et ce qui est en cours. Ces enregistrements sont également cruciaux pour garantir le paiement de la rémunération.

L’utilisateur s’attend à ce que « quelque chose soit achevé ». Le prestataire doit comprendre cette attente et la gérer de manière appropriée. Il est nécessaire de contrôler le niveau des attentes grâce à la gestion de projet. L’Agile est fondamentalement basé sur un contrat de quasi-mandat (obligation de moyens), mais cela ne signifie pas une exonération de responsabilité. Il ne faut pas oublier qu’une lourde obligation de diligence (devoir de sollicitude d’un bon professionnel) est imposée.

1-2. Responsabilité juridique

Le type de contrat de développement logiciel influence grandement la responsabilité juridique. Les types de contrats adaptés diffèrent entre l’Agile et le Waterfall.

① Contrat d’entreprise (obligation de résultat / au forfait)

Le contrat d’entreprise est un contrat qui promet « l’achèvement de l’ouvrage ». Le prestataire s’engage à livrer un produit livrable conforme aux spécifications définies avant la date limite. S’il y a des défauts dans le livrable, il sera tenu pour responsable de la non-conformité contractuelle.

Ce contrat est très compatible avec le développement en cascade. Comme les spécifications sont fixées avant le développement, la définition de « l’achèvement de l’ouvrage » est claire. Par conséquent, le point de litige juridique a tendance à se concentrer sur la « conformité ou non aux spécifications ».

② Contrat de quasi-mandat (obligation de moyens / en régie)

Le contrat de quasi-mandat est un contrat qui confie l’exécution de certaines tâches. Le prestataire n’est pas tenu d’achever un livrable, mais d’exécuter ses tâches de manière appropriée. C’est ce qu’on appelle « l’obligation de diligence » (ou obligation de moyens).

On considère que le développement Agile a une nature proche du contrat de quasi-mandat, car les spécifications changent de manière flexible pendant le développement. L’Agence pour la promotion des technologies de l’information (IPA) du Japon a également exprimé l’avis que le contrat de quasi-mandat est approprié pour le développement Agile.

1-3. Impact juridique du type de contrat

La responsabilité du prestataire varie considérablement selon que le contrat est un contrat d’entreprise (obligation de résultat) ou un contrat de quasi-mandat (obligation de moyens). Le principal point de litige dans un contrat de quasi-mandat est de savoir s’il y a eu ou non « violation de l’obligation de diligence ». On se demande si le prestataire, en tant que professionnel, a exécuté ses tâches avec diligence et honnêteté.

D’un autre côté, dans un contrat d’entreprise, « l’achèvement du livrable » est une obligation. Si le produit livré n’est pas conforme au contrat, la responsabilité du prestataire sera engagée. Conclure un contrat d’entreprise pour un développement Agile augmente les risques. Comme les spécifications changent constamment, il est facile d’entrer en conflit sur la conformité du livrable. Avec un quasi-mandat, il est généralement interprété que la responsabilité finale de l’achèvement n’est pas engagée.

L’obligation de diligence porte sur la pertinence du processus. Ses normes ne sont pas uniformes. Par exemple, si l’utilisateur a une grande maîtrise de l’informatique, le prestataire aura tendance à suivre davantage les instructions de l’utilisateur. Inversement, si l’utilisateur ne connaît pas bien l’informatique, le juge peut imposer une obligation de diligence plus lourde au prestataire, en tenant compte de l’asymétrie d’information.

2. Risques de litige en développement Agile auxquels les prestataires sont confrontés

Il faut d’abord savoir qu’il y a peu d’avocats spécialisés en informatique. On observe des cas où même la partie qui intente l’action en justice le fait sans comprendre le développement. Les frais d’avocat ont également tendance à être élevés.

Par conséquent, la priorité absolue est d’éviter les litiges. Visez d’abord une résolution à l’amiable. Cependant, les sociétés cotées en bourse, par exemple, peuvent être contraintes de choisir la voie du litige pour des raisons de responsabilité (accountability).

2-1. Risque ① : Conflit sur l’étendue de l’exécution dû à l’ambiguïté des modifications de spécifications

Le risque de litige le plus courant dans le développement Agile est que l’étendue de l’exécution du contrat devienne floue en raison d’un accord ambigu sur les modifications de spécifications. Cela conduit à des litiges où l’utilisateur prétend que « cela devrait être inclus dans le budget initial », refuse de payer des frais supplémentaires, ou exige un développement supplémentaire gratuit.

En Agile, il est entendu que les spécifications changent au fur et à mesure que le développement progresse. Cependant, si l’estimation initiale est ambiguë, l’étendue de l’exécution du contrat devient également floue. C’est ce qui déclenche les conflits.

Principaux types de conflits découlant des modifications de spécifications

• Conflit sur l’étendue de l’estimation initiale : Cas où l’utilisateur prétend que les spécifications supplémentaires « devraient être incluses dans le budget initial » et refuse de payer des frais supplémentaires.
• Conflit sur l’évaluation des livrables : Risque que l’utilisateur exige un développement supplémentaire gratuit, prétextant que « le livrable n’atteint pas le niveau attendu ».
• Conflit sur l’existence d’une responsabilité de résultat : Même si le prestataire prétend n’avoir « aucune responsabilité d’achèvement » en raison du contrat de quasi-mandat (obligation de moyens), le tribunal peut reconnaître une certaine responsabilité de résultat. « Agile » n’est pas synonyme d' »exonération ».

Lors d’un procès, les échanges pendant le développement sont examinés de près. Les comptes rendus de réunion, les e-mails, les cahiers des charges, etc., servent de preuves. C’est à partir de ces enregistrements que la pertinence du processus de travail est jugée. Le processus d’accord sur les modifications de spécifications est particulièrement important. Laisser des traces claires est la meilleure arme pour se protéger.

2-2. Risque ② : Possibilité d’être accusé de manquement à l’obligation d’information

Le prestataire, en tant qu’expert, a une lourde responsabilité d’explication. Le risque particulier est le « manquement à l’obligation d’information ». Si le prestataire n’explique pas à l’avance la possibilité de fluctuations des coûts ou l’importance de la validation des résultats de chaque sprint, il peut être tenu responsable d’avoir laissé perdurer les malentendus de l’utilisateur.

Les tribunaux ont tendance à imposer une lourde obligation d’explication au prestataire, en tant qu’expert. Dans le développement Agile, les points suivants sont particulièrement susceptibles de devenir litigieux :

Responsabilité d’explication spécifique requise du prestataire

• Avoir expliqué à l’avance le déroulement de l’Agile : Les spécifications sont fluides. Il est donc nécessaire d’expliquer à l’utilisateur que les coûts et les délais peuvent varier.
• Avoir obtenu la validation (« acceptation ») des résultats de chaque sprint : Il est indispensable de mettre en place un mécanisme pour obtenir une confirmation d’acceptation claire de l’utilisateur pour les livrables de chaque sprint. Conservez la preuve de cet accord.
• Ne pas avoir laissé perdurer les malentendus de l’utilisateur : Si vous sentez que l’utilisateur comprend mal le processus, vous devez activement dissiper ce malentendu. Le laisser perdurer risque d’être interprété comme une responsabilité du prestataire.

2-3. Risque ③ : Perte de confiance due à la négligence dans la gestion de l’avancement et le partage des problèmes

La « transparence » est essentielle dans le développement Agile. Négliger de partager l’avancement et les problèmes érode la confiance avec l’utilisateur et augmente le risque de litige. En particulier, si un problème grave est découvert tard dans le développement, le prestataire est plus susceptible d’être accusé de manquement à son obligation de diligence (devoir de sollicitude) en raison d’une gestion négligente de l’avancement.

La « transparence » est essentielle dans le développement Agile. Cependant, dans les situations suivantes, la confiance peut être érodée et conduire à des conflits :

• Le rapport d’achèvement n’est-il pas devenu une simple formalité ? Si le rapport d’achèvement du sprint devient purement formel, un décalage de perception se crée entre le prestataire et l’utilisateur, et celui-ci s’accumule.
• Avoir négligé de partager les bugs ou les contraintes techniques ? Les bugs découverts pendant le développement doivent être partagés rapidement. Si le rapport est retardé et que le problème s’aggrave par la suite, la responsabilité du prestataire sera engagée. Il est important d’expliquer avec transparence et à un stade précoce, y compris les raisons pour lesquelles l’estimation de la charge de travail est difficile.
• Avoir laissé perdurer l’incompréhension du PO (Product Owner) ? Si le PO côté client ne comprend pas l’Agile, le prestataire ne doit pas l’ignorer. Cela pourrait être interprété comme ayant encouragé le malentendu. Ne vous contentez pas de suivre passivement l’autre partie ; ce qui doit être dit doit être clairement consigné dans le compte rendu.

3. Documents requis et mesures à prendre en cas de litige

3-1. Preuves importantes lors d’un procès

Lors d’un procès, les contrats et les cahiers des charges ne suffisent pas. Comme les juges ne sont pas des experts en informatique, les « enregistrements du développement » eux-mêmes, tels que les rapports d’activité, le backlog et l’analyse du code source, qui démontrent concrètement la pertinence du processus de travail, constituent les preuves les plus importantes.

Lors d’un procès, les contrats et les cahiers des charges ne suffisent pas. Des rapports d’activité, le backlog et une analyse du code source sont requis. Il est nécessaire de montrer clairement au juge ce que le prestataire a fait.

Cependant, le juge n’est pas un expert en informatique. Il est fréquent qu’il ne connaisse même pas les termes « Agile » ou « code source ».

3-2. Importance de la préservation des documents de l’environnement de développement et des sauvegardes

Le risque majeur est de ne conserver aucune preuve. Surtout lorsque le développement est effectué dans l’environnement cloud du client, l’accès peut être révoqué après la fin du contrat. En prévision d’un litige, il est impératif de conserver une sauvegarde des journaux de travail et des documents de l’environnement de développement dans votre propre entreprise.

Le plus gros problème est le cas où il n’y a aucun document de développement. C’est le cas lorsque le développement a été fait sur l’environnement cloud du client et qu’il n’y a aucune trace en local. En prévision d’un litige, assurez-vous de sauvegarder vos journaux de travail. Sans documents, vous serez extrêmement désavantagé au tribunal.

3-3. Collaborer avec un expert (avocat) pour prendre l’avantage dans le litige

Même si vous avez des preuves, vous serez désavantagé si le juge ne comprend pas la pertinence du développement. L’ingénieur ne doit pas tout déléguer en pensant « ils comprendront », mais doit collaborer avec un avocat spécialisé en informatique et expliquer patiemment l’historique du développement. Une consultation précoce peut également aider à éviter un procès.

Une fois les preuves réunies, il est nécessaire de rédiger un rapport clair et compréhensible pour le juge. Les ingénieurs ont tendance à tout déléguer à l’avocat en pensant « il devrait comprendre ça ». Cependant, cette façon de penser est très dangereuse.

Seules les parties concernées connaissent le contexte et l’historique du développement. Les conversations entre développeurs sont généralement incompréhensibles pour un tiers. C’est la même chose même pour un expert externe.

L’ingénieur doit expliquer patiemment à l’avocat la pertinence de son travail. Le juge, en raison de l’asymétrie d’information, n’est pas nécessairement du côté de l’ingénieur. Il est crucial d’être toujours conscient du risque de litige et de s’y préparer. Et consultez rapidement un avocat spécialisé en informatique. Cela augmentera les chances d’éviter un procès.