Tutoriel Principal · IA & Souveraineté

IA Souveraine :
8 Agents 100% sous ton contrôle

Déploie une infrastructure multi-agents IA complète, LLMs locaux, zéro API commerciale, zéro log chez un tiers. Headscale, Ollama, n8n, gVisor, CrewAI. Tout tourne sur ton VPS, dans ta juridiction.

Main Tutorial · AI & Sovereignty

Sovereign AI:
8 Agents 100% under your control

Deploy a complete multi-agent AI infrastructure, local LLMs, zero commercial API, zero third-party logs. Headscale, Ollama, n8n, gVisor, CrewAI. Everything runs on your VPS, in your jurisdiction.

IntermédiaireIntermediate ⏱ ~4h 10 chapitreschapters Budget ~15€/moisBudget ~€15/month

Prérequis

  • Linux Ubuntu 22.04 sur le VPS (couvert au ch.03) et en local si possible
  • Nom de domaine avec accès DNS (ex: umbra.tondomaine.io)
  • Terminal : macOS / Linux / Windows WSL2, savoir utiliser ssh, cd, sudo
  • Budget VPS : 4-20€/mois selon l'hébergeur
  • Recommandé : avoir fait le tutoriel VPN Souverain ou savoir ce qu'est WireGuard

Prerequisites

  • Ubuntu 22.04 Linux on the VPS (covered in ch.03) and locally if possible
  • Domain name with DNS access (e.g.: umbra.yourdomain.io)
  • Terminal: macOS / Linux / Windows WSL2, know how to use ssh, cd, sudo
  • VPS budget: €4-20/month depending on provider
  • Recommended: having done the Sovereign VPN tutorial or knowing what WireGuard is
← Voir la présentation complète du tutoriel
00

Before you start

5 min

Chapter objective

You have a clear vision of the final infrastructure, total budget, and you confirm you have all the prerequisites. Zero surprises in the following chapters.

By the end of this tutorial, you'll have a self-hosted multi-agent AI infrastructure with 8 specialized agents working for you. Each agent has a local LLM, specific tools, and an automatic trigger. No data leaves your network.

Final architecture at a glance

The OS-NEXUS architecture splits work between two environments:

  • VPS (Iceland/Switzerland): n8n orchestrator, Redis queue, AI Gateway (FastAPI), Postgres, small fast models (deepseek-v2:16b)
  • Local machine: Python orchestrator, large models (qwen2.5-coder:32b), ChromaDB (RAG), gVisor sandbox
  • Connection: encrypted WireGuard tunnel, local initiates, VPS never pushes

Estimated budget

ComponentRecommended optionCost
VPS1984 Hosting (Iceland, 2 vCPU, 4 GB RAM)~€8/month
DomainAny registrar (Cloudflare recommended)~€10/year
Local machineYour existing computer (at least 16 GB RAM)€0
SoftwareAll open source€0
Total~€100/year

Chapter result

You have a clear view of the final infrastructure and confirm the prerequisites. Move on to chapter 01.

Final result in 90 seconds

dev agent · Shopify task · CrewAI result in real time

Final architecture: public VPS (n8n, Redis, AI Gateway) + local machine (heavy LLMs, gVisor) connected via encrypted WireGuard tunnel.
00

Avant de commencer

5 min

Objectif de ce chapitre

Tu as une vision claire de l'architecture finale, du budget total, et tu confirmes que tu as tous les prérequis. Zéro surprise dans les chapitres suivants.

Résultat final en 90 secondes

agent dev · tâche Shopify · résultat CrewAI en temps réel

À la fin de ce tutoriel, tu auras une infrastructure multi-agents IA auto-hébergée avec 8 agents spécialisés qui travaillent pour toi. Chaque agent a un LLM local, des outils spécifiques, et un déclencheur automatique. Aucune donnée ne quitte ton réseau.

L'architecture finale en un coup d'œil

Architecture finale : VPS public (n8n, Redis, AI Gateway) + machine locale (LLMs lourds, gVisor) reliés par tunnel WireGuard chiffré.

Budget estimé

ComposantOption recommandéeCoût
VPS1984 Hosting (Islande, 2 vCPU, 4 Go RAM)~8€/mois
DomaineN'importe quel registrar (Cloudflare recommandé)~10€/an
Machine localeTon ordi existant (au moins 16 Go RAM)0€
LogicielsTous open source0€
Total~100€/an

Résultat de ce chapitre

Tu as une vue claire de l'infra finale et tu confirmes les prérequis. Passe au chapitre 01.

01

Why sovereign AI?

~15 min

Chapter objective

You identify the 3 concrete reasons why OpenAI and Anthropic aren't enough for true autonomy. You know what you gain by self-hosting.

« Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can't get privacy unless we all do, we're going to write it. »

— Eric Hughes, A Cypherpunk's Manifesto, 1993

Using ChatGPT or the Anthropic API to automate your business is like renting a printer that keeps a copy of everything you print. Comfortable, but fundamentally problematic if you care about privacy.

The 3 real problems

1

Your prompts belong (temporarily) to OpenAI

By default, OpenAI retains API data for 30 days for "security and abuse prevention". Opt-out is available but not automatic. Your business secrets, strategy, source code, customer data, transit through their servers.

2

CLOUD Act: one US court order is enough

OpenAI and Anthropic are US companies. The CLOUD Act (2018) allows US courts to demand access to your data, even if you're European and even if servers are in Europe. This is structural, not a matter of personal trust in these companies.

3

Operational dependency: they can cut the tap

In November 2023, OpenAI had a worldwide outage lasting several hours. Thousands of businesses depending on their API were paralyzed. Your automation strategy can't rely on a third-party service you don't control.

What self-hosting gives you

  • 🔒 Zero third-party logs : Your prompts never leave your network.
  • Total availability : If a provider goes down, your infra keeps running.
  • 💰 Predictable cost : Fixed €8/month, regardless of volume.
  • 🎛 Fine-tuning possible : Adjust models to your business vocabulary.

Chapter result

