Quel est le niveau de protection des sites populaires des Émirats et d'Arabie saoudite ? 1 000 domaines .ae et .sa mesurés (septembre 2026)

J'ai pris les 500 premiers domaines en .ae et les 500 premiers domaines en .sa du classement Tranco, une liste conçue pour la recherche, et je les ai analysés le matin du 24 septembre 2026 depuis l'extérieur, comme les voit n'importe quel visiteur ou serveur de messagerie. La mesure était passive : des requêtes DNS, une visite de chaque page d'accueil et quelques connexions TLS par domaine, sans recherche de vulnérabilités ni tentative de connexion. Les résultats ont été comptés par les mêmes tests que ceux des outils gratuits de ShieldWave. Je ne nomme aucun des domaines.

J'ai mesuré depuis la Pologne. Pour 344 des 1 000 domaines, la page d'accueil n'a pas répondu à mes requêtes, a affiché un contrôle anti-robots ou a renvoyé une erreur. Ces pages d'accueil sont écartées des chiffres sur les pages et ne sont pas comptées comme non sécurisées. La section sur la méthode explique pourquoi.

Principaux constats

• Le 24 septembre 2026, 499 des 987 domaines .ae et .sa populaires (50,6 %) avaient une politique DMARC demandant aux serveurs de messagerie destinataires de rejeter ou de mettre en quarantaine les e-mails falsifiés : 234 sur 498 aux Émirats arabes unis (EAU, 47,0 %) et 265 sur 489 en Arabie saoudite (54,2 %).
• Dans la mesure du 24 septembre 2026, 408 des 652 pages d'accueil populaires des EAU et d'Arabie saoudite servies en HTTPS (62,6 %) envoyaient un en-tête HSTS, et 280 sur 656 (42,7 %) appliquaient une Content-Security-Policy.
• En septembre 2026, 182 des 832 domaines populaires des EAU et d'Arabie saoudite (21,9 %) acceptaient encore les connexions TLS 1.0. Sur ces 182, 101 sont servis par Cloudflare, qui accepte TLS 1.0 tant que le propriétaire n'a pas relevé la version minimale.
• Les domaines saoudiens qui publient DMARC choisissent le plus souvent son réglage le plus strict : 232 des 363 enregistrements saoudiens (63,9 %) indiquent p=reject, contre 139 sur 368 aux EAU (37,8 %).
• Il n'existe aucun enregistrement DMARC pour 256 des 987 domaines (25,9 %), et 198 autres (20,1 %) en ont un réglé sur p=none, qui ne bloque rien.
• J'ai trouvé un fichier security.txt, qui indique aux chercheurs où signaler une vulnérabilité, sur au moins 41 sites sur 649 (6,3 %).
• Par rapport à la même mesure sur des domaines polonais, les pages d'accueil des EAU et d'Arabie saoudite envoient plus souvent HSTS et CSP, alors que moins de domaines prennent en charge TLS 1.3. La comparaison a des limites, décrites plus bas.

Usurpation d'e-mail : DMARC et SPF

Un e-mail falsifié avec l'adresse de votre entreprise dans le champ « De » suffit pour envoyer une fausse facture à un client. Trois enregistrements DNS protègent contre cela : SPF, DKIM et DMARC, que j'explique dans SPF, DKIM et DMARC expliqués. DMARC est celui qui tranche : il dit au serveur destinataire quoi faire d'un message qui se prétend de vous mais échoue aux vérifications.

SPF est courant : 843 des 987 domaines l'ont (85,4 %), 426 sur 497 aux EAU (85,7 %) et 417 sur 490 en Arabie saoudite (85,1 %). SPF seul ne vérifie pourtant pas l'adresse que le destinataire voit dans le champ « De ». Seul DMARC le fait.

• EAU (.ae)47,0%234 sur 498
• Arabie saoudite (.sa)54,2%265 sur 489
• Pologne (.pl), pour comparaison46,1%460 sur 997

L'enregistrement propre au domaine avec p=quarantine ou p=reject, appliqué à tout le courrier (pct=100 ou sans pct). Domaines avec une réponse DNS définitive. Pologne : la même mesure le même jour.

