Les modèles d’OpenAI arrivent sur Google Cloud : ce que les équipes d’entreprise doivent tester avant de changer

OpenAI apporte ses modèles de pointe et ses flux de travail Codex au Model Garden de Google Cloud. L’annonce est stratégiquement importante, mais sa portée pratique est plus limitée : certains clients de Google Cloud peuvent commencer à évaluer les modèles d’OpenAI dans un environnement cloud qu’ils utilisent déjà pour leurs achats, leurs identités et leur gouvernance. La disponibilité générale est prévue dans les prochaines semaines, tandis que le déploiement initial se fait en préversion privée.

Cette distinction compte. Il ne s’agit pas d’une nouvelle version de modèle OpenAI, ni de la preuve qu’une application peut passer de Gemini à Claude ou à OpenAI sans travail d’ingénierie. C’est un changement de distribution et de modèle d’exploitation. Les clients de Google Cloud pourront découvrir les modèles d’OpenAI aux côtés de ceux d’autres fournisseurs, les acheter via Google Cloud Marketplace et utiliser leurs engagements de dépenses Google Cloud existants pour financer ces achats. OpenAI indique également que les flux de travail agentiques de Codex seront inclus dans le partenariat.

Pour une équipe d’entreprise, la bonne question n’est pas : « Quel modèle a remporté l’annonce ? » Il faut plutôt demander : « Acheter un modèle par l’intermédiaire de notre cloud rend-il un flux de production plus sûr, moins coûteux ou plus facile à exploiter ? » La réponse dépendra de la charge de travail, des contrôles nécessaires et de la part de l’application environnante qui reste liée à un fournisseur donné.

Ce qui a réellement été annoncé

OpenAI et Google Cloud indiquent que les modèles d’OpenAI seront ajoutés au Model Garden de Google Cloud. L’annonce publiée par Google cite GPT-Astra, GPT-6.1 Sol et GPT-6 Luna comme les modèles déployés auprès de certains clients d’entreprise en préversion privée. L’annonce d’OpenAI décrit plus largement le dispositif comme un accès à ses modèles de pointe et à ses flux de travail Codex via Google Cloud.

Les clients devraient acheter les modèles par l’intermédiaire de Google Cloud Marketplace. Les organisations disposant d’engagements de dépenses Google Cloud pourront imputer ces achats sur ces engagements. Google précise également que l’utilisation apparaîtra sur une facture Google Cloud unique et sera prise en compte dans les Flexible Savings Plans applicables à différents fournisseurs de modèles. Ces modalités de facturation pourraient avoir une réelle importance pour les entreprises dont les équipes financières et achats gèrent déjà l’essentiel de l’infrastructure via Google Cloud.

Le partenariat ouvre aussi la voie à un accès depuis Google Antigravity et Gemini Agent. Cela laisse penser que l’accord vise davantage qu’un simple endpoint de modèle : les modèles d’OpenAI pourraient devenir sélectionnables dans les outils de développement et d’agents plus larges de Google. Les deux entreprises ne présentent pas cette annonce comme un parcours de migration achevé et généralement disponible. OpenAI indique que la disponibilité générale est prévue dans les prochaines semaines, tandis que Google décrit le déploiement actuel des modèles comme une préversion privée.

Microsoft reste le principal partenaire cloud d’OpenAI. L’accord avec Google doit donc être compris comme une extension de la distribution, et non comme le remplacement d’Azure ou comme l’abandon par OpenAI de ses relations cloud existantes.

Pourquoi la décision d’achat a changé

L’accès aux modèles était autrefois considéré comme une décision de fournisseur prise par l’équipe d’ingénierie. En pratique, les entreprises choisissent souvent un modèle au terme d’une série de décisions impliquant les achats, l’architecture cloud, la sécurité, la résidence des données, les finances et les opérations. La disponibilité d’un modèle dans le compte cloud où résident déjà les données et les applications peut réduire certains obstacles, même si le modèle lui-même ne change pas.

Il y a quatre effets pratiques.

