Honeypots et technologies de déception : détecter les attaquants avant qu’ils n’atteignent vos données

Un honeypot, littéralement un « pot de miel », est un système volontairement exposé et surveillé dont la seule fonction est d’attirer un attaquant pour observer ses méthodes avant qu’il n’atteigne les données réelles de l’entreprise. Longtemps réservée aux grands groupes et aux laboratoires de recherche, cette technologie de déception s’est démocratisée au point de devenir accessible aux PME, grâce à des outils open source gratuits ou à des offres managées hébergées en France.

Faux serveur, faux compte administrateur, faux fichier « mots_de_passe.xlsx » déposé sur un partage réseau : le principe reste identique. Toute interaction avec cet appât est par définition suspecte, puisqu’aucun collaborateur légitime n’a de raison de s’y connecter. Ce guide détaille les différents types de honeypots, leur cadre légal en France, les solutions disponibles (open source, commerciales et souveraines) et la méthode pour en déployer un dans votre PME sans faire exploser ni votre budget, ni votre charge de travail.

Qu’est-ce qu’un honeypot ? Définition et principe

Un honeypot est un système, un service ou un compte qui n’a aucune fonction de production : il n’existe que pour être trouvé, sondé et attaqué. C’est précisément cette absence d’usage légitime qui en fait l’un des outils de détection les plus fiables qui soient. Un pare-feu ou un antivirus doit trier en permanence le trafic normal du trafic malveillant, avec son lot de faux positifs et de réglages fins. Un honeypot n’a pas ce problème : par définition, personne n’a de raison valable de s’y connecter. La moindre interaction est donc un signal quasiment certain de compromission ou de reconnaissance active.

Le concept remonte aux années 1990, popularisé par des chercheurs comme Clifford Stoll et le projet Honeynet, mais il a considérablement évolué. On distingue aujourd’hui trois objectifs, souvent combinés au sein d’une même stratégie de déception :

• Détection précoce : repérer un attaquant qui a déjà franchi le périmètre (VPN compromis, poste infecté, identifiant volé) avant qu’il n’atteigne les données réelles.
• Ralentissement et diversion : faire perdre du temps et des ressources à l’attaquant sur un système sans aucune valeur, pendant que l’équipe réagit sur les systèmes réels.
• Renseignement (threat intelligence) : collecter des indicateurs de compromission, des techniques d’attaque et parfois des souches de malware inédites, réutilisables pour durcir l’ensemble du système d’information.

Pour une PME sans SOC dédié, cette dernière dimension change la donne : un honeypot correctement isolé transforme une intrusion qui aurait pu passer inaperçue pendant des semaines en une alerte immédiate et exploitable.

Les différents types de honeypots : faible, moyenne et forte interaction

Tous les honeypots ne se valent pas. Le niveau d’« interaction », c’est-à-dire la profondeur de simulation offerte à l’attaquant, détermine à la fois la richesse du renseignement collecté, les ressources nécessaires et le risque encouru en cas de mauvaise isolation.

Honeypots à faible interaction

Ils simulent superficiellement un service, par exemple un serveur SSH ou Telnet qui accepte une tentative de connexion et journalise les identifiants testés, sans jamais offrir de véritable système d’exploitation derrière. Léger, peu gourmand en ressources et pratiquement sans risque, ce niveau convient parfaitement à une PME qui débute : il capture l’essentiel des attaques automatisées et des scans de masse, au prix d’un renseignement plus limité sur les techniques post-intrusion.

Honeypots à interaction moyenne

Ils simulent une couche applicative plus crédible : une fausse interface d’administration, un faux CMS avec des vulnérabilités connues, un faux partage de fichiers. L’attaquant peut aller un peu plus loin dans son exploration sans jamais atteindre un vrai système sous-jacent. C’est le compromis le plus souvent recommandé pour une PME : suffisamment réaliste pour retenir l’attaquant plus longtemps et collecter des techniques d’exploitation, sans la complexité d’un système complet à maintenir et à isoler.

Honeypots à forte interaction

