Interface des agents externes par CLI et skills

Aune héberge les corpus, les méthodes, les travaux et leur revue. Les agents s’exécutent dans les sessions de travail des contributeurs et utilisent une CLI pour lire et déposer leurs résultats. La plateforme distribue elle-même cette CLI et le skill qui en explique l’usage. Elle ne lance, ne planifie et n’héberge aucun agent IA dans cette première version.

Ce document précise l’architecture du cahier des charges. La grille analytique et le protocole de validation continuent de définir la méthode et les conditions de publication. Les interfaces Aune décrites ici définissent la cible ; leur disponibilité effective est précisée dans le document d’implémentation ci-dessous.

Une première tranche est désormais décrite dans Pilote CLI implémenté. Elle couvre les exercices fictifs personnels de structuration ; les autres éléments de ce document restent des exigences cibles et ne doivent pas être présumés disponibles.

Section § 01Décision et conséquences#

Un contributeur ouvre une tâche dans Aune, copie ses instructions dans une session d’agent externe, puis cette session récupère les éléments autorisés, travaille dans un dossier local et soumet une proposition structurée. Le navigateur sert à voir, vérifier et approuver. La session externe réalise l’analyse. La CLI transporte les données et applique les contrôles locaux. Le serveur contrôle les droits, les versions et les transitions éditoriales.

La plateforme reste nécessaire et sera hébergée. Elle peut exécuter des opérations déterministes comme valider un schéma, calculer une différence, rendre un PDF ou vérifier une empreinte. Elle n’a pas besoin de clés de fournisseurs de modèles, de conversations persistantes, de processus d’agents en arrière-plan ou d’une infrastructure de lancement des agents.

Fermer une session d’agent ne supprime aucun résultat déjà déposé. Une tâche peut être reprise depuis son dernier état enregistré. Les modifications qui n’existent encore que sur le poste local restent sous la responsabilité du contributeur jusqu’à leur synchronisation.

Section § 02Références examinées#

Le dépôt cité comme « served-tools » dans la demande est matrice-technologies/served-tool↗ (nouvel onglet), au singulier. Deux révisions ont été examinées le 24 septembre 2026 :

2.1Ce que fournit réellement served tool#

Le paquet expose trois parties : cli, server et build. Le cœur CLI fournit notamment login, whoami, version, upgrade, skill et help. Le projet ajoute ses commandes métier. La partie serveur fournit les primitives de connexion par code et de gestion des clés, derrière des interfaces de stockage à implémenter. La construction produit un script autonome contenant les fichiers du skill et deux compteurs de version. README à la révision examinée↗ (nouvel onglet)

Le contrat fixe les routes de distribution, de connexion et de clés, les statuts d’erreur et les codes de sortie. Il ne fournit pas le modèle des programmes, la revue éditoriale, les droits par dossier, un ordonnanceur d’agents ni une preuve de bonne exécution de la méthode. Contrat à la révision examinée↗ (nouvel onglet)

Le cœur actuellement examiné installe le skill sous ~/.claude/skills. Une installation pour d’autres clients exige un adaptateur ou un export explicite. Elle ne doit pas être annoncée comme une capacité existante du paquet. Implémentation du cycle de vie↗ (nouvel onglet)

2.2Ce que montre Truva Mapping Assistant#

Truva applique le modèle à un dossier de société immobilière : récupération locale, édition d’entités par chemins stables, validation, envoi de modifications versionnées et revue dans le navigateur. Le skill et ses références ont une source unique, embarquée dans la CLI et publiée par le déploiement. Les écritures portent l’identité de l’auteur et les versions du tool et du skill. Description du modèle↗ (nouvel onglet), interface CLI↗ (nouvel onglet)

La revue porte sur une version précise et une approbation cesse d’être valable lorsque la version courante change. La décision est réservée à une session humaine dans le navigateur. Le skill prévoit un seul rédacteur du dossier local, même lorsque plusieurs sous-agents contribuent à sa lecture. Revue↗ (nouvel onglet), skill de référence↗ (nouvel onglet)

