Si vous lisez cet article, vous êtes peut-être développeur.

Cela tombe bien, car nous allons explorer une question qui vous concerne : l’intelligence artificielle va-t-elle remplacer votre travail ?

Aujourd’hui, des modèles de machine learning sont capables d’écrire du code.

Alors, certains parmi vous se disent peut-être que ce n’est pas nouveau. Il est vrai que l’on parle de génération automatique de code depuis quelques années déjà.

D’ailleurs, il y a eu de nombreuses publications scientifiques sur le sujet. Pour ceux que cela peut intéresser, voici quelques articles scientifiques, certains datent déjà de 2005.

  • M. Puschel et al., “SPIRAL: Code Generation for DSP Transforms,” in Proceedings of the IEEE, vol. 93, no. 2, pp. 232-275, Feb. 2005, doi: 10.1109/JPROC.2004.840306.
  • Usman, Muhammad & Nadeem, Aamer. (2009). Automatic generation of Java code from UML diagrams using UJECTOR. International Journal of Software Engineering and Its Applications. 3. 
  • Chris J. Maddison and Daniel Tarlow (2014). Structured Generative Models of Natural Source Code, CoRR, abs/1401.0514.
  • Mou, L.,Men, R., Li, G., Zhang, L., & Jin, Z. (2015). On End-to-End Program Generation from User Intention by Deep Neural Networks
  • Xiaodong Gu, Hongyu Zhang, Dongmei Zhang, and Sunghun Kim. 2016. Deep API learning. In Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2016). Association for Computing Machinery, New York, NY, USA, 631–642.

Technologiquement parlant, la génération automatique de code est passée par plusieurs phases : il y a d’abord eu des moteurs de règles — c’est-à-dire de la programmation classique —, ensuite des méthodes statistiques telles que les chaines de Markov, et enfin des réseaux de neurones de plus en plus complexes, jusqu’aux transformers — nous y reviendrons plus bas.

Nous sommes en train de passer un cap.

Ces méthodes deviennent de plus en plus efficaces ; c’est pourquoi nous pensons qu’il est temps de rédiger un article sur le sujet. Nous allons analyser quelques démos de modèles d’IA capables d’écrire du code ; ces exemples fleurissent sur les réseaux sociaux tels que Twitter, Reddit, etc.

Ces prototypes sont très impressionnants. Ils sont si spectaculaires qu’il y a de quoi devenir suspicieux: ces technologies fonctionnent-elles réellement, ou bien est-ce que ces démos sont des leurres marketing ? Commençons dès maintenant notre exploration.

Nous avons été interpellés par un tweet.

Son auteur est le CEO d’une startup  « tech » de San Francisco. Dans ce tweet, nous découvrons une zone de texte à gauche, dans laquelle un utilisateur décrit une application. La description mentionne un bouton pour ajouter 3 dollars, un autre bouton pour retirer 5 dollars, puis précise que le solde du compte doit être affiché.

Ensuite, lorsque l’utilisateur clique sur un bouton « générer », nous voyons sur la partie droite de l’écran que la description est devenue réalité : il y a bien une petite interface avec deux boutons et un affichage du solde du compte.

Pour ceux qui, parmi vous, sont des développeurs « front end », nous pouvons voir plus loin dans l’extrait que du code React-Javascript a été rédigé. Il y a un « component », deux fonctions, un « état » qui contient le solde du compte, et un peu plus bas, nous trouvons du code en JSX — qui permet de rendre la partie visuelle en HTML.

Est-ce que cet exemple est bien réel ? Sans doute. Mais nous devons garder l’esprit critique ;nous verrons plus loin dans cet article qu’il serait hasardeux de tirer des conclusions sur base d’une telle démo. Mais avant d’aller plus loin dans cette réflexion, regardons quelle technologie se cache derrière ce genre d’outils.

Comment ces générateurs de code fonctionnent-ils ?

La technologie derrière ces générateurs de codes, ce sont des modèles de langage. C’est-à-dire des modèles d’intelligence artificielle capables de générer du texte… sur base de texte.

Ils peuvent être utilisés dans différentes tâches. L’un des exemples les plus évidents est l’autocomplétion. Vous en faites tous l’expérience, lorsque vous écrivez un message avec votre téléphone, ou lorsque vous rédigez un e-mail en utilisant « Gmail Smart Compose ».

Un autre usage des modèles de langage est la traduction automatisée. C’est le cas, par exemple, lorsque vous utilisez Google Traduction. Et il y a d’autres exemples encore : la reconnaissance optique de caractère, la reconnaissance de la parole pour interagir avec un assistant virtuel — tel que Siri ou Alexa —, ou encore, tout simplement, la recherche d’information via des moteurs tels que Google.

