IA et développement logiciel : où va-t-on ?

Petits rappels autour des IAG

Le but de cette partie n’est pas de rappeler tous les aspects théoriques et techniques derrière les IAG reposant sur des grands modèles de langages (les seules considérées ici), mais de rappeler les quelques éléments nécessaires pour comprendre la suite.

Une IAG est un programme qui, à partir d’un modèle appris sur des données, génère une suite probable à un texte appelé prompt. Il est à noter que le processus est en fait itératif : à partir du prompt, l’IAG ne génère que le « mot » suivant. Le mot généré est alors rajouté au prompt précédent, et on réitère le processus avec ce prompt prolongé. Suivant les cas, le prompt initial peut être :

La plupart des outils interactifs comme ChatGPT rentrent dans le deuxième cas. Un préambule (non communiqué) est ajouté afin d’obtenir des réponses plus pertinentes. Les assistants de code comme Github copilot relèvent du troisième cas : en général l’utilisateur n’interroge pas explicitement l’outil ; un prompt est régulièrement créé à partir du code en cours de développement et est envoyé à l’assistant, qui propose alors une complétion probable du code.

Utilisation des IAG par les équipes de développement

Dans le cadre du développement, différents usages des IAG sont mis en œuvre, parmi lesquels :

Dans le cas du développement de code (que ce soit le code de l’application ou le code de test), deux façons de procéder sont souvent envisagées :

Dans le premier cas, l’IAG apparaît comme un outil de complétion de code amélioré. Mais là où les outils classiques de complétion de code se limitent à ne proposer que des complétions courtes lorsque la liste de complétions possibles est fortement limitée, les IAG vont bien au-delà, en proposant des complétions longues (des blocs d’instructions ou des sous-programmes complets) dans des contextes très ouverts. La confusion entre les outils, tout comme la diminution des cas d’hallucination flagrante de la part des outils d’IAG a soudainement amené les équipes de développement à adopter massivement ces outils au cours de l’année 2024, comme le montre [2].

Dans le second cas, on obtient souvent très rapidement un programme semblant répondre au problème posé. Les contextes pris en compte par les IAG ayant par ailleurs beaucoup augmenté, la taille des problèmes pouvant être traités a également grandement augmenté.

Conséquences

Effondrement possibles des IAG et perte de diversité du code

Les IAG sont entraînées à partir des données trouvées sur Internet. Mais comme le montrent les études déjà citées, le code présent sur Internet est de plus en plus généré par des IAG. Or plusieurs études (comme [3]) tendent à montrer que les IAG s’écroulent lorsqu’elles apprennent de leurs propres résultats. Par ailleurs, dans les sciences du vivant, il a été montré dans de nombreuses circonstances, qu’un être vivant — ou son patrimoine génétique — pour être robuste, doit être diversifié [4]. Or la multiplication de code produit par IA mène à une uniformité du code. En perdant ainsi en diversité dans la mémoire collective que constituent les entrepôts de code, on risque aussi de perdre en robustesse : même avec des recherches Web « classiques », la recherche de solutions par des équipes de développement fournira des résultats similaires, diminuant ainsi les chances de produire de meilleures solutions par hybridation de solutions existantes.

IA et test : le grand danger

Si, pendant longtemps, le test logiciel a été très empirique, les choses ont maintenant bien changé. C’est un domaine de l’informatique à part entière permettant d’apporter de réelles garanties sur le bon fonctionnement d’un logiciel. Et même si l’activité de test devrait être considérée comme une activité particulièrement riche intellectuellement [5], elle reste souvent vue comme une perte de temps par les employeurs et comme une écriture pénible quasi automatique de code par les équipes de développement.

Aussi, de nombreux travaux proposent d’utiliser les IAG pour écrire ces fameux cas de test [6]. C’est malheureusement le contraire de ce qui devrait être fait. En effet, comme cela a déjà été rappelé, les IAG ne génèrent que du « probable », et n’ont aucune notion du « correct ». Ainsi, une IAG, pourra générer un cas de test à partir d’un simple commentaire de code — potentiellement erroné — ou du code déjà écrit, générant alors un cas de test biaisé. J’ai notamment pu constater que des responsables d’équipes de développement pensaient qu’une simple mesure de couverture de code suffisait à évaluer la production de cas de tests par une IAG !

Si, à terme, le développement devait utiliser massivement les IAG, l’écriture des tests devrait au contraire être le dernier endroit où les utiliser.

Aspects écologiques

