Quand un projet de modernisation, de mise en conformité ou de renforcement sécurité démarre, la première question devrait être simple : est-ce qu’on sait réellement ce qu’on a ?
Dans la majorité des cas, la réponse est non, ou seulement partiellement. Il existe bien des schémas d’architecture, parfois un inventaire applicatif, souvent une documentation produite à un moment donné et jamais mise à jour. Mais entre ce qui est documenté et ce qui tourne réellement en production, l’écart est presque toujours significatif.
La cartographie du SI n’est pas un exercice académique. C’est le préalable méthodique sans lequel toute décision de transformation repose sur une lecture incomplète. Et sur un SI critique, une lecture incomplète mène à des surprises coûteuses.
Ce que “cartographier” signifie en pratique
Cartographier un SI ne consiste pas à produire un schéma avec des boîtes et des flèches. Cela consiste à rendre lisibles les couches du système telles qu’elles fonctionnent réellement, pas telles qu’elles ont été conçues il y a cinq ans.
En pratique, la cartographie couvre au minimum quatre niveaux. Le premier est applicatif : quels composants sont en production, quelles sont leurs responsabilités fonctionnelles, et quels sont leurs liens de dépendance. Le deuxième est celui des flux : quelles données circulent entre les composants, par quels protocoles, à quelle fréquence, et avec quelles contraintes de latence ou de disponibilité. Le troisième concerne l’infrastructure : sur quels environnements chaque composant tourne, avec quelles dépendances d’exécution (runtime, base de données, cache, file d’attente), et selon quel modèle de déploiement. Le quatrième est celui de l’identité et des droits : qui accède à quoi, avec quels comptes, quels mécanismes d’authentification, et quelles règles de cloisonnement.
Sur un SI de gestion de contrats dans le secteur financier, ce travail a récemment révélé que le schéma d’architecture officiel ne mentionnait pas trois services intermédiaires ajoutés au fil du temps, que deux flux nocturnes de synchronisation de données passaient par un serveur FTP qui n’apparaissait dans aucun inventaire, et que les droits d’accès à la base de production étaient partagés via un compte générique utilisé par six personnes.
Rien de spectaculaire pris isolément. Mais l’accumulation de ces angles morts rend le système impossible à transformer sereinement.
Pourquoi la documentation existante ne suffit presque jamais
La plupart des organisations ont de la documentation. Le problème est rarement son absence totale, mais plutôt sa fiabilité et sa fraîcheur.
Un schéma d’architecture produit lors de la mise en service initiale, il y a trois ou cinq ans, reflète un état qui n’existe plus. Les composants ont été ajoutés, retirés ou remplacés sans que le schéma soit mis à jour. Les flux ont évolué avec les besoins métier. Des scripts de contournement sont devenus des composants de fait, sans jamais entrer dans le radar de la documentation officielle.
Le résultat est une documentation qui donne l’illusion de la lisibilité sans en offrir la substance. Elle est suffisamment détaillée pour qu’on ne la remette pas en question, mais trop datée pour servir de base à une décision réelle.
C’est pour cela que la cartographie utile ne part pas de la documentation existante. Elle part de la production : logs, monitoring, historique Git, entretiens avec les exploitants, analyse des flux réseau réels. La documentation existante sert de point de départ, mais elle est systématiquement confrontée à la réalité opérationnelle.
Les dépendances invisibles sont le vrai risque
Sur un SI qui a vécu plusieurs années, les dépendances les plus dangereuses ne sont pas celles qui apparaissent dans les diagrammes. Ce sont celles que personne n’a documentées parce qu’elles semblaient temporaires ou secondaires.
Un batch lancé par cron chaque nuit pour consolider des données entre deux systèmes. Un fichier CSV déposé par FTP vers un partenaire qui n’accepte que ce format depuis 2018. Une bibliothèque partagée entre trois services, dont la version n’a pas été mise à jour depuis deux ans parce que personne ne sait exactement quels effets de bord cela produirait. Un service de cache qui masque un problème de performance sur la base de données, et dont l’arrêt provoquerait une dégradation visible de tout le système.
Ces dépendances ne se révèlent généralement pas par l’analyse statique du code. Elles se révèlent par l’analyse de l’activité réelle : les logs de production, les patterns de trafic, les anomalies de timing, et surtout les témoignages des exploitants. Un opérateur qui dit “on ne redémarre jamais ce service parce que la dernière fois ça a tout cassé” est souvent la meilleure source de cartographie disponible.
La cartographie des droits est un sujet à part entière
Sur beaucoup de SI, la cartographie applicative et la cartographie des droits sont traitées séparément, si cette dernière est traitée du tout.
C’est une erreur. Comprendre qui accède à quoi, avec quels comptes, quels mécanismes et quels niveaux de privilège fait partie intégrante de la lecture du système. Un annuaire LDAP ou un fournisseur d’identité ne dit pas tout : il faut aussi voir les comptes de service, les accès directs en base de données, les clés API distribuées sans rotation, les droits hérités qui n’ont jamais été révoqués.
Sur un projet dans le secteur assurantiel, la cartographie des droits a révélé que 40 % des comptes actifs dans l’annuaire correspondaient à des collaborateurs ayant quitté l’entreprise depuis plus d’un an. Pas par malveillance, simplement parce que le processus de départ ne prévoyait pas la révocation systématique des accès techniques.
Ce type de découverte a un impact direct sur le périmètre de toute transformation. On ne peut pas renforcer la sécurité d’un système si on ne sait pas qui y accède réellement.
La cartographie n’est pas un livrable, c’est un processus
L’erreur classique est de traiter la cartographie comme un projet ponctuel. On mandate un audit, on produit un rapport de 80 pages avec des schémas, on le range dans un dossier partagé, et six mois plus tard il est déjà obsolète.
La cartographie utile est vivante. Elle est alimentée en continu par le monitoring, les déploiements, les revues de sécurité et les retours d’incident. Elle est accessible à l’équipe et maintenue comme un artefact du système, au même titre que le code ou les tests.
En pratique, cela peut prendre des formes très simples : un diagramme d’architecture versionné dans le dépôt Git, mis à jour à chaque changement significatif. Un inventaire des composants et de leurs dépendances maintenu dans un tableur structuré ou un outil dédié. Une revue trimestrielle des flux et des droits, intégrée au processus de maintenance courante.
L’enjeu n’est pas la sophistication de l’outil. C’est la discipline de mise à jour.
Ce que la cartographie permet ensuite
Une cartographie à jour ne résout rien en elle-même. Mais elle conditionne toutes les décisions suivantes.
Elle permet d’identifier les zones de fragilité avant de lancer une modernisation, plutôt que de les découvrir en cours de migration. Elle permet de dimensionner correctement un projet de mise en conformité, en sachant quels flux et quels droits sont réellement concernés. Elle permet de prioriser les actions de sécurité sur les composants qui concentrent le risque, plutôt que de traiter le SI comme un bloc homogène. Et elle permet aux équipes de reprendre confiance dans leur capacité à faire évoluer le système, parce qu’elles savent enfin ce qu’elles touchent.
Sans cartographie, on avance à l’intuition. Avec une cartographie à jour, on avance sur des faits.
Conclusion
Cartographier un SI n’est pas un exercice préparatoire qu’on peut sauter pour aller plus vite. C’est le socle qui rend possible toute transformation, toute sécurisation et tout maintien en condition de confiance.
Lire un SI avant de prétendre le transformer, distinguer la documentation de la réalité d’exploitation : ces lectures structurent nos missions. Modernisation et maintien en condition de confiance.