Introduction : La révolution de la documentation commence ici
Dans le monde effréné du développement logiciel, il existe une vérité inconfortable que nous affrontons tous :notre documentation est presque toujours obsolète. Nous avons passé d’innombrables heures à lutter avec des outils de diagrammes par glisser-déposer, alignant méticuleusement des boîtes et des flèches, pour seulement voir nos visuels soigneusement conçus devenir obsolètes dès que le code change.
Mais et si la documentation pouvait suivre le rythme du développement ? Et si la création de diagrammes d’architecture professionnels était aussi simple que d’écrire une fonction ?
Bienvenue dans la révolution du Diagramme-as-Code. Ce tutoriel vous guidera à traversVPasCode, la plateforme basée sur le navigateur de Visual Paradigm qui transforme la façon dont les équipes créent, partagent et maintiennent les diagrammes d’architecture système. En traitant les diagrammes comme du code, vous découvrirez comment produire des visuels de qualité publication en quelques minutes, pas en heures, tout en assurant que votre documentation évolue de manière transparente avec vos systèmes.
Que vous soyez un développeur documentant des microservices, un architecte présentant à des parties prenantes, ou un ingénieur DevOps cartographiant l’infrastructure, ce guide complet vous dotera des compétences pour maîtriser VPasCode et améliorer le niveau de documentation de votre équipe.
1. Premiers pas : Votre premier diagramme en 5 minutes {#getting-started}
Aucune installation, aucune configuration, juste du code
L’une des fonctionnalités les plus puissantes de VPasCode est son intégration sans friction. Rien à installer, aucun compte à créer, aucune configuration complexe. Créons votre premier diagramme dès maintenant.
Démarrage rapide étape par étape :
-
Accédez à VPasCode: Ouvrez votre navigateur et visitezhttps://www.vpascode.com/editor/
-
Choisissez votre moteur: Sélectionnez dans le menu déroulant :
-
Mermaid – Idéal pour les organigrammes et la documentation moderne
-
PlantUML – Idéal pour les diagrammes UML et l’architecture d’entreprise
-
Graphviz – Parfait pour les topologies de réseau complexes
-
-
Chargez un modèle: Cliquez sur « Exemples » et sélectionnez un modèle de démarrage
-
Éditez et prévisualisez: Modifiez le code dans le panneau de gauche ; regardez votre diagramme se mettre à jour instantanément à droite
-
Exportez ou partagez: Téléchargez en SVG/PNG ou copiez l’URL partageable

Figure 1 : VPasCode transforme instantanément le code basé sur du texte en diagrammes d’architecture professionnels
2. Comprendre l’interface VPasCode {#interface}
Avant de plonger en profondeur dans la syntaxe, familiarisons-nous avec l’espace de travail.

Figure 2 : L’interface à deux panneaux de VPasCode — code à gauche, aperçu en direct à droite
Détail des composants de l’interface :
Panneau gauche (éditeur de code) :
-
Éditeur de texte avec mise en évidence de la syntaxe
-
Numéros de ligne pour une référence facile
-
Prise en charge de l’auto-complétion
-
Mise en évidence des erreurs en temps réel
Panneau droit (aperçu en direct) :
-
Rendu visuel instantané
-
Contrôles de déplacement et de zoom
-
Affichage vectoriel (net à tout niveau de zoom)
-
Cliquez pour inspecter les éléments
Barre d’outils supérieure :
-
Sélecteur de moteur (Mermaid/PlantUML/Graphviz)
-
Galerie de modèles
-
Options d’exportation (SVG, PNG, PDF)
-
Bouton de partage (génère une URL permanente)
-
Paramètres et préférences
Barre d’état inférieure :
-
Statut de validation de la syntaxe
-
Compteur de caractères
-
Horodatage de la dernière sauvegarde
-
Référence des raccourcis clavier
Principe fondamental du flux de travail :
Écrire du code → Voir l'aperçu instantané → Affiner → Exporter/Partager
Cette boucle de rétroaction immédiate est ce qui rend VPasCode si puissant. Il n’y a pas de bouton « rendre » à cliquer, pas d’attente de compilation — juste un retour visuel pur et instantané pendant que vous tapez.
3. Maîtriser Mermaid.js : Diagrammes de flux et au-delà {#mermaid-tutorial}
Mermaid.js est devenu la norme de facto pour la création de diagrammes adaptée aux développeurs. Sa syntaxe est intuitive, lisible et parfaite pour la documentation qui vit aux côtés du code.
Tutoriel 1 : Création d’un flux d’authentification utilisateur
Créons un diagramme de flux d’authentification pratique que vous pourriez utiliser lors de votre prochaine planification de sprint.
Code exemple :

graph TD
A[Utilisateur entre ses identifiants] --> B{Format valide ?}
B -->|Non| C[Afficher une erreur de validation]
B -->|Oui| D[Envoyer au service d'authentification]
C --> A
D --> E{Les identifiants correspondent-ils ?}
E -->|Non| F[Retourner 401 Non autorisé]
E -->|Oui| G[Générer un jeton JWT]
G --> H[Stocker le jeton dans un cookie HttpOnly]
H --> I[Rediriger vers le tableau de bord]
F --> A
style A fill:#e1f5ff,stroke:#0066cc
style I fill:#d4edda,stroke:#28a745
style F fill:#f8d7da,stroke:#dc3545
Ce que cela démontre :
-
Nœuds de décision (losanges avec
{?}) -
Flux directionnel (
TD= Haut-Bas) -
Style personnalisé avec des couleurs
-
Boucles auto-référentielles
-
Étiquetage clair
Tutoriel 2 : Diagramme d’architecture de microservices
Créons maintenant une architecture système plus complexe montrant les relations entre les services.
Code exemple :

graph LR
subgraph Client["Couche Client"]
Web[Application Web<br/>React]
Mobile[Application Mobile<br/>Flutter]
end
subgraph API["Passerelle API"]
Gateway[ Passerelle Kong ]
Auth[Service d'authentification]
Rate[Limiteur de débit]
end
subgraph Services["Services métier"]
User[Service utilisateur]
Order[Service de commande]
Product[Service produit]
Payment[Service de paiement]
end
subgraph Data["Couche de données"]
UserDB[(Base de données utilisateur<br/>PostgreSQL)]
OrderDB[(Base de données de commande<br/>MongoDB)]
ProductDB[(Base de données de produit<br/>PostgreSQL)]
Cache[(Cache Redis)]
end
Web --> Gateway
Mobile --> Gateway
Gateway --> Auth
Gateway --> Rate
Rate --> User
Rate --> Order
Rate --> Product
User --> UserDB
User --> Cache
Order --> OrderDB
Order --> Payment
Product --> ProductDB
Payment --> OrderDB
style Gateway fill:#ff6b6b,stroke:#c92a2a,color:white
style UserDB fill:#4ecdc4,stroke:#087f5b
style OrderDB fill:#4ecdc4,stroke:#087f5b
style ProductDB fill:#4ecdc4,stroke:#087f5b
style Cache fill:#ffe66d,stroke:#f08c00
Concepts clés :
-
subgraphpour un regroupement logique -
LRpour une disposition de gauche à droite -
Étiquettes multi-lignes avec
<br/> -
Notation de cylindre de base de données avec
[( )] -
Routage et relations complexes
Tutoriel 3 : Diagramme de séquence pour le traitement des commandes
Les diagrammes de séquence sont essentiels pour comprendre les interactions temporelles entre les composants.
Code exemple :

sequenceDiagram
autonumber
participant C as Client
participant W as Application Web
participant O as Service de Commande
participant P as Service de Paiement
participant I as Service d'Inventaire
participant N as Service de Notification
C->>W: Ajouter des articles au panier
C->>W: Cliquer sur "Payer"
W->>O: POST /orders {articles, livraison}
O->>I: Réserver l'inventaire
I-->>O: Réservation confirmée
O->>P: Traiter le paiement
P-->>O: Paiement réussi
O->>O: Créer un enregistrement de commande
O->>N: Envoyer une confirmation de commande
N-->>C: Confirmation par e-mail
O-->>W: 201 Created {orderId}
W-->>C: Afficher la page de succès
Note over O,P: Section critique<br/>doit être transactionnelle
rect rgba(200, 200, 0, 0.2)
O->>P: Charger la carte
P-->>O: ID de transaction
end
Fonctionnalités du diagramme de séquence :
-
autonumberpour une numérotation automatique des étapes -
participantdéclarations -
->>pour les appels synchrones -
-->>pour les réponses -
Note au-dessuspour les annotations -
rectpour mettre en évidence des sections
Tutoriel 4 : Diagramme de Gantt pour la planification de sprint
Mermaid prend également en charge la visualisation des chronologies de projet.
Code exemple :

gantt
titre Sprint 24 - Module d'authentification
formatDate YYYY-MM-DD
formatAxe %m/%d
section Backend
Conception des contrats API :terminé, des1, 2024-06-01, 2j
Implémentation du service JWT :actif, des2, 2024-06-03, 3j
Migration de la base de données : des3, après des2, 2j
Tests unitaires : des4, après des3, 2j
section Frontend
Composant de connexion : front1, 2024-06-03, 3j
Gestion des jetons : front2, après front1, 2j
Routes protégées : front3, après front2, 2j
section Intégration
Intégration API : int1, après des4, 2j
Tests E2E : int2, après int1, 3j
Audit de sécurité : int3, après int2, 2j
4. Plongée profonde dans PlantUML : Architecture d’entreprise {#plantuml-tutoriel}
PlantUML excelle dans la création de diagrammes UML formels et de documentation d’architecture d’entreprise. Explorons des exemples pratiques.
Tutoriel 1 : Diagramme de composants pour une plateforme de commerce électronique
Code exemple :

@startuml
!theme plain
skinparam backgroundColor #FFFFFF
skinparam componentStyle uml2
title "Plateforme de commerce électronique - Architecture des composants"
package "Couche de présentation" {
[Frontend Web] as Web
[Application mobile] as Mobile
[Tableau de bord administrateur] as Admin
}
package "Couche API" {
[Passerelle API] as Gateway
[Authentification] as Auth
[Limiteur de débit] as RateLimit
}
package "Services métier" {
[Service de catalogue] as Catalog
[Service de commande] as Order
[Service de paiement] as Payment
[Service d'expédition] as Shipping
[Service de notification] as Notify
}
package "Couche de données" {
base de données "Base de données produits" as ProdDB
base de données "Base de données des commandes" as OrderDB
base de données "Base de données des utilisateurs" as UserDB
file d'attente "File d'attente de messages" as MQ
}
Web --> Gateway
Mobile --> Gateway
Admin --> Gateway
Gateway --> Auth
Gateway --> RateLimit
Gateway --> Catalog
Gateway --> Order
Order --> Payment
Order --> Shipping
Order --> Notify
Catalog --> ProdDB
Order --> OrderDB
Auth --> UserDB
Payment ..> MQ : publier des événements
Shipping ..> MQ : s'abonner aux événements
Notify ..> MQ : s'abonner aux événements
@enduml

Figure 3 : Diagramme de composants PlantUML montrant une architecture en couches
Tutoriel 2 : Diagramme de déploiement pour l’infrastructure cloud
Code exemple :
Tutoriel 3 : Modèle C4 – Diagramme de conteneurs
Le modèle C4 est excellent pour communiquer l’architecture logicielle à plusieurs niveaux d’abstraction.
Code d’exemple :

@startuml
!define AWS_COLOR FF9900
!define DOCKER_COLOR 0DB7ED
skinparam componentStyle uml2
skinparam backgroundColor #FAFAFA
title “Architecture de déploiement cloud”
package “Région AWS : us-east-1” {
package “Sous-réseau public” {
[CloudFront CDN] as CDN
[Équilibreur de charge d’application] as ALB #AWS_COLOR
}
package “Sous-réseau privé 1” {
[Serveur Web 1] as Web1 #DOCKER_COLOR
[Serveur Web 2] as Web2 #DOCKER_COLOR
}
package “Sous-réseau privé 2” {
[Serveur API 1] as API1 #DOCKER_COLOR
[Serveur API 2] as API2 #DOCKER_COLOR
}
package “Niveau de données” {
database “RDS Primaire” as RDS1 #AWS_COLOR
database “RDS Réplique” as RDS2 #AWS_COLOR
[ElastiCache Redis] as Cache #AWS_COLOR
}
package “Stockage” {
[Bac S3] as S3 #AWS_COLOR
[Stockage partagé EFS] as EFS #AWS_COLOR
}
}
Internet –> CDN
CDN –> ALB
ALB –> Web1
ALB –> Web2
Web1 –> API1
Web1 –> API2
Web2 –> API1
Web2 –> API2
API1 –> RDS1
API2 –> RDS1
RDS1 -[dashed]> RDS2
API1 –> Cache
API2 –> Cache
API1 –> S3
API2 –> S3
Web1 –> EFS
Web2 –> EFS
@enduml
Tutoriel 4 : Diagramme d’activité pour le flux de travail
Code exemple :

@startuml
|Client|
début
:Parcourir les produits ;
:Ajouter au panier ;
:Passer à la caisse ;
|Système|
:Valider les articles du panier ;
:Calculer le total ;
si (Articles disponibles ?) alors (oui)
:Réserver l'inventaire ;
sinon (non)
:Afficher « Épuisé » ;
stop
finsi
|Client|
:Entrer l'adresse de livraison ;
:Sélectionner le mode de paiement ;
|Système|
:Traiter le paiement ;
si (Paiement réussi ?) alors (oui)
:Créer la commande ;
:Envoyer un e-mail de confirmation ;
:Mettre à jour l'inventaire ;
sinon (non)
:Afficher une erreur de paiement ;
detach
finsi
:Expédier la commande ;
:Mettre à jour le statut de la commande ;
stop
partition "Tâches en arrière-plan" {
:Générer la facture ;
:Notifier l'entrepôt ;
}
@enduml
5. Fondamentaux de Graphviz : Visualisation de réseaux complexes {#graphviz-tutorial}
Graphviz (langage DOT) excelle dans la visualisation de relations complexes et de topologies de réseaux où les algorithmes de mise en page sont déterminants.
Tutoriel 1 : Diagramme de dépendance des microservices
Code d’exemple :

Figure 4 : Visualisation Graphviz montrant les dépendances et le flux de données des microservices
digraph MicroservicesDependencies {
rankdir=TB;
node [shape=box, style="rounded,filled", fontname="Arial"];
edge [fontname="Arial", fontsize=10];
// Définitions des nœuds avec couleurs
node [fillcolor="#e3f2fd"];
"API Gateway" [fillcolor="#ffcdd2"];
"Service Mesh" [fillcolor="#fff9c4"];
// Services principaux
"User Service";
"Auth Service";
"Order Service";
"Payment Service";
"Inventory Service";
"Notification Service";
"Analytics Service";
// Bases de données
node [shape=cylinder, fillcolor="#c8e6c9"];
"User DB";
"Order DB";
"Product DB";
"Analytics DB";
// Services externes
node [shape=box, fillcolor="#f3e5f5", style="dashed,filled"];
"Payment Gateway";
"Email Service";
"SMS Service";
// Relations
"API Gateway" -> "Service Mesh";
"Service Mesh" -> "User Service";
"Service Mesh" -> "Auth Service";
"Service Mesh" -> "Order Service";
"Service Mesh" -> "Payment Service";
"Service Mesh" -> "Inventory Service";
"User Service" -> "User DB";
"Auth Service" -> "User DB";
"Order Service" -> "Order DB";
"Order Service" -> "Inventory Service";
"Order Service" -> "Payment Service";
"Inventory Service" -> "Product DB";
"Payment Service" -> "Payment Gateway";
"Notification Service" -> "Email Service";
"Notification Service" -> "SMS Service";
"Analytics Service" -> "Analytics DB";
"Order Service" -> "Notification Service" [style=dashed];
"Payment Service" -> "Notification Service" [style=dashed];
// Sous-graphes pour le regroupement
{
rank=same;
"User Service";
"Auth Service";
}
{
rank=same;
"Order Service";
"Payment Service";
"Inventory Service";
}
} Tutoriel 2 : Hiérarchie organisationnelle
Code d’exemple :

digraph OrgChart {
rankdir=TB;
node [shape=box, style="rounded,filled", fontname="Helvetica"];
edge [fontname="Helvetica", arrowsize=0.7];
// Niveau exécutif
CEO [label="CEOnJohn Smith", fillcolor="#1976d2", fontcolor="white"];
// Niveau C-Level
subgraph cluster_exec {
label="Équipe exécutive";
style=dashed;
color="#90caf9";
CTO [label="CTOnSarah Johnson", fillcolor="#42a5f5"];
CFO [label="CFOnMichael Brown", fillcolor="#42a5f5"];
COO [label="COOnEmily Davis", fillcolor="#42a5f5"];
CPO [label="CPOnDavid Wilson", fillcolor="#42a5f5"];
}
// Ingénierie
subgraph cluster_eng {
label="Ingénierie";
style=filled;
color="#e3f2fd";
VP_Eng [label="VP Ingénierie", fillcolor="#64b5f6"];
subgraph cluster_eng_teams {
label="Équipes";
style=dotted;
Backend [label="Équipe Backendn(12 ingénieurs)", fillcolor="#bbdefb"];
Frontend [label="Équipe Frontendn(8 ingénieurs)", fillcolor="#bbdefb"];
DevOps [label="Équipe DevOpsn(5 ingénieurs)", fillcolor="#bbdefb"];
QA [label="Équipe QAn(6 ingénieurs)", fillcolor="#bbdefb"];
}
}
// Produit
subgraph cluster_product {
label="Produit";
style=filled;
color="#fff3e0";
VP_Product [label="VP Produit", fillcolor="#ffb74d"];
PM1 [label="Chef de produitnPlateforme", fillcolor="#ffcc80"];
PM2 [label="Chef de produitnMobile", fillcolor="#ffcc80"];
PM3 [label="Chef de produitnAnalytique", fillcolor="#ffcc80"];
}
// Relations
CEO -> CTO;
CEO -> CFO;
CEO -> COO;
CEO -> CPO;
CTO -> VP_Eng;
VP_Eng -> Backend;
VP_Eng -> Frontend;
VP_Eng -> DevOps;
VP_Eng -> QA;
CPO -> VP_Product;
VP_Product -> PM1;
VP_Product -> PM2;
VP_Product -> PM3;
// Lignes pointillées pour la collaboration
PM1 -> Backend [style=dotted, color="#757575"];
PM2 -> Frontend [style=dotted, color="#757575"];
PM3 -> Backend [style=dotted, color="#757575"];
} Tutoriel 3 : Diagramme de flux de données
Code d’exemple :

digraph DataFlow {
rankdir=LR;
nodesep=1.0;
node [shape=ellipse, style="filled", fontname="Arial"];
edge [fontname="Arial", fontsize=9];
// Entités externes
node [fillcolor="#ffccbc", shape=box];
Customer [label="Client"];
Vendor [label="Fournisseur"];
Bank [label="Système bancaire"];
// Processus
node [fillcolor="#c5cae9", shape=circle];
P1 [label="Passer une commande"];
P2 [label="Traiter le paiement"];
P3 [label="Mettre à jour l'inventaire"];
P4 [label="Générer une facture"];
P5 [label="Expédier la commande"];
P6 [label="Envoyer une notification"];
// Dépôts de données
node [fillcolor="#c8e6c9", shape=box3d];
D1 [label="Base de données des commandes"];
D2 [label="Base de données de l'inventaire"];
D3 [label="Base de données des clients"];
D4 [label="Enregistrements de factures"];
// Flux de données
Customer -> P1 [label="Demande de commande"];
P1 -> D1 [label="Enregistrer la commande"];
P1 -> D3 [label="Mettre à jour le client"];
P1 -> P2 [label="Détails de paiement"];
P2 -> Bank [label="Demande de paiement"];
Bank -> P2 [label="Confirmation de paiement"];
P2 -> P3 [label="Paiement réussi"];
P3 -> D2 [label="Diminuer le stock"];
P3 -> P4 [label="Commande confirmée"];
P4 -> D4 [label="Enregistrer la facture"];
P4 -> P6 [label="Données de facture"];
P3 -> P5 [label="Demande d'expédition"];
P5 -> Vendor [label="Étiquette d'expédition"];
P5 -> P6 [label="Informations de suivi"];
P6 -> Customer [label="Confirmation de commanden+ Suivi"];
// Lignes pointillées pour les requêtes
D1 -> P5 [label="Obtenir les détails de la commande", style=dashed];
D2 -> P1 [label="Vérifier la disponibilité", style=dashed];
D3 -> P1 [label="Obtenir les informations du client", style=dashed];
} 6. Modèles d’implémentation en monde réel {#implementation-patterns}
Modèle 1 : Documentation du pipeline CI/CD
Code d’exemple (Mermaid) :

graph LR
sous-graphique Source["Contrôle de source"]
Git[Dépôt GitHub]
PR[Pull Request]
fin
sous-graphique CI["Intégration continue"]
Lint[Linting]
Test[Test unitaires]
Build[Artifacts de construction]
Scan[Analyse de sécurité]
fin
sous-graphique CD["Déploiement continu"]
Dev[Déploiement vers Dev]
Stage[Déploiement vers Staging]
E2E[Test E2E]
Prod[Déploiement vers Production]
fin
sous-graphique Monitor["Surveillance"]
Logs[Agrégation de logs]
Metrics[Tableau de bord des métriques]
Alerts[Système d'alerte]
fin
Git --> PR
PR --> Lint
Lint --> Test
Test --> Build
Build --> Scan
Scan --> Dev
Dev --> Stage
Stage --> E2E
E2E --> Prod
Prod --> Logs
Prod --> Metrics
Metrics --> Alerts
style Git fill:#f0f0f0,stroke:#333
style Prod fill:#d4edda,stroke:#28a745,color:black
style Alerts fill:#f8d7da,stroke:#dc3545,color:black
Modèle 2 : Conception du schéma de base de données
Code exemple (PlantUML) :

Figure 5 : Diagramme entité-relationship montrant le schéma de base de données e-commerce
@startuml
!define TABLE(name) entité name << (T,#FFAAAA) >>
!define PK(x) x <<PK>>
!define FK(x) x <<FK>>
TABLE(Users) {
PK(user_id) : INT
--
email : VARCHAR(255)
password_hash : VARCHAR(255)
created_at : TIMESTAMP
last_login : TIMESTAMP
status : ENUM
}
TABLE(Products) {
PK(product_id) : INT
--
sku : VARCHAR(50)
name : VARCHAR(255)
description : TEXT
price : DECIMAL(10,2)
stock_quantity : INT
category_id : INT
}
TABLE(Categories) {
PK(category_id) : INT
--
name : VARCHAR(100)
parent_id : INT
}
TABLE(Orders) {
PK(order_id) : INT
--
FK(user_id) : INT
order_date : TIMESTAMP
total_amount : DECIMAL(10,2)
status : ENUM
shipping_address : TEXT
}
TABLE(OrderItems) {
PK(item_id) : INT
--
FK(order_id) : INT
FK(product_id) : INT
quantity : INT
unit_price : DECIMAL(10,2)
}
TABLE(Payments) {
PK(payment_id) : INT
--
FK(order_id) : INT
payment_method : ENUM
transaction_id : VARCHAR(255)
amount : DECIMAL(10,2)
status : ENUM
processed_at : TIMESTAMP
}
Users ||--o{ Orders : places
Orders }o--|{ Users : belongs_to
Orders ||--|{ OrderItems : contains
OrderItems }o--|| Products : references
Products }o--|| Categories : categorized_in
Orders ||--o{ Payments : paid_by
note right of Users
Stocke les comptes clients
et les données d'authentification
fin note
note left of Orders
Enregistrement principal de transaction
avec les détails d'expédition
fin note
@enduml
Modèle 3 : Visualisation de l’Infrastructure as Code
Code exemple (Mermaid) :
graph TB
sous-graphique AWS["Infrastructure cloud AWS"]
direction TB
sous-graphique Networking["Réseau"]
VPC[VPC 10.0.0.0/16]
IGW[Pont Internet]
NAT[Pont NAT]
sous-graphique Public["Sous-réseaux publics"]
ALB[Chargeur de charge d'application]
Bastion[Hôte Bastion]
fin
sous-graphique Private["Sous-réseaux privés"]
sous-graphique AppTier["Niveau application"]
ECS1[Tâche ECS 1]
ECS2[Tâche ECS 2]
ECS3[Tâche ECS 3]
fin
sous-graphique DataTier["Niveau données"]
RDS[RDS PostgreSQL<br/>Multi-AZ]
Redis[ElastiCache Redis]
fin
fin
fin
sous-graphique Storage["Stockage"]
S3[Buckets S3<br/>Actifs et sauvegardes]
EFS[Stockage partagé EFS]
fin
sous-graphique Security["Sécurité"]
WAF[Règles WAF]
SG[Groupe de sécurité]
IAM[Rôles IAM]
fin
sous-graphique Monitoring["Surveillance et journalisation"]
CW[CloudWatch]
XRay[AWS X-Ray]
SNS[Notifications SNS]
fin
fin
User[Utilisateurs finaux] --> CloudFront[CloudFront CDN]
CloudFront --> WAF
WAF --> ALB
ALB --> ECS1
ALB --> ECS2
ALB --> ECS3
ECS1 --> RDS
ECS2 --> RDS
ECS3 --> RDS
ECS1 --> Redis
ECS2 --> Redis
ECS3 --> Redis
ECS1 --> S3
ECS2 --> S3
ECS3 --> S3
ECS1 --> EFS
ECS2 --> EFS
ECS3 --> EFS
ECS1 --> CW
ECS2 --> CW
ECS3 --> CW
RDS --> CW
Redis --> CW
CW --> SNS
style VPC fill:#f9f9f9,stroke:#333,stroke-width:2px
style ALB fill:#ff9900,stroke:#cc7a00,color:white
style RDS fill:#2e73b8,stroke:#1a4d80,color:white
style User fill:#95a5a6,stroke:#7f8c8d

Figure 6 : Diagramme d’architecture de l’infrastructure cloud AWS
7. Techniques avancées : Style et personnalisation {#techniques-avancees}
Style avancé Mermaid
Personnalisation du thème :

%%{init: {'theme':'base', 'themeVariables': {
'primaryColor': '#4CAF50',
'primaryTextColor': '#fff',
'primaryBorderColor': '#388E3C',
'lineColor': '#757575',
'secondaryColor': '#FFC107',
'tertiaryColor': '#fff'
}}}%%
graph TD
A[Début] --> B{Décision}
B -->|Oui| C[Processus A]
B -->|Non| D[Processus B]
C --> E[Fin]
D --> E
style A fill:#2196F3,stroke:#1976D2,color:white
style E fill:#F44336,stroke:#D32F2F,color:white
Paramètres de peau PlantUML
Style professionnel :

@startuml
' Style global
skinparam backgroundColor #FFFFFF
skinparam shadowing false
skinparam roundcorner 10
skinparam linetype ortho
' Style des composants
skinparam component {
BackgroundColor #E3F2FD
BorderColor #1976D2
ArrowColor #1976D2
}
' Style des paquets
skinparam package {
BackgroundColor #FFF3E0
BorderColor #F57C00
FontSize 14
}
' Style des notes
skinparam note {
BackgroundColor #F1F8E9
BorderColor #689F38
FontColor #33691E
}
package "Frontend" {
component [Application React]
component [Redux Store]
}
package "Backend" {
component [API Node.js]
component [Serveur Express]
database [MongoDB]
}
[Application React] --> [Redux Store]
[Redux Store] --> [API Node.js]
[API Node.js] --> [Serveur Express]
[Serveur Express] --> [MongoDB]
note right of [Redux Store]
Gestion centralisée de l'état
pour toute l'application
end note
@enduml
Attributs avancés Graphviz
Diagramme de réseau professionnel :

digraph AdvancedStyling {
// Attributs globaux du graphe
graph [
bgcolor="#f8f9fa"
fontname="Helvetica"
fontsize=16
label="Architecture du système d'entreprisenEnvironnement de production"
labelloc="t"
pad=0.5
ranksep=1.5
nodesep=1.0
];
// Attributs de nœud par défaut
node [
fontname="Helvetica"
fontsize=11
style="filled,rounded"
penwidth=2
];
// Attributs de bord par défaut
edge [
fontname="Helvetica"
fontsize=9
penwidth=1.5
arrowsize=0.8
];
// Grappes de nœuds avec style personnalisé
subgraph cluster_presentation {
label="Couche de présentation";
style=filled;
color="#e3f2fd";
fontcolor="#1565c0";
Web [label="Application Web<br/>React 18", fillcolor="#64b5f6", fontcolor="white"];
Mobile [label="Application mobile<br/>Flutter", fillcolor="#64b5f6", fontcolor="white"];
}
subgraph cluster_business {
label="Couche de logique métier";
style=filled;
color="#fff3e0";
fontcolor="#e65100";
API [label="API REST<br/>Node.js", fillcolor="#ffb74d", fontcolor="black"];
GraphQL [label="Passerelle GraphQL", fillcolor="#ffb74d", fontcolor="black"];
}
subgraph cluster_data {
label="Couche de données";
style=filled;
color="#e8f5e9";
fontcolor="#2e7d32";
Primary [label="Base de données principale<br/>PostgreSQL 14", shape=cylinder, fillcolor="#a5d6a7"];
Replica [label="Réplique en lecture<br/>PostgreSQL 14", shape=cylinder, fillcolor="#c8e6c9"];
Cache [label="Cache Redis<br/>Mode cluster", shape=cylinder, fillcolor="#c8e6c9"];
}
// Arêtes avec style personnalisé
Web -> API [label="HTTPS/REST", color="#1976d2", fontcolor="#1976d2"];
Mobile -> API [label="HTTPS/REST", color="#1976d2", fontcolor="#1976d2"];
Web -> GraphQL [label="WebSocket", color="#1976d2", fontcolor="#1976d2", style=dashed];
API -> Primary [label="Lecture/Écriture", color="#388e3c", fontcolor="#388e3c"];
API -> Cache [label="Cache", color="#f57c00", fontcolor="#f57c00", style=dashed];
GraphQL -> Replica [label="Lecture seule", color="#388e3c", fontcolor="#388e3c"];
Primary -> Replica [label="Réplication en flux", color="#757575", style=dotted];
}
8. Flux de travail de collaboration et de partage {#collaboration}
Création de diagrammes partageables
Partage étape par étape :
-
Générer un lien de partage :
-
Cliquez sur le bouton « Partager » dans VPasCode
-
Copiez l’URL générée
-
Partagez par e-mail, Slack ou documentation
-
-
Intégrer dans la documentation :
## Architecture du système  Ou intégrez la version interactive : <iframe src="https://www.vpascode.com/embed/abc123xyz" width="100%" height="600"></iframe> -
Exporter pour les présentations :
-
SVG pour les graphiques web évolutifs
-
PNG (300 DPI) pour PowerPoint/Keynote
-
PDF pour la documentation imprimée
-
Intégration au contrôle de version
Stocker le code du diagramme dans Git :
project-root/
├── docs/
│ ├── diagrams/
│ │ ├── architecture/
│ │ │ ├── system-overview.puml
│ │ │ ├── deployment-view.puml
│ │ │ └── data-flow.mmd
│ │ ├── processes/
│ │ │ └── user-journey.mmd
│ │ └── infrastructure/
│ │ └── aws-architecture.dot
│ └── README.md
└── src/
Exemple de flux de travail Git :
# Créer le diagramme
echo '@startuml
component "Passerelle API"
@enduml' > docs/diagrams/architecture/gateway.puml
# Valider les modifications
git add docs/diagrams/architecture/gateway.puml
git commit -m "Ajout du diagramme d'architecture de la passerelle API"
git push
# Les membres de l'équipe peuvent désormais visualiser dans VPasCode
# en collant le code ou en le chargeant depuis une URL
Modèles de collaboration d’équipe
Modèle 1 : Enregistrements de décisions d’architecture (ADRs)
# ADR-007 : Modèle de communication des microservices
## Contexte
Nous devons standardiser la manière dont les microservices communiquent.
## Décision
Utiliser la messagerie asynchrone via RabbitMQ pour la communication inter-services.
## Diagramme d'architecture
```mermaid
graph LR
A[Service A] -->|Publier| B[(RabbitMQ)]
B -->|S'abonner| C[Service B]
B -->|S'abonner| D[Service C]
Conséquences
-
Découplage amélioré
-
Meilleure évolutivité
-
Complexité accrue dans la gestion des messages
**Modèle 2 : Documentation de la planification de sprint**
Créez des diagrammes vivants qui évoluent avec votre sprint :

graph TD
subgraph Sprint24["Sprint 24 - En cours"]
Done[✅ Tâches terminées]
InProgress[🔄 En cours]
ToDo[📋 À faire]
Blocked[⛔ Bloqué]
end
Done --> Task1[Module d'authentification utilisateur]
Done --> Task2[Migration de la base de données]
InProgress --> Task3[Développement de l'API]
InProgress --> Task4[Intégration frontend]
ToDo --> Task5[Test unitaire]
ToDo --> Task6[Documentation]
Blocked --> Task7[Intégration tierce]
style Done fill:#d4edda,stroke:#28a745
style InProgress fill:#fff3cd,stroke:#ffc107
style ToDo fill:#e2e3e5,stroke:#6c757d
style Blocked fill:#f8d7da,stroke:#dc3545
Conclusion : Votre parcours vers l’excellence en documentation
Félicitations ! Vous avez maintenant terminé un parcours complet à travers VPasCode et la méthodologie Diagramme-as-Code. Réfléchissons à ce que vous avez appris et traçons votre chemin vers l’avenir.
Ce que vous avez maîtrisé
Au cours de ce tutoriel, vous avez découvert :
-
La puissance des diagrammes basés sur du texte: Vous avez vu comment l’écriture de code pour créer des diagrammes élimine la friction du positionnement manuel, assure la cohérence et rend la documentation maintenable.
-
Trois moteurs standards de l’industrie: Vous avez désormais des compétences pratiques dans :
-
Mermaid.js pour des diagrammes de flux conviviaux aux développeurs et une documentation moderne
-
PlantUML pour des diagrammes UML et d’architecture de niveau entreprise
-
Graphviz pour des topologies de réseaux complexes et des visualisations de relations
-
-
Modèles du monde réel: De l’architecture de microservices aux schémas de bases de données, des pipelines CI/CD aux organigrammes organisationnels, vous avez appris à visualiser pratiquement n’importe quel système ou processus.
-
Flux de travail collaboratifs: Vous comprenez comment partager des diagrammes via des URL, les intégrer dans la documentation, les intégrer au contrôle de version et automatiser leur génération dans les pipelines CI/CD.
-
Style professionnel: Vous pouvez créer des visuels de qualité éditoriale avec des thèmes personnalisés, une marque cohérente et des niveaux de détail appropriés pour différents publics.
La grande image
Ce qui rend VPasCode véritablement transformateur n’est pas seulement l’outil lui-même, mais le changement de paradigme qu’il représente. En traitant les diagrammes comme du code, vous :
-
Combler le fossé entre l’implémentation et la documentation
-
Démocratiser l’architecture en la rendant accessible à tous les membres de l’équipe
-
Préparer l’avenir des connaissances grâce à des artefacts basés sur du texte et contrôlés par version
-
Accélérer l’intégration grâce à une documentation claire et exécutable
-
Réduire la dette technique en rendant les mises à jour aussi simples que l’édition de texte
Vos prochaines étapes
Semaine 1 : Commencez petit
-
Choisissez un diagramme existant dans votre organisation
-
Recréez-le dans VPasCode en utilisant votre moteur préféré
-
Partagez-le avec un collègue et recueillez des retours
-
Stockez le code dans votre dépôt de projet
Semaines 2-3 : Créer de l’élan
-
Créer des modèles pour les types de diagrammes courants de votre équipe
-
Établir des conventions de dénomination et des directives de style
-
Intégrer les revues de diagrammes dans votre processus de revue de code
-
Documenter votre flux de travail « Diagramme en tant que code »
Mois 2 : Mettre à l’échelle et automatiser
-
Mettre en place une intégration CI/CD pour la génération automatique de diagrammes
-
Créer une bibliothèque de diagrammes pour votre organisation
-
Former les membres de l’équipe au flux de travail
-
Mesurer le temps gagné et les améliorations de la qualité de la documentation
Mois 3+ : En faire une culture
-
Promouvoir le diagramme en tant que code dans les décisions d’architecture
-
Partager les succès avec la direction
-
Contribuer des modèles à la communauté
-
Explorer des fonctionnalités avancées comme la génération de diagrammes assistée par IA
L’avantage concurrentiel
Les organisations qui maîtrisent le Diagramme en tant que code obtiennent des avantages significatifs :
✅ Prise de décision plus rapide: Des visuels clairs accélèrent la compréhension et l’alignement
✅ Temps d’intégration réduit: Les nouveaux ingénieurs comprennent les systèmes plus rapidement grâce à une documentation exécutable
✅ Meilleure communication avec les parties prenantes: Les diagrammes professionnels font le pont entre les perspectives techniques et commerciales
✅ Charge de maintenance réduite: Mettre à jour du texte est plus rapide que de redessiner des visuels
✅ Qualité de code améliorée: L’acte de diagrammer révèle les problèmes d’architecture tôt
Rejoignez le mouvement
Vous faites désormais partie d’une communauté en croissance de développeurs, d’architectes et d’équipes qui reconnaissent que la documentation n’a pas à être une charge. Avec VPasCode, vous avez les outils pour en faire un atout : une représentation vivante et dynamique de votre système qui évolue avec votre code.
Dernière pensée
Le meilleur moment pour commencer à traiter les diagrammes comme du code était hier. Le deuxième meilleur moment est maintenant.
Votre futur vous-même — et vos futurs collègues — vous remercieront pour la clarté, la cohérence et la confiance qui découlent d’une documentation toujours à jour, toujours accessible et toujours précise.
Prêt à commencer ? Visitez VPasCode dès maintenant, collez votre premier code de diagramme, et regardez le texte se transformer en clarté. En moins de temps qu’il n’en a fallu pour lire cette conclusion, vous aurez créé votre premier artefact Diagramme-en-Code.
L’avenir de la documentation technique est là. Il est piloté par le code, basé sur le navigateur et entièrement gratuit. Bienvenue dans la révolution.
À propos de ce tutoriel
Ce guide complet a été créé pour aider les équipes de développement à moderniser leurs pratiques de documentation grâce au Diagramme-en-Code. Construit sur les deux décennies d’expertise en architecture d’entreprise de Visual Paradigm, VPasCode représente l’avenir de la communication technique — accessible, maintenable et gratuit.
Dernière mise à jour : juin 2026
Public cible : développeurs de logiciels, architectes de systèmes, ingénieurs DevOps, rédacteurs techniques et équipes de développement
Prérequis : Compréhension de base des concepts d’architecture logicielle
Temps de complétion estimé : 2-3 heures pour le tutoriel complet, 15 minutes pour le démarrage rapide
Bon diagrammage ! 🎨📊