Les IA reposant sur l’apprentissage sont, de manière générale, des systèmes assez gourmands en énergie. Mais cela est pire pour les IAG, pour lesquelles non seulement le processus d’apprentissage est ultra-gourmand (en énergie, comme en matières premières), mais le processus d’utilisation est également très gourmand. Les chiffres sur le sujet restent en général flous : entre les aspects confidentiels et les différents outils disponibles, il n’est guère possible d’avoir une estimation précise. Par ailleurs, suivant les pays, l’électricité nécessaire au fonctionnement de ces outils est produite de manière plus ou moins renouvelable. Mais, même si une requête vers ces outils ne consommait pas plus qu’une simple requête dans un moteur de recherche, il faut prendre en compte la fréquence d’utilisation : en utilisant des IAG comme « outils de complétion de code améliorés », on peut considérer que chaque période d’inactivité d’au moins une seconde d’un développeur va générer une requête. Ce sont donc des centaines de requêtes quotidiennes supplémentaires par développeur qui vont finalement être générées. Les énergies renouvelables ne produisent actuellement dans le monde qu’environ 30 % de l’électricité. En augmentant ainsi la consommation électrique, une partie non négligeable des nouveaux sites de production d’énergie renouvelable ne sera pas consacrée à diminuer la production de gaz à effet de serre et la consommation de ressources fossiles, mais sera consacrée à absorber cette augmentation de la demande. Ce problème n’est cependant pas propre au développement informatique, donc je n’en parlerai pas davantage, même si c’est un problème fondamental, qui doit être pris en considération dans l’éventuelle utilisation de l’IAG comme aide au développement de logiciels.

Formation

La percée des IAG influe également sur la façon dont nous devons mener nos formations au développement.

En effet, il est clair maintenant que la quasi-totalité des exercices de programmation « de base » peuvent être résolus par une IAG. Faut-il alors sauter cette étape ? Certainement pas : les concepts de base doivent être parfaitement acquis. Ce n’est pas parce que les calculatrices existent qu’on n’apprend plus les bases du calcul à l’école. Bien sûr, avant l’avènement des IAG, on trouvait déjà beaucoup d’exercices corrigés sur Internet. Mais il y avait toujours un travail minimum d’adaptation à faire, difficile pour un élève n’ayant pas les bases (j’ai déjà vu un élève rendre du PL/SQL alors que seul PL/pgSQL avait été présenté et pratiqué pendant toute l’année). Mais maintenant, les IAG font ce travail en totale autonomie. Il est important d’en avoir conscience et d’évaluer les élèves dans des contextes où les IAG ne sont pas utilisables (examen sur papier, mise en place d’un firewall, etc.).

Par ailleurs, il faut également avoir conscience que les élèves utiliseront de toutes façons les IAG. Il n’est donc plus possible de les ignorer. Il devient nécessaire de former les élèves à leur utilisation : détailler les risques, la place qu’elles peuvent prendre dans leurs études, et montrer leurs limites. Ainsi, en licence 3, je pratique beaucoup de live coding, c’est-à-dire que je développe en direct du code devant les étudiants, que ce soit pour illustrer directement un point de cours ou pour répondre à une question d’un étudiant. J’en profite alors pour montrer et commenter les suggestions de Github copilot : si certaines de ses propositions sont assez bluffantes, je jette ou modifie à peu près 80 % de ce qu’il me propose.

Il semble toutefois que les IAG vont de plus en plus réussir à produire des « unités de code » correctes : fonctions relativement standard, classes relativement simples. Mais elles risquent d’avoir du mal, à terme, à produire des applications de taille « raisonnable ». Le travail de développement que peut faire un technicien risque ainsi, à terme, de pouvoir être en partie effectué par une IAG. Mais ce ne sera probablement pas le cas de tâches que l’on demande à un bac + 5. Il est donc impératif de proposer un maximum de passerelles permettant d’amener tout développeur qui le peut à un niveau bac + 5. Le développement de la spécialité NSI (incluant d’en faire un prérequis pour les formations en informatique) pourrait permettre de faciliter grandement les choses.

La promotion actuellement faite par certaines personnes du vibe coding est un risque important à prendre en compte : de plus en plus de développeurs en font la promotion, et ils trouvent un certain écho y compris sur la place publique : certains annoncent même la fin du métier de développeur. Pourtant les défauts du code produit par les IA sont bien là, et il est particulièrement important d’insister auprès des étudiants sur tout le contrôle qu’il faut avoir sur du code produit par IA.

En attendant, dans le cadre de mes enseignements, je présente deux grands types d’information à mes étudiants, détaillés dans les deux sections suivantes.

En guise de conclusion

La fin du métier de développeur n’est pas pour demain. Les intelligences artificielles génératives peuvent parfois apporter un gain de temps appréciable, mais elles doivent être utilisées avec rigueur et parcimonie, en pleine conscience de leurs nombreuses limites.

Références bibliographiques