Configuration¶

flower n'a pas de format de fichier de configuration, et aucune sous-commande de configuration qui aille vraiment jusqu'au bout — toute la configuration passe par des variables d'environnement, un fichier .env, plus une poignée d'objets de politique qui ne se donnent que depuis Python. Cette page rassemble en un seul endroit ce qui est éparpillé sur cinq : chaque variable, l'ordre de recherche des credentials, la syntaxe reconnue par .env, ce que setting_sources=[] isole exactement, ce qu'un run laisse sur le disque, ce que chacune des trois couches du session store jette, et comment ça attend quand le réseau tombe. Les termes suivent le glossaire.

Table complète des variables d'environnement¶

Cinq groupes : les credentials et endpoints que flower lit directement, la sélection de modèle, la recherche de chemins, les interrupteurs de comportement, et celles que flower écrit pour le sous-processus agent. Ce dernier groupe n'est pas à régler — si vous le réglez, il sera écrasé.

Credentials et endpoints¶

Si aucune des deux n'est réglée (ou si les deux sont des chaînes vides), check_credentials() renvoie ce message d'erreur de quatre lignes et Runtime.__init__ lève un RuntimeError (env.py:184-194 ; runtime.py:156-158).

Sélection de modèle¶

flower n'en lit que trois pour ses propres décisions ; les autres sont chargées puis transmises telles quelles au SDK.

Si flower setup reçoit un nom de modèle, ANTHROPIC_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL et ANTHROPIC_DEFAULT_SONNET_MODEL sont écrites toutes les trois ensemble (cli.py:1383-1385).

Chemins et recherche¶

Interrupteurs de comportement¶

Ce sont deux issues de secours : la norme est de ne pas les régler ; on les règle pour que flower en fasse une de moins. N'importe quelle valeur non vide les active, la valeur elle-même n'est pas interprétée (update.py:121 ; cli.py:1413).

Un flower lancé depuis les sources git n'est pas concerné par la mise à jour automatique, et FLOWER_NO_UPDATE y est un no-op — l'étape de commande de mise à jour reconnaît un .git dans le dépôt et renvoie directement None (update.py:83-87).

Ce que flower écrit pour le sous-processus agent¶

Ces trois-là sont produites par CompactPolicy.env() puis injectées dans ClaudeAgentOptions.env (agent.py:48-58、:241-245) ; elles contrôlent le compact intégré au harness. Les régler dans votre shell n'a aucun sens — ce qui compte est la copie que flower transmet au sous-processus.

Ce que lit le wrapper de conteneur¶

Ces deux-là ne sont pas lues par flower lui-même, mais par le wrapper shell docker/flowerbox. Usage complet dans Déploiement.

Les clés du .env ne se limitent pas à celles ci-dessus. Le parser charge toutes les lignes k=v dans os.environ, sans liste blanche (env.py:30、:102-107). L'ensemble KNOWN formé par les 9 clés de credentials ci-dessus ne sert qu'à deux endroits : la liste blanche lors de l'emprunt de la configuration ~/.claude (env.py:72), et l'étendue des champs affichés par describe() au démarrage avec -v (env.py:205).

Priorité de recherche des credentials¶

Sans chemin explicite, load_dotenv() lit tous les fichiers existants dans l'ordre suivant (env.py:45-53、:78-112) :

1. Variables d'environnement du processus — toujours prioritaires. Aucun .env ne recouvre une valeur déjà exportée. (env.py:91)
2. Le fichier désigné par $FLOWER_ENV — présent seulement si la variable est réglée. (env.py:48-49)
3. $PWD/.env — le répertoire de travail courant. Le projet dans lequel vous êtes, celui qui est lu. (env.py:50)
4. ${XDG_CONFIG_HOME:-~/.config}/flower/.env — l'emplacement global, un par utilisateur ; c'est celui qu'écrit flower setup. (env.py:51、:39-42)
5. Le .env à la racine du dépôt source — trois niveaux au-dessus de flower/core/env.py. N'existe qu'en exécution depuis les sources ; un flower installé par pip / pipx / uv vit dans site-packages et n'a pas cette entrée. (env.py:52)
6. Le bloc env de ~/.claude/settings.json, puis de ~/.claude/settings.local.json — dernier repli, 9 clés de credentials uniquement. (env.py:56-75、:109-111)