Parmi les domaines qui reçoivent du courrier (avec des enregistrements MX), la part ayant une politique bloquante est un peu plus élevée : 216 sur 430 aux EAU (50,2 %) et 253 sur 426 en Arabie saoudite (59,4 %). Pour les autres, c'est entièrement aux filtres du destinataire de décider si un message falsifié arrive dans la boîte de réception.

p=none n'est pas une erreur mais la première étape recommandée : le domaine collecte des rapports, et son propriétaire voit qui envoie du courrier en son nom. Sur les 731 enregistrements DMARC, 618 (84,5 %) comprennent une adresse pour les rapports agrégés (rua). La protection ne commence toutefois qu'avec quarantine ou reject. Les domaines saoudiens qui publient DMARC vont en majorité jusqu'au bout : 232 des 363 enregistrements (63,9 %) indiquent p=reject. Aux EAU, les trois réglages sont plus proches de l'égalité : p=none sur 126 sur 368 (34,2 %), quarantine sur 103 (28,0 %) et reject sur 139 (37,8 %).

Un détail dans la liste saoudienne : 26 domaines utilisent quarantine ou reject avec un pct inférieur à 100, ce qui n'applique la politique qu'à cette part des messages en échec.

Défauts SPF plus mineurs : 10 des 843 enregistrements (1,2 %) demandent plus que les 10 consultations DNS autorisées par la norme, 11 domaines (1,3 %) publient deux enregistrements SPF au lieu d'un, et un termine son enregistrement par +all, ce qui autorise n'importe quel serveur à envoyer du courrier en son nom.

Je ne rapporte pas DKIM. Les sélecteurs sous lesquels les clés DKIM sont publiées ne peuvent pas être listés par le DNS, si bien que « introuvable » voudrait seulement dire « pas sous les noms usuels ».

Chiffrement : HTTPS, HSTS et TLS

HTTPS lui-même est la norme : 652 des 656 pages d'accueil analysées (99,4 %) se chargent depuis une adresse https://. Les différences tiennent à ce qui l'accompagne.

Les dénominateurs diffèrent parce que chaque ligne ne compte que les domaines pour lesquels le test a obtenu une réponse. La section sur la méthode donne les détails.

HSTS est un en-tête qui dit au navigateur de n'utiliser que HTTPS pour le domaine pendant une durée donnée. Sans lui, chaque visite à une adresse saisie sans https:// commence par une connexion non chiffrée avant que le serveur la redirige, et sur le Wi-Fi de quelqu'un d'autre cette connexion peut être interceptée. HSTS est envoyé par 408 des 652 pages d'accueil en HTTPS (62,6 %), et par 246 (37,7 %) avec la durée recommandée d'au moins un an.

TLS 1.0 et 1.1 sont d'anciennes versions du protocole de chiffrement. Les navigateurs les ont désactivées en 2020, et l'IETF les a officiellement abandonnées en 2021 (RFC 8996). TLS 1.0 est encore accepté par 182 des 832 domaines (21,9 %). Un visiteur avec un navigateur récent se connecte de toute façon en TLS 1.2 ou 1.3, ce n'est donc pas un moyen de prendre le contrôle d'un site. Cela signifie en revanche que le serveur accepte un chiffrement obsolète quand on le lui demande, et les auditeurs ainsi que les questionnaires de sécurité des fournisseurs demandent de désactiver les anciennes versions.

Sur ces 182 domaines, 101 (55,5 %) sont servis par Cloudflare, qui accepte TLS 1.0 par défaut et ne s'arrête que lorsque le propriétaire relève la version minimale dans le tableau de bord : 60 sur 92 aux EAU et 41 sur 90 en Arabie saoudite. Les autres acceptent TLS 1.0 sur leurs propres serveurs ou chez d'autres fournisseurs.

TLS 1.3, la version actuelle, fonctionne sur 620 des 834 domaines (74,3 %), plus souvent aux EAU (350 sur 443, 79,0 %) qu'en Arabie saoudite (270 sur 391, 69,1 %).

CAA est un enregistrement DNS qui liste les autorités de certification autorisées à émettre des certificats pour le domaine, les autres devant alors refuser. J'en ai trouvé un pour 99 des 994 domaines (10,0 %).

En-têtes de sécurité

Les en-têtes de sécurité sont quelques lignes d'instructions que le serveur envoie au navigateur avec la page. Je les décris dans En-têtes de sécurité d'un site web : ce que c'est et quoi demander. Voici leur fréquence sur les pages d'accueil (HSTS figure dans la section sur le chiffrement) :

