Quand l’IA écrit du code que l’ingénieur ne comprend plus

Et si le véritable basculement provoqué par l’IA dans le développement logiciel n’était pas simplement qu’elle sache écrire du code, mais que le code cesse progressivement d’être quelque chose qu’un humain doit comprendre dans le détail pour produire un résultat performant ?

Deux publications récentes permettent d’entrevoir cette évolution. La première la théorise. La seconde semble déjà en montrer une forme concrète.

Quand le code cesse d’être le centre du métier

En juin 2026, Zhenfeng Cao publie sur arXiv The End of Software Engineering, dont la version révisée est intitulée Agentic Software: How AI Agents Are Restructuring the Software Paradigm.

Sa thèse est volontairement radicale. Pendant des décennies, l’ingénieur logiciel a transformé un problème en logique, puis cette logique en code. Le code constituait à la fois le produit de son travail et l’un des principaux supports de son expertise.

Dans le modèle décrit par Cao, cette chaîne pourrait progressivement se modifier. L’humain définit l’intention et les contraintes. L’agent planifie, produit le code nécessaire, l’exécute, le teste et l’adapte. L’humain intervient davantage sur le résultat obtenu que sur chacune des opérations ayant permis de l’obtenir.

Le rôle de l’ingénieur passerait ainsi progressivement de code author à intent architect, coordinator and auditor.

L’expertise ne disparaît pas nécessairement. Elle remonte d’un niveau d’abstraction.

Une scène étonnante chez OpenAI

Fin août, SemiAnalysis publie une analyse du nouveau processeur d’inférence Jalapeño développé par OpenAI. Une partie de l’article concerne les kernels, ces programmes extrêmement bas niveau permettant d’exploiter efficacement le matériel.

SemiAnalysis décrit certains kernels atteignant environ 3 000 lignes et explique qu’une version interne de Codex est désormais utilisée pour en produire et optimiser une partie. L’équipe rapporte notamment que Codex a généré rapidement une implémentation fonctionnelle et performante d’un kernel MLA pour DeepSeek sans intervention directe de l’équipe spécialisée dans les kernels.

Dans une intervention diffusée quelques jours plus tard, Jordan Nanos de SemiAnalysis raconte une scène encore plus frappante. Alors que des ingénieurs d’OpenAI parcourent avec eux un de ces kernels générés par l’IA, ils comprennent parfaitement le matériel, l’architecture générale et les principes du système, mais ne semblent plus capables d’expliquer précisément ce que réalise chaque ligne.

Selon Nanos, lorsqu’on avance ligne après ligne, la réponse ressemble essentiellement à :

“Nope, nope, nope.”

Pourtant, le programme fonctionne et obtient de très bonnes performances. OpenAI rapporte par ailleurs avoir utilisé GPT-5.6 Sol avec Codex pour réécrire et optimiser de manière autonome des kernels de production, avec une réduction annoncée de 20 % des coûts de serving de bout en bout. L’entreprise insiste parallèlement sur le développement d’outils de vérification permettant de contrôler la correction de ces programmes.

L’ingénieur n’a pas disparu. Mais son rapport à l’objet technique commence peut-être à changer.

Ce que ce déplacement change pour le travail

01 / Compétences — Être expert sans comprendre chaque ligne

Il serait excessif de conclure que ces ingénieurs ne comprennent plus ce qu’ils font. Ils comprennent précisément le système à un autre niveau.

Architecture du processeur, mouvements de données, contraintes matérielles, performances attendues, tests de correction et comportement global restent des objets d’expertise humaine. Ce qui semble changer est l’endroit où cette expertise s’exerce.

L’ingénieur peut devenir moins spécialiste de la fabrication détaillée d’un artefact et davantage spécialiste de la définition de ce que cet artefact doit accomplir, de son architecture et des moyens de vérifier qu’il le fait correctement.

Un développeur utilisant un langage de haut niveau ne comprend généralement pas instruction par instruction l’assembleur finalement produit par son compilateur. La nouveauté serait moins l’existence d’une couche technique non inspectée par l’humain que le déplacement progressif vers l’IA de couches du travail qui constituaient auparavant directement l’activité intellectuelle de l’ingénieur.

02 / Autonomie — Plus de capacité, mais moins de prise sur l’exécution

Avec un agent performant, un ingénieur peut produire beaucoup plus. Il peut résoudre des problèmes auparavant trop longs ou trop complexes, explorer davantage d’options et piloter plusieurs tâches simultanément. Son pouvoir d’action augmente.

Mais sa compréhension détaillée de la manière dont chaque résultat est obtenu peut simultanément diminuer. Il devient donc possible d’avoir davantage de capacité sans nécessairement avoir davantage de maîtrise sur tous les mécanismes qui produisent cette capacité.

Or l’autonomie au travail ne correspond pas uniquement à la possibilité d’obtenir rapidement un résultat. Elle repose aussi sur la possibilité de comprendre son activité, d’agir sur son déroulement, de mobiliser ses compétences et de reprendre la main lorsqu’une situation inhabituelle apparaît.

