Runtime et évolution

Page générée — ne pas éditer

Rendue au build par scripts/gen_doc_reference.py, depuis web/data/catalogue-export.json. Une modification manuelle serait perdue au build suivant.

Ces patterns gouvernent les capacités et sorties produites par le runtime agentique afin d'éviter la prolifération invisible.

15 patterns dans cette famille.

RUN-01 — Dynamic factory contrôlée

Intention. Créer de nouvelles capacités sans prolifération incontrôlée.

Problème. Agents, skills et workflows dynamiques peuvent devenir une dette invisible.

Solution. Détecter le gap, classer l'artefact, décider éphémère/permanent, valider puis promouvoir ou purger.

Maturité. Gouverné

Contrôles. Usage tracking, expiration, score de durabilité, review, registre

À ne pas faire. Créer un agent permanent pour chaque demande ponctuelle.

Relations. À rapprocher de KNO-04

RUN-02 — Runtime output governance

Intention. Gouverner les artefacts produits par le runtime agentique.

Problème. Plans, traces, rapports, captures et sorties temporaires s'accumulent sans statut.

Solution. Déclarer type, propriétaire, sensibilité, rétention, indexation et statut.

Maturité. Minimal

Contrôles. Registre de surfaces runtime, cleanup, doc drift, audit périodique

À ne pas faire. Laisser les sorties runtime devenir une documentation parallèle non fiable.

RUN-03 — Kubernetes agent control plane

Intention. Exécuter agents et sandboxes en production comme ressources réconciliées, isolées et observables.

Problème. Un worker local ne suffit pas pour quotas, scheduling, multi-tenant, service accounts et tolérance de panne.

Solution. Fournir un provider K8s natif : pods gérés directement, requests/limits, node selectors, tolerations, affinity, service accounts, images prebaked et télémétrie OTel.

Maturité. Production

Contrôles. Admission policy, network allowlist, quotas, image provenance, service account minimal, SLO runtime

À ne pas faire. Lancer des agents en cluster via scripts ad hoc sans contrat de ressources ni observabilité.

Relations. Spécialise RUN-08

RUN-04 — Orders exec/formula dispatcher

Intention. Choisir le coût et le niveau d'orchestration appropriés pour un ordre.

Problème. Toutes les commandes ne nécessitent pas une session agent ; inversement certains workflows shell cachent une orchestration complexe.

Solution. Distinguer exec (shell-only, sans session agent) et formula (workflow agentique instancié), avec budget, preuve et blast-radius différents.

Maturité. Orchestré

Contrôles. Type d'ordre, budget token, policy tool, evidence attendu, classification risque

À ne pas faire. Lancer un agent complet pour une commande déterministe ou exécuter un workflow risqué comme simple shell.

Relations. S'appuie sur ORC-08 · Aligné avec GOV-02

RUN-05 — Primitive-first capability model

Intention. Éviter que les rôles et capacités deviennent des types SDK rigides.

Problème. Un framework role-centric pousse à forker le core dès qu'un rôle ou workflow change.

Solution. Définir rôles, prompts, formules et permissions dans des packs/configs ; le SDK ne fournit que les primitives d'exécution et de composition.

Maturité. Orchestré

Contrôles. Registry de packs, résolution de conflits, tests de compétence, versioning et promotion

À ne pas faire. Encoder Mayor/Reviewer/Builder comme classes SDK non composables.

Relations. Socle de RUN-06 · Renforce ORG-01

RUN-06 — Capability marketplace

Intention. Rendre les capacités agentiques découvrables, gouvernées et réutilisables.

Problème. Agents, prompts, skills, outils et workflows se multiplient sans catalogue ni statut.

Solution. Publier des capability packs avec owner, version, runtime compatible, permissions, tests et lifecycle.

Maturité. Orchestré

Contrôles. Capability pack manifest, skill record, tests de compétence, usage telemetry, retirement

À ne pas faire. Copier-coller des prompts et scripts d'équipe en équipe sans source d'autorité.

Relations. Alimente RUN-07

RUN-07 — Skill/capability lifecycle

Intention. Promouvoir ou retirer les skills selon preuve d'utilité et de sécurité.

Problème. Une skill expérimentale peut devenir critique sans review, ou une skill obsolète rester active.

Solution. Utiliser les statuts draft, experimental, canary, enforced, deprecated, retired avec gates et owner.

Maturité. Gouverné

Contrôles. Skill record, eval, telemetry usage, false positive review, changelog

À ne pas faire. Installer une skill comme permanente parce qu'elle a aidé une fois.

RUN-08 — Runtime provider contract

Intention. Séparer l'orchestration logique du backend d'exécution réel.

Problème. Le même workflow doit pouvoir tourner localement, dans un IDE, sur worker distant ou cluster sans changer ses garanties.

