Le jour où le site est en ligne, tout le monde se détend

Il y a un moment très précis dans la vie d'un projet web où la tension retombe : le site est en ligne, il est beau, le client est content, moi aussi. On se serre la main (ou on s'envoie un message de félicitations si le projet s'est fait à distance), et chacun repart de son côté.

C'est exactement le moment où, pour beaucoup de sites, les vrais problèmes commencent à se préparer en silence.

Pas tout de suite. Pas la semaine d'après. Mais six mois, un an, deux ans plus tard, quand plus personne n'y pense : un site qui devient lent, un plugin qui n'a pas été mis à jour depuis trois ans, un formulaire de contact piraté et transformé en relais de spam, ou pire — un site totalement inaccessible, sans aucune sauvegarde récente pour le remettre en ligne.

Je vois passer ce genre de situations régulièrement, souvent chez des indépendants ou des petites entreprises qui ont fait développer leur site il y a plusieurs années, par quelqu'un qui a livré le projet puis a disparu de la circulation. Ce n'est pas de la malchance. C'est la conséquence directe d'un malentendu très répandu : on pense qu'un site web, une fois en ligne, tourne tout seul. Ce n'est pas le cas. Jamais.

Cet article a pour but de démystifier trois mots qu'on entend souvent sans vraiment savoir ce qu'ils recouvrent concrètement : hébergement, sécurité, sauvegardes. Et d'expliquer pourquoi les négliger revient presque toujours plus cher que de s'en occuper sérieusement dès le départ.

L'hébergement, ce n'est pas juste "avoir une adresse sur internet"

Quand on me demande ce qu'est l'hébergement, la comparaison qui revient le plus souvent dans ma bouche, c'est celle du local commercial. Un site web, ce sont des fichiers, du code, des images, une base de données parfois. Tout ça doit être stocké quelque part, sur un serveur, une machine allumée en permanence, connectée à internet, qui répond aux visiteurs quand ils tapent votre adresse.

L'hébergement, c'est ce local. Et comme pour un vrai local commercial, tous les locaux ne se valent pas.

Il y a des hébergements bas de gamme, mutualisés à l'extrême, où votre site partage les ressources d'un même serveur avec des centaines d'autres sites. Le jour où l'un de ces sites voisins se fait pirater ou reçoit un pic de trafic massif, c'est parfois tout le serveur qui ralentit ou plante — et votre site avec, sans que vous n'y soyez pour rien.

Il y a aussi des hébergements plus sérieux, mieux dimensionnés, avec un vrai support technique, des mises à jour de sécurité régulières sur les serveurs eux-mêmes, une infrastructure pensée pour encaisser les pics de trafic sans s'effondrer.

La différence de prix entre les deux peut sembler minime au premier abord — quelques dizaines d'euros par an. Mais la différence d'expérience, elle, est énorme. Un hébergement mal choisi, c'est un site qui met huit secondes à charger (et que Google pénalise pour ça), qui plante pendant les périodes où vous avez justement besoin qu'il tienne — soldes, lancement d'un produit, campagne publicitaire —, ou qui devient une porte d'entrée facile pour des attaques automatisées.

Je choisis toujours l'hébergement de mes clients avec le même sérieux que le reste du projet. Ce n'est pas un détail technique qu'on case à la fin, c'est une fondation.

La sécurité : ce n'est pas une question de "est-ce que je suis une cible intéressante"

Beaucoup de gens pensent qu'ils ne risquent rien parce que leur site n'a "rien d'intéressant à voler". C'est un raisonnement qui se tient... si on part du principe que les pirates s'attaquent aux sites un par un, à la main, en évaluant leur intérêt. Ce n'est presque jamais le cas.

La grande majorité des attaques sur les petits sites sont automatisées. Des robots scannent en permanence des millions d'adresses web à la recherche de failles connues : une version de plugin obsolète, un mot de passe faible, une porte laissée entrouverte dans le code. Ces robots ne savent pas si votre site est celui d'un plombier à Uccle ou d'une multinationale. Ils cherchent juste des serrures faciles à crocheter.

Une fois qu'ils sont entrés, l'objectif n'est presque jamais de "voler" quelque chose de précieux sur votre site. C'est souvent d'utiliser votre serveur comme relais : envoyer du spam en masse, héberger discrètement des pages de phishing, insérer des liens invisibles vers d'autres sites pour tricher avec Google, ou rediriger vos visiteurs vers des sites douteux sans même que vous vous en rendiez compte immédiatement.

Ce qui rend ce genre de situation particulièrement désagréable, c'est qu'on ne s'en aperçoit souvent pas tout de suite. Le site a l'air normal. Et puis un jour, Google affiche un bandeau "Ce site peut nuire à votre ordinateur" devant vos visiteurs, ou votre hébergeur suspend le compte parce que le serveur envoie des milliers de mails de spam par heure. Là, c'est la panique — et c'est le pire moment pour découvrir qu'on n'a pas de sauvegarde propre à restaurer.

