EEI remplace-t-il la télémétrie ?

Non. La télémétrie et EEI remplissent des fonctions différentes dans la même stack. La télémétrie fournit à l'opérateur des signaux de risque probabilistes — patterns comportementaux, réputation des appareils, vélocité cross-session — qu'EEI ne produit pas. EEI fournit à l'opérateur un enregistrement cryptographique de ce que le runtime de l'appareil a observé au moment de l'exécution — vérifiable indépendamment par les émetteurs, les schémas et les régulateurs sans passer par un vendor. La plupart des déploiements Tier-1 ont besoin des deux.

Que fait la télémétrie qu'EEI ne fait pas ?

La télémétrie agrège des signaux dans le temps et entre appareils. Biométrie comportementale, réputation des appareils construite à partir d'observations cross-marchands, timing d'interaction, vélocité de session — ces signaux probabilistes et agrégés sont la spécialité des vendors de télémétrie. EEI n'a ni agrégation de signaux cross-clients, ni couche de biométrie comportementale, ni modèle de profil de vie. Pour ces capacités, un SDK de télémétrie est l'outil adapté.

Que fait EEI que la télémétrie ne fait pas ?

EEI produit un enregistrement d'exécution signé et lié à l'appareil que toute partie disposant de la clé publique de l'opérateur peut vérifier indépendamment — sans médiation vendor. En cas de litige, l'émetteur vérifie le token directement contre la clé publique de l'opérateur. Lors d'un audit de schéma, le reviewer rejoue la chaîne de hachage. Dans tous ces cas, l'opérateur présente le token sans appeler une API vendor. Les scores de risque de télémétrie ne se transportent pas ainsi.

Peut-on utiliser les deux ?

Oui — et la composition naturelle consiste à router les deux vers le moteur de risque de l'opérateur. La télémétrie fournit le signal de risque probabiliste ; EEI fournit l'enregistrement d'exécution déterministe. Le moteur de risque lit les deux ; l'evidence store conserve les tokens EEI pour les besoins de litige et d'audit en aval. Les deux ne sont pas en conflit — ils couvrent des aspects différents de la question de confiance.

Pourquoi le chemin de vérification est-il important pour les litiges et la conformité ?

Un token EEI est vérifiable par toute partie disposant de la clé publique de l'opérateur — émetteur, plateforme de litige, reviewer de schéma, régulateur — sans que l'opérateur n'appelle une API vendor pour re-dériver le verdict. C'est important quand le vendor est indisponible, quand le vérificateur n'a pas de relation avec le vendor, ou quand la chaîne de custody doit être indépendamment auditable. Les scores de télémétrie sont optimisés pour les décisions de risque en temps réel ; ils ne sont pas conçus pour la vérification indépendante post-hoc.

Nous instrumentons déjà notre app mobile avec OpenTelemetry et envoyons des traces à notre SIEM. Qu'apporte EEI ?

Les spans OTel enregistrent ce que votre SDK a rapporté au collector — ils ne sont pas signés à la source par l'appareil. Votre trace backend prouve qu'une requête est arrivée et a été traitée ; elle ne prouve pas à quoi ressemblait l'environnement d'exécution de l'appareil au moment où l'utilisateur a agi, si le payload a été assemblé par l'app légitime, ou si l'interaction avec le credential était non-médiée. Les tokens signés d'EEI comblent cet écart : chaque événement est signé sur l'appareil avec une clé liée au platform key store, porte une déclaration de trust_basis issue du moniteur de cohérence runtime, et est hash-linké à l'événement précédent. Quand vous corrèlez des traces OTel avec des tokens EEI dans votre SIEM, vous obtenez la couche d'evidence côté appareil qu'OTel n'a jamais été conçu à fournir.

comparaison · EEI vs télémétrie

Signal, rencontre preuve.
La télémétrie infère. EEI signe.

Analytics comportementaux, fingerprinting d'appareils, scoring de risque — la télémétrie assemble son verdict de risque dans le backend vendor ; l'inférence n'est pas signée à la source par l'appareil. EEI signe un enregistrement d'exécution sur l'appareil au moment de chaque événement de sécurité, avec une clé liée au platform key store de l'appareil. Les deux parviennent au moteur de risque de l'opérateur ; seul EEI peut être présenté par l'opérateur — aux plateformes de litige, auditeurs et contreparties — sans médiation vendor.

réponse courte

