Comprendre et maîtriser la variété des contrats informatiques

• Les contrats informatiques sont une catégorie de contrats particuliers qui, bien que ne faisant pas l'objet d'un droit spécifique, sont soumis à énormément d'exigences et de concepts tirés de la pratique, que le rédacteur doit appréhender.

• Le système d'information de l'entreprise soutenant l'ensemble de ses activités, il est crucial que les contrats négociés par l'entreprise lui apportent une protection optimale, et l'aident à respecter les réglementations afférentes, ce même lorsque les fournisseurs présentent des contrats d'adhésion auxquels il peut sembler difficile, de prime abord, d'apporter des modifications.

• Licence et maintenance de logiciel, hébergement de données, intégration de systèmes, acquisition de service cloud, licence de base de données, infogérance, assistance technique... comment naviguer au sein de ces nombreuses figures et comment définir, rédiger et négocier LE contrat pertinent ?

Temps de lecture estimé : 20 minutes

L’informatique est au cœur des activités de l’entreprise, et celle-ci doit recourir à des prestataires afin de s’équiper en matériels, logiciels et de plus en plus, en services cloud. L’externalisation et la virtualisation des systèmes d’information se poursuit, et on est loin, aujourd’hui, des quelques modèles initiaux qui étaient signés dans les années 90 (licences de logiciel, contrats d’hébergement et contrats « ASP » pour « application service provider » - les prémices du cloud).

Il est important pour l’entreprise de savoir identifier les contrats qui sont nécessaires en fonction de ses besoins, et d’en comprendre à la fois la nomenclature et les caractéristiques propres.

Nous n’examinons ci-dessous que les principales caractéristiques de chaque type de contrat, mais il est évident que chacun comporte un grand nombre de particularismes en fonction notamment des besoins du client, des compétences du prestataire, de l’objet du contrat, du contexte d’utilisation de la solution numérique, et des évolutions réglementaires (relatives par exemple à la cybersécurité, aux données ou à l’IA), autant de problématiques qui ne sont pleinement appréhendées que via une solide expérience de la négociation des contrats informatiques.

Pour cela, le praticien doit maîtriser les concepts techniques, et selon la partie pour laquelle il intervient, comprendre les spécificités du projet du client et/ou comprendre la nature et les limites des services proposés par le prestataire, afin d’encadrer contractuellement tous les tenants et aboutissants d’un projet ou d’un service qui est le plus souvent vital pour l’entreprise.

 1. Le contrat d’achat de matériel

Il s’agit d’une vente : l’entreprise acquiert des matériels (PC, serveurs, terminaux mobiles, etc.) que ses salariés utiliseront quotidiennement pour exécuter leurs fonctions et traiter les données.

Ces contrats sont classiques, généralement bien bordés, mais impliquent de sécuriser la cession de propriété et le transfert des risques. En outre, ils posent essentiellement trois questions : l’utilisation des logiciels dont le « hardware » est équipé nativement, la garantie et la maintenance.

L’utilisation des logiciels embarqués (OS, antivirus, applications) implique que le contrat comporte une licence (cf. infra, le contrat de licence logicielle "propriétaire") qui prévoit en particulier leurs mises à jour (par téléchargement), aux fins en premier lieu de préserver leurs performances et d’assurer leur sécurité.

Les garanties liées aux contrats de vente s’appliquent, dont la garantie des vices cachés, à laquelle les constructeurs ajoutent souvent une garantie de bon fonctionnement limitée dans le temps (gratuite ou payante).

La maintenance du matériel implique sa réparation ou son remplacement en cas de dommage. Le contrat doit donc détailler les modalités de signalement du dommage et d’intervention du fournisseur.

A noter que l’achat peut être remplacé par un leasing avec des formules de financement. Dans tous les cas, le contrat doit clairement établir les engagements du vendeur, ceux assumés par le constructeur, et respecter les exigences réglementaires relatives notamment aux restrictions d’exportation et au recyclage des déchets électroniques (Directive européenne 2012/19/UE dite « DEEE »).

2. Le contrat de licence logicielle « propriétaire »

Il s’agit d’une licence d’utilisation d’un logiciel généralement standard (« progiciel »), directement installé sur l’infrastructure informatique de l’entreprise. En son temps, ce contrat a donné lieu à de furieux débats doctrinaux pour définir sa nature, entre cession et louage d’ouvrage. La controverse est toutefois close depuis longtemps : par contrat de licence, un éditeur (ou son distributeur) concède un droit d’utilisation limité à un client utilisateur, sur un exemplaire (ou « copie ») du logiciel.

Ce contrat est essentiellement fondé sur la propriété intellectuelle de l’éditeur sur le code source du logiciel, lequel conserve intégralement la propriété de son logiciel et n’accorde qu’un faisceau de droits patrimoniaux plus ou moins large en contrepartie d’une redevance périodique.

La formule classique se limite au droit personnel d’utilisation du logiciel, depuis le terminal ou le serveur sur lequel il est installé, par les utilisateurs désignés au sein de l’entreprise, pour des utilisations conformes à sa destination et à sa documentation.

