Infogérance serveur Linux à Paris et en petite couronne : un devis clair en 2 minutes

Confier l’infogérance d’un serveur Linux, c’est transférer son exploitation courante à un prestataire : supervision, application des mises à jour, sécurisation, sauvegardes et prise en charge des incidents. Le périmètre se définit par écrit, serveur par serveur, avec la distribution installée, les services qui tournent dessus et les accès accordés.

Ce qui est confié et ce qui reste à l’entreprise

L’infogérant prend en charge le système, les services de base et leur mise à jour. L’entreprise garde en général la maîtrise de ses applications métier et de leurs évolutions fonctionnelles, sauf si le contrat prévoit autrement. La frontière entre les deux doit être nommée noir sur blanc, car c’est dans cet espace flou que naissent les désaccords après un incident.

Hébergement et infogérance, deux métiers distincts

L’hébergeur fournit la machine, physique ou virtuelle, ainsi que le réseau et l’alimentation. L’infogérance porte sur ce qui tourne dessus. Les deux peuvent être confiés au même prestataire ou séparément, mais il faut savoir qui répond lorsqu’un serveur ne répond plus : une panne matérielle relève en principe de l’hébergeur, une panne logicielle de l’exploitant.

Le sujet arrive rarement avec un projet en tête. Il surgit le plus souvent à l’occasion d’un incident ou d’un départ. Quelques signaux reviennent souvent :

• Une distribution en fin de vie : elle ne reçoit plus de correctifs de sécurité, et chaque nouvelle faille reste ouverte sans que personne ne le décide vraiment.
• Un administrateur unique : il connaît seul les serveurs, les particularités de chaque machine et les accès, et son départ laisserait l’entreprise sans repères.
• Des mises à jour repoussées : on évite de patcher de peur de casser une application, si bien que l’écart avec la version courante se creuse.
• Un service qui tombe la nuit : une application métier s’interrompt sans qu’aucune alerte n’atteigne une personne d’astreinte.
• Des accès SSH partagés : les clés circulent entre prestataires successifs, et personne ne sait plus exactement qui peut se connecter.
• Un disque plein au mauvais moment : l’espace disponible n’est pas surveillé, et le service s’arrête brutalement.
• Des sauvegardes jamais restaurées : rien ne prouve qu’elles sont exploitables tant qu’une restauration n’a pas été tentée.
• Des journaux ignorés : ils contiennent les premiers signes d’une panne ou d’une intrusion, mais personne ne les lit avant l’incident.

Avant la prise en charge : reprise de l’existant

Le prestataire audite les serveurs, leurs distributions, les services installés et les tâches planifiées. Il récupère les accès, vérifie qu’ils sont nominatifs et rédige une première documentation de l’état réel, souvent différent de ce que l’équipe imagine. Cette étape fait aussi ressortir les priorités, comme une distribution arrivée en fin de vie ou une sauvegarde qui n’a jamais été testée.

Pendant la mission : supervision et correctifs

La supervision porte sur les ressources, les services et l’échéance des certificats, avec des alertes adressées à la personne d’astreinte désignée. Les correctifs de sécurité sont appliqués selon un calendrier, après un passage par un environnement de préproduction lorsque l’application le permet. Un correctif du noyau ou d’une bibliothèque partagée comme OpenSSL ne prend effet qu’après un redémarrage de la machine ou des services concernés : l’offre doit dire qui planifie ces redémarrages, ou si un mécanisme de correction à chaud est utilisé. Chaque modification de configuration fait l’objet d’une trace écrite, pour pouvoir revenir en arrière à tout moment.

Après la mise en service : exploitation et compte rendu

Chaque incident donne lieu à un diagnostic, au rétablissement du service et à un compte rendu écrit qui indique la cause probable et les mesures prises. Les sauvegardes sont restaurées à intervalles réguliers pour vérifier qu’elles tiennent leur rôle. Les évolutions, comme l’ajout d’un serveur ou une montée de version, font l’objet d’un planning distinct de l’exploitation courante.

Une offre sérieuse décrit ce qui est fait, à quelle fréquence et par qui. Elle précise le niveau de service attendu pour la prise en charge d’un incident, sans promettre de délai que le prestataire ne maîtrise pas lui-même, et indique clairement ce qui se passe en dehors des plages couvertes.

La documentation est un bon révélateur. Une offre qui prévoit un dossier d’exploitation tenu à jour, partagé avec l’entreprise, donne de meilleures garanties qu’une simple intervention ponctuelle. Vérifiez aussi la méthode de durcissement annoncée : la gestion des comptes et des clés SSH, le pare-feu, la journalisation et la désactivation des services inutiles doivent figurer explicitement, et non sous une formule générale comme « sécurisation du serveur ».

Enfin, regardez la répartition des responsabilités lors d’une mise à jour majeure ou d’une migration. Une offre claire indique qui teste, qui valide la bascule et qui assume le retour arrière. Sans cette précision, le serveur appartient en pratique à celui qui connaît la machine, ce qui n’est jamais une situation confortable pour l’entreprise.

Quelques erreurs reviennent dans les projets d’infogérance Linux. Chacune a sa parade.

• Confier les serveurs sans inventaire. Sans liste des machines, des services et des flux, le prestataire découvre les dépendances au moment de la panne. Parade : exiger l’inventaire avant la prise en charge.
• Repousser les mises à jour indéfiniment. L’écart grandit et chaque correctif devient plus risqué à appliquer. Parade : un calendrier de correctifs, testé en préproduction quand elle existe.
• Laisser les accès entre les mains d’un seul intervenant. Les clés et les mots de passe deviennent un point de dépendance. Parade : des comptes nominatifs, des clés conservées par l’entreprise et révoquées à chaque départ.
• Ne jamais tester les sauvegardes. Une sauvegarde non restaurée reste une hypothèse. Parade : des tests de restauration planifiés, suivis d’un compte rendu.
• Ignorer les alertes faute de destinataire. Une alerte envoyée à une boîte que personne ne consulte n’a aucune valeur. Parade : désigner une personne d’astreinte et vérifier toute la chaîne d’alerte.

Avant de signer, posez des questions précises. Quelles alertes sont surveillées, et à qui sont-elles envoyées ? Comment les correctifs sont-ils testés avant d’être appliqués en production ? Les clés SSH et les accès restent-ils la propriété de l’entreprise, et celle-ci peut-elle les révoquer à tout moment ?

Demandez aussi ce que prévoit la clause de réversibilité. Elle doit décrire la passation en fin de contrat : documentation, liste des accès, configurations et sauvegardes remises à l’entreprise, dans un format exploitable sans le prestataire sortant. Comparez les réponses plutôt que la seule présentation commerciale : un prestataire qui répond avec précision à ces questions donne une bonne indication de la qualité de son exploitation.