Anticiper les risques d’échec en optimisant les contrats et mieux gérer les contentieux à l’aune de l’expertise judiciaire et de l’indemnisation des préjudices

Anticiper les risques d’échec en optimisant les contrats et mieux gérer les contentieux à l’aune de l’expertise judiciaire et de l’indemnisation des préjudices

Article rédigé par Olivier Pignatari, Avocat IT/IP et Docteur en droit

Temps de lecture : 5mn| Numérique

Précautions à prendre avant la contractualisation

 

Un projet informatique mal défini est souvent synonyme d’échec. Aussi, le client doit-il se ménager un temps suffisant pour bien préparer l’appel d’offres et formaliser clairement ses besoins et objectifs dans le cahier des charges qui exposera notamment l’existant, le contexte métier/marché, les contraintes techniques et organisationnelles entourant la mise en place de la solution, le périmètre fonctionnel du projet, le calendrier et les éventuelles dates impératives, les ressources alloués au projet, les performances attendues, les objectifs commerciaux et financiers ou encore les conséquences d’un éventuel échec.

Ce document peut également prévoir une liste de prérequis juridiques (maîtrise d’œuvre, obligations de résultat, limites de responsabilité, pénalités, propriété intellectuelle, droit applicable et tribunaux compétents, etc.) sur lesquels les candidats devront se positionner, ce qui simplifiera et accélérera les négociations avec le candidat retenu.

Les candidats pourront également être amenés, dans le cadre de leur réponse à appel d’offres, à fournir les documents techniques suivants :

 

  • un projet de plan d’assurance qualité (PAQ) précisant notamment :
    • la méthode de gestion de projet envisagée (« Agile » ou « cascade »),
    • les grandes phases du projet,
    • l’organisation humaine du projet (ressources/profil),
    • les phases et procédures de recette,
    • la gestion des risques et des problèmes rencontrés,
    • les niveaux de services,
    • la composition/périodicité/rôle des instances de gouvernance, etc.
  • la description des prestations envisagées,
  • la répartition des tâches entre le candidat, le client et d’éventuels intervenants tiers (sous-traitants, éditeurs, hébergeurs, tiers-mainteneur, etc.) formalisée dans une matrice de responsabilité (RACI)

 

On perçoit l’importance du cahier des charges qui, en cas de litige, permettra de comprendre ce qu’attendait le client et de mesurer les engagements du prestataire.

Cela étant, le client attend souvent des fonctionnalités qui, en réalité, ne sont pas couvertes par la solution proposée ou bien ne sont pas portées à la connaissance du prestataire et, in fine, ne sont pas comprises dans le périmètre.

Pour éviter ce type de malentendu, le client doit donc, en phase d’avant-vente, exprimer clairement ses besoins et objectifs fonctionnels, les partager avec le prestataire qui, se son côté, lui fournit une information circonstanciée et personnalisée, notamment sur l’aptitude de sa solution à l’utilisation prévue, sur son adéquation au regard des fonctionnalités proposées ou encore sur son possible interfaçage avec la configuration du client, etc.

 

Précautions à prendre au stade de la contractualisation

 

La contractualisation d’un projet informatique est essentielle à son succès : elle permet aux parties d’encadrer les enjeux financiers ainsi que l’organisation du projet et de régir leurs responsabilités respectives.

 

Un contrat informatique équilibré

 

La réussite du projet nécessite une étroite et permanente collaboration entre les parties, ce qu’un contrat déséquilibré ne permet a priori pas. Tout en défendant leurs intérêts propres, chaque partie doit donc veiller à ce que les termes du contrat préservent, d’une certaine manière, les intérêts de son cocontractant. En effet, un contrat négocié dans un esprit « gagnant/gagnant » devrait permettre une collaboration entre les parties et limiter ainsi les situations de blocage en phase de réalisation.

 

Un contrat informatique adapté

 

Le contrat doit être adapté à la complexité du projet ainsi qu’à la nature des prestations à délivrer. Dans le cadre d’un projet d’envergure, de type intégration, les parties auront tout intérêt à prévoir une phase préalable de cadrage général.

