Moins de code humain, plus d'architecture humaine

Si l'IA produisait demain chaque ligne de l'implémentation d'un système, que resterait-il à l'ingénierie à concevoir, à décider et à vérifier ? La question est hypothétique, mais elle n'est plus oiseuse, et cet article soutient que la réponse est l'architecture, dans un sens précis et exécutable. Il sépare trois sortes d'énoncés : ce que des études ont mesuré, avec sa source ; ce qui découle de ces mesures par raisonnement, signalé comme inférence ; et la thèse elle-même, une hypothèse à mettre à l'épreuve, pas un résultat.

La capacité mesurée est réelle et a vite progressé. SWE-bench demande à un système de résoudre de vrais tickets GitHub dans de vrais dépôts Python et note le résultat avec les tests des projets eux-mêmes ; en 2023, le meilleur modèle en résolvait 1,96 %. Sur SWE-Bench Pro, plus difficile, construit à partir de changements plus importants et en partie de code commercial jamais publié, le meilleur résultat de la première version de l'article, en septembre 2025, était d'environ 23 % ; à la mi-2026, le classement tenu par le propriétaire du benchmark affichait environ 60 % sur l'ensemble public et environ 50 % sur l'ensemble commercial, avec des harnais qui diffèrent d'une entrée à l'autre. L'horizon temporel de METR est la durée d'une tâche, chronométrée par une personne compétente, qu'un agent d'IA accomplit une fois sur deux. Sur ses tâches bien spécifiées et notées automatiquement, cette durée a doublé environ tous les sept mois entre 2019 et le début de 2025, et environ tous les quatre mois depuis 2023 selon son estimation de 2026.

Au sein des organisations, le changement se voit en volume, et ce sont les entreprises elles-mêmes qui le rapportent. Google a indiqué en janvier 2025 que les complétions d'IA acceptées représentaient 67 % des caractères de code saisis dans les éditeurs de ses ingénieurs, code collé exclu, et que 80 % des modifications d'une série de grandes migrations internes, un type de tâche bien spécifié, avaient été écrites entièrement par l'IA, chacune relue comme n'importe quel autre code. Dans une enquête non anonyme auprès de 132 de ses salariés, les ingénieurs d'Anthropic ont déclaré utiliser son modèle pour environ 59 % de leur travail, tandis que plus de la moitié disait ne pouvoir en déléguer entièrement qu'un cinquième au plus.

Les preuves de productivité sont plus contrastées que la courbe de capacité ne le laisse penser. Dans un essai contrôlé randomisé mené début 2025 avec 16 développeurs expérimentés travaillant sur des projets matures auxquels ils contribuaient depuis des années, METR a constaté que l'accès aux outils d'IA allongeait les tâches de 19 %, alors que les développeurs pensaient avoir gagné environ 20 % en vitesse. Une étude de suivi début 2026 a indiqué des accélérations modestes, avec des intervalles de confiance qui incluent zéro, et METR a qualifié ces données de signal peu fiable, parce que les développeurs refusaient de plus en plus de travailler sans IA. Des expériences de terrain avec 4 867 développeurs chez Microsoft, Accenture et une troisième entreprise, cosignées par des chercheurs de Microsoft et menées avec l'autocomplétion des années 2022 à 2024, ont trouvé 26 % de tâches achevées en plus, avec des gains plus importants, mais estimés avec beaucoup d'incertitude, chez les moins expérimentés. Un essai randomisé mené par Google avec 96 de ses propres ingénieurs a estimé environ 21 % de temps en moins sur une tâche, avec un intervalle de confiance assez large pour inclure l'absence d'effet. L'enquête DORA de 2024 associait chaque hausse de 25 % de l'adoption de l'IA à une baisse estimée de 1,5 % du débit de livraison et de 7,2 % de la stabilité de livraison ; son rapport de 2025 a constaté que le débit augmente désormais avec l'adoption tandis que l'instabilité continue de croître, et a décrit l'IA comme un amplificateur des forces et des dysfonctionnements qu'une organisation a déjà.

