MCP et schedule

Deux primitives qui étendent le périmètre fonctionnel de Nika OS au-delà de l'agent CLI : les MCP servers (outils externes), les triggers (déclenchement temporel).

Mis à jour · 22 mai 2026

MCP : Model Context Protocol

Le Model Context Protocol est un protocole standardisé par Anthropic en 2024 pour exposer des outils externes à un modèle de langage. Chaque MCP server est un processus indépendant qui :

déclare une liste d’outils avec leur schema JSON ;
communique avec l’agent CLI via stdio (stdin/stdout) ou HTTP ;
expose éventuellement des resources (fichiers, bases de données).

Nika OS utilise 22 MCP servers configurés dans ~/.mcp.json. Quelques exemples :

Server	Rôle
`qdrant`	Recherche et écriture dans le vector store `nika_vault`
`nika-mcp`	Kernel maison : spawn de pods, bus, RAG, tournois
`playwright`	Automation de navigateur headless
`runpod`	Dispatch de jobs GPU à la demande
`grafana`	Lecture des dashboards monitoring
`datagouv`	API ouverte des données du gouvernement français
`mcp-builder`	Génère un nouveau MCP server depuis une doc d’API (OAuth-compatible si scopes fournis)

Exemples concrets d’usage par catégorie

Quelques workflows opérationnels (par catégorie de tool, sans noms de clients) :

Catégorie	Tools MCP	Workflow type
Mail	`gmail`, `outlook`	Envoyer, lire, classifier, résumer un fil, indexer dans le RAG
Banque / fintech	`mcp-banking` (OAuth API)	Lister les transactions, exporter les relevés mensuels, créer un devis ou une facture
CAO / 3D	`freecad-pilot`, `techdraw-fab-drawings`	Générer une pièce paramétrée, exporter STL/STEP, produire un plan technique normé ISO
Drive / Storage	`drive` (Google), `sharepoint` (M365)	Sync, ingest multimodal (PDF + images), search semantic
Calendar	`google-calendar`, `outlook-calendar`	Lister événements, proposer créneau, créer un rendez-vous
Web / scraping	`playwright`, `chrome-cdp`	Naviguer un site auth, extraire, automatiser un flow
GPU compute	`runpod`	Dispatcher un fine-tune ou un benchmark, killer le pod à la fin
Monitoring	`grafana`, `qdrant`	Lire dashboards, requêter le vecteur store

Pourquoi MCP plutôt que des plugins maison

Trois raisons :

Interopérabilité — un MCP server écrit pour un agent CLI compatible marche aussi avec d’autres clients qui parlent MCP. Le coût d’implémentation est mutualisé.
Sécurité par défaut — chaque MCP server tourne dans son propre processus, avec ses propres credentials. La surface d’attaque est contenue.
Hot-swap — on peut activer ou désactiver un MCP server sans redémarrer l’agent. Utile pour isoler un bug ou tester une nouvelle intégration.

Le pattern serveur-skill

Plusieurs MCP servers sont accompagnés d’une skill qui sait comment les utiliser. Exemple générique : un serveur bas niveau mcp-foo-api (expose les endpoints REST bruts d’une API tierce) est associé à une skill foo-workflow (haut niveau, sait quand appeler quel endpoint pour produire un rapport métier). Le serveur reste réutilisable, la skill encode la logique métier.

Cette séparation respecte le principe Unix : un outil par responsabilité. Le serveur sait comment parler à l’API. La skill sait quand l’appeler.

Créer un MCP server depuis une API (avec OAuth)

Nika OS inclut une skill mcp-builder qui automatise la création d’un nouveau serveur MCP à partir d’une documentation d’API (OpenAPI, README, ou markdown arbitraire). Le générateur produit :

Un wrapper Python qui expose les endpoints comme outils MCP (@tool).
Un flow OAuth 2.0 si l’API utilise OAuth (PKCE par défaut), avec stockage chiffré du refresh token dans ~/.config/nika-os/credentials/ et rotation automatique avant expiration.
Un manifeste déclaratif (mcp.toml) listant les scopes, rate limits, et permissions par tool.
Une skill compagnon optionnelle qui encode les workflows fréquents (e.g. “sync hebdomadaire”, “rapport mensuel”) pour ne pas re-spécifier la logique à chaque session.