You understand the 3 structural limits of commercial APIs and the 4 concrete advantages of self-hosting.

01

Pourquoi l'IA souveraine ?

~15 min

Objectif de ce chapitre

Tu identifies les 3 raisons concrètes pour lesquelles OpenAI et Anthropic ne suffisent pas pour une vraie autonomie. Tu sais ce que tu gagnes en auto-hébergeant.

« Cypherpunks write code. We know that someone has to write software to defend privacy, and since we can't get privacy unless we all do, we're going to write it. »

— Eric Hughes, A Cypherpunk's Manifesto, 1993

Utiliser ChatGPT ou l'API d'Anthropic pour automatiser ton entreprise, c'est comme louer une imprimante qui garde une copie de tout ce que tu imprimes. Confortable, mais fondamentalement problématique si tu t'en soucies.

Les 3 problèmes réels

1

Tes prompts appartiennent (temporairement) à OpenAI

Par défaut, OpenAI conserve les données d'API 30 jours pour "sécurité et prévention des abus". Opt-out disponible mais non automatique. Tes secrets d'entreprise, stratégie, code source, données clients, transitent par leurs serveurs.

2

CLOUD Act : une ordonnance US suffit

OpenAI et Anthropic sont des entreprises américaines. Le CLOUD Act (2018) permet à la justice US d'exiger l'accès à tes données, même si tu es européen et même si les serveurs sont en Europe. C'est structurel, pas une question de confiance personnelle envers ces entreprises.

3

Dépendance opérationnelle : ils peuvent couper le robinet

En novembre 2023, OpenAI a subi une panne mondiale de plusieurs heures. Des milliers d'entreprises dépendant de leur API se sont retrouvées paralysées. Ta stratégie d'automatisation ne peut pas reposer sur un service tiers que tu ne contrôles pas.

Ce que l'auto-hébergement te donne

🔒

Zéro log chez un tiers

Tes prompts ne quittent jamais ton réseau. Pas de rétention, pas d'entraînement sur tes données.

Disponibilité totale

Si un fournisseur tombe en panne, ton infra continue. Tu contrôles les mises à jour.

💰

Coût prévisible

8€/mois fixe, peu importe le volume. Pas de surprise à 5 000 appels d'API.

🎛

Fine-tuning possible

Ajuste les modèles à ton vocabulaire métier. Impossible avec une API commerciale.

💎

Mode Expert, Les LLMs open source en 2026

Les modèles open source (Qwen 2.5, DeepSeek-V2, Llama 3.x) ont atteint la parité avec GPT-4 sur la majorité des tâches d'entreprise. Le benchmark MMLU 2024 montre des scores >85% pour les modèles 32B+ quantisés. La raison principale de rester sur APIs commerciales n'est plus la qualité, c'est la commodité.

Résultat de ce chapitre

Tu comprends les 3 limites structurelles des APIs commerciales et les 4 avantages concrets de l'auto-hébergement. Tu es convaincu(e) de continuer.

02

The OS-NEXUS architecture

~20 min

Chapter objective

You visualize the complete infrastructure and understand the role of each component. You can explain why VPS and local machine are separated.

💡

Beginner Corner, Why split VPS + Local?

A 32 billion parameter LLM needs ~20 GB of GPU RAM. A standard VPS doesn't have that. Solution: the VPS handles light orchestration (n8n, Redis) and small fast models (16B), while your local machine runs heavy models when needed. This is OS-NEXUS's asymmetric architecture.

The two environments and their roles

ComponentLocationRole
n8nVPSVisual workflow orchestrator, triggers, webhooks
RedisVPSTask queue (pull-based, local polls)
AI GatewayVPSFastAPI, ECHO validation, routing to Redis
Ollama (small)VPSFast models: deepseek-v2:16b, support/social
OrchestratorLocalPython worker, pulls from Redis, runs CrewAI
Ollama (large)LocalHeavy models: qwen2.5-coder:32b
ChromaDBLocalVector database for RAG
gVisorLocalSandbox for AI-generated code execution

Task flow

Event → n8n → ECHO risk filter → AI Gateway → Redis → Local orchestrator → CrewAI agent → Tools → Result

Chapter result

You understand why the architecture is split and the role of each component. You can start deploying.

OS-NEXUS architecture: the VPS handles public orchestration (n8n, Redis, AI Gateway) and lightweight LLMs, the local machine runs heavy LLMs (qwen2.5-coder:32b) in gVisor. Everything transits via WireGuard tunnel, local initiates, VPS never pushes.
02

L'architecture OS-NEXUS

~20 min

Objectif de ce chapitre

Tu visualises l'infrastructure complète et comprends le rôle de chaque composant. Tu peux expliquer pourquoi on sépare VPS et machine locale.

💡

Coin du Débutant, Architecture VPS + Local, pourquoi ?

Un LLM de 32 milliards de paramètres a besoin de ~20 Go de RAM GPU. Un VPS standard n'en a pas. Solution : le VPS gère l'orchestration légère (n8n, Redis) et les petits modèles rapides (16B), pendant que ta machine locale fait tourner les modèles lourds quand nécessaire. C'est l'architecture asymétrique d'OS-NEXUS.

Architecture OS-NEXUS : le VPS gère l'orchestration publique (n8n, Redis, AI Gateway) et les LLMs légers, la machine locale exécute les LLMs lourds (qwen2.5-coder:32b) dans gVisor. Tout transite par tunnel WireGuard, le local initie, le VPS ne push jamais.

Les 5 composants et leur rôle

n8n

n8n, L'orchestrateur central

Chef d'orchestre visuel. Il écoute les événements (emails entrants, webhooks GitHub, cron jobs), valide les intentions via le patron ECHO, et envoie les tâches à l'AI Gateway. Self-hosted, interface web, 400+ connecteurs.

Redis

Redis, La file d'attente des tâches

Base de données en mémoire ultra-rapide. Quand n8n crée une tâche, elle va dans Redis. L'orchestrateur local tire les tâches de Redis (pull-based). Zéro port ouvert côté local, zéro connexion entrante.

