L’incendie déclaré le 7 mai au centre de données de NorthC à Almere a rappelé une vérité que le secteur du cloud évoque souvent en présentations, mais que l’on ne comprend vraiment que lors d’une crise. L’infrastructure numérique brûle aussi, doit être évacuée, devient inaccessible et peut mettre hors service des entreprises, universités, administrations et professionnels qui, jusqu’alors, considéraient la disponibilité de leurs systèmes comme acquise.

Dans ce contexte, le témoignage public de Jeroen Derks, spécialiste en PHP et Laravel, a donné un nom à une partie moins visible de la réponse technique. Après l’incendie, Derks a expliqué sur LinkedIn que son serveur géré par Stackscale était à nouveau opérationnel dans un autre emplacement “en un temps record”. Pendant qu’il s’inquiétait de la perte d’accès à ses e-mails, l’équipe d’ingénierie et de support travaillait en coulisses pour rétablir le service. Sa conclusion, aussi simple que parlante : « Turns out, Stackscale is fireproof. »

Un incendie qui a rappelé la dimension physique du cloud

Le feu s’est déclaré le jeudi 7 mai 2026 dans les installations de NorthC Datacenters à Rondebeltweg, dans la zone industrielle de Sallandsekant, Almere Stad. L’incendie a commencé vers 08h45 et toutes les personnes présentes ont été évacuées à temps. Les autorités ont activé une alerte NL-Alert pour la population voisine en raison de la fumée. Le niveau GRIP 1, un niveau de coordination des urgences utilisé aux Pays-Bas, a été déclenché.

Ce sinistre n’était pas anodin. Des médias néerlandais et internationaux ont relayé des perturbations dans des services numériques liés à des organismes publics, éducatifs et commerciaux. L’Université d’Utrecht a signalé des problèmes dans son réseau, ses applications et ses sites web, affectant le travail quotidien, la recherche et l’enseignement. D’autres sources ont évoqué des effets sur les transports en commun, les cliniques et des organismes administratifs.

Ce scénario a mis en évidence une réalité souvent éludée : le cloud, l’hébergement et les plateformes numériques dépendent de bâtiments spécifiques, de systèmes électriques et de salles techniques qui, aussi redondants soient-ils, peuvent devenir inaccessibles pendant des heures ou des jours. Le “nuage” ne flotte pas dans l’air. Il réside dans des centres de données exposés à des risques physiques : incendies, coupures électriques, inondations, ruptures de fibres, problèmes de refroidissement. La question n’est pas si cela arrivera, mais quand. Et également de savoir si les centres se construisent dans les bons endroits — une dynamique analysée dans notre article sur comment l’IA pousse les centres de données vers les zones rurales, loin des concentrations urbaines à risque.

Techzine a indiqué que la restauration complète du centre pourrait prendre jusqu’à 72 heures. Pour toute entreprise concernée, cette durée peut être acceptable si un plan de reprise d’activité testé existe ; elle devient critique si tout dépend d’un seul site.

La restauration d’un serveur ne se limite pas à rallumer une machine

Le cas de Jeroen Derks est concret et utile parce qu’il ramone le débat à la réalité opérationnelle. La continuité d’activité ne se résume pas à posséder une sauvegarde. Il faut connaître l’emplacement des données, leur intégrité, le temps de restauration, les dépendances du service, les changements DNS à appliquer, la gestion des pertes de données et la communication avec les clients.

Récupérer un serveur dans une autre localisation après un incident en centre de données nécessite une coordination technique et opérationnelle : évaluer l’état du service affecté, identifier les sauvegardes ou répliques, provisionner une capacité alternative, reconstruire les machines, valider les systèmes, vérifier la connectivité, les bases de données, les certificats, le pare-feu et la surveillance. Parfois sans accès immédiat au site d’origine.

C’est ce qui différencie un hébergeur qui fournit uniquement de l’infrastructure d’un fournisseur gérant activement la continuité. La réponse ne dépend pas uniquement du matériel disponible, mais aussi des processus, des compétences humaines, de la documentation, de l’automatisation et de l’expérience accumulée. Le témoignage de Derks a une valeur particulière parce qu’il ne provient pas d’une communication institutionnelle, mais de l’expérience concrète d’un client qui a vu son service rétabli ailleurs. Dans ces moments-là, la confiance se construit par les actes, pas les promesses.