Ce droit d’utilisation inclut un droit de reproduction du logiciel sur les machines du client, à concurrence du nombre de copies autorisé, et un droit de représentation pour l’afficher et l’utiliser sur les terminaux de l’entreprise.

L’article L.122-1-6 II° et III° du Code de la propriété intellectuelle a accordé quelques droits complémentaires aux utilisateurs, dont celui d’effectuer une copie de sauvegarde du logiciel afin de continuer à l’utiliser en cas de perte, ainsi que le droit d’obtenir les informations d’interopérabilité pour interfacer le logiciel avec d’autres solutions.

Mais en toute hypothèse, la licence de logiciel est une concession temporaire, limitée dans le temps (durée déterminée ou, dans le cas de licences « perpétuelles », durée équivalente à la durée de protection des droits d’auteur applicables), et limitée dans l’espace.

L’éditeur s’en réserve généralement la maintenance (corrective et évolutive, cf. infra, le contrat de maintenance informatique), et interdit strictement au client utilisateur toute modification ou décompilation du logiciel, afin de préserver sa propriété.

Ce contrat appelle essentiellement des précautions relatives aux garanties qui doivent accompagner la licence, essentiellement la garantie de conformité à sa documentation et la garantie de non-contrefaçon, étant rappelé que la garantie des vices cachés peut également s’y appliquer.

Les points d’attention vont également concerner la parfaite compréhension des métriques d’utilisation et donc de facturation de la redevance de logiciel (nombre d’utilisateurs, nombre de documents traités, etc.).

Certaines licences peuvent toutefois prévoir un périmètre de droits d’utilisation plus large : il en va notamment ainsi de la licence de développement, où l’utilisateur obtient également le code source du logiciel afin de pouvoir en développer lui-même des versions dérivées et nouvelles évolutions.

Dans tous les cas, on doit soigneusement distinguer la licence, qui organise la concession d’un droit personnel et limité d’utilisation du logiciel de l’éditeur, et le contrat de cession d’un logiciel, par lequel l’éditeur se départit cette fois intégralement de la propriété du logiciel : il ne démembre plus son monopole d’exploitation : il le transfère intégralement au cessionnaire, qui devient seul titulaire du droit d’en autoriser l’utilisation par les tiers.

3. Les licences libres ou « open source »

A l’opposé de la licence dite « propriétaire » par laquelle l’éditeur se réserve tous les droits non expressément concédés au licencié, existent des formules de licences « libres » ou « open source ».

Dans le cas du logiciel libre, les droits d’utilisation, de reproduction, de distribution, de modification ou d’évolution du logiciel sont universellement autorisés, par défaut, et a priori sans contrepartie financière. L’auteur du code source se défait ici de son monopole d’exploitation en ouvrant largement à tous tiers les prérogatives qui relèvent normalement d’une logique propriétaire.

Ce type de logiciel peut être (plus ou moins) librement réutilisé par quiconque entre en possession de son code source, à condition cependant de respecter les termes de la licence libre qui l’accompagne (et qui peut comporter des conditions ou restrictions – son usage n’est donc pas entièrement « libre » et ne relève pas non plus du domaine public).

Schématiquement, cette large concession de droits inclut quatre prérogatives principales : le droit d’accéder pleinement au code source, le droit d’utiliser le logiciel pour tout type d’utilisation, le droit de rediffuser des copies du logiciel, et le droit de le modifier et de publier ses améliorations.

Les licences libres présentent une grande diversité, et parfois une certaine complexité qui requiert l’analyse d’un spécialiste. Cet article n’a pas pour objet d’entrer dans le détail des différentes licences, mais le principal point d’attention du juriste réside dans l’identification des obligations qui caractérisent la licence libre, plus ou moins « permissive ».