Ollama

Ollama, Le serveur d'inférence local

Sert les LLMs open source via une API compatible OpenAI. Même code Python, différent serveur. DeepSeek-V2 (16B) tourne sur le VPS pour les tâches rapides, Qwen 2.5-Coder (32B) tourne en local pour les tâches complexes.

CrewAI

CrewAI, Le framework multi-agents

Orchestre plusieurs agents IA spécialisés en séquence ou en hiérarchie. Chaque agent a un rôle, un LLM, des outils, et peut passer le résultat à l'agent suivant. 8 agents = 8 équipes avec des compétences différentes.

gVisor

gVisor, La prison des agents

Sandboxing du code généré par les agents Dev. Sentry (kernel invité en espace utilisateur) intercepte tous les appels système. Réseau coupé, système de fichiers en lecture seule. Si un agent génère du code malveillant, il ne peut pas sortir du conteneur.

Calculateur VRAM, Quel matériel pour quels modèles ?

⚙ Estimateur VRAM

16K256K
Poids du modèle36.0 Go
KV Cache (contexte)0.6 Go
Overhead CUDA/PyTorch15 Go
VRAM totale requise51.6 Go

Matériel recommandé

2x RTX 4090 (48 Go) ou 1x A100 (80 Go)

Tableau des LLMs par agent

AgentLLM assignéOù tourneJustification
</> Dev/Opsqwen2.5-coder:32bLocalPrécision code, longues sessions
@ Supportdeepseek-v2:16bVPSLatence faible, réponses courtes
[o] Creativeqwen2.5:72bLocalRaisonnement créatif profond
$ Growthqwen2.5:72bLocalCopywriting nuancé
# Socialdeepseek-v2:16bVPSFormats courts, haute fréquence
■ OPSECqwen2.5:72bLocalRigueur technique requise
▶ UXqwen2.5:72bLocalAnalyse empathique complexe
◆ Designerqwen2.5:72bLocalGénération HTML précise

Résultat de ce chapitre

Tu comprends le rôle de chaque composant et pourquoi l'architecture VPS + Local est plus intelligente qu'un seul serveur. Tu sais quel LLM va où.

03

Choose and harden the sovereign VPS

~30 min

Chapter objective

Your server is operational in a sovereign jurisdiction, SSH hardened, Docker installed, firewall active. No bot can brute-force it.

Choosing a hosting provider by jurisdiction

ProviderJurisdictionSpecsPrice 2026OPSEC advantage
1984 HostingIceland 🇮🇸2 vCPU, 4 GB~€8/moOutside EU/US jurisdiction
InfomaniakSwitzerland 🇨🇭2 vCPU, 4 GB~€10/moSwiss privacy laws
HetznerFinland/Germany 🇫🇮🇩🇪2 vCPU, 4 GB~€5/moEU GDPR, no CLOUD Act

Hardening checklist

  • Change SSH port to non-standard (e.g. 50222)
  • Disable password authentication, keys only
  • Disable direct root login
  • UFW: deny all incoming, allow 50222/80/443/51820
  • Install Docker via official script

⚠️ Always test the new SSH config from a second terminal before closing the first session, a misconfiguration can permanently lock you out.

Chapter result

VPS operational in a sovereign jurisdiction, SSH hardened, UFW active, Docker installed. Bots can no longer attack your server.

03

Choisir et sécuriser le VPS souverain

~30 min

Objectif de ce chapitre

Ton serveur est opérationnel dans une juridiction souveraine, SSH durci, Docker installé, pare-feu actif. Aucun robot ne peut le bruteforcer.

Choisir l'hébergeur selon ta juridiction cible

HébergeurJuridictionSpécificationsPrix 2026Avantage OPSEC
1984 Hosting🇮🇸 Islande2 vCPU, 4 Go RAM, 80 Go SSD8€/moisLiberté d'expression absolue, hors CLOUD Act
Infomaniak Lite M🇨🇭 Suisse2 vCPU, 4 Go RAM, 80 Go SSD9,90€/moisLPD stricte, données énergie verte
UpCloud Helsinki🇫🇮 Finlande2 vCPU, 4 Go RAM, 80 Go MaxIOPS20$/moisRGPD souverain, réseau haute performance
💡

Coin du Débutant, Pourquoi hors de France ?

Pas d'anti-patriotisme : c'est une question de droit. La France est soumise à des réglementations européennes qui permettent, dans certains cas, des demandes d'accès aux données hébergées sur son territoire. L'Islande a une loi sur la liberté de la presse parmi les plus protectrices du monde, et n'est pas membre de l'UE.

bash : Première connexion + création utilisateur
# Connexion initiale (remplace par ton IP)
ssh root@203.0.113.42

# Mise à jour du système
apt update && apt upgrade -y

# Créer l'utilisateur admin (remplace "umbra" par ton nom)
adduser umbra
usermod -aG sudo umbra

# Copier ta clé SSH publique vers le nouvel utilisateur
rsync --archive --chown=umbra:umbra ~/.ssh /home/umbra
bash : Durcissement SSH + Pare-feu UFW
# Durcir SSH
sudo nano /etc/ssh/sshd_config
# Modifier ces paramètres :
Port                    50222    # Port non-standard
PermitRootLogin         no
PasswordAuthentication  no       # Clés uniquement
PubkeyAuthentication    yes

sudo systemctl restart sshd

# Configurer le pare-feu (dans un SECOND terminal, AVANT de fermer)
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 50222/tcp  comment 'SSH'
sudo ufw allow 80/tcp     comment 'HTTP'
sudo ufw allow 443/tcp    comment 'HTTPS'
sudo ufw allow 51820/udp  comment 'WireGuard'
sudo ufw enable

# Installer Docker
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker umbra
newgrp docker && docker --version
Docker version 26.x.x ← attendu

Ne ferme jamais ta session avant de tester le nouveau port

Ouvre un deuxième terminal, teste ssh -p 50222 umbra@ton-ip, confirme la connexion, PUIS ferme le premier terminal. Si tu fermes avant de tester, tu peux te retrouver lockout définitivement.

