Politique de confidentialité

Le responsable du traitement sur ce site est l’éditeur indiqué dans les mentions légales. Pour les données que le produit collecte sur les visiteurs de nos clients, c’est le client concerné qui est responsable ; nous y agissons en qualité de sous-traitant.

Responsable du traitement

Kokolorum GmbH
Industriering Ost 66
47906 Kempen

Délégué à la protection des données

heyData GmbH
Schützenstraße 5
10117 Berlin
www.heydata.eu
datenschutz@heydata.eu

Point de contact pour la protection des données

privacy@metrunio.com

Autorité de contrôle compétente

Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LDI NRW), Kavalleriestraße 2–4, 40213 Düsseldorf

Metrunio traite des données dans deux rôles distincts. Comme responsable, pour ce site et pour les comptes de nos clients. Comme sous-traitant, pour les données de mesure collectées pour le compte de nos clients sur leurs sites — là, c’est le client qui détermine les finalités et les moyens, pas nous. Les deux rôles ont des bases juridiques, des destinataires et des délais différents ; ils sont donc exposés séparément.

L’art. 6.1.b RGPD ne s’applique que si vous êtes vous-même, en tant que personne physique, notre cocontractant et que le traitement est nécessaire au contrat. Si vous agissez pour le compte d’une entreprise, par exemple en tant que dirigeant, salarié ou agence mandatée, le traitement repose sur l’art. 6.1.f RGPD. Notre intérêt légitime réside dans la création et la gestion du compte client professionnel, la connexion et la sécurité de votre accès, la facturation et la communication nécessaire à l’exécution du contrat. Vous pouvez vous opposer au traitement fondé sur le point f pour des raisons tenant à votre situation particulière au titre de l’art. 21 RGPD.

Connexion avec des clés d’accès

Si vous créez une clé d’accès dans le portail, vous pouvez vous connecter avec elle sans mot de passe ou l’utiliser comme seconde étape après le mot de passe. Une clé d’accès n’est valable que pour l’adresse du portail. Pour chaque clé d’accès, nous conservons son identifiant, la clé publique, le compteur de votre appareil, les modes de transmission signalés par le navigateur, l’indication d’une sauvegarde ou d’une synchronisation, le nom que vous lui donnez et les dates de création et de dernière utilisation. Pour que votre appareil puisse afficher la clé d’accès, nous lui transmettons lors de sa création votre adresse e-mail, votre nom et l’identifiant interne de votre compte utilisateur.

Metrunio ne reçoit pas votre clé privée. Votre appareil ou le fournisseur de clés d’accès que vous avez choisi la gère ; selon le fournisseur et vos paramètres, elle peut être sauvegardée et synchronisée entre vos appareils. Metrunio conserve la clé publique ainsi que les données d’identification et de gestion décrites. Une vérification par code PIN ou biométrique est effectuée par votre authentificateur ; Metrunio ne reçoit à cette occasion aucune donnée d’empreinte digitale ni de visage.

Votre appareil ou le fournisseur de clés d’accès que vous avez choisi, par exemple celui de votre système d’exploitation, de votre navigateur ou de votre gestionnaire de mots de passe, enregistre la clé d’accès avec votre adresse e-mail, votre nom et l’identifiant de votre compte utilisateur. S’il la sauvegarde ou la synchronise avec vos autres appareils, et quelles données il reçoit à cette fin, dépend de ce fournisseur et de vos paramètres. Il est dans cette mesure destinataire de ces données ; votre choix n’en fait pas notre sous-traitant.

La création et l’utilisation d’une clé d’accès sur votre appareil sont strictement nécessaires au mode de connexion que vous demandez expressément (§ 25.2.2 TDDDG) ; nous ne demandons pas de consentement distinct à cet effet. Notre traitement des données repose, comme pour les autres données du compte, sur l’art. 6.1.b ou 6.1.f RGPD (voir sous le tableau).

Pour chaque connexion et chaque création, nous générons un défi à partir de nombres aléatoires, valable une seule fois et pendant cinq minutes. Seule son empreinte est conservée. Nous supprimons immédiatement un défi utilisé et un défi non utilisé au plus tard six minutes après sa création.

Nous supprimons une clé d’accès dès que vous la retirez et, à défaut, avec votre compte utilisateur. Un compte utilisateur peut appartenir à plusieurs comptes clients, par exemple si vous travaillez pour une agence. Si un seul compte client prend fin, votre compte utilisateur et vos clés d’accès sont donc conservés tant que vous appartenez à un autre compte ; lorsque le dernier prend fin, nous supprimons le compte utilisateur avec lui 30 jours après la fin du contrat (première ligne du tableau). Si un Admin vous retire d’un compte client, votre compte utilisateur et ses clés d’accès sont également conservés ; vous pouvez en demander la suppression à tout moment. La création et le retrait d’une clé d’accès figurent, avec son nom et son identifiant interne, dans le journal de chaque compte client auquel vous appartenez, et une connexion avec une clé d’accès comme toute connexion. Les tentatives de connexion refusées figurent dans le journal de la plateforme et, pour le lien de connexion de l’app Shopify, dans le journal du compte client. Nous supprimons ces entrées au bout de 180 jours, même si vous retirez la clé d’accès plus tôt, et celles du journal d’un compte client au plus tard avec celui-ci. Pour qu’une clé d’accès retirée ne réapparaisse pas après la restauration d’une sauvegarde, nous consignons en outre le retrait, avec l’identifiant interne de la clé d’accès, dans un journal des opérations distinct pendant 90 jours.

Création via l’app Shopify

Lors de la création via notre app Shopify, Shopify nous transmet les données de la boutique nécessaires au rattachement (identifiant, nom, langue, devise, fuseau horaire et domaines de la boutique), le nom du titulaire de la boutique et l’adresse e-mail enregistrés dans les données de base de la boutique — cette adresse devient l’adresse de contact du compte — ainsi que l’adresse de facturation de la boutique. Nous ne proposons l’adresse de facturation que comme raison sociale et adresse pour le contrat de sous-traitance ; est enregistré ce que la personne agissante confirme. De la personne qui utilise l’app et crée le compte, nous recevons son identifiant utilisateur Shopify, son nom, son adresse e-mail et l’indication de si Shopify la désigne comme titulaire de la boutique. Cette personne devient titulaire du compte Metrunio, et ses données attestent qui a accepté les conditions générales et le contrat de sous-traitance. Nous utilisons ces informations pour créer et gérer le compte Metrunio et pour le relier à la boutique.

