L’évolutivité du cloud n’est pas infinie, elle repose sur des limites physiques
Abordons une vérité sur l’informatique Cloud que trop peu de gens veulent dire à voix haute : elle n’est pas extensible à l’infini. Ce n’est pas possible. Même les plateformes de cloud à grande échelle comme Microsoft Azure, AWS et Google Cloud reposent toujours sur du matériel physique. Ce matériel se trouve dans des centres de données situés dans des endroits spécifiques. Une fois que ces racks sont pleins, la mise à l’échelle s’arrête. Il n’y a plus de machines. Plus de calcul.
C’est ce qui est apparu clairement lors de l’interruption d’Azure dans la région Est des États-Unis, le 29 juillet 2025. Une forte augmentation de la demande a submergé le système. Trop de demandes de machines virtuelles. Pas assez de capacité. Microsoft a résolu le problème le 5 août, mais à ce moment-là, l’impact s’était déjà propagé dans les entreprises, les opérations étaient bloquées, les services retardés, les clients frustrés.
Il ne s’agissait pas d’un problème de code ou d’une cyberattaque. Il s’agissait d’une défaillance logistique due à des contraintes matérielles réelles. Très probablement, une combinaison de délais de fin de vie pour Kubernetes 1.30 et de mises à niveau massives a poussé la demande au-delà des limites pratiques. Les entreprises qui pensaient qu’Azure serait toujours « simplement évolutif » ont été prises au dépourvu, car à ce moment-là, ce n’était pas possible.
C’est là le point essentiel. L’évolutivité semble automatique, mais il y a des limites à l’infrastructure derrière l’interface du cloud. Une infrastructure que nous ne voyons pas… jusqu’à ce qu’elle tombe en panne. Les dirigeants avisés cesseront de penser qu’élastique signifie infini. Construisez votre stratégie autour de la réalité physique : les systèmes cloud peuvent évoluer, mais seulement dans la limite de ce qui est déjà installé et disponible.
Les accords de niveau de service standard ne couvrent pas ce qui fait vraiment mal, à savoir la capacité disponible.
Parlons maintenant des contrats, et plus précisément des accords de niveau de service (SLA) que vous avez conclus avec vos fournisseurs de cloud. Les accords de niveau de service donnent un sentiment de certitude : objectifs de temps de fonctionnement, temps de latence minimum, promesses de temps de réponse. Mais le problème est là. La plupart d’entre eux ne disent rien sur la capacité. Ils ne garantissent pas que si vous avez besoin de plus d’espace de calcul, vous l’obtiendrez.
Ce fut un problème majeur lors de l’interruption d’Azure East US. Les entreprises ont vu leurs demandes rejetées, non pas parce que les serveurs tombaient en panne, mais parce qu’il n’y en avait pas de disponibles. Pourtant, les accords de niveau de service ne couvraient pas ce mode de défaillance. Il n’y avait pas de termes définis pour l’incapacité à faire évoluer les ressources. Aucune mention n’était faite des écarts de disponibilité géographique. Les entreprises n’avaient donc aucun moyen de pression contractuel et aucun moyen d’être remboursées.
La solution est simple à esquisser, mais difficile à mettre en œuvre : exigez de meilleurs accords de niveau de service. La couverture doit aller au-delà du simple temps de fonctionnement. Vos accords doivent prévoir des seuils de capacité maximale et minimale, des protocoles de repli si une classe de ressources est épuisée et des modèles de compensation si les engagements ne sont pas respectés, qu’il s’agisse d’une compensation financière ou de crédits de service. Sans ces clauses, vous vous exposez à des risques importants.
Les dirigeants de la suite devraient insister pour que ces accords soient conclus dès maintenant, et non après la prochaine panne. Le cloud n’est plus seulement une infrastructure. C’est la continuité de l’activité, l’expérience client et l’avantage concurrentiel. Si votre accord de niveau de service ne protège pas ces éléments, il ne fait pas son travail. Soyez précis. Soyez direct. Mettez-le par écrit.
Une visibilité limitée du cloud crée des angles morts opérationnels
L’un des plus grands risques de l’informatique d’entreprise aujourd’hui se résume à ceci : vous ne savez pas ce que vous ne pouvez pas voir. Les plateformes cloud vous donnent des tableaux de bord et des mesures de performance, certes. Mais lorsqu’il s’agit des limites de capacité, de la disponibilité réelle des ressources informatiques, la visibilité est limitée. Et lorsque ces données sont cachées, votre capacité à agir rapidement s’effondre.
Prenez l’exemple de la panne de capacité d’Azure East US en juillet 2025. Certaines entreprises n’ont appris l’existence de cette pénurie qu’après qu’elle ait commencé à avoir un impact sur les charges de travail de production. Microsoft a ensuite recommandé de changer de type d’instance ou de déplacer les charges de travail vers une région voisine. Mais à ce moment-là, les opérations étaient déjà perturbées. L’accès à des informations plus claires et plus précoces aurait pu changer la donne. Il ne s’agissait pas de défaillances techniques, mais d’un manque de visibilité.
C’est un domaine dans lequel les dirigeants doivent intervenir. La télémétrie ne doit pas être un simple outil DevOps. Vous avez besoin de transparence au niveau de la plateforme, de tendances globales de l’offre et de la demande, d’alertes sur l’utilisation au niveau régional et de contraintes prévues en temps réel. Ce n’est pas négociable. Vous n’évoluez pas de manière réactive au niveau de l’entreprise. Vous évoluez sur la base de prévisions intelligentes étayées par des données d’utilisation réelles.
Sans cette clarté, vous devez constamment réagir après coup, et chaque retard représente un risque : mécontentement des clients, pertes de transactions, échecs publics. Ce type d’exposition n’est pas acceptable. Poussez vos fournisseurs de cloud à partager davantage. Intégrez la visibilité dans votre cadre d’accords de niveau de service. Si la plateforme est informée d’un manque de capacité, vous devez l’être aussi, avant que vos systèmes ne tombent en panne.
La résilience exige une stratégie hybride et multicloud
S’appuyer sur un seul fournisseur de cloud fonctionne, jusqu’à ce que ce ne soit plus le cas. Lorsque la capacité d’Azure East US a été épuisée en juillet 2025, les entreprises exclusivement liées à cette région n’avaient aucun moyen de déplacer leurs charges de travail. Résultat ? Des temps d’arrêt et des pertes financières. Cela ne devrait pas être acceptable au niveau de l’entreprise.
Il est judicieux de répartir les risques. Les architectures de cloud hybride et de multicloud n’ont pas pour but de suivre les tendances, mais d’assurer la stabilité de l’entreprise. Vous n’avez pas besoin de répliquer entièrement les environnements entre les plateformes. Mais vous avez besoin d’options. Conservez les charges de travail de base dans votre propre infrastructure. Conservez une architecture déployable sur au moins un autre fournisseur de cloud. Conservez suffisamment de flexibilité dans l’ingénierie de votre plateforme pour pouvoir évoluer latéralement, et pas seulement verticalement, au sein d’une même plateforme.
Cela rendra-t-il votre architecture cloud plus complexe ? Oui. Mais la complexité n’est pas l’ennemi, c’est la fragilité qui l’est. Votre environnement informatique doit absorber les chocs. Et le fait que des régions ou des fournisseurs de cloud soient mis hors ligne, même temporairement, est un choc que vous devez prévoir. À mesure que les contraintes de capacité deviennent plus fréquentes, en particulier lors des mises à niveau de versions ou des expansions régionales, les stratégies distribuées cessent d’être optionnelles. Elles deviennent la norme.
Les dirigeants doivent bien comprendre ceci : la concentration sur un seul fournisseur ne se justifie que si votre modèle de risque est conçu pour des scénarios d’échec. Si ce n’est pas le cas, vous devez repenser cette approche. Toutes les équipes n’ont pas besoin d’une capacité multicloud complète. Mais chaque entreprise a besoin d’un plan de basculement qui fonctionne dans la pratique, et pas seulement sur le papier.
Pour rétablir la confiance dans l’évolutivité du cloud, il faut de la transparence et une responsabilité partagée.
La promesse du cloud public a toujours été la rapidité, l’échelle et la simplicité. Mais la confiance dans cette promesse s’érode lorsque les plateformes tombent en panne sans avertissement et sans responsabilité. L’incident d’Azure East US en juillet 2025 n’était pas seulement un manque de capacité. Il a mis en évidence un fossé plus profond entre les attentes et la réalité. Ce fossé ne se comblera pas tant que les fournisseurs de cloud ne modifieront pas leur mode de communication et ne s’engageront pas sur la voie de la transparence.
Si vous êtes un chef d’entreprise dépendant de plateformes hyperscale pour des opérations critiques, vous ne devriez pas être dans l’ignorance des ressources disponibles. Vous ne devez pas attendre la cascade d’erreurs pour découvrir que vos charges de travail ne peuvent pas évoluer parce que la capacité n’est pas là. Et vous ne devriez pas avoir à accepter de vagues avis émis après que l’impact se soit déjà produit.
Les fournisseurs de clouds doivent passer de mises à jour réactives à une communication proactive des capacités. Cela inclut des rapports en temps réel sur les contraintes de l’infrastructure, ainsi que des informations prospectives sur les tendances régionales en matière de disponibilité. Il ne s’agit pas d’options supplémentaires, mais de responsabilités essentielles dans le cadre d’un service d’entreprise.
Mais les clients ont également un rôle à jouer. Trop souvent, les responsables informatiques partent du principe que le cloud s’adaptera simplement sous la pression. Comme nous l’avons vu, cette hypothèse ne tient pas la route. Les entreprises doivent jouer un rôle plus actif, exiger des engagements de capacité spécifiques dans les accords de niveau de service, investir dans la surveillance de la capacité et tester l’évolutivité en fonction de la charge pendant les opérations normales, et pas seulement pendant les crises.
Il s’agit d’une question de maturité. Les services cloud ont largement dépassé le stade de simples outils. Ils soutiennent désormais des industries entières, des infrastructures nationales et des systèmes de santé. Avec une telle responsabilité, il n’y a pas de place pour des relations unilatérales. L’évolutivité du cloud n’est ni automatique ni infinie. Il s’agit d’un résultat partagé qui dépend d’une communication ouverte, de contrats clairs et d’une gouvernance responsable.
Si les fournisseurs de solutions hyperscale veulent conserver la confiance des entreprises, ils doivent être visibles quand c’est important et responsables quand ça l’est. Les dirigeants ne doivent rien exiger de moins, et le faire respecter si nécessaire.
Principaux enseignements pour les dirigeants
- L’évolutivité du cloud est limitée par l’infrastructure physique : Les dirigeants doivent cesser de croire que les plateformes cloud s’adaptent automatiquement aux pics de demande. La capacité est limitée par les limites physiques des centres de données, ce qui fait des interruptions opérationnelles dues à l’épuisement des ressources un risque réel.
- Les accords de niveau de service ne protègent souvent pas contre les défaillances d’évolutivité : Les dirigeants doivent faire pression pour que les accords de niveau de service soient renforcés et incluent explicitement la disponibilité de la capacité, la redondance et des conditions de compensation exécutoires. Sans ces clauses, les entreprises sont exposées lorsque les garanties d’évolutivité ne sont pas respectées.
- Une visibilité limitée de la capacité crée des risques évitables : Les fournisseurs de cloud offrent rarement un aperçu en temps réel de la disponibilité des ressources. Les décideurs devraient exiger une télémétrie transparente pour permettre des réponses proactives avant que les pannes ne s’aggravent.
- Les stratégies multi-nuages et hybrides réduisent l’exposition : La dépendance à l’égard d’un seul fournisseur accroît la vulnérabilité en cas de panne régionale ou de pénurie de capacité. Les dirigeants devraient adopter des configurations hybrides ou multiclouds pour maintenir la résilience et la continuité opérationnelle.
- La confiance dans l’évolutivité du cloud dépend du partage des responsabilités : Les fournisseurs doivent accroître la transparence et rendre des comptes en cas de défaillance de la capacité. Les chefs d’entreprise doivent considérer la planification de l’évolutivité comme une fonction commune et intégrer le contrôle de la capacité dans la gouvernance.