Votre SI existe. Savez-vous le dessiner ?

Cartographie SI outils — ce guide compare les solutions gratuites pour documenter votre système d’information en PME ou ETI.

Votre système d’information tourne. Les flux de données circulent, les applications communiquent, les workflows s’enchaînent. Mais si quelqu’un vous demandait de montrer comment tout ça fonctionne sur un schéma, que répondriez-vous ?

Pour la plupart des PME, la réponse honnête est : “on a un Visio quelque part, ou un PowerPoint, qui date de 2019 et ne reflète plus grand-chose.” La cartographie du SI est l’une des pratiques les plus négligées — et l’une des plus utiles quand elle est bien faite.

Ce n’est pas un exercice réservé aux grandes DSI. C’est une pratique accessible, avec des outils gratuits et ouverts, qui change concrètement la façon dont on parle d’architecture, dont on onboarde de nouveaux collaborateurs, et dont on prend des décisions techniques.

Pourquoi cartographier son SI

La question n’est pas vraiment “faut-il cartographier ?” — elle est “à qui sert cette cartographie, et pour quoi faire ?”

Trois usages concrets dominent :

La communication — expliquer à un dirigeant, un auditeur ou un nouveau collaborateur comment les systèmes s’articulent. Un schéma bien construit vaut dix minutes d’explication orale.

La décision — avant d’ajouter un nouvel outil, d’intégrer une API ou de migrer une application, visualiser les dépendances existantes évite les mauvaises surprises. On voit immédiatement ce qui dépend de quoi.

La documentation vivante — un diagramme écrit en code (D2, DSL Structurizr) se versionne dans Git comme le code source. Il évolue avec le SI au lieu de se périmer dans un coin de SharePoint.

Les 4 niveaux de représentation à connaître

Avant de choisir un outil, il faut comprendre ce qu’on veut représenter. Les architectes utilisent généralement 4 niveaux de zoom, formalisés par le modèle C4 de Simon Brown.

Niveau 1 — Contexte

La vue la plus haute : votre système dans son environnement. Qui l’utilise ? Avec quels systèmes externes communique-t-il ? C’est le schéma qu’on montre à un dirigeant ou un client.

Niveau 2 — Conteneurs

Les grandes briques techniques : l’application web, la base de données, l’API, le service d’orchestration. Les conteneurs communiquent entre eux — on représente ces échanges avec leurs protocoles.

Niveau 3 — Composants

À l’intérieur d’un conteneur : les modules, services ou workflows qui le composent. Pour un outil comme n8n par exemple, ce niveau représente les workflows individuels et leurs interactions.

Niveau 4 — Code

Le niveau des classes, fonctions et dépendances. Rarement utile dans un contexte PME — on s’arrête généralement au niveau 3.

Les outils : forces et limites

L’offre est pléthorique. Mermaid, PlantUML, draw.io, Lucidchart, Miro, Sparx Enterprise Architect, LeanIX, Ardoq, BizzDesign HoriZZon, MEGA Hopex, iGrafx… Des dizaines d’outils couvrent tout ou partie de la cartographie SI. Pour s’y retrouver, deux critères s’imposent à une PME.

Gratuit. Les plateformes d’architecture d’entreprise comme LeanIX, Ardoq ou BizzDesign HoriZZon sont puissantes — et leurs tarifs dépassent souvent 1 000 €/mois. Ils s’adressent aux grandes DSI avec une équipe architecture dédiée. Pour une PME, la question ne se pose pas.

Intégrable dans un flux d’automatisation. Un diagramme qui vit dans un fichier texte (.d2, .dsl) se versionne dans Git, se génère par script, se met à jour via API. Un fichier Visio ou Lucidchart ne peut pas. C’est la différence entre une documentation qui se maintient et une documentation qui se périme.

Sur cette base, quatre outils se dégagent : D2, C4/Structurizr, ArchiMate (via Archi + jArchi) et Diagrams — ce dernier occupant une place à part pour les environnements cloud. BPMN, souvent cité dans ce contexte, est délibérément écarté : c’est un langage de modélisation de processus métier — pas un outil de cartographie d’architecture. Il a toute sa pertinence pour documenter un circuit de validation ou un processus de commande, mais il répond à une question différente.

D2 — le diagramme as-code

D2 est un langage de description de diagrammes : vous écrivez du texte, D2 génère le visuel. La syntaxe est simple, le rendu propre, et le fichier .d2 se versionne dans Git comme n’importe quel fichier de code.

direction: right

utilisateur -> site: "Soumet formulaire"
site -> n8n: "POST /webhook"
n8n -> supabase: "INSERT données"

Forces :

• Fichier texte versionnable, lisible sans outil spécifique
• Rendu sequence diagram ou flow diagram selon le besoin
• Icônes via URL (Iconify, Simple Icons) pour les logos tech
• Idéal pour documenter des flux techniques dans un README ou un wiki

Limites :

• Pas de standard métier — la sémantique des blocs est libre
• Le moteur de layout automatique peut donner des résultats imprévisibles sur les diagrammes complexes
• Peu adapté à la communication avec des non-techniques

