SDK télématiques : 3 critères testés en conditions réelles pour identifier les plus performants

Introduction

La réussite d'un programme d'assurance connectée dépend de nombreux facteurs. Parmi les plus critiques, outre l’application mobile et la souscription, l’expérience client est en tête de liste. Il est indispensable pour les assureurs de soigner l’expérience client afin de favoriser l’adhésion des conducteurs. La pierre angulaire qui régit l’expérience client d’un programme connecté, et sur laquelle doit se porter la vigilance des assureurs, est le SDK télématique intégré à l’application.

Fort heureusement, l’ensemble des SDK télématiques disponibles aujourd’hui sur le marché est de bonne facture. Et pour cause : la télématique smartphone est une technologie éprouvée depuis plus de dix ans, et utilisée en 2025 par plus de 50 millions d’assurés. Les assureurs qui se sont emparés pleinement de cette technologie (Progressive, AllState, Direct Assurance ou encore Tokio Marine) revendiquent des ratio combinés inférieurs au marché et une satisfaction client supérieure à celle des offres non connectées.

Si tous les SDK télématiques sont de bonne facture, tous ne se valent pas. Il y a des différences significatives de performance entre un SDK de bonne facture et un SDK de pointe. Si l’on se fie au retour d’expérience des assureurs ayant lancé des programmes Pay-As-You-Drive (PAYD) et Pay-How-You-Drive (PHYD), trois métriques clés permettent de différencier les SDK télématiques : la détection de trajets, la consommation batterie et l'utilisation des données mobiles. 

• La détection de trajets est la capacité du SDK à détecter automatiquement tous les trajets motorisés grâce aux données du smartphone. C’est la fonctionnalité la plus importante car les programmes connectés utilisent les données des trajets pour personnaliser la prime en fonction de la distance et/ou du comportement de conduite. Si la détection de trajet n’est pas fiable, cela peut engendrer un décalage entre le niveau de risque réel et le montant de la prime. Au-delà même de ce risque, c’est le bon fonctionnement des services connectés, y compris de la détection d'accident, qui est compromis, et dont les conséquences pourraient s’avérer dramatiques.

• La consommation batterie correspond à l'utilisation de la batterie par un SDK. Une consommation élevée de la batterie impacte négativement l'expérience utilisateur, génère des demandes de support, et résulte sur une note négative de l’app puis sa désinstallation.

• L'utilisation de données mobiles désigne la quantité de données cellulaires consommées par un SDK. Une consommation élevée de données draine le forfait d’un utilisateur. Les conséquences sont similaires à celles d'une consommation excessive de batterie : satisfaction des utilisateurs en berne, note négative sur les magasins d’applications et désinstallation de l’app.

Chacun de ces facteurs contribue à façonner l'expérience client, qui constitue un levier de valeur fondamental des programmes d’assurance connectée. Si un SDK télématique n'est pas performant sur les trois items, l’adoption à grande échelle d'un programmes connecté est compromise.

C’est pourquoi ce guide partage une méthodologie de test, accompagnée de résultats obtenus en conditions réelles, afin d’aider les assureurs auto à identifier les SDK les plus performants sur ces trois indicateurs. L’objectif est de fournir aux assureurs une approche reproductible et fiable pour identifier les solutions télématiques qui préservent l’expérience client et la satisfaction des assurés.

Détection de trajets

Détection des trajets motorisés

Comme mentionné précédemment, la détection de trajets indique la capacité d'un SDK à identifier automatiquement les trajets motorisés grâce aux données du smartphone. Cette fonctionnalité est critique pour tous les programmes PAYD et PHYD, car l’analyse du risque routier, la personnalisation des primes et la détection d’accident reposent tous sur les données de trajet.

Pour chaque trajet, les participants ont relevé les points de départ et d'arrivée ainsi que la distance et la durée. Ces informations ont ensuite été comparées aux données enregistrées par les SDK afin de mesurer avec précision le taux de détection de trajets.

Le graphique ci-dessous indique le taux de détection de trajets pour chaque SDK :

