Souveraineté numérique & éco-conception — Stack France 100 %

#Souveraineté numérique & numérique responsable — reprendre la main sur la couche technique

La souveraineté numérique n'est pas un slogan de colloque : c'est une propriété d'architecture, qui se vérifie brique par brique en répondant à trois questions. Quelle juridiction peut contraindre l'entité qui détient effectivement vos données ? Que se passe-t-il si ce fournisseur devient indisponible, modifie unilatéralement ses conditions ou triple ses tarifs ? Et combien de semaines vous faut-il, réellement, pour en sortir ?

Tant qu'une DSI ne sait pas répondre à ces trois questions pour chaque composant critique de son SI, elle n'a pas de stratégie de souveraineté. Elle a une intention. La différence apparaît le jour où un auditeur, un régulateur ou un acheteur public demande les pièces.

Le numérique responsable procède de la même logique sur un autre axe : mesurer avant d'optimiser, réduire le périmètre fonctionnel avant de micro-optimiser le code, documenter plutôt que proclamer. Les deux sujets convergent souvent — moins de dépendances tierces, c'est moins de requêtes, moins de données transportées, moins de surface d'attaque. Ils s'opposent parfois, et cette page dit aussi où.

Ce que nous faisons concrètement : auditer l'exposition juridique et technique d'un SI existant, définir une cible souveraine réaliste, migrer par couches sans arrêter la production, déployer des modèles de langage français en API souveraine ou en auto-hébergement, mettre un service en conformité avec les référentiels d'écoconception. Notre stack souveraine de référence — celle que nous opérons en production chez nos clients — repose sur Next.js, Postgres, Qdrant, Mistral et un hébergement OVHcloud. Nous ne vendons pas une architecture que nous n'opérons pas.

#Ce que « souverain » veut dire — et les trois confusions qui coûtent cher

Le mot recouvre des réalités très différentes. Trois confusions reviennent dans presque tous les dossiers que nous auditons.

#Confusion 1 : « nos données sont en France, donc nous sommes souverains »

La localisation physique des serveurs est un critère parmi d'autres, et pas le plus structurant. Ce qui détermine la juridiction applicable, c'est l'entité juridique qui opère le service et le groupe qui la contrôle — pas la latitude du datacenter. Une filiale française d'un groupe américain hébergeant à Paris reste, en analyse de risque, exposée aux injonctions adressées à sa maison mère. C'est le point central du CLOUD Act, et exactement ce que le référentiel SecNumCloud cherche à écarter par des exigences portant non sur la sécurité technique mais sur le droit applicable et le contrôle capitalistique.

#Confusion 2 : « c'est un acteur européen, donc c'est immunisé »

Européen ne signifie pas immunisé : tout se joue dans la chaîne de sous-traitance ultérieure. Un éditeur SaaS européen qui déploie sur un hyperscaler non européen déplace le problème d'un cran, il ne le résout pas. Dans nos cartographies, la colonne la plus révélatrice n'est jamais « pays du fournisseur » mais « sous-traitants ultérieurs déclarés dans le DPA » : CDN, brique anti-bot, moteur de recherche interne, outil de support, plateforme d'e-mails transactionnels.

#Confusion 3 : « c'est de l'open source, donc c'est souverain »

L'open source est une condition très favorable de la réversibilité, pas une garantie de souveraineté. Un logiciel libre consommé en SaaS chez un éditeur soumis à une juridiction extraterritoriale ne vous apporte rien de plus qu'un logiciel propriétaire, sauf si vous savez le réinstaller ailleurs et y restaurer vos données. L'open source auto-hébergé, lui, donne une maîtrise réelle — au prix d'une charge d'exploitation à assumer honnêtement dans le budget.

La bonne façon de raisonner est graduée, pas binaire. Nous évaluons chaque brique sur cinq axes : localisation des données, juridiction de l'entité contractante, chaîne de sous-traitance, réversibilité effective, maîtrise opérationnelle (qui détient les clés, qui administre, qui lit les journaux). Un SI peut être excellent sur quatre axes et catastrophique sur le cinquième — c'est celui-là qui fera tomber le dossier en audit.

#CLOUD Act, FISA, Schrems : l'état du droit sans dramatisation ni déni

Le débat est souvent conduit sur un registre émotionnel. Voici les éléments factuels sur lesquels nous construisons nos analyses de risque.