Quand l’utiliser : documenter un workflow n8n, une architecture de services, un flux de données entre APIs. Tout ce qui vit dans un repo Git.

C4 Model avec Structurizr — l’architecture en 4 zooms

Le modèle C4 propose une approche structurée en 4 niveaux de zoom (Contexte, Conteneurs, Composants, Code). Structurizr en est l’implémentation de référence : vous écrivez un fichier DSL qui déclare les éléments et leurs relations, Structurizr génère tous les diagrammes automatiquement.

workspace {
  model {
    utilisateur = person "Utilisateur"
    sys = softwareSystem "Mon Système" {
      webapp = container "Application Web" { technology "React" }
      db = container "Base de données" { technology "PostgreSQL" }
    }
    utilisateur -> webapp "Utilise"
    webapp -> db "Lit et écrit"
  }
  views {
    container sys { include * autoLayout }
  }
}

Forces :

• Navigation entre niveaux intégrée dans l’interface
• Un seul fichier DSL, plusieurs vues générées automatiquement
• Structurizr Lite fonctionne en local via Docker — gratuit, aucun compte requis
• Les relations se propagent entre les vues

Limites :

• Nécessite Docker pour Structurizr Lite
• DSL plus verbeux que D2
• autoLayout donne parfois des résultats à retravailler manuellement

Quand l’utiliser : documenter l’architecture d’une application ou d’un SI complet, naviguer entre niveaux d’abstraction, onboarder de nouveaux membres sur un système complexe.

ArchiMate — la vue d’ensemble du SI

ArchiMate est un standard ouvert (The Open Group) conçu pour représenter l’ensemble d’un SI en 3 couches horizontales : Métier, Application et Infrastructure. Il permet de tracer les alignements entre stratégie métier et architecture technique.

Forces :

• Standard reconnu, utilisé dans les audits et les revues de gouvernance
• Force à penser en 3 couches et à tracer les alignements métier ↔ technique
• Outil de référence : Archi (open source, gratuit) — implémentation de référence d’ArchiMate
• jArchi — le plugin JavaScript d’Archi permet d’automatiser la génération et la mise à jour des modèles via script, y compris depuis Claude
• Intégration CMDB — via jArchi et les APIs REST de GLPI ou ServiceNow, les éléments du modèle (serveurs, applications, services) peuvent être synchronisés avec l’inventaire réel. Vos diagrammes reflètent ce qui est réellement en production, pas ce qui était prévu il y a 18 mois
• Export HTML interactif — Archi génère un site statique navigable avec toutes vos vues, partageable avec la direction ou des auditeurs sans qu’ils aient à installer quoi que ce soit. Combiné à jArchi, cet export peut être automatisé en CI/CD
• Navigation par objet — clic droit sur n’importe quel élément (une application, un serveur, un service) → Archi liste toutes les vues où il apparaît. Utile pour l’analyse d’impact : avant de modifier un composant, vous voyez immédiatement tous les diagrammes concernés

Limites :

• Courbe d’apprentissage significative (notation formelle, dizaines de types d’éléments)
• L’intégration CMDB via jArchi nécessite du développement — ce n’est pas clé en main
• Trop verbeux pour des cas d’usage simples

Quand l’utiliser : cartographie stratégique du SI, dossiers d’architecture d’entreprise, communication avec la direction ou des auditeurs. Et dès que vous avez un CMDB (GLPI, ServiceNow) et que vous voulez une architecture qui reste synchronisée avec l’inventaire.

Diagrams (Python) — la cartographie cloud-native

Diagrams est une bibliothèque Python open source qui génère des diagrammes d’architecture à partir de code. Son positionnement est radicalement différent des trois outils précédents : il est conçu spécifiquement pour les environnements cloud, avec les icônes officielles des providers (AWS, Azure, GCP, Kubernetes, Oracle Cloud…) directement intégrées.

from diagrams import Diagram, Cluster
from diagrams.aws.compute import EC2
from diagrams.aws.database import RDS
from diagrams.aws.network import ELB

with Diagram("Architecture AWS", show=False):
    lb = ELB("Load Balancer")
    with Cluster("Auto Scaling Group"):
        servers = [EC2("api-1"), EC2("api-2")]
    db = RDS("PostgreSQL")
    lb >> servers >> db

L’avantage clé : génération depuis les CLI cloud. En combinant Diagrams avec les CLI AWS, Azure ou GCP (aws ec2 describe-instances, az resource list, gcloud compute instances list), on peut scripter la génération automatique d’un diagramme fidèle à l’infrastructure réelle — pas à ce qui était prévu, à ce qui tourne. C’est l’approche la plus proche d’une cartographie “as-deployed”.

Forces :

• Icônes officielles AWS, Azure, GCP, K8s → représentation immédiatement reconnaissable par les équipes cloud
• As-code Python, versionnable dans Git, automatisable en CI/CD
• Clusters natifs pour représenter VPCs, zones de disponibilité, namespaces Kubernetes
• Scriptable : extraction CLI → génération de diagramme en pipeline automatisé
• Gratuit et open source