Quel fichier gagne : l'entrée 3 (.env du projet) bat l'entrée 4 (.env global), l'entrée 4 bat l'entrée 5 (.env racine du dépôt), les trois battent l'entrée 6 (configuration de Claude Code), et aucune ne bat l'entrée 1 (environnement du processus).

L'implémentation est « une clé déjà pourvue n'est pas écrasée » (env.py:90-93) : ceux qui passent en premier occupent les clés, les suivants ne comblent que les trous. La priorité est donc par clé, pas par fichier — si le .env du projet ne contient que ANTHROPIC_BASE_URL, le token peut parfaitement venir du fichier global. La première valeur rencontrée pour une clé donnée est définitive.

L'entrée 6 n'est activée qu'en recherche automatique. Un chemin explicite (load_dotenv("/path/to/.env")) ne lit que ce fichier, sans aucun repli (env.py:86-87、:109).

Entrée 6 : emprunter le token de Claude Code¶

On lit successivement ~/.claude/settings.json et ~/.claude/settings.local.json, on prend le dict data["env"], et on y sélectionne ces 9 clés (env.py:31-36、:65-74) :

ANTHROPIC_API_KEY   ANTHROPIC_AUTH_TOKEN   ANTHROPIC_BASE_URL
ANTHROPIC_MODEL     ANTHROPIC_DEFAULT_OPUS_MODEL    ANTHROPIC_DEFAULT_SONNET_MODEL
ANTHROPIC_DEFAULT_HAIKU_MODEL    CLAUDE_CODE_SUBAGENT_MODEL    CLAUDE_CODE_EFFORT_LEVEL

Si le fichier n'existe pas, n'est pas lisible, ou n'est pas du JSON valide (OSError / ValueError), on renvoie un dict vide et on continue — l'échec d'un repli ne doit pas emporter le run (env.py:62-63、:66-69).

La position prise dans le code : on n'emprunte que « où trouver le token » ; rien d'autre dans settings.json (règles de permission, hooks, réglages de modèle) n'est repris, ce qui ne trahit donc pas la promesse de portabilité de setting_sources=[] (env.py:17-19、:59-61). install.sh:77 en fait même un argument : qui a déjà configuré Claude Code localement ne verra jamais l'écran de configuration.

flower 不读 ~/.claude/settings.json —— 那是可移植性的代价。

Règles de parsing .env¶

Les règles sont assez courtes pour être mémorisées (env.py:95-107, 13 lignes) : strip ligne par ligne, on saute les lignes vides, celles qui commencent par #, et celles qui ne contiennent pas = ; le reste est coupé au premier = en clé et valeur, chaque côté est stripé, puis la valeur passe encore par .strip("'\"") — les guillemets simples ou doubles en tête et en queue sont retirés, sans exiger qu'ils soient appariés.

Reconnu :

Non reconnu. Aucune erreur n'est levée, vous obtenez simplement une valeur inattendue en silence :

Une valeur vide occupe quand même la clé. Si ANTHROPIC_AUTH_TOKEN= apparaît dans un fichier prioritaire, take() exécute os.environ["ANTHROPIC_AUTH_TOKEN"] = "" ; les fichiers suivants ne peuvent plus la combler puisque « la clé existe déjà » (env.py:90-93), tandis que check_credentials() teste la véracité et considère une chaîne vide comme non configurée (env.py:186). Résultat : ni credential, ni repli. Si vous ne voulez pas d'une clé, supprimez la ligne entière ; n'en laissez pas une vide.

Le prix de la portabilité¶

Tout le mécanisme tient dans cette ligne de build_options() (agent.py:207) :

"setting_sources": [] if portable else ["project"],

portable=True est la valeur par défaut de Runtime, et aucune option de ligne de commande ne permet de la désactiver — il faut passer par l'API Python avec Runtime(portable=False), ce qui donne ["project"], c'est-à-dire la lecture du .claude/ du projet.

Ce qui est isolé¶

Les capacités métier ne passent pas par là — elles sont distribuées avec le dépôt et chargées via plugins=[{"type": "local", "path": PLUGIN_DIR}] (agent.py:26、:210-212), voir Déploiement. Les instructions métier sont quant à elles appendées après le system prompt natif de Claude Code, non substituées (agent.py:198-202) : la spécialisation ne se paie donc pas par une perte de capacité générale.