Lues ensemble, ces études ne montrent pas que l'IA rend l'ingénierie logicielle bon marché. Elles sont compatibles avec quelque chose de plus étroit, que cet article infère plutôt qu'il ne le mesure : produire une implémentation candidate devient moins coûteux plus vite qu'établir qu'une candidate est acceptable. L'IA automatise aussi une partie de la vérification, des tests générés aux preuves vérifiées par machine. Ce qu'elle ne tranche pas d'elle-même, c'est ce que les vérifications doivent vérifier. Cette asymétrie est le point de départ de tout ce qui suit.

Un benchmark compte une tâche comme résolue quand un correctif fait passer les tests prévus. Un système est accepté quand les personnes qui en sont responsables sont prêtes à s'y fier. L'essentiel de la difficulté se loge dans l'écart entre les deux.

Les benchmarks eux-mêmes montrent cet écart. SWE-bench Verified existe parce qu'en 2024, quand 93 développeurs ont examiné un échantillon des tâches d'origine, 38,3 % ont été signalées pour des énoncés sous-spécifiés et 61,1 % pour des tests susceptibles de rejeter des solutions valides, un filtre que ses auteurs jugent eux-mêmes probablement trop zélé. En 2026, OpenAI a cessé de publier ses résultats sur ce benchmark, après qu'un audit de 138 tâches, choisies parce que son propre modèle y échouait régulièrement, a trouvé des problèmes sérieux dans les tests ou les énoncés de 59,4 % d'entre elles, et que chaque modèle de pointe testé a pu reproduire, pour certaines tâches, le correctif d'origine ou des détails de l'énoncé. Une étude présentée à ICSE 2026 a montré que 29,6 % des correctifs d'agents comptés comme plausibles se comportaient autrement que le correctif des développeurs eux-mêmes, pas tous à tort ; avec d'autres faiblesses des tests, cela gonflait les taux de résolution publiés d'environ six points. Et METR a demandé à des mainteneurs de scikit-learn, de Sphinx et de pytest d'examiner des correctifs qui passaient les tests, sans savoir qui les avait écrits. Les correctifs venaient d'agents publiés jusqu'à fin 2025, chacun avec une seule tentative et sans retour, et environ la moitié n'aurait pas été fusionnée ; METR souligne que ce n'est pas un plafond de ce que les agents savent faire.

Au-delà des tests fonctionnels, le tableau est semblable. Sur BaxBench, un benchmark d'applications backend présenté à ICML 2025, le meilleur modèle produisait un programme correct dans 62 % des cas et, en moyenne sur l'ensemble des modèles, des exploits de sécurité réussissaient contre environ la moitié des programmes corrects. Sur 576 000 échantillons de code générés en 2024 par 16 modèles, 19,7 % des paquets logiciels cités par les modèles n'existaient pas, 5,2 % pour les modèles commerciaux et 21,7 % pour les modèles ouverts ; un attaquant peut enregistrer ces noms. Dans une étude de 2022 avec 47 participants, surtout des étudiants, et un modèle ancien, ceux qui disposaient d'un assistant d'IA écrivaient du code moins sûr et le croyaient plus souvent sûr. Une étude quasi expérimentale de projets publics sur GitHub ayant adopté un éditeur de code à base d'IA, Cursor, a trouvé un gain de production important mais passager, tandis que les avertissements de l'analyse statique augmentaient de 30 % et la complexité du code de 41,6 %, et y restaient.

Les preuves vont aussi dans l'autre sens, et cela compte. Un essai préenregistré avec 151 participants n'a trouvé aucune différence significative dans la facilité avec laquelle d'autres développeurs pouvaient ensuite faire évoluer du code écrit avec l'aide de l'IA. La plupart des études de sécurité citées n'ont pas de point de comparaison humain équivalent. Rien de tout cela ne montre que le code généré soit pire que le code humain.

Ce que cela montre, c'est que le code généré devrait être traité pour ce qu'il est : une implémentation candidate. Un changement candidat devrait être vérifié au regard des contraintes de l'architecture et de ses tests, validations et règles ; il devrait laisser la preuve de ce qui a été vérifié ; et il devrait être accepté ou rejeté sur cette base. Là où une décision comporte un risque qu'aucune vérification ne peut trancher, une personne devrait être consultée. Ce modèle ne dépend pas de qui a produit la candidate.

