L’Incendie déclaré le 7 mai au centre de données de NorthC à Almere a laissé une de ces leçons que le secteur du cloud évoque souvent en présentations, mais que l’on ne comprend vraiment que lorsque survient 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, présumaient de la disponibilité de leurs systèmes.

Dans ce contexte, le témoin 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 de nouveau opérationnel dans un autre emplacement « en un temps record ». Alors 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.

Son message, avec une phrase aussi simple que puissante : « Turns out, Stackscale is fireproof », résume quelque chose que tout fournisseur d’infrastructure devrait pouvoir démontrer : la continuité d’activité ne se mesure pas uniquement en brochures commerciales, mais par la capacité à réagir lorsqu’un site physique tombe en panne.

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. NorthC a indiqué que l’incendie a commencé vers 08h45 et que 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, et la situation a été initialement portée au niveau GRIP 1, un niveau de coordination des urgences utilisé aux Pays-Bas.

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

Ce scénario a mis en évidence une réalité inconfortable : le cloud, l’hébergement, la connectivité et les plateformes numériques dépendent de bâtiments spécifiques, de systèmes électriques définis, de salles techniques et d’équipements qui, aussi redondants soient-ils, peuvent devenir inaccessibles pendant des heures ou des jours. La « nuage » ne flotte pas dans l’air. Il réside dans des centres de données confrontés à des risques physiques, allant des incendies aux coupures électriques, inondations, coupures de fibres ou problèmes de refroidissement.

Dans le cas d’Almere, Techzine a signalé que la restauration complète du centre pourrait prendre jusqu’à 72 heures, tandis que NorthC poursuivait les inspections, la gestion des dommages et la communication avec ses clients. Pour toute entreprise concernée, cette durée peut être acceptable si un plan de reprise d’activité testé existe ; elle peut devenir critique si tout dépend d’un seul site.

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

Le cas évoqué par Jeroen Derks est pertinent parce qu’il ramène le débat à la réalité concrète. La continuité d’activité ne consiste pas simplement à posséder une sauvegarde. Il faut connaître l’emplacement des données, leur intégrité, le temps nécessaire à leur restauration, les dépendances du service, les changements DNS, les réseaux à rétablir, 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. Il faut é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é, le courrier, les bases de données, les certificats, le pare-feu, le stockage et la surveillance. Parfois, cela implique de travailler sans accès immédiat au site d’origine.

C’est ici qu’un fournisseur qui se contente d’héberger de l’infrastructure diffère de celui qui pratique une gestion axée sur 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. La présence en plusieurs sites et la capacité à déplacer rapidement les charges en cas de sinistre sont aussi cruciales.

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 ayant connu une interruption réelle et constaté que son service était rétabli dans un autre lieu. En pareil contexte, la confiance ne se construit pas par des promesses, mais par des actions efficaces.

La résilience doit être conçue en amont, avant la crise

Le feu chez NorthC à Almere enseigne une vérité essentielle à toute organisation dépendant de l’infrastructure numérique : la résilience ne s’improvise pas lors d’un incident. Elle se planifie en amont. Et se teste avant qu’un problème ne survienne.

Beaucoup d’entreprises pensent être « résilientes » parce qu’elles font des sauvegardes. C’est une étape, mais insuffisante. 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 au pire moment. Concentrer toute l’architecture critique sur un seul centre de données transforme un incident physique en un vrai risque pour l’activité.

La stratégie adaptée dépend du type de charge. Tous les services ne nécessitent pas une haute disponibilité active-active sur plusieurs sites, ni une réplication synchrone ou un clustering géographique complexes. Toutefois, tous doivent définir précisément leurs RPO et RTO : le volume de données pouvant être perdu et le délai maximal d’indisponibilité.

Un e-mail professionnel, une boutique en ligne, une plateforme SaaS, un ERP, une base de données clients ou un site institutionnel n’ont pas tous la même criticité. Mais il est essentiel d’y répondre de façon concrète : où sont situés les données, que faire si le centre principal devient inaccessible, qui intervient pour la restauration, combien de temps cela prend, comment informer les utilisateurs, et la dernière fois que cela a été testé.

Le cas d’Almere illustre aussi l’importance de la diversification géographique. En Europe, nombre d’entreprises optent pour le cloud ou la colocation en pensant à la latence, aux coûts ou aux certifications, mais ne conçoivent pas toujours une architecture capable de supporter une panne physique. Disposer de plusieurs centres de données, de réseaux redondants et de copies séparées géographiquement est un investissement crucial pour maintenir une activité critique stable.

Leçons pour fournisseurs et clients

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

De leur côté, les clients doivent être vigilants. La continuité ne doit pas se limiter à déléguer à un fournisseur. Il faut comprendre sa propre architecture, exiger des tests réguliers, consulter les sauvegardes, documenter les dépendances, et ne pas laisser le prix seul déterminer le choix de la résilience. La haute disponibilité doit être conçue, contractée et maintenue activement.

L’expérience de Stackscale avec le serveur de Jeroen Derks illustre une facette positive des crises : avec une organisation adaptée, plusieurs sites et une équipe compétente, il est possible de limiter l’impact et de rétablir rapidement les services, même en situation critique. Elle met aussi en lumière la valeur des équipes humaines qui, derrière le cloud, prennent des décisions, coordonnent, communiquent et agissent rapidement. L’automatisation est un atout, 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 à croître, tout comme l’exposition à des risques qui, jusqu’à présent, semblaient improbables. La question pour entreprises et fournisseurs n’est pas si un problème surviendra, mais si l’architecture et les équipes seront préparées lorsqu’il arrivera.

Questions fréquentes

Que s’est-il passé au centre de données de 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 en raison de la fumée.

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

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, les réseaux, la gestion des délais, la communication et les tests réguliers.

Que doit vérifier une entreprise après un tel incident ?
Il faut examiner ses RPO et RTO, la localisation des sauvegardes, leur test de restauration, la dépendance à un seul site, le plan de communication, et le niveau réel de disponibilité garanti.