La télémétrie est la couche de risque probabiliste — patterns comportementaux, réputation des appareils, signaux cross-session assemblés dans le backend vendor. EEI est la couche d'evidence signée — chaque événement de sécurité configuré signé à la source sur l'appareil, hash-chaîné sur toute la séquence d'exécution, vérifiable par toute partie disposant de la clé publique de l'opérateur, sans passer par YinkoShield.

où chacun forme son verdict

EEI signe à la source. La télémétrie assemble côté backend vendor.

EEI signe l'evidence à la source sur l'appareil — pas de vendor dans le chemin de vérification. La télémétrie assemble son verdict dans le backend vendor avant de transmettre un score de risque à l'opérateur.

comparaison

Ce que chacun produit. Ce que chacun ne produit pas.

Dimension	Télémétrie	EEI
Ce qu'elle produit	Un score de risque ou un signal de réputation assemblé dans le backend vendor à partir de signaux collectés sur l'appareil. Le verdict est une inférence probabiliste.	Un Evidence Token signé (JWS-compact ES256) produit par l'appareil au moment de chaque événement de sécurité configuré. Le token porte une signature qui ne peut être produite sans la clé privée liée à l'appareil.
Où l'assertion est formée	Le backend vendor : les signaux sont assemblés et interprétés dans l'infrastructure du vendor en une inférence de risque. Le verdict de risque n'est pas signé par l'appareil à la source.	L'appareil, au moment de chaque événement. La clé de signature est liée au platform key store de l'appareil ; le token signé est le seul artefact qui transite vers l'opérateur.
Qui est dans le chemin de vérification	Le score de risque est formé et vérifié dans le backend vendor ; l'opérateur ne peut pas vérifier l'inférence indépendamment sans la coopération du vendor.	Aucun endpoint YinkoShield n'est consulté lors de la vérification. L'opérateur vérifie contre ses propres clés publiques stockées dans sa propre stack.
Portée temporelle	Patterns comportementaux accumulés dans le temps : vélocité de session, réputation cross-session des appareils, timing d'interaction. Adapté aux signaux de profil de vie.	Événement-continu du début de session jusqu'à la soumission. Chaque événement configuré — utilisation de credential, biométrie, assemblage du payload, soumission — produit un token signé hash-linké à son prédécesseur.
Custody des données et confidentialité	Les signaux comportementaux — pouvant inclure timing d'interaction, patterns de frappe et identifiants d'appareils — sont assemblés et conservés dans le backend vendor, regroupés avec ceux d'autres clients de l'opérateur.	Classes de signaux uniquement — pas de PII via le substrat.
Signaux cross-flotte	Un vrai point fort : réputation cross-marchands et cross-sessions des appareils construite à partir d'observations sur la base de déploiement du vendor. EEI ne fournit pas cela.	N'agrège pas de signaux cross-clients. La valeur d'EEI est la chaîne cryptographique par opérateur et par appareil — pas la réputation au niveau réseau.
Portabilité de l'output	Un score de risque dans le format du vendor, vérifiable uniquement via le système du vendor. Les émetteurs et reviewers de schéma reçoivent l'interprétation par l'opérateur du verdict du vendor.	Tokens JWS-compact, vérifiables par toute partie disposant de la clé publique de l'opérateur — émetteur, schéma, plateforme de litige, régulateur — sans passer par YinkoShield.
Chaîne de custody	Pas de chaîne cryptographique originaire de l'appareil entre la collecte des signaux et le score de risque. Le score est l'inférence du vendor ; sa dérivation est interne au vendor.	Séquence hash-chainée à preuve de falsification dès le premier événement instrumenté. Chaque token référence le hash de son prédécesseur ; dans la séquence observée, tout token supprimé crée un écart détectable dans la chaîne de hachage ou les numéros de séquence.
Usage en litige et audit	Le score de risque soutient la décision de fraude au moment de la transaction. Le re-présenter à un émetteur, un schéma ou une contrepartie après coup est un processus médiatisé par le vendor.	Les tokens signés sont vérifiables indépendamment à tout moment ultérieur — résolution de litige, audit de schéma, revue par contrepartie — sans l'implication de YinkoShield, sous réserve que l'opérateur maintienne son registre de clés publiques.
Pattern d'adoption	Mature ; les analytics comportementaux et les SDKs de télémétrie sont largement déployés chez les opérateurs de paiement Tier-1 dans le monde.	Catégorie émergente ; conçue pour coexister avec la télémétrie et produire la couche d'evidence déterministe que la télémétrie ne fournit pas.

comment ils se composent

