AAA³ : trois plans, un même projet

§Définition

AAA3 signifie AI-Addressable Application — Three-Plane Architecture. Les trois A disent qu’une intelligence artificielle peut piloter l’application de bout en bout en écrivant un document ; le 3 dit comment elle est construite pour que ce soit possible : en trois plans qui opèrent sur le même projet.

AAA3

Le nom officiel et technique. C’est celui qu’on emploie dans les URL, les recherches, le code et la documentation.

AAA³

Graphie visuelle facultative, pour les titres et les diagrammes.

AI-Addressable Application

Le sens des trois A : une application qu’on peut piloter en écrivant son document, sans manipuler son interface.

Three-Plane Architecture

Le sens du 3 : un plan humain, un plan déclaratif et un plan d’exécution.

La définition est une proposition d’Iván Braida dans le cadre de SyncThinkDesign, développée sur le plan technologique chez Braidata. Le sens du 3 a été formalisé le 28 octobre 2026 ; jusque-là, le terme était employé en interne uniquement au sens d’AI-Addressable Application. Le formaliser ne modifie aucun contrat JSON ni aucun identifiant existant. AAA n’est pas employé comme nom à part entière.

§Les trois plans

1 · Plan humain

L’interface visuelle par laquelle une personne crée, consulte et modifie le projet.

2 · Plan déclaratif

Le document JSON canonique : structuré, versionné, validable et lisible aussi bien par des personnes que par des programmes et des modèles de langage. C’est la source de vérité de l’état déclaratif du projet.

3 · Plan d’exécution

Le moteur, le runtime et les API qui interprètent le document et produisent un comportement ou des résultats réels.

§Trois plans. Un même projet.

Une application AAA3 permet à ses trois plans d’opérer sur une représentation cohérente du même projet. Le document canonique est la source de vérité de l’état déclaratif ; l’interface permet de le manipuler et le moteur l’interprète pour l’exécuter. Les plans peuvent évoluer techniquement chacun de leur côté — une nouvelle interface, un moteur plus rapide, une nouvelle version du format — tant qu’ils respectent le même contrat.

Aucun des plans n’a besoin d’une IA. Une personne peut utiliser l’application sans aucune ; une IA externe, quelle qu’elle soit, peut la piloter en écrivant ou en modifiant le document, sans manipuler visuellement l’interface et sans que l’application dépende d’un modèle intégré. L’IA est un client possible du plan déclaratif, pas un composant de l’architecture.

Des chemins, pas une séquence

Les relations interface ↔ document ↔ moteur ne forment pas une chaîne obligatoire. Une application AAA3 admet, le cas échéant, les chemins suivants :

• Personne → interface → document.
• IA externe → document.
• Script → document.
• Document → moteur → exécution.
• Moteur → résultats et diagnostics.
• Résultats → revue humaine ou automatisée → évolution du document.

État déclaratif et état d’exécution

Les résultats d’une exécution ne font pas automatiquement partie du document. Le runtime peut conserver un état transitoire — une position de caméra, une partie en cours, un calcul intermédiaire — qui n’est pas persisté. Ce qui doit revenir au document y revient par des règles explicites, avec la même validation que n’importe quelle autre écriture. Sans cette séparation, exécuter un projet le modifierait en silence, et le document cesserait d’être une description lisible et comparable de ce qui a été décidé.

§Invariants

Ces six invariants disent ce qu’une application doit respecter pour être considérée comme AAA3, comment chacun se vérifie et où en est aujourd’hui notre écosystème. Nous distinguons ce qui est implémenté (avec des preuves vérifiables), ce qui est partiellement vérifiable et ce qui reste un objectif d’architecture.

§Ce qu’AAA3 ajoute à une application avec interface et backend

Presque toute application possède une interface, un format de données et un serveur ou un moteur. Les avoir tous les trois ne la rend pas AAA3. Ce qui distingue l’architecture, ce sont quatre garanties qu’une application classique n’offre généralement pas, et les problèmes que ces garanties résolvent. Ce sont des invariants proposés : la matrice de conformité indique lesquels chaque application respecte aujourd’hui.

