Pas de magie. Un pipeline en 5 phases. Chaque connecteur est généré, testé, validé — ou corrigé automatiquement.
Du trafic réseau brut au connecteur fonctionnel. Entièrement automatique.
Dès que NOVA est branchée, le moteur d'auscultation (294 signatures) scanne le réseau. Chaque équipement est identifié. Si un service est inconnu — c'est-à-dire qu'il répond sur un port mais n'a pas de signature connue — le pipeline auto-adaptatif se déclenche automatiquement.
# Étape 1 : sniff passif (tcpdump + analyse) $ nova sniff --target 192.168.1.50:8080 --duration 10s → Protocole détecté : HTTP/1.1 → Auth détectée : Bearer token (header Authorization) → Format données : JSON → Endpoints : /api/v1/devices, /api/v1/readings → Codes erreur : 401, 403, 429, 500
Les données brutes (headers, payloads JSON, patterns d'erreur) sont envoyées à Synapse avec un prompt spécialisé. Le noyau analyse la structure et génère un modèle sémantique du service — une description structurée de ce que fait le service, comment l'authentifier, et comment mapper les données.
# Prompt envoyé à Synapse (simplifié)
You are a connector architect. Analyze this service:
PROTOCOL: HTTP/1.1
AUTH: Bearer token in Authorization header
ENDPOINTS:
GET /api/v1/devices → [{id, name, status, last_seen}]
GET /api/v1/readings?device_id=X → [{timestamp, value, unit}]
ERRORS: 401=unauthorized, 429=rate_limit
Generate:
1. Service classification (what is this?)
2. Data model (fields, types, relations)
3. Sync strategy (poll? webhook? interval?)
4. Cockpit UI (what to display?)
Le noyau produit un connecteur Python complet. Chaque connecteur suit une interface standard : 6 méthodes obligatoires. C'est cette standardisation qui permet à NOVA d'utiliser n'importe quel connecteur immédiatement.
# Structure standard de tout connecteur NOVA class Connector: def connect(self) -> bool: # Établit la connexion def authenticate(self) -> bool: # Gère l'authentification def discover(self) -> list: # Découvre les ressources disponibles def read(self, resource) -> dict: # Lit les données def write(self, resource, data): # Écrit/modifie (si applicable) def health(self) -> str: # Vérifie l'état du service def sync_schema(self) -> dict: # Décrit le schéma pour le cockpit
6 tests obligatoires. Chaque connecteur doit TOUS les passer avant d'être activé.
→ Test 1 Connexion : ✅ (socket TCP OK, TLS validé)
→ Test 2 Authentification : ✅ (Bearer token accepté)
→ Test 3 Lecture : ✅ (23 devices lus, 0 perte)
→ Test 4 Écriture : ⚠️ (N/A — read-only service)
→ Test 5 Erreurs : ✅ (401/429/500 gérés correctement)
→ Test 6 Performance : ✅ (latence moyenne 340ms)
SCORE FINAL : 92/100 — CONNECTEUR ACTIVÉ
Si score < 80 → retour en phase 2 (max 3 corrections auto)
Si toujours < 80 après 3 itérations → mode manuel (l'humain révise)
nova adapt 192.168.1.50:8080.httpx. SQL → sqlalchemy. Modbus → pymodbus. SIP → pjsua2. MQTT → paho-mqtt. Chaque connecteur est un micro-service isolé dans un conteneur Docker dédié, avec son propre réseau, ses propres credentials, et son propre cycle de vie.Après 3 échecs consécutifs du pipeline auto-adaptatif, NOVA passe en mode assistance humaine. Elle ne bloque pas — elle prépare un dossier d'intervention complet.
📋 DOSSIER D'INTERVENTION #NOVA-2026-0781
─────────────────────────────────────────────
Service : 192.168.1.50:8443
Protocole : TCP/TLS, payload binaire propriétaire
Détecté le : 06/07/2026 14:32
Tentatives : 3 échecs
Score max : 41/100 (Tentative 2)
📦 FICHIERS ATTACHÉS
├── capture.pcap (trafic brut, 30s)
├── tentative_1/ (logs + code généré)
├── tentative_2/ (meilleure tentative)
├── tentative_3/ (logs + code généré)
└── analyse_deepseek.json (modèle sémantique)
🔍 CE QUE NOVA A COMPRIS
├── Protocole probable : Modbus TCP (confiance 72%)
├── Structure trame : partiellement identifiée
├── Auth : non détectée
└── Raison échec : payload binaire non standard
❓ CE DONT NOVA A BESOIN
├── [ ] Spécification du protocole (PDF, doc, RFC)
├── [ ] Credentials de test (login/mdp ou token)
├── [ ] Accès direct au service pour test
└── [ ] Exemple de payload valide (requête + réponse)
L'humain peut alors :
🔧 Option 1 — Fournir la spec : uploader un PDF/RFC/documentation du protocole. Synapse le lit et retente la génération avec ce contexte supplémentaire.
✏️ Option 2 — Éditer le connecteur : ouvrir le code généré (tentative_2, le meilleur score) et le corriger manuellement dans l'éditeur intégré du cockpit.
🔐 Option 3 — Fournir des credentials : entrer un login/mdp ou token de test pour que NOVA puisse interagir avec le service et apprendre de ses réponses.
📡 Option 4 — Donner accès : autoriser NOVA à se connecter directement au service. Elle observe les vrais échanges et affine le connecteur.
🧬 Option 5 — Écrire un template : si le protocole est totalement inconnu, l'humain peut écrire un squelette de connecteur manuellement. NOVA l'utilise comme base pour les futurs services similaires.
10 catégories d'échecs. Une stratégie pour chacune.
┌─────────────────────────────┬────────┬──────────────────────────┐
│ DIFFICULTÉ │ FRÉQ. │ RÉSOLUTION │
├─────────────────────────────┼────────┼──────────────────────────┤
│ Protocole propriétaire │ 40% │ 👤 Spec ou doc requise │
│ Chiffrement opaque │ 20% │ 👤 Certificat ou accès │
│ Authentification exotique │ 12% │ 👤 Credentials de test │
│ Format non standard │ 10% │ 🤖👤 Parsing + spec │
│ Stateful complexe │ 6% │ 🤖 Machine d'état │
│ Rate limiting │ 4% │ 🤖 Backoff automatique │
│ Service instable │ 3% │ 🤖 Retry + mode dégradé │
│ Dépendances cachées │ 2% │ 👤 Config réseau │
│ Encodage non standard │ 2% │ 🤖 Force-brute décodeurs │
│ Streaming / temps réel │ 1% │ 👤 Identification manuelle│
├─────────────────────────────┼────────┼──────────────────────────┤
│ 🤖 Automatique │ 13% │ Zéro humain │
│ 👤 Assistance humaine │ 72% │ 5 options disponibles │
│ 🤖👤 Mixte │ 15% │ Auto + validation │
└─────────────────────────────┴────────┴──────────────────────────┘
TOTAL : 85% résolus automatiquement. 15% nécessitent l'humain.
Le taux s'améliore à chaque nouveau connecteur créé.
Une seule approche architecturale qui rend 6 des 10 problèmes caducs. Le Connecteur Passif par Observation.
Au lieu d'interroger le service (mode actif), NOVA observe les échanges réels entre le client légitime et le service (mode passif). Elle s'intercale comme un proxy transparent, déchiffre le trafic, et apprend du vrai comportement — sans jamais perturber le service.
┌─────────────────────────────────────────────────────────────┐ │ MODE PASSIF — APPRENTISSAGE PAR OBSERVATION │ │ │ │ ┌──────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Client │────▶│ NOVA PROXY │────▶│ Service │ │ │ │ légitime │◀────│ (MITM) │◀────│ legacy │ │ │ └──────────┘ └──────┬───────┘ └──────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────┐ │ │ │ OBSERVATION │ │ │ │ + APPRENTI- │ │ │ │ SSAGE │ │ │ └──────┬───────┘ │ │ │ │ │ ▼ │ │ ┌──────────────┐ │ │ │ CONNECTEUR │ │ │ │ GÉNÉRÉ │ │ │ └──────────────┘ │ │ │ │ Ce que NOVA capture : │ │ ▸ Requêtes réelles (pas des probes) │ │ ▸ Réponses réelles (pas des erreurs) │ │ ▸ Séquence exacte des échanges │ │ ▸ Authentification réelle (token, session) │ │ ▸ Payloads en clair (après déchiffrement TLS) │ │ ▸ Gestion d'erreurs réelle │ │ ▸ Timing et patterns d'usage │ └─────────────────────────────────────────────────────────────┘
Résultat : 60% des difficultés contournées. Le connecteur est généré à partir de vrais échanges — pas de probes, pas de devinettes, pas de rate limiting. C'est le mode le plus fiable pour les protocoles inconnus.
# Option A — NOVA comme proxy transparent $ nova proxy --target 192.168.1.50:443 --listen 8443 → Le client pointe vers NOVA:8443 au lieu du service → NOVA déchiffre, observe, forwarde → Temps d'observation recommandé : 5-10 minutes # Option B — NOVA sniff le trafic (mode promiscuous) $ nova sniff --interface eth0 --host 192.168.1.50 --duration 10m → Capture passive sur le switch (port mirroring) → Zéro modification du réseau existant → Extraction des patterns après capture # Option C — Import d'un PCAP existant $ nova learn --pcap capture.pcap --host 192.168.1.50 → Upload d'une capture Wireshark/tcpdump → Synapse analyse hors ligne → Connecteur généré sans accès direct au service
┌──────────────────────────┬──────────┬──────────┬──────────┐
│ MODE │ SUCCÈS │ ÉCHEC │ HUMAIN │
├──────────────────────────┼──────────┼──────────┼──────────┤
│ Actif seul (sniff+probe) │ 85% │ 15% │ requis │
│ Passif (proxy/sniff) │ 96% │ 4% │ optionnel│
│ Passif + Actif (combiné) │ 99% │ 1% │ rarissime│
└──────────────────────────┴──────────┴──────────┴──────────┘
AVEC le mode passif : 99% des services → connecteur fonctionnel.
Les 1% restants = protocoles air-gapped ou physiquement inaccessibles.