La plupart des SDK ont un taux de détection de trajets supérieur à 97 %. La performance en retrait du SDK D est probablement due à l'application dans laquelle il a été intégré. Cette dernière privilégie le suivi des membres du cercle familial au suivi des trajets motorisés. Si le SDK D avait été implémenté dans une application télématique en marque-blanche, il est probable que son taux de détection de trajets aurait été à minima de 97 %.

Détection de la distance et de la durée

Tous les SDK télématiques collectent également des données sur la distance et la durée afin de fournir une vision complète du trajet. Ces indicateurs sont essentiels pour les programmes d'assurance connectée car les modèles actuariels ont démontré qu’un kilométrage et un temps de conduite élevés sont corrélés à un risque routier accru. Cependant, bien que la télématique smartphone soit très efficace pour détecter les trajets motorisés, déterminer avec précision la distance et la durée exacte des trajets est plus complexe. 

Comme expliqué dans l’article “Comment fonctionne la détection automatique de trajets ?”, la télématique smartphone combine plusieurs mécanismes efficaces à 99 % pour détecter un trajet. Cependant, un court laps de temps est nécessaire à l’OS du téléphone pour activer l'application en arrière-plan et ainsi confirmer que le mouvement détecté est un trajet motorisé. Durant ces quelques secondes, aucune donnée de conduite n'est enregistrée par les SDK. Pour cette raison, les 300 à 500 premiers mètres de chaque trajet ne contiennent aucune donnée de distance, de durée et de comportement de conduite.

Certains fournisseurs télématiques contournent cette contrainte technique en complétant automatiquement le trajet. Ils partent du principe que la distance entre la dernière position connue du véhicule et le premier point mesuré du nouveau trajet a bien été parcourue par le véhicule. Cette stratégie d’auto-complétion améliore l'interface utilisateur puisque le trajet s’affiche en entier dans l’application, avec un point de départ supposé correct.

Cette option bien qu'intéressante, ne fait pas l'unanimité parmi les fournisseurs télématiques. Certains comme DriveQuant n’appliquent pas par défaut cette stratégie pour deux raisons :

• Les trajets avec et sans auto completion fournissent le même volume de données de conduite aux assureurs. En effet, la complétion automatique du trajet n'apporte aucune information sur le comportement conducteur. Son seul intérêt est d’améliorer visuellement l’affichage du trajet en supposant un point de départ. Les fournisseurs télématiques qui n'appliquent pas l'auto-complétion privilégient l’affichage des parties du trajet où les données de conduite sont effectivement collectées.

• L’auto complétion peut générer de la confusion et des erreurs. Les tests effectués révèlent qu'environ 15 % des trajets auto-complétés affichent un point de départ incorrect. Ces erreurs surviennent généralement lorsque les testeurs conduisent un deuxième véhicule ou utilisent un autre moyen de transport. Dans ces cas, l'auto complétion fusionne par erreur deux trajets correspondant à deux véhicules différents en considérant le point d'arrivée du trajet du deuxième véhicule comme point de départ du trajet suivant avec le premier véhicule.

Même si l’auto-complétion offre une restitution qui semble visuellement plus fidèle des trajets, son usage pour l’assurance connectée est limité :

• Dans le cadre d’un programme Pay-How-You-Drive, l’auto complétion n'apporte pas de valeur ajoutée en l'absence de données de conduite associées à la distance et à la durée calculées.

• Dans le cadre d’un programme Pay-As-You-Drive, comme expliqué dans l’article « Pourquoi utiliser des beacons pour votre assurance auto connectée ? », l’auto complétion est peu pertinente car les applications télématiques doivent être combinées à une balise. 

Les assureurs peuvent facilement identifier les applications qui utilisent l’auto complétion en consultant un trajet. Si la couleur des premiers mètres diffère de celle du reste du tracé, alors la distance a été calculée via auto complétion. Comme expliqué précédemment, il n’y a aucune différence en termes de qualité et quantité des données de conduite collectées avec les autres SDK.

Consommation batterie

