Quand un site cœur du réseau brûle : le retour d'expérience de Mantes-la-Jolie

Publié le 19 octobre 2026 — Retour d'expérience, reprise d'activité

Schéma : deux sites de données reliés par une boucle de fibre dont les deux brins passent par le site incendié, qui hébergeait aussi le witness du cluster

En bref. Dans la nuit du 27 au 28 juin 2023, la mairie de quartier du Val Fourré, à Mantes-la-Jolie, est entièrement détruite par un incendie. Elle hébergeait l'un des quatre sites cœur du réseau municipal, et le witness, l'arbitre, du cluster VxRail de la ville. Perdre en même temps l'arbitre et le lien entre les deux moitiés du cluster l'a arrêté : il a fallu redéployer le witness, puis déménager des serveurs pour regrouper tout le cluster sur un seul site.

Ce qu'on en retient. Un witness placé sur le chemin du lien entre les sites n'est pas un troisième site, c'est un point de défaillance commun. Et une bascule qui n'a jamais été testée en conditions réelles n'est pas une bascule.

Le réseau avant le sinistre

De septembre 2016 à décembre 2024, RDEM Systems a travaillé en direct pour la ville de Mantes-la-Jolie, environ 32 000 habitants : conception du réseau, support de niveaux 2 et 3 et maintien en condition opérationnelle, en lien avec les techniciens de la commune.

Le réseau relie environ 80 sites (services municipaux, écoles, locaux techniques) autour de quatre sites cœur. Les sites sont interconnectés par le réseau MPLS de l'opérateur, avec des pseudowires pour transporter les VLAN d'un site à l'autre.

L'hébergement des serveurs repose sur un cluster VxRail en mode étendu (stretched cluster) : les nœuds sont répartis entre deux des sites cœur, et un troisième site héberge le witness. Le principe est simple. Si le lien entre les deux sites de données se coupe, chacun se retrouve seul, et c'est le witness qui départage : le site qui le voit encore garde la majorité des voix et continue à servir les machines virtuelles. L'autre s'arrête, pour éviter que les deux moitiés n'écrivent chacune de leur côté (le split brain). RDEM n'avait pas la charge du VxRail lui-même.

Ce troisième site, c'était la mairie de quartier du Val Fourré. Elle accueillait un cœur de réseau et le witness. Surtout, les deux brins de la boucle de fibre qui reliait les deux sites du cluster y passaient tous les deux. Une paire de fibres reliait les sites l'un après l'autre ; une seconde paire, patchée sur chaque site, refermait la boucle. Il n'existait qu'un seul chemin physique.

Ce n'était pas un oubli, mais un risque assumé. Le scénario redouté sur une fibre, c'est la pelleteuse, et le fournisseur s'engageait à réparer en quelques heures. Personne n'avait envisagé la perte du bâtiment lui-même.

Nuit du 27 au 28 juin 2023 : le site est perdu

Le magazine municipal le rapporte en une de son numéro de l'été : un incendie est « survenu, détruisant entièrement la mairie de quartier, dans la nuit de mardi 27 à mercredi 28 juin » (MLJ Mag, juillet-août 2023). Les agents qui y travaillaient sont réaffectés dans d'autres bâtiments de la ville. La mairie de quartier ne rouvrira que le 5 février 2024, dans de nouveaux locaux au 1, rue La Fontaine, à 300 mètres de l'ancien bâtiment (communiqué de la ville, février 2024).

Pour le réseau, le constat est sans appel : tout ce qui se trouvait dans le bâtiment est perdu. Le cœur de réseau, le witness, et une partie des fibres qui y passaient.

Le jour même : état des lieux et premières décisions

L'intervention d'urgence commence le 28 juin par un état des lieux : ce qui ne répond plus, ce qui dépendait du site détruit, ce qui peut encore être sauvé. Viennent ensuite les préconisations, et une première tentative sur l'existant : repatcher les fibres pour remettre le reste du backbone en fonction.

La tentative échoue : les fibres ont brûlé avec le bâtiment, et rien ne remonte. Tant qu'elles ne seront pas ressoudées, il faut faire tourner la production sans elles. D'où la décision du jour : déplacer une partie de la production, puis remonter le backbone une fois les fibres réparées.

