Pourquoi les MSPs choisissent monsys.ai comme plateforme monitoring + conformité
€3/serveur/mois à partir du 6e serveur, MSP Cockpit avec tous les clients sur un écran, impersonation RBAC, EATs pré-émis pour les heures non ouvrables et rapports mensuels signés. Plus un calcul de marge honnête.
En tant que MSP, vous tournez sur la marge. Chaque outil que vous achetez doit être récupéré via la prestation. Une plateforme de monitoring à €15-20/agent/mois grignote votre marge avant d'avoir facturé une seule heure.
Mais le vrai coût du monitoring n'est pas la licence — c'est le temps que vos ingénieurs passent à gérer des outils disjoints. Alerte dans l'outil A, CVE dans l'outil B, conformité dans l'outil C, export audit dans l'outil D. Chaque mois, tout rassembler à la main pour le rapport client.
Cet article explique comment monsys.ai fonctionne comme plateforme MSP, ce qu'elle apporte, et quel est le coût réel.
Le modèle MSP : €3/agent/mois, cinq premiers gratuits
La tarification est simple : les cinq premiers agents par tenant sont gratuits, à vie. À partir du sixième agent vous payez €3/agent/mois via Stripe ou PayPal, résiliable mensuellement.
Un client avec 20 serveurs : (20 - 5) × €3 = €45/mois. Un client avec 50 serveurs : €135/mois.
En tant que MSP vous pouvez refacturer à €8-15/serveur/mois et garder une marge saine sur le monitoring, y compris la couche conformité et audit qui aurait sinon dû être achetée séparément.
Aucune licence MSP ou channel-agreement nécessaire. Vous créez un compte par client (chaque client a son propre tenant avec isolation RLS), et vous gérez le tout depuis un MSP Cockpit unique.
Le MSP Cockpit : 20+ clients sur un seul écran
Le plus gros point douloureux pour les ingénieurs MSP est le context-switching. Se connecter à chaque client, reconstruire la situation, se déconnecter, recommencer. Le MSP Cockpit résout cela.
Le MSP Cockpit liste tous les tenants sur un écran, triés par un score d'urgence combinant alertes critical ouvertes, CVE KEV, breaches SLA et deltas Trust Score.
Un clic « Open in tenant context » utilise l'impersonation RBAC — vous travaillez dans le contexte client sans vous reconnecter, et chaque action exécutée est journalisée avec votre email comme acteur.
Impersonation RBAC : transparence envers le client
Les ingénieurs MSP travaillent au nom des clients. Cela crée des obligations de transparence et de traçabilité, surtout sous NIS2.
Quand un admin MSP entre dans un environnement client, une session scopée est créée avec un token à durée limitée et une raison obligatoire. Chaque action dans cette session est journalisée avec votre user ID ET le tenant client. Le client voit dans son propre audit-pack mensuel exactement quand vous avez géré son environnement et ce que vous avez fait.
La page RBAC montre par utilisateur quel rôle sur quel scope (tenant-wide ou limité à un groupe / agent spécifique).
Pas de surprises. Pas de zones grises sur qui a exécuté quelle action.
Emergency Action Tokens pré-émis : couverture hors-heures sans réveiller personne
Problème que tout MSP connaît : un incident critique à 2h du matin. Votre ingénieur est prêt mais doit d'abord se connecter, entrer TOTP, créer un Emergency Action Token. Ce sont cinq minutes en plus quand un chiffrement ransomware est actif.
La solution : EATs pré-émis. Vous créez un Emergency Action Token pour un agent spécifique, avec une fenêtre de validité et une condition d'activation. Pendant cette fenêtre, si l'agent rencontre la condition, il exécute l'action lui-même. Single-use nonce, audit trail complet. Votre ingénieur n'a qu'à vérifier le matin que tout s'est bien passé.
Les playbooks définissent ce qu'un EAT peut exécuter — d'isolate-network à rotate-secrets. Les EATs pré-émis référencent un playbook + une condition d'activation.
Multi-party signing : principe des quatre yeux pour les actions destructrices
Pour les actions irréversibles — restore production database, rotation secrets sur toute la fleet, isolation réseau d'un serveur core — vous voulez un principe des quatre yeux. Les EATs niveau 3 exigent quorum : deux ingénieurs MSP, chacun avec son propre code TOTP, un ingénieur ne peut pas faire deux approbations. Le client voit dans son audit-pack « action exécutée via quorum 2-sur-2 ». C'est une preuve forte pour SOC2 separation-of-duties.
Le rapport mensuel : que livrez-vous au client ?
Chaque mois un client — ou son auditeur — demande ce qui a été fait. Le rapport mensuel monsys est un PDF + JSONL signé que le client peut vérifier offline lui-même.
Les audit packs mensuels sont générés automatiquement. Filtre par MSP-actor pour ne montrer que les actions de votre équipe dans le rapport.
Le client vérifie le PDF offline avec une CLI standalone ; pas de compte monsys nécessaire, pas d'appel réseau. Ce n'est pas votre parole, mais une preuve cryptographique.
White-label : votre marque, votre portail client
Les clients voient votre brand, pas monsys.ai. Par tenant vous configurez : logo, couleur primaire, nom de produit et optionnellement un domaine custom. Le client ouvre ops.client.com et voit son propre logo, votre nom en footer en « powered by ». Il a un accès read-only à son dashboard et peut télécharger ses propres preuves d'audit — mais pas d'actions admin.
Vérification pricing : que gagnez-vous en tant que MSP ?
Supposons que vous gérez 15 clients moyennant 12 serveurs par client :
| Coût monsys | Refacturation @€10/serveur | Marge | |
|---|---|---|---|
| Par client (12 serveurs) | (12-5) × €3 = €21/mois | 12 × €10 = €120/mois | €99/mois |
| Tous les 15 clients | €315/mois | €1.800/mois | €1.485/mois |
La couche conformité et audit (preuve NIS2, evidence packs, Trust Score) est incluse dans ces €3/agent.
Ce que les MSPs rapportent comme raison principale de switcher
Basé sur des conversations avec des opérateurs MSP qui ont évalué :
« Nous utilisions Zabbix pour le monitoring et un outil séparé pour le reporting conformité. Deux outils = deux logins, deux datasources, et fusion manuelle chaque mois. Avec monsys c'est un outil avec une API. »
« La vérification client a fait la différence. Nous envoyons maintenant un PDF signé que le client peut vérifier lui-même. C'est une autre conversation qu'un export Excel. »
« Les EATs pré-émis pour les heures non ouvrables ont évité deux escalades. L'ingénieur a vu le matin que l'EAT d'isolation s'était activé et rollback sans que personne ne soit réveillé. »
Ce que nous n'offrons pas (être honnête)
Les MSPs qui cherchent une plateforme SOC complète avec détection managée 24/7, flux de threat intelligence, et incident response dédiée — monsys n'a pas été construit pour cela. Nous sommes une plateforme monitoring + conformité pour MSPs qui sont eux-mêmes la première ligne.
Pour les MSPs qui doivent livrer des preuves NIS2, suivre les CVE, et produire des rapports mensuels pour 10-50 clients : c'est précisément le use case pour lequel monsys a été construit.
Les workflows MSP sont documentés dans docs.monsys.ai/fr/practical/msp. Contactez-nous pour un onboarding MSP : info@gotrust.be.