Ce sont de véritables systèmes d’exploitation, avec de vrais services, sur lesquels l’attaquant peut agir presque sans limite : installer des outils, tenter un mouvement latéral, déployer un malware. Le renseignement obtenu est le plus riche possible, mais le risque l’est tout autant : un système à forte interaction mal segmenté peut devenir un point de rebond réel vers le reste du réseau. Ce niveau se justifie surtout pour des équipes disposant déjà de compétences techniques internes et d’une segmentation réseau stricte, un sujet détaillé dans notre guide sur la segmentation réseau pour PME.

Honeytokens et canary tokens : la déception à l’échelle de la donnée

Déployer un honeypot demande une infrastructure, même minimale. Les honeytokens et les canary tokens répondent à une logique plus légère : au lieu de simuler un système entier, on dissémine de fausses données au cœur des systèmes réels. Un identifiant AWS factice glissé dans un dépôt de code, une ligne fictive dans une base clients, un faux compte administrateur inactif dans l’Active Directory : dès que l’un de ces leurres est utilisé, l’alerte part instantanément, puisqu’aucun usage légitime n’existe pour cette donnée.

Le canary token pousse cette logique à l’extrême simplicité : c’est un fichier, une URL ou un document (PDF, Excel, image) qui déclenche une notification silencieuse dès qu’il est ouvert ou consulté, sans nécessiter la moindre infrastructure dédiée. Le service Canarytokens.org, gratuit et open source, permet de générer ce type de leurre en quelques minutes ; des offres commerciales comme Thinkst Canary ajoutent la gestion de flotte et des intégrations SIEM pour les organisations plus matures.

Pour une PME, c’est souvent le point d’entrée le plus rentable dans la déception : un faux fichier « RIB_fournisseurs.xlsx » posé sur un partage réseau sensible, ou un identifiant factice ajouté au coffre-fort du gestionnaire de mots de passe, suffit à détecter un mouvement latéral ou un compte compromis, sans budget ni maintenance significative.

MITRE Engage : le cadre de référence de la déception

Improviser quelques leurres sans méthode a ses limites. Depuis mars 2022, le MITRE (à l’origine du célèbre référentiel ATT&CK) publie MITRE Engage, un cadre dédié à la planification des opérations de déception et d’engagement de l’adversaire. Gratuit pour un usage non commercial, il fournit un guide, des ateliers et une cartographie directe avec les techniques d’attaque référencées dans ATT&CK, ce qui permet de choisir ses leurres en fonction des tactiques réellement observées contre son secteur d’activité plutôt qu’au hasard.

L’intérêt pour une PME sans SOC mature : Engage donne une structure clé en main pour démarrer, là où l’alternative aurait été de bricoler des honeypots isolés sans cohérence d’ensemble. Combiné à des outils de supervision assistée par IA et à une démarche de threat intelligence, il permet de faire de la déception un vrai levier de détection plutôt qu’un gadget technique isolé dans un coin du réseau.

Pourquoi les honeypots sont efficaces : ce que montrent les chiffres

Selon le rapport Cost of a Data Breach d’IBM, les organisations utilisant des technologies de déception affichaient un temps de présence moyen de l’attaquant (dwell time) de 181 jours, contre 277 jours pour celles qui n’en utilisaient pas, soit un écart de près de trois mois entre l’intrusion et sa détection. D’autres analyses de terrain montrent que les leurres déclenchent la toute première alerte dans 42 % des incidents confirmés où ils sont déployés, avec un délai médian de seulement 18 minutes entre la première compromission et la détection, largement plus rapide que la moyenne des mécanismes de détection classiques.

Cette efficacité explique la progression du marché : plus de la moitié des entreprises intègrent désormais une forme de déception dans leur stratégie de sécurité, et une part croissante des centres opérationnels de sécurité (SOC) s’appuie sur ce type de détection pour réduire le temps de présence des attaquants. Pour une PME, l’argument central n’est pas la sophistication de l’outil mais son taux de faux positifs proche de zéro : à l’inverse d’un SIEM qu’il faut régler et affiner pendant des mois, un honeypot ou un honeytoken est utile dès le premier jour, sans expertise poussée en analyse de logs.

Honeypot et conformité NIS2 : quelle place dans vos obligations

