"QUENTUM ORCHESTRATOR"
Modèle conceptuel canonique
Référentiel des objets fondamentaux, de leurs relations, de leurs autorités et de leurs cycles de vie
Version : 0.1 — Document de travail
Statut : À valider
Opérateur : QuentumSpace
Document parent : Document de cadrage fonctionnel — QUENTUM ORCHESTRATOR
Note sur le nom de code « HARMONIA »
Le présent document utilise QUENTUM ORCHESTRATOR comme dénomination technique du système. Cette appellation désigne son architecture, ses mécanismes d’orchestration et l’ensemble des composants permettant de transformer une intention professionnelle en une trajectoire d’action gouvernée.
Dans le cadre des travaux de conception, le nom de code HARMONIA a été retenu (provisoirement) pour représenter l’identité fonctionnelle et symbolique du système. Dans la tradition grecque, Harmonia personnifie l’harmonie et la concorde, c’est-à-dire la capacité à mettre en accord des éléments différents pour former un ensemble cohérent.
Cette notion correspond directement à la vocation de QUENTUM ORCHESTRATOR : coordonner des humains, des agents d’intelligence artificielle, des outils, des données, des documents, des règles et des processus autour d’une même intention, tout en préservant l’autorité humaine, la gouvernance et la traçabilité des actions.
Le choix de HARMONIA traduit ainsi moins une référence esthétique à la mythologie qu’une idée fondamentale du produit : la valeur du système ne réside pas uniquement dans l’intelligence de ses composants, mais dans leur capacité à agir ensemble de manière coordonnée, gouvernée et cohérente.
À ce stade, HARMONIA demeure un nom de code. Il pourra, après vérification de sa disponibilité juridique, numérique et commerciale, être envisagé ultérieurement comme nom commercial de l’application, tandis que QUENTUM ORCHESTRATOR conserverait sa fonction de dénomination technique et architecturale.
QUENTUM ORCHESTRATOR est le système.
HARMONIA en exprime la finalité : mettre les intelligences et les capacités en accord au service d’une intention.
1. Objet du document
Le présent document définit le modèle conceptuel canonique de QUENTUM ORCHESTRATOR.
Il établit le vocabulaire, les objets fondamentaux, leurs responsabilités, leurs relations, leurs cycles de vie et les règles d'autorité qui devront servir de référence commune aux futures :
- spécifications fonctionnelles détaillées ;
- architectures techniques ;
- structures de données ;
- API ;
- interfaces utilisateurs ;
- moteurs de workflows ;
- systèmes multi-agents ;
- mécanismes de gouvernance ;
- mécanismes de mémoire et d'apprentissage ;
- politiques de conservation et de purge ;
- mécanismes d'audit et d'observabilité.
Ce document ne définit pas encore une implémentation technique particulière.
Il définit ce que le système est conceptuellement avant de définir comment il sera construit techniquement.
2. Principe architectural fondamental
QUENTUM ORCHESTRATOR est un système d'orchestration d'intentions professionnelles.
Son unité d'entrée fondamentale est le Vœu.
Son unité d'exécution spécialisée est l'Agent.
Son unité de réalisation est le Workflow.
Son unité élémentaire d'exécution est l'Étape.
Son unité d'autorité est la Capability.
Son unité d'arbitrage humain est la Décision.
Son unité factuelle d'expérience est l'Observation.
Son unité de justification cognitive est l'Evidence.
Son unité de connaissance révisable est la Théorie.
Son unité de traçabilité est l'Événement.
Son mécanisme de contrôle est la Politique.
Figure 1 — Vue conceptuelle globale de QUENTUM ORCHESTRATOR.
3. Chaîne canonique de réalisation
Le fonctionnement général de QUENTUM ORCHESTRATOR repose sur la chaîne suivante :
INTENTION
↓
VŒU
↓
INTERPRÉTATION
↓
CONSULTATION DE LA MÉMOIRE COGNITIVE
↓
PLAN
↓
VALIDATION ÉVENTUELLE
↓
WORKFLOW
↓
ÉTAPES
↓
AGENTS / HUMAINS / OUTILS
↓
DÉCISIONS ET ÉVÉNEMENTS
↓
RÉSULTAT
↓
OBSERVATIONS
↓
DISTILLATION COGNITIVE
↓
CONNAISSANCES RÉUTILISABLES
↓
PURGE DES DONNÉES OPÉRATIONNELLES
↓
CLÔTURE
Le système transforme ainsi une volonté humaine en une trajectoire d'action gouvernée.
Figure 2 — Chaîne canonique de transformation d’une intention en résultat gouverné.
4. Principe de séparation des responsabilités
QUENTUM ORCHESTRATOR ne doit pas confondre raisonnement, autorité, exécution et vérité métier.
4.1. Le LLM raisonne et propose
Le modèle d'intelligence artificielle peut :
- interpréter ;
- synthétiser ;
- comparer ;
- raisonner ;
- générer ;
- proposer ;
- expliquer ;
- identifier des hypothèses.
Il ne constitue pas, par lui-même, une autorité métier.
4.2. L'Orchestrateur coordonne
L'Orchestrateur :
- reçoit les intentions structurées ;
- construit ou fait construire les trajectoires ;
- identifie les ressources nécessaires ;
- sollicite les agents ;
- coordonne l'exécution ;
- déclenche les validations ;
- surveille l'avancement.
4.3. Le Policy Engine autorise
Le moteur de politiques détermine si une action :
- est autorisée ;
- est interdite ;
- nécessite une validation ;
- nécessite une autorité supérieure ;
- dépasse une limite budgétaire ;
- implique une donnée sensible ;
- peut utiliser un outil ;
- peut être déléguée.
4.4. Le Workflow Engine exécute
Le moteur de workflows maintient l'état réel des trajectoires d'exécution.
Il gère notamment :
- les états ;
- les dépendances ;
- les délais ;
- les reprises ;
- les attentes ;
- les erreurs ;
- les validations ;
- les transitions.
4.5. Les données métier établissent les faits
Le statut réel d'un objet métier ne doit jamais dépendre uniquement d'une affirmation produite par un LLM.
Figure 3 — Séparation des responsabilités entre intelligence, orchestration, autorité, exécution et vérité métier.
5. Objet canonique n°1 — Le Vœu
5.1. Définition
Un Vœu est l'expression formalisée d'un résultat souhaité par un acteur autorisé.
Le Vœu décrit prioritairement ce qui doit être obtenu, et non la manière détaillée de l'obtenir.
Exemple :
« Je veux préparer et envoyer un NDA à notre nouveau partenaire. »
5.2. Le Vœu n'est pas une tâche
Une tâche décrit généralement une action à réaliser.
Un Vœu décrit un état futur souhaité.
Un Vœu peut produire :
- aucun workflow si l'intention est impossible ou refusée ;
- un workflow simple ;
- plusieurs workflows ;
- plusieurs décisions ;
- plusieurs interventions humaines ;
- plusieurs agents ;
- plusieurs résultats intermédiaires.
5.3. Structure conceptuelle
Un Vœu possède notamment :
- identifiant ;
- auteur ;
- organisation ;
- formulation originale ;
- interprétation structurée ;
- résultat attendu ;
- contexte ;
- contraintes ;
- priorité ;
- échéance éventuelle ;
- niveau de sensibilité ;
- statut ;
- plan actif ;
- workflow actif ;
- résultats ;
- politique de conservation applicable.
5.4. Cycle de vie
BROUILLON
↓
SOUMIS
↓
EN INTERPRÉTATION
↓
À CLARIFIER, si nécessaire
↓
INTERPRÉTÉ
↓
PLANIFIÉ
↓
À VALIDER, si nécessaire
↓
AUTORISÉ
↓
EN EXÉCUTION
↓
EN ATTENTE, éventuellement
↓
RÉALISÉ
↓
EN DISTILLATION
↓
EN PURGE
↓
CLÔTURÉ
Des états complémentaires peuvent exister :
- suspendu ;
- refusé ;
- annulé ;
- réorienté ;
- réouvert ;
- en échec.
Figure 4 — Machine d’états et transitions du cycle de vie d’un Vœu.
5.5. Invariant
Un Vœu ne doit jamais être considéré comme réalisé uniquement parce qu'un agent ou un LLM affirme qu'il l'est.
La réalisation doit être déterminée à partir de critères d'achèvement persistés.
6. Objet canonique n°2 — Le Plan
6.1. Définition
Le Plan est une représentation proposée de la manière dont un Vœu pourrait être réalisé.
Le Plan appartient au domaine du raisonnement et de la proposition.
Il n'est pas encore l'exécution.
6.2. Contenu
Il peut comprendre :
- objectif interprété ;
- sous-objectifs ;
- étapes proposées ;
- dépendances ;
- agents nécessaires ;
- humains concernés ;
- documents nécessaires ;
- outils nécessaires ;
- estimations ;
- risques ;
- hypothèses ;
- théories mobilisées ;
- validations requises ;
- ressources estimées ;
- conditions de réussite.
6.3. Versionnement
Un Vœu peut posséder plusieurs versions de Plan.
Toute modification significative doit produire une nouvelle version traçable.
6.4. Principe
Le Plan propose. Le Workflow engage l'exécution.
7. Objet canonique n°3 — Le Workflow
7.1. Définition
Le Workflow est la représentation exécutable et persistante de la trajectoire retenue pour réaliser tout ou partie d'un Vœu.
Contrairement au Plan, le Workflow appartient au domaine de l'exécution.
7.2. Responsabilités
Il maintient :
- l'état ;
- les étapes ;
- les dépendances ;
- les responsables ;
- les délais ;
- les validations ;
- les résultats ;
- les erreurs ;
- les reprises ;
- les événements.
7.3. Invariant
Un workflow doit pouvoir survivre :
- à l'arrêt d'un LLM ;
- au redémarrage d'un serveur ;
- au remplacement d'un modèle ;
- à l'indisponibilité temporaire d'un agent ;
- à une attente humaine prolongée.
Le LLM ne constitue donc jamais la mémoire d'exécution du workflow.
8. Objet canonique n°4 — L'Étape
8.1. Définition
Une Étape est l'unité élémentaire gouvernée d'un Workflow.
Elle représente une action ou une attente dont l'état doit pouvoir être déterminé.
8.2. Une Étape possède notamment
- un objectif ;
- un type ;
- des entrées ;
- des sorties attendues ;
- un responsable ;
- des dépendances ;
- une politique d'autorisation ;
- un état ;
- une politique d'erreur ;
- une éventuelle échéance ;
- des critères d'achèvement.
8.3. Types possibles
Une étape peut être :
- exécutée par un agent ;
- exécutée par un humain ;
- exécutée par un outil ;
- une demande de décision ;
- une attente ;
- une vérification ;
- une transformation documentaire ;
- une communication ;
- une condition ;
- une opération système.
9. Objet canonique n°5 — L'Agent
9.1. Définition
Un Agent est une unité logicielle spécialisée pouvant raisonner et agir dans un périmètre défini afin de contribuer à la réalisation d'un objectif.
9.2. Modèle canonique
Un Agent possède :
Identity
Identité technique et fonctionnelle.
Purpose
Finalité de l'agent.
Capabilities métier
Compétences déclarées.
Tools
Outils qu'il peut potentiellement solliciter.
Knowledge Access
Connaissances auxquelles il peut accéder.
Memory Policy
Règles relatives à sa mémoire.
Authority Boundary
Limites de son autorité.
Delegation Policy
Conditions de délégation.
Budget Limits
Limites de consommation ou d'engagement.
Input Contract
Nature des données qu'il peut recevoir.
Output Contract
Nature des résultats attendus.
Security Context
Contexte de sécurité applicable.
Version
Version de sa configuration.
9.3. Principe d'autorité
La possession d'un outil ne signifie pas automatiquement que l'agent est autorisé à l'utiliser.
La capacité technique et l'autorisation effective sont deux notions distinctes.
10. Objet canonique n°6 — La Capability
10.1. Définition
Une Capability est une autorisation explicite, bornée et vérifiable permettant à un acteur d'effectuer une catégorie déterminée d'action dans un contexte déterminé.
Elle constitue l'unité fondamentale d'autorité opérationnelle.
10.2. Exemples
- lire le document D ;
- modifier le brouillon X ;
- utiliser l'outil de recherche ;
- préparer un e-mail ;
- envoyer un e-mail à un destinataire déterminé ;
- engager une dépense jusqu'à un plafond donné ;
- créer un sous-agent ;
- consulter une catégorie de données.
10.3. Principe de moindre privilège
Une Capability doit être limitée autant que possible par :
- objet ;
- périmètre ;
- durée ;
- montant ;
- outil ;
- organisation ;
- finalité ;
- niveau de sensibilité.
10.4. Capability temporaire
Lorsque cela est possible, l'Orchestrateur fournit à l'Agent une autorisation limitée à l'exécution de la mission en cours plutôt qu'une permission permanente.
11. Objet canonique n°7 — La Politique
11.1. Définition
Une Politique est une règle déterministe ou formalisée gouvernant ce qui peut ou doit se produire dans le système.
11.2. Domaines
Les politiques peuvent concerner :
- accès ;
- rôles ;
- attributs ;
- agents ;
- outils ;
- budgets ;
- délégation ;
- communications ;
- validations ;
- données ;
- LLM externes ;
- conservation ;
- purge ;
- sécurité.
11.3. Invariant
Les politiques critiques ne doivent pas dépendre uniquement de l'interprétation libre d'un LLM.
12. Objet canonique n°8 — La Demande de décision
12.1. Définition
Une Demande de décision représente une situation dans laquelle l'exécution ne peut ou ne doit pas continuer sans intervention d'une autorité humaine déterminée.
12.2. Structure
Elle comprend notamment :
- identifiant ;
- Vœu concerné ;
- Workflow ;
- Étape ;
- action proposée ;
- auteur de la demande ;
- justification ;
- contexte ;
- conséquences connues ;
- niveau de risque ;
- impact financier éventuel ;
- documents associés ;
- autorités habilitées ;
- échéance ;
- décision rendue ;
- auteur de la décision ;
- date.
12.3. Résultats possibles
- approuvée ;
- refusée ;
- modification demandée ;
- déléguée ;
- expirée ;
- annulée.
12.4. Principe
Le dirigeant ne doit pas nécessairement gérer une liste de tâches.
QUENTUM doit pouvoir lui présenter principalement une file de décisions contextualisées.
13. Objet canonique n°9 — L'Événement
13.1. Définition
Un Événement est l'enregistrement d'un fait significatif survenu dans le système.
Exemples :
- WISH_CREATED ;
- PLAN_PROPOSED ;
- PLAN_APPROVED ;
- AGENT_ASSIGNED ;
- STEP_STARTED ;
- TOOL_CALLED ;
- DECISION_REQUESTED ;
- DECISION_GRANTED ;
- DOCUMENT_ATTACHED ;
- THEORY_USED ;
- CONTRADICTION_DETECTED ;
- WORKFLOW_COMPLETED ;
- PURGE_COMPLETED.
13.2. Principe
L'Événement décrit ce qui s'est produit.
Il ne doit pas être confondu avec une théorie sur la raison pour laquelle cela s'est produit.
14. Objet canonique n°10 — L'Observation
14.1. Définition
Une Observation est un constat issu de l'exécution d'un Vœu ou d'une source autorisée et susceptible de contribuer à la connaissance du système.
Exemple :
« L'autorisation administrative a été obtenue en 28 jours. »
14.2. Principe épistémique
Une Observation n'est pas une Théorie.
Elle décrit un fait ou un constat contextualisé.
Elle ne doit pas être automatiquement généralisée.
15. Objet canonique n°11 — L'Evidence
15.1. Définition
Une Evidence est une représentation distillée, contextualisée et gouvernée d'un élément probant pouvant soutenir, nuancer ou contredire une hypothèse ou une théorie.
15.2. Rôle
L'Evidence constitue le pont entre :
l'expérience opérationnelle temporaire
et
la connaissance persistante.
15.3. Structure indicative
Une Evidence peut comprendre :
- identifiant ;
- nature ;
- énoncé factuel ;
- contexte ;
- provenance ;
- date ;
- qualité estimée ;
- niveau de fiabilité ;
- domaine d'applicabilité ;
- relation avec une ou plusieurs théories ;
- statut de dépersonnalisation ;
- politique de conservation.
15.4. Règle essentielle
Après purge du dossier opérationnel, une théorie persistante ne doit pas nécessiter la conservation du dossier confidentiel d'origine pour rester intelligible.
16. Objet canonique n°12 — L'Hypothèse
16.1. Définition
Une Hypothèse est une proposition explicative ou prédictive qui n'a pas encore atteint le niveau de validation nécessaire pour être considérée comme une Théorie active.
Exemple :
« L'absence de l'agrément X semble constituer une cause fréquente de retard. »
16.2. Cycle possible
Observation
↓
Evidence
↓
Hypothèse
↓
Confrontation
↓
Confirmation / Nuance / Contradiction
↓
Théorie proposée ou abandon
17. Objet canonique n°13 — La Théorie
17.1. Définition
Une Théorie est une connaissance générale structurée, révisable et contextualisée permettant d'améliorer l'interprétation, la planification ou l'anticipation de futurs Vœux.
17.2. Une Théorie n'est jamais une vérité absolue
Elle possède :
- un domaine ;
- un énoncé ;
- un contexte d'applicabilité ;
- un niveau de confiance ;
- des Evidence favorables ;
- des Evidence contradictoires ;
- des limites ;
- un statut ;
- une version ;
- un historique de révision.
17.3. Contexte d'applicabilité
Une Théorie peut être conditionnée notamment par :
- territoire ;
- organisation ;
- secteur ;
- activité ;
- procédure ;
- période ;
- catégorie d'acteur ;
- catégorie de document ;
- conditions particulières.
17.4. Cycle de vie
HYPOTHÈSE
↓
PROPOSÉE
↓
ÉVALUÉE
↓
ACTIVE
↓
éventuellement
CONTESTÉE
↓
CONTEXTUALISÉE / RÉVISÉE
↓
ACTIVE RÉVISÉE
ou
INVALIDÉE
ou
REMPLACÉE
17.5. Invariant
Une Théorie significative ne doit jamais être silencieusement modifiée.
18. Taxonomie canonique de la connaissance
La mémoire cognitive persistante ne doit pas traiter toutes les connaissances comme des Théories.
Elle doit distinguer au minimum :
Observations
Constats contextualisés issus de l'expérience.
Evidence
Éléments probants distillés et gouvernés.
Hypothèses
Propositions encore insuffisamment établies.
Théories empiriques
Régularités générales révisables.
Règles métier
Contraintes ou règles établies par l'organisation ou une autorité externe.
Modèles de workflows
Trajectoires génériques réutilisables.
Modèles documentaires
Structures génériques de documents.
Heuristiques
Règles pratiques de raisonnement ou de planification.
Contraintes
Limites juridiques, opérationnelles, techniques ou organisationnelles.
Ces catégories ne doivent pas posséder automatiquement le même niveau d'autorité.
19. Distillation cognitive
19.1. Définition
La Distillation cognitive est le processus permettant d'extraire de l'expérience opérationnelle des connaissances générales susceptibles d'être conservées après la disparition du dossier source.
19.2. Processus canonique
DONNÉES OPÉRATIONNELLES
↓
IDENTIFICATION DES OBSERVATIONS PERTINENTES
↓
SÉLECTION
↓
DÉPERSONNALISATION
↓
ABSTRACTION
↓
CRÉATION D'EVIDENCE
↓
ÉVALUATION
↓
HYPOTHÈSE / MODÈLE / THÉORIE
↓
VALIDATION SELON POLITIQUE
↓
MÉMOIRE COGNITIVE
↓
PURGE OPÉRATIONNELLE
19.3. Condition
La connaissance conservée ne doit pas permettre, sauf politique explicitement contraire, de reconstituer le dossier confidentiel ayant permis son acquisition.
Légende :
Figure 5— Pipeline de distillation de l’expérience opérationnelle vers une connaissance réutilisable.
20. Architecture canonique des mémoires
QUENTUM ORCHESTRATOR distingue plusieurs espaces logiques.
20.1. Operational State
Contient l'état actuel nécessaire à l'exécution des Vœux.
20.2. Document Store
Contient les documents opérationnels.
20.3. Event Store
Contient les événements nécessaires à l'exécution et au diagnostic.
20.4. Cognitive Memory
Contient les connaissances générales réutilisables.
20.5. Agent Memory
Contient les informations nécessaires au fonctionnement d'un Agent selon sa politique de mémoire.
20.6. Audit Store
Contient les preuves nécessaires à la gouvernance, à l'autorisation et à l'audit.
20.7. Security Log
Contient les événements nécessaires à la sécurité.
20.8. CEO Private Memory
Contient les informations appartenant à l'espace personnel isolé du dirigeant.
Chaque espace possède une politique distincte :
- d'accès ;
- de chiffrement ;
- de conservation ;
- de sauvegarde ;
- de purge ;
- d'export.
Figure 6 — Architecture logique des espaces mémoire de QUENTUM ORCHESTRATOR
21. Cycle canonique de conservation des données
Toute donnée entrant dans QUENTUM doit pouvoir être associée à une catégorie et à une politique de conservation.
Cycle général :
CRÉATION
↓
CLASSIFICATION
↓
UTILISATION
↓
CONSERVATION OPÉRATIONNELLE
↓
ÉVALUATION À LA CLÔTURE
↓
soit
DISTILLATION
soit
CONSERVATION OBLIGATOIRE
soit
PURGE
↓
PREUVE DE TRAITEMENT
22. Objet canonique n°14 — Le Purge Record
22.1. Définition
Un Purge Record est une preuve technique et gouvernée attestant l'exécution d'une opération de purge.
Il ne contient pas nécessairement les données supprimées.
Il permet de déterminer notamment :
- quelle politique a été appliquée ;
- quel périmètre a été traité ;
- quand ;
- par quel mécanisme ;
- avec quel résultat ;
- quelles exceptions ont été appliquées ;
- quelles données ont été légalement ou techniquement conservées.
23. Architecture canonique de l'autorité
QUENTUM doit distinguer explicitement les verbes d'autorité.
Un acteur peut être autorisé à :
- voir ;
- lire ;
- proposer ;
- préparer ;
- modifier ;
- exécuter ;
- communiquer ;
- dépenser ;
- déléguer ;
- approuver ;
- administrer ;
- supprimer.
Ces pouvoirs sont indépendants.
Le droit de préparer n'implique pas le droit d'envoyer.
Le droit de consulter n'implique pas le droit de modifier.
Le droit de proposer n'implique pas le droit d'exécuter.
Le droit d'exécuter n'implique pas le droit d'approuver sa propre action.
Figure 7 — Modèle d’autorité et chemin d’autorisation d’une action.
24. Gouvernance de la délégation multi-agents
24.1. Principe
Un Agent ne possède pas un droit illimité de créer ou de mobiliser d'autres Agents.
La délégation doit être gouvernée.
24.2. Limites possibles
Toute délégation peut être limitée par :
- profondeur maximale ;
- nombre maximal d'Agents ;
- budget ;
- coût LLM ;
- durée ;
- outils ;
- domaines ;
- sensibilité des données ;
- organisation ;
- Capability.
24.3. Principe de souveraineté de l'Orchestrateur
Lorsqu'un Agent estime avoir besoin d'un sous-agent, il peut formuler une demande de délégation.
L'Orchestrateur et le Policy Engine déterminent si cette délégation est autorisée.
La topologie du système multi-agents reste ainsi gouvernée.
Figure 8 — Architecture d’orchestration et de délégation multi-agents gouvernée.
25. Architecture conceptuelle synthétique
UTILISATEUR
↓
INTERFACE D'INTENTION
↓
WISH ENGINE
↓
INTERPRETATION / PLANNER ↔ COGNITIVE MEMORY
↓
PLAN
↓
POLICY ENGINE
↓
WORKFLOW ENGINE
↓
┌───────────────┬───────────────┬───────────────┐
AGENTS — HUMAINS — OUTILS
↓
RESULTATS / EVENEMENTS
↓
OPERATIONAL STATE
↓
DISTILLATION COGNITIVE
↓
COGNITIVE MEMORY
↓
RETENTION & PURGE ENGINE
↓
PURGE RECORD
Le Policy Engine intervient transversalement dans l'ensemble des opérations sensibles.
26. Principaux invariants du système
Les règles suivantes constituent des invariants conceptuels de QUENTUM ORCHESTRATOR.
Invariant 1
Le LLM n'est pas la source de vérité métier.
Invariant 2
Une proposition n'est pas une autorisation.
Invariant 3
La possession d'un outil n'est pas une autorisation d'utilisation.
Invariant 4
Toute action sensible est gouvernée.
Invariant 5
Toute décision significative est traçable.
Invariant 6
Toute délégation est bornée.
Invariant 7
Le Workflow survit au modèle d'IA.
Invariant 8
La mémoire cognitive survit au remplacement du modèle d'IA.
Invariant 9
Une Observation n'est pas automatiquement une Théorie.
Invariant 10
Une Théorie possède un contexte d'applicabilité.
Invariant 11
Une Théorie significative possède une provenance cognitive.
Invariant 12
Une Théorie peut être contestée et révisée.
Invariant 13
La mémoire opérationnelle et la mémoire cognitive sont distinctes.
Invariant 14
La connaissance persistante ne doit pas nécessiter la conservation indéfinie du dossier opérationnel source.
Invariant 15
La purge est un processus gouverné et traçable.
Invariant 16
Le droit de proposer, d'exécuter et d'approuver sont conceptuellement distincts.
Invariant 17
Un Agent n'étend pas lui-même son autorité.
Invariant 18
L'espace privé du dirigeant est isolé de la mémoire partagée par défaut.
27. Graphe conceptuel principal
Les relations fondamentales peuvent être représentées ainsi :
USER
→ crée → WISH
WISH
→ possède → PLAN
PLAN
→ mobilise → THEORY
PLAN
→ devient → WORKFLOW
WORKFLOW
→ contient → STEP
STEP
→ est exécutée par → AGENT / HUMAN / TOOL
ACTOR
→ agit sous → CAPABILITY
CAPABILITY
→ est contrôlée par → POLICY
STEP
→ peut produire → DECISION REQUEST
WORKFLOW
→ produit → EVENT
WORKFLOW
→ produit → OBSERVATION
OBSERVATION
→ peut devenir → EVIDENCE
EVIDENCE
→ soutient ou contredit → THEORY
THEORY
→ influence → FUTURE PLAN
WISH
→ clôture → DISTILLATION
DISTILLATION
→ alimente → COGNITIVE MEMORY
RETENTION POLICY
→ commande → PURGE
PURGE
→ produit → PURGE RECORD
Figure 9 — Modèle conceptuel des objets canoniques et de leurs relations.
28. Noyau conceptuel minimal du MVP
Le MVP ne doit pas chercher à implémenter immédiatement toute l'architecture cible.
Le noyau conceptuel minimal doit démontrer :
- Wish Engine ;
- Planner ;
- Agent Registry ;
- Workflow Engine ;
- Policy Engine minimal ;
- Human Approval ;
- Document Store minimal ;
- Event/Audit Store ;
- Cognitive Memory minimale ;
- Retention & Purge Engine minimal.
Le workflow NDA peut constituer la première démonstration opérationnelle.
La mémoire cognitive minimale doit néanmoins permettre :
- l'enregistrement d'une Observation ;
- sa transformation gouvernée en Evidence ;
- l'association d'une Evidence à une Hypothèse ou Théorie ;
- la consultation d'une Théorie lors d'un nouveau Vœu ;
- l'enregistrement d'une contradiction ;
- une révision simple ;
- la purge du dossier opérationnel.
Figure 10 — Démonstration end-to-end du MVP : préparation, validation et envoi gouverné d’un NDA.
29. Conséquence sur la future architecture technique
La future architecture devra préserver une séparation nette entre :
Couche cognitive
LLM, raisonnement, interprétation, planification.
Couche d'orchestration
Vœux, plans, coordination.
Couche d'exécution
Workflows, étapes, reprises.
Couche d'autorité
Policies, Capabilities, décisions humaines.
Couche métier
États persistants et données de référence.
Couche cognitive persistante
Evidence, hypothèses, théories, modèles.
Couche documentaire
Documents et artefacts.
Couche de gouvernance
Audit, sécurité, observabilité, conservation et purge.
Aucun choix technologique futur ne devra remettre en cause ces séparations sans révision explicite du présent modèle.
30. Questions restant à formaliser
Avant le gel de la version 1.0 du modèle conceptuel, les points suivants devront être approfondis :
- cardinalités exactes entre Vœu, Plan et Workflow ;
- possibilité pour un Vœu de produire plusieurs résultats ;
- modèle exact de Capability ;
- héritage des permissions ;
- règles de séparation des pouvoirs ;
- structure canonique des politiques ;
- classification des niveaux de risque ;
- modèle de délégation ;
- définition exacte de l'Evidence ;
- calcul ou représentation de la confiance ;
- conditions de promotion d'une Hypothèse en Théorie ;
- règles de contradiction ;
- règles de révision ;
- gouvernance humaine des connaissances ;
- politique de dépersonnalisation ;
- politique de réidentification ;
- traitement des sauvegardes lors de la purge ;
- traitement des embeddings, caches et traces LLM ;
- frontière exacte de l'espace privé du dirigeant.
31. Doctrine synthétique
QUENTUM ORCHESTRATOR ne doit pas être conçu comme un chatbot capable d'appeler des outils.
Il doit être conçu comme un système gouverné de transformation des intentions en actions.
L'intelligence artificielle y fournit des capacités de compréhension et de raisonnement.
L'Orchestrateur transforme ces capacités en trajectoires.
Le Workflow Engine maintient l'exécution réelle.
Le Policy Engine contrôle l'autorité.
Les humains conservent les décisions qui leur appartiennent.
Les Agents fournissent des capacités spécialisées.
La mémoire cognitive capitalise l'expérience sans devenir une archive permanente des affaires.
La distillation sépare ce que le système a appris de ce qu'il doit oublier.
La purge garantit que la réalisation d'un Vœu n'implique pas nécessairement sa conservation indéfinie.
Ainsi, QUENTUM ORCHESTRATOR peut progressivement devenir une infrastructure capable de construire, pour chaque intention autorisée, une organisation opérationnelle temporaire et gouvernée, puis d'en conserver l'expérience utile après disparition des données qui n'ont plus vocation à subsister.
32. Formule canonique
L'humain exprime une volonté.
QUENTUM construit une trajectoire.
Les politiques définissent l'autorité.
Les Agents et les humains réalisent les actions.
Le Workflow conserve la réalité de l'exécution.
L'expérience produit de la connaissance.
La connaissance utile demeure.
Les données opérationnelles qui n'ont plus lieu d'être sont purgées.
Fin du document — Version 0.1
