Date : 12/02/2026 03:30 (v3 — 04:30)
Priorite : HAUTE
Status : EN ATTENTE DE VALIDATION
Backlog : 12-02-2026-recreer-claude-code-devstral.md
Une organisation complete d'agents IA qui vit sur l'infra locale. Pas un outil, pas un assistant — une equipe autonome structuree en departements, avec une intelligence transversale qui identifie les axes d'amelioration et genere ses propres objectifs.
L'utilisateur est le CEO : il donne la direction strategique, prend les decisions critiques, et laisse l'organisation travailler.
┌──────────────────────┐
│ CEO (Humain) │
│ │
│ Objectifs strategiques│
│ Decisions critiques │
│ Validation finale │
└──────────┬─────────────┘
│
┌──────────┴─────────────┐
│ DIRECTION GENERALE │
│ (Orchestrateur IA) │
│ │
│ Decompose objectifs │
│ Priorise inter-equipes │
│ Alloue ressources GPU │
│ Escalade au CEO │
└──┬───┬───┬───┬───┬──┬──┘
│ │ │ │ │ │
┌───────────────────┘ │ │ │ │ │ └────────────────────┐
│ ┌────────────┘ │ │ │ └──────────┐ │
│ │ ┌──────────┘ │ └──────┐ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼
┌──────────┐ ┌──────┐ ┌────────┐ ┌────────┐ ┌──────┐ ┌──────────┐ ┌───────┐
│INGENIERIE│ │ OPS │ │RECHERCHE│ │ MEDIA │ │SECU │ │TRANSVERSAL│ │ CEO │
│ │ │ │ │ │ │ │ │ │ │ │ │ INTEL │
│ 5 agents │ │4 agts│ │3 agents│ │3 agents│ │3 agts│ │ 4 agents │ │4 agents│
└──────────┘ └──────┘ └────────┘ └────────┘ └──────┘ └──────────┘ └───────┘L'equipe qui code, teste, deploie, et maintient la qualite du code.
| Agent | Role | Outils | Modele |
|---|---|---|---|
| Coder | Ecrire/modifier du code, refactoring | read, write, edit, AST, git | Devstral (3090) |
| Reviewer | Review de code, detecter bugs, suggestions | read, AST, git diff, grep | Devstral (3090) |
| Tester | Ecrire et executer tests, valider coverage | bash (bun test), read, write | Qwen3-CN (2070S) |
| Deployer | CI/CD, smart-deploy, rollback | smart-deploy, docker, ssh, git | Qwen3-CN (2070S) |
| Architect | Decisions d'architecture, design patterns | read, AST, memory_search | Devstral (3090) |
Workflows internes :
L'equipe qui surveille, maintient, et reagit aux incidents 24/7.
| Agent | Role | Outils | Modele |
|---|---|---|---|
| Monitor | Healthchecks continus, detection anomalies | loki_query, docker, ssh, http_check | Qwen3-CN (2070S) |
| Incident | Diagnostic et resolution d'incidents | ssh, docker, loki, bash, git | Devstral (3090) |
| Backup | Verification backups, test restore, sync O2switch | ssh, rsync, zfs, cron_check | Qwen3-CN (2070S) |
| Infra | Gestion VMs, containers, ressources, updates | proxmox_api, docker, ssh, apt | Devstral (3090) |
Workflows internes :
Proactivite :
L'equipe qui cherche, documente, et apprend.
| Agent | Role | Outils | Modele |
|---|---|---|---|
| Explorer | Grep, read, AST, navigation codebase | grep, read, glob, AST, git_log | Qwen3-CN (2070S) |
| Analyst | Analyse logs, metriques, tendances | loki_query, supabase, jq | Devstral (3090) |
| Documenter | Genere/met a jour documentation, CLAUDE.md, memory | read, write, memory_store | Qwen3-CN (2070S) |
Workflows internes :
Proactivite :
L'equipe qui gere les contenus multimedia.
| Agent | Role | Outils | Modele |
|---|---|---|---|
| Transcriber | Transcription audio/video (Whisper) | ai_job (whisper), read, write | Qwen3-CN (2070S) |
| Vision | Analyse images, OCR, detection objets | ai_job (yolo), read | Qwen3-CN (2070S) |
| Organizer | Gestion Jellyfin, Nextcloud, fichiers | connector_fetch, ssh, bash | Qwen3-CN (2070S) |
Proactivite :
L'equipe qui protege l'infra.
| Agent | Role | Outils | Modele |
|---|---|---|---|
| Auditor | Audit configs, permissions, ports ouverts | ssh, nmap_light, read_config | Devstral (3090) |
| Watcher | Surveillance acces, logs auth, fail2ban | loki_query, ssh, fail2ban | Qwen3-CN (2070S) |
| Patcher | Veille CVE, mises a jour securite | web_search, apt, docker | Qwen3-CN (2070S) |
Workflows internes :
Proactivite :
L'equipe la plus importante. Elle ne produit rien directement — elle rend tout le reste meilleur.
| Agent | Role | Outils | Modele |
|---|---|---|---|
| Strategist | Identifie axes d'amelioration, genere objectifs | all_metrics, memory_search, supabase | Devstral (3090) |
| Optimizer | Analyse performance des agents, optimise prompts/contexte | agent_metrics, a/b_test | Devstral (3090) |
| Connector | Detecte les synergies inter-equipes, coordonne | all_tasks, cross_reference | Qwen3-CN (2070S) |
| Learner | Consolide les lecons apprises, enrichit la memoire collective | memory_store, memory_search, read | Qwen3-CN (2070S) |
Le Strategist est l'agent qui pense a la place de l'organisation. Il tourne en continu et :
Exemples de ce qu'il pourrait identifier :
Observation : "Les 5 derniers deploys ont pris > 15 min chacun"
Analyse : "Le build Docker de connectors-api telecharge 200MB de deps a chaque fois"
Objectif genere : "Optimiser le Dockerfile connectors-api avec multi-stage build et cache layers"
→ Envoye a l'equipe Ingenierie
Observation : "L'Agent Monitor envoie 12 alertes/jour dont 10 sont des faux positifs"
Analyse : "Les seuils de RAM sont trop bas pour les containers Java"
Objectif genere : "Ajuster les seuils monitoring pour gitlab et supabase"
→ Envoye a l'equipe Ops
Observation : "3 bugs cette semaine lies a des query params non-string sur connectors-api"
Analyse : "Le schema /api/fetch n'est pas valide cote TypeScript"
Objectif genere : "Ajouter une validation Zod sur les query params de /api/fetch"
→ Envoye a l'equipe Ingenierie
Observation : "Le CEO a du intervenir 8 fois cette semaine pour des decisions simples"
Analyse : "Les agents escaladent trop — la plupart des decisions avaient un choix evident"
Objectif genere : "Reduire le seuil d'escalade de 0.7 a 0.5 pour les taches non-critiques"
→ Auto-applique par l'OptimizerL'Optimizer mesure la performance de chaque agent et optimise en continu :
Metriques suivies par agent :
- Taux de succes (tache completee sans intervention)
- Confiance moyenne
- Tokens consommes / tache
- Temps moyen / tache
- Taux de retry
- Taux d'escalade CEOLe Connector detecte quand le travail d'une equipe pourrait beneficier a une autre :
Securite/Auditor trouve une config nginx fragile
→ Connector notifie Ingenierie/Architect : "A prendre en compte pour le prochain deploy"
Recherche/Analyst detecte un pic de 404 sur /api/old-endpoint
→ Connector notifie Ops/Monitor : "Ajouter une redirection ou un rate-limit"
Ingenierie/Coder vient de deployer un nouveau service
→ Connector notifie :
- Ops/Monitor : "Ajouter le healthcheck"
- Securite/Auditor : "Auditer la config"
- Recherche/Documenter : "Documenter le service"Apres chaque objectif complete (reussi OU echoue), le Learner :
Resultat : l'organisation ne fait jamais deux fois la meme erreur.
L'equipe qui comprend le CEO. Elle apprend comment tu parles, ce que tu veux vraiment dire, et anticipe tes besoins.
| Agent | Role | Outils | Modele |
|---|---|---|---|
| Interpreter | Traduit les messages CEO en specifications precises | memory_search, user_patterns | Devstral (3090) |
| Profiler | Apprend les preferences, le vocabulaire, les habitudes du CEO | user_history, memory_store | Qwen3-CN (2070S) |
| Anticipator | Predit les besoins futurs du CEO en fonction des patterns | all_objectives, scheduler, calendar | Devstral (3090) |
| Simplifier | Traduit le jargon technique en langage CEO pour les rapports | read, template | Qwen3-CN (2070S) |
Quand le CEO ecrit "ca marche pas", l'Interpreter :
Message CEO : "pousse ca sur o2switch"
Interpreter traduit :
- "ca" = le fichier dont on vient de parler (proposition agent)
- "o2switch" = le serveur O2switch, dossier backup/configs/claude/propositions/
- "pousse" = scp/rsync, pas git push
→ Objectif genere : "Copier le fichier X vers O2switch:~/backup/configs/claude/propositions/"
Message CEO : "je suis tres etonné je m'attendais a ce que l'on ait vraiment une team d'ia beaucoup plus vaste"
Interpreter traduit :
- Mecontentement sur le scope de la proposition
- "team vaste" = pas 5 agents, mais des dizaines, couvrant tous les aspects
- Le CEO voit plus grand que ce qu'on propose
→ Feedback a l'equipe Transversale : "La proposition manque d'ambition, elargir le scope"Le Profiler maintient un profil vivant du CEO qui s'enrichit a chaque interaction :
{
"communication_style": {
"language": "fr",
"formality": "informal",
"typos_frequent": true,
"uses_abbreviations": true,
"prefers_concise": true,
"examples_patterns": [
"'ca' = le sujet de la derniere conversation",
"'pousse/push' = deploy/upload selon contexte",
"'verifie' = check + fix si necessaire",
"questions sans '?' = c'est un ordre"
]
},
"preferences": {
"detail_level_reports": "resume d'abord, details sur demande",
"notification_frequency": "resultats importants uniquement",
"decision_style": "choix binaires rapides, pas de longs argumentaires",
"working_hours": "souvent tard le soir (22h-4h)",
"impatience_threshold": "si > 2 messages sans resultat → frustration"
},
"priorities": {
"current": ["agent autonome devstral", "connectors ecosystem"],
"recurring": ["stabilite prod", "pas de regression", "automatiser les taches repetitives"],
"values": ["autonomie", "simplicite", "fiabilite > features"]
},
"vocabulary": {
"stack": "infrastructure 33800",
"la bas": "o2switch",
"le front": "connectors-front",
"la prod": "prod-portainer",
"le reverse proxy": "nginx VM 192.168.1.104"
}
}Ce profil est :
agents.ceo_profile)L'Anticipator observe les patterns et genere des objectifs proactifs :
Pattern detecte : "Chaque lundi matin, le CEO verifie les logs du weekend"
→ Objectif genere (dimanche soir) : "Preparer un resume des logs weekend"
→ Le CEO recoit le resume avant meme de le demander
Pattern detecte : "Apres un deploy, le CEO teste toujours l'endpoint manuellement"
→ Objectif genere (post-deploy) : "Tester automatiquement l'endpoint et envoyer le resultat"
Pattern detecte : "Le CEO travaille souvent tard et oublie de verifier les backups"
→ Objectif genere (quotidien 23h) : "Rapport backup du jour via ntfy"Traduit les rapports techniques en langage que le CEO comprend et apprecie :
Rapport technique (Agent Incident) :
"Container connectors-api (prod-portainer) OOM killed a 03:47:22 UTC.
Memory usage peaked at 2.1GB, limit set at 2GB in compose config.
Root cause: memory leak in /api/fetch handler when proxying large responses.
Mitigation: restarted container, added --max-old-space-size=1536 to Bun flags."
Rapport Simplifier (pour le CEO) :
"connectors-api a crash cette nuit (trop de RAM). Redemarré automatiquement.
Cause : fuite memoire sur les grosses requetes /api/fetch.
Fix temporaire appliqué. Fix definitif à planifier → decision requise."Un agent generaliste avec 10 outils et un prompt de 2000 tokens :
Un micro-agent avec 2-3 outils et un prompt de 400 tokens :
Un agent = une competence = un scope = un contexte minimal
Si un agent a besoin de plus de 5 outils, il faut le decouper. Si son prompt systeme depasse 500 tokens, il faut le simplifier. Si sa tache prend plus de 10 iterations ReAct, il faut la decomposer.
Mauvais : Agent "DevOps" qui code, teste, deploie, monitore
Prompt : 2000 tokens
Outils : 15 (read, write, grep, bash, git, docker, ssh, loki, test, deploy...)
Contexte : tout le projet + infra + logs + historique
→ Le modele est perdu, fait des erreurs, oublie des reglesBon : 5 micro-agents qui se passent le relais
Coder : 400 tok prompt, 4 outils (read, write, edit, AST)
Reviewer : 300 tok prompt, 3 outils (read, AST, git_diff)
Tester : 300 tok prompt, 3 outils (bash, read, write)
Deployer : 300 tok prompt, 3 outils (smart-deploy, docker, ssh)
Monitor : 300 tok prompt, 3 outils (loki, http_check, docker)
→ Chaque agent est un expert chirurgical sur son domaineAvec 26 agents au total (vs 5 dans la v1), chaque agent :
Le resultat : meme un modele 24B local peut etre excellent quand il n'a qu'UNE chose a faire avec un contexte parfait.
RTX 3090 (24 GB) RTX 2070 Super (8 GB)
┌──────────────────────┐ ┌──────────────────────┐
│ Devstral Small 2 │ │ Qwen3-Coder-Next │
│ Q5_K_M (~17 GB) │ │ (~5 GB VRAM) │
│ │ │ │
│ Agents "penseurs" : │ │ Agents "executants": │
│ (raisonnement) │ │ (taches rapides) │
│ │ │ │
│ - Coder │ │ - Tester │
│ - Reviewer │ │ - Deployer │
│ - Architect │ │ - Explorer │
│ - Incident │ │ - Monitor │
│ - Infra │ │ - Backup │
│ - Analyst │ │ - Transcriber │
│ - Auditor │ │ - Vision │
│ - Strategist │ │ - Organizer │
│ - Optimizer │ │ - Watcher │
│ - Interpreter │ │ - Patcher │
│ - Anticipator │ │ - Documenter │
│ │ │ - Connector │
│ (11 agents) │ │ - Learner │
│ │ │ - Profiler │
│ ~7 GB KV cache │ │ - Simplifier │
│ │ │ │
│ │ │ (15 agents) │
│ │ │ ~3 GB KV cache │
└──────────────────────┘ └──────────────────────┘Repartition : 11 agents "penseurs" sur la 3090 (raisonnement complexe), 15 agents "executants" sur la 2070S (taches rapides, formatage, routing). 26 agents au total.
Les agents ne tournent pas tous en permanence — ils sont actives a la demande par la Direction Generale. Les modeles sont charges une fois et reutilises.
Pour les situations ou le modele local ne suffit pas :
Chaque appel LLM passe par le Context Builder qui assemble le contexte parfait.
| # | Layer | Source | Budget | Trimming |
|---|---|---|---|---|
| 1 | Regles | CLAUDE.md, MEMORY.md, regles agent | ~500 tok | JAMAIS trimme |
| 2 | Etat | Tache courante, resultats precedents, objectif parent | ~300 tok | JAMAIS trimme |
| 3 | Semantique | claude-memory (pgvector), incidents similaires | ~500-1500 tok | Top-3 resultats |
| 4 | Code | AST repo map, grep cible, git diff recent | ~2000-4000 tok | Signatures d'abord, corps si budget |
| 5 | Infra | index/*.md, conf.gouroubleu.yml | ~500 tok | Condense |
| 6 | Git | git log, git blame sur fichiers concernes | ~300-500 tok | Condense ou supprime |
Au lieu de balancer des fichiers entiers, on parse la structure :
// Budget : ~200 tokens au lieu de ~5000 pour le fichier entier
// connectors-api/src/routes/fetch.ts
export async function fetchRoute(app: Elysia) {
// POST /api/fetch - proxy vers connecteurs externes
// Params: { connector_id, instance_id, endpoint, method, body?, query? }
}
// connectors-api/src/connectors/registry.ts
export class ConnectorRegistry {
getConnector(type: string): BaseConnector
getInstances(connector_id: string): Instance[]
// Note: auth_type 'ssh' mappe vers 'custom' en DB
}| Canal | Usage | Direction |
|---|---|---|
| ntfy (push) | Alertes, resultats, demandes rapides | Org → CEO |
| Mail (Mailjet) | Rapports detailles, resume quotidien/hebdo | Org → CEO |
| Web UI | Decisions complexes, dashboard, logs temps reel | CEO ↔ Org |
| ntfy reply | Reponses rapides A/B/C | CEO → Org |
📊 Resume Ulias Org — 12/02/2026
OBJECTIFS
✅ 7 completes (dont 4 auto-generes par Strategist)
🔄 2 en cours
❌ 1 echoue (escalade CEO requise)
⏸️ 3 en attente de decision
EQUIPES
Ingenierie : 3 commits, 1 feature, 2 bug fixes
Ops : 0 incident, 288 healthchecks OK, 1 alerte faux-positif supprimee
Recherche : 47K lignes de logs analysees, 2 patterns detectes
Securite : audit hebdo OK, 0 CVE critique
Media : 3 fichiers transcrits, 12 images classifiees
Transversal : 4 objectifs generes, 2 optimisations prompts appliquees
METRIQUES
Taux autonomie : 78% (objectif : 80%)
Confiance moyenne : 0.82
Interventions CEO : 3 (objectif : < 5/jour)
Tokens consommes : 847K (cout cloud equivalent : ~$0.34)
DECISIONS EN ATTENTE
→ #47 : "Migrer connectors-api vers Elysia v2 ?" (Ingenierie)
→ #51 : "Ouvrir le port 8443 pour le nouveau service ?" (Securite)
→ #53 : "Supprimer les logs > 60 jours sur O2switch ?" (Ops) ┌─────────────────────┐
│ Sources d'objectifs │
│ │
│ - CEO (web UI/ntfy) │
│ - Strategist (auto) │
│ - Scheduler (cron) │
│ - Incident (alerte) │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ Direction Generale │
│ │
│ 1. Priorise │
│ 2. Decompose │
│ 3. Assigne equipe │
│ 4. Alloue GPU │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ Equipe assignee │
│ │
│ Agent 1 → Agent 2 │
│ (workflow interne) │
└──────────┬───────────┘
│
┌──────────▼───────────┐
│ Verification │
│ │
│ - Tests passent ? │
│ - Confiance > 0.7 ? │
│ - Review OK ? │
└──────────┬───────────┘
│
┌────────────────┼────────────────┐
│ │ │
✅ Succes ⚠️ Doute ❌ Echec
│ │ │
Notification Escalade CEO Retry/Escalade
+ Learner (decision) + Incident report
extrait lecons| Frequence | Agent | Tache |
|---|---|---|
| 5 min | Monitor | Healthcheck tous les endpoints + containers |
| 1h | Watcher | Scan logs auth pour tentatives suspectes |
| 6h | Analyst | Analyse tendances logs (volume, erreurs, latence) |
| Quotidien | Backup | Verification snapshots ZFS + sync O2switch |
| Quotidien | Strategist | Analyse metriques → genere objectifs amelioration |
| Quotidien | Learner | Consolidation memoire collective |
| Hebdo | Auditor | Audit securite complet (configs, ports, permissions) |
| Hebdo | Optimizer | A/B test prompts, ajustement thresholds |
| Hebdo | Patcher | Veille CVE + mises a jour disponibles |
Coder → Reviewer → Tester → bash (tests) → Deployer
│
├─ OK → deploy
└─ KO → retour Coder (max 3 cycles)Meme tache → 2 approches paralleles → Agent Juge → meilleur resultatMeme prompt → 3 temperatures differentes → vote pondere par confiance
(46% moins d'echecs que le vote simple)Equipe A resout le probleme
Equipe B verifie independamment (sans voir la solution A)
Si concordent → haute confiance
Si divergent → Strategist analyse pourquoiL'organisation apprend a 3 niveaux : memoire factuelle, evolution des prompts, et optimisation du routing.
Apres CHAQUE tache (reussie ou echouee), le Learner extrait une lecon :
Tache : "Ajouter endpoint /api/users/export"
Resultat : ECHEC au 1er essai, SUCCES au 2eme
Lecon extraite : {
category: "pitfall",
lesson: "Les query params de connectors-api doivent etre des strings, pas des numbers",
services: ["connectors-api"],
agent: "coder",
team: "engineering",
embedding: [0.23, -0.41, ...] // nomic-embed-text
}Au prochain appel du Coder sur connectors-api, le Context Builder (layer 3 — semantique) retrouve cette lecon par similarite vectorielle et l'injecte dans le contexte :
[LECON PASSEE] Attention : les query params de connectors-api
doivent etre des strings. maxWidth: 800 → 422 erreur.
Utiliser maxWidth: '800' (string).L'agent ne fait JAMAIS deux fois la meme erreur — tant que la lecon est dans pgvector.
Chaque agent a un prompt versionne. L'Optimizer fait evoluer les prompts :
┌─────────────────────────────────────────────────┐
│ CYCLE PROMPT EVOLUTION │
│ │
│ 1. Prompt v1 deploye │
│ │ │
│ 2. Metriques collectees sur 20 taches : │
│ - Taux succes : 72% │
│ - Confiance moy : 0.68 │
│ - Echecs frequents : "oublie de lire le │
│ fichier avant d'editer" │
│ │ │
│ 3. Optimizer analyse les echecs, genere v2 : │
│ + Ajout regle : "TOUJOURS read avant edit" │
│ + Suppression exemple inutile (-80 tokens) │
│ + Reformulation consigne ambigue │
│ │ │
│ 4. A/B test : 50% taches v1, 50% taches v2 │
│ │ │
│ 5. Resultats v2 : 84% succes, 0.79 confiance │
│ │ │
│ 6. v2 devient le prompt actif │
│ v1 archivee (rollback possible) │
└─────────────────────────────────────────────────┘Table Supabase agents.prompt_versions :
CREATE TABLE agents.prompt_versions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
agent_name TEXT NOT NULL,
version INT NOT NULL,
prompt_text TEXT NOT NULL,
is_active BOOLEAN DEFAULT false,
success_rate FLOAT,
avg_confidence FLOAT,
avg_tokens FLOAT,
sample_size INT DEFAULT 0,
created_at TIMESTAMPTZ DEFAULT now(),
promoted_at TIMESTAMPTZ, -- quand cette version est devenue active
notes TEXT -- pourquoi cette version a ete creee
);Concretement, le prompt du Coder va passer de :
v1 : "Tu es un agent qui edite du code TypeScript."
→ 72% succes
v7 : "Tu edites du code TypeScript dans l'ecosysteme 33800.
REGLES :
1. TOUJOURS read_file avant edit
2. Verifier les types des query params (strings uniquement)
3. Ne JAMAIS modifier un fichier sans comprendre le contexte
4. Preferer edit a write (ne pas ecraser)
OUTILS : read_file, write_file, edit_file, ast_search"
→ 91% succesChaque version est le resultat de lecons apprises par echec et corrigees.
L'Optimizer apprend quel modele utiliser pour quel type de tache :
┌──────────────────────────────────────────────────────┐
│ TABLE DE ROUTING (evoluante) │
│ │
│ Type de tache │ Modele initial │ Modele actuel │
│ ────────────────────┼────────────────┼───────────────│
│ Edit simple │ Qwen3-CN │ Qwen3-CN ✓ │
│ Bug fix 1 fichier │ Devstral │ Qwen3-CN ↑ │
│ Bug fix multi-fich │ Devstral │ Devstral ✓ │
│ Feature nouvelle │ Devstral │ Devstral ✓ │
│ Refactor │ Devstral │ Devstral ✓ │
│ Config nginx │ Devstral │ Qwen3-CN ↑ │
│ Analyse logs │ Devstral │ Qwen3-CN ↑ │
│ Decision archi │ Devstral │ Claude API ↑ │
│ ────────────────────┼────────────────┼───────────────│
│ ↑ = le routing a ete modifie par l'Optimizer │
│ Raison : metriques montrent que le modele initial │
│ etait surdimensionne (Devstral → Qwen3-CN) ou │
│ sous-dimensionne (Devstral → Claude API) │
└──────────────────────────────────────────────────────┘L'Optimizer track les metriques par (agent, type_tache, modele) et rebalance :
Au-dela des agents individuels, l'organisation apprend des patterns globaux :
Patterns detectes par le Strategist (exemples) :
1. "Les taches qui touchent connectors-api echouent 3x plus souvent
que les autres projets"
→ Analyse Learner : "Le schema Elysia a des pieges specifiques
(query strings, headers, WS objects)"
→ Action : enrichir les regles du Coder avec les pieges Elysia
2. "Les deploys du vendredi soir echouent 2x plus souvent"
→ Analyse : "Les pipelines GitLab sont plus lentes le vendredi
(backup ZFS concurrent)"
→ Action : decaler les deploys non-urgents au lundi matin
3. "Le CEO corrige l'Interpreter 40% du temps sur les messages courts"
→ Analyse : "Les messages de 1-3 mots sont trop ambigus"
→ Action : l'Interpreter demande une clarification au lieu de deviner
quand le message < 4 mots et confiance < 0.6
4. "L'Agent Reviewer trouve 0 problemes dans 80% des reviews"
→ Analyse : "Le Coder est devenu assez bon pour que le review
soit souvent inutile sur les edits simples"
→ Action : skip le review pour les edits < 20 lignes avec
confiance Coder > 0.9 (economie de tokens)EXECUTION
│
├── Tache executee par agent
│ │
│ ├── Succes ──→ Learner extrait lecon positive
│ │ │
│ └── Echec ───→ Learner extrait lecon negative
│ │
│ ▼
│ ┌─────────────────────┐
│ │ STOCKAGE │
│ │ │
│ │ pgvector : lecons │
│ │ Supabase : metrics │
│ │ prompt_versions │
│ │ routing_table │
│ └─────────┬───────────┘
│ │
▼ ▼
PROCHAINE EXECUTION OPTIMISATION
│ │
│ Optimizer :
│ - A/B test prompts
│ - Ajuste routing
│ - Ajuste thresholds
│ │
│ Strategist :
│ - Patterns globaux
│ - Objectifs amelioration
│ │
└── Context Builder injecte les lecons pertinentes
dans le contexte du prochain appelResultat : l'organisation s'ameliore de maniere exponentielle les premieres semaines (beaucoup de lecons nouvelles), puis converge vers un plateau de haute performance. Chaque echec est un investissement — il rend le prochain succes plus probable.
CREATE SCHEMA IF NOT EXISTS agents;
-- Objectifs (source: CEO, Strategist, Scheduler, Incident)
CREATE TABLE agents.objectives (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
title TEXT NOT NULL,
description TEXT,
priority INT DEFAULT 5 CHECK (priority BETWEEN 1 AND 10),
status TEXT DEFAULT 'pending'
CHECK (status IN ('pending','planning','in_progress','blocked','completed','failed','cancelled')),
source TEXT DEFAULT 'ceo', -- 'ceo', 'strategist', 'scheduler', 'incident'
source_agent TEXT, -- quel agent a genere l'objectif
team TEXT, -- equipe assignee
tags TEXT[],
parent_objective_id UUID REFERENCES agents.objectives(id), -- sous-objectifs
created_at TIMESTAMPTZ DEFAULT now(),
started_at TIMESTAMPTZ,
completed_at TIMESTAMPTZ,
result JSONB,
error TEXT
);
-- Taches (decomposition d'un objectif)
CREATE TABLE agents.tasks (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
objective_id UUID REFERENCES agents.objectives(id) ON DELETE CASCADE,
agent_type TEXT NOT NULL,
agent_name TEXT NOT NULL, -- 'coder', 'monitor', 'strategist', etc.
team TEXT NOT NULL, -- 'engineering', 'ops', 'research', 'media', 'security', 'transversal'
title TEXT NOT NULL,
description TEXT,
context JSONB,
status TEXT DEFAULT 'pending'
CHECK (status IN ('pending','in_progress','completed','failed','blocked','cancelled')),
blocked_by UUID[],
parent_task_id UUID REFERENCES agents.tasks(id),
pipeline_type TEXT DEFAULT 'direct'
CHECK (pipeline_type IN ('direct','verification_chain','horse_race','cisc','cross_validation')),
result JSONB,
confidence FLOAT CHECK (confidence BETWEEN 0 AND 1),
model_used TEXT,
tokens_used INT,
duration_ms INT,
iterations INT,
created_at TIMESTAMPTZ DEFAULT now(),
completed_at TIMESTAMPTZ
);
-- Messages agent <-> LLM (historique debug)
CREATE TABLE agents.messages (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
task_id UUID REFERENCES agents.tasks(id) ON DELETE CASCADE,
role TEXT NOT NULL CHECK (role IN ('system','user','assistant','tool')),
content TEXT,
tool_calls JSONB,
tool_results JSONB,
tokens INT,
created_at TIMESTAMPTZ DEFAULT now()
);
-- Decisions en attente du CEO
CREATE TABLE agents.decisions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
task_id UUID REFERENCES agents.tasks(id),
objective_id UUID REFERENCES agents.objectives(id),
question TEXT NOT NULL,
options JSONB, -- [{label, description, recommended}]
context_summary TEXT, -- resume du contexte pour le CEO
urgency TEXT DEFAULT 'normal' CHECK (urgency IN ('low','normal','high','critical')),
response TEXT,
responded_at TIMESTAMPTZ,
timeout_at TIMESTAMPTZ,
auto_decision TEXT, -- decision automatique si timeout
notified_via TEXT[],
created_at TIMESTAMPTZ DEFAULT now()
);
-- Metriques par agent (pour l'Optimizer)
CREATE TABLE agents.metrics (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
agent_name TEXT NOT NULL,
team TEXT NOT NULL,
metric_type TEXT NOT NULL, -- 'success_rate', 'avg_confidence', 'avg_tokens', 'avg_duration', 'escalation_rate'
value FLOAT NOT NULL,
period TEXT NOT NULL, -- 'daily', 'weekly'
period_start TIMESTAMPTZ NOT NULL,
metadata JSONB,
created_at TIMESTAMPTZ DEFAULT now()
);
-- Lecons apprises (indexees par le Learner)
CREATE TABLE agents.lessons (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
objective_id UUID REFERENCES agents.objectives(id),
task_id UUID REFERENCES agents.tasks(id),
lesson TEXT NOT NULL,
category TEXT, -- 'bug', 'pattern', 'convention', 'pitfall', 'optimization'
team TEXT,
services TEXT[], -- services concernes
embedding VECTOR(768), -- nomic-embed-text via claude-memory
importance FLOAT DEFAULT 0.5,
created_at TIMESTAMPTZ DEFAULT now()
);
-- Profil CEO (maintenu par le Profiler)
CREATE TABLE agents.ceo_profile (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
profile_type TEXT NOT NULL, -- 'vocabulary', 'preference', 'pattern', 'habit'
key TEXT NOT NULL,
value JSONB NOT NULL,
confidence FLOAT DEFAULT 0.5, -- augmente avec les confirmations
learned_from UUID, -- objectif/task qui a revele ce pattern
created_at TIMESTAMPTZ DEFAULT now(),
updated_at TIMESTAMPTZ DEFAULT now()
);
-- Historique interactions CEO (pour le Profiler/Interpreter)
CREATE TABLE agents.ceo_interactions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
raw_message TEXT NOT NULL, -- message original du CEO
interpreted_as TEXT, -- traduction par l'Interpreter
objective_created UUID REFERENCES agents.objectives(id),
feedback TEXT, -- le CEO a-t-il corrige l'interpretation ?
created_at TIMESTAMPTZ DEFAULT now()
);
-- Versions de prompts par agent (pour l'Optimizer)
CREATE TABLE agents.prompt_versions (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
agent_name TEXT NOT NULL,
version INT NOT NULL,
prompt_text TEXT NOT NULL,
is_active BOOLEAN DEFAULT false,
success_rate FLOAT,
avg_confidence FLOAT,
avg_tokens FLOAT,
sample_size INT DEFAULT 0,
created_at TIMESTAMPTZ DEFAULT now(),
promoted_at TIMESTAMPTZ,
notes TEXT
);
-- Table de routing modele par type de tache (pour l'Optimizer)
CREATE TABLE agents.routing_rules (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
agent_name TEXT NOT NULL,
task_pattern TEXT NOT NULL, -- regex ou tag qui matche le type de tache
model TEXT NOT NULL, -- 'devstral', 'qwen3-cn', 'claude-api'
pipeline TEXT DEFAULT 'direct', -- quelle pipeline utiliser
success_rate FLOAT,
sample_size INT DEFAULT 0,
is_active BOOLEAN DEFAULT true,
created_at TIMESTAMPTZ DEFAULT now(),
updated_at TIMESTAMPTZ DEFAULT now()
);
-- GRANT obligatoire
GRANT ALL ON SCHEMA agents TO anon, authenticated, service_role;
GRANT ALL ON ALL TABLES IN SCHEMA agents TO anon, authenticated, service_role;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA agents TO anon, authenticated, service_role;| Composant existant | Usage | Modifications |
|---|---|---|
| ai-orchestrator | Queue GPU, dispatch 3090/2070S | Endpoint /agent/infer |
| claude-memory (pgvector) | Memoire semantique + embeddings lecons | Table agents.lessons |
| connectors-api | SSH, GitHub, Proxmox, Supabase, APIs | Aucune |
| notif-logger | ntfy + mail Mailjet | Templates agents |
| smart-deploy | Agent Deployer l'utilise | Aucune |
| Ollama (multi-GPU) | Devstral + Qwen3-CN | Pull modeles |
| Supabase | Toutes les tables agents.* | Creer schema + tables |
| Loki | Logs de tous les agents | Config Promtail |
| GitLab | Agents Code/Deployer commit/push | Aucune |
| Grafana | Dashboard metriques agents | Nouveau dashboard |
Runtime : Bun 1.x (TypeScript)
API : Elysia (orchestrateur + web UI backend)
Frontend : Qwik (web UI decisions + dashboard)
Database : Supabase PostgreSQL + Realtime (events inter-agents)
Memoire : claude-memory (pgvector + nomic-embed-text)
LLM local : Ollama (Devstral Small 2 Q5 + Qwen3-Coder-Next)
LLM cloud : API Claude Opus (fallback)
AST parsing : tree-sitter (node bindings)
Notifications: notif-logger (ntfy + Mailjet)
Logs : Loki via Promtail
CI/CD : GitLab pipeline
Deploy : smart-deployGate critique : on ne construit RIEN tant que ca n'est pas valide.
devstral-small-2 et qwen3-coder-next sur Ollamaceo_profile, ceo_interactionsTotal estime : 8-9 semaines pour l'organisation complete. Mais valeur utilisable des Sprint 2 (equipe Ingenierie fonctionnelle).
| Risque | Impact | Mitigation |
|---|---|---|
| Tool calling Devstral pas fiable | Haut | JSON fallback + retry + vLLM si besoin |
| Boucles infinies agent | Moyen | Max 15 iterations, timeout, alerte |
| Strategist genere des objectifs inutiles | Moyen | Validation CEO pour les 2 premieres semaines, puis autonomie progressive |
| Surcharge GPU (trop d'agents simultanes) | Moyen | Queue avec priorites, agents non-urgents attendent |
| L'org fait une betise en prod | Tres haut | Dry-run par defaut, confirmation CEO pour toute action destructive |
| Cout API Claude explose | Bas | Budget cap $20/mois, alertes a $5/$10/$15 |
| Complexite excessive | Haut | Incremental : chaque sprint ajoute une equipe, on valide avant la suivante |
| Metrique | Sprint 2 | Sprint 5 | Sprint 8 |
|---|---|---|---|
| Taux d'autonomie | 30% | 60% | 80% |
| Objectifs auto-generes/jour | 0 | 2-3 | 5-10 |
| Interventions CEO/jour | 10+ | 5 | < 3 |
| Incidents detectes avant impact | 0% | 50% | 80% |
| Temps moyen resolution bug | Manuel | 30 min | 10 min |
| Interpretation correcte CEO msg | N/A | 60% | 90% |
| Besoins anticipes/semaine | 0 | 2 | 10+ |
Nom : ulias-org (pas juste un agent — une organisation)
Repository : gouroubleu/ulias-org
ulias-org/
├── src/
│ ├── director/ # Direction Generale (orchestrateur)
│ ├── teams/
│ │ ├── engineering/ # Coder, Reviewer, Tester, Deployer, Architect
│ │ ├── ops/ # Monitor, Incident, Backup, Infra
│ │ ├── research/ # Explorer, Analyst, Documenter
│ │ ├── media/ # Transcriber, Vision, Organizer
│ │ ├── security/ # Auditor, Watcher, Patcher
│ │ ├── transversal/ # Strategist, Optimizer, Connector, Learner
│ │ └── ceo-intel/ # Interpreter, Profiler, Anticipator, Simplifier
│ ├── context-builder/ # Assemblage contexte multi-source
│ │ ├── layers/
│ │ ├── ast/ # tree-sitter
│ │ └── ranker.ts
│ ├── agent-runner/ # Boucle ReAct generique
│ ├── pipelines/ # direct, verification, horse_race, cisc, cross_validation
│ ├── tools/ # bash, git, ssh, docker, loki, etc.
│ ├── communication/ # ntfy, mail, web UI bridge
│ ├── models/ # Ollama, vLLM, Claude API
│ └── db/ # Supabase client, migrations
├── prompts/ # 1 fichier par agent (26 prompts)
├── web-ui/ # App Qwik (decisions, dashboard, logs)
├── tests/
├── Dockerfile
├── conf.prod.gouroubleu.yml
└── package.jsonCe n'est plus un agent — c'est une organisation de 26 micro-agents repartis en 7 equipes, avec :
Les deux equipes cles :
La philosophie micro-agent est le multiplicateur de force : 26 agents hyper-specialises avec 300-500 tokens de prompt et 2-5 outils chacun, plutot que 5 agents generalistes noyes dans leur contexte. C'est ce qui permet a un modele 24B local de rivaliser avec des modeles 10x plus gros.
Le CEO intervient de moins en moins : au debut ~10 decisions/jour, objectif < 3/jour au Sprint 7. L'organisation apprend, s'adapte, anticipe, et s'ameliore d'elle-meme.
80% de l'infra existe. Le travail c'est la colle intelligente entre les morceaux, et surtout la qualite du Context Builder qui fait TOUT.
Premiere etape : Sprint 0 — valider que Devstral peut appeler des outils de maniere fiable. Rien ne sert de construire une cathedrale si les briques ne tiennent pas.