Quand ils conçoivent leurs applications, les développeurs informatiques s’appuient désormais sur des Intelligences Artificielles qui génèrent automatiquement du code. Problèmes : ces grands modèles de langage (LLM) sont souvent fermés, coûteux, peu fiables, opaques quant à l’origine des données et guère plus loquaces sur les licences pouvant s’appliquer. Porté par l’équipe Software Heritage de l’Inria, en collaboration avec le CEA et Tweag ainsi que d’autres partenaires, le projet CodeCommons vise à constituer des jeux de données qualifiés pour pouvoir ensuite entraîner des modèles ouverts, transparents et responsables.
En 2025, dans le monde, 84% des développeurs ont utilisé un robot conversationnel pour concevoir du code(1). En tête du palmarès : le célèbre ChatGPT et aussi GitHub Copilot, un outil plus spécialisé qui s’intègre directement dans les environnements de développement. Ces LLM sont dits ‘fermés’ car ils ne divulguent pas les données ayant servi à leur entraînement. Aucune traçabilité. Rien ne garantit qu’ils n’enfreignent pas des droits d’auteurs en s’entraînant sur du code source protégé par des licences. Rien non plus ne certifie que ce code n’est pas vérolé par des bugs ou des failles de sécurité.
Et ce n’est pas tout… Ils ne donnent de bonnes réponses que dans respectivement 65% et 46% des cas(2). Ils ne prennent en compte qu’une douzaine de langages de programmation. Pourtant leur taille dépasse allègrement les 175 milliards de paramètres, rendant leur entraînement et leur exploitation très énergivore. Un ‘prompt’ sur ce type d’outil émet au minimum 10 fois plus de CO2 qu’une requête sur Google.
À titre de comparaison, un modèle ouvert comme StarCoder2 fonctionne avec seulement 15 milliards de paramètres alors qu’il gère plus de 80 langages et donne de bonnes réponses dans 41% des cas. Le modèle ouvert LLaMA présente également des métriques du même ordre.
Mais il y a encore énormément de chemin à faire avant de parvenir à élaborer des assistants de codage aussi vertueux qu’efficaces. Et c’est précisément l’objectif de CodeCommons, une nouvelle infrastructure d’entraînement de LLM à partir de logiciels open source. Financé par la banque publique d’investissement Bpifrance, ce projet va durer deux ans. Il se charpente autour d’un consortium rassemblant Inria, le CEA, Tweag, AboutCode, ainsi que Sant’Anna, les universités de Pise, Bologne et Turin.
Défi Inria LLM4CODE
L’institut travaille aussi à l’amélioration des LLM pour l’assistance aux développeurs à travers un Défi Inria, c’est-à-dire une action de recherche transversale impliquant plusieurs équipes. Baptisé LLM4CODE, ce projet réunit pour quatre ans des spécialistes en IA, génie logiciel et méthodes formelles. Il implique les équipes de recherche Argo, Deducteam, DiverSE, Evref, Flowers, Mnemosyne, Picube, Spirals et Stamp, ainsi que le Service d’expérimentation et de développement d’Inria (SED), l’archive de code Software Heritage, le Laboratoire bordelais de recherche en informatique (LaBRI) et la société Sopra Steria.
Software Heritage
Pour ces travaux, les scientifiques ne partent pas de zéro. Ils s’appuient sur Software Heritage. Lancée en 2016 par Inria et soutenue par l’Unesco, cette archive ouverte collecte le code source des logiciels disponibles publiquement. Elle héberge à ce jour la bagatelle de 28 milliards de fichiers issus de 430 millions de projets provenant de 500 ‘forges’ collaboratives comme GitHub ou GitLab. Cette masse d’informations s’organise dans un graphe qui comporte aujourd’hui un trilliard d’arêtes et pèse 2 pétaoctets.
Quatre équipes-projets d’Inria s’impliquent dans CodeCommons : Software Heritage à Rocquencourt, Cedar à Saclay, ALMAnaCH à Paris et DiverSE(3) à Rennes. Spécialisée en génie logiciel, cette dernière intervient sur l’accélération de la collecte et la qualification des données.
“Avant de pouvoir mettre un LLM en production, il y a plusieurs étapes, indique Caroline Landry, ingénieure de recherche dans l’équipe DiverSE et responsable technique de CodeCommons. D’abord, il faut collecter les données auprès des différentes forges. C’est très long et très coûteux. Ensuite, il faut trier ces données et les qualifier pour trouver des caractéristiques, identifier les langages employés et éventuellement d’autres critères d’intérêt. Actuellement, ce travail s’effectue à la main ! Le but est d’extraire de ce gros jeu de données un sous-ensemble à la fois moins volumineux et plus pertinent pour l’apprentissage. Après cela, il faut créer le modèle, l’entraîner sur ce jeu de données et enfin tester son efficacité à l’aide de HumanEval, un outil qui mesure les performances des LLM dans les tâches de génération de code.”
Des progrès dans les résultats
Dans tout ce processus, la qualification s’avère une phase critique. “Il ne s’agit pas seulement de collecter le code source, précise Caroline Landry. Nous voulons aussi adjoindre toutes informations supplémentaires qui s’y rapportent. C’est le cas en particulier de ce que nous appelons les ‘issues’. Cela comprend les signalements de bug à corriger ou encore des demandes d’évolution. Ces discussions techniques sont associées à des ‘pull requests’. Dans GitHub, cette fonction permet de proposer des modifications au code source d’un projet. Un développeur améliore sa copie locale et souhaite partager cette version modifiée. Les autres développeurs font une revue du code. Quand tout le monde a validé, le développeur effectue sa livraison. Pour nous, cette fonction présente un énorme intérêt. Car souvent les modifications proposées sont à la fois de petite taille et associées à une discussion entre développeurs. Nous pouvons donc relier une portion de code modifiée à une description en langage naturel. C’est l’équivalent d’une annotation. Cette association entre bribe de code et discussion fournit des éléments de réponse pertinents quand un développeur interroge un LLM. En pratique, toutes les données sont organisées dans un graphe. Les nœuds contiennent les fichiers de code source dans leurs versions successives auxquels nous rajoutons des qualifications. À partir de ce graphe qualifié, on peut imaginer un développeur qui dise : moi, je veux du Python 3.5 minimum utilisant la bibliothèque Pandas, avec une licence open source, sans faille de sécurité et avec une couverture de code(4) de plus de 60%. Un LLM comme StarCoder a intégré ce genre de données et nous avons constaté des progrès dans les résultats.”
Détecter les licences
La caractérisation permettra aussi d’incorporer les CVE (Common Vulnerabilities and Exposures) qui sont des bibliothèques de vulnérabilités connues. Grâce au partenariat avec AboutCode, le projet pourra par ailleurs s’appuyer sur le logiciel ScanCode pour détecter les licences couvrant le code source collecté.
Dans le cadre du projet, huit ingénieurs ont été recrutés au sein de l’équipe DiverSE. Ils conçoivent deux outils. Le premier est un ‘crawler’ parcourant toutes les forges pour collecter les codes, les issues, les pull requests… Le second analyse la syntaxe du code pour identifier les langages, les versions, les compatibilités…
CodeCommons va permettre aux éditeurs de concevoir de meilleurs assistants de codage dont les développeurs pourront ensuite se servir. “Mais il y a aussi un intérêt pour les scientifiques, conclut Caroline Landry. Avant de pouvoir construire et étudier des modèles, les chercheurs passent énormément de temps à collecter, trier, qualifier les données. C’est un frein à la recherche en IA que nous allons contribuer à lever.”
- Sondage international par Stack Overflow portant sur 50 000 professionnels.
- Lire : Evaluating the Code Quality of AI-Assisted Code Generation Tools: An Empirical Study on GitHub Copilot, Amazon CodeWhisperer, and ChatGPT, par Burak Yetiştiren, Işık Özsoy, Miray Ayerdem et Eray Tüzün.
- Spécialisée en génie logiciel, DiverSE est une équipe Inria, Insa Rennes, CNRS et Université de Rennes, commune à l’Irisa.
- La couverture de code correspond au pourcentage d’instructions qui ont été vérifiées par des tests.