La directive NIS2 impose, via son article 21.2, dix familles de mesures aux entités essentielles et importantes, dont le traitement des incidents et la capacité à détecter les anomalies sur le système d’information. Les honeypots et honeytokens n’y sont pas cités nommément : NIS2 fixe des objectifs de résultat, pas une liste d’outils obligatoires. En France, le référentiel ReCyF publié par l’ANSSI en mars 2026 décline ces dix mesures en exigences opérationnelles concrètes, et la capacité de détection précoce y occupe une place centrale.

Concrètement, un honeypot ou quelques honeytokens bien placés constituent un argument tangible lors d’un audit de conformité : ils démontrent une capacité de détection active, et non une simple politique sur papier. C’est un complément peu coûteux à une démarche de mise en conformité plus large, détaillée dans notre guide de mise en conformité NIS2 pour PME et dans notre guide complet de cybersécurité pour PME.

Cadre légal en France : ce qu’il faut savoir avant de déployer un honeypot

Déployer un honeypot sur son propre système d’information est légal en France, au titre de l’autodéfense numérique reconnue par l’ANSSI, mais ce n’est pas un blanc-seing. Trois points de vigilance concrets s’imposent avant tout déploiement.

• Ne jamais provoquer une action que l’attaquant n’aurait pas commise de lui-même. La notion de provocation, issue de l’article 23 de la loi du 29 juillet 1881, peut engager la responsabilité de celui qui incite activement une personne identifiée à commettre une infraction. Un honeypot passif, qui se contente d’observer une intrusion spontanée, ne pose pas ce problème ; un dispositif conçu pour cibler et pousser à agir une personne précise est une tout autre affaire.
• Traiter les données collectées comme des données personnelles. Une adresse IP est une donnée à caractère personnel au sens du RGPD. La CNIL attend que ce traitement figure dans votre registre, avec une finalité clairement documentée (sécurité du système d’information) et une durée de conservation proportionnée.
• Ne jamais riposter. Utiliser un honeypot pour justifier une contre-attaque, un « hack back » sur l’infrastructure de l’attaquant, est une infraction pénale en France au titre des articles 323-1 et suivants du Code pénal, quelle que soit la légitimité perçue de la riposte. Le honeypot reste un outil d’observation, jamais un outil d’action offensive.

Le ministère de l’Intérieur a par ailleurs indiqué ne pas déployer lui-même de dispositifs de type honeypot ou honeynet au sein des organismes gouvernementaux français, un rappel utile que cette technologie, bien que légale, reste entourée de prudence institutionnelle. Pour une PME, la meilleure pratique reste la simplicité : un honeypot passif, isolé, documenté au registre RGPD, et intégré à une politique de sécurité écrite plutôt que déployé de façon improvisée.

Outils et solutions : comparatif open source, commercial et souverain

Trois grandes familles de solutions coexistent sur le marché. Les outils open source auto-hébergés (Cowrie, T-Pot) sont gratuits mais demandent des compétences techniques internes pour l’installation, la maintenance et l’isolation réseau. Les solutions commerciales clé en main simplifient le déploiement, mais sont le plus souvent hébergées hors de l’Union européenne. Les solutions souveraines françaises ou européennes combinent facilité de déploiement et hébergement sous droit français ou européen, un critère qui compte doublement ici : les logs collectés par un honeypot contiennent des adresses IP d’attaquants, potentiellement liées à des enquêtes en cours, et l’exposer au CLOUD Act américain n’est jamais souhaitable.

Trapster, édité par la société française Ballpoint, illustre bien cette troisième voie : hébergement en France chez OVHcloud, moteur open source auditable (Trapster Community), et une offre pensée pour faciliter la conformité NIS2 et DORA plutôt que pour la contourner. Sekoia.io, acteur français de la threat intelligence depuis 2015, combine de son côté honeypots, trackers d’infrastructures C2 et surveillance de malwares au sein d’une plateforme hébergée en France en partenariat avec Thales. Face à ces alternatives, une solution comme Thinkst Canary reste appréciée pour sa simplicité d’usage, mais héberge ses données hors du territoire européen, un compromis à évaluer selon la sensibilité de votre activité.

Comment déployer un honeypot dans votre PME : la méthode en 8 étapes

