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 Samedi 4 avril 2026 à 14h49À ce moment-là, l'instance Cloud appartenant au service Aruba Cloud.it et portant le nom de nœud « MANAGEDSERVER.IT »Le système devient 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. Aucune accessibilité, aucune opération, aucun contrôle effectif depuis le panneau de contrôle. Un ticket a été ouvert à l'adresse suivante : 15:01De là commence une séquence d'heures qui se transforment en jours, jusqu'à la seule restauration. Le 7 avril 2026 à 10h30Au total, presque 67 heures et 41 minutes d'inactivité.
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 arrivent. Un problème physique survient au niveau d'un nœud, une panne de stockage se produit, un événement provoque une interruption de service majeure. Personne travaillant dans l'infrastructure n'est surpris par l'idée abstraite qu'une panne puisse survenir. Le problème est ailleurs : Que se passe-t-il ensuite ?.
Et c'est là que l'incident cesse d'être une simple 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 qui est le plus irritant avec le down. Les infrastructures peuvent tomber en panne. Mais la gestion de cette panne ne peut se permettre d'échouer à son tour.
Après plus de 18 heures de coupure, un courriel certifié est envoyé. Avertissement formel et avis de défautPuis, 33 heures plus tard, un autre rappel détaillé. Puis, 50 heures plus tard, un autre courriel certifié réaffirmant l'évidence : ce n'est pas seulement l'absence de solution qui pose problème, mais aussi le manque de communication. Le strict minimum attendu d'un fournisseur de services cloud censés être destinés, du moins en théorie, à un usage professionnel, fait cruellement défaut.
À un moment donné, deux itinéraires alternatifs ont même été demandés, tous deux raisonnables : Soit on restaure le nœud, soit on fournit un instantané de la machine au format OpenStack, permettant une migration autonome. Rien. Ni l'un ni l'autre. 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 où l'on lui répète sans cesse qu'« on le 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 dommages bien plus importants a été due à un facteur extérieur au fournisseur. Après une interruption de service initiale d'environ quarante minutes, constatant l'absence de tout retour d'information utile et pressentant qu'il n'y aurait pas de rétablissement rapide, nous avons activé notre système. Réplication ZFS sur HetznerC’est ce qui nous a sauvés. Ni la résilience intrinsèque du service, ni le support, ni même le faux parapluie protecteur que suggère le terme « cloud ». Le salut est venu d’une réplique indépendante, géographiquement distincte, en dehors de cette infrastructure et prête à l’emploi. Grâce à cette réplique, le site web de l’institution a pu se remettre 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
À ce stade, la question de Contrat de niveau de servicecar c'est là que de nombreuses entreprises s'illusionnent en pensant être protégées. Le SLA publié par Cloud.it est le document. « Accord de niveau de service (SLA) du service de cloud computing Aruba », version publique 1.3, à compter de Juillet 31 2025Le document distingue plusieurs scénarios. Pour les services cloud en général, Aruba déclare que Disponibilité de 99,95 % sur une base annuelle pour l'accessibilité Internet à l'infrastructure du centre de données et un plus 99,95 % sur une base annuelle pour la disponibilité des nœuds physiques qui hébergent l'infrastructure virtuelle du client. Pour certains types spécifiques, tels que VPS OpenStack Starter e VPS VMware, le niveau chute à 99,8 % sur une base annuelle à la fois pour l'accessibilité et la disponibilité des nœuds physiques. De plus, la maintenance planifiée n'est pas prise en compte et doit être communiquée au moins préavis de 48 heures.
En termes concrets, une disponibilité annuelle de 99,95 % signifie une interruption de service théoriquement tolérée d'environ 4 heures et 23 minutes par an99,8 % signifie en réalité environ 17 heures et 31 minutes par anComparons maintenant ces chiffres à ce qui s'est réellement passé : presque 67 heures et 41 minutes d'indisponibilitéMême en supposant le scénario le plus favorable pour le fournisseur, c'est-à-dire 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 se situait dans la fourchette standard de 99,95 %, le dépassement serait encore plus dramatique. Dans les deux cas, cependant, il ne s'agit pas d'un faible écart statistique : il s'agit d'un 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.
Il y a ensuite le thème du remboursementCe qui est peut-être l'aspect le plus ironique de toute cette histoire. Pour l'infrastructure virtuelle créée et allouée par le client, l'article 6.2 prévoit une crédit égal à 5 % des dépenses totales générées au cours des 30 jours précédant la panne, ou du mois précédent pour les services payants mensuels, pour chaque fraction de 15 minutes d'interruption de service au-delà des limites fixées par le SLA, jusqu'à un maximum de 300 minutesÉtant donné que 300 minutes équivalent à 20 blocs complets de 15 minutes, le crédit maximal atteint effectivement 100 % des dépenses relatives à la partie concernée de l'infrastructure virtuelle dans le délai de référence. La demande de crédit doit être soumise dans les 10 jours suivant la fin de la panne par ticket, et seules les interruptions de service confirmées par le système de surveillance d'Aruba sont considérées comme valides. Pour les services cloud mensuels payants, le document précise également que Aucun remboursement supplémentaire n'est dû pour la période d'inactivité., à l'exception du crédit prévu à l'article 6.2. Le texte ajoute également que, pendant la période d'inactivité, le service cloud ne génère 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é considérablement plus longtemps que les limites tolérées par le SLA, le mécanisme de crédit a très probablement atteint ses limites. maximum théorique, soit 20 euros, VINGT.
En d'autres termes, sauf exceptions appliquées par le fournisseur ou litiges concernant la qualification du service, l'indemnisation financière à laquelle on aurait droit atteindrait vraisemblablement 100 % des dépenses d'infrastructure impactées au cours des 30 derniers jours, ou al 100 % du salaire du mois dernier S'il s'agit d'un service mensuel, pas plus. Pas 200 %. Pas le coût des dommages. Pas le manque à gagner. Pas le temps de travail perdu. Pas l'atteinte à la réputation. Pas l'anxiété opérationnelle. Pas le coût d'une migration d'urgence. Pas la perte potentielle de positionnement. Simplement, au maximum, l'équivalent d'un mois de salaire ou du dernier usage du 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.
Finalement, la vraie question n'est même pas de savoir si la perturbation était grave. Elle l'était sans aucun doute. La vraie question est ailleurs : 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 : aucuneOu plutôt, pas seul. Pas sans un plan B sérieux. Pas sans la conscience que, lorsque le prestataire fait défaut et que le soutien se réfugie derrière des formules toutes faites, la seule chose qui vous sauve vraiment, 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.
