Code source et ressources

Statut open source

Le kernel Nika OS lui-même est aujourd’hui un dépôt R&D privé. C’est une primitive de différenciation pour BCUB3 — elle reste fermée le temps que l’architecture stabilise et que les invariants de sécurité soient suffisamment éprouvés.

En parallèle, plusieurs composants utilitaires sont publiés progressivement en open source sur l’organisation Powwpol. La liste ci-dessous reflète l’état au 22 mai 2026.

Dépôts publics

Dépôt	Description	Licence
mempalace	Système de mémoire le mieux noté sur les benchmarks publics. Base théorique du PALACE PROTOCOL.	MIT
strauss-pilotage	Caissons paramétriques imprimables 3D pour pilotage IR + capteurs T°/HR (ESP32, ESP-NOW). CAO FreeCAD.	MIT
datagouv-skill	Skill officielle pour interagir avec le portail data.gouv.fr depuis un agent LLM.	MIT
datagouv_client	Wrapper Python de l’API data.gouv.fr.	MIT
csv-detective	Inspection automatique de fichiers tabulaires (csv, xls-like) pour deviner le contenu des colonnes.	MIT
api-meteo	Wrapper d’API météo agnostique du provider.	MIT
fr-format	Validation de chaînes au format français (SIRET, IBAN, code postal, etc.).	MIT
ui-ux-pro-max-skill	Skill qui apporte de l’intelligence design pour la construction d’interfaces UI/UX.	MIT
chrome-devtools-mcp	MCP server pour piloter Chrome DevTools depuis un agent.	MIT
bcub3-site	Le site sur lequel vous lisez cette documentation. Astro, statique, déployé sur GitHub Pages.	MIT

Composants privés

Les composants suivants restent privés. Cette section les liste pour documenter ce qui existe dans le système, sans donner accès au code.

Composant	Pourquoi privé
nika-os	Kernel principal. R&D active, primitive de différenciation.
nika-os-core / nika-os-private	Couches privées du kernel : routing, GEPA tournament engine.
Nika	Code historique pré-kernel, archivé pour traçabilité.
nika-agent / nika-kernel / nika-memory	Runtime alternatif (autre CLI) et sa mémoire dédiée.
nika-system-inventory	Inventaire de l’infrastructure (secrets, IPs, services).
nika-backups-dr	Backups disaster-recovery chiffrés en age.
Linkedin_mcp	MCP server LinkedIn, contient des credentials embarqués.
qonto-mcp-server	MCP server bancaire, contient des credentials embarqués.

Brevets et publications

Trois brevets ont été déposés à l’INPI par Paul Obara :

Code	Date dépôt	Domaine
sWELU (FR2513029)	2026	Fonction d’activation neuronale pour petits modèles
KTW B1	2026-01-08	Pilotage industriel prédictif Kelly + Weibull
KTW B2	2026-01-08	Pilotage probabiliste en boucle fermée + recadrage dynamique des consignes

Les brevets sont décrits en termes accessibles (sans formule) sur la page principale du Lab. Cette documentation Nika OS suppose que le lecteur a déjà parcouru ces présentations grand-public.

Références externes

Les travaux ci-dessous ont inspiré directement l’architecture de Nika OS. Cette section les liste pour permettre une lecture critique du système.

• GEPA: Genetic-Pareto evolution for prompt optimization (2025) — méthode d’évolution dirigée de prompts utilisée pour le harnais.
• Kelly J.L., A New Interpretation of Information Rate (1956) — formule de Kelly originale, appliquée ici au dosage de correction.
• Taguchi G., Quality Loss Function (1989) — fonction de perte quadratique utilisée pour traduire un écart de mesure en coût.
• Weibull W., A Statistical Distribution Function of Wide Applicability (1951) — distribution utilisée pour estimer si un écart est une dérive.
• Taleb N., Antifragile (2012) — cadre conceptuel pour la doctrine 1.
• Model Context Protocol (modelcontextprotocol.io) — protocole utilisé par tous les MCP servers.

Comment contribuer

Les composants publics acceptent les contributions externes selon le workflow GitHub standard :

1. Ouvrir une issue pour discuter du changement avant d’écrire du code.
2. Forker, brancher (feat/... ou fix/...), faire des commits atomiques.
3. PR vers main avec description claire de la motivation.

Les PRs qui touchent des invariants kernel (sécurité, brand, doctrines) nécessitent une validation humaine explicite. Les PRs purement utilitaires (typos, doc fixes, ajouts de tests) sont mergées rapidement.

Pour toute question architecture ou intégration BCUB3 : info@bcub3.com.

Open source vs config personnalisée — la difficulté de la publication

Une question revient régulièrement : pourquoi le kernel Nika OS reste-t-il privé alors que tant de composants utilitaires sont publiés ? La réponse tient en une phrase : ce qui tourne réellement aujourd’hui est profondément personnalisé.

L’instance Nika OS qui orchestre le travail quotidien chez BCUB3 connaît :

• Les clients (clés API qonto, identifiants SharePoint, comptes Microsoft 365 tenant-specific).
• Les conventions internes (codes de chantier, références projets, noms de membres d’équipe, processus métier).
• Les préférences de l’opérateur (CLI préféré, ton de communication, fuseaux horaires, doctrines GEPA accumulées).
• Les credentials chiffrés vers une dizaine d’APIs tierces.

Publier ce kernel en l’état serait à la fois inutile (personne d’autre n’a la même config) et dangereux (fuite de données).

Ce que la version open source doit fournir

Pour qu’un nouvel utilisateur installe Nika OS et l’utilise réellement, le release public doit séparer deux couches de kernel et la config :