Le CLOUD Act est une loi fédérale américaine adoptée en 2018. Elle précise que les fournisseurs de services de communication et de stockage soumis à la juridiction des États-Unis peuvent être contraints de produire les données qu'ils détiennent, contrôlent ou possèdent, y compris lorsque ces données sont stockées hors du territoire américain. Elle organise par ailleurs un cadre d'accords exécutifs entre les États-Unis et des États tiers. Le point important pour un RSSI : le critère déclencheur est le rattachement du fournisseur à la juridiction américaine, non l'emplacement du disque.

Les programmes de collecte de renseignement américains, dont la section 702 du FISA, visent des catégories de fournisseurs de services de communications électroniques. Cette exposition, combinée à l'absence de voies de recours équivalentes pour les personnes concernées européennes, a nourri le contentieux devant la Cour de justice de l'Union européenne.

L'arrêt Schrems II (CJUE, affaire C-311/18, 16 juillet 2020) a invalidé le Privacy Shield et confirmé que les clauses contractuelles types ne suffisent pas seules : le responsable de traitement doit évaluer le droit du pays destinataire et, le cas échéant, adopter des mesures supplémentaires effectives. En pratique, cela impose une analyse d'impact du transfert documentée, pas une case cochée dans un contrat.

Depuis, une décision d'adéquation encadre les transferts vers les organisations américaines certifiées au titre du cadre de protection des données adopté en 2023. Ce cadre a fait l'objet de recours. Notre position, que nous assumons : on ne conçoit pas une architecture sur dix ans en pariant sur la pérennité d'une décision d'adéquation. Ce n'est pas une prédiction juridique, c'est une règle de conception.

Un mot enfin sur « Schrems III », qu'on lit régulièrement dans les appels d'offres. Ce n'est pas un texte réglementaire, c'est l'hypothèse d'un futur contentieux : exiger un projet « conforme Schrems III » n'a aucune portée juridique. Ce qui en a : une analyse d'impact des transferts, un chiffrement dont les clés restent sous contrôle du responsable de traitement, une cartographie des sous-traitants ultérieurs, un plan de réversibilité testé. Nous détaillons cette approche dans notre offre conformité RGPD stricte et transferts hors UE, et le glossaire Schrems II reprend les points de droit.

#SecNumCloud : ce que le référentiel ANSSI exige vraiment

SecNumCloud est un référentiel publié par l'ANSSI qui donne lieu à une qualification — un acte de l'autorité nationale — et non à une certification délivrée par un organisme privé. La nuance a des conséquences pratiques : le périmètre qualifié est précisément délimité (telle offre, telle région, tels services) et figure au catalogue publié par l'ANSSI, seule source qui fasse foi. Ne vous fiez pas à une plaquette commerciale : demandez le périmètre exact et vérifiez-le sur cyber.gouv.fr.

Le référentiel combine deux familles d'exigences.

Les exigences de sécurité couvrent ce qu'on attend d'un hébergeur de haut niveau : gouvernance, gestion des identités et des accès, cloisonnement, journalisation, cryptographie, sécurité physique, gestion des incidents, réversibilité, continuité d'activité. Sur ce plan, un fournisseur certifié ISO/IEC 27001 sérieux couvre déjà une partie du chemin.

Les exigences relatives au droit applicable et à la gouvernance du prestataire sont, elles, spécifiques : siège du prestataire, localisation des traitements et des équipes d'administration, structure de contrôle capitalistique, avec l'objectif explicite d'écarter l'exposition aux législations extraterritoriales. C'est ce bloc, et lui seul, qui distingue SecNumCloud d'une bonne certification internationale. Comparer ISO 27001 et SecNumCloud sur la seule sécurité technique, c'est passer à côté de l'essentiel.

Ce que SecNumCloud n'est pas : ni une certification d'hébergement de données de santé, qui relève d'un référentiel distinct ; ni un label environnemental ; ni une garantie que votre application est sécurisée. On peut parfaitement déployer une application vulnérable sur une infrastructure qualifiée.

Côté public, la doctrine dite « cloud au centre », formalisée par circulaire du Premier ministre en 2021 puis actualisée, oriente l'hébergement des données sensibles de l'État vers des offres qualifiées. Pour les collectivités et les opérateurs publics, la conséquence est directe : le critère devient discriminant en consultation. Notre guide de bascule SecNumCloud pour les collectivités détaille le déroulé, et la page SecNumCloud — Visa ANSSI décrit notre prestation.

