Table des matières de l'article :
Il y a des pannes dont on se souvient quelques heures. Il y a celles qui deviennent un problème interne, un rappel opérationnel, une leçon à ne jamais oublier. Et puis il y a les épisodes qui méritent d'être relatés publiquement, car ils cessent d'être un simple incident technique et deviennent une illustration frappante d'un problème bien plus vaste : la fragilité de certains services cloud lorsque la théorie commerciale se heurte à la pratique, et lorsque le support cesse d'être un support et se transforme en simple centre d'orientation.
Temps d'arrêt VPS dans Cloud.it
Cette histoire commence le samedi 4 avril 2026 à 14h49 . À ce moment précis, l'instance Cloud du service Cloud.it d'Aruba, dont le nom de nœud est « MANAGEDSERVER.IT », est devenue totalement inaccessible. Il ne s'agit pas d'un service dégradé, d'une latence anormale ou de quelques paquets perdus. Il s'agit d'une panne générale. Impossible d'accéder au service, de l'utiliser, ni même de le contrôler depuis le panneau de contrôle. Un ticket d'incident a été ouvert à 15h01 . Dès lors, une série d'heures, puis de jours, s'est enclenchée, jusqu'au rétablissement du service le 7 avril 2026 à 10h30 . Au total, près de 67 heures et 41 minutes d'indisponibilité.
Soixante-sept heures. SOIXANTE-SEPT ! Plus de deux jours et demi. En 2026. Sur un service cloud.
Cela devrait suffire à en faire sourciller plus d'un.
La gestion inexistante du problème
Mais le problème ne se limite pas à la panne. Les pannes sont inévitables. Elles touchent tout le monde, Google, Microsoft, AWS. Elles surviennent. Un problème physique survient au niveau d'un nœud, une panne de stockage se produit, un événement provoque une indisponibilité critique. Personne travaillant dans l'infrastructure n'est surpris par l'idée abstraite qu'une panne puisse avoir lieu. L'important, c'est ce qui se passe ensuite.
Et c’est là que l’histoire cesse d’être une banale interruption de service et devient une mésaventure exemplaire.
Car dans les heures qui ont suivi l'ouverture du ticket, et pendant les dizaines d'heures qui ont suivi, le sentiment dominant n'était pas celui d'un fournisseur confronté à un problème grave mais maîtrisé. On avait plutôt l'impression d'être plongé dans une zone grise de formules automatisées, de vaines promesses et d'une quasi-absence d'informations techniques utiles. « Nous vérifions. » « Nous vous avons contacté. » « Nous vous recontacterons. » Des phrases qui servent à meubler, sans apporter de solution. Des phrases qui servent davantage à gagner du temps qu'à rétablir la visibilité pour le client. Et pendant ce temps, le temps passait, le système restait bloqué, et aucune explication concrète n'arrivait de l'autre côté concernant la cause de la panne, l'état réel des opérations, les problèmes critiques rencontrés, ni même une estimation minimale fiable du délai de rétablissement.
C’est ce point qui est plus irritant encore que l’indisponibilité du service. Une infrastructure peut tomber en panne. Mais la gestion de cette panne ne peut se permettre d’échouer à son tour.
Après plus de 18 heures de panne, un avertissement formel et une notification de défaut de paiement ont été envoyés par courriel certifié . Puis, 33 heures plus tard, un rappel détaillé. Enfin, 50 heures plus tard, un autre courriel certifié réitérant l'évidence : le problème ne se limite pas à l'absence de résolution, mais comprend également un manque de communication. Le minimum attendu d'un fournisseur proposant un service cloud destiné, du moins en théorie, à un usage professionnel, fait cruellement défaut.
À un moment donné, deux solutions alternatives, toutes deux raisonnables, ont même été proposées : soit restaurer le nœud, soit fournir un instantané de la machine au format OpenStack, permettant ainsi une migration autonome. Rien. Aucune des deux. Juste ce flou total où le client n’a ni la machine, ni les données, ni de date de résolution, ni de contact technique pour le tenir informé, mais entend sans cesse : « On vous recontactera. »
C’est dans ces moments-là que le cloud révèle son pire visage. Quand il fonctionne, tout est pratique : évolutivité, flexibilité, mise en service rapide, tableaux de bord, automatisation, marketing. Mais quand quelque chose dysfonctionne – et ça arrive souvent –, le client découvre soudain le côté le plus gênant de l’accord : l’infrastructure ne lui appartient pas, il n’en a pas le contrôle, il n’a pas accès à la couche physique et la rapidité de réponse dépend entièrement de l’expertise, de la transparence et de la fiabilité du fournisseur. Si ces trois éléments font défaut, le cloud cesse d’être pratique et devient une prison.
Dans notre cas, la différence entre une panne majeure et des dégâts bien plus importants a été due à un facteur extérieur au fournisseur. Après une interruption de service initiale de quarante minutes, constatant l'absence de tout retour d'information utile et pressentant une reprise tardive, nous avons activé notre réplication ZFS sur Hetzner . C'est ce qui nous a sauvés. Ni la résilience native du service, ni le support, ni même le prétendu parapluie protecteur du « cloud ». Le salut est venu d'une réplication indépendante, géographiquement distincte, en dehors de cette infrastructure et prête à l'emploi. Grâce à cette réplication, le site web de l'institution a été remis en ligne après les quarante premières minutes d'indisponibilité, alors même que le fournisseur n'avait reçu aucune indication quant à une résolution rapide.
Et c'est ici que nous devons nous arrêter un instant, car la leçon est importante.
Le cloud n'est pas une solution de sauvegarde. Le cloud n'est pas une solution de reprise après sinistre. Le cloud n'est pas une réplication géographique. Le cloud, en soi, est simplement l'ordinateur de quelqu'un d'autre. Et lorsque cet ordinateur disparaît pendant près de trois jours, tous les beaux discours sur la continuité des activités commencent soudain à montrer leurs faiblesses.
Pour couronner le tout, la SLA
C’est à ce stade que la question des SLA entre en jeu , car c’est là que de nombreuses entreprises s’illusionnent en pensant être protégées. Le SLA publié par Cloud.it est le « Contrat de niveau de service (SLA) du service de cloud computing Aruba » , version publique 1.3 , en vigueur jusqu’au 31 juillet 2025. Ce document distingue plusieurs scénarios. Pour les services cloud en général, Aruba garantit une disponibilité de 99,95 % par an pour l’accessibilité Internet à l’infrastructure du centre de données et une disponibilité de 99,95 % par an également pour les nœuds physiques hébergeant l’infrastructure virtuelle du client. Pour certaines typologies spécifiques, telles que VPS OpenStack Starter et VPS VMware , ce niveau est abaissé à 99,8 % par an, tant pour l’accessibilité que pour la disponibilité des nœuds physiques. De plus, les opérations de maintenance planifiées ne sont pas prises en compte et doivent être annoncées au moins 48 heures à l’avance.
Concrètement, une disponibilité annuelle de 99,95 % signifie une interruption de service théoriquement tolérée d'environ 4 heures et 23 minutes par an . À l'inverse, 99,8 % correspond à environ 17 heures et 31 minutes par an . Comparons maintenant ces chiffres à la réalité : près de 67 heures et 41 minutes d'indisponibilité . Même en prenant l'hypothèse la plus optimiste pour le fournisseur, à savoir le seuil plus large de 99,8 %, il ne s'agit pas d'un simple dépassement. Nous sommes face à un incident qui dépasse largement la limite promise. Si, en revanche, le service avait respecté le scénario habituel de 99,95 %, le dépassement aurait été encore plus dramatique. Dans les deux cas, cependant, il ne s'agit pas d'un faible écart statistique : il s'agit d'un véritable gouffre.
Mais alors, concrètement, à quoi aurait-on dû s'attendre d'une SLA de ce type ?
Tout d'abord, on aurait attendu que la garantie de disponibilité ne soit pas un simple chiffre décoratif, mais l'expression d'un modèle opérationnel cohérent : surveillance efficace, gestion des incidents graves, communication claire, véritables canaux d'escalade et capacité à proposer des solutions de contournement. Un SLA n'est pas qu'un pourcentage. C'est la garantie concrète qu'en cas de panne grave, le fournisseur dispose d'un système prêt à intervenir. Autrement dit : on n'attend pas l'impossible, mais on attend de l'expertise, de la transparence et des délais proportionnels à la gravité de l'événement. Après quelques heures, on attend au minimum une cause probable. Après plusieurs dizaines d'heures, on attend un plan d'action. Après plus de deux jours, on attend une solution, ou au moins une alternative concrète permettant au client de surmonter la panne. Or, c'est tout le contraire qui s'est produit : un SLA qui, face à un incident réel, n'a empêché ni la panne prolongée ni la rupture de communication.
Le remboursement « inexistant » du dommage subi.
Vient ensuite la question du remboursement , qui est peut-être l'aspect le plus paradoxal de toute cette histoire. Pour l'infrastructure virtuelle créée et allouée par le client, l'article 6.2 prévoit un crédit équivalent à 5 % du coût total encouru au cours des 30 jours précédant l'interruption , ou du paiement du mois précédent pour les services mensuels payants, pour chaque tranche de 15 minutes d'interruption dépassant les limites du SLA , jusqu'à un maximum de 300 minutes . Sachant que 300 minutes correspondent à 20 tranches de 15 minutes, le crédit maximal représente en réalité 100 % du coût de la portion d'infrastructure virtuelle affectée pendant la période de référence. La demande de crédit doit être soumise dans les 10 jours suivant la fin de l'interruption via un ticket, et seules les interruptions confirmées par le système de surveillance d'Aruba sont prises en compte. Par ailleurs, pour les services cloud mensuels payants, le document précise qu'aucun autre remboursement n'est dû pour la période d'inactivité , hormis le crédit prévu à l'article 6.2. Le texte précise également que, pendant la période d'inactivité, le service cloud n'engendre aucun coût et que tout montant facturé par erreur doit être recrédité sur le panneau de gestion.
Ici, le paradoxe est presque choquant tant il est clair.
Étant donné que la panne a duré beaucoup plus longtemps que les limites tolérées par le SLA, le mécanisme de crédit a très probablement atteint son maximum théorique, soit 20 euros, VINGT.
En d'autres termes, sauf exceptions accordées par le fournisseur ou litiges relatifs à la qualification du service, l'indemnisation financière à laquelle vous pourriez prétendre s'élèverait vraisemblablement à 100 % du coût de l'infrastructure affectée au cours des 30 derniers jours , ou à 100 % du dernier paiement mensuel s'il s'agit d'un service mensuel. Pas plus. Pas 200 %. Ni le coût des dommages. Ni le manque à gagner. Ni le temps de travail perdu. Ni l'atteinte à la réputation. Ni le stress opérationnel. Ni le coût d'une migration d'urgence. Ni la perte potentielle de positionnement. Simplement, au maximum, l'équivalent d'un mois de paiement ou du dernier paiement effectué sur le bloc concerné.
Et c’est là que la SLA, en tant qu’outil de protection, révèle toute son insuffisance pratique.
Face à une indisponibilité de près de trois jours, malgré des tickets d'assistance ouverts, des e-mails certifiés, des appels téléphoniques et une absence totale de support technique effectif, le client se voit proposer un avoir couvrant le coût du service pendant la période concernée : vingt euros, soit le prix d'une pizza et d'un Coca dans une pizzeria de banlieue. Une sorte de « remboursement » déguisé en protection contractuelle. D'un point de vue strictement contractuel, le prestataire affirme avoir clairement défini le périmètre de l'indemnisation. D'un point de vue opérationnel, le client constate un écart considérable entre le préjudice réel et la valeur de l'avoir prévu par le SLA.
De plus, le contrat de niveau de service (SLA) lui-même comporte une série d'exclusions : force majeure, interventions urgentes et exceptionnelles pour des raisons de sécurité ou de stabilité, problèmes imputables au client, dysfonctionnements de logiciels tiers, pannes externes au réseau Aruba, etc. Ces clauses sont assez classiques et n'ont rien d'étonnant en soi. Cependant, lorsque l'indemnisation financière est déjà modeste, la présence d'une liste exhaustive d'exclusions démontre d'autant plus que ce type de document protège avant tout le fournisseur, et bien moins le client.
Conclusions de cette mauvaise expérience.
Au final, la vraie question n'est même pas de savoir si la panne était grave. Elle l'était sans aucun doute. La vraie question est : est-il judicieux d'utiliser un tel service comme unique pilier d'une infrastructure s'il n'est pas complété par des sauvegardes indépendantes, une réplication géographique et une stratégie de reprise après sinistre autonome ?
Pour nous, la réponse après cette expérience est d'une simplicité brutale : non . Ou plutôt, pas seul. Pas sans un plan B solide. Pas sans être conscient que, lorsque le prestataire fait défaut et que le soutien se réfugie derrière des formules toutes faites, la seule chose qui puisse vraiment vous sauver, c'est ce que vous avez construit en dehors de tout cela.
Dans notre cas, c'est une réplication ZFS sur Hetzner qui a permis de remettre en service le site web de l'institution après les quarante premières minutes d'indisponibilité, et ce, malgré l'absence de retour d'information significatif de l'autre côté. Difficile d'imaginer une situation plus catastrophique. Pendant près de trois jours, la promesse du cloud s'est évanouie. La continuité des activités a été gravement compromise.
Ce qui nous amène à la conclusion la plus honnête, et aussi la plus difficile à accepter : un contrat de niveau de service (SLA) peut vous accorder un certain crédit. Mais il ne compense pas le temps perdu, la réputation ternie, la confiance trahie, ni l’absurdité de devoir réclamer pendant près de soixante-huit heures un service qui aurait dû rester opérationnel sans interruption.