Le pattern permet d’industrialiser l’intégration d’une nouvelle API en quelques minutes : doc en entrée, serveur MCP utilisable en sortie, sans duplication entre les CLI backends (Claude Code / Mistral Vibe / Gemini CLI).

Pods exposés comme serveurs (N agents concurrents)

Un pod Nika OS n’est pas seulement un worker éphémère. Il peut être exposé comme un serveur (port local + token éphémère) pour permettre à N agents concurrents (humains ou autres pods, ou même CLI tierces) de :

Lire son état en temps réel (transcript, RAG retrieval, working memory).
Lui envoyer des directives sans redémarrer la session.
Voter sur ses propositions (tournoi multi-pods sur la même tâche).
Re-router ses messages vers un autre backend en cas de quota épuisé.

Cette exposition transforme un pod en primitive composable : un agent devient une ressource adressable depuis n’importe où dans le mesh Tailscale privé, avec des contrats d’accès explicites (lecture / écriture / kill / re- adjuste). Plusieurs sessions d’agents peuvent ainsi collaborer sur le même objectif sans se piétiner, et un méta-orchestrateur peut arbitrer entre elles en lisant leurs états respectifs.

Schedule : déclencheurs temporels

Le routeur de Nika OS transforme automatiquement une demande récurrente en trigger schedule. C’est une décision de routing au même niveau que spawn_pod. Quand le router classifie une intention comme query_class=cron, il invoque l’un des trois backends.

Les trois backends

Backend	Persistence	Accès local	Quand l’utiliser
Remote Triggers	Oui (cloud)	Via bridge env	Tasks avec connectors (Gmail, Calendar, etc.)
CronCreate	Non (session)	Oui	Polling rapide, reminders dans la session
Crontab OS	Oui	Oui	Scripts infra (health, oauth, compaction)

Remote Triggers : la couche cloud persistante

Les Remote Triggers sont créés via l’API /v1/code/triggers d’Anthropic. Ils continuent à tourner même quand aucun pod n’est ouvert. Le déclenchement se fait par cron (UTC, à convertir depuis Europe/Paris) avec un intervalle minimum de 1 heure.

RemoteTrigger(
    action="create",
    body={
        "name": "morning-brief",
        "cron_expression": "0 5 * * *",  # 7h Paris l'hiver, 6h UTC l'été
        "job_config": {...},
        "mcp_connections": ["gmail", "calendar"],
    },
)

Le trigger spawne un pod agent (CLI compatible MCP) au moment T avec les connectors MCP demandés et le brief en job_config. Le pod tourne, produit son livrable, notifie via les canaux configurés, et se kill.

CronCreate : la couche session

Quand le besoin est ponctuel (polling pour vérifier qu’un build CI est passé, reminder à 14h dans la session courante), CronCreate crée un cron à la session. Il disparaît quand le pod termine.

C’est la primitive utilisée par les skills verify, loop, et par les pods qui doivent attendre un événement externe sans bloquer leur boucle principale.

Crontab OS : la couche infra

Pour les scripts infra qui n’ont pas besoin de la boucle agent (rotation de logs, health checks, oauth refresh, compaction de bases), Nika utilise crontab classique de Linux. C’est la couche la plus basique et la plus fiable.

Le code de ces scripts vit dans scripts/cron_jobs/. Tous loguent en JSONL dans logs/cron/ pour respecter le pattern d’auditabilité.

Une décision de routing, pas une config statique

Important : ces trois backends ne sont pas hardcodés. Le routeur on_user_prompt.py regarde la demande, et choisit le backend approprié au runtime. Une demande comme « tous les matins envoie-moi un brief de mes mails » sera routée vers un Remote Trigger. Une demande comme « vérifie toutes les 2 minutes que le pod X a fini » sera routée vers un CronCreate.

Cette dynamique de routing est ce qui permet au système de transformer une intention utilisateur en primitive opérationnelle sans intervention humaine.

Capacités multimodales : voix, vision, gateways

Nika OS ne se limite pas au texte. Plusieurs primitives de la couche multimodale ouvrent l’interface au-delà du terminal :

Voix (Text-to-Speech + Speech-to-Text)

