Brevet FR3141241A1 — publié le 20240426

La présente invention concerne un procédé et un dispositif (10) pour le suivi d’au moins un airbag (4) d’un véhicule (2). Le procédé, mis en œuvre par un dispositif (10), comprend : obtention de données d’historique (DT1) représentatives d’au moins un déclenchement d’airbag ; si des données de contexte (DT2), représentatives d’un contexte dans lequel s’est produit ledit au moins un déclenchement d’airbag, sont récupérées en association avec les données d’historique (DT1), détermination de si ledit au moins un déclenchement d’airbag est normal ou anormal par analyse de conformité desdites données de contexte (DT2) par rapport à au moins un critère d’intégrité (CT1) ; et génération, à partir d’un résultat de ladite détermination, d’un indicateur d’intégrité (IN1) indiquant un degré d’intégrité des données d’historique (DT1). Figure pour l’abrégé : Figure 1 Procédé et dispositif pour la surveillance d’au moins un airbag d’un véhicule La présente invention concerne les procédés et dispositifs pour le suivi du ou des airbags d’un véhicule, et notamment mais pas exclusivement d’un véhicule automobile. L’invention vise en particulier la surveillance d’un airbag de véhicule pour déterminer s’il a été déclenché de façon normale ou anormale, notamment pour détecter des défauts ou fraudes liés aux déclenchements anormaux d’airbags. Arrière-plan technologique La sécurité routière fait partie des enjeux importants de nos sociétés. Avec l’augmentation du nombre d’usagers, que ce soient les véhicules, les piétons ou encore les cyclistes, sur les réseaux routiers du monde entier, les risques d’accidents et d’incidents provoqués par ces mêmes usagers n’ont jamais été aussi importants. Pour améliorer la sécurité routière, de nombreux véhicules automobiles sont aujourd’hui équipés d’airbags. Il s’agit de coussins gonflables de sécurité (appelés aussi coussins gonflables ou enveloppes flexibles) dans lesquels un gaz est brusquement injecté par une réaction chimique explosive de façon à gonfler très rapidement l’enveloppe et ainsi servir de coussin pour amortir un choc. Ces dispositifs de sécurité peuvent ainsi être déclenchés lors d’un accident ou choc anormal d’un véhicule afin d’assurer la protection du ou des occupants du véhicule. Les airbags jouent un rôle essentiel dans la sécurisation des véhicules automobiles ou autres. Cependant, il arrive que les airbags soient actionnés de façon anormales, en raison par exemple d’un défaut du système d’airbag lui-même ou éventuellement en cas de fraude. Or, il est essentiel de pouvoir s’assurer que les airbags d’un véhicule ont été utilisés de façon normale, notamment pour vérifier s’ils sont toujours fonctionnels. S’assurer de l’intégrité d’un airbag dans un véhicule pose aujourd’hui des difficultés techniques. Il est difficile de connaître l’état d’un airbag équipant un véhicule, de type automobile ou autre, ce qui pose des problèmes de confiance, sécurité, traçabilité, etc., notamment en cas de revente du véhicule en question. Résumé de la présente invention L’un des objets de la présente invention est de résoudre au moins l’un des problèmes ou déficiences de l’arrière-plan technologique décrit précédemment. Un autre objet de la présente invention est de permettre un suivi de l’état d’un ou plusieurs airbags d’un véhicule, par exemple de type automobile ou autre. Un autre objet de la présente invention est de vérifier si un ou des airbags équipant un véhicule sont été utilisés de façon normale. Selon un premier aspect, la présente invention concerne un procédé (dit aussi procédé de suivi ou procédé de traitement), mis en œuvre par un dispositif de traitement, pour surveiller au moins un airbag d’un véhicule, ledit procédé comprenant : - obtention de données d’historique représentatives d’au moins un déclenchement d’airbag survenu parmi ledit au moins un airbag du véhicule ; - si des données de contexte, représentatives d’un contexte dans lequel s’est produit ledit au moins un déclenchement d’airbag, sont récupérées en association avec les données d’historique, détermination de si ledit au moins un déclenchement d’airbag est normal ou anormal par analyse de conformité desdites données de contexte par rapport à au moins un critère d’intégrité ; et - génération, à partir d’un résultat de ladite détermination, d’un indicateur d’intégrité indiquant un degré d’intégrité des données d’historique. La présente invention permet avantageusement de surveiller de façon fiable et sécurisée les airbags d’un véhicule, par exemple de type automobile ou autre. Un utilisateur peut notamment déterminer l’état des airbags d’un véhicule en consultant l’indicateur d’intégrité qui indique si les données d’historique sont intègres ou non. On peut ainsi vérifier si un ou des airbags équipant un véhicule ont été utilisés de façon normale. Si un airbag d’un véhicule est par exemple déclenché lors d’un accident, d’une activation d’un appel d’urgence et/ou d’une opération de maintenance (passage en atelier), alors l’indicateur d’intégrité peut indiquer que ce déclenchement est normal. En revanche, si un airbag est déclenché dans un contexte autre que ceux précités, alors l’indicateur d’intégrité peut indiquer que ce déclenchement constitue une anomalie et donc le signe d’une potentielle fraude. La génération d’un tel indicateur d’intégrité est possible en prenant en compte à la fois des données d’historique et des données de contexte. Autrement dit, les données d’historique et les données de contexte sont agrégés afin d’en déduire si des déclenchements d’airbag sont normaux ou anormaux. Les données de contexte permettent avantageusement d’évaluer si un déclenchement d’airbag est conforme à l’utilisation qui attendue pour l’airbag en question. Sans justification appropriée, un déclenchement d’airbag peut en particulier est détecté comme potentiellement frauduleux. Le procédé selon l’invention peut comporter d’autres caractéristiques qui peuvent être prises séparément ou en combinaison, notamment parmi les modes de réalisation qui suivent. Selon un mode de réalisation particulier, l’analyse de conformité détermine ledit au moins un déclenchement d’airbag comme normal si les données de contexte sont conformes audit au moins critère d’intégrité et détermine ledit au moins un déclenchement d’airbag comme anormal si les données de contexte ne sont pas Selon un mode de réalisation particulier, l’analyse de conformité détermine ledit au moins un déclenchement d’airbag comme normal si ledit au moins un déclenchement d’airbag s’est produit dans au moins l’un quelconque des contextes suivants selon les données de contexte : - un accident du véhicule ; - une activation d’un appel d’urgence ; et - une opération de maintenance du véhicule. Selon un mode de réalisation particulier, lesdites données de contexte récupérées comprennent des données de contexte externes reçues via une plateforme de gestion de données, lesdites données de contexte externes indiquant que ledit au moins un déclenchement d’airbag s’est produit dans le contexte d’une opération de maintenance du véhicule. Selon un mode de réalisation particulier, la plateforme de gestion de données est une plateforme de type chaine de blocs. Selon un mode de réalisation particulier, sur détection des données de contexte externes, ladite analyse de conformité détermine que ledit au moins un déclenchement d’airbag est normal. Selon un mode de réalisation particulier, si aucune dite donnée de contexte n’est récupérée en association avec les données d’historique, détermination que ledit au moins un déclenchement d’airbag est anormal, dans lequel l’indicateur d’intégrité indique un défaut d’intégrité des données d’historique. Selon un mode de réalisation particulier, le procédé comprend : - incorporation de l’indicateur d’intégrité dans un certificat numérique associé au véhicule ; et - transmission du certificat numérique pour causer une restitution par une interface utilisateur dudit certification numérique comprenant l’indicateur d’intégrité. Selon un deuxième aspect, la présente invention concerne un dispositif de traitement (dit aussi dispositif de contrôle ou dispositif) pour surveiller au moins un airbag d’un véhicule, le dispositif comprenant une mémoire associée à un processeur configuré pour la mise en œuvre des étapes du procédé selon le premier aspect de la présente invention. A noter que les différents modes de réalisation mentionnés ci-avant en relation avec le procédé selon le premier aspect de l’invention ainsi que les avantages associés s’appliquent de façon analogue au dispositif de contrôle selon le deuxième aspect de l’invention. Selon un troisième aspect, la présente invention concerne un système comprenant un dispositif de traitement selon le deuxième aspect de la présente invention ainsi qu’un véhicule, par exemple de type automobile ou de type véhicule à moteur terrestre. Selon un quatrième aspect, la présente invention concerne un programme d’ordinateur qui comporte des instructions adaptées pour l’exécution des étapes du procédé selon le premier aspect de la présente invention, ceci notamment lorsque le programme d’ordinateur est exécuté par au moins un processeur. Autrement dit, les différentes étapes du procédé sont déterminées par des instructions de programmes d’ordinateurs. Ce programme d’ordinateur est configuré pour être mis en œuvre dans un dispositif de traitement du deuxième aspect de l’invention, ou plus généralement dans un ordinateur. Un tel programme d’ordinateur peut utiliser n’importe quel langage de programmation, et être sous la forme d’un code source, d’un code objet, ou d’un code intermédiaire entre un code source et un code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. Selon un cinquième aspect, la présente invention concerne un support d’enregistrement (ou support d’informations), lisible par le dispositif de traitement selon le deuxième aspect ou plus généralement par un ordinateur (ou un processeur), sur lequel est enregistré un programme d’ordinateur comprenant des instructions pour l’exécution des étapes du procédé selon le premier aspect de la présente invention. D’une part, le support d’enregistrement peut être n'importe quel entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une mémoire ROM, un CD-ROM ou une mémoire ROM de type circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou un disque dur. D'autre part, ce support d’enregistrement peut également être un support transmissible tel qu'un signal électrique ou optique, un tel signal pouvant être acheminé via un câble électrique ou optique, par radio classique ou hertzienne ou par faisceau laser autodirigé ou par d'autres moyens. Le programme d’ordinateur selon la présente invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme d’ordinateur est incorporé, le circuit intégré étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des figures D’autres caractéristiques et avantages de la présente invention ressortiront de la description des exemples de réalisation particuliers et non limitatifs de la présente invention ci-après, en référence aux figures 1 à 3 annexées, sur lesquelles : illustre schématiquement un dispositif surveillant au moins un airbag d’un véhicule, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; illustre schématiquement le dispositif de la , selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; et illustre un diagramme de différentes étapes d’un procédé pour surveiller au moins un airbag du véhicule de la , selon au moins un exemple de réalisation particulier et non limitatif de la présente invention. Description des exemples de réalisation Un procédé et un dispositif de contrôle d’un véhicule vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1-3. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité. Les termes « premier(s) » (ou première(s)), « deuxième(s) », etc.) sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des données, des opérations, etc.) mis en œuvre dans les modes de réalisation décrits ci-après. Comme précédemment indiqué, l’invention vise notamment un procédé (ou procédé de surveillance, ou procédé de traitement) d’au moins un airbag d’un véhicule, tel qu’un véhicule de type automobile ou autre, ou plus généralement un véhicule de type véhicule terrestre motorisé. Selon un exemple particulier et non limitatif de réalisation de la présente invention, ce procédé comprend : - obtention de données d’historique représentatives d’au moins un déclenchement d’airbag survenu parmi ledit au moins un airbag du véhicule ; - si des données de contexte, représentatives d’un contexte dans lequel s’est produit ledit au moins un déclenchement d’airbag, sont récupérées en association avec les données d’historique, détermination de si ledit au moins un déclenchement d’airbag est normal ou anormal par analyse de conformité desdites données de contexte par rapport à au moins un critère d’intégrité ; et - génération, à partir d’un résultat de ladite détermination, d’un indicateur d’intégrité indiquant un degré d’intégrité des données d’historique. D’autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant. La illustre schématiquement un dispositif de traitement 10 (dit aussi dispositif de contrôle ou dispositif) configuré pour surveiller au moins un airbag 4 d’un véhicule 2. Autrement dit, le dispositif 10 est apte à suivre l’état d’au moins un airbag du véhicule 2. On considère par la suite que le véhicule 2 est de type automobile bien que le concept de l’invention soit applicable à d’autres types de véhicule. Le type et les caractéristiques du véhicule 2 peuvent ainsi être adaptés selon le cas. En variante, le véhicule 2 peut par exemple être un car, un bus, un camion, un véhicule utilitaire, ou plus généralement un véhicule de type véhicule terrestre motorisé. Le véhicule 2 peut être équipé d’un unique airbag 4 ou d’une pluralité d’airbags 4. Comme déjà indiqué, les airbags 4 sont des coussins gonflables de sécurité (appelés aussi coussins gonflables ou enveloppes flexibles) configurés pour qu’un gaz y soit brusquement injecté par une réaction chimique explosive de façon à être gonflés très rapidement et ainsi servir de coussin pour amortir un choc. Chaque airbag 4 est configuré pour être déclenché sur détection d’un évènement déclencheur, par exemple sur détection d’un accident ou d’un choc affectant le véhicule 2. L’activation des airbags permet d’assurer la protection du ou des occupants du véhicule 2. On suppose par la suite que le dispositif 10 surveille de multiples airbags 4 du véhicule 2, bien que le concept de l’invention soit applicable de façon analogue à la surveillance d’un unique airbag 4 du véhicule 2. Comme représenté en , le véhicule 2 peut comprendre par exemple un dispositif embarqué 3, tel qu’un ou plusieurs calculateurs par exemple, configuré pour détecter chaque déclenchement d’airbag survenu dans le véhicule 4 et pour générer des données d’historique DT1 représentatives de ce ou ces déclenchements d’airbag. Pour chaque déclenchement d’airbag détecté, les données d’historique DT1 comprennent par exemple un identifiant de l’airbag 4 déclenché et d’éventuelles informations complémentaires (instant dans le temps, etc.). Ces données d’historique DT1 sont par exemple enregistrées dans une mémoire non volatile du dispositif 3. Le contenu, le format, etc. des données d’historique DT1 peuvent être adaptés selon le cas. Le dispositif embarqué 3 peut en outre être configuré pour transmettre au dispositif 10 les données d’historique DT1 afin que ces dernières soient traitées comme décrit ci-après. Comme illustré en , le dispositif 10 le dispositif 10 peut être un serveur ou tout autre équipement informatique apte à mettre en œuvre un processus (ou procédé) comme décrit ci-après. A cet effet, le dispositif 10 est apte à coopérer (ou communiquer) avec le véhicule 2, et plus particulièrement avec son dispositif embarqué 3 afin de récupérer les données d’historique DT1 du véhicule 2. Le dispositif 10 est par exemple implémenté dans un réseau de communication NT1, de type Internet, Intranet ou autre, accessible par le dispositif embarqué 3. Comme décrit plus en détail ultérieurement en référence à la , le dispositif 10 peut comprendre au moins un processeur et une mémoire non volatile. Le dispositif 10 peut comprendre un programme d’ordinateur PG1 ( ) stockée dans la mémoire non volatile (mémoire de type Flash ou ROM par exemple), ce programme d’ordinateur PG1 comprenant des instructions pour la mise en œuvre du procédé (ou processus) comme décrit ci-après. Le processeur est ainsi configuré pour exécuter notamment les instructions définies par le programme d’ordinateur PG1. Comme représenté en , le dispositif 10 est configuré pour recevoir et traiter les données d’historique DT1 transmises depuis le dispositif embarqué 3 du véhicule 2. Ces données d’historique DT1 peuvent par exemple être stockées dans une mémoire non volatile du dispositif 10. Le dispositif 10 peut en outre obtenir des données de contexte DT2 ( ) et traiter ces données DT2 conformément au procédé (ou processus) de l’invention. Comme décrit plus en détail ci-après, ces données de contexte DT2 sont représentatives d’un contexte dans lequel s’est produit au moins un déclenchement d’airbag 4 parmi les airbags 4 du véhicule 2. Autrement dit, ces données de contexte DT2 caractérisent dans quelles circonstances se sont produit un ou des déclenchements d’airbag 4. Ainsi, en associant les données d’historique DT1 à des données de contexte DT2, on peut définir chaque déclenchement d’airbag se produisant dans le véhicule 2 ainsi que le contexte dans lequel ce ou ces déclenchement d’airbag se sont produits. Comme décrit par la suite dans des exemples particuliers, la manière dont les données de contexte DT2 sont obtenues par le dispositif 10 peut varier selon le cas. Le dispositif 10 peut par exemple recevoir tout ou partie des données de contexte DT2 depuis le dispositif embarqué 3 du véhicule 2. A cet effet, le dispositif embarqué 3 peut être configuré pour associer, aux données d’historiques DT1, des données de contexte DT2 définissant le contexte dans lequel s’est produit chaque déclenchement d’airbag. Selon un exemple particulier, le dispositif 10 est configuré pour recevoir tout ou partie des données d’historique DT2 depuis une infrastructure 6, ou plus particulièrement depuis un dispositif externe 8 gérant ladite infrastructure 6. Cette infrastructure 6 correspond par exemple à un atelier de réparation, un garage ou toute autre infrastructure destinée à réaliser des opérations de maintenance sur des véhicules, tel que notamment le véhicule 2. Comme illustré, le dispositif externe 8 est par exemple configuré pour transmettre au dispositif 10 des données de contexte DT2, notée plus précisément DT2a, ces données étant représentatives d’un contexte dans lequel s’est produit au moins un déclenchement d’airbag parmi les airbags 4 du véhicule 2. En effet, en cas de maintenance du véhicule 2, ce dernier peut être soumis à une ou des opérations de maintenance. Ces opérations de maintenance peuvent varier selon le cas et peuvent correspondre à une quelconque opération (révision, test, vérification, etc.) destinées à assurer la maintenance du véhicule 2. Ces opérations de maintenance peuvent le cas échéant conduire à (ou comprendre) au moins un déclenchement d’airbag parmi les airbags 4 du véhicule 2. Ainsi, les données de contexte DT2a permettent par exemple de définir au moins un déclenchement d’airbag parmi les airbags 4 du véhicule 2 en tant que déclenchement de maintenance, c’est-à-dire un déclenchement d’airbag résultant d’une (ou associé à une) opération de maintenance. Par ailleurs, le dispositif 10 est configuré pour générer un indicateur d’intégrité IN1 au cours du procédé (ou processus) de l’invention, par un traitement des données d’historique DT1 et des données de contexte DT2. La nature de cet indicateur IN1 ainsi que du traitement nécessaire sera décrit plus en détail ultérieurement. Le dispositif 10 est en outre configuré pour transmettre des données de suivi DT3, comprenant l’indicateur de suivi IN1, pour causer la restitution par une interface utilisateur 12 des données de suivi DT3. Ces données de suivi DT3 prennent par exemple la forme d’un certificat numérique associé au véhicule 2, ce certificat comprenant des données caractérisant l’état du véhicule 2 et en particulier l’état de ses airbags 4. Comme illustré en , on suppose par la suite qu’un utilisateur UR1 utilise un terminal T1 (une tablette, un téléphone intelligent de type « smartphone », ou tout autre équipement approprié) comprenant l’interface utilisateur 12 nécessaire pour la restitution des données de suivi DT3. La restitution peut comprendre un affichage, une restitution sonore, ou tout autre restitution permettant à l’utilisateur UR1 de prendre connaissance du contenu des informations de suivi DT3. Comme indiqué ci-avant, le dispositif 10 est configuré pour mettre en œuvre un processus (dit aussi processus de traitement ou processus de surveillance). Ce processus est à présent décrit conjointement aux figures 1 et 2 selon des modes de réalisation particuliers. Dans une première opération, le dispositif 10 obtient des données d’historique DT1 représentatives d’au moins un déclenchement d’airbag survenu parmi les airbags du véhicule 2. Comme déjà indiqué, ces données d’historique DT1 sont par exemple préalablement générées par le dispositif embarqué 3 et transmises par ce dernier au dispositif 10. A noter que des variantes son possibles dans lesquelles le dispositif 10 obtient les données d’historique DT1 d’une quelconque autre façon appropriée (par exemple en consultant une mémoire ou en recevant ces données depuis une autre source). On suppose par la suite que les données d’historique DT1 définissent une pluralité de déclenchements d’airbag qui se sont produites parmi les airbags 4 du véhicule 2. Dans une deuxième opération, le dispositif 10 détermine si des données de contexte DT2 correspondant aux données d’historique DT1 sont disponibles. Autrement dit, le dispositif 10 cherche à récupérer des données de contexte DT2. Cette phase de recherche au cours de la deuxième opération peut comprendre par exemple la consultation d’une mémoire ou l’envoi d’au moins une requête (par exemple au dispositif externe 8). Selon un exemple particulier, les données de contexte DT2 récupérées comprennent des données de contexte externes DT2a reçues via une plateforme de gestion de données, ces données de contexte externes DT2a indiquant que les (ou au moins un parmi les) déclenchements d’airbag se sont produits (ou s’est produit) dans le contexte d’une opération de maintenance du véhicule 2. Le dispositif 10 peut par exemple comprendre une telle plateforme de gestion de données ou coopérer avec au moins un serveur mettant en œuvre cette plateforme de gestion de données. Selon un exemple particulier, la plateforme de gestion de données est une plateforme de type chaine de blocs (ou « blockchain » en anglais). L’usage d’une telle plateforme peut permettre de partager de façon sécurisée et confidentielle des données de contexte DT2a entre des centres de maintenance (garages, ateliers, etc.) et l’entité (par exemple le constructeur du véhicule 2) en charge du dispositif 10. Si des données de contexte DT2, représentatives d’un contexte dans lequel se sont produits les déclenchements d’airbag, sont récupérées en association avec les données d’historique DT1, le dispositif 10 détermine alors si les déclenchements d’airbag sont normaux ou anormaux par analyse de conformité des données de contexte DT2 par rapport à au moins un critère d’intégrité CT1. Autrement dit, le dispositif 10 compare (ou agrège) les données de contexte DT2 avec un ou des critères d’intégrité CT1 et détermine, à partir d’un résultat de cette comparaison (ou agrégation), si les déclenchements d’airbag sont normaux (ou conformes à une utilisation normale) ou anormaux (pas conforme à une utilisation normale). Comme décrit par la suite, des variantes sont toutefois possibles dans lesquelles aucune donnée de contexte DT2 n’est obtenue par le dispositif 10 au cours de la deuxième opération. L’analyse de conformité réalisée au cours de la deuxième opération vise donc à vérifier si les données de contexte DT2 associée aux déclenchements d’airbag sont conformes à un ou des critères d’intégrités CT1. L’analyse de conformité détermine les déclenchements d’airbag comme normaux si les données de contexte DT2 associées sont conformes audit au moins critère d’intégrité CT1 et détermine les déclenchements d’airbag comme anormaux si les données de contexte DT2 associées ne sont pas conformes audit au moins critère d’intégrité CT1. Le nombre et la nature du ou des critères d’intégrité CT1 appliqués lors de l’analyse de conformité peuvent être adaptés selon le cas, notamment en fonction des déclenchements d’airbag qui sont censés survenir dans le cycle de vie normal d’un airbag du véhicule 2. Selon un exemple particulier, sur détection de données de contexte externes DT2a (par exemple sur réception de données de contexte externes DT2a en provenance du dispositif externe 8 comme précédemment décrit), l’analyse de conformité au cours de la deuxième opération détermine que les déclenchements d’airbag sont normaux. Plus précisément, si des données de contexte externes DT2a sont par exemple récupérées et qu’elles indiquent qu’un déclenchement d’airbag parmi les airbags 4 résulte d’une opération de maintenance, alors ce déclenchement d’airbag est déterminé comme étant normal (conforme aux critères d’intégrité CT1). Selon un exemple particulier, l’analyse de conformité au cours de la deuxième opération détermine un déclenchement d’airbag comme normal si ledit déclenchement d’airbag s’est produit dans au moins l’un quelconque des contextes suivants selon les données de contexte DT2 associées : - un accident du véhicule ; - une activation d’un appel d’urgence ; et - une opération de maintenance du véhicule (passage en atelier). Autrement dit, si un déclenchement d’airbag est défini par les données de contexte DT2 comme s’étant produit lors d’un accident du véhicule 4, lors d’une activation d’un appel d’urgence associée au véhicule 2 (par exemple activation d’un service d’appel d’urgence de type « e-call » depuis le véhicule 2) ou lors d’une opération de maintenance du véhicule 2, alors ledit déclenchement d’airbag 4 est considéré comme étant normal. On peut ainsi appliquer au moins l’un quelconque des critères d’intégrité parmi ce qui suit : contexte de déclenchement = accident ; contexte de déclenchement = activation d’appel d’urgence ; et contexte de déclenchement = opération de maintenance. Selon un exemple particulier, l’analyse de conformité au cours de la deuxième opération détermine un déclenchement d’airbag comme anormal (et donc une potentielle fraude) si ledit déclenchement d’airbag ne s’est produit dans aucun parmi les contextes suivants : - un accident du véhicule ; - une activation d’un appel d’urgence ; et - une opération de maintenance du véhicule. A noter ce que l’on entend ici par « accident » peut correspondre à un quelconque évènement rencontré par le véhicule 2 et détecté comme tel par le dispositif embarqué 3 (par exemple une collision, un choc, une panne, etc.). Comme indiqué ci-avant, si des données de contexte DT2 sont récupérées au cours de la deuxième opération, le dispositif 10 réalise une analyse conformité pour déterminer si ces données de contexte DT2 sont conformes ou non conformes aux critères d’intégrité CT1. A noter toutefois que des exemples de réalisation sont possibles dans lesquels aucune donnée de contexte DT2 n’est récupérée par le dispositif 10 au cours de la deuxième opération. Ainsi, selon un exemple particulier, si aucune donnée de contexte DT2 n’est récupérée en association avec les données d’historique DT1, le dispositif 10 détermine que les déclenchements d’airbag sont anormaux. Dans une troisième opération, le dispositif 10 génère, à partir d’un résultat de la détermination réalisée au cours de la deuxième opération, un indicateur d’intégrité IN1 indiquant un degré d’intégrité des données d’historique DT1. Autrement dit, l’indicateur d’intégrité IN1 indique dans quelle mesure les données d’historique DT1 sont intègres (ou acceptables). Selon un exemple particulier, l’indicateur d’intégrité IN1 prend la forme d’un taux d’intégrité. Selon un exemple particulier, le dispositif 10 enregistre dans une mémoire locale non volatile l’indicateur d’intégrité IN1 afin que ce dernier soit accessible par un utilisateur UR1. A partir de cet indicateur IN1, un utilisateur UR1 peut donc en déduire si les données d’historique DT1 sont intègres ou non, autrement dit si elles présentent ou non un défaut d’intégrité. En particulier, si un déclenchement d’airbag résulte d’une fraude ou d’une défaut du véhicule 2 (comportement anormal), alors il est possible de le détecter à partir de l’indicateur d’intégrité IN1. Selon un exemple particulier, si un déclenchement d’airbag défini par les données d’historique DT1 sont déterminées comme anormales lors de l’analyse de conformité, alors l’indicateur d’intégrité IN1 indique un défaut d’intégrité desdites données d’historique DT1 (autrement dit, les données d’historique DT1 sont corrompues). Selon un exemple particulier, le dispositif 10 génère en outre des données de suivi DT3 comprenant l’indicateur d’intégrité IN1 et éventuellement aussi les données d’historique DT1. Le dispositif 10 peut en outre transmettre ces données de suivi DT3 pour causer la restitution par une interface utilisateur 12 des données de suivi DT3 comprenant l’indicateur d’intégrité IN1 (éventuellement en association avec les données d’historique DT1). Les données de suivi DT3 sont par exemple transmises au terminal T1 de façon à causer la restitution (affichage ou rendu par exemple) de ces données. L’utilisateur UR1 peut ainsi consulter les données de suivi DT3, et plus particulièrement l’indicateur d’intégrité IN1, pour déterminer l’état des airbags 4 du véhicule 2. Selon un exemple particulier, les données de suivi DT3 sont (ou comprennent) un certificat numérique associé au véhicule 2. Ainsi, un certificat de véhicule (ou « Vehicule Certificate » en anglais) incorporant l’indicateur IN1 peut être fourni via l’interface utilisateur 12 à l’utilisateur UR1. Selon un exemple particulier, le dispositif 10 incorpore l’indicateur d’intégrité IN1 dans un certificat numérique associé au véhicule 2 et transmet le certificat numérique pour causer une restitution par l’interface utilisateur 12 dudit certification numérique comprenant l’indicateur d’intégrité IN1. Un tel processus permet donc de surveiller de façon fiable et sécurisée les airbags d’un véhicule, par exemple de type automobile ou autre. Un utilisateur peut notamment déterminer l’état des airbags d’un véhicule en consultant l’indicateur d’intégrité IN1 qui indique si les données d’historique DT1 sont intègres ou non. On peut ainsi vérifier si un ou des airbags équipant un véhicule ont été utilisés de façon normale. Si un airbag d’un véhicule est par exemple déclenché lors d’un accident, d’une activation d’un appel d’urgence et/ou d’une opération de maintenance (passage en atelier), alors l’indicateur d’intégrité IN1 peut indiquer que ce déclenchement est normal. En revanche, si un airbag est déclenché dans un contexte autre que ceux précités, alors l’indicateur d’intégrité IN1 peut indiquer que ce déclenchement constitue une anomalie et donc le signe d’une potentielle fraude. La génération d’un tel indicateur d’intégrité est possible en prenant en compte à la fois des données d’historique DT1 et des données de contexte DT2. Autrement dit, les données DT1 et DT2 sont agrégés afin d’en déduire si des déclenchements d’airbag sont normaux ou anormaux. Les données de contexte DT2 permettent avantageusement d’évaluer si un déclenchement d’airbag est conforme à l’utilisation qui attendue pour l’airbag en question. Sans justification appropriée, un déclenchement d’airbag peut en particulier est détecté comme potentiellement frauduleux. Comme indiqué ci-avant, un certificat numérique (ou certificat de véhicule) incorporant l’indicateur d’intégrité IN1 peut en outre être généré et restitué à un utilisateur UR1. L’usage d’un tel certificat, et en particulier de l’indicateur d’intégrité IN1, peut permettre par exemple de sécuriser la documentation technique d’un véhicule, ce qui est utile par exemple pour sécuriser une transaction lors d’une vente (par exemple en cas de revente du véhicule 2). En renforçant la sécurité du certificat de véhicule, on peut ainsi améliorer le service associé et augmenter sa valeur. La illustre schématiquement un dispositif de contrôle 10 selon un exemple de réalisation particulier et non limitatif de la présente invention, ledit dispositif 10 étant configuré pour suivre le ou les airbags 4 d’un véhicule, tel que le véhicule 2 comme précédemment décrit en référence à la . Le dispositif 10 correspond par exemple à un ou plusieurs serveurs. Le dispositif 10 est par exemple configuré pour la mise en œuvre des opérations du processus tel que précédemment décrit en regard des figures 1-2 et/ou des étapes du procédé décrit ci-après en regard de la . Des exemples d’un tel dispositif 10 comprennent, sans y être limités, un serveur, un équipement électronique embarqué tel qu’un ordinateur de bord d’un véhicule, un calculateur électronique tel qu’une UCE (« Unité de Commande Electronique »), un téléphone intelligent (de l’anglais « smartphone »), une tablette, un ordinateur portable. Les éléments du dispositif 10, individuellement ou en combinaison, peuvent être intégrés dans un unique circuit intégré, dans plusieurs circuits intégrés, et/ou dans des composants discrets. Le dispositif 10 peut être réalisé sous la forme de circuits électroniques ou de modules logiciels (ou informatiques) ou encore d’une combinaison de circuits électroniques et de modules logiciels. Le dispositif 10 comprend un (ou plusieurs) processeur(s) 40 configurés pour exécuter des instructions pour la réalisation des étapes du procédé (ou du processus) de l’invention et/ou pour l’exécution des instructions du ou des logiciels embarqués dans le dispositif 10. Le processeur 40 peut inclure de la mémoire intégrée, une interface d’entrée/sortie, et différents circuits connus de l’homme du métier. Le dispositif 10 comprend en outre au moins une mémoire 41 correspondant par exemple à une mémoire volatile et/ou non volatile et/ou comprend un dispositif de stockage mémoire qui peut comprendre de la mémoire volatile et/ou non volatile, telle que EEPROM, ROM, PROM, RAM, DRAM, SRAM, flash, disque magnétique ou optique. Le code informatique du ou des logiciels embarqués comprenant les instructions à charger et exécuter par le processeur 40 est par exemple stocké sur la mémoire 41. La mémoire 41 peut constituer un support d’informations selon un mode de réalisation particulier en ce qu’elle comprend un programme d’ordinateur (par exemple PG1 en ) comportant des instructions pour la réalisation des étapes du procédé (ou du processus) de l’invention. Selon différents exemples de réalisation particuliers et non limitatifs, le dispositif 10 est couplé en communication avec d’autres dispositifs ou systèmes similaires et/ou avec des dispositifs de communication, par exemple une TCU (de l’anglais « Telematic Control Unit » ou en français « Unité de Contrôle Télématique »), par exemple par l’intermédiaire d’un bus de communication ou au travers de ports d’entrée / sortie dédiés. Selon un exemple de réalisation particulier et non limitatif, le dispositif 10 comprend un bloc 42 d’éléments d’interface pour communiquer avec des dispositifs externes, par exemple un serveur distant ou le « cloud », ou le véhicule 2. Les éléments d’interface du bloc 42 comprennent une ou plusieurs des interfaces suivantes : interface radiofréquence RF, par exemple de type Wi-Fi® (selon IEEE 802.11), par exemple dans les bandes de fréquence à 2,4 ou 5 GHz, ou de type Bluetooth® (selon IEEE 802.15.1), dans la bande de fréquence à 2,4 GHz, ou de type Sigfox utilisant une technologie radio UBN (de l’anglais Ultra Narrow Band, en français bande ultra étroite), ou LoRa dans la bande de fréquence 868 MHz, LTE (de l’anglais « Long-Term Evolution » ou en français « Evolution à long terme »), LTE-Advanced (ou en français LTE-avancé) ; interface USB (de l’anglais « Universal Serial Bus » ou « Bus Universel en Série » en français) ; interface HDMI (de l’anglais « High Definition Multimedia Interface », ou « Interface Multimedia Haute Definition » en français). Selon un exemple de réalisation particulier et non limitatif, le dispositif 10 comprend une interface de communication 43 qui permet d’établir une communication avec d’autres dispositifs via un canal de communication 45. L’interface de communication 43 correspond par exemple à un transmetteur configuré pour transmettre et recevoir des informations et/ou des données via le canal de communication 45. L’interface de communication 43 correspond par exemple à un réseau filaire de type CAN (de l’anglais « Controller Area Network » ou en français « Réseau de contrôleurs »), CAN FD (de l’anglais « Controller Area Network Flexible Data-Rate » ou en français « Réseau de contrôleurs à débit de données flexible »), FlexRay (standardisé par la norme ISO 17458), Ethernet (standardisé par la norme ISO/IEC 802-3) ou LIN (de l’anglais « Local Interconnect Network », ou en français « Réseau interconnecté local »). Le dispositif 10 coopère par exemple avec le dispositif embarqué 42 et le terminal T1 au moyen du bloc 42 d’éléments d’interface et/ou de l’interface de communication 43. Selon un exemple de réalisation particulier et non limitatif, le dispositif 10 peut fournir des signaux de sortie à un ou plusieurs dispositifs externes, tels qu’un écran d’affichage, tactile ou non, un ou des haut-parleurs et/ou d’autres périphériques (système de projection) via des interfaces de sortie respectives. Selon une variante, l’un ou l’autre des dispositifs externes est intégré au dispositif 10. La illustre un diagramme des différentes étapes d’un procédé (ou procédé de traitement, ou procédé de suivi) pour le suivi d’au moins un airbag 4 d’un véhicule, par exemple du véhicule 2 comme précédemment décrit. Le procédé est par exemple mis en œuvre par le dispositif 10 précédemment décrit. Dans une première étape 51, des données d’historique DT1 sont obtenues, ces données DT1 étant représentatives d’au moins un déclenchement d’airbag survenu parmi ledit au moins un airbag 4 du véhicule 2. Dans une deuxième étape 52, si des données de contexte DT2, représentatives d’un contexte dans lequel s’est produit ledit au moins un déclenchement d’airbag, sont récupérées en association avec les données d’historique DT1, il est déterminé si ledit au moins un déclenchement d’airbag est normal ou anormal par analyse de conformité des données de contexte DT2 par rapport à au moins un critère d’intégrité CT1. Dans une troisième étape 53, un indicateur d’intégrité IN1 est généré à partir d’un résultat de la détermination réalisé au cours de la deuxième étape 52, l’indicateur d’intégrité IN1 indiquant un degré d’intégrité des données d’historique DT1. Selon des variantes de réalisation, les variantes et exemples des opérations décrits ci-avant en relation avec les figures 1-2 s’appliquent de façon analogue aux étapes du procédé de la . Un homme du métier comprendra que les modes de réalisation et variantes décrits ci-avant ne constituent que des exemples non limitatifs de mise en œuvre de l’invention. En particulier, l’homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant, afin de répondre à un besoin bien particulier. La présente invention ne se limite donc pas aux exemples de réalisation décrits ci-avant mais s’étend notamment à un procédé qui inclurait des étapes secondaires sans pour cela sortir de la portée de la présente invention. Il en serait de même d’un dispositif configuré pour la mise en œuvre d’un tel procédé. La présente invention concerne également un système comprenant un dispositif 10 tel que précédemment décrit ainsi qu’un véhicule 2, par exemple automobile ou plus généralement un véhicule à moteur terrestre. Procédé, mis en œuvre par un dispositif de traitement (10), pour surveiller au moins un airbag (4) d’un véhicule (2), ledit procédé comprenant : - obtention (51) de données d’historique (DT1) représentatives d’au moins un déclenchement d’airbag survenu parmi ledit au moins un airbag du véhicule ; - si des données de contexte (DT2), représentatives d’un contexte dans lequel s’est produit ledit au moins un déclenchement d’airbag, sont récupérées en association avec les données d’historique (DT1), détermination (52) de si ledit au moins un déclenchement d’airbag est normal ou anormal par analyse de conformité desdites données de contexte (DT2) par rapport à au moins un critère d’intégrité (CT1) ; et - génération (53), à partir d’un résultat de ladite détermination, d’un indicateur d’intégrité (IN1) indiquant un degré d’intégrité des données d’historique. Procédé selon la revendication 1, dans lequel l’analyse de conformité détermine ledit au moins un déclenchement d’airbag comme normal si les données de contexte (DT2) sont conformes audit au moins critère d’intégrité (CT1) et détermine ledit au moins un déclenchement d’airbag comme anormal si les données de contexte (DT2) ne sont pas conformes audit au moins critère d’intégrité (CT1). Procédé selon la revendication 1 ou 2, dans lequel l’analyse de conformité détermine ledit au moins un déclenchement d’airbag comme normal si ledit au moins un déclenchement d’airbag s’est produit dans au moins l’un quelconque des contextes suivants selon les données de contexte (DT2) : - un accident du véhicule ; - une activation d’un appel d’urgence ; et - une opération de maintenance du véhicule. Procédé selon l’une quelconque des revendications précédentes, dans lequel lesdites données de contexte (DT2) récupérées comprennent des données de contexte externes (DT2a) reçues via une plateforme de gestion de données, lesdites données de contexte externes indiquant que ledit au moins un déclenchement d’airbag s’est produit dans le contexte d’une opération de maintenance du véhicule. Procédé selon la revendication 4, dans lequel la plateforme de gestion de données est une plateforme de type chaine de blocs. Procédé selon la revendication 4 ou 5, dans lequel, sur détection des données de contexte externes (DT2a), ladite analyse de conformité détermine que ledit au moins un déclenchement d’airbag est normal. Procédé selon l’une quelconque des revendications précédentes, dans lequel si aucune dite donnée de contexte (DT2) n’est récupérée en association avec les données d’historique (DT1), détermination que ledit au moins un déclenchement d’airbag est anormal, dans lequel l’indicateur d’intégrité (IN1) indique un défaut d’intégrité des données d’historique. Procédé selon l’une quelconque des revendications précédentes, dans lequel le procédé comprend : - incorporation de l’indicateur d’intégrité (IN1) dans un certificat numérique (DT3) associé au véhicule (2) ; et - transmission du certificat numérique (DT3) pour causer une restitution par une interface utilisateur dudit certification numérique comprenant l’indicateur d’intégrité. Programme d’ordinateur (PG1) comportant des instructions pour la mise en œuvre du procédé selon l’une quelconque des revendications précédentes, lorsque ces instructions sont exécutées par un processeur (40). Dispositif de traitement (10) pour surveiller au moins un airbag (4) d’un véhicule (2), ledit dispositif de traitement comprenant une mémoire (41) associée à au moins un processeur (40) configuré pour la mise en œuvre des étapes du procédé selon l’une quelconque des revendications 1 à 8.