Dans la révision examinée, la CLI Truva contient sa propre implémentation et son paquet racine ne déclare pas de dépendance à served-tool. Nous retenons donc Truva comme référence métier et served-tool comme socle réutilisable ; nous ne supposons pas une migration de Truva déjà effectuée vers ce paquet. CLI examinée↗ (nouvel onglet), paquet racine↗ (nouvel onglet)

2.3Adaptations nécessaires pour Aune#

Ces adaptations sont des choix Aune. La réutilisation du socle ne constitue pas une validation scientifique de l’analyse des programmes.

Section § 03Les cinq éléments du système#

flowchart LR
    H[Contributeur humain] --> W[Navigateur Aune]
    H --> A[Session externe avec le skill]
    A --> C[CLI aune]
    C <--> L[Dossier local de travail]
    C <--> API[API Aune]
    W <--> API
    API --> S[Corpus et travaux versionnés]
    API --> R[Contrôles et revue éditoriale]
    D[CLI et skill distribués par Aune] --> C
    D --> A

Le modèle et l’abonnement de la session externe sont choisis par son opérateur. Une compatibilité CLI ne vaut pas qualification méthodologique : chaque couple environnement, modèle et skill doit satisfaire les tests applicables avant que ses performances soient revendiquées.

Section § 04Unité de travail et objets conservés#

4.1Une tâche délimitée par rôle et périmètre#

L’unité récupérée par un agent est une tâche : une action attendue sur une édition de corpus, avec un rôle, un ensemble de critères et des droits définis. Un programme entier peut produire plusieurs tâches : transcription, structuration, style, cohérence, faits, contradiction et synthèse.

Une tâche de vérification peut couvrir un petit lot d’assertions. Une tâche de cohérence reçoit le contexte transversal nécessaire et ne doit pas être réduite à quelques passages isolés. Le serveur rend la profondeur d’accès explicite dans son manifeste.

Une tentative enregistre une exécution déclarée de cette tâche par une session. Une reprise peut continuer la même tentative si le contexte reste conforme, ou en ouvrir une autre. Une tâche n’est pas une conversation stockée par la plateforme.

4.2Contrat du manifeste#

Le manifeste contient au minimum :

• Identifiants de la tâche, de l’édition de corpus et de la révision du travail.
• Rôle, critères applicables et question précise à traiter.
• Versions de méthode, de schéma, de CLI et de skill autorisées, avec empreintes.
• Documents et passages autorisés, versions et empreintes, politique de masquage.
• Périmètre thématique, dates de référence et dépendances connues.
• Accès permis à la recherche externe et aux conclusions d’autres tâches.
• Objets attendus, règles d’abstention et conditions de fin.
• Droits d’écriture, budget ou limite déclarative et circuit de revue.

Le serveur enregistre ce contrat au début de la tentative. Il ne le reconstruit pas seulement à partir des déclarations envoyées à la fin par l’agent.

4.3Forme du dossier local#

Arborescence proposée, créée par aune pull dans un nouveau dossier ou un dossier déjà reconnu :

task.json                 Manifeste et consignes métier de la tâche
work.json                 Objets de travail modifiables pour ce rôle
inputs/                   Originaux autorisés et transcriptions figées
evidence/                 Pièces recueillies pendant cette tentative
method/                   Méthode et critères figés
skill/                    Skill et références associés à la tâche
outputs/                  Synthèses et pièces à soumettre
.aune/base.json            Origine, identifiants et base de comparaison
.aune/outbox/              Opérations en attente et clés d’idempotence
AGENTS.md                 Guide local pour les clients qui le lisent
CLAUDE.md                 Guide local pour le client de référence

Les guides sont produits par des adaptateurs et renvoient au même contrat. Ils ne doivent pas contenir de copies divergentes de la méthode. Les noms présentés aux rôles masqués ne révèlent pas les auteurs par leurs chemins ou métadonnées.

Les clés d’API ne sont jamais stockées dans ce dossier. Elles restent dans la configuration de l’outil. Les pièces volumineuses sont adressées par identifiant et empreinte ; elles ne sont pas réinsérées dans chaque message ou dans le JSON complet du programme.

Le CLI peut télécharger les pièces à la demande. Il distingue systématiquement « non téléchargé », « non consulté », « partiellement consulté » et « consulté selon la déclaration de l’agent ». Une présence sur disque ne prouve pas une lecture.

