Hébergement web infogéré à Paris

L’hébergement fournit l’infrastructure. L’infogérance ajoute l’exploitation : supervision, mises à jour, sauvegardes testées, interventions et suivi des incidents.

La distinction se paie dans les deux sens. Un hébergement seul coûte de dix à quelques centaines d’euros par mois selon la taille et vous laisse tout le reste : personne ne regarde les alertes, n’applique les correctifs du système, ne vérifie que la sauvegarde s’exécute. Beaucoup de sites tournent ainsi pendant des années sans incident, puis en concentrent plusieurs la même semaine.

L’infogérance ajoute un destinataire aux alertes et un délai d’intervention écrit. Ce qu’elle achète réellement n’est pas la disponibilité — un bon hébergeur mutualisé tient des taux très corrects — mais le temps de rétablissement quand quelque chose casse, et le fait que la restauration ait été testée avant d’en avoir besoin.

Le repère pour choisir : si une journée d’indisponibilité vous coûte plus que douze mois d’infogérance, la question est tranchée. Sinon, un hébergement soigné et des sauvegardes vérifiées suffisent, et nous le disons.

En fonction du trafic, du type d’application, des pics, des besoins de cache, des services tiers et du niveau de disponibilité attendu.

En pratique, trois configurations couvrent presque tout. Un serveur unique avec cache et sauvegardes externalisées convient à un site éditorial ou une boutique jusqu’à quelques milliers de visiteurs par jour ; c’est la configuration la moins chère et la plus simple à restaurer. Une séparation application et base de données devient utile dès que le catalogue grossit ou que les requêtes se complexifient. Une répartition sur plusieurs machines ne se justifie que lorsque l’indisponibilité de quelques minutes a un coût mesurable.

Nous commençons volontairement par la configuration la plus simple qui tienne la charge mesurée, avec de la marge. Une architecture dimensionnée pour un trafic espéré coûte chaque mois et complique chaque intervention.

Ce qui décide plus que le trafic : la nature des pics. Mille visiteurs réguliers ne demandent rien ; mille visiteurs en dix minutes après un passage radio demandent un cache en amont, et c’est un réglage plutôt qu’une machine de plus.

En France ou dans l’Union européenne selon vos exigences, avec les engagements contractuels et les localisations précisées dans le contrat.

La localisation seule ne suffit pas à répondre à la question qu’on pose vraiment, qui est celle de la juridiction. Un centre de données situé à Paris mais exploité par une filiale d’un groupe soumis à une législation extra-européenne n’offre pas la même garantie qu’un hébergeur de droit français ou européen. Nous précisons donc les deux : où sont les machines, et sous quel droit se trouve l’entité qui les opère.

Pour la plupart des projets, un hébergeur français ou européen convient et coûte le même prix qu’une offre internationale. Quand votre activité impose davantage — santé, secteur public, données sensibles —, il existe des offres qualifiées et nous les nommons, avec leur surcoût réel.

Les sauvegardes suivent la même règle et c’est le point qu’on oublie : héberger en France et sauvegarder ailleurs annule la démarche. Le contrat précise la localisation des deux.

Sauvegardes régulières, externalisées, avec rétention définie et tests de restauration documentés afin de garantir la reprise réelle en cas d’incident.

Le schéma courant : une sauvegarde quotidienne conservée un mois, une hebdomadaire conservée trois mois, stockées chez un fournisseur distinct de l’hébergeur. Cette séparation est le point essentiel : une sauvegarde qui vit sur la même machine que le site disparaît avec elle, et une sauvegarde chez le même fournisseur disparaît avec le compte si celui-ci est suspendu.

La rétention se décide par la durée pendant laquelle un problème peut passer inaperçu. Une base corrompue se voit en heures ; un contenu supprimé par erreur se découvre parfois trois semaines plus tard. Un mois de rétention quotidienne couvre ces deux cas.

Et la sauvegarde est restaurée pour de vrai, à intervalle régulier, sur un environnement séparé. C’est la seule vérification qui vaut : un fichier peut être tronqué, incomplet, ou ne pas contenir la base. Le compte rendu du test, avec sa date et sa durée, vous est transmis.

