L’IA peut-elle coder seule ? Les freins de l’ingénierie logicielle autonome

L’image d’une intelligence artificielle capable de prendre en charge seule tout le travail d’un ingénieur logiciel séduit autant qu’elle inquiète. Les assistants de programmation savent déjà proposer une fonction, expliquer un extrait de code ou suggérer un correctif. Pourtant, entre produire une réponse qui semble correcte et livrer un changement fiable dans un logiciel utilisé au quotidien, l’écart reste considérable. Une étude de chercheurs du MIT, intitulée « Challenges and Paths Towards AI for Software Engineering », s’intéresse précisément à cette distance.

Le constat est simple : programmer n’est qu’une partie de l’ingénierie logicielle. Dans une entreprise, un développeur doit comprendre une demande parfois imprécise, retrouver les composants concernés dans une vaste base de code, respecter des règles internes, écrire ou adapter des tests, documenter son travail, puis vérifier que la modification ne crée pas de régression. Les outils d’IA générative peuvent accélérer plusieurs de ces étapes, mais ils ne les maîtrisent pas encore de façon suffisamment fiable pour travailler sans supervision.

Écrire du code n’est pas encore faire de l’ingénierie logicielle

La génération de code est la capacité la plus visible des modèles d’IA. À partir d’une instruction en langage naturel, ils peuvent proposer une requête, un script, une interface ou une fonction. Cette aptitude est utile, en particulier pour les tâches répétitives ou pour explorer rapidement une idée. Mais l’ingénierie logicielle désigne un travail plus large : il faut concevoir un système qui reste compréhensible, sûr et maintenable dans le temps.

L’étude du MIT insiste sur les tâches qui disparaissent facilement des démonstrations, alors qu’elles occupent une place importante dans les équipes techniques. Parmi elles figurent les refactorisations quotidiennes, c’est-à-dire des réorganisations du code qui n’ajoutent pas nécessairement de fonctionnalité mais améliorent sa lisibilité ou sa solidité. Les migrations de systèmes anciens constituent un autre défi majeur : elles impliquent souvent de modifier de nombreux composants sans interrompre un service existant.

Ces travaux demandent une compréhension fine du contexte. Une même modification peut être techniquement correcte tout en contredisant une décision d’architecture prise des années auparavant, une règle de sécurité interne ou une contrainte métier inconnue du modèle. Le code n’est donc pas un texte isolé : il est lié à des personnes, des procédures, des outils et une histoire technique.

Pourquoi les benchmarks actuels ne suffisent pas

Pour savoir si les IA progressent, il faut pouvoir les mesurer. Or, les chercheurs soulignent que les indicateurs actuels ne représentent pas toujours les situations rencontrées dans les entreprises. SWE-bench est l’un des cadres de référence cités dans l’étude. Il demande à des modèles de corriger des problèmes réels provenant de dépôts GitHub.

Ce type de test constitue une avancée par rapport à de simples exercices de programmation : il place les modèles face à des problèmes associés à des projets logiciels. Mais il ne couvre pas à lui seul toute la réalité de l’ingénierie à grande échelle. Une correction ponctuelle n’évalue pas nécessairement la capacité à travailler avec un collègue humain, à modifier une architecture complexe ou à garantir qu’un correctif restera valable après les évolutions futures du logiciel.

Le problème n’est pas seulement de savoir si le programme compile ou si un test passe. Un changement peut réussir une batterie de tests limitée tout en introduisant une dette technique, en compliquant la maintenance ou en créant une fragilité qui ne se révélera que plus tard. Pour les auteurs, il faut donc élargir les critères afin de mesurer des scénarios plus proches du travail réel.

Une meilleure mesure des performances ne serait pas un détail méthodologique. Elle déterminerait les progrès réellement accomplis. Tant qu’un outil est évalué principalement sur des tâches isolées, ses résultats ne permettent pas de conclure qu’il saura évoluer dans un projet de plusieurs années, avec des millions de lignes de code et de multiples équipes.

Le problème central de la communication entre humain et machine

L’autonomie dépend aussi de la qualité de l’échange. Alex Gu, premier auteur de l’étude, décrit l’interaction actuelle entre développeurs et systèmes d’IA comme une ligne de communication insatisfaisante. Souvent, l’outil renvoie des fichiers ou des modifications peu structurés. Le développeur doit alors reconstituer le raisonnement suivi, repérer les hypothèses implicites et décider seul quelles parties nécessitent une vérification approfondie.

Ce défaut de dialogue est particulièrement sensible lorsque l’IA n’indique pas son niveau de confiance. Toutes les lignes de code générées ne se valent pas. Certaines reposent sur des éléments explicitement fournis par l’utilisateur, d’autres sur une interprétation incertaine de la demande ou sur une connaissance incomplète du projet. Sans signalement clair des zones ambiguës, l’ingénieur peut accorder sa confiance à une proposition dont la logique de départ est erronée.