Résultat de ce chapitre

VPS opérationnel dans une juridiction souveraine, SSH durci, UFW actif, Docker installé. Les bots ne peuvent plus attaquer ton serveur.

04

WireGuard VPN + Headscale

~30 min

Chapter objective

The encrypted VPS↔local tunnel is active. Your local machine has IP 100.64.0.2. No port is open on the local side. The orchestrator can reach Redis on the VPS via the VPN IP.

The VPN is the security backbone. Without it, the local orchestrator would need to expose ports, which is unacceptable. This chapter covers the essential steps; for more details, see the dedicated Sovereign VPN tutorial.

Deploy Headscale on the VPS

Deploy Headscale via Docker Compose, create a namespace, generate a pre-auth key.

Connect your local machine

Install Tailscale, connect with --login-server pointing to your Headscale instance, verify with ping 100.64.0.1.

Chapter result

WireGuard tunnel active. Your local machine (100.64.0.2) can reach the VPS (100.64.0.1) over an encrypted connection. No open ports on the local side.

04

VPN WireGuard + Headscale

~30 min

Objectif de ce chapitre

Le tunnel chiffré VPS↔local est actif. Ta machine locale a l'IP 100.64.0.2. Aucun port n'est ouvert côté local. L'orchestrateur peut joindre Redis sur le VPS via l'IP VPN.

Le VPN est la colonne vertébrale de la sécurité. Sans lui, l'orchestrateur local devrait exposer des ports, ce qui est inacceptable. Ce chapitre reprend les étapes essentielles ; si tu veux plus de détails, suis le tutoriel dédié VPN Souverain.

Déployer Headscale sur le VPS

bash : Headscale via Docker Compose
mkdir -p /opt/headscale/{config,data} && cd /opt/headscale

# docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: "3.9"
services:
  headscale:
    image: headscale/headscale:latest
    restart: unless-stopped
    volumes:
      - ./config:/etc/headscale
      - ./data:/var/lib/headscale
    ports:
      - "443:8080"
      - "51820:51820/udp"
    command: headscale serve
EOF

# config/config.yaml (minimal)
cat > config/config.yaml << 'EOF'
server_url: https://vpn.tondomaine.io
listen_addr: 0.0.0.0:8080
ip_prefixes:
  - 100.64.0.0/10
database:
  type: sqlite
  sqlite:
    path: /var/lib/headscale/db.sqlite
tls_letsencrypt_hostname: vpn.tondomaine.io
tls_letsencrypt_cache_dir: /var/lib/headscale/cache
EOF

docker compose up -d
# Créer namespace + clé pré-auth
docker exec headscale headscale namespaces create umbra
docker exec headscale headscale preauthkeys create --namespace umbra --expiration 24h
# Output : mkey:xxxx  ← copie cette clé
bash : Connecter la machine locale
# Sur ta machine locale
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up \
  --login-server=https://vpn.tondomaine.io \
  --authkey=mkey:xxxx \
  --hostname=local-worker

# Vérification
ping 100.64.0.1 -c 3
64 bytes from 100.64.0.1: time=12ms  ← tunnel actif

Résultat de ce chapitre

Tunnel WireGuard actif. Ta machine locale (100.64.0.2) joindre le VPS (100.64.0.1) de façon chiffrée. Aucun port ouvert côté local.

05

Docker + n8n Queue Mode

~30 min

Chapter objective

n8n is accessible via HTTPS on your domain, connected to Redis and PostgreSQL. You can create your first workflow and send a task to the AI Gateway.

n8n in Queue Mode separates the main process (UI, webhooks) from the workers (task execution). This makes it resilient and scalable.

Docker Compose stack on VPS

The stack includes: n8n main + n8n worker, PostgreSQL (state persistence), Redis (queue), AI Gateway (FastAPI), all on the same Docker network.

Verify

After docker compose up -d, n8n should be accessible at https://n8n.yourdomain.io. Create a test webhook workflow to confirm task routing works.

Chapter result

n8n accessible at https://n8n.yourdomain.io. PostgreSQL persists state, Redis manages the queue. The central orchestrator is in place.

05

Docker + n8n Queue Mode

~30 min

Objectif de ce chapitre

n8n est accessible via HTTPS sur ton domaine, connecté à Redis et PostgreSQL. Tu peux créer ton premier workflow et envoyer une tâche vers l'AI Gateway.

💡

Coin du Débutant, n8n, c'est quoi ?

n8n est comme Zapier mais que tu héberges toi-même. Il connecte des services (GitHub, email, Discord...) via des workflows visuels. Dans OS-NEXUS, n8n est le chef d'orchestre : il reçoit les événements et décide quel agent appeler. Interface web à n8n.tondomaine.io après ce chapitre.

yaml : docker-compose.n8n.yml (sur le VPS)
version: "3.9"
services:

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: umbra
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: umbralabs
    volumes: [postgres_data:/var/lib/postgresql/data]

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    ports: ["127.0.0.1:6379:6379"]  # Accessible uniquement en local/VPN

  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports: ["5678:5678"]
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: umbralabs
      DB_POSTGRESDB_USER: umbra
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      QUEUE_BULL_REDIS_HOST: redis
      EXECUTIONS_MODE: queue
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_HOST: n8n.tondomaine.io
      WEBHOOK_URL: https://n8n.tondomaine.io
    depends_on: [postgres, redis]

volumes:
  postgres_data:
bash : Lancer et vérifier
# Créer le .env
echo "POSTGRES_PASSWORD=$(openssl rand -hex 16)" > .env
echo "N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)" >> .env

docker compose -f docker-compose.n8n.yml up -d

# Vérifier que n8n répond
curl https://n8n.tondomaine.io/healthz
{"status":"ok"}  ← attendu

Résultat de ce chapitre

n8n accessible sur https://n8n.tondomaine.io. PostgreSQL persiste l'état, Redis gère la file. L'orchestrateur central est en place.