Dans la mesure où la personne concernée est elle-même partie au contrat et où le traitement est nécessaire, celui-ci repose sur l’art. 6.1.b RGPD. Pour les interlocuteurs d’une entreprise, il repose sur l’art. 6.1.f RGPD ; notre intérêt légitime réside dans la gestion du compte client professionnel et dans la communication liée à l’exécution du contrat. Vous pouvez vous opposer à un traitement fondé sur le point f pour des raisons tenant à votre situation particulière (art. 21 RGPD) ; vos autres droits figurent sous « Ce que vous pouvez exiger ». Nous conservons ces informations comme les données du compte de la première ligne du tableau ci-dessus : pendant la durée du contrat, puis jusqu’à la suppression du compte 30 jours après la fin du contrat. La preuve de l’acceptation et de la conclusion du contrat est conservée sous forme minimisée après la fin du contrat pendant la durée indiquée à la ligne « Preuve de la conclusion du contrat » du tableau, en règle générale six ans à compter de l’année de conclusion du contrat (§ 257 du code de commerce allemand, HGB). Si l’adresse du titulaire enregistrée dans la boutique diffère de celle de la personne agissante — par exemple parce qu’une employée ou une agence a installé l’app —, le titulaire de la boutique reçoit ces informations par e-mail conformément à l’art. 14 RGPD.

Connexion avec Google Ads et Meta

Lorsqu’un client connecte son compte publicitaire en se connectant avec Google ou Meta, la plateforme nous remet un identifiant d’accès : un jeton d’actualisation chez Google, un jeton d’accès de longue durée chez Meta. Nous le conservons chiffré (AES-256-GCM) et rattaché au compte du client. Il n’est jamais affiché ni journalisé.

Grâce à cet accès, nous lisons dans le compte publicitaire choisi :

• la liste des comptes accessibles avec nom, identifiant et devise, afin de choisir le bon ;
• les coûts, impressions et clics par campagne et par jour ;
• si l’analyse par annonce est activée pour le compte client, en outre les coûts, impressions et clics par annonce et par jour, avec le nom et l’identifiant de l’annonce et de son groupe d’annonces ainsi que, lorsque la plateforme en fournit une, l’adresse d’une image d’aperçu de l’annonce.

Nous conservons les adresses des images d’aperçu, les noms et identifiants des annonces et groupes d’annonces ainsi que leurs indicateurs comme les autres coûts, tant que le compte client existe. Nous ne conservons pas durablement les images d’aperçu elles-mêmes : nos serveurs les récupèrent auprès de la plateforme à l’ouverture de l’analyse et les gardent au plus une heure en mémoire vive ; votre navigateur ne se connecte ni à Meta ni à Google. Les images d’aperçu et les noms d’annonces peuvent montrer ou nommer des personnes identifiables, par exemple des personnes qui apparaissent dans la publicité. Nous n’affichons les coûts par annonce que dans cette analyse du portail ; l’assistant de données, les exports et les interfaces ne les fournissent pas.

Si le client active le renvoi des conversions, nous transmettons en outre des conversions à son compte : l’identifiant de clic de la plateforme, le type, la date, la valeur et la devise de la conversion, selon la plateforme un identifiant d’événement permettant à la plateforme de reconnaître les doublons (Meta, TikTok, LinkedIn), le numéro de commande (Google, Meta, TikTok) et l’adresse de la page sur laquelle le clic est arrivé (Meta, TikTok). Comme valeur, nous transmettons le chiffre d’affaires de la conversion ou, si le client le paramètre ainsi pour une destination, pour les commandes la marge sur coûts variables (valeur nette moins coût des marchandises). Si le client limite une destination aux premières commandes, elle ne transmet que celles-ci ; la plateforme apprend ainsi indirectement qu’une commande était une première commande. Nous ne transmettons ni adresses e-mail, ni numéros de téléphone, ni adresses IP, ni caractéristiques du navigateur, ni nos propres identifiants de personne ou de terminal. La transmission n’a lieu qu’avec un consentement marketing et, chez Google, en outre uniquement avec le consentement `ad_user_data` ou la catégorie de consentement que le client lui a attribuée. Nous ne modifions ni campagnes, ni annonces, ni enchères, ni budgets.

Ces données servent uniquement à présenter au client ses propres coûts à côté de ses propres conversions et à renvoyer ses conversions vers son propre compte. À la demande du client, l’assistant de données du portail peut lire ces mêmes chiffres de coûts. Il fonctionne sur Vertex AI dans la région europe-west3, et ses entrées ne servent pas à entraîner des modèles. Nous ne vendons pas ces données, ne les utilisons pas à des fins publicitaires et ne les croisons pas entre clients. Nous ne les communiquons à des tiers que si le client connecte lui-même un outil d’IA ou un programme à son compte et nous donne ainsi l’instruction d’y transmettre ses données (voir « Connexion d’outils d’IA d’autres fournisseurs »).

L’utilisation et le transfert des informations reçues via les API Google respectent la Google API Services User Data Policy, y compris les exigences d’utilisation limitée (« Limited Use »).

Si la connexion est supprimée dans Metrunio, nous effaçons immédiatement l’identifiant. L’accès peut aussi être révoqué à tout moment auprès de la plateforme, sur myaccount.google.com/permissions ou dans les paramètres de Meta, rubrique « Intégrations professionnelles ». Les coûts importés sont conservés tant que le compte Metrunio existe et sont supprimés avec lui. La suppression de données particulières peut être demandée à tout moment à privacy@metrunio.com.

Connexion avec Google Search Console

Si Search Console est activée pour un compte client et qu’une personne ayant le rôle Admin la connecte en se connectant avec Google, Google nous remet un jeton d’actualisation autorisant la lecture de Search Console (`https://www.googleapis.com/auth/webmasters.readonly`). Nous le conservons chiffré (AES-256-GCM) et rattaché au compte client. Il n’est jamais affiché ni journalisé. Pour la connexion, nous conservons en outre qui l’a établie et quand, quel accès Google elle utilise (client OAuth) et la propriété choisie pour chaque site. Pendant la connexion à Google, nous conservons une empreinte de son état et le vérificateur PKCE ; tous deux sont valables dix minutes et sont supprimés à l’issue de la connexion ou, à défaut, au plus tard onze minutes après son début.

