Hébergement souverain : le modèle de cahier des charges pour 2026

En 2026, le choix de votre infogéreur n'est plus une simple validation technique entre DSI. C’est une décision stratégique qui engage la responsabilité pénale des dirigeants.

Notre précédent modèle de cahier des charges était orienté performance et MCO (Maintien en Condition Opérationnelle). Aujourd'hui, la question n'est plus seulement de savoir où sont vos données mais sous quelle juridiction elles tombent.

L'accumulation des contraintes: Directive NIS 2, Cloud Act américain et Plan de souveraineté numérique de la DINUM a changé la donne. La géographie ne vous protège plus: un serveur à Paris opéré par un acteur soumis au droit US reste une faille juridique majeure.

Pour répondre à ce contexte, nous avons actualisé notre trame de référence.

×

Ce qui a changé (et pourquoi c’est critique)

Notre modèle historique posait les bonnes questions techniques (trafic, SLA, PRA). Nous les avons conservées, mais nous y avons ajouté quatre sections.

1. Trajectoire Linux et Souveraineté (Section 04)

Ce n'est pas une préférence idéologique, c'est un critère d'exclusion. La migration vers Linux est devenue un prérequis dans la quasi-totalité des appels d'offres publics et des schémas directeurs souverains. Découvrir une dépendance Windows Server au moment du cadrage est une dette technique qui peut bloquer votre conformité DINUM.

2. Réversibilité : la fin du "Vendor Lock-in" (Section 06)

C'est souvent là que ça coince deux ans après la signature. Pouvoir changer d'hébergeur sans reconstruire toute son infrastructure, c'est un critère architectural qui se décide au départ, pas à la sortie.

3. Bloc Souveraineté et Conformité NIS 2 (Section 08)

Etes-vous soumis à NIS 2 ? Votre hébergeur actuel est-il soumis au Cloud Act ? Avez-vous une obligation de qualification ANSSI ? Est-ce que la doctrine DINUM vous concerne directement ou indirectement ? 

Ces questions permettent à l'infogéreur que vous allez consulter,  que ce soit nous ou quelqu'un d'autre, de vous proposer une architecture adaptée à votre réalité réglementaire.

4. Grille d’auto-évaluation (Section 11)

Nous avons intégré huit critères d’auto-évaluation car la plupart des organisations ignorent encore leur niveau réel d'exposition aux lois extraterritoriales.

Lever les freins : coût, technique et méthode

Migrer vers du souverain fait souvent peur. On redoute une explosion des coûts ou une perte de services.

Pour lever ces freins, ce cahier des charges doit être lu en parallèle de notre approche sur la responsabilité des dirigeants face à la souveraineté. Nous y détaillons notamment :

• La méthode de migration (de l'architecture standard au Cloud Native) pour traiter votre dette technique.
• Le pilotage FinOps pour passer d'une facture cloud aléatoire à un budget maîtrisé.
• Le comparatif réel entre hyperscalers (AWS, Azure, GCP) et cloud souverain européen.

×

Précisions sur le cadre d'utilisation du document 

On ne vous promet pas une infrastructure "certifiée ANSSI". La certification est un processus d'audit officiel qui porte sur un produit ou service spécifique, pas une étiquette qu'un prestataire peut se coller. 

Ce cahier des charges n'est pas non plus un document de conformité juridique. C'est un outil de cadrage. Si votre situation nécessite une analyse juridique approfondie, notamment autour de NIS 2 ou de marchés publics, vous aurez besoin d'un avocat spécialisé en droit du numérique en complément.

Pour qui est-ce utile ?

• Pour une DSI ou un responsable IT qui prépare une consultation et veut structurer son brief sans oublier les dimensions réglementaires.
• Pour un dirigeant ou un DAF qui a entendu parler de NIS 2 ou du Cloud Act et qui veut comprendre concrètement ce que ça implique pour son choix d'hébergeur.
• Pour une collectivité ou un organisme public qui doit construire sa feuille de route souveraineté et qui ne sait pas par quel bout commencer.
• Pour une ESN ou un intégrateur qui accompagne ce type de client et qui cherche un document de qualification à faire remplir en amont.