Premièrement, les achats pourraient être simplifiés. Une équipe qui dispose déjà d’un accord avec Google Cloud pourra potentiellement s’appuyer sur une relation commerciale existante au lieu de négocier un arrangement distinct avec un fournisseur de modèles. Cela ne garantit pas un prix inférieur. En revanche, cela modifie la manière dont la dépense est approuvée, engagée, prévisionnée et auditée.

Deuxièmement, la gestion des identités et des accès pourrait être plus facile à centraliser. Google Cloud indique que les charges de travail OpenAI utiliseront ses contrôles d’accès, ses identités authentifiées, sa journalisation d’audit et les protections VPC Service Controls. Ces contrôles peuvent aider une organisation à répondre à des questions opérationnelles élémentaires : quel service a appelé le modèle, quelle identité l’a autorisé, quel projet a payé la requête et quelle règle s’y est appliquée.

Troisièmement, l’évaluation peut devenir plus réaliste. Une entreprise peut comparer les modèles d’OpenAI à Gemini, Claude et aux modèles ouverts dans le même environnement de découverte. C’est plus utile que de comparer des scores de benchmarks publics, car l’organisation peut tester ses propres prompts, documents, appels d’outils, exigences de latence et modes d’échec.

Quatrièmement, le fournisseur cloud gagne de l’influence sur la couche de sélection des modèles. Google présente Model Garden comme un moyen de choisir et de remplacer des modèles en fonction de leurs performances, de leur latence et de leur coût. Cela peut réduire le risque de sélectionner trop tôt un modèle unique, mais cela fait aussi de Google Cloud un intermédiaire plus important dans l’architecture applicative. Une équipe doit considérer cette commodité comme une capacité qui a un prix, et non comme une forme de portabilité équivalente.

La préversion privée est le premier signal d’alerte

L’accès en préversion privée est utile pour explorer les possibilités, mais constitue une base fragile pour un engagement de production. Les programmes en préversion peuvent comporter des identifiants de modèles changeants, un nombre limité de régions, une documentation incomplète, des quotas restreints, une latence instable et des conditions d’assistance différentes de celles de la disponibilité générale. Un prototype réussi prouve qu’une requête a fonctionné dans les conditions de la préversion. Il ne prouve pas que le même flux respectera un objectif de niveau de service après son lancement.

Les équipes qui évaluent la préversion devraient consigner les conditions de chaque test :

• l’identifiant et la version exacts du modèle ;
• la région ou le point de terminaison Google Cloud utilisés ;
• le fait que les requêtes aient été acheminées via un service régional ou mondial ;
• les limites de jetons, la taille du contexte et les paramètres de sortie ;
• le comportement des appels d’outils et les règles d’expiration ;
• le comportement des mécanismes de sécurité ou de filtrage des contenus ;
• les paramètres de journalisation, de conservation et d’accès ;
• la source du prix et l’unité de facturation utilisées pour le test.

Ce relevé n’est pas de la bureaucratie. C’est le minimum d’informations nécessaire pour expliquer plus tard pourquoi un résultat, un coût ou une mesure de latence a changé. L’accès en préversion est particulièrement risqué pour les flux faisant intervenir des agents : une petite modification du format des appels d’outils ou du comportement des délais d’expiration peut transformer une démonstration réussie en boucle de tentatives répétées et d’actions partielles.

Ce qu’il faut tester avant de déplacer du travail réel

Une évaluation sérieuse doit s’appuyer sur un échantillon représentatif de l’application, plutôt que sur une collection de prompts impressionnants. Sélectionnez des tâches qui révèlent les interactions entre le modèle, la plateforme et le reste du système.

1. Testez le résultat métier, pas la prose du modèle

Définissez la condition d’acceptation avant de comparer les fournisseurs. Pour un flux de support, cela peut signifier un routage correct, une chaîne complète de citations et une escalade sûre lorsque la réponse est incertaine. Pour le développement logiciel, il peut s’agir de réussir les tests, de préserver un contrat d’API et de produire une modification facile à examiner. Pour le traitement de documents, cela peut vouloir dire atteindre une précision au niveau des champs et prévoir une méthode explicite pour gérer les informations manquantes.