Si les implémentations candidates deviennent abondantes, la question rare devient celle de savoir laquelle est acceptable, et y répondre suppose de savoir ce qu'acceptable veut dire. Cet article soutient qu'à mesure que l'implémentation devient plus facile à générer, la valeur relative de la décision sur ce qui doit rester vrai augmente. C'est une inférence, pas une mesure, et elle ne dit pas que le code n'a pas de valeur.

Des éléments la soutiennent à la marge. Plus d'un tiers des tâches examinées pour SWE-bench Verified ont été signalées comme sous-spécifiées. Les modèles repèrent mal les consignes sous-spécifiées, et les agents qui posent des questions de clarification font nettement mieux, jusqu'à 74 % en termes relatifs, avec un utilisateur simulé, dans une étude présentée à ICLR 2026. Google décrit l'auteur de code assisté par IA qui en devient de plus en plus le relecteur, et les ingénieurs d'Anthropic décrivent un paradoxe de la supervision : bien utiliser le modèle exige de le superviser, et le superviser exige précisément les compétences qu'une délégation excessive peut éroder. Le rapport DORA de 2025 observe que la friction ne disparaît pas tant qu'elle se déplace, du travail manuel vers la décision et la vérification. Dans l'enquête Stack Overflow de 2025, davantage de développeurs se méfiaient de la précision des outils d'IA qu'ils ne lui faisaient confiance, 46 % contre 33 %, et la frustration la plus courante était un résultat presque juste, mais pas tout à fait.

Une façon utile de décrire ce déplacement est de séparer deux questions. L'architecture répond à : qu'est-ce qui doit rester vrai ? L'implémentation répond à : comment est-ce réalisé ici ? Prenons une propriété : un résultat probabiliste ne doit pas devenir en silence une donnée de référence. Elle peut être réalisée par une validation de schéma à l'exécution, par une frontière typée que seul un service de validation peut construire, par un adaptateur dans la couche applicative ou par un test d'architecture en intégration continue qui échoue quand un client de modèle est importé dans le cœur. Chacune couvre une partie de la propriété, avec une force différente ; une règle d'import, par exemple, impose le sens d'une dépendance, pas la propriété elle-même. La technologie peut changer. La propriété demeure.

Une IA peut produire de plus en plus le second type de réponse. Le premier reste une affaire d'intention, de compréhension du domaine, de risque et de responsabilité. La frontière n'est pas parfaitement nette : un cache ou une stratégie de nouvelle tentative choisis pendant l'implémentation créent leurs propres propriétés, si bien que le code généré doit encore être relu au regard de l'architecture, pas seulement de ses tests.

L'architecture logicielle connaît déjà l'idée d'une intention exécutable. Dans Building Evolutionary Architectures, Ford, Parsons et Kua définissent une fonction d'aptitude architecturale comme une évaluation objective de l'intégrité d'une ou de plusieurs caractéristiques architecturales. Des outils comme ArchUnit font tourner les règles de dépendance entre couches comme de simples tests unitaires. Contrats, schémas, systèmes de types, tests fondés sur les propriétés et, là où le coût se justifie, vérification formelle expriment la même idée à des profondeurs différentes.

La définition de travail retenue ici est simple. Une contrainte devient architecturale au sens qui intéresse cet article, appliquée et non seulement énoncée, quand sa violation conduit le système ou son processus de livraison à rejeter le résultat. Selon cette définition, un principe qu'aucun build, aucun déploiement et aucune vérification à l'exécution ne peut faire échouer reste une description, aussi soigneusement qu'il soit rédigé. Tout ce qui est architectural ne peut pas être appliqué ainsi ; la façon dont un système est découpé, ou qui possède quelles données, se juge plutôt qu'elle ne se vérifie.

Quand l'implémentation devient abondante, l'architecture consiste moins à dessiner des diagrammes de systèmes qu'à définir des frontières exécutables : contraintes vérifiables par machine, propriétés d'acceptation, exigences de preuve, tests d'architecture, exigences d'observabilité, frontières de règles et comportement défini en cas de défaillance. Formulé comme une thèse et non comme une définition de la discipline : l'artefact de l'architecte n'est plus seulement un diagramme. C'est aussi l'ensemble des propriétés que le système est incapable de violer en silence.

