Il est rare de rencontrer un prestataire capable de cumuler, dans une même opération, autant de mauvaises décisions, d’impréparation et d’amateurisme. Pourtant, Hosteur semble avoir relevé ce défi avec un certain talent.
Tout commence par l’annonce de la disparition de l’offre FlexOne, accompagnée d’une injonction à migrer vers une solution VPS dont le coût est pratiquement doublé. Une augmentation tarifaire déjà difficile à justifier en soi, mais qui pourrait éventuellement être acceptée si elle s’accompagnait d’une amélioration tangible du service, des performances ou des garanties offertes aux clients.
Malheureusement, les événements qui ont suivi démontrent exactement l’inverse.
Dans un choix qui défie toute logique d’exploitation informatique, Hosteur décide d’effectuer une migration d’infrastructure en pleine journée, c’est-à-dire durant les heures où l’impact potentiel sur les clients est maximal. Cette décision seule soulève de sérieuses interrogations quant à la compréhension des principes élémentaires de continuité de service.
Dans n’importe quelle organisation maîtrisant un minimum ses processus de production, ce type d’opération critique est planifié de nuit, durant un week-end ou au cours d’une fenêtre de maintenance clairement définie. C’est une évidence connue depuis des décennies dans le monde de l’exploitation informatique.
Manifestement, cette évidence n’a pas trouvé son chemin jusqu’aux équipes responsables de cette opération.
Le plus inquiétant n’est cependant pas la décision elle-même, mais son résultat.
Après avoir interrompu les services de ses clients, Hosteur s’est retrouvé dans l’incapacité de remettre en fonctionnement les serveurs dans les délais annoncés. Une migration préparée de longue date, réalisée sur des infrastructures parfaitement connues de l’hébergeur, s’est transformée en démonstration grandeur nature des conséquences d’une préparation insuffisante et d’une maîtrise technique manifestement défaillante.
Lorsqu’un hébergeur provoque lui-même une indisponibilité, il est censé disposer :
• d’un plan de migration validé ;
• de procédures de retour arrière éprouvées ;
• de sauvegardes vérifiées ;
• d’un plan de reprise immédiat en cas d’échec ;
• d’équipes capables de diagnostiquer et corriger rapidement les incidents.
À la lumière des événements, on peut légitimement s’interroger sur l’existence réelle ou l’efficacité de ces dispositifs.
Car lorsqu’une opération prévue se transforme en panne prolongée, deux hypothèses existent généralement :
1. Soit les risques n’ont pas été correctement évalués.
2. Soit les compétences nécessaires à leur maîtrise n’étaient pas réunies.
Dans les deux cas, le constat est particulièrement préoccupant pour une société dont le cœur de métier est précisément l’hébergement et la disponibilité des services numériques.
Le plus paradoxal dans cette affaire est sans doute le message envoyé aux clients : payer deux fois plus cher pour bénéficier d’un niveau de fiabilité qui semble, lui, avoir été divisé par deux.
On pourrait presque admirer la performance si ses conséquences n’étaient pas aussi pénalisantes pour les entreprises qui dépendent quotidiennement de ces infrastructures.
Au-delà de la panne elle-même, c’est surtout le sentiment d’improvisation qui choque. Chaque heure supplémentaire d’indisponibilité donne l’impression d’assister non pas à la gestion d’une infrastructure professionnelle, mais à une séance de dépannage improvisée où les problèmes sont découverts au fur et à mesure qu’ils apparaissent.
Pour un hébergeur, la confiance constitue le principal capital. Les clients ne paient pas uniquement pour des ressources CPU, de la mémoire ou du stockage. Ils paient pour la compétence, l’anticipation, la rigueur et la capacité à garantir la continuité de leur activité.
Or, dans cette situation, Hosteur est malheureusement parvenu à démontrer exactement l’inverse.
Augmentation brutale des coûts, migration imposée, interruption en pleine journée, indisponibilité prolongée, incapacité à rétablir rapidement les services : difficile d’imaginer une succession d’événements plus contre-productive pour convaincre ses clients de rester.
Cette opération restera sans doute comme un exemple particulièrement révélateur de ce qu’une migration d’infrastructure ne devrait jamais être : mal planifiée, mal exécutée et subie intégralement par les clients qui, au final, financent pourtant l’ensemble du dispositif.
Pour un hébergeur dont la mission consiste à assurer la disponibilité des systèmes, réussir à provoquer lui-même l’indisponibilité de ses propres clients est déjà problématique. Réussir à le faire lors d’une opération qu’il a lui-même planifiée depuis des semaines relève d’un niveau de dysfonctionnement qui mérite une profonde remise en question des méthodes de travail, des procédures techniques et de la gouvernance opérationnelle.
En l’état, cette expérience laisse surtout l’impression d’avoir affaire à une organisation davantage préoccupée par l’augmentation de ses revenus que par la qualité de service qu’elle est censée fournir. Et lorsqu’un hébergeur commence à inspirer davantage d’inquiétude que de confiance, c’est généralement le signe que quelque chose de fondamental ne fonctionne plus.