12 autres pages d'accueil (1,8 %) ont une CSP uniquement en mode Report-Only, dans lequel le navigateur ne bloque rien.

Le contrôle gratuit des en-têtes de sécurité (en anglais) les note de A à F. Chaque en-tête reçoit une lettre, HSTS et CSP comptent double, les autres comptent une fois, et la moyenne donne la note finale. L'étude a utilisé exactement cette échelle.

• A2,6%17 sur 656
• B39,0%256 sur 656
• C19,4%127 sur 656
• D18,6%122 sur 656
• F20,4%134 sur 656

L'échelle du contrôle gratuit des en-têtes de ShieldWave. HSTS et CSP comptent double, les autres en-têtes une fois.

Un F ne veut pas dire qu'un site a une faille, et un A ne garantit pas qu'il n'en a pas. Les en-têtes sont une deuxième ligne de défense : ils limitent les dégâts quand autre chose échoue. Des en-têtes absents signalent généralement la configuration par défaut d'un serveur, qui ne les ajoute pas. Souvent, un CDN ou une extension les ajoute plus tard.

Plateformes et logiciels obsolètes

J'ai reconnu une plateforme sur 267 des 656 pages d'accueil. Les 389 autres (59,3 %) sont développées sur mesure ou ne révèlent pas ce qui les fait tourner : les parts ci-dessous sont donc des minimums.

WordPress fait tourner 88 des 656 pages d'accueil (13,4 %) : 55 sur 346 aux EAU et 33 sur 310 en Arabie saoudite. Viennent ensuite Drupal (31), Microsoft SharePoint (28), Shopify (27), Sitecore (23) et Magento (15).

La version de WordPress est visible sur 58 des 88. Ce sont de petits nombres, je ne donne donc que des effectifs :

• 30 des 58 ne sont pas sur la dernière version, la 7.1.2,
• 25 sont sur une branche antérieure à 7.1,
• 18 ne sont pas sur la dernière version de leur propre branche, ils manquent donc des correctifs de sécurité déjà publiés pour elle.

Seules 34 des 656 pages d'accueil indiquent leur version de PHP dans un en-tête : cela décrit donc ces 34, pas le web entier. Parmi elles, 16 utilisent des branches qui ne reçoivent plus aucun correctif (8.1 et antérieures), 13 ne reçoivent que des correctifs de sécurité (8.2 et 8.3), et 5 sont pleinement prises en charge (8.4 et 8.5).

Un nom de serveur avec un numéro de version apparaît dans les en-têtes de 60 des 656 pages d'accueil (9,1 %) ; dans 34 de ces 60 cas, c'est Microsoft IIS. Divulguer la version n'est pas une faille en soi, mais cela réduit le nombre de bogues connus qui peuvent s'appliquer.

Je n'ai pas vérifié les extensions dans cette étude. Si votre site tourne sur WordPress, commencez par Extensions WordPress obsolètes : quoi mettre à jour en premier et quoi supprimer.

security.txt : où signaler une vulnérabilité

Le fichier /.well-known/security.txt (RFC 9116) donne l'adresse à laquelle un chercheur en sécurité peut signaler une vulnérabilité qu'il a trouvée. Sans lui, un signalement part vers une adresse de contact générale, ou nulle part.

J'en ai trouvé un avec un champ Contact: sur 41 sites sur 649 (6,3 %) : 16 sur 345 aux EAU (4,6 %) et 25 sur 304 en Arabie saoudite (8,2 %). C'est un minimum : 21 autres sites ont répondu par une redirection vers un fichier security.txt à une autre adresse, et je n'ai pas suivi les redirections. Sur les 41 fichiers, 32 ont le champ Expires exigé par la norme.

Traceurs et plateformes de consentement

Cette partie est descriptive. Aucun JavaScript n'a été exécuté, je ne vois donc que les outils nommés dans le HTML de la page d'accueil. Je ne peux pas dire s'ils s'exécutent ni quand : un script peut attendre le consentement du visiteur, et Google Tag Manager peut charger des outils qui ne figurent pas dans le code de la page.