Exécutable ne veut pas dire prouvé. Les tests échantillonnent le comportement ; ils peuvent révéler des défauts, mais pas montrer qu'il n'en reste aucun. Des propriétés différentes appellent des assurances différentes : types et schémas pour la forme des données, analyse statique et tests d'architecture pour les dépendances, tests fondés sur les propriétés pour le comportement sur de nombreuses entrées, vérification formelle là où une propriété est critique et peut être spécifiée, contrôles à l'exécution pour ce qui ne s'observe qu'en fonctionnement, et revue humaine pour ce qu'aucun mécanisme ne peut juger.

Les travaux sur la génération de spécifications en même temps que le code montrent à la fois la promesse et la limite. Des modèles de langage ont transformé une intention exprimée en langage naturel en postconditions qui ont détecté 64 bogues historiques réels du jeu de données Defects4J. Sur le benchmark VERINA, le meilleur modèle écrivait du code correct pour 72,6 % des tâches, mais une spécification correcte et complète pour 52,3 % seulement. Lahiri énonce la limite de fond : vérifier une implémentation au regard d'une spécification peut se définir mécaniquement, mais aucune voie algorithmique ne permet de s'assurer que la spécification saisit ce que l'utilisateur voulait. C'est le problème architectural en une phrase.

Un système n'est pas sous contrôle parce qu'on a dit à un modèle ce qu'il ne doit pas faire. Un prompt système, une règle écrite, une consigne d'éviter quelque chose, la bonne volonté apparente d'un modèle à suivre une règle et une personne qui parcourt tout après coup décrivent un comportement espéré. Aucun d'eux ne bloque de façon fiable un état inacceptable quand le modèle ne coopère pas ; une personne qui parcourt après coup en rattrape une partie, tard et inégalement.

Le contrôle, au sens retenu ici, existe quand un état inacceptable peut être détecté, bloqué, rejeté ou remonté indépendamment de la coopération du modèle. Ses instruments sont connus : contraintes d'architecture exécutables, frontières de types, schémas, validateurs déterministes, tests d'architecture et de contrat, vérifications en intégration continue qui font échouer le build, application de règles, admission au déploiement, provenance et traçabilité, tests d'acceptation, revue humaine encadrée et portes de publication. Une règle qu'une IA peut ignorer n'est pas encore un contrôle architectural.

Une conséquence est que les contrôles n'ont pas besoin de savoir qui a écrit le code. La même frontière contraint un changement tapé par une personne, un changement suggéré par un assistant et un changement produit de bout en bout par un agent. La question importante n'est plus seulement de savoir qui a écrit le code, mais si le système qui en résulte préserve les propriétés requises. Le profil du NIST pour le développement sécurisé au sein des équipes qui construisent des modèles d'IA générative adopte la même position pour les vulnérabilités : ses pratiques ne distinguent pas le code source écrit par des humains de celui généré par l'IA, parce que tout code devrait être évalué avant usage. Il ne s'agit pas d'un régime de surveillance du code écrit par des machines. C'est une architecture qui contraint l'implémentation quelle que soit son origine, y compris les erreurs que font les personnes.

Cela change aussi ce qu'un système devrait laisser derrière lui. Un système généré qui a seulement l'air correct n'a laissé aucune preuve de ce qui a été vérifié. Les propriétés importantes devraient laisser la preuve qu'elles ont été évaluées : quels tests ont tourné, quelle version de règle s'appliquait, ce qu'une validation a renvoyé, comment un changement se rattache à l'exigence qu'il sert, d'où venaient ses entrées et ce qu'a décidé la porte de mise en production. Les cadres de la chaîne d'approvisionnement logicielle traitent déjà ce type d'enregistrement comme quelque chose qu'un build produit et qu'un consommateur vérifie : SLSA spécifie la provenance de la construction d'un artefact, et in-toto vérifie que chaque étape d'une chaîne d'approvisionnement a été exécutée comme prévu. La provenance montre comment un artefact a été produit, pas qu'il est correct.

Revenons à la question de départ. Si l'IA produisait demain chaque ligne de l'implémentation, l'ingénierie devrait encore établir ce que l'implémentation a le droit de signifier et de faire, quelles propriétés elle ne peut pas violer en silence et quelles preuves sont nécessaires avant de pouvoir s'y fier.