Grâce à cet accès, nous lisons dans Search Console :

• la liste des propriétés auxquelles le compte Google connecté a accès, avec le type d’autorisation, afin de choisir la bonne pour chaque site ;
• pour les propriétés choisies, les clics, les impressions, le taux de clics et la position moyenne dans la recherche web Google, par jour, par page et par requête.

Nous ne modifions rien dans Search Console. Les données servent uniquement à montrer au client, dans le rapport « Recherche organique », ses propres chiffres de recherche à côté de ses propres visites et conversions mesurées. Nous les comparons par page ; nous ne rattachons aucune requête individuelle à une visite, à une personne ou à une conversion. Nous récupérons les chiffres à l’ouverture du rapport et les gardons au plus une heure en mémoire vive, uniquement pour le compte client, la connexion et la propriété pour lesquels ils ont été récupérés ; ils ne sont pas conservés durablement. Une fois la connexion supprimée, nous ne les fournissons plus et les écartons. Les chiffres ne figurent ni dans les exports, ni dans les interfaces, ni dans les rapports par e-mail, ni dans l’assistant de données. Nous ne vendons pas les données, ne les utilisons pas de manière indépendante à nos propres fins, ne les utilisons pas à des fins publicitaires, ne les combinons pas entre clients et ne les utilisons pas pour entraîner des modèles. Elles ne sont traitées que par les sous-traitants au moyen desquels nous fournissons la fonction (voir « Destinataires »).

L’utilisation et le transfert des informations reçues via les API Google respectent la Google API Services User Data Policy, y compris les exigences d’utilisation limitée (« Limited Use »).

Les requêtes et les pages peuvent désigner des personnes, par exemple par leur nom. Google n’affiche pas séparément les requêtes rares ; cela n’exclut pas toute déduction. Nous considérons donc ces chiffres comme des données personnelles que nous traitons pour le compte du client (art. 28 RGPD) ; le client détermine leur base juridique en tant que responsable du traitement.

Lors de la connexion et à chaque requête, Google reçoit de notre part l’identifiant d’accès, la propriété et les paramètres de la requête (période et ventilation par jour, page ou requête) ; nous ne transmettons aucune donnée de visiteurs ni de mesure. L’interface est fournie par Google LLC aux États-Unis. Ce transfert repose sur la décision d’adéquation de la Commission européenne pour les États-Unis (EU-US Data Privacy Framework), au titre de laquelle Google LLC est certifiée. Google est ici la source des données et le destinataire de ces requêtes, sans devenir pour autant notre sous-traitant ; séparément, Google Cloud, sur laquelle nous exploitons Metrunio, reste notre sous-traitant.

Nous sommes responsables des données de la connexion. La base juridique est l’art. 6.1.b RGPD, dans la mesure où vous êtes vous-même, en tant que personne physique, partie à notre contrat et où le traitement est nécessaire à cet effet. Si ce sont des salariés ou des mandataires d’un client, par exemple d’une agence, qui connectent, le traitement repose sur l’art. 6.1.f RGPD ; notre intérêt légitime réside dans une connexion autorisée et sécurisée au service du client. Vous pouvez vous y opposer en vertu de l’art. 21 RGPD. L’autorisation accordée chez Google ne constitue pas un consentement à ce traitement. Si la personne qui a connecté perd son rôle ou son appartenance au compte client, la connexion subsiste jusqu’à ce qu’un Admin la supprime ou la reconnecte ; les Admins du compte client voient un avis à ce sujet.

Si la connexion est supprimée dans Metrunio, nous effaçons immédiatement le jeton d’actualisation et les propriétés choisies ; sur demande, nous révoquons également l’accès chez Google. L’accès peut aussi être révoqué à tout moment chez Google, sur myaccount.google.com/permissions. Le journal du compte client consigne la connexion, le choix d’une propriété (avec cette propriété) et la déconnexion, chacun avec la date et la personne ayant agi ; nous supprimons ces entrées au bout de 180 jours, au plus tard avec le compte client.

Autres sources de données de nos clients

Nos clients peuvent connecter d’autres services dont nous récupérons, pour leur compte, des coûts et des indicateurs. Ils saisissent pour cela une clé, un jeton ou l’adresse d’un tableur : pour les coûts publicitaires de TikTok, LinkedIn et Microsoft Advertising, pour les coûts de releva.nz, pour les indicateurs de leurs newsletters chez Klaviyo ou Brevo et pour des coûts issus d’un tableur partagé (Google Sheets ou un fichier CSV). Pour Klaviyo, Brevo et releva.nz, cela ne s’applique que si ces sources sont activées pour le compte client. La connexion relève du rôle Admin et, pour un tableur, aussi du rôle Analyse.

Des sources publicitaires et de coûts, nous lisons les coûts, impressions et clics par campagne ou boutique et par jour. D’un tableur, nous ne reprenons dans l’analyse que les colonnes prévues : campagne, jour, coûts et, le cas échéant, devise, impressions, clics et plateforme ; lors de la récupération du fichier, d’autres colonnes peuvent être transmises temporairement. De Klaviyo et Brevo, nous lisons pour chaque campagne envoyée son identifiant, son nom, la date d’envoi, le paramètre de campagne `utm_campaign` et le nombre de destinataires, de remises et de clics uniques ; ni ouvertures, ni contenus des e-mails, ni données sur des destinataires individuels. Les totaux, les noms de campagnes et les adresses peuvent eux aussi se rapporter à des personnes, par exemple avec de très petits nombres ; nous les traitons donc comme les autres données que nous traitons pour le compte de notre client.

Nous utilisons les coûts comme ceux de Google Ads et de Meta : dans les rapports du compte client, dans les exports, via l’API de lecture, dans l’assistant de données et dans les rapports par e-mail. Nous n’affichons les indicateurs de Klaviyo et de Brevo que dans le portail, sur la page « Newsletter », à côté des visites et conversions que nous mesurons nous-mêmes ; ils ne figurent ni dans les exports, ni dans l’API de lecture, ni dans l’assistant de données, ni dans le miroir d’analyse.

Nous conservons les clés et jetons de ces sources chiffrés (AES-256-GCM) et rattachés au compte client et à leur finalité, de même que l’adresse d’un tableur, car sa seule connaissance donne accès au tableur. Ils ne sont pas journalisés et ne sont pas affichés en entier dans le portail : on voit au plus les quatre derniers caractères et, pour un tableur, l’hôte et les quatre derniers caractères de l’adresse.