• Google Tag Manager38,6%253 sur 656
• Google Analytics36,4%239 sur 656
• Meta Pixel9,8%64 sur 656
• Microsoft Clarity5,9%39 sur 656
• TikTok Pixel3,8%25 sur 656
• Snap Pixel3,5%23 sur 656
• Hotjar3,0%20 sur 656
• X (Twitter) Pixel2,4%16 sur 656

Sous toute forme : script, extrait d'installation ou simple appel. Figurer dans le code ne montre pas si l'outil s'exécute avant le consentement.

Google Analytics ou Google Tag Manager apparaît dans le code de 395 des 656 pages d'accueil (60,2 %). Google Consent Mode avec refus par défaut, où les outils de Google fonctionnent sans cookies tant que le consentement n'est pas donné, apparaît sur 12 des 656 pages d'accueil (1,8 %).

Une plateforme de consentement connue, comme OneTrust, CookieYes ou TrustArc, apparaît sur 41 des 656 pages d'accueil (6,3 %). Cela ne veut pas dire que les autres n'ont pas de bandeau de consentement. Les bandeaux sur mesure, ceux intégrés à une plateforme et les outils chargés par Google Tag Manager sont invisibles pour cette méthode, je ne tire donc aucune conclusion sur la conformité légale à partir de ces chiffres.

Comparaison avec la Pologne