Mesurez le résultat avec un jeu d’évaluation fixe. Gardez un jeu distinct d’exemples jamais vus afin de réduire le risque qu’un ajustement du prompt se contente de suradapter le système aux cas de test. Incluez des requêtes difficiles et ordinaires ; un modèle performant uniquement sur les cas limites n’est pas forcément le meilleur choix pour la production.

2. Comparez le coût total d’une tâche

Le prix des jetons ne représente qu’une partie de la facture. Un modèle de coût pratique doit inclure les jetons d’entrée et de sortie, le comportement du contexte mis en cache, les nouvelles tentatives, les appels d’outils, la récupération d’informations, le stockage, l’orchestration, l’observabilité et la revue humaine. Les tâches agentiques peuvent coûter particulièrement cher, car une seule requête utilisateur peut générer de nombreux appels au modèle et des répétitions du contexte.

Calculez le coût par tâche métier terminée, et pas seulement le coût par million de jetons. Par exemple :

coût par tâche terminée =
  utilisation du modèle
  + appels de récupération et d’outils
  + orchestration et infrastructure
  + nouvelles tentatives et échecs
  + revue humaine

Exécutez la même charge de travail à différents niveaux de concurrence. Un modèle peu coûteux à dix requêtes par minute peut devenir moins intéressant lorsque le système nécessite une capacité réservée importante, une latence plus stricte ou une gestion plus agressive des nouvelles tentatives. Vérifiez également si la facturation marketplace, les remises cloud et la tarification du fournisseur sont appliquées de la même manière. Une facture unifiée simplifie la comptabilité ; elle ne rend pas pour autant transparente l’économie unitaire sous-jacente.

3. Mesurez la latence comme une distribution

Ne communiquez pas uniquement le temps de réponse moyen. Suivez la latence médiane ainsi que les latences p95 et p99 pour l’ensemble du flux. Distinguez le temps d’attente du modèle du temps consacré à la récupération d’informations, à l’exécution des outils, aux contrôles de politique et au rendu de la réponse.

Pour un agent, mesurez le délai avant la première action utile et le délai avant l’achèvement. Un modèle plus lent qui effectue moins d’appels d’outils incorrects peut terminer plus vite qu’un modèle plus rapide nécessitant des corrections répétées. À l’inverse, un modèle très performant peut être disproportionné pour la classification, l’extraction ou la rédaction courante.

4. Tester les comportements en cas d’échec et de reprise

Le test le plus important est peut-être celui qui échoue. Fournissez au système des données incomplètes, une réponse d’outil malformée, un service indisponible, une instruction ambiguë et une demande qui dépasse l’autorité du modèle. Observez si le flux s’arrête, demande des précisions, réessaie sans danger ou poursuit son exécution en inventant des hypothèses.

Gardez les effets de bord externes derrière des étapes de validation explicites. Un modèle ne devrait pas pouvoir envoyer un e-mail, modifier la fiche d’un client, approuver une transaction ou déployer du code simplement parce qu’il a produit une prochaine étape plausible. Le lieu d’hébergement dans le cloud ne change rien à cette exigence. La journalisation centralisée aide les enquêteurs à comprendre une action après sa réalisation ; elle ne remplace pas l’autorisation nécessaire avant son exécution.

5. Valider les frontières des données à partir d’éléments concrets

Google Cloud affirme que les prompts, le contexte et les sorties des charges de travail resteront à l’intérieur d’un périmètre de données désigné par le client et ne serviront pas à entraîner des modèles de fondation. L’entreprise décrit également des limites d’accès isolées et indique que des options de conservation nulle des données (Zero Data Retention) seront bientôt disponibles. Ces affirmations sont importantes, mais l’acheteur doit vérifier quels contrôles s’appliquent exactement au service en préversion, à la région, au modèle, au type de compte et au contrat concernés.

Demandez des réponses écrites à des questions comme celles-ci :

