Azure sous perfusion : un ex-ingénieur Microsoft révèle comment le deuxième cloud mondial tourne depuis 2008 grâce à des rustines humaines,
pendant que l'IA achève de vider les équipes de leur substance
Un ancien ingénieur de Microsoft a publié une série de révélations accablantes sur l'état réel d'Azure. Entre fuite massive des talents, décisions architecturales absurdes et pari tout-IA au détriment de l'infrastructure, le numéro deux mondial du cloud vacille sur des fondations que ses propres équipes ne comprennent plus.
Il aura fallu un Substack, six épisodes et la plume d'un ancien cadre technique pour mettre des mots sur ce que beaucoup dans l'industrie murmuraient depuis des années : Azure ne fonctionne pas comme annoncé. Axel Rietschin, ingénieur senior qui a travaillé neuf ans chez Microsoft, dont une année au sein de l'équipe Azure Core Compute et huit ans sur le noyau Windows, a publié fin mars 2026 une série d'articles intitulée How Microsoft Vaporized a Trillion Dollars. Le titre n'est pas une métaphore : la capitalisation boursière de Microsoft a chuté de plus de 30 % depuis son sommet d'octobre 2025, effaçant plus de mille milliards de dollars de valeur de marché.
Rietschin reconte comment Microsoft a précipité le lancement d'Azure en 2008 pour concurrencer Amazon Web Services, sacrifiant la stabilité sur l'autel de la vitesse de mise sur le marché, et ratant ainsi des occasions cruciales de consolider la plateforme tout en laissant les équipes sans soutien suffisant. Ce que le monde voyait comme un cloud robuste et scalable était, selon lui, un système sophistiqué maintenu en permanence sous perfusion artificielle. Cette fragilité fondamentale, enracinée dans des décisions prises à la hâte et dans un optimisme excessif quant à la vitesse à laquelle la plateforme pouvait croître et se stabiliser, a engendré de petites perturbations permanentes qui se sont accumulées au fil du temps.
173 agents, et personne ne sait pourquoi
Le récit de Rietschin commence dès son premier jour, le 1er mai 2023, lorsqu'il rejoint l'équipe Overlake, les ingénieurs derrière la carte d'accélération réseau Azure Boost. Il arrive dans une salle de réunion bondée où l'on débat sérieusement de l'idée de porter une partie de la pile logicielle Windows sur une puce ARM minuscule, sans ventilateur, disposant de ressources infimes. Une organisation de 122 ingénieurs, supervisée par un Principal Group Engineering Manager, envisageait concrètement de porter Windows vers Linux pour faire tourner ses agents de gestion de nœuds.
Plus révélateur encore : personne dans l'organisation Microsoft n'était capable d'expliquer pourquoi jusqu'à 173 agents logiciels tournaient sur chaque nœud Azure, ce qu'ils faisaient tous, comment ils interagissaient, ou même pourquoi ils existaient. Cette accumulation d'agents incontrôlés, véritable dette organisationnelle solidifiée en code, illustre le cœur du problème : des années de recrutement massif, de turn-over élevé et d'absence de documentation ont produit une infrastructure que ses propres gardiens ne comprennent plus. Cette pile non maîtrisée orchestre pourtant les machines virtuelles hébergeant les API de ce qui reste d'OpenAI sur Azure, SharePoint Online, les clouds gouvernementaux et d'autres infrastructures critiques et un grain de sable dans cet empilement fragile peut provoquer un effondrement mondial, avec des implications sérieuses pour la sécurité nationale.
La fuite des cerveaux comme diagnostic central
Pour Rietschin, la cause profonde de toutes ces défaillances n'est pas technique mais humaine. Il estime que le départ massif des talents après le lancement, le manque de discipline en matière de qualité logicielle et de tests, l'absence de vision architecturale et une exécution durablement défaillante ont laissé le service cloud à lutter en permanence contre les incendies. Sa prescription est claire : les dirigeants de Microsoft devraient prioritairement chercher à ramener des leaders techniques expérimentés pour améliorer la formation des développeurs à tous les niveaux, car leur défi le plus significatif a été la dilution des connaissances causée par un taux d'attrition élevé.
Le paradoxe est cruel : au moment précis où Azure aurait besoin de renforcer ses équipes d'infrastructure, Microsoft fait le choix inverse. Microsoft a licencié environ 15 000 personnes entre mai et juillet 2025 et a depuis gelé les recrutements dans son unité cloud et ses équipes commerciales nord-américaines. Azure Core lui-même n'a plus la capacité ni l'autorisation de recruter. Des ingénieurs actuels et anciens décrivent un environnement de travail de plus en plus absorbé par les initiatives d'IA au détriment des services cloud fondamentaux. Les équipes responsables des services Azure de base (calcul, réseau, stockage) ont subi des réductions d'effectifs et des réallocations budgétaires au profit des projets liés à l'IA. Un ancien ingénieur a caractérisé cette dynamique interne comme un système à deux vitesses : les projets d'IA bénéficient d'un soutien quasi illimité, tandis que les équipes d'infrastructure cloud traditionnelles se voient demander de faire plus avec moins.
OpenAI, le signal le plus éloquent
Le vote de défiance le plus visible est venu de là où on ne l'attendait pas : d'OpenAI lui-même, pourtant principal partenaire stratégique de Microsoft dans l'IA. OpenAI a signé un accord de 11,9 milliards de dollars avec CoreWeave en mars 2025 et a désigné Microsoft comme un risque majeur dans son dossier pré-IPO. Rietschin est catégorique : on peut raisonnablement en déduire que Microsoft a échoué à satisfaire les exigences d'OpenAI en temps voulu et à l'échelle requise.
La suite confirme cette lecture. OpenAI a ensuite élargi son accord avec CoreWeave de 6,5 milliards de dollars supplémentaires en septembre 2025 et s'est engagé dans un partenariat de calcul majeur avec Oracle, valorisé à 300 milliards de dollars.
Cette diversification multi-fournisseurs signale qu'il s'agissait d'une décision architecturale délibérée, et non d'une négociation commerciale ordinaire. Pendant ce temps, un rapport de ProPublica a documenté l'insatisfaction du gouvernement américain vis-à-vis des services Azure, et le secrétaire à la Défense Pete Hegseth a publiquement reconnu une « rupture de confiance » avec Microsoft.
La sécurité nationale en question : quand Azure exige des escortes numériques
Les défaillances d'Azure ne se cantonnent pas au monde commercial. Elles ont également atteint les plus hauts niveaux de la chaîne de sécurité américaine, avec des révélations particulièrement embarrassantes sur la gestion des environnements gouvernementaux. Microsoft aurait eu recours à des ingénieurs chinois pour gérer des machines virtuelles Azure destinées au Pentagone, nécessitant la présence de personnels américains habilités comme « escortes numériques » pour superviser l'accès de ces ressortissants étrangers à des infrastructures classifiées, une pratique qui viole directement les contrôles de sécurité du NIST exigeant que seul du personnel habilité accède aux réseaux gouvernementaux.
Cette révélation illustre jusqu'où la dilution des compétences internes a poussé Microsoft : faute d'ingénieurs suffisamment qualifiés et habilités en nombre suffisant, l'entreprise aurait dû s'appuyer sur des prestataires étrangers pour maintenir une infrastructure censée héberger certaines des données les plus sensibles de l'État américain. Le résultat est une absurdité opérationnelle et sécuritaire : des gardes du corps humains pour surveiller des accès informatiques dans un cloud présenté comme souverain.
En été 2025, le secrétaire à la Défense Pete Hegseth a publiquement reconnu une « rupture de confiance » avec Microsoft. Cette formulation, dans un contexte gouvernemental, n'est pas anodine : elle ouvre la voie à une remise en question des contrats fédéraux, dont certains représentent des revenus considérables pour le groupe de Redmond. Les évaluateurs fédéraux en cybersécurité avaient d'ailleurs, selon des sources rapportées par The Register, qualifié Microsoft 365 Government Community Cloud High (GCC High) en des termes peu amènes dès 2024, l'acronyme du service avait même été jugé, cyniquement, comme une description involontaire de sa qualité réelle.
Cette crise de confiance avec Washington arrive au pire moment. Microsoft a investi massivement pour remporter des contrats cloud dans le secteur public américain, face à AWS GovCloud et à Google Cloud for Government. Si les agences fédérales commencent à diversifier leurs fournisseurs après cette série de révélations, c'est une part de marché stratégique et symboliquement cruciale que le groupe risque de ne pas regagner facilement.
GitHub : un effet domino qui s'accélère
Les difficultés d'Azure ont une conséquence concrète et quotidienne pour des millions de développeurs : la dégradation de GitHub. Depuis l'acquisition de la plateforme par Microsoft en 2018, le groupe a entrepris une migration progressive de son infrastructure vers Azure. Or cette migration coïncide avec une aggravation spectaculaire de la fiabilité du service. En 2019, GitHub enregistrait de 1 à 4 incidents par mois. En février 2026, ce chiffre atteignait 37, soit un ordre de grandeur de plus en six ans.
Un suivi non officiel de la disponibilité de GitHub fait état d'un taux de disponibilité global de 90,21 % sur les 90 derniers jours, soit un seul neuf de disponibilité, très loin des trois neuf (99,9 %) garantis contractuellement aux clients Enterprise Cloud. Les incidents de 2026 témoignent d'une fragilité systémique : saturation de bases de données, défaillances Redis, dégradation des opérations Git pendant des heures entières. GitHub a annoncé que 12,5 % de son trafic est désormais acheminé depuis sa région Azure Central US, avec un objectif de 50 % d'ici juillet 2026. Pour certains observateurs, cette dépendance croissante envers un Azure lui-même instable ne fait qu'aggraver la situation.
Un autre facteur aggrave l'équation : l'explosion du trafic généré par les agents de codage IA. Un développeur humain effectue le cycle clone-lecture-commit deux ou trois fois par jour au maximum. Un agent IA peut le faire toutes les quelques minutes. Multiplié par des millions de développeurs utilisant désormais Copilot, Claude Code, Cursor et d'autres assistants, la demande sur l'infrastructure GitHub a atteint des niveaux que personne n'avait anticipés.
L'IA comme accélérateur de crise
Rietschin, dans sa lecture de la situation, refuse de voir dans l'IA une solution aux problèmes qu'elle contribue à amplifier. Pour lui, les grands modèles de langage sont très efficaces pour reproduire des patterns déjà vus dans leurs données d'entraînement, et peuvent aider à détecter des anomalies dans le code. Mais il ne partage pas l'enthousiasme de ceux qui prédisent le remplacement imminent des ingénieurs logiciels par les IA.
L'analyse de Martin Alderson, cofondateur de catchmetrics.io, complète ce tableau : l'IA absorbe d'immenses quantités de calcul pour l'entraînement et l'inférence, mais elle génère aussi des effets de second ordre massifs. Les agents de codage produisant des dizaines de milliers de lignes de code, la demande en calcul pour les pipelines CI/CD s'envole, et ce nouveau code doit être déployé quelque part, ce qui fait exploser la demande en serveurs applicatifs et en bases de données.
La contradiction fondamentale de la stratégie Microsoft est là, exposée en plein jour : l'entreprise réduit ses effectifs d'ingénieurs humains au nom de l'efficacité promise par l'IA, mais c'est précisément cette IA qui génère une charge sans précédent sur une infrastructure déjà fragile, et qui exige davantage de supervision humaine compétente pour rester sous contrôle. Avec de plus en plus de code créé, soumis et exécuté sur des services cloud, nous avons besoin de davantage de personnes pour vérifier le travail et maintenir l'infrastructure en état de marche. Microsoft semble pour l'instant faire exactement l'inverse.
Sources : Axel Rietschin, GitHub
Et vous ?
La dépendance croissante de GitHub à Azure est-elle une stratégie délibérée pour créer du lock-in, ou un pari risqué sur une infrastructure encore instable ?
Le témoignage d'Axel Rietschin confirme-t-il vos propres expériences avec Azure en production et avez-vous déjà envisagé ou effectué une migration vers AWS ou GCP ?
L'IA peut-elle vraiment compenser la perte de connaissances institutionnelles dans des équipes techniques frappées par des vagues de licenciements successives ?
La fuite des clients souverains (gouvernement américain, OpenAI) vers d'autres infrastructures marque-t-elle un tournant irréversible pour Azure, ou s'agit-il d'une correction temporaire ?








La dépendance croissante de GitHub à Azure est-elle une stratégie délibérée pour créer du lock-in, ou un pari risqué sur une infrastructure encore instable ?
Répondre avec citation


à toutes et tous,


Partager