Pourquoi l’IA ne programme pas encore seule, selon une étude du MIT

L’idée d’un logiciel entièrement conçu, corrigé et maintenu par une intelligence artificielle est séduisante. Les outils capables de proposer une fonction, d’expliquer un message d’erreur ou de compléter un fichier ont déjà changé une partie du travail quotidien des développeurs. Mais passer de cette assistance à une ingénierie logicielle autonome suppose de résoudre des problèmes beaucoup moins visibles que l’écriture de quelques lignes de code.

C’est le constat d’une étude interactive du laboratoire MIT CSAIL, intitulée Challenges and Paths Towards AI for Software Engineering. Au 19 juillet 2025, ses auteurs invitent à regarder au-delà des démonstrations impressionnantes de génération de code. Leur sujet n’est pas de nier l’utilité de l’IA, mais de décrire précisément ce qui lui manque encore pour intervenir de façon sûre et pertinente dans les projets logiciels réels.

Générer du code ne suffit pas à faire de l’ingénierie logicielle

Dans le débat public, programmer est volontiers réduit à une suite d’instructions que l’on pourrait déléguer à un modèle d’IA. Or, dans une entreprise ou au sein d’un projet open source, écrire du code n’est qu’une étape parmi d’autres. Il faut comprendre un besoin parfois imprécis, se conformer à une architecture existante, tenir compte des dépendances techniques, vérifier la sécurité, tester les modifications et s’assurer que le changement ne crée pas de régression ailleurs.

Armando Solar-Lezama, auteur principal de l’étude, met en garde contre cette vision trop réduite : « Le discours actuel réduit souvent le domaine à une simple programmation universitaire. » Dans la pratique, souligne-t-il, les équipes ne travaillent pas uniquement sur une fonctionnalité isolée. Elles doivent aussi composer avec des migrations complexes portant sur des codes de plusieurs millions de lignes.

Cette différence est décisive. Une demande courte, telle que « écris une fonction qui trie une liste », contient un objectif clair et un périmètre restreint. À l’inverse, modifier un logiciel ancien peut impliquer des services interdépendants, des outils internes, des conventions documentées de manière incomplète et des contraintes propres à l’organisation. Le code proposé doit alors être compatible avec tout ce qui l’entoure, y compris ce que l’IA ne voit pas dans son contexte immédiat.

Quelles tâches posent problème aux outils d’IA ?

Les chercheurs du MIT CSAIL identifient plusieurs travaux essentiels qui dépassent la simple création de nouvelles fonctions. Ils citent notamment le refactoring, l’analyse des bugs de concurrence et la migration de systèmes hérités. Ces opérations sont moins spectaculaires qu’une application créée à partir d’une consigne, mais elles occupent une place majeure dans la vie d’un logiciel.

Le refactoring illustre bien l’écart entre une suggestion locale et un travail d’ingénierie. Il ne s’agit pas seulement de réécrire un bloc pour le rendre plus lisible. Il faut conserver le comportement attendu, respecter les interfaces utilisées par d’autres parties du logiciel et vérifier que la nouvelle organisation reste maintenable. Une mauvaise modification peut introduire un défaut discret qui ne se révélera que beaucoup plus tard.

Les bugs de concurrence sont un autre cas complexe. Ils surviennent lorsque plusieurs opérations se déroulent simultanément et interagissent de façon imprévue. L’erreur peut ne se produire que dans un ordre très particulier d’événements. Une IA peut proposer une correction convaincante à première vue, sans pour autant avoir la garantie que celle-ci couvre toutes les situations possibles.

Enfin, les migrations de systèmes hérités demandent une compréhension de l’histoire technique du projet. Un code ancien peut contenir des choix qui semblent inutiles, mais répondent en réalité à une contrainte encore active. Retirer ou remplacer ces éléments sans disposer du bon contexte peut déstabiliser l’ensemble du système.

Pourquoi le contexte d’entreprise échappe encore aux modèles

Les modèles d’IA générative produisent des réponses à partir des régularités apprises dans de grandes quantités de textes et de code. Cette capacité leur permet de formuler rapidement des propositions cohérentes. Cependant, elle ne leur donne pas automatiquement accès à l’ensemble des connaissances qui structurent un projet précis.

Chaque base de code possède ses particularités : conventions de nommage, bibliothèques autorisées, règles de sécurité, interfaces internes, historique des décisions techniques ou processus de validation. Ces informations peuvent être réparties entre le code, des documents, des discussions d’équipe et l’expérience des personnes qui entretiennent le logiciel.

L’étude souligne que la taille même des projets constitue une barrière importante. Face à des bases comprenant des millions de lignes, les modèles peinent à conserver une vision suffisamment fiable de l’ensemble. Ils peuvent alors générer un code qui paraît adapté, mais qui appelle une fonction inexistante ou ne respecte pas la structure réelle du programme.

C’est ce que l’on désigne souvent par le terme d’« hallucination » : l’IA produit une réponse crédible dans sa forme, mais erronée dans son contenu. Dans le développement logiciel, le risque ne consiste pas uniquement à obtenir une explication inexacte. Une référence inventée, une hypothèse erronée sur une interface ou une logique inadaptée peut se retrouver dans un produit utilisé par des clients ou des salariés.