Quoi emporter en changeant de machine¶

• Credentials : un fichier. Copiez ~/.config/flower/.env, ou reconfigurez-le sur la nouvelle machine. Sans lui, rien ne démarre — rien n'est hérité automatiquement.
• État de continuité : le répertoire entier. runs/ (base de sessions, manifeste, lignage) et .flower/ (workbench).
• Mais les chemins doivent correspondre. lineage.json stocke le chemin absolu de l'espace de travail ; s'il ne correspond pas, c'est comme s'il n'existait pas : repli silencieux vers une nouvelle session, sans erreur (lineage.py:65-66). La raison : le project_key du SDK dérive du chemin de l'espace de travail (/, _ et . deviennent tous -, runtime.py:40-41) ; si le répertoire change de place, l'ancien session_id devient introuvable.

Disposition sur disque¶

Un run de flower écrit deux arbres : <run_dir>/ pour la comptabilité et les sessions, <workspace>/.flower/ pour le workbench. Les deux sont par défaut sous le répertoire courant, mais leur référence n'est pas la même.

<run_dir>/ — par défaut ./runs/¶

runs/
  sessions.db        SQLite, transcript intégral (y compris celui propre à chaque subagent)
  manifest.json      manifeste de run : session_id / coût / retries / cause d'échec par étape, cumulé entre processus
  lineage.json       lignage : nom d'étape → session_id, c'est ce qui permet de reprendre dans le même répertoire
  aside/             Runtime distinct des questions-réponses de l'oracle, avec son propre sessions.db + manifest.json
  workbench/         seulement en chemin run / once et avec -W

Chaque ligne de manifest.json est un asdict(StepResult) plus deux correctifs (runtime.py:44-71、:579-582) :

La stratégie d'écriture est ajout sans écrasement : à chaque flush, le fichier est relu, les lignes dont run correspond au sien sont remplacées par les plus récentes, les lignes des autres restent intactes (runtime.py:564-586). Plusieurs flower en parallèle dans le même répertoire ne s'écrasent donc pas mutuellement leur comptabilité.

Le contenu de runs/ est de la donnée pure, consultable hors ligne à tout moment avec sqlite3 ou tools/analyze_run.py.

<workspace>/.flower/ — le workbench¶

.flower/
  INDEX.md      index généré automatiquement, injecté dans le system prompt de l'agent principal
  scripts/      scripts destinés à resservir. La première ligne `# desc: une phrase` apparaît dans l'index
  artifacts/    productions longues de plus de 2000 caractères : rapports, données, logs
  notes/        décisions consignées d'une étape à l'autre
  spill/        gros résultats d'outil spillés, nom de fichier = 16 premiers caractères du sha256 du contenu + `.txt`

Les trois sous-répertoires et l'index sont créés par Workbench (workbench.py:73-92). INDEX.md passe par le system_prompt.append au niveau de la session, dont les subagents n'héritent pas — la règle « les productions longues vont dans artifacts/ » doit donc être relayée par le coordinateur dans le brief de tâche, c'est le seul canal.

Le chemin go produit systématiquement ceci sous notes/ :

Avec --isolate, le workbench sort du dépôt : <répertoire parent du workspace>/.flower-<nom du workspace>/ (starter.py:47-55). Le worktree est la copie privée de chaque agent, le workbench est la couche partagée entre agents ; ce qui est partagé ne peut pas vivre dans un enclos privé. Dans ce cas, les chemins donnés au modèle sont absolus (workbench.py:69-71、:142-145).

spill/ a deux écrivains, avec des algorithmes de destination différents :

Dans la disposition par défaut, c'est le même répertoire. Mais dès que le workbench est déplacé (-W le fait atterrir dans runs/workbench/, ou --isolate le sort du dépôt), les deux divergent — la copie de TrimPolicy reste toujours dans l'espace de travail, parce que le Read de l'agent doit pouvoir l'atteindre.

Ce que spill_guard met à la place n'est pas une ligne, mais une ligne de pointeur plus les 400 premiers caractères (guard.py:132-140). Les appels qui lisent le fichier spillé lui-même sont laissés passer, sinon « lisez-le avec Read si vous voulez le texte intégral » serait une phrase creuse — on relit, ça dépasse encore le seuil, c'est spillé à nouveau, boucle infinie (guard.py:155-170).

