TL;DRConfier un serveur à un prestataire ne veut pas dire s'en désintéresser : tout dépend de ce que le contrat couvre réellement. Voici comment lire une offre d'infogérance et savoir si votre situation la justifie.
Infogérance serveur : de quoi parle-t-on exactement ?#
L'infogérance (ou infogérance de serveurs, en anglais managed services) consiste à confier à un prestataire l'administration courante d'un serveur ou d'une infrastructure. Le serveur peut être physique, virtuel (VPS) ou loué chez un hébergeur ; le principe reste le même : quelqu'un d'autre que vous se charge de le maintenir en état, de le surveiller et d'intervenir quand il dysfonctionne.
Le mot recouvre des réalités très différentes selon les prestataires. Certains vendent une simple supervision qui envoie une alerte, d'autres prennent en charge l'ensemble du cycle de vie du serveur. C'est pourquoi la première question n'est pas « faut-il de l'infogérance ? » mais « qu'est-ce qui est écrit dans le périmètre ? ».
Chez Websource, l'infogérance de serveurs porte sur l'administration d'un serveur existant (Debian ou CentOS), que nous en soyons l'hébergeur ou non. Elle est distincte de l'hébergement infogéré, où le site est hébergé sur nos propres serveurs. Les deux peuvent se combiner selon la situation.
Ce que couvre en général l'infogérance#
Le périmètre typique se décompose en huit briques. Un prestataire n'est pas tenu de toutes les proposer : c'est justement ce qu'il faut vérifier avant de signer.
- Supervision et monitoring : suivi de la charge, de l'espace disque, de la mémoire et de la disponibilité des services, avec des seuils d'alerte définis.
- Mises à jour et correctifs de sécurité : application régulière des correctifs du système d'exploitation et des services (serveur web, PHP, base de données).
- Sauvegardes et tests de restauration : planification des sauvegardes, contrôle de leur bon déroulement et, idéalement, vérification périodique qu'elles se restaurent réellement.
- Durcissement : configuration du pare-feu, désactivation des services inutiles, réglages de sécurité des accès distants.
- Gestion des accès : création et retrait des comptes, clés SSH, séparation des droits d'administration.
- Alerting et journalisation : conservation des journaux système et détection des comportements anormaux.
- Support : un interlocuteur pour les demandes courantes (ajout d'un site, changement de version de PHP, renouvellement de certificat).
- Gestion d'incident : diagnostic et correction en cas de panne, de charge anormale, de faille détectée ou de tentative d'intrusion.
Ce que l'infogérance ne couvre pas (sauf mention contraire)#
La confusion la plus fréquente concerne la frontière entre le serveur et ce qui tourne dessus. Sauf clause explicite, une infogérance de serveur ne couvre pas :
- Le code applicatif : un bug dans votre site, un plugin WordPress obsolète ou un module PrestaShop vulnérable relèvent de la maintenance applicative, pas de l'administration système. Les deux métiers sont voisins, mais ils ne sont pas interchangeables.
- Les contenus : textes, images, catalogue, référencement.
- La conformité juridique : registre des traitements, mentions légales, politique de confidentialité, bandeau cookies. Le prestataire peut vous aider techniquement, mais la responsabilité de conformité reste celle de l'organisation qui traite les données.
La règle pratique : tout ce qui n'est pas écrit dans le périmètre est présumé hors contrat. Demandez une liste des exclusions aussi précise que la liste des inclusions.
Mutualisé, VPS nu, serveur infogéré, cloud managé : le comparatif#
L'infogérance s'inscrit dans un spectre d'options. Le tableau ci-dessous les compare sur ce qui compte vraiment : qui fait quoi.
| Option | Ce que fournit l'hébergeur | Ce qui reste à votre charge | Adaptée à |
|---|---|---|---|
| Hébergement mutualisé | Serveur partagé, panneau de gestion, mises à jour de la plateforme | Votre site et son code, vos mises à jour applicatives, la vérification des sauvegardes | Site vitrine ou blog à faible criticité |
| VPS ou serveur dédié « nu » (non géré) | Ressources matérielles ou virtuelles, accès root | Tout l'entretien système : correctifs, pare-feu, sauvegardes, supervision, incidents | Équipe technique disposant de compétences système et de temps |
| Serveur infogéré | Ressources, plus administration déléguée selon le périmètre contractuel | Le code applicatif, les contenus, la conformité, sauf mention contraire | Site ou application important sans équipe système interne |
| Cloud managé | Services gérés (base de données, stockage, orchestration) exploités par le fournisseur | L'architecture, la configuration des services, les coûts d'usage, la sécurité côté client | Applications conçues pour le cloud, montée en charge variable |
Les deux ne s'excluent pas : on peut faire infogérer un VPS chez un hébergeur cloud, et dans le cloud le fournisseur opère l'infrastructure mais pas votre configuration. Voir notre article sur l'hébergement cloud souverain et notre explication du mutualisé.
Si votre question est « infogérance ou mutualisé ? », le critère central est la marge de manœuvre. Le mutualisé est économique et simple, mais vous ne choisissez ni la configuration du système ni les versions de tous les composants. L'infogérance sur serveur dédié ou VPS redonne cette maîtrise, sans vous imposer de l'exercer vous-même. Nous avons détaillé cette différence dans notre comparatif des hébergements mutualisés et de l'hébergement infogéré.
Les signaux qui indiquent qu'il est temps de passer à l'infogérance#
Aucun seuil universel n'existe, mais plusieurs situations reviennent quand un projet dépasse le stade du « ça tourne tout seul ».
Le site est devenu un outil de travail#
Si une heure d'indisponibilité fait perdre des ventes, des demandes de devis ou de la crédibilité, la question n'est plus technique mais économique. Un e-commerce en pleine période de forte activité n'a pas le même profil de risque qu'un site institutionnel consulté quelques fois par semaine.
Les incidents se répètent#
Disque saturé, certificat expiré, base de données qui plante, pic de charge non anticipé : quand vous découvrez les pannes par vos clients, c'est que la supervision manque.
Personne en interne ne maîtrise l'administration système#
Le prestataire web qui a créé le site n'est pas forcément administrateur système. Si le serveur est un « héritage » que personne n'ose toucher, ou si les mises à jour ne sont plus faites depuis des mois, le risque s'accumule en silence.
La sécurité et les données personnelles entrent en jeu#
Dès que le serveur héberge des données de clients, de patients, d'adhérents ou de salariés, la sécurité n'est plus optionnelle. Le RGPD impose des mesures de sécurité adaptées au risque ; un serveur non corrigé et sans sauvegarde testée est difficile à défendre en cas d'incident.
À l'inverse, si votre site est un blog ou une vitrine sans enjeu fort, un bon hébergement mutualisé bien entretenu suffit souvent.
Les notions de service à connaître avant de lire un contrat#
Un contrat d'infogérance s'appuie sur quelques sigles. Mieux vaut les maîtriser que de les découvrir au premier incident.
- SLA (Service Level Agreement) : la partie du contrat qui définit les engagements mesurables du prestataire. Sans engagements chiffrés et sans conséquence en cas de non-respect, il ne s'agit que d'une intention.
- GTI (garantie de temps d'intervention) : délai entre le signalement d'un incident et sa prise en charge par un technicien.
- GTR (garantie de temps de rétablissement) : délai entre le signalement et le retour à un fonctionnement normal. Vérifiez si le décompte s'applique en heures ouvrées ou en continu.
- RPO (Recovery Point Objective) : durée maximale de perte de données acceptable en cas de sinistre, exprimée en unité de temps (par exemple « quatre heures de données »). Il dépend directement de la fréquence des sauvegardes.
- RTO (Recovery Time Objective) : durée maximale d'interruption acceptable en cas de sinistre. Il dépend du temps réel de restauration, qu'on ne connaît qu'en le testant.
La disponibilité annoncée mérite aussi qu'on la traduise en durée. À titre d'illustration donnée par la documentation Microsoft, une disponibilité de 99,9 % correspond à environ 43 minutes d'indisponibilité tolérée par mois. Demandez sur quelle période elle est mesurée : le même pourcentage n'autorise pas la même durée d'arrêt selon qu'on le calcule par mois ou par an.
Sur les sauvegardes, la CNIL recommande des sauvegardes fréquentes, dont au moins une stockée sur un site géographiquement distinct, une copie isolée hors ligne, et des tests réguliers d'intégrité et de restauration. Elle cite la règle dite 3-2-1 : trois copies des données, sur deux supports différents, dont une hors ligne. L'ANSSI formule une recommandation voisine et insiste sur le fait qu'une sauvegarde non testée est une hypothèse, pas une garantie.
Dix questions à poser à un prestataire d'infogérance#
- Quel est le périmètre exact ? Demandez la liste des serveurs, des services (web, base de données, messagerie) et des tâches incluses, puis la liste des exclusions.
- Quels engagements mesurables prenez-vous ? GTI, GTR, disponibilité visée, avec la méthode de mesure et les conséquences d'un manquement.
- Quels sont les horaires de support ? Heures ouvrées, week-end, jours fériés ? Existe-t-il une astreinte, et à quelles conditions ?
- Comment sont gérées les sauvegardes ? Fréquence, durée de conservation, emplacement, chiffrement, copie hors site.
- À quelle fréquence testez-vous les restaurations ? Et me remettrez-vous la preuve du dernier test ?
- Quels sont le RPO et le RTO annoncés ? Sont-ils cohérents avec la fréquence des sauvegardes et avec ce que mon activité peut supporter ?
- Comment appliquez-vous les correctifs de sécurité ? Délais selon la criticité, fenêtres de maintenance, procédure en cas de correctif qui casse quelque chose.
- Qui détient les accès ? Aurai-je un accès administrateur ou au moins un accès complet aux fichiers et aux bases, sans dépendre de vous ?
- Que se passe-t-il à la fin du contrat ? Restitution des données, documentation de l'infrastructure, aide au transfert.
- Quelle journalisation et quel reporting ? Quels journaux sont conservés, combien de temps, et recevrai-je un compte rendu périodique ?
Les éléments d'un bon contrat d'infogérance#
Les réponses aux questions précédentes doivent se retrouver par écrit. Voici ce qu'un contrat solide contient.
- Le périmètre : équipements, systèmes, services, environnements (production, préproduction), avec inclusions et exclusions explicites.
- Les engagements de service : GTI, GTR, disponibilité, mode de calcul, plages horaires concernées et compensations en cas de non-respect.
- Les horaires de support : canaux de contact (téléphone, ticket, e-mail), plages couvertes, éventuelle astreinte.
- Les objectifs de sauvegarde : RPO, RTO, durée de conservation, lieu de stockage, fréquence des tests de restauration.
- La propriété des accès et des données : les données vous appartiennent, vous conservez des accès complets, les comptes du prestataire sont nominatifs et révocables.
- La réversibilité : conditions et délais de restitution des données et de la documentation, formats de restitution, éventuelle assistance à la migration.
- La journalisation : quels journaux sont collectés, durée de conservation, conditions d'accès pour vous.
- Les responsabilités : qui répond de quoi en cas d'incident, plafond éventuel de responsabilité, obligation de moyens ou de résultat selon les engagements.
- La protection des données personnelles : si le prestataire accède à des données personnelles, il agit en général comme sous-traitant au sens du RGPD. L'article 28 impose alors un contrat écrit ; la CNIL en détaille les clauses attendues, parmi lesquelles la confidentialité, les mesures de sécurité, l'autorisation des sous-traitants ultérieurs, la notification des violations, le sort des données en fin de contrat et l'accès aux éléments de preuve de conformité.
Quatre scénarios types#
Les situations ci-dessous sont des cas d'école construits pour illustrer la démarche, pas des témoignages de clients.
Scénario 1 : la boutique en ligne qui grossit#
Une boutique fonctionne sur un mutualisé depuis ses débuts. Les périodes de promotion provoquent des lenteurs, et un module de paiement exige une version de PHP que l'hébergeur ne propose pas. La boutique passe sur un VPS, ce qui résout la contrainte technique mais crée un besoin nouveau : personne ne surveille le serveur. L'infogérance apporte la supervision, les correctifs et les sauvegardes ; le développeur de la boutique continue de s'occuper du code.
Scénario 2 : le serveur hérité que personne ne veut toucher#
Une entreprise dispose d'un serveur dédié installé il y a des années par un prestataire qui a disparu. Les versions du système et des services sont anciennes, les accès sont partagés. La démarche commence par un audit : état des lieux de la configuration, des accès et du niveau de sécurisation, puis remise à niveau, durcissement et mise en place de la supervision.
Scénario 3 : l'organisation qui traite des données personnelles#
Une association gère des dossiers d'adhérents sur une application hébergée sur un VPS. Elle n'a pas de compétences système et redoute une fuite. Le prestataire d'infogérance devient sous-traitant au sens du RGPD : le contrat précise les mesures de sécurité, les conditions d'accès aux données et la restitution en fin de mission. La conformité de l'association, elle, reste sa responsabilité.
Scénario 4 : la petite vitrine#
Un artisan dont le site de quelques pages est mis à jour deux fois par an n'a pas besoin d'infogérance : un mutualisé entretenu suffit.
Ce qui fait varier le coût d'une infogérance#
Aucun tarif pertinent ne peut être donné sans connaître votre situation. En revanche, les facteurs qui font varier un devis sont bien identifiés :
- Le périmètre : supervision seule, administration complète, gestion des sauvegardes, support applicatif partiel.
- Le nombre de serveurs et leur hétérogénéité (systèmes, versions, services installés).
- Le niveau de disponibilité visé : plus l'engagement est exigeant, plus il impose de redondance, de supervision fine et de réactivité.
- L'astreinte : une couverture en dehors des heures ouvrées mobilise des personnes et se facture différemment d'une prise en charge en journée.
- L'état initial : un serveur à remettre à niveau demande un travail préalable qu'un serveur sain ne nécessite pas.
- Les exigences de sauvegarde : RPO serré, copies hors site, tests de restauration fréquents.
Un devis sérieux part d'un audit et détaille ce qu'il inclut.
Ce que fait Websource, et ce que nous ne promettons pas#
Pour rester cohérent avec ce que nous proposons réellement : notre infogérance de serveurs s'appuie sur un audit initial, puis sur le durcissement (mise à jour du système, configuration du pare-feu et des accès, sauvegardes automatisées), la supervision (charge, espace disque, disponibilité des services) et l'intervention en cas d'incident (panne, faille détectée, dégradation de performance). Elle s'adresse aux serveurs Debian ou CentOS existants, quel que soit l'hébergeur.
Côté hébergement infogéré, la sauvegarde quotidienne est conservée sur 15 jours glissants, avec accès FTP/SSH et base de données pour le client, et choix de la version de PHP par site. Notre offre d'hébergement web est décrite sur sa page dédiée.
Les engagements chiffrés (délais d'intervention, horaires de couverture, astreinte) ne sont pas des éléments standards affichés : ils se définissent lors du cadrage, à partir de votre besoin, et doivent figurer par écrit avant toute prise en charge.
Questions fréquentes#
Quelle est la différence entre infogérance et hébergement infogéré ?#
L'infogérance consiste à administrer un serveur qui peut rester chez son hébergeur d'origine. L'hébergement infogéré, lui, comprend l'hébergement du site sur les serveurs du prestataire, avec leur entretien. Chez Websource, ce sont deux prestations distinctes qui peuvent se combiner selon la situation.
L'infogérance couvre-t-elle aussi mon site (WordPress, PrestaShop, code sur mesure) ?#
Pas par défaut. L'infogérance de serveur porte sur le système et ses services (serveur web, PHP, base de données). Les mises à jour applicatives, les corrections de code et les contenus relèvent de la maintenance applicative, qu'il faut prévoir séparément ou faire ajouter explicitement au contrat.
Qu'est-ce que le RPO et le RTO dans un contrat de sauvegarde ?#
Le RPO est la durée maximale de perte de données acceptable en cas de sinistre : il dépend de la fréquence des sauvegardes. Le RTO est la durée maximale d'interruption acceptable : il dépend du temps réel de restauration, qu'on ne connaît qu'en testant. Les deux doivent être écrits au contrat.
Qu'est-ce que la règle de sauvegarde 3-2-1 ?#
C'est une bonne pratique citée notamment par la CNIL : disposer de trois copies des données, sur deux supports différents, dont une copie hors ligne. Elle protège contre la panne matérielle, l'erreur humaine et le rançongiciel, à condition que les restaurations soient testées régulièrement.
Un prestataire d'infogérance est-il un sous-traitant au sens du RGPD ?#
S'il accède à des données personnelles pour votre compte, il agit en général comme sous-traitant. L'article 28 du RGPD impose alors un contrat écrit précisant les mesures de sécurité, la confidentialité, les sous-traitants ultérieurs et le sort des données en fin de contrat. En cas de doute, faites valider votre situation par un juriste ou votre DPO.
Peut-on faire infogérer un serveur qui reste chez son hébergeur actuel ?#
Oui, c'est un cas courant : le prestataire intervient sur l'infrastructure existante, sans changement d'hébergeur ni migration de données. Un audit préalable de la configuration et des accès permet de cadrer précisément le périmètre avant toute intervention.
Article rédigé le 29/09/2026 par l'équipe Websource à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.