Ces outils s’améliorent jour après jour.

Vous avez sans doute constaté comme, depuis quelques années, les outils de traduction automatisée, de reconnaissance vocale, d’autocomplétion, etc., sont devenu de plus en plus performants. Il s’éloigne, le temps où l’on riait des traductions maladroites de Google Traduction.

Grâce aux progrès des modèles de Deep Learning utilisés dans le traitement automatisé du langage, et plus spécifiquement aux développements des modèles de type « transformers » et leurs mécanismes d’attention, ces modèles de langage ont aujourd’hui ont une compréhension très solide du français, de l’anglais, de l’allemand, etc.

Les langages de programmation sont-ils des langages comme les autres ?

Bien entendu, les langages de programmation n’ont pas les mêmes particularités que les langages naturels. Cependant, très vite, d’aucuns ont réalisé que des modèles tels que GPT-3 d’OpenAI, une fois entraînés sur de grands volumes de pages Web, étaient capables de générer des fragments de codes.

Pour quelle raison ? Simplement parce qu’ils avaient eu accès à des morceaux de codes, notamment dans le contenu de certaines pages Wikipédia. Et comme la méthode d’entrainement de ces modèles d’IA, incluant notamment le Masked Langage Modelling, permet d’apprendre à prédire un mot sur base de son contexte — et ce même s’il s’agit d’un morceau de code —, ces modèles ont en quelque sorte appris à générer du code.

Ces modèles sont donc parfaitement à même de générer du code… sur base de code — voire sur base de descriptions en anglais, sous la forme de commentaire de code. Nous envisageons d’expérimenter cela dans un prochain article.

Le potentiel économique de la génération de code est énorme.

Les progrès que nous faisons dans l’autocomplétion, la traduction automatisée, etc., impactent donc également l’écriture automatique de code. Et les entrepreneurs l’ont bien compris :  plusieurs startups émergent et cherchent à lever des fonds dans ce domaine. Sans surprises, elles n’ont pas trop de mal à trouver des investisseurs.

La raison pour laquelle cela intéresse les investisseurs est que le retour sur investissement est potentiellement grand. Écrire du code est un processus chronophage. De surcroit, les développeurs sont une ressource rare. Et ces défis s’inscrivent dans un marché du développement d’applications en perpétuelle croissance.

D’après Grand View Research, la valeur du marché de développement de logiciel est de près de 400 milliards de dollars — deux fois le PIB de la Grèce par exemple — et devrait augmenter de 10% en cinq ans. Du coup, pour faire face à ces défis, beaucoup cherchent des alternatives.

Par exemple, vous avez sans doute entendu parler du « low code » ou « no code ». L’idée est de pouvoir concevoir des applications sans rédiger de ligne de code, grâce à des interfaces graphiques qui seraient bien pensés. Ce type d’outils devient mature aujourd’hui et il existe de plus en plus de solutions sur le marché. D’ailleurs, la société de conseil Gartner — qui est un peu le Guide Michelin des technologies — propose pas mal de documentation sur le sujet ; apparaître dans les rapports Gartner, c’est souvent un signe de maturité et de potentiel pour une technologie.

Une étude de marché réalisée par Forrester estime que ce marché atteindrait  21 milliards de dollars en 2022. Bien entendu, le « low code » n’est pas le sujet de cet article. Mais ces quelques données montrent le potentiel économique de ces solutions, et soulignent la problématique du coût du développement de logiciel. Il est probable que la génération automatique de code ait un potentiel au moins similaire ; c’est pourquoi il y aura probablement de plus en plus d’investissements dans cette discipline au cours des prochaines années.

Cette technologie va-t-elle mettre les développeurs au chômage ?

Ne faisons pas durer le suspens plus longtemps : il est peu probablement que cette technologie remplace les développeurs. En réalité, les premiers utilisateurs de ces algorithmes de génération de code seront les développeurs eux-mêmes.

Si nous considérions la démo dont nous parlions plus haut dans cet article, qui construisait une application React sur base d’une description en anglais : qui utiliserait un tel outil ?

Quelqu’un ne pouvant pas coder serait incapable d’utiliser un tel outil, car le code généré est loin d’être parfait : il faut l’ajuster, le refactorer, l’adapter au contexte plus large dans lequel ce morceau de code doit s’inscrire ; autant de tâches qui nécessitent un développeur.

Prenons maintenant cet autre exemple, qui vient de la même société : un utilisateur décrit en anglais  « un bouton qui ressemble à une pastèque » et l’outil génère un peu de HMTL qui représente  un bouton rond, coloré en rose avec une bordure verte, comme une pastèque. Honnêtement, c’est impressionnant. Mais on ne peut pas dire qu’un tel fragment de code soit prêt à être mis en ligne.

