Infogérer un parc entièrement à distance : notre méthode, et ses limites

« Infogérance à distance » est devenu un argument de vente qui ne dit plus rien. Tout le monde l'affiche, personne n'explique ce qu'il y a derrière : comment on entre dans le réseau d'un client sans l'exposer, ce qu'on voit quand personne ne regarde, ce qu'on fait quand un disque lâche à 200 km, et surtout ce qu'on ne sait pas faire sans se déplacer.

Voici notre méthode, dans l'ordre où nous la déroulons sur un nouveau parc. Elle vaut ce qu'elle vaut, mais elle est écrite, elle est la même pour tout le monde, et vous pourrez la comparer à ce que vous propose quelqu'un d'autre.

#1. Avant tout : savoir ce qu'on reprend

Un parc informatique de PME n'est presque jamais documenté. Il a grandi par couches : un serveur installé par un prestataire parti depuis, des comptes créés au fil des années sur une douzaine de services en ligne, des accès partagés par commodité, un contrat de sauvegarde dont plus personne ne connaît le périmètre.

Notre première semaine ne sert donc pas à installer quoi que ce soit, mais à inventorier. Quels postes, quel âge, quel système. Quels serveurs, physiques ou virtuels, et qui les héberge. Quels services en ligne, payés par qui, avec quel compte administrateur. Quels accès existent encore au nom de salariés partis. Ce que sauvegarde réellement la sauvegarde actuelle.

Ce document vous appartient dès le premier jour. C'est votre garantie de pouvoir partir : un prestataire qui garde l'inventaire dans sa tête vous tient, même s'il ne le dit pas.

#2. L'accès : ne jamais ouvrir de port

C'est le point technique qui sépare une infogérance distante sérieuse d'une infogérance distante dangereuse.

La méthode ancienne consiste à ouvrir un port sur la box ou le pare-feu, souvent du RDP ou du VPN historique, pour pouvoir se connecter de l'extérieur. Elle fonctionne, et elle est devenue l'une des principales portes d'entrée des rançongiciels : un port d'administration exposé sur internet est scanné en permanence, et il suffit d'un mot de passe faible ou d'une faille non corrigée dans le service lui-même.

Nous ne procédons pas ainsi. Nous installons un maillage privé chiffré entre nos machines et les vôtres, où chaque machine établit elle-même sa connexion sortante vers un point de rendez-vous. Aucun port entrant n'est ouvert sur votre réseau. De l'extérieur, votre parc ne présente aucune surface d'administration : il n'y a rien à scanner, rien à forcer.

Trois conséquences pratiques, que nous préférons annoncer :

• Si votre connexion internet tombe, nous perdons l'accès comme vous. Le maillage ne crée pas de porte dérobée.
• Chaque machine du maillage est identifiée individuellement, et nous pouvons révoquer un accès précis sans toucher au reste.
• Vous pouvez demander la liste de ce à quoi nous avons accès, à tout moment. Elle doit correspondre à l'inventaire, sinon l'un des deux est faux.

#3. Ce qu'on voit sans se connecter

L'erreur courante de l'infogérance à distance est de confondre l'accès et la surveillance. Pouvoir se connecter à un serveur ne sert à rien si personne ne regarde avant que le client n'appelle.

Chaque machine remonte donc en continu un petit nombre d'indicateurs qui ne sont pas des données métier : espace disque, mémoire, charge, état des services, température et santé des disques, dernière sauvegarde réussie, dernières mises à jour appliquées, et les journaux système. Le tout arrive sur une supervision qui déclenche une alerte selon des seuils définis avec vous, pas selon des valeurs par défaut.

L'intérêt n'est pas de produire de jolis graphiques. Il est de transformer les pannes en événements prévisibles. Un disque qui commence à présenter des secteurs défectueux le signale des semaines avant de lâcher. Un espace disque qui se remplit de trois pour cent par semaine donne une date. Une sauvegarde qui échoue silencieusement depuis onze jours se voit le douzième seulement si quelqu'un la surveille.

C'est la différence entre un prestataire qui intervient et un prestataire qui anticipe, et elle se mesure sur une année, pas sur une intervention.

#4. La sauvegarde : le seul test qui compte est la restauration

Nous n'avons jamais vu une entreprise sans sauvegarde. Nous voyons régulièrement des entreprises dont la sauvegarde ne restaure pas.

Les causes sont toujours les mêmes : le périmètre a changé sans que la sauvegarde suive, un dossier critique n'a jamais été inclus, la copie est sur le même réseau que les données donc un rançongiciel la chiffre aussi, ou personne n'a jamais essayé de remonter quoi que ce soit.

Notre règle est simple : une sauvegarde qui n'a pas été restaurée n'existe pas. Concrètement, cela veut dire une copie hors ligne ou immuable, que personne ne peut effacer ni chiffrer depuis le réseau, même avec les droits d'administrateur. Un chiffrement dont la clé est chez vous. Et une restauration réellement rejouée, pas une ligne verte dans un rapport, avec un compte rendu qui indique ce qui a été remonté et en combien de temps.

