FR 3111447 A1 20211217 FR 2006274 A 20200616 L’invention concerne la gestion de versions de logiciels exécutés par des composants embarqués (ECU1, ECU2) dans un véhicule terrestre à moteur (VEH) à partir de la génération d’une empreinte informatique (FGPRNT). FIG. 1 Gestion de versions de logiciels embarqués à partir d’une empreinte informatique La présente invention appartient au domaine de l’électronique embarquée dans un véhicule terrestre à moteur. En particulier, il concerne la gestion des versions de logiciels exécutés par l’électronique embarquée. On entend par « véhicule terrestre à moteur » tout type de véhicule tel qu’un véhicule automobile, un cyclomoteur, une motocyclette, un robot de stockage dans un entrepôt, etc. Un véhicule terrestre à moteur moderne embarque de nombreux composants électroniques. Ces composants ont par exemple la charge d’activer le moteur d’une vitre électrique, d’exécuter des algorithmes d’intelligence artificielle en charge de la conduite autonome ou encore d’échanger des données avec un serveur distant. Chacun de ces composants électroniques exécute au moins un logiciel. Les formes que peuvent prendre un tel logiciel sont extrêmement variées, allant d’un niveau applicatif élevé (interface homme machine des systèmes d’infotainment) à très bas niveau (circuits électroniques numériques et analogiques pour l’exécution de commande basiques). A ce titre, dans la présente demande, on entend par « logiciel » tout ensemble de séquences d’instructions interprétables par tout composant électronique. Ainsi, la configuration matérielle d’un composant analogique (paramétrage d’une fonction de transfert par exemple) ou numérique (type FPGA par exemple), la version d’un système d’exploitation ou encore un type de chargeur d’amorçage (bootloader en anglais) sont des exemples de logiciels. D’autres exemples seront données dans la description détaillée ci-après. Il est nécessaire de pouvoir contrôler les versions de ces logiciels. En effet, un changement de version incohérent peut traduire une attaque informatique sur un composant électronique. En outre, l’organisation des campagnes de mises à jour à distance des composants électroniques implique une connaissance fine et actualisée des versions exécutées par les composants électroniques susceptibles d’être mis à jour. Ainsi, l’exécution d’une mise à jour pour un composant exécutant déjà une version correcte d’un logiciel est couteuse en bande-passante et en ressources de calcul pour le serveur distant en charge de la mise à jour et pour les composants électroniques concernés. De plus, l’exécution de ces mises à jour peut-être très contraignante dans les cas où il s’agit d’une mise à jour FOTA, Firmware Over-The-Air (micrologiciel mis à jour à distance en français), car le composant peut ne pas supporter une mise-à-jour tout en étant en fonctionnement (un redémarrage complet, très contraignant, peut s’imposer). Plusieurs facteurs complexifient la gestion des versions des logiciels, et tout particulièrement la multiplication des logiciels et des versions possibles pour ces logiciels. En effet, la multiplication des composants pouvant être mis à jour à distance (over-the-air en anglais) a pour conséquence de multiplier le nombre de versions disponibles pour ces composants. Ces composants pouvant être mis à jour à distance présentent en outre plus de vulnérabilités (attaques informatiques à distance) et doivent donc exécuter des logiciels résistants aux dernières attaques informatiques connues. Ils doivent donc être mis à jour très fréquemment. De plus, les ressources de calcul des composants étant de plus en plus importantes, les logiciels qu’ils exécutent sont de plus en plus complexes. Ainsi, les architectures logicielles comportant initialement quelques versions de quelques logiciels (premières version d’Autosar par exemple) impliquent désormais des centaines de versions pour des milliers de logiciels (architectures modernes fondées sur Linux/Unix). Actuellement, la gestion des versions de ces logiciels est faite par un inventaire à période fixe, composant par composant, voir logiciel par logiciel. La lourdeur d’un tel procédé d’inventaire implique une période relativement longue entre chaque inventaire (typiquement un mois). Les versions de tous les logiciels ne sont donc pas connues en temps réel. Ceci expose les composants à des attaques informatiques et est couteux en mise à jour inutiles. La présente invention vient améliorer la situation. A cet effet un premier aspect de l’invention concerne un procédé de gestion de versions d’un premier logiciel configuré pour être exécuté par un premier composant électronique et d’un deuxième logiciel configuré pour être exécuté par un deuxième composant électronique, le premier et le deuxième composant électronique étant compris dans un véhicule terrestre à moteur et reliés par un réseau de communication de données interne au véhicule, le premier et le deuxième logiciel étant configurés pour pouvoir être mis à jour depuis au moins un premier serveur débarqué, le procédé comportant les étapes, mises en œuvre par une unité de traitement et sur détection d’une activation d’un système électrique du véhicule, de : réception d’une première information relative à une version du premier logiciel ; réception d’une deuxième information relative une version du deuxième logiciel ; génération d’une empreinte informatique à partir des première et deuxième informations ; transmission de l’empreinte à un deuxième serveur informatique débarqué. Ainsi, dans la présente invention, à chaque activation d’un système électrique du véhicule (typiquement lors du démarrage du véhicule comme vu ci-après), une empreinte informatique des deux logiciels est envoyée au deuxième serveur. L’empreinte est donc générée, pour une pluralité de logiciel et une pluralité de composants électroniques, par une unique unité de traitement pour un envoi centralisé au deuxième serveur. Il n’est pas nécessaire de prévoir des campagnes d’inventaire, composant par composant, mais dans la transmission d’une unique empreinte informatique. Dès lors, il est possible d’effectuer cette transmission à chaque activation du système électrique et donc d’avoir une vision en temps réel des versions exécutées par les différents véhicules sous la supervision du deuxième serveur. On entend par « empreinte informatique » toute donnée (chaine de caractère, image, etc.) formalisant les première et deuxième informations. Des explications détaillées sont données ci-après dans la description détaillée. Dans un mode de réalisation, le premier serveur débarqué et le deuxième serveur débarqués sont identiques. Dans un autre mode de réalisation, ces deux servers sont distincts. Dans un mode de réalisation, l’empreinte informatique est générée à partir : des première et deuxième informations ; d’une configuration matérielle du premier et du deuxième composant ; d’une configuration d’un chargeur d’amorçage du premier et du deuxième composant ; d’une version d’un système d’exploitation du premier et du deuxième composant. Une telle combinaison correspond au meilleur compromis complexité/performance pour gérer les versions de logiciels exécutés par les composants. Dans un mode de réalisation, l’activation d’un système électrique du véhicule correspond à un démarrage du véhicule. Dans un mode de réalisation, l’activation d’un système électrique du véhicule correspond à au moins un élément parmi : • un déverrouillage d’au moins un ouvrant du véhicule ; • un allumage d’au moins un groupe motopropulseur du véhicule ; • une détection de présence d’un terminal électronique authentifié par un système d’authentification du véhicule. Ainsi, la transmission est faite lors d’une première mise à disposition d’énergie électrique dans le véhicule, maximisant ainsi les possibilités de transmission de l’empreinte. Dans un mode de réalisation, l’unité de traitement est un bloc logiciel ou un circuit électronique matériel. Dans un mode de réalisation, l’unité de traitement est comprise sur le premier composant électronique, le deuxième composant électronique ou sur un troisième composant électronique compris dans le véhicule terrestre à moteur. En particulier, dans un mode de réalisation, l’unité de traitement est comprise sur le troisième composant électronique et dans lequel le troisième composant électronique est une unité de communication télématique. Ainsi, les capacités de calcul et de transmission de l’unité de communication télématique sont avantageusement mises à profit. Dans un mode de réalisation, le procédé comportant en outre une étape de hachage de l’empreinte informatique avant la transmission au deuxième serveur. Ainsi, la transmission de l’empreinte est avantageusement sécurisée et impacte peu le traitement au niveau du deuxième serveur dans la mesure où l’étape de comparaison (détaillée ci-après) peut être faite à partir d’une base de donnée d’empreinte hachées. Un deuxième aspect de l’invention concerne un procédé de vérification d’une empreinte informatique, l’empreinte informatique correspondant à une version d’un premier logiciel configuré pour être exécuté par un premier composant électronique et à une version d’un deuxième logiciel configuré pour être exécuté par un deuxième composant électronique, le premier et le deuxième composant électronique étant compris dans un véhicule terrestre à moteur et reliés par un réseau de communication de données interne au véhicule, le premier et le deuxième logiciels étant configurés pour pouvoir être mis à jour depuis au moins un premier serveur débarqué, le procédé étant mis en œuvre par un deuxième serveur informatique et comportant les étapes de : réception de l’empreinte informatique ; comparaison de l’empreinte informatique avec une base de données comprenant une pluralité d’empreintes informatique correspondant chacune à une combinaison de versions possibles pour le premier et le deuxième logiciel ; identification d’une combinaison d’une version identifiée du premier logiciel et d’une version identifiée du deuxième logiciel à partir de la comparaison. Un troisième aspect de l’invention concerne un programme informatique comportant des instructions pour la mise en œuvre du procédé selon le premier ou de le deuxième aspect de l’invention, lorsque ces instructions sont exécutées par un processeur. Un quatrième aspect de l’invention concerne un dispositif de gestion de versions d’un premier logiciel configuré pour être exécuté par un premier composant électronique et d’un deuxième logiciel configuré pour être exécuté par un deuxième composant électronique, le premier et le deuxième composant électronique étant compris dans un véhicule terrestre à moteur et reliés par un réseau de communication de données interne au véhicule, le premier et le deuxième logiciels étant configurés pour pouvoir être mis à jour depuis au moins un premier serveur débarqué, le dispositif comportant au moins un processeur et au moins une mémoire configurés pour effectuer, sur détection d’une activation d’un système électrique du véhicule, les opérations de : réception d’une première information relative à une version du premier logiciel ; réception d’une deuxième information relative une version du deuxième logiciel ; génération d’une empreinte informatique à partir des première et deuxième informations ; transmission de l’empreinte à un deuxième serveur informatique débarqué. Un cinquième aspect de l’invention concerne un dispositif de vérification d’une empreinte informatique, l’empreinte informatique correspondant à une version d’un premier logiciel configuré pour être exécuté par un premier composant électronique et à une version d’un deuxième logiciel configuré pour être exécuté par un deuxième composant électronique, le premier et le deuxième composant électronique étant compris dans un véhicule terrestre à moteur et reliés par un réseau de communication de données interne au véhicule, le premier et le deuxième logiciels étant configurés pour pouvoir être mis à jour depuis au moins un premier serveur débarqué, le dispositif comportant au moins un processeur et au moins une mémoire pour effectuer les opérations de : réception de l’empreinte informatique ; comparaison de l’empreinte informatique avec une base de données comprenant une pluralité d’empreintes informatique correspondant chacune à une combinaison de versions possibles pour le premier et le deuxième logiciel ; identification d’une combinaison d’une version identifiée du premier logiciel et d’une version identifiée du deuxième logiciel à partir de la comparaison. Un sixième aspect de l’invention concerne un véhicule comportant le dispositif selon le quatrième aspect de l’invention. D’autres caractéristiques et avantages de l’invention apparaîtront à l’examen de la description détaillée ci-après, et des dessins annexés sur lesquels : est un schéma illustrant le contexte de l’invention selon un mode de réalisation de l’invention ; est un diagramme illustrant les étapes d’un procédé selon un mode de réalisation de l’invention ; illustre la structure d’un dispositif selon un mode de réalisation de l’invention. L’invention est décrite ci-après dans son application, non limitative, au cas d’un véhicule automobile comprenant sept composants électroniques, dont deux configurés pour pouvoir être mis à jour depuis un premier serveur débarqué. D’autres applications sont naturellement envisageables pour la présente invention. Par exemple, le procédé selon l’invention peut être mis en œuvre pour une motocyclette comprenant douze composants électroniques, tous configurés pour pouvoir être mis à jour depuis un premier serveur débarqué ou encore par une trottinette électrique comprenant deux composants électroniques, chacun configuré pour pouvoir être mis à jour depuis un premier serveur débarqué. La f igure 1 illustre un contexte d’application de l’invention, selon un mode de réalisation. Un véhicule terrestre à moteur (VEH) comprend sept composants électroniques ECU1, ECU2, ECU3, ECU4, ECU5, ECU6 et ECU7. Sur ces sept composants électroniques, les composants ECU1 et ECU2 sont configurés pour pouvoir être mis à jour depuis au moins un premier serveur débarqué (non représenté). Une empreinte informatique FGPRNT est généré par une unité de traitement pour être transmise à un deuxième serveur débarqué CLD. L’unité de traitement est ici le composant ECU3. Dans un mode de réalisation, le premier et le deuxième serveur débarqué correspondent à un même serveur débarqué. Dans ce mode de réalisation, des composants logiciels différents peuvent toutefois avoir la charge des mises à jour à distance (premier serveur) et le traitement de l’empreinte FGPRNT (deuxième serveur). Dans un autre mode de réalisation, le premier et le deuxième serveur débarqué sont distincts. Dans un mode de réalisation, les opérations effectuées par le premier et le deuxième serveur débarqué sont mises en œuvre dans l’informatique en nuage (cloud en anglais). Ainsi, par exemple selon les ressources disponibles dans différents serveurs, différentes opérations peuvent être mise en œuvre dans différents serveurs du cloud. Les composants électroniques sont reliés par un réseau de communication de données interne au véhicule. Un exemple d’un tel réseau est le bus de données CAN (Controller Area Network en anglais, pour Réseau de Contrôle de Zone en français), normalisé par la norme ISO 11898. Un autre exemple est un réseau Ethernet dédié aux communications dans le véhicule. On entend par « configuré pour être mis à jour depuis au moins un premier serveur » qu’au moins un logiciel exécuté par le composant peut-être mis à jour par téléchargement (download en anglais) et/ou téléversement (upload en anglais) depuis et/ou vers le premier serveur. Comme évoqué ci-avant, dans la présente demande, un logiciel s’entend de tout type de configuration (matérielle ou applicative) et tout type d’élément du composant. Par exemple, la mise à jour consiste à télécharger puis appliquer une nouvelle version d’un code source d’un logiciel, appliquer une configuration différente d’un transistor dont les paramètres peuvent être changés, modifier le paramétrage d’un circuit électronique programmable (FPGA par exemple), etc. Dans le mode de réalisation ici illustré à la figure 1, le premier composant électronique ECU1 comporte quatre types de logiciels exécutés par ECU1 ; Hardware, Bootloader, BasicSoftware et Dataset, exécutant respectivement les versions 123456778 (pour Hardware), 12344321 (pour Bootloader), 12349876 (pour BasicSoftware) et 12341749 (pour Dataset). D’autres logiciels peuvent être exécutées par ECU1, comme par exemple un logiciel de contrôle d’un actionneur, etc. Ces versions sont ici exprimées dans un référentiel Osek/Autosar. Dans un autre mode de réalisation, les versions sont exprimées par rapport à un référentiel unique, commun à tous les ECU du véhicule. Le deuxième composant électronique ECU2 exécute neuf types de logiciels ; Hardware, Bootloader, Hypervisor, OS1, OS2, Software1, Software2, Software3 et Software4, exécutant respectivement les versions 22345678 (pour Hardware), 22344321 (pour Bootloader), 22349876 (pour Hypervisor), 22348997 (pour OS1), 22348997 (pour OS2), 22341749 (pour Software1), 22341750 (pour Software2), 22341751 (pour Software3) et 12341752 (pour Software4). D’autres logiciels peuvent être exécutées par ECU1, comme par exemple un logiciel de contrôle d’un actionneur, etc. Ces versions sont ici exprimées dans un référentiel Linux/Unix. Dans un autre mode de réalisation, les versions sont exprimées par rapport à un référentiel unique, commun à tous les ECU du véhicule. La figure 2 est un diagramme illustrant les étapes d’un procédé selon un mode de réalisation de l’invention. En particulier, la colonne ECU3 représente les étapes effectuées au niveau de l’unité de traitement, correspondant à ECU3 dans le présent mode de réalisation. La colonne CLD correspond aux étapes effectuées au niveau du deuxième serveur informatique distant CLD. A des étapes 20 et 22, au moins une première information INF1 relative à au moins une version d’au moins un logiciel exécuté par ECU1 est reçu. Ici, ECU1, comme vu à la figure 1, ECU1 exécute 4 logiciels et 4 informations correspondantes aux versions (123456778 pour Hardware, 12344321 pour Bootloader, etc.) exécutées par ces 4 logiciels sont donc reçues. A des étapes 24 et 26, au moins une deuxième information INF2 relative à au moins une version d’au moins un logiciel exécuté par ECU2 est reçu. Ici, ECU2, comme vu à la figure 1, ECU1 exécute ç logiciels et ç informations correspondantes aux versions (22345678 pour Hardware, 22344321 pour Bootloader, etc.) exécutées par ces 9 logiciels sont donc reçues. Les premières et deuxièmes informations sont transmises par le réseau CAN du véhicule VEH. Ces transmissions peuvent être intégrées à des processus existants de cycle de vie, supervision ou encore de contrôle de version des composants électroniques du véhicule. A une étape 28, sur détection d’une activation d’un système électrique du véhicule, une empreinte informatique FGPRNT est générée à partir des premières et deuxièmes informations. L’activation d’un système électrique du véhicule correspond à au moins un élément parmi : un déverrouillage d’au moins un ouvrant du véhicule ; un allumage d’au moins un groupe motopropulseur (moteur thermique et/ou électrique) du véhicule ; une détection de présence d’un terminal électronique authentifié par un système d’authentification du véhicule. Typiquement, cela correspond au cas où un terminal (smartphone, clef main libre, etc.) du propriétaire/utilisateur du véhicule est authentifié, c’est-à-dire que le véhicule a identifié qu’une personne autorisée à utiliser le véhicule est présente (déblocage d’un véhicule partagé, déverrouillage d’un véhicule par une clef main libre, etc.). Dans un mode de réalisation, en plus de la mise en œuvre du procédé ici décrit sur détection d’une activation du système électrique du véhicule, le procédé est mis en œuvre à une période minimum prédéterminée. Par exemple, la période minimum prédéterminée est de 1 jour, 1 semaine, 2 semaines, 1 mois, 2 mois, 6 mois ou encore 1 an. Dans le détail, ECU3 peut commencer par générer une cartographie d’inventaire des versions des logiciels puis générer l’empreinte à partir de cette cartographie. La cartographie d’inventaire est un fichier reprenant tous les logiciels et toutes les versions. On entend par « empreinte informatique » toute donnée (chaine de caractère, image, etc.) formalisant les première et deuxième informations. D’autre noms pour « empreinte informatique » (fingerprint en anglais) au sens de la présente invention sont empreinte digitale d’appareil ou empreinte digitale d’ordinateur ou empreinte digitale de navigateur (en anglais device fingerprint, machine fingerprint ou browser fingerprint). Il s’agit de générer une donnée unique, selon un format particulier (par exemple une chaîne de bits), correspondant à une combinaison particulière de paramètres (ici les versions des différents logiciels). Dans un mode de réalisation, FGPRNT est hachée avant transmission, selon des procédés connus de l’homme du métier (fonctions SHA-1 ou encore MD5). Dans un mode de réalisation particulier, l’empreinte informatique est générée à partir : des première et deuxième informations (par exemple 12341749 (pour Dataset de ECU1) et 22341749 (pour Software1 de ECU2)) ; d’une configuration matérielle du premier et du deuxième composant (par exemple 12345678 (pour Hardware de ECU1) et 22345678 (pour Hardware de ECU2)) ; d’une configuration d’un chargeur d’amorçage du premier et du deuxième composant (par exemple 12344321 (pour Boatloader de ECU1) et 22344321 (pour Boatloader de ECU2)) ; d’une version d’un système d’exploitation du premier et du deuxième composant (par exemple 12349876 (pour BasicSoftware de ECU1) et 22348997 (pour OS1de ECU2)). A une étape 30, l’empreinte FGPRNT est transmise au deuxième serveur informatique débarqué CLD. En particulier, FGPRNT est transmise, via la réseau interne du véhicule, à une unité de communication télématique (TCU, pour Telematic Control Unit, unité de contrôle télématique en français) en charge des transmissions externes au véhicule, et qui transmettra FGPRNT vers le deuxième serveur informatique. Dans un mode de réalisation, ECU3 est directement l’unité de communication télématique. A une étape 32, FGPRNT est reçue par le deuxième serveur informatique CLD. A une étape 34, une comparaison de l’empreinte informatique FGPRNT avec une base de données 36 comprenant une pluralité d’empreintes informatique correspondant chacune à une combinaison de versions possibles pour le premier et le deuxième logiciel est effectuée. Dans le cas où FGPRNT a été hachée, la comparaison est faite avec une base de données d’empreinte déjà hachées. Si une combinaison d’une version identifiée du premier logiciel et d’une version identifiée du deuxième logiciel à partir de la comparaison est identifiée, les versions des logiciels exécutés par les composants du véhicule VEH sont validées à une étape 40. Cette identification peut identifier les logiciels de VEH comme conformes et/ou planifier une montée de version d’au moins un de ces logiciels. Sinon, une erreur est identifiée à une étape 38. La figure 3 représente un exemple de dispositif D compris dans le véhicule VEH. Ce dispositif D peut être utilisé en tant que dispositif centralisé en charge d’au moins certaines étapes du procédé décrit ci-avant en référence à la figure 1. Dans un mode de réalisation, il correspond par exemple au dispositif ECU3. Ce dispositif D peut prendre la forme d’un boitier comprenant des circuits imprimés, de tout type d’ordinateur ou encore d’un smartphone. Le dispositif D comprend une mémoire vive 1 pour stocker des instructions pour la mise en œuvre par un processeur 2 d’au moins une étape des procédés tels que décrits ci-avant. Le dispositif comporte aussi une mémoire de masse 3 pour le stockage de données destinées à être conservées après la mise en œuvre du procédé. Le dispositif D peut en outre comporter un processeur de signal numérique (DSP) 4. Ce DSP 4 reçoit des données pour mettre en forme, démoduler et amplifier, de façon connue en soi ces données. Le dispositif comporte également une interface d’entrée 5 pour la réception des données mises en œuvre par des procédés selon l’invention et une interface de sortie 6 pour la transmission des données mises en œuvre par les procédés. La présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d’exemples ; elle s’étend à d’autres variantes. Ainsi, il a été décrit un mode de réalisation correspondant à une architecture électronique exemplatif (sept composants électroniques, etc.) pour un véhicule automobile. La présente invention est également applicable à d’autres architectures électroniques (nombre différent de composants et/ou de logiciels, etc.). Procédé de gestion de versions d’un premier logiciel configuré pour être exécuté par un premier composant électronique (ECU1) et d’un deuxième logiciel configuré pour être exécuté par un deuxième composant électronique (ECU2), le premier et le deuxième composant électronique étant compris dans un véhicule terrestre à moteur (VEH) et reliés par un réseau de communication de données interne au véhicule, le premier et le deuxième logiciel étant configurés pour pouvoir être mis à jour depuis au moins un premier serveur débarqué, le procédé comportant les étapes, mises en œuvre par une unité de traitement et sur détection d’une activation d’un système électrique du véhicule, de : réception (22) d’une première information relative à une version du premier logiciel ; réception (26) d’une deuxième information relative une version du deuxième logiciel ; génération (28) d’une empreinte informatique à partir des première et deuxième informations ; transmission (30) de l’empreinte à un deuxième serveur informatique débarqué. Procédé selon la revendication 1, dans lequel l’empreinte informatique est générée à partir : des première et deuxième informations ; d’une configuration matérielle du premier et du deuxième composant ; d’une configuration d’un chargeur d’amorçage du premier et du deuxième composant ; d’une version d’un système d’exploitation du premier et du deuxième composant. Procédé selon l’une des revendications précédentes, dans lequel l’activation d’un système électrique du véhicule correspond à au moins un élément parmi : un déverrouillage d’au moins un ouvrant du véhicule ; un allumage d’au moins un groupe motopropulseur du véhicule ; une détection de présence d’un terminal électronique authentifié par un système d’authentification du véhicule. Procédé selon l’une des revendications précédentes, dans lequel l’unité de traitement est un bloc logiciel ou un circuit électronique matériel. Procédé selon l’une des revendications précédentes, dans lequel l’unité de traitement est comprise sur une unité de communication télématique (ECU3). Procédé selon l’une des revendications précédentes, le procédé comportant en outre une étape de : hachage de l’empreinte informatique avant la transmission au deuxième serveur. Procédé de vérification d’une empreinte informatique, l’empreinte informatique correspondant à une version d’un premier logiciel configuré pour être exécuté par un premier composant électronique (ECU1) et à une version d’un deuxième logiciel configuré pour être exécuté par un deuxième composant électronique (ECU2), le premier et le deuxième composant électronique étant compris dans un véhicule terrestre à moteur (VEH) et reliés par un réseau de communication de données interne au véhicule, le premier et le deuxième logiciel étant configurés pour pouvoir être mis à jour depuis au moins un premier serveur débarqué, le procédé étant mis en œuvre par un deuxième serveur informatique et comportant les étapes de : réception (32) de l’empreinte informatique ; comparaison (34) de l’empreinte informatique avec une base de données comprenant une pluralité d’empreintes informatique correspondant chacune à une combinaison de versions possibles pour le premier et le deuxième logiciel ; identification d’une combinaison d’une version identifiée du premier logiciel et d’une version identifiée du deuxième logiciel à partir de la comparaison. Programme informatique 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 (2). Dispositif (D) de gestion de versions d’un premier logiciel configuré pour être exécuté par un premier composant électronique (ECU1) et d’un deuxième logiciel configuré pour être exécuté par un deuxième composant électronique (ECU2), le premier et le deuxième composant électronique étant compris dans un véhicule terrestre à moteur (VEH) et reliés par un réseau de communication de données interne au véhicule, le premier et le deuxième logiciel étant configurés pour pouvoir être mis à jour depuis au moins un premier serveur débarqué, le dispositif comportant au moins un processeur et au moins une mémoire configurés pour effectuer, sur détection d’une activation d’un système électrique du véhicule, les opérations de : réception (22) d’une première information relative à une version du premier logiciel ; réception (26) d’une deuxième information relative une version du deuxième logiciel ; génération (28) d’une empreinte informatique à partir des première et deuxième informations ; transmission (30) de l’empreinte à un deuxième serveur informatique débarqué. Véhicule (VEH) configuré pour comprendre le dispositif selon la revendication 9.