Cartographie du SI : la faire pour décider, pas pour inventorier

Une cartographie du SI décrit ce qui existe : les applications, ce qu’elles font, les données qu’elles échangent et ce qu’elles coûtent. Faite sans question précise, elle devient un inventaire long à produire, périmé avant d’être fini, que personne ne consulte.

La plupart des méthodes publiées partent de la sécurité. Le guide de cartographie de l’ANSSI, la référence la plus citée, cartographie pour savoir quoi protéger. Une ETI qui change d’ERP, intègre une société rachetée ou doit réduire ses coûts informatiques se pose une autre question : qu’est-ce qui dépend de quoi, et combien ça coûte ?

Ce guide décrit une cartographie faite pour décider : les vues à retenir, par quoi commencer, la méthode pas à pas, un exemple de cartographie applicative, et ce qu’elle doit conclure.

Qu’est-ce qu’une cartographie du SI, et à quoi sert-elle ?

C’est une représentation du système d’information en plusieurs vues, de la plus métier à la plus technique. Chacune sert un usage différent, et c’est l’usage qui fixe ce qu’il faut relever.

• Sécuriser : connaître ce qu’il faut protéger, jusqu’aux serveurs et aux réseaux. C’est l’objet du guide de l’ANSSI.
• Se mettre en conformité : relier les applications aux traitements de données personnelles, pour tenir le registre qu’exige le RGPD.
• Décider : savoir ce qu’un changement va toucher avant de l’engager. Un ERP qu’on remplace, deux SI qu’on fusionne, des applications qu’on arrête.

Les deux premiers usages demandent une cartographie complète et tenue à jour. Le troisième demande une cartographie juste, sur un périmètre précis, à une date donnée. Les confondre, c’est s’engager pour des mois là où quelques semaines suffisent.

Quelles vues retenir : fonctionnelle, applicative, technique ?

L’ANSSI organise la cartographie en trois visions, déclinées en vues : métier, applicative et infrastructure. Pour une décision, deux suffisent le plus souvent.

• La cartographie fonctionnelle décrit ce que fait l’entreprise : ses processus et les fonctions qui les servent, de la prise de commande à la facturation. Elle ne cite aucun logiciel.
• La cartographie applicative décrit les logiciels qui portent ces fonctions et la façon dont ils échangent leurs données : interfaces, extractions, fichiers déposés.
• La vue technique décrit les serveurs, l’hébergement et les réseaux. Elle ne sert que si la décision porte sur l’hébergement, un passage au cloud ou la sécurité.

C’est la superposition des deux premières qui fait décider. Une fonction portée par deux applications est un doublon. Une fonction que rien ne porte est un fichier Excel quelque part. Une application qui ne porte plus aucune fonction est un coût à arrêter.

Par quoi commencer une cartographie du SI ?

Par la décision qu’elle doit éclairer, pas par l’inventaire. C’est elle qui fixe le périmètre, le niveau de détail et la date à laquelle la cartographie doit être prête.

• Un ERP à remplacer. Le périmètre est l’ERP et tout ce qui s’y branche. Le détail descend jusqu’au flux : ce qui entre, ce qui sort, à quelle fréquence. C’est le cas des entreprises que la fin de maintenance de SAP ECC oblige à choisir.
• Une société rachetée à intégrer. Le périmètre est double : les deux SI, rapprochés fonction par fonction. On cherche ce qui fait deux fois la même chose.
• Des coûts à réduire. Le périmètre couvre tout le parc applicatif, mais avec peu de détail : une ligne par application, ce qu’elle coûte et qui s’en sert.
• Un DSI qui arrive. Le périmètre est large et le détail minimal : savoir ce qui existe et à qui s’adresser.

Comment cartographier un SI, étape par étape ?