Concrètement, une sécurité sérieuse pour un site, ça repasse par des choses simples mais qui demandent du suivi dans la durée :

  • Maintenir à jour le CMS et ses extensions (Joomla, dans mon cas, mais le principe est le même partout)
  • Utiliser des mots de passe robustes et les renouveler
  • Limiter les tentatives de connexion pour bloquer les attaques automatisées
  • Surveiller les fichiers du site pour détecter une intrusion rapidement
  • Configurer correctement le serveur pour fermer les portes inutiles

Aucune de ces actions n'est spectaculaire. C'est justement pour ça qu'on les oublie.

Les sauvegardes : le filet de sécurité qu'on ne teste jamais avant d'en avoir besoin

S'il y a une chose que j'ai apprise en accompagnant des clients dans la durée, c'est que tout le monde pense avoir des sauvegardes... jusqu'au jour où il faut vraiment les utiliser.

Une sauvegarde, ce n'est pas juste "le site existe quelque part". C'est une copie complète et récente du site — fichiers et base de données — stockée dans un endroit différent du serveur principal, prête à être restaurée rapidement en cas de problème.

Je dis bien "stockée ailleurs", parce que c'est un point sur lequel beaucoup de gens se trompent. Une sauvegarde qui vit sur le même serveur que le site ne protège de rien en cas de piratage sérieux, de panne matérielle, ou si l'hébergeur ferme le compte pour une raison ou une autre. C'est comme garder la copie de ses clés de maison... collée à la porte d'entrée.

Les cas où une sauvegarde solide fait toute la différence sont plus fréquents qu'on ne le pense :

  • Une mise à jour de plugin qui casse tout le site du jour au lendemain
  • Une erreur de manipulation (ça arrive à tout le monde, moi y compris)
  • Un piratage qui corrompt les fichiers ou la base de données
  • Un problème matériel chez l'hébergeur
  • Une suppression accidentelle de contenu par un client qui gère lui-même son site

Dans tous ces cas, la question n'est pas "est-ce grave" mais "depuis combien de temps ma dernière sauvegarde propre date-t-elle". Si la réponse est "je ne sais pas" ou "il y a huit mois", le problème n'est plus technique, il devient un vrai problème business : des mois de contenu, de commandes, d'articles, de mises à jour perdus définitivement.

Je mets en place des sauvegardes automatiques régulières pour tous les sites que j'accompagne, avec une conservation sur plusieurs points dans le temps — pas juste "la dernière version", mais un historique qui permet de revenir en arrière si le problème n'a été détecté que plusieurs jours après.

Pourquoi négliger tout ça coûte plus cher, concrètement

Je ne vais pas vous faire le coup de la peur pour vous vendre un contrat de suivi. Mais je peux vous donner des chiffres et des situations réelles, parce que c'est plus parlant qu'un discours général.

Scénario 1 : le site piraté sans sauvegarde récente. J'ai déjà été contacté par des personnes dans cette situation — pas des clients à moi à l'origine, mais des gens qui cherchaient de l'aide en urgence. Le site est piraté, l'hébergeur a suspendu le compte, et la dernière sauvegarde disponible date de plus d'un an. Résultat : soit on reconstruit une bonne partie du site depuis zéro, soit on paie très cher un service de nettoyage et de récupération de données, avec un résultat jamais garanti à 100%. Le coût final dépasse largement ce qu'aurait coûté un suivi sérieux pendant toutes ces années.

Scénario 2 : le site lent à cause d'un hébergement bas de gamme. Moins spectaculaire, mais tout aussi coûteux sur la durée. Un site qui charge lentement perd des visiteurs (les études sur le sujet sont unanimes : au-delà de 3 secondes de chargement, une part significative des visiteurs quitte la page) et est pénalisé par Google dans les résultats de recherche. Concrètement : moins de trafic, moins de conversions, un référencement qui stagne — pour économiser quelques dizaines d'euros par an sur l'hébergement.

Scénario 3 : le CMS jamais mis à jour. Au fil des années, les mises à jour de sécurité s'accumulent. Un CMS qui a pris trop de retard devient parfois impossible à mettre à jour "en douceur" : il faut migrer, adapter le design qui casse avec la nouvelle version, parfois même tout reconstruire. Ce qui aurait coûté quelques dizaines d'euros de suivi régulier devient un projet de plusieurs centaines, voire milliers d'euros, de remise à niveau complète.

Dans les trois cas, le point commun est le même : le coût ne disparaît jamais, il se déplace. On économise sur l'entretien régulier, mais on paie plus cher — et souvent dans l'urgence, avec moins de contrôle — quand le problème finit par arriver.

Ce que je mets en place concrètement chez InWeb

Je ne livre jamais un site en considérant que mon travail s'arrête à la mise en ligne. Pour moi, l'hébergement, la sécurité et les sauvegardes font partie intégrante de la responsabilité que je prends en développant un site pour quelqu'un.

Concrètement, voici ce que ça signifie dans mon accompagnement :