Une communication homme-machine encore trop limitée

Pour les auteurs, l’un des obstacles majeurs se situe dans l’interface entre la personne qui développe et l’outil qui assiste. Le rapport décrit une « mince ligne de communication » entre l’humain et la machine. Une consigne écrite, même détaillée, ne transmet pas nécessairement les intentions, les compromis et les connaissances implicites nécessaires à une bonne décision technique.

Le résultat peut prendre la forme de fichiers volumineux et peu structurés, plus difficiles à examiner qu’une modification limitée et clairement justifiée. Or, relire le code est une part essentielle du travail : il ne suffit pas qu’une proposition existe, il faut pouvoir comprendre ce qu’elle change, pourquoi elle le change et quelles conséquences elle peut avoir.

L’étude relève également que les modèles actuels n’exposent pas leur niveau de confiance pour les différentes parties du code généré. Dans un environnement professionnel, cette absence de signal peut être problématique. Un développeur pourrait accorder le même degré de confiance à une modification fondée sur un contexte bien identifié et à une autre qui repose sur une supposition fragile.

Rendre les échanges plus utiles ne signifie donc pas seulement produire des réponses plus longues. Cela suppose des outils capables d’aider à délimiter le périmètre d’une modification, à faire apparaître les hypothèses prises et à faciliter l’évaluation humaine du résultat.

L’IA peut-elle remplacer les développeurs ?

L’étude ne présente pas l’automatisation comme un remplacement immédiat des ingénieurs logiciels. Elle décrit plutôt une trajectoire dans laquelle l’IA peut contribuer à réduire la charge des tâches répétitives, tandis que les personnes se concentrent davantage sur les problèmes complexes, créatifs et contextuels.

Cette distinction est importante. Le développeur ne se limite pas à produire la syntaxe d’un programme. Il formule les bonnes questions, arbitre entre plusieurs solutions, interprète des besoins contradictoires, vérifie les conséquences d’un changement et assume la responsabilité des décisions prises. Lorsqu’un outil propose du code, ces activités ne disparaissent pas : elles peuvent même devenir plus importantes si la quantité de modifications à examiner augmente.

Le risque serait de confondre rapidité de production et qualité du logiciel. Une IA peut accélérer la rédaction initiale d’un morceau de code, mais le gain réel dépend ensuite du temps consacré à le comprendre, le tester, l’intégrer et le corriger. Dans les systèmes où robustesse et sécurité comptent, une proposition non vérifiée peut coûter plus cher qu’un développement plus lent mais maîtrisé.

La question n’est donc pas simplement de savoir si une IA « sait programmer ». Elle est de déterminer dans quelles conditions elle peut aider sans dégrader la qualité, la sécurité ou la compréhension collective d’un projet. Pour l’utilisateur d’un assistant de code, cela implique de traiter les suggestions comme des propositions à examiner, et non comme des décisions prêtes à être déployées.

Des données partagées et de meilleurs tests pour progresser

Face à ces limites, les auteurs appellent à un effort collectif. Ils suggèrent de constituer des bases de données riches et partagées, capables de documenter les véritables processus de développement logiciel. L’enjeu est de rapprocher l’apprentissage et l’évaluation des outils des situations rencontrées par les équipes, plutôt que de les limiter à des exercices courts et isolés.

Ils proposent également de créer des suites d’évaluation qui mesurent la qualité des refactorings. Évaluer une modification de code ne revient pas seulement à vérifier qu’elle s’exécute. Il faut aussi s’intéresser à la préservation du comportement attendu, à l’intégration dans le projet et à la qualité de la transformation réalisée.

Gu, l’un des coauteurs, appelle dans ce cadre à des collaborations open source. Cette logique de partage peut permettre de réunir des pratiques, des méthodes d’évaluation et des retours d’expérience qui seraient difficiles à constituer par une seule organisation. Elle pose néanmoins une question pratique importante : les données de développement peuvent contenir des éléments propres à une entreprise. Les efforts communs devront donc concilier utilité des informations partagées et respect des contraintes de chaque projet.

Ce qu’il faut surveiller pour l’ingénierie logicielle autonome

Les prochaines avancées ne se mesureront pas seulement à la capacité d’un modèle à écrire davantage de lignes de code. Elles dépendront de sa faculté à travailler dans des projets vastes, à se conformer à des règles locales et à rendre ses propositions contrôlables par les équipes humaines.

Trois évolutions seront particulièrement révélatrices : la qualité des évaluations sur des tâches réelles comme le refactoring, la capacité des outils à gérer le contexte d’une grande base de code, et l’amélioration des interfaces de collaboration avec les développeurs. Des assistants plus transparents, qui signalent clairement leurs hypothèses et les zones incertaines, seraient plus faciles à intégrer dans des processus rigoureux.

L’étude du MIT CSAIL ramène ainsi le débat à une réalité simple : produire du code est différent de concevoir, maintenir et faire évoluer un logiciel fiable. L’IA peut devenir un appui précieux pour les ingénieurs, en particulier sur les tâches routinières. Mais l’autonomie complète reste conditionnée par des défis de contexte, de fiabilité, d’évaluation et de communication qui ne se résolvent pas par la seule génération de texte ou de code.