Utilisateurs les plus vulnérables

Ce rapport est un cumul de vulnérabilité sur 12 mois par utilisateur : une ligne par personne ayant reçu au moins une simulation au cours de l’année écoulée, avec le nombre et le taux de clics, de saisies d’identifiants et de signalements, une série de clics en cours, et une liste concaténée des 5 derniers résultats. La fenêtre couvre 12 mois calendaires (minuit UTC le même jour du mois, douze mois plus tôt), et non une durée de 365 jours. La configuration, les identifiants, la pagination et la nouvelle tentative en cas de limitation de débit sont identiques à ceux du guide de connectivité Power BI / Excel. Ajoutez d’abord la requête partagée Fn_FetchAll ; ce rapport l’appelle par son nom.

​

Portées de clé requises

Ce rapport utilise la liste opérationnelle des résultats par personne, et non la famille d’aperçus de reporting. Une clé disposant uniquement de reporting:read ne peut pas appeler GET /v1/simulation_results (l’API renvoie 403). Voir choisir la bonne granularité.

​

Points de terminaison sources

Filtres autorisés sur la liste des résultats : limit, page_token, simulation, entity. Cette liste ne comporte pas de delivered_after / start_date, les 12 derniers mois sont donc appliqués dans Power Query après le parcours complet. Champs utilisés pour chaque résultat : id, simulation, entity, status, targeted_at, delivered_at, bounced_at, opened_at, clicked_at, attachment_opened_at, credential_submitted_at, reported_at, reported_before_interaction, bot_activity_detected, email_subject, sender_email, difficulty_level, created_at, updated_at.

​

Granularité

Une ligne par entité possédant au moins un résultat avec delivered_at au cours des 12 derniers mois calendaires. Une personne ciblée mais à laquelle rien n’a été remis n’apparaît pas. Les simulations multiples pour une même personne sont regroupées ici. Budget de requêtes : un parcours paginé de tous les résultats de simulation de l’organisation, plus un parcours des entités. Définissez toujours limit = "500".

​

Priorité des résultats (last_5_assessments)

Chacun des cinq résultats remis les plus récents (delivered_at décroissant) est résumé sous la forme YYYY-MM-DD: <outcome>. Le premier horodatage correspondant l’emporte, par ordre de priorité décroissante : « Remis uniquement » correspond à no action (le message est arrivé ; la personne n’a rien fait). Une personne qui a cliqué puis signalé correspond à clicked : le signalement ne prime pas sur une interaction à risque dans cette liste. Les lignes signalées comme robots reçoivent tout de même un libellé de résultat d’après les horodatages présents ; elles n’incrémentent simplement pas les décomptes de clics et d’identifiants saisis. Série de clics en cours : parcourez ces mêmes résultats remis du plus récent au plus ancien et comptez les lignes consécutives où clicked_at n’est pas nul et bot_activity_detected n’est pas true. Arrêtez-vous à la première ligne qui ne correspond pas.

​

Correspondance des colonnes

Les noms de colonnes historiques proviennent de l’export de votre fournisseur précédent. Les champs /v1 sont les noms de l’API publique ; la requête calcule les décomptes et les taux. Clé de jointure conservée pour un modèle en étoile : entity_id.

​

Divergences par rapport à l’export historique

• L’activité des robots est exclue des décomptes de clics et d’identifiants saisis. L’export d’un fournisseur précédent comptabilisait les interactions d’outils d’analyse automatisés ou de robots comme des clics et des saisies d’identifiants. Cette requête ne le fait pas. Un résultat avec bot_activity_detected = true reste une simulation remise : il est comptabilisé dans total_received et dans les agrégats de signalements, mais il est traité comme un non-clic et une non-saisie : il est omis de clicks / credential_submissions et il interrompt une série de clics en cours. Ne « corrigez » pas cela en comptant les robots pour vous aligner sur l’export historique.
• Le signalement ne prime pas sur un clic dans last_5_assessments. Une personne qui a cliqué puis signalé est libellée clicked.
• Les informations complémentaires de l’annuaire sont omises, et non mises à null. Le service et les champs similaires ne figurent pas dans /v1.
• Aucun filtre temporel côté serveur. GET /v1/simulation_results ne comporte pas de delivered_after. La requête parcourt tous les résultats, puis conserve delivered_at au cours des 12 derniers mois calendaires. Une grande organisation ayant un long historique peut consommer une plus grande part du budget de limitation de débit par clé qu’une liste filtrée.

​

Étapes suivantes