Brevet FR3126208A1 — publié le 20230224

Ce système (2) pour identifier des défauts probables d’un actif (1) au sein d’un parc d’actifs (8) comprend des capteurs (10) configurés pour détecter des données de capteur d’actifs (6b) ; un ou plusieurs dispositifs d’entrée d’utilisateur (13, 16) associés à ladite pluralité d’actifs (8) ; et une ou plusieurs bornes de sortie d’utilisateur (15) associées à ladite pluralité d’actifs (8) ; et un dispositif serveur (7). Le dispositif serveur (7) est configuré pour collecter des données historiques; pour utiliser un algorithme pour identifier des corrélations dans lesdites données historiques ; obtenir des données de capteur d’actifs actuelles (6b); calculer un ou plusieurs défauts probables qui peuvent être présents sur l’actif (1) sur la base des corrélations identifiées dans les données historiques, et sur la base des données de capteur d’actifs actuelles (6b); et envoyer lesdits défauts probables à une borne de sortie d’utilisateur associée à l’actif donné (1). Figure pour l’abrégé : Fig 1 ASSISTANT D’INSPECTION D’ACTIFS La présente invention concerne des systèmes et des procédés d’aide à l’inspection d’actifs et/ou d’identification de défauts probables d’un actif au sein d’un parc d’actifs. Plus particulièrement, la présente invention concerne des systèmes et des procédés d’aide à l’inspection d’un véhicule et/ou d’identification de défauts probables d’un véhicule au sein d’un parc de véhicules. Contexte Dans la plupart des pays, les utilisateurs d’actifs tels que les groupes électrogènes, les remorques, les machines ou les véhicules utilitaires sont tenus en vertu de la loi et/ou des politiques d’entreprise de remplir une liste de contrôle périodiquement ou, avant d’utiliser un actif, de vérifier les défauts de l’actif. Ce processus est extrêmement important pour la sécurité des utilisateurs, des employés et, lorsque l’actif est un véhicule, des passagers et des autres usagers de la route. Actuellement, les utilisateurs effectuent les contrôles en se basant principalement sur leur expérience antérieure et sur les défauts visibles. Cette approche introduit cependant un degré élevé d’erreur humaine. En particulier, les conducteurs de véhicules utilitaires sont souvent soumis à des contraintes de temps importantes en raison d’horaires chargés. En conséquence, il n’est pas rare que les utilisateurs/conducteurs effectuent des contrôles moins approfondis ou sautent certains éléments de liste de contrôle afin de réduire le temps d’inspection et de les aider à respecter le programme. De toute évidence, une telle approche compromet la sécurité, et il est donc nécessaire d’améliorer les moyens pour effectuer des vérifications d’actifs. Selon un premier aspect de la présente invention, il est proposé un système d’identification de défauts probables d’un actif au sein d’un parc d’actifs, le système comprenant : un ou plusieurs capteurs configurés pour détecter des données de capteur d’actifs du parc d’actifs ; un ou plusieurs dispositifs d’entrée d’utilisateur associés à ladite pluralité d’actifs configurés pour recevoir des données de rapport d’inspection du parc d’actifs ; une ou plusieurs bornes de sortie d’utilisateur associées à ladite pluralité d’actifs ; et un dispositif serveur, dans lequel le dispositif serveur est configuré pour : collecter des données historiques comprenant : des données de capteur d’actifs historiques générées par les un ou plusieurs capteurs sur le parc d’actifs ; et des données de rapport d’inspection historiques à partir des un ou plusieurs dispositifs d’entrée d’utilisateur associés au parc d’actifs ; utiliser un algorithme pour identifier les corrélations dans les données historiques ; obtenir des données de capteur d’actifs actuelles à partir des un ou de plusieurs capteurs sur un actif donné au sein du parc d’actifs et/ou obtenir des données de rapport d’inspection actuelles à partir d’un dispositif d’entrée d’utilisateur associé à un actif donné au sein du parc d’actifs ; calculer un ou plusieurs défauts probables qui peuvent être présents sur l’actif donné sur la base des corrélations identifiées dans les données historiques, et sur la base des données de capteur d’actifs actuelles et/ou des données de rapport d’inspection actuelles ; et envoyer lesdits un ou plusieurs défauts probables à une borne de sortie d’utilisateur associée à l’actif donné ; dans lequel ladite borne de sortie d’utilisateur est configurée pour afficher une indication desdits un ou plusieurs défauts probables. Les données de capteur d’actifs, à la fois historiques et actuelles, générées par un ou plusieurs capteurs peuvent éventuellement être obtenues par le dispositif serveur directement à partir des un ou plusieurs capteurs. Cependant, dans des modes de réalisation préférés, les données de capteur d’actifs peuvent être obtenues par le dispositif serveur à partir d’un dispositif télématique installé sur l’actif ou sur chaque actif au sein du parc d’actifs. Ainsi, de préférence, le dispositif serveur est configuré pour communiquer avec un dispositif télématique installé sur un actif au sein du parc d’actifs pour obtenir des données de capteur d’actifs actuelles générées par un ou plusieurs capteurs sur l’actif. Le système peut donc comprendre en outre un dispositif télématique installé sur le (ou chaque) actif au sein du parc d’actifs. Dans de tels modes de réalisation, le dispositif télématique peut obtenir les données de capteur d’actifs directement à partir des un ou plusieurs capteurs, ou le dispositif télématique peut obtenir le dispositif de capteur d’actifs à partir d’un ordinateur d’actifs, installé sur l’actif ou sur chaque actif, qui obtient les données de capteur d’actifs à partir des un ou plusieurs capteurs. En variante, dans certains modes de réalisation, le dispositif serveur peut obtenir les données de capteur d’actifs à partir d’un ordinateur d’actifs, installé sur l’actif ou sur chaque actif, qui obtient les données de capteur d’actifs à partir des un ou plusieurs capteurs - c’est-à-dire sans avoir besoin d’un dispositif télématique séparé. Un dispositif télématique tel que divulgué ici sera entendu comme comportant au moins les composants électroniques nécessaires pour activer une fonction télématique. Le dispositif télématique comporte un émetteur-récepteur sans fil agencé pour communiquer avec le dispositif serveur. Comme la présente invention concerne un système d’identification de défauts probables d’un actif au sein d’un parc d’actifs, par exemple pour la gestion de parc, les actifs peuvent se déplacer indépendamment les uns des autres et le dispositif serveur est nécessairement éloigné des actifs. Dans divers modes de réalisation, le dispositif télématique peut comprendre un capteur d’emplacement, tel qu’un récepteur GPS (ou tout autre récepteur de système mondial de navigation par satellite (GNSS), ou un dispositif de localisation équivalent), et un processeur agencé pour obtenir des données d’emplacement sur la base de mesures du capteur d’emplacement. D’autres composants électroniques, tels qu’un capteur d’accélération ou une unité de mesure inertielle, peuvent éventuellement être inclus dans le dispositif télématique. Dans les modes de réalisation dans lesquels un dispositif télématique est installé sur l’actif ou sur chaque actif au sein du parc d’actifs, on comprendra que le dispositif télématique peut fonctionner indépendamment de l’unité de commande de moteur de véhicule (ECU) pour obtenir les données de capteur d’actifs à partir des un ou plusieurs capteurs. Dans certains modes de réalisation, le dispositif télématique est un dispositif mobile installé sur l’actif. Dans certains autres modes de réalisation, le dispositif télématique est un dispositif fixe installé sur l’actif, par exemple branché sur un port de diagnostic embarqué (OBD) (par exemple lorsque l’actif est un véhicule). Le dispositif fixe peut comporter des moyens de montage mécaniques et/ou électriques (par exemple pour se connecter à l’alimentation à partir d’une batterie embarquée). Le fait que le dispositif télématique soit un dispositif fixe signifie qu’il n’est pas destiné à être régulièrement retiré et transporté par un utilisateur sous la forme d’un dispositif mobile, cependant le dispositif fixe peut toujours être installable et retirable plutôt que d’être un élément permanent de l’actif. En d’autres termes, le dispositif télématique peut être fabriqué par un tiers et installé sur un actif ultérieurement à sa fabrication, par exemple dans le cadre d’un système de gestion de parc. Le dispositif télématique se distingue donc des systèmes informatiques de données embarqués installés par le fabricant de l’actif (par exemple un véhicule). Dans divers exemples, le dispositif télématique peut être l’un des dispositifs de suivi LINK disponibles auprès de Webfleet Solutions B.V. On comprendra qu’à l’aide de ce système, des défauts probables potentiels sont identifiés à l’aide de modèles reconnus dans les données historiques d’un parc d’actifs, les données historiques comprenant à la fois des données de capteur d’actifs acquises à partir de capteurs sur les actifs du parc, et des données de rapport d’inspection détaillant les défauts qui ont été signalés par les utilisateurs dans le passé. Les défauts probables sont des défauts potentiels qui justifient une inspection pour confirmer si oui ou non un défaut réel est présent. À l’aide de ce système, les défauts qui pourraient autrement être manqués par un inspecteur humain, tel qu’un utilisateur remplissant une liste de contrôle des actifs, peuvent être identifiés, améliorant ainsi la sécurité. De plus, étant donné que le système indique les défauts probables à l’utilisateur, l’utilisateur peut concentrer son temps d’inspection sur les éléments de liste de contrôle qui sont indiqués comme susceptibles d’être défectueux, lui permettant ainsi d’utiliser son temps limité plus efficacement, en économisant du temps sans compromettre la sécurité. De préférence, l’algorithme est entraîné à identifier des corrélations dans les données historiques. Dans divers modes de réalisation, l’algorithme est entraîné à reconnaître des corrélations dans les données historiques provenant de modèles détectés dans les données de capteur d’actifs historiques et/ou les données de rapport d’inspection historiques. Dans certains modes de réalisation, l’algorithme est entraîné à rechercher des corrélations entre des points de données dans les données de capteur d’actifs historiques et des points de données dans les données de rapport d’inspection historiques. L’algorithme peut donc détecter lorsque certaines données de capteur d’actifs (telles qu’une lecture de capteur de pneu d’un véhicule) ont tendance à se produire en même temps que certaines données de rapport d’inspection (telles qu’un dysfonctionnement de la direction du véhicule). Dans certains modes de réalisation, en plus ou en variante, l’algorithme est entraîné à rechercher des corrélations dans les données de rapport d’inspection historiques elles-mêmes. Par exemple, lors de la recherche de corrélations, l’algorithme peut être entraîné à reconnaître simultanément des éléments de liste de contrôle qui sont fréquemment signalés comme défectueux par un utilisateur. Dans des modes de réalisation, l’algorithme peut être entraîné à rechercher uniquement l’un des deux types de corrélations discutés ci-dessus. Par exemple, l’algorithme peut être entraîné uniquement à rechercher des corrélations entre des données de capteur d’actifs historiques et des données de rapport d’inspection historiques, ou l’algorithme peut être entraîné uniquement à rechercher des corrélations dans les données de rapport d’inspection historiques. Dans un ensemble de modes de réalisation, l’indication affichée d’un défaut probable sur la borne de sortie d’utilisateur peut être sous la forme d’une icône d’alerte sur un élément de liste de contrôle, ou peut être sous la forme d’une notification écrite. Dans un ensemble de modes de réalisation, l’indication affichée d’un défaut probable sur la borne de sortie d’utilisateur peut être sous la forme d’un élément de liste de contrôle prioritaire (par exemple pour les données de rapport d’inspection). La borne de sortie d’utilisateur peut décider elle-même comment afficher l’indication d’un défaut probable. Cependant, comme décrit plus en détail ci-dessous, il peut être préférable que la borne de sortie d’utilisateur soit munie d’un modèle d’affichage approprié par le dispositif serveur. Dans certains modes de réalisation, chaque dispositif d’entrée d’utilisateur comprend une borne de sortie d’utilisateur. Dans certains modes de réalisation, le dispositif d’entrée d’utilisateur associé à l’actif donné comprend ladite borne de sortie d’utilisateur associée à l’actif donné. Le dispositif d’entrée d’utilisateur peut être un dispositif personnalisé, en variante, le dispositif d’entrée d’utilisateur peut être un téléphone intelligent avec une application installée sur celui-ci. Dans certains modes de réalisation, l’utilisateur peut se voir présenter une liste de contrôle prédéfinie (par exemple un modèle) pour les données de rapport d’inspection qui peut être créée sur la base de la législation et/ou de la politique d’entreprise. La liste de contrôle peut être ordonnée de n’importe quelle manière appropriée, par exemple, la liste de contrôle peut simplement être ordonnée par ordre alphabétique. La liste de contrôle prédéfinie peut en outre être basée sur des données de capteur d’actifs actuelles, et sur les corrélations reconnues à partir des données de capteur d’actifs historiques et des données de rapport d’inspection historiques. Une telle liste de contrôle prédéfinie peut être présentée à un utilisateur au niveau de la borne de sortie d’utilisateur avant que l’utilisateur n’ait commencé à effectuer une inspection d’actif, étant donné qu’aucune donnée de rapport d’inspection actuelle n’a été collectée à ce stade. Chaque élément de liste de contrôle peut être considéré comme une action suggérée, l’action suggérée étant d’effectuer une inspection du composant d’actif correspondant à l’élément de liste de contrôle. La liste de contrôle pour les données de rapport d’inspection peut être une liste de contrôle prioritaire, les éléments de liste de contrôle concernant les défauts les plus probables et/ou les plus graves étant présentés en premier. La liste de contrôle prédéfinie peut être mise à jour avec de nouveaux éléments de liste de contrôle lorsque l’utilisateur entre des données de rapport d’inspection actuelles, par exemple si l’algorithme détermine un nouveau défaut probable sur la base des données de rapport d’inspection actuelles, un élément de liste de contrôle correspondant au défaut probable peut être ajouté à la liste de contrôle. Cette mise à jour de la liste de contrôle affichée pour les données de rapport d’inspection peut avoir lieu localement au niveau du dispositif d’entrée d’utilisateur. Cependant, il peut être préférable que le dispositif d’entrée d’utilisateur requière relativement peu de capacité de traitement et repose à la place sur le dispositif serveur pour mettre à jour la liste de contrôle affichée pour les données de rapport d’inspection. Dans divers modes de réalisation, le dispositif serveur est configuré pour : sélectionner un modèle d’affichage à partir d’une mémoire du dispositif serveur sur la base desdits un ou plusieurs défauts probables et envoyer le modèle d’affichage à la borne de sortie d’utilisateur, le modèle d’affichage donnant la priorité à l’affichage d’un ou de plusieurs éléments de liste de contrôle dans les données de rapport d’inspection en fonction desdits un ou plusieurs défauts probables. Cela signifie que les défauts probables ne sont pas directement indiqués mais plutôt utilisés pour informer la sélection d’un modèle d’affichage approprié pour les données de rapport d’inspection. Étant donné que le modèle d’affichage donne la priorité à certains éléments de liste de contrôle dans les données de rapport d’inspection, un utilisateur est amené à donner la priorité à l’entrée des données de rapport d’inspection les plus pertinentes en se concentrant sur ces éléments de liste de contrôle. Même si l’utilisateur perd sa concentration ou ne parvient pas à remplir un rapport d’inspection, il est toujours probable que la saisie de données pour les éléments de liste de contrôle prioritaires détecte les défauts probables. Le système est donc suffisamment intelligent pour compenser la mauvaise saisie par l’utilisateur des données de rapport d’inspection actuelles. De plus ou en variante, dans des modes de réalisation, le modèle donne la priorité à un ou plusieurs éléments de liste de contrôle en fonction de la gravité desdits un ou plusieurs défauts probables. Selon un second aspect de la présente invention, il est proposé un système d’aide à l’inspection d’actifs au sein d’un parc d’actifs, le système comprenant : un ou plusieurs capteurs configurés pour détecter des données de capteur d’actifs du parc d’actifs ; un ou plusieurs dispositifs d’entrée/sortie d’utilisateur associés à ladite pluralité d’actifs configurés pour recevoir des données de rapport d’inspection du parc d’actifs ; et un dispositif serveur, dans lequel le dispositif serveur est configuré pour : collecter des données historiques comprenant : des données de capteur d’actifs historiques générées par les un ou plusieurs capteurs sur le parc d’actifs ; et des données de rapport d’inspection historiques à partir des un ou plusieurs dispositifs d’entrée d’utilisateur associés au parc d’actifs ; utiliser un algorithme pour identifier les corrélations dans les données historiques ; obtenir des données de capteur d’actifs actuelles à partir des un ou de plusieurs capteurs sur un actif donné au sein du parc d’actifs et/ou obtenir des données de rapport d’inspection actuelles à partir d’un dispositif d’entrée d’utilisateur associé à un actif donné au sein du parc d’actifs ; calculer un ou plusieurs défauts probables qui peuvent être présents sur l’actif donné sur la base des corrélations identifiées dans les données historiques, et sur la base des données de capteur d’actifs actuelles et/ou des données de rapport d’inspection actuelles ; et sélectionner un modèle d’affichage à partir d’une mémoire du dispositif serveur sur la base desdits un ou plusieurs défauts probables et envoyer le modèle d’affichage au dispositif d’entrée/sortie d’utilisateur associé à l’actif donné, le modèle d’affichage donnant la priorité à l’affichage d’un ou de plusieurs éléments de liste de contrôle dans les données de rapport d’inspection en fonction desdits un ou plusieurs défauts probables. Comme décrit ci-dessus, cela signifie que le modèle d’affichage reçu au niveau du dispositif d’entrée/sortie d’utilisateur peut être sélectionné pour donner la priorité intelligemment à un ou plusieurs éléments de liste de contrôle pour les données de rapport d’inspection sur la base des défauts probables calculés. De préférence, le dispositif d’entrée/sortie d’utilisateur est configuré pour utiliser le modèle d’affichage sélectionné lorsque les données de rapport d’inspection actuelles sont saisies. Le modèle d’affichage peut être mis à jour par le dispositif serveur envoyant un modèle d’affichage de remplacement sur la base des données de rapport d’inspection actuelles et/ou des données de capteur d’actifs actuelles reçues. Dans certains exemples, le modèle d’affichage est mis à jour dynamiquement par le dispositif serveur lorsque de nouvelles données de rapport d’inspection actuelles sont reçues. Dans certains exemples, en plus ou en variante, le modèle d’affichage est mis à jour dynamiquement par le dispositif serveur lorsque de nouvelles données de capteur d’actifs actuelles sont reçues. Les modèles d’affichage stockés dans la mémoire du dispositif serveur peuvent être mis à jour par l’algorithme, par exemple périodiquement ou en continu, sur la base des corrélations identifiées dans les données historiques et/ou sur la base des données de rapport d’inspection actuelles. Par exemple, cela signifie qu’un modèle standard peut être mis à jour au fil du temps pour refléter les données de rapport d’inspection collectées sur le terrain pour un parc d’actifs donné. Dans certains modes de réalisation, le dispositif serveur est configuré pour calculer une action suggérée sur la base desdits un ou plusieurs défauts probables, et envoyer l’action suggérée à la borne de sortie d’utilisateur associée à l’actif sur la base desdits un ou plusieurs défauts probables. La borne de sortie d’utilisateur est configurée pour afficher l’action suggérée. Une action suggérée peut être une instruction de vérifier l’état d’un composant d’actif ou de prendre des lectures de capteur supplémentaires. Les actions suggérées peuvent également être des instructions de prendre des mesures plus immédiates telles que la planification de l’entretien ou de la maintenance, ou une instruction de ne pas utiliser l’actif. Dans un ensemble de modes de réalisation, le dispositif serveur est configuré pour calculer une liste prioritaire d’actions suggérées à fournir à la borne de sortie d’utilisateur sur la base desdits un ou plusieurs défauts probables. Une telle liste prioritaire peut être présentée à l’utilisateur une action suggérée à la fois, les actions ayant la priorité la plus élevée étant présentées en premier. En variante, les actions suggérées prioritaires peuvent être présentées ensemble dans une liste ordonnée. L’ordre de priorité peut être décidé par exemple en fonction de la gravité du défaut probable. Par exemple, si un défaut rendait l’actif inutilisable, ou par exemple, si un défaut avec un véhicule rendait le véhicule inapte à la circulation, alors ce défaut serait présenté en premier, tandis qu’un défaut mineur qui pourrait nécessiter un entretien futur mais ne cause pas de problème immédiat serait présenté plus tard. Dans d’autres modes de réalisation, les actions suggérées peuvent être présentées sous la forme d’une liste prioritaire, par exemple sur la base d’un modèle sélectionné. La liste d’actions suggérées prioritaires peut être mise à jour lorsque l’utilisateur saisit des données de rapport d’inspection actuelles, par exemple si l’algorithme détermine un nouveau défaut probable sur la base des données de rapport d’inspection actuelles et/ou des données de capteur d’actifs actuelles. Dans un ensemble de modes de réalisation, l’action suggérée consiste pour l’utilisateur à inspecter un ou plusieurs composants sur l’actif et à mettre à jour les données de rapport d’inspection actuelles au niveau du dispositif d’entrée d’utilisateur. Dans des modes de réalisation où une indication d’un défaut probable a été fournie au niveau de la borne de sortie d’utilisateur, le système peut demander (par exemple via la borne de sortie d’utilisateur) que l’utilisateur inspecte le défaut probable indiqué, et qu’une confirmation que ledit défaut probable a été inspecté soit donnée au dispositif d’entrée d’utilisateur. Dans un ensemble préféré de modes de réalisation, le dispositif d’entrée d’utilisateur comprend la borne de sortie d’utilisateur. Dans des modes de réalisation, un ou plusieurs des capteurs est un capteur intelligent, et le dispositif serveur est configuré pour ordonner à un capteur intelligent associé à un composant d’actif lié à un défaut probable de fournir (par exemple automatiquement) des données de capteur au dispositif serveur pour vérifier l’état actuel du composant d’actif. Le parc d’actifs peut être un parc de véhicules du même type et/ou appartenant au même exploitant de parc, tel qu’un parc de camions lourds exploité par une société de transport. En variante, la pluralité d’actifs peut être constituée d’actifs à partir d’une pluralité de parcs différents, par exemple exploités par différentes sociétés. Par exemple, les utilisateurs de la présente invention peuvent regrouper les données historiques de leurs actifs en un ensemble de données historiques unique. Dans un ensemble de modes de réalisation où les actifs sont des véhicules, la pluralité de véhicules sont tous du même type de véhicule. Le type de véhicule peut être défini par exemple en termes de catégories telles que des motos, des voitures, des camionnettes, des minibus, des autobus, des camions ultralégers, des camions très légers, des camions légers, des camions moyens, des camions lourds et des camions tout-terrain. Limiter la pluralité de véhicules à un seul type de véhicule peut augmenter l’efficacité du processus de formation et conduire à des prédictions de défauts plus précises. Dans certains modes de réalisation, les données historiques peuvent être collectées à partir d’une pluralité de véhicules du même type mais de constructeurs de véhicules différents. L’algorithme peut reconnaître des corrélations dans les données historiques qui sont indépendantes du constructeur du véhicule. Les données de capteur d’actifs peuvent comprendre des données sous n’importe quelle forme appropriée qui sont collectées par des capteurs à bord de l’actif. Ces capteurs peuvent faire partie intégrante de l’actif ou être contenus à l’intérieur d’un dispositif télématique séparé porté par l’actif. Cependant, dans un ensemble de modes de réalisation, les données de capteur d’actifs comprennent des codes d’anomalie de diagnostic (DTC) tels que spécifiés par un ou plusieurs fabricants d’actifs pour identifier les défauts d’actifs. Les données de rapport d’inspection peuvent comprendre des données sous n’importe quelle forme appropriée qui sont collectées auprès des utilisateurs de l’actif. Dans un ensemble préféré de modes de réalisation, les données de rapport d’inspection comprennent des réponses saisies par l’utilisateur tout en remplissant une liste de contrôle d’inspection d’actifs comme décrit ci-dessus. Dans un ensemble de modes de réalisation, le dispositif serveur est configuré pour regrouper les données de capteur d’actifs selon un composant d’actif auquel les données de capteur d’actifs se rapportent. Dans des modes de réalisation où les données de capteur d’actifs comprennent des DTC, le regroupement peut comprendre le regroupement de DTC selon le composant d’actif auquel le DTC se rapporte. En outre, dans des modes de réalisation, le dispositif serveur est configuré pour regrouper les données de rapport d’inspection selon un composant d’actif auquel les données de rapport d’inspection se rapportent. Dans des modes de réalisation où les données de rapport d’inspection comprennent une réponse de liste de contrôle, le regroupement peut comprendre le regroupement d’éléments de liste de contrôle selon le composant d’actif auquel l’élément de liste de contrôle se rapporte. Dans des modes de réalisation, à la fois les données de rapport d’inspection et les données de capteur d’actifs sont regroupées selon le composant d’actif auquel les données se rapportent, en variante, uniquement les unes parmi les données de rapport d’inspection ou les données de capteur d’actifs peuvent être regroupées comme discuté ci-dessus. En outre, l’étape de regroupement peut s’appliquer uniquement aux données historiques, mais dans un ensemble de modes de réalisation préféré, à la fois les données historiques (capteur d’actifs, rapport d’inspection ou les deux) et les données actuelles (capteur d’actifs, rapport d’inspection ou les deux) sont regroupées comme discuté ci-dessus. Dans des modes de réalisation, la confirmation demandée comprend la fourniture par l’utilisateur d’une autre entrée, au niveau du dispositif d’entrée d’utilisateur, vérifiant l’état actuel d’un composant d’actif lié au défaut probable. Ces entrées supplémentaires peuvent comprendre la prise d’une photographie du composant d’actif et son téléchargement sur le dispositif d’entrée d’utilisateur. Cette photographie peut alors être examinée automatiquement, ou être envoyée, par le serveur, à un exploitant de parc qui peut examiner la photographie. En variante, l’utilisateur peut être invité à prendre une lecture manuelle d’un capteur ou d’une jauge relative au composant d’actif, comme une lecture de pression des pneus ou une lecture de jauge de profondeur de bande de roulement, et à entrer la lecture au niveau du dispositif d’entrée d’utilisateur. Dans des modes de réalisation, la lecture d’un capteur ou d’une jauge relative au composant d’actif peut être prise automatiquement au moyen de capteurs intelligents transférant des données directement au dispositif d’entrée d’utilisateur. De tels modes de réalisation peuvent supprimer la nécessité pour l’utilisateur d’effectuer une lecture manuelle pour vérifier l’état actuel d’un composant d’actif lié à un défaut probable, ce qui peut faire gagner du temps. Il est en outre envisagé que l’utilisateur puisse être invité à scanner un code d’identification, tel qu’un code QR ou un code RFID, qui est présent sur ou à proximité du composant d’actif pour confirmer que l’utilisateur a visité l’emplacement du composant d’actif pour effectuer un contrôle. Dans des modes de réalisation, par exemple dans des modes de réalisation où le dispositif d’entrée d’utilisateur est un téléphone intelligent, il peut être possible pour l’utilisateur d’effectuer un tel scan directement avec le dispositif d’entrée d’utilisateur. Dans un ensemble de modes de réalisation préféré, le dispositif serveur est configuré pour ajouter des données de capteur d’actifs actuelles et des données de rapport d’inspection actuelles aux données historiques ; et pour entraîner l’algorithme à reconnaître des corrélations dans les données historiques ajoutées de sorte que l’algorithme continue d’apprendre à reconnaître des corrélations dans les données historiques. Les données de rapport d’inspection actuelles qui sont ajoutées aux données historiques englobent les données de rapport d’inspection qui ont été entrées à la fois avant et après que des indications et/ou des actions suggérées concernant des défauts probables ont été données. Par exemple, lorsque l’actif est un véhicule et que l’utilisateur de l’actif est un conducteur du véhicule, un rapport d’inspection de direction défectueuse peut être entré, ce qui incite l’algorithme à indiquer qu’il y a probablement un défaut avec les pneus et à suggérer que les pneus sont contrôlés. Lors du contrôle des pneus, le conducteur entrera s’ils étaient défectueux ou non, et donc pour que l’algorithme continue à apprendre efficacement, à la fois les données de rapport de direction (avant indication) et les données de rapport de pneus (après indication) doivent être ajoutées aux données de rapport d’inspection historiques. Dans des modes de réalisation dans lesquels un modèle d’affichage est sélectionné sur la base des un ou plusieurs défauts probables identifiés, les modèles stockés dans la mémoire du dispositif serveur peuvent être mis à jour par l’algorithme sur la base de corrélations reconnues dans les données historiques ajoutées. Le modèle d’affichage peut donc évoluer pour donner la priorité aux éléments de liste de contrôle qui se sont révélés avoir la plus grande corrélation aux défauts probables en fonction des données historiques ajoutées. Selon un autre aspect de la présente invention, il est proposé un serveur destiné à être utilisé dans un système d’identification de défauts probables avec un actif au sein d’un parc d’actifs, le serveur étant configuré pour : collecter des données historiques, les données historiques comprenant : des données de capteur d’actifs historiques à partir d’un ou de plusieurs capteurs sur la pluralité d’actifs ; et des données de rapport d’inspection historiques à partir d’un ou de plusieurs dispositifs d’entrée d’utilisateur associés à la pluralité d’actifs ; entraîner un algorithme à reconnaître des corrélations dans les données historiques ; obtenir des données de capteur d’actifs actuelles à partir d’un actif au sein du parc d’actifs et des données de rapport d’inspection actuelles à partir d’un dispositif d’entrée d’utilisateur associé à un actif au sein du parc d’actifs ; calculer, à l’aide de l’algorithme, un ou plusieurs défauts probables qui peuvent être présents sur l’actif sur la base des corrélations dans les données historiques, et sur la base des données de capteur d’actifs actuelles et/ou des données de rapport d’inspection actuelles. Comme mentionné ci-dessus, il est préférable que le serveur soit configuré pour obtenir des données de capteur d’actifs actuelles à partir d’un dispositif télématique installé sur l’actif ou sur chaque actif au sein du parc d’actifs. Dans de tels modes de réalisation, le serveur est configuré pour être en communication sans fil avec un dispositif télématique installé sur l’actif ou sur chaque actif au sein du parc d’actifs. Il sera bien sûr apprécié que le terme « serveur » tel qu’il est utilisé ici signifie un ordinateur ou une machine (par exemple, un dispositif serveur) connecté à un réseau de sorte que le serveur envoie et/ou reçoit des données d’autres dispositifs (par exemple, des ordinateurs ou d’autres machines) sur ce réseau. De plus ou en variante, le serveur peut fournir des ressources et/ou des services à d’autres dispositifs sur le réseau. Le réseau peut être Internet ou un autre réseau approprié. Le serveur peut être incorporé dans n’importe quel type de serveur ou dispositif serveur approprié, par exemple un serveur de fichier, un serveur d’application, un serveur de communication, un serveur informatique, un serveur Web, un serveur proxy, etc. Le serveur peut être un dispositif informatique unique ou peut être un système distribué, c’est-à-dire que la fonctionnalité du serveur peut être répartie sur une pluralité de dispositifs informatiques. Par exemple, le serveur peut être un serveur basé sur le cloud, c’est-à-dire que ses fonctions peuvent être réparties sur de nombreux ordinateurs « à la demande ». Dans de tels agencements, les ressources de serveur peuvent être acquises à partir d’un ou de plusieurs centres de données, qui peuvent être situés à différents emplacements physiques. On comprendra ainsi que les processus décrits ci-dessus qui sont exécutés par le serveur, peuvent être exécutés par un dispositif informatique unique, c’est-à-dire un serveur unique, ou par plusieurs dispositifs informatiques séparés, c’est-à-dire plusieurs serveurs. Par exemple, tous les processus peuvent être exécutés par un serveur unique qui a accès à toutes les informations pertinentes nécessaires. Les un ou plusieurs capteurs peuvent comprendre un ou plusieurs capteurs qui font partie intégrante de l’actif, et/ou un ou plusieurs capteurs contenus à l’intérieur d’un dispositif télématique porté par l’actif. Dans divers modes de réalisation, l’appareil de détection peut comprendre l’un des dispositifs de suivi LINK disponibles auprès de Webfleet Solutions B.V. Selon un autre aspect de l’invention, il est fourni un procédé mis en œuvre par ordinateur d’identification de défauts probables avec un actif au sein d’un parc d’actifs, le procédé comprenant : la collecte, par un dispositif serveur, de données historiques, les données historiques comprenant : des données de capteur d’actifs historiques d’un ou de plusieurs capteurs sur le parc d’actifs ; et des données de rapport d’inspection historiques d’un ou de plusieurs dispositifs d’entrée d’utilisateur associés au parc d’actifs ; l’obtention de données de capteur d’actifs actuelles à l’aide d’un ou de plusieurs capteurs sur un actif donné au sein du parc d’actifs et/ou la collecte de données de rapport d’inspection actuelles à l’aide d’un dispositif d’entrée d’utilisateur associé à un actif donné au sein du parc d’actifs ; le calcul, à l’aide d’un algorithme sur le dispositif serveur, d’un ou de plusieurs défauts probables qui peuvent être présents sur l’actif donné sur la base de corrélations dans les données historiques, et sur la base des données de capteur d’actifs actuelles et/ou des données de rapport d’inspection actuelles ; et la fourniture d’une indication desdits un ou plusieurs défauts probables au niveau d’une borne de sortie d’utilisateur associée à l’actif donné. On comprendra que cet aspect peut comporter (de préférence) une ou plusieurs parmi (par exemple toutes) les caractéristiques préférées et éventuelles décrites ici, par exemple concernant d’autres aspects et modes de réalisation de l’invention, selon le cas. Par exemple, le procédé peut comprendre en outre l’entraînement, par le dispositif serveur, de l’algorithme à reconnaître des corrélations dans les données historiques. Par exemple, le procédé peut comprendre en outre l’affichage d’une indication desdits un ou plusieurs défauts probables au niveau de la borne de sortie d’utilisateur associée à l’actif donné. On comprendra que dans chacun des modes de réalisation discutés ci-dessus, la référence aux données de capteur d’actifs actuelles et aux données de rapport d’inspection actuelles est destinée à signifier des données qui se rapportent à l’actif sur lequel des défauts sont actuellement identifiés, et qui peuvent être collectées en temps réel. On comprendra en outre que les données qui sont collectées en temps réel n’ont pas nécessairement besoin d’être envoyées en temps réel, par exemple envoyées du dispositif d’entrée d’utilisateur au serveur, ou des un ou plusieurs capteurs sur l’actif au serveur. Par exemple, les données de rapport d’inspection actuelles peuvent être envoyées dès qu’elles sont entrées au niveau du dispositif d’entrée d’utilisateur, ou elles peuvent être envoyées uniquement une fois qu’une liste de contrôle a été complétée. Il sera entendu que les données associées à l’actif en cours d’évaluation seront toujours classées comme données actuelles, même s’il y a un délai entre la collecte des données et leur envoi au serveur. Dans l’un quelconque des aspects et modes de réalisation divulgués ici, les actifs peuvent être des actifs mobiliers, tels que des véhicules ou des actifs destinés à être couplés à des véhicules (par exemple des camions, des voitures, des remorques, des caravanes, etc.), ou des actifs non mobiliers tels que des machines. Dans divers modes de réalisation, les actifs sont tous enregistrés dans un serveur distant en tant que partie du même parc. Comme mentionné ci-dessus, un actif appartenant à un parc peut être distingué de tout autre actif (par exemple un véhicule ou une machine) en y installant un dispositif télématique. Un actif destiné à être couplé à un véhicule peut ne pas comporter son propre dispositif télématique mais être en communication avec le dispositif télématique du véhicule. Dans chacun des modes de réalisation discutés ci-dessus, les actifs peuvent être des véhicules et les utilisateurs desdits actifs peuvent être des conducteurs des véhicules. L’invention concerne l’identification de défauts probables d’un véhicule au sein d’un parc de véhicules comprenant des véhicules à moteur à combustion interne, des véhicules hybrides et/ou des véhicules électriques. Un ou plusieurs exemples non limitatifs vont maintenant être décrits, à titre d’exemple uniquement, et en référence aux figures annexées dans lesquelles : est une vue d’ensemble schématique d’un système pour déterminer des défauts probables avec un véhicule selon un mode de réalisation de la présente invention ; est un organigramme illustrant un procédé de détermination de défauts probables avec un véhicule selon un mode de réalisation de la présente invention ; est une vue d’ensemble d’un procédé d’entraînement d’un algorithme d’apprentissage automatique à déterminer des défauts probables avec un véhicule selon un mode de réalisation de la présente invention ; est une vue d’ensemble d’un procédé d’obtention de données de rapport d’inspection mises à jour ; montre une liste de contrôle affichée sur un dispositif d’entrée de conducteur ; montre un écran d’entrée présenté sur un dispositif d’entrée de conducteur ; montre un menu de type de défaut présenté sur un dispositif d’entrée de conducteur ; montre un gros plan d’une icône du menu de la ; montre un écran d’entrée tel qu’illustré à la qui a été complété par un conducteur ; montre une liste de contrôle telle qu’illustrée à la , mais avec un exemple d’indication d’un défaut probable affiché ; et montre un message qui peut être fourni au conducteur au niveau de la borne de sortie de conducteur. Description détaillée des modes de réalisation préférés Dans le mode de réalisation illustré, l’actif est un véhicule 1 parmi une pluralité de véhicules 1. L’utilisateur de l’actif est un conducteur du véhicule 1. La est une vue d’ensemble schématique montrant un système 2 pour identifier des défauts probables avec un véhicule 1, et fournir une indication de ces défauts à un conducteur. Le véhicule 1 porte un dispositif télématique 3 qui peut comprendre des capteurs pour générer des données relatives au véhicule 1. Par exemple, le dispositif télématique 3 peut comprendre un capteur d’emplacement, par exemple un capteur GPS, configuré pour générer des données de position relatives à la conduite du véhicule 1. Le véhicule 1 comprend également une pluralité de capteurs 5 qui sont configurés pour générer des données relatives à l’état des composants de véhicule. La pluralité de capteurs 5 peuvent comprendre, par exemple, des capteurs de pression des pneus, des capteurs de température de moteur, des capteurs de pression d’huile, etc. Le dispositif télématique 3 et la pluralité de capteurs 5 sont configurés pour générer des données de capteur d’actifs actuelles qui, dans le mode de réalisation illustré, sont des données de capteur de véhicule actuelles 6b et sont capables de transmettre des données de capteur de véhicule actuelles 6b à un serveur 7, soit directement, soit via un dispositif de communication séparé (non représenté). Dans l’application actuelle, des données de capteur de véhicule sont définies comme des données de capteur qui contiennent des détails sur un véhicule, qui peuvent comporter l’emplacement, la vitesse, le temps de ralenti, une accélération ou un freinage brusque, la consommation de carburant et des informations de défaut de véhicule telles que les codes d’anomalie de diagnostic (DTC). Les données de capteur de véhicule sont générées par un ou plusieurs capteurs qui peuvent être connectés à un bus de données et de signaux de véhicule tel qu’un bus de réseau de zone de contrôleur (CAN). Comme illustré, le serveur 7 est situé à distance et à l’extérieur du véhicule 1. Le dispositif télématique 3 peut être tout dispositif capable de collecter des données de capteur de véhicule. Par exemple, il peut s’agir d’un dispositif mobile, par exemple un téléphone portable ou une tablette, porté par un conducteur du véhicule 1. Alternativement, le dispositif télématique 3 peut être un dispositif connecté au véhicule 1 ou faisant partie intégrante de celui-ci. Par exemple, le dispositif télématique 3 peut être connecté à un port de diagnostic embarqué (OBD) du véhicule 1. Le dispositif télématique 3 peut être temporairement, ou définitivement, installé sur le véhicule 1. Dans certains exemples, le dispositif télématique 3 peut comprendre l’un des dispositifs de suivi LINK disponibles auprès de Webfleet Solutions B.V. La pluralité de capteurs 5 peut faire partie intégrante du véhicule 1. Le serveur 7 comprend un processeur 9 et une mémoire 11 qui stockent un produit informatique comprenant des instructions exécutables par ordinateur pour effectuer au moins une partie d’un procédé de calcul de défauts probables avec le véhicule 1. Le processeur 9 peut comprendre un ou plusieurs dispositifs de traitement, par exemple plusieurs dispositifs de traitement agencés en série ou en parallèle. Le procédé d’identification de défauts probables avec le véhicule 1 est représenté sur la et décrit plus en détail ci-dessous. Le serveur 7 peut comprendre un support lisible par ordinateur sur lequel est stocké un algorithme. Le système 2 comprend en outre un dispositif d’entrée d’utilisateur associé à l’actif, qui à son tour comprend une borne de sortie d’utilisateur. Dans le mode de réalisation illustré, le dispositif d’entrée d’utilisateur est un dispositif d’entrée de conducteur 13 associé au véhicule 1, qui à son tour comprend une borne de sortie de conducteur 15. La borne de sortie de conducteur 15 est utilisée pour fournir des indications de défauts probables calculés à un conducteur, ainsi que des actions recommandées. Le dispositif d’entrée de conducteur 13 est configuré pour accepter des entrées du conducteur telles que des données de rapport d’inspection actuelles 14b concernant le véhicule 1 et est capable de transmettre des données de rapport d’inspection actuelles 14b, ainsi que d’autres données d’entrée, au serveur 7, soit directement, soit via un dispositif de communication séparé (non représenté). Le dispositif d’entrée de conducteur 13 peut être distant du serveur 7, et peut être le téléphone intelligent d’un conducteur. Bien que le dispositif d’entrée de conducteur 13 soit représenté ici comme un dispositif séparé du dispositif télématique 3, un dispositif combiné peut être prévu. Le système comprend en outre une pluralité d’actifs qui, dans le mode de réalisation illustré, est un parc de véhicules 8, ayant une pluralité de dispositifs télématiques 12 qui peuvent eux-mêmes comprendre chacun des capteurs pour générer des données relatives au parc de véhicules 8. Par exemple, la pluralité de dispositifs télématiques 12 peuvent comprendre chacun un capteur d’emplacement, par exemple un capteur GPS, configuré pour générer des données de position relatives à la conduite de chaque véhicule 1 du parc de véhicules 8. Chaque véhicule 1 dans le parc de véhicules 8 comprend également une pluralité de capteurs 10, qui sont configurés pour générer des données sur l’ensemble du parc concernant l’état d’un ou de plusieurs composants de véhicule. Les pluralités de capteurs 10 peuvent comprendre, par exemple, des capteurs de pression des pneus, des capteurs de température de moteur, des capteurs de pression d’huile, etc. Les dispositifs télématiques 12 et les pluralités de capteurs 10 sont configurés pour générer des données de capteur d’actifs historiques (qui, dans le mode de réalisation illustré, sont des données de capteur de véhicule historiques) 6a. Dans cet exemple, les dispositifs télématiques 12 sont capables de transmettre sans fil les données de capteur de véhicule historiques 6a au serveur 7. Le système comprend en outre une pluralité de dispositifs d’entrée d’utilisateur associés à la pluralité d’actifs, qui dans le mode de réalisation illustré sont une pluralité de dispositifs d’entrée de conducteur 16 associés au parc de véhicules 8, configurés pour accepter des entrées de conducteurs telles que des données de rapport d’inspection historiques 14a sur le parc de véhicules 8. La pluralité de dispositifs d’entrée de conducteur 16 sont capables de transmettre des données de rapport d’inspection historiques 14a, ainsi que d’autres données d’entrée, au serveur 7, soit directement soit via un dispositif de communication séparé (non représenté). Le système 2 comprend également une borne de sortie d’exploitant de parc 17 qui est utilisée pour fournir des indications de défauts à un exploitant de parc, lui permettant de prendre des décisions concernant le contrôle technique du véhicule 1 ou de programmer une maintenance. Le serveur 7 est configuré pour recevoir des données de rapport d’inspection actuelles 14b, ainsi que d’autres données d’entrée, du dispositif d’entrée de conducteur 13, et pour envoyer les données reçues à la borne de sortie d’exploitant de parc 17. Les données envoyées à la borne de sortie d’exploitant de parc 17 peuvent comprendre des données de rapport d’inspection actuelles 14b, des notes de conducteur supplémentaires, des photographies et/ou des lectures de capteur. On comprendra que le véhicule 1 peut être inclus dans le parc de véhicules 8, et/ou que le dispositif d’entrée de conducteur 13 associé au véhicule 1 peut être inclus dans la pluralité de dispositifs d’entrée de conducteur 16. La pluralité de capteurs 10 sur le parc de véhicules 8 transmettent des données de capteur de véhicule historiques 6a au même serveur distant 7, et la pluralité de dispositifs d’entrée de conducteur 16 associés au parc de véhicules 8 transmettent des données de rapport d’inspection historiques 14a au même serveur distant 7. Un tel système 2 est donc utilisé pour calculer des défauts probables avec un véhicule 1 sur la base de données de capteur de véhicule historiques 6a et de données de rapport d’inspection historiques 14a à partir de plusieurs véhicules dans un parc. Dans le mode de réalisation illustré, La est un organigramme illustrant un procédé 20 d’identification de défauts probables avec le véhicule 1. Le procédé 20 peut par exemple être exécuté par le système 2 décrit ci-dessus, par exemple il peut être partiellement exécuté par le serveur 7, par exemple par le processeur 9 du serveur 7. À l’étape 22, des données historiques sont collectées à partir du parc de véhicules 8, qui peut être une pluralité de véhicules 1 dans un parc. Les données historiques comprennent des données de capteur de véhicule historiques 6a obtenues à partir du parc de véhicules 8, par exemple via les dispositifs télématiques 12 et/ou directement à partir des pluralités de capteurs 10, et des données de rapport d’inspection historiques 14a obtenues à partir de la pluralité de dispositifs d’entrée de conducteur 16. À l’étape 24, l’algorithme est entraîné sur les données historiques à l’aide de techniques d’apprentissage automatique connues telles que celles décrites dans Collaborative Deep Learning for Recommender Systems by Wang et al (https://arxiv.org/pdf/1409.2944.pdf) pour reconnaître des corrélations dans les données historiques. La illustre un procédé d’apprentissage 33 moyennant quoi l’algorithme est entraîné à l’aide de données historiques qui comprennent des données de capteur de véhicule historiques 6a obtenues à partir des dispositifs télématiques 12 et/ou des pluralités de capteurs 10 sur le parc de véhicules 8, et des données de rapport d’inspection historiques 14a obtenues à partir de la pluralité de dispositifs d’entrée de conducteur 16 associés au parc de véhicules 8. L’ensemble de données doivent être d’une taille significative et collectées sur une période significative pour être considérées comme des données historiques. Par exemple, un ensemble approprié de données historiques peuvent être collectées à partir d’un parc de 20 véhicules sur une période de 6 mois. Alternativement, un ensemble approprié de données historiques peuvent être collectées à partir d’un parc de 10 véhicules sur une période de 12 mois. Les données historiques peuvent contenir des données associées à des véhicules d’un type commun, éventuellement d’un fabricant commun, ou d’un modèle commun. Une liste non exhaustive de types de véhicules peut comporter : des motos, des voitures, des camionnettes, des minibus, des autobus, des camions ultralégers, des camions très légers, des camions légers, des camions moyens, des camions lourds et des camions tout-terrain. Dans certains exemples, il peut être avantageux de limiter les données historiques auxquelles l’algorithme est exposé à un seul type de véhicule, constructeur et/ou modèle afin de s’assurer que les défauts probables calculés sont aussi pertinents et aussi précis que possible. L’inconvénient d’une telle limitation est la réduction de la taille de l’ensemble de données historiques car davantage de limites sont imposées sur les propriétés de la pluralité de véhicules 1. Pour les utilisateurs qui disposent d’un parc de véhicules suffisamment important pour fournir un ensemble de données historiques utilisables, les données historiques peuvent comprendre uniquement des données de leur parc de véhicules. En variante, lorsqu’un utilisateur ne possède pas un grand parc de véhicules, l’ensemble de données historiques peuvent comprendre des données associées à des véhicules d’une pluralité de parcs différents. Dans le mode de réalisation illustré, l’algorithme est entraîné à rechercher deux types de corrélations. À l’étape 37, l’algorithme est entraîné à rechercher des corrélations entre des données de capteur de véhicule historiques 6a et des données de rapport d’inspection historiques 14a. Les données de capteur de véhicule historiques 6a peuvent être sous la forme de codes d’anomalie de diagnostic (DTC), communément appelés « codes d’anomalie ». Ces codes d’anomalie peuvent être générés par les capteurs 10 ou signalés directement par les intégrations OEM. Les données de rapport d’inspection historiques 14a peuvent être sous la forme de réponses de liste de contrôle soumises par les conducteurs. Ainsi, lors de la recherche de corrélations, à l’étape 37, l’algorithme peut être entraîné à reconnaître quels DTC sont fréquemment présents lorsque des éléments de liste de contrôle spécifiques sont signalés comme défectueux par un conducteur. Dans le cadre de l’entraînement à reconnaître quels DTC sont fréquemment présents avec des éléments de liste de contrôle spécifiques, l’algorithme est muni d’une matrice de mappage pour regrouper les DTC en fonction des composants de véhicule spécifiques auxquels le DTC se rapporte. Cette matrice de mappage peut être prédéfinie et statique, ou la matrice de mappage peut être adaptable (par exemple, sur la base de la logique floue, de certaines règles basées sur la probabilité, d’algorithmes d’apprentissage, etc.). Le tableau 1 ci-dessous montre un exemple de regroupement des DTC selon les composants de véhicule auxquels ils se rapportent selon une matrice de mappage. On comprendra qu’un « composant de véhicule » peut être tout composant physique intervenant dans le fonctionnement du véhicule, qu’il soit distinct (par exemple les pneus) ou réparti (par exemple le liquide de refroidissement et l’huile moteur). Codes d’anomalie signalés par le dispositif LINK (peuvent être lus depuis OBD ou CAN) Composant de véhicule correspondant / élément de liste de contrôle Codes d’anomalie liés à l’échappement P2463 : Restriction du filtre à particules - Banque d’accumulation de suie 1 P246C : Restriction du filtre à particules - Banque d’alimentation limitée forcée 1 509 Dépassement NOx P2BAC - Désactivation d’EGR 890 P0420 : Efficacité du système catalytique inférieure au seuil (Banque 1) P0430 : Efficacité du système catalytique inférieure au seuil (Banque 2) Échappement P0700 : Dysfonctionnement du système de contrôle de transmission P0702 : Système de contrôle de transmission électrique Moteur/Embrayage P00B7 Flux de liquide de refroidissement moteur faible/performances Liquide de refroidissement moteur P0195 Dysfonctionnement du capteur de température d’huile moteur P0196 Plage/Performances du capteur de température d’huile moteur P0197 Capteur de température d’huile moteur bas P0198 Capteur de température d’huile moteur élevé Huile moteur P0460 Dysfonctionnement du circuit de capteur de niveau de carburant P0461 Plage/Performances du circuit du capteur de niveau de carburant P0462 Entrée basse du circuit de capteur de niveau de carburant P0463 Entrée élevée du circuit de capteur de niveau de carburant P0464 Intermittence du circuit du capteur de niveau de carburant Niveau de carburant BS, 1094, Différents pneus (circonférence) montés sur un essieu Mesure d’accéléromètre inattendue depuis les essieux Pneus Connexion électrique défectueuse P0562 OBD-II : Code d’anomalie de diagnostic de faible tension de système (DTC) P0561 – Tension de système – instable P0560 - Dysfonctionnement de la tension de système P0563 – Tension de système - élevée Temps de recharge inattendus Câble de recharge défectueux Batterie / Circuit électrique En outre, une approche similaire d’une matrice de mappage peut être appliquée aux données de rapport d’inspection historiques 14a. Dans des modes de réalisation où les données de rapport d’inspection historiques 14a se présentent sous la forme de réponses de liste de contrôle, les éléments de liste de contrôle sont généralement regroupés selon les composants de véhicule spécifiques auxquels ils se rapportent. Ces regroupements peuvent rationaliser le processus d’entraînement. Une fois les regroupements appliqués aux données de capteur de véhicule historiques 6a et/ou aux données de rapport d’inspection historiques 14a, on laisse l’algorithme s’entraîner à rechercher des corrélations entre les deux ensembles de données 6a, 14a. Dans ce premier type de corrélation (étape 37), l’algorithme est entraîné à reconnaître quels éléments de liste de contrôle sont fréquemment signalés avec certains DTC. Un exemple de ce premier type de corrélation, donné ci-dessous, est une corrélation reconnue entre le DTC « BS, 7300, Le modulateur d’essieu de l’essieu arrière est défectueux » et l’élément de liste de contrôle « Pneus ». Un autre exemple de ce premier type de corrélation est une corrélation étant reconnue entre un code d’anomalie relatif à une chute de tension à une connexion de circuit électrique particulière ou à l’absence de signal électrique, et un composant de véhicule donné sur la liste de contrôle. Exemple d’éléments de liste de contrôle Composants de véhicule externes Pneus Échappement Pare-brise Phares Contrôles quotidiens du véhicule Freins Niveau de carburant Moteur/embrayage Direction Contrôles hebdomadaires du véhicule Huile moteur Liquide de refroidissement moteur Liquide de frein Liquide de direction assistée Batterie / circuit électrique De plus, ou en variante, à l’étape 39, l’algorithme est entraîné à rechercher des corrélations dans les données de rapport d’inspection historiques 14a elles-mêmes. Ainsi, lors de la recherche de ce second type de corrélations, à l’étape 39, l’algorithme peut être entraîné à reconnaître simultanément des éléments de liste de contrôle qui sont fréquemment signalés comme défectueux par un conducteur. Un exemple de ce second type de corrélation, donné ci-dessous, est une corrélation reconnue entre les éléments de liste de contrôle « Pneus » et « Direction ». En se référant à nouveau à la , à l’étape 26, les données de capteur de véhicule actuelles 6b sont obtenues à partir du véhicule 1. Dans la présente demande, les données de capteur de véhicule actuelles 6b sont définies comme discuté ci-dessus. Ces données de capteur de véhicule actuelles 6a peuvent comprendre une liste de codes d’anomalie de diagnostic (DTC). Les données de capteur de véhicule actuelles 6a peuvent être obtenues à partir de l’un ou des deux du dispositif télématique 3 et de la pluralité de capteurs 5. À l’étape 28, l’algorithme calcule s’il existe des défauts probables qui peuvent être présents sur le véhicule 1 sur la base des données de capteur de véhicule actuelles 6b. L’algorithme est capable de faire ce calcul sur la base de l’entraînement de corrélation effectué sur les données historiques à l’étape 37 du procédé de formation de la . En variante ou en plus, à l’étape 30, les données de rapport d’inspection actuelles 14b sont obtenues à partir du dispositif d’entrée de conducteur 13 associé au véhicule 1. Ces données de rapport d’inspection actuelles 14b peuvent comprendre des réponses de liste de contrôle soumises par un conducteur au niveau du dispositif d’entrée de conducteur 13. À l’étape 32, l’algorithme détermine s’il existe des défauts probables qui peuvent être présents sur le véhicule 1 sur la base des données de rapport d’inspection actuelles 14b. L’algorithme est capable d’effectuer ce calcul sur la base de l’entraînement de corrélation effectué sur les données de rapport d’inspection historiques à l’étape 37 et/ou à l’étape 39 du procédé d’entraînement 35 de la . Si l’algorithme n’identifie aucun défaut probable, alors aucune action concernant l’indication de défauts n’est donnée. Si des défauts probables sont identifiés dans l’une ou les deux étapes 28 et 32, alors une indication est fournie et/ou une action suggérée est fournie à l’étape 33, par exemple une indication au niveau de la borne de sortie de conducteur 15. Dans certains exemples, le procédé 20 peut comprendre l’obtention de données de capteur de véhicule actuelles 6b à partir d’un véhicule 1 à l’étape 26, et le fait de calculer s’il existe des défauts probables qui peuvent être présents sur la base des données de capteur de véhicule actuelles 6b à l’étape 28, mais ne comprend pas l’obtention de données de rapport d’inspection actuelles 14b à partir d’un dispositif d’entrée de conducteur 13 associé au véhicule 1 à l’étape 30, ou le fait de calculer s’il existe des défauts probables qui peuvent être présents sur la base des données de rapport d’inspection actuelles 14b à l’étape 32. Cela peut se produire dans des situations avant que le conducteur ait commencé à effectuer une inspection du véhicule, et n’a donc pas encore entré de données de rapport d’inspection actuelles 14b au niveau du dispositif d’entrée de conducteur 13. Dans d’autres exemples, le procédé 20 peut comprendre l’obtention de données de rapport d’inspection actuelles 14b à partir d’un dispositif d’entrée de conducteur 13 associé au véhicule 1 à l’étape 30, et le fait de calculer s’il existe des défauts probables qui peuvent être présents sur la base des données de rapport d’inspection actuelles 14b à l’étape 32, mais ne comprend pas l’obtention de données de capteur de véhicule actuelles 6b à partir d’un véhicule 1 à l’étape 26, ou le fait de calculer s’il existe des défauts probables qui peuvent être présents sur la base des données de capteur de véhicule actuelles 6b à l’étape 28. Dans certains exemples, le procédé 20 peut comprendre l’obtention de données de capteur de véhicule actuelles 6b à partir d’un véhicule 1 à l’étape 26, et le fait de calculer s’il existe des défauts probables qui peuvent être présents sur la base des données de capteur de véhicule actuelles 6b à l’étape 28, et comprend également l’obtention de données de rapport d’inspection actuelles 14b à partir d’un dispositif d’entrée de conducteur 13 associé au véhicule 1 à l’étape 30, et le fait de calculer s’il existe des défauts probables qui peuvent être présents sur la base des données de rapport d’inspection actuelles 14b à l’étape 32. Dans divers exemples, les défauts probables sont des éléments de liste de contrôle (par exemple tels que définis par les exigences légales locales), et l’action suggérée consiste à effectuer un contrôle du composant de véhicule lié à l’élément de liste de contrôle. Le procédé 20 va maintenant être expliqué plus en détail au moyen de deux exemples. Un premier exemple suit les étapes 22→24→26→28→33. À l’étape 22, les données historiques sont collectées comme discuté ci-dessus. À l’étape 24, l’algorithme est entraîné à reconnaître des corrélations dans les données historiques, y compris des corrélations entre les données de capteur de véhicule historiques 6a et les données de rapport d’inspection historiques 14a. Dans un exemple de ce premier type de corrélation, les données de capteur de véhicule historiques 6a se présentent sous la forme de DTC, et les données de rapport d’inspection historiques 14a se présentent sous la forme d’entrées de liste de contrôle. Dans cette étape de formation, l’algorithme reconnaît une corrélation entre le DTC « BS, 7300, Le modulateur d’essieu de l’essieu arrière est défectueux » et un rapport d’inspection d’un défaut avec les pneus. Cette corrélation est susceptible d’être présente car le modulateur d’essieu module la pression de freinage des roues sur l’essieu, et donc si le modulateur d’essieu est défectueux, les roues peuvent être freinées de manière inégale, provoquant une usure inégale des pneus. À l’étape 26, les données de capteur de véhicule actuelles 6b sont obtenues à partir du véhicule 1, et le DTC « BS, 7300, Le modulateur d’essieu de l’essieu arrière est défectueux » est présent dans les données de capteur de véhicule actuelles 6b. Par conséquent, à l’étape 28, l’algorithme identifie qu’il existe un défaut probable avec les pneus sur la base du DTC qui est présent dans les données de capteur de véhicule actuelles 6b. À l’étape 33, une indication est fournie au conducteur au niveau de la borne de sortie de conducteur 15 qu’il y a un défaut probable avec les pneus, et une action suggérée est fournie qui, dans cet exemple, consiste à effectuer une inspection des pneus. Un second exemple suit les étapes 22→24→30→32→33. À l’étape 22, les données historiques sont collectées comme discuté ci-dessus. À l’étape 24, l’algorithme est entraîné à reconnaître des corrélations dans les données historiques, y compris des corrélations dans les données de rapport d’inspection historiques 14a. Dans un exemple de ce second type de corrélation, les données de rapport d’inspection historiques 14a se présentent sous la forme d’entrées de liste de contrôle. Dans cette étape d’apprentissage 24, l’algorithme reconnaît une corrélation entre une entrée de liste de contrôle d’un défaut avec la direction, et une entrée de liste de contrôle d’un défaut avec les pneus. Cette corrélation peut être présente parce que des pneus avant sous-gonflés peuvent rendre la direction lourde, ou un gonflage irrégulier entre les pneus avant peut entraîner une traction de la direction vers la gauche/droite. À l’étape 30, des données de rapport d’inspection actuelles 14b sont obtenues à partir du véhicule 1, et une entrée de liste de contrôle signalant un défaut avec la direction est présente dans les données de rapport d’inspection actuelles 14b. Par conséquent, à l’étape 32, l’algorithme identifie qu’il existe un défaut probable avec les pneus sur la base de l’entrée de liste de contrôle qui est présente dans les données de rapport d’inspection actuelles 14b. À l’étape 33, une indication est fournie au conducteur au niveau de la borne de sortie de conducteur 15 qu’il y a un défaut probable avec les pneus, et une action suggérée est fournie qui, dans cet exemple, consiste à effectuer une inspection des pneus. La montre des étapes de procédé associées à l’indication de défauts probables à un conducteur, et à l’apprentissage continu de l’algorithme. À l’étape 41, des indications des défauts probables et des actions suggérées résultantes sont fournies au conducteur au niveau de la borne de sortie de conducteur 15. À l’étape 43, la borne de sortie de conducteur 15 est configurée pour demander que le conducteur mette à jour les données de rapport d’inspection actuelles 14b sur la base des actions suggérées. Si la borne de sortie de conducteur 15 a indiqué au conducteur qu’il y a probablement un défaut avec un composant de véhicule, et a suggéré l’action d’effectuer un contrôle sur le composant de véhicule, la borne de sortie de conducteur 15 demandera que le conducteur confirme qu’il a effectué un contrôle sur le composant, et mette à jour les données de rapport d’inspection actuelles 14b pour confirmer si oui ou non un défaut a été identifié par le conducteur. Cette confirmation peut être fournie au moyen d’une case à cocher et/ou le conducteur peut être tenu de fournir une signature pour confirmer qu’il a effectué l’inspection. En outre, dans des modes de réalisation, il peut être demandé que le conducteur télécharge une photographie du composant de véhicule contrôlé sur le dispositif d’entrée de conducteur. Dans des modes de réalisation, un code d’identification (tel qu’un code QR) peut être présent sur ou à proximité du composant de véhicule que le conducteur devra scanner avec le dispositif d’entrée de conducteur 13 pour confirmer qu’il a contrôlé le composant de véhicule. En outre, il est envisagé qu’il puisse être demandé au conducteur d’effectuer une lecture manuelle d’un capteur ou d’une jauge associée à l’élément de liste de contrôle pour vérifier si un défaut est présent ou non. Dans de tels modes de réalisation, il peut être nécessaire que le conducteur prenne une lecture à partir d’un capteur ou d’une jauge et entre manuellement la lecture dans le dispositif d’entrée de conducteur 13. De plus ou en variante, lorsqu’il y a des capteurs intelligents connectés installés sur le véhicule 1, par exemple des capteurs de système intelligent de surveillance de la pression des pneus (TPMS), il peut être possible pour le dispositif serveur de demander automatiquement d’autres lectures des capteurs intelligents. Par exemple, lorsqu’un capteur intelligent est associé à un composant de véhicule lié à un défaut probable, le dispositif serveur peut demander des lectures supplémentaires à partir de ce capteur afin de vérifier si un défaut existe ou non pour ce composant de véhicule. Alternativement, il peut être nécessaire que le conducteur effectue une lecture directement à partir du capteur intelligent à l’aide du dispositif d’entrée de conducteur 13, par exemple en initiant une connexion sans fil entre le dispositif d’entrée de conducteur 13 et le capteur intelligent. À l’étape 45, les données de rapport d’inspection actuelles mises à jour 14b, qui indiqueront si oui ou non le défaut probable indiqué correspondait à un défaut réel qui a été identifié par le conducteur, sont envoyées au serveur 7 qui ajoute les données aux données historiques. Les données de capteur de véhicule actuelles 6b sont également ajoutées aux données historiques par le serveur 7. En tant que tel, l’algorithme peut continuer à apprendre à partir des données de rapport d’inspection actuelles mises à jour 14b qui sont entrées par le conducteur en réponse aux actions suggérées, suggérées par l’algorithme. Dans des modes de réalisation, les données de rapport d’inspection actuelles mises à jour 14b et/ou les données de capteur de véhicule actuelles 6b sont regroupées à l’aide d’une matrice de mappage, comme discuté ci-dessus, avant d’être ajoutées aux données historiques. La illustre une liste de contrôle présentée à un conducteur sur la borne de sortie de conducteur 15. Dans le mode de réalisation illustré, un téléphone intelligent 50 fournit à la fois le dispositif d’entrée de conducteur 13 et la borne de sortie de conducteur 15, et la liste de contrôle est fournie au conducteur au moyen d’une application qui est installée sur le téléphone intelligent 50. La illustre un écran d’entrée présenté au conducteur sur le téléphone intelligent 50. Cet écran d’entrée permet au conducteur de mettre à jour les données de rapport d’inspection actuelles 14b, soit dans le cadre d’un contrôle légal régulier, soit en réponse à une action suggérée pour effectuer une inspection d’un composant de véhicule et mettre à jour les données de rapport d’inspection actuelles 14b. Trois options sont présentées au conducteur, une icône « Sans objet » 61 qui peut être utilisée lorsque le contrôle n’est pas applicable, par exemple si l’élément de liste de contrôle concerne une remorque et que le véhicule actuel ne porte pas de remorque, une icône « Défaut » 63 que le conducteur utilisera pour indiquer qu’un défaut est présent avec l’élément de liste de contrôle, et une icône « OK » 65 que le conducteur utilisera pour indiquer qu’il a terminé une inspection de l’élément de liste de contrôle et qu’il n’a pas identifié de défaut. D’autres entrées sont également disponibles pour le conducteur. Si le conducteur indique qu’un défaut est présent en sélectionnant l’icône de défaut 63, alors, dans un ensemble de modes de réalisation préféré, il doit entrer le type de défaut à l’aide de la barre « Type de défaut » 67. La sélection de la barre « Type de défaut » 67 amène le conducteur à un menu « Type de défaut » 70 représenté sur la qui contient une pluralité de défauts possibles prédéfinis 71, ainsi qu’une option « Autre » 73 qui peut être utilisée lorsque le défaut présent n’est pas contenu dans les défauts possibles prédéfinis. Le conducteur doit sélectionner lequel des défauts prédéfinis 71 est présent à l’aide des cases à cocher 72, et confirmer sa sélection avec l’icône de confirmation 75. On peut voir sur la que certains des défauts prédéfinis ont une icône non en état de circuler 74. Les défauts prédéfinis marqués de cette icône 74 sont d’une gravité non apte à la circulation et conduiront à ce que le véhicule soit considéré comme non en état de circuler. La montre l’icône non en état de circuler 74 en vue rapprochée. En limitant l’entrée du conducteur (les données de rapport d’inspection) à une liste de défauts prédéfinis 71, le procédé d’identification de défauts probables est rationalisé. Si les données de rapport d’inspection se limitaient à indiquer qu’il y avait un défaut avec un élément de liste de contrôle, c’est-à-dire un défaut avec le pneu, mais ne contenaient pas d’informations sur la nature du défaut, alors les défauts probables calculés par l’algorithme seraient moins précis. De plus, si le conducteur était en mesure de fournir des détails sur le défaut sans contraintes, et que ces détails étaient ajoutés aux données de rapport d’inspection, alors le procédé 20 devrait contenir une sorte d’étape d’interprétation avant que l’algorithme puisse rechercher des corrélations relatives aux données de rapport d’inspection. En se référant à nouveau à la , des options sont fournies au conducteur pour ajouter une note relative au défaut dans une zone de saisie de note 68, et pour ajouter une image du composant de véhicule liée à l’élément de liste de contrôle à l’aide d’une option d’entrée d’image 69. Pour les raisons discutées ci-dessus, dans le mode de réalisation actuel, ces détails supplémentaires ne seront pas inclus dans les données de rapport d’inspection actuelles 14b qui sont envoyées au serveur 7 pour être ajoutées aux données historiques, mais elles peuvent être envoyées à un exploitant de parc, via le serveur 7, ou via tout autre moyen approprié, et affichées sur une borne d’exploitant de parc 17 de sorte que l’opérateur de parc peut effectuer une vérification supplémentaire, programmer la maintenance ou réserver l’entretien du véhicule si nécessaire. La montre un écran d’entrée tel qu’illustré à la qui a été rempli par un conducteur. Dans l’exemple illustré, l’élément de liste de contrôle est l’huile moteur, le conducteur a indiqué qu’il y a un défaut en sélectionnant l’icône de défaut 63, a indiqué que le type de défaut est une fuite mineure en sélectionnant l’option de fuite mineure parmi les défauts prédéfinis 71, a ajouté une note 81 pour vérifier l’étanchéité dans la zone de saisie de note 68, et a ajouté une image 83 du défaut à l’aide de l’option d’entrée d’image 69. La montre une liste de contrôle comme le montre la , mais avec un exemple d’indication d’un défaut probable donné au moyen d’une icône d’avertissement 91. L’icône d’avertissement 91 informe le conducteur qu’il existe un défaut probable calculé avec l’élément de liste de contrôle de visibilité, et le conducteur sera incité à inspecter cet élément avec soin, ou à donner la priorité à cet élément de liste de contrôle par rapport aux autres éléments de liste de contrôle. La liste de contrôle vue sur la peut être affichée selon un modèle d’affichage sélectionné au niveau du serveur 7, sur la base du ou des défauts probables calculés, et envoyée au téléphone intelligent 50. C’est le modèle d’affichage qui donne la priorité à l’affichage de l’élément de liste de contrôle « Visibilité » en première page du rapport d’inspection et ajoute l’icône d’avertissement 91. Un modèle d’affichage différent peut être sélectionné et envoyé au téléphone intelligent 50, ou le modèle d’affichage peut être mis à jour, en fonction du ou des défauts probables calculés et de leurs éléments de liste de contrôle associés. Des indications et des actions suggérées peuvent être fournies au conducteur via la borne de sortie de conducteur 15 sous différentes formes, telles que des messages qui peuvent apparaître sous forme de notifications. La montre un exemple de message 100 qui peut être fourni au conducteur au niveau de la borne de sortie de conducteur 15. Le message 100 contient une partie d’indication 101 qui fournit l’indication au conducteur, et une partie d’action suggérée 102 qui fournit l’action suggérée au conducteur. Dans le cas du message 100, ce message peut être présenté au conducteur sur la borne de sortie de conducteur 15 à l’étape 33 du second exemple discuté ci-dessus en relation avec la . Le procédé a calculé sur la base des données de rapport d’inspection actuelles 14b contenant un rapport d’un défaut avec la direction qu’il y a un défaut probable avec la pression des pneus, et donc l’action suggérée est de contrôler la pression. On peut donc voir sur la que la partie d’indication 101 du message 100 indique « cela pourrait être lié aux pneus », et la partie d’action suggérée 102 du message 100 indique « Veuillez contrôler la pression ». Dans les modes de réalisation illustrés, l’indication est donnée au conducteur sous la forme d’une icône ou dans le cadre d’un message de notification, mais l’homme du métier comprendra que l’indication pourrait être fournie de toute manière appropriée. Dans des modes de réalisation, une liste de contrôle prioritaire peut être présentée au conducteur sur la borne de sortie de conducteur 15, la liste de contrôle prioritaire ordonnant les éléments de liste de contrôle selon qu’un défaut probable a été identifié ou non avec l’élément de la liste de contrôle, et en outre selon la gravité du défaut probable. Dans un tel mode de réalisation, les éléments de liste de contrôle avec des défauts probables calculés qui aboutiraient à ce que le véhicule 1 soit jugé non en état de circuler peuvent être présentés au conducteur en premier. Des actions suggérées peuvent de même être fournies de n’importe quelle manière appropriée. Dans le mode de réalisation illustré, les données historiques sont continuellement mises à jour avec les données de rapport d’inspection actuelles mises à jour 14b obtenues à partir du dispositif d’entrée de conducteur 13. Il est envisagé que, dans des modes de réalisation, les données historiques puissent également être mises à jour avec des données liées aux actions du gestionnaire de parc, de sorte que l’algorithme peut apprendre comment le gestionnaire de parc répond aux défauts, et peut adapter ses actions suggérées en conséquence. Par exemple, si le gestionnaire de parc planifie toujours un entretien en réponse à un défaut particulier, l’algorithme peut présenter la planification d’un entretien comme l’action suggérée lorsque ce défaut est identifié et confirmé par le conducteur. En outre, dans le mode de réalisation illustré, les données historiques contiennent des données de capteur de véhicule historiques 6a et des données de rapport d’inspection historiques 14a, mais dans des modes de réalisation, il est envisagé que d’autres données puissent être présentes dans les données historiques qui peuvent être prises en compte par l’algorithme. Par exemple, l’algorithme peut prendre en compte des données à partir d’un constructeur automobile qui peuvent contenir des défauts communs avec un modèle particulier de véhicule. L’algorithme peut donc fournir une indication dudit défaut commun au conducteur, et/ou ordonner au conducteur d’accorder une attention particulière à l’élément de liste de contrôle couramment défectueux ou de le contrôler plus fréquemment. En plus ou en variante, les données peuvent comprendre des données géographiques. Par exemple, si le véhicule 1 fonctionne dans une zone où les routes sont connues pour être de mauvaise qualité, alors l’algorithme peut fournir une indication au conducteur que des défauts sont plus probables avec les pneus et la suspension, et/ou ordonner au conducteur de porter une attention particulière ou de contrôler plus fréquemment les éléments de la liste de contrôle correspondant aux pneus et à la suspension. Dans l’un quelconque des modes de réalisation décrits ci-dessus, les données de capteur de véhicule historiques 6a et les données de rapport d’inspection historiques 14a peuvent comprendre des données collectées pendant au moins 6 mois à partir d’une pluralité de véhicules constituée de 20 véhicules. L’intervalle de temps pendant lequel les données historiques sont collectées peut dépendre du nombre de véhicules dans la pluralité de véhicules, et de l’utilisation typique de la pluralité de véhicules et de la façon dont leur utilisation varie dans le temps. Alors que l’invention a été décrite en détail en relation avec seulement un nombre limité de modes de réalisation, en se concentrant sur le cas où les actifs en question sont des véhicules, il doit être facilement compris que l’invention n’est pas limitée à ces modes de réalisation divulgués, et les actifs pourraient être tout actif sur lequel il est nécessaire d’effectuer des contrôles d’utilisation. L’invention peut être modifiée pour incorporer n’importe quel nombre de variantes, altérations, substitutions ou agencements équivalents non décrits jusqu’ici, mais qui sont proportionnels à la portée de l’invention. De plus, bien que divers modes de réalisation de l’invention aient été décrits, il faut comprendre que des aspects de l’invention peuvent comporter uniquement certains des modes de réalisation décrits. En conséquence, l’invention ne doit pas être considérée comme limitée par la description précédente, mais est uniquement limitée par la portée des revendications annexées. Système (2) d’identification de défauts probables avec un actif (1) au sein d’un parc d’actifs (8), le système comprenant : - un ou plusieurs capteurs (5, 10) configurés pour détecter des données de capteur d’actifs (6b, 6a) du parc d’actifs (8) ; - un ou plusieurs dispositifs d’entrée d’utilisateur (13, 16) associés à ladite pluralité d’actifs (8) configurés pour recevoir des données de rapport d’inspection (14b, 14a) du parc d’actifs (8) ; - une ou plusieurs bornes de sortie d’utilisateur (15) associées à ladite pluralité d’actifs (8) ; et un dispositif serveur (7), dans lequel le dispositif serveur est configuré pour : collecter des données historiques comprenant : des données de capteur d’actifs historiques (6a) générées par les un ou plusieurs capteurs (10) sur le parc d’actifs (8) ; et des données de rapport d’inspection historiques (14a) à partir des un ou plusieurs dispositifs d’entrée d’utilisateur (16) associés au parc d’actifs ; utiliser un algorithme pour identifier des corrélations dans les données historiques ; obtenir des données de capteurs d’actifs actuelles (6b) à partir des un ou plusieurs capteurs (5) sur un actif donné (1) dans le parc d’actifs (8) et/ou obtenir des données de rapport d’inspection actuelles (14b) à partir d’un dispositif d’entrée d’utilisateur (13) associé à un actif (1) donné au sein du parc d’actifs (8) ; calculer un ou plusieurs défauts probables qui peuvent être présents sur l’actif donné (1) sur la base des corrélations identifiées dans les données historiques, et sur la base des données de capteur d’actifs actuelles (6b) et/ou des données de rapport d’inspection actuelles (14b) ; et envoyer lesdits un ou plusieurs défauts probables à une borne de sortie d’utilisateur (15) associé à l’actif donné (1), dans lequel ladite borne de sortie d’utilisateur (15) est configurée pour afficher une indication dudit ou desdits défauts probables. Système (2) selon la revendication 1, dans lequel le dispositif d’entrée d’utilisateur (13) associé à l’actif donné (1) comprend ladite borne de sortie d’utilisateur (15) associée à l’actif donné (1). Système (2) selon la revendication 1 ou la revendication 2, dans lequel le dispositif serveur (7) est configuré pour : sélectionner un modèle d’affichage à partir d’une mémoire (11) du dispositif serveur (7) sur la base desdits un ou plusieurs défauts probables et envoyer le modèle d’affichage à la borne de sortie d’utilisateur (15), dans lequel le modèle d’affichage donne la priorité à l’affichage d’un ou de plusieurs éléments de liste de contrôle dans les données de rapport d’inspection en fonction desdits un ou plusieurs défauts probables. Système (2) d’aide d’inspection d’actifs au sein d’un parc d’actifs (8), le système comprenant : - un ou plusieurs capteurs (10) configurés pour détecter des données de capteur d’actifs (6) du parc d’actifs ; - un ou plusieurs dispositifs d’entrée/sortie d’utilisateur (13, 16) associés à ladite pluralité d’actifs (8) configurés pour recevoir des données de rapport d’inspection (14b, 14a) du parc d’actifs (8) ; et un dispositif serveur (7), dans lequel le dispositif serveur est configuré pour : collecter des données historiques comprenant : des données de capteur d’actifs historiques (6a) générées par les un ou plusieurs capteurs (10) sur le parc d’actifs (8) ; et des données de rapport d’inspection historiques (14a) à partir desdits un ou plusieurs dispositifs d’entrée d’utilisateur (16) associés au parc d’actifs (8) ; utiliser un algorithme pour identifier des corrélations dans les données historiques ; obtenir des données de capteurs d’actifs actuelles (6b) à partir des un ou plusieurs capteurs (5) sur un actif donné (1) dans le parc d’actifs (8) et/ou obtenir des données de rapport d’inspection actuelles (14b) à partir d’un dispositif d’entrée d’utilisateur (13) associé à un actif (1) donné au sein du parc d’actifs (8) ; calculer un ou plusieurs défauts probables qui peuvent être présents sur l’actif donné (1) sur la base des corrélations identifiées dans les données historiques, et sur la base des données de capteur d’actifs actuelles (6b) et/ou des données de rapport d’inspection actuelles (14b) ; et sélectionner un modèle d’affichage dans une mémoire (11) du dispositif serveur (7) sur la base desdits un ou plusieurs défauts probables et envoyer le modèle d’affichage au dispositif d’entrée/sortie d’utilisateur (13) associé à l’actif donné (1), dans lequel le modèle d’affichage donne la priorité à l’affichage d’un ou de plusieurs éléments de liste de contrôle dans les données de rapport d’inspection en fonction desdits un ou plusieurs défauts probables. Système (2) selon la revendication 3 ou 4, dans lequel le dispositif serveur (7) est configuré pour mettre à jour dynamiquement le modèle d’affichage à mesure que de nouvelles données de rapport d’inspection actuelles (14b) et/ou données de capteur d’actifs actuelles (6b) sont reçues. Système (2) selon une quelconque revendication précédente, dans lequel le dispositif serveur (7) est configuré pour calculer une action suggérée sur la base desdits un ou plusieurs défauts probables, et envoyer l’action suggérée à la borne de sortie d’utilisateur (15), et dans lequel la borne de sortie d’utilisateur (15) est configurée pour afficher l’action suggérée. Système (2) selon la revendication 6, dans lequel le dispositif serveur (7) est en outre configuré pour calculer une liste prioritaire d’actions suggérées à fournir à la borne de sortie d’utilisateur (15) sur la base desdits un ou plusieurs défauts probables. Système (2) selon la revendication 6 ou la revendication 7, dans lequel l’action suggérée consiste pour l’utilisateur à inspecter un ou plusieurs composants sur l’actif (1) et à mettre à jour les données de rapport d’inspection actuelles (14b) au niveau du dispositif d’entrée d’utilisateur (13). Système (2) selon une quelconque revendication précédente, dans lequel un ou plusieurs des capteurs (10, 5) est un capteur intelligent, et le dispositif serveur (7) est configuré pour ordonner à un capteur intelligent associé à un composant d’actif lié à un défaut probable de fournir des données de capteur au dispositif serveur (7) afin de vérifier l’état actuel du composant d’actif. Système (2) selon une quelconque revendication précédente, dans lequel la pluralité d’actifs est une pluralité de véhicules qui sont tous du même type de véhicule. Système (2) selon une quelconque revendication précédente, dans lequel les données de capteur d’actifs comprennent des codes d’anomalie de diagnostic tels que spécifiés par un ou plusieurs fabricants d’actifs pour identifier des défauts d’actifs. Système (2) selon une quelconque revendication précédente, dans lequel le dispositif serveur (7) est configuré pour : - regrouper les données de capteur d’actifs selon un composant d’actif auquel les données de capteur d’actifs se rapportent ; et/ou - regrouper les données de rapport d’inspection en fonction d’un composant d’actif auquel les données de rapport d’inspection se rapportent. Système (2) selon une quelconque revendication précédente, dans lequel le dispositif serveur (7) est configuré pour utiliser l’algorithme pour identifier des corrélations entre des données de capteur d’actifs historiques (6a) et des données de rapport d’inspection historiques (14a). Système (2) selon une quelconque revendication précédente, dans lequel le dispositif serveur (7) est configuré pour utiliser l’algorithme pour identifier des corrélations dans les données de rapport d’inspection historiques (14a). Procédé mis en œuvre par ordinateur pour identifier des défauts probables avec un actif (1) au sein d’un parc d’actifs (8), le procédé comprenant : - la collecte, par un dispositif serveur (7), de données historiques, les données historiques comprenant : des données de capteur d’actifs historiques (6a) à partir d’un ou de plusieurs capteurs (10) sur le parc d’actifs (8) ; et des données de rapport d’inspection historiques (14a) à partir d’un ou de plusieurs dispositifs d’entrée d’utilisateur (16) associés au parc d’actifs (8) ; l’obtention de données de capteur d’actifs actuel (6b) à l’aide d’un ou de plusieurs capteurs (5) sur un actif donné (1) au sein du parc d’actifs (8) et/ou la collecte de données de rapport d’inspection actuelles (14b) à l’aide d’un dispositif d’entrée d’utilisateur (13) associé à un actif donné (1) au sein du parc d’actifs (8) ; le calcul, à l’aide d’un algorithme sur le dispositif serveur (7), d’un ou de plusieurs défauts probables qui peuvent être présents sur l’actif donné (1) sur la base de corrélations dans les données historiques, et sur la base des données de capteur d’actifs actuelles (6b) et/ou des données de rapport d’inspection actuelles (14b) ; et la fourniture d’une indication desdits un ou plusieurs défauts probables au niveau d’une borne de sortie d’utilisateur (15) associée à l’actif donné (1).