Un assistant plus utile ne devrait donc pas seulement produire du code. Il devrait pouvoir expliquer ce qu’il a modifié, signaler les hypothèses qu’il a retenues, identifier les éléments qu’il n’a pas pu vérifier et demander une précision lorsque la demande est ambiguë. Cette capacité à interrompre l’automatisation pour poser une question est essentielle : dans un projet réel, choisir une mauvaise interprétation peut coûter davantage de temps que l’écriture manuelle du code.

Le contrôle humain ne doit pas être compris comme un frein à l’automatisation. Il est le mécanisme qui permet de l’employer de manière responsable. Dans les systèmes logiciels, une erreur peut se propager : une fonction incorrecte peut être appelée ailleurs, une convention rompue peut rendre les contributions suivantes plus difficiles et une défaillance passée inaperçue peut atteindre la production.

Les immenses bases de code restent un terrain difficile

Les difficultés s’accentuent lorsque les modèles doivent intervenir dans de très grandes bases de code. Les chercheurs évoquent des projets pouvant atteindre des millions de lignes. À cette échelle, aucune personne ne connaît tout le logiciel dans le détail. Les équipes s’appuient sur des conventions, une documentation, des tests, des revues de code et des règles d’organisation pour maintenir une compréhension collective.

Les modèles d’IA sont fréquemment entraînés sur des dépôts publics, notamment disponibles sur GitHub. Or, le code d’une entreprise comporte souvent des spécificités absentes de ces données : bibliothèques internes, noms de fonctions propres à l’organisation, pratiques de sécurité, choix architecturaux et exigences liées au métier. Même un modèle très compétent sur du code généraliste peut alors se retrouver hors de son domaine de compétence.

Le résultat peut sembler convaincant à première vue. L’IA peut écrire un appel vers une fonction au nom plausible, proposer une structure conforme aux habitudes générales d’un langage ou reproduire un motif courant. Mais la fonction peut ne pas exister dans le projet concerné, la règle de style peut être enfreinte ou les contrôles automatiques de l’intégration continue peuvent échouer. Ces réponses plausibles mais fausses sont souvent qualifiées d’hallucinations.

Dans le développement logiciel, une hallucination n’a pas besoin d’être spectaculaire pour être coûteuse. Un import inexistant, une mauvaise version d’une dépendance ou une hypothèse erronée sur une interface peuvent bloquer une livraison. Cela explique pourquoi l’examen humain, les tests automatisés et les outils de contrôle demeurent indispensables, même lorsqu’un assistant accélère fortement la rédaction initiale.

Des données et des critères communs pour progresser

Face à ces limites, les auteurs appellent à une mobilisation plus large de la communauté. Leur proposition repose notamment sur la création de jeux de données enrichis : ils devraient représenter non seulement le code final, mais aussi la complexité du processus qui mène à sa modification. Cela inclut les informations nécessaires pour comprendre un problème, les contraintes d’un projet et les conséquences d’un changement.

L’enjeu est également de construire des modèles d’évaluation partagés. Mesurer la qualité d’une refactorisation, par exemple, suppose de dépasser la question binaire « le programme fonctionne-t-il ? ». Il faut pouvoir apprécier si le code reste cohérent avec le reste du projet, s’il est plus simple à maintenir et si les corrections proposées tiennent dans le temps.

L’étude présente cette démarche comme un appel à des collaborations open source à grande échelle. L’idée est d’aborder progressivement les difficultés les plus importantes, puis d’intégrer les résultats dans des outils commerciaux. Cette trajectoire contraste avec la promesse d’un ingénieur logiciel entièrement autonome disponible d’un seul coup : les progrès utiles pourraient plutôt venir de systèmes spécialisés, bien évalués et intégrés avec prudence aux pratiques des équipes.

Ce qu’il faut surveiller avant de parler d’ingénieur autonome

À la date du 21 juillet 2025, les assistants de code sont déjà capables d’apporter une aide concrète. Ils peuvent accélérer la recherche d’une solution, faciliter certaines transformations et servir de premier interlocuteur face à un problème technique. Mais leur présence dans le processus de développement ne prouve pas qu’ils savent assumer seuls la responsabilité d’un logiciel.

Les prochains progrès devront être observés sur des critères plus exigeants que la simple capacité à générer du code. Un système réellement utile devra naviguer dans de grandes bases de code, respecter des règles qu’il n’a pas vues dans ses données d’entraînement, demander de l’aide lorsque le contexte lui manque et rendre ses incertitudes lisibles. Il devra aussi être jugé sur la fiabilité de ses changements dans la durée.

La question n’est donc pas seulement « l’IA sait-elle coder ? ». À bien des égards, elle le peut déjà. La question décisive est plutôt de savoir si elle peut contribuer à un logiciel complexe sans déplacer le travail de vérification, de compréhension et de réparation vers les humains. C’est sur ce point que se jouera le passage de l’autocomplétion à une assistance d’ingénierie véritablement mature.