Lorsqu’une connexion est supprimée, nous effaçons immédiatement sa clé et, pour Klaviyo et Brevo, également les indicateurs récupérés. Les coûts de releva.nz, d’un tableur et des autres sources publicitaires et de coûts sont conservés, comme tous les coûts importés, tant que le compte client existe et sont supprimés avec lui ; lorsqu’un tableur est retiré, sa récupération prend fin et nous supprimons son adresse. La connexion, le remplacement de la clé et la déconnexion d’une plateforme de newsletter, ainsi que l’ajout et le retrait d’un tableur, sont consignés avec la date et la personne ayant agi dans le journal du compte client, sans la clé et, pour un tableur, uniquement avec son hôte ; nous supprimons ces entrées au bout de 180 jours, au plus tard avec le compte client.

Nous sommes responsables des données de la connexion ; comme pour les autres données du compte, la base juridique est l’art. 6.1.b ou 6.1.f RGPD (voir sous le tableau). Nous traitons les coûts et indicateurs récupérés pour le compte de notre client (art. 28 RGPD) ; le client détermine leur base juridique en tant que responsable du traitement. Les fournisseurs de ces services sont des fournisseurs de notre client et ne deviennent pas nos sous-traitants du fait de la récupération. Cela vaut aussi pour Brevo, que nous utilisons par ailleurs pour notre propre newsletter (ligne « Newsletter » du premier tableau).

Connexion d’outils d’IA d’autres fournisseurs

Si vous connectez à votre compte, via la page d’autorisation du portail, un outil d’IA d’un autre fournisseur, par exemple Claude d’Anthropic ou ChatGPT d’OpenAI, ou si vous créez une clé de lecture, cet outil ou programme reçoit une autorisation de lecture permanente sur les données de mesure du compte. Dans les limites de l’autorisation accordée, l’outil connecté peut demander des données pour vos analyses ; il décide des requêtes qu’il effectue dans le cadre de ses propres processus. Seules les personnes ayant le rôle Admin dans le compte peuvent accorder l’autorisation ou créer des clés, et seulement après une notice expliquant ce que signifie l’autorisation.

Sont accessibles les indicateurs et ventilations, y compris les coûts publicitaires importés de Google Ads, de Meta et d’autres comptes publicitaires connectés, les conversions individuelles avec date, valeur et numéro de commande en clair, ainsi que les parcours clients pseudonymes avec identifiant, dates et canaux. Pour les abonnements, les paiements de renouvellement sont signalés ; seule l’API de lecture avec une clé de lecture fournit l’identifiant de l’abonnement en clair, un outil d’IA connecté via la page d’autorisation ne le reçoit pas. Les indicateurs sont agrégés ; des déductions sur des opérations individuelles peuvent néanmoins être possibles. La connexion ne fournit ni noms, ni adresses e-mail, ni adresses IP, ni identifiants de navigateur, ni identifiants de clic des plateformes publicitaires, ni les pages visitées. Les commandes que la boutique a transmises sans consentement au suivi ne sont pas fournies sous forme d’enregistrements individuels ; elles sont incluses dans les indicateurs autorisés, comme les nombres et les totaux de chiffre d’affaires, et avec de petits nombres, des déductions sur des commandes individuelles peuvent en être possibles.

Nous communiquons les données de mesure des visiteurs et acheteurs de nos clients en tant que sous-traitant, sur instruction de notre client ; la base juridique de cette communication est déterminée par notre client en tant que responsable du traitement. Le fournisseur de l’outil n’est pas notre sous-traitant ultérieur. Il traite les données qu’il obtient selon les conditions du compte que notre client détient chez lui, le cas échéant aussi hors de l’Union européenne. Notre client s’assure du contrat avec le fournisseur, d’un contrat de sous-traitance si nécessaire et des conditions d’un transfert vers des pays tiers ; nos propres obligations de sous-traitant demeurent. Nous sommes responsables des données relatives à l’autorisation elle-même ; elles figurent dans le tableau ci-dessus.

Les mesures de protection propres à notre assistant de données dans le portail ne s’appliquent pas à cette connexion : les numéros de commande et identifiants de parcours ne sont pas remplacés par des codes courts, la limite de lignes individuelles par question ne s’applique pas, et la conservation, l’entraînement et la suppression chez le fournisseur relèvent de ses conditions, et non de celles de Google Cloud pour Vertex AI.

Vous pouvez déconnecter une autorisation à tout moment dans le portail, sous « Exports et connexions IA » ; vous y révoquez aussi une clé de lecture. À partir de sa requête suivante, l’outil ne reçoit plus de données. La déconnexion ne supprime pas chez le fournisseur les données que l’outil a déjà obtenues ; cela dépend de votre contrat avec lui.

Les partenaires recommandent Metrunio et perçoivent une commission en contrepartie. Pour les partenaires personnes physiques et les personnes de contact d’une entreprise partenaire, nous traitons le nom, l’adresse, l’adresse e-mail de facturation, le numéro fiscal ou le numéro de TVA, le statut fiscal et la date de l’accord de partenariat, ainsi que, pour chaque client apporté, le montant net payé et le mois du paiement. La finalité est l’attribution des clients apportés au partenaire, le calcul de la commission, l’autofacturation (§ 14, al. 2 UStG) et la comptabilité.

La base juridique est l’art. 6.1.b RGPD (accord de partenariat) ; pour les personnes de contact d’une entreprise partenaire, l’art. 6.1.f RGPD (exécution de l’accord de partenariat avec l’entreprise ; vous pouvez vous y opposer au titre de l’art. 21 RGPD) ; pour la conservation, l’art. 6.1.c RGPD en lien avec le § 147 AO et le § 257 HGB. Nous conservons les autofactures comme pièces comptables pendant huit ans à compter de la fin de l’année civile ; les données de base jusqu’à la fin du partenariat et au-delà, tant qu’une autofacture qui les mentionne doit être conservée. Les destinataires sont notre conseiller fiscal et, pour l’exploitation, les sous-traitants mentionnés sous « Destinataires ».

