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 (Claude Code / Mistral Vibe / Gemini CLI / Hermes Agent) 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 (RunPod, Google Cloud, Microsoft Azure, AWS) via SSH provisionné automatiquement — fine-tune d’un modèle d’embedding sur votre corpus, entraînement d’un classifieur métier, benchmark comparatif, sans avoir à gérer l’infrastructure GPU vous-même.

BCUB3 utilise Nika OS pour automatiser le travail intellectuel de l’atelier industriel ; le même système est conçu dès le départ pour des usages plus larges (admin, finance personnelle, apprentissage, recherche). PA —> M[“🗄️ Mémoire sémantique
Qdrant”] PB —> M PC —> M PA —> I[”📡 IPC bus
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;

<<<<<<< HEAD


## Pourquoi pas juste "ouvrir un terminal"

Les agents CLI (Claude Code, Mistral Vibe, Gemini CLI, Hermes Agent) 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 Node.js / Python, configurer une
   clé API, comprendre les fichiers `~/.claude/`, é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 industrielle utilisable par toute une
équipe*.
=======
>>>>>>> origin/main


## Pourquoi pas juste "ouvrir un terminal"

Les agents CLI (Claude Code, Mistral Vibe, Gemini CLI, Hermes Agent) 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 Node.js / Python, configurer une
   clé API, comprendre les fichiers `~/.claude/`, é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 industrielle utilisable par toute une
équipe*.


## Pourquoi pas juste "ouvrir un terminal"

Les agents CLI (Claude Code, Mistral Vibe, Gemini CLI, Hermes Agent) 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 Node.js / Python, configurer une
   clé API, comprendre les fichiers `~/.claude/`, é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 industrielle 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 nous structurons les
  systèmes multi-agents en production.
- **Chercheurs** intéressés par l'application pratique de techniques récentes
  (GEPA, prompt evolution, Kelly–Taguchi–Weibull control).
- **Clients industriels BCUB3** qui veulent savoir ce qui tourne réellement
  derrière les livrables que nous leur fournissons.

## Statut

Nika OS est un projet R&D actif. Le kernel n'est pas open source à date — c'est
une primitive de différenciation pour BCUB3. Des composants utilitaires
(skills, MCP servers, didacticiels, fonctions d'activation neuronales) sont
publiés progressivement sur [github.com/Powwpol](https://github.com/Powwpol)
en MIT.

Cette documentation reflète l'état au **22 mai 2026**.


## Maintenant vs Plus tard — séparer ce qui tourne de ce qui est prévu

Une dernière note pour le lecteur : cette documentation décrit
**ce qui tourne réellement aujourd'hui** chez BCUB3, *plus* des éléments
de roadmap qui sont conceptuellement clairs mais pas encore implémentés
de bout en bout. Pour éviter toute confusion :

### Aujourd'hui — opérationnel chez BCUB3

- Kernel + 1 backend (Claude Code) + ~50 pods en parallèle dans tmux.
- Mémoire 3 niveaux (working + episodic Qdrant ~360k pts + semantic).
- IPC Redis Streams + bus JSONL.
- Skills (~24) + hooks (~16) + MCP servers (~22).
- WhatsApp Business comme gateway principal (bridge Baileys port 3300).
- Navigateur Chrome CDP + Playwright pour la navigation web.
- Cron (~50 entrées) pour orchestration récurrente + observabilité.
- Brevets KTW B1/B2 + sWELU déposés à l'INPI.

### Prévu — roadmap court terme (T+1 à T+6 mois)

- Tournament multi-CLI complet (Claude + Mistral Vibe + Gemini CLI + Hermes).
- Méta-pod déterministe pour LLM-as-judge sur livrables customer-facing.
- Auto-scale horizontal multi-cloud (Scaleway + Contabo + GCP + Azure + AWS).
- Stratégie A — compression vers repo lisible par humain et nouveau kernel.
- Multi-tenant avec 1 tmux par tenant.
- Continuous training d'un modèle propriétaire d'embeddings.
- Microsoft Teams + Google Chat gateways en complément de WhatsApp.

### Vision — plus loin (T+6 à T+18 mois)

- Wizard d'install 1-click déployable par un tiers (publication open source).
- Marketplace de skills et de MCP servers.
- Modèles d'embeddings fine-tunés par tenant et déployés sur GPU
  propriétaire en edge.
- Récursion fractale complète (kernels-of-kernels, pods-of-pods).
- Adoption en intégration industrielle B2B par d'autres entreprises.

Cette séparation est faite explicitement pour éviter de mélanger
**ce que vous pouvez raisonnablement utiliser dès maintenant** avec
**ce vers quoi Nika OS tend**. Les deux ont leur place dans cette
documentation, mais ne doivent pas être confondus.