Redéployer le witness ne suffit pas : on regroupe le cluster

Le cluster venait de perdre deux choses à la fois : son arbitre et le lien entre ses deux moitiés. Chaque site de données se retrouvait isolé, sans personne pour le départager. Pour le cluster, c'est une double panne, et il s'arrête.

Première mesure : déployer un nouveau witness sur l'un des deux sites du cluster. Cela rendait un arbitre au cluster, mais pas sa seconde moitié : les deux brins de la boucle ayant brûlé ensemble, les nœuds de l'autre site restaient injoignables. Le cluster n'est pas reparti sur une seule moitié.

Pourquoi cela n'a pas suffi n'a pas été établi. C'est précisément ce qu'un test en conditions réelles aurait révélé avant le sinistre.

Puisque le lien entre les deux sites ne pouvait pas être rétabli à court terme, RDEM Systems et les équipes de la mairie ont pris le problème à l'envers : ramener les quatre nœuds VxRail de l'autre site sur le même site que le witness, et y remonter le cluster entier. Un déménagement de serveurs en urgence, pour reconstituer physiquement ce que le réseau ne pouvait plus relier.

Le backbone, lui, n'est revenu qu'une fois les fibres ressoudées.

Ce qui a tenu, ce qui a manqué

Ce qui a tenu : le cluster lui-même, une fois ses nœuds réunis sur un même site, et la possibilité de déplacer la production sans attendre la réparation des fibres.

Ce qui a manqué tient en deux points. D'abord, le witness et les deux brins de la boucle dépendaient du même bâtiment. Le risque d'une coupure de fibre était couvert par le délai de réparation du fournisseur ; la perte du bâtiment, qui emportait l'arbitre et le lien d'un coup, ne l'était pas. Ensuite, ce scénario n'avait jamais été joué : les tests du VxRail n'avaient pas mis le cluster en situation de split brain réel, lien inter-sites coupé et witness perdu.

Des sauvegardes existaient, hors du périmètre de RDEM Systems. Elles n'ont pas eu à servir : une fois les nœuds VxRail regroupés, le cluster est reparti avec ses données, sans restauration.

Ce qu'on en retient pour un PRA

  1. L'arbitre d'un cluster est une dépendance. Le witness doit joindre chaque site de données par un chemin qui lui est propre. Placé sur un site par où passe le lien entre les deux autres, il tombe avec lui. « Secondaire » ne veut pas dire « sans risque ».
  2. Cartographier les chemins physiques, pas seulement les liens logiques. Une boucle dont les deux brins traversent le même bâtiment protège d'une pelleteuse, pas de la perte du bâtiment. La question à poser pour chaque site : s'il disparaît, qu'est-ce qui tombe avec lui ? Et si la réponse est assumée, qu'elle soit écrite dans le PRA.
  3. Tester le split brain en conditions réelles. Une recette qui coupe un lien ou arrête un nœud ne prouve rien sur la double panne. Couper le lien inter-sites et le witness en même temps, en fenêtre de maintenance, et l'écrire dans le cahier de recette de l'intégrateur.
  4. Préparer le plan B physique. Savoir à l'avance où l'on peut regrouper des serveurs, avec quelle alimentation, quels ports et quels VLAN. Le jour du sinistre, ce n'est pas le moment de le découvrir.
  5. Chiffrer ce qu'on accepte de perdre. Combien de temps d'arrêt, combien de données : un calculateur RPO / RTO aide à poser ces chiffres avant d'arbitrer les investissements.

Les réflexes des premières heures sont les mêmes qu'un sinistre touche une salle municipale ou un datacenter : faire l'état des lieux avant d'agir, décider vite de ce qu'on abandonne. Nous les détaillons dans que faire pendant une panne d'hébergeur.

Pour mettre ces leçons en ordre avant le prochain sinistre, voici la méthode pour construire un plan de reprise d'activité : inventaire des dépendances, objectifs de reprise, scénarios et tests.

Pour aller plus loin

Et si l'un de vos sites disparaissait demain ?

On cartographie ce qui dépend de chaque bâtiment, on repère les points de défaillance communs, et on vous aide à tester vos bascules avant d'en avoir besoin.

01 77 62 42 42