Schéma de sessions.db¶

Trois tables, DDL dans stores/sqlite.py:27-51 :

CREATE TABLE entries (
    store_key TEXT NOT NULL,
    seq       INTEGER NOT NULL,
    uid       TEXT,
    payload   TEXT NOT NULL,
    PRIMARY KEY (store_key, seq)
);
CREATE UNIQUE INDEX entries_uid
    ON entries(store_key, uid) WHERE uid IS NOT NULL;
CREATE TABLE meta (
    store_key TEXT PRIMARY KEY,
    mtime     INTEGER NOT NULL,
    next_seq  INTEGER NOT NULL
);
CREATE TABLE summaries (
    project_key TEXT NOT NULL,
    session_id  TEXT NOT NULL,
    mtime       INTEGER NOT NULL,
    data        TEXT NOT NULL,
    PRIMARY KEY (project_key, session_id)
);

Construction de store_key (sqlite.py:54-58) : <project_key>/<session_id>, avec un subpath supplémentaire pour les subagents. project_key est dérivé par le SDK du chemin de l'espace de travail — /, _ et . deviennent tous -.

Un coup d'œil sur un échantillon réel (human-test/HT002/runs/sessions.db) :

sqlite3 runs/sessions.db "select store_key, next_seq from meta;"

-Users-hechenyu-explore-test-ide/601c8c91-6c4b-4525-8a5f-295b99bf9515|37
-Users-hechenyu-explore-test-ide/47395075-bec7-466e-80cd-f4d60b360235|80
-Users-hechenyu-explore-test-ide/47395075-…/subagents/agent-a99a6ce30a5471f44|104

Cet exemplaire contient 956 entries, 10 meta, 4 summaries — sur les 10 sessions, 4 sont des transcripts principaux et 6 sont des subagents, et summaries égale exactement le nombre de transcripts principaux.

Les trois couches du session store¶

append (écriture) est toujours un enregistrement intégral, sans un mot de modifié. Les trois couches n'affectent que load (la copie relue pour être donnée au modèle). L'ordre réel de load est :

SqliteSessionStore.load     lit tout depuis la table entries, par seq
  → TrimmingSessionStore.expire()   résultats Bash périssables → remplacés par « expiré »
  → TrimmingSessionStore.trim()     vieux gros tool_result → spill + remplacement par un pointeur
    → PruningSessionStore.prune()   messages d'erreur synthétiques / vieux appels refusés → entrée retirée et chaîne recousue

La couche 2 fait le trim, la couche 3 le prune — le trim jette selon le volume et la valeur, le prune jette selon « est-ce une erreur » ; ne les confondez pas. Signatures complètes dans l'API Python.

SqliteSessionStore — les fondations¶

SqliteSessionStore(path: str | Path)

Implémentation SQLite sans dépendance externe. Pour passer à Postgres / S3 / Redis, il suffit d'implémenter le même protocole ; le SDK fournit la suite de tests de conformité claude_agent_sdk.testing.session_store_conformance qui permet de vérifier directement (sqlite.py:1-8).

En plus des méthodes du protocole, trois requêtes synchrones à l'usage propre de flower :

TrimmingSessionStore + TrimPolicy / EphemeralPolicy¶

TrimmingSessionStore(path, workspace, policy: TrimPolicy | None = None,
                     ephemeral: EphemeralPolicy | None = None)

Deux règles orthogonales. TrimPolicy gère le volume :

Le corps trimmé est écrit dans <16 premiers caractères du sha256>.txt, et la position d'origine est remplacée par [工具结果已归档:N 字符。完整内容在 <路径>,需要时用 Read 读取] (trim.py:54-57、:308-317).

EphemeralPolicy gère la péremption : les résultats de git status, ls, ps sont très courts et ne seraient jamais candidats au trim par volume, mais leur justesse se dégrade avec le temps — le git status d'il y a 20 tours n'est pas « inutile », il induit en erreur.

Ne s'applique qu'aux résultats de l'outil Bash, et la commande doit correspondre à EPHEMERAL_CMD. Read n'en fait pas partie : le contenu d'un fichier ne se dénature pas avec le temps au point d'induire en erreur, et il peut être précisément la base du raisonnement du modèle (trim.py:153-160). Le contenu périmé n'est pas spillé — archiver un git status périmé n'a aucun sens, il suffit de le relancer.