En pratique, c'est une liste de responsabilités : définir la finalité du système, décider quels résultats sont inacceptables, déterminer ce qui compte comme preuve, lever les ambiguïtés sémantiques, fixer la tolérance au risque, définir des invariants, examiner les cas exceptionnels, valider l'architecture, accepter le risque résiduel et continuer d'en répondre. Chaque point n'exige pas qu'une personne l'exécute à la main à chaque fois. Chacun exige une personne ou un rôle nommément désigné, qui agit dans un processus défini et en répond. Un système peut automatiser le travail sans rendre la responsabilité indéfinie. Moins de code humain ne signifie pas moins de responsabilité humaine.

L'intention humaine n'est pas juste d'office, et elle n'est pas disponible d'office. Une exigence qui n'existe que dans la tête de quelqu'un n'est pas un contrôle architectural. Pour contraindre une implémentation générée, l'intention doit être rendue explicite, représentée sous une forme vérifiable, relue, versionnée quand elle change et reliée à la vérification qui l'applique.

C'est sur le sens que la difficulté est la plus grande. Un générateur peut produire un système syntaxiquement irréprochable qui comprend mal son domaine, parce que les termes portent un contexte : la même étiquette signifie des choses différentes dans deux organisations, les définitions d'une norme évoluent d'une version à l'autre, et des données qui franchissent une frontière entrent dans un autre vocabulaire juridique. Générer de la syntaxe ne résout pas l'alignement sémantique. Décider de ce que signifie un champ, et garder ce sens stable pendant que les données passent d'un système, d'une organisation et d'une juridiction à l'autre, est un travail d'architecture que davantage d'implémentation ne remplace pas.

L'attention humaine est en outre une ressource limitée, aux défaillances connues. Bainbridge observait en 1983 que l'automatisation laisse aux opérateurs les tâches que ses concepteurs n'ont pas su automatiser, et leur demande de surveiller un système installé justement parce qu'il fait le travail mieux qu'eux. Une revue systématique du biais d'automatisation, la tendance à trop se fier aux résultats automatisés, range l'insistance sur la responsabilité de l'utilisateur parmi les mesures qui le réduisent. La conclusion n'est pas que les personnes doivent lire chaque ligne générée, ce qui ne passe pas à l'échelle. C'est que les systèmes devraient concentrer l'attention humaine sur le jugement et le risque non résolus, et donner des conséquences à cette attention.

Cet article soutient qu'on ne peut compter sur l'autonomie de l'implémentation que dans la mesure où le comportement qui en résulte peut être contraint et vérifié de façon indépendante. Formulé comme un principe et non comme une formule : l'autonomie accordée à un agent d'implémentation devrait dépendre de la façon dont son résultat peut être vérifié de manière indépendante. Là où les propriétés sont bien spécifiées et les vérifications solides, comme pour une migration mécanique, une mise à jour de dépendance sous une suite de tests approfondie ou un adaptateur derrière une frontière typée, beaucoup peut être délégué. Là où les propriétés sont floues, les vérifications faibles ou le coût d'une erreur élevé, l'autonomie devrait croître lentement, ou pas du tout.

Selon cet argument, l'implémentation peut devenir de plus en plus autonome sans que le contrôle le devienne. L'autonomie est accordée par les contraintes, mesurée à l'aune des preuves et retirée quand les preuves cessent de l'étayer. Les critères d'acceptation n'ont pas à dépendre de qui a écrit le code ; ce qu'un producteur peut faire avant qu'une personne regarde peut en revanche dépendre de ses antécédents.

C'est aussi pourquoi l'argument ne dépend pas d'un langage ou d'une plateforme en particulier. La même propriété architecturale peut être vérifiée à la compilation par un type en TypeScript, à l'exécution par un schéma en Python, par une frontière de module en Java ou par une règle d'admission dans Kubernetes. Quand l'implémentation change, y compris quand elle est régénérée, c'est la propriété qui subsiste.

COADF, le Compliance-Oriented AI Development Framework, est une exploration pratique de cette thèse, et une seule. C'est une méthode de développement pour les systèmes d'IA qui doivent tenir face à la réglementation européenne. Lu à la lumière de cette thèse, il demande quelles propriétés doivent rester vraies quand des composants probabilistes participent à la production, à la transformation ou à la publication d'informations, et comment un build peut remarquer qu'elles cessent de l'être. Il est issu du projet de recherche et développement AnyLAI, qui étudie comment l'intention architecturale peut rester contraignante dans des systèmes qui contiennent de plus en plus de comportements probabilistes et générés par des machines.

