Une obligation de fait
Aucun texte n’impose à toutes les organisations publiques de « tenir une cartographie ». Mais l’analyse de risques, l’homologation de sécurité, le registre des traitements de données personnelles, le plan de reprise et le schéma directeur la supposent tous. L’ANSSI lui consacre un guide en cinq étapes et la présente comme un outil de maîtrise, de protection et de résilience du système d’information.
Dans sa synthèse de la menace visant les collectivités territoriales, l’agence relève que ces dernières gèrent des systèmes nombreux et disparates et peinent souvent à en maîtriser la cartographie. Le constat vaut bien au-delà des collectivités : un système d’information public est le produit de décennies de marchés successifs, de fusions, de transferts de compétences et de solutions montées dans l’urgence.
Ce qu’une cartographie utile contient
Une liste de serveurs n’est pas une cartographie. Ce qui la rend utile à une direction, ce sont les liens entre les couches :
- Processus vitauxLes quelques activités dont l’arrêt met le service en défaut : paie, état civil, admission, versement des prestations.
- Objets métierUsager, agent, dossier, acte, marché, titre de recette : ce que les processus manipulent.
- DonnéesLeur emplacement, leur sensibilité, leur responsable.
- LogicielsApplications, éditeurs, contrats, dates de fin de support.
- InfrastructuresServeurs, réseaux, hébergeurs, postes.
- Risques et ressourcesCe qui menace chaque élément, ce qu’il coûte, qui le maintient.
Avec ces liens, une question de dirigeant trouve une réponse en quelques minutes : « si cet hébergeur tombe, quels services s’arrêtent ? », « si cet agent part, qui sait encore faire fonctionner cette application ? ».
Une vue par lecteur
La même base produit des vues différentes. C’est ce qui évite la cartographie que personne ne lit.
- Élus et direction générale : les processus vitaux, leur niveau de risque et les investissements associés, sur une page.
- Directions métiers : leurs applications, leurs données, leurs interlocuteurs.
- DSI : les dépendances techniques, l’obsolescence, la charge de maintenance.
- RSSI et délégué à la protection des données : les flux, les données sensibles, les prestataires.
- Acheteurs : les contrats, leurs échéances et les conditions de sortie.
Les erreurs qui font échouer la démarche
- Vouloir tout décrire. Une cartographie exhaustive n’est jamais terminée. Mieux vaut dix processus vitaux bien reliés que mille composants isolés.
- Choisir l’outil avant la méthode. Un logiciel de cartographie vide reste vide. Un tableur bien tenu suffit pour commencer.
- Rester dans la technique. Sans rattachement aux missions, la cartographie ne sert qu’à la DSI et ne pèse dans aucun arbitrage.
- Oublier la mise à jour. Un inventaire sans propriétaire est faux au bout de six mois.
Un périmètre de départ réaliste
La démarche la plus sûre part du haut. On réunit la direction générale pour arrêter la liste des processus vitaux, une dizaine au plus. Pour chacun, on identifie les applications qui le portent, les données qu’elles contiennent, l’infrastructure qui les héberge et les fournisseurs concernés. On note au passage tout ce qui étonne : c’est la matière des rapports d’étonnement de la méthode, souvent plus utile que la carte elle-même.
Ce premier périmètre tient en quelques semaines de travail et rend déjà trois services : une base pour l’analyse de risques, une première liste de dépendances critiques et un support de discussion avec les directions métiers.
Tenir la carte à jour
La cartographie vit si elle est rattachée à des événements, non à un calendrier. Chaque nouveau marché, chaque projet, chaque départ d’agent clé, chaque incident déclenche une mise à jour. Un responsable est désigné par domaine. La DSI en assure la cohérence, elle n’en est pas le seul auteur.
Une cartographie se juge à une seule chose : permet-elle de répondre vite aux questions de la direction ? Si oui, elle est suffisante. Si non, plus de détails n’y changeront rien.
Pour confier tout ou partie de ce travail à un prestataire, la page rédiger un CCTP de cartographie décrit les livrables à exiger. Des exemples de schémas figurent sur dynamap.fr.
Dans la méthode DYNAMAP SI
Les trois premières phases de DYNAMAP SI sont entièrement consacrées à la connaissance du système d’information.
- 1Phase 1 · Analyse de l’existant : inventorier les actifs, les processus et les risques tels qu’ils sont réellement.
- 2Phase 2 · Rapports d’étonnement : consigner ce qui surprend : applications sans responsable, coûts sans visibilité, dépendances non maîtrisées.
- 3Phase 3 · Cartographies et points de vue : relier processus, données, logiciels et infrastructures dans des vues lisibles par chaque public.
La méthode appliquée au secteur public · Le framework complet sur dynamap.fr
Pour approfondir : les livres de la collection
Manuel de cartographie du Système d’Information
Un manuel illustré qui déroule la cartographie couche par couche : processus vitaux, chaîne de valeur, objets métier, données, logiciels, infrastructures, puis risques, ressources et gouvernance. Pour toute organisation qui doit produire une cartographie lisible par sa direction.
Modèles de livrables d’Architecture d’Entreprise
Les modèles de livrables des sept phases : inventaires, fichiers de risques, rapports d’étonnement, feuilles de route, RACI, indicateurs. Un appui concret pour décrire, phase par phase, ce que l’on attend d’une équipe interne ou d’un prestataire.
Toute la collection est présentée sur la page livres sur le système d’information.
Sources et références
Yann-Eric Devars
Architecte d’entreprise · créateur du framework DYNAMAP SI
Fondateur de Solve DSI, il accompagne depuis près de dix ans des organisations dans la cartographie et la gouvernance de leur système d’information. Il publie sur LinkedIn ses analyses sur les systèmes d’information publics ; les échanges entre pairs y sont ouverts.