Le contre-argument honnête, que nous formulons systématiquement : une offre qualifiée propose un catalogue de services plus étroit qu'un hyperscaler. Moins de services managés exotiques, moins de briques serverless clés en main, des cycles de mise à disposition plus lents. Une équipe habituée à assembler quinze services managés doit revenir à des composants standards — Postgres, Redis, Kubernetes, stockage objet compatible S3 — et les opérer. C'est faisable, c'est même souvent plus sain en termes de dette, mais ce n'est pas transparent pour l'équipe. Un projet qui ignore ce point dérape. Le comparatif cloud public vs cloud souverain et notre comparatif OVHcloud vs AWS posent les termes de l'arbitrage.

Enfin, un projet européen de schéma de certification des services cloud est en discussion au niveau de l'Union : ni son contenu ni son calendrier ne sont stabilisés, et nous déconseillons de conditionner une décision d'architecture à son adoption. Nous en suivons l'avancement sur notre blog souveraineté.

#Cartographier l'exposition : l'audit de souveraineté en pratique

Un audit de souveraineté ne commence pas par une discussion sur le cloud, mais par un inventaire. L'exercice paraît trivial ; il ne l'est jamais, parce qu'une partie des dépendances ne figure dans aucun contrat.

Nous produisons une matrice où chaque brique est décrite par sept colonnes : fonction assurée, éditeur, entité juridique effectivement contractante (et non la marque), localisation des traitements, sous-traitants ultérieurs déclarés, criticité métier, coût estimé de sortie. Cette dernière colonne déclenche les arbitrages en comité de direction, parce qu'elle transforme un débat idéologique en décision d'investissement.

#Les dépendances dormantes

Le poste le plus sous-estimé, systématiquement : les dépendances qu'aucun contrat ne mentionne, parce qu'elles ont été introduites par une décision technique et non par un achat.

• Des polices chargées depuis un CDN tiers à chaque affichage de page, ce qui transmet l'adresse IP de chaque visiteur.
• Un service anti-bot ou de gestion de consentement dont le script s'exécute avant tout le reste.
• Des SDK de télémétrie embarqués dans une application mobile, activés par défaut.
• Une brique de recherche, de traduction ou de cartographie appelée côté navigateur.
• Des sauvegardes répliquées dans une région différente de celle de production, souvent par défaut.
• Des webhooks sortants vers des outils no-code, qui font transiter des données métier hors périmètre.

Nous les détectons par analyse des requêtes réseau réelles en production, pas par lecture de la documentation. L'écart entre les deux est régulièrement significatif.

#Les quatre niveaux de criticité

Toutes les briques ne méritent pas le même effort. Nous classons en quatre niveaux : données personnelles sensibles ou stratégiques (1), données personnelles courantes (2), données internes non personnelles (3), données publiques (4). Un outil de niveau 4 hébergé hors UE n'est pas un problème ; le même outil en niveau 1 est bloquant. La souveraineté est un curseur qu'on positionne brique par brique, pas une religion qu'on applique uniformément. Vouloir tout rapatrier d'un coup est le meilleur moyen de ne rien livrer.

Livrables : la matrice complète, une note juridique par brique de niveau 1 et 2, une trajectoire de migration priorisée par ratio risque/effort, une estimation de charge par lot. Pour les organisations soumises à DORA ou à NIS2, cette matrice alimente directement le registre des prestataires TIC et l'analyse des dépendances critiques — même travail, capitalisé deux fois. Voir audit DORA, audit NIS2 et la checklist DORA/NIS2.

#IA souveraine : choix du LLM, régime de déploiement et pipeline RAG

C'est le sujet où la demande progresse le plus, et où les décisions sont le plus souvent prises sur des critères flous. Trois régimes de déploiement existent, aux profils de risque et de coût très différents.

#Régime 1 — API managée d'un éditeur européen

Vous appelez l'API d'un éditeur comme Mistral AI, dont les traitements s'opèrent en Europe. Simplicité opérationnelle d'un service managé, question du transfert hors UE écartée, dépendance maintenue à la disponibilité et à la politique tarifaire de l'éditeur. À vérifier au contrat : durée de rétention des prompts, usage éventuel des données pour l'entraînement (à exclure explicitement), localisation des traitements et des sauvegardes, préavis en cas de retrait d'un modèle. Ce dernier point est sous-estimé : un modèle déprécié, c'est un système de prompts et un jeu d'évaluation à refaire.

#Régime 2 — Modèle ouvert auto-hébergé sur cloud souverain