TTS via Vertex AI Gemini 2.5 Flash TTS (voix Kore par défaut) ou OpenAI TTS. Une réponse texte est synthétisée en .ogg Opus et renvoyée comme voice note WhatsApp ou message vocal Teams. Latence ~2-4s pour un message de 30 secondes.
STT via Whisper local (CPU) ou Vertex Speech-to-Text. Les messages vocaux reçus sont transcrits avant d’entrer dans la pipeline texte standard.
Heuristique : si l’utilisateur envoie un vocal, on répond en vocal (avec un fallback texte en parallèle pour les recherches).

Vision (yeux de l’agent) — analyse d’image poussée

Image input simple — n’importe quel pod peut lire une image (PDF, screenshot, photo de produit, plan technique) via les modèles multimodaux natifs (Claude vision, Gemini vision, OpenAI vision selon backend choisi par le router).
Analyse d’image avancée — pipeline en plusieurs passes :
1. OCR haute fidélité via DeepSeek OCR hébergé sur GPU privé (multilingue, reconnaissance plan technique + texte manuscrit).
2. Layout parsing des PDF complexes (Docling, LayoutParser) — extrait tableaux, figures, légendes, hiérarchie de titres en JSON structuré.
3. Détection d’éléments métier (cotes mécaniques sur plan, valeurs sur cadran, codes-barres, signatures) via modèles spécialisés.
4. Vision multimodale (Gemini 2.5 Pro / Claude vision) pour la compréhension sémantique : “que voit-on ? quel est l’état du procédé ?”.
5. Cross-check texte ↔ image — un fait extrait du texte est confronté à ce qui est visible sur l’image (détection d’incohérence).
RAG multimodal — Qdrant stocke en parallèle deux collections : nika_vault (texte, embedding 384d) et nika_multimodal (images + extraits structurés, embedding Vertex 1408d). Une question peut retrouver une image pertinente même si la requête est textuelle.
Génération d’images via Vertex Imagen ou modèles spécialisés exposés via RunPod (par exemple un fine-tune logo).

Gateways de messagerie

Pour qu’un pod puisse interagir avec un humain sans terminal :

WhatsApp Business — bridge Baileys local + dispatcher Redis. Le message reçu déclenche un UserPromptSubmit synthétique sur le kernel cible. Réponse renvoyée via POST /send (texte ou média).
Microsoft Teams — Graph API delegated OAuth. Le bot écoute les @mentions dans les canaux autorisés, route vers le kernel, retourne la réponse en adaptive card riche.
Google Chat — Chat API webhook + bot account configurable, même pattern que Teams.

Wizard d’installation 1-click

L’installation d’un nouveau tenant Nika OS suit un flow détaillé en 7 étapes :

Choix du CLI préféré — l’utilisateur sélectionne son agent CLI par défaut (Claude Code / Mistral Vibe / Gemini CLI / Hermes Agent). C’est le premier backend que Nika OS appelle pour ses prompts.
Configuration du fallback chain — ordre des backends de repli en cas d’usage limit ou de quota épuisé sur le préféré. Par défaut : [préféré] → Mistral Vibe → Gemini CLI → Hermes. L’utilisateur peut réordonner. Détecteur automatique d’usage-limit (regex sur stdout) qui bascule de manière transparente.
Gateways de messagerie — OAuth en un clic :
- WhatsApp Business : scan QR pour relier le bridge Baileys.
- Microsoft Teams : OAuth Graph API delegated, multi-tenant.
- Google Chat (optionnel) : Chat API webhook.
Inventaire des outils utilisés — wizard demande quels outils l’utilisateur souhaite intégrer (Drive, Calendar, Gmail, Outlook, SharePoint, Qonto, GitHub, LinkedIn, etc.). Pour chacun, OAuth en un clic si le provider le supporte (Famille A/B/C ci-dessus), sinon clé API demandée. Génération automatique des MCP servers correspondants.
Setup voix + vision — entrée API key Vertex (Gemini 2.5 Flash TTS + STT) ou clé Whisper local. Activation RAG multimodal (Qdrant collection nika_multimodal 1408d Vertex). Test smoke : envoi d’un message vocal test → transcription → réponse vocale.

5bis. Configuration multi-cloud (facultatif) — pour les utilisateurs qui veulent lancer des jobs ML / IA à la demande ou activer l’auto-scaling horizontal de Nika OS. Le wizard propose des clés API pour les providers suivants :