La fonction de décision est is_ephemeral(cmd), qui est en même temps la liste des permissions rendues au coordinateur : delegate_guard(allow_glance=True) utilise la même fonction (trim.py:63-68、:128-150). Les deux ensembles doivent rester identiques — autoriser sans trimmer laisse un git status périmé occuper le contexte à jamais ; trimmer sans autoriser fait déléguer un subagent par le coordinateur pour un simple ls, 4,3k de coût de démarrage pour quelques dizaines de caractères. Ajouter une commande à la liste blanche, c'est dire ces deux choses à la fois.

Quand utiliser quoi :

• Vous voulez seulement que les résidus de coupure réseau n'entrent pas dans le contexte → rien à faire, Runtime utilise déjà PruningSessionStore par défaut. trim=False se contente de ne pas trimmer les gros résultats ; le retrait, lui, a bien lieu.
• Run de longue haleine, sorties d'outil volumineuses → trim=True. Le CLI du chemin go l'active déjà par défaut ; --no-trim le désactive.
• Le coordinateur a glance=True → ephemeral doit rester actif, raison au paragraphe précédent.

PruningSessionStore + PrunePolicy¶

PruningSessionStore(path, workspace, policy: TrimPolicy | None = None,
                    prune: PrunePolicy | None = None,
                    ephemeral: EphemeralPolicy | None = None)

keep_denials est le seul paramètre de construction de Runtime transmis jusqu'à cette couche (Runtime(keep_denials=N)). La raison du défaut 1 plutôt que 0 : le refus le plus récent est un signal utile, il empêche le modèle de retenter en boucle la même commande bloquée dans un même tour. Ne l'augmentez pas — un appel refusé n'a jamais été exécuté, son résultat ne contient aucune information, il occupe 273 caractères mesurés (93 caractères de message de refus plus 180 caractères de la commande morte), et il induit en erreur : mesuré, après avoir lu quelques « n'utilise pas Bash directement », le coordinateur cesse même d'essayer le git status pourtant autorisé et déclare « Bash est restreint, envoyons un agent voir » (prune.py:135-148).

heal_orphans soigne le cas où tout resume après une interruption renvoie 400 : l'interruption coupe à une frontière de message, le tool_use en vol à ce moment-là peut n'avoir aucun tool_result derrière lui, alors que l'API exige la paire. Cette mauvaise histoire reste dans le transcript et ne disparaît pas d'elle-même, si bien que chaque resume ultérieur est rejeté par elle. La réparation consiste à insérer une entrée user juste après l'assistant contenant les orphelins, à y compléter d'un coup les résultats de tous ces orphelins, puis à réorienter vers cette nouvelle entrée le parentUuid qui pointait sur cet assistant (prune.py:95-147). On complète, on ne supprime pas : supprimer les orphelins obligerait à recoudre la chaîne parent-enfant, et le même assistant peut contenir d'autres blocs normaux, du texte et du thinking, faciles à emporter au passage (prune.py:195-204).

Trois lignes rouges structurelles, dont la violation fait immédiatement échouer l'API :

1. Le bloc tool_result doit rester présent, seul son content peut être remplacé. Un de moins et c'est « Missing Tool Result Block » (trim.py:20-22 ; prune.py:79-92).
2. Les entrées isCompactSummary / isMeta sont intouchables — c'est la seule forme d'existence de l'historique qui a été compacté (trim.py:179-181).
3. Retirer une entrée oblige à rattacher ses enfants à son parent. Le transcript est une chaîne simple de parentUuid et le harness la remonte depuis la feuille ; là où la chaîne casse, tout l'historique antérieur est perdu (prune.py:95-122). C'est pourquoi relink() doit recevoir la liste complète incluant l'entrée à retirer, et fait elle-même le filtrage.

Le texte original dans SQLite n'est pas modifié d'un caractère — les trois couches n'affectent que « la copie redonnée au modèle » (trim.py:18 ; prune.py:8).

Résilience hors ligne¶