Vous déployez les poids d'un modèle ouvert sur des instances GPU d'un fournisseur français ou européen. Vous gagnez la maîtrise du cycle de vie du modèle — personne ne peut le déprécier sous vos pieds — et gardez l'élasticité du cloud. Vous assumez en contrepartie le dimensionnement, le serveur d'inférence, les mises à jour, la supervision et la gestion de la file d'attente.

#Régime 3 — On-premise strict

Les GPU sont dans vos murs, aucun flux ne sort du réseau. Coût d'entrée capitalistique, souplesse nulle, charge d'exploitation réelle. Nous le recommandons quand la contrainte est explicitement posée par le régulateur, le donneur d'ordre ou la classification de l'information — pas par confort psychologique. Voir Mistral en local et LLM on-premise vs API cloud.

#Le piège de licence que presque personne ne vérifie

« Poids publiés » ne signifie pas « utilisation commerciale libre ». Les modèles de la famille Mixtral (8x7B, 8x22B) sont publiés sous licence Apache 2.0, ce qui autorise l'usage commercial y compris en auto-hébergement. Les poids de Mistral Large 2, eux, relèvent d'une licence de recherche : un déploiement commercial auto-hébergé suppose une licence commerciale négociée avec l'éditeur. D'autres familles de modèles ouverts imposent des conditions d'usage spécifiques ou des seuils d'utilisateurs. Nous vérifions la licence effective des poids avant toute décision d'architecture et documentons ce contrôle dans le dossier de conformité. Cinq minutes de vérification évitent une régularisation coûteuse deux ans plus tard.

#Comment choisir, concrètement

Volume faible ou irrégulier : l'API managée européenne gagne presque toujours, le coût marginal est plat et il n'y a pas de GPU à amortir. Volume élevé, stable et prévisible : l'auto-hébergement devient compétitif, le point de bascule dépendant du couple débit visé / taille de modèle et se calculant projet par projet. Contrainte réglementaire explicite : la question du coût ne se pose plus dans les mêmes termes.

Un dernier arbitrage, souvent mal posé : la taille du modèle. Beaucoup de cas d'usage métier — classification, extraction structurée, reformulation, routage — sont traités par un petit modèle correctement instruit, pour une fraction du coût et de la consommation. Sur le raisonnement long, l'analyse documentaire complexe et la génération de code, l'écart entre les meilleurs modèles ouverts et les meilleurs modèles propriétaires reste perceptible. Nous le disons quand c'est le cas : un projet où la qualité de raisonnement est le facteur limitant n'est pas un bon candidat au tout-souverain, et mieux vaut traiter la question par le cloisonnement des données que par un modèle sous-dimensionné. Le comparatif Mistral Large vs Llama vs Phi et le comparatif Mistral vs OpenAI en entreprise documentent ces écarts. Pour la personnalisation, voir fine-tuning de LLM et LLM souverain & fine-tuning.

#Architecture RAG souveraine : la donnée qui ne sort pas

Dans la plupart des projets d'IA documentaire, la vraie question de souveraineté ne porte pas sur le modèle de génération mais sur le pipeline d'indexation : c'est là que la donnée circule. Une architecture RAG souveraine comporte cinq étages, et chacun peut fuir.

L'extraction. Les documents sources sont convertis en texte. Si vous utilisez un service d'OCR en ligne pour des courriers, des factures ou des dossiers médicaux, l'intégralité du corpus transite chez ce prestataire. Premier point de fuite, et le plus courant.

Le découpage et l'enrichissement. Étape locale, sans enjeu de transfert, mais déterminante pour la qualité : un découpage qui ignore la structure du document produit des réponses fausses même avec un excellent modèle.

Les embeddings. Point de vigilance majeur : utiliser un modèle d'embedding hébergé hors UE annule l'essentiel du bénéfice de souveraineté, puisque l'intégralité du corpus doit passer par ce service pour être vectorisée, puis chaque requête utilisateur à l'exécution. Nous utilisons des modèles d'embedding auto-hébergés ou des services européens, et nous le vérifions explicitement.

Le stockage vectoriel. Nous déployons Qdrant en auto-hébergement, ou pgvector quand le volume ne justifie pas une base dédiée — deux briques open source opérables sur infrastructure souveraine. Le comparatif Pinecone vs Qdrant vs Weaviate explique pourquoi nous écartons les bases disponibles uniquement en SaaS hors UE dès qu'il y a de la donnée personnelle.

