Architecture et cartographie¶

Documenter l'architecture d'un système pour permettre à toute l'équipe de comprendre comment les pieces s'assemblent.

Pourquoi les diagrammes d'architecture¶

Un diagramme d'architecture bien construit répond en quelques secondes a des questions qui prennent des heures a reconstituer sans lui :

Quels services communiquent avec ce composant ?
Ou sont les points de défaillance unique ?
Quelles équipes ou systèmes externes sont impactes si ce service tombe ?
Quel est le chemin d'un appel depuis l'utilisateur jusqu'à la base de données ?

Un diagramme est un modèle, pas la réalité

Tout diagramme simplifie. L'objectif n'est pas l'exhaustivité mais la lisibilite. Un diagramme trop détaillé n'est pas plus utile qu'une carte au 1/1 — il faut choisir le niveau d'abstraction adapté à l'audience.

Le modèle C4¶

Le modèle C4 (Context, Container, Component, Code) propose quatre niveaux d'abstraction progressifs. On n'utilise pas tous les niveaux pour tous les systèmes.

Niveau	Nom	Contenu	Audience
1	Context	Le système dans son écosystème — utilisateurs, systèmes externes	Tout le monde, management
2	Container	Applications, services, bases de données qui composent le système	Ops, dev, sécurité
3	Component	Modules et composants internes d'un container	Développeurs
4	Code	Classes, fonctions — diagramme UML	Rarement nécessaire

En exploitation, les niveaux 1 et 2 sont les plus utiles. Le niveau 3 est pertinent pour les systèmes critiques ou complexes.

Exemple niveau 2 : plateforme e-commerce¶

graph TB
    subgraph "Utilisateurs"
        U1["Client web"]
        U2["Client mobile"]
        U3["Admin back-office"]
    end

    subgraph "Plateforme e-commerce"
        FE["Frontend SPA"]
        API["API Gateway"]
        SVC_CMD["Service commandes"]
        SVC_CAT["Service catalogue"]
        DB_CMD[("BDD commandes")]
        DB_CAT[("BDD catalogue")]
        CACHE["Cache Redis"]
        QUEUE["Queue messages"]
    end

    EXT["Systeme paiement externe"]

    U1 --> FE
    U2 --> API
    U3 --> FE
    FE --> API
    API --> SVC_CMD
    API --> SVC_CAT
    SVC_CMD --> DB_CMD
    SVC_CMD --> QUEUE
    SVC_CAT --> DB_CAT
    SVC_CAT --> CACHE
    QUEUE --> EXT

Outils de diagrammes¶

Outil	Approche	Avantages	Inconvénients
Mermaid	Texte (Markdown)	Versionnable, gratuit, intégré MkDocs	Mise en forme limitee pour grands diagrammes
draw.io (diagrams.net)	Interface graphique	Flexible, export XML versionnable	Moins intégré au workflow Git
Structurizr	DSL + C4 natif	C4 natif, rendu automatique	Courbe d'apprentissage
PlantUML	Texte (DSL)	Versionnable, riche en types	Syntaxe verbeuse
Lucidchart	Interface graphique SaaS	Collaboratif, templates	Payant, données hors contrôle

Pour une approche docs-as-code, Mermaid est le choix pragmatique. Pour des architectures complexes avec plusieurs niveaux C4, Structurizr est preferable.

CMDB : Configuration Management Database¶

Une CMDB recense les actifs d'infrastructure et leurs relations. Elle répond aux questions : qu'est-ce qui existe, ou, dans quel état, et avec quelles dépendances ?

Quoi mettre dans une CMDB¶

Type d'élément	Attributs clés
Serveurs / VM	Nom, IP, OS, environnement, owner, criticite
Services applicatifs	Nom, version, dépendances, SLA
Bases de données	Type, version, serveur, taille, backup schedule
Composants réseau	Type, localisation, VLAN, responsable
Certificats	Domaine, date expiration, responsable

Maintenir la CMDB à jour¶

La CMDB devient inutile si elle est obsolète. Stratégies pour la maintenir :

Lier toute création ou modification d'infrastructure a une mise à jour CMDB (IaC + CMDB)
Utiliser des outils d'auto-discovery (Netbox, Snipe-IT, AWS Config, Azure Resource Graph)
Revue trimestrielle par domaine avec les équipes proprieetaires

Une CMDB jamais mise à jour est pire qu'une absence de CMDB

Elle crée une fausse confiance. Mieux vaut une CMDB partielle mais fiable qu'une CMDB complète et perimee.

Dependency mapping¶

Le dependency mapping va au-delà de l'inventaire : il cartographie les flux et dépendances entre composants pour anticiper les impacts en cascade.

Auto-discovery¶

Plusieurs outils permettent de générer automatiquement des cartes de dépendances :

Outil	Périmètre	Notes
Netbox	Réseau, IP, rack	Open source, très complet
AWS Config / Service Map	AWS uniquement	Natif cloud, très fiable
Datadog Service Map	Applicatif (APM)	Nécessité agents
Dynatrace Smartscape	Infrastructure + appli	Puissant, coûteux

Documentation manuelle des dépendances critiques¶

Pour les composants critiques, combler les angles morts de l'auto-discovery par une documentation explicite :

Dépendances externes (API tierces, fournisseurs)
Dépendances organisationnelles (qui appelle qui en cas d'incident)
Dépendances de configuration (quel service lit quelle configuration)

Commencez par les services avec les SLA les plus exigeants

Cartographier toutes les dépendances en une fois est decourageant. Commencez par les services critiques et etendez progressivement.