Arc OS

L'Orchestration System pour les équipes AI

Ton entreprise n'a pas besoin de plus de chatbots. Elle a besoin d'un département qui ne dort jamais.

Qu'est-ce qu'Arc OS

Arc OS est une plateforme de gestion de main-d'œuvre AI qui déploie des équipes d'agents autonomes dans un bureau visuel en temps réel. Chaque agent a un rôle défini, un superviseur et des standards de qualité applicables. Le CEO fixe la direction. Les agents gèrent tout le reste.

En une phrase : Arc OS transforme les modèles AI en employés responsables qui révisent mutuellement leur travail avant de te le remettre.

v2 : Architecture Native-First

Arc OS est une refonte de fond en comble sur les outils natifs de Claude Code :

67% moins de code. Zéro backend personnalisé. Mêmes capacités.

Fonctionnalités principales

1. Chaîne d'approvisionnement AI

Les agents opèrent comme une chaîne d'approvisionnement coordonnée — pas des chatbots isolés :

Le CEO fixe un objectif
    → Rick décompose, délègue, assigne les contraintes
        → Morty exécute (code, analyse, infrastructure)
            → Summer révise (sécurité, qualité, audit OWASP)
                → Jerry documente (décisions, raisonnements, piste d'audit)
    → Rick synthétise tous les résultats
    → Le CEO ne voit que la sortie finale, validée

2. Équipes d'agents (natif)

Construit sur les Agent Teams de Claude Code :

• TeamCreate — Déployer une équipe coordonnée
• TaskCreate/TaskUpdate — Gestion structurée des tâches
• SendMessage — Communication inter-agents
• Aucune couche de messagerie personnalisée nécessaire

3. Bureau visuel

Bureau pixel Phaser.js en temps réel où les agents existent comme des entités persistantes :

• Les agents sont assis à des bureaux, se déplacent les uns vers les autres lors des délégations
• Des bulles de dialogue montrent l'activité en cours
• Les couleurs de statut reflètent la charge de travail
• Le tableau des tâches visible sur le mur
• Le bureau EST l'état du système — un coup d'œil montre tout

4. Centre de commandes mobile (Telegram)

Intégration officielle Telegram Channel :

• Commandes en langage naturel : /status, /tasks, délégation
• Uploads de fichiers auto-classés et routés vers les agents
• Mises à jour de progression via les modifications de messages
• Réactions pour un feedback rapide

5. Confidentialité et chiffrement zero-knowledge

Tes données sont chiffrées au repos — les clés API, les messages de chat et la configuration sensible sont protégés par le chiffrement AES-256-GCM. Les clés de récupération (format style 1Password) garantissent que tu ne perds jamais l'accès. Les en-têtes de sécurité (CSP, X-Frame-Options) et la désidentification PII dans les logs ajoutent une défense en profondeur.

6. Skills à la demande

Expertise portable chargée dynamiquement :

• handoff-protocol, code-review, system-audit, git-manager, project-onboarding
• Les skills correspondent aux déclencheurs de commandes
• Chargement à la demande, pas en permanence dans le contexte
• Jusqu'à 70% de réduction de la consommation de tokens en mode inactif

6. Mémoire infinie (NotebookLM Bridge)

Recherche sémantique réelle propulsée par Google NotebookLM — pas de correspondance par mots-clés :

• NotebookLM Bridge — service Python FastAPI (:19213) encapsule notebooklm-py
• Auto-sync — la fermeture/ouverture de tickets et les mises à jour wiki se synchronisent automatiquement vers Google
• Chat Cloud PM — l'outil ask_notebooklm interroge sémantiquement la connaissance du projet
• Fallback — recherche locale par mots-clés quand le bridge est indisponible
• Notebooks par projet — chaque projet obtient son propre notebook Google NotebookLM
• Le Bridge EST la mémoire persistante — Google gère le RAG gratuitement, précision 100%

7. Hooks de cycle de vie

Les hooks Claude Code synchronisent automatiquement l'état des agents sans intervention manuelle :

• SubagentStop → agent marqué inactif dans office-state.json → SSE → mise à jour de l'UI Phaser
• Stop → wrapup de session généré, tous les agents remis en inactif
• Les hooks SONT le liant — pas de polling, pas de cron, juste une synchronisation d'état event-driven

8. Blueprints de département

5 configurations pré-construites :

• Web : Rick dirige, Morty code, Summer révise
• GameDev : Summer dirige le design, Rick gère le moteur
• Debug : Rick triage, Morty débogue, Summer valide
• Legal : Beth dirige l'analyse, Summer révise
• Service : Rick dirige les opérations, Morty exécute

Pour qui c'est fait

• Développeurs solo qui ont besoin de sorties AI fiables sans surveiller chaque réponse
• Fondateurs techniques qui veulent une couche d'opérations AI qui passe à l'échelle
• Agences qui ont besoin de workspaces AI isolés et personnalisés par client
• Quiconque en a assez de copier des prompts entre onglets et de relire manuellement du code AI

9. Architecture de bots fédérée (Phase 20)

Gestion multi-projets via la fédération Master + Child bots :

• Master Bot — orchestrateur Telegram léger (pas AI) : /status, /health, /deploy, /new_project, /remove_project, /watchdog
• Child Bots — proxies Telegram ↔ Claude CLI par projet avec contexte isolé
• Onboarding — interview interactive → provisionnement automatique avec correspondance de skills
• Auto-guérison — le watchdog redémarre automatiquement les children crashés avec backoff exponentiel
• Vault chiffrée — stockage AES-256-GCM pour les tokens de bots (pas dans .env)
• Logging structuré — format JSONL, rotation quotidienne, compatible grep/jq

10. CRM Dashboard & Observabilité (Phase 22)

Gestion de projet en temps réel via le serveur HTTP Bun :

• REST API — 18 endpoints CRM : projets, logs, fichiers, skills, métriques, specs, rôles, messages, learnings, heartbeat
• Flux SSE — tail en direct des logs JSONL + sortie consultant
• Terminal WebSocket — capture-pane tmux avec couleurs ANSI + mode interactif
• Graphiques Sparkline — graphiques à barres canvas pour les timeseries succès/échecs
• Flux d'auth — email/mot de passe ou OAuth (Google, GitHub) → token JWT (TTL 24h)

11. Flux dual-agent (Phase 24.5)

Collaboration à deux rôles par projet :

• Consultant (Sonnet, read-only) — analyse, specs, propositions d'architecture via /c
• Developer (Opus, accès complet) — implémentation, déploiement via /d
• File de specs — extraites automatiquement depuis le pattern ### SPEC:, le CEO approuve/rejette
• Thème Slate & Silver — glassmorphisme sombre sur toute l'UI

12. Local Gateway Bridge (Phase 25)

Connecte l'IDE local à l'intelligence Arc OS :

• Bridge CLI (citadel-bridge) — connect, pull, push, status, disconnect
• Skills Sync — pull du bundle skills + evals depuis le CRM vers le projet local
• Learnings Sync — bidirectionnel : pull des corrections, push des découvertes locales
• CLAUDE.md Injection — contexte Arc OS automatique via les marqueurs <!-- CITADEL:START/END -->
• Heartbeat — rapport d'activité de session locale vers le CRM Dashboard

13. Knowledge Dashboard (Phase 32)

Gestion complète de la connaissance du projet :

• Feed de rapports — vue timeline, groupée par date, tags de source colorés
• CRUD de skills — éditeur split-pane pour les définitions de skills
• Éditeur Wiki — édition inline, sauvegarde, création de pages markdown
• NotebookLM — landing branded avec cartes de cas d'usage

14. Création de projet multi-tenant (Phase 33)

Création de workspace en self-service pour les utilisateurs récurrents :

• Paramètres du compte — clés API par utilisateur stockées de manière sécurisée (0o600)
• Modal Créer un projet — 3 champs (nom, niche, preset), pas besoin d'assistant complet
• Répertoires par utilisateur — /opt/repos/{chatId}_{projectName}/
• 10 helpers réutilisables — allocatePort, createProjectDirectories, generateClaudeMd, etc.

15. Chef de projet autonome (Phase 34)

8 outils MCP pour la gestion de projet sans les mains :

• CRUD de tickets — create_issue, list_issues, update_issue (P0-P3, labels)
• Wiki Sync — update_wiki crée/met à jour des pages markdown
• Moteur de roadmap — sync_roadmap avec remplacement de statut en place
• Init Injection — tickets ouverts + prochaine cible roadmap auto-injectés dans CLAUDE.md

16. Live Terminal Sync (Phase 35)

Stream de la sortie locale Claude Code vers le tableau de bord web en temps réel :

• Backend — POST /terminal/log reçoit des lignes JSONL, les ajoute aux fichiers de log
• ARC CLI — Bun.spawn avec pipe stdout, POST bufferisé 2s, strip ANSI
• Frontend — switcher d'onglets Bot/Live avec point vert pulsant pour les streams en direct

17. Cloud Project Manager (Phase 36)

Analyse de projet propulsée par AI via le tableau de bord web :

• Chat SSE — POST /api/crm/projects/:name/chat proxifie vers l'API Anthropic
• Boucle d'outils côté serveur — ask_notebooklm interroge sémantiquement wiki, tickets, roadmap
• NotebookLM Bridge — Python FastAPI avec recherche sémantique Google + auto-sync

18. Sage Worker + Skill Evolution (Phase 40.11)

Curation de skills basée sur les données avec benchmarking A/B optionnel :

• Sage (modèle Haiku) — analyse les brouillons de skills vs le registre, identifie les chevauchements et lacunes
• Demandes de mise à jour (PRs) — les humains révisent, approuvent/rejettent, auto-log de l'évolution
• Benchmarks A/B — exécuter des évaluations face-à-face sur des prompts réels avant de promouvoir une skill
• Découverte marketplace (Phase 40.12) — scanner claudemarketplaces.com, analyser la compatibilité via LLM, installation en un clic (global ou par projet)

19. Graphe de connaissances + Lien Obsidian (Phase 40.17)

• /api/crm/projects/:name/knowledge-graph — nœuds + arêtes depuis les liens wiki
• Graphe force-directed canvas sur le frontend (sans bibliothèque tierce)
• Bouton Ouvrir dans Obsidian sur chaque carte de mémoire neurale — accès direct au vault

20. Refonte UI — Adaptation du design Vercel (Phase 41)

Migration par étapes d'un design de référence Next.js généré par Vercel dans la stack React+Lingui+Vite existante. 8 sous-phases, zéro changement de framework :

• Tokens de design — espace colorimétrique OKLCH (teale profond primaire, ambre chaud accent, ivoire chaud surface), Inter + JetBrains Mono
• Pills de sélection de workers — pills horizontales avec avatars tone-ring (colorés par hash déterministe de l'id worker)
• Bulles de messages chat — inversé utilisateur (bg premier plan sombre), préfixe avatar-worker, coins arrondis asymétriques, barre d'action par message (Sauvegarder en note, Copier, 👍, 👎)
• Composer — switcher de modèle inline (Sonnet ↔ Opus), chip Outils avec badge de compte actif, chip d'insertion rapide /btw, dock d'actions en bas (/btw, Pause, Stop, Approve Last)
• Sidebar — badge de compte de tickets sur la nav, feed d'activité Live (top 3 événements de tickets, poll 30s), ping-pulse animé sur la mémoire neurale synchronisée
• TopBar — bouton Recherche avec hint kbd ⌘/Ctrl K aware de la plateforme (listener global le focus)
• Context Rail (nouveau) — panneau droit 320px, visible ≥1280px : Objectif actuel parsé de ROADMAP.md + métriques 2×2 (Tickets ouverts, Fermés/semaine, Bloqués, Skills) + liste des Skills actives + Épinglées depuis le fil + pied de page git-branch
• Notes épinglées (fonctionnalité backend) — migration 009 + POST/GET/DELETE /api/crm/projects/:name/pins. "Sauvegarder en note" dans le chat épingle maintenant le message dans le Context Rail au lieu d'écrire dans le wiki.

21. Hardening de sécurité (Phase 42)

Déclenché par l'audit de l'agent Sentinel le 2026-04-23. 13 correctifs de sécurité sur 4 passes d'audit indépendantes. Verdict : 🟢 VERT, prêt multi-utilisateurs.

• Garde multi-tenancy — canAccessProject(registry, chatId, project) sur chaque route protégée (SSE, terminal WebSocket, bloc CLI/MCP). Le terminal WS interactif nécessite CEO ou role=admin.
• Périmètre — Bun bind uniquement 127.0.0.1:19210 ; /api/internal/* rejette les en-têtes proxy (X-Forwarded-For/X-Real-IP/Forwarded) comme canari de mauvaise configuration nginx.
• Liste blanche SSRF — handleScoutAnalyze restreint le fetch sortant à https + hôte claudemarketplaces.com, redirect:"manual" bloque le contournement par chaîne de redirections.
• Chemins de token — extractChatId lit à la fois l'en-tête Bearer et le query ?token= (correspondance browser EventSource avec crmAuthMiddleware).
• Hardening — timingSafeEqual sur la signature JWT, audit safePath sur tous les handlers (fix traversal handleSaveSkill), liste de refus nginx étendue à config/+data/+knowledge-base/.
• Couverture de régression — scripts/vps-sync.sh exécute 7+ tests de fumée post-déploiement (bind loopback, path traversal, bloc SSRF, canari proxy, SSE ?token=, validation fail-closed, input chat/save).

Référence complète : docs/SECURITY.md, rapport d'audit : docs/security/audit-2026-04-23.md.

22. E2EE zero-knowledge (Phase 45)

Chiffrement côté client pour les données sensibles du workspace. Même les opérateurs Arc OS ne peuvent pas lire le contenu chiffré.

• Dérivation de clé maître — WebCrypto PBKDF2 (100k itérations) → clé AES-256-GCM mise en cache dans sessionStorage
• Clés de récupération — format style 1Password XXXX-XXXX-XXXX-XXXX-XXXX, backup de la clé maître chiffrée
• Chiffrement au repos — vault AES-256-GCM pour les clés API, colonnes SQLite chiffrées pour les messages de chat
• Défense en profondeur CSP — default-src 'self', X-Frame-Options: DENY, X-Content-Type-Options: nosniff
• Désidentificateur PII — censure les emails, clés API, JWT, numéros de carte des logs JSONL avant l'écriture sur disque

23. Timeline & Refonte des tickets (Phase 47)

Observabilité inspirée DAW et suivi de tickets groupés par phase.

• Timeline — lanes de workers, chips d'événements, contrôles mute/solo, tête de lecture scrubable. Rejoue la session d'un worker comme une console de mixage audio.
• IssuesRedesign (Phase 47.8) — table groupée par phase + panneau de détail coulissant, animation de pulsation P0, barres de progression, responsive mobile.

24. Décomposition d'architecture (Phase 48)

Refactorisation des monolithes en modules de domaine sans changer le comportement.

• Routeur CRM — crm-routes.ts (10 779 LOC) → shared/routes/router.ts (373 LOC) dispatchant vers 19 modules de domaine
• UI Workspace — Workspace.jsx (~2 000 LOC) → orchestrateur 168 lignes + 9 composants dans pages/workspace/
• Serveur API — master-bot/api-server.ts (196 lignes) délègue à master-bot/routes/{auth,internal,cli,websocket}.ts
• Phase 48.5 — inbox CRM event-driven via fs.watch (latence 100× plus faible que le polling 500ms)
• Phase 48.6 — cycle de vie lazy des workers : idle-kill + réveil à la demande, ~298 Mo RAM libérés (39%), capacité 2 → 6-10 utilisateurs concurrents

25. Application de la documentation (Phase 49.1)

Hook git pre-push (.githooks/pre-push → scripts/check-docs-coverage.ts) bloque les pushs qui changent du code sans mettre à jour les docs mappées.

26. Crédits d'essai + Facturation Stripe (Phases 50-51)

Monétisation self-serve par-dessus une base zéro coût.

• Crédits d'essai (Phase 50) — unique par email, conditionne la création d'un nouveau projet + accès à l'API Anthropic pour les plans payants
• subscriptions + stripe_events (migration 020) — ID client Stripe, niveau de plan, log d'idempotence
• PLAN_LIMITS — source de vérité unique pour le mapping plan → projets/workers/fonctionnalités
• checkPlanLimit(userId, action) — middleware sémantique OR retourne {allowed, reason, current, limit, plan}
• Niveaux de prix — Gratuit (1 projet / 5 workers), Min (4,99 $ — 5 OU 25), Max (11,99 $ — 20 OU 150)
• 402 Payment Required — erreur structurée sur handleOnboardingSetup + handleCreateWorker en cas de dépassement de limite

27. Lancement F&F Bêta (Phase 52.1)

Porte bêta fermée avant le lancement public — inscription sur invitation uniquement, boucle de feedback dédiée.

• Codes d'invitation — format arc-XXXX-XXXX (hex crypto.randomBytes), table invites (migration 021)
• Porte d'inscription — /api/auth/register nécessite invite_code, retourne 403 invite_required sinon
• Endpoints admin — POST/GET/DELETE /api/crm/admin/invites + ARC CLI arc invites generate/list/revoke
• Niveau de plan beta — illimité (Infinity projets/workers, toutes les fonctionnalités Max) sans octroyer le rôle admin
• Canal de feedback — @arcos_beta_feedback Telegram, digest hebdomadaire, 50% de réduction à vie + Founders Wall

28. Application de la discipline des tickets (#115 / #116 / #117, mai 2026)

"Chaque tâche = ticket enregistré + piste d'activité auditable" est la pierre angulaire de la promesse d'Arc OS. Les workers connaissaient la règle depuis CLAUDE.md mais rien dans le runtime ne l'appliquait — les projets accumulaient régulièrement des jours de sessions CLI complètes sans aucun ticket créé. Ce trio de trois tickets ferme la boucle de bout en bout.

#115 — binding runtime (CLI + Web + Telegram, les trois surfaces) :

• Picker au démarrage de session sur arc <project> — liste interactive des tickets ouverts (tri P0→P3 + récents en premier, filtre fuzzy quand >10), récemment fermés (avec confirmation de réouverture), [n] créer nouveau, [q] skip avec double confirmation. L'id sélectionné persiste dans ~/.arc/sessions/<project>-<worker>.json et est injecté comme variable d'environnement ARC_ACTIVE_ISSUE_ID dans le subprocess Claude + comme bloc Active issue: #N — Title dans CLAUDE.md pour que les workers auto-loguent en milieu de session.
• Modal Web Workspace reflète le flux CLI ; pill de ticket actif cliquable dans la barre workers permet à l'utilisateur de re-choisir à tout moment. Persiste via POST /api/crm/projects/:name/active-issue (écrit un événement activity_log session_active_issue).
• Suite Telegram /issue dans chaque child-bot — list, switch <id>, create <title>, close <id>, current.
• Hook de fin de session auto-logue une entrée session_end avec durée + nombre de commits + fichiers modifiés. Les tags étendent le flux d'activité par ticket : session_start / session_end / switched_in / switched_away / auto_summary / reopened.
• Cron d'audit nocturne signale les projets avec ≥5 événements d'activité mais zéro mise à jour de ticket en 24h et ping le propriétaire via le bot Telegram master.

#116 — application au moment du commit git : .githooks/commit-msg bloque tout commit manquant #<id> (ou closes #<n> / fixes #<n> / refs #<n> / resolves #<n> / (#<n>)) quelque part dans le message. Les trailers Co-Authored-By + Signed-off-by sont strippés en premier, donc les refs de trailer seul ne satisfont pas la règle. Les préfixes de maintenance (chore/docs/style/test/build/ci/refactor/perf), Merge / Revert / fixup! / [ci skip] passent proprement. Le message d'échec affiche l'id de session actif de l'utilisateur pour copier-coller. Contournement d'urgence : git commit --no-verify.

#117 — backfill rétroactif : arc retro <project> reconstruit les tickets depuis ~/.arc/sessions/<project>-*.json + transcriptions JSONLs + git log --since=started_at --until=ended_at. Déduplique via la similarité de titre Jaccard (≥0,55) croisée avec une fenêtre de chevauchement ±48h. Les entrées d'activité atterrissent aux timestamps originaux via le nouveau champ optionnel ts sur POST /api/mcp/issues/:project/:id/log (les valeurs futures se plafonnent à maintenant). L'ancien travail avec commits se ferme automatiquement ; les travaux récents non terminés restent ouverts. Dry-run par défaut, --apply crée.

Statut actuel

Phase 52.1 — Lancement F&F Bêta en cours. Lancement public conditionné aux critères de succès (≥70% inscription → first_message, ≥40% rétention Jour-1, ≥25% rétention Jour-7, 0 bugs P0 dans les 3 derniers jours).

• 6 agents, 5 blueprints, 15+ skills, ARC CLI (3 plateformes + 9 sous-commandes cloud), CRM Dashboard React avec Context Rail + Timeline + IssuesRedesign, frontend Phaser (legacy), fédération Telegram (Master + Children)
• 70+ endpoints CRM API sur 19 modules de domaine (auth, projets, workers, skills, sage, fichiers, wiki, chat, analytics, facturation, invitations, etc.), Bun HTTP bind sur 127.0.0.1
• Flux dual-agent, Workers dynamiques avec rechargement à chaud fsWatch + cycle de vie lazy, Bridge CLI, ARC CLI, Knowledge Dashboard, Chat Cloud PM, NotebookLM Bridge, Sage Worker + benchmarks A/B + Marketplace Discovery, Graphe de connaissances
• i18n EN/UK (438 chaînes), auth web (email + OAuth + réinitialisation de mot de passe + vérification email via Resend), projets multi-tenant avec owner_id SSOT, hooks de cycle de vie, watchdog avec backoff exponentiel, vault AES-256-GCM, watcher d'auto-ingestion
• Sécurité & confidentialité : JWT (timingSafeEqual), gardes multi-tenancy sur chaque route, liste blanche SSRF, bind loopback, E2EE zero-knowledge (PBKDF2 + AES-256-GCM, clés de récupération), en-têtes CSP/X-Frame, désidentificateur PII, tests de fumée de régression à chaque déploiement
• Monétisation : Crédits d'essai + Facturation Stripe Stage 1 (DB + middleware + statut), inscription gate invitation, niveau de plan bêta
• DX : Hook pre-push de couverture de docs, décomposition d'architecture Phase 48 (refactorisation monolithe 10 779 → 373 LOC)

Arc OS. Construit nativement sur Claude Code. Les agents font le travail. Google se souvient de tout.