C'est aussi là que se décide ce qu'on appelle le plan de reprise, qui n'a rien d'un document théorique : quelles applications doivent redémarrer en premier, en combien de temps, et combien d'heures de travail vous acceptez de perdre. Tant que ces trois réponses ne sont pas écrites, aucun engagement de délai n'a de sens.

#5. Les mises à jour : planifiées, réversibles, jamais le vendredi

Appliquer les correctifs est la mesure de sécurité la plus rentable qui existe, et la plus mal exécutée, parce qu'elle fait peur : une mise à jour peut casser une application métier dont dépend la production.

Nous traitons donc le parc en groupes. Un petit groupe pilote reçoit les correctifs en premier, en général des postes dont l'interruption est sans gravité. Si rien ne casse, le reste suit quelques jours plus tard. Les serveurs sont traités sur des créneaux convenus, avec un point de retour arrière pris avant. Et les postes qui pilotent des machines de production ne sont jamais mis à jour en pleine activité, ils attendent un arrêt programmé.

Ce qui ne peut pas être mis à jour, parce que le logiciel métier ne le supporte pas, n'est pas laissé en l'état pour autant : il est isolé sur son propre segment réseau et surveillé de près. C'est un compromis, nous l'écrivons comme tel.

#6. La sécurité n'est pas une option du contrat

Un parc supervisé à distance sans détection, c'est une voiture avec un compteur mais sans freins. Les mêmes agents qui remontent l'espace disque remontent aussi les signaux de compromission : une connexion qui réussit depuis un pays où vous n'avez personne, un compte qui tente cinquante mots de passe, un processus qui chiffre des fichiers en série, une tâche planifiée créée à trois heures du matin.

Nous utilisons pour cela des briques open source, pour une raison qui n'est pas idéologique : vous pouvez les auditer, et vous pouvez les reprendre. Le jour où vous changez de prestataire, la stack reste en place et les règles de détection sont lisibles. Rien de ce que nous installons ne devient une raison de rester.

#Un cas concret : déplacer toute une production sans se déplacer

En octobre 2026, nous avons migré l'intégralité de nos applications hébergées, sites, API, mesure d'audience, automatisation, gestion documentaire et stack de sécurité, d'un serveur vers un autre plus récent. Sans interruption visible pour les utilisateurs, et sans que personne ne se rende devant la machine.

Ce n'est pas un exploit, c'est une méthode. Et comme c'est exactement ce que nous faisons chez nos clients, autant raconter comment cela se passe réellement.

La configuration existait déjà sous forme de code. C'est la condition qui rend tout le reste possible. Monter les services sur la nouvelle machine n'a pas consisté à réinstaller en suivant des notes, mais à rejouer une configuration versionnée. Si vous ne pouvez pas reconstruire un serveur à partir d'un dépôt, vous ne migrez pas : vous recommencez, et vous recommencez avec les erreurs d'origine.

La nouvelle machine a tourné à côté de l'ancienne avant toute bascule. Les services ont été déployés, démarrés et vérifiés pendant que la production continuait ailleurs. Cette phase ne coûte rien d'autre qu'un peu de ressources, et elle transforme une migration en non-événement : au moment de basculer, on sait déjà que tout fonctionne.

La bascule s'est faite par la couche réseau, en dernier. Tant que le point d'entrée pointe vers l'ancienne machine, rien ne change pour personne. C'est le dernier geste, il prend quelques secondes, et il s'annule tout aussi vite.

Les sauvegardes ont été vérifiées avant, pas après. Évidence rarement respectée : on ne déplace pas des données dont on n'a pas prouvé qu'on sait les remonter.

#Les trois pièges, et ils ne sont pas techniques

Ce qui nous a coûté du temps n'est pas la migration elle-même, mais ce qui pointait encore vers l'ancienne machine, longtemps après.

Les empreintes d'accès changent, et c'est normal. Une nouvelle machine présente une nouvelle identité cryptographique. Les postes qui s'y connectaient refusent alors la connexion avec un avertissement d'usurpation, qui est précisément le comportement attendu d'un système bien configuré. Il faut le prévoir, l'expliquer aux utilisateurs concernés, et surtout ne pas prendre l'habitude de passer outre ce type d'alerte.

Les noms changent, les scripts ne le savent pas. Les composants ont été renommés au passage, plus proprement. Résultat : des scripts d'exploitation écrits des mois plus tôt cherchaient des noms qui n'existaient plus. Rien de grave tant qu'on s'en aperçoit, dangereux quand c'est un script de sauvegarde qui échoue en silence. Toute migration doit s'accompagner d'une relecture de ce qui tourne automatiquement.

Les chemins de déploiement pointaient encore vers l'ancien serveur. Deux semaines après la migration, une procédure de mise en ligne visait toujours la machine précédente. Elle ne produisait pas d'erreur, elle déployait simplement au mauvais endroit. C'est le piège le plus courant et le plus sournois : ce ne sont pas les systèmes qui restent en retard, ce sont les procédures et les habitudes.

