Puces TPU de Google : pourquoi OpenAI diversifie ses achats

Pourquoi OpenAI voudrait-elle acheter des TPU à Google ?

La raison la plus évidente serait de ne pas dépendre d'une seule source. Les systèmes Nvidia sont devenus centraux pour développer et déployer l'IA. Mais être trop dépendant d'un fournisseur unique peut exposer à des délais, à des prix et à des arbitrages de capacité qui échappent à l'acheteur. Quand on entraîne et qu'on exploite des modèles à très grande échelle, ces contraintes peuvent freiner un lancement ou limiter ce qu'on peut absorber en production.

Avoir une seconde architecture donne aussi plus d'options. Cela ne veut pas dire qu'OpenAI renoncerait à Nvidia. Elle pourrait garder les puces Nvidia pour certaines charges, et réserver les TPU à d'autres usages si, pour ces cas précis, les performances, les coûts et l'outillage logiciel sont au rendez-vous. L'objectif, dans ce scénario, ressemble davantage à une répartition des besoins - et à plus de pouvoir de négociation - qu'à une substitution totale.

Le passage de la location à l'achat, si l'information se confirme, pourrait aussi signaler une volonté de mieux maîtriser l'accès au matériel. Louer permet de tester une architecture sans investir tout de suite dans des équipements et dans de la capacité de centre de données. Acheter devient plus logique quand les besoins sont clairs et durables. Mais acheter implique aussi des responsabilités opérationnelles : installer la puce, l'intégrer à l'infrastructure, gérer l'alimentation, le refroidissement et la maintenance.

Enfin, il y a un signal côté logiciel. OpenAI aurait publié une offre d'emploi pour un ingénieur chargé d'optimiser des modèles sur TPU. Adapter des modèles à une architecture donnée, ce n'est pas « juste » compiler et lancer : il faut travailler sur les compilateurs, les performances et les outils d'exécution. Ce recrutement ne prouve pas une commande d'achat, mais il colle avec l'idée qu'OpenAI travaille sérieusement la compatibilité de ses logiciels avec les TPU.

La stratégie se déroule aussi dans un paysage de partenariats déjà dense. Nvidia a signé en 2025 une lettre d'intention évoquant un investissement pouvant atteindre 100 milliards de dollars et le déploiement d'au moins 10 gigawatts de systèmes Nvidia chez OpenAI. Nvidia a ensuite investi 30 milliards de dollars dans un tour de financement, un montant inférieur à celui mentionné dans la lettre d'intention. OpenAI a aussi conclu un accord avec AMD, avec une possibilité d'acquérir des actions si certains déploiements de puces sont réalisés. Bref : même si OpenAI explore d'autres pistes, Nvidia reste au centre.

Que sont les TPU et pourquoi ne remplacent-ils pas Nvidia automatiquement ?

Les TPU, Tensor Processing Units, sont des puces conçues par Google pour accélérer des calculs utilisés par les modèles d'apprentissage automatique. Google a présenté cette famille en 2016 et l'utilise déjà dans ses centres de données. Comme les GPU de Nvidia, elles servent à faire tourner des calculs lourds. Mais leur conception, leur écosystème logiciel et leurs choix d'architecture ne sont pas les mêmes.

Google a annoncé en 2026 deux puces de « huitième génération » : la TPU 8t pour l'entraînement et la TPU 8i pour l'inférence, c'est-à-dire la production de réponses par un modèle déjà entraîné. Cette distinction dit quelque chose d'important : « une puce pour l'IA » ne correspond pas à un seul type de tâche. Entraîner un modèle, servir des requêtes en production et traiter des charges spécialisées ne demandent pas exactement le même profil de calcul.

Comparer les performances pose aussi une question simple : sur quelle base de mesure ? Google a publié des chiffres qui comparent ses nouvelles puces à sa génération précédente (Ironwood), pas directement aux systèmes Nvidia. Ces résultats peuvent montrer un progrès à l'intérieur de l'offre de Google, mais ils ne suffisent pas à conclure que les TPU seraient systématiquement plus rapides ou moins coûteux qu'un GPU pour une charge donnée. Il faut regarder aussi la consommation électrique, le taux d'utilisation, le coût de l'infrastructure et le temps nécessaire pour adapter les logiciels.

