# Conditions de l’expérience OpenCode et Qwen RTX des 21–22 septembre 2026

Notice historique publiée le 15 octobre 2026.

Cette notice explique les conditions du lot **Qwen RTX de septembre 2026** :
ce qui était fourni au cluster, ce que le modèle générait et ce que les
contrôles permettaient de conclure. Elle ne décrit pas les variantes
**Qwen Flash** présentes ultérieurement dans la galerie. Publier cette
documentation ne constitue pas une nouvelle construction des applications.

Le cluster a reçu davantage que des notebooks. Qwen local a généré et réparé
des fichiers applicatifs dans un environnement préparé, avec du code d’appui,
des données, des dépendances, des objectifs et des tests préexistants.
La supervision Codex restait en ligne : l’expérience était hybride.

## Schéma et résultats historiques

[Voir le schéma détaillé des flux](tokki-codex-opencode-experiment-flows-fr.svg).

![Environnement et résultats historiques de l’expérience Tokki, OpenCode, Qwen et AGILAB](tokki-agilab-environnement-resultats-fr-20261015-1080.png)

[Télécharger le poster en PDF](tokki-agilab-environnement-resultats-fr-20261015.pdf).

Les durées du poster décrivent les essais historiques. Les matériels, modèles
et périmètres diffèrent entre Astra, Qwen Mac et Qwen RTX ; ces durées ne
forment pas un benchmark contrôlé.

## Qui faisait quoi ?

| Composant | Fonction dans le lot étudié |
| --- | --- |
| Codex en ligne, depuis le poste de supervision Mac | Préparer et superviser les opérations, examiner les résultats et organiser la livraison. |
| Tokki | Encadrer les commandes et conserver des éléments de preuve ; sur le cluster, lancer OpenCode et les opérations locales. |
| OpenCode | Exécuter l’agent de développement : conversation, lecture, édition, appels d’outils et itérations. |
| Qwen local | Produire les réponses, décisions et nouveaux fichiers applicatifs de cet agent. |
| AGILAB et les contrôleurs fournis | Fournir l’intégration et les vérifications indépendantes du notebook, de l’interface et du workflow. |
| Hugging Face | Héberger les fichiers sélectionnés lors d’une étape de publication ultérieure. |

L’agent initial est le mode **build d’OpenCode**, avec
**Qwen3.8-27B Q4_K_M** : un modèle de 27 milliards de paramètres sous une forme
quantifiée, qui réduit la précision de stockage de ses poids. Certaines phases
de réparation utilisent ensuite le mode OpenCode `repair_patch`.

OpenCode appelle le modèle par une interface HTTP — Hypertext Transfer
Protocol — compatible avec le format d’API OpenAI, à
`127.0.0.1:11234/v1`. Cette adresse désigne la boucle locale du nœud :
la compatibilité du protocole ne signifie pas que le modèle tourne dans le
cloud OpenAI. Le reçu Iris consulté situe effectivement son exécution sur le
nœud Linux `rtx5`, avec cette identité de modèle local.

## Ce que le cluster recevait avant de générer

| Apport préexistant | Contenu et rôle |
| --- | --- |
| Chaîne de développement | Tokki, OpenCode, serveur Qwen et environnement AGILAB préparé. |
| Environnement d’exécution | Interpréteurs Python, composants AGILAB, bibliothèques de calcul et d’interface, outils de test et navigateur Chromium. |
| Entrées scientifiques | Notebooks de référence, fichiers de provenance et de licence, corpus texte local et modèle Chronos-2 Small mis en cache à une révision fixée pour Forecast. |
| Objectifs et consignes | Adaptation attendue, fichiers à produire, contraintes et retours des vérifications. |
| Code d’appui | `agilab_pool.py` fourni pour Threading et MILP, avec les licences applicables. |
| Qualification | Vérificateurs AGILAB préexistants, contrat d’entrée et contrôleur indépendant. |

L’orchestrateur extrait les cellules de code du notebook dans
`source/code_only.txt`. Cette représentation et les fichiers d’entrée
participent au contexte de Qwen. Les consignes interdisent d’exécuter le
notebook original, conservé comme référence ; la qualification exécute le
notebook nouvellement produit.

Selon l’application, les livrables demandés comprennent `app.py`, des modules
de calcul, `solution.ipynb`, les dépendances déclarées et un éventuel
`tests.py`. L’intégration AGILAB importe ensuite le notebook généré et produit
`notebook_import.json` et `lab_stages.toml`. Ces métadonnées sont créées par
l’orchestration ; leur présence ne prouve pas que Qwen les a écrites.

## Code fourni, code généré et mesures

Le fichier `agilab_pool.py` est du code fourni, pas une création nouvelle de
Qwen dans cet essai. Sa présence dans un projet ou un téléchargement ne prouve
pas qu’il est importé, exécuté ou utilisé par la mesure affichée.

Le compte rendu final précise ainsi que **MILP RTX mesure son lanceur de
processus généré**. Le moteur AGILAB fourni dans ce bundle reste une référence
de source. Attribuer la mesure à ce moteur changerait le périmètre de l’essai.

