En matière d'hébergement, il y a deux types d'entreprises : celles qui ont déjà connu un gros incident, et celles qui ne l'ont pas encore connu. Plutôt que d'attendre la panne pour découvrir que personne n'avait de plan, autant s'y préparer dès maintenant. Voici la méthode que nous recommandons pour aborder sereinement les soucis d'infrastructure.
Accepter que la panne est inévitable
Aucun hébergeur, aussi sérieux soit-il, ne peut promettre une disponibilité de 100 %. Disques durs qui lâchent, bug applicatif qui fait exploser la RAM, coup de pelleteuse sur une fibre, pic de trafic imprévu, attaque DDoS, mise à jour qui se passe mal côté datacenter : la liste des scénarios est longue. La vraie question n'est pas « est-ce que ça va casser ? » mais « quand ça cassera, combien de temps mon business sera-t-il à l'arrêt ? ».
Une fois ce constat posé, on arrête de chercher la garantie absolue et on commence à travailler sur les bons indicateurs : le temps d'indisponibilité acceptable, la perte de données tolérable, et la chaîne de personnes capables d'intervenir.
Définir vos seuils business : RTO et RPO
Avant de parler technique, il faut parler chiffres business. Deux notions à connaître absolument :
- RTO (Recovery Time Objective) : combien de temps votre site ou votre application peut rester hors-ligne avant que ça ne devienne critique ? Une heure ? Quatre heures ? Une journée ?
- RPO (Recovery Point Objective) : combien de données pouvez-vous accepter de perdre ? Une journée de commandes ? Une heure de saisie ? Zéro ?
Ces deux chiffres conditionnent l'architecture, le coût de l'hébergement et la fréquence des sauvegardes. Un site institutionnel et un e-commerce qui fait 50 000 € par jour n'ont pas du tout les mêmes contraintes. Tant que ces seuils ne sont pas validés par la direction, toutes les discussions techniques tournent dans le vide.
Cartographier votre infrastructure
Vous seriez surpris du nombre d'entreprises incapables de répondre à la question : « quels sont les serveurs et services dont dépend votre site ? ». Posez-vous calmement et listez :
- les serveurs web et applicatifs,
- les bases de données,
- les services tiers (paiement, mail transactionnel, CDN, recherche, analytics),
- les noms de domaine, certificats SSL et leurs dates d'expiration,
- les comptes administrateurs (qui a accès, où sont stockés les mots de passe).
Cette cartographie n'est pas un livrable consultant à 10 000 € : un simple tableau partagé suffit. Mais il doit exister, être à jour, et être accessible à plus d'une personne. Le jour où votre développeur freelance est en vacances et que le site tombe, vous serez content de ne pas chercher où sont stockés les DNS.
Mettre en place une vraie politique de sauvegarde
On reviendra plus en détail là-dessus dans un autre article, mais la règle de base est connue : la fameuse règle du 3-2-1. Trois copies de vos données, sur deux supports différents, dont une hors site. Et surtout, des sauvegardes testées régulièrement. Une sauvegarde qui n'a jamais été restaurée est une sauvegarde dont on ne sait pas si elle marche.
Vérifiez aussi la rétention : conserver uniquement les sauvegardes des 24 dernières heures ne sert à rien si vous découvrez un piratage ou une corruption silencieuse deux semaines plus tard.
Construire un plan de continuité et de reprise
On parle souvent de PCA (Plan de Continuité d'Activité) et de PRA (Plan de Reprise d'Activité). Derrière ces acronymes, il y a simplement un document qui répond à trois questions :
- Qui fait quoi quand un incident est détecté ?
- Comment basculer vers une solution de secours ?
- Comment communiquer auprès des clients, partenaires et équipes internes ?
Pas besoin d'un classeur de 200 pages. Une page A4 claire, affichée dans l'open-space ou épinglée dans le wiki interne, vaut mieux qu'un PRA parfait que personne n'a jamais lu. L'objectif est qu'en cas de coup dur, n'importe qui dans l'équipe sache quoi faire dans les cinq premières minutes.
Tester, encore et encore
C'est le point le plus négligé. Une fois par trimestre minimum :
- simulez une restauration de sauvegarde sur un environnement de test,
- coupez volontairement un service secondaire pour voir si la supervision déclenche bien une alerte,
- vérifiez que les contacts d'astreinte sont à jour et que les numéros répondent vraiment.
Vous découvrirez, presque à chaque fois, un trou dans la raquette : un certificat qui n'avait pas été renouvelé, un script de bascule qui pointe vers une IP périmée, un email d'alerte qui partait dans un dossier spam. Mieux vaut le découvrir un mardi à 14h qu'un samedi à 3h du matin.
Bien choisir et bien dialoguer avec son hébergeur
Tout cela suppose un hébergeur qui joue le jeu. Avant de signer, posez les bonnes questions :
- quel est le SLA réel, pénalités incluses ?
- qui surveille les serveurs, à quelle fréquence, et comment êtes-vous prévenu ?
- combien de temps pour avoir un humain au téléphone en pleine nuit ?
- les sauvegardes sont-elles incluses, ou facturées en supplément ?
Un bon hébergeur ne vendra jamais du « zéro incident », mais il vous expliquera précisément comment il gère les incidents quand ils arrivent. C'est cette transparence-là qu'il faut chercher.
En résumé
Se préparer aux soucis d'hébergement, ce n'est pas être pessimiste : c'est être professionnel. Cartographiez, sauvegardez, documentez, testez, et choisissez un hébergeur qui parle le même langage que vous. Le jour où ça casse — et ça cassera — vous gagnerez les heures qui font toute la différence entre un incident géré et une crise médiatique.
