La direction demande « un hébergeur plus fiable » après trois incidents ce trimestre. L'équipe technique veut migrer vers le cloud d'ici six semaines. Personne n'a listé où pointe le DNS, qui paie le domaine qui expire dans quarante jours, ni testé si la sauvegarde d'hier se restaure réellement.
Remplacer un hébergeur sans audit, c'est transporter en camion des problèmes non diagnostiqués — et en créer de nouveaux : TTL DNS mal calibrés, messagerie MX interrompue, certificats oubliés. Un audit bien mené répond d'abord à une question simple : qu'est-ce qui casse, où, et est-ce vraiment l'hébergement ?
Les cinq couches à auditer, dans l'ordre
| Couche | Questions | Outils / preuves |
|---|---|---|
| Contrat | SLA, exclusions, renouvellement, support | PDF contrat, tickets passés |
| DNS et domaines | TTL, MX, expirations, DNS scindé | whois, dig, registrar |
| Infrastructure | Région, type d'offre, limites | Panneau, facture, traceroute |
| Application | Cache, requêtes, tâches planifiées | slow log, APM, EXPLAIN |
| Données | Sauvegarde, restauration, rétention | Test de restauration chronométré |
Migrer sans valider la couche Données, c'est jouer à la roulette russe avec la production.
Performance : séparer origin, base et CDN
Consacrez deux heures à un diagnostic ciblé. Mesurez d'abord le TTFB origin sans CDN — requête directe vers l'adresse IP ou en-tête de contournement. Relevez ensuite la latence au percentile 95 sur les pages critiques : connexion, paiement, recherche. Analysez le journal des requêtes lentes sur vingt-quatre heures et isolez les cinq requêtes les plus coûteuses. Vérifiez la saturation des workers PHP-FPM aux heures de pointe. Enfin, calculez le taux de succès CDN si un réseau de diffusion est en place.
Si le TTFB origin reste sous deux cents millisecondes mais l'expérience utilisateur est lente, suspectez un front lourd — JavaScript, images non optimisées. Si le TTFB dépasse une seconde avec un processeur au repos, orientez-vous vers la base ou les requêtes en N+1. Si le processeur atteint cent pour cent sur un trafic modeste, le dimensionnement ou un voisin mutualisé bruyant entre en ligne de compte.
Consultez TTFB diagnostic et Index MySQL manquant pour approfondir ces deux causes fréquentes.
Sécurité et accès : l'inventaire que personne n'a
Listez les comptes panneau et SSH : qui a accès, la double authentification est-elle activée ? Vérifiez les versions du système d'exploitation, de PHP et de TLS — une fin de vie approche ? Contrôlez le renouvellement automatique des certificats. Cherchez des fichiers .env ou des sauvegardes SQL sur un disque accessible publiquement. Enfin, documentez la rétention et l'accès aux journaux au regard du RGPD.
Demandez à l'hébergeur l'historique des incidents sur douze mois — pas seulement le SLA théorique affiché en page marketing.
Sauvegardes : le test qui tranche
L'audit des sauvegardes n'est pas une lecture de brochure. Identifiez d'abord la fréquence, la rétention et le lieu de stockage — même compte, chiffrement, région. Restaurez ensuite sur un environnement isolé et chronométrez l'opération. Vérifiez l'intégrité : nombre d'utilisateurs, dernière commande enregistrée. Notez enfin ce qui n'est pas inclus : messagerie, DNS, stockage objet.
Un échec de restauration ou une durée supérieure à quatre heures constitue un P0 : migration ou correction avant tout travail de référencement ou de refonte.
Quand migrer versus quand optimiser
| Constat | Action habituelle |
|---|---|
| Index SQL manquants | Correction applicative et travail DBA |
| Absence de CDN pour les médias | Stockage objet plus CDN |
| Mutualisé saturé par un voisin | Passage VPS chez le même hébergeur |
| SLA non respecté, documenté | Négociation ou migration |
| Région hors UE non consentie | Migration pour conformité |
| Support incompétent de façon récurrente | Migration |
Le sommet : l'audit sert à décider — pas à justifier une décision prise
La migration a un coût réel — DNS, messagerie, régressions, double exécution temporaire. L'audit la rend optionnelle, ou sereine parce que les preuves sont documentées.
Décider et avancer sans angle mort
Établissez un inventaire complet — DNS, accès, piles techniques — dans un tableur partagé accessible à toute l'équipe concernée. Planifiez un test de restauration cette semaine, pas « quand on aura le temps ». Rédigez un rapport de constats classé de P0 à P3, avec un responsable par action. Identifiez les gains rapides sur trente jours : cache, index, alertes sur les tâches planifiées. Ne lancez une migration que si des écarts structurels sont documentés noir sur blanc. Comparez les alternatives via l'annuaire et le comparateur, et consultez Auditer un fournisseur pour le volet contractuel.
Questions fréquentes
Par où commencer un audit hébergement ?
Commencez par un inventaire complet — domaines, DNS, serveurs, bases, sauvegardes, accès et contrats. Mesurez ensuite le TTFB, les erreurs 5xx et testez une restauration réelle avant de juger la marque. Sans inventaire, vous confondez symptômes et causes.
Comment savoir si le problème vient de l'hébergeur ou du code ?
Comparez processeur au repos versus saturation, requêtes lentes et latence origin par rapport au CDN. Processeur bas et site lent : suspectez application ou base. Processeur saturé sur trafic modeste : dimensionnement ou voisinage mutualisé.
Faut-il migrer après un audit ?
Seulement si l'écart contrat-réalité ou les limites produit sont structurels. Sinon, cache, index SQL, tâches planifiées observables ou montée d'offre suffisent souvent — sans changement de marque.
Quels documents demander à l'hébergeur actuel ?
Contrat, SLA, politique de sauvegarde, DPA si données personnelles, incidents sur douze mois et détail de l'offre — processeur, entrées-sorties, support inclus.
Auditer, c'est mesurer avant de déménager — pas choisir la camionnette avant d'avoir ouvert le grenier.