La question arrive régulièrement dans nos missions : "On veut héberger notre LLM de façon souveraine, on part sur du SecNumCloud ou on installe des GPUs chez nous ?" La formulation présuppose deux options. En réalité, il y en a trois, avec des profils de risque, des contraintes réglementaires et des économies très différentes selon le contexte de chaque organisation.
Le marché du cloud de confiance en France s'est structuré à grande vitesse en 2025 et 2026. S3NS (Thales-Google) a obtenu la qualification SecNumCloud en décembre 2025, devenant le premier prestataire à couvrir simultanément IaaS, PaaS et CaaS. Bleu (Orange-Capgemini), qui distribue Azure dans un environnement souverain, a franchi la première étape de la procédure de qualification en avril 2025 et vise l'achèvement au premier semestre 2026. OVHcloud et Scaleway sont qualifiés sur certains périmètres. Au total, neuf prestataires sont qualifiés SecNumCloud en 2026, douze candidatures supplémentaires sont en cours d'examen. Le marché existe, il se consolide, et les promesses commerciales se multiplient autour de lui.
Ce qui ne suit pas le même rythme, c'est la clarté sur ce que ces qualifications couvrent réellement. Un cloud "souverain" peut désigner des choses très différentes : données hébergées physiquement en France sans protection légale particulière, engagement contractuel de localisation, certification technique sectorielle, ou qualification SecNumCloud avec immunité contre les lois extraterritoriales. Pour un dirigeant qui doit décider où héberger ses LLMs en 2026, ces distinctions ne sont pas cosmétiques. Elles déterminent ce que l'organisation peut traiter, ce qu'elle risque juridiquement, et ce que l'infrastructure coûte sur trois ans.
Ce que la qualification SecNumCloud garantit vraiment
Le référentiel SecNumCloud 3.2 de l'ANSSI est le niveau d'exigence le plus élevé disponible en France pour les prestataires cloud. Il impose plus de 360 critères de conformité répartis en 19 chapitres, couvrant les dimensions techniques, opérationnelles, juridiques et organisationnelles de la sécurité. L'exigence centrale qui le distingue de tous les autres labels : le prestataire doit avoir son siège social et son capital en Union européenne, et son infrastructure doit être immunisée contre les lois extraterritoriales étrangères, CLOUD Act américain et section 702 du FISA en tête.
C'est précisément ce point qui rend SecNumCloud pertinent pour héberger des LLMs traitant des données sensibles. La Cour de justice de l'UE a formalisé en 2020 l'incompatibilité entre le CLOUD Act et le RGPD pour les transferts vers des entités soumises à la surveillance américaine, même lorsque les serveurs sont physiquement situés en Europe. Un prestataire qualifié SecNumCloud offre une protection légale que les engagements contractuels des hyperscalers américains ne peuvent tout simplement pas fournir, quelles que soient la qualité de leur DPA ou leurs certifications techniques.
Le périmètre de la qualification : la question essentielle
La qualification SecNumCloud porte sur un service précis, pas sur un prestataire en général. Un hébergeur peut être qualifié SecNumCloud pour son infrastructure IaaS tout en proposant des services GPU ou des APIs d'inférence IA qui ne sont pas encore dans le périmètre qualifié. OVHcloud, par exemple, annonçait en début 2026 l'intégration de ses services IA dans sa pile SecNumCloud pour fin 2026 : ses services AI Endpoints n'étaient donc pas couverts par la qualification à date. La question à poser à tout prestataire, sans exception : "Le service spécifique que j'utilise est-il dans le périmètre de la qualification, ou seulement l'infrastructure sous-jacente ?" Cette nuance change tout à l'analyse.
Cloud public hyperscaler : maturité réelle et limites nettes
AWS, Azure et Google Cloud offrent le catalogue de modèles le plus large disponible, une intégration native avec tous les outils de développement, des SLA robustes, une scalabilité quasi instantanée et des prix en baisse continue. AWS a réduit ses tarifs GPU H100 de 44% en juin 2025, les faisant passer d'environ 7,57 à 3,90 dollars par GPU-heure sur ses instances P5. Pour des usages IA sans contrainte de souveraineté, c'est une proposition difficile à concurrencer en valeur pure.
La limite est strictement juridique. Microsoft, Google et Amazon sont des entités de droit américain, soumises au CLOUD Act. Un contrat de localisation des données en France ou en UE ne protège pas contre une injonction légale américaine si les autorités des États-Unis décident de l'émettre. Ce risque est réel et documenté : pour les organisations qui traitent des données de santé nominatives, des secrets industriels, des plans stratégiques, ou des données contractuelles avec des tiers non consentants, il n'est pas acceptable.
Le cloud hyperscaler reste le bon choix pour : les POCs et projets d'exploration, les modèles de base accessibles via API sur des données génériques, les usages de classification ou de génération sur des contenus non-sensibles, et les équipes qui ont besoin de vitesse d'itération et de flexibilité d'échelle sans contrainte réglementaire formelle.
La souveraineté de façade : les signaux d'alerte
Le marché est saturé de solutions qui se présentent comme "souveraines" sans que ce terme repose sur une garantie juridique ou technique précise. Trois formulations méritent un examen critique systématique.
"Datacenter en France" : l'hébergement physique des données en France ne crée aucune immunité légale si l'entité qui opère l'infrastructure est une filiale d'une société de droit américain. Le serveur peut être à Strasbourg, si la maison mère est à Seattle, le CLOUD Act s'applique.
"RGPD-compliant" : toute entreprise opérant dans l'UE doit respecter le RGPD. Ce label n'implique ni qualification SecNumCloud, ni protection contre les lois extraterritoriales, ni gouvernance souveraine. C'est un plancher légal minimum, pas un niveau de protection avancé.
"Cloud souverain" sans qualification ANSSI : le terme n'est pas protégé réglementairement. Il peut désigner un engagement contractuel sans portée juridique réelle, une certification sectorielle (HDS, ISO 27001), ou une qualification SecNumCloud complète. Ces niveaux ne sont pas interchangeables. La réponse aux questions "qualifié par qui ?" et "pour quel périmètre précis ?" doit être vérifiable, pas seulement affirmée dans un deck commercial.
En pratique, la souveraineté réelle s'évalue sur deux axes indissociables : l'immunité contre les lois extraterritoriales (SecNumCloud en France, exigences équivalentes dans d'autres États membres de l'UE) et la localisation de la décision opérationnelle (qui peut accéder aux données, qui répond aux injonctions légales, qui décide des configurations). Les deux doivent être verts pour qu'une solution soit réellement souveraine.
On-premise GPU : le bon calcul économique
L'on-premise, c'est-à-dire l'achat et l'opération de GPU propres, est souvent présenté comme la solution ultime de contrôle et de souveraineté. C'est vrai dans certains contextes précis. C'est une erreur de calcul dans beaucoup d'autres.
Le coût réel sur trois ans
Un serveur équipé de 8 GPU NVIDIA H100 coûte entre 250 000 et 350 000 euros à l'achat en 2025-2026, avec des délais d'approvisionnement de 5 à 6 mois en moyenne. À ce coût matériel s'ajoutent l'alimentation électrique (40 à 100 kW par rack, incompatible avec la plupart des datacenters d'entreprise existants sans rénovation lourde et coûteuse), le refroidissement liquide, la maintenance préventive et corrective, et surtout le coût humain. L'analyse TCO publiée par Lenovo en 2025 le quantifie avec précision : un ingénieur infrastructure à 0,5 ETP représente 75 000 à 100 000 euros par an, soit 225 000 à 300 000 euros sur trois ans. Ce montant dépasse souvent le coût matériel dans les organisations qui n'avaient pas d'équipe infrastructure dédiée au préalable.
La règle de rentabilité est claire. Une analyse de marché publiée début 2026 situe le break-even d'une configuration 8 GPU H100 à environ 8 500 à 9 000 heures d'utilisation effective, soit 11 à 12 mois si la machine tourne en continu. En deçà de 70% d'utilisation soutenue, le cloud public reste moins cher sur trois ans. Au-dessus de 80% d'utilisation sur des charges stables et prévisibles, l'on-premise devient l'option la plus économique à horizon trois ans.
Les trois situations où l'on-premise s'impose
Première situation : la classification le requiert. Les données Diffusion Restreinte, les systèmes d'importance vitale (OIV), les environnements de défense avec isolation réseau totale (air-gapped) ne peuvent pas transiter par un cloud externe, même SecNumCloud. La contrainte est réglementaire et non négociable.
Deuxième situation : le volume d'inférence est élevé et prévisible. Un modèle qui tourne 18 à 20 heures par jour, 7 jours sur 7, sur un cas d'usage de production stabilisé atteint le seuil de rentabilité en moins d'un an. La prévisibilité du volume compte autant que son niveau absolu.
Troisième situation : l'infrastructure et la compétence existent déjà. Un grand groupe industriel qui dispose de son propre datacenter et d'une équipe infrastructure rodée a un TCO réel très différent d'une ETI qui construirait tout de zéro. L'on-premise qui s'intègre dans un socle existant est économiquement très différent de l'on-premise from scratch.
Ce que l'on-premise ne résout pas
L'on-premise déplace la responsabilité de sécurité, il ne la réduit pas. Un cluster GPU mal configuré, sans monitoring, avec des accès physiques non contrôlés ou des mises à jour de firmware en retard est objectivement moins sûr qu'un cloud SecNumCloud audité sur 360 critères. La souveraineté physique ne se substitue pas à la maturité opérationnelle de sécurité. C'est une confusion fréquente, et elle a des conséquences réelles.
La matrice de décision : quatre questions dans l'ordre
Plutôt qu'une grille de critères abstraits, voici les quatre questions que l'on pose systématiquement en mission pour orienter le choix d'architecture d'hébergement.
Question 1 : quelle est la contrainte réglementaire des données ?
Les données traitées entrent-elles dans une catégorie réglementée : données de santé (HDS obligatoire), données d'État ou de défense (SecNumCloud ou on-premise air-gapped), OIV, ou données de classification administrative ? Si oui, le cadre s'impose et délimite les options viables. L'analyse économique vient après, pas avant.
Question 2 : y a-t-il un risque extraterritorial inacceptable ?
Les données contiennent-elles des secrets industriels, des plans stratégiques, des informations concurrentielles sensibles, ou des données contractuelles que vous ne pouvez pas risquer d'exposer à une injonction légale étrangère ? Si oui, le cloud public hyperscaler est exclu. SecNumCloud ou on-premise sont les deux options viables.
Question 3 : le volume d'inférence est-il élevé et prévisible ?
Si l'utilisation prévue est inférieure à 70% du temps machine sur la durée, le cloud reste moins cher à trois ans. Si elle dépasse 80% sur une charge stable, l'on-premise devient pertinent si la compétence est disponible. Entre les deux, le cloud SecNumCloud représente souvent le meilleur équilibre entre protection et flexibilité.
Question 4 : l'organisation a-t-elle la compétence pour gérer de l'infrastructure GPU ?
L'on-premise sans compétence infrastructure solide génère un cycle prévisible : installation difficile, problèmes de configuration chroniques, GPU sous-utilisés, abandon progressif. Si la compétence n'est pas là et que le budget de recrutement ne suit pas, le cloud est le seul choix réaliste, quelle que soit la préférence théorique pour la souveraineté.
| Cloud public | Cloud SecNumCloud | On-premise | |
|---|---|---|---|
| Contrainte réglementaire forte | Non | Oui | Oui (air-gapped) |
| Protection extraterritoriale | Non | Oui | Oui |
| Volume faible ou erratique | Oui | Oui | Non |
| Volume élevé et stable | Oui | Oui | Oui (si compétence) |
| Compétence infra requise | Non | Non | Oui |
| Coût initial | Faible | Moyen | Élevé |
| Richesse du catalogue modèles | Élevée | Moyenne | Variable |
Ce qu'on met en place en mission
Quand un client nous sollicite pour choisir son architecture d'hébergement LLM, on commence toujours par cartographier les données réelles qui vont transiter dans le système, pas les catégories génériques. Dans la grande majorité des cas, deux flux coexistent : un flux de données sensibles qui exige une protection renforcée (rarement plus de 20 à 30% du volume total), et un flux courant sans contrainte réglementaire forte. Ce constat oriente presque toujours vers une architecture hybride.
Ce que les organisations sous-estiment systématiquement : le coût de la cohérence d'un système hybride. Deux environnements distincts impliquent des passerelles de données, des politiques de classification appliquées en amont, et des équipes capables d'opérer les deux registres. C'est faisable et souvent la bonne réponse. Mais ça doit entrer dans le calcul dès le départ, pas apparaître comme une surprise à l'intégration.
Ce qu'elles surestiment : la protection qu'apporte le simple fait de choisir un prestataire "français" ou "européen". La nationalité du prestataire ne suffit pas. Ce qui compte, c'est que le service IA spécifiquement utilisé soit dans le périmètre de la qualification, pas seulement que le prestataire soit qualifié en général pour d'autres services. Vérifier ce point avant de signer, en demandant le périmètre exact de la qualification en vigueur, est l'une des vérifications les plus importantes et les plus souvent omises dans les processus d'achat.
Vous voulez qu'on regarde votre cas ensemble ? Réservez un créneau, on bloque 30 minutes pour cartographier vos données, qualifier vos contraintes réglementaires et identifier l'architecture d'hébergement la plus adaptée à votre contexte.