Brevet FR3143785A1 — publié le 20240621

L’invention concerne un dispositif et un procédé mis en œuvre par ordinateur, d’analyse de bases de données massive de codes logiciels, comprenant des étapes consistant à recevoir (202) une famille de codes logiciels à analyser, ladite famille de codes logiciels étant un regroupement par similarités d’une pluralité de codes logiciels stockés dans une base de données massive de codes logiciels (16) ; à effectuer (204) une préparation sur les codes logiciels de la famille sélectionnée en fonction de paramètres caractérisant ladite famille de codes logiciels ; et à exécuter (206) une analyse sémantique et une analyse architecturale des codes préparés de ladite famille de codes logiciels, ladite analyse comprenant une boucle d’itération permettant, avant une nouvelle exécution, d’effectuer une nouvelle préparation du code en fonction des résultats de l’analyse précédente. Figure pour l’abrégé : Fig.1 Procédé et dispositif d'inférence sémantique pour bases de données logicielles Domaine de l’invention L’invention se situe dans le domaine de l’ingénierie logicielle, et concerne un procédé et un dispositif d'inférence sémantique pour des bases de données logicielles, i.e. des bases de données dont les éléments sont des codes informatiques. Etat de la Technique L’effervescence du développement logiciel depuis quelques décennies, a donné naissance à de grandes bases de données logicielles. De telles bases massives contiennent des codes dont les caractéristiques en termes de volume, de contenu (technique de programmation, langage de programmation, architecture), d’application, sont hétérogènes. Ces bases peuvent être publiques ou privées. Un exemple de base de code publique est la plateforme « GitHub » qui est un site regroupant le plus important nombre de dépôt de codes au monde, utilisé comme dépôt public pour des projets libres ou comme dépôt privé pour des entreprises. Cette base contient du code provenant de dizaine de millions de projets différents, ayant des applications diverses dont certaines peuvent éventuellement avoir un rapport entre elles. De telles quantités de données doivent pouvoir être exploitées, à profit, pour améliorer les techniques d’ingénierie logicielle et dès lors améliorer la maitrise des chaines d’approvisionnement des composants numériques. Cependant de tels développements se heurtent à au moins la difficulté d’inférer, avec précision et à grande échelle, les comportements sémantiques des codes. On entend par inférer des comportements sémantiques de code, la recherche de dépendance entre des éléments de code, soit au sein d’un même code (i.e. un code complet permettant d’exécuter une/des fonction(s)), soit entre des éléments de codes différents, et ce quelle que soit la variabilité entre les codes. De nombreuses techniques d’analyse de code et de rétroingénierie de modèles existent, mais elles se heurtent à un triple problème : - celui de la fiabilité de leurs résultats, qui impose un processus long et coûteux de révision manuelle ; - celui du passage à l’échelle des outils, car ces derniers nécessitent un paramétrage complexe qui est directement lié aux codes auxquels ils sont appliqués ; - celui de la réutilisation du processus d’analyse, générant une reprise « à zéro » de celui-ci à chaque nouvelle version de code. Une approche connue est celle de l’infrastructure « MUSE » (Mining and Understanding Software Enclaves), construite autour d'un corpus large, diversifié et évolutif de logiciels issus de centaines de milliards de lignes de code source ouvert, conçue pour améliorer la façon dont les logiciels sont construits, débogués, vérifiés, maintenus et compris. MUSE se concentre sur l'inférence de spécifications, la réparation automatisée et la synthèse de programmes. Un inconvénient de cette approche réside dans la difficulté à paramétrer les analyses de programme, en particulier pour identifier précisément les dépendances des plateformes et des environnements et pour identifier les modèles (de mémoire, d’exécution, …). Un autre inconvénient réside dans une mise en œuvre séquentielle des analyses, qui fait qu’elles ne peuvent bénéficier de résultats précédents. Aussi, le problème de l’analyse du comportement sémantique de codes logiciels reste à traiter. Il réside alors un besoin de réaliser des inférences sémantiques sur des bases de données de codes logiciels, qui ne présente pas les inconvénients des solutions existantes. La présente invention répond à ce besoin. Un objet de la présente invention est un procédé d'inférence sémantique pour bases de données logicielles. Avantageusement le procédé de l’invention permet l’inférence à grande échelle des comportements sémantiques de codes logiciels, et en particulier l’inférence de leurs caractéristiques intrinsèques (flots de données, flots de contrôle, etc.) et de leurs caractéristiques extrinsèques (dépendances, utilisations, etc.). Le procédé de l’invention repose sur des capacités d’analyse de code et de construction de modèles, où les paramètres d’analyse sont générés automatiquement dans une phase dédiée, soit par des techniques d’aléa, d’heuristique, ou d’apprentissage machine. Avantageusement, le procédé de l’invention, par un enchainement d’étapes itératives, permet un enrichissement au fur et à mesure des bases de données logicielles, grâce aux résultats des inférences sémantiques réalisées aux étapes précédentes. De manière générale, les caractéristiques distinctives et avantageuses du procédé de l’invention sont : - une mise en œuvre de techniques de génération automatique, en particulier pour la génération de paramètres de prétraitement, de paramètres d’analyse, la génération des domaines d’entrée, et des spécifications ; - une utilisation d’analyses formelles, considérées alors comme « correctes », c’est-à-dire produisant des résultats mathématiquement démontrés, pour effectuer des inférences sémantiques fiables ; - un enrichissement itératif des bases de données logicielles avec les résultats des inférences sémantiques (flots de données, spécifications fonctionnelles, architecture des composants et leurs relations) ; - une approche conjointe combinant l’utilisation de générateurs aléatoires, et l’utilisation de générateurs basés sur des techniques d’apprentissage, bénéficiant des résultats des générateurs aléatoires. L’approche proposée permet le passage à l’échelle des techniques d’inférence sémantique. Les domaines d’application industrielle de l’invention sont alors multiples. Les domaines d’utilisation concernent potentiellement l’ensemble des cycles de développement logiciels. Les applications qui peuvent tirer un avantage majeur sont celles dans les domaines dits critiques que sont les transports, l’énergie, la santé, la défense. Pour obtenir les résultats recherchés, il est proposé un procédé d'inférence sémantique pour bases de données logicielles. Le procédé d’analyse de bases de données massive de codes logiciels est mis en œuvre par ordinateur, l’ordinateur comprenant au moins un processeur couplé à une mémoire stockant des instructions de code non transitoires qui, lorsqu'elles sont exécutées, amènent le processeur à effectuer des étapes consistant à : - recevoir une famille de codes logiciels à analyser, ladite famille de codes logiciels étant un regroupement par similarités d’une pluralité de codes logiciels stockés dans une base de données massive de codes logiciels ; - effectuer une préparation sur les codes logiciels de la famille sélectionnée en fonction de paramètres caractérisant ladite famille de codes logiciels ; et - exécuter une analyse sémantique et une analyse architecturale des codes préparés de ladite famille de codes logiciels, ladite analyse comprenant une boucle d’itération permettant, avant une nouvelle exécution, d’effectuer une nouvelle préparation du code en fonction des résultats de l’analyse précédente. Le procédé peut opérer selon des modes de réalisation alternatifs ou combinés. Selon un mode de réalisation, l’étape de recevoir une famille de codes logiciels comprend des étapes consistant à : étiqueter les codes logiciels contenus dans la base de données massive de code logiciel ; regrouper les codes logiciels en familles de code logiciel, en fonction des étiquettes et d’une similarité morphologique ; et sélectionner une famille de code logiciel à analyser. Selon un mode de réalisation, l’étape d’effectuer une préparation du code comprend des étapes consistant à : - extraire de chaque code logiciel appartenant à une même famille, différentes informations caractérisant leur typologie ; - générer des paramètres de caractérisation à partir de l’ensemble des informations extraites ; et - générer une représentation agrégée et normalisée du code logiciel et des paramètres de caractérisation. Selon un mode de réalisation, l’étape d’extraction d’informations comprend de plus des étapes consistant à extraire des informations de fichiers « Makefile », des informations de fichiers de documentation et de manuels d’utilisation, des informations de commentaires présents dans les codes logiciels. Selon un mode de réalisation, l’étape d’effectuer une nouvelle préparation des codes logiciels de la famille sélectionnée, consiste à utiliser des annotations sémantiques et/ou des annotations architecturales obtenues comme résultats d’analyses précédentes. Selon un mode de réalisation, l’étape de générer des paramètres de caractérisation consiste à générer des paramètres à partir d’un algorithme de génération aléatoire de paramètres ou d’un algorithme de génération semi-aléatoire de paramètres. Selon un mode de réalisation, l’étape de générer une représentation agrégée et normalisée comprend des étapes consistant à intégrer les paramètres générés dans le code logiciel et à normaliser les formes de code. Selon un mode de réalisation, l’étape de générer une représentation agrégée et normalisée consiste à générer une forme de blob binaire ou un code source enrichi. Selon un mode de réalisation, la boucle d’itération est répétée un nombre prédéfini de fois. Dans une variante de réalisation, la boucle d’itération est répétée tant qu’un point fixe n’est pas atteint. L’invention concerne aussi un dispositif d’analyse de bases de données massive de codes logiciels, le dispositif comprenant des moyens pour mettre en œuvre les étapes du procédé de l’invention. L’invention concerne aussi un produit programme d’ordinateur qui comprend des instructions de code permettant d’effectuer les étapes du procédé de l’invention, lorsque le programme est exécuté sur un ordinateur. Description des figures D’autres caractéristiques et avantages de l’invention apparaîtront à l’aide de la description qui suit et des figures des dessins annexés dans lesquels : La illustre schématiquement un dispositif permettant de mettre en œuvre le procédé de l’invention ; La est un organigramme des étapes générales d’un procédé d’analyse de bases de données massive de codes logiciels selon un mode de réalisation de l’invention ; La est un organigramme illustrant de manière plus détaillée les étapes itératives du procédé de l’invention, selon un mode de réalisation ; La est un organigramme illustrant de manière plus détaillée, le déroulé d’une analyse sémantique selon un mode de réalisation du procédé de l’invention ; La est un organigramme illustrant de manière plus détaillée, le déroulé d’une analyse architecturale selon un mode de réalisation du procédé de l’invention. Description détaillée de l’invention La illustre schématiquement un dispositif 100 permettant de mettre en œuvre le procédé d’analyse de bases de données logicielles selon l’invention. Le dispositif 100 dans une implémentation générique comprend un système 10 de type ordinateur ayant des capacités de stockage et de traitement de données. Il comprend entre autres éléments, un processeur 12 couplé à une mémoire 14 qui comprend des instructions de code permettant d’effectuer les étapes du procédé de l’invention, lorsque les instructions sont exécutées. Les instructions de code peuvent être produites sous la forme d’un programme d’ordinateur qui peut être installé sur le système 10 ou être lu par le système 10 depuis un support lisible, tangible et non transitoire, tel qu'une mémoire magnétique, optique ou électronique, ou être accéder à distance vis un réseau par exemple. Certaines fonctions du processeur 12 peuvent être exécutées par des circuits logiques programmables appropriés. Le système 10 comprend des moyens (non illustrés) pour accéder à (i.e. transmettre vers et recevoir de) une base de données de codes logiciels 16. Dans le contexte de mise en œuvre de l’invention, la base de données de codes logiciels 16 est une base massive stockant un volume très important de codes logiciels de toute nature, dont les caractéristiques en termes de techniques de programmation, de langages de programmation, d’architectures, d’applications, peuvent être très hétérogènes. Le procédé de l’invention vise à faciliter les analyses sémantiques et les analyses architecturales des codes contenus dans de telles bases de données, en inférant les différentes relations, dépendances, pouvant exister entre les objets contenus dans les bases de données. Le processeur 12 est couplé à une mémoire 14 qui comprend différents modules fonctionnels pour opérer le procédé de l’invention. Un module de sélection de code 102 permet de fournir à un module de génération de paramètres de caractérisation 104, un ensemble de codes sélectionnés, issus de la base de données 16. Dans un mode de réalisation, l’ensemble de codes sélectionnés est un regroupement d’une pluralité de codes par similarités, donnant une famille de codes, selon des étapes qui sont décrites en relation à la . Dans une variante de réalisation, les regroupements de codes sont effectués par un sous-module fonctionnel du module de sélection 102. Dans une autre variante de réalisation, les regroupements de code sont effectués par un dispositif fonctionnel externe, et le système 10 reçoit une famille de codes à analyser. Le module de génération de paramètres de caractérisation 104 opère une caractérisation des codes regroupés dans une famille de codes logiciels fournie par le module de sélection de code 102. Le module de génération de paramètres de caractérisation 104 opère des étapes décrites en relation aux figures 3 et 4, pour générer des paramètres caractérisant la famille de codes logiciels, et pour effectuer un prétraitement des codes avant de procéder à leur analyse par un module d’analyse sémantique 106 et un module d’analyse architecturale 108. Chaque module d’analyse (106, 108) opère des étapes décrites en relation aux figures 3, 5 et 6. La montre sur un organigramme, les étapes générales d’un procédé d’analyse de bases de données massive de codes logiciels selon un mode de réalisation de l’invention. Le procédé 200 débute par une étape 202 consistant à recevoir ou à constituer une famille de codes logiciels à analyser qui regroupe par similarités, une pluralité de codes logiciels stockés dans une base de données massive de codes logiciels (16). Dans un mode de réalisation, la constitution d’une famille de codes logiciels comprend plusieurs étapes. Une étape 202-1 consiste à étiqueter les codes logiciels contenus dans la base de données massive de code logiciel (16). Cette étape aussi connue comme « tagging » selon l’anglicisme consacré, consiste en une opération d’annotation des objets, i.e. les codes logiciels, d’une base de données massive, visant à en identifier les grandes caractéristiques. Ainsi, par exemple, l’opération d’étiquetage peut consister à identifier et à marquer des codes optimisés (pour certains environnement embarqués de type Internet des objets IoT), des codes effectuant des communications électroniques (identifiés par la reconnaissance de protocoles), des codes effectuant de l’apprentissage machine / artificiel (par reconnaissance d’opérations propres à des réseaux de neurones). Dans certains modes de réalisation l’opération d’étiquetage est entièrement automatique, et peut mettre en œuvre des algorithmes de reconnaissance de schémas de programmation. De tels algorithmes peuvent par exemple, reconnaitre dans des codes logiciels, une absence d’allocation dynamique, un appel à des fonctions modem ou réseau, une utilisation d’algorithmes de calcul de gradients. L’homme du métier comprend que seuls quelques exemples de mise en œuvre d’une opération d’étiquetage de codes logiciels sont donnés, mais ils ne sont pas exhaustifs, et d’autres approches et outils connus peuvent être employés. Après l’étiquetage des codes, une étape suivante 202-2 consiste à regrouper les codes logiciels en groupes ou familles de code logiciel, en fonction des étiquettes et d’une similarité morphologique. Cette étape aussi connue comme partitionnement de données ou « clustering » selon l’anglicisme consacré, consiste à permettre un regroupement des objets d’une base de données, i.e. des codes logiciels, en fonction de leurs annotations (i.e. de leurs éventuelles relations) et de leur similarité morphologique. Divers algorithmes de partitionnement de données peuvent être utilisés, comme par exemple les algorithmes de k-moyenne, de regroupement hiérarchique (ascendant ou descendant) ou de cartes auto-adaptatives (cartes auto-organisatrices, cartes topologiques, fondées sur des méthodes d'apprentissage non supervisées), afin d’identifier des similarités entre codes logiciels de la base de données. Après l’étape de création de familles de codes logiciels, une étape 202-3 permet de sélectionner une famille de code logiciel à analyser. Revenant à la , le procédé poursuit alors par une étape 204 consistant en une préparation des codes de la famille sélectionnée. La préparation du code effectuée selon le procédé de l’invention permet d’effectuer des analyses automatiques, sémantiques et architecturales, des codes de la famille sélectionnée, dans une étape suivante 206. Une analyse sémantique consiste généralement à établir, à déterminer l’ensemble des relations existant au sein d’un même code. Une analyse architecturale consiste généralement à établir, à déterminer l’ensemble des relations existant entre des éléments de codes différents. Les relations peuvent être par exemple de déterminer que tel code utilise telle librairie, ou encore que tel code dérive de tel autre code (artefact numérique). Avantageusement, le procédé de l’invention introduit une étape d’analyse automatique et itérative. A l’issue de la première analyse (sémantique et architecturale), le procédé permet de réinjecter (illustré par une boucle de retour 205) les résultats de chaque analyse dans le module de préparation de code 104, comme données additionnelles, permettant ainsi d’enrichir les éléments considérés dans la boucle d’itération. Le procédé se poursuit par une nouvelle étape de préparation de code 204 qui prend en compte ces nouvelles informations, puis réitère une nouvelle étape d’analyse 206. La boucle des étapes de préparation de code 204 et d’analyse 206 peut être reconduite un certain nombre de fois, puis le procédé se termine. Les résultats des analyses, i.e. les inférences sémantiques et architecturales (flots de données, spécifications fonctionnelles, architecture des composants et leurs relations), peuvent aussi être réinjectés dans la base de données de codes logiciels pour permettre un enrichissement itératif de la base de données. La est un organigramme illustrant de manière plus détaillée les étapes itératives du procédé de l’invention. Dans un mode de réalisation, l’étape 204 de préparation de code, comprend une première étape 302 consistant à extraire des informations caractérisantes des codes de la famille sélectionnée. L’extraction d’informations caractérisantes se fait à travers l’identification de schémas de programmations spécifiques et caractérisantes, tels que des fonctions d’optimisation, des fonctions cryptographiques, ou encore des algorithmes spécifiques à certains types de code réseau, d’apprentissage, etc. Dis autrement, l’étape 302 consiste à pouvoir identifier au sein des différents codes sources, des éléments qui permettent de classifier les codes grâce à l’identification de « patterns » qui sont connus et se retrouvent très régulièrement pour des codes de la même nature. Il pourra ainsi être fixé des seuils de probabilités d’occurrences pour permettre la classification des codes, comme par exemple un seuil de 0,9 pour des occurrences relatives au terme ‘crypto’ (et toutes ses variantes), un seuil de 0,3 pour des occurrences relatives au terme ‘network’ ou encore un seuil de 0,01 pour des occurrences relatives à une classification ‘neural_network’. L’homme du métier comprend que seuls quelques exemples sont donnés mais ils ne sont pas limitatifs, et que la recherche de pattern et l’extraction d’informations caractérisantes dans les codes sources sélectionnés, pourra prendre d’autres formes. Ainsi par exemple, dès lors qu’une extraction d’informations d’un code logiciel identifie un ensemble de fonctions qui gèrent des paquets (de données), il peut être considéré que ce code relève d’un logiciel qui (en tout ou en partie) implémente un protocole de communication. Un autre exemple peut porter sur une extraction d’informations d‘un code qui identifie un algorithme de classification et qui identifie que cet algorithme implémente un empilement de passes de transformation non-linéaires, alors il peut être considéré que ce code relève d’un logiciel qui sert à faire de l’apprentissage automatique. Dans des variantes de réalisation distinctes ou combinées, l’extraction d’informations consiste à extraire des informations de fichiers « Makefile », et/ou des informations de fichiers de documentation et de manuels d’utilisation, et/ou des informations de commentaires présents dans les codes logiciels. L’extraction d’information de fichiers de type « Makefile » issus du processus de développement (i.e. dépendances de librairies, paramètres des environnements d’exécution comme l’architecture processeur par exemple) peut provenir de fichiers stockés dans la base de données de codes sources. L’extraction d’information de fichiers de documentation et de manuels d’utilisation accompagnant la distribution des logiciels, peut porter sur la définition des modes d’interaction utilisateurs et/ou sur les types de données traitées. L’extraction d’information de commentaires présents dans les codes informatiques, en général écrits par les développeurs, peut apporter des informations sur des invariants de code, sur des préconditions et des post-conditions. Revenant à la , dans une étape suivante 304, le procédé permet de générer des paramètres de caractérisation à partir de l’ensemble des informations caractérisantes extraites. Les paramètres de caractérisation peuvent consister en des annotations du code et /ou des options des outils d’analyse, en des instructions qui vont permettre d’effectuer dans une étape suivante 306, un prétraitement automatique du code à analyser. Cette étape 304 permet de spécifier différents paramètres. Des paramètres de mise en œuvre des codes à analyser peuvent être spécifiés, en extrayant les données contenues dans les directives de compilation. Par exemple, un paramètre « -I librairie » permet de spécifier aux outils d’analyses qu’une dépendance envers la librairie « librairie » doit être prise en compte. L’étape 304 peut permettre de spécifier des ressources de calcul à mobiliser dans l’exécution des analyses, par exemple en modulant ces ressources selon la topologie des codes. Par exemple, un paramètre « slevel-function f:N » permet de spécifier aux outils d’analyse sémantique qu’ils doivent appliquer un niveau de précision N à l’analyse de la fonction de code f). L’étape 304 peut permettre de spécifier les stratégies d’analyse, par exemple en annotant certains schémas de programmation avec une directive de traitement pour l’analyse. Un exemple illustré dans le tableau ci-après, propose une annotation « unrool loop N » (avec N=10) qui permet de spécifier aux outils d’analyse sémantique que la boucle annotée doit être déroulée N fois. Ces critères permettent de guider les analyseurs dans les étapes suivantes, et l’avantage est de permettre d’effectuer des analyses plus rapides et précises. Selon des variantes de réalisation, la génération de paramètres utilise des algorithmes de génération aléatoire ou semi-aléatoire, et peut utiliser des algorithmes de type « génétique » ou « par apprentissage machine » par exemple. Avantageusement, l’étape de génération de paramètres de caractérisation 304 peut prendre en compte, les résultats des analyses obtenus dans une phase précédente. Dans un mode de réalisation, les résultats sont des annotations sémantiques ou architecturales produites par les outils d’analyse utilisés. Revenant à la , l’étape suivante 306 consiste en un prétraitement du code. Cette étape est effectuée en préparation des analyses sémantiques et architecturales, et permet de transformer le code initial en : - Intégrant les paramètres générés à l’étape 304, et en particulier en insérant les annotations aux locations de code appropriées ; - Normalisant les formes de code, par exemple en adoptant des formes communes pour les schémas de code comme des boucles ou des retours de fonction. L’étape de prétraitement 306 produit ainsi une représentation agrégée et normalisée du code et des paramètres de caractérisation. Cette représentation peut prendre une forme de blob binaire, ou de code source enrichi. Revenant à la , le procédé poursuit par des étapes d’analyse sémantique 308 (détaillées à la ) et des étapes d’analyse architecturale 314 (détaillées à la ) du code tel que prétraité. Selon les modes de réalisation, les analyses sémantiques et architecturales sont basées sur des algorithmes d’analyse connus. Dans un mode particulier, les analyses sont faites par la suite « Frama-C » qui offre un ensemble d'analyseurs de programmes interopérables pour les programmes C. Frama-C s'appuie sur le langage CIL (acronyme de « C Intermediate Language ») pour générer un arbre syntaxique abstrait. L'arbre syntaxique abstrait supporte les annotations écrites en langage ACSL (acronyme de « ANSI/ISO C Specification Language »). Plusieurs modules peuvent manipuler l'arbre syntaxique abstrait pour ajouter des annotations en ACSL. D’autres outils d’analyse peuvent être cités pour effectuer les analyses comme par exemple « Infer » pour le langage C++, « SPARK » pour le langage ADA, ou encore « javalib/sawja » pour le langage Java. Les étapes d’analyse sémantique 308 et d’analyse architecturale 314 produisent respectivement des annotations sémantiques 310 et des annotations architecturales 316. Selon des modes de réalisation, les annotations sémantiques et architecturales sont générées en utilisant des langages de formalisation de l’état de l’art, tels que par exemple et sans limitation, le langage ACSL, le langage SysML (acronyme de « Systems Modeling Language ») qui est un langage de modélisation spécifique au domaine de l'ingénierie système, le langage JML (acronyme de « Java Modeling Language ») qui est un langage de spécification pour Java, qui fournit une sémantique pour décrire formellement le comportement des programmes Java. Les spécifications JML sont ajoutées au code Java sous forme d'annotations dans les commentaires). Après les étapes d’analyse et de fourniture des résultats d’analyse, le procédé détermine (respectivement étapes 312, 318) si l’analyse doit être répétée afin d’être améliorer ou non, selon un critère prédéfini. Le critère de réitération de l’analyse peut être défini par un compteur d’itérations fixant un nombre d’itérations, ou bien il peut être basé sur des heuristiques, telles que par exemple la recherche d’un point fixe. Si le critère prédéfini est atteint, le procédé se termine (Fin). Quand une nouvelle passe de l’analyse doit être effectuée, le procédé reboucle sur l’étape de préparation du code 204, en injectant les résultats d’analyses, comme nouvelles informations caractérisantes. Le procédé permet alors de générer une mise à jour des paramètres de caractérisation à partir desquels, il est effectué un nouveau prétraitement du code sur lequel une nouvelle analyse va être réalisée. Avantageusement, les résultats d’analyse, annotations sémantiques et architecturales générées par une ou plusieurs analyses, peuvent être ajoutées dans les codes stockés dans la base de données de codes logiciels, permettant ainsi un enrichissement du contenu sémantique et architectural de ces codes. En effet, un code peut appartenir à différentes familles de code, et ainsi lorsqu’il est utilisé pour une autre analyse, cette dernière peut bénéficier de l’enrichissement des annotations produites lors d’une autre analyse. La est un organigramme illustrant de manière plus détaillée, le déroulé d’une analyse sémantique selon un mode de réalisation du procédé de l’invention. L’analyse sémantique est initiée sur le code à analyser après son prétraitement (étape 204), et consiste à partir d’un cahier des charges existant (branche oui de 402) à produire en 408 des invariants, des pré-conditions et des post-conditions (i.e. phase de « Predicate Transformer » en anglais) qui vont être utilisés pour l’analyse en 410 . S’il n’existe pas de cahier des charges (branche non de 402), il est d’abord généré en 404 des annotations à partir des propriétés intrinsèques du code, puis il est généré en 406 des paramètres d’analyses, afin de lancer à l’étape 410 une analyse sémantique du code (analyse du flow « Dataflow Analysis »; analyse temporelle « Runtime Analysis »). Le résultat de l’analyse produit des annotations sémantiques 310, et l’analyse peut être itérée (vers 204) ou se terminer (Fin). Un tel déroulé étant connu de l’homme du métier, ce dernier pourra mettre en œuvre des outils connus pour les différentes phases. Ainsi, la phase 404 de génération d’annotations basée sur des propriétés intrinsèques peut s’appuyer sur des outils comme Frama-C/RTE par exemple ; la phase 406 de génération de paramètres d’analyse, peut être une génération aléatoire ou semi-aléatoire et utiliser des algorithmes de type « génétique » par exemple. La phase de Predicate Transformer 408 peut s’appuyer sur des outils comme Frama-C/WP, SPARK Pro, par exemple. La est un organigramme illustrant de manière plus détaillée, le déroulé d’une analyse architecturale selon un mode de réalisation du procédé de l’invention. L’analyse architecturale est initiée sur le code à analyser après son prétraitement (étape 204), et consiste à partir d’une documentation de code existante (branche oui de 502) à extraire en 508 de l’information textuelle qui va être utilisée en 510 pour l’analyse. S’il n’existe pas de documentation de code (branche non de 502), il est récupéré des directives de compilation de d’exécution en 504 permettant de générer en 506 des paramètres d’analyses, afin de lancer à l’étape 510 une analyse architecturale du code. Le résultat de l’analyse architecturale produit des annotations architecturales 316, et l’analyse peut être itérée (vers 204) ou se terminer (Fin). Un tel déroulé étant connu de l’homme du métier, ce dernier pourra mettre en œuvre des outils connus de « reverse-engineering » de code source. Il a ainsi été décrit une solution basée sur une approche itérative et incrémentales pour procéder à l’analyse de bases de données de code logiciel, particulièrement adaptée à l’analyse de bases de données massive. Le procédé met en œuvre une phase spécifique et dédiée à la génération de paramètres d’analyses utilisant de techniques d’aléas, d’heuristiques, ou d’apprentissage machine. Des étapes de sélection de caractéristiques des codes et de prétraitement sont mises en œuvre avant les phases d’analyse sémantiques et architecturales, permettant d’améliorer la fiabilité des résultats des analyses. L’approche itérative de l’invention permet de tirer parti, à chaque itération, des inférences réalisées précédemment. Partant des principes généraux décrits, l’homme du métier pourra apporter des variantes et des adaptations selon l’application envisagée. Procédé (200) mis en œuvre par ordinateur, d’analyse de bases de données massive de codes logiciels, l’ordinateur comprenant au moins un processeur (12) couplé à une mémoire (14) stockant des instructions de code non transitoires qui, lorsqu'elles sont exécutées, amènent le processeur à effectuer des étapes consistant à : recevoir (202) une famille de codes logiciels à analyser, ladite famille de codes logiciels étant un regroupement par similarités d’une pluralité de codes logiciels stockés dans une base de données massive de codes logiciels (16) ; effectuer (204) une préparation sur les codes logiciels de la famille sélectionnée en fonction de paramètres caractérisant ladite famille de codes logiciels ; et exécuter (206) une analyse sémantique et une analyse architecturale des codes préparés de ladite famille de codes logiciels, ladite analyse comprenant une boucle d’itération permettant, avant une nouvelle exécution, d’effectuer une nouvelle préparation du code en fonction des résultats de l’analyse précédente. Le procédé selon la revendication 1 dans lequel l’étape de recevoir une famille de codes logiciels comprend des étapes consistant à : étiqueter (202-1) les codes logiciels contenus dans la base de données massive de code logiciel (16); regrouper (202-2) les codes logiciels en familles de code logiciel, en fonction des étiquettes et d’une similarité morphologique ; et sélectionner (202-3) une famille de code logiciel à analyser. Le procédé selon la revendication 1 ou 2 dans lequel l’étape d’effectuer une préparation du code comprend des étapes consistant à : extraire (302) de chaque code logiciel appartenant à une même famille, différentes informations caractérisant leur typologie ; générer (304) des paramètres de caractérisation à partir de l’ensemble des informations extraites ; et générer (306) une représentation agrégée et normalisée du code logiciel et des paramètres de caractérisation. Le procédé selon la revendication 3 dans lequel l’étape d’extraction d’informations comprend de plus des étapes consistant à extraire des informations de fichiers « Makefile », des informations de fichiers de documentation et de manuels d’utilisation, des informations de commentaires présents dans les codes logiciels. Le procédé selon l’une quelconque des revendications 1 à 4 dans lequel l’étape d’effectuer une nouvelle préparation des codes logiciels de la famille sélectionnée, consiste à utiliser des annotations sémantiques et/ou des annotations architecturales obtenues comme résultats d’analyses précédentes. Le procédé selon l’une quelconque des revendications 3 à 5 dans lequel l’étape de générer des paramètres de caractérisation consiste à générer des paramètres à partir d’un algorithme de génération aléatoire de paramètres ou d’un algorithme de génération semi-aléatoire de paramètres. Le procédé selon l’une quelconque des revendications 3 à 6 dans lequel l’étape de générer une représentation agrégée et normalisée comprend des étapes consistant à intégrer les paramètres générés dans le code logiciel et à normaliser les formes de code. Le procédé selon l’une quelconque des revendications 3 à 7 dans lequel l’étape de générer une représentation agrégée et normalisée consiste à générer une forme de blob binaire ou un code source enrichi. Le procédé selon l’une quelconque des revendications 1 à 8 dans lequel la boucle d’itération est répétée un nombre prédéfini de fois. Le procédé selon l’une quelconque des revendications 1 à 8 dans lequel la boucle d’itération est répétée tant qu’un point fixe n’est pas atteint. Un produit programme d’ordinateur, ledit programme d’ordinateur comprenant des instructions de code permettant d’effectuer les étapes du procédé selon l'une quelconque des revendications 1 à 10, lorsque ledit programme est exécuté sur un ordinateur. Un dispositif d’analyse de bases de données massive de codes logiciels, le dispositif comprenant des moyens pour mettre en œuvre les étapes du procédé de l’une quelconque des revendications 1 à 10.