• Les données sont-elles conservées par Google Cloud, OpenAI ou les deux, et pendant combien de temps ?
• Les prompts et les sorties servent-ils à surveiller les abus, à déboguer le service ou à l’améliorer ?
• La politique de conservation change-t-elle lorsque l’assistance ou la traçabilité sont activées ?
• Où sont stockés les journaux, les entrées mises en cache, les embeddings et les sorties des outils ?
• Les prompts sont-ils envoyés hors de la région sélectionnée pour le routage ou les contrôles de sécurité ?
• Quels contrôles sont disponibles maintenant et lesquels sont seulement prévus ?
• Que deviennent les données lorsqu’une requête échoue ou est relancée ?

« Dans notre cloud » ne constitue pas une description suffisante de la confidentialité. Une requête peut traverser plusieurs services gérés, chacun pouvant appliquer ses propres règles de journalisation, de conservation et d’accès par les administrateurs. Considérez la documentation et le contrat du fournisseur comme la source de référence pour le déploiement que vous utiliserez réellement.

Le choix du modèle n’est utile que si l’application peut le supporter

La promesse de Google repose sur le choix du modèle : utiliser le modèle adapté à chaque charge de travail et pouvoir en changer sans verrouillage architectural. C’est un objectif de conception pertinent, mais il exige de séparer volontairement l’application de la surface propre à chaque fournisseur.

Au minimum, placez la sélection du modèle derrière une interface interne. Conservez les prompts, les schémas, les définitions d’outils, les règles de sécurité et les résultats d’évaluation sous forme d’artefacts versionnés. Normalisez les métadonnées de réponse et les erreurs. L’application doit préciser les capacités dont elle a besoin : sortie structurée, vision, contexte long, exécution de code, navigation web, utilisation d’un ordinateur, appel d’outils ou mode de raisonnement particulier.

Ne supposez pas qu’une requête compatible avec l’API d’OpenAI sera portable sur le plan du comportement. Les fournisseurs peuvent traiter différemment les instructions système, les schémas JSON, les événements de diffusion en continu, les arguments des outils, le décompte des jetons, les réponses de refus, le contexte mis en cache et les filtres de sécurité. Une fine couche de compatibilité peut accélérer la première intégration tout en masquant des différences importantes. La portabilité doit être testée au niveau des tâches terminées et de la gestion des échecs.

Un bon routeur de modèles a également besoin d’une politique de repli. Si le modèle préféré est indisponible, le système doit-il se fermer par défaut, utiliser un modèle moins cher, basculer vers un autre fournisseur ou placer la tâche dans une file destinée à un humain ? La réponse dépend du risque métier. Un résumé destiné au support client peut tolérer un modèle de repli. Une approbation financière ou un déploiement en production, probablement pas.

Les questions de coût que les clients de Google Cloud doivent poser

La possibilité d’utiliser un engagement cloud existant est séduisante, car elle peut transformer des dépenses d’infrastructure inutilisées en moyen d’expérimenter avec des modèles. Elle peut aussi donner une fausse impression d’économie. Une dépense engagée reste un engagement, et un modèle qui la consomme peut revenir plus cher qu’une solution directe une fois pris en compte le taux d’utilisation, les remises et les frais opérationnels.

Établissez une comparaison avec au moins trois scénarios :

1. le fournisseur et l’architecture actuels ;
2. les modèles d’OpenAI achetés via Google Cloud ;
3. un second fournisseur ou un modèle ouvert exécuté sur la même plateforme.

Utilisez la même charge de travail et incluez les mêmes coûts de revue et d’infrastructure. Comparez le coût réel par tâche réussie, et pas seulement les tarifs de jetons annoncés. Intégrez le coût du transfert des données vers le service, du stockage des traces, de l’exécution de la récupération d’informations et du maintien d’un second fournisseur pour assurer la résilience.

Clarifiez également la relation commerciale. Une facture Google Cloud peut simplifier le paiement, tout en laissant l’assistance propre au modèle, les quotas, la gestion des incidents et les conditions de niveau de service dépendre d’un fournisseur distinct ou d’un accord de préversion. Les achats doivent savoir à qui revient l’escalade lorsque le modèle est disponible, mais que le point de terminaison intégré rencontre une défaillance.

Qui devrait l’essayer maintenant