Si un client s’inscrit avec le code de recommandation d’un partenaire, nous enregistrons sur le compte à quel partenaire il est rattaché et, pour la commission, les montants payés par mois. Le partenaire ne reçoit aucune ventilation par client : son autofacture n’indique, pour chaque taux de commission, que le total et le nombre de clients. Pour de petits groupes, par exemple lorsqu’un seul client relève d’un taux de commission, des déductions sur le montant de clients individuels peuvent être possibles. La base juridique est l’art. 6.1.f RGPD (décompte du programme partenaires) ; les montants par client sont conservés comme base de l’autofacture aussi longtemps que celle-ci. Nous ne versons aucune commission pour les clients qui avaient déjà un compte chez nous dans les douze mois précédant leur inscription avec un code de recommandation. Pour le vérifier, nous comparons le nom de l’entreprise et le domaine de messagerie de l’inscription avec les comptes existants. Pour les comptes supprimés, nous conservons à cet effet, pendant douze mois à compter de la suppression, uniquement une somme de contrôle calculée avec une clé secrète (HMAC) du nom de l’entreprise et de chaque domaine de messagerie des personnes ayant le rôle Admin, sans les domaines des fournisseurs de messagerie grand public et sans texte en clair. La base juridique est l’art. 6.1.f RGPD ; notre intérêt légitime consiste à protéger le programme partenaires contre les abus.

• Identifiants pseudonymes de session et de terminal, sous réserve d’un consentement. Avant la décision dans la bannière de consentement, le script ne conserve les événements que dans la mémoire de la page ; après un consentement, il les envoie avec ce consentement, après un refus ou à la sortie de la page, il les écarte.
• Données de campagne issues des créations et des paramètres de campagne de la page consultée, par exemple `utm_source`, `utm_medium`, `utm_campaign` et `utm_content`. Si l’analyse par annonce est activée pour le compte de notre client, nous rattachons une visite à l’annonce dont l’identifiant figure dans `utm_content` ; cet identifiant est le même pour tous les clics sur la même annonce. Les identifiants individuels de clic et d’impression, les nôtres comme ceux des plateformes publicitaires (par exemple gclid ou fbclid), uniquement avec un consentement marketing ; avec un consentement limité aux statistiques, seule subsiste l’indication de la plateforme d’où provient un clic.
• Données d’événements telles que pages vues, interactions et conversions avec valeur et devise.
• Nous traitons les adresses IP lors de la transmission et pour limiter les requêtes et ne les conservons pas dans les données d’événements, pas même sous forme de somme de contrôle. Depuis le 14 octobre 2026, nous ne formons plus la somme de contrôle tronquée qui y était auparavant conservée et avons supprimé les valeurs existantes. Les autres caractéristiques techniques sont conservées tronquées ou hachées.
• Aucune adresse e-mail ni numéro de téléphone en clair dans les événements analytiques. Les événements rejetés à la réception (format invalide, horodatage hors de la plage autorisée ou adresse e-mail/numéro de téléphone en clair) ne sont pas enregistrés. Pour le diagnostic, seuls sont consignés le motif du rejet, la date, la source, le site, le type d’événement et les noms des champs concernés avec le type et la longueur de la valeur, sans contenu des champs ni identifiants. Ces informations sont supprimées selon la durée de conservation des données brutes de notre client (180 jours par défaut).
• L’état du consentement est enregistré et évalué pour chaque événement. Sans le consentement adéquat, aucun événement publicitaire n’est enregistré, pas même brut ; seul est consigné, sans aucun identifiant, le fait qu’un événement n’a pas été enregistré pour cette raison.
• Un identifiant de vue pour le post-view : un cookie sur l’adresse de mesure de notre client (`metrunio_view`, 30 jours, pour cette adresse uniquement). Il n’est déposé qu’avec un consentement marketing, par le pixel d’impression et le tag de visibilité sur le site publicitaire ou par le script de mesure dans la boutique ; le navigateur le renvoie lors de la visite de la boutique. Si le navigateur le rejette, rien ne le remplace : ni empreinte numérique, ni calcul probabiliste. Si la personne retire son consentement marketing, l’adresse de mesure supprime le cookie lors de la transmission du retrait ; si elle retire entièrement son consentement, le script efface en outre l’identifiant pseudonyme et la session dans le navigateur. Les contacts publicitaires déjà enregistrés qui sont liés à ce navigateur sont supprimés ; un consentement ultérieur repart sans eux.
• Pour les commandes qu’une boutique transmet avec consentement, un identifiant client pseudonyme : le numéro client de la boutique ou une somme de contrôle (SHA-256) de l’adresse e-mail, telle que la transmettent notre app Shopify et nos plugins pour Shopware et WordPress. À la réception, nous combinons chacune de ces valeurs avec une clé différente pour chaque client et n’enregistrons que le résultat ; une même personne donne deux valeurs différentes chez deux clients. L’identifiant relie les achats d’une même personne entre plusieurs appareils et n’est transmis à aucune plateforme publicitaire.
• Une redirection pour les clics sur les créations : notre adresse de mesure redirige vers le site de notre client. En l’absence de signal de consentement du site publicitaire, elle n’ajoute à l’adresse de destination que l’identifiant de la campagne (`metrunio_camp`, identique pour tous les clics d’une même campagne) et n’enregistre aucun clic ; seul est consigné, sans aucun identifiant, le fait qu’un clic n’a pas été enregistré pour cette raison.
• Si notre client utilise son propre domaine de mesure sous son domaine, nous déposons en outre l’identifiant pseudonyme du visiteur sous forme de cookie sur ce domaine (`metrunio_aid`), uniquement avec consentement à l’analyse. Le cookie rend le même identifiant lisible sur tous les sous-domaines de ce domaine, par exemple dans la boutique et lors du paiement, et reconnaît un navigateur même après l’effacement du stockage du site. La finalité est de relier les visites et les commandes d’un même navigateur. Il dure 13 mois ; Safari le limite à sept jours. Le retrait du consentement le supprime.
• Si notre client a activé la question après achat, la page qui suit l’achat vous demande comment vous avez connu notre client, avec une liste fixe de réponses et sans texte libre. La question n’est posée qu’avec consentement à l’analyse. Nous enregistrons la réponse avec le numéro de commande et l’identifiant pseudonyme du navigateur et la relions à la commande et à l’historique des visites ; il ne s’agit donc pas d’une enquête anonyme. Elle n’est transmise à aucune plateforme publicitaire et est supprimée avec les autres événements.
• Si notre client a activé l’origine dans les formulaires, le script inscrit des données d’origine dans des champs masqués de ses formulaires : un identifiant de la demande, la source, le support, la campagne et la plateforme publicitaire et, avec consentement marketing, en outre l’identifiant de clic. Par défaut, cela n’a lieu qu’avec consentement à l’analyse ; sans lui, le script n’inscrit rien dans les formulaires et ne lit pas non plus l’adresse de la page à cette fin. Pour certains sites, notre client peut l’activer sans consentement ; seuls la source, le support et la campagne de l’adresse de la page consultée sont alors repris, et notre client doit justifier lui-même ce réglage. Les champs sont transmis avec votre demande, c’est-à-dire avec votre nom et votre adresse e-mail, au système de notre client, par exemple son CRM, et non à nous. Il peut y relier votre demande à son origine et, s’il importe ultérieurement la conclusion dans Metrunio, à l’historique pseudonyme des visites. Cela se fait sur son instruction et sous sa responsabilité ; son système ne devient pas pour autant notre sous-traitant.
• Pour les abonnements, l’identifiant de l’abonnement tel que la boutique ou le prestataire de paiement l’attribue, et l’indication qu’un paiement est un paiement de renouvellement ; les deux sont fournis par la source, nous ne les devinons pas. Nous conservons l’identifiant en clair comme le numéro de commande, mais uniquement pour les achats avec consentement. Un paiement de renouvellement avec consentement reprend l’attribution de la première commande du même abonnement sur le même site ; il n’est transmis à aucune plateforme publicitaire et ne compte pas comme nouveau client. Si la première commande disparaît par suppression, opposition, retrait du consentement ou expiration de sa durée de conservation, nous recalculons immédiatement ses paiements de renouvellement, qui restent alors sans attribution. Nous ne fournissons l’identifiant de l’abonnement que dans l’export CSV des conversions et via l’API de lecture. Le portail n’affiche que l’indication « paiement de renouvellement » ; l’assistant de données et un outil d’IA connecté via la page d’autorisation ne reçoivent eux aussi que cette indication, le miroir d’analyse dans BigQuery ne conserve que l’indication, et les webhooks ne contiennent ni l’une ni l’autre.