Scaleway — VPS souverain EU, GPU L4 / H100, idéal pour la conformité RGPD.
Contabo — VPS haute RAM / CPU à coût mensuel faible, point d’entrée standard.
Microsoft Azure — Compute + ML Compute (NDv4, NC, NDm), intégration Active Directory tenant.
Google Cloud — Vertex AI + Compute Engine (A100, L4, TPU si projet éligible).
AWS — EC2 spot + SageMaker (p4d, g5, inf2).
RunPod — GPU spot ou serverless, facturé à la minute.

La connexion se fait par clé SSH générée localement et copiée dans le provider via leur API officielle. Le wizard teste ensuite que nvidia-smi répond depuis le pod déclenchant. Une fois configuré, le skill runpod (et ses équivalents par provider) peut dispatcher un job en une commande.

Cette étape est facultative : un tenant qui n’a pas besoin de compute lourd peut la sauter et l’activer plus tard depuis l’UI.

Auto-scale horizontal — si plusieurs providers sont configurés, le scheduler Nika OS peut spawner automatiquement un VPS worker quand la charge dépasse un seuil (CPU > 80 % / RAM > 75 % / queue Redis > N tâches). Le worker rejoint le mesh Tailscale, télécharge l’image Nika OS, draine la queue, puis se decommissionne quand la charge redescend. Les bascules d’un provider à un autre se font en fonction du coût et de la disponibilité — Scaleway et Contabo pour le base load EU, RunPod ou GCP pour les pics GPU.

Cas d’usage clé : continuous training d’un modèle propriétaire d’embeddings + retrieval pour Nika OS. Plutôt que de dépendre d’un modèle d’embeddings externe (baseline bge-small-en-v1.5 384d), le tenant peut entraîner périodiquement son propre modèle sur le corpus Qdrant nika_vault qui lui est propre. Le pipeline :

Dataset builder — pull périodique de paires (query, document pertinent) depuis l’historique des sessions et l’audit JSONL.
Hard negatives — génération par BM25 + adversarial LLM.
Fine-tune — LoRA / QLoRA sur 1-3 epochs (3-8 heures de GPU A100).
Eval — NDCG@10, MRR, Recall@10 vs baseline ; déploiement si gain significatif (>5 %).
Migration zero-downtime — re-embedding incrémental de Qdrant via la skill qdrant-model-migration, sans interruption du retrieval.
Boucle — un cron hebdomadaire ou mensuel relance le pipeline.

L’effet : la qualité du retrieval augmente progressivement au fur et à mesure que le tenant utilise Nika OS, parce que le modèle d’embeddings apprend la sémantique propre de son métier.

Provisioning de l’instance — pod K3s dédié OR shared instance, avec quotas par tenant. Le wizard package toutes les dépendances dans une image Docker self-contained :
- Agent CLI choisi + adaptateurs des autres
- Redis 7 + Qdrant (pré-rempli avec doctrines + skills publics)
- PostgreSQL + pgvector (état hierarchy)
- Tailscale client pour rejoindre le mesh privé
- Bridge WhatsApp Baileys
- Tous les MCP servers de l’étape 4
- Modèles embedding fastembed bge-small en local
Une seule commande nika-install.sh orchestre le tout, démarre les services dans l’ordre, vérifie les healthchecks.

6bis. Ingestion 1-click de la documentation personnelle — avant le chatbot d’onboarding, le wizard demande à l’utilisateur quelques infos de profil (nom, rôle, secteur d’activité, langue préférée, contexte métier en quelques phrases). Sur cette base, il propose une ingestion guidée de la documentation personnelle ou professionnelle :

Connexion Tailscale SSH guidée — le wizard ouvre une page avec un identifiant Tailscale auth-key éphémère + une commande à coller dans un terminal local (Mac, Linux, Windows via WSL). Une fois exécutée, le poste de l’utilisateur rejoint le mesh privé du tenant.
Transfert simplifié — l’utilisateur glisse-dépose ses dossiers (Documents, Drive local, exports d’outils SaaS, anciens PDFs, photos de plans, fichiers Excel) dans une UI web servie par Nika OS via Tailscale. Aucune donnée ne transite par Internet ouvert.
Pipeline d’ingestion — Nika OS détecte le type (PDF, image, docx, xlsx, txt, eml, jsonl), applique la bonne pipeline (OCR, parsing layout, extraction tableaux), tag avec metadata (tenant_id, scope, entity_type, language, domain), embed via le modèle d’embeddings courant, et insère dans Qdrant nika_vault filtré par tenant.
Validation — un résumé est présenté avec : nombre de documents ingérés, taille, distribution des thèmes détectés. L’utilisateur valide ou rejette.