Est-ce que ces démos sont réalistes ?

Il est important de prendre en compte l’intention de ceux qui publient ce genre de démonstrations. Ces démos ne viennent pas de la communauté des bloggers qui cherchent à partager de la connaissance, elles sont plutôt créées par des entrepreneurs qui cherchent à gagner en visibilité pour attirer des investisseurs ou se constituer une base de client. D’ailleurs, Debuild.co qui est à l’origine de ces deux exemples est clairement dans une démarche de levée de fond, nous pouvons le voir sur CrunchBase. La société ne partage son code ni n’explique sur quelles données son modèle a été construit. Même si c’est regrettable, c’est son droit le plus strict. Là n’est pas la question.

De plus, il est difficile de tester ces outils. Dans le cas de Debuild.co, il est théoriquement possible d’expérimenter le générateur, mais il faut remplir un formulaire plein de données personnelles pour être dans une liste d’attente sans garantie de pouvoir l’essayer. Ce qui est une pratique plutôt discutable, comme l’a noté cette personne sur un post Reddit.

Malgré cet aspect promotionnel évident, ces exemples ne sont pas pour autant des impostures. Ces morceaux de code ont probablement bien été générés par des modèles d’intelligence artificielle. Les auteurs de ces démos n’ont aucun intérêt à créer un scandale.

Par contre, il est fort probable qu’ils aient choisi des exemples « parfaits » parmi un grand nombre d’exemples qui ne fonctionnent pas. Sur HackerNews, un utilisateur parle de « cherry picking ». Ce terme décrit bien la situation, car c’est un peu comme si l’on choisissait de cueillir les belles cerises, et qu’on laissait sur le cerisier les fruits plus repoussants.

Pour illustrer cette idée, reprenons notre démo qui crée une application React : ce qu’on nous montre, c’est un algorithme qui ne fait aucune erreur. Pourtant, d’expérience, il est probable que si l’on modifie légèrement la description, par exemple en remplaçant « a button saying » par « a button that says », le code généré aurait été totalement différent, et peut-être complètement inutilisable — mais nous ne pouvons l’affirmer puisque nous n’avons pas pu essayer l’outil.

Pour ces raisons, il est peu probable que dans les prochaines années apparaissent des solutions magiques qui créent une application parfaite sur la seule base d’une description. Les développeurs n’ont donc rien à craindre.

La vraie utilité de la génération de code.

En réalité, la vraie utilité de ce genre d’alogrithme sera d’améliorer les outils d’autocomplétion pour les développeurs. Par exemple, il y a quelques mois, Microsoft a publié un article dans lequel il présente IntelliCode Compose.

Dans cet article, les chercheurs ont fait du  « fine-tuning » d’un modèle GPT d’Open AI en l’entrainant sur un corpus de 52 000 repositories provenant de GitHub. Ils ont obtenu des résultats encourageants :  leur générateur de code a une « edit similarity » d’environ 87%. Pour expliquer simplement ce chiffre, disons que c’est un peu comme si 9 recommandations sur 10 étaient conformes à ce qu’aurait codé un humain.

La raison pour laquelle Microsoft a exploré la génération de code, c’est parce que la société possède l’un des éditeurs de code le plus utilisé au monde: VSCode. L’idée sera sans doute à l’avenir de proposer aux utilisateurs de l’outil une autocomplétion « intelligente » du code. L’adjectif sert ici à différencier ce service de l’autocomplétion « naive », déjà utilisée par tous les développeurs, et qui se base soit sur les librairies que l’on a installées dans notre environnement, soit sur les variables que l’on a mentionnées plus haut dans notre code.

L’idée de l’autocomplétion intelligente, c’est d’aller plus loin : de comprendre l’intention du développeur et de lui proposer des patterns non encore présents dans son code ou dans son environnement. Au fond, c’est un peu comme si l’on interrogeât StackOverflow en temps réel et à mesure que l’on rédige le code.

D’ailleurs, il existe déjà des outils qui proposent ce genre de services, notamment Kite ou TabNine. Ce dernier utilise un modèle d’intelligence artificielle appelé « Deep Tabnine » — également basé sur GPT d’OpenAI. Il est présenté sur leur blog, n’hésitez pas à aller jeter un oeil.

Nous pouvons donc imaginer que la génération automatique de code, poussée par les progrès réalisés dans le traitement automatisé du langage, va prochainement devenir une réalité. Mais, loin de remplacer les développeurs, celle-ci deviendra très probablement un outil à leur service.

Références et liens utiles