Ce que les LLM de code signifient pour l’avenir du développement logiciel

Nous sommes entrés dans une ère où le code est coécrit avec les machines.

Lorsque ChatGPT d’OpenAI a fait irruption sur la scène technologique, il a ouvert l’ère de l’IA générative, avec la génération de code parmi ses premiers cas d’utilisation. Les assistants de codage fondés sur l’intelligence artificielle (IA) ont ensuite suivi, depuis le pionnier GitHub Copilot jusqu’à Amazon Q Developer, Anthropic Claude Code, Google Gemini Code Assist, IBM Bob et Mistral Code.

Mais derrière ces outils de codage se cache une technologie puissante : les grands modèles de langage (LLM) pour le code. Et ils transforment la façon de développer des logiciels.

Nous avons échangé avec plusieurs experts IBM afin de mieux comprendre comment les LLM pour le code redéfinissent le rôle des développeurs logiciels, ainsi que leurs prévisions sur l’avenir de ces modèles. Ils partagent ici leurs analyses :

• Kaoutar El Maghraoui, Principal Research Scientist

• Bridget McGinn, Research Software Engineer, AI for Code

• Rameswar Panda, Distinguished Engineer

• Fumiko Satoh, Senior Technical Staff Member and Senior Manager, AI for Code and Security

Les LLM pour le code sont des modèles spécialisés entraînés sur du code source. Ils peuvent être créés de zéro ou dérivés d’un modèle préentraîné, puis affinés sur des jeux de données de codage. Ces données d’entraînement doivent être de qualité et suffisamment diversifiées pour permettre aux LLM pour le code de gérer différents scénarios de codage dans plusieurs langages de programmation.

Comme les LLM pour le code sont généralement dérivés de modèles IA conçus pour le traitement automatique du langage naturel (NLP), ils utilisent souvent des descriptions en langage naturel comme prompts. Ils peuvent accomplir les tâches de codage concrètes suivantes :

• Aider au débogage

• Compléter le code, ou autocomplete

• Génération de code

• Refactorisation de code

• Synthèse de code

• Générer de la documentation sous forme de commentaires intégrés pour des extraits de code

• Moderniser du code hérité, par exemple en convertissant du COBOL en Java

• Suggérer des optimisations de code

• Traduire du code existant d’un langage de programmation vers un autre, par exemple de Python vers JavaScript

Parmi les exemples connus de LLM pour le code figurent CodeGemma de Google, Code Llama de Meta, ainsi que Codestral et Devstral de Mistral. Les modèles de code open source incluent quant à eux DeepSeek Coder, IBM Granite Code et Qwen3 Coder.

D’autres LLM qui ne sont pas exclusivement conçus pour la programmation, mais qui ont été entraînés sur du code et optimisés pour le codage, incluent Claude Sonnet et Opus d’Anthropic, ainsi que Gemini Pro de Google.

Les LLM pour le code démocratisent l’accès à la création logicielle en accompagnant les développeurs citoyens, les experts métier et d’autres profils non traditionnels qui n’ont ni formation ni diplôme officiel en informatique. Ils permettent de prototyper rapidement, d’accélérer les cycles d’itération et de faciliter l’intégration des nouveaux ingénieurs logiciels.

Au-delà de la transformation du développement logiciel, les LLM pour le code redéfinissent le rôle des développeurs logiciels.

Selon El Maghraoui, les ingénieurs logiciels passent du rôle de producteurs de code à celui de curateurs de code. « Si le codage reste essentiel, l’accent se déplace vers le prompt engineering. Comment formuler les bonnes requêtes dans le contexte de ces LLM ? Et au lieu d’écrire chaque ligne de code, les développeurs orchestrent de plus en plus du code généré par l’IA, en assemblant les différents éléments. »

Cette évolution n’est toutefois que la partie émergée de l’iceberg. El Maghraoui estime que le rôle des développeurs évoluera vers ce qu’elle appelle l’« ingénierie pilotée par l’intention ». L’idée est de s’éloigner de la syntaxe pour se concentrer sur la structure, de laisser de côté les détails les plus fins pour prendre de la hauteur, et de passer du « quoi » au « pourquoi », en mettant en avant les objectifs, les résultats et l’impact.

Pour Bridget McGinn, les LLM pour le code peuvent être traités comme des bibliothèques importées dans un programme. « Les problèmes peuvent être résolus plus rapidement, de la même manière que les bibliothèques nous aident, en tant qu’ingénieurs, à réutiliser des fonctionnalités déjà développées au lieu de réinventer la roue. »