Section § 05Parcours depuis le site#

5.1Première connexion#

La page « Connecter un agent » présente l’adresse de l’instance, la CLI, le skill distribué et un court texte à transmettre à la session externe. Cette session installe l’outil, lance la connexion par code et montre le code à l’utilisateur. Celui-ci l’approuve dans Aune après avoir vu le nom de l’appareil, les droits demandés et leur durée.

La CLI reçoit la clé, la conserve localement avec des permissions restrictives et confirme l’identité avec whoami. Le secret n’est ni copié dans le chat ni affiché. La session doit pouvoir montrer le code sans rester bloquée derrière une commande dont elle ne reçoit la sortie qu’à la fin ; l’adaptateur de lancement gère ce fonctionnement.

Le contrat served-tool transmet une empreinte du secret d’appareil au démarrage, puis le secret lui-même lors de la récupération sur une connexion sécurisée. La clé d’API finale n’est remise qu’une fois et seule son empreinte est conservée par le serveur. Le projet ne promet donc pas que tous les secrets restent matériellement sur le poste ; il exige leur transport sécurisé et leur absence des sorties et journaux.

5.2Démarrer une analyse#

Un opérateur crée ou sélectionne une tâche dans Aune. Le bouton « Travailler avec un agent » fournit une instruction qui nomme exactement la tâche, l’instance et le rôle. Il ne lance aucun processus distant.

La session vérifie son identité et sa compatibilité, récupère la tâche, lit le skill et la méthode figés, puis travaille sur les objets autorisés. Elle peut déposer plusieurs versions de brouillon. Elle soumet ensuite une révision déterminée à la revue, avec les limites rencontrées.

5.3Reprendre un travail#

Une autre session peut récupérer la dernière révision serveur, les lectures et les éléments déjà déposés. Elle déclare cette reprise et son propre environnement. Si les versions exigées ont changé, Aune crée une tâche successeure ou demande une nouvelle tentative ; le changement n’est pas absorbé silencieusement dans l’historique.

Une panne réseau ne donne pas lieu à une nouvelle analyse par défaut. La session conserve son travail, vérifie si la dernière opération a été reçue et reprend la synchronisation avec le même identifiant d’opération.

Section § 06Contrat de la CLI Aune#

6.1Identité et distribution#

Nom proposé : aune. Skill commun proposé : aune-programmes, comprenant des références par rôle. Le prototype conserve le modèle d’un script Node autonome construit avec served-tool. La version examinée de ce socle requiert Node 20 ou supérieur ; la version minimale réellement supportée par Aune sera épinglée et testée lors de l’implémentation.

La CLI ne contient aucune logique de sélection d’un modèle et ne lance pas d’agent. Elle doit pouvoir être utilisée par une personne, une session capable d’exécuter des commandes ou un processus de test.

6.2Commandes proposées#

Les commandes métier de cette table constituent le contrat à construire. Les commandes de connexion et de cycle de vie proviennent du socle, avec les adaptations indiquées plus bas.

Les opérations de lecture ou de rédaction de pièces sont locales jusqu’au push, sauf commandes explicitement documentées comme des enregistrements serveur, notamment le début d’une tentative et la soumission en revue. Cette convention diffère de certains verbes Truva et doit être visible dans l’aide.

L’envoi de blobs lors d’un push est suivi d’une validation et d’un enregistrement atomique des objets qui les référencent. Des blobs provisoires sans révision validée restent invisibles aux lecteurs et sont nettoyés selon une règle documentée. Un succès d’envoi de fichier ne vaut pas succès du dépôt métier.

Il n’existe pas de commande approve, publish --execute ou d’option de contournement des droits pour les clés d’agents. Ces décisions restent dans l’interface humaine et sont aussi refusées par l’API en cas d’appel direct avec une clé.

6.3Exemple de session#

Exemple illustratif d’une tâche de cohérence. Les identifiants sont fictifs et ces commandes Aune ne sont pas encore disponibles.