La génération. Le LLM, selon l'un des trois régimes décrits plus haut.

S'y ajoutent deux exigences non négociables. Le cloisonnement par droits appliqué à la recherche, pas à la réponse : les filtres d'habilitation s'exécutent au moment de la requête vectorielle, de sorte qu'un document non autorisé ne soit jamais présenté au modèle. Filtrer après génération, c'est espérer que le modèle n'a pas déjà divulgué le contenu. Et la traçabilité : chaque réponse rattachable à ses sources, chaque accès journalisé — sans quoi vous ne pourrez ni instruire un incident, ni répondre à une demande d'exercice de droits.

Les corpus internes ouvrent enfin une surface d'attaque spécifique : un document piégé peut contenir des instructions destinées au modèle. Le traitement de ce risque relève de notre protocole sécurité LLM et OWASP. Voir aussi RAG sur documents internes et la méthode agents IA & RAG souverain.

#La stack applicative souveraine, couche par couche

Voici les briques que nous déployons, avec leur point de vigilance. Nous opérons cette stack en production chez nos clients.

Couche	Option souveraine retenue	Point de vigilance
Framework applicatif	Next.js en auto-hébergement (build standalone, conteneur)	Vérifier qu'aucune fonctionnalité ne dépend d'une plateforme d'hébergement spécifique
CMS	Payload CMS auto-hébergé	Stockage des médias sur objet compatible S3 chez l'hébergeur souverain
Base de données	PostgreSQL	Localisation des sauvegardes et des réplicas, souvent hors région par défaut
Cache, files, vecteurs	Redis, Qdrant ou pgvector selon la charge	Éviter les services managés propriétaires non portables
Hébergement	Cloud français, offre qualifiée SecNumCloud si le niveau de données l'exige	Vérifier le périmètre exact qualifié, pas la marque
CDN / WAF	C'est le point de friction honnête de l'écosystème	Les alternatives européennes existent ; comparer couverture réelle et capacité anti-DDoS
Analytics	Solution sans cookie auto-hébergée	Vérifier l'absence de transfert de l'adresse IP brute vers un tiers
E-mail transactionnel	Prestataire européen	Les sous-traitants de délivrabilité et les journaux d'ouverture sont souvent hors UE
Observabilité	Collecte auto-hébergée, agrégation de journaux en interne	Les traces applicatives contiennent fréquemment des données personnelles
CI/CD, dépôts, identité	Forge et fournisseur d'identité auto-hébergés ou européens	Secrets d'intégration et artefacts de build sont des données sensibles

Deux remarques d'expérience.

La première : le CDN est le sujet le plus difficile, et nous refusons de faire semblant. Les acteurs au maillage mondial et à la capacité d'absorption d'attaques la plus large ne sont pas européens. Pour une audience nationale, une alternative européenne couvre le besoin. Pour un service mondial exposé à des attaques volumétriques, l'arbitrage est réel et doit être documenté, pas maquillé.

La seconde : Next.js n'impose aucune plateforme d'hébergement. Le mode de sortie autonome produit un conteneur qui s'exécute chez n'importe quel hébergeur. L'adhérence vient des fonctionnalités périphériques adoptées sans y penser — optimisation d'images déportée, exécution en périphérie, stockage de fichiers propriétaire, analytics de plateforme. Nous les remplaçons dès la conception. Voir le comparatif Vercel vs Netlify vs OVH vs Cloudflare et notre méthode Stack Souveraine.

#Réversibilité : la seule preuve qui compte

Un dossier de souveraineté sans plan de réversibilité testé est incomplet. C'est aussi le critère le plus regardé en audit, parce que c'est le seul qui ne se satisfait pas d'une déclaration. Ce qu'un plan digne de ce nom contient :

• des formats d'export ouverts et documentés pour chaque type de donnée, métadonnées et binaires compris ;
• une infrastructure décrite en code, reconstructible sans reverse engineering ;
• un test de restauration réel, exécuté au moins une fois par an sur un environnement vierge, avec compte rendu daté ;
• une clause contractuelle fixant délai de mise à disposition, format et durée d'assistance à la sortie ;
• une estimation du coût de sortie, frais de transfert sortant compris — poste sous-estimé sur les gros volumes.

Un plan de réversibilité non testé est une fiction, et l'auditeur le sait. Bonne nouvelle : l'exercice de restauration teste aussi votre plan de continuité. Un seul effort, deux obligations couvertes.