La base juridique des identifiants et des événements issus du navigateur est le consentement de la personne concernée au sens de l’art. 6.1.a RGPD et du § 25.1 TDDDG. Sur le site de notre client, sa plateforme de gestion du consentement le recueille. Pour les contacts publicitaires sur des sites tiers, le serveur publicitaire qui diffuse l’annonce transmet le signal de consentement ; nous ne recevons pas de preuve propre de celui-ci. Si notre client importe des conversions depuis un fichier, il indique pour chaque ligne l’origine, la date et une référence à la preuve du consentement ; nous vérifions que ces indications sont complètes et non contradictoires, et non le consentement lui-même. Sans consentement, seul a lieu ce que décrivent les paragraphes suivants ; la base juridique en est déterminée par notre client en tant que responsable. La durée de conservation est fixée par le client dans le cadre de sa formule ; la valeur par défaut est de 180 jours pour les données brutes.

Un retrait dans la bannière de consentement vaut pour le navigateur dans lequel il est déclaré. Si la personne retire uniquement son consentement marketing, nous supprimons les événements publicitaires de ce navigateur et les contacts publicitaires qui lui sont liés, et retirons les identifiants de clic et d’impression de ses autres événements ; ce qui repose sur son consentement aux statistiques est conservé. Si elle retire entièrement son consentement, nous supprimons tous les événements de ce navigateur, y compris les commandes que la boutique a transmises avec son identifiant. Les transmissions aux plateformes publicitaires non encore envoyées sont arrêtées. Celles déjà envoyées se trouvent chez la plateforme et nous ne pouvons pas les récupérer ; nous indiquons les destinataires à notre client afin qu’il puisse remplir son obligation de les informer au titre de l’art. 19 RGPD. Nous enregistrons l’état du consentement avec la date du retrait, rattaché à l’identifiant pseudonyme du navigateur, pour prouver que le retrait a été exécuté et pour rejeter les événements ultérieurs de ce navigateur ; il est conservé tant qu’il est nécessaire au traitement ou à l’exécution du retrait. Un état de consentement est supprimé lorsque le navigateur n’a, pendant 13 mois, ni modifié sa décision ni visité le site ; l’état après un retrait est conservé comme preuve jusqu’à la fin de la troisième année civile suivant le retrait. Les deux sont supprimés au plus tard lors de la suppression du site ou du compte de notre client. Un retrait dans la bannière n’est pas une demande au titre des art. 15 à 21 RGPD : toute personne souhaitant un accès, l’effacement de toutes les données la concernant sur tous ses appareils ou formuler une opposition doit s’adresser à notre client, qui la met en œuvre dans l’espace confidentialité du produit.

Depuis le 29 septembre 2026, la mesure de portée pour les visites sans consentement ne peut plus être activée. Pour les sites sur lesquels notre client l’avait activée auparavant : aucun identifiant de personne ou de terminal n’est enregistré en l’absence de consentement. Chaque vue génère un événement comportant la date, la page sans paramètres de requête, le titre de la page, l’origine du lien et les données de campagne, qui est agrégé en un comptage par jour, site, canal et source. Ni l’événement ni le comptage ne contiennent d’identifiant par lequel une demande d’accès ou d’effacement pourrait retrouver une personne. La base légale est déterminée par notre client en tant que responsable ; nous traitons sur ses instructions. Les sources totalisant moins de cinq vues apparaissent regroupées plutôt qu’individuellement, et les événements comme le comptage expirent selon le même délai que les autres données brutes.