La télémétrie donne le signal de risque. EEI donne l'enregistrement d'evidence signé.

Un déploiement Tier-1 typique utilise les deux. La télémétrie alimente le moteur de risque en temps réel — patterns comportementaux, réputation des appareils, vélocité de session — informant la décision autoriser / challenger / refuser au moment de la transaction. EEI signe chaque événement indépendamment, produisant un enregistrement d'exécution hash-chaîné qui voyage séparément du score de risque.

Ce qui change quand vous ajoutez EEI à une stack qui fait déjà tourner de la télémétrie :

Les litiges se résolvent contre des preuves d'exécution signées, pas contre un score de risque vendor re-présenté. L'émetteur ou la plateforme de litige vérifie le token directement contre la clé publique de l'opérateur.
Les audits de schéma et réglementaires obtiennent une chaîne cryptographique, pas une reconstruction médiatisée par le vendor. La séquence d'exécution hash-chainée est rejouable depuis le ledger de l'appareil de manière indépendante.
Le moteur de policy de l'opérateur lit les deux. Découplage de policy défini sur /fr/eei-vs-rasp.

Les deux ne sont pas en compétition. La télémétrie répond : « quelle est la probabilité que cet appareil et cette session soient légitimes ? » EEI répond : « quels événements l'appareil a-t-il signés, avec quel trust basis, et dans quelle séquence ? » Les deux questions importent pour une posture complète en matière de fraude, litiges et conformité.

Et les outils d'observabilité — OpenTelemetry, APM, SIEM ?

Notons d'abord que Datadog et New Relic ne sont pas uniquement des outils APM backend — les deux proposent des produits de monitoring mobile et de lecture de session (Datadog Mobile Monitoring, New Relic Mobile). Ces produits instrumentent la couche de vue de l'app et ont le même angle mort que tout SDK de lecture de session : les overlays de couche OS, les services d'accessibilité et les hooks runtime se trouvent en dessous de la frontière d'observation du SDK. La dimension lecture de session est couverte séparément dans EEI vs Lecture de session.

Pour l'observabilité backend spécifiquement — OpenTelemetry, traces distribuées, SIEM — la question est différente : qu'est-ce que le backend a traité, avec quelle latence, avec quelles erreurs ? Les traces distribuées sont le bon outil pour ça. Elles ne sont pas conçues pour prouver ce qui s'est passé sur l'appareil avant que la requête ne parte.

Trois choses qu'une trace OTel ne peut pas vous dire :

Si l'environnement d'exécution était cohérent. Un span OTel enregistre que l'app a appelé l'endpoint de paiement. Il n'enregistre pas si un service d'accessibilité interceptait les entrées, si l'interface vue par l'utilisateur correspondait à ce que l'app affichait, ou si le processus avait été instrumenté par un tiers. Le moniteur de cohérence runtime d'EEI observe cela et le déclare dans le trust_basis de chaque événement signé.
Si le payload a été assemblé par l'app légitime. La trace backend montre la requête arrivée. EEI signe le payload au moment de l'assemblage sur l'appareil. Si les deux diffèrent, l'écart est une preuve — pas juste une anomalie dans un log.
La chaîne de custody pour l'action utilisateur. Une trace distribuée prouve que le service A a reçu une requête et appelé le service B. Elle ne prouve pas qu'un utilisateur a pris une décision délibérée sur un appareil non-compromis. La séquence hash-chainée d'EEI — ancrée à l'attestation de l'appareil — fournit cette couche.

OTel et APM ne sont pas remplacés ici ; ils restent les bons outils pour l'observabilité backend. La composition : les traces OTel prouvent ce que le backend a traité ; les tokens EEI prouvent ce que l'appareil a signé. Le SIEM qui corrèle les deux dispose de preuves plus solides que celui qui ne corrèle que des logs backend.

questions fréquentes

Six questions, six réponses.

