Un premier « code rouge » national. Pour nous, un non-événement — parce que nous étions prêts.

Un identifiant auquel vous ne pouvez pas accéder est un identifiant que vous n'avez pas. Pour un coffre à identifiants, rester disponible — à chaque instant, depuis n'importe où — n'est pas une fonctionnalité ; c'est toute la mission.

Cette semaine, les Pays-Bas ont déclaré pour la première fois de leur histoire un « code rouge » national pour la chaleur extrême — un épisode à 40 °C que le pays n'avait pas connu depuis le début de ses relevés en 1901 [1][2]. D'ici vendredi, la chaleur avait grimpé jusqu'à la couche que presque personne ne considère tant qu'elle ne tombe pas en panne : le centre de données. Notre fournisseur à Amsterdam, Leaseweb, a fait exactement ce qu'il fallait et nous a prévenus tôt — l'installation chauffait, elle avait commencé à mettre hors tension une partie de sa propre infrastructure pour évacuer la chaleur, et la machine que nous y conservons pouvait être la suivante. Nous l'avons vérifiée : en bonne santé, servant normalement. Puis nous sommes retournés au travail. Non parce que nous étions certains qu'Amsterdam tiendrait — parce que ce n'est pas nécessaire.

Un centre de données chaud à Amsterdam n'a pas le droit de devenir notre problème

La machine à Amsterdam est l'un des deux points d'ancrage de notre système de gestion — le cerveau en coulisses qui exécute et coordonne notre parc. Et avant toute autre chose, le point essentiel, en langage clair : il ne s'agit pas du coffre qui conserve et sert vos identifiants. Ceux-ci tournent sur un plan entièrement séparé et indépendant — un système mondial différent — que cette chaleur n'a jamais approché. Le cerveau de gestion et les coffres auxquels vos agents parlent réellement sont deux mondes différents : une mauvaise journée pour l'un n'est tout simplement pas une mauvaise journée pour l'autre. Nous appliquons simplement à ce cerveau de gestion la même exigence qu'à tout le reste — jamais de point unique. Il y a donc deux points d'ancrage, par choix — l'un à Amsterdam (Leaseweb), l'autre à Osaka (Ablenet). Deux continents. Deux fournisseurs. Deux réseaux électriques. Deux climats. Un après-midi à 40 °C aux Pays-Bas n'a aucune incidence physique sur une machine au Japon : météo différente, réseau différent, domaine de panne entièrement différent. (Détail amusant : alors qu'Amsterdam atteignait 40 °C sous un code rouge national, Osaka était à environ 29 °C en pleine saison des pluies — onze degrés de moins, à l'autre bout du monde, sur un système météo totalement indépendant. Cet écart est la conception.) Les deux points d'ancrage restent continuellement synchronisés, de sorte qu'aucun n'est jamais très en retard sur l'autre. Si une canicule, une panne de réseau électrique ou un incident chez un fournisseur mettait Amsterdam hors ligne, le pire cas est un basculement court et borné vers l'autre côté de la planète — pas une interruption de service.

La résilience n'est pas une fonctionnalité d'un coffre à identifiants. C'est le produit.

Un coffre à identifiants est l'élément le plus porteur d'une pile : chaque application, chaque chaîne de traitement et chaque agent s'y authentifie. Quand il répond, tout fonctionne ; quand il ne le peut pas, tout s'arrête d'un coup. Cette asymétrie explique pourquoi la résilience n'est pas quelque chose que l'on ajoute après coup. Vous ne voulez pas découvrir, le jour le plus chaud d'un siècle, si votre unique centre de données, dans votre unique ville, sur votre unique réseau, supporte la chaleur. Vous le décidez un jour de fraîcheur, en refusant de parier l'entreprise sur un seul climat. Nous avons tranché cela depuis longtemps : aucune région, aucun fournisseur, aucun réseau électrique ni aucun système météo n'a jamais le droit de constituer à lui seul toute l'histoire.

La version honnête

Rien ne rend une infrastructure invulnérable. La météo tombe en panne, les réseaux tombent en panne, les fournisseurs tombent en panne — et quiconque vous affirme le contraire vous vend quelque chose. Ce que vous choisissez réellement, c'est que la défaillance de l'un d'entre eux puisse ou non vous emporter avec elle. Nous avons choisi deux hémisphères pour que la réponse soit non. Cette semaine a mis ce choix à l'épreuve de la façon la plus littérale qui soit, et le test a été ennuyeux : Amsterdam a continué de servir pendant la chaleur, et même si elle ne l'avait pas fait, la conception avait déjà la réponse, en attente à Osaka.

Concevoir pour la catastrophe le jour où elle n'a pas lieu

Telle est toute la discipline. Le jour frais est celui où l'on conçoit pour le jour chaud ; le jour chaud est celui où l'on est discrètement content de l'avoir fait. Cette semaine a été un jour chaud — un jour de record — et pour nous ce fut un non-événement. C'est exactement ce que cela doit être.

Le mérite revient à qui de droit : Leaseweb a géré la chaleur comme le font les bons opérateurs — alerte précoce, action de protection, aucun drame. Les meilleurs fournisseurs vous préviennent avant qu'il n'y ait de problème. Notre travail est simplement de faire en sorte que, lorsqu'un site a une mauvaise journée, il n'ait jamais été le seul site.

Clavitor (@clavitorai) est le coffre à identifiants conçu pour les agents d'IA, et contre eux. clavitor.ai

Sources

[1] NL Times — Canicule aux Pays-Bas désormais officielle ; alerte historique « code rouge » pour la chaleur (premier « code rouge » national pour la chaleur extrême ; la plus longue canicule de juin depuis le début des relevés en 1901) : https://nltimes.nl/2026/06/25/dutch-heatwave-now-official-historic-code-red-hot-weather-alert-debated

[2] DutchReview — Les températures aux Pays-Bas devraient atteindre jusqu'à 40 degrés (pics de température à l'intérieur des terres approchant les 40 °C) : https://dutchreview.com/news/netherlands-up-to-40-degrees-then-plummet-to-21-degrees-25062026/