Celle-ci se concrétisera par des ateliers d’analyse technique et fonctionnelle qui permettront aux parties de synchroniser leur vision des processus cible, de partager leurs contraintes respectives ou encore de s’entendre sur les livrables attendus pour chaque jalon. Il est d’ailleurs recommandé, lorsque l’organisation du client le permet, d’y impliquer les métiers, ces derniers ayant souvent des attentes particulières qui ne sont pas toujours exprimées dans le cahier des charges initial. Le client pourra ainsi affiner ses besoins tandis que le prestataire s’assurera de leur bonne compréhension et mesurera l’aptitude de sa solution à y répondre. Autant de précautions qui faciliteront l’adéquation entre le résultat et l’attendu et éviteront des retours en arrière en conception voire en phase de réalisation, limitant ainsi le risque de dérive.

Le contrat doit en outre tenir compte de la méthode de projet (« cascade » ou Agile), sous peine d’être inadapté et de rendre son exécution délicate, voire impossible. Le contrat doit également être clair sur le type de prestations attendues (développements spécifiques, intégration de logiciels, paramétrages, hébergement, maintenance, etc.) ainsi que sur le phasage du projet et les livrables associés, toute ambiguïté sur ces points pouvant générer des désordres.

 

Enfin, le périmètre des prestations confiées au prestataire doit être clairement défini : pour cela, les parties peuvent y exclure expressément certains services. Ainsi, le client reçoit une information adéquate sur les limites du périmètre d’intervention de son prestataire tandis que ce dernier sera protégé en cas de griefs formulés à son encontre pour des manquements à des engagements qu’il n’aurait précisément pas pris.

 

Précautions à prendre au stade de l’exécution du contrat informatique

 

L’exécution d’un projet informatique renferme son lot d’imprévus et d’incidents, sources potentielles de désaccords, voire de contentieux. Certains réflexes devraient toutefois permettre d’en limiter le risque et, lorsqu’il survient, de mieux s’y préparer.

 

Comment limiter le risque de contentieux informatiques ?

 

Les contentieux informatiques naissent, le plus souvent, d’un manque de collaboration, d’incompréhensions entre les parties ou encore d’une défaillance dans l’organisation du projet. Pour permettre au projet d’aboutir, les parties devront donc collaborer de façon étroite et permanente.

Elles devront également appliquer rigoureusement le PAQ ainsi que les procédures prévues (escalade, recette, signalement, gouvernance, etc.). Les parties ont en effet souvent tendance à traiter les difficultés par l’envoi – prématuré – de courriers recommandés entre directions générales plutôt que de les aborder dans le cadre des instances de pilotage dont le rôle est de remonter et qualifier les problèmes, de les tracer et de procéder aux arbitrages nécessaires.

 

Comment anticiper le risque de contentieux ?

 

Que l’on soit côté client ou prestataire, il est fondamental de réunir et conserver les éléments de preuve susceptibles d’être soumis à un expert (en cas d’expertise avant-dire droit) ou à un juge (en cas d’action en justice) et qui permettront d’établir la réalité des prestations ainsi que l’historique des échanges intervenus avant et pendant le projet (demande de précisions, alertes remontées en comité, échange de mails/courriers, PV de recette, etc.). En effet, un grief qui n’est pas notifié à la partie adverse durant le projet et/ou qui n’est corroboré par aucune pièce datée au moment des faits ne pourra pas être valablement invoqué pour caractériser un manquement.

De même que, pour être exploitables, les comptes-rendus de comités doivent décrire le désordre rencontré, rappeler les circonstances de sa survenance, qualifier son niveau de criticité, préciser ses éventuelles conséquences sur le projet et, le cas échéant, exposer le plan d’actions proposé pour y remédier.

S’agissant des preuves techniques, il est conseillé aux parties de réaliser, lorsque cela est possible, une sauvegarde du système d’information et/ou de l’application incriminée dans sa version existante au moment des faits litigieux. A défaut, les tests réalisés dans le cadre d’une expertise judiciaire avec un matériel ou à partir d’une configuration différente de ceux utilisés à l’époque des faits pourrait affaiblir la demande, voire rendre impossible la démonstration du grief[1].

 

