Doctrines

Pourquoi des doctrines plutôt que des règles

Une règle dit quoi faire. Une doctrine explique pourquoi, et permet à un système autonome de prendre les bonnes décisions dans des cas non couverts par les règles écrites. Les quatre doctrines ci-dessous structurent toute mutation, tout spawn de pod, toute extension du système.

Doctrine 1 — Antifragilité (pas de harnais rigide)

Un système rigide se dégrade quand l’environnement bouge. Un système robuste résiste. Un système antifragile au sens de Taleb s’améliore quand l’environnement bouge.

Conséquences pratiques :

• Pas de harnais hardcodé quand un algorithme déterministe ou un MCP server peut faire le travail. Si une intégration externe (CLI-Anything, par exemple) ajoute une couche d’abstraction qui empêche le système d’apprendre, on désinstalle.
• Mutation continue du harnais sous tournoi GEPA. Les formulations de prompt évoluent ; le kernel ne mute jamais.
• Pas de fallback complaisant. Quand un pod échoue, on mute ses primitives et on retry. On n’enrobe pas l’échec dans un try/except qui cache la cause.

Application concrète

Décision 2026-05-21 : désinstallation des packages cli-anything-hub et cli-anything-freecad. Pourquoi ? Parce qu’ils introduisaient une couche de harness CLI externe qui empêchait la skill freecad-pilot d’appeler directement l’API Python interne de FreeCAD. Une mutation sur la skill devait passer par l’API du package externe, qui ne suivait pas les évolutions de FreeCAD. Résultat : on dépendait de quelqu’un d’autre pour évoluer.

Doctrine appliquée : moins d’intermédiaires, plus de contrôle direct, plus de capacité d’évolution.

Doctrine 2 — Algos comme tools, pas comme LLM

Pour un problème qui a une solution algorithmique déterministe, on n’utilise pas un LLM. On expose l’algo comme un outil que le LLM peut appeler.

Conséquences :

• Stats inférentielles, DoE, SPC, ANOVA sont implémentés en Python OSS (pyDOE3, statsmodels, scipy.stats, scikit-learn) et exposés via la skill stats-doe-spc-python.
• Génération de plans techniques ISO passe par FreeCAD AppImage + skill techdraw-fab-drawings. Pas de génération LLM d’un dessin technique.
• Recherche d’entreprises via API recherche-entreprises.api.gouv.fr + skill recherche-entreprises. Pas de Q&A LLM sur ces données.

Pourquoi : un LLM est cher, lent, et stochastique. Un algo déterministe est gratuit, rapide, et reproductible. Le LLM doit servir aux décisions, à la synthèse, à la communication — pas aux calculs déjà résolus.

Le critère

On promeut une primitive en kernel uniquement si elle :

1. apporte un avantage net mesurable sur la satisfaction utilisateur ;
2. permet de faire bon du premier coup, donc économise des tokens.

Sinon, elle reste une primitive accessoire mutable — donc dans le scope GEPA, donc soumise à évolution continue.

Doctrine 3 — Kernel/pod split

Le kernel d’un système agentique long-running doit être gravé. Le harnais qui l’entoure doit être mutable. Mélanger les deux est la cause la plus fréquente d’incidents.

Couche	Statut	Exemples
Kernel	Off-limits pour la mutation auto	CLAUDE.md, system prompt agents, contrats sécurité, PALACE PROTOCOL, matrice SQP
Harnais	Mutable sous GEPA	Formulations skills, hyperparams modèles, ordre des prompts, heuristiques de routing

Règle stricte : aucune mutation automatique ne peut modifier un fichier kernel. Une mutation qui aurait besoin de toucher le kernel est interceptée et escaladée à l’opérateur humain pour validation explicite.

Cette discipline permet :

• de garantir la stabilité des invariants critiques (sécurité, intégrité, brand) ;
• d’autoriser l’apprentissage agressif du harnais sans risquer une régression sur les invariants ;
• de rollback rapidement une mutation du harnais sans devoir reconstruire le kernel.

Doctrine 4 — Agnostique multi-CLI

Nika OS est conçu pour fonctionner avec plusieurs runtimes d’agent : l’agent CLI (référence principale), Hermès (CLI maison), Gemini CLI, Mistral on-premise. La logique métier ne dépend pas d’un runtime spécifique.

Conséquences :

• Les skills sont markdown + frontmatter, donc lisibles par n’importe quel runtime qui sait parler markdown.
• Les hooks sont des scripts Python qui lisent stdin et écrivent stdout. Aucune dépendance à l’API interne de l’agent CLI.
• Les MCP servers suivent le protocole standard, donc tout client MCP peut les utiliser.
• Le bus JSONL est lisible par n’importe quel processus capable de parser JSON.