aune whoami
aune tasks show task-coherence-001
aune pull task-coherence-001 ./travail-coherence-001
cd ./travail-coherence-001
aune doctor
aune run start --role coherence
aune docs ls
aune get assertions/assertion-017
aune get assertions/assertion-042
aune put findings/constat-001 @outputs/constat-001.json
aune diff
aune validate
aune push -m "Ajout du constat et de ses passages sources"
aune run finish @outputs/bilan.json
aune submit -m "Analyse de cohérence soumise avec les limites documentées"

Les fichiers de résultat sont produits après lecture des instructions figées. Le push conserve un brouillon ; submit demande une revue. Aucune de ces commandes ne publie une analyse.

6.4Entrées et sorties#

Les commandes acceptent les fichiers et l’entrée standard pour les textes longs. Les objets sont adressés par identifiants stables, par exemple assertions/<id>, findings/<id> et evidence/<id>. Les champs inconnus sont refusés avec leur chemin ; un champ non établi reste inconnu selon le schéma, sans valeur inventée.

Le mode --json constitue un contrat explicite pour les commandes Aune : sortie structurée sur stdout, messages de progression sur stderr, erreurs structurées documentées et codes de sortie stables. Le socle expose une option --json, mais toutes ses commandes de cycle de vie ne produisent pas déjà un JSON uniforme. Les adaptations devront être testées ; cette propriété ne peut pas être supposée acquise.

Les codes de sortie conservent le sens du socle : 0 succès, 1 usage ou ressource absente, 2 requête ou service indisponible, 3 refus d’accès, 4 conflit de version, 5 données invalides. validate doit sortir avec 5 si le serveur répond HTTP 200 avec ok: false, comme le fait l’interface métier Truva.

Une sortie tronquée indique qu’elle l’est, son périmètre et le moyen de poursuivre. Le secret de connexion est masqué dans toutes les sorties, y compris erreurs distantes et diagnostic. Une erreur HTML d’un proxy n’est pas affichée comme un résultat métier.

Section § 07Rôle et contenu des skills#

7.1Un skill commun et des références spécialisées#

