Organigramme

À propos des organigrammes

Un organigramme cartographie la structure hiérarchique formelle d'une organisation — qui gère qui, quelles équipes relèvent de quels responsables, et où les postes ouverts et les conseillers externes s'inscrivent. Les équipes RH y ont recours lors de la planification des effectifs ; les fondateurs les utilisent avant les réunions du conseil d'administration ; les directeurs des opérations les font circuler lors des restructurations. Contrairement à un organigramme de flux générique, un organigramme traite les personnes (et les postes) comme les entités principales, avec la hiérarchie encodée par l'indentation ou des arêtes explicites.

Schematex suit les conventions générales des organigrammes avec des extensions pour les postes ouverts/non pourvus, les liens hiérarchiques matriciels (en pointillés) et les relations d'assistant. Il n'existe pas de standard ISO unique pour les organigrammes ; les conventions implémentées ici sont issues de la pratique RH et des normes du secteur logiciel. Pour le contexte académique faisant autorité, voir Fayol (1916) et l'article Wikipedia sur les organigrammes.

1. Votre premier organigramme

L'organigramme utile le plus simple : une hiérarchie à trois niveaux avec un poste ouvert.

Quatre règles couvrent 80 % des usages :

1. Commencez avec le mot-clé orgchart, suivi optionnellement d'un titre entre guillemets.
2. Chaque personne est un nœud — id: "Nom" | "Titre" | "Département" [propriétés]. Le | sépare les champs nom, titre et département.
3. L'indentation détermine la hiérarchie — chaque deux espaces supplémentaires (ou plus) déplace un nœud d'un niveau plus profond sous le nœud le moins indenté situé au-dessus de lui.
4. Déclarez les postes ouverts avec open id: ou draft id:, et les conseillers externes avec advisor id:.

Les commentaires doivent commencer par # sur leur propre ligne (les // de fin de ligne en ligne sont également supprimés).

2. Nœuds

Une ligne de nœud a la forme [type] id: champs [propriétés]. L'id doit correspondre à [A-Za-z][A-Za-z0-9_-]*.

2.1 Champs (séparés par des barres verticales)

La partie après : et avant le bloc optionnel [propriétés] est divisée sur | :

alice: "Alice Zhang"                                # nom uniquement
alice: "Alice Zhang" | "VP Engineering"             # nom + titre
alice: "Alice Zhang" | "VP Eng" | "Platform"        # nom + titre + département
alice: "Alice Zhang" | "VP Eng" | "Platform" | "x@co.com"  # + ligne d'info

2.2 Types de nœuds

Le mot-clé de type optionnel avant l'id change la façon dont le nœud est rendu :

2.3 Propriétés des nœuds

Les propriétés vont dans [clé: valeur, …] à la fin d'une ligne de nœud.

Icônes de rôle — la valeur de role: se résout en une icône d'affichage. Mots-clés acceptés (insensible à la casse) :

3. Hiérarchie

La hiérarchie est exprimée par l'indentation — le modèle le plus courant. Chaque nœud devient un enfant du nœud le plus proche au-dessus de lui qui a une indentation moindre. Les tabulations sont traitées comme deux espaces.

ceo: "CEO"
  cto: "CTO"           # enfant du ceo (indentation 2)
    eng: "Engineer"    # enfant du cto (indentation 4)
  cfo: "CFO"           # enfant du ceo (indentation 2, même niveau que cto)

Alternativement, utilisez la propriété reports: pour définir un parent explicitement, quelle que soit l'indentation :

orgchart "Flat file"
ceo: "CEO"
cto: "CTO" [reports: ceo]
eng: "Engineer" [reports: cto]

4. Arêtes

Deux types d'arêtes existent. La plupart des lignes hiérarchiques proviennent automatiquement de la hiérarchie d'indentation. Vous pouvez également les écrire explicitement — ou ajouter des lignes matricielles (en pointillés).

Les arêtes explicites requièrent que les deux ids de nœuds soient déjà déclarés. Une arête report créée explicitement n'est pas dupliquée si la même relation est déjà impliquée par l'indentation.

Les étiquettes d'arêtes sont prises en charge :

pm1 -.-> design [label: "product partnership"]

5. Configuration

Les lignes config: ajustent la disposition et l'orientation. Chacune va sur sa propre ligne.

Notes sur la disposition :