La résilience se planifie avant la crise

L’incendie chez NorthC enseigne une vérité simple : la résilience ne s’improvise pas lors d’un incident. Elle se planifie en amont et se teste avant qu’un problème n’arrive.

Beaucoup d’entreprises pensent être “résilientes” parce qu’elles font des sauvegardes. C’est une étape, insuffisante seule. Une sauvegarde jamais restaurée n’est qu’un espoir, pas une sécurité. Un plan de reprise sans responsabilités claires, échéances et essais réguliers peut échouer exactement au mauvais moment. Concentrer toute l’architecture critique sur un seul centre de données transforme un incident physique en risque d’activité réel.

La stratégie appropriée dépend du type de charge. Tous les services ne nécessitent pas une haute disponibilité active-active sur plusieurs sites. Mais tous doivent définir précisément leurs RPO (volume de données pouvant être perdu) et RTO (délai maximal d’indisponibilité). Un e-mail professionnel, une boutique en ligne, un ERP ou un site institutionnel n’ont pas tous la même criticité. Mais chacun doit répondre concrètement à ces questions : où sont les données, que faire si le centre principal devient inaccessible, qui intervient pour la restauration, combien de temps cela prend et quand le plan a-t-il été testé pour la dernière fois.

Le cas d’Almere illustre aussi l’importance de la diversification géographique. En Europe, beaucoup d’entreprises optent pour la colocation en pensant à la latence ou aux certifications, sans concevoir une architecture capable de supporter une panne physique. Avoir plusieurs centres de données, des réseaux redondants et des copies séparées géographiquement est un investissement, pas un luxe, pour maintenir une activité critique stable. Et cette dimension de gouvernance de l’infrastructure à plusieurs sites est exactement ce qu’adressent des offres comme le cloud IA gouverné de Rackspace et AMD pour les secteurs réglementés.

Leçons pour fournisseurs et clients

Pour les fournisseurs d’infrastructure, des incidents comme celui d’Almere invitent à revoir les plans d’urgence, la stratégie de communication, la gestion des accès, la relation client et la capacité à assurer une récupération croisée. La transparence est essentielle : dans une crise, les clients ont besoin d’informations régulières et claires, même si toutes les réponses ne sont pas encore disponibles.

Pour les clients, la vigilance est tout aussi nécessaire. La continuité ne peut pas se résumer à déléguer à un fournisseur. Il faut comprendre sa propre architecture, exiger des tests réguliers, documenter les dépendances et ne pas laisser le seul prix déterminer le choix de la résilience.

L’expérience de Stackscale avec le serveur de Jeroen Derks montre que, avec une organisation adaptée, plusieurs sites et une équipe compétente, il est possible de limiter l’impact même en situation critique. Elle rappelle aussi la valeur des équipes humaines qui, derrière le cloud, prennent des décisions, coordonnent et agissent vite. L’automatisation aide, mais elle ne remplace pas l’expertise humaine au moment crucial. Ce sinistre à Almere ne sera pas le dernier incident physique affectant un centre de données en Europe. La dépendance numérique va continuer de croître. La question n’est pas si un problème surviendra, mais si l’architecture sera prête quand il arrivera.

Questions fréquentes

Que s’est-il passé au centre de données NorthC à Almere ?

Le 7 mai 2026, un incendie s’est déclaré dans les installations de NorthC Datacenters à Rondebeltweg, Almere. Le bâtiment a été évacué et les autorités ont déclenché une alerte NL-Alert. La restauration complète a été estimée à 72 heures.

Quel lien avec Stackscale ?

Un client de Stackscale, Jeroen Derks, a expliqué publiquement que son serveur était à nouveau opérationnel ailleurs après l’incendie, en saluant la réponse rapide de l’équipe technique et de support de Stackscale.

Quelle différence entre sauvegarde et continuité d’activité ?

La sauvegarde consiste à copier des données. La continuité inclut aussi la restauration, une infrastructure de secours opérationnelle, la gestion des réseaux et dépendances, la communication et des tests réguliers avant qu’un incident ne survienne.

Que doit vérifier une entreprise après un tel incident ?

Il faut examiner ses RPO et RTO, la localisation et l’intégrité des sauvegardes, leur dernière restauration testée, la dépendance à un site unique, le plan de communication client et le niveau de disponibilité garanti par contrat.