Aucune de ces idées n’est nouvelle prise isolément. Les formats de document ouverts, l’infrastructure as code et le logiciel local-first traitent déjà une représentation déclarative comme source de vérité. Ce qu’AAA3 propose, c’est de les réunir dans un ensemble explicite d’invariants au service d’un objectif précis : qu’une application puisse être pilotée de bout en bout par une personne, un script ou n’importe quel modèle de langage, sans dépendre d’un modèle intégré. Qu’il s’agisse d’une contribution architecturale ou d’une synthèse utile d’idées connues, c’est à d’autres d’en juger.

§Matrice de conformité

Nous avons examiné le code et la documentation de chaque application de l’écosystème. Oui signifie qu’il existe une preuve vérifiable : un test automatisé ou du code partagé que nous avons contrôlé. Partiel désigne une règle écrite sans test, ou une preuve qui ne couvre qu’une partie. Non signifie que nous n’avons trouvé aucune preuve. Avoir une interface, un JSON et une API ne suffit pas pour cocher un plan ou un invariant.

§Liens avec SyncThinkDesign

AAA3 et SyncThinkDesign ont des identités indépendantes. STD étudie et propose l’évolution continue des systèmes par des processus synchronisés qui s’influencent mutuellement ; AAA3 applique certains de ces principes à l’architecture d’applications. La synchronisation entre les trois plans permet aux décisions de rédaction, à la représentation structurée et au comportement du système de se nourrir mutuellement, mais l’architecture n’implémente pas à elle seule tous les principes de STD.

Les trois plans ne correspondent pas non plus un à un aux quatre processus. Capter, Concevoir, Exécuter et Optimiser peuvent avoir lieu dans n’importe quel plan : une personne conçoit dans l’interface, un modèle conçoit en écrivant le document, le moteur exécute, une revue optimise. Forcer une équivalence masquerait précisément ce qui est intéressant : que les processus traversent les plans.

§L’écosystème actuel

Aujourd’hui, l’écosystème comprend un orchestrateur et plusieurs fournisseurs. L’orchestrateur est Experience Creator, publié sous le nom d’Alterverse : un éditeur d’expériences 3D interactives et de pièces audiovisuelles. Un projet Experience Creator peut déclarer les ressources dont il a besoin — un monde, une texture, une interface, une pièce musicale — sous forme de demandes adressées à d’autres fournisseurs, chacune écrite dans le format natif du fournisseur. Un résolveur, qui tourne dans l’éditeur ou en ligne de commande, les produit. Chaque application a ses propres trois plans ; le contrat braidata.aaa3.*.v1 relie leurs plans d’exécution.

§Le contrat entre applications

// demande (abrégée)
{
  "contract": "braidata.aaa3.request.v1",
  "requestId": "music",
  "operation": "audio.render",
  "spec": { /* document natif du fournisseur, non réinterprété */ },
  "inputs": [{ "name": "albedo", "sha256": "…", "mimeType": "image/png" }]
}

// résultat
{
  "contract": "braidata.aaa3.result.v1",
  "status": "succeeded",
  "diagnostics": [],
  "outputs": [{ "outputId": "<sha256>", "kind": "audio", "mimeType": "audio/wav", "url": "…" }]
}

§Comment il est construit

Une bonne partie du code d’AAA3 est écrite avec des agents de programmation IA, sous direction et revue humaines ; l’historique de chaque dépôt l’enregistre commit par commit. Nous le mentionnons parce que cela fait partie de l’expérience : si H5 est vraie, c’est dans des projets comme celui-ci qu’elle devrait se manifester en premier. Et parce que cela laisse une question à laquelle nous ne savons pas encore bien répondre : comment attribuer équitablement le travail quand une partie est produite par un agent.

§Ce qu’AAA3 ne résout pas

• Il ne capte pas de signaux du monde. Les observations sont toujours saisies à la main.
• La correspondance entre interface et document (invariant I) n’est testée automatiquement dans aucune application.
• Les stocks de sorties sont des mémoires bornées propres à chaque fournisseur ; une nouvelle instance peut avoir oublié un résultat et le client doit le redemander.
• Les dépôts sont privés. Ce site documente l’architecture et le contrat pour qu’ils puissent être discutés, mais le code ne peut pas encore être audité de l’extérieur.

§Références

• Kleppmann, M., Wiggins, A., van Hardenberg, P., & McGranaghan, M. (2019). Local-first software: You own your data, in spite of the cloud. Onward! 2019, ACM.
• Morris, K. (2016). Infrastructure as Code: Managing Servers in the Cloud. O'Reilly Media.

§Historique