Si un switch tombe ce soir, qui s’en aperçoit demain matin ?
La vraie réponse n’est presque jamais technique : c’est « la comptabilité ne peut plus clôturer », ou « les commandes ne partent plus ».
Pour répondre, il faut une cartographie qui relie le matériel aux processus métier, sans rupture. Cet article remonte ces couches une à une, du câblage jusqu’aux processus, en s’appuyant à chaque étape sur les vues produites par Optim-SI.
CMDB → Le socle : savoir ce qui est branché à quoi
Tout commence par le plus concret : le matériel.
- Serveurs,
- Machines virtuelles,
- Postes,
- Routeurs,
- Switchs,
- Imprimantes
- …
et surtout la façon dont ils sont reliés entre eux.
Optim-SI CMDB inventorie l’ensemble des équipements, physiques et virtuels, et décrit les connexions physiques entre eux.
Un inventaire seul est une liste ; un inventaire relié devient une carte.
C’est à partir de cette carte qu’on raisonne en cas d’incident, de migration ou de renouvellement : par où passe un poste pour atteindre un serveur, et ce qu’un routeur isole s’il s’arrête.
CMDB → Du physique au logique
Deux serveurs peuvent être côte à côte dans la même baie… et ne jamais pouvoir communiquer.
Le câblage ne dit pas tout : au-dessus du physique, l’infrastructure logique détermine ce qui peut réellement parler à quoi.
Avec Optim-SI CMDB :
- L’infrastructure réseau logique est décrite : réseaux, gateways, liaisons vers l’extérieur ;
- Elle est rattachée aux équipements physiques qui la portent ;
- Les middlewares installés sur chaque serveur sont inventoriés : bases de données, serveurs web, serveurs d’applications.
On sait alors non seulement où se trouve une machine, mais aussi dans quel réseau elle vit et ce qui tourne dessus.
APM → L’application, le maillon qui relie tout
« L’application tourne sur quel serveur ? » La réponse est rarement aussi simple.
Une application a souvent plusieurs environnements (production, recette, préqualification, préproduction), et chacun s’appuie sur ses propres serveurs et ses propres instances de middlewares.
Optim-SI APM décrit :
- L’inventaire des applications ;
- Pour chacune, ses responsables, ses technologies, ses risques, son état de santé, et toute autre information utile à l’organisation ;
- Ses environnements : la production de telle application utilise tels serveurs, telle instance Oracle, tel serveur JBoss installé sur tel serveur.
C’est ce niveau de détail qui fait le lien entre le métier et l’infrastructure.
Sans lui, les deux mondes restent séparés.
URBA → Les flux : ce qui circule entre les applications
Une application isolée, ça n’existe presque plus. Elle reçoit des données, en envoie, en transforme. Et c’est souvent par ces échanges que les problèmes se propagent : une interface modifiée sans prévenir, un flux oublié lors d’une migration, une dépendance découverte au moment de décommissionner.
Optim-SI APM inventorie les flux inter-applicatifs. Optim-SI URBA les représente graphiquement et s’appuie sur un référentiel des flux qui permet de parcourir le graphe pour analyser les dépendances sur plusieurs niveaux :
- qui échange avec qui ;
- dans quel sens ;
- quelles données sont échangées ;
- quelles applications deviennent des points de passage critiques.
Avant de modifier ou de supprimer une application, la question n’est pas seulement « qui l’utilise ? » mais aussi « qui en dépend sans le savoir ? ».
URBA → APM → CMDB → Du processus métier jusqu’au switch
Revenons à la question de départ : si ce switch tombe, qui s’en aperçoit ?
Pour répondre en termes métier, il faut relier la dernière couche.
Optim-SI URBA l’ajoute :
- Modélisation des processus en BPMN ;
- Cartographie des processus et des fonctions ;
- Rattachement des applications aux fonctions et aux processus qu’elles supportent.
Et surtout, les analyses d’impact sont générées automatiquement à partir des données de tous les modules, à jour en temps réel.
Elles ne sont pas « dessinées à la main », avec toutes les erreurs et les oublis que cela entraîne. Elles sont justes.
Du processus à l’application, de l’application au serveur, du serveur au réseau : une seule chaîne, consultable et à jour à tout moment.
Une base de connaissances, pas un schéma
Ce qui rend cette chaîne exploitable, ce n’est pas la qualité des diagrammes. C’est que tout est relié dans un même graphe, que l’on interroge et parcourt sur plusieurs niveaux : les diagrammes n’en sont qu’une représentation parmi d’autres.
Et cette chaîne sert bien au-delà d’un seul usage. Dès lors que processus, applications, flux et infrastructures sont reliés, on peut :
- Anticiper l’impact d’un changement (migration, montée de version, décommissionnement) avant de le lancer.
- Traiter un incident par son impact métier, du composant en panne jusqu’aux processus touchés, pour prioriser la résolution.
- Fonder un PCA ou un PRA solide, en sachant ce qui fait tourner chaque processus critique et dans quel ordre le reprendre.
- Rationaliser le parc : repérer les doublons, les applications peu utilisées, les serveurs et middlewares à mutualiser ou à retirer.
- Maîtriser l’obsolescence et la sécurité, en identifiant les processus exposés par un middleware en fin de support ou une vulnérabilité.
- Répondre aux audits et à la conformité, avec la traçabilité des données et une documentation générée depuis l’état réel du SI.
- Cadrer les projets et piloter l’urbanisation, en voyant dès le départ ce qu’un projet transforme.
- Savoir qui appeler, puisque les responsabilités sont rattachées à chaque application.
Optim-SI APM, CMDB et URBA composent le Pack Maîtrise du SI.
