Conception de diagrammes
Créez des diagrammes sous forme de fichiers HTML autonomes avec SVG intégré et un système de conception éditorial.
Quarante-cinq types visuels. Les motifs sémantiques décrivent le comportement ; les références de type décrivent la disposition.
0. Configuration initiale — Porte du guide de style
Avant de générer votre premier diagramme dans un nouveau projet, vérifiez que le guide de style a été personnalisé.
N'expédiez pas silencieusement des diagrammes aux styles par défaut dans un projet de marque.
Résolvez d'abord tout marqueur .diagram-design du projet conformément à references/profiles.md ; un marqueur résolu avec succès sélectionne son profil et contourne cette porte. Cette référence est responsable des échecs, de la valeur par défaut protégée et du comportement de sauvegarde.
Ouvrez references/style-guide.md et vérifiez les jetons par défaut. S'ils sont toujours les valeurs par défaut (fond #f5f5f5, encre #2d3142, accent #bf4520), faites une pause et demandez à l'utilisateur :
"Ceci est votre premier diagramme dans ce projet et le guide de style est encore celui par défaut. Le personnaliser maintenant ? Options : (a) URL du site web, (b) compétence installée, (c) dossier local / système de conception, (d) coller les jetons, (e) conserver les valeurs par défaut, (f) charger un profil sauvegardé."
Ensuite, bifurquez selon la section correspondante de references/onboarding.md ; pour (f) suivez references/profiles.md.
Une fois le guide de style personnalisé (ou l'utilisateur a explicitement choisi les valeurs par défaut), ignorez cette porte lors des exécutions suivantes. Un en-tête de profil principal nomme le profil actif copié. Sans en-tête, toute valeur de rôle sémantique ou famille typographique différente des valeurs par défaut signifie personnalisé-non-sauvegardé : ignorez la porte et proposez de le sauvegarder en tant que profil. Les jetons tous par défaut sans marqueur/en-tête déclenchent la porte. Après l'intégration, proposez de sauvegarder en tant que profil client nommé conformément à references/profiles.md.
1. Philosophie
La meilleure action est généralement la suppression.
Appliqué aux schémas :
- Chaque nœud représente une idée distincte. Deux nœuds qui voyagent toujours ensemble ne forment qu'un seul nœud.
- Chaque connexion porte une information. Si la relation est évidente à partir de la disposition, supprimez la ligne.
- Le corail est éditorial, pas un drapeau. 1 à 2 nœuds focaux par diagramme. L'utiliser sur 5 nœuds efface le signal.
- Le schéma n'est pas terminé quand tout est ajouté. Il est terminé quand rien ne peut être retiré.
Densité cible : 4/10. Suffisamment complet techniquement. Pas assez dense pour nécessiter un guide. Au-dessus de 9 nœuds, ce sont probablement deux diagrammes.
2. Quand l'utiliser
Utilisez-le pour l'un des 45 types visuels (§3) lorsqu'un lecteur apprendra plus d'un visuel que d'un texte, d'un tableau ou d'une liste à puces.
Ne pas utiliser pour :
- Diagrammes unicode rapides → un outil texte séparé comme wiretext. Cette compétence n'en fournit pas.
- Listes de choses → tableau ou puces.
- Avant/après basé uniquement sur des attributs → tableau ; changements de topologie → Delta d'architecture.
- « Diagrammes » à une seule forme → écrivez simplement la phrase.
Avant de dessiner, demandez : Le lecteur apprendrait-il plus de ceci que d'un paragraphe bien écrit ? Si non, ne dessinez pas.
3. Sélection : motif sémantique, puis type visuel
Lorsque le comportement, l'état, l'application ou le risque est porteur de sens, chargez d'abord references/semantic-patterns.md et choisissez un motif principal. Choisissez ensuite le type visuel le plus proche pour la disposition. Si aucun motif ne correspond, choisissez le type directement.
| Déclencheur comportemental | Motif sémantique → type le plus proche |
|---|---|
| Fan-in, profondeur de file d'attente, capacité finie, goulot d'étranglement | File d'attente fan-in / goulot d'étranglement → Flux de données |
| Emplacements de Question / Entrée / Gouvernance / Sortie répétés à travers les étapes | Cadre d'étape avec emplacements sémantiques → Processus |
| Une conversation ou une entrée libre devient un artefact structuré durable | Entrée non structurée → artefact structuré → Flux de données |
| Deux traces de règles nécessitent une évaluation réussite/échec/sautée/non-atteinte et une première divergence | Traces d'évaluation de politiques appariées → Organigramme |
| Limites de confiance plus chemins d'entrée/déploiement autorisés/interdits | Route pavée sécurisée → Architecture |
| Contrôles regroupés par leur lieu d'application | Catalogue de gouvernance / contrôle → Pile de couches |
| Les défenses compensent les lacunes antérieures et le risque résiduel se propage | Couches de sécurité compensatoires → Pile de couches |
| Décomposition hiérarchique adressable par ID nécessitant des E/S par bloc, des contraintes et un lien de code | Décomposition de bloc traçable → Arbre |
| Un sujet progresse à travers des phases, des attentes, des tentatives, des annulations et des résultats terminaux | Carte de cycle de vie → Machine d'état |
Le motif possède les primitives sémantiques et son budget plus serré ; le type possède la grammaire de disposition. Utilisez references/animation.md uniquement lorsque le mouvement est demandé ou clarifie matériellement un changement ordonné ; le statique reste la valeur par défaut.
Guide des types visuels (45)
| Si vous montrez… | Utilisez | Référence |
|---|---|---|
| Composants + connexions en un seul instantané ; périmètres d'administration et de trafic imbriqués | Architecture | type-architecture.md |
| Changement structurel entre topologies Avant / Après synchronisées, avec un registre des modifications | Delta d'architecture | type-architecture-delta.md |
| Paysage SI existant par phase ou département ; montre l'état avant | État actuel SI | type-it-state.md |
| Logique de décision avec branches | Organigramme | type-flowchart.md |
| Messages ordonnés dans le temps entre acteurs | Séquence | type-sequence.md |
| États + transitions + gardes | Machine d'état | type-state.md |
| Entités + champs + relations | ER / modèle de données | type-er.md |
| Événements positionnés dans le temps | Chronologie | type-timeline.md |
| Processus interfonctionnel avec transferts | Couloirs | type-swimlane.md |
| Positionnement / priorisation sur deux axes | Quadrant | type-quadrant.md |
| Plusieurs entités notées sur 3 à 5 critères quantitatifs | Radar / Araignée | type-radar.md |
| Une série quantitative à travers des catégories cycliques ; angle=catégorie, rayon=magnitude | Graphique polaire | type-polar.md |
| Cycle de renforcement ; la dernière étape alimente la première et un hub accumule l'état | Boucle | type-loop.md |
| Hiérarchie par contenance / périmètre | Imbriqué | type-nested.md |
| Relations parent → enfants | Arbre | type-tree.md |
| Propriété humaine/agent/équipe, rapports, routage, escalade | Organigramme | type-org-chart.md |
| Niveaux d'abstraction empilés | Pile de couches | type-layers.md |
| Parties d'un objet écartées le long d'un axe : démontage, déballage, ordre d'assemblage | Axonométrique éclatée | type-exploded.md |
| Un étage ou site vu du dessus en angle : pièces avec mobilier, bâtiments par phase | Plan axonométrique | type-axonometric-plan.md |
| Chevauchement entre ensembles | Venn | type-venn.md |
| Hiérarchie classée ou perte de conversion | Pyramide / entonnoir | type-pyramid.md |
| Comparaison quantitative entre catégories | Graphique à barres | type-bar.md |
| Un total de départ relié à un total d'arrivée par des contributions signées (budget bridge, deltas d'effectifs) | Graphique en cascade | type-waterfall.md |
| Partie d'un tout où les tailles relatives sont l'histoire | Treemap | type-treemap.md |
| Données croisées ; le remplissage code la valeur par cellule | Heatmap | type-heatmap.md |
| Tendances continues dans le temps, changement entre exactement deux états (slopegraph), une distribution par série (ridgeline), ou mouvement de rang à travers plusieurs instantanés (bump) | Graphique en courbes | type-line.md |
| Tâches et phases sur une chronologie | Gantt | type-gantt.md |
| Corrélation ou distribution de deux variables ; variantes bulle (trois variables) et beeswarm (une variable, un point par élément) | Nuage de points | type-scatter.md |
| Stack de données de bout en bout sur un cluster de conteneurs | Haut niveau | type-high-level.md |
| Processus séquentiel multi-acteurs avec transferts de données | Processus | type-process.md |
| Stockage de données multi-niveaux avec niveaux de qualité et politiques d'accès | Médaillon | type-medallion.md |
| Flux de données limité par rôle : qui fait quoi à chaque étape du pipeline | Flux de données | type-data-flow.md |
| Topologie d'intégration d'une plateforme de données — sources → cœur → consommateurs | Intégration DP | type-dp-integration.md |
| Matrice de permissions d'accès par rôle / par composant | Matrice de sécurité DP | type-dp-security-matrix.md |
| Une quantité se divisant et fusionnant à travers les étapes, largeur de bande = montant | Sankey | type-sankey.md |
| Causes d'un effet observé, regroupées par catégorie (analyse des causes profondes) | Arête de poisson (Ishikawa) | type-fishbone.md |
| Chaîne de valeur face à l'évolution — quoi construire, acheter, et ce qui bouge | Carte de Wardley | type-wardley.md |
| Travail en cours par état, avec limites WIP et éléments bloqués | Kanban | type-kanban.md |
| Ce qu'une personne fait à travers les étapes d'une expérience, et ce qu'elle ressent | Parcours utilisateur | type-journey.md |
| Ce que le client fait vs ce que le service cache, à travers les étapes, avec une ligne de visibilité | Blueprint de service | type-service-blueprint.md |
| Où le logiciel s'exécute — zones, hôtes, artefacts, réplicas, ports | Déploiement | type-deployment.md |
| Ce qui dépend de quoi, avec fan-in et cycles qu'un arbre ne peut exprimer | Graphe de dépendances | type-dependency.md |
| Classes avec opérations, héritage, composition (autres routes UML ailleurs) | Classe UML | type-uml-class.md |
| Colonne vertébrale narrative découpée en versions, avec la ligne de coupe | Story map | type-story-map.md |
| Tables physiques : types SQL, contraintes, index, FK au niveau colonne | Schéma de base de données | type-db-schema.md |
Règles empiriques :
- Si un tableau à 3 colonnes communique la même chose, choisissez le tableau.
- Si deux types semblent utiles, choisissez l'axe dominant ; un motif sémantique peut ajouter des primitives spécifiques au comportement, pas une seconde grammaire de disposition.
- Si vous dépassez le budget de complexité (§7), divisez en une vue d'ensemble + un détail.
Chargez toujours la référence de type choisie liée dans le guide avant de dessiner. Lorsqu'elle est acheminée ci-dessus, chargez également semantic-patterns.md ; lorsque l'animation est choisie, chargez animation.md.
Confirmer avant de dessiner
Avant le rendu, énoncez le plan en un court message : le type visuel choisi (et le motif sémantique, si acheminé), le préréglage de taille, et tout ce que le budget de complexité (§7) forcera à exclure. Si l'utilisateur est joignable, laissez-le rediriger avant de dessiner ; sinon, procédez et notez les hypothèses à côté du livrable. Ne faites la pause que lorsque la demande précise déjà exactement le type, la taille et le contenu.
4. Anti-patrons universels
Ceux-ci marquent les schémas « bâclés par IA » de tout type :
| Anti-patron | Pourquoi ça échoue |
|---|---|
| Mode sombre + lueur cyan/violet | A l'air « technique » sans décisions de conception |
| JetBrains Mono comme police « développeur » générique | Mono est pour le contenu technique — ports, commandes, URL. Les noms vont en Geist sans sérif. |
| Boîtes identiques pour chaque nœud | Efface la hiérarchie |
| Légende flottante dans la zone du diagramme | Entre en collision avec les nœuds |
| Étiquettes de flèche sans rectangle de masquage | Transparaît à travers la ligne |
Texte en writing-mode vertical sur les flèches | Illisible |
| 3 cartes récapitulatives de largeur égale par défaut | Grille générique — variez les largeurs |
| Ombre sur tout élément | Les ombres sont supprimées. Les bordures sont de retour. |
rounded-2xl sur les boîtes | Rayon max 6–10px ou aucun |
| Corail sur chaque nœud « important » | Le corail est 1 à 2 accents éditoriaux, pas un système de signalisation |
| Reproduire la disposition du rendu de Mermaid | Importe l'espacement automatique et le routage au lieu de faire une disposition éditoriale |
| Toute violation des six règles de connecteurs §6 | Échec automatique : obliques diagonaux, étiquettes touchant leur trait, masques coupés par un nœud ultérieur, chemins se chevauchant, points d'attache partagés, transit derrière une boîte non terminale |
Les anti-patrons spécifiques à un type vivent dans chaque référence de type liée dans le guide.
5. Système de conception
Le système de conception est personnalisable. references/style-guide.md est la source unique de vérité pour les couleurs, la typographie, les jetons et la palette par défaut ; ce fichier nomme les rôles sémantiques (paper, ink, muted, accent, link, …). Pour appliquer une marque, modifiez style-guide.md ou exécutez le flux basé sur URL dans references/onboarding.md.
Lorsque les spécifications ci-dessous ou dans les références de type mentionnent « ink », « accent », « muted », etc., recherchez la valeur hexadécimale actuelle dans
style-guide.md.
Les extraits de référence de type écrivent les rôles comme des espaces réservés : {ink}, {ink @ 0.40} pour un rôle à une opacité, et {node-name}, {sublabel}, {eyebrow}, {arrow-label}, {title}, {callout} pour les polices. Résolvez chaque espace réservé par rapport à style-guide.md avant d'émettre.
Rôles sémantiques (en un coup d'œil)
| Rôle | Objectif |
|---|---|
paper, paper-2 | Fond de page et fond de conteneur |
ink | Texte principal / trait |
muted, soft | Texte secondaire, flèches par défaut, sous-étiquettes |
ru |
…
[le contenu a été tronqué pour la traduction]