Limites :

• Nécessite Python et Graphviz installés — barrière technique réelle pour les non-développeurs
• Le moteur de layout (Graphviz) positionne les nœuds automatiquement : les diagrammes complexes deviennent vite illisibles sans ajustements manuels
• La génération depuis les CLI cloud n’est pas native — elle demande du scripting, voire des outils complémentaires comme InfraMap ou Steampipe pour le discovery automatique
• Rendu statique (PNG/PDF uniquement) : aucune interactivité, aucun drill-down
• Activité de maintenance ralentie depuis 2023
• Limité à la couche infrastructure — ne représente ni les processus métier ni les couches applicatives au sens ArchiMate

Quand l’utiliser : votre SI est majoritairement cloud (AWS, Azure, GCP) et vous voulez une cartographie fidèle à l’infrastructure déployée, générée et mise à jour automatiquement. Le cas d’usage type : un pipeline CI/CD qui régénère le diagramme à chaque terraform apply ou déploiement Kubernetes.

Tableau comparatif

Les outils exclus et pourquoi : BPMN (processus métier, pas architecture SI), Mermaid (alternative valide à D2, retenu si vous vivez dans GitHub), draw.io / Lucidchart / Miro (GUI sans intégration d’automatisation), Sparx EA, LeanIX, Ardoq, MEGA Hopex (tarifs hors portée PME, >1 000 €/mois).

Par où commencer selon votre contexte

Vous voulez documenter un workflow ou un flux entre services → D2. Installez-le en 5 minutes (brew install d2), écrivez votre premier fichier, générez un SVG. Le résultat est versionnable et maintenable. Si votre documentation vit dans GitHub ou Notion, regardez aussi Mermaid — la syntaxe est encore plus simple et l’intégration est native.

Vous voulez cartographier votre SI sur plusieurs niveaux → C4 avec Structurizr Lite. Lancez Docker, écrivez votre workspace.dsl, naviguez entre les niveaux Contexte et Conteneurs en quelques minutes.

Vous préparez un dossier d’architecture formelle ou une revue de gouvernance → ArchiMate avec Archi. Prévoyez du temps pour monter en compétence sur la notation. Si vous avez un CMDB (GLPI, ServiceNow), explorez jArchi pour synchroniser vos modèles avec l’inventaire réel.

Votre SI est majoritairement cloud (AWS, Azure, GCP) et vous voulez une cartographie générée depuis l’infrastructure réelle → Diagrams avec Python. Attendez-vous à du scripting : il faut extraire les ressources via les CLI cloud et coder leur représentation. Si vous cherchez du discovery automatique clé en main, regardez d’abord InfraMap ou Steampipe.

Vous voulez formaliser un processus métier avec des acteurs humains et des conditions de routage → BPMN dans draw.io ou Camunda Modeler. C’est un cas d’usage distinct de la cartographie SI — mais il vaut d’être documenté séparément.

La règle d’or : un diagramme qui ne se maintient pas ne vaut rien

Le vrai enjeu n’est pas l’outil — c’est la discipline de mise à jour. Un beau schéma ArchiMate qui date de 18 mois est moins utile qu’un fichier D2 basique maintenu à chaque sprint.

Les outils as-code (D2, DSL Structurizr) ont un avantage décisif sur ce point : ils s’intègrent dans les workflows de développement existants. Une pull request qui modifie l’architecture inclut la mise à jour du diagramme. C’est dans le repo, c’est reviewable, c’est versionné.

Visio, PowerPoint, draw.io statique : des outils à proscrire

Il faut être direct : les outils de dessin statiques — Visio, PowerPoint, draw.io utilisé comme un bloc-notes — ne sont plus adaptés à la réalité d’un SI moderne. Ils étaient acceptables quand un SI d’entreprise se résumait à quelques serveurs on-premise et un ERP. Ce temps est révolu.

Un SI de PME en 2026 consomme en moyenne une dizaine de SaaS, deux ou trois fournisseurs cloud, des workflows d’automatisation qui évoluent chaque semaine, des APIs qui changent de version, des modèles d’IA qui s’intègrent dans les processus. Chaque nouvelle brique modifie les dépendances. Chaque migration reconfigure les flux.

Dans ce contexte, un fichier Visio est structurellement condamné à mentir. Il reflète l’état du SI au moment où quelqu’un a eu le courage de le mettre à jour — rarement aujourd’hui, souvent il y a six mois. Personne ne l’ouvre pour prendre une décision parce que tout le monde sait qu’il est faux. Il existe pour rassurer lors des audits, pas pour piloter.

La cartographie du SI n’est pas un projet — c’est une pratique. Elle commence avec un premier fichier, imparfait, qui représente honnêtement l’état actuel du système. Elle s’améliore à chaque changement, dans le même repo que le code, avec les mêmes outils.

Votre SI existe. Il ne demande qu’à être dessiné — avec les bons outils.