Nos contrôles regardent uniquement ce que n’importe qui peut déjà voir depuis Internet — c’est précisément ce qu’un attaquant regarde en premier. Aucun compte, rien à installer, et rien n’est forcé : les contrôles sont non intrusifs.
Un lien est un lien, qu’il arrive par SMS, WhatsApp, un réseau social ou un e-mail. Nous suivons les premiers liens jusqu’à leur vraie destination, après avoir retiré les paramètres qui pourraient vous identifier. Aucun formulaire n’est rempli, aucun code n’est saisi, aucun fichier n’est exécuté.
Sur chaque lien, nous croisons plusieurs signaux :
Quelques mots dans le message — « voter pour », « ma nièce », « concours », « votre compte va être fermé » — sont un piège classique. Seuls, ils ne prouvent rien ; combinés à un lien suspect, ils déclenchent l’alerte.
Pour un e-mail, nous lisons aussi les contrôles d’expéditeur enregistrés par le serveur qui l’a reçu (SPF, DKIM, DMARC) et les pièces jointes — lues comme des fichiers, jamais ouvertes.
Le verdict donne un niveau de risque, du plus neutre au plus sérieux, fixé par le pire signal trouvé. Pour rester efficaces, nous ne publions pas les seuils exacts que nous utilisons — ce serait donner aux escrocs un guide pour passer entre les mailles.
Ce que nous conservons : un journal de chaque contrôle (date, heure, adresse IP, type) pendant 12 mois ; le texte du message pendant 30 jours, pour améliorer la détection ; et les adresses des liens dangereux, sans leurs paramètres et sans aucun lien avec vous. Les liens sont comparés à une copie de la base URLhaus (abuse.ch) conservée sur nos serveurs : aucun lien n’en sort. Détails dans notre politique de confidentialité.
Environ 138 vérifications (204 règles) réparties en 19 catégories mesurent si le site et sa messagerie respectent les bonnes pratiques et les obligations : domaine et DNS, authentification et acheminement des e-mails, certificat et chiffrement, en-têtes de sécurité et cookies, logiciels en fin de support, pays et juridiction de l’hébergement, mentions légales, RGPD. 90 et plus, c’est solide ; sous 50, c’est très faible.
Elle part de 100 et perd des points pour chaque scénario d’abus trouvé — 15 au total, plus 3 compléments : secrets laissés en ligne (fichiers .env, dépôts .git, sauvegardes), base de données ouverte sur Internet, sous-domaine abandonné dont quelqu’un pourrait prendre le contrôle, domaine sur le point d’expirer, panneaux d’administration exposés, logiciels obsolètes, chiffrement faible, redirection ouverte… Les plus profonds d’entre eux — secrets laissés en ligne, base de données ouverte sur Internet, panneaux d’administration exposés — ne sont montrés et détaillés qu’après que le propriétaire a prouvé le domaine, et expliqués après paiement. Plus la note est haute, mieux le site résiste.
Nous cherchons les portes d’entrée qu’un attaquant cherche en premier : quelques ports d’administration connus sur le serveur du site (4443, 5001, 5480, 8006, 9090, 9443, 10443), et les noms publiés dans le DNS du domaine qui ressemblent à une entrée (vpn., remote., portal., citrix., owa., vcenter., gitlab.…), sur le port 443 uniquement. Nous ne lisons que la page de connexion : aucun identifiant, aucun mot de passe, aucun exploit.
Nous reconnaissons les passerelles VPN (Fortinet, Ivanti, Citrix NetScaler, Palo Alto, Cisco, Check Point, SonicWall, F5), les outils de prise en main à distance (ScreenConnect, SimpleHelp, MeshCentral, Guacamole, RD Web Access), les consoles d’administration (vCenter/ESXi, Proxmox, iLO, iDRAC, Cockpit, Portainer, phpMyAdmin, Adminer, Jenkins, Kaseya) et les applications exposées (Exchange OWA, MOVEit, GoAnywhere, Confluence, Jira, GitLab, Grafana, Kibana, Synology, QNAP). Une console d’administration publiée est grave ; un outil de prise en main à distance est un risque moyen ; une passerelle VPN est normale et ne baisse pas la note — ce qui compte, c’est de la tenir à jour. Une version n’est notée que si la page l’affiche.
AnyDesk et TeamViewer passent par les serveurs de leur éditeur : rien n’est publié côté domaine, nous ne pouvons donc pas les voir.
Si les serveurs DNS d’un domaine ne répondent pas, nous le signalons comme un problème grave : sans eux, le site et la messagerie sont injoignables pour une partie des visiteurs.
Couverture estimée 60 à 80 %. Ce n’est pas un test d’intrusion : ni force brute, ni exploit, ni injection.
Voyez-le comme un contrôle courtois — on frappe poliment à la porte d’entrée : depuis l’extérieur, nous regardons si les protections les plus connues et les plus recommandées sont en place, sans jamais chercher à entrer.
Aucun mot de passe n’est jamais essayé et aucune attaque n’est simulée. L’ancienneté des logiciels est jugée sur les dates de fin de support des éditeurs. Les vérifications les plus profondes (davantage de ports et de chemins sensibles) ne sont montrées et détaillées qu’après une preuve de propriété du domaine, et expliquées après paiement.
Le rapport cite les mentions légales obligatoires (LCEN), le RGPD et le CLOUD Act américain. Nos contrôles aident aussi à respecter une partie de l’article 32 du RGPD, des recommandations de la CNIL sur les cookies, de l’article 21 de NIS2, des exigences de Gmail et Yahoo envers les expéditeurs et de PCI DSS 4.0 — ils aident, ils ne certifient pas la conformité.