Les comptages de code historique excluent les tests, les sources originales
et les fichiers fournis. Un KLOC correspond à mille lignes de code selon la
convention de comptage retenue ; cette quantité ne mesure ni la qualité ni la
correction du programme.

## Quels tests, et exécutés par qui ?

Les contrôles de qualification sont fournis par la préparation et
l’orchestration de supervision, notamment à partir de vérificateurs AGILAB
préexistants. Leurs empreintes et celles du contrat sont protégées ; Qwen
reçoit l’interdiction de les modifier.

Un éventuel `tests.py` du projet généré est exécuté séparément. Il ne
remplace pas les vérifications indépendantes. On ne peut donc attribuer
l’ensemble des tests à Qwen, ni attribuer à Codex la rédaction initiale de
chaque test préexistant.

Les contrôleurs exécutent les vérifications et renvoient leurs échecs à Qwen
pour réparation. L’agent OpenCode peut également appeler les contrôles fournis
avec ses outils. Pour le run Iris observé et ses contrôles navigateur, les
preuves situent l’exécution sur `rtx5`. La préparation d’un test et son lieu
d’exécution sont deux informations distinctes.

## Par quelles interfaces passaient les échanges ?

SSH signifie Secure Shell, l’interface d’administration à distance.

| Sens | Interface et contenu | Ce qui est établi |
| --- | --- | --- |
| Supervision Mac → cluster | Administration SSH documentée et mise à disposition des scripts, objectifs, environnement, entrées et contrôles. | La configuration et la notice SSH existent ; le protocole exact de chaque transfert historique n’est pas reconstitué. |
| Contrôleur local → Tokki → OpenCode | Lancement du programme d’agent avec le projet, le modèle et les consignes. | Les scripts de lancement et des reçus de modèle sont conservés. |
| OpenCode ↔ Qwen | API HTTP locale pour les messages, réponses et demandes d’appels d’outils. | L’endpoint local est configuré ; le reçu Iris confirme le fournisseur et le modèle. |
| OpenCode → outils locaux | Lecture des entrées, édition des fichiers et exécution des contrôles, via les commandes encadrées par Tokki. | Les consignes et les traces examinées documentent cette boucle. |
| Cluster → supervision | Retour des résultats, erreurs, reçus et livrables. | Les artefacts récupérés existent ; ils ne constituent pas une capture réseau exhaustive. |
| Préparation de publication → Hugging Face | Publication de fichiers sélectionnés et validés. | Cette étape est distincte de la génération locale. |

Une configuration ne prouve pas chaque exécution. Un prompt ne prouve pas le
respect de toutes ses consignes. La documentation disponible ne permet pas
d’affirmer que chaque transfert a utilisé SCP ou rsync, ni que chaque octet a
été retracé.

## L’incident Threading et la version livrée

Le contrôleur de reconstruction désigne la tentative
`20260922T091918Z-b680a442` comme remplacée pour copie d’une application
préexistante. Il exige ensuite l’absence des anciennes ressources de démos et
prévoit une reconstruction sur `rtx1`. Ce script décrit la décision et ses
garde-fous ; il ne prouve pas seul l’achèvement d’une reconstruction.

L’index de livraison associe la route `threading_rtx` à un run ultérieur,
`20260922T161005Z-fb75e76b`. Les empreintes de ses fichiers concordent avec
celles du reçu de publication. Une validation du bundle porte le même reçu et
rapporte l’exécution réussie du notebook, du démarrage de l’application, de
son interaction et du workflow.

Cette validation indique **`scientific_correctness_verified: false`**.
Son périmètre couvre l’exécution et l’interface, puis la concordance des
résultats du notebook et du workflow. Le statut `passed` doit être lu avec
ces limites ; il ne constitue pas une certification générale de correction
scientifique.

Le journal original de la copie rejetée n’a pas été retrouvé dans la
sélection examinée. Elle ne permet pas de nommer précisément le fichier copié
et son chemin d’origine, ni de certifier la filiation de chaque ligne entre
les runs. L’audit de provenance cherche des empreintes identiques et des
accès à un répertoire connu, en excluant les sources et le helper fourni :
c’est un contrôle ciblé, pas une certification complète d’originalité.

## Ce que cette expérience permet de conclure

Les éléments conservés documentent une génération et des réparations
applicatives locales, accompagnées d’une préparation, de réutilisation de
code et d’une qualification indépendante. Ils ne démontrent pas une
construction intégrale à partir du seul notebook.

Les comparaisons restent non contrôlées. Elles n’établissent pas de gain
général de performance, d’économie, de qualité ou de débit reçu. Les contrôles
numériques particuliers d’autres applications doivent être interprétés dans
leurs propres périmètres.

La supervision Codex en ligne et la publication ultérieure sont explicites.
Un modèle local ne démontre ni une chaîne entièrement hors ligne, ni une
absence de sortie de données, ni un environnement isolé de tout réseau.

Cette synthèse repose sur une sélection de reçus historiques, scripts et
empreintes conservés par le mainteneur. Les pièces de travail ne sont pas
jointes à cet export public ; les liens proposés ici donnent accès aux
illustrations et au poster, pas à ces archives. Les conclusions et les
lacunes de preuve sont conservées ensemble.