Pour héberger une application métier, partez de vos données, pas des fournisseurs. Une application qui traite des données de gestion courantes peut être hébergée dans un cloud public, dans une région européenne, avec un contrat conforme au RGPD. Des données de santé imposent un hébergeur certifié HDS. Des données sensibles de l’État, ou des données stratégiques que vous voulez protéger des lois extraterritoriales, orientent vers une offre qualifiée SecNumCloud par l’ANSSI. Dans tous les cas, la sécurité et la réversibilité de l’application se conçoivent en plus du choix de l’hébergeur.
Ce guide clarifie les labels, puis propose une grille de décision et la liste de ce qu’un contrat d’hébergement doit couvrir.
Cloud public, cloud souverain, SecNumCloud : de quoi parle-t-on ?
Les termes se mélangent dans les discours commerciaux. Voici les définitions utiles.
- Un cloud public est une infrastructure mutualisée, louée à la demande, opérée par un fournisseur qui la partage entre de nombreux clients. Les grands fournisseurs proposent des « régions » européennes où les données sont stockées.
- Un cloud « souverain » désigne, dans l’usage courant, une offre opérée par une entreprise européenne, sur des centres de données européens, et non soumise à des lois étrangères. Ce n’est pas une catégorie juridique : n’importe qui peut employer le mot.
- SecNumCloud est une qualification délivrée par l’ANSSI. Selon l’agence, elle reconnaît des offres IaaS, PaaS ou SaaS « de confiance », capables de protéger les données sensibles face à la menace cybercriminelle et à l’application de lois extraterritoriales. La liste des offres qualifiées est publiée dans le catalogue de l’ANSSI.
- HDS (hébergeur de données de santé) est une certification obligatoire, prévue par l’article L.1111-8 du code de la santé publique, pour quiconque héberge des données de santé à caractère personnel pour le compte d’un tiers.
Trois sigles décrivent le niveau de service acheté. IaaS : vous louez des machines et du stockage, et vous administrez le reste. PaaS : le fournisseur gère aussi les systèmes, les bases de données ou l’exécution du code. SaaS : vous utilisez une application prête à l’emploi. Plus vous montez, moins vous avez à administrer, mais plus vous dépendez du fournisseur.
Ce que disent les textes en 2026
Données de santé : le référentiel HDS renforcé
Le référentiel de certification HDS a été révisé par un arrêté du 26 avril 2024, publié au Journal officiel le 16 mai 2024. D’après l’analyse du cabinet CMS, il apporte trois changements majeurs :
- l’hébergement physique des données de santé doit être réalisé exclusivement dans l’Espace économique européen ;
- si les données sont accessibles depuis un pays hors de l’Union ou si l’hébergeur est soumis à une législation extra-européenne non adéquate, il doit en informer son client dans le contrat, avec les risques et les mesures prises ;
- l’hébergeur publie sur son site une cartographie des transferts de données hors de l’EEE.
Les hébergeurs déjà certifiés avaient jusqu’au 16 mai 2026 pour basculer sur ce nouveau référentiel : en 2026, un certificat HDS à jour doit donc s’y référer. Si vous opérez dans le secteur sanitaire et médico-social, c’est la première vérification à faire.
Données sensibles de l’État : SecNumCloud devient opposable
La loi visant à sécuriser et réguler l’espace numérique (dite SREN) impose aux administrations, aux opérateurs de l’État et à certains groupements d’intérêt public de recourir, pour les données d’une sensibilité particulière, à des offres cloud protégées contre les lois extraterritoriales. Le décret n° 2026-272 du 14 avril 2026 a précisé la notion de données sensibles et, selon la Banque des Territoires, rend « enfin opposable » l’obligation de recourir à des prestataires qualifiés SecNumCloud ou à une certification européenne équivalente. Un arrêté du 12 août 2026 a ensuite approuvé le référentiel d’exigences correspondant, comme le relève le cabinet Landot.
Pour une PME ou une ETI, ces textes ne s’appliquent pas directement. Ils comptent dès que vous développez ou opérez un service pour un acheteur public concerné : l’exigence se retrouve alors dans le marché.
Données personnelles : le RGPD encadre les transferts, pas la nationalité
Le RGPD n’impose pas d’héberger en France. Il encadre les transferts de données personnelles hors de l’Union, qui exigent une décision d’adéquation ou des garanties appropriées, comme l’explique la CNIL. Pour les États-Unis, la Commission européenne a adopté le 10 juillet 2023 une décision d’adéquation qui couvre les organisations certifiées dans le cadre du Data Privacy Framework. L’hébergeur reste votre sous-traitant au sens du RGPD : le contrat doit en porter les clauses. Nous détaillons ces points dans notre article sur le RGPD dans une application métier.
Quelle option pour quel besoin ?
| Option | Points forts | Points de vigilance | Adaptée à |
|---|---|---|---|
| Cloud public, région européenne | Catalogue de services très large, montée en charge, outillage mature | Exposition aux lois extraterritoriales, dépendance aux services propriétaires | Applications de gestion, SaaS B2B sans données sensibles |
| Fournisseur cloud européen non qualifié | Opérateur soumis au droit européen, interlocuteurs proches | Catalogue plus restreint, niveau de sécurité à vérifier soi-même | Données confidentielles, clients attentifs à la souveraineté |
| Offre qualifiée SecNumCloud | Exigences contrôlées par l’ANSSI, protection contre les lois extraterritoriales | Offres moins nombreuses, services managés plus limités | Données sensibles, marchés publics concernés, secrets industriels |
| Hébergeur certifié HDS | Conformité obligatoire pour la santé, hébergement dans l’EEE | Périmètre de certification à vérifier activité par activité | Toute application qui héberge des données de santé |
| Serveurs internes (sur site) | Maîtrise physique totale | Sécurité, redondance, astreinte et mises à jour entièrement à votre charge | Contraintes très spécifiques, réseau isolé d’atelier |
Ces options se combinent. Une même application peut héberger son cœur métier sur une offre qualifiée et utiliser un service tiers pour l’envoi d’e-mails, à condition de savoir précisément quelles données sortent et vers où.
La grille de décision en six questions
Avant de comparer des offres, répondez à ces questions, de préférence avec votre DPO et vos principaux clients :
- Quelles données l’application traite-t-elle ? Données de gestion, données personnelles, données de santé, secrets d’affaires, données couvertes par un secret légal.
- Une réglementation impose-t-elle un label ? HDS pour la santé, exigences SecNumCloud dans certains marchés publics, obligations de sécurité liées à NIS2 pour les entités concernées.
- Que demandent vos clients ? De plus en plus de questionnaires de sécurité de grands comptes interrogent la localisation, l’exposition extraterritoriale et la certification de l’hébergeur.
- Quelle interruption pouvez-vous tolérer ? Le délai maximal de remise en service (RTO) et la perte de données maximale admissible (RPO) dimensionnent la redondance et les sauvegardes.
- Qui administre ? Votre équipe, votre prestataire de développement, un infogérant ? La réponse détermine le niveau de service (IaaS, PaaS) et parfois le périmètre de certification.
- Comment en sortir ? Si changer d’hébergeur demande de réécrire l’application, vous n’avez pas vraiment choisi.
Ce que le label ne fait pas à votre place
L’ANSSI le rappelle elle-même : la qualification d’une offre ne garantit pas la sécurité des services numériques que le client y héberge. Le modèle est celui de la responsabilité partagée : le fournisseur sécurise son infrastructure, vous restez responsable de ce que vous y déployez.
Côté application, cela recouvre notamment :
- la gestion des accès : authentification forte pour les administrateurs, comptes nominatifs, droits minimaux ;
- le chiffrement des données en transit et au repos, avec une gestion des clés maîtrisée ;
- les sauvegardes : automatiques, stockées hors de l’environnement principal, et surtout restaurées régulièrement à titre de test ;
- la journalisation des actions sensibles et la surveillance des anomalies ;
- les mises à jour des composants, suivies dans le cadre de la maintenance applicative ;
- la sécurité du code lui-même, qui relève des bonnes pratiques décrites dans notre article sur l’OWASP Top 10.
Comment garder la liberté de changer d’hébergeur ?
La réversibilité se prépare dans l’architecture et dans le contrat.
Dans l’architecture, trois choix limitent la dépendance : conteneuriser l’application pour qu’elle tourne à l’identique d’un fournisseur à l’autre, décrire l’infrastructure sous forme de code pour pouvoir la recréer ailleurs, et privilégier des briques standard (bases de données relationnelles, stockage objet compatible, files de messages ouvertes) plutôt que des services exclusifs à un fournisseur. Ce n’est pas un dogme : un service propriétaire peut être un bon choix s’il fait gagner beaucoup, à condition d’isoler son usage.
Dans le contrat, vérifiez au minimum :
| Clause | Ce qu’elle doit prévoir |
|---|---|
| Localisation | Pays des centres de données, des sauvegardes et des équipes d’administration |
| Sous-traitance | Liste des sous-traitants ultérieurs et information en cas de changement |
| Accès étrangers | Exposition à des lois non européennes, conduite en cas de demande d’une autorité |
| Disponibilité | Engagement de service, pénalités, procédure d’incident |
| Sauvegardes | Fréquence, durée de conservation, tests de restauration |
| Réversibilité | Restitution des données dans un format standard, délais, assistance, effacement certifié |
| Certifications | Périmètre exact (activités HDS, services qualifiés SecNumCloud), dates de validité |
Pour le code de l’application lui-même, la réversibilité relève du contrat de développement : c’est l’objet de notre article sur la propriété du code source.
En pratique : la démarche que nous recommandons
- Classer les données de l’application par niveau de sensibilité dès le cadrage.
- En déduire les labels obligatoires, puis les attentes des clients clés.
- Fixer les objectifs de reprise (RTO, RPO) avec la direction, pas seulement avec l’informatique.
- Choisir l’hébergeur sur cette base, puis concevoir une architecture portable.
- Contractualiser localisation, sous-traitance, sauvegardes et réversibilité.
- Tester la restauration et le plan de reprise avant la mise en production, puis chaque année.
Lorsque nous développons une application web sur mesure, l’hébergement fait partie du cadrage : nous déployons sur l’infrastructure qui correspond à vos données et à vos clients, et la documentation permet de la reprendre ou de la déplacer. Pour savoir quel niveau d’hébergement votre projet exige, décrivez-le dans notre diagnostic de projet.