Idéalement la sauvegarde doit être contradictoire, et ce pour éviter que sa valeur probante ne soit remise en cause par l’autre partie qui aura beau jeu d’en contester l’origine, l’authenticité ou encore la complétude ainsi que l’intégrité des fichiers sauvegardés. Cela étant, un expert pourra examiner une sauvegarde non contradictoire, qui conservera une utilité probatoire, dès lors qu’elle sera soumise à la libre discussion des parties et de l’expert. A noter toutefois qu’un expert judiciaire ou un juge ne pourra se fonder exclusivement sur une sauvegarde non contradictoire.

Les parties auront également intérêt à faire constater par PV de Commissaire de Justice les dysfonctionnements rencontrés : même s’il ne permettra pas à lui seul d’imputer les désordres à l’une ou l’autre des parties, un tel document aura une utilité en cas de litige, notamment pour établir la réalité des désordres et justifier que soit ordonnée une mesure d’expertise.

L’intérêt de préparer en amont un dossier probatoire est d’autant plus grand que les ressources mobilisées sur le projet (surtout pour les projets à longue durée) auront, entre temps, quitté l’entreprise. La conservation des éléments ainsi collectés sera utile dans le cadre d’une expertise et/ou d’un contentieux judiciaire, les parties disposant le moment venu de la « mémoire » du projet.

 

Préparer un contentieux suppose de s’atteler au volet indemnitaire. S’il est possible d’obtenir une réelle indemnisation, encore faut-il disposer d’un dossier indemnitaire robuste et documenté (tant sur l’identification des chefs de préjudices que sur le chiffrage des dommages). Pour cela, les parties doivent mobiliser en interne les expertises du chiffre (comptabilité et finance) et, éventuellement, recourir à un cabinet d’experts spécialisés en chiffrage de préjudices.

Ces précautions seront utiles, que ce soit pour parvenir à un règlement amiable (cela constitue un levier de négociation pour inciter l’autre partie à transiger), ou dans le cadre d’une procédure judiciaire (les tribunaux exigeant la communication de pièces probantes à l’appui des demandes indemnitaires).

 

Comment gérer une expertise judiciaire ?

 

La sophistication croissante des architectures techniques ainsi que la multiplicité des acteurs (fabricant, éditeur, intégrateur, maître d’ouvrage et assistant au maître d’ouvrage, etc.) et l’intrication de leurs rôles et responsabilités rend les litiges informatiques de plus en plus complexes. Dans ce contexte, l’expertise est une étape quasi incontournable : elle permet aux parties, avant d’engager une éventuelle action au fond, d’obtenir un éclairage objectif et technique sur la réalité et la qualité des prestations, sur la gestion du projet ou encore sur l’évaluation des préjudices. L’expertise est également utile au Tribunal qui pourra apprécier le contentieux à la lumière des conclusions de l’expert.

Dans le cadre des opérations d’expertise, les parties sont assistées de leur avocat (spécialisé en IT), de leur DSI, des équipes mobilisées sur le projet et, en fonction des enjeux et de la technicité du dossier, d’un expert informatique privé.

Les parties s’échangent des Dires exposant leurs griefs respectifs. Ceux-ci doivent être rattachés à un référentiel de conformité (contrat, cahier des charges, PAQ, etc.), documentés (CR de COPIL, mails, PV de recette, extraction JIRA, journaux de connexion, etc.) et datés.

Au terme de l’expertise, l’expert remet son rapport définitif qui est précédé d’un pré-rapport ainsi que d’un Dire récapitulatif rédigé par chaque partie et qui reprenant de manière synthétique l’ensemble des observations, griefs et réclamations antérieurs.

Si l’avis de l’expert consigné dans le rapport définitif ne lie pas le Tribunal, il constitue néanmoins un document dont le juge fera grand cas.

 

Enfin, si l’expertise a été ordonnée dans le cadre d’une action au fond, les parties devront, après avoir pris connaissance du rapport, conclure au fond en exploitant les passages du rapport qui leur sont le plus favorables. Dans le cadre d’un référé-expertise, le demandeur à l’expertise pourra, en fonction des conclusions du rapport, décider de déclencher ou non une procédure au fond.

[1] CA Aix-en-Provence, 2e ch. 22 janv. 2015, n° 12/11557.

Vous avez aimé l’article ? 

N’hésitez pas à le partager et à nous suivre sur nos réseaux sociaux pour en apprendre plus