Il existe deux façons de mettre un site en ligne, et elles ne se distinguent pas d'abord par le prix. Soit vous souscrivez un hébergement chez un hébergeur et vous restez l'exploitant de votre site, soit vous louez un outil dont l'hébergement fait partie et l'éditeur exploite à votre place. Le premier modèle vous laisse les commandes, le second vous les retire.
Cet article ne rechiffre pas l'hébergement. Les montants, formule par formule, avec les lignes qui s'y ajoutent toujours, sont dans ce que coûte vraiment l'hébergement d'un site internet. Ici, il est question du modèle : qui exploite la machine, qui répond quand elle tombe, ce que vous pouvez emporter, et ce que vous ne contrôlez plus.
C'est une question de répartition des responsabilités. Elle paraît abstraite tant que tout va bien, et elle devient parfaitement concrète un mardi matin, quand le site n'affiche plus rien.
Ce que « héberger un site » veut dire, en une minute
Un site n'est pas un document rangé quelque part. C'est un programme qui tourne : une machine allumée en permanence reçoit une demande, construit une page, l'envoie, et recommence quelques milliers de fois par mois sans que personne ne la regarde.
Pour que cela fonctionne, trois choses doivent exister en même temps. Une machine qui répond. Un nom de domaine qui pointe vers elle. Et quelqu'un qui maintient les deux en état — parce qu'un serveur reçoit des correctifs de sécurité, qu'un certificat expire, qu'un disque finit par tomber en panne et qu'un logiciel cesse un jour d'être compatible avec la version du langage qui le fait tourner.
C'est la troisième condition qui décide de tout. Héberger n'est pas un achat, c'est une activité continue. La bonne question n'a donc jamais été « combien coûte l'hébergement » mais « qui l'exerce » — et c'est de cette question que naissent les deux modèles.
Les deux modèles, et ce qui les sépare
L'hébergement souscrit à part. Vous ouvrez un contrat chez un hébergeur, vous y installez un logiciel de site, ou votre prestataire le fait pour vous, et vous devenez l'exploitant. L'hébergeur garantit que la machine répond ; ce qui tourne dessus vous regarde. C'est le modèle historique, celui de la quasi-totalité des sites bâtis sur un logiciel que l'on installe soi-même.
L'hébergement compris dans l'abonnement. Vous louez un outil, et l'éditeur exploite l'infrastructure pour l'ensemble de ses clients. Il n'y a pas de contrat d'hébergement à votre nom, pas de serveur à administrer, pas de version à choisir. Vous n'achetez pas une machine, vous achetez un service qui rend des pages.
Un troisième cas existe à mi-chemin : l'hébergement infogéré, où un prestataire administre pour vous une machine qui reste la vôtre. Il combine la souplesse du premier modèle et la tranquillité du second, à un prix qui reflète les deux. C'est une option sérieuse, rarement la plus économique pour un site vitrine.
Ce qui sépare les deux modèles n'est ni la vitesse, ni la fiabilité : un bon hébergement mutualisé et une plateforme sérieuse servent une page vitrine avec la même aisance. Ce qui les sépare est une liste de responsabilités, et cette liste mérite d'être écrite noir sur blanc. Le modèle de l'abonnement dépasse d'ailleurs la seule question de l'hébergement, comme le détaille ce que le site en abonnement achète vraiment.
Ce qui change vraiment : la liste des responsabilités
| Responsabilité | Hébergement souscrit à part | Hébergement compris |
|---|---|---|
| Choix du serveur et de la formule | Vous, ou votre prestataire | L'éditeur, sans intervention de votre part |
| Certificat de sécurité | À activer, puis à surveiller à chaque renouvellement | Émis et renouvelé automatiquement |
| Sauvegardes | À souscrire, à vérifier, à tester | Comprises, exécutées pour tous les clients à la fois |
| Mises à jour du logiciel du site | Vous, ou un contrat de maintenance | L'éditeur, en continu, sans version à choisir |
| Surveillance | Personne par défaut : un outil ou un prestataire | L'éditeur, sur toute la plateforme |
| Montée en charge en cas d'afflux | Changer de formule, parfois dans l'urgence | Absorbée par une infrastructure mutualisée |
| Restauration après incident | Vous ou votre prestataire, avec la sauvegarde disponible | L'éditeur, selon un délai annoncé |
| Interlocuteur en cas de panne | Deux à quatre, selon la nature du problème | Un seul |
Une lecture rapide donne l'impression que la colonne de droite gagne partout. C'est faux, et la suite de cet article dit précisément où elle perd. Mais il faut voir ce que la colonne du milieu suppose : une personne identifiée, disponible, compétente, et encore là dans deux ans. Dans beaucoup d'entreprises, cette personne n'existe pas — et le tableau devient alors la liste des choses que plus personne ne fait.
C'est le point aveugle du modèle séparé : il ne coûte pas cher tant qu'on ne l'exerce pas. La facture d'hébergement reste basse précisément parce que les tâches de cette colonne ne sont pas effectuées. Elles se paient plus tard, d'un coup, et le détail de ce qu'elles recouvrent est dans ce que couvre la maintenance d'un site.
La panne : la seule situation qui révèle le modèle choisi
Un site en bonne santé ne révèle rien du modèle qui le porte. Les deux se ressemblent, les deux affichent un cadenas, les deux sont assez rapides. La différence apparaît le matin où l'adresse renvoie une erreur et où le téléphone se met à sonner.
Dans le modèle séparé, la première difficulté n'est pas de réparer : c'est de savoir qui doit réparer. Un site peut tomber pour au moins quatre raisons distinctes. La machine ne répond plus. Le nom de domaine n'a pas été renouvelé. Le certificat a expiré. Une mise à jour a cassé une page. Chacune relève d'un interlocuteur différent, et chacun peut légitimement répondre que le problème n'est pas chez lui. L'hébergeur a raison : sa machine répond. Le prestataire a raison : il n'a rien touché depuis six mois. Pendant ce temps, le site reste éteint.
Dans le modèle compris, il n'y a qu'un numéro. C'est l'argument principal du modèle, et il est réel : l'éditeur ne peut renvoyer la responsabilité nulle part, puisqu'il détient toute la chaîne, du serveur au logiciel.
La contrepartie est tout aussi réelle : vous ne pouvez rien faire vous-même. Si la plateforme est en panne, vous attendez, et votre seule prise sur l'événement est un message d'information. Certains dirigeants préfèrent l'attente à l'enquête ; d'autres supportent très mal de n'avoir aucune main. Les deux réactions sont défendables, et c'est là le vrai critère de choix — bien plus que quelques euros par mois.
Une question vaut d'être posée dans les deux modèles, et d'obtenir une réponse écrite : quel délai est annoncé avant une réponse humaine, et à quelle heure ce délai commence-t-il ? Une assistance qui répond en quatre heures ouvrées répond en trois jours quand la panne survient un vendredi soir.
Les sauvegardes : ce qu'on croit avoir et ce qu'on a
Tout le monde a des sauvegardes. Très peu de gens savent ce qu'elles contiennent, qui peut les restaurer, et en combien de temps. Ce sont trois questions différentes, et le modèle d'hébergement décide de qui doit y répondre.
- Qui déclenche une restauration, et sous quel délai ? Dans le modèle séparé, c'est vous, ou un prestataire dont il faut d'abord obtenir la disponibilité. Dans le modèle compris, c'est l'éditeur, sur simple demande. La bonne réponse n'est pas « je peux le faire » : c'est un délai chiffré et une personne joignable aux heures où votre entreprise travaille.
- Que restaure-t-on exactement ? Les fichiers, la base de données, les deux ? Les documents envoyés depuis la dernière copie sont-ils inclus ? Une restauration qui ramène le site de la semaine dernière sans les demandes reçues depuis n'a pas les mêmes conséquences selon ce que votre site fait de ces demandes.
- Que vous reste-t-il si vous partez ? Une sauvegarde détenue par le seul fournisseur n'est pas la vôtre. La question à poser avant de souscrire, dans les deux modèles, est celle de l'export : sous quel format, à quelle fréquence, et facturé ou non. Une réponse évasive ici annonce une sortie compliquée.
Une remarque vaut les trois questions réunies : une restauration jamais exécutée est une hypothèse, pas une sauvegarde. Dans le modèle compris, l'opération est courante parce que l'éditeur la pratique pour l'ensemble de ses clients. Dans le modèle séparé, la première restauration a souvent lieu le jour de l'incident, ce qui est le pire moment pour découvrir qu'il manque une étape.
Le certificat de sécurité ne devrait jamais être une facture
Le certificat est ce qui fait passer votre adresse en https et fait disparaître l'avertissement du navigateur. Ce n'est pas un objet que l'on achète une fois : c'est une attestation qui expire, et qui doit être renouvelée régulièrement pour que le site continue de s'afficher normalement.
Sa panne est donc toujours la même. Un renouvellement automatique s'interrompt sans que personne ne le remarque, et les visiteurs se retrouvent devant un écran leur déconseillant d'entrer. L'effet sur les demandes est immédiat, et il dure aussi longtemps que le problème passe inaperçu — souvent plusieurs jours, parce que celui qui gère le site ne le visite pas comme un inconnu.
Dans le modèle compris, cette panne n'existe pratiquement pas : l'éditeur gère les certificats de tous ses clients avec le même mécanisme, et une défaillance se verrait sur des milliers de sites à la fois, donc immédiatement. Dans le modèle séparé, tout dépend d'une configuration faite une fois, il y a longtemps, par quelqu'un qui n'est peut-être plus là.
Reste la question de la facture. Un certificat destiné à un site vitrine est gratuit, délivré automatiquement et renouvelé sans intervention. Le voir apparaître en ligne facturée chaque année est le signe qu'on vous vend un automatisme comme s'il s'agissait d'un produit. Retenez la formulation qui compte ici : ce n'est pas une dépense, c'est une responsabilité — et il faut savoir laquelle des deux parties la porte.
Ce que l'hébergement compris vous fait perdre, honnêtement
Un article qui ne dirait que du bien du modèle compris serait une brochure. Voici ce qu'il vous retire, sans atténuation.
- L'accès au serveur. Pas de connexion directe aux fichiers, pas d'accès à la base de données, pas de tâche programmée que vous écrivez vous-même. Ce que la plateforme n'expose pas n'existe pas pour vous, et aucune insistance n'y changera rien.
- Le choix de l'infrastructure. Vous ne décidez ni du fournisseur d'hébergement, ni de la région où tournent les machines, ni du moment des interventions. Vous héritez des choix de l'éditeur, y compris de ses fenêtres de maintenance.
- Les réglages fins. Règles de cache, compression, en-têtes, redirections exotiques : ce qui n'est pas prévu dans l'interface ne se règle pas. Sur un site vitrine, cela n'a en général aucune conséquence, la lenteur venant presque toujours des images — sujet traité dans ce qui ralentit vraiment un site.
- Les logiciels tiers. Vous ne pouvez pas installer une bibliothèque, un module ou un composant qui ne fait pas partie de l'outil. C'est la limite la plus concrète du modèle, et celle qui fait qu'il ne convient pas à tout le monde.
À qui ces pertes manquent-elles réellement ? À trois profils, et ils sont identifiables à l'avance. Celui qui a un besoin technique précis : un traitement particulier, une connexion à un logiciel interne, une contrainte de sécurité imposée par un donneur d'ordres. Celui qui dispose déjà d'une équipe capable d'administrer, auquel cas déléguer coûte plus qu'il ne rapporte. Et celui dont le site n'est pas une vitrine mais une application.
À tous les autres — et c'est l'immense majorité des entreprises qui publient une vingtaine de pages — ces pertes restent théoriques. Perdre le droit de régler soi-même un serveur, c'est aussi perdre la possibilité de le casser un dimanche soir.
Un cas mérite d'être écarté au passage : les offres entièrement gratuites, où l'hébergement est compris parce que ce n'est pas vous le client. On y perd bien davantage que des réglages fins, souvent l'adresse elle-même. Ce que le gratuit vous prend détaille la différence, qui n'a rien à voir avec celle décrite ici.
La localisation des données, et pourquoi la question se pose
Un site vitrine collecte plus de données personnelles qu'on ne le croit. Le formulaire de contact enregistre des noms, des courriels et des numéros de téléphone. Les journaux du serveur conservent des adresses de connexion. Un outil de mesure de fréquentation dépose parfois des identifiants sur le navigateur du visiteur.
La question de la localisation se pose donc, et elle a deux volets. Le premier est simple : où tournent les serveurs, et où sont stockées les sauvegardes ? Les deux réponses diffèrent plus souvent qu'on ne l'imagine, et c'est la seconde qu'on oublie systématiquement de demander.
Le second volet est celui des sous-traitants. Une plateforme, quel que soit son modèle, s'appuie sur d'autres services : envoi de courriels, stockage de fichiers, mesure d'audience, outil d'assistance. Chacun voit passer une partie des données. Un fournisseur sérieux publie cette liste, et c'est elle qui vous permet de tenir votre propre documentation à jour.
Chaque modèle a ici son avantage. Le modèle compris n'a qu'un fournisseur à interroger, et la réponse est publique. Le modèle séparé vous fait choisir, donc vous savez. Ce qui n'est acceptable dans aucun des deux, c'est l'absence de réponse écrite à une question posée par écrit.
Sur la qualification juridique de vos traitements, sur ce que vous devez inscrire dans vos mentions et sur les obligations qui vous incombent, ce n'est pas un article de blog qu'il faut lire mais un professionnel du droit qu'il faut consulter. De notre côté, ce que nous traitons et où figure dans notre politique de confidentialité.
Déplacer un site d'un modèle à l'autre
Changer de modèle n'est pas un déménagement de serveur : c'est un changement d'outil. Ce qui se déplace n'est pas la machine, c'est le contenu.
Quatre choses passent d'un modèle à l'autre : les textes, les images, le nom de domaine et les adresses de page. Quatre choses ne passent pas : la configuration du serveur, les modules installés, le thème, et les développements faits sur mesure. C'est brutal à lire, et c'est la réalité de toute migration entre deux outils différents, dans un sens comme dans l'autre.
L'opération se prépare en trois temps. Reconstruire d'abord le site dans le nouvel outil, à une adresse temporaire, pendant que l'ancien continue de tourner normalement. Établir ensuite la liste exacte des adresses existantes et prévoir une redirection pour chacune. Basculer enfin le nom de domaine, et laisser l'ancien hébergement actif quelques semaines — c'est l'assurance la moins chère du secteur.
Le point qui décide du résultat n'est pas technique, il est méthodique : ce sont les redirections. Un site reconstruit à l'identique mais dont toutes les adresses ont changé repart de zéro aux yeux des moteurs. La marche à suivre complète est dans refaire son site sans perdre son référencement.
Un détail à ne pas oublier : les adresses de courriel professionnelles. Elles sont souvent fournies avec l'hébergement, rarement avec un abonnement à un outil de site, et un basculement mal préparé les fait disparaître avec des années de messages. Traitez-les séparément, et avant le reste.
Les questions à poser avant de choisir
Six questions suffisent, et elles tiennent dans un courriel. Les réponses écrites valent mieux que n'importe quel comparatif de caractéristiques.
- Qui exploite la machine qui sert mes pages, et au nom de qui le contrat est-il établi ?
- Un mardi à huit heures, le site est éteint : qui est-ce que j'appelle, et quel délai de réponse m'est annoncé par écrit ?
- Qui déclenche une restauration, sous quel délai, et cette restauration a-t-elle déjà été exécutée pour de vrai ?
- Où tournent les serveurs, où sont stockées les sauvegardes, et quels sous-traitants voient passer les données de mes formulaires ?
- Si je pars dans deux ans, qu'est-ce que j'emporte, sous quel format, et le nom de domaine est-il bien déposé à mon nom ?
- Qu'est-ce qui est compris dans le montant annoncé, et qu'est-ce qui apparaîtra en ligne séparée l'année prochaine ?
Une hésitation sur la cinquième question est en soi une réponse : elle dit que la sortie n'a pas été prévue, donc qu'elle sera coûteuse. Une réponse claire aux six, en revanche, vous renseigne davantage sur un fournisseur que trois pages de caractéristiques techniques.
Comment c'est fait chez Webcosa
Webcosa est un CMS en abonnement pour site vitrine, et l'hébergement fait partie de l'outil : il n'y a pas de contrat d'hébergement à côté, pas de certificat à renouveler, pas de version de plateforme à choisir ni à installer.
Ce qui est compris dans les deux formules : l'hébergement en Europe, le certificat de sécurité, les sauvegardes, les mises à jour de la plateforme, les thèmes du Store, et les demandes reçues par vos formulaires sans limite de nombre. Ni frais d'installation, ni commission sur ce que le site rapporte.
Les deux formules diffèrent surtout par le volume. Solo, à 29 € par mois ou 290 € à l'année, comprend 30 pages, un blog, 1 Go de fichiers et un nom de domaine personnalisé — le domaine et l'adresse professionnelle y sont proposés en option. Pro, à 59 € par mois ou 590 € à l'année, lève la limite de pages, monte à 3 blogs, 3 domaines et 20 Go, comprend le nom de domaine et l'adresse professionnelle, et ajoute les redirections d'anciennes adresses. Le comparatif ligne à ligne est sur la page des tarifs, et le détail de ce que fait l'outil sur la page des fonctionnalités.
La contrepartie est celle décrite plus haut, et nous n'allons pas prétendre l'inverse : vous n'avez pas d'accès au serveur, vous ne choisissez pas la région, et ce que l'interface n'expose pas ne se règle pas. En échange, il n'y a personne à appeler pour une mise à jour, un seul interlocuteur en cas de panne, et une seule facture par mois.
L'essai dure sept jours, sans carte bancaire, et le travail est conservé quatre-vingt-dix jours après l'expiration : de quoi comparer les deux modèles sur pièces plutôt que sur brochure.
Ce qu'il faut retenir
Héberger n'est pas un achat, c'est une activité continue : surveiller, mettre à jour, sauvegarder, restaurer, renouveler. Les deux modèles ne se distinguent pas par le prix mais par la personne qui exerce cette activité, et par ce qu'il advient quand cette personne n'est plus disponible.
L'hébergement souscrit à part vous laisse les commandes, donc la charge. Il convient à qui dispose d'une compétence disponible dans la durée, et il devient cher dès qu'il faut acheter cette compétence à l'extérieur. L'hébergement compris supprime la charge et retire les commandes : plus de serveur à administrer, mais plus de serveur à régler non plus.
Le test qui départage les deux tient en une scène. Le site est éteint, il est huit heures du matin, qui appelez-vous ? Si la réponse est claire dans le modèle séparé, gardez-le : il vous donne plus de liberté pour moins d'argent. Si elle ne l'est pas, le modèle compris n'achète pas de la performance, il achète un interlocuteur — et c'est ce que vous payez.
Trois vérifications valent, dans les deux cas, mieux qu'un comparatif : la localisation des serveurs et des sauvegardes, le format d'export de vos contenus, et le nom du titulaire du domaine. Les montants, eux, sont détaillés poste par poste dans l'article consacré au coût de l'hébergement.
Questions fréquentes sur l'hébergement compris
Dans un CMS hébergé, oui, par construction : c'est l'éditeur qui exploite les serveurs pour l'ensemble de ses clients, et il n'existe pas de contrat d'hébergement à votre nom. Dans un logiciel que l'on installe soi-même, non : le logiciel peut être gratuit, la machine se souscrit à part. La question à poser à tout prestataire est simple : le montant annoncé est-il un total, ou l'une des factures que je vais recevoir ?
La différence n'est pas technique, elle est contractuelle. Avec un hébergement souscrit à part, vous êtes l'exploitant : l'hébergeur garantit que la machine répond, et tout ce qui tourne dessus vous incombe. Avec un hébergement compris, l'éditeur exploite l'ensemble et répond de tout. La première formule vous laisse le choix du serveur, des réglages et de la localisation ; la seconde vous laisse un seul interlocuteur et rien à administrer.
Cela dépend de la cause, et c'est précisément le problème du modèle séparé. Une machine qui ne répond plus relève de l'hébergeur, un domaine non renouvelé du bureau d'enregistrement, un certificat expiré de la configuration, une page cassée d'une mise à jour. Chacun peut légitimement dire que le problème n'est pas chez lui pendant que le site reste éteint. Avec un hébergement compris, il n'y a qu'un interlocuteur, et il ne peut renvoyer la responsabilité nulle part.
Non, et une offre qui facturerait les deux mérite une explication écrite. Dans un abonnement à un CMS hébergé, le serveur, le certificat, les sauvegardes et les mises à jour de la plateforme font partie du prix. Ce qui reste éventuellement à part, c'est le nom de domaine, qui est une location d'adresse auprès d'un registre indépendante de la machine, et les adresses de courriel professionnelles, que tous les éditeurs ne fournissent pas.
Oui, à trois conditions qu'il faut vérifier avant d'entrer, pas au moment de sortir. Vos textes et vos images doivent être exportables dans un format lisible ailleurs. La liste de vos adresses de page doit être récupérable, pour prévoir des redirections. Et le nom de domaine doit être déposé au nom de votre entreprise, puisque c'est lui qui vous rend libre de pointer où vous voulez. Si ces trois conditions sont remplies, une sortie coûte du temps de recopie, pas une négociation.
Là où l'éditeur a placé son infrastructure, et c'est une information qui doit être publique. Demandez deux choses plutôt qu'une : la localisation des serveurs et celle des sauvegardes, car elles diffèrent parfois. Demandez également la liste des sous-traitants qui voient passer les données, envoi de courriels et mesure d'audience compris. Chez Webcosa, l'hébergement est en Europe, et le détail figure dans notre politique de confidentialité.
Pour un site vitrine, non. La vitesse perçue d'une page dépend d'abord du poids des images et du nombre de scripts chargés, très rarement de la puissance de la machine : un serveur dédié servira une page trop lourde exactement aussi lentement. Le serveur dédié devient utile quand un site calcule beaucoup à chaque visite, ce qui n'est pas le cas d'un site de prestations dont les pages sont mises en cache une fois pour toutes.
L'éditeur, pour tous ses clients à la fois, ce qui est aussi la raison pour laquelle le mécanisme est éprouvé plutôt que théorique. Trois questions restent à poser malgré tout : qui déclenche une restauration et sous quel délai, ce qu'elle ramène exactement, et ce que vous pouvez exporter vous-même. La troisième est la plus importante à long terme, car une sauvegarde détenue uniquement par le fournisseur ne vous appartient pas.
Oui. Le nom de domaine est indépendant de la machine qui sert les pages : il suffit de le faire pointer vers la nouvelle plateforme, opération qui prend quelques heures à se propager. Vous n'êtes pas tenu de le transférer chez le nouveau fournisseur, et il est même souvent préférable de le laisser où il est, à condition que le titulaire déclaré soit bien votre entreprise et que le renouvellement automatique soit actif.
Dans la grande majorité des cas, oui : un site de vingt à trente pages ne consomme presque rien, et ce qu'il demande n'est pas de la puissance mais de l'exploitation régulière. Le modèle ne convient pas lorsque le site doit se connecter à un logiciel interne, exécuter des traitements particuliers ou respecter une contrainte imposée par un donneur d'ordres. Ces besoins-là s'identifient à l'avance, et ils ne concernent pas un site de prestations ordinaire.