Pourquoi : un système qui dépend d’un seul provider est fragile. Si le provider change ses prix, ses limites, ou son comportement, le système entier est exposé. En gardant l’architecture neutre, on garde la liberté de switcher.

Application concrète

Le routeur cognitif nika_route_request est invocable via la skill route. Il dispatche une intention vers les primitives appropriées (skill, pod, MCP, schedule). Le dispatch ne suppose pas que c’est l’agent CLI qui reçoit la requête : la sortie est un plan structuré que n’importe quel runtime peut exécuter.

En une phrase chacune

• Antifragilité : préfère apprendre plutôt que résister.
• Algos comme tools : déterministe gagne contre stochastique quand c’est possible.
• Kernel/pod split : ce qui est gravé reste gravé, ce qui mute est borné.
• Multi-CLI : pas d’enracinement dans un runtime unique.

Ces quatre doctrines, ensemble, expliquent toutes les décisions d’architecture documentées sur ce site.

Doctrine — Fiabilité mesurée + validation humaine sur écritures externes

Nika OS est un système autonome qui agit sur des outils, mais cette autonomie est bornée par deux primitives immutables du kernel qui ne peuvent pas être mutées par GEPA, ni désactivées par un pod, ni contournées par un skill.

Primitive 1 — Mesure du niveau de fiabilité

Chaque livrable produit par Nika OS est accompagné d’un score de fiabilité calculé en continu :

• Sources : KTW Y observé (chunks/min, error_rate, tool_diversity), score du méta-pod LLM-as-judge déterministe, dispersion entre N CLIs en tournament mode, recency / staleness du RAG retrieval, taux de contradictions internes détectées.
• Échelle : 0-100, calibrée empiriquement sur dataset gold.
• Affichage : le score est visible à côté de chaque livrable (page web, message WhatsApp, mail draft). Pas un score caché.
• Granularité : score global du livrable + sous-scores par dimension (factualité, complétude, cohérence, style).

Sans mesure, pas de confiance vérifiable. Sans confiance, pas d’usage en production. Cette mesure est constitutive du système.

Primitive 2 — Human-in-the-loop sur les écritures externes

Toute action qui écrit hors du système Nika OS requiert une validation humaine explicite avant exécution. La liste exhaustive :

Catégorie	Exemples
Envoi de communications	Mail (Gmail, Outlook), WhatsApp à un contact externe, post LinkedIn / Teams public, SMS, fax
Écritures BDD externes	API publique POST / PUT / DELETE, modification d’un dossier client SharePoint, écriture dans un ERP / CRM tiers
Engagements financiers	Paiement, virement, achat, signature de devis / contrat
Code en production	Push direct sur main, merge sans review, déploiement, modification d’infra partagée
Documents légaux	Soumission d’un dossier officiel (Greffe, DREETS, INPI, fiscal), signature d’un acte
Données personnelles	Création d’un compte client, modification d’un dossier RH / médical

Cette règle est gravée dans le kernel via un hook PreToolUse qui :

1. Intercepte chaque tool call avant exécution.
2. Classifie l’action (lecture / écriture interne / écriture externe).
3. Si écriture externe → bloque + demande validation à l’opérateur humain via le canal qu’il a configuré (WhatsApp / Teams par défaut, console admin en backup).
4. L’opérateur valide ou rejette. Sans réponse dans le délai configuré (default 30 min) → action annulée et tracée comme rejetée.
5. La règle ne peut pas être désactivée par GEPA, ni par un skill, ni par un pod. Le hook est marqué kernel_immutable: true dans settings.json.

Exceptions strictes

Trois cas seulement sont auto-validés :

• Réponses sortantes sur un thread initié par Paul (réponse à un mail où Paul est en CC explicite et a déjà autorisé le draft).
• Mises à jour internes Nika OS (logs, métriques, RAG, JSONL, configs tenant-local).
• Actions explicitement budgétées dans le wizard avec un seuil maximum (e.g. achat consommable < 10 € via API achat dédiée).

Toute autre écriture externe → validation humaine obligatoire.

Pourquoi cette doctrine

L’autonomie sans garde-fous mène à des incidents qui coûtent infiniment plus cher que la friction d’une validation. Le système peut se tromper sur un résumé de réunion (impact 0), mais pas sur l’envoi d’un mail mal formulé à un client (impact réputation, juridique, commercial).

Cette doctrine est l’expression opérationnelle du principe de dual-control appliqué historiquement aux systèmes critiques : décision automatisée + validation humaine = autonomie sûre.

Sans cette doctrine, Nika OS ne serait pas industrialisable.