Souveraineté IA et Cloud de confiance. Ce que les DSI doivent arbitrer.

Cloud de confiance et SecNumCloud. Ce que recouvrent vraiment les qualifications.

Lorsque la question arrive au comité de direction d'une DSI française, le vocabulaire est souvent mélangé. Cloud souverain, Cloud de confiance, SecNumCloud, hébergement européen, isolation contractuelle. Dans les conversations que nous avons avec des directions techniques, c'est rarement par défaut de rigueur. C'est parce que le paysage a évolué très vite et que les frontières entre catégories se déplacent encore.

SecNumCloud est une qualification délivrée par l'ANSSI. Elle impose des exigences techniques, organisationnelles et juridiques précises, dont l'objectif est de protéger les environnements contre les législations extra-territoriales et contre certaines catégories d'attaque sophistiquée. Tous les fournisseurs qualifiés SecNumCloud sont des Cloud de confiance, au sens où ils ont passé l'évaluation. L'inverse n'est pas vrai. Un Cloud de confiance peut désigner une offre conçue pour répondre à ces enjeux sans avoir encore obtenu la qualification, ou une offre construite sur un référentiel proche mais distinct.

Cette distinction n'est pas cosmétique. Elle change la nature des engagements opposables. Pour des données régulées, pour certains marchés publics ou pour des opérateurs d'importance vitale, seule la qualification ANSSI tient devant le contrôle. Pour d'autres cas d'usage, une offre de confiance non qualifiée peut suffire, à condition que la gouvernance assume explicitement le périmètre couvert et le périmètre exclu.

Le travail utile, au début d'un arbitrage, n'est pas de comparer les offres entre elles. C'est de clarifier quelle catégorie de qualification est exigée par le métier, par le régulateur et par les clients institutionnels du périmètre. Sans ce cadrage, les comparaisons portent sur des paniers qui ne se valent pas.

Souveraineté IA. Données, modèles et infrastructures.

La souveraineté IA est un terme qui mérite d'être décomposé. Trois couches se chevauchent et n'obéissent pas aux mêmes contraintes.

Les données.

La couche la plus visible et souvent la plus simple à instruire. Les données utilisées pour entraîner, affiner et alimenter l'inférence d'un modèle ont une localisation, une catégorie de sensibilité et un cadre juridique applicable. La question à poser est binaire dans la forme et plus subtile dans la pratique. Quelles données peuvent quitter le périmètre national ou européen, dans quelles conditions, sous quelle clé de chiffrement et avec quelle traçabilité des accès. Une DSI sérieuse a une classification de données opérationnelle avant d'engager une discussion sur l'IA souveraine. Sans cette classification, le débat reste théorique.

Les modèles.

Cette couche est plus mouvante. Le marché propose à la fois des modèles européens entraînés sur des infrastructures localisées, des modèles ouverts qui peuvent être hébergés dans un Cloud de confiance, et des modèles propriétaires d'acteurs non européens dont la disponibilité en environnement qualifié progresse. Le critère de souveraineté ne se limite pas à l'origine du modèle. Il englobe la maîtrise de son cycle de vie, la transparence sur les versions et la capacité à reproduire ou rejouer une inférence pour des besoins d'audit.

Les infrastructures de calcul.

La couche la moins discutée et souvent la plus stratégique. L'entraînement à grande échelle et l'inférence sur des modèles volumineux supposent un accès à des capacités spécialisées que peu d'acteurs européens opèrent à l'échelle requise. Pour beaucoup d'organisations, le constat honnête est qu'une autonomie complète sur cette couche n'est pas accessible à court terme. Le bon arbitrage consiste alors à reconnaître la dépendance, à la cartographier précisément et à organiser des bascules possibles, plutôt qu'à la nier.

Une réponse cohérente à la question "êtes-vous souverain sur votre IA" doit donc nommer les trois couches séparément. Une posture qui répond globalement par l'affirmative sans distinguer les niveaux est, dans notre expérience, soit une vue partielle, soit une formulation marketing qui ne survit pas à un examen technique sérieux.

Les arbitrages concrets à poser.

Lorsque nous accompagnons une DSI sur ce sujet, nous essayons de ramener la conversation à trois arbitrages opérationnels, qui peuvent être instruits avec un comité dans des délais raisonnables.