1. Le kernel personnel de Paul (BCUB3) — l’instance opérationnelle qui tourne ici, accumulée par 6+ mois d’usage, profondément personnalisée avec les clients, les conventions, les credentials, les mutations GEPA accumulées. Reste privé, ne sera jamais publié en l’état.

2. Le kernel de base agnostic — orchestrateur, primitives (skills, hooks, MCP, memory, IPC), router multi-CLI, GEPA tournament engine, KTW controller. Tout ce qui est commun à tous les utilisateurs. Publié progressivement après stabilisation.

   Particularité : ce kernel est vivant. Dès qu’un nouvel utilisateur l’installe et l’utilise, ses traces opérationnelles anonymisées peuvent alimenter une boucle d’amélioration commune (avec son consentement explicite via le wizard). Les patterns récurrents, les mutations GEPA utiles, les skills demandées par plusieurs tenants : tout ce qui est réutilisable cross-tenant enrichit progressivement le kernel agnostic.

3. La config tenant-spécifique — vide à l’install, remplie par le wizard via OAuth et entrée d’API keys. Chaque utilisateur construit sa propre couche personnalisée, jamais publiée.

Cycle d’amélioration du kernel agnostic

flowchart LR
    P["🪆 Paul (BCUB3)<br/>kernel personnel"] -.->|"primitives utiles<br/>extraites + anonymisées"| K["🌱 Kernel agnostic<br/>open source"]
    U1["👤 Tenant 1"] -->|"installe + use"| K
    U2["👤 Tenant 2"] -->|"installe + use"| K
    UN["👤 Tenant N"] -->|"installe + use"| K
    U1 -.->|"patterns / mutations<br/>avec consentement"| K
    U2 -.->|"patterns / mutations<br/>avec consentement"| K
    UN -.->|"patterns / mutations<br/>avec consentement"| K
    K -->|"v0.2, v0.3, …<br/>publication versionnée"| GH["📦 Powwpol/nika-os<br/>(public progressivement)"]

    classDef perso fill:#E99971,color:#FDFBF8,stroke:#C97A55;
    classDef tenant fill:#F3EADE,color:#2C3E42,stroke:#7DB5A5;
    classDef kernel fill:#7DB5A5,color:#FDFBF8,stroke:#5E9384,stroke-width:2px;
    classDef repo fill:#2C3E42,color:#FDFBF8,stroke:#1A262A;
    class P perso;
    class U1,U2,UN tenant;
    class K kernel;
    class GH repo;

Cet enrichissement collectif est strictement opt-in : aucune donnée utilisateur ne quitte son tenant sans consentement explicite. Ce qui remonte vers le kernel agnostic, c’est uniquement :

• Des patterns architecturaux (e.g. “10 % des tenants spawn un pod freecad → mérite skill native”).
• Des mutations GEPA validées qui améliorent un prompt sans révéler le contexte privé du tenant.
• Des bugs / améliorations signalés via issues GitHub.
• Des MCP servers que des tenants ont créés via mcp-builder et veulent partager (eg. un wrapper API d’un service publique).

Cette architecture kernel personnel ↔ kernel agnostic enrichi par la communauté est la voie pour que Nika OS reste utile à BCUB3 tout en devenant un produit que d’autres peuvent adopter et faire évoluer ensemble.

Le 1-click pour connecter le SI utilisateur

L’enjeu opérationnel de l’open source est donc : comment un utilisateur qui n’a pas notre config arrive-t-il à brancher son propre SI à Nika OS en quelques clics ? La réponse repose sur deux primitives existantes, exposées dans le wizard d’install :

Cas	Primitive	Action utilisateur
API du SI supporte OAuth	oauth-mcp-builder	Cliquer “Connecter [Google / Microsoft / GitHub / etc.]” → consent OAuth → MCP server généré + skill compagnon optionnelle
API du SI a une clé API	apikey-mcp-builder	Coller la clé dans le wizard (chiffrée age) → wrapper Python généré + endpoints exposés en outils MCP
SI custom sans API documentée	api-to-mcp (mcp-builder)	Pointer le wizard vers la doc (URL, fichier OpenAPI, README markdown) → Opus / Mistral génère le wrapper MCP en quelques minutes

Dans les trois cas, le résultat est le même : un MCP server fonctionnel, chargé dans le kernel sans redémarrage, immédiatement utilisable depuis les pods. Le wizard préserve aussi l’idempotence — relancer le wizard sur un tenant existant ajoute / met à jour les MCPs sans casser la config en cours.

Roadmap publication

Composant	Statut publication	Pourquoi
Kernel générique (orchestrateur + primitives)	À publier après stabilisation	Couche utile à tout utilisateur
oauth-mcp-builder + apikey-mcp-builder	À publier en parallèle du kernel	Sans ça, kernel inutile pour un tiers
Adaptateurs CLI (Claude/Mistral/Gemini/Hermes)	Publié progressivement	Utile pour la communauté CLI
Skills (dataviz, freecad-pilot, harvest-linkedin, etc.)	Publiées au cas par cas	Pas toujours pertinent hors BCUB3
Wizard install (page web + flow OAuth)	Publié en même temps que le kernel	Cœur de la promesse “1-click”
Config tenant (clés API, doctrines GEPA accumulées, mémoire)	Jamais	Données personnelles
Brevets KTW / sWELU (algos as tools)	Articles + démos publiques	Le contenu mathématique est publié, l’implémentation propriétaire reste interne

Cette séparation est la pré-condition pour passer Nika OS d’un outil interne BCUB3 à un produit utilisable par d’autres sans renoncer à la sécurité ni à la valeur des invariants propriétaires.