03 / Expertise — Quand faire et savoir faire commencent à se séparer

Un ingénieur peut devenir extrêmement performant grâce à l’IA tout en pratiquant moins fréquemment certaines compétences qui permettaient auparavant d’atteindre ce niveau de performance.

Ce phénomène mérite probablement d’être distingué d’un simple deskilling. Certaines compétences peuvent perdre de leur importance tandis que d’autres deviennent plus importantes : comprendre une architecture, définir correctement un problème, identifier les contraintes pertinentes, construire des évaluations, détecter un résultat aberrant et savoir quand ne pas faire confiance au système.

Ce qui permettait hier de reconnaître un bon ingénieur pourrait ne plus être exactement ce qui permettra de le reconnaître demain.

Pour des professionnels ayant construit une partie importante de leur identité autour de leur maîtrise technique, cette transition peut également toucher à la reconnaissance professionnelle et au sentiment de compétence.

04 / Automatisation — Le risque de sortir progressivement de la boucle

Les facteurs humains connaissent depuis longtemps un phénomène appelé out-of-the-loop performance problem. Lorsque l’automatisation prend progressivement en charge une activité, l’opérateur peut perdre une partie de sa conscience de la situation ou de ses compétences pratiques. Le problème apparaît surtout lorsqu’il doit reprendre la main après une défaillance du système.

Il serait prématuré de transposer directement les résultats issus de l’aviation ou d’autres systèmes automatisés au développement logiciel. Mais ils soulèvent une question centrale : que se passe-t-il lorsque l’humain chargé de superviser un système intervient de moins en moins dans les opérations qu’il devra précisément comprendre le jour où l’automatisation échoue ?

Plus les agents deviennent compétents, moins il est économiquement rationnel de vérifier manuellement chaque ligne. Mais plus cette vérification disparaît, plus il devient nécessaire de construire d’autres moyens de conserver une compréhension suffisante du système.

05 / Responsabilité — Rester responsable d’un résultat que l’on comprend moins

Dans un système beaucoup plus agentique, la relation entre celui qui produit le code et l’objet dont il est responsable peut se distendre. L’ingénieur fixe les objectifs. L’agent produit. Des outils automatisés testent. L’ingénieur valide finalement le résultat.

Le risque apparaît lorsque l’organisation continue à attribuer à l’humain la même responsabilité sur le résultat alors que son contrôle concret sur sa production diminue.

La responsabilité devrait rester cohérente avec les informations disponibles, les possibilités d’action et le niveau réel de contrôle dont dispose le travailleur.

Ne pas seulement apprendre aux ingénieurs à mieux utiliser les agents

Si cette évolution se confirme, la prévention ne pourra probablement pas consister uniquement à former les salariés au prompting ou à l’utilisation de nouveaux outils.

Décider quelles compétences doivent volontairement rester entretenues.
Définir les situations dans lesquelles une compréhension humaine détaillée reste indispensable.
Préserver des activités permettant de continuer à exercer les compétences nécessaires pour reprendre la main.
Adapter les processus de revue à des volumes de code qui dépassent les capacités de lecture humaines.
Construire des tests et des évaluations robustes pour que la vérification ne repose pas uniquement sur la confiance accordée au modèle.
Maintenir la cohérence entre responsabilité et contrôle réel. Un salarié ne devrait pas être tenu responsable d’un système que l’organisation ne lui donne plus les moyens de comprendre ou de contrôler.

Peut-être moins la fin de l’ingénieur que la fin d’une certaine relation au code

Le titre initial du papier de Cao annonçait The End of Software Engineering. La formule est probablement excessive. Le papier reste une proposition théorique publiée sur arXiv et certaines de ses prédictions concernant l’évolution future des systèmes agentiques restent spéculatives.

L’exemple d’OpenAI concerne par ailleurs un domaine très particulier, celui de kernels extrêmement bas niveau, et ne permet évidemment pas de généraliser à l’ensemble du développement logiciel.

Mais la convergence entre les deux observations mérite attention. L’un décrit un futur dans lequel le code devient progressivement un artefact intermédiaire produit par des agents. L’autre décrit des ingénieurs hautement qualifiés supervisant déjà un code performant généré par une IA sans nécessairement pouvoir en expliquer chaque ligne.

Cela ne signifie pas que l’expertise humaine devient inutile. Cela pourrait au contraire signifier qu’elle change profondément d’objet.

Pour la santé au travail, la question ne sera peut-être pas seulement de savoir combien d’ingénieurs seront remplacés par l’IA. Il faudra aussi comprendre ce que devient le rapport au travail de ceux qui restent lorsque leur capacité de production augmente beaucoup plus rapidement que leur capacité à comprendre directement tout ce qu’ils produisent.

Le paradoxe pourrait être celui-ci : être capable de construire des systèmes toujours plus complexes, tout en comprenant de moins en moins directement les artefacts qui les font fonctionner.

Que devient le métier d’ingénieur quand l’IA écrit un code qu’il ne comprend plus ligne par ligne ?