Un workflow long-horizon tourne des heures, le réseau tombera forcément une fois. Le comportement par défaut est mauvais : à l'instant de la coupure, le harness insère dans le transcript un message assistant synthétique (model="<synthetic>", isApiErrorMessage=true) dont le corps est API Error: Can't reach the API server … ; il devient la feuille de la session, si bien qu'au resume il est redonné comme « la dernière phrase du modèle » et le modèle croit discuter d'une panne réseau ; il se glisse aussi dans StepResult.text et se propage le long du workflow jusqu'au prompt de l'étape suivante (resilience.py:1-22).

La couche de résilience fait trois choses, aucune facultative : la sonde, la reprise plutôt que le redémarrage, et l'erreur tenue hors du contexte.

Paramètres de Resilience¶

Formule de backoff (resilience.py:119-121) :

min(base_delay * 2 ** (attempt - 1), max_delay) * (0.75 + random() * 0.5)

Soit une gigue de ±25%, pour éviter qu'une foule de processus ne se rue au même instant dès le rétablissement du réseau. Avec les valeurs par défaut : 1er backoff 4 secondes (3~5 en pratique), 2e 8 secondes (6~10), plafonné à 120 secondes (90~150) à partir du 5e.

Stratégie de sonde¶

• On sonde le host:port de ANTHROPIC_BASE_URL, pas api.anthropic.com (resilience.py:67-72). Avec une passerelle auto-hébergée, la joignabilité du second ne dit rien de celle du premier.
• Uniquement DNS plus poignée de main TCP : getaddrinfo, puis connect_tcp, puis fermeture immédiate. Pas de HTTP, pas de credentials, pas un centime (resilience.py:75-85). La sonde doit être gratuite, sinon « sonder toutes les 15 secondes pendant une coupure » devient elle-même la panne.
• Tout échec compte comme injoignable — on ne distingue pas un DNS mort d'un TCP refusé.
• wait_online() attend sur place : renvoie True dès que ça passe, False une fois max_offline_wait écoulé. À la première indisponibilité, une notification d'une ligne <host>:<port> 不可达,等待恢复(最多 60 分钟), et au rétablissement une autre ligne <host>:<port> 恢复,继续 ; rien entre les deux (resilience.py:126-140).

La sonde de credentials avant le démarrage est une autre affaire : elle envoie réellement un POST <BASE_URL>/v1/messages avec max_tokens=16, timeout de 20 secondes par défaut (env.py:126-181). Ne mettez pas max_tokens à 1 — mesuré, un modèle à chaîne de pensée forcée ne peut même pas y loger sa réflexion, et le serveur se débat jusqu'à 30 secondes avant de répondre ; à 16, il suffit de 3,6 secondes (env.py:120-123).

Classification des erreurs¶

classify(text) renvoie l'une de trois valeurs. On teste d'abord le fatal : un texte de 401 contient souvent aussi un mot comme « connection », et l'ordre inverse ferait attendre indéfiniment (resilience.py:53-64).

Distinguer le réessayable du non-réessayable est le cœur de cette couche : une secousse réseau mérite l'attente, un credential erroné mérite l'arrêt immédiat — attendre pendant une coupure est juste, attendre à cause d'une clé mal écrite ne fait que brûler du temps.

Ce qui est tenu hors du contexte¶

1. Les messages d'erreur synthétiques. PruningSessionStore les retire entièrement au load et recoud le parentUuid (prune.py:27-32、:191-195). Ils restent tels quels dans SQLite, ils ne sont simplement pas redonnés.
2. Dans le flux d'événements, c'est un kind="error" et non un "text", donc il n'entre pas dans StepResult.text et ne se propage pas le long du workflow jusqu'au prompt de l'étape suivante (resilience.py:17-18).
3. resume_prompt ne contient délibérément aucun détail d'erreur. Le modèle doit savoir « tu as été interrompu, continue » ; il n'a pas besoin de savoir si c'était ENOTFOUND ou 503. Cela relève du log, pas du contexte (resilience.py:112-113). Pour le log, voyez le champ errors de manifest.json.

Reprendre plutôt que recommencer : au moment de l'échec, le session_id est déjà obtenu, on reprend au point d'interruption par resume, et le coût déjà payé n'est pas perdu.

Voir aussi¶

• Ligne de commande — comment chaque option se projette sur la configuration de cette page.
• API Python — signatures complètes de Runtime, des trois stores et de Resilience.
• Déploiement — exécution en conteneur, distribution des capacités métier par plugin.
• Glossaire — le sens exact de chaque terme utilisé ici.