C'est là que la migration devient compliquée. Les modèles ne se déplacent pas d'un serveur à l'autre comme un fichier. Les compilateurs traduisent le code du modèle pour l'adapter au processeur cible. Les bibliothèques, les outils de débogage et la façon de distribuer le calcul influencent directement la performance. Une équipe peut devoir revoir des opérations, corriger des erreurs numériques ou optimiser l'exécution sur plusieurs puces.

Au final, le coût réel ne se limite pas au prix de la puce. Une option « moins chère » peut coûter plus cher si elle exige des mois d'adaptation, ou si elle utilise moins efficacement l'énergie disponible. À l'inverse, une architecture complémentaire peut devenir intéressante sur des tâches répétitives, bien comprises et exécutées à grande échelle. Le bon indicateur n'est pas seulement le nombre d'opérations, mais le coût et la qualité du service rendu pour un usage précis.

Comment OpenAI pourrait-elle organiser plusieurs sources de calcul ?

Une entreprise d'IA n'est pas obligée d'utiliser une architecture unique pour tout. Elle peut répartir les charges selon leur nature, leur urgence et leur coût. L'entraînement d'un modèle mobilise des ressources pendant une période déterminée. L'inférence se répète à chaque requête, et peut devenir une dépense continue à mesure que l'usage grandit. Les contraintes de latence, de capacité et de disponibilité ne sont pas les mêmes.

Dans un scénario multi-fournisseurs, OpenAI pourrait donc répartir les tâches entre Nvidia, AMD et Google, et à terme intégrer aussi une puce conçue en interne avec Broadcom. Les systèmes déjà en place continueraient à servir les charges où ils sont les mieux adaptés. Les nouvelles architectures seraient introduites progressivement : d'abord sur certains modèles ou services compatibles, puis élargies si les résultats tiennent en production. Cette méthode limite le risque d'une migration « à tout casser », mais elle ajoute de la complexité technique.

Toujours d'après les informations évoquées, OpenAI aurait commencé à louer des TPU en juin 2025, avec des tests préliminaires et sans déploiement annoncé à grande échelle. Sur le papier, c'est logique : louer permet de mesurer des performances sur des modèles réels avant de s'engager. On peut comparer le temps de traitement, le coût par requête, la stabilité et la quantité de travail nécessaire à l'adaptation. Les performances en laboratoire ne prédisent pas toujours ce qui se passe en production, où les pics de demande et les contraintes de disponibilité changent la donne.

Le recrutement d'un spécialiste des compilateurs s'inscrit exactement dans cette logique. L'objectif est de rendre l'exécution efficace, de repérer les opérations qui tirent profit de la puce et d'éviter les goulots d'étranglement entre composants. En pratique, ça relie la recherche logicielle à l'économie du produit : mieux utiliser le matériel peut réduire le coût par réponse et permettre de servir plus d'utilisateurs avec une capacité donnée.

En parallèle, OpenAI préparerait sa propre puce, nom de code Jalapeño, avec Broadcom. Elle serait orientée vers l'inférence, avec un déploiement initial prévu à la fin de 2026. Concevoir un processeur interne peut donner plus de contrôle sur des points spécifiques de performance et de coûts. Mais ça ne rend pas l'entreprise « indépendante » du jour au lendemain : il faut fabriquer les puces, les intégrer aux systèmes, développer les logiciels et garantir une disponibilité à l'échelle.

Un schéma pragmatique ressemblerait donc à : tester, mesurer, puis déplacer progressivement des charges. Il faut garder une solution de repli, regarder le coût total plutôt que le seul prix d'achat, et vérifier que la qualité de service ne baisse pas. Cette logique vaut aussi pour les entreprises européennes qui évaluent des fournisseurs cloud : la diversification ne sert à grand-chose si les applications ne peuvent pas réellement tourner ailleurs sans trop de friction.

Quels sont les risques et les limites de cette stratégie ?

Le premier risque, c'est de confondre diversification et indépendance. Acheter des TPU réduirait potentiellement la dépendance à Nvidia pour certaines opérations, mais créerait une autre dépendance : celle à une architecture, à des outils et à une chaîne d'approvisionnement contrôlée par Google. Le fournisseur peut alors peser sur l'accès, la disponibilité et l'évolution de l'environnement technique.