Si la boutique de notre client transmet des commandes et des remboursements côté serveur sans consentement au suivi, nous les traitons pour son compte uniquement à des fins de rapprochement du chiffre d’affaires : rapprocher ses recettes, détecter les opérations en double et rattacher les remboursements. Cette finalité est distincte du suivi. Nous enregistrons à cet effet le numéro de commande comme clé de commande nécessaire, le type d’opération (commande, paiement de renouvellement d’un abonnement ou remboursement), le montant, la devise et le jour de la commande sans l’heure, mais aucun identifiant de navigateur, de client ni publicitaire : l’identifiant pseudonyme du visiteur, la session, l’identifiant client pseudonyme, l’identifiant de clic, la caractéristique IP, la page consultée, les données de campagne, l’identifiant d’un abonnement et les articles sont supprimés avant l’enregistrement. L’indication « paiement de renouvellement » fait apparaître séparément, dans le chiffre d’affaires rapproché, les paiements d’abonnements en cours ; nous n’en déduisons aucune caractéristique de nouveau client. Les données restent en principe des données personnelles, car notre client peut rattacher le numéro de commande à une personne. La commande n’est reliée à aucune visite ni à aucun contact publicitaire et n’est transmise à aucune plateforme publicitaire ; la seule exception figure au paragraphe suivant. Cela vaut pour les commandes pour lesquelles la boutique ne transmet aucune décision sur le consentement, faute de décision prise. Si la boutique transmet un refus, nous n’enregistrons la commande dans cette mesure que si notre client nous a donné une instruction distincte à cet effet ; sans cette instruction, nous ne l’enregistrons pas. Une telle commande n’est jamais rattachée à une visite. La base légale est déterminée par notre client en tant que responsable ; son intérêt légitime à disposer de chiffres d’affaires complets peut s’appliquer (art. 6.1.f RGPD). Il appartient à notre client d’informer de ce traitement, de sa base légale et de la manière de s’y opposer dans sa propre politique de confidentialité. Le refus du suivi ne constitue pas en soi une opposition au rapprochement du chiffre d’affaires. Veuillez adresser une opposition au sens de l’art. 21 RGPD à notre client ; s’il la met en œuvre dans l’espace confidentialité du produit, nous supprimons les données relatives à votre commande et bloquons le numéro de commande pour les transmissions ultérieures. Le retrait de votre consentement au suivi entraîne la suppression des commandes transmises avec ce consentement ; elles ne sont pas transférées dans le rapprochement du chiffre d’affaires.

Rattachement via le passage en caisse. Il ne concerne que les commandes pour lesquelles la boutique n’a transmis aucune décision, jamais les commandes après un refus, et seulement si notre client l’a activé séparément. Si vous avez consenti, lors du même passage en caisse, à la mesure de suivi dont la portée inclut le rattachement des commandes aux visites et aux contacts publicitaires, et que ce consentement existait déjà au moment de l’achat, nous rattachons la commande à votre visite sur cette base. Cela se fait en deux étapes. Dès réception de la commande, nous créons un enregistrement de rapprochement de courte durée, même si aucun événement correspondant d’un navigateur n’arrive ensuite : une somme de contrôle, formée avec une clé, de l’identifiant du passage en caisse et l’heure exacte de la commande. Cela concerne aussi les commandes qui ne sont finalement rattachées à aucune visite ; la base juridique en est déterminée par notre client en tant que responsable du traitement, son intérêt légitime pouvant constituer cette base (art. 6, paragraphe 1, point f) RGPD). La commande n’est rattachée qu’à la seconde étape et uniquement avec votre consentement. Nous n’utilisons la somme de contrôle et l’heure de la commande que jusqu’à 24 heures après la commande, et la somme de contrôle sur les événements du navigateur que jusqu’à 24 heures après leur réception ; nous les supprimons ensuite dans le fonctionnement courant. Les sauvegardes obéissent à leurs propres délais ; après une restauration, les données de rapprochement expirées ne sont plus utilisées et sont supprimées lors de la maintenance suivante. Si vous retirez votre consentement, nous supprimons le rattachement et la commande.

Sorties vers des destinataires que notre client détermine. Sur son instruction, nous transmettons des données à des destinations qu’il saisit lui-même : webhooks vers son propre système avec l’identifiant de la commande ou de la demande, la valeur et l’heure de commandes, demandes ou remboursements individuels ; résumés de rapports et d’alertes vers un canal Slack ou Teams ; exports et consultations via l’interface de lecture ou un outil connecté. Les destinataires ne deviennent pas pour autant nos sous-traitants. Si un effacement, une opposition ou un retrait du consentement concerne un message pas encore remis, nous ne l’envoyons plus. Nous ne pouvons pas récupérer des données déjà remises ; nous communiquons les destinataires à notre client afin qu’il puisse remplir son obligation au titre de l’art. 19 RGPD. Afin de pouvoir indiquer les destinataires ultérieurement, nous ne conservons pour chaque livraison que la destination, l’horodatage et une somme de contrôle de l’identifiant de commande ou de demande, sans contenu, aussi longtemps que les autres données brutes. Des sorties sans nom ni adresse e-mail peuvent elles aussi être des données personnelles, et il en va de même du miroir d’analyse dans BigQuery que nous tenons pour les comptes de tous nos clients dans la même région et à partir duquel les rapports de chaque compte sont calculés lorsque les volumes de données sont plus importants : les numéros de commande et les clés d’enregistrements et d’historiques de visites peuvent être reliés, et avec de petits nombres, même des totaux permettent des déductions sur des personnes individuelles.

Les clients de Metrunio, par exemple des agences, peuvent désigner pour un compte client des personnes qui reçoivent chaque mois un rapport sur ce compte en PDF par e-mail. Nous traitons les destinataires de rapports désignés par notre client exclusivement pour le compte de celui-ci. Le message indique qui est responsable de l’envoi et de quelle source provient votre adresse. Une désinscription bloque les rapports suivants de ce compte client. Seule la preuve de blocage nécessaire est conservée à cet effet, tant que cette finalité d’envoi existe.

Les informations complètes au titre de l’art. 14 RGPD sont fournies par le responsable du traitement ; le message y renvoie. Nous conservons votre adresse e-mail, votre nom s’il est indiqué, le compte client, qui vous a inscrit et quand, ainsi qu’une empreinte du jeton de désinscription. Pour le compte client, nous enregistrons qui est le responsable du traitement (l’agence ou son client), le lien vers ses informations sur la protection des données et qui a saisi ces deux éléments et quand ; les indications figurant dans le message en proviennent. La seule finalité est l’envoi du rapport mensuel et le respect de votre désinscription. Le rapport ne contient que des totaux du compte client, aucune commande individuelle ni aucun identifiant de visiteur ; avec de petits nombres, les totaux peuvent eux aussi permettre des déductions sur des personnes. Nous l’envoyons via Google Workspace, sans pixel de suivi et sans liens suivis.

