Une agence qui quitte la gestion d’un parc serveur laisse rarement derrière elle une documentation à la hauteur de ce qu’elle sait, mentalement, du fonctionnement réel de l’infrastructure. La topologie réseau, en particulier, se transmet souvent mal : elle vit dans la tête de la personne qui a construit le parc, pas dans un document que l’agence suivante pourra exploiter sans reconstituer l’historique par tâtonnements.
Consigner cette topologie avant une passation évite à l’agence entrante de découvrir, plusieurs semaines après la reprise, qu’une règle de pare-feu bloque un flux dont personne ne connaît plus la raison d’être, ou qu’une zone DNS contient des enregistrements pointant vers des serveurs qui n’existent plus. Ce travail se concentre ici sur les éléments réseau, sans aborder les accès applicatifs, qui relèvent d’une documentation distincte.
Les zones DNS, premier point de vérité à figer
Une zone DNS accumule, au fil des années, des enregistrements dont l’utilité initiale a parfois disparu : un sous-domaine de test jamais nettoyé, un enregistrement MX pointant vers un ancien prestataire de messagerie, un CNAME vers un service tiers résilié depuis longtemps. Avant transmission, chaque enregistrement mérite d’être vérifié et, si possible, annoté sur son usage réel plutôt que simplement recopié tel quel.
dig exemple.fr ANY +noall +answer
dig monsite.exemple.fr MX +short
Cette vérification sert aussi à repérer les enregistrements orphelins, ceux qui pointent vers une adresse IP qui ne répond plus, signe presque certain d’un service abandonné qu’il vaut mieux documenter comme tel plutôt que de le laisser dans un flou qui inquiétera l’agence suivante.
Les règles de pare-feu, justifiées plutôt que simplement listées
Une liste brute de règles de pare-feu, exportée telle quelle depuis iptables ou une console cloud, ne dit rien de la raison d’être de chaque règle. Une règle qui autorise un flux entrant depuis une adresse IP précise peut correspondre à un accès VPN d’un ancien collaborateur, à une intégration avec un service tiers toujours actif, ou à un vestige qui n’a plus lieu d’être.
La documentation transmise doit associer, à chaque règle, une justification courte mais explicite : quel service ou quelle personne cette règle autorise, et depuis quand elle existe si cette information reste accessible. Sans cette annotation, l’agence entrante se retrouve face à un choix risqué, tout conserver par prudence ou tout nettoyer au risque de casser un flux légitime encore utilisé.
- Lister chaque règle de pare-feu avec sa justification métier
- Identifier les règles liées à un VPN ou à un accès distant nominatif
- Repérer les règles qui semblent obsolètes sans les supprimer avant validation
- Documenter les flux sortants autorisés, pas seulement les flux entrants
Le VPN et les accès distants, un point souvent oublié
Un parc serveur géré par une agence s’accompagne fréquemment d’un accès VPN utilisé par l’équipe technique pour administrer les machines à distance, ou par certains clients pour accéder à des environnements de recette non exposés publiquement. Ces configurations, souvent mises en place au fil de l’eau, méritent d’être consignées précisément : quel logiciel VPN, quelle plage d’adresses attribuée, quels comptes existent encore et lesquels devraient être révoqués au moment de la passation.
Un audit de ces accès, réalisé juste avant la transmission, permet aussi de révoquer les comptes qui n’ont plus lieu d’exister, une étape de sécurité qui profite autant à l’agence sortante qu’à celle qui prend le relais.
Un schéma d’interconnexion vaut mieux qu’un historique de tickets
La documentation la plus utile pour une agence entrante n’est pas un historique de tickets de support épars, mais un schéma synthétique qui représente l’interconnexion entre les différents éléments du parc : quels serveurs communiquent entre eux, sur quels ports, via quel réseau interne ou quelle interconnexion privée. Ce schéma, même simple, condense en une image ce qu’il faudrait autrement reconstituer à partir de dizaines de documents dispersés.
Sur les passations que nous avons menées, le seul document qui a réellement évité des semaines de reconstitution était un schéma réseau tenu à jour, même sommaire, bien avant un compte rendu détaillé de chaque incident passé.
Organiser la remise en un point de contact unique
La transmission gagne à se faire via un document unique, structuré par catégorie, plutôt que par l’envoi dispersé de fichiers exportés depuis différents outils. Ce document sert de point d’entrée : il renvoie vers les exports techniques détaillés pour qui souhaite aller plus loin, mais il permet à l’agence entrante de comprendre en une lecture la structure générale du parc avant de plonger dans le détail.
En résumé
Une transmission de parc serveur réussie repose sur une documentation réseau qui va au-delà de l’export brut des configurations : zones DNS vérifiées et annotées, règles de pare-feu justifiées une par une, accès VPN audités et schéma d’interconnexion à jour. Ce travail de consignation, souvent négligé en fin de mission, conditionne directement la rapidité avec laquelle l’agence suivante pourra reprendre le parc sans mauvaise surprise.