06

Ollama: your local LLMs

~20 min

Chapter objective

Ollama is running on both the VPS and your local machine. You have the required models, you can send a prompt and receive a response without touching the Internet.

Ollama is a local inference server for open source LLMs. It exposes an OpenAI-compatible API at localhost:11434.

Install and pull models

bash : Install Ollama + pull models
# Install Ollama (VPS and local machine)
curl -fsSL https://ollama.com/install.sh | sh

# On VPS, fast model for support/social agents
ollama pull deepseek-v2:16b

# On local machine, heavy model for dev/marketing agents
ollama pull qwen2.5-coder:32b

# Test (no internet required)
ollama run deepseek-v2:16b "What is digital sovereignty?"

Chapter result

Ollama running on both machines. LLMs respond locally. No data leaves your network.

06

Ollama : tes LLMs locaux

~20 min

Objectif de ce chapitre

Ollama tourne sur le VPS et sur ta machine locale. Tu as les modèles nécessaires, tu peux envoyer un prompt et recevoir une réponse sans toucher Internet.

💡

Coin du Débutant, La quantization expliquée

Un modèle 32B en FP32 pèse ~128 Go. En Q4 (4 bits par paramètre), il tombe à ~20 Go, même GPU grand public. La qualité baisse légèrement (~3-5% sur les benchmarks) mais reste excellente pour les tâches d'entreprise. Q4 = le meilleur compromis pour commencer.

bash : Installer Ollama + télécharger les modèles
# Installer Ollama (VPS ET machine locale, même commande)
curl -fsSL https://ollama.com/install.sh | sh

# === VPS === télécharger le modèle rapide (léger)
ollama pull deepseek-v2:16b
pulling manifest... ✓  (~10 Go, ~5-10min)

# === Machine locale === télécharger le modèle de raisonnement
ollama pull qwen2.5-coder:32b
pulling manifest... ✓  (~20 Go, ~10-20min selon connexion)

# Tester la réponse (doit fonctionner sans Internet)
ollama run deepseek-v2:16b "Réponds en français : qu'est-ce qu'un agent IA ?"
Un agent IA est un programme capable de percevoir son environnement...
python : Test via API Python (compatible OpenAI)
# Test Python, même API que OpenAI, serveur différent
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",  # Ollama local
    api_key="ollama",                    # ignoré, mais requis
)

response = client.chat.completions.create(
    model="deepseek-v2:16b",
    messages=[{"role": "user", "content": "Dis 'Souveraineté numérique!'"}]
)
print(response.choices[0].message.content)
Souveraineté numérique!  ← réponse sans API commerciale

Résultat de ce chapitre

Ollama tourne sur les deux machines. Les LLMs répondent localement. Aucune donnée ne quitte ton réseau.

07

gVisor sandbox: isolate the agents

~20 min

Chapter objective

gVisor is installed on your local machine. Code generated by the Dev agent runs in an isolated container (network disabled, read-only filesystem). You've validated isolation with a test.

The Dev agent generates Python code to fix Shopify or GSheets bugs. This code is executed locally for testing. Without isolation, a bug in the generated code, or a malicious injection, could access your filesystem or network. gVisor prevents that.

How gVisor (Sentry) works

gVisor intercepts all syscalls from the container via a user-space guest kernel (Sentry). The host kernel is never touched directly. Network is disabled, filesystem is read-only.

DOCKER CONTAINER, gVisor Dev Agent Code (Python, Bash, Node.js…) Python Bash Node.js ↕ intercepted syscalls Sentry user-space guest kernel ↕ filtered syscalls Linux Host Kernel intact, never directly exposed Network: disabled Filesystem: read-only Code CANNOT touch the host system
gVisor isolation model: Sentry (user-space guest kernel) intercepts all syscalls before they reach the Linux host kernel.
bash : Install gVisor (local Ubuntu machine)
# Add gVisor repository
curl -fsSL https://gvisor.dev/archive.key | \
  sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg
sudo apt update && sudo apt install -y runsc
sudo runsc install && sudo systemctl restart docker

# Test isolation
docker run --rm --runtime=runsc \
  --network=none --read-only \
  python:3.12-slim \
  python -c "print('gVisor sandbox OK, isolation active')"
gVisor sandbox OK, isolation active  ← expected

Chapter result

gVisor installed, isolation test passed. Code generated by agents cannot access the host system. The most important security layer is in place.

07

Sandbox gVisor : isoler les agents

~20 min

Objectif de ce chapitre

gVisor est installé sur ta machine locale. Le code généré par l'agent Dev s'exécute dans un conteneur isolé (réseau coupé, filesystem en lecture seule). Tu as validé l'isolation avec un test.

L'agent Dev génère du code Python pour corriger des bugs Shopify ou GSheets. Ce code est exécuté localement pour les tests. Sans isolation, un bug dans le code généré, ou une injection malveillante, pourrait accéder à ton filesystem ou à ton réseau. gVisor empêche ça.

Comment fonctionne gVisor (Sentry)

CONTENEUR DOCKER gVisor Code agent Dev (Python, Bash, Node.js…) Python Bash Node.js ↕ syscalls interceptés Sentry noyau invité, userspace ↕ syscalls filtrés Noyau Linux hôte intact, jamais exposé directement Réseau : désactivé Filesystem : read-only Le code ne touche PAS le système hôte
Modèle d'isolation gVisor : Sentry (noyau invité en userspace) intercepte tous les syscalls avant qu'ils atteignent le noyau Linux hôte.
bash : Installer gVisor (machine locale Ubuntu)
# Ajouter le dépôt gVisor
curl -fsSL https://gvisor.dev/archive.key | \
  sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg

echo "deb [arch=$(dpkg --print-architecture) \
  signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] \
  https://gvisor.dev/apt stable main" | \
  sudo tee /etc/apt/sources.list.d/gvisor.list

sudo apt update && sudo apt install -y runsc
sudo runsc install  # Configure Docker pour utiliser runsc
sudo systemctl restart docker

