Déploiement souverain et confidentiel : VPC, on-premises, air-gapped et TEE
Demandez à la plupart des équipes où tourne leur IA et vous obtenez une seule réponse : le cloud, ou l'on-premises, ou, si elles sont prudentes, l'air-gapped. Une topologie, choisie une fois, appliquée à tout. C'est une décision nette, et pour une activité non réglementée elle convient d'habitude.
Sauf que dans une entreprise réglementée, une topologie de déploiement unique est soit gaspilleuse, soit dangereuse, et souvent les deux à la fois. La topologie de déploiement n'est pas un choix unique pour tout le système. C'est une règle de routage pilotée par la sensibilité des données, et elle doit échouer en fermé. Choisissez une topologie pour tout et vous sur-contraignez du travail bon marché et non sensible en l'enfermant dans un air-gap dont il n'avait pas besoin, ou, bien pire, vous laissez des données réglementées aller là où elles n'auraient jamais dû aller parce que cet endroit était commode pour autre chose. Le bon modèle est un spectre de topologies, et une règle qui route chaque charge vers l'environnement le moins exposé que sa classe de données permet.
Il y a aussi un point plus récent sur ce spectre que la plupart des architectures de référence sautent, et c'est celui qui résout le cas le plus dur : comment traiter des données réglementées sur une infrastructure que vous ne contrôlez pas physiquement sans les exposer, grâce à l'informatique confidentielle et aux environnements d'exécution de confiance. C'est là que ça devient réellement intéressant.
Le spectre des topologies, routé par sensibilité
Voyez le déploiement comme une échelle d'exposition décroissante, et la sensibilité des données comme ce qui décide jusqu'où il faut grimper pour chaque charge.
Au bout tolérant à l'exposition se trouve un compte cloud que vous apportez vous-même, qui donne de l'élasticité et la charge d'exploitation la plus faible, au prix de données qui quittent votre compte vers la région du modèle si vous l'autorisez. Au-dessus, un VPC épinglé à une région garde les données dans votre propre périmètre cloud et votre zone de résidence requise, en échange de quoi vous exploitez la frontière et le routage. Plus haut encore, le déploiement on-premises donne un contrôle physique total quand les règles interdisent tout traitement externe, et vous remet en échange la planification de capacité et l'exploitation GPU. Au sommet, un environnement air-gapped supprime entièrement le chemin de sortie pour le travail le plus sensible, et vous payez cette isolation par des mises à jour de modèle et une exploitation manuelles et délibérées.
L'erreur est de lire cette échelle comme un menu et de choisir un barreau pour toute l'organisation. Ce n'est pas un menu. C'est une table de routage. Vous classez les données que porte une charge donnée, et la classification vous dit le barreau le plus bas sur lequel cette charge a le droit de tourner. Un même processus métier traverse couramment les classes : une étape lit un dossier réglementé et appartient en haut de l'échelle, une autre rédige une notification générique et peut rester en bas. Le routage se fait donc par étape, pas une fois pour le système, et le même processus peut toucher deux topologies dans une même exécution.
L'informatique confidentielle : traiter des données réglementées que vous ne pouvez pas isoler entièrement
Voici le cas que l'échelle classique gère mal. Parfois il vous faut l'élasticité ou le matériel spécialisé d'une infrastructure que vous ne possédez pas physiquement, mais les données sont trop sensibles pour être exposées à celui qui exploite cette infrastructure. L'air-gap dit non. Le VPC dit « faites confiance aux opérateurs de votre fournisseur cloud ». Aucun des deux ne satisfait quand le modèle de menace inclut la plateforme elle-même.
C'est ce que traite l'informatique confidentielle, et le mécanisme est un environnement d'exécution de confiance, un TEE. Un TEE est une enclave appliquée par le matériel dans laquelle les données sont déchiffrées et traitées tout en restant chiffrées partout ailleurs : en mémoire, l'enclave les garde dans une région que le système d'exploitation hôte, l'hyperviseur et l'opérateur cloud ne peuvent physiquement pas lire. Les données sont protégées non seulement au repos et en transit, les deux états que tout le monde sécurise déjà, mais en cours d'usage, l'état qui a historiquement été la brèche. La charge tourne, la donnée réglementée est traitée, et l'opérateur de la machine sur laquelle elle a tourné n'a jamais eu la capacité de la voir.
Deux propriétés en font un contrôle plutôt qu'une affirmation. L'enclave est appliquée par le matériel du processeur, pas par une configuration logicielle qu'un opérateur privilégié pourrait désactiver. Et l'attestation à distance vous permet de vérifier cryptographiquement, avant d'envoyer la moindre donnée, que le code qui tourne dans l'enclave est exactement celui que vous attendez et qu'il tourne bien dans un vrai TEE. Vous ne faites pas confiance à l'assurance de l'opérateur que vos données sont protégées. Vous vérifiez l'enclave, puis vous lui libérez les données, et la vérification est une signature que vous pouvez garder comme preuve.
Pour une organisation réglementée, cela recadre une décision autrefois binaire. L'ancienne question était « posséder le matériel, ou exposer les données ». L'informatique confidentielle ajoute une troisième réponse pour une tranche précise et précieuse de charges : tourner sur du matériel que vous ne possédez pas, sur des données que vous ne pourriez pas exposer autrement, parce que l'environnement est attesté et l'opérateur cryptographiquement exclu. Cela ne remplace pas l'on-premises ni l'air-gap pour les cas les plus extrêmes. Cela étend la portée de la souveraineté à des endroits où elle ne pouvait pas aller.
Un routage de souveraineté qui échoue en fermé
Un spectre de topologies ne vaut que la règle qui y affecte les charges, et la propriété qui rend cette règle défendable est précise : elle échoue en fermé.
La politique de routage classe les données par sensibilité et épingle chaque classe aux topologies sur lesquelles elle a le droit de tourner. Les données réglementées et personnelles restent par défaut dans votre périmètre, que ce périmètre soit un VPC épinglé à une région, de l'on-premises, un air-gap ou une enclave attestée. Seules les charges explicitement non sensibles peuvent atteindre un modèle en région externe, et seulement quand une politique a autorisé cette classe à sortir. La partie décisive est ce qui se passe en cas d'incertitude : quand une classification est ambiguë, le système traite la donnée comme sensible et la garde dans l'environnement le plus protégé que ses classes possibles permettent. Le défaut vous protège. L'assouplir demande une décision délibérée et journalisée, pas une omission.
C'est la différence entre « vos données ne quittent jamais vos murs » comme phrase marketing et comme architecture. Comme architecture, la sortie est refusée par défaut et permise seulement par politique explicite, par classe de données, par étape, chaque assouplissement étant enregistré. Une erreur de configuration n'ouvre pas silencieusement une porte, parce que la porte est fermée sauf si quelque chose l'a délibérément ouverte. L'échec fermé est toute la raison pour laquelle un superviseur peut croire l'affirmation de souveraineté, parce que cela veut dire que le mode d'échec du système est la surprotection, pas la fuite.
DORA et la résidence sont les moteurs, pas la paperasse
Rien de tout cela n'est de l'ingénierie pour elle-même. C'est la forme que l'obligation réglementaire impose, et deux obligations en particulier la poussent.
La résidence des données est la plus brutale. Des règles qui exigent que certaines données restent dans une juridiction transforment « où tourne le modèle ? » en une question juridique à réponse physique. Un VPC épinglé à une région, un cluster on-premises ou une enclave attestée dans la bonne juridiction ne sont pas une préférence ; c'est ainsi que vous satisfaites une règle qu'une région par défaut commode violerait. Les régimes de résilience opérationnelle comme DORA poussent en parallèle : ils se soucient du risque de concentration et de votre capacité à garder un processus critique en marche et inspectable, ce qu'une posture routée, agnostique et déployable partout fournit exactement, et qu'une topologie unique câblée en dur ne fournit pas. Quand votre déploiement est une règle de routage qui vous appartient plutôt que le défaut d'un fournisseur, vous pouvez démontrer à un superviseur à la fois où restent les données réglementées et comment le processus survit à un fournisseur ou à une région devenus inutilisables.
La question à apporter à votre prochaine revue d'architecture n'est donc pas « cloud ou on-premises ? ». C'est : pour chaque classe de données de ce processus, quel est l'environnement le moins exposé dans lequel elle a le droit de tourner, le routage l'y envoie-t-il par défaut, et le système échoue-t-il en fermé quand il n'est pas sûr ? Si vous pouvez répondre par classe de données, et si l'informatique confidentielle a étendu votre portée aux charges qui imposaient autrefois un choix impossible, vous avez une architecture de souveraineté. Si votre réponse est une topologie pour tout, vous avez l'espoir que rien de sensible ne prenne jamais le chemin commode.
Si vous voulez cartographier vos classes de données sur les topologies permises, et trouver où une enclave attestée change la réponse, prenez rendez-vous et apportez-nous le processus contenant les données les plus sensibles sur le plan juridictionnel.