Vous pouvez vous désinscrire par le lien figurant dans chaque message. Nous supprimons alors immédiatement votre inscription. Pour ce compte client, il ne reste qu’une preuve de blocage : une empreinte de votre adresse e-mail normalisée calculée avec une clé secrète (HMAC) avec la date de la désinscription, sans l’adresse elle-même, votre nom ni le jeton de désinscription. Elle empêche que votre adresse y soit inscrite à nouveau ; elle ne bloque pas d’autres comptes clients. Nous la supprimons dès que cette finalité d’envoi disparaît : avec le compte client ou le compte de l’agence, dès que l’agence ne gère plus le compte client, et 30 jours après la désactivation, pour l’agence, de l’envoi à des destinataires désignés. Seul votre propre souhait lève le blocage. Notre client peut à cet effet vous envoyer une invitation au plus une fois tous les 30 jours, valable sept jours ; vous ne recevez à nouveau des rapports qu’après avoir confirmé l’invitation par le lien figurant dans cet e-mail. Tant qu’une invitation est ouverte, la preuve de blocage contient votre adresse, votre nom s’il est indiqué, et une empreinte du jeton d’invitation ; ensuite, nous effaçons ces données. Notre client ne peut pas lever le blocage lui-même. Si notre client vous retire comme destinataire avant votre désinscription, nous supprimons votre inscription. Adressez l’exercice de vos droits au titre des art. 15 à 21 RGPD au responsable du traitement ; nous l’assistons à cet égard.

Le traitement principal a lieu dans l’Union européenne : l’application, la base de données, le miroir d’analyse, les journaux de l’application et le modèle de langue de la fonction de questions du portail fonctionnent en région europe-west3 (Francfort). La partie contractante est dans chaque cas une société établie dans l’UE.

Cela seul ne serait pas une réponse complète. Il existe des exceptions. Les journaux d’administration et de système de la plateforme cloud sont conservés dans des espaces de journalisation mondiaux du fournisseur, qui ne peuvent pas être déplacés dans une région, jusqu’à 400 jours. Pour l’administration et l’assistance, des sociétés du groupe et des prestataires de nos fournisseurs peuvent accéder aux systèmes depuis l’extérieur de l’UE ; la base est la décision d’adéquation de la Commission européenne pour les États-Unis (EU-US Data Privacy Framework) dans la mesure où le destinataire est certifié à ce titre et, en complément et pour les sociétés non certifiées, les clauses contractuelles types de l’UE ; la liste indique la base pour chaque destinataire. Vous pouvez obtenir des informations et une copie des garanties applicables via privacy@metrunio.com. Les outils et canaux que notre client connecte lui-même sont exploités par leur fournisseur, le cas échéant hors de l’UE. Quel destinataire traite où, avec qui le contrat est conclu et quels accès sont possibles figure pour chaque entrée dans la liste des sous-traitants ultérieurs et dans l’aperçu « Prestataires et destinataires ».

Nous faisons appel à des prestataires qui exploitent des serveurs, acheminent des e-mails et traitent les paiements pour nous. Le rôle dans lequel ils traitent les données n’est pas le même partout, et il détermine quel contrat s’applique et à quelles instructions ils sont tenus.

• Sous-traitants au sens de l’art. 28 RGPD : exploitation de l’application, boîte aux lettres et envoi d’e-mails. Ils traitent uniquement sur instruction.
• Le prestataire de paiement, dans un double rôle : pour les données contractuelles que nous lui transmettons, il est sous-traitant. Pour le paiement lui-même, il est responsable de traitement, car le droit des services de paiement et la lutte contre le blanchiment lui imposent des obligations propres — et qui a ses propres obligations ne suit pas d’instructions à cet égard.
• Les plateformes publicitaires ne sont pas des sous-traitants. Elles ne reçoivent quelque chose que si notre client active le renvoi des conversions, et traitent alors les données en tant que responsables propres ou conjoints, à leurs propres fins.

Nous ne transmettons rien aux plateformes publicitaires, sauf si notre client active expressément le renvoi des conversions. Même alors, pour l’attribution publicitaire, nous envoyons l’identifiant de clic de la plateforme et, pour chaque destination, les identifiants de commande ou d’événement décrits plus haut aux fins de la déclaration et du dédoublonnage ; nous n’envoyons pas nos propres identifiants de personne ou de terminal. Ce qui est transmis en outre est décrit plus haut, sous « Connexion avec Google Ads et Meta ».

Documents pour l’examen

• Accès aux données traitées vous concernant (art. 15 RGPD).
• Rectification des données inexactes (art. 16 RGPD).
• Effacement (art. 17 RGPD).
• Limitation du traitement (art. 18 RGPD).
• Portabilité des données (art. 20 RGPD).
• Opposition à un traitement fondé sur des intérêts légitimes (art. 21 RGPD).
• Retrait d’un consentement donné, avec effet pour l’avenir (art. 7.3 RGPD). Le retrait ne remet pas en cause la licéité du traitement effectué avant celui-ci.
• Réclamation auprès d’une autorité de contrôle (art. 77 RGPD).

Si votre demande porte sur des données de mesure issues du site de l’un de nos clients, adressez-vous à ce client : c’est lui le responsable. Nous l’y aidons : le produit dispose d’un espace dédié à l’accès, à l’effacement et à l’opposition, et un effacement continue de produire effet via une liste de blocage, afin que le même identifiant ne soit pas de nouveau collecté la minute suivante.

• Pas de fingerprinting à partir des caractéristiques du terminal.
• Pas d’attribution probabiliste fondée sur des probabilités.
• Aucune liaison au-delà des frontières entre clients.
• Aucune vente ni transmission à nos propres fins publicitaires.
• Aucune conservation durable d’adresses IP brutes : pour limiter les requêtes, elles restent au plus dix minutes en mémoire vive.

Les modifications de cette déclaration figurent dans le journal des changements, sous Statut.

Chaque version reste consultable sous sa date, de façon permanente et sans modification ; l’e-mail de confirmation envoyé lors de la conclusion du contrat dans le portail ou via l’app Shopify renvoie à ces adresses, et le portail conserve le texte convenu lui-même.

• Version du 17 octobre 2026 · en vigueur
• Version du 16 octobre 2026
• Version du 15 octobre 2026
• Version du 14 octobre 2026
• Version du 13 octobre 2026
• Version du 12 octobre 2026
• Version du 11 octobre 2026
• Version du 10 octobre 2026
• Version du 7 octobre 2026
• Version du 4 octobre 2026
• Version du 3 octobre 2026
• Version du 2 octobre 2026
• Version du 1 octobre 2026
• Version du 30 septembre 2026
• Version du 26 septembre 2026
• Version du 25 septembre 2026
• Version du 24 septembre 2026