Cette vision rejoint l’informatique générative. Dans ce cadre, un modèle de code est intégré aux systèmes comme un composant logiciel modulaire et utilisé comme une interface programmable. À ce titre, il peut abstraire les tâches de bas niveau, tandis que les développeurs consacrent davantage d’efforts à la résolution de problèmes de plus haut niveau.

« Ils doivent penser en termes de design thinking plutôt que d’écriture de code », explique Satoh. « Nous avons besoin d’ingénieurs de plus haut niveau, capables de concevoir l’architecture d’un système. »

Ce rôle devient plus pluridisciplinaire : il intègre non seulement la conception et l’architecture, mais aussi d’autres dimensions comme l’éthique et la sécurité. « Le travail est moins manuel et davantage automatisé, mais il devient plus stratégique », explique El Maghraoui. « Vous combinez le génie logiciel avec une pensée à l’échelle des systèmes, une réflexion produit et un raisonnement éthique. Nous ne sommes plus seulement à l’aise avec le code : nous devenons des ingénieurs à l’aise avec l’IA et orientés IA dès la conception. »

Cette évolution ouvre des possibilités de montée en compétences sur ces tâches de plus haut niveau, en particulier pour les développeurs juniors. « Beaucoup de benchmarks visent à atteindre le niveau fonctionnel d’un développeur junior. Si c’est la métrique que nous visons, l’idée est donc de réduire le besoin associé à ce niveau », explique McGinn. « Nous avons besoin de profils qui disposent d’un niveau plus approfondi que celui d’un développeur junior, ou qui n’ont peut-être plus besoin de passer par un poste de développeur junior pour comprendre ce que fait un développeur senior. »

Panda souligne que, comme tout grand modèle de langage, les LLM pour le code ont leurs limites. Il recommande la prudence sur les sujets de droits d’auteur, de biais et de sécurité, en particulier lorsqu’il s’agit d’applications critiques dans des secteurs comme la finance et la santé.

« On ne peut pas leur faire aveuglément confiance », explique Panda. « Il faut toujours prendre le code qu’ils génèrent avec du recul. »

Ce scepticisme doit aussi s’accompagner de mécanismes d’optimisation des performances et de mesures de validation pour vérifier la solidité et l’exactitude du code. « Il faut continuer à écrire des cas de test et à vérifier le code avec autant de rigueur que s’il avait été écrit manuellement », explique McGinn.

El Maghraoui insiste sur l’idée de s’appuyer sur les LLM pour le code, plutôt que d’en dépendre. « Si nous les utilisons comme aide à l’apprentissage, comme pair programmer ou comme générateur d’idées, ils peuvent stimuler notre apprentissage, notre créativité et notre productivité. Mais si nous les utilisons comme une béquille, sans introspection ni validation, ils peuvent affaiblir notre jugement et notre sens des responsabilités. »

La validation n’est possible que si les développeurs maîtrisent les principes fondamentaux de l’informatique. Après tout, si vous ne comprenez pas les bases de la programmation, comment pouvez-vous confirmer la validité du code généré par ces modèles ?

« Le codage est rapide, mais il n’est pas toujours robuste, correct ou sécurisé », explique El Maghraoui. Elle ajoute qu’utiliser du code généré tel quel peut être dangereux. « Cela peut fragiliser les bases de code. Si vous vous appuyez trop sur ces modèles ou accordez une confiance excessive à leurs résultats, cela peut propager des bugs subtils ou des inefficacités, en particulier dans les systèmes critiques. C’est pourquoi il est important de comprendre ce qui se passe. »

C’est ici qu’intervient l’expertise approfondie, rendue possible par les concepts fondamentaux du développement logiciel.

« À l’école, nous apprenons encore aux élèves à poser une division à la main, mais à quoi cela sert-il s’ils utilisent ensuite une calculatrice ? C’est la même chose pour le codage. Quels sont les éléments fondamentaux que nous jugeons importants pour comprendre ce qui se passe ? », explique McGinn.

Ces bases techniques peuvent notamment inclure les compilateurs, l’architecture informatique, les bases de données, la gestion de la mémoire et les systèmes d’exploitation. « Les développeurs pourraient commencer à ne plus apprendre ces concepts en profondeur, parce que les LLM pour le code les abstraient », explique El Maghraoui. Elle ajoute toutefois qu’il est essentiel de comprendre les mécanismes internes du développement logiciel, en raison de leurs implications sur le fonctionnement et les performances du code source.

Et si les LLM pour le code peuvent réduire la charge cognitive en automatisant les tâches répétitives, ils peuvent aussi favoriser ce qu’El Maghraoui appelle une « atrophie cognitive ». Elle compare ce phénomène à l’utilisation croissante du GPS, qui affaiblit notre sens naturel de l’orientation. « Si les développeurs s’appuient fortement sur les suggestions de code, ils seront moins à l’aise avec le débogage. Les LLM pour le code peuvent affaiblir notre capacité à penser de manière algorithmique si nous ne les équilibrons pas par une pratique ou des connaissances fondamentales. »