Ses principes appliquent la thèse à un cas plus étroit : ce que la sortie d'un modèle a le droit de devenir pendant que le système fonctionne. P-1 maintient le comportement probabiliste dans les bornes du comportement déterministe du système : un modèle renvoie une valeur avec sa confiance et la méthode qui la sous-tend, jamais une valeur nue. P-4 maintient traçables les transformations importantes, d'une sortie publiée jusqu'aux preuves sur lesquelles elle repose. P-6 transforme les garde-fous en fences, des vérifications qui bloquent une mise en production au lieu de conseils dans un document, et demande à chaque fence de montrer qu'elle se déclenche. P-7 tient les normes externes, les systèmes de classification et les services terminologiques dans des adaptateurs hors du cœur. P-8 garde les règles explicites et versionnées sous forme de données, de sorte qu'une décision nomme la version de règle qui l'a produite. P-2 et P-3 posent qu'une confiance faible n'atteint jamais une sortie publiée et qu'une personne y décide, un fait après l'autre, au regard de sa source.

Seuls ses modèles de gouvernance traitent l'autre cas, celui des agents d'IA qui écrivent du code de production. Une échelle d'autonomie fixe ce qu'un agent peut faire avant qu'une personne regarde : au barreau le plus bas, une personne lit chaque ligne ; au plus haut, une personne lit les résultats des tests et la sortie des gardiens, un barreau qui exige une couverture mûre de fences et un historique et qui, selon le framework, devrait rester rare. Une courte liste de décisions, parmi lesquelles les changements de schéma de base de données, la configuration de sécurité, les contrats d'interface dont le changement casse un appelant et les changements du système de fences lui-même, reste à une personne à chaque barreau.

COADF ne rend pas sûre la programmation autonome et n'établit pas que le logiciel généré est correct. Ce n'est pas un framework de programmation autonome. Il rend certaines hypothèses architecturales explicites et testables, et il est publié pour que ces hypothèses puissent être examinées et contestées.

Elle n'affirme pas que les développeurs de logiciels ne seront plus nécessaires, que le code écrit par des humains est dépassé ou que les développeurs seront remplacés par des architectes. Une grande partie de ce que cet article appelle architecture est faite par des développeurs. La thèse porte sur l'endroit où l'effort d'ingénierie crée le plus de valeur, pas sur des intitulés de poste.

Elle n'affirme pas que l'IA sait déjà construire de façon autonome des logiciels de production, que l'architecture élimine les hallucinations ou que les bons contrôles sont tout ce dont une IA a besoin. Les preuves citées plus haut comprennent des mainteneurs qui rejettent environ la moitié des correctifs passant les tests, des benchmarks qui surestiment la correction et des failles de sécurité dans du code généré.

Et elle n'affirme pas que la transition qu'elle décrit est achevée, universelle ou inévitable. C'est une hypothèse sur une direction, avec un mécanisme qui peut être examiné : à mesure que l'implémentation devient plus facile à générer, la vérification gagne en importance, et le travail qui consiste à décider ce qui doit rester vrai prend une plus grande part de l'ingénierie.

Une thèse n'est utile que si elle produit des questions auxquelles on peut répondre. Celles-ci paraissent les plus pressantes.

1. 01Quelle part du détail d'implémentation peut-on déléguer avant que la vérification ne devienne le coût dominant ?
2. 02Quelles propriétés architecturales peuvent être vérifiées automatiquement, et lesquelles exigent encore un jugement humain ?
3. 03Comment représenter l'architecture pour que les personnes comme les machines puissent raisonner à son sujet ?
4. 04L'intention architecturale peut-elle devenir vérifiable par machine sans être liée à une technologie d'implémentation ?
5. 05Quelle autonomie accorder quand les techniques d'assurance diffèrent en force ?

Aucune n'a de réponse définitive. Entre l'affirmation selon laquelle l'IA aide seulement les développeurs à coder plus vite et celle selon laquelle les développeurs ne sont plus nécessaires se trouve la question dont traite cette recherche : ce qu'un système doit être incapable de faire, qui en décide et comment cette décision est appliquée.