Vue d'ensemble

Ce qu’est Nika OS

Nika OS est un proto-OS sémantique : un système d’exploitation agentique qui permet à n’importe qui d’interagir facilement avec un ordinateur — par voix, image, texte ou fichier — pour personnaliser sa vie, simplifier l’accès aux outils d’IA générative, faire de l’analyse de données en toute sécurité, et apprendre au passage.

Ce n’est pas un chatbot. Ce n’est pas une boîte à scripts. C’est un système qui :

• Orchestre des essaims d’agents (instances d’agents CLI compatibles MCP, appelées « pods ») via une couche d’inter-process communication temps réel.
• Persiste la connaissance dans une mémoire à trois niveaux : working memory, mémoire épisodique, mémoire sémantique.
• Évolue ses propres stratégies via des tournois d’optimisation par prompt (inspirés de la recherche GEPA, 2025) — sans muter son kernel.
• Route les requêtes vers le bon backend CLI selon coût, latence, qualité attendue et souveraineté.
• Comprend la voix, l’image, le texte, et les fichiers : on parle ou on envoie une photo via WhatsApp / Teams, le système identifie l’intention, applique la bonne pipeline, et répond dans le même format.
• Pilote un navigateur comme un humain (Chrome via CDP + Playwright) pour les services qui n’ont pas d’API : remplir un formulaire, consulter un site authentifié, extraire des données structurées, faire un achat, récupérer un document. Le navigateur est une primitive nécessaire — la plupart des SI internes n’exposent pas d’API officielle.
• Lance des jobs ML / IA à la demande sur GPU distants via SSH provisionné automatiquement — fine-tune d’un modèle d’embedding sur un corpus, entraînement d’un classifieur métier, benchmark comparatif, sans avoir à gérer l’infrastructure GPU soi-même.

Le « OS » est délibéré : on traite les agents comme des processus, la mémoire comme un système de fichiers, l’IPC comme un bus système, et les hooks comme des signaux POSIX.

Architecture en une image

flowchart TB
    U["👤 Utilisateur<br/>voix · texte · image · fichier"] --> A["🪆 Kernel<br/>orchestrateur"]
    H["⚙️ Hooks lifecycle"] -.->|SessionStart · PostToolUse · Stop| A
    A --> PA["Pod A"]
    A --> PB["Pod B"]
    A --> PC["Pod C"]
    PA --> M["🗄️ Mémoire sémantique<br/>Qdrant"]
    PB --> M
    PC --> M
    PA --> I["📡 IPC bus<br/>Redis Streams + JSONL"]
    PB --> I
    PC --> I
    I -.->|signaux| A
    M -.->|RAG retrieval| A

    classDef kernel fill:#E99971,stroke:#5E9384,color:#FDFBF8,stroke-width:2px;
    classDef pod fill:#F3EADE,stroke:#7DB5A5,color:#2C3E42,stroke-width:1.5px;
    classDef infra fill:#7DB5A5,stroke:#5E9384,color:#FDFBF8,stroke-width:2px;
    classDef hook fill:#FAF5EC,stroke:#A86640,color:#2C3E42,stroke-dasharray:4 3;
    classDef user fill:#2C3E42,stroke:#1A262A,color:#FDFBF8;
    class U user;
    class A kernel;
    class PA,PB,PC pod;
    class M,I infra;
    class H hook;

Pourquoi pas juste “ouvrir un terminal”

Les agents CLI sont le moyen le plus puissant d’exploiter les modèles de langage génératifs aujourd’hui : accès direct au shell, manipulation de fichiers, scripting, parallélisme, mémoire persistante, hooks de cycle de vie. Et pourtant, la plupart des utilisateurs métier — y compris des ingénieurs très compétents — n’utilisent pas ces outils.

Trois résistances reviennent :

1. Le terminal intimide — fond noir, prompt austère, pas de wizard. L’utilisateur ne sait pas par où commencer et craint de casser quelque chose.
2. L’onboarding est manuel — installer un runtime, configurer une clé API, comprendre l’arborescence de config de l’agent, écrire un premier prompt. Ça décourage avant même le premier résultat.
3. L’écosystème est fragmenté — chaque CLI a sa propre config, ses propres skills, son propre langage. Apprendre l’un ne sert pas pour l’autre. Décourageant pour qui veut comparer.

Nika OS est conçu pour faire disparaître ces trois obstacles :

• Le wizard d’installation enlève le terminal comme barrière. L’utilisateur ne touche jamais à un shell : tout passe par une page web d’install puis par WhatsApp ou Teams.
• Le packaging Docker self-contained installe en un clic tout l’écosystème (CLI + adaptateurs + Redis + Qdrant + Postgres + mesh Tailscale + bridges) sans demander à l’utilisateur de comprendre les dépendances.
• Le routing agnostique permet d’utiliser le CLI préféré et de basculer vers les autres sans réapprendre. La configuration est partagée entre toutes les CLI via le format YAML universel des primitives.

L’effet recherché : un utilisateur métier (chef d’atelier, qualiticien, acheteur, comptable) tape une question en français dans WhatsApp comme s’il parlait à un collègue. Derrière, Nika OS choisit le bon agent CLI, lui fournit la mémoire pertinente, observe son travail, valide le livrable, et renvoie la réponse. Le CLI redevient ce qu’il devrait être depuis le début : une primitive d’orchestration invisible, pas une barrière à franchir.

C’est ce déplacement qui transforme un CLI puissant mais réservé aux développeurs en outil d’opération utilisable par toute une équipe.

Pour qui ce site

Cette documentation décrit le fonctionnement interne de Nika OS pour trois publics :

• Ingénieurs IA / data qui veulent comprendre comment structurer des systèmes multi-agents en production.
• Chercheurs intéressés par l’application pratique de techniques récentes (GEPA, prompt evolution, contrôle probabiliste en ligne).
• Utilisateurs et intégrateurs qui veulent savoir ce qui tourne réellement derrière les livrables qu’ils obtiennent.

La documentation décrit le mécanisme — comment le système fonctionne — de façon intemporelle. L’état d’exécution courant (ce qui tourne, ce qui est en cours) vit dans les canaux de statut, pas dans cette doc.