L'arbitrage d'hébergement.

Pour chaque grande famille de cas d'usage, quelle est la cible d'hébergement raisonnable. Cloud public ouvert, cloud hyperscaler avec garanties européennes, Cloud de confiance non qualifié, environnement qualifié SecNumCloud, ou environnement on-premises. La logique n'est pas de tout pousser vers la qualification la plus exigeante, mais d'affecter chaque cas d'usage à l'environnement minimal qui couvre son risque réel. Une charge homogène sur un seul environnement est rarement le bon optimum économique.

L'arbitrage de modèle.

Pour chaque cas d'usage, quelle est la fenêtre acceptable entre performance de modèle et contraintes de souveraineté. Sur certains usages, un modèle européen ouvert hébergé dans un environnement qualifié suffit largement. Sur d'autres, l'écart de performance entre le meilleur modèle disponible en environnement qualifié et le meilleur modèle disponible globalement reste significatif. La direction métier doit comprendre cet arbitrage explicitement, et le valider en connaissance de cause, pas par défaut.

L'arbitrage d'orchestrateur.

La couche qui orchestre les flux entre données, modèles et applicatifs est rarement discutée au même niveau que les deux précédentes. Elle est pourtant le point de bascule où la souveraineté peut être perdue silencieusement, parce qu'une étape de routage ou de stockage temporaire passe par une infrastructure non maîtrisée. Une cartographie de bout en bout des flux d'inférence est l'un des livrables que nous recommandons systématiquement avant tout arbitrage définitif.

Les compromis acceptables.

La conversation que nous avons le plus souvent au comité, après que ces arbitrages sont posés, porte sur les compromis. Faut-il accepter de rester sur un cloud hyperscaler ouvert pour bénéficier d'un catalogue de modèles plus riche, ou faut-il basculer vers un environnement qualifié au prix d'un écart de capacité.

Notre lecture, à ce stade, est qu'il n'existe pas de réponse universelle, mais une grille assez stable. Lorsque les données traitées sont à enjeu réglementaire fort ou exposées à un risque extra-territorial significatif, la bascule vers un environnement qualifié devient difficile à éviter, même au prix d'un écart de performance sur les modèles disponibles. Lorsque les données sont sensibles mais non régulées au sens strict, et que l'écart de capacité change matériellement la valeur métier, un cloud hyperscaler avec garanties contractuelles européennes et chiffrement maîtrisé peut rester un compromis défendable, à condition que la gouvernance en assume explicitement les limites.

Le piège que nous voyons régulièrement consiste à choisir un environnement qualifié pour des raisons d'affichage, sans avoir clarifié ce que cela coûte en capacité réelle pour les cas d'usage prioritaires. La souveraineté qui freine l'usage finit par être contournée, parfois par les métiers eux-mêmes, et le risque revient par la fenêtre, sans contrôle. Le compromis explicite, instrumenté et documenté, vaut presque toujours mieux que la posture maximaliste appliquée à contre-emploi.

La souveraineté qui n'est pas instrumentée jusqu'au bout du flux d'inférence n'est pas une souveraineté. C'est une intention.

Souveraineté comme stratégie, pas comme slogan.

La conclusion à laquelle nous arrivons, après plusieurs cycles d'arbitrage avec des DSI françaises et leurs comités, tient en une idée. La souveraineté IA mérite d'être traitée comme un sujet stratégique, avec la rigueur que l'on appliquerait à une question d'architecture financière, et non comme un slogan qui se règle dans un communiqué.

Concrètement, cela suppose une classification de données opérationnelle, une cartographie de bout en bout des flux d'inférence pour chaque famille de cas d'usage, et une grille de bascule qui décrit explicitement les conditions dans lesquelles l'organisation passerait d'un environnement à un autre. Avec ces trois éléments, la conversation au comité change de nature. Elle cesse d'être théologique et devient instructible.

Si vous êtes en train de poser ces arbitrages pour votre périmètre, les équipes Consulting de B One basées à Paris suivent ces sujets de près et travaillent régulièrement avec des partenaires technologiques sur les briques d'orchestration et de qualification. Le formulaire de brief plus bas permet d'engager la conversation, et nous répondons dans la journée ouvrée qui suit.