# Tester l'isolation
docker run --rm --runtime=runsc \
  --network=none --read-only \
  python:3.12-slim \
  python -c "print('Sandbox gVisor OK, isolation active')"
Sandbox gVisor OK, isolation active  ← attendu

Résultat de ce chapitre

gVisor installé, test d'isolation réussi. Le code généré par les agents ne peut pas accéder au système hôte. La couche de sécurité la plus importante est en place.

08

The ECHO pattern: intent filtering

~20 min

Chapter objective

You understand and deploy the ECHO pattern in n8n. Every agent task goes through a risk evaluation (LOW/MEDIUM/HIGH) before being executed. HIGH actions are blocked.

« Secure systems don't trust their users. Resilient systems don't trust their own components. »

— Defensive security principle, inspired by Zero-Trust Architecture (NIST SP 800-207)

The fundamental OS-NEXUS rule: no AI agent directly executes a real-world action. It produces a JSON intent. n8n validates that intent deterministically (no AI in the validation). That's the ECHO pattern.

The 3 risk levels

LOW → AUTO_RUN

Read, search, analyze, draft writing. No real side effect.

E.g.: RAG search, classify an email

MEDIUM → SANDBOX

Code execution, file creation, non-critical emails.

E.g.: run Python in gVisor, create a draft PR

HIGH → HUMAN

Code merge, email campaign, data deletion.

E.g.: merge a PR, send a mailing to 5000 contacts

Chapter result

The ECHO pattern is configured in n8n. Every task is classified LOW/MEDIUM/HIGH before execution. HIGH actions are blocked pending human approval.

08

Le patron ECHO : filtration d'intention

~20 min

Objectif de ce chapitre

Tu comprends et tu déploies le patron ECHO dans n8n. Toute tâche d'agent passe par une évaluation de risque (LOW/MEDIUM/HIGH) avant d'être exécutée. Les actions HIGH sont bloquées.

« Les systèmes sûrs ne font pas confiance à leurs utilisateurs. Les systèmes résilients ne font pas confiance à leurs propres composants. »

— Principe de sécurité défensive, inspiré du Zero-Trust Architecture (NIST SP 800-207)

La règle fondamentale d'OS-NEXUS : aucun agent IA n'exécute directement une action dans le monde réel. Il produit une intention JSON. n8n valide cette intention de façon déterministe (pas d'IA dans la validation). C'est le patron ECHO.

Les 3 niveaux de risque

LOW → AUTO_RUN

Lecture, recherche, analyse, rédaction de brouillon. Aucun effet de bord réel.

Ex: chercher dans la RAG, classifier un email

MEDIUM → SANDBOX

Exécution de code, création de fichiers, envoi d'emails non critiques.

Ex: exécuter du Python dans gVisor, créer une PR draft

HIGH → HUMAIN

Merge de code, envoi de campagne email, suppression de données.

Ex: merger une PR, envoyer un mailing à 5000 contacts

javascript : n8n/risk_validator.js (nœud Code dans n8n)
// ECHO Pattern v2, Umbra Labs
// Ce script s'exécute dans un nœud "Code" de n8n
// AVANT tout appel à l'AI Gateway

const RISK_RULES = {
  HIGH:   ['merge', 'delete', 'bulk_email', 'drop_table'],
  MEDIUM: ['create_pr', 'exec', 'send_email', 'push'],
  LOW:    ['read', 'search', 'analyse', 'draft'],
};

function evaluateRisk(payload) {
  const text = JSON.stringify(payload).toLowerCase();
  for (const kw of RISK_RULES.HIGH)   if (text.includes(kw)) return 'HIGH';
  for (const kw of RISK_RULES.MEDIUM) if (text.includes(kw)) return 'MEDIUM';
  return 'LOW';
}

const input = $input.first().json;
const level = evaluateRisk(input.payload);
const routing = {
  HIGH:   'HUMAN_GATE',     // Bloqué → notification Slack/email
  MEDIUM: 'ISOLATED_SANDBOX', // Exécuté dans gVisor
  LOW:    'AUTO_RUN',        // Exécuté directement
}[level];

return [{ json: { ...input, risk_level: level, routing, approved: routing === 'AUTO_RUN' }}];

Philosophie ECHO, Pourquoi ne pas faire confiance à l'IA directement ?

Les LLMs sont probabilistes, pas déterministes. Un même prompt peut produire des outputs différents selon le contexte. La validation ECHO est déterministe (un programme classique), elle évalue le risque objectivement, sans hallucination possible. La séparation décision (IA) / validation (ECHO) / exécution (agent) est le principe fondamental d'OS-NEXUS.

Résultat de ce chapitre

Le patron ECHO est configuré dans n8n. Toute tâche est classifiée LOW/MEDIUM/HIGH avant exécution. Les actions HIGH sont bloquées en attente d'approbation humaine.

09

Deploy the 8 agents

~30 min

Chapter objective

The AI Gateway and orchestrator are deployed. All 8 agents are active, each with its n8n trigger. You can fire a task and see an agent execute it.

bash : Deploy AI Gateway + Orchestrator
# On VPS, clone and deploy
git clone https://github.com/umbralabs/ai-agents /opt/umbra
cd /opt/umbra && cp .env.example .env
nano .env  # fill in API keys, Redis URL, etc.
docker compose -f docker/docker-compose.vps.yml up -d --build

# On local machine, start the orchestrator
cd /opt/umbra
python -m agents.orchestrator.router

# Test: trigger the dev agent
curl -X POST http://localhost:8080/task \
  -H "x-api-key: $API_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type":"dev","payload":{"task":"fix bug in cart.js"}}'
{"task_id":"uuid","status":"queued"}

Chapter result

All 8 agents deployed and operational. You can trigger any agent via curl or via an n8n trigger. Sovereign AI is in production.

09

Déployer les 8 agents

~30 min

Objectif de ce chapitre

L'AI Gateway et l'orchestrateur sont déployés. Les 8 agents sont actifs, chacun avec son trigger n8n. Tu peux déclencher une tâche et voir un agent l'exécuter.