L’effet : dès le premier prompt à Nika OS, le RAG contient déjà la connaissance propre du tenant. Pas besoin de 10 sessions conversationnelles pour que Nika devienne utile — il connaît votre contexte tout de suite.

Cette étape est facultative mais fortement recommandée pour les usages métier (admin, finance, R&D, support). Pour un usage purement conversationnel (chat général), on peut sauter.

Onboarding chatbot — via WhatsApp ou Teams, un assistant guide l’utilisateur pour ses 10 premiers prompts (présenter sa stack métier, ses préférences, ses pain points). Tout est mémorisé dans le RAG dès le début, ce qui rend les sessions suivantes immédiatement contextuelles.

Let’s go — minimum viable install

Pour un POC rapide, le minimum fonctionnel est :

Étape	Minimum
CLI	1 (le préféré) — fallback optionnel
OAuth	Google OU Microsoft (au moins 1)
Gateway	WhatsApp OU Teams (au moins 1)
Voix	Optionnel — texte seul OK pour démarrer
Vision	Optionnel — peut être activé après
Tools	Drive + Calendar + Gmail = 90% des usages courants
RAG	Qdrant pré-chargé avec doctrines publiques

→ ~15 minutes du clic “Installer” au premier prompt fonctionnel.

Toute la stack de gateway s’appuie sur les adaptateurs CLI (Claude Code, Mistral Vibe, Gemini CLI, Hermes Agent) qui peuvent tourner en parallèle, ce qui permet de proposer plusieurs niveaux de qualité / souveraineté / coût sans changer le wiring côté tenant.

One-click OAuth to MCP — flow détaillé

Le wizard d’installation Nika OS automatise le branchement des providers externes via OAuth en un clic. Deux familles sont supportées :

Famille A — Google Cloud / Google Workspace (GWS)

L’utilisateur clique “Connecter Google” sur la page d’install.
Nika OS génère une URL OAuth 2.0 avec PKCE + scopes minimaux :
- https://www.googleapis.com/auth/drive.readonly
- https://www.googleapis.com/auth/calendar
- https://www.googleapis.com/auth/gmail.modify (modifier labels, drafts)
- https://www.googleapis.com/auth/cloud-platform (si GCP nécessaire)
Le navigateur ouvre le consent Google. L’utilisateur valide.
Callback https://install.bcub3.com/oauth/google/callback reçoit le code.
Échange code → refresh + access token. Stockage chiffré dans ~/.config/nika-os/credentials/google.enc (age + clé tenant).
Génération automatique de 4 MCP servers (gmail-mcp, gdrive-mcp, gcalendar-mcp, gcp-mcp) avec credentials prêts. Hot-swap dans le pod sans redémarrage.
Test smoke : gmail.list_threads(maxResults=1) doit retourner 200.

Famille B — Microsoft 365 / Azure

Pattern identique pour Outlook + Teams + SharePoint + OneDrive via Microsoft Graph API (delegated OAuth). L’app Azure est multi-tenant ; chaque client autorise dans son propre tenant. Scopes :

Mail.ReadWrite, Calendars.ReadWrite, Sites.Read.All, Files.ReadWrite
Chat.ReadWrite (Teams)

Famille C — Serveurs MCP classiques (API key)

Pour les services qui n’ont pas OAuth (LinkedIn, certaines APIs internes, banques fintech avec API key brute), le wizard demande la clé directement, la chiffre (age), et génère le MCP correspondant. Le wrapper Python expose @tool décorateurs qui chargent la clé à l’exécution depuis le coffre.

Rotation et révocation

Refresh token Google → rotation automatique 24h avant expiration.
Si OAuth refresh échoue (utilisateur a révoqué) → notification WA + UI re-consent en un clic.
Audit log JSONL chaque rotation / utilisation pour traçabilité GDPR.

Recommandations réseau

