Intégration de système, anticiper les risques pour mieux les éviter (A propos de l'arrêt Faurecia / Oracle, C. Cass. 13 février 2007)

Il est assez rare qu’un contentieux lié à un projet informatique parvienne jusqu’à la Cour de cassation. L’aspect factuel et technique de ce type de contentieux induit souvent de longues expertises, pour des litiges tranchés devant les juridictions du premier et du second degré, ou transigés entre temps.

Pourtant, la récente décision de la chambre commerciale du 13 février 2007, dans l’affaire Faurecia / Oracle, a ravivé à la fois les questions des groupes de contrats et celles des clauses limitatives de responsabilité, en illustrant toute la complexité d’un grand projet informatique et la nécessité d’une communication optimale entre les parties au(x) contrat(s).

En l’espèce, quatre contrats conclus par Faurecia avec la société Oracle portaient sur un progiciel d’intégration, des licences de logiciels tiers, ainsi que des prestations de mise en œuvre, de maintenance et de formation.

Le progiciel Oracle, retenu par Faurecia en 1997, devait permettre les activités de gestion de production et de gestion commerciale. En outre, furent signés trois autres contrats portant sur des prestations de mise en œuvre du progiciel (développements spécifiques et paramétrages de l’ERP), de licence, de maintenance et de formation.
Le progiciel ne donnant finalement pas satisfaction, Faurecia a engagé une procédure afin d’obtenir la résolution pour inexécution de l’ensemble des contrats.

La Chambre commerciale a cassé l’arrêt de la Cour d’appel, au motif qu’elle avait admis l’application des clauses limitatives de responsabilité d’Oracle et limité en conséquence les sommes dues par Oracle à son client. Sur le fondement de l’article 1131 du Code civil, la Cour de Cassation a jugé qu’il n’y avait pas à rechercher la faute lourde du fournisseur dès lors qu’avait été constaté que celui-ci n’avait pas livré le logiciel qu’il s’était engagé à livrer, sans que puisse être évoqué un cas de force majeur. Oracle a ainsi manqué à une obligation essentielle, celle de la délivrance de la chose promise – inscrivant l’arrêt Faurecia dans le mouvement jurisprudentiel initié par l’arrêt Chronopost.

La Cour a par ailleurs repris le raisonnement des juges d’appel et a souligné que ces contrats « poursuivaient tous le même but et n’avaient aucun sens indépendamment les uns des autres, les prestations de maintenance et de formation ne se concevant pas sans les licences sur lesquelles elles portaient et l’acquisition de ces licences par la société Faurecia n’ayant aucune raison d’être si le contrat de mise en œuvre n’était pas exécuté (…) ».

Allant plus loin, la Cour a estimé que le prestataire n’avait pas à être informé du caractère indivisible des prestations dans l’esprit du client, dès lors qu’il est également signataire de tous les contrats.

Il semble donc, au regard de cet arrêt, que l’indivisibilité des contrats de prestations informatique se déduise de leur finalité commune, à partir du moment où ils sont conclus avec un seul et unique prestataire. En cas de pluralité de prestataires en revanche, le client devrait alors très certainement préciser sa volonté de concevoir leurs interventions comme un ensemble homogène répondant à un objectif unique.

Cet arrêt illustre une certaine sévérité à l’égard des prestataires, malgré la généralisation de l’informatique dans l’entreprise et la spécialisation croissante de leurs DSI. : le respect des délais contractuels a intégré l’obligation de délivrance conforme (CA Paris 25e, 2 septembre 2005), et l’obligation de délivrance conforme est devenue une obligation essentielle (Cass. Com 13 février 2007 Faurecia).

Comment expliquer cette sévérité ? Les projets informatiques sont des projets éminemment stratégiques : ils conditionnent la productivité de l’entreprise, l’organisation de ses ressources, la gestion de ses flux. Le choix et l’implémentation d’un ou plusieurs progiciels au sein d’un système d’information sont donc particulièrement sensibles.

Il en résulte un grand nombre de précautions à observer, sur le plan technique, et sur le plan contractuel, comme le montre l’arrêt Faurecia. Une informatisation ou la modernisation d’un système doivent s’envisager comme une unique opération d’envergure, qui implique une définition optimale des besoins et du contexte de production, en amont, ainsi qu’une conduite du changement rigoureuse.

Ces précautions sont autant le gage de la réussite du projet d’informatisation, que des garanties en cas de dérive et de contentieux subséquent. Le contrat est par excellence l’occasion d’exprimer les besoins, d’anticiper les risques, d’organiser le déroulement des opérations d’informatisation, et d’envisager les conséquences d’un retard ou d’un échec dès lors que le projet concerne l’appareil de production de l’entreprise.

L’arrêt Faurecia est également une excellente occasion de rappeler les précautions rédactionnelles à observer avant de lancer un projet informatique important. Car si l’obligation de conformité du logiciel livré, on l’interdépendance des contrats ont provoqué la condamnation d’Oracle, bien d’autres écueils peuvent mettre un terme prématuré à une opération d’intégration de système.

Le projet peut en effet recouper bien des domaines techniques. Il convient donc d’effectuer un recensement précis des besoins fonctionnels de l’entreprise, ainsi que ses objectifs en termes de performances, et surtout, on le constate, la dimension du projet (intégration, licences et services informatiques faisant alors partie d’un ensemble cohérent, pour un nombre d’utilisateurs précis).

A cette « introspection » doit correspondre une étude de marché, afin de sélectionner le ou les progiciel(s) susceptible(s) de couvrir ces besoins. Il s’agit là d’une étape critique, où réside l’origine de nombreux contentieux. L’expression des besoins est cruciale, qu’il s’agisse de choisir un ERP ou de commander le développement d’un logiciel spécifique à l’entreprise. Il est donc important que celle-ci synthétise ses pré-requis dans un document techniquement et juridiquement valide, exhaustif, au besoin en sollicitant l’assistance d’un professionnel.

Ces besoins doivent être définis le plus précisément possible, dans une optique dynamique. En effet, trop d’entreprises se contentent d’un bilan de leurs besoins au moment où elles lancent le projet, et font ensuite évoluer le périmètre de ces besoins.

Rien n’est plus facile alors pour le prestataire de dénoncer un manque de définition des besoins, imputable aux choix trop peu prospectifs du client. Celui-ci doit donc prévoir les hypothèses d’évolution de ses demandes, de montée en charge, de volumétrie… Il doit calquer l’expression de ses besoins informatiques sur ses perspectives de développement commercial et/ou industriel.

Le cahier des charges, document stratégique, doit intégrer le périmètre fonctionnel, mais aussi la durée du projet et les exigences de performances. Il doit expliciter l’environnement d’implémentation, souligner toute particularité organisationnelle de l’entreprise, mais également traiter du transfert des droits de propriété intellectuelle sur d’éventuels développements spécifiques, des prérogatives obtenues sur les codes sources, ou encore des conditions de garantie et de maintenance.
 
Le cahier des charges doit également présenter la dimension du projet, et prévoir notamment les modalités du déploiement d’une solution informatique, sur un réseau de points de vente par exemple. Doit apparaître la volonté du client de concevoir le projet comme une opération unique, en particulier en cas de pluralité de prestataires. Les diligences des uns seront donc expressément liées aux diligences des autres.

Les questions à se poser sont donc très nombreuses : y a-t-il des dates clés ou des objectifs chiffrés ? Est-ce un contrat « clef en main » ou un ensemble de contrats spécifiques ? Le cas échéant, ces contrats contribuent-ils à une objectif unique ? Quels seront les éventuels sous-traitants impliqués, leurs responsabilités et leurs liens ? Quels sont les flux financiers et de facturation de l'opération ? Y a-t-il une cession globale des droits de propriété intellectuelle ? Comment assurer la pérennité de la solution mise en œuvre ? Qui en assure la maintenance ? Comment s'organise sa réversibilité ?

Mais l’essentiel d’une prestation aussi complexe que l’informatisation ou la modernisation d’un système, si elle fait intervenir plusieurs prestataires, est de déterminer une maîtrise d’œuvre.

Car si l’arrêt Faurecia illustre une certaine bienveillance envers le client qui signe plusieurs contrats avec un même prestataire, il faut considérer qu’il en irait différemment en cas de pluralité de prestataires. Le client doit alors expressément mentionner son intention de lier l’ensemble des contrats. La maîtrise d’œuvre est l’instrument idéal.

Qu’il s’agisse de l’intégration et du déploiement d’un progiciel de gestion de flux, ou d’une externalisation des opérations informatiques de l’entreprise par exemple, la pluralité de prestataires induira l’organisation optimale de leurs interventions. Le prestataire chargé de cette tâche particulière de maîtrise d’œuvre devra constituer l’interlocuteur juridique unique du client, et assumer une charge supplémentaire en matière de conseil, d’organisation et de reporting. De plus en plus, la maîtrise d’œuvre a donc un coût.

Prestations techniques, modalités juridiques, encadrement du planning et gestion des dérives, le ou les contrat(s) signés pour un grand projet informatique doit ensuite envisager toutes les hypothèses, ou à tout le moins prévoir un mode de résolution des difficultés fondé sur des procédures d’alerte et un mode de concertation efficaces et rapides.
Dès lors que le projet informatique s’étale dans le temps, il est capital que les difficultés aient été anticipées (anomalies des développements, retard d’installation, non-conformité des livrables, performances insatisfaisantes, etc.), et que leur résolution s’inscrive dans un processus déjà rôdé.

Par ailleurs, les utilisateurs de la solution au sein de l’entreprise, doivent être impliqués dans le projet dès son évocation en interne : depuis la définition des besoins fonctionnels jusqu’aux tests en production, ils sont ceux qui sont le plus à même d’exprimer la satisfaction de l’entreprise.

Pour chaque phase du projet, le contrat doit envisager le degré d’exigence du client. Chacun des engagements des cocontractants doit être défini : obligation de moyen, de résultat, voire garantie spécifique, en passant par des obligations renforcées (ou « essentielles ») doivent conférer une certaine automaticité dans la qualification de tout évènement affectant le projet, et dans son traitement par chacune des parties.

Un « plan d’assurance qualité » ou une « charte de projet » viennent ici compléter le cahier des charges.
Le planning doit idéalement comporter des phases, comportant lots et livrables répartis par types de prestations (livraison, installation, validations unitaires, développements spécifiques, migration des données, connexion au réseau, intégration des logiciels et du matériel, interfaçage et paramétrage, réception d’ensemble, déploiement, hébergement, exploitation des flux, formation, garanties, maintenance et hotline, sécurité du système, entretien de la documentation, etc.).

A la phase de spécification fonctionnelle, servant à préciser le cahier des charges et qu’il est conseillé au client de valider, peut donc succéder une période de développement logiciel, par lots ou par phases, comportant chacune une recette unitaire. Les conditions de cette recette doivent être formelles, afin qu’aucune anomalie majeure ne traverse ce stade.

Le projet peut ensuite comporter, selon sa nature, une phase d’intégration, suivie d’une recette d’intégration qui décidera de la conformité globale des prestations. Il s’agit d’une phase très délicate en cas de pluralité de prestataires. Si le périmètre de l’intervention de chacun n’a pas été clairement défini (connexions, reprise des données, etc.) ou scrupuleusement contrôlé par le maître d’œuvre, chacun aura tendance à rejeter sur les autres la responsabilité d’un éventuel dysfonctionnement.

Les procédures d’arbitrage peuvent être fastidieuses, et le projet prend un retard aussi exponentiel que le préjudice subi par le client – et parfois même par le prestataire qui lui alloue de plus en plus de ressources.
C’est souvent là l’occasion pour le prestataire de mettre en défaut le client qui n'a pas évalué clairement ses besoins, exprimé ses contraintes particulières, qui a élargi le périmètre ou écourté les délais, ou qui n'a pas collaboré activement à chacune des phases.

Côté client, c’est le moment d’émettre tout grief contre le prestataire qui n'a pas respecté le cahier des charges ou le plan d'assurance qualité, qui a fait déraper les délais ou les coûts, qui a mal encadré ses sous-traitants ou manqué à son obligation de conseil et d’alerte en cas de dérive.

Le contrat doit permettre au client de souligner toute défaillance dans la correction des anomalies graves ou bloquantes identifiées lors de la recette, d’autant que l’évolution de la jurisprudence tend à ériger la délivrance de la chose conforme et le respect des délais en obligations essentielles, comme l’a montré l’arrêt Faurecia.

Une fois le système recetté et mis en production, les conditions de son déploiement, de sa garantie et de sa maintenance doivent être parfaitement claires, afin d’éviter qu’une solution efficace ne se brise sur un suivi anarchique. Là encore, les niveaux de qualité (planning de déploiement, rythme de basculement des systèmes locaux, délais d’intervention de maintenance, délais de correction, fréquence des mises à jour, etc.) doivent être précisés dans le contrat.

Les clauses de propriété intellectuelle doivent stipuler, en cas de licence d’utilisation, l’étendue et la portée ainsi que la liste précise des droits concédés. En cas de cession, elles doivent alors distinguer les éléments composant la solution en précisant s'ils étaient ou non préexistants au contrat : logiciels standards, développements spécifiques, interfaces, paramétrages, dossiers de conception, documentation, données, bases de données, outils de développement, méthodes et savoir-faire.

Les garanties comportent nécessairement la garantie d’éviction, pour les livrables cédés ou accordés en licence, ainsi que les garanties contractuelles que les prestataires auront accepté d’assumer.

Les conditions de mise en jeu de la responsabilité du prestataire sont également capitales, et l’arrêt Faurecia démontre que celui-ci ne peut pas toujours se réfugier derrière des clauses limitatives, en cas de faute lourde naturellement, ou en cas de manquement à son obligation de délivrance conforme.

Compte tenu de la complexité d’un système informatique, ou du caractère stratégique d’un ERP, le contrat doit impérativement prévoir la réversibilité des prestations, surtout en cas d’externalisation. Le sort des données de l’entreprise doit être traité, les conditions d’accès aux codes sources doivent être explicitées, et le ou les prestataires doivent collaborer pleinement à la reprise des prestations par tout tiers désigné par le client. Il en va d’ailleurs de même pour la maintenance des logiciels installés, pour le cas où leurs éditeurs ne souhaitent ou ne peuvent plus l’assurer.

La mise en œuvre d'une solution informatique est souvent considérée par les clients comme une prestation globale. Il importe alors que le ou les contrat(s) reflètent cet état d’esprit, en imposant par exemple la maîtrise d’œuvre évoquée plus haut, ou encore en liant expressément l’exécution des différents contrats signés. Il doit être rappelé que l’indivisibilité reconnue par la chambre commerciale le 13 février 2007 doit tout au fait que le client avait signé l’ensemble des contrats avec un unique prestataire.

Mais en cas de pluralité d’intervenants, chacun d’entre eux doit être conscient des implications de sa défaillance. Le client cherchera donc à porter à sa connaissance tout préjudice pouvant découler de sa prestation, en particulier le retard ou l’échec du projet dans son ensemble – à charge pour ce prestataire de limiter sa responsabilité efficacement.
Compte-tenu du caractère technique des dysfonctionnements et des difficultés d'évaluation des préjudices (investissements engagés, ressources immobilisées, audits, solutions de contournement, perte d'exploitation ou d'image, etc.), la pratique des expertises judiciaires, privées ou amiables, augmente. Celles-ci sont l'occasion pour chacune des parties de revenir avec l'expert sur l'ensemble du projet, depuis les travaux préparatoires et l'appel d'offres. Chaque document technique, contrat, annexe, courrier, e-mail ou PV de comité a donc toute son importance dans la stratégie de demande ou de défense.

L'expérience montre que les clients, même profanes en matière de projets informatiques, font des efforts de rationalisation afin de pouvoir faire valoir leurs droits face aux éditeurs, intégrateurs ou prestataires. Les entreprises ont pris conscience de l’importance d’une définition des besoins complète et détaillée, et les prestataires savent le prix de leurs obligations de conseil. L’arrêt Faurecia est venu illustrer l’encouragement que la jurisprudence apporte à cette tendance.