Un honeypot déployé sans méthode devient vite un gadget oublié dans un coin du réseau. Voici la démarche à suivre pour qu’il reste utile dans la durée.

1. Auditer l’existant. Avant d’ajouter un leurre, assurez-vous que les fondamentaux (sauvegardes, MFA, correctifs) sont en place. L’outil gratuit Audit Cyber PME de SIAC Media donne une photographie rapide de votre niveau de maturité avant d’investir dans la déception.
2. Définir l’objectif. Détecter une intrusion interne (mouvement latéral, compte compromis) ou collecter du renseignement sur les attaques externes : les deux objectifs n’appellent pas le même outil ni le même emplacement réseau.
3. Choisir le bon niveau d’interaction. Commencez par des honeytokens gratuits et un honeypot à faible interaction plutôt que de viser d’emblée un honeynet complet à forte interaction.
4. Isoler strictement le honeypot. Placez-le dans un segment réseau dédié, sans accès aux ressources de production, pour qu’il ne puisse jamais servir de rebond en cas de compromission.
5. Configurer des alertes surveillées. Une alerte que personne ne lit ne sert à rien : reliez le honeypot à un canal réellement suivi (messagerie d’astreinte, SIEM). Si l’analyse des alertes est en partie automatisée par un outil d’IA, formalisez son usage dans une charte interne, par exemple à l’aide du générateur de charte IA de SIAC Media.
6. Documenter le traitement RGPD. Consignez la finalité, la base légale et la durée de conservation des données collectées dans votre registre des traitements.
7. Tester avant de généraliser. Simulez une connexion depuis un poste externe pour vérifier que l’alerte remonte correctement, puis affinez au fil des premières semaines.
8. Intégrer les alertes au plan de réponse à incident. Une détection sans procédure de réaction ne sert à rien : reliez le déclenchement d’un honeypot à votre plan de réponse aux 24 premières heures d’une cyberattaque.

Limites et pièges à éviter

La déception a fait ses preuves, mais elle n’est pas magique. Quelques pièges reviennent régulièrement dans les déploiements mal préparés.

• Isolation insuffisante. Un honeypot connecté, même indirectement, au réseau de production devient lui-même une porte d’entrée. La segmentation n’est pas optionnelle.
• Maintenance négligée. Un système à forte interaction non patché peut être détourné par un attaquant expérimenté pour héberger ses propres outils, à l’insu de l’entreprise qui pense encore l’observer.
• Trop d’outils, pas assez de surveillance. Multiplier les leurres sans personne pour lire les alertes revient à ajouter du bruit, pas de la sécurité. Mieux vaut un seul honeytoken surveillé qu’une dizaine de honeypots ignorés.
• La déception ne remplace rien. Elle complète les fondamentaux (sauvegardes, MFA, gestion des correctifs, sensibilisation des équipes) ; elle ne compense jamais leur absence. Un honeypot peut détecter une attaque fileless en observant son comportement en mémoire, mais seulement si les protections de base existent déjà en amont.
• Jamais de contre-attaque. Céder à la tentation de « suivre » l’attaquant jusqu’à son infrastructure pour la neutraliser expose l’entreprise elle-même à des poursuites pénales.

Conclusion

Un honeypot ne détecte pas tout, mais il change la nature du signal : chaque interaction avec un système qui n’a aucune raison d’être utilisé est un indice quasiment certain de compromission, sans les réglages fastidieux qu’exige un outil de détection classique. Pour une PME, l’approche la plus réaliste n’est pas de viser d’emblée un honeynet complexe, mais de commencer petit : quelques honeytokens gratuits, un honeypot à faible interaction bien isolé, puis une montée en sophistication au rythme des ressources disponibles, dans le cadre structurant proposé par une stratégie de cyber-résilience plus large.

Le choix de l’hébergement compte presque autant que le choix technique : les logs d’un honeypot contiennent des données personnelles au sens du RGPD, et les héberger en France ou en Europe plutôt que chez un hyperscaler américain reste la décision la plus cohérente avec l’esprit de NIS2. Pour resituer la déception dans une stratégie de sécurité augmentée par l’IA plus large, notre panorama complet des technologies IA en cybersécurité pour PME détaille les autres briques à considérer en complément.