Nika OS tourne sur une infra modeste (1 VPS Contabo + workers spawn à la demande). Les choix réseau privilégient la simplicité et la défense en profondeur plutôt que la sophistication.

Topologie recommandée

flowchart LR
    U["👤 Paul (iPhone / laptop)"] -->|"Tailscale<br/>WireGuard"| TS["🌐 Tailscale Mesh<br/>(privé, chiffré bout-à-bout)"]
    TS --> VPS["🖥️ VPS Contabo<br/>(Ubuntu 24.04 LTS)"]
    VPS -->|Caddy/Traefik| TLS["🔒 TLS 1.3 + HSTS"]
    TLS --> NIKA["🪆 Nika OS Kernel"]
    TLS --> BAILEYS["💬 Bridge WhatsApp<br/>port 3300 (loopback)"]
    NIKA --> REDIS[("Redis<br/>127.0.0.1:6379")]
    NIKA --> QDRANT[("Qdrant<br/>127.0.0.1:6333")]

    classDef user fill:#2C3E42,color:#FDFBF8,stroke:#1A262A;
    classDef mesh fill:#7DB5A5,color:#FDFBF8,stroke:#5E9384;
    classDef vps fill:#F3EADE,color:#2C3E42,stroke:#7DB5A5;
    classDef edge fill:#E99971,color:#FDFBF8,stroke:#C97A55;
    classDef store fill:#FAF5EC,color:#2C3E42,stroke:#A86640;
    class U user;
    class TS mesh;
    class VPS,NIKA vps;
    class TLS,BAILEYS edge;
    class REDIS,QDRANT store;

Règles strictes

Bind sur loopback par défaut — tous les services internes (Redis, Qdrant, Postgres, bridge WhatsApp) écoutent uniquement sur 127.0.0.1. Aucun port n’est exposé sur l’IP publique sauf 80/443 (Traefik) et 22 (SSH restreint).
Tailscale comme VPN d’accès — l’admin accède aux services internes exclusivement via le mesh Tailscale WireGuard. Pas de VPN OpenVPN exposé, pas d’IPSec, pas de panneau d’admin sur Internet ouvert. Les workers spawn (multi-VPS futur) rejoignent automatiquement le mesh avec une auth-key éphémère.
TLS partout — Traefik (ou Caddy en alternative) termine TLS 1.3 + HSTS sur 443. Certs Let’s Encrypt automatiques. Pas de TLS 1.0/1.1 acceptés.
Firewall UFW restrictif — par défaut deny ; allow uniquement 22 (depuis IP admin), 80 (redirige 443), 443. Tailscale gère son tunnel séparément.
SSH hardening — pas de password auth, clé publique uniquement, port 22 limité aux IP admin via UFW. fail2ban actif sur SSH + audit cron.
MTA-STS + DKIM + SPF + DMARC pour le mail sortant depuis bcub3.com. Politique DMARC quarantine minimum, idéalement reject une fois la chaîne stabilisée. MTA-STS publié à .well-known/mta-sts.txt.
Secrets jamais en clair — credentials chiffrés age, clés gérées par un coffre local (Vaultwarden self-hosted recommandé) accessible uniquement via Tailscale. Pas de secrets dans git, pas de logs en clair.
Audit régulier — daily-security-audit (cron horaire) vérifie ports ouverts publics, tentatives SSH, événements sudo, OOM kills, intégrité authorized_keys + sudoers, fail2ban banlist, state services critiques. Anomalie → notification WA chiffrée.

Ce qu’on ne fait pas (volontairement)

Pas d’exposition Internet directe du kernel Nika. Si un client externe doit interagir, c’est via une gateway publique (Teams, WhatsApp, web) avec OAuth ; jamais d’accès SSH ou API privée directement exposé.
Pas de Cloudflare Worker pour le kernel — on garde le contrôle complet sur la chaîne, quitte à supporter moins de trafic.
Pas de cluster multi-zone managé (GKE / EKS) — overkill pour notre charge actuelle. K3s mono-node + workers VPS éphémères suffisent.
Pas de Bastion host séparé — Tailscale couvre déjà le cas avec moins de surface d’attaque.

Cette frugalité réseau est cohérente avec la doctrine d’antifragilité : moins de pièces mobiles, plus simple à raisonner, plus rapide à recouvrer en cas d’incident.