bash : Déployer l'AI Gateway + Orchestrateur
# Sur le VPS, cloner et déployer
git clone https://github.com/umbralabs/ai-agents /opt/umbra
cd /opt/umbra && cp .env.example .env
nano .env  # Remplir REDIS_URL, API_SECRET_KEY, credentials APIs

docker compose -f docker/docker-compose.vps.yml up -d --build
curl http://localhost:8080/health
{"status":"online","agent":"umbra-labs-gateway"}  ← attendu

# Sur la machine locale, lancer l'orchestrateur
cd /opt/umbra
docker compose -f docker/docker-compose.local.yml up -d --build
docker logs umbra_orchestrator --tail=5
Orchestrateur Umbra Labs démarré, en écoute sur les queues Redis

Les 8 agents et leurs déclencheurs

AgentDéclencheur n8nType taskLLM
</> Dev/OpsWebhook GitHub Issues/PRsdevqwen2.5-coder:32b
@ SupportPolling IMAP 5min + Discordsupportdeepseek-v2:16b
[o] CreativeWebhook S3/Drive image brutedevqwen2.5:72b
$ GrowthCron ou changement Airtablemarketingqwen2.5:72b
# SocialCron 2x/jour (10h, 17h)socialdeepseek-v2:16b
■ OPSECIssue GitHub ou manuelopsecqwen2.5:72b
▶ UXRapport mensuel automatiqueuxqwen2.5:72b
◆ DesignerBrief UX ou demande composantdesignqwen2.5:72b
bash : Tester un agent manuellement
# Déclencher l'agent Social pour un post Twitter
curl -X POST http://localhost:8080/task \
  -H "Content-Type: application/json" \
  -H "x-api-key: $API_SECRET_KEY" \
  -d '{
    "type": "social",
    "payload": {
      "topic": "Pourquoi auto-héberger son IA en 2026",
      "platforms": ["twitter", "linkedin"],
      "format": "thread",
      "tone": "educatif"
    },
    "risk_level": "LOW"
  }'

{"task_id":"uuid","status":"queued","message":"Routé vers agent [social]"}

# Vérifier le résultat
curl http://localhost:8080/task/uuid
{"task_id":"uuid","status":"completed","result":{"output":"Thread créé..."}}

Résultat de ce chapitre

Les 8 agents sont déployés et opérationnels. Tu peux déclencher n'importe quel agent via curl ou via un trigger n8n. L'IA souveraine est en production.

10

Verify and maintain the infrastructure

~15 min

Chapter objective

You've validated each infrastructure component. You know how to monitor, update, and diagnose common problems.

bash : Full verification script
#!/bin/bash
# Save as verify.sh and run: bash verify.sh

echo "=== OS-NEXUS INFRA VERIFICATION ==="

ping -c 1 100.64.0.1 &>/dev/null && echo "✓ WireGuard VPN active" || echo "✗ VPN DOWN"
curl -sf https://vpn.yourdomain.io/health &>/dev/null && echo "✓ Headscale OK" || echo "✗ Headscale DOWN"
curl -sf https://n8n.yourdomain.io/healthz &>/dev/null && echo "✓ n8n OK" || echo "✗ n8n DOWN"
curl -sf http://100.64.0.1:8080/health &>/dev/null && echo "✓ AI Gateway OK" || echo "✗ Gateway DOWN"
curl -sf http://100.64.0.1:11434/api/tags &>/dev/null && echo "✓ Ollama VPS OK" || echo "✗ Ollama VPS DOWN"
curl -sf http://localhost:11434/api/tags &>/dev/null && echo "✓ Ollama Local OK" || echo "✗ Ollama Local DOWN"
docker run --rm --runtime=runsc alpine echo "ok" &>/dev/null && echo "✓ gVisor OK" || echo "✗ gVisor DOWN"

echo "=== END ==="

Congratulations, Sovereign AI infrastructure operational

You've deployed a complete multi-agent AI infrastructure. 8 agents, local LLMs, zero commercial API, zero third-party logs. Everything runs under your control.

10

Vérifier et maintenir l'infrastructure

~15 min

Objectif de ce chapitre

Tu as validé chaque composant de l'infra. Tu sais comment surveiller, mettre à jour et diagnostiquer les problèmes courants.

bash : Script de vérification complète
#!/bin/bash
# Coller dans verify.sh et lancer : bash verify.sh

echo "=== VÉRIFICATION INFRA OS-NEXUS ==="

# 1. VPN
ping -c 1 100.64.0.1 &>/dev/null && echo "✓ VPN WireGuard actif" || echo "✗ VPN DOWN"

# 2. Headscale
curl -sf https://vpn.tondomaine.io/health &>/dev/null && echo "✓ Headscale OK" || echo "✗ Headscale DOWN"

# 3. n8n
curl -sf https://n8n.tondomaine.io/healthz &>/dev/null && echo "✓ n8n OK" || echo "✗ n8n DOWN"

# 4. AI Gateway
curl -sf http://100.64.0.1:8080/health &>/dev/null && echo "✓ AI Gateway OK" || echo "✗ Gateway DOWN"

# 5. Ollama VPS
curl -sf http://100.64.0.1:11434/api/tags &>/dev/null && echo "✓ Ollama VPS OK" || echo "✗ Ollama VPS DOWN"

# 6. Ollama Local
curl -sf http://localhost:11434/api/tags &>/dev/null && echo "✓ Ollama Local OK" || echo "✗ Ollama Local DOWN"

# 7. gVisor
docker run --rm --runtime=runsc alpine echo "ok" &>/dev/null && echo "✓ gVisor OK" || echo "✗ gVisor DOWN"

echo "=== FIN ==="

Bravo, Infrastructure IA Souveraine opérationnelle

Tu as déployé une infrastructure multi-agents IA complète. 8 agents, LLMs locaux, zéro API commerciale, zéro log chez un tiers. Tout tourne sous ton contrôle.

Checklist

Coche chaque point, sauvegardé dans ton navigateur. Check each item, saved in your browser.