La consommation de la batterie indique l'impact d'un SDK sur l'autonomie du téléphone. Optimiser la consommation batterie est essentiel pour ne pas freiner l'adoption et minimiser les frictions et les plaintes des utilisateurs.

La mesure de la consommation de la batterie varie en fonction de l’OS du téléphone.

• Sur les appareils iOS, il faut se rendre dans «Paramètres», «Batterie» et «Utilisation quotidienne».

• Sur les appareils Android, il faut se rendre dans «Paramètres» puis «Batterie». Certaines surcouches constructeurs n'affichent pas l'utilisation quotidienne. Il faut alors configurer une alarme toutes les 24h pour relever manuellement la consommation batterie. 

Le graphique ci-dessous indique la consommation quotidienne moyenne de batterie de chaque SDK :
  
Tous les SDK, à l'exception du SDK C, consomment en moyenne moins de 3 % de batterie par jour. Les SDK B et C ont une consommation de batterie supérieure de 1 % sur iOS comparé à leur SDK Android. En revanche, les SDK A, D et DriveKit affichent une consommation de batterie équivalente sur les deux OS.

Utilisation des données mobiles

L’utilisation de données mobiles désigne la quantité de données cellulaires consommées par un SDK. Une consommation minimale préserve le forfait data des conducteurs, un impératif dans les pays où les forfaits de données mobiles sont limités et/ou coûteux. Par ailleurs, une faible utilisation des données témoigne également de l’importance accordée à la confidentialité, puisque cela indique que le SDK transfère le minimum de données nécessaires à son fonctionnement.

Comme pour la consommation de la batterie, la méthode pour mesurer l’utilisation data varie en fonction de l’OS du téléphone.

• Les utilisateurs iOS doivent réinitialiser leurs statistiques de données mobiles en accédant à « Paramètres », « Cellulaire », puis « Réinitialiser les statistiques » avant le début des tests.

• Les utilisateurs Android doivent relever manuellement leurs statistiques initiales de données cellulaires pour chaque application télématique avant le début des tests.

Le graphique ci-dessous présente l'utilisation mensuelle moyenne des données pour chaque SDK :

Le SDK A et DriveKit consomment moins de 400 Mo de données par mois, ce qui équivaut au streaming d'une vidéo HD de moins de 30 minutes. Les SDK B et C consomment une quantité plus importante de données cellulaires, supérieure à 1 Go par mois. Mais ces SDK monitorent tous les types de mobilité, y compris les déplacements à pied. Ils ont donc par nature une consommation de données supérieure.

Conclusion

Les résultats des tests révèlent que malgré des capacités de détection de trajets similaires, des écarts significatifs de consommation batterie et de consommation data séparent les SDK de bonne facture des SDK les plus performants. Ces écarts ne sont pas neutres sur l’expérience client : 

• Sans une détection de trajet optimale, le décalage entre le niveau de risque réel et la personnalisation de la prime est inéluctable, en plus de compromettre le bon fonctionnement des services connectés comme la détection d’accident.

• Sans une consommation minimale de la batterie, l'application d’assurance est vouée à être désinstallée en quelques jours en raison de la friction générée et de l'insatisfaction client qui en découle.

• Sans une faible utilisation des données mobiles, les assurés abandonneront le programme connecté car ils n'accepteront pas de revoir à la hausse leur forfait téléphonique. 

D’après les mesures relevées en conditions réelles, DriveKit est le SDK qui offre l'expérience client la plus équilibrée grâce à une détection de trajet optimale et un impact négligeable sur la batterie du téléphone. Certes, le SDK A consomme légèrement moins de données mobiles, mais DriveKit se classe second avec une consommation également très faible.

Les assureurs à la recherche d’un fournisseur télématique peuvent s’appuyer sur la méthode de test partagée dans ce guide pour évaluer les performances des SDK télématiques sur trois métriques clés de l’expérience client. Il est probable que les résultats obtenus diffèrent légèrement car les SDK télématiques s’améliorent continuellement. Mais en répliquant ces tests, les assureurs ont la garantie d’identifier les partenaires télématiques qui offrent les SDK les plus performants et user-friendly.