Monsys surveille vos serveurs Linux et Windows, scanne chaque dépendance npm/pip/composer/go contre OSV.dev, prend l'empreinte de chaque binaire en cours d'exécution et pose des honeypots qui s'allument dès qu'on les touche. Sur un environnement type, nous remontons en 90 secondes des centaines de matches CVE — dont plusieurs CRITICAL que l'opérateur ignorait avoir en production. Délai entre détection et correctif : quelques minutes, pas des semaines.
Trois différences qui atterrissent directement dans le rapport d'audit de votre client.
Lockfiles npm, pip, composer, go et gem par projet contre OSV.dev. Images conteneurs via Trivy côté hub — aucun logiciel supplémentaire sur l'hôte client. Process DNA détecte quand un binaire est remplacé silencieusement.
Seuils avec durée ('CPU >85% pendant 1h'), règles par conteneur, fenêtres de maintenance pour les upgrades. Honeypots (faux clés AWS, GPG, Kube config, jetons GitLab runner) déclenchent un Critical immédiat. Pas de spam.
Hub hébergé en Belgique par GoTrust BV. Détection sur l'hôte — seuls les signaux agrégés remontent, jamais de logs bruts. Auto-hébergement possible : une seule stack Docker, agent Rust de 5 Mo.
Générez un jeton dans la hub, collez la commande, et l'agent s'enregistre. Pas de ports à ouvrir, pas de YAML.
Essayer gratuitement →Un binaire Rust, quatre catégories de signaux. Tout traité localement ; seuls les agrégats remontent vers la hub.
CPU, RAM, disque, réseau, load — toutes les 15s vers TimescaleDB. 90 jours de rétention par défaut. Sparklines de trafic par NIC, croissance par disque + projection 'days until full'.
Paquets + services + conteneurs + ports ouverts + users locaux + règles sudo + clés SSH (fingerprint seul) + password policy depuis /etc/shadow + arbre lsblk + matériel DMI + NICs + findings filesystem (SUID/SGID/world-writable/orphaned).
10+ canaries avec credentials réalistes : AWS, SSH, Kube, Docker auth, GitLab runner, Postgres pgpass, GPG private key, Grafana token, WordPress config. Une lecture = Critical immédiat via inotify.
Fingerprint SHA256 du binaire de chaque top-process. Baseline TOFU à la première observation ; déviation = Critical. Rebaseline manifest-aware : les auto-updates légitimes ne déclenchent pas de faux-positifs.
Un binaire Rust de 5 Mo lié statiquement (musl libc, aucune dépendance glibc → tourne sur RHEL/Alma/Rocky 8+9, Fedora, Debian 11+12, Ubuntu 18.04+ à 24.04, Alpine 3.10+, SUSE/SLES, Oracle Linux, Amazon Linux). systemd-service ou StartServiceCtrlDispatcher (Windows). Sudoers scopé strictement emergency + self-update. Signature payload Ed25519 avec pinning TOFU côté hub.
Postgres Row Level Security par tenant, tenant_id WHERE explicite sur toutes les queries (défense en profondeur). Rôles Owner / Admin / Operator / Viewer. Chaque écriture en audit_log avec user/IP/payload (secrets scrubbés).
Paquets OS, images conteneurs et dépendances applicatives — tous automatiquement scannés, liés à vos serveurs, avec version corrective et risk score.
apt, rpm, winget et wmic lus par l'agent. La hub matche contre NVD + EPSS (probabilité d'exploit) et attribue un risk score. Les processus exposés à Internet reçoivent 1.5× supplémentaire.
Les agents remontent les noms d'images. La hub fait tourner Trivy côté serveur contre chaque image unique. Aucun Trivy sur l'hôte client, pas de root requis — la sortie `docker ps` suffit.
package-lock.json, yarn.lock, requirements.txt, composer.lock, Gemfile.lock et go.sum parsés. La hub interroge OSV.dev (gratuit, UE-friendly) en batch par (package, version). 14 CRITICAL et 1.984 autres CVE trouvés dans notre flotte de test.
Nous n'envoyons PAS le contenu des lockfiles à notre backend. Uniquement les tuples (package, version) parsés — même info que `npm ls` à quiconque a un shell.
Sur un environnement récemment monitoré (MSP belge, ~10 hôtes prod avec services Node.js + Go), le pipeline a démarré à 16:47. En 90 secondes, OSV.dev avait remonté 1.998 matches — dont 14 CRITICAL inconnues. Toutes patchées avant 17:00.
T+45s
Batch-query OSV.dev → 1.000 tuples (package, version) par requête, sévérité normalisée par la hub
T+5min
10.854 dépendances sur 4 écosystèmes (npm / Go / Packagist / PyPI) — liés au project-path + risk_score
T+13min
L'opérateur voyait la fix-version à côté de chaque CVE ; un `go get` + redeploy. L'auto-update propage la suite.
Pas de rapport de six semaines en retard. Pas de "on s'y met au sprint prochain". La fix-version est à côté de la CVE, le playbook tourne en un clic.
Douze briques que nous avons déjà construites. Chacune de ces fonctionnalités peut être activée aujourd'hui sur votre tenant.
Seuils avec durée (CPU>85% pendant 1h), règles par conteneur, agrégats fleet (≥3 agents prod offline). Fenêtres de maintenance qui taisent TOUTES les alertes pendant les upgrades. 8 templates de démarrage rapide.
Par serveur : régression linéaire sur 14 jours CPU/mem/réseau + croissance par disque. Projection 'days until ceiling' avec date. Pas de prétention ML, juste régression honnête.
Z-score sur les 15 dernières min vs baseline 7 jours par agent par métrique. |z| > 2.5 = anomalie. Statistique classique, pas de black-box — l'opérateur voit immédiatement ce qui sort du lot.
Chaque POST/PUT/PATCH/DELETE avec user/IP/method/path/resource. Rôle 'viewer' bloque les écritures (lecture seule). Filtre clé : /audit?resource_type=playbook scoped par tenant.
Specs JSON d'actions, validées par admin, déclenchées par opérateur depuis une alerte. Hub signe un token Ed25519 → agent vérifie + exécute. Chaque run loggé dans /audit avec le nonce.
Hash SHA256 de /proc/<pid>/exe sur chaque top-process. Déviation = Critical — sauf si le nouveau hash matche notre manifest d'auto-update. Faux-positifs sur deploys exclus.
Faux clés AWS, SSH, Kube config, Docker auth, GitLab runner token, Postgres pgpass, clé privée GPG, token Grafana, config WordPress. Une lecture = Critical immédiat.
Agent + hub reçoivent chacun un release-manifest. Côté hub : poll 6h, curl-download, vérif sha256, installeur sudo, swap atomique, restart systemd. Process DNA manifest-aware accepte le nouveau hash auto.
Logo, couleur d'accent, nom — écrits dans /settings → Branding, vos clients voient leur logo dans la topbar. Backend valide https-only pour les logo URLs (pas de XSS javascript:).
Terminal navigateur via WebSocket — sans port SSH ni RDP. Sous Linux : `bash --restricted` sous l'utilisateur low-priv `monsys-console`, sans sudoers. Sous Windows : PowerShell via ConPTY dans un endpoint JEA avec ~60 cmdlets IR whitelistés (pas d'Invoke-Expression, pas de Remove-Item, pas d'élévation de privilèges). Hard-limit 15 min, TOTP + raison ≥20 caractères requis. Chaque frappe journalisée de manière inaltérable avec scellé SHA256.
Graphe auto-détecté (nodes + edges + zones). Générateur → PNG/SVG/PDF avec 4 algos de layout, export Mermaid. Overlay alertes : rouge=critical, jaune=warn sur chaque node.
Un clic sur alerte/log — llama3.1:8b local explique. Réponses NL/FR/EN, première réponse <4s CPU. Pas de fournisseur IA externe, donc pas de questions GDPR.
Connectez votre compte AWS, Azure, GCP, Hetzner, Proxmox, DigitalOcean, Scaleway, OVH ou IONOS. monsys.ai découvre toutes les ressources toutes les 4 heures, les apparie à vos agents existants et signale ce qui n'est pas surveillé.
EC2 · RDS · S3 · VPC · ELB · IAM
VMs · SQL · Storage · NSGs · VNets
GCE · Cloud SQL · GCS · Firewalls
Servers · Networks · Firewalls · Volumes
Self-hosted: VMs · LXC · Storage · Nodes
Droplets · Volumes · LBs · Managed DBs
Instances · SGs · Volumes · RDB
Instances · Networks · Failover IPs
Datacenters · Servers · Volumes · LANs
Compromis honnêtes — pas de marketing brillant. Pour chaque outil, nous montrons quand monsys est le meilleur choix et quand l'inverse est vrai.
Un llama3.1:8b local explique ce que signifie le log et si une action est nécessaire. Pas de fournisseur d'IA externe — vos données restent sur notre backend.
Pas de jungle YAML, pas de templates par OS — une seule commande par hôte.
Entrez email + mot de passe. Pas de carte bancaire. Vous obtenez immédiatement un tenant et un login dashboard.
Dans Settings → Agents tapez un hostname. Nous générons un token et vous donnons une commande one-liner. Sur le serveur cible : une commande curl en root.
En 30s vous voyez CPU/RAM/disque/réseau de l'hôte dans l'écran Overview. Les alertes se déclenchent dès le premier dépassement de seuil.
Surveiller cinq serveurs coûte zéro euro. À vie. À partir du sixième serveur : €3 par serveur par mois — via Stripe ou PayPal, résiliable au mois.