Il y a une question qu'aucun dirigeant ne pose au moment de signer avec son agence web. Une seule. Et c'est toujours la même : « où seront stockées mes données ? »
On la découvre plus tard. Généralement dans de mauvaises conditions. Un audit qui tombe, un client grand compte qui exige un questionnaire de conformité, une résiliation qui se passe mal, ou pire, un incident de sécurité qu'il faut déclarer à la CNIL sous 72 heures alors qu'on ne sait même pas nommer l'entité qui héberge le fichier clients.
Le décalage est là, et il est vertigineux. On croit avoir acheté un site. Un CRM. Une plateforme de réservation. En réalité, on a confié à un tiers la garde d'un actif commercial : le fichier des clients, l'historique des commandes, parfois des données de santé ou des coordonnées bancaires. On a délégué la garde sans jamais demander l'adresse du coffre.
Cet article a un objectif simple : vous permettre de savoir où sont vos données aujourd'hui, de comprendre ce que le droit vous impose réellement (et ce qui relève du discours commercial), et de repartir avec des clauses contractuelles utilisables. Pas de la théorie. Des formulations que vous pouvez copier dans un avenant.
Ce que « hébergement des données » recouvre vraiment chez un prestataire digital
La chaîne de sous-traitance que personne ne vous montre
Votre contrat est signé avec une agence. C'est elle votre interlocuteur, elle qui envoie les factures, elle qui répond au téléphone. Mais elle n'héberge presque jamais vos données elle-même.
La chaîne réelle ressemble plutôt à ça : agence web → hébergeur → opérateur de datacenter → et derrière, tout un cortège de sous-traitants tiers. CDN pour accélérer l'affichage. Service de sauvegarde externalisé. Prestataire de mail transactionnel pour les confirmations de commande. Outil d'analytics. Plateforme de tickets support. Et depuis deux ans, presque systématiquement, un ou plusieurs services d'IA générative branchés quelque part dans le flux.
Chacun de ces maillons voit passer, stocke ou traite une partie de vos données. Le prestataire signataire, lui, n'est souvent qu'un intégrateur. Ce n'est pas un reproche, c'est le modèle économique du secteur. Mais cela change tout sur le plan juridique, parce que vos obligations, elles, ne s'arrêtent pas au premier maillon.
Vos données existent à plusieurs endroits en même temps
Voilà le point que la plupart des dirigeants ratent, et il est capital.
Quand on demande « où est ma base de données », on imagine un serveur, une machine, un lieu. La réalité est beaucoup plus dispersée. Vos données vivent simultanément dans :
- la base de production, celle qui fait tourner le site ;
- les réplicas, ces copies synchronisées qui assurent la performance et la tolérance aux pannes ;
- les sauvegardes, quotidiennes, hebdomadaires, mensuelles, souvent conservées plusieurs mois ;
- les journaux applicatifs, qui enregistrent une quantité surprenante d'informations personnelles ;
- les environnements de préproduction et de recette, très fréquemment alimentés par une copie brute de la base de production ;
- les postes de travail des développeurs, qui ont pu télécharger un export pour déboguer ;
- les boîtes mail, où circulent des tableurs d'export « juste pour vérifier un truc ».
Et maintenant, le détail qui fait mal : les sauvegardes et les logs ont très souvent une localisation différente de la base principale. Un hébergement à Roubaix avec des sauvegardes répliquées à Francfort ou en Virginie, c'est banal. Sauf que les sauvegardes contiennent exactement les mêmes données personnelles que la production. Elles sont soumises aux mêmes règles. Elles sont réquisitionnables dans les mêmes conditions.
Poser la question de la localisation sans mentionner explicitement les sauvegardes, c'est n'avoir posé que la moitié de la question.
Toutes les données ne se valent pas
Le niveau d'exigence doit être proportionné. Inutile de blinder un contrat comme un hôpital si vous collectez trois adresses mail via un formulaire de contact.
Données d'identification : nom, prénom, adresse, téléphone, mail. Le socle commun, présent partout.
Données de commande et de transaction : historique d'achat, panier moyen, préférences. Sensibles commercialement plus que juridiquement, mais leur perte ou leur fuite fait très mal à l'image.
Données de navigation : adresses IP, identifiants de session, comportement sur le site. Souvent sous-estimées, elles sont pourtant des données personnelles à part entière.
Données sensibles au sens de l'article 9 du RGPD : santé, opinions politiques ou religieuses, orientation sexuelle, données biométriques, appartenance syndicale. Changement de régime complet. Interdiction de principe, exceptions strictes, exigences de sécurité renforcées.
Données bancaires : soumises en plus au référentiel PCI-DSS si vous stockez des numéros de carte, ce que vous ne devriez de toute façon jamais faire vous-même.
Qui est responsable de quoi (et la mauvaise nouvelle)
Trois rôles à distinguer, et la distinction n'a rien d'académique.
Le responsable de traitement, c'est vous. C'est celui qui décide des finalités et des moyens : pourquoi on collecte, quoi, pour combien de temps.
Le sous-traitant, c'est votre agence. Elle traite les données pour votre compte, sur vos instructions.
Le sous-traitant ultérieur, c'est l'hébergeur, et tous ceux qui viennent derrière.
La conséquence est brutale, et beaucoup la découvrent trop tard : en cas de manquement, c'est vous que la CNIL sanctionne. Pas votre prestataire. L'autorité s'adresse au responsable de traitement, celui dont le nom figure sur la politique de confidentialité. Vous pourrez ensuite vous retourner contre votre agence, si votre contrat le permet, ce qui suppose justement d'avoir des clauses solides. Mais le premier courrier, l'amende éventuelle, la publicité de la sanction : c'est pour vous.
Autrement dit, déléguer la technique ne délègue pas la responsabilité. Jamais.
Le cadre légal en 2026 : ce qu'il faut exiger, ce qui n'est que du marketing
Ce que le RGPD impose réellement sur la localisation
Commençons par démonter une croyance très répandue, y compris chez des prestataires : le RGPD n'impose aucune obligation générale d'héberger en France ou en Europe. Aucune. Ce n'est écrit nulle part.
Ce que le texte impose, c'est autre chose, et c'est en réalité plus contraignant qu'une simple règle de géographie :
L'article 28 exige un contrat écrit entre responsable de traitement et sous-traitant, avec un contenu obligatoire précis : objet, durée, nature et finalité du traitement, catégories de données, obligations des parties. C'est le fameux DPA (Data Processing Agreement). Si vous n'en avez pas signé avec votre agence, vous êtes déjà en infraction, et c'est une infraction que la CNIL constate en trois minutes lors d'un contrôle.
L'article 32 impose des mesures techniques et organisationnelles appropriées au risque : chiffrement, pseudonymisation, capacité à rétablir la disponibilité, procédure de test régulier.
Le chapitre V encadre les transferts hors Union européenne. Pas d'interdiction, mais un encadrement.
Le RGPD raisonne en garanties appropriées, pas en frontières. Ce qui n'empêche pas la localisation d'être un excellent indicateur, souvent le plus lisible. Simplement, elle n'est ni suffisante, ni juridiquement obligatoire en soi.
Les transferts hors UE : trois mécanismes, une fragilité
Sortir des données de l'Union européenne suppose l'un de ces trois fondements.
La décision d'adéquation : la Commission européenne estime qu'un pays offre un niveau de protection équivalent. Le transfert se fait alors librement. Une quinzaine de pays en bénéficient (Suisse, Royaume-Uni, Japon, Canada pour le secteur privé, Corée du Sud, entre autres).
Les clauses contractuelles types : des modèles adoptés par la Commission, à signer entre l'exportateur et l'importateur de données. C'est le mécanisme le plus courant.
L'analyse d'impact des transferts : depuis l'arrêt Schrems II, les clauses types seules ne suffisent plus. Il faut évaluer si le droit du pays de destination ne vide pas ces clauses de leur substance, et ajouter le cas échéant des mesures supplémentaires (chiffrement avec conservation des clés en Europe, par exemple).
Et puis il y a le cas américain, qui mérite un paragraphe à lui seul.
Le Data Privacy Framework, en vigueur depuis 2023, est la troisième tentative d'accord transatlantique. Les deux précédentes, le Safe Harbor et le Privacy Shield, ont été annulées par la Cour de justice de l'Union européenne, respectivement en 2015 et 2020. Deux annulations, pour des motifs structurellement identiques : les programmes de surveillance américains restent incompatibles avec les exigences européennes de protection.
Le DPF est actuellement valide. Il est aussi contesté devant les juridictions européennes, et sa fragilité est reconnue par à peu près tout le monde, y compris par ses défenseurs.
Est-ce que cela signifie qu'il ne faut pas l'utiliser ? Non. Est-ce que cela signifie qu'il ne faut pas bâtir toute son architecture dessus ? Absolument. Construire un système d'information entier sur une décision d'adéquation qui a déjà été annulée deux fois pour les mêmes raisons, c'est accepter un risque de continuité d'activité, pas seulement un risque de conformité. Le jour où le DPF tombe (et le pari est raisonnable), les entreprises concernées auront quelques mois pour trouver une solution. Celles qui auront prévu une porte de sortie contractuelle passeront. Les autres improviseront.
L'angle mort : l'extraterritorialité
C'est le sujet que la plupart des prestataires n'abordent jamais, souvent parce qu'ils l'ignorent eux-mêmes.
Le Cloud Act américain, adopté en 2018, permet aux autorités américaines d'exiger d'un fournisseur soumis à leur juridiction la communication de données qu'il détient où qu'elles soient stockées dans le monde. Le FISA 702 organise, lui, la surveillance des communications de personnes non américaines.
Retenez la conséquence pratique, elle tient en une phrase : la localisation physique du serveur ne détermine pas l'exposition à une réquisition étrangère. Ce qui la détermine, c'est la nationalité et la structure capitalistique de l'opérateur.
Un exemple concret, très banal. Vos données sont stockées dans un datacenter parisien. Vraiment parisien, adresse vérifiable, personnel français. Sauf que ce datacenter est opéré par une filiale de droit irlandais ou luxembourgeois d'un groupe dont la maison mère est américaine. Le groupe entre alors dans le champ du Cloud Act, et la filiale européenne peut se voir demander de transmettre des données. « Hébergé en France » est parfaitement exact. Et parfaitement insuffisant.
Faut-il en faire une paranoïa ? Non. Le nombre de réquisitions visant des PME françaises est, disons-le, statistiquement négligeable. Mais la question devient très concrète dès lors que vous traitez des données stratégiques, que vous travaillez avec le secteur public, la défense, la santé, ou que vous êtes sur des marchés où un concurrent américain pourrait avoir un intérêt à l'information.
Les régimes sectoriels qui changent la donne
Certaines activités sortent du régime général et basculent dans des obligations bien plus strictes.
Les données de santé. Leur hébergement par un tiers impose la certification HDS (Hébergeur de Données de Santé). Ce n'est pas une option, c'est une obligation légale, et elle s'applique beaucoup plus largement qu'on ne le croit. Une plateforme de prise de rendez-vous médicaux, un site de téléconsultation, une application de suivi de traitement, un logiciel de gestion de cabinet paramédical : tous concernés, même s'il s'agit d'entreprises privées sans lien avec l'hôpital public. Beaucoup de projets développés par des agences généralistes sont en infraction sur ce point, souvent de bonne foi, parce que personne n'a posé la question au départ.
Le secteur public. La doctrine « cloud au centre » impose aux administrations le recours à des offres qualifiées SecNumCloud pour les données sensibles. Si vous répondez à des appels d'offres publics, l'exigence descendra jusqu'à vous, et donc jusqu'à votre prestataire.
La finance. Le règlement DORA, applicable depuis janvier 2025, encadre la résilience opérationnelle numérique des entités financières et de leurs prestataires informatiques critiques. Registre des prestataires, tests de résilience, clauses contractuelles obligatoires.
Les opérateurs d'importance vitale et les entités visées par NIS 2 relèvent d'un régime encore différent, avec des obligations de notification et de sécurité renforcées qui se répercutent en cascade sur toute la chaîne de fournisseurs.
Le réflexe à avoir : avant de vous demander quel hébergeur choisir, vérifiez si votre activité ne vous impose pas déjà une réponse. Cela évite de refaire le travail six mois plus tard.
Décryptage des arguments commerciaux
Passons au vocabulaire, parce qu'il y a beaucoup de bruit.
« Hébergement français » garantit que les serveurs sont physiquement en France. C'est déjà quelque chose. Cela ne dit rien sur la nationalité de l'opérateur, ni sur la localisation des sauvegardes, ni sur celle des équipes d'administration.
« Serveurs souverains » ne correspond à aucune définition juridique. Le terme n'est ni normé, ni protégé. N'importe qui peut l'employer.
« Cloud de confiance » renvoie à une doctrine française associant qualification SecNumCloud et immunité aux législations extraterritoriales. L'expression est parfois reprise sans que la qualification existe.
« Conforme RGPD » est probablement la mention la plus vide du marché. Il n'existe aucune certification RGPD généralisée en France. Un prestataire qui affiche ce logo s'auto-déclare conforme, ce qui n'engage strictement rien.
SecNumCloud, en revanche, c'est du solide. C'est une qualification délivrée par l'ANSSI, après audit approfondi, avec un périmètre défini, une date d'expiration et une liste publique consultable. Elle couvre la sécurité technique et l'immunité aux droits extra-européens. Peu d'acteurs la détiennent, précisément parce qu'elle est exigeante.
Le réflexe simple : toute mention valorisante doit pouvoir être ramenée à un référentiel nommé, un organisme certificateur identifié, un numéro et une date de validité. Si ce n'est pas le cas, c'est de la communication.
Comment savoir où sont réellement stockées vos données aujourd'hui
Enquêter soi-même, sans être ingénieur
Bonne nouvelle : une grande partie de l'information est publique. Il faut vingt minutes et aucune compétence technique particulière.
Étape 1 : trouver l'adresse IP de votre site. Un service de lookup DNS en ligne suffit, ou la commande nslookup votredomaine.fr depuis un terminal. Vous obtenez une ou plusieurs adresses IP.
Étape 2 : interroger le whois de cette IP. Les registres régionaux (le RIPE pour l'Europe) publient l'organisation à laquelle le bloc d'adresses est attribué. C'est là que le nom réel de l'hébergeur apparaît, et il ne correspond souvent pas du tout à celui que vous aviez en tête.
Étape 3 : identifier l'AS (autonomous system). Chaque opérateur réseau possède un numéro d'AS. Il vous donne l'opérateur d'infrastructure effectif, au-delà des revendeurs intermédiaires.
Étape 4 : lire les en-têtes de réponse HTTP. Ouvrez les outils de développement de votre navigateur (touche F12), onglet Réseau, rechargez la page, cliquez sur la première requête. Les en-têtes trahissent énormément : server, x-powered-by, la présence de cf-ray pour Cloudflare, x-amz- pour AWS, x-served-by pour Fastly. En quelques secondes vous savez si un CDN s'intercale, et lequel.
Étape 5 : examiner le certificat TLS. Cliquez sur le cadenas dans la barre d'adresse. L'autorité émettrice et les noms alternatifs du certificat révèlent parfois des infrastructures entières.
Attention à un piège classique : cette méthode identifie l'hébergement du site web. Elle ne dit rien de la base de données (qui peut être ailleurs), ni des sauvegardes, ni des outils tiers. C'est un point de départ, pas une cartographie complète. Mais quand le résultat contredit franchement ce que le prestataire raconte, vous avez déjà une conversation intéressante à engager.
Les questions à poser (et la façon de les poser)
Une question ouverte appelle une réponse floue. Une question fermée appelle un fait vérifiable. Formulez donc ainsi :
- Quelle est la dénomination sociale exacte et le numéro d'immatriculation de l'entité qui héberge les données ?
- Dans quel pays est immatriculée sa société mère ultime ?
- Quelle est l'adresse du ou des datacenters hébergeant la base de production ?
- Où sont physiquement stockées les sauvegardes, et pendant combien de temps sont-elles conservées ?
- Les environnements de test ou de recette contiennent-ils des données réelles de production ? Si oui, où sont-ils hébergés ?
- Pouvez-vous fournir la liste nominative complète des sous-traitants ultérieurs, avec pour chacun sa fonction et sa localisation ?
- Des personnels d'administration situés hors Union européenne disposent-ils d'un accès technique aux données, y compris pour de la maintenance ou du support ?
- Des données sont-elles transmises à des services d'intelligence artificielle, et si oui lesquels et sous quel régime ?
Cette dernière question est récente et de plus en plus déterminante. Un chatbot support, un outil de résumé automatique, une fonctionnalité de recommandation : autant de canaux par lesquels des données clients partent, parfois vers des serveurs américains, souvent sans que personne n'ait rien décidé consciemment.
Envoyez ces questions par écrit. Toujours. Une réponse orale rassurante n'a aucune valeur probatoire le jour où un problème survient.
Les documents à réclamer
Cinq pièces, et vous saurez à qui vous avez affaire :
- Le DPA signé (contrat de sous-traitance article 28). S'il n'existe pas, c'est le premier chantier.
- Le registre ou l'annexe des sous-traitants ultérieurs, nominatif et daté.
- Les certifications en cours de validité : ISO 27001, HDS, SecNumCloud, PCI-DSS selon le contexte. Exigez le certificat lui-même, pas un logo sur un site. Vérifiez trois choses : la date d'expiration, le périmètre exact (une certification peut ne couvrir qu'un seul datacenter ou qu'une seule offre), et l'organisme certificateur.
- Un rapport d'audit ou une attestation de tiers indépendant (SOC 2 Type II, par exemple).
- Le plan de reprise et de continuité d'activité, avec les objectifs chiffrés : RTO (durée maximale d'interruption admissible) et RPO (perte de données maximale admissible).
Les signaux qui doivent vous alerter
Certaines réponses en disent plus long que d'autres.
« Nos serveurs sont sécurisés et situés en France » sans autre précision. C'est une phrase, pas une information.
Le refus de nommer les sous-traitants au motif du secret des affaires. L'argument ne tient pas : l'article 28 du RGPD vous donne droit à cette information, et un prestataire sérieux la fournit sans discuter.
Une certification affichée mais expirée, ou dont le périmètre ne couvre pas votre service. C'est plus fréquent qu'on ne l'imagine, et rarement de la mauvaise foi. Souvent, personne n'a mis la page à jour depuis trois ans.
L'absence totale de DPA, ou un DPA que le prestataire découvre en même temps que vous.
« Les sauvegardes sont dans le cloud. » Quel cloud ? Opéré par qui ? Où ? Cette réponse-là devrait déclencher immédiatement une relance écrite.
Enfin, l'agacement. Un prestataire qui prend mal la question, qui la trouve tatillonne ou qui laisse entendre que vous manquez de confiance, c'est un prestataire qui n'a pas les réponses. Ceux qui les ont répondent en quelques heures, parfois avec un document déjà prêt, parce qu'on leur a posé la question vingt fois.
Le cas des outils que vous avez ajoutés vous-même
Voilà l'angle mort le plus courant, et il ne vient pas du prestataire. Il vient de vous.
Un formulaire de contact branché sur un outil externe. Un chat en ligne installé par le service commercial. Une plateforme de marketing automation connectée à la base clients. Un outil de prise de rendez-vous. Un assistant IA ajouté « pour tester » et jamais retiré. Un tracker publicitaire posé par l'agence média.
Chacune de ces intégrations déplace des données vers un tiers, souvent hors d'Europe, sans que le prestataire principal en soit informé, et parfois sans qu'il en ait la moindre visibilité technique.
Pour les recenser, une méthode qui prend une demi-journée : ouvrez les outils de développement, onglet Réseau, naviguez sur votre site comme un visiteur normal (page d'accueil, fiche produit, formulaire, tunnel de commande), et notez tous les domaines tiers appelés. Complétez avec le tag manager s'il en existe un, avec la liste des connecteurs de votre CRM, et avec un tour rapide auprès des équipes marketing et commerciale : « quels outils utilisez-vous qui contiennent des noms de clients ? » La réponse surprend presque toujours le dirigeant.
Les clauses à exiger noir sur blanc
On entre dans le concret. Voici les clauses qui comptent vraiment, avec ce qu'elles doivent contenir.
La clause de localisation
Le principe : nommer un périmètre géographique et l'étendre à tout.
« Le Prestataire s'engage à ce que l'ensemble des données à caractère personnel traitées pour le compte du Client soient stockées et traitées exclusivement sur le territoire de l'Union européenne. Cet engagement s'étend expressément aux bases de production, aux réplicas, aux sauvegardes quel qu'en soit le support, aux journaux applicatifs et aux environnements de développement, de test et de recette. Tout transfert, même temporaire, hors de ce périmètre, y compris pour des opérations de maintenance ou de support, est subordonné à l'accord écrit et préalable du Client. »
Les trois mots qui font toute la valeur de cette clause : sauvegardes, logs, environnements de test. Sans eux, vous n'avez protégé qu'une partie du périmètre.
La clause de sous-traitance ultérieure
Quatre exigences.
Une liste nominative en annexe du contrat, avec pour chaque sous-traitant sa raison sociale, sa fonction et sa localisation. Une obligation d'information préalable de tout ajout ou remplacement, avec un délai de prévenance chiffré (trente jours est un standard raisonnable). Un droit d'opposition motivé du client, assorti d'une solution en cas de désaccord (le prestataire propose une alternative, ou le client peut résilier sans pénalité). Enfin, la répercussion contractuelle : chaque sous-traitant ultérieur doit être lié par des obligations équivalentes, et le prestataire principal demeure pleinement responsable de leurs manquements.
Ce dernier point est essentiel. Sans lui, votre agence peut vous répondre « ce n'est pas nous, c'est notre hébergeur » et la conversation s'arrête là.
La clause d'audit et de preuve
Le droit d'audit est prévu par l'article 28, mais il reste théorique s'il n'est pas organisé. Précisez : audit sur pièces et sur site, fréquence (une fois par an, plus en cas d'incident avéré), préavis raisonnable, prise en charge des frais (généralement par le client, sauf si l'audit révèle un manquement), possibilité pour le prestataire de substituer une attestation de tiers indépendant à un audit direct, et surtout un délai maximal de réponse aux demandes documentaires. Trente jours, sinon la clause ne vaut rien.
La clause de notification d'incident
Vous disposez de 72 heures pour notifier une violation de données à la CNIL. Ce délai court à partir du moment où vous en avez connaissance. Si votre prestataire vous prévient au bout de 70 heures, vous êtes cuit.
Exigez donc un délai nettement plus court : 24 heures maximum à compter de la découverte, idéalement 12. Nommez le canal de notification (une adresse mail dédiée, un contact identifié, pas « le support »). Définissez le contenu minimal : nature de la violation, catégories et volume approximatif de données concernées, catégories et nombre de personnes concernées, conséquences probables, mesures prises ou envisagées. Ajoutez une obligation d'assistance active dans les démarches déclaratives, y compris la fourniture des éléments techniques.
Un prestataire qui refuse un délai inférieur à 72 heures vous dit en creux qu'il n'a pas de dispositif de détection. C'est en soi une information.
La clause de réversibilité et de restitution
C'est la clause la plus souvent absente. C'est aussi celle dont l'absence coûte le plus cher.
Scénario vécu par beaucoup : vous décidez de changer d'agence. Vous demandez vos données. On vous répond que c'est possible, bien sûr, mais que cela représente « environ quinze jours de travail » à facturer. Ou bien on vous livre un export dans un format propriétaire que personne d'autre ne sait relire. Ou bien on ne vous répond simplement plus.
Ce qu'il faut écrire :
« En cas de cessation du contrat, pour quelque cause que ce soit, le Prestataire s'engage à restituer au Client l'intégralité des données dans un format ouvert, structuré, documenté et couramment utilisé, dans un délai maximal de quinze jours ouvrés à compter de la demande. La documentation du format et du schéma de données est fournie avec l'export. Le Prestataire assure une assistance à la migration pour un volume de X jours, au tarif journalier fixé à l'annexe Y. À l'issue de la restitution et après confirmation écrite du Client, le Prestataire procède à la suppression définitive des données, y compris des sauvegardes, et en délivre une attestation dans un délai de trente jours. »
Le point capital : le coût de la réversibilité doit être plafonné ou forfaitisé dès la signature. Négocié au moment du départ, il devient un levier de pression. Négocié à l'entrée, quand le prestataire veut décrocher le contrat, il est presque toujours accepté.
La clause de propriété
Elle paraît évidente. Elle ne l'est pas.
« Le Client demeure seul propriétaire des données, contenus, fichiers et bases constitués dans le cadre du présent contrat. Le Prestataire ne dispose sur ces éléments d'aucun droit de rétention, de quelque nature que ce soit, y compris en cas de litige commercial ou de contestation portant sur le paiement des prestations. »
Il faut traiter ce sujet frontalement, parce que la rétention de données comme moyen de pression existe. Elle est juridiquement très contestable, elle finit généralement mal pour celui qui la pratique, mais entre-temps l'entreprise cliente est paralysée. Un site coupé, un fichier clients inaccessible, un référencement qui s'effondre : le temps de la procédure judiciaire, le mal est fait.
Une clause explicite ne rend pas la rétention impossible. Elle la rend beaucoup plus risquée pour celui qui l'envisage, et elle accélère considérablement une éventuelle procédure de référé.
La clause de continuité
Que se passe-t-il si votre prestataire disparaît ? Liquidation judiciaire, rachat, départ du développeur unique qui connaissait le projet : ce n'est pas rare, surtout avec des structures de quelques personnes.
Prévoyez : un séquestre des accès et, si le code est spécifique, un séquestre du code source auprès d'un tiers de confiance. Un engagement de niveau de service (disponibilité, délai de rétablissement) assorti de pénalités réelles, pas symboliques. Une procédure explicite en cas de défaillance.
Et surtout, le geste le plus simple et le plus efficace de tout cet article : les comptes d'administration doivent être ouverts au nom de votre entreprise, avec votre adresse mail, votre moyen de paiement. Nom de domaine, DNS, hébergement, dépôt de code, comptes analytics. Le prestataire y accède comme utilisateur délégué. Cette seule mesure élimine 80 % des situations de blocage.
Les clauses à refuser
Quatre pièges classiques.
La modification unilatérale des conditions, souvent formulée en « le Prestataire se réserve le droit de modifier les présentes ». Refusez, ou exigez un droit de résiliation sans frais en cas de modification substantielle.
La sous-traitance libre sans information ni opposition. Elle vide de son sens tout le reste du contrat.
La limitation de responsabilité dérisoire, du type « la responsabilité du Prestataire est limitée au montant des trois derniers mois de prestation ». Confrontez le chiffre au risque réel : une sanction CNIL peut atteindre 4 % du chiffre d'affaires mondial. Un plafond à 3 000 € face à un risque à six chiffres n'est pas un plafond, c'est une exonération déguisée.
Enfin, la combinaison mortelle : tacite reconduction longue plus réversibilité payante et non chiffrée. Vous êtes engagé pour trois ans et sortir vous coûtera un montant que vous découvrirez le jour où vous voudrez partir.
Arbitrer : quel niveau d'exigence pour quelle situation
Une grille par profil
Site vitrine sans collecte de données. Un formulaire de contact, peut-être une newsletter. Exigences minimales : DPA signé, hébergement UE, mentions légales à jour, accès au nom de l'entreprise. Sur-dimensionnement inutile : certification ISO, audit annuel, séquestre de code.
E-commerce. Base clients, historique de commandes, parfois des milliers de comptes. Ajoutez : clause de réversibilité chiffrée (essentielle, la base clients est votre premier actif), notification d'incident sous 24 heures, PCI-DSS via le prestataire de paiement, sauvegardes localisées et testées. Un point souvent négligé : demandez la preuve qu'une restauration de sauvegarde a été testée récemment. Une sauvegarde jamais restaurée n'est pas une sauvegarde, c'est une hypothèse.
Plateforme traitant des données sensibles. Santé, données biométriques, situations de vulnérabilité. Le régime change : certification HDS si santé, analyse d'impact obligatoire, chiffrement de bout en bout, journalisation des accès, DPO recommandé sinon obligatoire. Ne transigez pas ici, et n'acceptez pas un prestataire généraliste qui vous assure que « ça devrait aller ».
Activité candidate aux marchés publics. Anticipez SecNumCloud pour les données sensibles, préparez un dossier de conformité réutilisable. L'exigence viendra du donneur d'ordre, et il sera trop tard pour migrer entre la publication de l'appel d'offres et la remise des plis.
Activité exportatrice ou internationale. La question des transferts devient centrale dans les deux sens. Vérifiez aussi les législations locales des pays où vous opérez : plusieurs imposent une localisation nationale des données de leurs ressortissants.
Le coût réel de la souveraineté
Autant l'assumer : un hébergement qualifié coûte plus cher. Parfois deux à trois fois plus qu'une offre cloud grand public. Et il offre souvent moins de services managés, moins d'automatisation, un écosystème plus restreint.
Quand l'écart est justifié ? Quand vous traitez des données sensibles. Quand un régime sectoriel l'impose. Quand vos clients l'exigent contractuellement. Quand la donnée elle-même constitue votre avantage concurrentiel.
Quand il ne l'est pas ? Pour un site vitrine. Pour un blog. Pour des données déjà publiques. Payer une qualification ANSSI pour héberger un catalogue produit consultable par tous relève de la posture, pas de la sécurité.
Le vrai critère n'est pas idéologique. Il est simple : que se passe-t-il concrètement si ces données sont exposées, perdues, ou rendues inaccessibles pendant une semaine ? Répondez à cette question, chiffrez-la, et le niveau d'exigence se déduit tout seul.
Ce qui se négocie vraiment
Un mot de lucidité pour finir cette partie.
Une agence de cinq personnes ne signera pas les mêmes engagements qu'un éditeur de cent cinquante salariés avec un juriste et un RSSI. Elle ne le peut pas, matériellement. Lui faire signer une annexe de quinze pages qu'elle ne pourra jamais appliquer ne vous protège pas : cela vous donne l'illusion d'être protégé, ce qui est nettement pire.
Mieux vaut trois clauses réellement tenues qu'un pavé décoratif. Et si l'on devait n'en garder que trois, ce seraient celles-ci : les accès au nom du client, la réversibilité chiffrée dès la signature, la localisation étendue aux sauvegardes.
Ces trois-là, un petit prestataire honnête les accepte sans difficulté. S'il les refuse, la question n'est plus contractuelle. Elle est sur le choix du prestataire.
Plan d'action : sécuriser une relation déjà engagée
Vous avez lu ce qui précède et vous vous dites que rien de tout cela n'a été fait. C'est le cas de l'immense majorité des entreprises. Voici comment rattraper, dans l'ordre.
Étape 1 : cartographier l'existant
Un tableau, quatre colonnes : donnée concernée, outil qui la traite, entité hébergeante, localisation.
Recensez tous les prestataires, tous les outils SaaS, tous les flux. Utilisez la méthode d'investigation technique décrite plus haut, complétée par un entretien avec chaque service qui manipule des données clients.
Comptez une demi-journée pour une PME, deux ou trois pour une structure plus étoffée. Ce tableau vous servira ensuite en permanence : registre des traitements, réponses aux questionnaires de conformité, réponse à un incident. C'est le document le plus rentable de tout le processus.
Étape 2 : envoyer une demande formelle
Un mail suffit, mais un mail construit. Rappelez le fondement : article 28 du RGPD et votre qualité de responsable de traitement. Listez précisément les informations demandées (reprenez la liste de questions plus haut). Fixez un délai raisonnable, quinze à trente jours. Précisez que la réponse sera versée à votre registre des traitements.
Ce cadrage change complètement la nature de l'échange. Ce n'est plus un client curieux, c'est un responsable de traitement qui exerce une obligation légale. Les réponses arrivent plus vite, et elles sont plus précises.
Étape 3 : combler les manques contractuels
N'essayez pas de renégocier tout le contrat. Un avenant ciblé passe infiniment mieux, et se signe en quelques semaines plutôt qu'en six mois.
Hiérarchisez : d'abord le DPA s'il manque, puis la réversibilité, puis la localisation étendue, puis la notification d'incident. Le reste peut attendre le renouvellement.
Et choisissez le bon moment. Trois fenêtres s'ouvrent naturellement : le renouvellement annuel, le lancement d'un nouveau projet (vous avez alors un vrai levier), et l'annonce d'une hausse tarifaire (une hausse acceptée contre des garanties contractuelles est un échange équilibré, et généralement bien reçu).
Étape 4 : reprendre la main sur les accès
Faites la liste : registrar du nom de domaine, gestion DNS, panneau d'hébergement, dépôt de code, comptes analytics, outils marketing, comptes de facturation.
Pour chacun, une seule question : le compte propriétaire est-il au nom de votre entreprise ?
Si la réponse est non, demandez le transfert. C'est une opération technique simple, une heure de travail dans la plupart des cas. Un prestataire de bonne foi le fait sans discuter. Un prestataire qui traîne, qui trouve des obstacles, qui « va voir » : vous venez d'apprendre quelque chose d'important sur votre relation.
Geste modeste, effet immédiat sur le rapport de force. Et sur votre capacité à réagir vite le jour où quelque chose se passe mal.
Étape 5 : instaurer un contrôle périodique
Une revue annuelle, une demi-journée, à date fixe. On met à jour la cartographie, on vérifie les dates d'expiration des certifications, on contrôle que la liste des sous-traitants n'a pas bougé sans notification, on met à jour le registre des traitements.
Cela paraît anodin. C'est pourtant ce qui distingue une conformité réelle d'une conformité de façade : la première est datée et vivante, la seconde est un PDF de 2019 dans un dossier partagé.
Questions fréquentes
Mon prestataire refuse de me dire où sont mes données : que faire ?
D'abord, formalisez la demande par écrit, en visant l'article 28 du RGPD. Beaucoup de refus initiaux sont des malentendus qui se dissipent dès que la demande devient formelle.
Si le refus persiste, rappelez que vous êtes responsable de traitement et que cette information vous est légalement nécessaire. Mentionnez, sans agressivité, qu'un défaut d'information vous placerait dans l'impossibilité de tenir votre registre. Fixez un délai.
En cas de blocage complet, vous pouvez saisir la CNIL. Mais soyons pragmatiques : un prestataire qui refuse de nommer son hébergeur est un prestataire dont vous devez planifier le remplacement. Le vrai sujet n'est plus l'information, c'est la confiance, et elle est déjà rompue.
Un hébergement chez un acteur américain est-il interdit ?
Non. Ni interdit, ni illégal en soi.
Il suppose un encadrement : adhésion au Data Privacy Framework ou clauses contractuelles types, analyse d'impact des transferts, mesures supplémentaires si nécessaire, information des personnes concernées.
Ce qui est déconseillé, c'est de le faire sans le savoir, sans encadrement, et sans plan B. Et c'est franchement inadapté pour des données de santé, des données stratégiques ou une activité liée au secteur public.
Suis-je responsable si c'est mon agence qui a fait l'erreur ?
Oui, devant la CNIL et devant les personnes concernées. En tant que responsable de traitement, vous répondez du choix de vos sous-traitants et de la surveillance de leur activité. L'article 28 vous impose d'ailleurs de ne recourir qu'à des sous-traitants présentant des garanties suffisantes, ce qui suppose de les avoir vérifiées.
Vous pouvez ensuite vous retourner contre votre prestataire pour obtenir réparation. Encore faut-il que le contrat le permette, et que la limitation de responsabilité ne réduise pas votre recours à néant. D'où l'importance des clauses évoquées plus haut.
Que vaut la mention « conforme RGPD » sur un site de prestataire ?
Rien, ou presque. Il n'existe pas de certification RGPD généralisée en France. C'est une auto-déclaration.
Ce qui a de la valeur : une certification ISO 27001 en cours de validité avec un périmètre défini, une certification HDS pour la santé, une qualification SecNumCloud, un rapport SOC 2 Type II, un DPA complet et signé. Tout ce qui est vérifiable auprès d'un tiers, en somme.
Puis-je changer d'hébergeur sans refaire mon site ?
Dans la grande majorité des cas, oui. Une migration d'hébergement est une opération courante : on transfère les fichiers, la base de données, on ajuste la configuration, on bascule le DNS. Comptez de quelques heures à quelques jours selon la complexité.
Les vraies difficultés surviennent quand l'application dépend de services propriétaires de l'hébergeur actuel, quand le code n'est pas documenté, ou quand personne ne dispose des accès complets. Ce qui ramène toujours au même point : les accès et la documentation, dès le départ.
Mes données de sauvegarde sont-elles soumises aux mêmes règles ?
Oui, intégralement. Une sauvegarde contient des données personnelles, donc le RGPD s'y applique : localisation, sécurité, durée de conservation, droit à l'effacement.
Le sujet de l'effacement mérite une nuance. La CNIL admet qu'on ne restaure pas une sauvegarde entière pour en supprimer une ligne. La solution acceptée : documenter la politique de rotation, s'engager à ne pas réintroduire les données supprimées en cas de restauration, et fixer une durée de conservation raisonnable pour que les sauvegardes anciennes s'effacent d'elles-mêmes.
Il n'en reste pas moins que les sauvegardes sont, sur le plan de la localisation, exactement aussi sensibles que la production. Et ce sont elles qu'on oublie.
Conclusion
L'hébergement n'est pas un sujet technique qu'on délègue avec le reste du chantier. C'est une question de contrôle sur un actif commercial, au même titre que votre bail, vos brevets ou votre fichier fournisseurs.
La différence, c'est que cet actif-là est invisible. On ne le voit pas s'abîmer, on ne le voit pas partir, et le jour où on veut le récupérer, on découvre qu'on n'en avait jamais eu la clé.
Trois exigences à retenir, non négociables, quel que soit votre profil et quelle que soit la taille de votre prestataire.
Un : les accès au nom de votre entreprise. Nom de domaine, DNS, hébergement, dépôts. C'est gratuit, cela prend une heure, et cela change tout.
Deux : la réversibilité chiffrée dès la signature. Format d'export documenté, délai ferme, coût plafonné. Négociée à l'entrée, elle est presque toujours accordée. Négociée à la sortie, elle se paie très cher.
Trois : la localisation étendue aux sauvegardes, aux logs et aux environnements de test. Sans cette extension, l'engagement de localisation ne couvre qu'une fraction de vos données.
Le reste est affaire de proportionnalité, de secteur et de négociation. Mais ces trois-là, obtenez-les. Même si le reste attend.
Et si l'exercice paraît lourd, rappelez-vous qu'il se fait une fois, puis se met à jour une demi-journée par an. Face au coût d'un incident mal géré ou d'une séparation conflictuelle, le calcul est vite fait. Un audit de conformité, une relecture contractuelle ou l'accompagnement d'une migration se financent tout seuls le jour où ils servent.