Un hébergement choisi, pas subi. Je ne recommande jamais un hébergement uniquement parce qu'il est le moins cher du marché. Je choisis une infrastructure adaptée à la taille et aux besoins réels du site : un site vitrine simple n'a pas besoin de la même puissance qu'une boutique en ligne qui traite des commandes chaque jour, mais tous les deux ont besoin d'un hébergement fiable et réactif.

Des sauvegardes automatiques, régulières, et vérifiées. Pas juste "activées et oubliées" — je m'assure qu'elles fonctionnent réellement et qu'elles sont exploitables en cas de besoin. Une sauvegarde qu'on n'a jamais testée n'est qu'une illusion de sécurité.

Une veille de sécurité continue. Mises à jour du CMS et des extensions, surveillance des accès, configuration du serveur pour limiter les points d'entrée. Ce n'est pas quelque chose que je fais une fois puis j'oublie — c'est un travail de fond, discret, qui ne se voit que quand il évite un problème.

Un seul interlocuteur pour tout ça. Si un problème survient, vous ne devez pas jongler entre l'hébergeur, le développeur du site et un prestataire de sécurité qui ne se connaissent pas et se renvoient la responsabilité. Vous m'appelez, ou vous m'écrivez, et je m'occupe de comprendre et résoudre le problème — que ce soit moi qui aie développé le site à l'origine ou non, d'ailleurs.

Et si mon site existe déjà, chez un autre prestataire ?

Cette question revient souvent, et la réponse est simple : ce n'est pas un problème. Je peux tout à fait reprendre le suivi d'un site existant, faire un état des lieux honnête de sa situation actuelle — hébergement, niveau de sécurité, présence ou absence de sauvegardes fiables — et remettre les choses à niveau progressivement, sans tout casser ni tout reconstruire si ce n'est pas nécessaire.

Dans certains cas, un simple changement d'hébergement et la mise en place de sauvegardes suffisent à sécuriser durablement la situation. Dans d'autres, plus rares, le site a pris tellement de retard techniquement qu'une reconstruction devient effectivement la solution la plus raisonnable à moyen terme. Je le dis clairement quand c'est le cas — jamais pour vendre plus gros, mais parce que c'est parfois vraiment la meilleure option économique sur la durée.

Ce que ça coûte, concrètement

Je sais que la question du budget est toujours présente, et je préfère être transparent plutôt que de rester vague.

Le coût d'un accompagnement en hébergement, sécurité et sauvegardes varie selon la taille et la complexité du site — un site vitrine simple n'a pas les mêmes besoins qu'une boutique en ligne ou qu'une application avec base de données. Ce que je peux dire, c'est que ce coût reste toujours très inférieur à celui d'une reconstruction en urgence après un piratage, ou à celui d'une perte de trafic prolongée à cause d'un site trop lent.

Si vous faites développer un site chez moi, cet aspect est pensé dès la conception, pas ajouté après coup en option. Si vous avez déjà un site ailleurs et que vous vous demandez où vous en êtes réellement sur ces questions, je peux aussi faire un diagnostic simple et honnête de la situation actuelle, sans engagement.

Les bonnes questions à se poser dès aujourd'hui

Que vous soyez client chez moi, chez un autre prestataire, ou que vous ayez fait votre site vous-même, voici quelques questions simples qui permettent de savoir rapidement où vous en êtes réellement :

  • Ai-je une sauvegarde de mon site datant de moins d'une semaine, stockée ailleurs que sur le serveur du site lui-même ?
  • Est-ce que je sais qui est responsable de la sécurité de mon site aujourd'hui ? Est-ce que quelqu'un s'en occupe activement, ou est-ce que "ça tourne tout seul" depuis la mise en ligne ?
  • Mon CMS et mes extensions sont-ils à jour ? Depuis quand ne les ai-je pas vérifiés ?
  • Est-ce que je sais chez quel hébergeur mon site tourne, et si cet hébergement est adapté à mes besoins actuels — pas ceux d'il y a trois ans ?

Si une seule de ces questions vous met mal à l'aise, ce n'est pas une raison de paniquer. C'est simplement le signe qu'il est temps de remettre un peu d'ordre dans les fondations, avant que le problème ne se rappelle à vous au pire moment possible.

Parlons-en simplement

Si vous vous reconnaissez dans une de ces situations — un site qui vous semble à l'abandon côté technique, une inquiétude sur vos sauvegardes, ou simplement le sentiment que "personne ne s'occupe vraiment de ça" — le plus simple est d'en discuter directement. Je fais un état des lieux honnête, sans jargon et sans vous pousser vers une solution surdimensionnée par rapport à vos besoins réels.

Vous pouvez me contacter que vous soyez à Bruxelles ou ailleurs en Belgique, en présentiel ou entièrement à distance : c'est le contenu de l'accompagnement qui compte, pas le lieu où on en parle. N'attendez pas le message d'alerte de votre hébergeur ou le bandeau rouge de Google pour vous poser la question — c'est justement ce moment-là que je vous propose d'éviter. et voila ;-)