·01 EEI remplace-t-il la télémétrie ?: Non. La télémétrie et EEI remplissent des fonctions différentes dans la même stack. La télémétrie fournit à l'opérateur des signaux de risque probabilistes — patterns comportementaux, réputation des appareils, vélocité cross-session — qu'EEI ne produit pas. EEI fournit à l'opérateur un enregistrement cryptographique de ce que le runtime de l'appareil a observé au moment de l'exécution — vérifiable indépendamment par les émetteurs, les schémas et les régulateurs sans passer par un vendor. La plupart des déploiements Tier-1 ont besoin des deux.
·02 Que fait la télémétrie qu'EEI ne fait pas ?: La télémétrie agrège des signaux dans le temps et entre appareils. Biométrie comportementale, réputation des appareils construite à partir d'observations cross-marchands, timing d'interaction, vélocité de session — ces signaux probabilistes et agrégés sont la spécialité des vendors de télémétrie. EEI n'a ni agrégation de signaux cross-clients, ni couche de biométrie comportementale, ni modèle de profil de vie. Pour ces capacités, un SDK de télémétrie est l'outil adapté.
·03 Que fait EEI que la télémétrie ne fait pas ?: EEI produit un enregistrement d'exécution signé et lié à l'appareil que toute partie disposant de la clé publique de l'opérateur peut vérifier indépendamment — sans médiation vendor. En cas de litige, l'émetteur vérifie le token directement contre la clé publique de l'opérateur. Lors d'un audit de schéma, le reviewer rejoue la chaîne de hachage. Dans tous ces cas, l'opérateur présente le token sans appeler une API vendor. Les scores de risque de télémétrie ne se transportent pas ainsi.
·04 Peut-on utiliser les deux ?: Oui — et la composition naturelle consiste à router les deux vers le moteur de risque de l'opérateur. La télémétrie fournit le signal de risque probabiliste ; EEI fournit l'enregistrement d'exécution déterministe. Le moteur de risque lit les deux ; l'evidence store conserve les tokens EEI pour les besoins de litige et d'audit en aval. Les deux ne sont pas en conflit — ils couvrent des aspects différents de la question de confiance.
·05 Pourquoi le chemin de vérification est-il important pour les litiges et la conformité ?: Un token EEI est vérifiable par toute partie disposant de la clé publique de l'opérateur — émetteur, plateforme de litige, reviewer de schéma, régulateur — sans que l'opérateur n'appelle une API vendor pour re-dériver le verdict. C'est important quand le vendor est indisponible, quand le vérificateur n'a pas de relation avec le vendor, ou quand la chaîne de custody doit être indépendamment auditable. Les scores de télémétrie sont optimisés pour les décisions de risque en temps réel ; ils ne sont pas conçus pour la vérification indépendante post-hoc.
·06 Nous instrumentons déjà notre app mobile avec OpenTelemetry et envoyons des traces à notre SIEM. Qu'apporte EEI ?: Les spans OTel enregistrent ce que votre SDK a rapporté au collector — ils ne sont pas signés à la source par l'appareil. Votre trace backend prouve qu'une requête est arrivée et a été traitée ; elle ne prouve pas à quoi ressemblait l'environnement d'exécution de l'appareil au moment où l'utilisateur a agi, si le payload a été assemblé par l'app légitime, ou si l'interaction avec le credential était non-médiée. Les tokens signés d'EEI comblent cet écart : chaque événement est signé sur l'appareil avec une clé liée au platform key store, porte une déclaration de trust_basis issue du moniteur de cohérence runtime, et est hash-linké à l'événement précédent. Quand vous corrèlez des traces OTel avec des tokens EEI dans votre SIEM, vous obtenez la couche d'evidence côté appareil qu'OTel n'a jamais été conçu à fournir.

pour aller plus loin

Deux questions que cette page soulève sans répondre complètement :

Quels champs contient chaque Evidence Token signé ?: Type d'événement, source de timestamp, key ID, trust basis, numéro de séquence monotone, hash précédent, liaison nonce/contexte, version d'app, version de policy, résultat du vérificateur — les définitions normatives de champs et les contraintes de valeur se trouvent dans la spécification YEI-001. L'article format de l'Evidence Token couvre l'ensemble de claims requis public.
Comment la clé de signature est-elle provisionnée — et que se passe-t-il lors d'une réinstallation ou migration d'appareil ?: La génération de clé, les garanties de hardware-backing, la destruction lors d'un reset d'usine, et la chaîne d'attestation bootstrap sont couverts dans Custody locale des clés — frontières appareil, opérateur et vendor.

Les opérateurs qui font déjà tourner de la télémétrie tirent le plus d'un mapping en 60 minutes.

Nous mappons votre stack de télémétrie existante aux classes de signaux EEI et montrons ce qui change pour les litiges, la conformité et l'audit de schéma quand l'evidence signée entre en jeu. Vous gardez la télémétrie ; vous ajoutez l'enregistrement d'evidence.

Mapper votre stack de télémétrie aux signaux EEI

Signal, rencontre preuve. La télémétrie infère. EEI signe.