Aller au contenu principal
adminsysCartographier un système d'information

Cartographier un système d'information

Ce que ce chapitre apporte

  • Définir un système d'information et le distinguer de l'infrastructure qui le porte.
  • Nommer les composants d'une infrastructure : serveur, switch, routeur, service, flux.
  • Distinguer architecture, topologie et cartographie.
  • Conduire un inventaire des composants et des services.
  • Représenter les flux entre services et repérer les dépendances critiques.
  • Reconnaître les symptômes d'une infrastructure non documentée.
Où on va
Chez NeoLink Industries, tout fonctionne. Presque. Des utilisateurs perdent l'accès à des dossiers sans raison apparente, des imprimantes disparaissent du réseau puis réapparaissent, et personne ne suit la même procédure pour créer un compte. Aucun de ces symptômes n'est une panne : ce sont les signes d'un système d'information que plus personne ne connaît en entier. Ce chapitre pose le vocabulaire, puis la première compétence du bloc : savoir dire ce qu'on administre avant de prétendre l'administrer.

Ce qu'est un système d'information

Définition

Un système d'information est l'ensemble des ressources permettant à une organisation de collecter, stocker, traiter et diffuser l'information nécessaire à son fonctionnement.

Le mot important est ressources, pas machines. Un système d'information regroupe cinq familles :

FamilleExemples
Les utilisateurssalariés, prestataires, comptes de service
Les donnéesfichiers métier, base clients, sauvegardes
Les applicationslogiciel de gestion, messagerie, site interne
Les équipementsserveurs, postes, switches, imprimantes
Les procéduresarrivée d'un salarié, demande d'accès, gestion d'incident
La procédure fait partie du système
C'est la famille qu'on oublie, et c'est celle qui explique le désordre de NeoLink. Quand chaque technicien crée les comptes à sa façon, le problème n'est ni matériel ni logiciel : la procédure n'existe pas. Aucun outil ne corrigera cela.

L'infrastructure, elle, désigne uniquement les composants matériels et logiciels qui portent le système d'information. Elle en est le support, pas le tout.

Le vocabulaire des équipements

Définitions

Un serveur est un ordinateur qui fournit un ou plusieurs services aux utilisateurs ou aux autres machines.

Un switch (commutateur) fait communiquer les équipements d'un même réseau local.

Un routeur fait communiquer des réseaux distincts.

Un service est une fonction fournie par un équipement ou une application : partage de fichiers, messagerie, résolution de noms.

Un flux réseau est la circulation des données entre deux équipements ou deux services.

Switch ou routeur, la question qui tranche
Les deux équipements font circuler des trames, et on les confond souvent. Pose-toi une seule question : les deux machines qui se parlent sont-elles dans le même réseau ? Si oui, un switch suffit. Si non, il faut un routeur, parce que passer d'un réseau à un autre suppose une décision d'acheminement.

Architecture, topologie, cartographie

Trois mots qu'on emploie l'un pour l'autre, et qui ne disent pas la même chose.

L'architecture est l'organisation globale : quels services existent, comment ils se répartissent, quels choix de conception ont été faits.

La topologie décrit la manière dont les équipements sont reliés entre eux. C'est le plan de câblage, au sens large.

La cartographie est la représentation visuelle des composants et de leurs interactions. C'est un document, et il se met à jour.

La distinction utile
L'architecture est une décision, la topologie un fait, la cartographie une description. Une entreprise peut très bien avoir une topologie sans architecture, c'est-à-dire un réseau qui a poussé sans qu'aucun choix n'ait jamais été arrêté. C'est exactement la situation de NeoLink.

Les symptômes d'un système non documenté

Relis les plaintes rapportées à la direction. Chacune est le symptôme d'un manque précis, et savoir faire cette traduction est déjà la moitié du diagnostic.

Symptôme observéCe qu'il révèle
Des utilisateurs perdent l'accès sans raisondroits attribués individuellement, sans groupes
Des imprimantes disparaissent puis reviennentadressage dynamique non maîtrisé, pas de réservation
Des dossiers accessibles à qui ne devrait pashéritage de permissions non contrôlé
Chaque technicien a sa méthodeabsence de procédure écrite
La documentation n'est plus à jourpas de mise à jour à la mise en service
Les réponses varient selon la personne interrogéeconnaissance orale, non capitalisée
Le réflexe à ne pas avoir
Devant ces symptômes, la tentation est d'ouvrir la console d'administration et de corriger les cas un par un. Chaque correction fonctionne, et le problème revient un mois plus tard sous une autre forme. On ne corrige pas une infrastructure qu'on n'a pas cartographiée : on ne fait que déplacer le désordre.