La première version distribue un skill commun afin de rester compatible avec la structure actuelle de served-tool : SKILL.md et des fichiers reference/*.md. Les rôles sont décrits dans ces références ; une tâche désigne celles à lire.

cli/skill/
  SKILL.md
  reference/cli.md
  reference/model.md
  reference/sources.md
  reference/ingestion.md
  reference/style.md
  reference/coherence.md
  reference/facts.md
  reference/contradiction.md
  reference/synthesis.md

Le skill principal définit le vocabulaire, l’identité du dossier, les étapes communes, la lecture des versions, la procédure en cas de conflit et la séparation entre dépôt et publication. Les références spécialisées décrivent les entrées, les contrôles et les sorties de chaque rôle.

Les critères eux-mêmes restent une méthode versionnée distincte. Le skill indique comment les appliquer et où les lire ; il n’en maintient pas une seconde copie manuelle. Les exemples sont identifiés comme exemples et ne deviennent pas des résultats sur le programme en cours.

7.2Distribution identique et adaptation aux clients#

Le dépôt contient une source canonique du skill. La CLI embarquée, la version servie et les fichiers distribués doivent correspondre à cette source, avec un contrôle automatique des empreintes. Les fichiers de référence obsolètes sont retirés uniquement dans le répertoire que l’installateur gère.

Pour le premier client de référence, on peut réutiliser l’installation Claude du socle. Pour un autre client, Aune doit fournir un adaptateur ou un export du même contenu ; la portabilité sera validée sur le client réellement retenu. Une commande générique skill --export <dir> est une extension proposée, pas une option existante constatée dans served-tool.

La création des guides locaux respecte les fichiers de l’utilisateur : seul un guide identifié comme généré par Aune est actualisé automatiquement. Un fichier existant non géré est conservé et le conflit est expliqué.

7.3Les instructions ne constituent pas une permission#

Le skill peut demander une citation ou interdire la publication. Le serveur doit néanmoins contrôler les citations présentes, les objets accessibles, les transitions autorisées et l’identité réelle. Un client modifié qui ignore le skill reste soumis à ces contrôles.

Les programmes et preuves sont explicitement des documents à analyser. Une instruction présente dans une pièce ne peut devenir une instruction d’utilisation de la CLI. Les pièces sont séparées des fichiers d’instructions générés par Aune.

Section § 08Connexion et autorisations#

8.1Réutilisation de la connexion par code#

Routes du socle à exposer : /api/v1/login/start, /api/v1/login/claim, /api/v1/login/approve, /api/v1/whoami et gestion des clés personnelles. La route d’approbation de connexion accepte uniquement une session humaine. Une clé ne peut pas en créer une autre par cette route.

L’API applique les scopes génériques read et write du socle, puis les droits Aune sur le corpus, la tâche, les objets et l’étape. Demander write ne crée pas un droit de contribution sur tous les programmes. Les droits demandés sont bornés par ceux de la personne qui approuve et par la politique d’accès de la tâche.

Le serveur attribue auteur, date, identifiant de clé et révision. Ces données ne sont pas reprises comme vérité depuis le corps de requête. Quand un bearer est présent, son identité est évaluée sans augmentation silencieuse de droits par un cookie de session également présent. Résolution d’acteur de référence↗ (nouvel onglet)

8.2Droits selon les opérations#

Les restrictions s’appliquent à l’API, aux pièces, à la recherche, à l’historique et aux exports, pas seulement à ce que la CLI choisit d’afficher. Un identifiant trouvé ne suffit pas à ouvrir un dossier.

Pour une analyse indépendante, la clé utilisée est associée côté serveur aux tâches et vues permises, avec le rôle et les restrictions de visibilité correspondants. Cette association nécessite une habilitation humaine ; un paramètre role envoyé par la CLI ne l’accorde pas. Une clé générale autorisant aussi les résultats cachés ne peut pas servir à revendiquer cet isolement. Ces autorisations métier complètent le stockage des clés du socle ; elles n’y existent pas automatiquement. Une même personne peut conserver d’autres accès humains, ce qui limite la portée de la garantie d’indépendance.

8.3Limites d’un environnement externe#

Aune contrôle ce qu’il remet à une clé et ce qu’il accepte de cette clé. Il ne peut pas prouver que la personne n’a jamais vu un autre programme, qu’un modèle a oublié une conversation ou qu’une session n’a pas lu un document local externe.

Une analyse déclarée indépendante doit utiliser un contexte neuf et des entrées autorisées. Les interventions humaines, consultations extérieures et échanges entre rôles sont déclarés. Une première analyse déjà exposée aux conclusions qu’elle devait ignorer n’est pas étiquetée « indépendante » ; elle peut être conservée comme analyse informée.

Section § 09Versions et mises à jour#

9.1Séparer les versions#

Chaque tentative référence séparément l’édition du corpus, la méthode, le schéma métier, le protocole API, le compteur du tool, le compteur du skill et leurs empreintes. Un changement de skill ne peut pas se dissimuler derrière une version de CLI inchangée.

Les deux compteurs de served-tool sont conservés pour la distribution. Ils ne remplacent pas la version de méthode et ne prouvent pas la compatibilité de deux formats de données. Un manifeste de compatibilité Aune complète le contrat existant.

9.2Pas de mise à jour implicite pendant une analyse#

Le skill Truva demande une mise à jour au début de la session. Pour Aune, la première étape est la vérification de compatibilité. Une tâche commencée sous une version déterminée conserve les instructions correspondantes, y compris après une reprise.

Les versions distribuées sont archivées et récupérables par leur identifiant. Une version révoquée pour un défaut critique bloque les nouveaux dépôts et déclenche une reprise explicite selon une nouvelle version. Elle reste archivée pour expliquer les travaux historiques.

upgrade reste disponible pour préparer un poste ou un nouveau travail. Il ne modifie pas silencieusement method/ et skill/ d’une tâche en cours. La session doit lire le paquet figé de cette tâche, même si son installation globale contient une version plus récente.

9.3Distribution et intégrité#

Les quatre routes de distribution du socle sont conservées : installateur, script, skill et compteurs. Aune ajoute un manifeste de compatibilité et un accès aux versions archivées. L’instance est fixée par une origine configurée et des règles de proxy maîtrisées ; un en-tête arbitraire ne doit pas faire installer un outil pointant vers un autre site.

Les téléchargements utilisent HTTPS, un fichier temporaire et un remplacement atomique après vérification. Le build enregistre les empreintes et la révision source. Une empreinte servie par le même serveur détecte une incohérence de transfert ou de version ; elle ne suffit pas à démontrer l’authenticité face à une compromission du serveur. Une signature et sa racine de confiance pourront compléter le dispositif.

Le serveur vérifie le contrat annoncé au dépôt, mais une empreinte déclarée par un client externe ne prouve pas que ce binaire ou ce skill a réellement été exécuté. Cette limite figure dans le niveau de traçabilité.

Section § 10Synchronisation et travail à plusieurs rôles#

10.1Versions de travail#

Un push contient la base connue, les changements adressés, un message, l’identifiant de tentative et l’identifiant stable d’opération. Les pièces nécessaires sont référencées par leurs empreintes. Le serveur revalide les données et les droits, puis écrit une nouvelle révision attribuée.

Si une réponse se perd, rejouer la même opération avec le même contenu restitue le même reçu. Réutiliser l’identifiant avec un contenu différent est refusé. La durée de conservation des reçus couvre la période pendant laquelle la CLI peut reprendre cette campagne.

La première implémentation peut appliquer une concurrence optimiste à la tâche entière : si sa révision de base a changé, l’écriture est refusée avec HTTP 409. Le rapprochement sans conflit par chemins, présent dans Truva, est une amélioration possible après validation ; il n’est pas indispensable au premier démonstrateur.

10.2Conflits et dépendances#

Un conflit présente la révision courante et les objets concernés. La CLI conserve le travail local et propose de récupérer la nouvelle base. Elle ne remplace pas automatiquement le contenu distant et ne supprime pas les modifications locales non déposées. Une réconciliation produit une nouvelle version expliquée.

Une modification du corpus, d’une preuve ou d’une assertion dont dépend le travail peut invalider le résultat même si aucun chemin écrit n’entre en collision. La tâche conserve donc un manifeste de ses dépendances d’entrée. Une dépendance périmée bloque la soumission ou demande une réévaluation, selon la règle versionnée.

10.3Une session rédactrice par dossier local#

Chaque tentative dispose de son propre dossier. Plusieurs rôles peuvent travailler sur un même programme, chacun dans sa tâche. Ils ne modifient jamais simultanément le même fichier local work.json.

Si un opérateur choisit de déléguer des lectures à des sous-agents, ceux-ci produisent des résultats séparés et une seule session les intègre et les synchronise. La plateforme n’impose aucun outil de délégation et ne lance pas ces sous-agents.

Les observations indépendantes restent des objets distincts. Un agent de synthèse n’efface pas la conclusion d’un autre rôle pour obtenir un dossier uniforme. Il référence les constats approuvés, les objections et les décisions qui ont résolu ou conservé leurs divergences.

Section § 11Revue et publication#

La plateforme conserve un état de travail simple : disponible, en cours, bloqué, soumis, à reprendre et clos. Il décrit la tâche, sans prétendre connaître en direct l’activité du processus externe. « En cours » signifie qu’une tentative a été déclarée, pas qu’un agent tourne encore.

Les versions de travail, états de tâche et états éditoriaux sont séparés. Une soumission nomme exactement les constats, preuves, versions de documents et versions de méthode à examiner. Un dépôt accepté prouve sa conformité structurelle, pas sa justesse factuelle.

Les relecteurs travaillent dans Aune avec les pièces originales et les éléments fournis. Les validations exigées par le cahier des charges restent applicables. La publication référence un paquet immuable de versions. Toute modification substantielle produit un nouveau paquet à revoir ; aucune approbation d’un paquet précédent ne s’étend automatiquement au nouveau.

Une évolution du brouillon ne retire pas silencieusement une édition publique antérieure. Le site distingue l’édition publiée, les corrections en cours et, lorsqu’un problème grave est confirmé ou suffisamment crédible, l’avis ou le retrait décidé par le responsable éditorial.

Section § 12Traçabilité réellement possible#

Le manifeste de tentative distingue donc données observées par Aune, données déclarées et données inconnues. Une donnée inconnue vaut null avec un motif, jamais zéro. Les journaux ou extraits d’outils transmis sont expurgés des secrets et informations étrangères au dossier. Le produit ne demande pas un accès au raisonnement interne privé du modèle.

Aune peut limiter ses propres appels API, volumes de fichiers et coûts de services qu’il contrôle. Il ne peut pas arrêter la facturation d’un modèle utilisé directement par une session externe. Les budgets d’inférence sont des règles du protocole et des obligations déclaratives de l’opérateur ; les comparaisons à budget égal exigent un environnement d’essai instrumenté.

Section § 13Ce qui appartient au socle et ce qui appartient à Aune#

La dépendance served-tool sera épinglée à une version ou une révision vérifiée. La présence d’un manifeste de paquet public dans le dépôt ne suffit pas à confirmer la disponibilité d’une version sur un registre ; le mode d’installation sera vérifié pendant l’implémentation.

Section § 14Contrats API à construire#

Le serveur reste utilisable indépendamment de la CLI. Celle-ci est le client de référence, tandis que le navigateur utilise les mêmes règles métier. Les chemins ci-dessous sont des propositions Aune qui s’ajoutent au contrat de connexion et de distribution.

Chaque requête de mutation comporte un identifiant d’opération et un contrôle de version adapté. Les droits sont définis par opération, pas seulement par verbe HTTP : POST validate ne crée pas de donnée métier. L’API conserve l’enveloppe d’erreur compatible avec served-tool et distingue conflit, entrée invalide, refus d’accès, quota atteint et service indisponible.

Le contrat des pièces binaires doit préciser tailles, formats, empreintes, téléchargement autorisé et réception provisoire. Une URL de pièce n’autorise pas un accès permanent au-delà des droits du demandeur. Le téléchargement des originaux respecte également les droits documentaires du cahier des charges.

Section § 15Périmètre du premier démonstrateur#

Le premier démonstrateur doit prouver un aller-retour complet sur un dossier fictif ou un extrait historique autorisé : connexion, récupération, application d’un rôle, dépôt, correction, revue et publication humaine d’une édition de test. Il ne doit pas commencer par un système distribué de pilotage automatique des agents.

À construire d’abord : socle served-tool intégré, connexion, paquet de tâche figé, commandes locales essentielles, validation serveur, dépôt versionné, soumission, revue, contrôle d’accès et reprise après panne. Le premier rôle peut être la structuration des assertions, puis un rôle de cohérence sur un lot contrôlé.

À ajouter ensuite : autres rôles, pièces et preuves plus volumineuses, comparaison de tentatives indépendantes, export vers d’autres clients, gestion plus fine des collisions et qualification complète selon le protocole scientifique.

Hors première version : agents hébergés, lancement automatique de sessions, planification d’exécutions de modèles, gestion centralisée des abonnements aux modèles, conversations hébergées et publication autonome. Le registre de tâches conserve le suivi du travail sans fournir ces fonctions.

Section § 16Critères de réception spécifiques#

Ces cas complètent la recette méthodologique. Ils sont à implémenter et à exécuter ; aucun n’est présenté ici comme déjà réussi.

Section § 17Conséquences sur le cahier des charges#

L’orchestration décrite précédemment devient une procédure suivie par les sessions externes et un enchaînement de statuts contrôlé par Aune. Le serveur enregistre les prérequis et les soumissions, sans exécuter les rôles IA.

Les exigences de traçabilité distinguent les informations connues du serveur de celles déclarées par la session. Les budgets et temps d’inférence externes ne sont plus supposés contrôlables par la plateforme. Les expériences scientifiques continuent d’exiger une instrumentation adaptée.

Les exigences de preuve, d’abstention, de revue humaine, de versions et de correction restent inchangées dans leur finalité. Elles s’appliquent aux résultats reçus, quel que soit le lieu où l’agent a travaillé.

La première étape d’implémentation consiste à livrer le contrat du dossier de tâche et un aller-retour CLI complet. Le choix des modèles et le nombre de rôles pourront alors être évalués sans changer le mode d’intégration à la plateforme.