Microsoft Sovereign Cloud : vérifier le contrôle et la continuité des usages IA
L’annonce Microsoft du 20 octobre 2026 invite à évaluer la souveraineté par charge de travail. Pour une DSI belge ou française, la décision utile consiste à définir les preuves attendues avant de choisir une architecture IA publique, privée ou hybride.
1. Ce que Microsoft annonce, et à quelle échéance
Microsoft annonce la disponibilité générale de la gestion externe des clés avec Azure Managed HSM. Data Guardian et Production Touch Ledger font l’objet d’un déploiement progressif dans l’UE et l’AELE. Le Sovereign Control Panel doit entrer en préversion publique à Ignite. Le passage du mode connecté au mode déconnecté entre lui aussi en préversion publique ; Foundry Local sur Azure Local doit devenir généralement disponible à Ignite. Ces statuts ne constituent pas une disponibilité uniforme pour tous les clients.
2. Ce que cela change pour une entreprise belge ou française
Notre lecture : ces annonces fournissent des critères plus précis pour consulter un fournisseur. Demandez, pour chaque service envisagé, sa disponibilité effective, son périmètre contractuel et la preuve du contrôle annoncé. Une PME devrait commencer par un usage borné, par exemple la recherche dans une documentation interne non critique. Une ETI, une grande entreprise ou une administration devrait distinguer les traitements qui peuvent attendre d’un service dont l’interruption bloque une opération essentielle.
3. Analyse Underside : tester toute la chaîne du RAG et des agents
Nous recommandons de décrire un parcours complet : authentification, récupération documentaire, inférence, appel d’outil, journalisation et sauvegarde. Pour chaque étape, identifiez l’opérateur, les données exposées et la dépendance réseau. Dans un RAG, imposez le filtrage documentaire selon les droits de l’utilisateur. Pour un agent relié à Odoo Entreprise, séparez la consultation des écritures et exigez une validation métier avant une action sensible. Ce sont des exigences d’architecture proposées par Underside, pas des fonctionnalités Odoo annoncées par Microsoft.
4. Une recette de continuité avant la mise en production
Nous proposons de tester une coupure réseau sur un environnement représentatif, avec des données de test. Vérifiez si identité, modèles, index, licences et outils restent utilisables ; consignez ce qui s’arrête et qui décide du redémarrage. Testez aussi le retrait d’un accès opérateur et l’indisponibilité d’une clé, avec une procédure de retour contrôlé. Fixez avec les métiers une durée d’interruption acceptable et une perte de données tolérée, puis mesurez-les. Le fonctionnement local doit être démontré sur le parcours complet.
5. Une décision documentée, révisable et proportionnée
Notre recommandation est de comparer les scénarios sur les mêmes critères : données traitées, accès administratifs, preuves exportables, coûts d’exploitation et restauration. Demandez une démonstration des fonctions réellement disponibles plutôt qu’une feuille de route seule. Faites valider les obligations applicables par les responsables juridiques et sécurité ; l’annonce fournisseur ne suffit pas à conclure à une conformité réglementaire. Prévoyez enfin un test d’export des données, configurations et traces pour préparer un changement de prestataire.
Recommandation opérationnelle : constituez une fiche de recette par usage IA, avec un responsable métier, le statut de chaque fonction, les dépendances, les preuves d’accès et un test de continuité daté. Conditionnez l’ouverture des écritures ERP à cette validation.
Évaluer une architecture IA souveraine