Données collectées
Liste complète et transparente de toutes les données collectées par Korvus, avant et après consentement cookies. Classification CNIL champ par champ.
Philosophie
Korvus collecte le minimum nécessaire pour détecter les fuites financières de votre site. Chaque donnée collectée sert directement à identifier un problème et à calculer son impact en euros.
Korvus n'est pas un outil d'analytics comportemental. Il n'y a pas de session replay, pas de heatmap, pas de profil utilisateur, pas de fingerprinting.
Le snippet lit des signaux structurés dans le DOM de votre site : texte des boutons d'action, nom et prix des produits, messages d'erreur visibles, codes promo, libellés des moyens de paiement, statuts de rupture de stock. Il ne lit jamais le contenu libre des pages, ni les données saisies par vos visiteurs, ni les informations personnelles affichées dans les espaces clients.
Le snippet observe, le serveur calcule
Notre principe architectural est non négociable : aucun calcul métier, aucune classification, aucune logique de détection ne tourne dans le navigateur de votre visiteur. Le snippet Korvus se limite à des observers passifs (API standards du navigateur, lecture seule du DOM). Il envoie des signaux bruts au serveur Korvus, qui décide. Résultat : l'impact sur la vitesse et la réactivité de votre site (TBT, INP) reste indétectable, y compris en conditions réelles.
Concrètement, le snippet :
- S'exécute uniquement après le chargement complet de la page (
window load+setTimeout(0)) - N'écrit jamais dans le DOM, ne force jamais de reflow
- Se coupe automatiquement après 30 minutes d'inactivité, reprend à la première interaction
Ce que Korvus ne collecte pas
- Contenu de formulaires — aucune lecture d'email, mot de passe, adresse postale, numéro de carte bancaire, numéro de commande ou information personnelle saisie par l'utilisateur
- Champs de paiement — aucun accès aux iframes de paiement (Stripe Elements, Adyen, PayPlug, PayPal), aucune lecture de CVV, numéro de carte, ni code 3D Secure
- Pages
loginetaccount— le snippet détecte la présence de ces pages pour contextualiser les erreurs, mais ne lit jamais leur contenu (ni nom, ni email, ni historique de commandes, ni moyens de paiement enregistrés) - Corps des requêtes et réponses HTTP — Korvus observe les requêtes réseau qui échouent pour en extraire des méta-données techniques (URL sans paramètres, méthode, code de statut, durée, type de contenu de la réponse), mais ne lit jamais le corps d'une requête, ni le corps d'une réponse, ni les headers d'authentification
- Cookies — Korvus ne lit aucun cookie de votre site (sauf
korvus_optoutqu'il pose lui-même en cas d'opposition) - localStorage / sessionStorage — aucun accès au stockage local de votre site, sauf lecture technique de clés structurelles de panier (
cart,shopify_cart,woocommerce_cart_hash) pour confirmer un ajout au panier - Session replay — aucune capture du contenu des pages, des mouvements de souris, des frappes clavier, des clics individuels, ni de heatmap
- Rage clicks, dead clicks, mouvements de souris — hors scope Korvus
- Empreinte navigateur (fingerprinting) — pas de canvas, pas d'audio fingerprinting, pas de collecte de fonts installées, pas de
navigator.hardwareConcurrency, pas dememory - Résolution d'écran brute — seule la largeur de viewport bucketée est collectée (voir plus bas)
- Adresse IP — jamais stockée (voir la section dédiée)
- Suivi cross-session, cross-onglet, cross-domaine — chaque onglet est indépendant, pas de corrélation entre les visites
- Distinction nouveau / récurrent visiteur — incompatible avec notre modèle sessionStorage, non collectée
Transparence CNIL — deux classes de données
Korvus est une solution de mesure d'audience et de détection de problèmes techniques. À ce titre, une partie de nos données est exemptée de consentement au titre de l'article 82 de la loi Informatique et Libertés, selon les critères définis par l'outil d'auto-évaluation CNIL de juillet 2025 et les guidelines EDPB 2/2023 sur l'article 5(3) ePrivacy.
Les finalités exemptées couvrent :
- La mesure des performances techniques (Core Web Vitals, temps de chargement)
- La détection de problèmes de navigation (erreurs JavaScript, requêtes HTTP en échec)
- L'optimisation de l'ergonomie du site
Toute donnée à visée marketing (mesure de conversion, performance des campagnes publicitaires, canaux d'acquisition, valeurs monétaires individuelles) nécessite le consentement du visiteur.
Un différenciant concret
Dans la catégorie « réactions du site » (erreurs JS, requêtes HTTP en échec, ressources cassées, messages d'erreur, violations CSP, données structurées invalides), 6 signaux sur 9 sont captés sans aucun cookie ni consentement. Dans la catégorie « actions utilisateur », la moitié des signaux est également captée en mode exempt (tentatives d'ajout au panier, confirmations d'ajout, structure des recherches, codes promo visibles).
Concrètement, sur les visiteurs qui refusent les cookies, Korvus continue de détecter les fuites les plus critiques — erreurs de checkout, boutons cassés, ruptures de stock, pages 404 dans le tunnel — alors que la plupart des outils perdent 30 à 40 % de leurs signaux.
Identification des visiteurs
Korvus ne pose aucun cookie en fonctionnement normal.
L'identifiant de session est un identifiant anonyme généré localement par le navigateur du visiteur et stocké dans le sessionStorage. Concrètement :
- L'identifiant est créé à l'ouverture de l'onglet
- Il est détruit à la fermeture de l'onglet
- Il n'est pas partagé entre les onglets
- Il n'est pas persisté entre les visites
- Il est impossible de relier deux sessions d'un même visiteur
Korvus ne fait aucun fingerprinting et ne croise jamais les données entre sessions.
Adresse IP
L'adresse IP du visiteur est utilisée une seule fois côté serveur pour déterminer le code pays (ex : FR, BE, CH) et la langue préférée (via le header Accept-Language). Elle est immédiatement supprimée après cette opération :
- L'IP n'est jamais stockée en base de données
- L'IP n'est jamais tronquée (ce qui serait encore une donnée personnelle)
- L'IP n'est jamais transmise à un service tiers
Données collectées sans consentement
Ces données sont exemptées de consentement au titre de la mesure d'audience et de la détection de problèmes techniques. Elles sont collectées sur 100 % de votre trafic.
Session
Données collectées une fois par visite (un onglet = une session) :
| Donnée | Exemple | Utilité |
|---|---|---|
| Chemin de la landing page | /produit/air-max-90 | Identifier la page d'entrée, jamais l'URL complète, jamais les paramètres d'URL |
| Domaine du referrer | google.com | Identifier la source de trafic (host uniquement, jamais l'URL complète) |
| Canal d'entrée | organic_search / social / email / referral / direct | Classification dérivée serveur à partir du referrer (aucune donnée supplémentaire captée) |
| Pays | FR | Segmenter les problèmes par zone géographique |
| Langue préférée | fr-FR | Détecter les bugs spécifiques à une locale (ex : checkout cassé pour fr-BE). Lu depuis le header Accept-Language côté serveur |
| Type d'appareil | mobile | Détecter les problèmes spécifiques à un type d'appareil |
| Largeur du viewport (bucketée) | 769 (pour 769-1024 px) | Identifier les bugs liés à un breakpoint responsive. 6 buckets uniquement, pas de valeur exacte |
| Mode sombre | true / false | Détecter les drops de conversion liés à un affichage en dark mode (CTA invisibles, prix illisibles) |
| Système d'exploitation | iOS 17 | Identifier les incompatibilités (version majeure uniquement) |
| Navigateur | Chrome 124 | Identifier les incompatibilités (version majeure uniquement) |
| Type de connexion | 4g | Contextualiser les problèmes de performance |
| Ad blocker détecté | true / false | Distinguer un pixel marketing réellement cassé d'un pixel bloqué par l'utilisateur. Sans ce champ, nous générerions ~30 % de faux positifs sur desktop |
| Pixels chargés (liste) | ["meta", "ga4"] | Liste des pixels connus qui ont chargé avec succès sur la page |
| Pixels bloqués (liste) | ["tiktok"] | Liste des pixels connus dont la ressource a échoué au niveau réseau (adblocker, CSP, CDN indisponible). Mesure technique de chargement, aucun tracking utilisateur |
| Bot détecté | true / false | Filtrer les bots dans les détections |
Pages vues
Données collectées à chaque changement de page :
| Donnée | Exemple | Utilité |
|---|---|---|
| Chemin de la page | /produit/air-max-90 | Localiser le problème. Les paramètres d'URL sont séparés (voir section consent) |
| Type de page | pdp (fiche produit) | Segmenter par étape du parcours |
| Statut HTTP | 200, 404, 500 | Détecter les pages d'erreur qui reçoivent du trafic (fuite massive sur une campagne paid qui pointe vers une PDP supprimée) |
| Page d'erreur | true / false | Indicateur dérivé du statut HTTP et de signatures DOM (titre « 404 », « erreur », « not found ») |
| Type de navigation | navigate / reload / back_forward / prerender | Détecter les utilisateurs qui rechargent une page de paiement cassée (signal très fort de bug) |
| Temps de visibilité réelle | 12400 ms | Temps où la page était réellement au premier plan (onglet actif), pas le temps où elle était ouverte en arrière-plan |
| Scroll maximal atteint | 85 % | Détecter les pages dont le contenu principal (bouton d'achat, formulaire) n'est plus atteignable après un déploiement |
| Interaction utilisateur | true / false + time_to_first_interaction_ms | Distinguer une page « vue mais morte » (JS cassé, aucun clic possible) d'une page utilisée normalement |
| Type d'identifiant produit (PDP) | dataLayer / jsonld / dom / slug | Source de l'identifiant produit détecté (SKU catalogue) |
| Identifiant produit (PDP) | REF-12345 | SKU ou identifiant externe du produit affiché. Donnée catalogue, zéro donnée personnelle |
| Nom du produit (PDP) | Air Max 90 — Taille 42 | Nom humain affiché dans les alertes et le dashboard. Utilisé pour les messages du type « Rupture sur Air Max 90 avec 42 sessions/h » |
| Disponibilité produit (PDP) | true / false / null | Statut de stock observé via JSON-LD, bouton d'ajout au panier, ou texte visible |
| Time to First Byte | 320 ms | Détecter les ralentissements serveur |
| First Contentful Paint | 1200 ms | Mesurer la vitesse d'affichage initiale |
| Largest Contentful Paint | 2500 ms | Mesurer la vitesse de chargement perçue |
| Élément LCP | { tag: "img", selector: "section.hero > img.banner", url, size_kb: 850 } | Identifier précisément l'élément qui ralentit le chargement (un seul élément par page, celui qui a causé la mesure LCP) |
| Interaction to Next Paint | 180 ms | Mesurer la réactivité aux interactions |
| Élément INP | { selector: "button.add-to-cart", event_type: "click", processing_ms, delay_ms } | Identifier l'interaction lente (un seul élément par page, celui qui a causé la mesure INP) |
| Cumulative Layout Shift | 0.12 | Détecter les décalages visuels |
| Plus gros décalage CLS | { selector: "div.ad-banner", shift_value: 0.18, had_recent_input: false } | Identifier l'élément responsable du plus gros décalage visuel (un seul élément par page) |
| Long tasks | Nombre + total_blocking_time_ms | Mesurer le temps où un script bloque le navigateur (complémentaire au temps réseau) |
| Bfcache restauré | true / false | Détecter quand un script tiers casse le cache navigateur (dégradation massive des navigations arrière) |
| Ressources lentes | Top 15 des ressources chargées en plus de 100 ms, sous forme d'un tableau { url, type, duration_ms, transfer_kb, blocking } | Identifier les scripts, images, feuilles de style ou fonts qui ralentissent la page |
| Empreinte des scripts chargés | Hash SHA des URLs | Détecter les déploiements front et corréler avec l'apparition d'erreurs |
| Compteurs d'erreurs sur la page | js_error_count: 2, request_error_count: 1, resource_error_count: 0, ux_error_count: 0 | Résumé agrégé calculé côté serveur à partir des événements d'erreur détaillés |
Les types de pages détectés sont : home, plp (liste de produits), pdp (fiche produit), cart, checkout (générique), checkout_info, checkout_shipping, checkout_payment, order_confirmation, login, account, search, other.
Garde-fou strict sur les pages login et account
Korvus détecte la présence de ces pages pour pouvoir contextualiser les erreurs qui sont fréquentes lors d'un parcours d'achat. La détection s'appuie exclusivement sur trois signaux techniques :
- Les patrons d'URL (
/login,/my-account,/mon-compte...) - Le titre de la page (
<title>) - Des mots-clés dans 15 langues européennes
Le snippet ne lit jamais le contenu du corps de ces pages : aucun nom, email, adresse, historique de commande, moyen de paiement enregistré, ni aucune autre information personnelle.
Événements — Réactions du site
Korvus capte 6 types de signaux techniques émis par votre site, sans nécessité de consentement :
| Événement | Ce qui est capté | Utilité |
|---|---|---|
js_error | Nom de l'exception (TypeError, ReferenceError...), message, fichier source, numéros de ligne et colonne, stack trace tronqué à 500 caractères, indicateur script propre vs tiers, délai depuis la dernière interaction | Détecter les bugs qui bloquent le parcours. Les stack traces ne contiennent jamais de données utilisateur |
request_error | Hôte et chemin de l'URL (jamais les paramètres d'URL, strippés côté navigateur), méthode HTTP, code de statut, durée, type de contenu de la réponse, indicateur origine tierce, type (fetch / xhr) | Détecter les API cassées. Les query params sont toujours strippés avant envoi pour éviter toute fuite de token ou d'email |
resource_error | Type de balise (img, script, iframe...), hôte et chemin, indicateur tiers, indicateur iframe, durée avant échec | Détecter les ressources manquantes, les iframes de paiement cassées (Stripe, Adyen, PayPal), les widgets critiques indisponibles |
ux_error | Texte du message d'erreur visible (tronqué à 200 caractères), sélecteur CSS de l'élément, indicateur présence dans un formulaire, indicateur visibilité réelle | Détecter les messages d'erreur affichés au visiteur (« Une erreur est survenue », « Paiement refusé », « Stock indisponible ») |
csp_violation | Directive violée, hôte et chemin de la ressource bloquée, directive effective, mode (enforce / report) | Distinguer une ressource bloquée par votre Content Security Policy d'une ressource cassée. Permet un diagnostic précis du type « votre CSP bloque le pixel Meta, ajoutez connect.facebook.net à script-src » |
structured_data_check | Présence de Schema.org Product, présence de Schema.org Offer, champs manquants, erreurs, identifiant et nom produit (si présents dans le JSON-LD), disponibilité | Vérifier la conformité SEO des fiches produit et détecter les incohérences entre le schéma envoyé à Google Merchant et le prix réellement affiché |
Toutes ces données sont des mesures techniques pures. Aucune ne concerne le comportement individuel du visiteur.
Événements — Actions utilisateur (mode exempt)
La moitié des actions utilisateur monétisables est captée sans consentement, sous forme de faits techniques bruts, sans aucune valeur monétaire. Les valeurs (montants, remises) sont captées séparément avec consentement.
| Événement | Ce qui est capté | Utilité |
|---|---|---|
add_to_cart_attempt | Clic détecté sur un bouton d'ajout au panier, identifiant produit, indicateur de succès | Détecter les boutons cassés qui ne réagissent plus |
add_to_cart_succeeded | Confirmation de l'ajout au panier, détectée par observation passive du DOM (compteur panier incrémenté, notification de succès, ouverture d'un tiroir panier, changement d'URL, mutation d'une clé structurelle de panier en localStorage), latence entre le clic et la confirmation | Mesurer le taux de succès réel des ajouts au panier sur 100 % du trafic. Signal clé pour détecter les bugs silencieux d'API panier |
promo_applied (source DOM) | Code promo visible dans la page | Détecter la surutilisation d'un code promo (partagé sur un forum, une extension de cashback). Le montant de la remise est capté séparément avec consentement |
payment_method_selected | Signaux bruts décrivant le moyen de paiement choisi : libellé affiché, valeur technique de l'input, chemin de l'icône si présente, type de cascade de détection | Mesurer le mix de paiement réel et détecter un moyen de paiement qui disparaît du DOM suite à un bug d'intégration PSP. La normalisation en catégorie (card, paypal, apple_pay, alma...) est faite côté serveur. Aucune lecture des champs carte bancaire ni des iframes PSP opaques |
payment_attempted | Clic détecté sur un bouton « Payer » / « Valider la commande » / équivalents dans 15 langues européennes, texte du bouton cliqué (tronqué à 100 caractères), type de cascade de détection | Fait technique pur « bouton de paiement cliqué », sans aucune valeur monétaire. Clé pour détecter les clics qui plantent silencieusement (le cas le plus coûteux en checkout) |
promo_code_rejected | Code saisi, signal de rejet (message d'erreur, classe CSS, absence d'application) | Détecter un code promo cassé côté back-office, ou une tentative de brute-force de codes |
shipping_method_selected | Signaux bruts décrivant le mode de livraison choisi (libellé, valeur de l'input, type de cascade) | Détecter un transporteur cassé ou une option manquante qui force les utilisateurs à abandonner |
3ds_initiated / 3ds_completed | Contexte 3D Secure : apparition d'une iframe de défi, disparition, navigation vers une confirmation de commande. Aucune lecture du contenu de l'iframe, aucune lecture de code OTP, aucune lecture de carte | Mesurer le taux de succès des défis 3D Secure par émetteur et détecter une banque dont le flot est cassé |
variant_selected | Dimension choisie sur une fiche produit (taille, couleur, format), valeur sélectionnée | Détecter une variante systématiquement indisponible après sélection (bug de synchronisation stock / UI) |
search_performed (structure) | Nombre de résultats, indicateur de recherche vide (has_zero_results) | Détecter les recherches sans résultat massives. Le texte de la requête est capté séparément avec consentement (saisie libre susceptible de contenir des données personnelles) |
Limite assumée
Certains systèmes de paiement modernes rendent leurs champs dans une iframe cross-origin totalement opaque (Stripe Payment Element, Adyen Drop-in, Mollie Components). Dans ces cas, Korvus capte uniquement le signal « l'utilisateur a touché au bloc paiement », sans aucun détail sur la méthode exacte. Ce choix est volontaire : aucune technique d'inspection de ces iframes ne serait compatible avec le RGPD ni avec notre principe d'observation pure.
Données collectées avec consentement
Ces données nécessitent le consentement du visiteur (cookies acceptés). Si le consentement n'est pas accordé, elles ne sont tout simplement pas collectées. Aucun fallback, aucune estimation.
Session (compléments)
| Donnée | Exemple | Utilité |
|---|---|---|
| UTM source | facebook | Identifier le canal publicitaire |
| UTM medium | cpc | Identifier le type de campagne |
| UTM campaign | soldes-ete-2026 | Identifier la campagne spécifique |
| Trafic paid détecté | true / false | Segmenter les problèmes par type de trafic |
Identifiant de clic Meta (fbclid) | Présent : oui / non | Détecter le trafic Meta Ads (la valeur n'est pas stockée) |
Identifiant de clic Google (gclid) | Présent : oui / non | Détecter le trafic Google Ads (la valeur n'est pas stockée) |
Identifiant de clic TikTok (ttclid) | Présent : oui / non | Détecter le trafic TikTok Ads (la valeur n'est pas stockée) |
| Paramètres d'URL de la landing | { "utm_source": "google", "color": "red" } | L'ensemble des paramètres d'URL d'entrée. Non collecté sans consentement |
| Version complète de l'OS | iOS 17.4.1 | Analyse fine des bugs par version |
| Version complète du navigateur | Chrome 124.0.6367.91 | Analyse fine des bugs par version |
Pages vues (compléments)
| Donnée | Exemple | Utilité |
|---|---|---|
| Paramètres d'URL de la page | { "variant": "42", "utm_campaign": "soldes" } | Analyse fine des pages avec paramètres. Non collecté sans consentement |
| Prix produit observé (PDP) | 49.90 EUR | Détecter les incohérences de prix entre pages et les erreurs catastrophiques (produit affiché à 0,99 € au lieu de 99 €). Donnée financière, consentement requis |
Événements marketing et dataLayer
| Événement | Ce qui est capté | Utilité |
|---|---|---|
tag_fired | Tag normalisé (meta_pixel, google_ads, google_analytics, tiktok_pixel, pinterest_tag, linkedin_insight, bing_ads, criteo, other), type d'événement (PageView, Purchase, AddToCart...), statut (fired / failed / blocked), identifiant du pixel sanitisé (jamais de token de session) | Vérifier que chaque pixel marketing tire correctement et avec la bonne granularité |
datalayer_validation | Nom de l'événement, validité, champs manquants, champs null, nombre d'articles, présence d'une valeur | Vérifier l'intégrité des pushes dataLayer e-commerce avant qu'ils n'alimentent vos outils analytics |
datalayer_unknown | Nom d'un événement dataLayer inconnu avec structure e-commerce (maximum 5 par session) | Outil d'onboarding pour détecter automatiquement les dataLayers custom |
purchase | Identifiant de transaction, montant, devise, nombre d'articles, code promo, montant de la remise | Calculer l'impact financier réel des fuites détectées |
add_to_cart | Identifiant produit, nom, montant, devise | Mesurer la valeur réelle du taux de conversion |
promo_applied (source dataLayer) | Code promo, montant de la remise, type de remise | Mesurer l'impact financier des promotions |
search_performed (texte) | Texte de la requête saisie par l'utilisateur | Identifier les requêtes sans résultat pour lesquelles votre catalogue manque de produits. Texte saisi susceptible de contenir des informations personnelles, consentement requis |
Pourquoi ce découpage exempt / consent ?
Chaque action utilisateur monétisable est captée en deux étages :
- Le fait brut en exempt — sur 100 % du trafic, alimente la détection structurelle des fuites (taux d'échec, abandon, panne)
- La valeur monétaire en consent — sur environ 70 % du trafic consenti, alimente le chiffrage en euros
Résultat : les fuites les plus critiques sont détectées sur la totalité de votre audience, et l'impact financier est extrapolé honnêtement à partir d'un échantillon statistiquement représentatif. Vous ne perdez jamais un signal de fuite parce qu'un visiteur a refusé les cookies.
Référentiel de votre site
En complément des données de trafic, Korvus maintient un référentiel technique de votre site côté serveur, alimenté automatiquement :
- Liste des pixels attendus (
expected_pixels) — construit au départ par un crawl d'onboarding automatisé (analyse technique de votre page d'accueil et de quelques fiches produit), puis mis à jour en continu. Sert à distinguer un pixel marketing qui n'a jamais été installé sur votre site d'un pixel réellement cassé. Cette liste est déduite des données de trafic déjà collectées, elle ne déclenche aucune collecte supplémentaire. - Catalogue produit passif — construit à partir des PDP visitées (identifiant, nom, disponibilité, historique de changements de prix et de stock). Aucune synchronisation avec votre backend n'est nécessaire, aucun accès à votre base de données.
Durée de conservation
Toutes les données sont conservées 13 mois maximum, conformément aux recommandations CNIL. La suppression est automatique (partitionnement mensuel, suppression des partitions au-delà de 13 mois).
Droit d'opposition
Même pour les données exemptées de consentement, vos visiteurs peuvent refuser la collecte Korvus. En tant qu'éditeur du site, vous devez ajouter un lien dans votre politique de confidentialité qui pose le cookie korvus_optout=1.
Quand ce cookie est présent, le snippet Korvus ne s'initialise pas du tout : aucune donnée n'est collectée, aucune requête réseau n'est envoyée, aucun observer n'est attaché.
Hébergement des données
Toutes les données sont hébergées en France (Scaleway, région Paris) et ne font l'objet d'aucun transfert hors Union européenne. Korvus agit en tant que sous-traitant au sens de l'article 28 du RGPD. Les données de chaque client sont strictement isolées et ne sont jamais mutualisées ni réutilisées pour notre compte.
Dernière révision : 11 avril 2026. Cette page reflète la version V2 du snippet Korvus. Classification CNIL établie sur la base de l'outil d'auto-évaluation CNIL (juillet 2025) et des guidelines EDPB 2/2023 sur l'application de l'article 5(3) ePrivacy.