Conduire un inventaire

L'inventaire précède la cartographie. Il répond à une question simple et redoutable : qu'est-ce qui tourne ici ?

Pour chaque composant, six informations suffisent, et il en faut six :

  1. Nom et rôle en une phrase.
  2. Type : serveur, poste, équipement réseau, imprimante, service.
  3. Adressage : adresse IP, fixe ou obtenue automatiquement.
  4. Service rendu, et à qui.
  5. Dépendances : de quoi ce composant a besoin pour fonctionner.
  6. Criticité : que se passe-t-il s'il s'arrête ?
Une ligne d'inventaire complète
SRV-FIC-01, serveur de fichiers du site de Lyon. Adresse fixe 10.20.1.12. Sert les partages des services Production et Qualité, soit 40 utilisateurs. Dépend de l'annuaire pour l'authentification et du serveur de noms pour être joignable. Criticité haute : son arrêt bloque la production.

Le champ dépendances est celui qui fait la valeur de l'inventaire. Sans lui, on obtient une liste de machines. Avec lui, on obtient un graphe, et un graphe se raisonne : on peut y chercher ce qui tombe si tel service s'arrête.

main.py
Sortie
>_ Prêt à exécuter…
Ce que le calcul montre
L'annuaire n'a que deux dépendants directs, et pourtant son arrêt fait tomber quatre composants sur six. C'est ce qu'on appelle un point de défaillance unique, et un inventaire sans dépendances ne permet pas de le voir. La criticité d'un service ne se lit pas sur sa fiche : elle se déduit de sa position dans le graphe.

Représenter les flux

Une cartographie qui ne montre que des boîtes reliées par des traits ne sert pas à grand-chose. Ce qui compte, ce sont les flux : qui parle à qui, pour quoi faire, et par quel protocole.

Poste utilisateur
   |
   |-- authentification (Kerberos, LDAP) ---> Contrôleur de domaine
   |-- resolution de noms (DNS) ------------> Serveur DNS
   |-- adressage automatique (DHCP) --------> Serveur DHCP
   |-- acces aux partages (SMB) -----------> Serveur de fichiers
                                                   |
                                                   |-- authentification ---> Contrôleur de domaine

Trois lectures immédiates sur ce schéma, et ce sont exactement les trois qu'on attend d'une cartographie :

  1. Le poste ne peut rien faire sans le contrôleur de domaine. Ni ouvrir de session, ni accéder aux partages.
  2. Le serveur de fichiers dépend lui aussi de l'annuaire. La dépendance est donc transitive.
  3. Si le service de noms tombe, les autres serveurs restent allumés mais deviennent injoignables par leur nom. La machine va bien, le service non.
Une machine qui répond n'est pas un service qui fonctionne
C'est la distinction que la supervision naïve rate systématiquement. Un serveur qui répond au ping peut avoir son service arrêté, son disque plein ou son authentification cassée. On y revient au chapitre sur la supervision.

Les outils

Le document du bloc laisse le choix de l'outil de schématisation. Les usages courants :

OutilCe pour quoi il est adapté
draw.io, Diagrams.netschémas d'architecture et de flux, gratuit, format ouvert
Visiostandard en entreprise, gabarits réseau fournis
GLPIinventaire et gestion de parc, avec remontée automatique
Un tableurinventaire initial, quand il faut démarrer aujourd'hui
Le meilleur outil est celui qui sera mis à jour
Une cartographie magnifique et périmée vaut moins qu'un tableur tenu à jour. Le critère de choix n'est pas la beauté du rendu, c'est le coût de la mise à jour : si actualiser le schéma après une intervention prend vingt minutes, personne ne le fera.

Exercices type

Un utilisateur ne peut plus accéder à un dossier partagé. Par où commencer ?

Pas par les permissions du dossier. Par la chaîne de dépendances, du poste vers la ressource :

  1. La session s'ouvre-t-elle ? Sinon, le problème est l'authentification, donc le contrôleur de domaine.
  2. Le serveur est-il joignable par son nom ? Si l'adresse IP fonctionne mais pas le nom, c'est le service de noms.
  3. Le partage est-il monté ? Sinon, le service de partage ou le pare-feu.
  4. Alors seulement, regarder les permissions, et les deux niveaux : partage et système de fichiers.

Commencer par les permissions est le réflexe le plus répandu et le plus coûteux : on modifie des droits pour résoudre un problème de résolution de noms, et on crée une faille durable au passage.

Quelle différence entre un switch et un routeur, sur un cas concret ?

