Par où commencer pour cartographier son SI ?

Choisir un utilisateur et une question

Une direction générale, une équipe de production et un chef de projet n’attendent pas la même représentation. Commencez par identifier l’utilisateur de la carte. Demandez-lui quelle décision il souhaite prendre : comprendre un coût, préparer une migration, organiser une reprise ou identifier un point de dépendance.

Cette question fixe le niveau de détail. Pour comprendre la dépendance d’un processus à un fournisseur, le nom de chaque machine peut être secondaire. Pour préparer une restauration technique, il peut devenir essentiel.

Limiter le premier périmètre

Un processus important constitue souvent un bon point de départ. Décrivez ses activités, ses applications, ses informations et ses principaux fournisseurs. Recensez les relations nécessaires pour répondre à votre question. Le périmètre peut être élargi lorsque la première vue est utilisable.

Ne confondez pas périmètre limité et analyse isolée. Les dépendances qui sortent du périmètre doivent être signalées, même si elles ne sont pas encore décrites en détail.

Stabiliser le vocabulaire et les identifiants

Deux noms différents peuvent désigner la même application. Un même nom peut recouvrir un produit, une instance ou un service. Fixez quelques définitions et utilisez des identifiants stables. Vous éviterez de construire des liens entre des objets qui ne sont pas comparables.

Ajoutez un responsable et une date de vérification aux informations importantes. Une donnée sans source connue doit être présentée comme incertaine, pas comme un fait établi.

Séparer les données des représentations

Un référentiel conserve les objets et leurs relations. Une vue sélectionne ce qu’un lecteur doit voir. Cette distinction évite de recopier les mêmes informations dans plusieurs schémas qui finissent par se contredire.

La représentation peut rester simple : tableau de dépendances, vue applicative, chaîne de valeur ou plan de métro. Le choix graphique doit servir la lecture, non démontrer la sophistication de l’outil.

Prévoir la mise à jour avant la fin du projet

Une cartographie se dégrade dès que les changements ne lui sont plus signalés. Identifiez les événements qui déclenchent une mise à jour : nouvelle application, migration, modification de flux, changement de responsable ou de fournisseur.

Associez cette maintenance aux processus existants. Une revue d’architecture ou une mise en production peut devenir un point de contrôle. Le maintien de la connaissance doit être une responsabilité normale, pas une campagne exceptionnelle.

Les points à vérifier

• Un lecteur et une décision sont identifiés.
• Les informations ont une source et un responsable.
• Les dépendances inconnues sont signalées.
• La mise à jour est intégrée aux changements.

Pour approfondir ce thème : les ressources et ouvrages de l’écosystème DYNAMAP SI.