La détection tourne de façon déterministe, en continu, à coût nul. Un modèle lit les incidents sérieux en moins de deux minutes et vous dit en langage clair ce qui est réel, ce qui est du bruit et ce qu’il faut faire — puis rédige la procédure de réparation. Installé sur votre propre infrastructure, calibré 72 heures sur votre trafic, livré avec sa documentation.
Une seule machine ou une flotte. Pas de SIEM, pas d’agent externe, aucune donnée qui quitte votre serveur.
Ce n’est pas une liste de fonctions à cocher. À l’installation, Sentinel découvre ce qui se trouve sur la machine et écrit un inventaire que vous confirmez — ensuite les collecteurs, les règles de détection et les seuils s’ajustent dessus. Essayez ci-dessous.
Le panneau de droite correspond à ce que l’installation produirait pour la combinaison choisie. Chez vous, les mêmes décisions se prennent à partir de ce qu’elle trouve réellement sur la machine — pas de ce que vous avez coché.
Vous n’êtes plus choisi par un humain. Vous êtes une ligne dans une liste générée automatiquement — scannée, classée et priorisée par des programmes qui travaillent en continu, à un coût par cible proche de zéro. La taille de l’entreprise ne vous sort plus de la liste.
Aucun humain ne lit 20 000 événements hostiles par jour, et personne n’écrit à 3 h du matin pourquoi celui-ci compte précisément. Sentinel confie à un modèle la part de jugement — sévérité réelle, faux positif ou non, ce qu’il faut faire, en langage clair — en moins de deux minutes après l’ouverture de l’incident.
Mais la décision de bloquer reste déterministe. Ce n’est pas une limite : c’est la raison pour laquelle vous pouvez laisser le produit tourner seul.
Tourne 24/7, sur chaque événement. Ne dépend de rien hors du serveur.
Si le modèle contredit la règle, vous voyez les deux. Rien n’est réécrit en silence.
Un attaquant peut demander un chemin HTTP contenant des instructions. Sentinel les traite comme des données non fiables, avec des délimiteurs explicites, et le transport qui lit réellement les fichiers du serveur tourne en --permission-mode plan — structurellement incapable de modifier quoi que ce soit. Un test plante IGNORE PREVIOUS INSTRUCTIONS dans un journal d’accès et vérifie que rien n’a été exécuté.
Ce n’est pas un canal de notifications. C’est la console. Vous recevez l’incident avec des boutons d’action, vous bloquez l’attaquant d’une pression, vous demandez l’état du serveur et lancez un correctif — sans VPN, sans SSH, sans ouvrir le portable. Tout ce qui se fait depuis le tableau de bord se fait depuis la conversation.
Vous n’attendez pas d’ouvrir un tableau de bord. L’incident est poussé sur Telegram au moment où la règle se déclenche, avec la source, le pays, l’ASN, le nombre de tentatives et le verdict IA en langage clair — plus les boutons qui règlent la situation sur place.
Les commandes s’exécutent sur le serveur et répondent en moins d’une seconde. Celles qui changent quelque chose demandent une confirmation séparée, et les destructrices une seconde qui redit la cible.
/dashboard/status/incidents
/vulnerabilities/services/health
/events/blocked/patches
/selfcheck
/block/unblock
/resolve/falsepositive
/quiet/panic
Le vert lit, le rouge modifie. Les commandes existent en anglais et en roumain — l’affichage suit la langue du bot.
Le bot tire les messages, il ne les reçoit pas : aucun port ouvert ne pointe vers lui et il n’y a pas d’endpoint public à falsifier. Si nginx, TLS ou le tableau de bord tombent, le canal tient — donc il est disponible à la minute exacte où vous en avez besoin.
Telegram, c’est pour la minute de l’incident. Le panneau, c’est pour tout le reste : ce qui vous attaque, ce qui est ouvert, ce qui mérite d’être corrigé en premier — et, sous chaque constat, la commande qui le règle.
« root est la cible n° 1 — 12 813 tentatives depuis 938 adresses », et juste en dessous grep PermitRootLogin /etc/ssh/sshd_config. Chaque constat arrive avec son action, écrite noir sur blanc. Rien à déduire seul d’un diagramme.
812 ouvertes ne veut pas dire 812 à corriger. Le feu tricolore SSVC de la CISA les ordonne selon l’exploitation réelle (KEV, EPSS), le vecteur et la criticité de l’actif : cinq demandent attention, deux sont exploitées en ce moment même. Gris signifie que les données manquent, pas que tout va bien.
Pas seulement des adresses, mais des opérateurs. Quand 4 137 événements viennent de deux adresses du même réseau, ce n’est pas un botnet de machines compromises : c’est une infrastructure louée pour l’attaque, et la prochaine adresse viendra du même endroit. On bloque la plage, pas l’adresse.
Les incidents sont regroupés par la famille de règle qui les a produits. Une campagne reste active tant qu’elle reçoit de nouveaux incidents ; si elle disparaît de la liste, ce front s’est arrêté — il n’a pas cessé d’être surveillé.
Les services découverts sur la machine, chacun étiqueté public ou protégé, avec latence et disponibilité sur 24 heures. La liste se rafraîchit seule : un service démarré aujourd’hui apparaît aujourd’hui — y compris celui que vous avez laissé ouvert.
Vous voyez chaque adresse bloquée, le motif et l’heure d’expiration, et vous pouvez débloquer. Vous ne pouvez pas bloquer : un tableau de bord compromis ne doit pouvoir bloquer personne. Le blocage reste dans Telegram, ou dans la règle.
Un programme qui vous garde et qui est, en même temps, le seul à pouvoir donner l’alerte a un défaut de conception : qui l’arrête arrête aussi l’alerte. Le silence qui suit ressemble exactement à une nuit où personne n’a rien tenté.
Chaque instance envoie un signe de vie à une page qui tourne sur une autre machine que les serveurs surveillés. Cette page ne fait rien d’autre qu’écouter. Si le signal s’arrête, l’alerte part de là, par Telegram — pas du serveur qui vient de se taire.
La même page affiche l’autodiagnostic de chaque instance, exécuté toutes les cinq minutes. Vous n’avez pas à croire l’agent sur parole quand il tombe. Ce n’est pas lui qui vous le dit.
La licence est par serveur. La configuration initiale et le calibrage de 72 heures sont inclus dans toutes les formules — sans eux, un agent capable de bloquer du trafic est un risque, pas une protection.
Pour les équipes qui ont déjà quelqu’un de technique et veulent seulement l’outil, bien configuré.
Pour les entreprises sans responsable sécurité dédié. Nous surveillons, vous décidez de ce qui s’applique.
Pour plusieurs serveurs ou clients. Configuration par machine, vue unifiée.
Nous regardons ce qui est exposé, ce qui vous attaque en ce moment, quelles vulnérabilités sont ouvertes et à quelle vitesse vous sauriez que quelqu’un est entré. Nous n’installons rien à ce stade.
jour 1–2 · sans engagementLa découverte propose ce qu’elle a trouvé sur la machine ; vous confirmez ce qui est critique, ce qui n’est jamais touché automatiquement et qui doit toujours passer — sondes, bureau, CI.
jour 3Une heure sur un serveur propre. Rien de ce qui tournait avant ne s’arrête : l’installation compare avec l’état précédent et revient en arrière automatiquement si quelque chose a changé.
jour 3 · ~1 heure72 heures pendant lesquelles le blocage automatique est coupé et vous recevez seulement ce qu’il aurait bloqué. C’est là que sortent les faux positifs : la sonde de disponibilité, la validation des certificats, votre IP mobile.
jour 4–6Nous activons le blocage automatique avec les seuils ajustés, nous vous donnons l’accès au tableau de bord et au bot, plus la documentation d’exploitation. À partir de là, il tourne seul.
jour 7Chaque fournisseur vous dit ce que fait le produit. Quand un logiciel obtient les droits root sur votre serveur, la question qui compte est autre : ce qu’il n’a pas le droit de faire, et qui l’arrête.
Votre adresse d’administration, les réseaux privés et la boucle locale figurent dans une liste codée en dur dans le source — pas dans la configuration, pas dans la base. Compromettre la base ne peut pas l’élargir.
La règle de base est policy accept. C’est une liste de refus, pas un pare-feu. Si le processus meurt, si la base tombe ou si la configuration est fausse, le trafic passe.
Délibéré : un redémarrage est toujours une sortie d’un blocage qu’on s’est infligé. Plus un fichier PANIC qui vide tout en moins de 60 secondes, surveillé par un processus indépendant.
La génération du plan est automatique. L’application demande deux confirmations explicites sur le téléphone, et le bouton meurt si le plan est régénéré.
L’interface est le composant le plus exposé : elle n’a donc aucun chemin vers les actions privilégiées. La compromettre fait fuiter des données ; elle ne peut ni bloquer, ni débloquer, ni appliquer quoi que ce soit.
Les lignes de log et les chemins HTTP sont écrits par l’attaquant. Ils sont traités comme des données non fiables, et un test plante IGNORE PREVIOUS INSTRUCTIONS dans un journal d’accès puis vérifie que rien n’a été exécuté.
Afficher un chiffre rond et un graphique bien rempli est facile. Dire où s’arrête la mesure l’est moins, et sert davantage. Les notes ci-dessous sont dans le panneau, chez les clients — pas seulement sur cette page.
Les 5 000 premières lignes ont été lues, le reste n’a pas été compté. Tout agrégateur a un plafond de lecture ; la différence, c’est qu’il vous le dise. « Au moins autant » est une information sur laquelle s’appuyer dans un sens. « Exactement autant, sans doute » ne l’est pas.
Un compteur envoyé au milieu de son heure se lirait comme une chute de trafic qui n’a jamais eu lieu. La dernière barre est donc absente du graphique, et la raison est écrite dessous. Nous avons vu assez de gens décider sur cette barre.
Un collecteur arrêté et un collecteur qui traverse une journée calme produisent la même chose : zéro. Le silence est prouvé par le voisin qui utilise le même lecteur et qui, exposé à internet, ne se tait jamais. Aucun composant en plus.
Vingt-deux vulnérabilités restent déclarées non évaluées, plutôt que passées au vert pour que le total ait meilleure allure. Le seul écart au modèle SSVC y est écrit aussi, avec son motif.
Aucune de ces notes n’aide à vendre. Toutes les quatre rendent le reste des chiffres vérifiable — et quand on donne à un programme les droits root sur son serveur, c’est la seule propriété qui compte.
Les chiffres ci-dessous viennent du dépôt, pas d’une présentation.
Les manques sont déclarés, pas cachés : les journaux des conteneurs ne sont pas encore collectés, il n’y a pas de moniteur d’intégrité de fichiers dédié au-delà d’auditd, et l’installation Debian est couverte par des tests mais pas encore vérifiée sur un hôte Debian réel. Nous le disons avant le contrat, pas après.
Trente minutes, gratuites et sans engagement. Vous nous dites quel serveur vous avez et ce qui tourne dessus. Nous vous disons ce qui est exposé, ce qui vous attaque en ce moment et si Sentinel a du sens pour vous — y compris quand la réponse est « pas encore ».
Une expertise de niveau grand compte. Livrée vite. Sans surcouche, sans jargon, sans surprises.