#Numérique responsable : RGESN, écoconception et mesure honnête

Le second pilier de cette offre. Là encore, l'écart entre le discours et la pratique est important, et il se comble par la mesure.

#Les ordres de grandeur qui orientent la conception

L'étude conduite par l'ADEME et l'Arcep sur l'empreinte environnementale du numérique en France situe la part du numérique autour de quelques pour cent de l'empreinte carbone nationale, avec une contribution très majoritairement portée par la fabrication des terminaux utilisateurs, loin devant les datacenters et les réseaux. Conséquence directe et contre-intuitive pour un développeur : votre levier le plus puissant n'est pas de gagner cent millisecondes côté serveur, c'est de ne pas rendre obsolète le terminal de l'utilisateur. Une application qui reste utilisable sur un ordinateur de sept ans ou un téléphone d'entrée de gamme prolonge la durée de vie du parc. Source à consulter sur arcep.fr, et notre article écoconception web : dix leviers.

#Le RGESN

Le référentiel général d'écoconception de services numériques est le cadre français de référence. Sa première version, publiée fin 2022 dans le cadre de la mission interministérielle Numérique écoresponsable, comptait 79 critères ; une version révisée a été publiée par l'Arcep en 2024, avec un nombre de critères et une organisation en familles légèrement différents. Vérifiez toujours la version en vigueur au moment de la consultation — c'est le premier point sur lequel un dossier se fait retoquer. Référentiel officiel sur ecoresponsable.numerique.gouv.fr.

Il couvre la stratégie du service, ses spécifications, son architecture, son interface, son contenu, son hébergement et son cycle de vie. Le livrable attendu est une déclaration d'écoconception publiée sur le service, exposant le taux de conformité et les critères non satisfaits. Nous la produisons avec le détail critère par critère et les preuves associées. Voir notre service de conformité RGESN, l'audit RGAA et RGESN en ligne et le baromètre RGESN des collectivités.

Côté obligations, la loi visant à réduire l'empreinte environnementale du numérique, adoptée en novembre 2021, impose notamment aux communes et intercommunalités dépassant un seuil de population d'élaborer une stratégie numérique responsable, selon des modalités précisées par voie réglementaire. Pour les acheteurs publics, le sujet apparaît désormais dans les critères de jugement des offres, parfois en condition d'admissibilité.

#Mesurer sans se raconter d'histoires

Les scores d'empreinte de page — de type Ecoindex — sont utiles comme indicateurs de progression relative : une note reproductible qui décroît quand le poids, le nombre de requêtes et la complexité du document baissent. Ce n'est pas une comptabilité carbone. Annoncer « 1,2 gramme de CO2 par visite » avec deux décimales, c'est prêter à la méthode une précision qu'elle n'a pas. Nous utilisons ces scores comme boussole, jamais comme certificat. Voir le glossaire Ecoindex et notre calculateur d'empreinte carbone d'un site.

#Les leviers qui produisent vraiment un effet

Par ordre décroissant d'impact constaté :

1. La sobriété fonctionnelle. Supprimer une fonctionnalité peu utilisée ramène son empreinte à zéro, avec sa dette de maintenance et sa surface d'attaque. Aucune optimisation technique n'égale ce gain — c'est aussi la décision la plus difficile à faire accepter.
2. L'élimination des scripts tiers. Chaque outil de mesure, de personnalisation ou de support chargé dans le navigateur coûte du transfert, du temps d'exécution et de la batterie. Point de convergence exact entre souveraineté, performance, RGPD et écoconception : une seule action satisfait les quatre objectifs.
3. Les médias. Formats modernes, dimensions adaptées au conteneur réel, chargement différé hors zone visible, suppression des vidéos en lecture automatique.
4. Le cache et le rendu. Un rendu statique ou une régénération incrémentale évite de recalculer à chaque visite ce qui ne change pas.
5. Les polices et bibliothèques. Polices servies depuis le domaine, graisses limitées, dépendances qui apportent trois fonctions pour deux cents kilo-octets éliminées.

L'accessibilité rejoint cette démarche plus souvent qu'on ne le croit : un document bien structuré, léger et utilisable au clavier coche simultanément des critères RGESN et RGAA. Voir notre audit RGAA et le guide RGAA pour les collectivités.

#Là où souveraineté et sobriété s'opposent vraiment

Les deux démarches convergent souvent : moins de SaaS tiers, c'est moins de transferts, moins de requêtes, moins de dépendances. Mais il existe de vrais arbitrages, et les passer sous silence serait malhonnête.