La leçon, que nous appliquons désormais systématiquement chez nos clients : une migration ne s'arrête pas quand les services tournent sur la nouvelle machine. Elle s'arrête quand plus aucune procédure, aucun script et aucun poste ne connaît encore l'adresse de l'ancienne.

#7. Ce que nous ne savons pas faire à distance

C'est la partie que les plaquettes oublient, et c'est probablement la plus utile.

Un disque mort se remplace à la main. Un câble débranché se rebranche à la main. Un routeur qui ne répond plus du tout ne se répare pas par le réseau, puisque c'est le réseau qui est tombé. Un poste neuf arrive dans un carton que personne ne déballe à distance. Un câblage se regarde sur place, et un local technique mal ventilé ne se diagnostique pas depuis un tableau de bord.

Il y a aussi ce qui est techniquement faisable à distance mais qui se fait mal : comprendre comment vos équipes travaillent réellement, voir que les trois personnes de l'atelier partagent un même poste parce que c'est plus pratique, ou s'apercevoir que la sauvegarde du bureau d'études est sur un disque externe rangé dans le même tiroir que les clés du bâtiment.

Notre position est donc assumée : le quotidien se pilote à distance, la matière se traite sur place. Les déplacements nécessaires sont inclus dans le forfait, et nous préférons une visite annuelle sans urgence à trois interventions en catastrophe.

#8. Une infrastructure par client, jamais mutualisée

Un dernier point, qui a des conséquences sur tout ce qui précède : chaque client infogéré dispose de son propre environnement. Son serveur, son maillage réseau, ses sauvegardes, ses journaux. Rien n'est partagé entre deux clients.

C'est plus coûteux à exploiter qu'une plateforme mutualisée, et nous l'assumons pour trois raisons. Un incident chez l'un ne peut pas toucher l'autre. Une migration vers un autre prestataire se fait sans démêler vos données de celles de quelqu'un d'autre. Et quand votre client final vous demande où vivent vos données et qui d'autre est sur la même machine, la réponse est courte.

#Questions fréquentes

Peut-on vraiment infogérer un parc sans jamais se déplacer ? Le quotidien, oui : supervision, mises à jour, sauvegardes, gestion des comptes, dépannage logiciel, détection des incidents de sécurité. Le matériel, non. Un disque, un câble, un routeur hors service ou un poste neuf demandent une présence physique. Un prestataire qui affirme le contraire décrit son modèle économique, pas la réalité technique.

Faut-il ouvrir un port sur notre pare-feu pour que vous puissiez intervenir ? Non, et c'est volontaire. Les machines établissent elles-mêmes une connexion sortante chiffrée vers un maillage privé. Aucun port entrant n'est ouvert, donc aucune surface d'administration n'est exposée sur internet. Les ports d'administration ouverts sont l'une des premières portes d'entrée des rançongiciels.

Comment savoir si notre sauvegarde actuelle fonctionne vraiment ? En restaurant. C'est le seul test valable. Demandez à votre prestataire actuel de remonter un dossier précis, choisi par vous, sur une date précise, et de vous dire combien de temps cela a pris. Un rapport vert ne prouve que l'exécution du script, pas la lisibilité des données.

Que se passe-t-il si notre connexion internet tombe ? Nous perdons la supervision et l'accès, exactement comme vous perdez vos services en ligne. Le maillage ne crée aucune voie d'accès indépendante de votre connexion, ce serait une porte dérobée. C'est pour cela que le plan de reprise prévoit aussi ce cas, avec un contact téléphonique et une marche à suivre écrite.

Pouvez-vous migrer nos serveurs sans interruption, et à distance ? Oui, quand la configuration est décrite sous forme de code et que la nouvelle machine peut tourner à côté de l'ancienne avant la bascule. Nous l'avons fait en octobre 2026 pour notre propre production, applications, mesure d'audience, automatisation et stack de sécurité comprises. Le vrai travail n'est pas le déplacement, c'est de s'assurer qu'aucun script ni aucune procédure ne pointe encore vers l'ancienne machine une fois la bascule faite.

Est-ce que l'infogérance à distance coûte moins cher ? Elle coûte moins cher en déplacements, et elle coûte surtout moins cher en pannes, puisque l'essentiel du travail consiste à les éviter. Mais un forfait qui serait bas parce que personne ne regarde réellement le parc n'est pas une économie, c'est un report de dépense.

Peut-on récupérer notre parc si nous changeons de prestataire ? Oui, et cela se prépare dès le premier jour. L'inventaire, la documentation, les accès et les sauvegardes vous appartiennent. Les briques utilisées sont open source, donc votre successeur peut reprendre l'existant sans tout réinstaller. Une migration bien préparée se compte en semaines, pas en mois.

#Pour aller plus loin

Notre offre d'infogérance et ses paliers sont détaillés sur la page infogérance. Si votre parc est à Nancy, Metz, Épinal, Lunéville ou Sarrebourg, les pages locales précisent ce que nous couvrons sur chaque secteur. Pour la partie détection et surveillance de sécurité, le SOC managé va plus loin que ce qui est inclus dans l'infogérance courante.

Équipe M-KIS