Brevet FR3164299A1 — publié le 20260109

La présente invention concerne un procédé de détection d’une vulnérabilité à une attaque de type hameçonnage dans un système informatique, caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données (11) d’un serveur (1) dudit système informatique, d’étapes de : Obtention d’au moins un premier message informatique d’une tentative d’hameçonnage, ledit premier message informatique comprenant des données de personnalisation originales ; Génération d’un deuxième message informatique correspondant au premier message informatique dans lequel lesdites données de personnalisation originales ont été anonymisées ; Génération d’un troisième message informatique correspondant au deuxième message informatique dans lequel de nouvelles données de personnalisation ont été introduites pour au moins un utilisateur dudit système informatique, dit utilisateur cible, en fonction de données de ciblage dudit système informatique, stockées dans des moyens de stockage de données (12) dudit serveur (1) ; Emission dudit troisième message informatique à destination dudit utilisateur cible de sorte à simuler une attaque de type hameçonnage ; Détection d’au moins une réaction audit troisième message informatique mise en œuvre par ledit utilisateur cible dans ledit système informatique [Fig. 1] Procédé de détection d’une vulnérabilité à une attaque de type hameçonnage dans un système informatique. DOMAINE TECHNIQUE GÉNÉRAL La présente invention se rapporte au domaine de la sécurité informatique. Plus précisément, elle concerne un procédé de détection d’une vulnérabilité à une attaque de type hameçonnage dans un système informatique. ETAT DE L’ART On appelle hameçonnage (en anglais phishing) une technique d’attaque informatique visant à obtenir des données personnelles d’un utilisateur tel qu’un mot de passe, un numéro de carte bancaire, etc. L’idée est de faire croire à la victime qu'elle s'adresse à un tiers de confiance — banque, administration, entreprise, etc. Le plus souvent, un faux courrier électronique (reprenant le même formalisme qu’un courrier électronique du tiers de confiance et en utilisant une adresse e-mail très similaire) est envoyé à la victime l’invitant à cliquer sur un lien ou une pièce jointe qui va l’amener sur une copie d’un site web officiel (avec une fausse page de login l’invitant à saisir ses codes personnels), voire directement charger un virus. L’attaque peut aussi être réalisée par d’autres moyens électroniques comme un message sur un réseau social mobile ou un SMS, voire directement en créant de toute pièces un faux site complet. La protection contre de telles attaques est très compliquée, car elles n’exploitent pas de failles informatiques spécifiques, elles ne font que tromper les utilisateurs. Une solution est l’éducation et la sensibilisation des utilisateurs à la détection proactive d'e-mails de phishing. En pratiquant avec des exemples concrets, on peut apprendre à identifier les signaux d'alerte, tels que les erreurs dans le nom de domaine ou les incohérences dans l'adresse de l'expéditeur. Cependant, il suffit d’un seul utilisateur pas assez vigilant pour compromettre tout le système informatique d’une entreprise. De plus, on a aujourd’hui des attaques avancées de phishing dites de spear phishing (en français harponnage), dans lequel l’e-mail est fortement personnalisé (par exemple l’e-mail mentionne l’IBAN réel de la victime et usurpe l’identité de son conseiller bancaire), ce qui le rend plus convaincant. La sensibilisation au spear phishing est bien plus délicate. On connait alternativement des mécanismes de détection automatique d’e-mails d’hameçonnage, basés sur des filtres, mais ils n’apportent pas entière satisfaction. En effet, ces filtres sont souvent « trop sévères » et peuvent bloquer indument des e-mails légitimes et non frauduleux, de sorte que l’utilisateur doit vérifier régulièrement les e-mails bloqués (et dans certains cas il y a le risque qu’il débloque un e-mail réellement frauduleux). La présente invention vient améliorer la situation. PRÉSENTATION DE L’INVENTION La présente invention se rapporte donc selon un premier aspect à un procédé de détection d’une vulnérabilité à une attaque de type hameçonnage dans un système informatique, caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données d’un serveur dudit système informatique, d’étapes de : Obtention d’au moins un premier message informatique d’une tentative d’hameçonnage, ledit premier message informatique comprenant des données de personnalisation originales ; Génération d’un deuxième message informatique correspondant au premier message informatique dans lequel lesdites données de personnalisation originales ont été anonymisées ; Génération d’un troisième message informatique correspondant au deuxième message informatique dans lequel de nouvelles données de personnalisation ont été introduites pour au moins un utilisateur dudit système informatique, dit utilisateur cible, en fonction de données de ciblage dudit système informatique, stockées dans des moyens de stockage de données dudit serveur ; Emission dudit troisième message informatique à destination dudit utilisateur cible de sorte à simuler une attaque de type hameçonnage ; Détection d’au moins une réaction audit troisième message informatique mise en œuvre par ledit utilisateur cible dans ledit système informatique. Selon des caractéristiques avantageuses et non limitatives : L’étape (b) comprend l’identification de chaque donnée de personnalisation originale dudit premier message informatique, et son remplacement par une donnée générique représentative du type de donnée de personnalisation. L’étape (c) comprend le remplacement de chaque donnée générique par une nouvelle donnée de personnalisation du même type. Les données de personnalisation sont choisies parmi un numéro IBAN, un numéro de carte bancaire, un nom et/ou un prénom, un numéro administratif, une adresse de messagerie électronique, une adresse d’un portefeuille de cryptomonnaie, une adresse IP, un numéro de téléphone et une adresse physique. L’étape (a) est mise en œuvre par un modèle de langage génératif, en particulier un grand modèle de langage. Ledit modèle présente un paramètre représentatif de la langue du premier message électronique et/ou un paramètre représentatif d’un degré d'anonymisation à appliquer. L’étape (c) comprend la détermination préalable dudit utilisateur cible en fonction desdites données de ciblage. Lesdites nouvelles données de personnalisation sont associées à l’utilisateur cible ou à un autre individu déterminé en fonction dudit utilisateur cible et desdites données de ciblage. L’étape (d) comprend outre l’émission d’un quatrième message informatique à destination dudit utilisateur cible en fonction de la réaction détectée. Lesdits premier, deuxième et troisième messages informatiques sont des courriers électroniques, en particulier au format .eml. Selon un deuxième aspect, l’invention concerne un serveur d’un système informatique, caractérisé en ce qu’il comprend des moyens de traitement de données, configurés pour : Obtenir au moins un premier message informatique d’une tentative d’hameçonnage, ledit premier message informatique comprenant des données de personnalisation originales ; générer un deuxième message informatique correspondant au premier message informatique dans lequel lesdites données de personnalisation originales ont été anonymisées ; générer un troisième message informatique correspondant au deuxième message informatique dans lequel de nouvelles données de personnalisation ont été introduites pour au moins un utilisateur dudit système informatique, dit utilisateur cible, en fonction de données de ciblage dudit système informatique, stockées dans des moyens de stockage de données dudit serveur ; émettre ledit troisième message informatique à destination dudit utilisateur cible de sorte à simuler une attaque de type hameçonnage dans ledit système informatique ; détecter au moins une réaction audit troisième message informatique mise en œuvre par ledit utilisateur cible dans ledit système informatique. Selon un troisième et un quatrième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect pour la mise en œuvre d’un procédé de détection d’une vulnérabilité à une attaque de type hameçonnage dans un système informatique ; et un moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect pour la mise en œuvre d’un procédé de détection d’une vulnérabilité à une attaque de type hameçonnage dans un système informatique. PRÉSENTATION DES FIGURES D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : FIG. 1 la FIG. 1 est un schéma d’un système pour la mise en œuvre du procédé selon l’invention ; FIG. 2 la FIG. 2 est un logigramme illustrant les étapes d’un mode de réalisation du procédé selon l’invention. DESCRIPTION DÉTAILLÉE Architecture En référence à la FIG. 1 , on a représenté schématiquement un système informatique pour la mise en œuvre du présent procédé de détection d’une vulnérabilité à une attaque de type hameçonnage dans ledit système informatique. Par détection d’une vulnérabilité à une attaque de type hameçonnage, on entend test du système et en particulier de ses utilisateurs de sorte à estimer un risque de compromission en cas de tentative d’hameçonnage, de sorte à prendre des mesures en fonction du résultat. L’idée est de simuler une attaque la plus réaliste possible (i.e. ni trop évidente ni trop parfaite, mais vraiment alignée sur les tentatives d’hameçonnage actuelles), et de pouvoir constater les « dégats » sans pour autant ne prendre de risque pour ledit système informatique. A noter qu’il est tout à fait possible que le résultat soit un échec total de la tentative d’hameçonnage (vigilance et réponse appropriée) et donc qu’aucune vulnérabilité ne soit détectée. On peut alors ne prendre aucune mesure. Par « système informatique », on entend une infrastructure informatique, typiquement celle d’une entreprise, comprenant une pluralité d’équipements 2 d’utilisateurs (en particuliers employés de ladite entreprise) connectés par un réseau 20, généralement un réseau local (le cas échéant via un réseau étendu tel qu’internet, par exemple en utilisant un VPN). Les utilisateurs ont typiquement des comptes individuels auprès du système, avec des droits d’accès divers. On supposera notamment qu’ils ont un compte de messagerie électronique, voir plus loin. Lesdits équipements utilisateurs 2 peuvent être des PC de bureau, des smartphones, etc. La présente invention ne sera toutefois limitée à aucun type de système informatique. Le système comprend en outre au moins un serveur 1, qui peut être distant et lui-même connecté aux autres équipements via ledit réseau étendu tel qu’internet. Le serveur 1 et les équipements 2 comportent des moyens de traitement de données 11, 21, i.e. un calculateur tel que par exemple un processeur, un microprocesseur, un contrôleur, un microcontrôleur, un FPGA etc. Ces calculateurs sont adaptés pour exécuter des instructions de code pour mettre en œuvre le procédé ci-après. Le serveur 1 et les équipements 2 peuvent également comprendre des moyens de stockage de données 12, 22 (une mémoire, par exemple flash) éventuellement une interface utilisateur (typiquement un écran tactile), etc. Procédé En référence à la FIG. 2 , le présent procédé de détection d’une vulnérabilité à une attaque de type hameçonnage dans un système informatique, mis en œuvre par les moyens de traitement de données 11 du serveur 1 commence classiquement par une étape (a) d’obtention d’au moins un premier message informatique d’une tentative d’hameçonnage, ledit premier message informatique comprenant des données personnelles originales. Par message informatique, on entend préférentiellement un courrier électronique, i.e. un e-mail, préférentiellement au format .eml (ou encore directement en html, voire en texte brut), et on prendra cet exemple dans la suite de la présente description. Alternativement ce peut être un SMS, une notification d’une application de messagerie (WhatsApp, Telegram, etc.), un message sur un réseau social, etc. On suppose comme expliqué que lesdits utilisateurs du système informatique ont au moins un compte de messagerie électronique, par exemple un compte e-mail professionnel. Ledit premier message électronique est avantageusement un message réel, i.e. reçu dans le cadre d’une tentative d’hameçonnage ayant eu lieu. En effet, comme expliqué le présent procédé vise à simuler une attaque la plus réaliste possible, et donc partir de premiers messages réels est optimal. Le premier message pourra être obtenu de toute façon possible : on pourra utiliser des bases de messages d’attaques existantes, voire même prendre des messages reçus par des utilisateurs dudit système lors de tentatives déjouées d’hameçonnage. On suppose en outre que le premier message comprend des données de personnalisation originales, i.e. des données utilisateur rendant le message spécifique, voire personnalisé (cas du spear phishing évoqué). De manière préférée lesdites données de personnalisation comprennent au moins une donnée personnelle d’au moins un individu (potentiellement extérieur audit système informatique), et notamment • un numéro IBAN • un numéro de carte bancaire • un nom et/ou un prénom • un numéro administratif, notamment d’identification pour un service public (numéro de carte d’identité, de permis, de carte vitale, etc.) • une adresse de messagerie électronique • une adresse d’un portefeuille de cryptomonnaie (wallet) • une adresse IP • un numéro de téléphone • une adresse physique On peut avoir avantageusement en outre au moins une autre donnée de personnalisation dans le premier message telle qu’une URL ou une information temporelle. On comprend que ledit premier message électronique ne peut être utilisé ou du moins présenté à des utilisateurs à des fins de sensibilisation, du fait de son caractère personnel. En effet, cela poserait des problèmes de vie privée et de sécurité des données, et le stocker tel quel sur des moyens de stockage de données 12 du serveur 1 créerait des contraintes règlementaires (RGPD). De surcroit, un tel message n’aurait que peu d’impact sur une personne autre que l’individu auquel il emprunte des données personnelles. Ainsi, dans une étape (b), le procédé comprend la génération d’un deuxième message informatique correspondant au premier message informatique dans lequel lesdites données de personnalisation originales ont été anonymisées. En d’autres termes, il s’agit d’une étape d’anonymisation du premier message électronique. Par anonymisation, on entend dépersonnalisation, i.e. suppression desdites données de personnalisation originales, et avantageusement transformation de ces données de personnalisation originales en des données génériques, de sorte à ce que le message électronique ne soit plus relatif à un individu. Le deuxième message peut être vu comme un modèle de message électronique d’hameçonnage (en l’état inutilisable). On comprend que la simple anonymisation n’a pas d’impact sur la forme du message et permet : • le maintien de la typographie : la typographie, y compris la taille des caractères, le style (gras, italique, etc.), et l'espacement des lignes et des paragraphes, reste identique à celle du premier message. • Des polices de Caractères Intactes : les polices utilisées dans le premier message sont conservées. Cela assure que le style visuel et l'esthétique ne sont pas altérés. • le respect de la Charte Graphique : la charte graphique, incluant les couleurs, les logos, les images, et tout autre élément graphique, est préservée. Cela est crucial pour maintenir l'identité visuelle et la marque de l'émetteur du premier message. Ainsi l’étape (b) est typiquement une étape de génération du deuxième message électronique, correspondant au premier message électronique dans laquelle lesdites données de personnalisation sont remplacés par lesdites données génériques. Ces dernières sont typiquement des « codes » i.e. des champs identifiant de manière générale le type de donnée de personnalisation. A ce titre, l’étape (b) comprend avantageusement l’identification de chaque donnée de personnalisation originale, et son remplacement par une donnée générique. De manière préférée, chaque donnée de personnalisation est classifiée (pour identifier son type), et la donnée générique utilisée est fonction de sa classe, i.e. chaque donnée générique est représentative du type de donnée de personnalisation qu’elle remplace. Par exemple on pourra traiter les données de personnalisation de la sorte : • les URL sont transformées en • les données temporelles sont transformées en • les IBAN sont transformés en • les numéros de cartes sont transformés en • les numéros administratifs, sont transformés selon le type en , , , etc. • les adresses de messagerie électronique sont transformées en • les adresses d’un portefeuille de cryptomonnaie sont transformées en • les adresses IP sont transformées en • Les numéros de téléphone sont transformés en • Les noms/prénoms sont transformés en • les adresses physiques sont transformées en De manière préférée, si on a plusieurs données de personnalisation du même type (i.e. relatives à plusieurs individus), on peut numéroter lesdites données générique de sorte à les distinguer. L’étape (b) comprend à ce titre avantageusement l’identification de chaque donnée de personnalisation, ou du moins de celles d’un même type, et l’ajout à ladite donnée générique correspondante d’un identifiant unique. On comprend que cet identifiant ne permet pas de remonter à la donnée d’origine. A titre d’exemple on peut avoir le premier message suivant : Bonjour M. Dupont, Nous avons remonté les tickets d’incident de Mme Turpin et de M. Lesot entre le 01/01/24 et le 01/03/24. Ci-dessous leurs informations : Mme Turpin Numéro de téléphone : 06 64 37 87 98 Adresse IP : 192.67.28.10 M. Lesot Numéro de téléphone : 06 64 37 87 98 Adresse IP : 192.15.28.26 Lien vers les tickets Bien à vous, Benoit Lasalle 06 18 67 67 87 Alors le second message généré serait Bonjour , Nous avons remonté les tickets d’incident de et de entre le et le . Ci-dessous leurs informations : Numéro de téléphone : Adresse IP : Numéro de téléphone : Adresse IP : Bien à vous, On comprend que le deuxième message électronique généré ne pose plus aucun problème en termes de protection de la vie privée et peut être stocké sur les moyens de stockage 12 et/ou partagé sans problème. Il reste représentatif d’une situation réaliste et actuelle. La mise en œuvre d’une étape d’anonymisation est bien connue de l’homme du métier et on pourra utiliser toute technique connue. On note que les messages informatiques restent écrits en langage naturels, même s’ils peuvent être balisés (dans le cas d’un format structuré tel que html). Ainsi des modèles de langage génératifs sont particulièrement adaptés. Par modèle de langage génératif, on entend un modèle d’intelligence artificielle, capable de générer un texte en sortie à partir d’un prompt. Le modèle de langage génératif généralement est typiquement un grand modèle de langage (LLM), en particulier un modèle de type transformateur génératif pré-entraîné (GPT), par exemple GPT-4, LaMDA, LLaMA, BLOOM, etc. A noter qu’on peut utiliser un modèle dédié, entraîné notamment sur une base de paires de premier et second messages informatiques de référence (pas nécessairement liés à de l’hameçonnage). On peut avoir un module autonome et accessible via APIs REST normalisées pour simplifier l’intégration dans l’existant. De manière préférée, le module peut prendre en paramètre la langue du premier message électronique et/ou un seuil d’anonymisation et appliquer un modèle de langage le plus adapté pour appliquer l’anonymisation. De manière connue, le « seuil d’anonymisation » est un paramètre préférentiellement compris entre 0 et 1, représentatif d’un degré d'anonymisation appliqué à un ensemble de données. Il est utilisé dans le traitement des données, en particulier dans le contexte de la protection de la vie privée et de la sécurité des données. Ce seuil mesure le niveau d'anonymat garanti dans un ensemble de données. Plus le seuil est élevé, plus les données sont considérées comme anonymes. • Un seuil d'anonymisation proche de 0 indique un faible niveau d'anonymisation. Cela signifie que les données conservent beaucoup de leurs caractéristiques originales et sont donc potentiellement plus facilement identifiables ou liées à des individus spécifiques. Dans ce cas, il existe un risque plus élevé que les données puissent être re-associées ou « dé-anonymisées » à des personnes réelles, ce qui pose des problèmes de confidentialité. • Un seuil proche de 1 suggère un haut niveau d'anonymisation. Cela signifie que les données ont été considérablement modifiées pour empêcher l'identification des individus. Avec un seuil élevé, les risques de re-identification sont minimisés, offrant ainsi une meilleure protection de la vie privée. De manière préférée ; l’anonymisation est appliquée, dans le cas d’un message structuré, pour chaque segment de texte du premier message entre balises. L’intérieur des balises est ignoré afin de ne pas dégrader la mise en page. Ensuite, le procédé comprend une étape (c) de génération d’un troisième message informatique correspondant au deuxième message informatique dans lequel de nouvelles données de personnalisation ont été introduites pour au moins un utilisateur dudit système informatique, en fonction de données de ciblage dudit système informatique. Il s’agit d’une étape de repersonnalisation du deuxième message, dont on rappelle qu’il ne contient plus que des données génériques. Dans le premier message électronique, on avait des données de personnalisation dites originales, en ce qu’elles étaient celles initialement présentes, et donc inadaptées au système informatique dans lequel on cherche à détecter les vulnérabilités. On souhaite obtenir dans l’étape (c) un message informatique comprenant de nouvelles données de personnalisation, cette fois relatives (entre autres) à un utilisateur dudit système informatique, dit utilisateur cible. Il peut tout à fait y avoir des données de personnalisation relatives à d’autres individus, par exemple le banquier de l’utilisateur cible, mais comme l’on verra cela ne posera pas de problème de vie privée car la diffusion dudit troisième message sera limitée à l’utilisateur cible. A noter qu’il peut y avoir plusieurs utilisateurs cibles, dans le cadre d’une tentative d’hameçonnage plus importante (par exemple à destination de tous les membres d’un service), et dans ce cas il y aura généralement autant de troisièmes messages générés à partir du deuxième message, même si un même troisième message pourrait être envoyé en même temps à plusieurs utilisateurs cibles. Le troisième message correspond en d’autres termes au premier message dans lequel les données de personnalisation originales ont été remplacées par des nouvelles données de personnalisation. L’idée est d’obtenir un troisième message conservant la structure, la typographie, les polices et la charte graphique du premier message permet de protéger la confidentialité tout en préservant l'aspect original et professionnel du document. Cela garantit que l'email peut toujours être utilisé efficacement pour une campagne de phishing sans risquer de compromettre les informations personnelles. Et le fait de passer par le deuxième message anonymisé permet d’y parvenir aisément. De plus, il est très facile de générer plusieurs troisièmes messages dans le cas d’une pluralité d’utilisateurs cible. En effet, on utilise comme expliqué des « données de ciblage » définissant entres autres lesdites nouvelles données de personnalisation. Cette étape (c) peut être mise en œuvre également au moyen d’un modèle de langage génératif, mais elle peut tout simplement être mise en œuvre au moyen de règles déterminant quelle donnée de personnalisation introduire pour chaque donnée générique, lesdites données de ciblage définissant lesdites règles. Les données de ciblage comprennent par exemple des ensembles de données personnelles d’utilisateurs du système informatique (les données qu’ils ont eux même fournies, par exemple des données RH ou des données d’inscriptions), et il suffit de prendre les données personnelles du type défini par la donnée générique. A noter que certaines nouvelles données de personnalisation peuvent être celles d’autres individus différents dudit utilisateur cible, notamment des individus de référence potentiellement eux-mêmes utilisateurs du système informatique (par exemple un supérieur hiérarchique, dans le cas d’une tentative d’hameçonnage de type « escroquerie au président », des collègues, ou bien des utilisateurs quelconques du système informatique), ou bien encore des individus fictifs. L’étape (c) peut en outre comprendre l’ajout d’URL et/ou de pièces jointes prédéfinis en fonction encore des données de ciblage. De manière préférée, l’étape (c) comprend la détermination préalable dudit utilisateur cible, à nouveau en fonction desdites données de ciblage, ainsi que des éventuels autres individus impliqués. A ce titre les données de ciblages peuvent définir : des scénarios de tentatives d’hameçonnage, notamment associés à des listes d’utilisateurs susceptibles de subir ce type d’attaques (par exemple une attaque de type « faux ordre de virement » concerne des utilisateurs du service compatibilité), et les individus de référence associés à ces utilisateurs, et définissant les éventuels URL/pièces jointes à ajouter. On peut notamment avoir les types d’attaques suivants : « Credentials » dans le cas où une page de connexion est rattachée au template, « Click-Only » dans le cas contraire, « Ransomware » si on souhaite inclure une pièce jointe au mail pour suivre les ouvertures de celle-ci par les utilisateurs les résultats de mise en œuvre précédentes du présent procédé, et notamment d’utilisateur qui n’ont pas été testé depuis longtemps et/ou avaient échoué précédemment ; des paramètres prédéfinis, tel qu’un niveau de difficulté de la tentative d’attaque. Si on reprend l’exemple avant, on peut avoir un scénario visant à tester une attaque de spear phishing avancée sur une personne du service informatique (l’utilisateur cible), qui sera donc PERSON_1. En PERSON_2 et PERSON_3 on met deux utilisateur quelconques du système informatiques, susceptibles d’avoir ouvert un ticket d’incident. En PERSON_4 on met le supérieur hiérarchique de l’utilisateur cible En URL un lien vers une fausse page d’accès aux tickets demandant à l’utilisateur de saisir ses crédentiels. A l’issue de l’étape (c) on a un message électronique prêt. Alors, dans une étape (d), le procédé comprend l’émission du (ou des) troisième(s) message(s) informatique(s) à destination du (ou des) utilisateur(s) cible(s) de sorte à simuler une attaque de type hameçonnage. Il s’agit simplement de l’envoyer de manière automatisée, par exemple avec un module d’e-mailing, au milieu des autres messages électroniques habituels pour l’utilisateur cible. L’adresse dudit utilisateur est connue puisqu’il a un compte dans ledit système. A noter qu’on peut éventuellement rajouter un objet, ou jouer sur l’adresse de l’expéditeur (suivant le scénario). A noter que le processus d'envoi peut être configuré de manière immédiate ou planifiée, selon des objectifs de formation et un calendrier prédéfini : • Envoi immédiat : les utilisateurs reçoivent les troisièmes messages en temps réel. • Envoi planifié : un administrateur sélectionne la date l’heure d’envoi des troisièmes messages pour maximiser l’impact et l’engagement des utilisateurs. Le présent procédé permet ainsi d'entraîner de manière très efficace les utilisateurs à repérer un e-message de phishing, puisqu’il cible les utilisateurs avec des scénarios qui reflètent les types de messages qu'ils pourraient réellement recevoir. L'utilisation de données pertinentes à leur rôle spécifique ou à leur département, augmente la probabilité qu'ils appliquent cet apprentissage dans des situations réelles. Alors, dans une étape (e), les moyens 11 détectent au moins une réaction audit troisième message informatique mise en œuvre par ledit utilisateur cible dans ledit système informatique. Plus précisément, l’utilisateur cible reçoit le troisième message suite à l’étape (d), par exemple dans sa boite e-mail, et l’idée est déterminer quelle action est mise en œuvre sur ce message reçu. Par exemple, l’utilisateur peut : - recevoir le troisième message et l’ignorer - recevoir le troisième message et le signaler au service informatique - cliquer sur le troisième message et le supprimer - cliquer sur une URL dans le troisième message - cliquer sur l’URL et saisir ses crédentiels - ouvrir une pièce jointe du troisième message. Cette détection peut être mise en œuvre de toute manière connue, par exemple avec des accusés de réception, des accusés de lecture, des routines, ou le simple fait de surveiller le trafic sur ladite URL. L’étape (d) permet ainsi de déterminer le résultat de la tentative d’hameçonnage. Par exemple, si l’utilisateur cible clique sur l’URL et saisit ses crédentiels, alors la tentative simulée est (malheureusement) un succès et une vulnérabilité a pu être identifiée. Si au contraire tous les utilisateurs cible ont des réactions appropriées (suppression du message et/ou signalement au service informatique), alors la tentative simulée est un échec et il n’y a pas de vulnérabilité détectée. De manière préférée, l’étape (d) comprend en outre l’émission d’un quatrième message informatique à destination dudit utilisateur cible en fonction de la réaction détectée. Ledit quatrième message compare en particulier la réaction de l’utilisateur cible avec une réaction attendue). L’idée est de féliciter l’utilisateur s’il a réagi correctement, ou au contraire de l’informer qu’il a n’a pas détecté la tentative d’hameçonnage et qu’il aurait pu compromettre la sécurité du système informatique si cela avait été une tentative réelle et mal intentionné, au lieu d’une simulation. Par exemple, en cas de clic sur un lien ou une pièce jointe, il peut recevoir des explications sur les raisons pour lesquelles il n'aurait pas dû cliquer, pour éviter de répéter la même erreur dans le futur. L’étape (d) peut en outre comprendre la collecte des données de réaction recueillies pour stockage sur les moyens de stockage 12, analyse, et conclusion sur les risques de vulnérabilité à l’échelle du système informatique, avec identification des points forts et des axes d’amélioration pour les futures campagnes. Serveur Selon un deuxième aspect, l’invention concerne le serveur 1 pour la mise en œuvre du procédé selon le premier aspect. Il s’agit ainsi d’un serveur du système informatique, de détection d’une vulnérabilité à une attaque de type hameçonnage dans ledit système informatique. Le serveur 1 comprend respectivement des moyens de traitement de données 11 et des moyens de stockage de données 12. Les moyens de traitement de données 11 du premier équipement 1 sont configurés pour : Obtenir au moins un premier message informatique d’une tentative d’hameçonnage, ledit premier message informatique comprenant des données de personnalisation originales ; générer un deuxième message informatique correspondant au premier message informatique dans lequel lesdites données de personnalisation originales ont été anonymisées ; générer un troisième message informatique correspondant au deuxième message informatique dans lequel de nouvelles données de personnalisation ont été introduites pour au moins un utilisateur dudit système informatique, dit utilisateur cible, en fonction de données de ciblage dudit système informatique, stockées dans des moyens de stockage de données 12 dudit serveur 1 ; émettre ledit troisième message informatique à destination dudit utilisateur cible de sorte à simuler une attaque de type hameçonnage dans ledit système informatique ; détecter au moins une réaction audit troisième message informatique mise en œuvre par ledit utilisateur cible dans ledit système informatique. L’invention peut en outre concerner le système informatique, comprenant ledit serveur 1 et au moins un équipement 2 d’un utilisateur dudit système informatique, connectés via un réseau 20. Produit programme d’ordinateur Selon un troisième et un quatrième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (sur les moyens de traitement de donnés 11 du serveur 1) d’un procédé selon le premier aspect pour la mise en œuvre de détection d’une vulnérabilité à une attaque de type hameçonnage dans un système informatique ; et un moyen de stockage (par exemple les moyens de stockage de données 12 du serveur 1) sur lequel on trouve ce produit programme d’ordinateur. Procédé de détection d’une vulnérabilité à une attaque de type hameçonnage dans un système informatique, caractérisé en ce qu’il comprend la mise en œuvre, par des moyens de traitement de données (11) d’un serveur (1) dudit système informatique, d’étapes de : Obtention d’au moins un premier message informatique d’une tentative d’hameçonnage, ledit premier message informatique comprenant des données de personnalisation originales ; Génération d’un deuxième message informatique correspondant au premier message informatique dans lequel lesdites données de personnalisation originales ont été anonymisées ; Génération d’un troisième message informatique correspondant au deuxième message informatique dans lequel de nouvelles données de personnalisation ont été introduites pour au moins un utilisateur dudit système informatique, dit utilisateur cible, en fonction de données de ciblage dudit système informatique, stockées dans des moyens de stockage de données (12) dudit serveur (1) ; Emission dudit troisième message informatique à destination dudit utilisateur cible de sorte à simuler une attaque de type hameçonnage ; Détection d’au moins une réaction audit troisième message informatique mise en œuvre par ledit utilisateur cible dans ledit système informatique. Procédé selon la revendication 1, dans lequel l’étape (b) comprend l’identification de chaque donnée de personnalisation originale dudit premier message informatique, et son remplacement par une donnée générique représentative du type de donnée de personnalisation. Procédé selon la revendication 2, dans lequel l’étape (c) comprend le remplacement de chaque donnée générique par une nouvelle donnée de personnalisation du même type. Procédé selon l’une des revendications 1 à 3, dans lequel les données de personnalisation sont choisies parmi un numéro IBAN, un numéro de carte bancaire, un nom et/ou un prénom, un numéro administratif, une adresse de messagerie électronique, une adresse d’un portefeuille de cryptomonnaie, une adresse IP, un numéro de téléphone et une adresse physique. Procédé selon l’une des revendications 1 à 4, dans lequel l’étape (a) est mise en œuvre par un modèle de langage génératif, en particulier un grand modèle de langage. Procédé selon la revendication 5, dans lequel ledit modèle présente un paramètre représentatif de la langue du premier message électronique et/ou un paramètre représentatif d’un degré d'anonymisation à appliquer. Procédé selon l’une des revendications 1 à 6, dans lequel l’étape (c) comprend la détermination préalable dudit utilisateur cible en fonction desdites données de ciblage. Procédé selon la revendication 7, dans laquelle lesdites nouvelles données de personnalisation sont associées à l’utilisateur cible ou à un autre individu déterminé en fonction dudit utilisateur cible et desdites données de ciblage. Procédé selon l‘une des revendications 1 à 8, dans lequel l’étape (d) comprend outre l’émission d’un quatrième message informatique à destination dudit utilisateur cible en fonction de la réaction détectée. Procédé selon l‘une des revendications 1 à 9, dans lequel lesdits premier, deuxième et troisième messages informatiques sont des courriers électroniques, en particulier au format .eml. Serveur (1) d’un système informatique, caractérisé en ce qu’il comprend des moyens de traitement de données (11), configurés pour : Obtenir au moins un premier message informatique d’une tentative d’hameçonnage, ledit premier message informatique comprenant des données de personnalisation originales ; générer un deuxième message informatique correspondant au premier message informatique dans lequel lesdites données de personnalisation originales ont été anonymisées ; générer un troisième message informatique correspondant au deuxième message informatique dans lequel de nouvelles données de personnalisation ont été introduites pour au moins un utilisateur dudit système informatique, dit utilisateur cible, en fonction de données de ciblage dudit système informatique, stockées dans des moyens de stockage de données (12) dudit serveur (1) ; émettre ledit troisième message informatique à destination dudit utilisateur cible de sorte à simuler une attaque de type hameçonnage dans ledit système informatique ; détecter au moins une réaction audit troisième message informatique mise en œuvre par ledit utilisateur cible dans ledit système informatique. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 10 pour la mise en œuvre d’un procédé de détection d’une vulnérabilité à une attaque de type hameçonnage dans un système informatique, lorsque ledit programme est exécuté sur un ordinateur. Moyen de stockage lisible par un équipement informatique sur lequel est enregistré un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 10 pour la mise en œuvre d’un procédé de détection d’une vulnérabilité à une attaque de type hameçonnage dans un système informatique.