FR 3160023 A1 20250912 FR 2402395 A 20240311 PROCEDE ET DISPOSITIF D’EVALUATION DE LA QUALITE D’EXECUTION APRES TRADUCTION D’UN LOGICIEL La présente invention concerne un procédé (100) d’évaluation de la qualité de l’exécution après traduction d’un logiciel par un processeur cible, comprenant la traduction (110) d’un code source (CS) du logiciel en un code machine principal au moyen d’un dispositif de traduction principal et en un code machine alternatif au moyen d’un dispositif alternatif de traduction, le code machine principal et le code machine alternatif étant exécutables par le processeur cible, le dispositif de traduction principal et le dispositif de traduction alternatif étant dissemblables ; pour au moins un cas de test prédéterminé (CT), l’exécution (120) du code machine principal et du code machine alternatif au moyen du processeur cible, pour fournir respectivement un résultat d’exécution principal et un résultat d’exécution alternatif ; et la fourniture (130) d’un indicateur (IN) de la qualité de l’exécution du logiciel par le processeur cible en fonction du résultat d’une comparaison du résultat d’exécution principal et du résultat d’exécution alternatif. Figure pour l'abrégé : 1 PROCEDE ET DISPOSITIF D’EVALUATION DE LA QUALITE D’EXECUTION APRES TRADUCTION D’UN LOGICIEL La présente invention concerne un procédé d’évaluation de la qualité de l’exécution après traduction d’un logiciel par un processeur cible, notamment d’un logiciel utilisé sur un calculateur embarqué pour des applications aéronautiques imposant un niveau de sécurité élevé. Dans les domaines de l’aéronautique et des véhicules autonomes, de nombreuses fonctions de contrôle de l’aéronef ou du véhicule sont assurées par des calculateurs embarqués. Pour les fonctions critiques, par exemple pour les commandes de vol d’un aéronef ou de freinage d’une voiture, une sûreté de fonctionnement élevée est requise. La sûreté de fonctionnement peut être caractérisée par des attributs parmi lesquels on peut citer la fiabilité, la maintenabilité la disponibilité, la sécurité-innocuité et la sécurité-confidentialité. Pour assurer ou évaluer la sûreté de fonctionnement d’un calculateur critique, quatre catégories de moyens sont mis en œuvre : l’évitement des fautes par un processus de développement rigoureux, l’élimination des fautes pendant les phases de validation, la prévision des fautes, et la tolérance aux fautes. Les techniques de tolérance aux fautes sont principalement fondées sur les principes de monitoring et de redondance. La redondance asymétrique consiste à utiliser des éléments matériels et/ou logiciels qui sont issus de deux processus de développement différents à partir des mêmes spécifications fonctionnelles. En particulier, la programmation N-autotestable repose sur l’exécution de N logiciels en parallèle et la mise en œuvre d’un algorithme de comparaison des résultats d’exécution. Dans le cas le plus simple où N=2, un calculateur dédié à une fonction système donnée est composé de deux unités matérielles de calcul différentes, de préférence ségrégées physiquement, c’est-à-dire placées dans des boîtiers distincts, par exemple accolés. La première unité est une unité de commande COM. L’unité de commande COM élabore les consignes de commande et les émet vers les dispositifs d’actionnement concernés ainsi que vers la deuxième unité, dite unité moniteur MON qui surveille l’unité de commande COM, et le cas échéant vers d’autres calculateurs assurant la même fonction. L’unité moniteur MON élabore les mêmes consignes que l’unité de commande COM mais ne fait que surveiller COM. Les résultats calculés par les deux unités COM et MON sont comparés. Si un écart qui dépasse un seuil de tolérance autorisé par les concepteurs système est observé, le calculateur perd la fonction système concernée ainsi que son MON associé, et si cela est possible, passe la main à un autre calculateur pour traiter la fonction perdue. Idéalement, les unités COM et MON reposent sur des matériels différents, des logiciels développés par des équipes différentes et dans des langages différents. Cette propriété est la dissemblance des matériels, des logiciels et des procédés et peut aussi s’appeler la dissimilarité. Toutefois, dans certains domaines et en particulier le domaine de l’aéronautique, il peut être difficile voire impossible de multiplier les systèmes d’exploitation, de sorte que des défauts de modes communs peuvent subsister. De plus, dans les domaines des fonctions critiques, il n’est à l’heure actuelle pas envisagé de profiter des options d’optimisation des dispositifs de traduction, du fait d’une augmentation du niveau de risque que ces options peuvent entraîner, notamment en raison de la présence de défauts de conception ou de programmation (en anglais « bug ») dans ces options. Un but de l’invention est alors de proposer un procédé permettant d’évaluer la qualité de l’exécution d’un logiciel donné par un processeur cible après traduction, et notamment après traduction au moyen d’un dispositif de traduction optimisé, ce procédé permettant de renforcer la sûreté de fonctionnement lorsqu’une redondance totalement dissymétrique n’est pas possible. A cet effet, l’invention a pour objet un procédé d’évaluation de la qualité de l’exécution après traduction d’un logiciel par un processeur cible, comprenant les étapes de : a) traduction d’un code source du logiciel en un code machine principal au moyen d’un dispositif de traduction principal et en un code machine alternatif au moyen d’un dispositif alternatif de traduction, le code machine principal et le code machine alternatif étant exécutables par le processeur cible, le dispositif de traduction principal et le dispositif de traduction alternatif étant dissemblables ; b) pour au moins un cas de test prédéterminé, exécution du code machine principal et du code machine alternatif au moyen du processeur cible, pour fournir respectivement un résultat d’exécution principal et un résultat d’exécution alternatif ; et c) fourniture d’un indicateur de la qualité de l’exécution du logiciel par le processeur cible en fonction du résultat d’une comparaison du résultat d’exécution principal et du résultat d’exécution alternatif. La mise en œuvre d’un dispositif de traduction alternatif dissemblable du dispositif de traduction principal permet notamment de mettre en évidence certains défauts de modes communs induits par le dispositif de traduction du code source en code machine lui-même, lorsqu’un seul et même dispositif de traduction est utilisé dans deux unités redondantes telles qu’une unité commande COM et une unité moniteur MON. Pour assurer la sûreté de fonctionnement lorsqu’un dispositif de traduction est commun à deux unités redondantes, un choix peut être de réduire au minimum les optimisations de ce dernier. Ce choix permet en effet d’avoir une bonne connaissance des défauts du dispositif de traduction et, en conséquence, de considérer que ces défauts seront observables lors de tests unitaires ou d’intégration bien choisis. Cependant, le manque d’optimisation sur le dispositif de traduction a pour conséquence que le code machine issu de la traduction n’est pas optimal. Afin de compenser la sous-optimalité du code machine à exécuter, l’utilisation d’un processeur cible plus puissant peut être rendue nécessaire. Dans le domaine de l’aéronautique, faire le choix d’un dispositif de traduction pas ou peu optimisé n’est donc pas toujours techniquement envisageable. Dans le cas où un dispositif de traduction optimisé est requis, l’invention consiste donc, de manière contre-intuitive et contraire à ce prérequis, à générer un code machine alternatif à partir d’un dispositif de traduction alternatif dissemblable du dispositif de traduction optimisé. Le dispositif de traduction alternatif peut être sous-optimal, voire non optimisé, ou encore optimisé suivant des critères différents. Quel que soit le cas, la dissemblance entre les dispositifs de traduction permet d’augmenter le niveau de confiance dans le résultat d’exécution du logiciel par le processeur cible par l’intermédiaire du code machine généré par le dispositif de traduction optimisé. Dans le cas où le dispositif de traduction est optimisé, le procédé selon l’invention permet de bénéficier des avantages de l’optimisation, par exemple en termes de réduction de la consommation du processeur cible, tout en garantissant le niveau de sécurité requis pour le cas d’espèce. Notamment, si les résultats d’exécution du logiciel par le processeur cible via le code machine principal et via le code machine alternatif sont identiques, la probabilité pour que des défauts liés au compilateur optimisé soient présents est faible. Au contraire, si ces résultats sont différents, un défaut lié au compilateur optimisé peut être suspecté et recherché. Suivant d’autres aspects avantageux de l’invention, le procédé comprend une ou plusieurs des caractéristiques suivantes, prises isolément ou suivant toutes les combinaisons techniquement possibles : - le dispositif de traduction principal et le dispositif de traduction alternatif sont des compilateurs, l’étape d’exécution étant alors postérieure à l’étape de traduction ; - le dispositif de traduction principal et le dispositif de traduction alternatif sont des interpréteurs, les étapes de traduction et d’exécution étant dans ce cas simultanées ; - le procédé comprend une étape préalable d’optimisation du dispositif de traduction principal selon au moins un critère d’optimisation ; - l’au moins un critère d’optimisation est choisi parmi un temps de traduction du code source et/ou d’exécution du code machine sur le processeur cible, un coût en mémoire du code machine et/ou une consommation énergétique du processeur cible ; - l’étape préalable i) d’optimisation comprend l’optimisation du dispositif de traduction alternatif, l’au moins un critère d’optimisation du dispositif de traduction alternatif étant différent de l’au moins un critère d’optimisation du dispositif de traduction principal ; - le procédé comprend au moins une étape préalable de test du code source comprenant au moins un test unitaire et/ou au moins un test d’intégration et/ou au moins un test fonctionnel au moyen d’au moins un cas test préalable ; - l’au moins un cas de test prédéterminé de l’étape d’exécution comprend au moins un cas de test préalable ; - l’indicateur de la qualité de l’exécution du logiciel par le processeur cible est binaire. L’invention a également pour objet un dispositif d’évaluation de la qualité de l’exécution d’un logiciel par un processeur cible comprenant les moyens de mise en œuvre du procédé selon l’un quelconque des modes de réalisation précédente. L’invention apparaîtra plus clairement à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple non limitatif, et faite en référence aux dessins dans lesquels : FIG. 1 la FIG. 1 représente un mode de réalisation du dispositif selon l’invention ; FIG. 2 la FIG. 2 représente un mode de réalisation du procédé selon l’invention sous forme de logigramme, le procédé étant mis en œuvre par le dispositif de la FIG. 1 . Le dispositif 5 d’évaluation de la qualité de l’exécution après traduction d’un logiciel par un processeur cible selon l’invention est décrit en référence à la FIG. 1 . Le logiciel est par exemple configuré pour permettre la mise en œuvre d’une fonction, notamment une fonction critique, dans un aéronef ou un véhicule terrestre (non représentés), par exemple un véhicule terrestre autonome, lorsqu’il est implémenté sur un processeur de cet aéronef ou de ce véhicule, lors d’une phase d’exploitation du logiciel. Le processeur pour la phase d’exploitation du logiciel est le processeur cible. Le logiciel est développé antérieurement à la mise en œuvre du procédé selon l’invention sur le dispositif 5, sous la forme d’un code source CS. Le code source CS comprend un ensemble d’instructions écrites dans un langage de programmation donné, sous une forme lisible par un humain. Le langage de programmation choisi n’a pas d’importance pour l’invention. A titre d’exemples illustratifs, le langage de programmation dans lequel le code source CS est rédigé est choisi parmi Python, C, ADA, ou RUST. Le dispositif 5 comprend une mémoire 10, un processeur de traduction principal 15A, un processeur de traduction alternatif 15B et un processeur d’exécution 20. La mémoire 10 est configurée pour stocker le code source CS et pour échanger des données avec le processeur de traduction principal 15A, le processeur de traduction alternatif 15B et le processeur d’exécution 20. Le processeur de traduction principal 15A peut être le processeur cible lui-même ou un autre processeur. Le processeur de traduction principal 15A, implémente un dispositif de traduction principal, configuré pour produire un code machine principal du logiciel à partir du code source CS. Le code machine principal comprend un ensemble d’instructions directement exécutable par le processeur cible et éventuellement par un ou plusieurs autres processeurs embarqués dans l’aéronef ou le véhicule terrestre. Autrement dit, le code machine principal est un fichier binaire exécutable. Le dispositif de traduction principal est donc choisi non seulement en fonction du langage de programmation dans lequel le code source CS est écrit, mais de préférence aussi en fonction des spécifications du processeur cible. Avantageusement, le dispositif de traduction principal est optimisé selon au moins un critère d’optimisation. Ce critère d’optimisation peut notamment être choisi parmi : un critère portant sur un temps d'exécution du code machine principal par le processeur cible, un critère portant sur une empreinte mémoire lors de l’exécution du code machine principal par le processeur cible, un critère portant sur une empreinte mémoire pour le stockage du code machine principal dans une mémoire du processeur cible, et/ou encore un critère portant sur une consommation d'énergie du processeur cible lors de l’exécution du code machine principal par le processeur cible. Dans un premier mode de réalisation, le dispositif de traduction principal est un compilateur. Dans ce cas, le code machine principal est généré par le dispositif de traduction principal antérieurement à une étape d’exécution de ce code machine principal. Le code machine principal peut alors être stocké dans la mémoire 10, puis exécuté ultérieurement. Si le système d’exploitation du processeur cible est le système Unix, le compilateur est par exemple choisi parmi les compilateurs de la collection de compilateurs GNU (en anglais, « GNU Compiler Collection » GCC). Dans le cas où le dispositif de traduction principal est un compilateur, un code objet peut être généré de manière intermédiaire en un langage intermédiaire tel que le langage RTL (en anglais « Register Transfer Language »). Le code objet est un intermédiaire entre le code source CS et le code machine. Alternativement, le dispositif de traduction principal est un interpréteur. Dans ce cas, le code machine est généré ligne de code source par ligne de code source, en réponse à une commande d’exécution du logiciel. Le code machine est alors exécuté au fur et à mesure sans stockage préalable dans la mémoire 10 de l’ensemble des instructions du code source CS traduites. C’est par exemple le cas si le langage de programmation du code source CS est le langage Python. Encore alternativement, le dispositif de traduction est un compilateur à la volée (en anglais : « just-in time compiler ») qui combine un compilateur « classique », tel que décrit précédemment, et un interpréteur. Le processeur de traduction alternatif 15B peut être le processeur cible, le processeur de traduction principal 15A ou un autre processeur. Le processeur de traduction alternatif 15B, implémente un dispositif de traduction alternatif, configuré pour produire un code machine alternatif du logiciel à partir du code source CS de ce logiciel. A l’instar du code machine principal, le code machine alternatif comprend un ensemble d’instructions directement exécutable par le processeur cible. Le dispositif de traduction alternatif est par ailleurs dissemblable du dispositif de traduction principal. Par le qualificatif « dissemblable », ou équivalemment « dissimilaire », on entend que le développement du dispositif de traduction alternatif et celui du dispositif de traduction principal ont impliqué au moins une spécification de développement, et/ou au moins une étape de conception (en anglais, « design »), et/ou au moins une technologie, la notion de technologie englobant le langage de programmation, et/ou au moins un être humain pour le développement d’au moins une fraction de code qui diffèrent entre les deux dispositifs de traduction . Par exemple, le dispositif de traduction alternatif et le dispositif de traduction principal peuvent avoir été développés par deux équipes de développement différentes. A titre d’exemple, le dispositif de traduction principal peut être issu de la collection GCC et le dispositif de traduction alternatif peut être issu de la collection de compilateurs LLVM (en anglais « Low Level Virtual Machine »). Alternativement ou en complément, un seul du dispositif de traduction principal et du dispositif de traduction peut être optimisé. Alternativement ou en complément, le dispositif de traduction principal et le dispositif de traduction peuvent être optimisés suivant au moins un critère d’optimisation différent. De la même façon que pour le dispositif de traduction principal, le dispositif de traduction alternatif peut être du type compilateur, interpréteur ou compilateur à la volée. Dans un mode de réalisation particulier, le dispositif de traduction principal et le dispositif de traduction alternatif sont du même type, ce type étant choisi parmi un compilateur, un interpréteur ou un compilateur à la volée. Le processeur d’exécution 20 est configuré pour recevoir le code machine principal, le code machine alternatif et au moins un cas-test CT prédéterminé stocké dans la mémoire 10. Le processeur 20 est configuré pour fournir un résultat d’exécution principal (respectivement un résultat d’exécution alternatif) à l’issue de l’exécution du code machine principal (respectivement du code machine alternatif) pour l’au moins un cas-test CT prédéterminé. Le processeur d’exécution 20 est soit le processeur sur lequel le logiciel sera implémenté pour la phase d’exploitation du logiciel, soit un processeur qui présente les mêmes caractéristiques que le processeur utilisé dans la phase d’exploitation du logiciel, par exemple un processeur correspondant à une même référence fabricant. Le dispositif 5 comprend aussi un processeur de comparaison 30, configuré pour recevoir le résultat d’exécution principal et le résultat d’exécution alternatif, comparer ces deux résultats et fournir un indicateur IN de la qualité de l’exécution du logiciel par le processeur cible en fonction du résultat de la comparaison. Le processeur de comparaison 30 peut être le processeur d’exécution 20, le processeur de traduction principal 15A ou le processeur de traduction alternatif 15B, ou encore un autre processeur. Le procédé 100 d’évaluation de la qualité de l’exécution d’un logiciel par un processeur cible au moyen du dispositif 5 est décrit en référence à la FIG. 2 . Le procédé 100 comprend une étape de traduction 110 d’un code source CS du logiciel. L’étape de traduction 110 comprend une sous-étape de traduction principale 110A pour fournir le code machine principal à partir du code source CS. La sous-étape de traduction principale 110A est mise en œuvre au moyen du processeur de traduction principal 15A. L’étape de traduction 110 comprend une sous-étape de traduction alternative 110B pour fournir le code machine alternatif à partir du code source CS. La sous-étape de traduction alternative 110B est mise en œuvre au moyen du processeur de traduction alternatif 15B. La sous-étape de traduction alternative 110B et la sous-étape de traduction principale 110A peuvent être effectuées en parallèle ou de manière successive. Du fait de la dissemblance des dispositifs de traduction principal et alternatif, le code machine principal et le code machine alternatif ont une probabilité réduite de présenter les mêmes défauts liés à la traduction. Plus les causes de dissemblance des dispositifs de traduction principal et alternatif sont nombreuses, plus cette probabilité est faible . Le procédé 100 comprend aussi une étape d’exécution 120 du code machine principal et du code machine alternatif au moyen du processeur d’exécution 20, pour fournir respectivement un résultat d’exécution principal et un résultat d’exécution alternatif à partir d’au moins un cas-test CT prédéterminé. L’étape d’exécution 120 comprend une sous-étape d’exécution principale 120A dans laquelle le processeur d’exécution 20 reçoit ledit cas-test CT et le code machine principal. Le processeur d’exécution 20 exécute alors le code machine principal généré à la sous-étape de traduction 110A pour ce cas-test CT. Le cas-test CT peut être un cas-test connu, c’est-à-dire issu d’un processus de développement informatique antérieur. A titre d’exemple, un ou plusieurs cas-tests CT peuvent être issus d’un processus de développement d’un ou plusieurs logiciels antérieur, pour lequel le niveau de criticité DAL-A de la norme DO-178C applicable au premier janvier 2012 était exigé. Alternativement ou en complément, un ou plusieurs cas-tests CT peuvent être développés ad hoc pour le procédé 100. A titre d’exemple, un cas-test CT peut être conçu spécifiquement pour activer une fonction d’optimisation du dispositif de traduction que l’on souhaite utiliser. Chaque cas-test CT comprend une fonction de test. La fonction de test peut notamment être choisie pour permettre de réaliser un test unitaire, c’est-à-dire afin de contrôler l’exécution d’une portion prédéterminée du code source CS. La fonction de test peut encore être choisie pour permettre de réaliser un test d’intégration, c’est-à-dire afin de contrôler l’exécution correcte d’une combinaison d’au moins deux portions prédéterminées du code source CS en contrôlant les éventuels états intermédiaires du processeur cible. La fonction de test peut encore être choisie pour permettre de réaliser un test fonctionnel, c’est-à-dire afin de contrôler la correction du résultat fourni à l’exécution du code source. A l’issue de la sous-étape d’exécution principale 120A, un résultat d’exécution principal est fourni par le processeur d’exécution 20. La nature particulière du résultat d’exécution principal dépend dudit cas-test CT et n’a pas d’importance pour le procédé. Le résultat d’exécution principal comprend à titre d’exemple au moins une valeur binaire et/ou au moins une valeur entière ou réelle et/ou au moins une chaîne de caractères Le résultat d’exécution principal peut comprendre un sous-résultat d’exécution pour chacun des cas-tests individuels dudit cas-test CT. Dans un mode de réalisation particulier, le résultat d’exécution est un multiplet dont les éléments sont du même type ou de types différents. L’étape d’exécution 120 comprend aussi une sous-étape d’exécution alternative 120B dans laquelle le processeur d’exécution 20 reçoit ledit cas-test CT et le code machine alternatif. Le processeur d’exécution 20 exécute alors le code machine alternatif généré à la sous-étape de traduction 110B pour ce cas-test CT. A l’issue de la sous-étape d’exécution alternative 120B, un résultat d’exécution alternatif est fourni par le processeur d’exécution 20. Le cas-test CT étant le même pour les sous-étapes d’exécution principale 120A et alternative 120B, les explications qui précèdent pour le résultat d’exécution principal sont valables mutatis mutandis pour le résultat d’exécution alternatif. La sous-étape d’exécution alternative 120B et la sous-étape d’exécution principale 120A peuvent être effectuées en parallèle ou de manière successive. Dans le cas où le dispositif de traduction principal (respectivement alternatif) est un interpréteur, la sous-étape d’exécution principale 120A (respectivement alternative 120B) est simultanée avec la sous-étape de traduction principale 110A (respectivement alternative 110B). Dans le cas où le dispositif de traduction principal (respectivement alternatif) est un compilateur, la sous-étape d’exécution principale 120A (respectivement alternative 120B) peut être effectué juste après la sous-étape de traduction principale 110A (respectivement alternative 110B), ou alternativement de manière différée. A l’issue de l’étape d’exécution 120, le procédé 100 comprend une étape de fourniture 130 de l’indicateur IN de la qualité de l’exécution du logiciel par le processeur de comparaison 30. L’étape de fourniture 130 comprend la réception du résultat d’exécution principal et du résultat d’exécution alternatif puis la comparaison de ces deux résultats par le processeur de comparaison 30. La comparaison du résultat d’exécution principal et du résultat d’exécution alternatif peut comprendre la comparaison deux à deux de l’ensemble des éléments du résultat principal et du résultat d’exécution si ces résultats comprennent plusieurs éléments. A l’issue de la comparaison du résultat d’exécution principal et du résultat d’exécution alternatif, le processeur de comparaison 30 fournit en sortie l’indicateur IN de la qualité de l’exécution du logiciel par le processeur cible. L’indicateur IN peut être binaire. Par exemple, si le résultat d’exécution alternatif et le résultat d’exécution principal ne sont pas égaux au sens informatique, c’est-à-dire compte tenu des arrondis de codage, l’indicateur IN peut prendre la valeur 0 ou FALSE. Dans le cas contraire, l’indicateur IN peut prendre la valeur 1 ou TRUE. L’indicateur IN permet ainsi d’obtenir une information sur l’impact du dispositif de traduction principal sur l’exécution du logiciel par le processeur cible . Dans la mesure où les dispositifs de traduction principal et alternatif sont dissemblables, si une erreur est introduite du fait du dispositif de traduction principal, cette erreur se manifestera avec une probabilité élevée au travers d’une différence observable entre le résultat d’exécution alternatif et le résultat d’exécution principal, pour peu que le cas-test CT soit convenablement choisi. Notamment, si le dispositif de traduction principal est optimisé, au moins un cas-test CT peut être conçu en relation avec une ou plusieurs fonctions d’optimisation utilisées. Si aucune différence n’est observée, le niveau de confiance dans l’exécution du logiciel par le processeur-cible, ou en d’autres termes la sûreté de fonctionnement, est donc renforcé grâce au procédé 100. L’indicateur IN peut aussi être composite. Notamment, il peut comprendre un ensemble de sous-indicateurs IN_i, par exemples binaires, un sous-indicateur IN_i étant associé à chacun d’une pluralité de cas-tests CT. Alternativement ou en complément, l’indicateur IN peut comprendre une probabilité P reflétant la probabilité que la différence observée soit liée au dispositif de traduction principal ou alternatif. Par exemple, si une pluralité de N cas-tests CT sont mis en œuvre, chacun associé à un sous-indicateur IN_i binaire égal à zéro en l’absence de différence observable entre le résultat d’exécution alternatif et le résultat d’exécution principal et égal à 1 dans le cas contraire, la probabilité P peut être une moyenne, éventuellement pondérée, des sous indicateurs IN_i obtenus pour les N cas-tests CT. Quelle que soit la nature de l’indicateur IN, à l’issue de l’étape de fourniture 130, il est donc possible de décider de la disqualification ou du démarrage de l’exploitation du code machine principal si le procédé 100 est mis en œuvre lors d’une phase de validation préalable à l’exploitation du logiciel. Il est aussi possible de décider du maintien ou non de l’exploitation du code machine principal si le procédé 100 est implémenté au cours de la phase d’exploitation du logiciel. Si une différence entre le résultat d’exécution alternatif et le résultat d’exécution principal est observée par le biais de l’indicateur IN, cela ne signifie pas nécessairement que cette différence est liée au dispositif de traduction principal. La différence peut en particulier aussi être une manifestation d’une erreur liée au dispositif de traduction alternatif ou encore d’une erreur liée au code source CS ou liée au processeur d’exécution 20 lui-même. Avantageusement, le procédé 100 comprend une étape préalable de test du code source CS comprenant au moins un test unitaire et/ou au moins un test d’intégration et/ou au moins un test fonctionnel au moyen d’au moins un cas test préalable. Avantageusement, au moins un cas test préalable est inclus dans l’au moins un cas de test prédéterminé CT utilisé à l’étape d’exécution 120. Alternativement ou en complément, le procédé 100 peut comprendre une étape optionnelle d’analyse 140 de l’ensemble des éléments impliqués depuis le code source CS du logiciel jusqu’à l’exécution du logiciel par le processeur d’exécution 20. Pour l’étape d’analyse 140, un processeur, par exemple le processeur de comparaison 30, reçoit l’indicateur IN et fournit une consigne de vérification prioritaire, soit du code source CS, soit du processeur-cible, soit de vérification et/ou de remplacement du dispositif de traduction principal. En particulier, chaque cas-test CT peut être conçu pour tester un ou plusieurs éléments particuliers impliqués depuis le code source CS du logiciel jusqu’à l’exécution du logiciel par le processeur d’exécution 20. Dans le cas où l’indicateur IN est composite et comprend un ensemble de sous-indicateurs IN_i, l’analyse des différents indicateurs IN_i pour lesquels une différence entre le résultat d’exécution alternatif et le résultat d’exécution principal est observée peut permettre d’élaborer automatiquement la consigne de vérification prioritaire. Procédé (100) d’évaluation de la qualité de l’exécution après traduction d’un logiciel par un processeur cible, comprenant les étapes de : a) traduction (110) d’un code source (CS) du logiciel en un code machine principal au moyen d’un dispositif de traduction principal et en un code machine alternatif au moyen d’un dispositif alternatif de traduction, le code machine principal et le code machine alternatif étant exécutables par le processeur cible, le dispositif de traduction principal et le dispositif de traduction alternatif étant dissemblables ; b) pour au moins un cas de test prédéterminé (CT), exécution (120) du code machine principal et du code machine alternatif au moyen du processeur cible, pour fournir respectivement un résultat d’exécution principal et un résultat d’exécution alternatif ; et c) fourniture (130) d’un indicateur (IN) de la qualité de l’exécution du logiciel par le processeur cible en fonction du résultat d’une comparaison du résultat d’exécution principal et du résultat d’exécution alternatif. Procédé (100) selon la revendication 1, dans lequel le dispositif de traduction principal et le dispositif de traduction alternatif sont des compilateurs, l’étape d’exécution étant alors postérieure à l’étape de traduction. Procédé (100) selon la revendication 1, dans lequel le dispositif de traduction principal et le dispositif de traduction alternatif sont des interpréteurs, les étapes de traduction et d’exécution étant dans ce cas simultanées. Procédé (100) selon l’une quelconque des revendications précédentes, comprenant une étape préalable de : i) optimisation du dispositif de traduction principal selon au moins un critère d’optimisation. Procédé (100) selon la revendication 4, dans lequel l’au moins un critère d’optimisation est choisi parmi un temps de traduction du code source et/ou d’exécution du code machine sur le processeur cible, un coût en mémoire du code machine et/ou une consommation énergétique du processeur cible. Procédé (100) selon la revendication 4 ou la revendication 5 dans lequel l’étape préalable i) d’optimisation comprend l’optimisation du dispositif de traduction alternatif, l’au moins un critère d’optimisation du dispositif de traduction alternatif étant différent de l’au moins un critère d’optimisation du dispositif de traduction principal. Procédé selon l’une quelconque des revendications précédentes, comprenant au moins une étape préalable de : ii) test du code source (CS) comprenant au moins un test unitaire et/ou au moins un test d’intégration et/ou au moins un test fonctionnel au moyen d’au moins un cas test préalable. Procédé selon la revendication 7, dans lequel l’au moins un cas de test prédéterminé (CT) de l’étape d’exécution (120) comprend au moins un cas de test préalable. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’indicateur (IN) de la qualité de l’exécution du logiciel par le processeur cible est binaire. Dispositif (5) d’évaluation de la qualité de l’exécution d’un logiciel par un processeur cible comprenant les moyens de mise en œuvre du procédé selon l’une quelconque des revendications précédentes.