Redondance contre empreinte. Une architecture multi-région exigée par un plan de continuité double une partie de l'infrastructure. Pas de solution élégante : on documente le choix et on évite la redondance de confort sur les environnements non critiques.

GPU dédiés contre mutualisation. Un cluster GPU sous-utilisé consomme davantage par requête traitée qu'une capacité mutualisée à fort taux d'usage. Si votre charge d'inférence est faible et sporadique, l'on-premise strict est plus coûteux et moins sobre — raison de choisir le régime 1 ou 2 plutôt que le régime 3 quand rien ne l'impose.

Grands modèles contre petits modèles. L'arbitrage le plus rentable de l'IA d'entreprise : router les tâches simples vers un petit modèle réduit simultanément le coût, la latence et la consommation. C'est une décision d'architecture, pas un réglage.

#Marchés publics et secteurs régulés : quand la souveraineté devient bloquante

Quatre contextes où le sujet cesse d'être un choix stratégique pour devenir une condition d'accès au marché.

Secteur public et collectivités. Doctrine d'hébergement des données sensibles de l'État, exigences d'écoconception et d'accessibilité, stratégie numérique responsable au-delà d'un seuil de population. Ces éléments apparaissent en critères de jugement, parfois en conditions d'admissibilité. Voir secteur Collectivités & Service public et IA pour les collectivités.

Santé. L'hébergement de données de santé à caractère personnel relève d'une certification dédiée, distincte de SecNumCloud, et les traitements d'IA sur ces données appellent une analyse d'impact rigoureuse. Voir IA pour l'hôpital et le guide hébergement HDS et IA.

Banque, assurance, finance. DORA, applicable depuis janvier 2025, impose un registre des accords contractuels portant sur les services TIC, une analyse de concentration et des exigences contractuelles précises vis-à-vis des prestataires critiques. La juridiction du fournisseur y devient un élément de dossier, pas une opinion. Voir secteur Banque, Assurance & Finance et audit DORA.

Professions réglementées et données stratégiques. Cabinets d'avocats, propriété intellectuelle, données de recherche, secret des affaires. Voir IA pour les cabinets d'avocats.

S'ajoutent les obligations transverses : NIS2, dont la transposition en droit français a pris du retard et doit être suivie de près ; et le règlement européen sur l'intelligence artificielle, entré en vigueur en 2024, dont les obligations s'échelonnent selon la catégorie de risque du système. Voir audit AI Act, glossaire AI Act et guide NIS2.

#Notre méthode de migration : quatre étapes, et un droit d'arrêt à chaque palier

Étape 1 — Audit de souveraineté et écobilan. Inventaire, matrice d'exposition, analyse des requêtes réelles en production, mesure de l'empreinte des parcours principaux, évaluation RGESN à blanc. Livrables : matrice, note juridique par brique critique, trajectoire priorisée, charge estimée par lot. Durée typique : une semaine intensive avec vos équipes.

Étape 2 — Cible et plan de bascule. Choix d'hébergement selon le niveau de données, cible applicative brique par brique, régime de déploiement IA, plan de réversibilité, coût d'exploitation projeté. Nous chiffrons aussi le coût de ne pas migrer : coût de sortie futur, risque contractuel, points perdus en consultation. Notre calculateur d'économies FinOps cloud sert d'entrée sur le volet coût.

Étape 3 — Bascule par couches. Jamais de bascule globale : couche par couche, avec exécution en parallèle et comparaison des sorties avant coupure, selon un motif de substitution progressive comparable à celui de la modernisation legacy. Ordre habituel : les couches périphériques à faible risque d'abord (analytics, polices, e-mail), qui produisent un gain de conformité immédiat ; puis l'hébergement applicatif ; puis les données ; puis l'IA. Chaque couche a son critère de sortie et son plan de retour arrière.

Étape 4 — Vérification et maintien en condition. Audit final, déclaration d'écoconception publiée, dossier de conformité constitué, test de restauration exécuté. Puis un maintien en condition incluant la veille réglementaire : le droit bouge plus vite que les architectures, et un dossier non entretenu se périme en dix-huit mois.

#Pourquoi Nehos sur ces sujets

Nous opérons la stack que nous vendons. Nos services tournent sur un hébergement français, avec Postgres, Qdrant, Next.js et Mistral. Quand nous décrivons une contrainte d'exploitation, nous l'avons rencontrée.