Le même jour et avec les mêmes tests, j'ai mesuré les 1 000 domaines .pl les plus populaires (résultats). Les chiffres du DNS se comparent bien, car dans les deux listes ils couvrent presque tous les domaines. Les chiffres des pages d'accueil moins bien : les listes du Golfe descendent plus loin dans le classement (jusqu'au rang 835 367, contre 136 495 pour la Pologne), et 344 des 1 000 pages d'accueil du Golfe n'ont pas pu être analysées depuis la Pologne, contre 113 des 1 000 pages polonaises. Lisez les chiffres des pages d'accueil comme une comparaison approximative.

• HSTS, EAU et Arabie saoudite62,6%408 sur 652
• HSTS, Pologne46,0%406 sur 882
• CSP, EAU et Arabie saoudite42,7%280 sur 656
• CSP, Pologne24,5%217 sur 887

HSTS sur les pages d'accueil servies en HTTPS, CSP sur toutes les pages d'accueil analysées. Les deux mesurés le 24 septembre 2026 avec les mêmes tests.

Moins de pages d'accueil des EAU et d'Arabie saoudite obtiennent aussi un F au contrôle des en-têtes : 134 sur 656 (20,4 %), contre 290 sur 887 (32,7 %) en Pologne. La Pologne est en avance sur TLS 1.3 (833 domaines sur 953, 87,4 %, contre 620 sur 834, 74,3 %) et sur les enregistrements CAA (192 sur 999, 19,2 %, contre 99 sur 994, 10,0 %). Sur DMARC, l'écart est plus faible : 50,6 % des domaines des EAU et d'Arabie saoudite et 46,1 % des domaines polonais bloquent le courrier usurpé.

Ce que cela signifie pour votre entreprise

Si ces réglages manquent sur certains des sites les plus populaires de la région, ils sont faciles à manquer aussi sur un site plus petit. Chacun des contrôles ci-dessous prend une minute et ne demande aucun accès à votre serveur.

1. E-mail. Lancez le contrôle SPF, DKIM et DMARC (en anglais). Si vous n'avez pas de DMARC ou si vous êtes en p=none, passez progressivement à quarantine comme décrit dans SPF, DKIM et DMARC expliqués. Cela protège contre les fausses factures envoyées depuis votre domaine.
2. Chiffrement. Le contrôle de certificat SSL (en anglais) montre le certificat, la redirection HTTPS et les versions de TLS. Si votre site est derrière Cloudflare, changez le minimum dans le tableau de bord, sous SSL/TLS, Edge Certificates, Minimum TLS Version. Choisissez TLS 1.2.
3. En-têtes. Le contrôle des en-têtes de sécurité (en anglais) montre ce qui manque. En-têtes de sécurité d'un site web contient des consignes prêtes pour votre développeur : commencez par HSTS avec un max-age court et CSP en mode Report-Only.
4. security.txt. Publiez /.well-known/security.txt avec les champs Contact et Expires. Ce sont quelques lignes de texte.
5. Logiciels. Mettez à jour le CMS et les extensions, et retirez les numéros de version des en-têtes du serveur. Pour WordPress, voir Extensions WordPress obsolètes.
6. Traceurs et consentement. Le contrôle des cookies avant consentement (en anglais) montre si votre page d'accueil dépose des cookies de suivi ou charge des outils de mesure d'audience et de publicité avant que le visiteur accepte.

Les lois sur la protection des données des deux pays demandent des mesures techniques appropriées pour protéger les données personnelles : aux EAU, l'article 20 du décret-loi fédéral n° 45 de 2021 ; en Arabie saoudite, l'article 19 de la loi sur la protection des données personnelles. Aucune ne nomme DMARC ou HSTS, mais ce sont des réglages que n'importe qui peut vérifier depuis l'extérieur. Ce que chaque loi demande au site d'une entreprise est expliqué pour les EAU et pour l'Arabie saoudite. Si vous fournissez des entreprises de l'UE, leurs questionnaires fournisseurs NIS2 portent sur les mêmes réglages : voir NIS2 et votre site web.

Méthode

Domaines. Liste Tranco L5PV4, générée le 23 septembre 2026 à 22 h 00 UTC à partir de 30 jours de données (du 25 août au 23 septembre 2026) de cinq fournisseurs : Chrome UX Report, Farsight, Majestic, Cloudflare Radar et Cisco Umbrella. Tranco est un classement conçu pour la recherche et renforcé contre la manipulation. J'ai pris les 500 premiers domaines en .ae et les 500 premiers domaines en .sa dans l'ordre du classement, domaines de deuxième niveau comme gov.ae et com.sa compris. Le million de tête compte 744 domaines .ae, et les 500 retenus se classent de 3 319 à 705 110 ; il compte 548 domaines .sa, et les 500 retenus se classent de 1 245 à 835 367. Les domaines sous les codes pays en écriture arabe ne sont pas inclus. Tranco classe des domaines, pas des sites web, les listes contiennent donc aussi des domaines techniques (CDN, hôtes de publicité et de mesure) sans page d'accueil.

Quand et d'où. 24 septembre 2026 : la liste .sa de 07 h 32 à 07 h 39 UTC (10 h 32 à 10 h 39 à Riyad) et la liste .ae de 07 h 43 à 07 h 47 UTC (11 h 43 à 11 h 47 aux EAU), depuis une seule connexion réseau en Pologne. Les requêtes DNS sont allées aux résolveurs publics 1.1.1.1 et 8.8.8.8. Chaque requête HTTP s'identifiait comme ShieldWaveResearch/1.0 avec un lien vers shieldwave.io, sans se faire passer pour un navigateur.

Ce qui a été envoyé. Par domaine, uniquement :

1. des requêtes DNS : adresses, MX, TXT (SPF et DMARC), CAA,
2. une visite de la page d'accueil (https://, ou http:// quand https ne répondait pas ; 5 redirections au maximum),
3. une requête http:// simple pour voir si elle redirige vers https,
4. des négociations TLS sur le port 443 : une négociation complète et quatre sondes de version (1.0, 1.1, 1.2 et 1.3),
5. une requête pour /.well-known/security.txt.

Rien d'autre : pas de recherche de fichiers, de panneaux d'administration ou de sauvegardes, et pas de formulaires, de connexions ni de charges de test.

Les mêmes tests que les outils gratuits. Les résultats ont été calculés par le même code que celui qui fait tourner les outils gratuits de ShieldWave (certificat, e-mail, en-têtes et cookies), dans l'état du commit 8db196d. N'importe qui peut vérifier son propre domaine à la même mesure.

Dénominateurs et exclusions. Chaque chiffre a son propre dénominateur, car tous les domaines ne répondent pas à tous les tests. Depuis la Pologne, 656 des 1 000 pages d'accueil ont pu être analysées : 346 sur 500 aux EAU et 310 sur 500 en Arabie saoudite. Parmi les autres, 178 domaines n'ont donné aucune réponse HTTP (61 .ae, 117 .sa), 144 ont répondu par un contrôle anti-robots ou un blocage comme un 403 (84 .ae, 60 .sa), et 22 ont renvoyé une autre erreur (9 .ae, 13 .sa). La plupart des domaines .sa sans réponse se résolvent dans le DNS mais laissent expirer aussi bien la connexion https que http, ce à quoi ressemble le blocage du trafic étranger, sans que je puisse en prouver la cause. Ces nombres décrivent mon point de mesure, pas la sécurité des sites. Les domaines exclus sont écartés des chiffres sur les pages d'accueil (en-têtes, HTML, security.txt, redirection) et ne sont pas comptés comme non sécurisés, mais ils restent dans les chiffres du DNS, de l'e-mail et de TLS, qui ne dépendent pas de la page. Les chiffres du DNS ne comptent que les réponses définitives (pour DMARC, 987 sur 1 000 ; le test d'e-mail de 10 domaines .sa a expiré sur des serveurs de noms lents).

Définitions. Une politique DMARC qui met en quarantaine ou rejette est l'enregistrement propre au domaine avec p=quarantine ou p=reject et pct=100 ou sans pct. Un enregistrement hérité d'un domaine parent ne compte pas. HSTS n'est compté que sur les pages d'accueil qui aboutissent en HTTPS, et CSP seulement quand elle est appliquée. security.txt compte quand la réponse est un 200 avec un champ Contact: ; une page HTML ne compte jamais.

Limites.

• Page d'accueil seulement, une visite, un jour. D'autres pages peuvent envoyer d'autres en-têtes.
• Pas de JavaScript : les traceurs et les outils de consentement sont lus dans le HTML. Je ne vois pas ce que charge Google Tag Manager ni ce que des scripts stockent plus tard.
• De nombreux résultats reflètent les réglages par défaut d'un CDN ou d'un hébergeur (TLS 1.0 chez Cloudflare, en-têtes ajoutés ou non en périphérie).
• Les sites qui ont bloqué la visite manquent dans les chiffres des pages d'accueil, et ils peuvent différer de ceux qui restent.
• security.txt est un minimum, car les redirections n'ont pas été suivies.
• La détection des plateformes est un minimum (59,3 % des pages d'accueil non reconnues).
• DKIM n'est pas rapporté.
• Mesuré depuis la Pologne : les sites qui varient selon la localisation du visiteur peuvent montrer autre chose aux visiteurs du Golfe.

Répétabilité et contrôles. La liste .ae a aussi été collectée lors d'une première exécution complète environ 15 minutes plus tôt, que je ne publie pas car j'ai corrigé le code de collecte après elle. Entre les deux exécutions, l'écart médian sur l'ensemble des indicateurs était de 0,0 point de pourcentage et le 90e centile de 0,4 ; aucun indicateur avec un dénominateur de 100 ou plus n'a bougé de plus de 1,1 point. Les écarts plus grands, jusqu'à 6,3 points, concernaient des dénominateurs inférieurs à 60, ce qui explique que les petits groupes ne reçoivent que des effectifs dans cet article. La liste .sa a été collectée une fois, avec le code corrigé. Séparément, j'ai remesuré 36 domaines tirés au hasard (8 .ae, 8 .sa et 20 .pl) avec d'autres outils : DMARC et SPF par un autre résolveur (9.9.9.9), HSTS et l'en-tête Server avec curl, TLS 1.0 avec openssl, security.txt avec curl. Les 216 comparaisons concordaient.

Données. Je ne publie pas les données brutes, car elles nomment des sites précis. Les chiffres agrégés, chacun avec numérateur, dénominateur, pourcentage et population, sont téléchargeables librement sous licence CC BY 4.0 : gulf-2026-09.csv et gulf-2026-09.json (fichiers en anglais). Ils couvrent les deux pays ensemble ; les chiffres par pays de cet article proviennent de la même exécution, comptés séparément avec le même code. La mesure peut être répétée : la liste Tranco est publique, et chaque test fonctionne dans les outils gratuits de ShieldWave.

Comment citer

Version courte : Source : ShieldWave, mesure des 500 domaines .ae et des 500 domaines .sa les plus populaires, 24 septembre 2026, https://shieldwave.io/blog/uae-saudi-websites-security-2026/

Version complète : Radosław Fedorczuk (ShieldWave, ENSOMEDIA), « Quel est le niveau de protection des sites populaires des Émirats et d'Arabie saoudite ? 1 000 domaines .ae et .sa mesurés (septembre 2026) », 24 septembre 2026, https://shieldwave.io/blog/uae-saudi-websites-security-2026/. Données agrégées sous licence CC BY 4.0.

Questions sur la méthode ou les données : support@shieldwave.io.