Comment choisir un hébergement web adapté à son site

Le meilleur hébergement n’est pas celui qui affiche le plus de gigaoctets ou de « trafic illimité ». C’est celui qui correspond au rôle du site, maintient un niveau de service compréhensible et permet de partir sans perdre ses données. Pour une TPE, le vrai risque n’est pas seulement une panne : c’est de ne plus savoir qui possède le compte, où se trouvent les sauvegardes ni qui doit intervenir.

Ce guide propose une méthode de choix utilisable pour un site vitrine, un WordPress, une boutique ou une petite application métier. Il vous aide à comparer ce qui compte réellement derrière les tableaux commerciaux.

1. Commencez par décrire le rôle du site

Un site institutionnel consulté principalement en journée n’a pas les mêmes contraintes qu’une boutique dont chaque interruption bloque des commandes. Avant de comparer les offres, répondez à cinq questions :

• quelles fonctions produisent directement des demandes, des ventes ou du travail interne ;
• combien de contenus, d’images et de documents seront stockés ;
• quels pics de fréquentation sont possibles après une campagne ou un événement ;
• quelles données seraient difficiles à reconstruire ;
• combien de temps d’interruption l’activité peut raisonnablement supporter.

Ces réponses définissent le niveau de risque. Elles évitent de payer une infrastructure complexe pour un site simple, mais aussi d’installer un service critique sur une formule incapable d’absorber ses traitements.

2. Vérifiez le socle technique avant les options

Pour WordPress, la compatibilité ne signifie pas seulement « PHP et MySQL disponibles ». La page officielle des prérequis WordPress recommande actuellement PHP 8.3 ou plus, MariaDB 10.11 ou MySQL 8.0, ainsi que HTTPS. Les versions anciennes peuvent encore exécuter le logiciel, mais leur fin de support augmente le risque et limite les performances.

Demandez si vous pouvez choisir la version de PHP, consulter les erreurs, gérer les tâches planifiées et accéder aux fichiers par SFTP ou SSH lorsque le projet le nécessite. Vérifiez aussi les limites réelles : mémoire PHP, temps d’exécution, taille d’import, nombre de processus, stockage des bases et politique d’envoi d’e-mails.

Une limite claire n’est pas un défaut. Elle permet de savoir quand une formule devient insuffisante. Le terme « illimité » masque souvent une politique d’usage raisonnable qu’il faut lire avant la mise en ligne.

3. Ne confondez pas capacité et performance

Un grand espace disque ne rend pas un site rapide. Le temps de réponse dépend du processeur disponible, de la mémoire, du stockage, de la charge des autres comptes, de la base de données, du cache et surtout du code exécuté. Un thème lourd ou une requête inefficace restera lent sur une offre plus chère.

Pour comparer, demandez comment sont isolées les ressources et ce qui se passe en cas de dépassement. Le service ralentit-il, bloque-t-il ou facture-t-il un supplément ? Peut-on observer la consommation ? Existe-t-il un niveau supérieur compatible avec la même installation ?

Testez avec le site réel ou une copie représentative. Une page de démonstration vide ne permet pas d’évaluer une boutique, un moteur de recherche ou une administration chargée de milliers de contenus. Notre guide pour améliorer la vitesse de WordPress détaille la différence entre le serveur, le thème, les images et les scripts.

4. Examinez les sauvegardes comme une procédure

« Sauvegarde quotidienne incluse » ne suffit pas. Une sauvegarde utile doit répondre à quatre questions : quoi, où, combien de temps et comment restaurer ? Vérifiez si elle couvre les fichiers, la base de données et les e-mails. Demandez si elle est stockée sur une infrastructure séparée du compte principal et combien de versions sont disponibles.

La fréquence doit suivre la vitesse de changement. Pour un site vitrine modifié une fois par mois, une copie quotidienne peut être confortable. Pour une boutique qui reçoit des commandes, perdre vingt-quatre heures de base de données peut être inacceptable. La fréquence et la rétention doivent donc venir du risque métier, pas d’un réglage identique pour tous.

Enfin, une restauration doit être testée. Un fichier présent dans un tableau de bord n’est pas encore une preuve qu’il peut reconstruire le service. Demandez qui déclenche la restauration, dans quel délai, avec quel coût et jusqu’où va la responsabilité de l’hébergeur.

5. Séparez sécurité du serveur et sécurité du site

L’hébergeur protège le réseau, le système, l’isolation des comptes et une partie des accès. Il ne peut pas corriger une extension WordPress vulnérable, un mot de passe partagé ou un administrateur compromis. À l’inverse, un WordPress parfaitement à jour ne protège pas d’un compte d’hébergement sans double authentification.

Le minimum à vérifier comprend :

• HTTPS et renouvellement du certificat ;
• double authentification pour le compte client ;
• comptes nominatifs plutôt qu’un identifiant partagé ;
• protocoles chiffrés pour les fichiers et l’administration ;
• journal des connexions ou alertes de sécurité disponibles ;
• séparation entre production, sauvegardes et environnements de test.

La sécurité forme une chaîne. Notre guide de sécurisation WordPress complète les contrôles qui relèvent de l’application.

6. Lisez précisément la promesse de support

Un support « disponible 24 h/24 » peut seulement confirmer qu’un serveur répond, sans diagnostiquer votre formulaire ou votre extension. Distinguez le support d’infrastructure, la maintenance applicative et l’accompagnement de votre agence.

Demandez quels canaux sont disponibles, qui peut ouvrir un ticket, quelles langues sont prises en charge et quels événements sont prioritaires. Un engagement de disponibilité n’a de valeur que s’il définit la période de mesure, les exclusions, la maintenance planifiée et la compensation éventuelle. Pour une petite structure, un interlocuteur capable d’expliquer la cause et de coordonner les intervenants vaut souvent davantage qu’un grand catalogue de niveaux de service.

7. Vérifiez la localisation et les sous-traitants

La localisation des serveurs peut influencer les temps de réponse, les contrats et les transferts de données. Identifiez le pays d’hébergement des données principales et des sauvegardes, ainsi que les prestataires susceptibles d’y accéder. Une mention vague « cloud européen » ne dit pas nécessairement où se trouve chaque copie.

Si le site traite des données sensibles ou répond à une contrainte sectorielle, le choix doit être validé dans ce contexte. Pour un site classique, l’essentiel reste d’avoir une information exacte, un contrat accessible et une politique de confidentialité cohérente avec l’infrastructure réellement utilisée.

8. Préparez la réversibilité avant de signer

Vous devez pouvoir récupérer les fichiers, la base, les sauvegardes, les zones DNS et les paramètres nécessaires à une migration. Le domaine doit être enregistré au nom de votre entreprise et les contacts ne doivent pas dépendre uniquement de l’adresse d’un prestataire.

Vérifiez les coûts de sortie, le délai de fermeture après résiliation et la méthode d’export. Certaines fonctions propriétaires — cache, constructeur, messagerie ou sauvegarde — peuvent compliquer le déplacement même si les données sont techniquement exportables.

La bonne décision réduit surtout l’incertitude

Une offre adaptée rend visibles les limites, les responsabilités et la procédure de sortie. Elle ne promet pas qu’aucun incident n’arrivera ; elle permet de savoir comment le détecter, restaurer le service et éviter que le même problème se répète.

Alliance Web peut auditer votre environnement actuel, documenter les comptes et proposer un périmètre d’hébergement et de gestion technique adapté au rôle réel du site.