Solution. Normaliser lifecycle, ressources, logs, health, secrets, cleanup et policies via un runtime provider contract.

Maturité. Gouverné

Contrôles. Runtime provider contract, provider health, env scrub, quotas, workspace isolation

À ne pas faire. Écrire des workflows dépendants d'un shell local non déclaré.

Relations. Alimente RUN-09 · Mesuré par QUA-07

RUN-09 — Agent backend boundary

Intention. Isoler le backend agent des modèles, outils et environnements spécifiques.

Problème. Un agent couplé à un fournisseur ou runtime ne peut pas migrer entre Copilot, Codex, Claude, local ou cluster.

Solution. Définir des ports : model provider, tool provider, memory provider, runtime provider et telemetry provider.

Maturité. Orchestré

Contrôles. Provider registry, adapter contract, fallback explicite, eval de compatibilité

À ne pas faire. Appeler directement un SDK provider dans la logique métier du workflow.

Relations. Dépend de RUN-08 · Sert MOD-01

RUN-10 — Local agent worker pool

Intention. Exécuter plusieurs tâches locales sans bloquer l'orchestrateur.

Problème. Les missions longues, tests ou explorations concurrentes saturent une seule session et masquent les pannes.

Solution. Gérer un pool de workers locaux avec capacité, queue, timeout, health, logs et cleanup.

Maturité. Production

Contrôles. WIP limit, runtime provider contract, telemetry, workspace isolation, cancellation

À ne pas faire. Lancer des agents locaux en arrière-plan sans registre ni arrêt fiable.

Relations. S'appuie sur RUN-08 · Tracé par QUA-08

RUN-11 — Workspace isolation

Intention. Empêcher les agents de modifier ou lire hors du périmètre autorisé.

Problème. Un agent outillé peut toucher fichiers, secrets, caches ou repos voisins par accident.

Solution. Déclarer workspace root, mounts, write zones, secrets visibles, network policy et cleanup.

Maturité. Production

Contrôles. Path allowlist, sandbox, secret scan, runtime provider, blast-radius

À ne pas faire. Laisser l'agent opérer depuis un répertoire parent contenant plusieurs projets.

Relations. Alimente RUN-08 · Utilisée par RUN-10

RUN-12 — Secure local coordinator

Intention. Coordonner plusieurs agents locaux sans proxy de credentials ni canal opaque.

Problème. Un coordinateur local peut devenir un relais de tokens, un bus non audité ou un contournement des policies.

Solution. Utiliser inbox signée, terminal bridge officiel, sessions bornées, env scrub et gates avant action.

Maturité. Production

Contrôles. Agent privilege boundary, runtime provider contract, trajectory logging, policy engine

À ne pas faire. Faire transiter les tokens Copilot/Claude/Codex d'un outil vers un autre via un proxy maison.

Relations. S'appuie sur RUN-08 · Renforce GOV-07

RUN-13 — Idempotent tool action

Intention. Rendre les actions à effet externe rejouables sans doublon.

Problème. Un retry après timeout peut recréer, repayer ou renvoyer deux fois le même effet.

Solution. Utiliser clés d'idempotence, vérification d'état avant action et déduplication des effets.

Maturité. Contrôlé

Contrôles. Idempotency key, dry-run, trajectory logging, recovery policy

À ne pas faire. Rejouer une action externe sans clé ni vérification d'état.

Relations. Tracé par QUA-10

RUN-14 — Compensation / rollback action

Intention. Corriger ou compenser les effets partiels d'une séquence interrompue.

Problème. Un échec en milieu de séquence laisse le système dans un état incohérent.

Solution. Définir pour chaque effet une action de compensation ou de rollback, déclenchée par la recovery policy.

Maturité. Contrôlé

Contrôles. Recovery policy, idempotent tool action, evidence pack, incident record

À ne pas faire. Ignorer les effets déjà produits après un échec partiel.

RUN-15 — Acquisition d'outils et provisioning

Intention. Combler un manque de capacité par la bonne option d'outillage, choisie par l'utilisateur, sans réinventer la roue.

Problème. Face à un manque d'outil, l'agent réinvente un outil mûr (gaspillage), adopte un outil non gouverné ou payant sans accord, ou abandonne la tâche.

Solution. Produire un dossier d'options — adopter (gratuit, open-source, payant), commander un build aux agents de dev, ou faire soi-même si trivial — avec coût, risque et maintenance ; faire choisir l'utilisateur (GOV-15) ; gouverner l'adoption externe (GOV-09, GOV-05, GOV-07).

Maturité. Gouverné

Contrôles. Tool sourcing decision record, make-or-buy analysis, trust gate, budget et accord, lifecycle RUN-07

À ne pas faire. Réinventer un outil mûr existant, ou installer un outil tiers sans trust gate ni accord.

Relations. À ne pas confondre avec RUN-06