À mesure que les LLM pour le code progressent, ils feront émerger de nouvelles fonctionnalités, voire de nouveaux cas d’utilisation, comme l’illustre la tendance du vibe coding. Que peut-on attendre de ces modèles à l’avenir ? Nos experts livrent leurs prévisions.

Le monde entier parle des agents IA et de leur capacité à transformer l’avenir du travail dans presque tous les secteurs, y compris le développement logiciel.

« Je vois une évolution vers des systèmes de codage multi-agents, avec des bases de code capables de s’auto-réparer », explique El Maghraoui. Ces systèmes d’IA agentique prennent déjà forme. Par exemple, les agents d’ingénierie logicielle (SWE) d’IBM peuvent résoudre automatiquement des issues GitHub en commençant par « localiser » les bugs dans une base de code, puis en modifiant les lignes concernées pour les corriger.

McGinn espère voir émerger une stratégie plus économe en énergie, « dans laquelle tout ne repose pas sur le plus grand modèle, mais où une approche agentique plus légère permet d’économiser de l’énergie », avec différents agents chargés de tâches de programmation spécifiques.

De la même manière, Panda se réjouit de rendre des petits modèles de langage (SLM) comme Granite Code disponibles sur des appareils aux ressources limitées, tels que les ordinateurs portables et les appareils edge. « En même temps, certaines choses sont difficiles à résoudre pour les SLM ; les grands modèles Granite entreront alors en jeu. Il s’agit d’un équilibre entre plusieurs modèles, et non d’un modèle unique censé tout résoudre. »

L’intégration d’une mémoire contextuelle et de capacités de raisonnement dans les LLM pour le code est une autre évolution à surveiller, souligne El Maghraoui. « Ils peuvent se souvenir de tout l’historique du projet et de son évolution. Cela permet de formuler de meilleures suggestions pour l’avenir. »

La composante de raisonnement facilite ce que Panda appelle les « tâches de longue durée ». « Les LLM pour le code interagiront avec vos référentiels de code pour mener de nombreuses actions séquentielles, et non une seule action ponctuelle. Ils ne pourront accomplir ces tâches que s’ils disposent de solides capacités de raisonnement. »

Aujourd’hui, les environnements de développement intégrés (IDE) intègrent les modèles de code et les assistants de codage sous forme de services ou de plugins. Mais les IDE de demain pourraient évoluer vers des environnements de développement AI-native. « Nous verrons ces IDE être repensés autour des LLM pour le code dès la conception, et non plus simplement enrichis par des plugins », explique El Maghraoui.

Elle observe également une progression des déploiements de LLM pour le code sur des infrastructures privées. Par exemple, l’assistant IA Mistral Code, alimenté par Codestral et Devstral, prend en charge le déploiement sur site.

« Les déploiements privés de ces LLM pour le code sont accélérés par des enjeux de performances, de coûts et de confidentialité », explique El Maghraoui. « Les entreprises veulent éviter d’envoyer du code propriétaire vers des API tierces. Les déploiements privés garantissent que leur code source, leurs bibliothèques internes et leurs traces de stack ne quittent jamais le réseau interne de l’entreprise. Il existe aussi des enjeux de conformité réglementaire, en particulier dans la finance ou la santé, et le coût d’exécution de cas d’utilisation à fort débit en interne peut être inférieur à grande échelle. »

L’écriture du code et la création des tests sont deux étapes distinctes du processus de développement logiciel. Satoh imagine que les LLM pour le code pourraient aider à mieux articuler ces deux étapes, en facilitant à la fois la génération de code et la génération de tests.

« Nous devrions les connecter avec le même modèle pour créer un produit fluide », explique-t-elle. Satoh va encore plus loin et anticipe des modèles de code capables de « soutenir l’ensemble du cycle de vie du développement logiciel », y compris les phases amont comme la spécification des exigences et la conception.

Mais quelle que soit la direction que prendra cette nouvelle ère du code coécrit avec les machines, El Maghraoui reste à la fois prudente et optimiste. « C’est comme une lame à double tranchant. Cela peut être quelque chose qui nous pénalise en tant que développeurs, ou qui nous aide. Il est donc essentiel de comprendre comment utiliser correctement ces LLM pour le code, afin de ne pas perdre votre avantage, mais de devenir plus créatif. » Selon elle, ceux qui ont le plus de chances de réussir seront « les développeurs et les entreprises qui adoptent ces workflows et considèrent l’IA non pas seulement comme un outil, mais comme un partenaire ».