Détails

Écrit par : IT Pro

Catégorie : Blog

Publié le : 22 Novembre 2025

Clics : 5199

Présentation

L'informatique moderne fonctionne au silicium, et les GPU sont devenus le nouvel or. Qu'il s'agisse de jeux, de recherches sur l'IA, de VFX, de rendus 3D, de crypto-mines ou de datacenter, la demande de processeurs graphiques puissants a explosé ces dernières années. Le résultat a été une pénurie mondiale prolongée de GPU qui a touché tout le monde, des consommateurs individuels aux fournisseurs de cloud hyperscale.

Ce qui a commencé par une perturbation de l'approvisionnement est devenu une crise mondiale complexe et multicouche impliquant des goulets d'étranglement avancés dans la fabrication de semi-conducteurs, des contraintes géopolitiques, des investissements massifs dans l'IA, la demande de jeux, une augmentation de la consommation de nuages et des transitions technologiques.

Cet article se décompose pourquoi la pénurie mondiale de GPU persiste, pourquoi les nouvelles puces restent chères, et surtoutquand (et si) cette pénurie finira.

---

1. Pourquoi les GPU sont différents des autres puces

Les processeurs ne sont pas des processeurs.

Ils exigent:

• plus de transistors par mm2

• lithographie plus avancée (jusqu'à 3nm / 5nm)

• intégration de la mémoire haute bande (HBM)

• Emballage avancé (CoWoS, EMIB, 3D)

• Tolérance de défaut extrêmement faible

• Lignes de fabrication spécialisées

• fournisseurs mondiaux limités

Cela signifie:

• La production de GPU ne peut pas être simplement mise à l'échelle

• de nouvelles usines ne peuvent pas être allumées du jour au lendemain

• seulement une poignée d'entreprises peuvent les faire du tout

95%+ de la production de GPU en phase de saignement dépend du TSMC, le géant taïwanais des semi-conducteurs.

C'est un point unique d'échec mondial.

---

2. Qu'est-ce qui a déclenché la pénurie? (Vagues multiples)

La pénurie de GPU n'est pas un événement, c'est une série de vagues qui se chevauchent :

Vague 1 — Perturbation de l'offre pandémique (2020-2021)

Les usines ont fermé.
L'expédition a gelé.
La demande a augmenté.

Résultat : zéro inventaire au lancement pour la plupart des GPU consommateurs.

Vague 2 — Cryptomine Frenzy

Ethereum mines a envoyé la demande GPU par le toit.

Les joueurs étaient en concurrence avec les exploitations minières industrielles.

Les prix ont augmenté de 200 à 400 %.

Wave 3 — Explosion de l'informatique en nuage

Les hyperscaleurs ont considérablement augmenté la capacité GPU pour l'IA :

• AWS

• Google Cloud

• Microsoft Azure

• Nuage Oracle

• Nuage Tencent

• Nuage d'Alibaba

Chaque hyperscaleur a commandé des millions d'unités.

Vague 4 — Rush d'or AI (2023-2025)

La montée de:

• ChatGPT

• Famille GPT-4

• Modèles de lama

• Diffusion stable

• Cours moyen

• Formation IA partout

a transformé les GPU en infrastructure stratégique.

Les corporations, les gouvernements et les entrepreneurs de la défense sont entrés dans la guerre des enchères.

Wave 5 — Emballage semi-conducteur

L'emballage de CoWoS a retardé les expéditions de mois.

Peu importe si un GPU est prêt, s'il ne peut pas être lié à HBM, il est inutilisable.

---

3. Pourquoi AI est le conducteur principal maintenant

Ceci est crucial:

AI est aujourd'hui le premier consommateur de GPU haut de gamme.

L'IA génétique nécessite:

• paramètres de formation à l'échelle des milliards

• charge de travail à inférence continue

• énorme capacité de calcul parallèle

• débit de mémoire haut débit

La formation d'un modèle à la frontière peut exiger des dizaines de milliers de GPU de classe H100/H200—et que pour unique modèle.

Ensuite, l'inférence (usage continu) consomme plus Avec le temps.

La demande est passée de milliers → des centaines de milliers → des millions d'unités dans le monde.

Aucune industrie manufacturière ne peut absorber ce choc instantanément.

---

4. NVIDIA Dominance = goulot d ' étranglement du marché

Contrôles NVIDIA:

• 80 à 90 % du marché mondial du GPU AI

• presque tout le matériel de formation hyperéchelle

• Lock-in de l'écosystème CUDA

La quantité de GPU est limitée.
Les alternatives GPU sont limitées.
Les coûts de commutation du GPU sont énormes.

Les entreprises n'ont d'autre choix que d'attendre et de payer.

---

5. Pourquoi les GPU consommateurs et jeux restent coûteux

Vous penseriez que les GPU consommateurs seraient bon marché maintenant.

Toutefois:

1. La fabrication priorise les GPU datacenter

(H100, GH200, B200 etc.)

Parce que...
marge bénéficiaire par puce:
2000 $+ → 30 000 $+

vs
carte de consommateur:
200 $ → 1600$

Les fabricants préfèrent les jetons rentables.

2. La demande de jeux reste élevée

Les nouveaux titres AAA nécessitent plus de puissance.

3. Le marché utilisé est sec

L'effondrement minier a inondé l'approvisionnement une fois— mais cet approvisionnement a disparu.

4. Les amateurs d'IA sont maintenant en concurrence avec les joueurs

Plus de concurrence → prix plus élevés.

---

6. Goulets d'étranglement expliqués

Les plus grandes contraintes aujourd'hui:

• Lithographie

Seuls TSMC, Samsung et Intel peuvent construire des nœuds avancés.

• Capacité d'emballage

CoWoS est limité et complexe.

• Production de HBM

Seulement quelques fournisseurs fournissent:

• SK Hynix

• Samsung

• Micron

et les taux de rendement sont faibles.

• Épuisement des stocks

Il n'existe plus de stock d'entrepôt.

• Logistique maritime

Le matériel traverse des dizaines d'étapes :
fab → packaging → mémoire → board Assemblage → test → validation → distribution

---

7. Le risque géopolitique amplifie tout

La production de GPU dépend massivement de Taiwan.

Les facteurs de risque comprennent :

• tensions Chine-Taïwan

• Contrôle des exportations américaines

• sanctions

• restrictions commerciales

• politiques d'embargo sur les puces

Les États-Unis contrôlent l'accès aux puces AI pour la Chine.
La Chine stocke maintenant de manière agressive.
Cela entraîne une pénurie supplémentaire.

---

8. Quand la pénurie de GPU se terminera-t-elle réellement?

Réponse courte :

Pas bientôt.

Considérations de calendrier réalistes :

2025

• desserrer légèrement les contraintes d'approvisionnement

• nouveaux fabs commencer rampe limitée

• plus de disponibilité HBM

• mais la demande d'IA augmente plus rapidement que l'offre

2026

• lignes d'emballage supplémentaires complétées

• certaines régions voient la stabilisation des prix

• diminution de l ' arriéré

2027+

• fabs next-gen viennent en ligne

• l'offre mondiale augmente considérablement

• déclin significatif de la pénurie

La plupart des analystes prévoient une normalisation significative entre 2026-2028.

Pas en 2025.

Certainement pas en 2024-2025.

---

9. Les prix du GPU baisseront-ils?

Ils sera, mais lentement — parce que:

• les sociétés paieront toujours des primes

• des marges élevées sont maintenant normales

• La demande d'IA ne s'effondrera pas

• les cycles de jeu continuent

• les rafraîchissements technologiques annuels s'accélèrent

L'effondrement des prix ne survient que lorsque:

offre > demande

Nous en sommes loin.

---

10. Une autre pénurie pourrait-elle se reproduire?

Oui, et facilement.

Les principaux déclencheurs de risque :

• conflit à Taiwan

• Intensification de la course aux armements

• interdictions d'exportation

• Manque de HBM

• effondrement logistique

• Nouveau boom minier

• cyberattaque de la chaîne d'approvisionnement

La fragilité des semi-conducteurs reste extrêmement élevée.

---

Conclusion

La pénurie mondiale de GPU n'est pas un désagrément temporaire, elle est le résultat d'un déséquilibre structurel qui a remodelé l'industrie informatique.

Pour la première fois dans l'histoire:

Les GPU sont plus stratégiques que les CPU.

La demande de l'IA, du cloud computing, du jeu et de la simulation industrielle a dépassé la capacité de fabrication mondiale de fournir des processeurs graphiques avancés. Cette pénurie se maintiendra probablement dans la deuxième moitié de la décennie, n'évoluant qu'à mesure que les nouvelles usines de conditionnement et de mémoire mûriront et se stabiliseront à l'échelle mondiale.

La pénurie va-t-elle cesser?

Oui.

Mais pas cette année.

Pas l'année prochaine.

Nous sommes sur une période pluriannuelle – et l'appétit mondial pour l'IA s'accélère.

Jusqu'à ce que la production dépasse finalement la demande, les GPU resteront l'un des actifs les plus précieux et les plus coûteux du monde technologique.

Détails

Écrit par : IT Pro

Catégorie : Blog

Publié le : 22 Novembre 2025

Clics : 5981

Présentation

En 2025, l'augmentation massive des investissements dans des infrastructures de centres de données spécifiques à l'IA est indéniable. Des milliards d'engagements en capital des géants technologiques aux fonds souverains qui soutiennent activement de nouvelles installations, l'économie numérique mondiale s'oriente vers ce que l'on pourrait appeler la course aux armements de calcul de l'AI. Ci-dessous, nous examinons les principales forces qui poussent les entreprises à verser des milliards dans les centres de données de l'IA, les changements architecturaux et opérationnels qui sous-tendent le changement, la façon dont les modèles d'affaires s'adaptent, et les risques et implications futures pour des organisations comme la vôtre (avec un profond intérêt pour les infrastructures, l'analyse comparative, le calcul du déchargement, etc.).

---

L'ampleur de l'investissement

Pour saisir cette dynamique, voici quelques points de données représentatifs :

• Microsoft prévoit environ 80 milliards de dollars américains au cours de l'exercice 2025 pour la construction de centres de données sur l'IA, en particulier aux États-Unis. Reuters

• Le boom mondial de l'investissement dans les centres de données liés à l'IA est estimé dans les billions: un article a noté un boom de 3 billions de dollars dans les centres de données de l'IA en cours. Le gardien

• Selon un examen de 2025 des investisseurs de centres de données, des entreprises telles que Blackstone, Bain Capital et d'autres déployaient activement des capitaux dans des installations à grande échelle et riches en GPU. Partenaires STL

Ces chiffres montrent qu'il ne s'agit pas d'une croissance progressive — c'est un changement stratégique et à grande échelle des infrastructures.

---

Pourquoi maintenant?

1. Explosion de la complexité et de la demande des modèles d'IA

L'essor des grands modèles de langage (LLM), des systèmes génératifs-AI, des charges de travail de simulation et d'autres tâches lourdes de calcul a fondamentalement modifié le profil de demande des centres de données :

• La formation et l'inférence à l'échelle massif Clusters GPU, racks haute densité, réseau avancé et refroidissement.

• Comme le décrit un article : Chaque jeton supplémentaire généré par les algorithmes d'IA dépend de ce calque. Gagner

• Les entreprises passent des charges de travail traditionnellement centrées sur le CPU aux charges accélérées du GPU/ASIC, ce qui entraîne de nouvelles exigences architecturales (densité de puissance, refroidissement, connectivité).

Bref : la demande de calcul augmente à la fois horizontalement (plus de modèles/utilisateurs) et verticalement (plus de modèles, plus de paramètres, plus de données).

2. Avantage concurrentiel et investissements de premier rang

Pour de nombreuses grandes entreprises technologiques et fournisseurs de cloud, la course est plus qu'un simple calcul rentable : il s'agit de construire le fossé de l'infrastructure :

• Les entreprises telles que Microsoft, Amazon AWS, Google Cloud et Meta ne se contentent pas de simplement louer une infrastructure – elles construisent leurs propres installations de prochaine génération pour obtenir des avantages opérationnels, latences, coûts et de contrôle. 174 Puissance mondiale+1

• Pour les entreprises (y compris votre propre contexte de benchmarking, GPU off-load, virtualisation etc), avoir accès à une infrastructure spécialisée donne un différenciateur: itération de modèle plus rapide, inférence de latence plus faible, formation à haut débit.

Par conséquent, les entreprises sont disposées à engager des milliards de dollars maintenant pour verrouiller dans cette valeur future.

3. L ' infrastructure en tant qu ' atout stratégique

Les centres de données ne sont plus seulement des actifs statiques, ils sont une infrastructure stratégique pour l'IA :

• Ils représentent des actifs de longue durée (10+ ans) et sont de plus en plus traités comme des infrastructures industrielles essentielles (énergie, refroidissement, fibres, énergies renouvelables).

• Les investisseurs et les fonds d'infrastructure se déplacent : la liste des investisseurs de centres de données de haut niveau comprend désormais les entreprises d'infrastructure et d'actifs réels qui voient les centres de données comme des plateformes de croissance de base. Partenaires STL

• La nature du calcul d'IA signifie que ce qui compte n'est pas seulement des serveurs plus, mais des serveurs droit au bon endroit (avec une puissance efficace, faible latence, bande passante élevée).

Ainsi, pour les entreprises, construire le bon centre de données AI signifie souvent construire l'avenir de leur entreprise.

4. Économie de l ' énergie, de la localisation et de l ' échelle

Les grands centres de données sur l'IA sont à forte intensité d'énergie, à forte intensité de chaleur, à forte intensité d'espace et bénéficient d'économies d'échelle :

• Un document technique montre comment la colocalisation des centres de données sur l'IA avec la production d'énergie renouvelable et les systèmes intelligents de gestion de l'énergie peut réduire considérablement les coûts et l'impact environnemental. arXiv

• Un autre montre comment les centres de données distribués et avertis du réseau pourraient aider à stabiliser les réseaux tout en absorbant des charges de calcul massives. arXiv

• Emplacement stratégique, accès à l'énergie bon marché/renouvelable, politique de réseau favorable, terrains et permis toute la matière. Les entreprises qui tentent de construire l'IA-centrically prennent en compte non seulement le coût du calcul, mais aussi le coût du calcul + énergie + refroidissement + immobilier + connectivité.

5. Souveraineté, régulation et préoccupations géostratégiques

Calculer les matières non seulement commercialement mais aussi politiquement:

• Une étude récente portant sur 775 centres de données non américains a révélé que le contrôle de l'infrastructure des centres de données (quelle nation, quel opérateur) est de plus en plus un levier de souveraineté numérique. arXiv

• Certains pays essaient explicitement d'attirer des investissements dans les centres de données sur l'IA pour saisir la valeur de l'IA en aval au pays.

• Les entreprises, au-delà de la latence/coûts, pensent au risque : risque réglementaire, contrôle des exportations, contraintes de la chaîne d'approvisionnement, qui poussent toutes à posséder ou à contrôler étroitement les infrastructures.

---

Qu'est-ce que le centre de données prêt à l'AI – principaux changements architecturaux

La construction de centres de données pour les charges de travail en matière d'IA est sensiblement différente de celle des centres de données traditionnels d'entreprise ou d'hébergement en nuage. Quelques-unes des principales différences :

• Puissance volumique: Les racks AI peuvent nécessiter des dizaines de kilowatts (kW) par rack plutôt que quelques-uns. Le refroidissement et la distribution de l'énergie doivent appuyer cette démarche.

• Systèmes de refroidissement: Refroidissement liquide, refroidissement direct à la puce, le refroidissement par immersion devient de plus en plus courant pour les grappes GPU denses.

• Connectivité et latence: Les grandes grappes GPU nécessitent souvent des interconnexions très rapides (NVLink, CXL, PCIe, Ethernet haute vitesse) et des liaisons à faible latence vers les services de stockage, de réseau, de bord.

• Conception modulaire et déploiement rapide: Certains opérateurs plus récents conçoivent des modules GPU-pods ou des data-centers containerisés pour qu'ils puissent déployer rapidement de grandes capacités.

• Infrastructures énergétiques et durables: Parce que l'énergie est coûteuse et de plus en plus examinée, de nombreuses installations co-localisent les énergies renouvelables, utilisent le transfert de charge intelligent, construisent dans des sites à faible consommation d'énergie ou négocient des accords d'électricité à grande échelle.

• Cycle de vie du matériel spécialisé: Contrairement aux serveurs typiques, les grappes AI dépendent des cycles de rafraîchissement GPU/accélérateur (par exemple, tous les ~18-24 mois), ce qui signifie que l'infrastructure doit supporter les mises à niveau, le refroidissement, les charges de puissance à haute densité.

• Stratégie de localisation: proximité avec les centres de recherche modèles d'IA, les sources de données, les paramètres utilisateurs et la connectivité à la matière de configuration cloud/hybride.

Pour quiconque dans votre domaine (analyse comparative de l'AI, utilisation lourde du GPU, virtualisation, etc.), le choix est : l'infrastructure est maintenant un différenciateur primaire, pas seulement un coût.

---

Incidences du modèle d'entreprise — Pourquoi les entreprises investissent

D'un point de vue commercial, la logique d'investir massivement dans l'infrastructure des centres de données de l'IA se retrouve dans plusieurs seaux :

• Permettre de nouvelles sources de revenus

Les entreprises considèrent la transition vers l'IA comme créant de nouveaux secteurs d'activité : formation modèle, inférence en tant que service, conseil en matière d'IA d'entreprise, déploiements de pointe en matière d'IA. Pour les soutenir, vous avez besoin de l'infrastructure. Sans elle, vous risquez de dépendre de tiers.

• Contrôle des coûts et amélioration de la marge

En possédant ou en contrôlant l'infrastructure optimisée pour les charges de travail de l'IA, les entreprises visent à réduire les coûts opérationnels par inférence ou heure de formation. Pour les hyperéchelleurs, l'économie d'échelle peut faire baisser les coûts suffisamment pour permettre de nouveaux services avec des marges attrayantes.

• Avantage stratégique et verrouillage

Les investissements dans l'infrastructure créent des fossés : une fois qu'une organisation possède ou contrôle une importante capacité de calcul de l'IA, il devient plus difficile pour les concurrents de s'aligner. De plus, l'intégration avec le matériel propriétaire, les piles logicielles, le refroidissement personnalisé, etc., augmente les coûts de commutation.

• Soutenir l'innovation interne

Dans votre monde de GPU-offload, analyse comparative de l'IA, virtualisation, développement d'outils : avoir accès à de grandes installations de calcul permet une itération plus rapide, des expériences plus grandes et un avantage concurrentiel interne. C'est un investissement de productivité, pas seulement des infrastructures.

• Infrastructure comme service pour les autres

Certaines entreprises construisent des centres de données AI pour répondre à leurs propres besoins et offrir une capacité à d'autres (par exemple, les start-ups AI, les entreprises SaaS). Ce double modèle permet la monétisation de la capacité excédentaire.

• Couverture et contrôle des risques

Au fur et à mesure que l'IA devient au centre des modèles d'affaires, la dépendance à l'égard des fournisseurs externes ou du cloud peut devenir un goulot d'étranglement ou un risque (latence, souveraineté des données, inflation des coûts). Investir dans les infrastructures est une couverture.

---

Dynamique régionale et industrielle

• Le boom de l'investissement est mondial: Asie-Pacifique, Europe, Moyen-Orient tous à la recherche de campus de calcul AI. Par exemple, la France a annoncé d'importants investissements pour obtenir un retour dans la course avec des campus dédiés AI-supercomputing/data-center. Le Monde.fr

• Les marchés émergents peuvent devenir attrayants en raison d'avantages fonciers, énergétiques ou réglementaires (notamment pour les infrastructures d'IA à forte intensité énergétique).

• Les industries en dehors de la technologie pure sont également impliquées: les services financiers, l'automobile, les soins de santé, la fabrication investissent de plus en plus dans l'infrastructure interne de l'IA et alimentent ainsi la demande de centres de données de l'AI.

---

Principaux défis et risques

Bien que la justification soit solide, ces investissements ne sont pas dépourvus de risques et de complexité importants :

• Haute intensité de capital: Il s'agit d'engagements de plusieurs milliards de dollars à long terme avant remboursement.

• Changements technologiques rapides: Le paysage matériel, de refroidissement, de mise en réseau pour l'IA évolue rapidement ; l'investissement dans l'architecture actuelle peut devenir sous-optimal dans quelques années (par exemple, nouvelle génération de GPU, nouvelle mémoire/architecture, interconnects optiques).

• Pressions énergétiques et de durabilité: Avec le calcul de l'IA, la consommation d'énergie et l'empreinte carbone augmentent. Les organismes de réglementation, les collectivités et les entreprises sont sous pression pour assurer la durabilité. Les documents montrent comment les centres de données à colocalisation renouvelable peuvent aider, mais ils ajoutent aussi de la complexité. arXiv

• Grille et contraintes de puissance: De nombreuses régions ont du mal à fournir la puissance nécessaire ou une connectivité fiable, ou peuvent faire face à des retards en matière d'autorisation/de contrat de puissance.

• Risque géopolitique/réglementaire: L'infrastructure peut faire l'objet de contrôles à l'exportation, de lois sur la souveraineté des données, d'interventions gouvernementales. Des études portant sur des centres de données non américains montrent que les opérateurs ont la nationalité et le contrôle. arXiv

• Incertitude de la demande: Alors que la demande d'IA augmente, la forme exacte, le calendrier et le modèle d'affaires des futures charges de travail sont encore incertains. Il existe un risque de surcapacité ou de gaspillage si la demande évolue différemment.

• Refroidissement/risque thermique: Au fur et à mesure que les densités des racks augmentent, la gestion du refroidissement devient non-triviale (risque de défaillance, atténuation de la chaleur, escalade des coûts).

• Pression sur le rendement des investissements: Les investisseurs (fonds d'infrastructure, REIT, etc.) évaluent ce que sera le modèle de revenu des centres de données AI, au-delà de l'hébergement.

---

Ce que cela signifie (et ce que vous devriez considérer)

Compte tenu de votre intérêt pour l'analyse comparative des GPU, les flux de travail de l'IA, la virtualisation et l'infrastructure, voici quelques implications et considérations pratiques :

Plan pour un accès plus élevé aux ordinateurs

• Si vous développez des suites de benchmarking sur l'IA ou des stratégies de décharge (GPU/CPU/DirectML/ONNX, etc.), anticipez que les grandes organisations auront de plus en plus d'accès interne ou sous-traité aux grappes prêtes à l'IA.

• Si vous comptez uniquement sur le cloud/virtualisation des produits de base, vous pouvez trouver des coûts/performances sous-optimales par rapport aux organisations qui ont des centres de données AI personnalisés.

La stratégie en matière d'infrastructure devrait évoluer

• Considérez où exécuter vos charges de travail : cluster interne vs. tiers vs. hyperscale AI-data-centre.

• Évaluer si vos outils de benchmarking ou de provisioning sont adaptés au nouveau paradigme GPU (p. ex., interconnection à haute bande, refroidissement direct à la puce, rack > 50 kW).

• Pensez à l'évolutivité, le coût de l'énergie, le refroidissement et l'infrastructure électrique dans votre pile (pas seulement calculer).

La durabilité et l'énergie devraient faire partie de la planification

• À mesure que les charges de calcul augmentent, de même que les coûts d'énergie/refroidissement. La construction ou l'utilisation d'une infrastructure d'IA dans des endroits efficaces dotés d'un accès à l'énergie renouvelable peut avoir une incidence importante sur le BCT et le calendrier.

• Si vous comparez les systèmes, incluez des mesures de l'énergie par jeton ou de l'énergie par inférence.

Écosystèmes fournisseurs et matériels

• La chaîne d'approvisionnement des composants (GPU, ASIC, interconnects, mémoire) est de plus en plus liée aux déploiements à grande échelle de datacenters. Cela signifie que l'infrastructure pour laquelle vous êtes en mesure d'évaluer ou de développer évoluera rapidement et peut dépendre de partenariats ou d'échelles.

• L'accès au matériel d'IA next-gen (p. ex. GPUs conçus pour l'échelle de datacenter, ASICs personnalisés, interconnect CXL, refroidissement liquide) peut être un différentiateur.

Stratégie d'atténuation des risques

• Comme les cycles d'investissement sont importants et longs, envisagez la diversification (nuage hybride + on-prem + edge) plutôt que de supposer que tous les calculs migreront vers les centres de données d'AI.

• Surveiller les risques de réglementation et de souveraineté autour de l'emplacement des centres de données ou de leur mode d'exploitation.

• Être conscient des scénarios possibles de surcapacité qui pourraient réduire les marges pour les opérateurs de centres de données (ce qui pourrait avoir une incidence sur la disponibilité, les prix).

Possibilité d'analyse comparative et d'outils

• Votre intérêt pour les suites AI-Benchmark, GPU off-load et virtualisation pourrait s'aligner sur la tendance émergente de l'architecture data-centre d'AI. Il sera possible d'évaluer de nouvelles architectures, de comparer les centres de données dédiés à l'intelligence artificielle et à la modélisation des compromis entre l'énergie, le coût et le débit.

• Envisager de construire des modules ou des outils qui aident les entreprises à évaluer lorsqu'elles construisent leur propre centre de données sur l'IA est logique par rapport à la capacité de leasing des opérateurs hyperéchelle.

---

Regard vers l'avenir: Que regarder

Voici quelques thèmes prospectifs que les entreprises et les benchmarkers (comme vous) devraient surveiller :

• Sauts architecturaux: La prochaine génération de matériel d'IA (p. ex. GPU plus efficaces, accélérateurs personnalisés, copeaux, désagrégation de mémoire) influencera ce que signifie le centre de données d'AI en 2026-2027.

• Centres de données d'IA Edge: Alors que beaucoup d'investissement est pour les campus hyperscales, bord-AI (plus proche des utilisateurs) peut conduire mini-centres de données pour l'inférence de faible latence.

• Innovation en matière d'énergie et de refroidissement: Refroidissement par immersion, refroidissement par liquide, co-implantation renouvelable, planification intelligente de la charge deviendra de plus en plus importante lorsque la puissance deviendra le facteur limitant.

• Centres de calcul souverains et régionaux: Un plus grand nombre de gouvernements peuvent encourager le développement local de centres de données sur l'IA pour des raisons de souveraineté/privacité. Cela pourrait ouvrir de nouveaux marchés et pousser la réglementation.

• Évolution du modèle d'entreprise: Les modèles de calcul en service pour l'IA peuvent se développer : les entreprises achètent des grappes personnalisées pour la formation/l'inférence sur l'IA, plutôt que de louer une capacité de cloud générique.

• Durabilité et empreinte carboneAu fur et à mesure de l'augmentation du calcul de l'IA, l'examen public et réglementaire de l'énergie, des émissions et de la durabilité augmentera.

• Risque de surconstruction: Comme avec n'importe quel boom de l'infrastructure, le risque de trop de racks à la recherche de charges de travail pas encore matures est réel. Le calendrier de la demande par rapport à la capacité sera important.

---

Conclusion

L'afflux d'investissements dans les centres de données de l'IA en 2025 n'est pas simplement une continuation de la croissance du cloud, mais un changement structurel dans la façon dont l'infrastructure informatique est construite, déployée et monétisée. Pour les entreprises, la décision de verser des milliards dans la capacité des centres de données de l'IA est motivée par:

• L'échelle et la vitesse des charges d'IA.

• L'impératif stratégique de posséder l'infrastructure (ou d'avoir un accès préférentiel) qui permet l'IA.

• L'économie d'échelle, l'énergie et les performances qui favorisent les grandes installations spécialisées.

• L'évolution de la notion de data-centers comme des actifs stratégiques et compétitifs plutôt que simplement des fermes de serveurs.

Détails

Écrit par : IT Pro

Catégorie : Blog

Publié le : 19 Novembre 2025

Clics : 6763

Le 18 novembre 2025, une grande partie de l'internet s'est effondrée.
Si vous ouvriez ChatGPT, X (Twitter), League of Legends, Shopify, Coinbase ou d'innombrables sites plus petits, vous étiez accueilli par une page d'erreur 5xx de Cloudflare - ou les sites ne se chargeaient tout simplement pas. Ce qui ressemblait à première vue à un nouveau grand moment de "l'internet est cassé" s'est avéré être quelque chose de plus subtil et, à certains égards, de plus inquiétant : un bug auto-infligé au sein de l'infrastructure même de Cloudflare.

Voici un aperçu détaillé de ce qui s'est passé lors de la panne de Cloudflare d'hier (18 novembre 2025), des raisons de cette panne, des personnes touchées et des leçons que les équipes chargées de l'infrastructure devraient en tirer.

 

---

Que s'est-il réellement passé hier ?

Le mardi 18 novembre 2025, vers la fin de la matinée (UTC), Cloudflare a commencé à renvoyer un grand nombre d'erreurs de serveur HTTP 5xx pour le trafic qui passait par son réseau. Pour les utilisateurs finaux, cela signifiait des pages "Internal Server Error" ou "Gateway Error" lorsqu'ils essayaient d'accéder à de nombreux sites web et applications populaires.

Selon le blog de Cloudflare qui a suivi l'incident, la panne :

• L'impact sur le trafic HTTP des clients a commencé à 11:28 UTC

• Des erreurs 5xx ont été constatées sur l'ensemble des services CDN et de sécurité.

• Des mesures d'atténuation importantes ont été prises entre 13 h 05 et 14 h 30 (UTC).

• Le volume d'erreurs 5xx est revenu à son niveau de base à 17:06 UTC Le blog de Cloudflare

Cloudflare lui-même a décrit cette panne comme la pire depuis 2019, car elle n'a pas seulement affecté une fonctionnalité ou un tableau de bord - elle a perturbé la couche proxy centrale qui achemine la majorité du trafic des clients à travers son réseau. Le blog de Cloudflare

La surveillance par des tiers a étayé ce constat. Cisco ThousandEyes a constaté une panne globale affectant Cloudflare, avec des dépassements de temps et des erreurs 5xx sur des services tels que X, OpenAI (ChatGPT) et Anthropic, alors que les chemins du réseau eux-mêmes semblaient sains. Cela indique clairement qu'il s'agit d'une défaillance d'un service dorsal, et non d'un problème de routage ou de fournisseur d'accès à Internet. Mille yeux

 

---

Qui a été touché ?

Étant donné que Cloudflare se trouve devant une partie importante d'Internet (environ 20 % des sites Web dépendent de Cloudflare pour leurs performances et leur sécurité), le rayon d'action de l'explosion a été énorme. AP News+1

Parmi les services signalés comme touchés :

• ChatGPT / OpenAI

• X (anciennement Twitter)

• Canva, Shopify, Dropbox, Coinbase

• League of Legends et autres plateformes de jeux

• Divers sites de transport public et de gouvernement, dont New Jersey Transit et les systèmes numériques de la SNCF en France AP News+1

Les traqueurs de pannes comme Downdetector ont enregistré des milliers de rapports de problèmes simultanés au plus fort de la panne. Reuters a fait état d'environ 5 000 utilisateurs affectés pour le seul système X à un moment donné, avant que les chiffres ne diminuent au fur et à mesure que les correctifs étaient mis en place. Reuters

Du point de vue de l'utilisateur, cela s'est traduit par

• Les sites ne se chargent pas du tout

• Les flux de connexion se bloquent ou échouent (en particulier lorsque Cloudflare Access ou Turnstile sont impliqués).

• Les API répondent de manière intermittente ou avec des erreurs 5xx

• Tableaux de bord et panneaux d'administration interrompus

En d'autres termes, de vastes parties de l'internet se sont retrouvées en panne, même si la cause profonde était concentrée dans les systèmes internes d'un seul fournisseur d'accès.

 

---

Fonctionnement normal de Cloudflare (en termes simples)

Pour comprendre pourquoi cette panne a été si grave, il est utile de connaître le cheminement approximatif d'une requête à travers le réseau de Cloudflare.

Cloudflare agit comme un proxy inverse CDN et une couche de sécurité:

1. Votre navigateur ou votre application se connecte à Cloudflare au lieu de se connecter directement au site d'origine.

2. Cloudflare termine TLS et HTTP à sa périphérie.

3. Les requêtes sont acheminées vers le système de proxy central de Cloudflare, appelé FL ("Frontline") et sa nouvelle génération FL2.

4. Ce proxy central

   • applique les règles WAF (pare-feu d'application web)

   • Exécute des modèles de gestion des robots

   • gère la protection DDoS, la mise en cache, la sortie vers l'origine

   • Routage du trafic vers d'autres produits internes tels que Workers, R2, Access, etc. Le blog de Cloudflare

En fonctionnement normal, cette architecture est très résiliente : si un centre de données a un problème, le trafic est acheminé par d'autres ; les changements de configuration sont déployés avec précaution ; les fonctionnalités individuelles devraient tomber en panne de manière contenue.

La panne d'hier était précisément mauvaise parce que la défaillance se situait à l'intérieur du chemin de proxy commun lui-même, et qu'elle était étroitement liée à un fichier de configuration qui est poussé dans le monde entier fréquemment et automatiquement.

 

 

---

La cause première : un fichier de gestion des robots qui a été détourné

L'explication officielle de Cloudflare pointe vers un coupable principal :
un fichier de configuration de fonctionnalité utilisé par leur système de gestion des bots. Le blog de Cloudflare

Voici la chaîne des événements en langage clair :

1. Bot Management utilise un "fichier de fonctionnalités"

   • Le modèle de détection des robots de Cloudflare repose sur un ensemble de "caractéristiques", c'est-à-dire des signaux relatifs à chaque demande utilisés pour déterminer s'il s'agit d'un humain ou d'un robot.

   • Ces caractéristiques sont regroupées dans un fichier de configuration qui est régénéré toutes les quelques minutes et déployé à l'échelle mondiale, afin que Cloudflare puisse s'adapter rapidement aux nouveaux schémas d'attaque. Le blog de Cloudflare

2. Un changement dans le comportement des requêtes ClickHouse

   • Le fichier de caractéristiques est généré par des requêtes contre une base de données ClickHouse.

   • Cloudflare a effectué un changement vers 11:05 UTC pour améliorer la sécurité et les permissions pour les requêtes distribuées - permettant aux utilisateurs de voir les métadonnées non seulement à partir d'un schéma par défaut, mais aussi à partir des tables r0 sous-jacentes. Le blog de Cloudflare

   • La requête qui construit la liste des fonctionnalités n'a pas filtré par nom de base de données ; soudainement, elle a commencé à obtenir des colonnes dupliquées à la fois de default et de r0, doublant ainsi le nombre de lignes de fonctionnalités.

3. La taille du fichier d'éléments a explosé

   • Le module Bot Management a une limite stricte sur le nombre d'éléments qu'il accepte (fixée à 200, bien au delà des ~60 normalement utilisés).

   • Lorsque le fichier nouvellement généré a dépassé cette limite, le module a atteint le plafond et a paniqué, à cause d'une erreur non gérée dans le code Rust qui utilisait Result::unwrap() sur une valeur d'erreur. Le blog de Cloudflare

4. Les services proxy de base ont commencé à renvoyer des erreurs 5xx

   • Parce que Bot Management est intégré dans le chemin de proxy principal, la panique est apparue sous forme de réponses HTTP 5xx pour tout trafic dépendant de ce module.

   • Sur le nouveau moteur FL2, les clients ont vu des erreurs 5xx explicites.

   • Sur l'ancien moteur FL, les scores des bots passaient silencieusement à zéro, ce qui pouvait entraîner des faux positifs dans les règles de blocage des bots. Le blog de Cloudflare

5. La partie la plus désagréable : le fichier ne cessait de basculer entre "bon" et "mauvais"

   • Le cluster ClickHouse était progressivement mis à jour, et le fichier de caractéristiques était régénéré toutes les cinq minutes.

   • Parfois, la requête était exécutée sur des nœuds mis à jour (produisant un mauvais fichier), parfois sur des nœuds non mis à jour (produisant un bon fichier).

   • Cela signifie que pendant un certain temps, le réseau de Cloudflare a oscillé entre le fonctionnement normal et la défaillance, au fur et à mesure que les différentes versions du fichier se propageaient. Le blog de Cloudflare

Cette oscillation a rendu la situation extrêmement confuse en interne. Dans un premier temps, les équipes de Cloudflare ont soupçonné une attaque DDoS massive car le schéma d'erreur ne ressemblait pas à une simple panne logicielle. Même la page d'état de Cloudflare, qui est hébergée en dehors de leur propre infrastructure, a brièvement montré des erreurs - une coïncidence qui a alimenté les soupçons d'une attaque externe. Le blog+1de Cloudflare

Ce n'est que lorsqu'ils ont réalisé que le facteur commun était le fichier de caractéristiques du bot que la situation est devenue claire.

 

 

---

Chronologie de l'incident

Sur la base de l'analyse rétrospective de Cloudflare et des rapports de tiers, nous pouvons établir une chronologie approximative de l'incident survenu le 18 novembre 2025 : The Cloudflare Blog+2ThousandEyes+2

• 11:05 UTC - Un changement de contrôle d'accès à la base de données est déployé dans ClickHouse.

• 11:20-11:30 UTC - De mauvaises versions du fichier de fonctionnalité Bot Management commencent à être générées et propagées.

• 11:28 UTC - Premier impact sur les clients : des erreurs HTTP 5xx élevées sont observées sur le trafic des clients.

• 11:30-11:32 UTC - Des outils de surveillance externes et des tests automatisés commencent à détecter des défaillances intermittentes.

• 11:35 UTC - Cloudflare ouvre un appel d'incident interne ; l'enquête commence.

• ~11:48 UTC - Cloudflare publie une mise à jour de statut confirmant un incident. Renvoi

• 11:30-13:05 UTC - Les équipes se concentrent sur ce qui semble être un comportement dégradé de Workers KV et enquêtent sur de multiples causes possibles (y compris des scénarios d'attaque).

• 13:05 UTC - Atténuation clé : Workers KV et Cloudflare Access sont déplacés pour contourner le proxy central ; l'impact est réduit. Le blog de Cloudflare

• 14:30 UTC - La cause première est identifiée ; la génération et la propagation des mauvais fichiers de caractéristiques sont stoppées. Un fichier de configuration connu est inséré manuellement et le proxy central est redémarré. La plupart du trafic revient à la normale. Le blog de Cloudflare

• 14:40-15:30 UTC - Les problèmes de tableau de bord et de connexion persistent alors que le Turnstile et l'accumulation de tentatives d'authentification créent des pics de charge secondaires. Le blog de Cloudflare

• 17:06 UTC - Les taux d'erreur reviennent à la normale ; Cloudflare déclare que les systèmes sont entièrement normaux. Le blog de Cloudflare

Du point de vue de l'utilisateur, la panne a été ressentie comme la plus grave entre la fin de la matinée et le début de l'après-midi (UTC), bien que les fenêtres d'impact exactes varient en fonction de la région et des produits Cloudflare dont dépend chaque service.

---

Pourquoi cette panne est-elle si importante ?

Risque de centralisation

Cloudflare fait partie d'un petit groupe de fournisseurs d'infrastructures internet centrales, aux côtés des principales plateformes de cloud (AWS, Azure, GCP) et d'autres grands CDN. Lorsque l'un de ces acteurs tombe en panne, l'impact est important et souvent peu évident.

Cette panne :

• n'est pas due à un problème de routage BGP ou à une coupure de câble d'un fournisseur d'accès.

• Elle n'est pas due à une attaque malveillante (malgré les soupçons initiaux).

• Elle est due à une configuration unique et aux limites d'un bogue dans un composant interne.

C'est important car cela montre comment des systèmes complexes et étroitement couplés peuvent tomber en panne de manière catastrophique, même en l'absence d'interférences extérieures. Lorsque de nombreuses organisations s'appuient sur le même fournisseur, celui-ci devient de facto un élément important de l'internet sur le plan systémique.

Les dépendances "douces" sont également touchées

Certains des services touchés ne se contentaient pas d'utiliser Cloudflare comme un simple CDN. Ils le faisaient :

• Utilisaient Cloudflare Access pour l'authentification et l'accès de confiance zéro.

• Utilisaient Workers KV dans le cadre de plans de contrôle internes.

• S'appuyer sur Turnstile pour des connexions résistantes aux robots. Le blog de Cloudflare+1

Lorsque ces produits tombent en panne, ce n'est pas seulement le contenu du site Web qui s'effondre, mais aussi les connexions, les fonctions d'administration et les API internes. Cela rend la reprise plus complexe : votre page d'état, votre outil d'incident ou votre interface d'administration peuvent également s'appuyer sur le fournisseur qui vient de tomber en panne.

 

 

---

Ce que Cloudflare dit vouloir changer

Le blog de Cloudflare présente plusieurs mesures correctives que l'entreprise a déjà prises pour réduire le risque qu'une telle situation se reproduise : Le blog de Cloudflare

1. Durcir l'ingestion des fichiers de configuration générés automatiquement
   Traiter les fichiers de configuration générés en interne avec le même scepticisme et la même validation que les données fournies par l'utilisateur, y compris une vérification stricte du schéma et de la taille avant le déploiement.

2. Plus d'interrupteurs globaux
   Faciliter la désactivation rapide des modules internes problématiques (comme Bot Management) à travers le réseau, de sorte qu'ils échouent ouverts au lieu de paniquer l'ensemble du chemin de proxy.

3. Protéger les ressources du système contre les tempêtes d'erreurs
   S'assurer que les dumps du noyau, les métadonnées de débogage et les outils d'observabilité ne peuvent pas submerger le CPU et la mémoire lorsque les erreurs commencent à se multiplier.

4. Examiner les modes de défaillance des principaux modules du proxy
   Auditer systématiquement le comportement de chaque module interne en cas d'entrée ou de configuration inattendue, et assurer une dégradation gracieuse au lieu d'une défaillance globale.

5. Affiner les déploiements et l'isolation
   Bien que l'incident ne soit pas très détaillé, il suggère que Cloudflare va probablement segmenter davantage la façon dont les nouvelles configurations et les comportements DB se propagent, afin de réduire le risque qu'un seul mauvais changement affecte l'ensemble de la flotte.

Cloudflare a également qualifié l'incident d'échec absolu de ses attentes en matière de résilience, le qualifiant d'"inacceptable" et reconnaissant explicitement la douleur qu'il a causée aux clients et aux utilisateurs ordinaires d'Internet. Le blog de Cloudflare

---

Leçons pour les équipes d'infrastructure et de SRE

Même si vous ne gérez pas quelque chose d'aussi énorme que Cloudflare, il y a des leçons très pratiques à tirer de cette panne en matière de conception et d'exploitation :

Traiter la configuration interne comme un intrant non fiable

Il est facile de supposer que "notre propre" configuration générée est toujours correcte. La journée d'hier a montré pourquoi c'est dangereux :

• Toujours valider la taille, la forme et les limites des fichiers de configuration avant de les appliquer.

• Envisager l'application canarienne de la configuration à un petit sous-ensemble de trafic ou de nœuds en premier lieu, avec un retour en arrière automatisé en cas d'anomalie.

• Gardez des limites supérieures strictes et des coupe-circuits autour du nombre de fonctionnalités, de la pré-allocation de mémoire et de l'utilisation de l'unité centrale.

Concevoir pour une défaillance partielle gracieuse

Un bogue dans le module de gestion des robots ne devrait pas être en mesure de paniquer l'ensemble du chemin du proxy:

• Utiliser par défaut fail-open vs fail-closed dans certaines couches de sécurité lorsque l'alternative est une panne complète.

• Construire des interrupteurs d'arrêt clairs et testés pour les fonctionnalités non essentielles.

• S'assurer que les sous-systèmes critiques (authentification, page de statut, outil d'incident) peuvent fonctionner en mode dégradé ou via des routes alternatives.

Observer les bons signaux

L'oscillation entre "bonne configuration" et "mauvaise configuration" toutes les cinq minutes fait ressembler le signal à un trafic d'attaque ou à un comportement externe bruyant :

• Assurez-vous d'avoir une corrélation par version ou par configuration dans votre pipeline d'observabilité.

• Créez des tableaux de bord qui rendent les changements de configuration visuellement évidents au-dessus des graphiques d'erreurs.

• Incluez des tests synthétiques solides à partir d'un point de vue externe, afin que vous puissiez rapidement distinguer les défaillances internes des problèmes de réseau/chemins d'accès.

Ne mettez pas tous vos œufs dans le même panier d'infrastructure

Pour les organisations utilisant Cloudflare :

• Envisagez des configurations multi-CDN pour les propriétés réellement critiques.

• Evitez de rendre votre page de statut entièrement dépendante du même fournisseur que votre pile principale (Cloudflare le fait, mais il y a eu un problème coïncident avec l'hôte de leur page de statut hier, ce qui a rendu les choses encore plus confuses). Le blog de Cloudflare+1

• Pensez-y à deux fois avant de coupler étroitement votre authentification, vos plans de contrôle API et votre livraison frontale au même fournisseur sans chemins de repli.

---

Vue d'ensemble

Rien qu'au cours des derniers mois, nous avons assisté à des pannes majeures chez Microsoft Azure, Amazon Web Services et maintenant Cloudflare, qui ont toutes temporairement mis hors ligne des pans entiers de services destinés aux consommateurs et aux entreprises. AP News+2TheWashington Post+2

Le schéma est clair :

• L'internet dépend de plus en plus d'une poignée de fournisseurs d'infrastructure géants.

• Les pannes sont souvent auto-infligées, dues à des changements internes complexes plutôt qu'à des attaques extérieures.

• Même les fournisseurs dotés de pratiques SRE de classe mondiale peuvent encore être perturbés par des interactions inattendues entre la configuration, le comportement de la base de données et les limites codées en dur.

L'incident survenu hier chez Cloudflare nous rappelle brutalement que le "nuage" n'est pas magique. Au fond, il s'agit toujours d'un logiciel écrit par des humains, sujet aux mêmes catégories de bogues que n'importe quelle autre application, mais avec des ordres de grandeur plus élevés de personnes qui en dépendent.

Les utilisateurs se souviendront surtout de l'incident comme de "ce matin où X et ChatGPT ne se chargeaient pas".
Pour les ingénieurs, il sera probablement étudié comme un exemple classique de la manière dont de subtils bogues de configuration dans un système distribué central peuvent se répercuter sur un événement Internet mondial.