Microsoft Foundry et Google Cloud AI proposent tous deux un accès à plusieurs familles de modèles, mais leurs architectures répondent à des priorités différentes. Microsoft Foundry met l’accent sur l’intégration Azure, la gouvernance et le choix du chemin réseau. Google Cloud AI, notamment via Vertex AI, structure davantage l’accès autour d’endpoints globaux, multirégionaux et régionaux.
Le choix dépend donc moins du nombre de modèles que de la manière dont une entreprise veut gérer l’identité, la résidence des données, le routage et la connectivité. Microsoft Foundry documente quatre méthodes pour atteindre un modèle situé dans une autre région Azure. Vertex AI distingue de son côté trois types d’endpoints, avec un compromis explicite entre disponibilité, résidence géographique et prix.
Microsoft Foundry privilégie le contrôle du chemin d’accès
Microsoft Foundry permet de choisir l’architecture d’accès selon la propriété de la ressource, la gestion de l’identité et la connectivité réseau. Cette granularité est particulièrement utile lorsque le projet ne peut pas consommer un modèle depuis la même région que son application.
Quatre méthodes permettent d’accéder à des modèles Foundry situés dans d’autres régions Azure. Elles diffèrent par le composant qui porte l’identité, le mécanisme de routage et le chemin réseau utilisé pour atteindre le modèle.
Les options couvrent notamment des scénarios dans lesquels l’application consomme directement le point de terminaison du modèle, ainsi que des architectures s’appuyant sur des services intermédiaires. Le choix dépend de la manière dont l’entreprise veut séparer le projet Foundry, le modèle déployé et le réseau d’entreprise.
À retenir : Microsoft Foundry ne réduit pas l’accès interrégional à une simple adresse d’API. Il propose quatre schémas qui permettent d’adapter l’identité, le routage et le réseau aux contraintes de gouvernance.
Quatre accès, quatre compromis opérationnels
Les quatre méthodes se distinguent principalement sur trois axes :
- la ressource qui authentifie l’appel ;
- le composant qui sélectionne ou relaie le modèle ;
- le chemin réseau entre l’application et la région hébergeant le modèle.
Cette approche intéresse les organisations qui disposent déjà d’une architecture Azure segmentée. Elle permet de conserver le projet applicatif dans une région donnée tout en consommant un modèle disponible ailleurs, à condition de respecter les contraintes de déploiement et de réseau du service concerné.
Les équipes doivent aussi vérifier la compatibilité des fonctionnalités utilisées avec le mode d’accès choisi. Une configuration passant par Azure API Management peut bloquer les outils de première partie lorsque le mode on-behalf-of est utilisé. Cette limite concerne les scénarios dans lesquels le service doit agir au nom de l’utilisateur tout en appelant des fonctions intégrées à Foundry.
Un flux de décision orienté gouvernance
Le flux de décision proposé pour Foundry commence par la propriété de la ressource et la connectivité disponible. Il aide ensuite à déterminer si l’identité doit être portée par l’application, par un service intermédiaire ou par le composant qui expose le modèle.
Cette logique évite de choisir un endpoint uniquement sur sa proximité géographique. Dans un environnement réglementé, l’équipe doit également examiner le routage, les contrôles d’accès, la résolution réseau et les capacités prises en charge par le chemin retenu.
Google Cloud AI organise l’accès autour de trois endpoints
Google Cloud AI, via Vertex AI, distingue les endpoints globaux, multirégionaux et régionaux. Cette séparation rend le compromis entre disponibilité, résidence des données et performance plus lisible au moment de la conception.
Les endpoints globaux utilisent un routage dynamique pour maximiser la disponibilité. Les endpoints multirégionaux limitent ce routage à une zone géographique, comme les États-Unis ou l’Union européenne. Les endpoints régionaux imposent quant à eux le passage des données par une région déterminée.
| Type d’endpoint Vertex AI | Routage | Priorité principale | Effet tarifaire documenté |
|---|---|---|---|
| Global | Dynamique à l’échelle mondiale | Disponibilité | Référence tarifaire |
| Multirégional | Dynamique dans une zone géographique | Résidence géographique et disponibilité | Prime de 10 % pour certains modèles |
| Régional | Région déterminée | Contrôle géographique | Prime de 10 % pour certains modèles |
Les endpoints régionaux et multirégionaux incluent une prime tarifaire de 10 % sur certains modèles disponibles via Vertex AI. Cette différence rémunère le contrôle géographique accru par rapport au routage global.
L’endpoint global favorise la disponibilité
Le routage dynamique permet à Google Cloud de diriger les requêtes vers une infrastructure disponible dans le périmètre autorisé par le type d’endpoint. Ce modèle vise d’abord la continuité de service et l’utilisation efficace de la capacité.
Il convient aux applications pour lesquelles la priorité est l’accès au modèle et la capacité à absorber des variations de charge. En contrepartie, l’équipe doit vérifier que le niveau de résidence offert par l’endpoint correspond à ses exigences internes et réglementaires.
Les endpoints régionaux renforcent la maîtrise géographique
Un endpoint régional impose une zone de traitement déterminée. Il répond aux architectures qui doivent rattacher l’inférence à une région précise, par exemple pour des raisons de résidence des données ou de segmentation opérationnelle.
L’endpoint multirégional occupe une position intermédiaire. Il conserve un périmètre géographique défini tout en autorisant un routage dynamique à l’intérieur de ce périmètre, comme l’Union européenne ou les États-Unis.
Foundry propose un catalogue large, mais l’emplacement reste déterminant
Microsoft Foundry regroupe des modèles Microsoft, des modèles partenaires et des modèles accessibles sous forme d’API serverless. La disponibilité dépend du modèle, du type de déploiement, de la région et, pour certains modèles partenaires, du pays associé au compte de facturation Azure.
La documentation Microsoft distingue plusieurs catégories de déploiement, dont Global Standard, Data Zone Standard, Global Provisioned et Data Zone Provisioned. Ces catégories ne fournissent pas le même niveau de contrôle géographique ni la même capacité réservée.
Les modèles partenaires accessibles via des API serverless sont soumis à des conditions de disponibilité liées à la région où le fournisseur autorise leur achat. Pour les modèles Claude, Microsoft indique qu’un abonnement Azure payant est nécessaire et que le compte de facturation doit se trouver dans un pays où Anthropic propose ces modèles à l’achat.
Cette contrainte ajoute une dimension commerciale au choix technique. La région du projet Azure ne suffit pas toujours à déterminer si un modèle partenaire peut être utilisé : le pays du compte de facturation intervient également.
Des options globales et par zone
Microsoft a étendu la disponibilité de Model Router en Global Standard à 28 régions et celle de Data Zone Standard à 21 régions en juillet et août 2026. Model Router sélectionne un modèle parmi une configuration définie par l’équipe, tandis que le type de déploiement encadre le périmètre de traitement.
Les modèles disponibles directement auprès d’Azure disposent eux aussi de matrices régionales distinctes. La disponibilité d’un modèle ne doit donc pas être déduite de sa présence dans le catalogue : elle doit être vérifiée pour le type de déploiement et la région visés.
Google Cloud AI mise sur la lisibilité du choix géographique
Vertex AI simplifie la décision lorsqu’une équipe veut comparer trois niveaux de routage. Global correspond à la disponibilité maximale, régional à la maîtrise d’une région donnée et multirégional à un compromis entre les deux.
Cette présentation réduit le nombre de choix architecturaux exposés à l’équipe applicative. Le développeur sélectionne le type d’endpoint, puis applique les règles de sécurité et de réseau propres à Google Cloud.
Le modèle reste toutefois dépendant de la disponibilité de chaque fournisseur. Les conditions peuvent varier selon le modèle, la région et le type d’endpoint. La tarification peut également différer entre global, multirégional et régional.
Pour les projets qui utilisent plusieurs modèles, la lisibilité du routage constitue un avantage opérationnel. Une politique peut définir le périmètre accepté, puis empêcher l’utilisation d’un endpoint global lorsque la résidence géographique exige un endpoint régional ou multirégional.
Prix : les deux plateformes facturent principalement l’usage des modèles
Les services d’inférence ne se comparent pas à partir d’un abonnement mensuel universel. Microsoft Foundry et Google Cloud AI appliquent principalement une facturation à l’usage, généralement calculée selon le nombre de tokens traités et le type de déploiement.
Microsoft publie aussi des tarifs distincts selon le modèle, la longueur du contexte et la catégorie de déploiement. Pour GPT-6 Astra, Microsoft indique un tarif Global Standard de 10 dollars par million de tokens en entrée et 50 dollars par million de tokens en sortie pour le contexte court. En contexte long, les tarifs indiqués sont de 20 dollars en entrée et 75 dollars en sortie.
Pour GPT-6 Sol, Microsoft indique 2 dollars par million de tokens en entrée et 10 dollars en sortie en Global Standard pour le contexte court. GPT-6 Luna est affiché à 0,10 dollar en entrée et 0,50 dollar en sortie dans cette même catégorie.
| Modèle Microsoft Foundry | Déploiement | Entrée par million de tokens | Sortie par million de tokens |
|---|---|---|---|
| GPT-6 Astra, contexte court | Global Standard | 10 $ | 50 $ |
| GPT-6 Astra, contexte long | Global Standard | 20 $ | 75 $ |
| GPT-6 Sol, contexte court | Global Standard | 2 $ | 10 $ |
| GPT-6 Luna, contexte court | Global Standard | 0,10 $ | 0,50 $ |
Ces montants ne constituent pas un tarif générique de Foundry. Ils illustrent l’écart possible entre modèles et contextes. Les équipes doivent également intégrer les éventuels écarts entre Global Standard, Data Zone Standard, les capacités provisionnées et les options de traitement prioritaire.
Google Cloud facture également l’usage des modèles dans Vertex AI. Pour certains modèles, les endpoints régionaux et multirégionaux appliquent une prime de 10 % par rapport aux endpoints globaux. Cette règle rend le choix géographique directement visible dans le coût d’inférence.
À retenir : le routage global est généralement le point de référence tarifaire chez Vertex AI, tandis que la maîtrise géographique peut entraîner une prime de 10 % sur certains modèles. Chez Foundry, le prix dépend notamment du modèle et de la catégorie de déploiement.
Réseau et identité : Foundry offre plus de chemins, Vertex AI plus de catégories
La différence la plus nette concerne la profondeur du choix architectural. Microsoft Foundry expose quatre méthodes d’accès aux modèles hors région, avec des variations sur l’identité, le routage et le réseau. Google Cloud AI présente trois types d’endpoints, chacun associé à un comportement géographique identifiable.
Foundry convient aux organisations qui veulent intégrer l’accès au modèle dans une architecture Azure existante. Les équipes peuvent sélectionner un chemin cohérent avec leur réseau privé, leur mode d’authentification et la propriété des ressources.
Cette souplesse exige davantage de conception. L’équipe doit vérifier les interactions entre Azure API Management, le mode on-behalf-of, les outils de première partie et les contrôles réseau. Un chemin techniquement accessible peut donc ne pas être adapté à un agent qui dépend d’outils intégrés à Foundry.
Vertex AI présente un choix plus compact côté routage. Le type d’endpoint indique immédiatement si Google privilégie la disponibilité mondiale, le périmètre multirégional ou la région fixe. Cette simplicité peut réduire le temps de décision pour une application qui n’a pas besoin d’un intermédiaire réseau complexe.
Le rôle des services intermédiaires
Dans Foundry, un service intermédiaire peut modifier la manière dont l’identité est transmise et dont le trafic atteint le modèle. Azure API Management peut jouer un rôle central dans une architecture d’API, mais la compatibilité avec les outils de première partie doit être vérifiée lorsque le flux utilise le mode on-behalf-of.
Ce point est important pour les agents. Une application qui se limite à envoyer des requêtes de génération peut tolérer un chemin différent d’un agent qui appelle des outils, exploite une identité utilisateur ou dépend de services intégrés à la plateforme.
Dans Vertex AI, la sélection de l’endpoint encadre d’abord le routage géographique. Les autres composants Google Cloud, comme les règles IAM et les contrôles réseau, restent nécessaires, mais le choix entre global, multirégional et régional fournit une première décision claire.
Quel service choisir selon le projet ?
Microsoft Foundry est le meilleur choix lorsque le projet est déjà fortement ancré dans Azure et que l’équipe doit conserver une maîtrise détaillée de l’identité, du routage et du réseau. Ses quatre méthodes d’accès interrégional permettent d’adapter l’architecture aux contraintes de gouvernance plutôt que d’imposer un seul chemin.
Google Cloud AI est plus convaincant lorsque la priorité est de choisir rapidement un niveau de résidence et de disponibilité. Les trois catégories d’endpoints Vertex AI rendent le compromis explicite : disponibilité mondiale, routage dans une zone géographique ou région déterminée.
| Besoin du projet | Plateforme la plus adaptée | Raisonnement |
|---|---|---|
| Architecture Azure avec identité et réseau fortement personnalisés | Microsoft Foundry | Quatre méthodes d’accès interrégional et choix détaillé du chemin réseau |
| Routage mondial privilégiant la disponibilité | Google Cloud AI | Endpoint global avec routage dynamique |
| Routage dans l’Union européenne ou les États-Unis | Google Cloud AI | Endpoint multirégional avec périmètre géographique défini |
| Région Azure distincte de celle de l’application | Microsoft Foundry | Accès documentés aux modèles situés dans d’autres régions Azure |
| Agent utilisant des outils Foundry intégrés | Microsoft Foundry, après validation de l’architecture | Compatibilité à vérifier avec les intermédiaires et le mode on-behalf-of |
| Contrôle d’une région de traitement déterminée | Google Cloud AI | Endpoint régional avec routage vers une région précise |
Le choix ne doit pas être fondé uniquement sur le catalogue de modèles. Une entreprise peut trouver le modèle recherché dans les deux environnements, mais ne pas obtenir le même niveau de contrôle sur le trafic, l’identité ou la résidence des données.
Le cas des agents
Les agents rendent la décision plus sensible que la simple génération de texte. Ils peuvent appeler des outils, transmettre une identité utilisateur et dépendre de plusieurs services au cours d’une même exécution.
Dans Foundry, la présence d’outils de première partie impose de contrôler le comportement du chemin retenu. Une architecture passant par API Management peut bloquer ces outils en mode on-behalf-of, ce qui doit être intégré dès la conception.
Dans Vertex AI, les équipes doivent vérifier que le modèle et l’endpoint choisis prennent en charge les fonctionnalités d’agent nécessaires. Le routage géographique ne garantit pas à lui seul la compatibilité fonctionnelle de l’ensemble de la chaîne.
Notre avis : Foundry gagne en contrôle, Vertex AI en simplicité
Microsoft Foundry propose le meilleur accès aux modèles en 2026 pour les entreprises qui font de la gouvernance Azure, de l’identité et du réseau des critères de premier rang. Ses quatre méthodes d’accès aux modèles hors région offrent une latitude architecturale supérieure, au prix d’une conception plus exigeante et d’une vérification attentive des compatibilités.
Google Cloud AI remporte le duel sur la lisibilité du routage. Les endpoints global, multirégional et régional donnent une grille de décision immédiatement compréhensible, avec une prime de 10 % documentée pour certains endpoints régionaux et multirégionaux.
Sur les six prochains mois, le point décisif sera l’évolution des matrices de disponibilité et des modèles accessibles dans chaque zone. Les équipes qui veulent limiter les changements d’architecture ont intérêt à formaliser dès maintenant un flux de décision fondé sur l’identité, la connectivité, la résidence et les outils requis. La question ne sera plus seulement de savoir quel modèle est le meilleur, mais quelle plateforme permet de l’atteindre sans compromettre le réseau et la gouvernance.