Nous traitons le droit avec prudence. Un texte en négociation n'est pas un texte applicable, une doctrine administrative n'est pas une obligation légale, et référentiel, circulaire, directive et règlement n'ont pas la même portée. Un dossier bâti sur une approximation juridique se retourne contre son auteur en audit.

Nous refusons le tout-ou-rien. La souveraineté est un curseur qu'on positionne brique par brique selon la sensibilité de la donnée. Trois briques réellement rapatriées et documentées valent mieux qu'un plan directeur exhaustif que personne n'exécutera.

Nous disons quand la stack souveraine n'est pas le bon choix. Quand la qualité de raisonnement d'un modèle est le facteur limitant, quand un service mondial subit des attaques volumétriques, ou quand le budget d'exploitation ne permet pas d'assumer l'auto-hébergement, nous proposons une architecture cloisonnée plutôt qu'une souveraineté de façade.

Nous documentons. Matrice d'exposition, notes juridiques, déclaration d'écoconception, plan de réversibilité testé, dossier de conformité : c'est ce qui reste quand le projet est fini, et c'est ce qu'un auditeur ou un acheteur public demande. Notre approche transverse de l'IA est décrite sur la page Agence IA, nos engagements dans notre charte éthique IA et notre démarche RSE.

#FAQ — Souveraineté numérique et numérique responsable

Faut-il obligatoirement une offre qualifiée SecNumCloud ? Non, sauf lorsque la nature des données ou le donneur d'ordre l'imposent. La qualification vise des données sensibles et des contextes précis. Pour un site institutionnel, un extranet interne ou une application métier sans données sensibles, un hébergement français sérieux, correctement configuré et contractualisé, répond au besoin. Nous préférons une architecture propre chez un hébergeur souverain non qualifié à une architecture bancale sur une offre qualifiée. La liste des offres qualifiées et leur périmètre exact sont publiés par l'ANSSI, et c'est cette source qui fait foi.

Le CLOUD Act s'applique-t-il si mes données sont physiquement en France ? Le critère déclencheur porte sur le rattachement du fournisseur à la juridiction américaine, pas sur l'emplacement du stockage. Une filiale européenne d'un groupe américain doit donc être analysée pour ce qu'elle est. Cela ne signifie pas qu'une injonction est probable dans votre cas : cela signifie que le risque existe, qu'il doit être documenté, et que votre architecture doit rester conforme si le contexte juridique évolue. Voir le glossaire CLOUD Act.

Un LLM souverain est-il aussi performant qu'un modèle américain ? Cela dépend de la tâche. Sur la classification, l'extraction structurée, le résumé et la plupart des usages métier courants en français, l'écart n'est pas le facteur limitant — la qualité de vos données et de votre pipeline compte davantage. Sur le raisonnement long, l'analyse documentaire très complexe et la génération de code avancée, un écart reste perceptible. La bonne démarche : un jeu d'évaluation sur vos propres données, et une décision prise sur des mesures plutôt que sur des classements généralistes.

Le RGESN est-il obligatoire pour une entreprise privée ? Le référentiel s'inscrit d'abord dans un cadre applicable au secteur public, avec des obligations issues de la loi de novembre 2021 pour les collectivités au-delà d'un seuil de population. Une entreprise privée n'y est pas soumise de la même manière, mais elle a deux raisons de s'y conformer : c'est un différenciateur en consultation, et les critères recoupent largement des bonnes pratiques de performance et d'accessibilité.

Combien de temps prend une migration vers une stack souveraine ? Cela dépend du nombre de briques et de la criticité des données, pas d'un forfait. Les couches périphériques — analytics, polices, e-mail transactionnel — se traitent en quelques semaines pour un gain de conformité immédiat. La migration d'un hébergement applicatif se compte en semaines à quelques mois selon l'adhérence aux services managés d'origine ; une migration de données volumineuses avec exigence de continuité, en mois. Nous chiffrons lot par lot après l'audit, et vous pouvez vous arrêter à la fin de chaque lot.

Que faire des dépendances qu'on ne peut pas remplacer ? On les isole : cloisonnement du périmètre de données accessible, chiffrement avec des clés conservées de votre côté, minimisation stricte de ce qui transite, analyse d'impact du transfert documentée, plan de bascule préparé même s'il n'est pas exécuté. Une dépendance assumée et encadrée est infiniment plus défendable en audit qu'une dépendance ignorée.