Oui après audit. L’analyse porte sur la configuration, les versions, les accès, les sauvegardes et les risques éventuels avant toute intervention.

Ce que l’audit cherche en priorité : les versions de langage et de base et leur fenêtre de support, car une version en fin de vie impose un calendrier ; l’existence d’un environnement de préparation, sans lequel aucune intervention n’est sûre ; la réalité des sauvegardes, qui sont souvent configurées et jamais vérifiées ; et les accès, dont une partie appartient régulièrement à un ancien prestataire.

La reprise sans migration est fréquente et préférable quand la configuration tient : nous prenons l’exploitation en main là où le site se trouve, sans le déplacer. Cela évite un risque inutile.

Quand la migration est nécessaire, elle se prépare comme une bascule de site : copie, vérification, abaissement de la durée de vie du DNS quelques jours avant, puis bascule avec l’ancien environnement conservé. Comptez une demi-journée d’indisponibilité potentielle, souvent moins, et un retour arrière possible pendant une semaine.

Par le cache, l’optimisation des ressources, le dimensionnement adapté et, lorsque nécessaire, des mécanismes d’élasticité selon la nature de l’application.

La première réponse à un pic n’est presque jamais d’ajouter des machines : c’est de ne pas exécuter le site pour chaque visiteur. Une page éditoriale identique pour tous doit être servie depuis un cache en amont, et une machine modeste encaisse alors des dizaines de milliers de vues à l’heure. Les sites qui s’écroulent sous un passage presse sont presque toujours des sites sans cache de page.

Le cache devient plus délicat sur une boutique, où le panier et les prix personnalisés ne doivent pas être partagés. On sépare donc ce qui est cachable du reste, et c’est un travail d’intégration autant que d’infrastructure.

L’élasticité — ajouter automatiquement des ressources — a un intérêt réel sur les applications à charge très variable, et un coût de complexité. Nous la proposons quand le profil de trafic le justifie, pas par principe. Un pic annoncé se prépare mieux par un dimensionnement temporaire que par un mécanisme permanent.

Nous identifions l’origine, appliquons les contournements possibles, informons et suivons le rétablissement auprès du fournisseur concerné.

Le premier travail est le diagnostic, et il est moins évident qu’il paraît : un paiement qui échoue peut venir de la passerelle, du module qui l’appelle, d’un certificat expiré côté site, ou d’une règle antifraude déclenchée chez le prestataire. Confondre les quatre fait perdre des heures. Nous vérifions donc dans cet ordre, à partir des journaux.

Les contournements existent plus souvent qu’on ne le croit : basculer sur un second moyen de paiement, mettre en file les commandes pour les rejouer, désactiver temporairement une fonction qui dépend du service en panne plutôt que de laisser la page en erreur. Ces dispositifs se préparent avant, pas pendant.

Ce que nous ne pouvons pas faire : accélérer le rétablissement chez un fournisseur tiers. Nous suivons son canal d’incident, nous vous tenons informés avec des faits, et nous documentons l’événement. Un contrat qui promet mieux promet quelque chose qu’il ne maîtrise pas.

Oui. Les configurations, procédures et accès sont documentés pour permettre une migration sans dépendance imposée.

Ce qui rend une migration possible se décide à l’installation. Une configuration écrite dans des fichiers versionnés plutôt que cliquée dans une interface propriétaire se rejoue ailleurs. Des sauvegardes dans un format standard se restaurent ailleurs. Un nom de domaine enregistré à votre nom se pointe ailleurs. À l’inverse, un site qui dépend de services spécifiques à un fournisseur — sa base gérée, son stockage, ses fonctions — se déplace au prix d’un développement.

Nous documentons donc la configuration, la procédure de déploiement et la liste des dépendances externes dès la mise en place, et cette documentation vous est remise. Elle sert le jour où vous changez d’hébergeur, et aussi le jour où vous changez d’agence.

Un point à vérifier dans tout contrat, y compris le nôtre : au nom de qui sont enregistrés le domaine et les comptes d’hébergement. C’est la dépendance la plus simple à créer et la plus pénible à défaire.