• tree — arbre hiérarchique standard avec des connecteurs ramifiés. Idéal pour la plupart des organigrammes.
• list / directory / compact — vue en répertoire indenté compact. Idéal pour les grandes listes d'effectifs où la ramification de l'arbre devient difficile à gérer.

Disposition en arbre (défaut) — cartes avatar avec connecteurs ramifiés et codage couleur des départements. Idéal pour les équipes jusqu'à ~30 personnes.

Disposition en liste — lignes de répertoire compactes avec des guides d'indentation. Idéal pour les grandes équipes où la ramification de l'arbre devient difficile à gérer.

6. Étiquettes et commentaires

• Titre : orgchart "Acme Corp" — première ligne uniquement.
• Champ nom : premier champ délimité par des barres verticales après le deux-points ; peut être entre guillemets ("Alice Zhang") ou sans guillemets (Alice).
• Champs titre/département : deuxième et troisième champs délimités par des barres verticales.
• Ligne d'info : quatrième champ délimité par des barres verticales, ou défini via les propriétés note:, email:, phone: ou location:. Le premier rencontré l'emporte.
• Commentaires : # au début d'une ligne (après les espaces en tête). Les // en ligne sont également supprimés.

7. Mots réservés et échappement

Réservé en début de ligne : orgchart (en-tête), config:, role, open, draft, tbh, advisor, external.

Tokens opérateurs réservés — évitez ces séquences dans les ids : ->, .->

Règles d'ID : doit correspondre à [A-Za-z][A-Za-z0-9_-]*. Les noms avec des espaces vont dans le champ nom entre guillemets, pas dans l'id.

Les chaînes avec des espaces dans les valeurs de propriétés (ex. department: "Platform Eng") doivent être entre guillemets doubles.

8. Erreurs courantes

9. Grammaire (EBNF)

document       = header (blank | comment | config | edge | node)*

header         = "orgchart" ( WS quoted-string )? NEWLINE
quoted-string  = '"' any-char-but-quote* '"'

config         = "config" WS ":" WS key WS "=" WS value NEWLINE
key            = "direction" | "layout"

node           = INDENT* kind? id ":" WS fields ( "[" node-attrs "]" )? NEWLINE
kind           = "role" | "open" | "draft" | "tbh" | "advisor" | "external" | "person"
fields         = field ( "|" field )*
field          = quoted-string | unquoted-text
node-attrs     = node-attr ("," node-attr)*
node-attr      = "role:" role-keyword
               | "icon:" role-keyword
               | "department:" text
               | "status:" ( "new" | "leaving" | "on-leave" )
               | "avatar-color:" quoted-hex
               | "gender:" ( "male" | "female" )
               | "note:" text
               | "email:" text
               | "phone:" text
               | "location:" text
               | "assistant-of:" id
               | "matrix:" id-list
               | "reports:" id
               | bare-flag

bare-flag      = "open" | "draft" | "tbh" | "external"

edge           = id WS edge-op WS id ( "[" edge-attrs "]" )? NEWLINE
edge-op        = "->" | ".->"  // -.-> for matrix
edge-attrs     = "label:" quoted-string

id             = [A-Za-z] [A-Za-z0-9_-]*
comment        = ( "#" | "//" ) any NEWLINE

Source faisant autorité : src/diagrams/orgchart/parser.ts. Si cela diverge du parseur, le parseur a la priorité — veuillez ouvrir un ticket.

10. Feuille de route

Prévu — pas encore analysable. N'utilisez pas ces éléments dans le DSL généré aujourd'hui ; le parseur les rejettera ou les ignorera.

• Rendu visuel assistant-of: — la propriété est analysée et stockée dans l'AST mais le rendu ne trace pas encore le connecteur en coude pour l'assistant.
• Config coloring — thèmes de couleurs basés sur les départements (coloring: department).
• Niveaux de taille compact en config — contrôle explicite de la taille des cartes (size: small | medium | large).
• Largeur de nœud span: — étaler un nœud sur plusieurs colonnes de même niveau dans la disposition en arbre.
• Photo / URL d'avatar — avatar: "https://…" pour afficher une vraie photo de profil.
• Exportation vers les formats HRIS — sortie structurée JSON/CSV à côté du SVG.

Suivez dans les tickets GitHub si vous avez besoin de l'un de ces éléments plus tôt.

Exemples associés

Scénarios prêts à l'emploi depuis la galerie d'exemples :