Archtime

Un paradigme d'ingénierie logicielle pour le binôme humain-LLM. Déporter la complexité dynamique avant le runtime, la décrire exhaustivement dans un catalogue, et laisser le code d'exécution volontairement stupide.

Le problème

Tout système logiciel qui grandit accumule du routage conditionnel à l'exécution. Des branchements dans les workers, des feature flags, des machines à états implicites disséminées dans le code. Ce code est difficile à diagnostiquer, coûteux à modifier, et fragile à tester.

Un LLM peut produire 500 lignes de catalogue descriptif en quelques secondes. L'exhaustivité descriptive, qui était un luxe, devient gratuite. Si décrire tous les cas ne coûte plus rien, le routage dynamique à l'exécution perd sa justification économique.

Les trois temps

1. Archtime
L'interaction humain-LLM se situe en amont du runtime. Les flux sont pré-mappés dans un catalogue SQLite. Chaque étape est un INSERT. Chaque enchaînement est explicite. L'humain dirige et arbitre. Le LLM scripte et maintient.
conception
2. Runtime
Le runtime est volontairement stupide. Un superviseur lit le catalogue et enchaîne mécaniquement les étapes. Un worker exécute un handler pur sans savoir dans quel workflow il s'inscrit. Toute l'intelligence est dans le catalogue.
exécution
3. Signal
Si un flux est défaillant, le système signale au plus vite avec un blast zone précis : quel workflow, quel step, quel handler. Une ligne dans le catalogue, pas un call stack de 47 frames.
observation

Solidification

Chaque fonction métier existe sur un spectre thermique, de l'inférence libre (chaude, coûteuse, imprévisible) au binaire compilé (froid, gratuit, déterministe). La solidification consiste à faire descendre chaque fonction aussi bas que sa nature le permet.

strate 4 inférence libre coûteux, créatif, imprévisible strate 3 prompt cadré guidé, adaptable strate 2 skill paramétré répétable, structuré strate 1 binaire Go gratuit, déterministe, instantané strate 0 jugement humain irréductible

Le signal de descente est toujours le même : la répétabilité. Quand une tâche produit le même résultat de manière prévisible, elle est mûre pour descendre d'un cran. Un système mature a un ratio strate 1 élevé et une zone d'inférence libre réduite à ce qui est réellement nouveau.

Supervision multi-agents

Le modèle archtime s'applique aussi à la coordination d'agents LLM. Plusieurs agents opèrent en parallèle, chacun sur une tâche verrouillée. La synchronisation passe par trois bases SQLite partagées : mémoire (vault.db), observabilité (traces.db), analytics (sessions.db).

Un agent ne peut pas créer de nouvelles tâches, modifier le périmètre, ni déployer sans autorisation. Son scope est verrouillé par la mission vault. En cas de doute, il s'arrête et crée un checkpoint bloquant. L'humain supervise, arbitre, et relance.

Le coût de coordination est constant : le temps humain ne croît pas avec le nombre d'agents. Il croît avec le nombre de décisions non anticipées — que le modèle archtime vise précisément à réduire.

Pourquoi ça marche

Auditable

Un SELECT sur le catalogue montre toute la chaîne. Aucune lecture de code nécessaire.

Modifiable

Ajouter un step = un INSERT. Désactiver un step = UPDATE enabled = 0.

Diagnosticable

Le blast zone est un tuple (workflow, step, payload). Indexé, requêtable, précis.

Maintenable par un LLM

Le catalogue est du SQL. Le LLM le lit, le comprend, le génère. Pas de code clever à naviguer.

Conditions d'application

Archtime est adapté aux systèmes où le binôme humain-LLM peut itérer rapidement sur le catalogue, où les flux sont descriptibles en séquences plates, et où l'observabilité est une priorité.

Il n'est pas adapté aux systèmes où la latence d'adaptation est critique (trading haute fréquence, temps réel dur) ou où la variabilité runtime est irréductible (interactions utilisateur libres).

Archtime est le modèle d'exécution de l'écosystème HOROS. Le catalogue SQLite, les superviseurs génériques, et l'observation par traces sont déployés en production depuis mars 2026.