1. Écrire la question en une phrase, avec sa date. « Pouvons-nous remplacer l’ERP d’ici 2028 ? » se cartographie. « Avoir une vision de notre SI » ne se termine jamais.
2. Partir de ce qui est payé, pas de ce qui est documenté. Les contrats, les factures des éditeurs et les abonnements donnent la liste réelle des applications. La documentation donne celle d’il y a trois ans.
3. Mener un atelier par domaine métier, avec ceux qui utilisent les outils au quotidien. Ils décrivent ce qu’ils font vraiment : l’extraction du lundi, le fichier retraité à la main, l’outil installé par le service. Les dépendances que personne n’a listées sont là.
4. Relever les mêmes informations pour chaque application : la fonction, le responsable métier, le nombre d’utilisateurs, les flux entrants et sortants, le coût annuel, l’échéance du contrat.
5. Dessiner une vue par question, pas une vue unique qui dit tout. Une vue lisible tient sur une page.
6. Faire valider par les métiers, puis dater. Une cartographie sans date se lit comme si elle était à jour.

À quoi ressemble une cartographie applicative ? Un exemple

Voici un exemple type, construit à partir de situations courantes. Une entreprise envisage de changer d’ERP. Sa cartographie compte treize applications, réparties en cinq domaines, et douze échanges entre elles.

Sept échanges sont automatiques. L’ERP en porte une partie : le portail client, le logiciel d’entrepôt, la consolidation et le décisionnel. Les autres ne passent pas par lui : le SIRH et les notes de frais alimentent la paie, le décisionnel lit le CRM.

Cinq reposent sur une opération manuelle. Ce sont elles qui comptent : chacune a un coût, et chacune appelle une proposition.

• Les commandes du CRM sont ressaisies dans l’ERP. Chaque commande est saisie deux fois. Proposition : exiger l’interface avec le CRM dans le futur ERP.
• Les prix sont importés manuellement depuis un fichier Excel. Ils reposent sur une seule personne. Proposition : gérer les tarifs dans le futur ERP.
• Les heures partent par fichier chez le prestataire de paie. Chaque mois, une erreur de paie est possible. Proposition : relier la gestion des temps à la paie, sans attendre le projet ERP.
• Le budget est rempli par copier-coller depuis le décisionnel. Le budget et le réel se rapprochent mal. Proposition : alimenter le budget depuis le décisionnel.
• Les comptes utilisateurs sont créés manuellement. Des comptes d’anciens salariés restent actifs. Proposition : relier l’annuaire au SIRH.

Deux de ces propositions entrent dans le cahier des charges du futur ERP. Les trois autres se traitent sans lui, et souvent avant. Un inventaire ne fait pas ce tri ; une cartographie lue pour décider, si.

Quel outil pour cartographier le SI ?

Pour une décision, un tableur et un outil de dessin suffisent : une ligne par application, une colonne par information relevée, une vue dessinée par question.

Un logiciel de cartographie se justifie quand la cartographie doit vivre : tenue à jour en continu pour la sécurité ou la conformité, partagée par plusieurs équipes, sur un parc trop large pour un tableur. Le choisir avant une première cartographie, c’est choisir un outil sans connaître son besoin.

Que doit conclure une cartographie du SI ?

Une cartographie décrit. Elle ne dit pas ce qu’il faut faire. Pour préparer une décision, il faut la lire : quelles applications sont critiques, lesquelles font double emploi, lesquelles peuvent s’arrêter, et ce que le prochain projet devra reprendre.

Cette lecture est l’objet d’un audit du SI ciblé sur la décision à prendre. La cartographie en est le socle. L’audit en tire une recommandation que la direction peut arbitrer.

En résumé

Une cartographie du SI se fait pour une question, pas pour elle-même. La décision à prendre fixe son périmètre, son niveau de détail et sa date.

Deux vues suffisent le plus souvent : fonctionnelle et applicative. Leur superposition montre les doublons, les manques et ce qui peut s’arrêter.

La méthode part de ce qui est payé, passe par les ateliers métier et se termine par une validation datée. L’outil vient après la première cartographie, pas avant.