En particulier, on doit savoir identifier la notion de réciprocité ou « copyleft », qui oblige à reverser à la communauté, sous la même licence, toute évolution ou modification effectuée sur le logiciel, et qui interdit donc de « repropriariser » le logiciel ou ses dérivés (pas de droit privatif ou d'exploitation exclusive possible). C’est le cas de la plupart des licences livres GNU de la Free Software Federation dont le fondateur Richard Stallman est à l’origine de cette formule juridique originale.

Une très grande attention doit donc être apportée à cette licence si le développeur utilise un composant sous licence copyleft pour l’intégrer avec des composants sous d’autres licences ou s’il l’intègre à une solution logicielle qui a vocation à être commercialisée via une licence propriétaire payante, car le copyleft a un effet « contaminant » (ou « libérateur », selon l’approche) qui a pu réserver de très désagréables surprises à certaines entreprises par le passé.

Là encore, l’entreprise doit recourir aux services d’un juriste ou avocat qui comprend les termes des licences libres et interpréter leurs clauses pour identifier les éventuelles incompatibilités entre licences, préciser les usages autorisés ou au contraire alerter sur les prohibitions ou risques d’intégration.

On conseille à cet égard le livre blanc du Syntec Numérique (Numeum), qui bien qu’un peu daté, reste la référence pour comprendre les caractéristiques des licences libres et les modèles économiques et techniques associés.

4. Le contrat de maintenance ou de tierce maintenance de logiciel

Il s’agit ici d’un contrat à exécution successive qui porte sur le maintien en conditions opérationnelles du logiciel.

Le plus souvent fournie par l’éditeur du logiciel lui-même, cette maintenance va porter sur la correction de ses dysfonctionnements (« anomalies » ou « erreurs ») ainsi que sur les modalités de son évolution technique et fonctionnelle.

La correction des anomalies implique de mettre en place une procédure de signalement par le client et d’encadrer la réponse apportée par le prestataire, par télémaintenance (connexion distante au système d’information du client pour analyser et solutionner les anomalies) ou par intervention sur site.

La maintenance se double souvent d’un service de support aux utilisateurs, qui permet de recevoir les signalements ; attention aux plages horaires du support qui doivent être déterminées en fonction du moment où le client est le plus susceptible d’en avoir besoin.

Le cœur de ce contrat réside bien entendu dans les niveaux de service applicables, c’est-à-dire les délais de prise en compte et surtout de correction des anomalies (ou de mise en place d’une solution de contournement) afin de permettre le retour à un fonctionnement normal le plus rapidement possible.

Les dysfonctionnements ont en effet un impact considérable sur l’activité de l’entreprise, et celle-ci doit s’interroger, en fonction de la criticité de son logiciel, sur la nécessité de convenir avec le mainteneur de niveaux de service contraignants, voire des pénalités applicables en cas de non-respect des délais stipulés.

Pour des raisons à la fois commerciales et liées au secret d’affaires, l’éditeur d’un logiciel se réserve usuellement la maintenance, comme l’y autorise l’article L.122-6-1 I° du Code de la propriété intellectuelle. Les stipulations du contrat de maintenance sont d’ailleurs très souvent ajoutées à celles de la licence logicielle, au sein des conditions générales de vente de l’éditeur.

Cependant, on rencontre également des contrats de tierce maintenance applicative (TMA), qui permettent à un prestataire A d’intervenir sur le logiciel d’un éditeur B. Il est alors nécessaire pour le client de s’assurer qu’il dispose des droits de confier la maintenance du logiciel à ce tiers, et que le prestataire dispose des expertises appropriées à cette fin.

Les contrats de TMA impliquent parfois une phase d’initialisation permettant la montée en compétence du prestataire sur le logiciel à maintenir, et en toute hypothèse, son engagement de confidentialité puisqu’il va intervenir sur un actif qui appartient à l’éditeur.

La maintenance inclut également, selon les contrats, la maintenance préventive (consistant principalement dans les mises à jour de sécurité pour prévenir les anomalies), la maintenance évolutive (c’est-à-dire la gestion des mises à jour et montées de version du logiciel en fonction de la roadmap de l’éditeur), et parfois la maintenance réglementaire, si le logiciel est soumis à une législation spécifique.

Les conditions de ces différentes maintenances font l’objet de négociations corsetées, notamment pour identifier ce qui est inclus à la redevance de maintenance, et ce qui en est exclu. Certains éditeurs, par exemple, ne fournissent de montées de version de leur logiciel que moyennant la commande d’une licence complémentaire.

Dans tous les cas, les modalités et conséquences des montées de version doivent être soigneusement encadrées, car la pratique montre que c’est souvent à l’occasion de ces upgrades que peuvent survenir des difficultés (perte d’interopérabilité, régressions fonctionnelles, déficit de performances). Il est prudent de prévoir une faculté de « roll back » pour pouvoir revenir sur la version n-1 en cas de problème.

On doit enfin distinguer la maintenance, par construction payante, de la garantie de conformité qui accompagne souvent les licences logicielles ; en dernière analyse, la garantie s’analyse en effet en une courte période de maintenance gratuite.

Le service de maintenance est le plus souvent proposé sous forme d’un abonnement qui se prolonge dans le temps. Le contrat de maintenance (a fortiori le contrat de TMA) doit donc prévoir ce qui se passe à son terme, avec des précautions de réversibilité.

L’ensemble des considérations précédentes vaut quel que soit l’objet de la maintenance, c’est-à-dire qu’il s’agisse d’un logiciel installé sur le système d’information de l’entreprise, d’un site web ou d’une application mobile. Tout actif numérique est susceptible de renvoyer des erreurs, et il est particulièrement hasardeux d’utiliser un tel actif sans pouvoir s’appuyer sur un véritable service de maintenance professionnel et réactif.

5. La licence de base de données

Les bases de données ont un statut particulier au sein du Code de la propriété intellectuelle (on parle toujours du « droit sui generis » du producteur).

Ici, un producteur de bases de données, qui a pris l’initiative et exposé les coûts nécessaires à la constitution de la base (sur laquelle il jouit par conséquent d’un monopole d’exploitation), consent un droit d’utilisation limité à son client, portant sur la consultation, l’extraction et/ou la réutilisation des données contenues en base.

Ce type de contrat va mettre en jeu des questions liées à la protection de la propriété intellectuelle du producteur de la base, aux modalités d’accès aux données par le client, à la portée du droit d’utilisation concédé au client, et à l’hébergement de la base (qui implique à nouveau des engagements de niveaux de service et, sans surprise, de cybersécurité).

Si ces bases contiennent des données personnelles (ex : data brokers), il est capital que les traitements de ces données, ainsi que leur origine et la base légale soutenant leur utilisation, soient scrupuleusement encadrés dans le contrat.

6. Le contrat de développement informatique

Il s’agit ici d’un contrat de projet, et non plus d’un abonnement – même si certains projets de développement informatique peuvent s’étendre sur plusieurs années.

Le client acquiert ici une solution numérique qui va être spécifiquement développée pour répondre à ses besoins fonctionnels et contraintes techniques.

Ces besoins, le client doit les émettre sous sa responsabilité ou avec l’assistance d’un consultant, au sein d’un cahier des charges qui décrit le plus précisément possible les fonctionnalités attendues, les règles de gestion des données, les interdépendances fonctionnelles, etc.

On est donc ici à l’opposé de la concession d’une licence sur un progiciel standard du marché : il s’agit de créer un produit spécifique (logiciel métier, application mobile, site web…).

L’un des points d’attention de ce contrat réside dans le transfert en pleine propriété des travaux développés (codes sources du logiciel ou du site, spécifications, documentation…) qui doit être complet et définitif, car faute de stipulation expresse dans le contrat, les développements réalisés par le prestataire feront seulement l’objet d’une licence d’utilisation (forcément limitée à la durée du contrat).

Plus d’un client a rencontré des difficultés lorsque, désirant changer de prestataire, il découvre qu’il n’était pas devenu propriétaire de son logiciel « maison » ou de son propre site web.

L’autre point d’attention principal réside dans la conformité de ce qui est développé par rapport à ce qui a été commandé. On trouve donc au sein de ce contrat l’étape centrale de la recette, par laquelle le client va contrôler que les livrables remis correspondent à ses attentes.

La jurisprudence abonde d’exemples de litiges survenus en recette, soit parce que le développeur ne s’est pas conformé pleinement aux besoins (ou n’a pas alerté sur leur caractère inatteignable), soit parce que le client avait insuffisamment détaillé ses besoins ou les a fait évoluer par la suite (et il ne s’agit là que des deux cas extrêmes entre lesquels une multitude de situations plus contrastées existent).

Ce type de prestation peut faire l’objet d’un forfait, ou d’une facturation en régie, tout dépend des caractéristiques du projet et de la maturité des besoins du client.

Une fois le projet terminé, il est indispensable de s’interroger sur son maintien en conditions opérationnelles, et donc sur les services de maintenance à commander (cf. supra, le contrat de maintenance informatique).

7. Le contrat d’intégration de solution ou de système

Il s’agit sans doute du contrat le plus complexe et le moins standard qui existe dans la nomenclature des contrats informatiques ici étudiés. On parle de contrat d’intégration, terme toutefois générique qui peut couvrir une grande variété de prestations :

• Développement d’une solution informatique entièrement originale ou, le plus souvent, construction d’une solution ad hoc par adaptation et personnalisation d’un progiciel préexistant aux besoins spécifiques du client
• Intégration et personnalisation d’un ou plusieurs progiciels préexistants (solution « composite ») ou de services applicatifs (SaaS), ou encore interfaçage d’une solution à des logiciels préexistants dans l’entreprise ;
• Adaptation préalable d’un service applicatif ou d’infrastructure (cf. infra, le contrat de service cloud) avant sa mise en œuvre (cette adaptation pouvant être plus ou moins poussée, et il est ici capital de savoir définir si le client attend une véritable adaptation du service à ses besoins ou si au contraire il entend en majorité adopter les fonctionnalités standards disponibles) ;
• Construction d’une infrastructure technique et logicielle (contrats d’équipementiers ajoutant une dimension « hardware » au projet) ;
• Migration de données ou d’applications vers une nouvelle solution ou infrastructure informatique (notamment dans le cadre du vaste mouvement de transformation numérique des entreprises avec les projets « move to cloud») ;
• Déploiement de la solution intégrée auprès d’entités « pilotes » puis déploiement auprès de l’ensemble des entités utilisatrices du client (agences, succursales, filiales, etc.).

Ces contrats impliquent alors une attention très poussée sur un très grand nombre de sujets.

Outre l’identification de la philosophie du projet (s’agit-il majoritairement pour l’intégrateur d’épouser tous les besoins spécifiques du client ou plutôt pour le client d’adopter majoritairement les pratiques du produit socle qui lui est proposé), sa gouvernance implique de définir au contrat le calendrier du projet et sa méthode :

• Le calendrier peut, selon les cas, être impératif ou prévisionnel: la stipulation est capitale, notamment en cas de contentieux ultérieur. Le calendrier doit également être cohérent, et articuler les étapes successives du projet (cadrage, analyse, rédaction des spécifications, paramétrages et développements logiciels, recettes, reprise des données, interconnexion des interfaces, recette d’intégration, mise en production, déploiement, formations…) ;
• La méthode peut être linéaire (dite « en cascade ») ou au contraire une méthode agile, ce qui implique de parfaitement identifier dans un Plan d’Assurance Qualité l’ensemble des phases, étapes et concepts du projet, ainsi que les modalités de gestion des risques ;
• Le projet d’intégration ou déploiement fait intervenir un grand nombre de métiers, du côté du prestataire (analystes, architectes, développeurs…) et du côté du client (métiers, DSI, leaders fonctionnels…). Leur coordination est essentielle et la méthode comprend généralement des RACI afin de soigneusement identifier les diligences respectives à chaque étape ;
• Le pilotage du projet est également un point crucial, qui s’exprime dans le cadre d’une comitologie (comités de projet, de suivi, de pilotage, d’arbitrage…) que le contrat doit mettre en place ;
• Nonobstant ce rôle actif des deux parties dans le projet, a fortiori en cas de méthode agile, le pilotage du projet impose de clairement déterminer les responsabilités de la maitrise d’œuvre et de la maitrise d’ouvrage, avec l’ensemble des obligations de suivi et de reporting associées.

L’axe principal d’un contrat d’intégration réside dans le contrôle de conformité, qui s’effectue dans le cadre des recettes. Le contrat doit donc impérativement définir ce qu’est le référentiel de conformité applicable à chaque étape (remise du cadrage, livraison des spécifications, livraison de la solution, reprise de données) à partir de critères contractuels clairs, afin d’éviter les divergences d’interprétation.

Le contrat doit également définir la temporalité et les modalités précises de la procédure de recette.

Le périmètre d’un tel projet peut d’ailleurs évoluer dans le temps. Le contrat doit impérativement prévoir les modalités d’encadrement d’une telle évolution, à défaut de quoi le projet est voué à l’échec : une clause de gestion des modifications s’impose, en particulier si le projet est proposé dans le cadre d’un forfait : ce forfait a nécessairement été conçu en fonction d’un périmètre fonctionnel et technique qui, malheureusement, est parfois découvert (par l’une ou l’autre des parties) tardivement en cours de conception.

De plus, selon la nature et la durée du projet d’intégration, peuvent survenir des réorientations du besoin ou des sujétions imprévues, et il est vivement conseillé que le contrat permette suffisamment de souplesse pour pouvoir appréhender ces impondérables - sans pour autant qu’ils soient ipso facto assimilés à un manquement de l’une ou l’autre des parties.

Au-delà, on retrouve les problématiques liées à la propriété intellectuelle des travaux et développements du prestataire, aux garanties de conformité et de bon fonctionnement de la solution cible, à la responsabilité contractuelle (définie en fonction du périmètre du projet et de l’intensité des engagements du prestataire), etc.

Ces problématiques ont fait l’objet d’une analyse plus détaillée ici, mais sont toujours propres à chaque projet et ne peuvent donc pas faire l’objet d’une présentation réellement générique.

Le contrat de solution est un projet dont la dérive ou l’échec est nécessairement très coûteux ; il est donc indispensable de bénéficier d’un contrat solide, adapté à sa réalité opérationnelle et technique, qui prévoit en outre les conséquences de sa résolution (remboursements, indemnisation, réversibilité des prestations) car, contrairement aux contrats à exécution successives qui ne peuvent être résiliés que pour l’avenir (maintenance, hébergement, service cloud), le contrat de solution en échec prématuré prive le plus souvent de contrepartie les paiements précédemment effectués par le client.

Le prestataire quant à lui doit se prémunir des risques de transformation d’un projet initialement cadré en service d’« intégration continue » qui déjouerait ses prévisions budgétaires.

Le projet d’intégration doit réellement être pensé comme un projet d’entreprise, dont l’impulsion est donnée par sa direction générale, qui met en jeu de nombreuses compétences internes, et qui exige que client et prestataire œuvrent ensemble à la création de valeur.

Les plus fameuses jurisprudences liées au droit de l’informatique concernent l’échec de projets d’intégration et déploiement d’envergure (affaires Faurecia/Oracle, IBM/MAIF…).

8. Le contrat d’hébergement de données ou d’applications

Autre contrat à exécution successive, le contrat d’hébergement est une formule classique et très courante qui consiste schématiquement à commander de l’espace-mémoire pour stocker des données ou d’autres actifs numériques.

Mais ce classicisme ne doit pas occulter ses problématiques propres : le contrat doit clairement prévoir les ressources allouées, la capacité de stockage convenue (puisque tout dépassement provoquera des difficultés techniques et/ou des redevances additionnelles) et les métriques de facturation, ainsi que les modalités d’évolution de ces ressources et métriques si le besoin s’en fait sentir.

Au cœur du contrat d’hébergement trônent les clauses relatives aux niveaux de service (engagement de disponibilité ou « uptime », délais de rétablissement en cas d’indisponibilité ou ralentissement) et à la sécurité des actifs confiés par le client.

Les hébergeurs jouent un rôle si critique dans l’économie numérique qu’ils ont fait depuis longtemps l’objet de dispositions légales spécifiques (notamment la loi du 21 juin 2004 dite « LCEN » ou beaucoup plus récemment la loi du 21 mai 2024 dite « SREN ») ou sectorielles (pour l’hébergement de données de santé notamment).

La sécurité logicielle et physique est sans doute l’aspect le plus sensible du contrat d’hébergement, en ce qu’elle dépend notamment de la nature des données ou applications confiées par le client. En la matière, de nombreuses normes techniques (normes ISO, référentiel SecNumCloud, ReCyf…), et de plus en plus de textes juridiques vont s’appliquer (Directive NIS2) et le contrat doit leur donner force.

L’hébergement implique également le maintien en conditions opérationnelles des infrastructures qui le soutiennent. On retrouve ici les notions relatives à la maintenance, toutefois plus orientées vers la connectivité et la sécurité que vers des fonctionnalités logicielles. Les interruptions de service doivent être encadrées par contrat et faire l’objet, autant que possible, d’alertes préalables.

La distribution des responsabilités contractuelles revêt un aspect particulier pour ce type de contrat, car un manquement de l’hébergeur (qui par exemple aboutit à la perte ou la fuite des données) peut avoir des conséquences cataclysmiques pour le client, mais un manquement du client (qui par exemple charge des données corrompues ou illicites) peut également avoir un impact néfaste sur l’hébergeur (bien que celui-ci ne soit pas tenu d’une obligation de surveillance des données).

L’hébergement impliquant une dépossession par l’entreprise de ses actifs numériques, il doit nécessairement encadrer le recouvrement de ces actifs en fin de contrat, avec une forte exigence de réversibilité (toutefois centrée sur la récupération des données essentiellement).

Les considérations précédentes sont transverses pour tout type d’hébergement, qu’il s’applique à une solution informatique, à la partie « en ligne » d’un produit numérique, ou encore à un site web.

9. Le contrat de service cloud

L’une des grandes mutations du secteur numérique depuis les années 2000 consiste en la virtualisation des ressources informatiques (logiciels et plateformes). On est passé d’une économie de licences installées à une économie de l’accès et de la consommation « on demand ».

L’ancien éditeur logiciel adopte ici une logique d’hébergeur, avec des engagements de disponibilité et de réactivité (SLA) en s’appuyant par exemple sur un hébergeur qui dispose des datacenters, ou en modifiant son business model.

On retrouve donc ici des préoccupations comparables à celles liées au contrat d’hébergement (espace-mémoire, sécurité, disponibilité, restitution des données, augmentées des questions liées à la capacité de calcul et aux performances ici), et au contrat de licence logicielle (droits d’utilisation, contrôle des métriques, maintenance), mais qu’on doit relire à nouveaux frais.

Sans doute désormais le contrat informatique le plus courant, le contrat de service cloud porte sur une très grande variété de services exprimés via des acronymes à connaître (SaaS, IaaS, PaaS, etc.) :

• Le contrat « infrastructure as a Service» (IaaS) encadre une offre d’hébergement distant qui revient à louer une infrastructure de stockage et réseau qui fonctionne sous forme de machines virtuelles chez le prestataire. Le client consomme de l’espace-disque et de la puissance machine à la demande, dans le cadre de métriques en lien avec la consommation des ressources allouées à ses besoins (ex : Google Cloud Platform, Microsoft Azure, OVH Cloud, Scaleway, etc.) ;
• Le contrat « software as a Service» (SaaS) permet d’utiliser à distance un progiciel en ligne (ex : CRM SalesForce ; progiciel de gestion de paie ADP ; ERP Oracle, Cegid ou Sage, etc.) et se décline aujourd’hui sous de nombreuses formes et modèles économiques, principalement de souscription pour une durée déterminée. Il s’agit typiquement de la virtualisation complète de la licence logicielle examiné supra. Le client ne paie plus formellement des droits d’utilisation dans le cadre d’une licence, mais la consommation d’un service logiciel distant ;
• Le contrat « Platform as a Service» (PaaS) concerne quant à lui la mise à disposition à distance d’un environnement informatique à vocation plus technique qu’applicative, et prêt à l’emploi (environnement de test ou de développement d’applications à personnaliser) (ex : Google AppEngine, AWS, Clever Cloud, etc.). Le client s’appuie sur une plateforme distante pour effectuer ses propres travaux d’ingénierie et développement logiciel.

Dans les trois cas, le fournisseur cloud assure un rôle d’hébergeur, soit des données, soit des applications, soit de l’ensemble, confié par le client.

Les services cloud peuvent également être privés, publics, ou hybrides :

• L’éditeur d’un service cloud public mutualise ses ressources (puissance de calcul, espace de stockage, maintenance technique, réseau et bande passante) et les propose à ses clients. L’éditeur est cependant seul propriétaire des éléments logiciels et matériels du service ;
• Dans le cas du cloud privé, le client utilisateur est souvent le propriétaire du matériel, décide des applicatifs inclus dans le service cloud, et en confie l’intégration et l’hébergement à un fournisseur cloud. Le cloud privé permet souvent des paramétrages et mesures de sécurité plus spécifiques, la solution fonctionnant en cloud dédié ;
• Le cloud « hybride » propose de cumuler les avantages des précédentes configurations en permettant via une plateforme virtualisée unique de passer d’un cloud privé à un cloud public, par exemple pour absorber une montée en charge significative, multiplier les possibilités fonctionnelles ou distinguer des traitements d’importance inégale.

Le contrat cloud présente de nombreux avantages et certains inconvénients. Tout d’abord, en raison de la nature largement standardisée, parce que mutualisée, l’adaptation spécifique d’un service cloud est plus délicate a fortiori dans le cloud public.

On raisonnera moins ici en termes de conformité (contrairement au contrat de solution) qu’en termes de disponibilité du service. Cependant, l’acquisition d’un service cloud ne doit pas balayer toute exigence spécifique du client (qui ne cherche pas ici un hébergeur mais bien un éditeur avec une véritable valeur ajoutée logicielle), ni inverser la dialectique entre besoins de l’utilisateur et réponses fonctionnelles du fournisseur...

Certains services cloud se targuent d’une grande paramétrabilité, mais de nombreux projets dits « move to cloud » se heurtent aux limites de la reproduction en cloud des spécificités que pouvaient présenter les solutions on-premise précédentes du client.

En outre, le cloud implique une certaine forme de dépossession puisque la sécurité des actifs incorporels de l’entreprise cliente est externalisée, et confiée au fournisseur cloud. Cette perte de « souveraineté » (qui de manifeste de façon parfois particulièrement problématique lorsqu’il s’agit de se conformer aux exigences européennes de protection des données) est contrebalancée par le fait que les grands cloud providers proposent des conditions de sécurité et de performance particulièrement abouties - leurs contrats ne reflétant malheureusement pas toujours la confiance qu’ils sollicitent de leurs clients sur ces points.

Ces contrats impliquent nécessairement la conclusion d’un Plan d’Assurance Sécurité, qu’il soit fourni en standard par le fournisseur cloud ou établit de manière spécifique, en prévoyant tous les aspects liés à la protection des données et de la solution cloud, ainsi qu’un Plan de Continuité d’Activité (PCA) en cas de sinistre, portant des engagements d’alerte, de redondance et de résilience du système.

Face à un grand cloud provider, ces modalités de sécurité sont le plus souvent standards, peu négociables quel que soit leur niveau, et il appartient alors au client de les auditer de près pour vérifier si les objectifs proposés correspondent à ses besoins en matière de sécurité.

Les clients français bénéficient toutefois de plus en plus des exigences réglementaires européennes pour obtenir le rehaussement des engagements de responsabilité des cloud providers, mais ces questions font encore l’objet de négociations très accrochées.

De même, les niveaux de service sont généralement monolithiques et peu négociables, puisqu’ils sont appliqués à l’ensemble du parc de clientèle du fournisseur cloud. On peut ici retrouver des niveaux de service afférents à la fois à l’hébergement et à la maintenance, mais aussi des SLA spécifiques selon la nature du cloud.

Les pénalités correspondantes, exprimées le plus souvent en « crédits de service », ne suffisent pas toujours à rassurer le client sur la prise en compte de ses dommages en cas d’indisponibilité du service, et font l’objet d’âpres discussions.

La réversibilité, enjeu propre à tout contrat informatique, revêt ici un aspect particulièrement important, plus encore si le service cloud a fait l’objet d’une forte personnalisation, ou présente une empreinte très large au sein des activités du client. Sortir d’un contrat cloud complexe doit être appréhendé comme un projet en soi, à l’instar de son déploiement initial, et on doit se prémunir contre des clauses de réversibilité trop expéditives.

Ces contrats cloud ont eux aussi fait l’objet de quelques conseils spécifiques ici. Dès lors qu’ils sont désormais les plus répandus, mais pas les moins complexes, les contrats de service cloud impliquent une analyse juridique poussée, tant pour en négocier les aspects les plus saillants que pour avoir conscience des risques inhérents à la virtualisation des ressources de l’entreprise.

Un contrat de service cloud se négocie très différemment d’un simple contrat de maintenance ou surtout d’un contrat d’intégration ou déploiement ; il s’agit de catégories radicalement différentes bien que l’on y retrouve des notions communes (niveaux de service, propriété intellectuelle, garanties…).

Enfin, compte tenu de la diversité des services cloud, de nombreux textes s’y appliquent désormais, dont les textes européens relatifs à la cybersécurité (NIS2, DORA, CRA…) et ceux, nationaux ou européens, relatifs à l’autonomie dont doit bénéficier le client contre tout risque de dépendance technologique (Data Act, loi SREN). Ces textes doivent désormais trouver leur traduction contractuelle, rigoureuse et efficace.

10. Le contrat d’infogérance informatique

Le contrat d’infogérance (ou « outsourcing ») est un contrat de louage d’ouvrage par lequel l’entreprise confie une partie de la gestion de son système d’information à un prestataire externe. Il s’agit d’une prestation qui peut s’ajouter à une prestation d’hébergement, ou être fournie de façon autonome.

L’objet de l’infogérance peut être très varié : administration du système, activation de fonctions ou de routines, maintenance d’infrastructures, gestion des applications, supervision de la sécurité, gestion des sauvegardes, contrôle qualité, administration de réseau, traitements batch… et à cet égard, il n’existe aucun contrat « type » d’infogérance.

L’attention doit ici être portée à la définition précise des services fournis, à la caractérisation du système d’information concerné, et à l’identification très claire des zones infogérées et des répartitions de responsabilités. L’absence de prise en compte d’un flux ou d’une interdépendance technique constitue le plus grand risque en la matière.

L’infogérance en tant que telle peut être précédée d’un cadrage préalable permettant au prestataire de monter en compétences sur le système du client et d’initialiser ses accès et paramètres, qui peut faire l’objet d’un forfait.

Le contrat d’infogérance se caractérise également par la mise en place de niveaux de service, mais qui dépendront ici de l’objet infogéré : il ne s’agira donc pas d’un SLA classique portant sur la disponibilité d’une infrastructure ou le temps de correction d’une anomalie ; il pourra s’agir de temps d’exécution des tâches confiées, d’un nombre de tâches exécutées sur un segment temporel, etc. Et qui dit niveaux de service, dit pénalités.

En outre, et comme dans ce cas de figure client et prestataire interviennent tous deux sur le même système, la gestion de la cybersécurité implique une attention particulière, pour délimiter les responsabilités respectives et contenir les conséquences de toute erreur commise par l’un ou l’autre.

11. Les contrats de services informatiques

Hormis les grandes catégories susmentionnées (maintenance, hébergement, intégration, infogérance), il existe de nombreux services informatiques qui n’entraînent pas de forte spécificité contractuelle et n’entrent pas dans l’un des modèles précédents.

Ces contrats vont permettre d’encadrer les services des SSII et peuvent porter notamment sur l’administration du parc informatique, l’assistance technique, le paramétrage de logiciels, la gestion de données, la gestion de projet, l’AMOA, l’audit de cybersécurité, la réalisation de tests d’intrusion, l’audit de code, le consulting, la formation…

Ils correspondent à ce qu’on qualifie parfois de « P2I » pour « prestations intellectuelles informatiques » au sein des entreprises publiques ou des grands groupes qui disposent de conditions générales d’achat à cet effet.

Il s’agit toujours de contrats de louage d’ouvrage, qui vont mobiliser les questions liées à la propriété intellectuelle des résultats fournis, la facturation (là encore en régie ou au forfait), la protection contre le prêt de main d’œuvre illicite, la mesure de la qualité de la prestation, ou encore à la sécurité lorsque le prestataire accède au système d’information du client pour exécuter sa mission.

12. Autres contrats

Au-delà des principales figures étudiées ci-dessus, de nombreux contrats informatiques hybrides peuvent exister, comme par exemple les contrats de service de transition (en cas de cession d’entreprise) qui vont voir coexister des prestations contractuelles de détourage de système d’information (« carve-out ») et de poursuite temporaire des services récurrents (« TSA »), les contrats de codéveloppement ou de partenariat technologique, voire d’autres encore qui dépendent absolument de leur objet spécifique et du contexte de leur négociation.

Les contrats de revente ou distribution de logiciels ou de services applicatifs appellent également des précautions propres, en particulier pour délimiter les responsabilités respectives de l’éditeur et du distributeur, les conditions financières entre eux et le sort des contrats clients lorsque prend fin la relation de distribution commerciale.

Mais tous ces contrats feront nécessairement intervenir les concepts issus des principaux contrats informatiques susmentionnés.

13. Aspects transverses

Les contrats informatiques, pour très spécifiques qu’ils soient, obéissent par ailleurs à des règles transverses qui, elles aussi, vont guider la rédaction des clauses : durée de l’engagement et modalités de renouvellement, éventuels engagements d’exclusivité, obligations de moyens ou de résultat, obligations de conseil et d’alerte du prestataire, obligation de collaboration du client, conditions financières axées sur un résultat ou sur une mise à disposition de ressources, forfaits ou régies, responsabilité contractuelle, confidentialité des actifs de chaque partie, respect des restrictions d’exportations de certaines technologies, clauses de lutte anti-corruption, clauses de recyclage des déchets informatiques, clauses relatives à l’emploi de systèmes d’intelligence artificielle, protection contre le risque de prêt de main d’œuvre illicite, encadrement de la sous-traitance, cas et modalités de résolution ou résiliation et conséquences, réversibilité des prestations, et bien entendu, protection des données à caractère personnel… tous sujets dont l’étude approfondie conduirait à transformer cet article en manuel !

Dans tous les cas, la rédaction, l’analyse et la négociation des contrats informatiques implique la maîtrise d’un corpus d’expertises à la fois techniques et juridiques, ainsi qu’une forte capacité à adapter ces concepts à la réalité des services concernés.

Ils exigent un dialogue soutenu du rédacteur avec les techniciens et les métiers, pour encadrer au mieux la prestation, sécuriser ses aspects budgétaires, et prévenir autant que possible les risques de dérive. Ils exigent également une parfaite connaissance d’un environnement législatif et réglementaire aussi complexe qu’évolutif en matière de cybersécurité et de gestion des données.