L'intégration de plusieurs architectures a aussi un coût organisationnel. Les équipes doivent conserver des compétences et des outils adaptés à chaque système. Les logiciels optimisés pour une puce ne réagissent pas toujours de la même façon sur une autre. Sans standardisation suffisante, la diversité peut ralentir les mises en production et compliquer le diagnostic en cas d'incident. Une architecture supplémentaire n'a de valeur que si ses bénéfices dépassent les frais de coordination.

Il y a aussi un risque financier très concret : acheter du matériel exige d'engager du capital avant que les gains soient garantis. Il faut aussi financer les centres de données, l'électricité, le refroidissement et la maintenance. La valeur d'un équipement dépend de son taux d'utilisation et de sa durée de vie utile. Or les méthodes et les modèles évoluent vite : une puce achetée pour une charge spécifique peut perdre de l'intérêt avant d'être entièrement amortie.

La disponibilité énergétique est un autre point. Les infrastructures d'IA consomment beaucoup d'électricité et nécessitent des raccordements importants. Les acteurs du secteur parlent désormais en gigawatts : à cette échelle, les contraintes ne sont plus seulement informatiques. Les délais d'aménagement, l'accès à l'énergie et la localisation des centres de données peuvent décider si un projet est réalisable, y compris en Europe, où les règles d'implantation et les objectifs de sobriété pèsent dans les arbitrages.

Enfin, il faut rester prudent avec les informations disponibles. Le projet d'achat est rapporté par The Information à partir d'une source proche du dossier, mais sans confirmation officielle. Le montant, le volume et le calendrier ne sont pas publics. Les éléments observés - location antérieure, recrutement ciblé et relations industrielles - rendent l'hypothèse plausible, sans pour autant prouver qu'un contrat d'achat a été signé.

Pour les entreprises qui observent cette stratégie, la leçon n'est pas « multipliez les fournisseurs ». Elle consiste plutôt à mesurer le coût complet d'une dépendance, identifier les charges réellement déplaçables, et chiffrer la « portabilité » des applications. Une solution de secours inutilisée peut coûter cher ; une solution testée et prête peut éviter une interruption... et renforcer votre pouvoir de négociation.

Que signifie cette évolution pour le marché de l'IA ?

Si OpenAI achète effectivement des TPU, cela suggérerait que la compétition dans l'IA se joue aussi sur l'accès au calcul. Les modèles attirent l'attention, mais leur entraînement et leur exploitation reposent sur des équipements, des logiciels et des capacités énergétiques coûteux. Les grands laboratoires cherchent donc à sécuriser leurs ressources et à éviter qu'un seul fournisseur ne devienne un point de blocage.

Google a, de son côté, intérêt à vendre ses systèmes au-delà de ses propres services cloud. D'après sa direction financière, l'essentiel des revenus liés à la vente de systèmes TPU est attendu en 2027. Google aurait aussi commencé à livrer des systèmes TPU destinés à des centres de données de clients. Si de grands acteurs adoptent ces équipements, Google pourrait valoriser son savoir-faire matériel tout en renforçant son activité cloud.

Mais la concurrence ne se limite pas à OpenAI. Anthropic a conclu un accord avec Google et Broadcom portant sur plusieurs gigawatts de capacité TPU de nouvelle génération, attendue à partir de 2027. Nvidia reste, pour OpenAI, un partenaire financier et industriel important, tandis qu'AMD cherche aussi à être présent sur certains déploiements. Dans l'ensemble, on voit que les frontières entre fournisseur, investisseur et partenaire d'infrastructure se brouillent.

Pour les clients européens, cela peut augmenter le choix, sans promettre une baisse immédiate des prix. La concurrence entre architectures ne se transforme en économies que si les entreprises peuvent déplacer leurs applications sans coûts disproportionnés. Et les enjeux de localisation des données, de conformité au RGPD et de continuité de service restent distincts du choix du processeur. Un TPU ne garantit pas, à lui seul, l'hébergement ou la gouvernance des données.

Le signal le plus utile à surveiller ne serait donc pas une annonce, mais une adoption mesurable : quelles charges sont exécutées sur chaque puce, à quel coût par tâche, avec quelle disponibilité, et avec quel niveau d'effort logiciel. Tant que ces données ne sont pas publiques, il est prématuré de conclure que Google va remplacer Nvidia chez OpenAI. En revanche, l'idée de diversification colle avec la croissance des besoins et la volonté de mieux maîtriser les coûts sur la durée.