?

GlossaireGlossary

CrewAIFramework Python open source pour orchestrer plusieurs agents IA en séquence ou en hiérarchie. Chaque agent a un rôle, un LLM, et des outils.Open source Python framework for orchestrating multiple AI agents in sequence or hierarchy. Each agent has a role, an LLM, and tools.
OllamaServeur d'inférence local pour les LLMs open source. Expose une API compatible OpenAI. Zéro envoi de données externe.Local inference server for open source LLMs. Exposes an OpenAI-compatible API. Zero external data transmission.
n8nOrchestrateur de workflows visuels self-hosted. Connecte des services (GitHub, email, Discord...) et déclenche les agents via webhooks ou cron.Self-hosted visual workflow orchestrator. Connects services (GitHub, email, Discord...) and triggers agents via webhooks or cron.
gVisor / SentrySandbox de conteneur Google. Sentry est un noyau invité en espace utilisateur qui intercepte les syscalls du conteneur avant qu'ils atteignent le kernel hôte.Google container sandbox. Sentry is a user-space guest kernel that intercepts container syscalls before they reach the host kernel.
ECHO PatternArchitecture d'OS-NEXUS : l'agent produit une intention JSON, n8n évalue le risque de façon déterministe (LOW/MEDIUM/HIGH), puis route vers exécution, sandbox ou humain.OS-NEXUS architecture: the agent produces a JSON intent, n8n evaluates risk deterministically (LOW/MEDIUM/HIGH), then routes to execution, sandbox, or human.
VRAMVideo RAM, mémoire du GPU. Les LLMs ont besoin de VRAM pour stocker leurs poids (paramètres). Un modèle 32B en Q4 ≈ 20 Go de VRAM.Video RAM, GPU memory. LLMs need VRAM to store their weights (parameters). A 32B Q4 model ≈ 20 GB of VRAM.
QuantizationCompression d'un LLM en réduisant la précision des paramètres (FP32 → Q4 = 4 bits). Réduit la VRAM requise de ~4-8× avec une perte de qualité de ~3-5%.Compressing an LLM by reducing parameter precision (FP32 → Q4 = 4 bits). Reduces required VRAM by ~4-8× with ~3-5% quality loss.
RAGRetrieval-Augmented Generation. Technique qui injecte des documents pertinents dans le contexte du LLM avant de générer. Permet d'utiliser une base de connaissances locale.Retrieval-Augmented Generation. Technique that injects relevant documents into the LLM context before generating. Allows using a local knowledge base.
RedisBase de données en mémoire ultra-rapide. Utilisée comme file d'attente de tâches dans OS-NEXUS. L'orchestrateur local "tire" les tâches (pull-based, zéro connexion entrante).Ultra-fast in-memory database. Used as task queue in OS-NEXUS. The local orchestrator "pulls" tasks (pull-based, zero incoming connections).
Pull-basedArchitecture où le client (machine locale) interroge régulièrement le serveur pour de nouvelles tâches. Opposé au push-based où le serveur envoie directement. Avantage : aucun port ouvert côté client.Architecture where the client (local machine) regularly polls the server for new tasks. Opposite of push-based where the server sends directly. Advantage: no open ports on the client side.
FAQ

Questions fréquentesFrequently asked questions

Pour les tâches d'entreprise (code, emails, analyse, copywriting) : oui, les modèles 32B+ quantisés en Q4 sont comparables à GPT-4-Turbo sur la plupart des benchmarks.For business tasks (code, emails, analysis, copywriting): yes, 32B+ Q4 models are comparable to GPT-4-Turbo on most benchmarks. The difference shows on very complex multi-step reasoning where GPT-4o remains slightly superior. For 90% of OS-NEXUS use cases: open source is more than sufficient.
Non. L'orchestrateur local est en mode pull : il consomme des tâches de Redis quand il est allumé.No. The local orchestrator is in pull mode: it consumes tasks from Redis when on. Tasks accumulate in Redis during absence (1 hour TTL by default). In practice: for Support and Social agents (latency-sensitive), the local machine should be on. For Dev and Marketing agents (async tasks), a few hours per day is enough.
n8n et les triggers s'arrêtent, l'orchestrateur local ne peut plus récupérer de tâches. Mais aucune donnée n'est perdue (PostgreSQL persiste l'état).n8n and triggers stop, the local orchestrator can no longer fetch tasks. But no data is lost (PostgreSQL persists state). Maximum resilience requires a secondary VPS with automatic failover, beyond the scope of this tutorial. For personal infrastructure, a VPS with 99.9% uptime (1984 Hosting) is sufficient.
ollama pull nom-du-modele télécharge la dernière version et remplace l'ancienne automatiquement.ollama pull model-name downloads the latest version and replaces the old one automatically. Ollama handles versioning. In production, schedule overnight updates via cron to avoid interrupting agents.
Oui. Crée un nouveau dossier agents/mon_agent/crew.py avec les fonctions _build_agents() et run(payload).Yes. Create a new folder agents/my_agent/crew.py with functions _build_agents() and run(payload). Add the type in main.py (TASK_ROUTES) and in agents/orchestrator/router.py (mapping). Then create the corresponding n8n workflow with its trigger.

Prochaines étapes

Aller plus loin

PRÉREQUIS

VPN Souverain avec Headscale

Le tunnel WireGuard expliqué en détail.

ARTICLE

CLOUD Act : les faits

Pourquoi OpenAI ne suffit pas légalement.

RÉFÉRENCE

Architecture OS-NEXUS

Dashboard interactif des 8 agents.

Tu as aimé ce tutoriel ? Enjoyed this tutorial?

Reçois les prochains directement dans ta boîte, LLMs locaux, VPN souverain, IA sans nuage. Get the next ones in your inbox, local LLMs, sovereign VPN, cloudless AI.

Pour que je sache comment m'adresser à toi dans mes emails. So I know what to call you in my emails.

Zéro spam. Désabonnement en 1 clic. Zero spam. Unsubscribe in 1 click.