Les contrats d’intégration de système dans le domaine informatique ou le paradoxe de l’œuf et de la poule

Obligation de délivrance à la charge du vendeur, conformité de la prestation à l'accord des Parties, réception de l'ouvrage à la charge du client, comment préparer puis négocier les contrats pour la mise en œuvre d'un système informatique complexe pour éviter les dérapages et contentieux.

Un client (les sociétés susceptibles d’être concernées se reconnaîtront) souhaite s’équiper d’un logiciel d’entreprise quel qu’il soit (CRM, SIRH, ERP ...). Pour cela, il souhaite ce qu’il y a de mieux sur le marché, selon sa taille, son besoin, ses capacités financières … Souvent, et ce même s’il dispose d’une équipe interne, il pense (et c’est souvent judicieux) qu’il vaut mieux être accompagné d’un professionnel pour mettre en place et faire fonctionner le produit retenu. Pour ce projet, généralement important voire stratégique pour son fonctionnement, il va donc faire appel à un éditeur et à un intégrateur. A noter qu’il est aujourd’hui rare que le client ne contractualise qu’avec un seul partenaire (l’éditeur ou l’intégrateur).
La phase qui précède le choix par le client et la formalisation de son accord est la phase où il importe de challenger les candidats non seulement sur leurs capacités respectives mais encore et surtout sur leurs capacités et volontés à interagir pendant la phase de mise en place puis de fonctionnement de la solution finale. Plus encore, le système d’information du client, même incomplet, immature, construit de bric et de broc au fur et à mesure de l’évolution du client doit être pris en compte (ainsi que les intervenants externes qui l’ont éventuellement construit, le font évoluer et/ou le maintiennent en condition de marche). Dès cette phase, loin de se contenter du « quoi faire pour que tout se passe bien dans la mise en place » il importe déjà de se poser les questions du « quoi faire en cas de problème en fonctionnement ». « Gouverner c’est prévoir », qui que soit celui qui a originellement prononcé ou écrit ces termes , cette maxime doit être faite sienne par tout chef d’entreprise ou de projet.
Ainsi, s’interroger sur ce qui se passera si le logiciel de l’éditeur « bouge » pendant la phase de mise en place de la solution (évolution mais aussi correction), comment l’intégrateur prendra en compte ce(s) mouvement(s) et à quelles conditions y compris pendant la phase de garantie est indispensable.
C’est une évidence mais la solution n’est pas encore en fonctionnement réel qu’elle a déjà changé. S’arcbouter pour obtenir une garantie que l’on pose généralement comme devant être gratuite, alors qu’elle sera, bien normalement, intégrée au coût de mise en œuvre et disparaîtra (sans que le coût en soit alors déduit puisqu’elle est gratuite …) dès que la solution aura bougé, n’est pas nécessairement la panacée, surtout que bien souvent, les équipes du client oublient de se préoccuper, à ce stade avant-vente, de la manière dont elles vont contrôler la conformité de la solution aussi bien en test qu’en réel. La recette est souvent vue comme devant être traitée une fois le projet démarré. Malheureusement si le client n’a pas posé et défini dès l’origine sa volonté d’effectuer des contrôles avant la mise en production mais également après la mise en production en tenant compte des finalités de la solution (ex : pour un ERP, il peut être intéressant d’envisager notamment le passage d’une clôture réelle dans la phase de recette) lorsqu’il évoquera ce point, une fois son accord donné, il y a fort à parier que l’intégrateur lui rétorquera, à juste titre d’ailleurs, qu’il n’a pas prévu de mobiliser son équipe projet une fois les tests avant mise en production positifs et que ce point sera vu avec la maintenance. Rappelons qu’une fois en phase de maintenance, le contrôle de conformité est achevé et la jurisprudence des tribunaux français est assez unanime pour reconnaître que le client ne peut plus (ou beaucoup moins facilement) s’appuyer sur un défaut de conformité pour obtenir soit la résolution du contrat soit, à tout le moins, l’indemnisation du préjudice subi par ce qu’il considère comme une non-conformité.

Pour compliquer le tout, le temps du logiciel et de son éditeur n’est pas le temps de la solution et de l’intégrateur. Pour l’éditeur, « le produit livré [au client] correspond à un logiciel standard commercialisé par le biais de …[l’intégrateur] et pour lequel elle [l’éditeur] n’était pas tenue de réaliser une prestation de cadrage, d’accompagnement ou de réalisation de développements spécifiques… » . A compter de l’acquisition du logiciel, si le logiciel est installé chez le client ou de souscription de l’abonnement SaaS, l’éditeur va assurer la maintenance du logiciel. C’est-à-dire que bien avant que la solution soit même conçue par l’intégrateur, le logiciel aura « bougé ». Si ce décalage n’est pas prévu contractuellement, il est très probable que l’intégrateur n’acceptera pas de prendre à sa charge ce mouvement au sein de la solution, ce même (et surtout) si elle n’est pas encore réalisée et acceptée par le client. Le client peut donc se trouver face à un problème quasi inextricable : le logiciel est conforme aux engagements de l’éditeur et ne présente aucun vice de conception, l’intégrateur a réalisé la prestation conformément à ce qui était convenu MAIS la solution ne fonctionne pas, totalement ou partiellement.
Devant un tel problème, le client, dont l’objectif premier est que sa solution fonctionne, ne va généralement pas, en 1er ressort (voire même en dernier ressort), envisager d’intenter une action en justice. Il va tenter d’obtenir d’un côté et/ou de l’autre, la résolution de son problème et il a toutes les chances de se sentir comme « une boule de flipper » allant dans toutes les directions en fonction des contacts qu’il a avec les parties prenantes (éditeur, intégrateur mais aussi utilisateurs internes ou externes, autres fournisseurs impactés …) et surtout son projet risque de coûter beaucoup plus cher et de prendre beaucoup plus de temps que prévu. Encore un projet informatique qui ne manquera pas de valider les études successives sur l’échec des projets informatiques publiées par le Standish Group et qui ne contribuera pas à redorer le blason des éditeurs et intégrateurs informatiques auprès des clients.
Néanmoins, il est faux de penser (comme c’est le cas de beaucoup de clients fatalistes) que cela est inhérent à tout projet informatique et que c’est un fatum qu’il faut malheureusement accepter. La dérive des projets est très souvent évitable mais cela impose de ne surtout pas négliger le temps à passer à l’étude de ses besoins, de l’adéquation des offres à ses besoins, des interactions entre les fournitures, prestations … et surtout de définir clairement les processus qui permettent d’aboutir à la solution (notamment ceux de contrôle de conformité) en n’oubliant pas d’associer un juriste expérimenté dès l’origine du projet (et surtout pas seulement quand il s’agit de relire le contrat « proposé » par les fournisseurs). Le temps et l’argent que l’on pense perdre à cette étape (généralement euphorique) est, d’expérience, du temps et de l’argent gagnés au terme du projet.
Octobre 2023

(1) Maxime attribuée à A Thiers ((1797-1877) ou aussi à Émile de GIRARDIN (1806-1881)
(2) Cour d’Appel de Paris – Pôle 5 Chambre 11 - 09 septembre 2022- n°21/01844
(3) https://www.opendoorerp.com/the-standish-group-report-83-9-of-it-projects-partially-or-completely-fail/