Introduction
Externaliser un service ne veut pas dire externaliser sa responsabilité. Votre messagerie est peut-être hébergée par un fournisseur. Votre CRM est peut-être accessible en SaaS. Vos sauvegardes sont peut-être stockées dans le cloud. Votre système d’information reste le vôtre : la responsabilité ne disparaît pas parce qu’un service est fourni, hébergé ou administré par un tiers.
Le cloud peut simplifier l’exploitation technique. Il peut améliorer la disponibilité, accélérer les déploiements et réduire certaines contraintes internes. Mais il ne décide pas à votre place qui accède aux données, quels comptes doivent être supprimés, quels paramètres de sécurité doivent être activés, comment l’organisation doit fonctionner, quels usages sont acceptables, ni quelles informations sont critiques pour votre activité.
C’est précisément pour éviter cette confusion que le modèle de responsabilité partagée existe. Il ne cherche pas à compliquer le sujet, mais à répondre à une question très concrète : qui fait quoi, et jusqu’où ?
Responsabilité partagée : attention au faux ami
Le terme responsabilité partagée peut prêter à confusion. Il donne parfois l’impression que le fournisseur prend à sa charge une partie du risque métier, des conséquences économiques ou des obligations juridiques de l’entreprise en cas d’incident.
En réalité, ce modèle décrit d’abord une répartition opérationnelle : qui sécurise l’infrastructure, qui configure l’application, qui gère les accès, qui protège les données, qui surveille les usages, qui réagit en cas d’alerte.
Le contrat vient ensuite encadrer cette relation : engagements de service, support, sécurité, notification d’incident, réversibilité, exclusions, limites d’indemnisation. Et il faut le lire avec lucidité. Les fournisseurs de services ont souvent une forte expérience contractuelle et leurs conditions sont naturellement conçues pour cadrer leurs engagements, mais aussi pour limiter leur propre exposition.
Autrement dit, un contrat fournisseur n’est pas une assurance tous risques.
Le modèle de responsabilité partagée répartit les actions à mener ; le contrat encadre les engagements entre les parties ; mais le risque métier reste d’abord celui de l’entreprise.
Lois, règlements, normes et référentiels : le cadre à connaître
En Europe et en France, l’usage d’un service cloud ou d’une application en ligne ne se résume pas au contrat signé avec le fournisseur. Plusieurs cadres peuvent s’appliquer selon la nature du service, les données traitées, le secteur d’activité et les utilisateurs concernés.
Le RGPD reste central dès que des données personnelles sont concernées. L’entreprise peut rester responsable de traitement, même si le service est opéré par un sous-traitant. La CNIL rappelle d’ailleurs que responsables de traitement et sous-traitants doivent respecter le RGPD, et que cette relation doit être encadrée dès la signature du contrat. (CNIL)
Pour certaines organisations, la directive NIS2 renforce aussi les exigences en matière de cybersécurité, de gestion du risque et de notification d’incident. Elle établit un cadre européen commun pour la cybersécurité de secteurs critiques et importants. (Digital Strategy). Selon le contexte, d’autres textes peuvent entrer en jeu. La LCEN reste un cadre français important pour certains services en ligne et activités d’hébergement.
Le Digital Services Act concerne davantage les services intermédiaires, les plateformes en ligne, les places de marché ou les services exposés au public. Le RGAA est également à prendre en compte pour l’accessibilité des sites et services numériques concernés ; il vise à faciliter la mise en accessibilité des services numériques en France. (accessibilite.numerique.gouv.fr)
La responsabilité peut aussi s’élargir à des sujets de numérique responsable : localisation des données, sobriété numérique, durée de conservation, consommation énergétique, choix du fournisseur, capacité à fournir des engagements ou indicateurs environnementaux. Ce n’est pas le cœur du modèle cloud, mais cela fait partie des questions qu’une entreprise mature doit poser.
Enfin, des référentiels comme ceux de l’ANSSI, de l’ENISA, de la Cloud Security Alliance, ou les normes ISO/IEC 27001, 27017 et 27018, aident à structurer les contrôles et les questions à poser. En France, la qualification SecNumCloud de l’ANSSI vise notamment à reconnaître des offres cloud de confiance, avec un haut niveau d’exigence technique, opérationnel et juridique. (cyber.gouv.fr)
Les lois fixent des obligations, les contrats précisent les engagements, les normes structurent les contrôles. Mais l’entreprise doit toujours comprendre ce qu’elle délègue, ce qu’elle conserve et ce qu’elle risque.
Le principe : une responsabilité partagée, pas transférée
Le principe est simple : le fournisseur maîtrise son périmètre, l’entreprise maîtrise le sien.
Dans une application SaaS, le fournisseur gère généralement une grande partie de la plateforme : infrastructure, disponibilité, mises à jour du service, maintenance technique. Mais l’entreprise reste responsable de ses utilisateurs, de ses droits d’accès, de ses données, de ses paramètres de sécurité et des usages internes.
Dans un modèle PaaS, le fournisseur fournit l’environnement technique, mais l’entreprise conserve la responsabilité de ce qu’elle développe, configure et déploie dessus.
Dans un modèle IaaS, le fournisseur met à disposition l’infrastructure de base, mais l’entreprise conserve davantage de responsabilités : systèmes, applications, correctifs, sauvegardes, configurations, supervision.
Plus le service est bas niveau, plus l’entreprise garde la main sur la technique. Plus le service est prêt à l’emploi, plus la technique est masquée, mais cela ne veut pas dire que la responsabilité disparaît.
La bonne question n’est donc pas seulement : “est-ce que le fournisseur le fait ?”
La bonne question est plutôt : qui est responsable de cette action, qui la vérifie, et que se passe-t-il si elle n’est pas faite ?
Ce que le fournisseur maîtrise
Dans un service cloud, le fournisseur maîtrise généralement les éléments qui relèvent de son propre environnement technique.
Selon le type de service utilisé, cela peut inclure les centres de données, l’alimentation électrique, le réseau physique, les serveurs, les couches de virtualisation, la plateforme technique, certaines mises à jour, la disponibilité du service ou encore des protections de sécurité intégrées.
Dans un service SaaS, par exemple, le fournisseur prend souvent en charge l’infrastructure, la maintenance de l’application, les correctifs techniques et la disponibilité générale du service. Dans une offre IaaS, il maîtrise plutôt l’infrastructure sous-jacente : datacenter, matériel, réseau, virtualisation. L’entreprise conserve alors davantage de responsabilités sur ce qu’elle installe et configure au-dessus.
Mais il faut garder une nuance importante : ce que le fournisseur maîtrise n’est pas toujours ce qu’il garantit sans limite.
Ses engagements sont généralement précisés dans le contrat, les conditions générales, les SLA et la documentation du service. Le niveau de disponibilité annoncé, les délais de support, les modalités de notification d’incident ou les limites d’indemnisation ne sont pas des détails administratifs. Ce sont des éléments concrets de gestion du risque.
Autrement dit, le fournisseur peut maîtriser une couche technique sans devenir responsable de toutes les conséquences possibles pour l’entreprise cliente.
Une panne de service, une faille sur une couche d’infrastructure ou un incident chez un sous-traitant peuvent avoir un impact direct sur l’activité de l’entreprise. Mais la manière dont cet impact sera traité dépendra du contrat, des obligations légales, du contexte et des mesures que l’entreprise aura elle-même mises en place.
C’est pourquoi il est préférable de parler de périmètre maîtrisé par le fournisseur, plutôt que de croire que tout ce qui est “dans le cloud” est automatiquement “pris en charge” au sens large.
Ce que l’entreprise doit continuer à maîtriser
Même lorsqu’un service est hébergé, fourni ou administré par un tiers, l’entreprise conserve un rôle central. Elle reste responsable de ses données, de ses usages, de son organisation et des décisions qu’elle prend autour du service.
Elle doit notamment savoir qui utilise l’application, avec quels droits, pour quel besoin et pendant combien de temps. La gestion des identités et des accès reste un point clé : création des comptes, suppression après un départ, adaptation des droits lors d’un changement de poste, contrôle des comptes administrateurs, activation de l’authentification multifactorielle lorsque cela est possible.
L’entreprise doit aussi maîtriser ses données. Toutes les informations n’ont pas le même niveau de sensibilité. Une facture, un dossier RH, une base client, un document stratégique ou une donnée personnelle ne se gèrent pas de la même manière. Le fournisseur peut proposer des options de chiffrement, de sauvegarde ou de restriction d’accès, mais encore faut-il les comprendre, les activer et les vérifier.
Les paramètres de sécurité sont un autre point souvent sous-estimé. Beaucoup d’applications SaaS proposent des options utiles : journalisation, alertes de connexion, restrictions géographiques, gestion des appareils, règles de partage externe, politiques de mot de passe, intégration avec un annuaire d’entreprise. Si ces options ne sont pas configurées, elles ne protègent personne. Une fonctionnalité de sécurité désactivée reste, au fond, une très jolie décoration.
Enfin, l’entreprise doit garder la maîtrise de ses processus internes. Qui valide un nouvel accès ? Qui contrôle régulièrement les droits ? Qui reçoit les alertes ? Qui contacte le fournisseur en cas d’incident ? Qui décide d’arrêter le service ? Qui vérifie que les données peuvent être récupérées ?
Ces questions sont simples, mais elles évitent beaucoup de zones grises.
Le modèle de responsabilité partagée rappelle donc une évidence : même si la technique est partiellement externalisée, la gouvernance reste interne.
Contrat, fournisseur et localisation des données : les points à vérifier
Choisir un service cloud ou une application SaaS ne revient pas seulement à choisir une fonctionnalité. C’est aussi choisir un fournisseur, accepter un contrat, s’inscrire dans une chaîne de sous-traitance et confier des données à une organisation qui a ses propres règles, ses propres limites et parfois ses propres prestataires.
Le premier point à vérifier est le contrat. Il précise les engagements du fournisseur, mais aussi leurs limites. Il faut notamment regarder les niveaux de service, les conditions de support, les engagements de disponibilité, les clauses de sécurité, les délais de notification en cas d’incident, les conditions de sauvegarde, les modalités de réversibilité et les limites de responsabilité.
Ces éléments peuvent paraître juridiques ou administratifs, mais ils deviennent très concrets le jour où le service ne répond plus, où des données sont indisponibles ou où un incident de sécurité survient. Ce n’est jamais le bon moment pour découvrir que la garantie est limitée, que la restauration n’est pas incluse ou que le délai de support se compte en jours ouvrés.
Le deuxième point concerne le fournisseur lui-même. Qui est-il ? Où est-il établi ? Quelle est sa maturité en matière de sécurité ? Dispose-t-il de certifications, d’audits ou de rapports de conformité ? Utilise-t-il lui-même des sous-traitants ? Peut-il les changer ? Comment l’entreprise cliente en est-elle informée ?
Le troisième point concerne la localisation des données. Les données sont-elles hébergées en France, dans l’Union européenne ou ailleurs ? Des transferts hors Union européenne sont-ils possibles ? Les sauvegardes sont-elles localisées au même endroit que les données principales ? Les équipes support peuvent-elles accéder aux données depuis d’autres pays ? Ces questions sont particulièrement importantes dès que des données personnelles, sensibles ou stratégiques sont concernées.
La fin de contrat mérite aussi une attention particulière. L’entreprise doit savoir comment récupérer ses données, dans quel format, sous quel délai, avec quelles garanties de suppression chez le fournisseur. La réversibilité n’est pas un détail : c’est la porte de sortie. Et comme pour toute porte de sortie, mieux vaut vérifier qu’elle s’ouvre avant que le bâtiment ne soit en feu.
En résumé, un service numérique ne doit pas être évalué uniquement sur son prix et ses fonctionnalités. Il faut aussi comprendre le contrat, le fournisseur, les sous-traitants, la localisation des données et les conditions de sortie.
Choisir un service, ce n’est pas seulement choisir un outil. C’est aussi accepter un cadre de responsabilité.
