Red Hat et Rafay: architecture d'un cloud IA souverain en service
Red Hat publie avec Rafay une architecture de référence pour transformer une infrastructure GPU distribuée en service IA souverain, gouverné et multi-tenant. Pour les entreprises belges et françaises, l'intérêt tient moins au catalogue technologique qu'à la chaîne opérationnelle complète, de la commande à la mesure d'usage.
1. Ce que décrit l'architecture
Le blueprint vise les opérateurs télécoms, clouds souverains et neoclouds. Il combine la plateforme cloud et IA multi-tenant de Red Hat avec les fonctions Rafay de libre-service commercial. Red Hat précise qu'il s'agit d'une architecture validée: elle nomme les composants, répartit les responsabilités par couche et suit une demande locataire depuis la sélection d'une offre jusqu'à un environnement GPU mesuré.
Le point structurant est la séparation entre plan commercial, plan de contrôle et ressources d'exécution. Catalogue, quotas, identité, isolation, politiques, observabilité et consommation deviennent des éléments explicites du service, au même titre que Kubernetes, les modèles ou les accélérateurs.
2. Ce que cela change pour une entreprise belge ou française
Une PME ou une ETI peut accéder à une capacité GPU gouvernée sans construire toute la plateforme, mais doit vérifier le lieu d'exploitation, l'opérateur effectif, les accès privilégiés, la réversibilité et la portabilité des modèles et données. Une grande entreprise ou une administration peut demander des environnements séparés par entité, projet ou niveau de sensibilité, avec quotas et preuves d'usage.
La conséquence pour les DSI et achats est concrète: un appel d'offres ne devrait plus demander seulement où résident les données. Il doit couvrir l'identité des opérateurs, la chaîne d'administration, les clés, les journaux, la mesure de consommation, les dépendances logicielles, les mises à jour et la procédure de sortie.
3. Analyse Underside: la souveraineté devient un modèle d'exploitation
L'analyse Underside est qu'un cloud IA souverain crédible se juge sur des contrôles exécutables. Pour un agent ou un RAG, l'isolation du calcul doit être reliée aux droits sur les corpus, aux secrets, aux outils MCP, aux sorties réseau et aux journaux de décision. La localisation seule ne protège ni d'un compte administrateur trop puissant ni d'un connecteur métier mal limité.
Dans Odoo Entreprise, cette architecture peut soutenir des environnements distincts pour développement, évaluation et production, tandis que les agents n'obtiennent que les droits nécessaires sur le CRM, les achats ou la comptabilité. Un choix local, cloud européen ou hybride reste à faire workload par workload selon sensibilité, latence, coût et continuité.
4. Questions à imposer avant contractualisation
Les entreprises devraient demander une matrice de responsabilité couvrant matériel, cluster, modèles, données et applications; des preuves d'isolation entre locataires; des métriques de capacité et de coût; un export documenté des modèles, configurations et logs; ainsi que des tests de restauration et de révocation. La facturation GPU doit aussi être rapprochable d'un projet, d'un métier et d'un résultat.
Recommandation opérationnelle: tester le service avec un workload RAG ou agentique borné, puis vérifier isolation, droits, journaux, coût mesuré, reprise et export avant d'élargir aux données ou processus critiques.
Évaluer une architecture IA souveraine