Deux postes en 192.168.1.10 et 192.168.1.20, masque /24 : même réseau, un switch suffit.

Un poste en 192.168.1.10 et un serveur en 10.20.1.12 : réseaux différents, il faut un routeur pour acheminer.

L'intérêt pratique de la distinction : découper en plusieurs réseaux, c'est se donner un point de passage obligé où filtrer. C'est le fondement de la segmentation, sujet du chapitre sur la sécurité réseau.

Pourquoi la documentation d'une infrastructure devient-elle fausse ?

Parce qu'elle est produite comme un projet et non comme une procédure. Elle est écrite une fois, à la mise en service, puis plus jamais touchée alors que l'infrastructure, elle, continue de bouger.

Le remède n'est pas de mieux documenter, c'est de rendre la mise à jour inséparable de l'intervention : une modification n'est terminée que lorsque la fiche est à jour. C'est une règle d'équipe, pas un outil.

C'est aussi ce qui rend l'automatisation intéressante : un script qui crée un compte peut consigner ce qu'il a fait, là où un technicien oublie.

Sur l'inventaire du chapitre, quel composant faut-il redonder en priorité ?

SRV-AD-01. Il a la criticité maximale, et surtout son arrêt entraîne quatre autres composants, y compris le service de noms dont dépend tout le reste.

SW-CoeurA est également de criticité 5, mais aucun composant ne le déclare en dépendance dans cet inventaire. C'est un défaut de l'inventaire lui-même, pas une réalité : tout passe par le commutateur de cœur. À corriger, et c'est le genre d'omission qu'un inventaire fait apparaître quand on le confronte au schéma de flux.

Faut-il inventorier les postes de travail un par un ?

Individuellement, non, sauf en petit parc. Ce qu'il faut inventorier, c'est le modèle : un poste type de tel service, avec sa configuration, ses logiciels, ses accès.

La bonne granularité est celle qui permet de répondre aux questions qu'on se pose. « Combien de postes sous Windows 10 restent à migrer ? » suppose un inventaire par machine, et c'est le rôle d'un outil de gestion de parc. « Quels services accèdent au serveur de fichiers ? » suppose un inventaire par service, et un tableur y suffit.

Inventorier plus que nécessaire garantit que l'inventaire ne sera pas tenu à jour.

Que répondre à « on n'a pas le temps de cartographier » ?

Que le temps est déjà dépensé, mais autrement. Chaque incident chez NeoLink coûte du temps de diagnostic, et ce temps est d'autant plus long que personne ne sait de quoi le service dépend.

L'argument à porter n'est pas la conformité mais le temps de rétablissement. Une cartographie à jour transforme une recherche en lecture.

Ce qui se négocie, en revanche, c'est le périmètre : commencer par les services critiques, ceux dont l'arrêt bloque la production, plutôt que de viser l'exhaustivité et de n'aboutir à rien.

La méthode

  1. Inventorie avant de schématiser. Un schéma dessiné de mémoire reproduit ce qu'on croit savoir.
  2. Une ligne par composant, avec nom, type, adressage, service rendu, dépendances, criticité.
  3. Remplis les dépendances en dernier, quand la liste est complète : c'est là qu'apparaissent les oublis.
  4. Dessine les flux, pas les câbles. Ce qui intéresse l'exploitation, c'est qui parle à qui et pour quoi.
  5. Repère les points de défaillance unique : les composants dont beaucoup dépendent et qui n'ont pas de secours.
  6. Date le document et note qui l'a produit. Une cartographie sans date est une cartographie sans confiance.
  7. Traduis chaque symptôme en manque avant de proposer une correction.

En résumé

  • Un système d'information regroupe utilisateurs, données, applications, équipements et procédures. L'infrastructure n'en est que le support.
  • Switch : un même réseau. Routeur : entre réseaux distincts.
  • Architecture = décision, topologie = fait, cartographie = description datée.
  • L'inventaire tient en six champs, et le champ dépendances est celui qui fait sa valeur.
  • Les dépendances forment un graphe : la criticité réelle se déduit de la position, pas de la fiche.
  • Un point de défaillance unique est un composant dont beaucoup dépendent et qui n'a pas de secours.
  • Une machine qui répond n'est pas un service qui fonctionne.
  • Chaque symptôme d'exploitation se traduit en un manque précis : droits individuels, adressage non maîtrisé, héritage non contrôlé, procédure absente.

Et ensuite ? Le premier manque de NeoLink est le plus structurant : les comptes et les droits sont gérés machine par machine, sans point central. Le chapitre suivant installe l'outil qui y répond, l'annuaire Active Directory.

Cartographier un système d'information | Plateforme ETS