La préversion concerne surtout les équipes qui utilisent déjà Google Cloud et qui ont une raison concrète d’évaluer les modèles d’OpenAI sans créer un circuit distinct pour les achats et la gouvernance. Exemples :

• une équipe plateforme qui compare OpenAI, Gemini, Claude et des modèles ouverts sur la même charge de travail d’entreprise ;
• une organisation réglementée qui a besoin de contrôles centralisés pour les identités, les audits et le périmètre des données ;
• une équipe chargée des outils de développement qui teste des flux Codex à proximité des dépôts, des systèmes de build et de l’observabilité existants ;
• une équipe financière ou achats qui veut déterminer si les engagements cloud peuvent soutenir un programme exploitant plusieurs modèles ;
• une équipe d’architecture qui conçoit un routeur de modèles et accepte de maintenir des tests propres à chaque fournisseur.

Ces équipes devraient commencer par une évaluation limitée. Choisissez un petit nombre de flux de travail, utilisez des données synthétiques ou dûment approuvées, fixez un plafond budgétaire et définissez une date de décision. L’objectif est de vérifier si l’intégration modifie le coût d’exploitation ou la surface de contrôle de la charge de travail.

Qui devrait attendre

Les équipes devraient attendre la disponibilité générale et une documentation complète si elles ont besoin de régions garanties, de quotas stables, d’engagements formels de niveau de service, de preuves de conformité mûres ou d’une tarification prévisible. Une préversion privée ne constitue pas une base adaptée à une dépendance destinée aux clients et dépourvue de solution de repli.

Les organisations qui n’ont pas de présence significative sur Google Cloud devraient également remettre en question le principe même de l’opération. Si la seule raison de déplacer une charge de travail est l’accès aux modèles d’OpenAI, l’ajout d’un autre plan de contrôle cloud peut accroître la complexité au lieu de la réduire. Une intégration directe avec le fournisseur, une passerelle de modèles déjà en place ou une autre marketplace cloud pourraient être plus simples.

Les équipes qui peinent déjà à gérer l’évaluation, les autorisations ou les limites d’action ne doivent pas considérer un nouvel emplacement dans une marketplace comme une solution. Le partenariat peut regrouper l’accès et la facturation. Il ne peut pas définir ce qu’un agent est autorisé à faire, déterminer si une réponse générée est correcte ni fournir la responsabilité métier manquante.

Le changement de fond : les clouds deviennent des distributeurs de modèles

L’annonce illustre une évolution plus large de l’IA d’entreprise. Les plateformes cloud ne vendent plus seulement de la puissance de calcul, du stockage et des bases de données gérées. Elles deviennent des couches de distribution pour des fournisseurs de modèles concurrents, avec les achats, les identités, l’observabilité et les outils applicatifs intégrés autour du point de terminaison du modèle.

Cela peut être avantageux pour les acheteurs. Une entreprise peut gagner en pouvoir de négociation, disposer d’un plan de contrôle plus cohérent et obtenir un moyen pratique de mener des comparaisons. Mais la responsabilité peut aussi devenir moins lisible. Lorsqu’un modèle, un cloud, un framework d’agents et une plateforme de données sont regroupés, un incident peut impliquer plusieurs contrats et plusieurs ensembles de contrôles.

L’architecture gagnante ne sera pas nécessairement celle qui propose le plus de modèles dans un catalogue. Ce sera celle qui rend le choix du modèle réversible, mesure le coût du travail réellement terminé, consigne les déplacements des données et bloque les actions à fort impact jusqu’à leur approbation par une personne ou un système responsable.

L’arrivée d’OpenAI sur Google Cloud mérite donc d’être testée, en particulier par les clients Google existants. Mais la décision immédiate devrait être un plan d’évaluation, pas un plan de migration : reproduire une charge de travail réelle, comparer le coût total par tâche, vérifier le traitement des données, éprouver les scénarios de défaillance et conserver une solution opérationnelle. Si la préversion réussit ces tests, le partenariat pourra réduire les frictions pour l’entreprise. Dans le cas contraire, une facture unique et un catalogue de modèles plus vaste ne sauveront pas le projet.