DOCUMENTER LE SYSTEME D’INFORMATION : LES PRINCIPAUX TYPES DE DOCUMENTS ET LEURS ROLES

Si chacun s’accorde sur l’importance de rédiger et de mettre à jour la documentation nécessaire tant au Maintien en Conditions Opérationnelles du SI qu’à la conduite éclairée des évolutions, le rythme soutenu de ces dernières entraîne souvent un degré d’obsolescence, pouvant se traduire dans les faits par des pertes de capital informationnel lors du départ de personnels clés. Les solutions spécifiques de gestion documentaire et des processus liés (circuits de validation, versionning, archivage…) apportent un concours appréciable, à la condition toutefois de bien connaître les grandes catégories de documents afin d’identifier à quel moment les produire et mettre à jour, à l’attention de quel acteur opérationnel, par qui et pourquoi. Voici quelques exemples de types documentaires dont la rédaction et le maintien s’avère indispensable :

Le Document d’Architecture Technique (DAT) se concentre sur une fonction spécifique du SI dont il énumère les sous-composants physiques et logiques, précise la nature de leur activité et qualifie leurs interrelations. Il est rédigé et mis à jour par les ressources d’intégration à l’attention des responsables d’exploitation et des chefs de projet technico-fonctionnels, dans l’optique de leur transmettre une vision d’ensemble du périmètre adressé.
Trop souvent négligée, la Matrice de flux incorporée dans les DAT dresse la liste et l’objectif des expressions protocolaires entre les composants concernés à dessein de l’établissement de règles de filtrage tant au niveau des points de jonction entre les différentes zones de sécurité (firewalls/UTM) que pour administrer les dispositifs de protection host-based (HIPS, pare-feu système…).

Le Manuel d’Exploitation (MEX) est orienté vers le Maintien en Conditions Opérationnelles d’un composant technique particulier, isolé ou distribué. Il comporte des informations de terrain précises, à la fois sur le plan des préconisations d’exploitation courante (compteurs et seuils de supervision ; type, fréquence et rétention des sauvegardes ; licensing ; tâches périodiques…) que sur celui des méthodes de résolution applicable en cas d’incident (diagramme de résolution des pannes courantes ; modalités de support technique). Rédigé par les intégrateurs à l’attention des exploitants, il importe que ces derniers prennent en charge son évolution à mesure des améliorations apportées en matière de MCO et de prévention des problèmes.

Le Rapport de configuration se veut à la fois une forme de capitalisation d’un travail de détail (que l’on saura donc reproduire en cas de crash majeur) et un document à visée pédagogique, qui explique tant aux exploitants qu’aux responsables applicatifs l’objectif des paramètres appliqués sur tel ou tel système ou logiciel. Son cycle de mise à jour est généralement calqué sur celui du composant concerné, selon qu’il s’agisse d’une évolution mineure ou d’une migration majeure. Il est souvent complété par une Procédure d’installation destinée à rendre autonome techniciens et exploitants sur les actions de reconstruction compète d’un composant du SI irrécupérable en l’état.

La Procédure d’arrêt/reprise programmés de salle informatique fédère et ordonnance de façon cohérente les actions à mener lors d’une extinction volontaire, par exemple pour permettre la réalisation de travaux portant sur le courant fort. Son micro-planning (chronogramme) indique le phasage conçu pour minimiser les risques d’une telle opération et qualifier les écarts temporels à l’attendu. Il fait référence aux procédures d’arrêt et de démarrage propres à chaque élément (et utilisés ponctuellement dans d’autres contextes par les exploitants) ainsi qu’aux plans de test techniques et fonctionnels validant le bon fonctionnement de la reprise, couche par couche et fonction par fonction. La mise à jour régulière de ce jeu de documents s’impose, au minimum avant chaque arrêt programmé et immédiatement après celui-ci pour correction.
Bien souvent, l’arrêt d’une salle informatique s’accompagne de l’activation d’un Plan de Continuité Informatique (PCI) ou d’un Plan de Reprise d’Activité (PRA), employés par ailleurs en cas d’arrêt non programmé. Pour cette dernière raison, l’exécution des PCI/PRA devrait idéalement pouvoir être réalisée par des techniciens faiblement qualifiés et documentée en conséquence, au moins pour le rétablissement des fonctions critiques du SI. Envisager des entrainements réguliers à cadence semestrielle s’avère pertinent en matière de maintien des procédures associées et de contrôle d’une situation réellement dramatique.

Pour se former :

Conception de Salle Technique – Data Center

Energie – Data Center