Je code depuis près de trente ans. Vingt ans à titre professionnel. Et je vais dire quelque chose qui aurait semblé absurde il y a encore quatre ans : les intelligences artificielles me surpassent largement en termes de production de code. En vitesse, en volume, souvent en couverture de cas limites.
Ce n’est pas une capitulation. C’est un constat honnête, et je le vis bien. Ces outils m’ont rendu plus efficace que je ne l’ai jamais été. Copilot, Claude, GPT - selon les contextes, ils m’épatent régulièrement. Pour implémenter un algorithme connu, câbler une API, écrire des tests unitaires ou refactoriser une fonction, leur puissance est réelle et désormais indiscutable.
Mais depuis un moment, quelque chose me tracassait. Une intuition que je n’arrivais pas tout à fait à formuler. Ce papier l’a formulée pour moi.
Il s’intitule SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration, publié début mars 2026 sur arXiv par des chercheurs de Sun Yat-sen University et Alibaba Group. Il pose une question simple et dérangeante : on sait que les LLMs écrivent du code - mais est-ce qu’ils écrivent du code qui tient dans le temps ?
Pour comprendre l’apport de ce travail, il faut comprendre comment on évalue aujourd’hui les LLMs sur le code. Les benchmarks classiques (HumanEval, SWE-bench, LiveCodeBench) posent tous la même question fondamentale : l’agent reçoit un problème, produit une solution, est-ce que ça passe les tests ?
C’est ce que les chercheurs appellent l’évaluation « snapshot » : une photo à un instant T. Le modèle corrige un bug, génère une fonction, propose un patch. On vérifie. Ça marche ou pas.
Un problème → une solution → les tests passent. L'agent est évalué sur un seul acte de production. Ce qui précède et ce qui suit n'existe pas.
Partir d'une base de code réelle, faire évoluer le projet sur des dizaines d'itérations successives, et mesurer si le code reste maintenable au fil du temps.
Le problème ? Dans la vraie vie, un logiciel ne naît pas en une nuit et ne meurt pas après son premier déploiement. Il vit, mute, vieillit. Des fonctionnalités s’ajoutent, des interfaces changent, des collègues (ou des agents) reprennent ce qu’on a écrit. Ce qui compte alors, ce n’est pas seulement qu’un patch fonctionnel ait été produit - c’est que ce patch n’ait pas hypothéqué les cinquante suivants.
Un agent qui hard-code une rustine fragile et un agent qui écrit du code propre et extensible peuvent tous les deux passer les mêmes tests. Leur différence n'est visible qu'au troisième ou quatrième changement.
C’est précisément ce que les lois de Lehman sur l’évolution logicielle théorisaient dès les années 1970 : la qualité d’un logiciel se dégrade naturellement à mesure qu’il évolue. Et la littérature classique estime que la maintenance représente entre 60 et 80 % du coût total du cycle de vie d’un logiciel. La maintenance, pas le développement initial.
Le benchmark est construit avec soin. Les chercheurs ont parcouru GitHub à la recherche de projets Python sérieux : au moins trois ans de maintenance active, au moins 500 étoiles, une vraie suite de tests, une licence permissive. Sur 4 923 projets filtrés, ils ont finalement retenu 100 cas issus de 68 dépôts distincts.
Pour chaque cas, ils choisissent deux commits sur la branche principale : un commit de départ (la « base ») et un commit cible (l’« oracle »), séparés en moyenne par 233 jours et 71 commits de vrai historique de développement. Entre les deux, au moins 500 lignes de code source ont changé.
L’agent doit faire évoluer la base vers l’oracle, mais pas en une seule fois. Il procède par itérations successives, comme une équipe le ferait en intégration continue. À chaque tour :
Un agent « architecte » analyse les tests qui échouent, identifie les causes racines dans le code, et produit un document de requirements en langage naturel - pas plus de cinq exigences prioritaires, formulées en termes de comportement attendu, sans prescrire l’implémentation.
Un agent « développeur » lit ce document, comprend les contrats comportementaux, planifie ses modifications, et écrit le code. Sans exécuter les tests lui-même - c’est le système externe qui le fait.
Ce double protocole reproduit ce qui se passe dans une vraie équipe. L’architecte ne code pas. Le développeur ne sur-conçoit pas. Et c’est le résultat cumulé sur toute la séquence qui est mesuré.
Les chercheurs introduisent deux métriques originales. La première, le normalized change, mesure à chaque itération combien de tests supplémentaires passent par rapport à la base - avec une pénalité symétrique si des tests qui passaient sont cassés (ce qu’on appelle une régression).
La seconde, l’EvoScore, agrège ces mesures sur toute la séquence avec un poids croissant vers les dernières itérations. L’idée est simple et juste : un code vraiment maintenable est un code qui reste facile à modifier quand l’évolution avance. Un agent qui réussit les premières itérations en accumulant de la dette technique, puis s’effondre ensuite, sera pénalisé. Un agent qui progresse régulièrement, même lentement, sera récompensé.
Les chercheurs ont évalué 18 modèles de 8 fournisseurs différents, en dépensant plus de 10 milliards de tokens au total. Trois observations majeures ressortent.
Dans toutes les familles de modèles, les versions récentes surpassent systématiquement les précédentes. Et les modèles sortis après début 2026 affichent des gains particulièrement marqués. Ce n’est pas une progression linéaire : c’est une accélération. Ce qui était difficile il y a un an commence à être résolu.
Sur toute la période d’observation, la série Claude Opus se distingue nettement en tête, avec GLM-5 comme autre performeur remarquable.
Le paramètre γ de l’EvoScore permet de faire varier le poids donné aux premières versus aux dernières itérations. Quand on fait monter γ, on favorise les modèles qui maintiennent la qualité sur le long terme. Quand on le fait baisser, on récompense les gains immédiats.
Ce que les chercheurs observent est révélateur : les classements changent selon γ. MiniMax, DeepSeek et GPT favorisent les gains à long terme. Kimi et GLM privilégient les retours rapides. Qwen, Doubao et Claude restent relativement stables quelle que soit la pondération. Les auteurs interprètent ça comme un reflet des choix de formation - chaque fournisseur oriente ses modèles différemment, et ça se voit.
C’est l’observation la plus parlante, et la plus directement utile pour quiconque utilise l’IA dans ses projets.
Une régression, en développement, c’est quand une modification casse quelque chose qui fonctionnait avant. C’est le cauchemar de tout développeur expérimenté. Et c’est précisément là que les LLMs actuels peinent le plus.
Traduction concrète : si vous demandez à la plupart des LLMs actuels d’entretenir un projet sur la durée, dans plus de 75% des cas, ils vont casser quelque chose qui marchait. Pas intentionnellement. Pas par négligence. Par manque de vision de l’ensemble - exactement comme un développeur junior qui règle un bug sans lire le reste du code.
Quand j’ai commencé à construire phpmetrics, la question centrale était : comment savoir, objectivement, si un projet PHP est en bonne santé ? Pas si ça compile. Pas si ça passe les tests. Mais si la structure interne du code va permettre qu’on y travaille encore dans six mois sans souffrir.
La complexité cyclomatique. Le couplage entre modules. La cohésion des classes. L’instabilité des composants. Ces métriques n’ont rien de glamour. Elles ne répondent pas à la question « ça marche ? » - elles répondent à la question « ça va tenir ? »
ast-metrics prolonge cette logique en allant plus profond dans la structure syntaxique du code, indépendamment du langage. L’idée reste la même : donner une image de la maintenabilité, pas seulement de la fonctionnalité.
Ce que SWE-CI vient de formaliser pour les agents IA, c’est exactement cette distinction. Et ça m’a frappé en lisant le paper : les chercheurs ont construit, pour évaluer les LLMs, le même type de raisonnement que celui qui a guidé ces outils depuis le début.
Faire fonctionner, c'est nécessaire. Faire durer, c'est différent. Les deux ne se mesurent pas de la même façon.
Les LLMs excellent aujourd’hui à faire fonctionner. Ils progressent, vite, sur la question de faire durer. Mais ils n’y sont pas encore - sauf exception. Et cette exception n’est pas anodine : Claude Opus 4.6 atteint un taux sans régression de 0.76. C’est remarquable. C’est aussi la preuve que c’est possible, et que le reste du marché va suivre.
Pour moi, la leçon pratique est double.
D’abord, les métriques de maintenabilité ne sont pas un luxe. Elles l’étaient peut-être quand le code était entièrement humain et que les équipes avaient naturellement une mémoire du projet. Elles deviennent essentielles quand on génère du code à vitesse industrielle, avec des outils qui n’ont pas de mémoire entre les sessions et aucune vision de l’architecture globale. Sans mesure externe, on avance à l’aveugle.
Ensuite, l’IA ne remplace pas l’architecture - elle en a d’autant plus besoin. Un LLM qui génère une fonction le fait dans un contexte local, sans voir les modules adjacents, sans comprendre les contraintes qui ont guidé les décisions passées. Plus on délègue la production de code à ces outils, plus il devient important que quelqu’un (un humain) maintienne la vision d’ensemble, fixe les invariants, définit les contrats.
Ce n’est pas une critique de l’IA. C’est une description de ce qu’elle est aujourd’hui : un outil de production extraordinairement puissant, qui a besoin d’un cadre pour que sa puissance ne se retourne pas contre elle-même.
Trente ans de code m’ont appris que les problèmes vraiment coûteux ne sont presque jamais des bugs. Ce sont des erreurs d’architecture découvertes trop tard, des dépendances mal pensées, des abstractions qui ne tiennent pas à l’épreuve du temps. Les LLMs n’ont pas encore résolu ça. Et c’est précisément pour ça que des outils comme phpmetrics ou ast-metrics restent utiles - pas comme rempart contre l’IA, mais comme complément nécessaire.
Le paper SWE-CI est disponible sur arXiv : arxiv.org/abs/2603.03823. Il est accessible, bien écrit, et ses données sont publiques sur Hugging Face. Si vous travaillez avec des agents IA sur des projets réels, ça vaut le détour.
Pour aller plus loin
💡 Ces sujets vous parlent ?
Vous voulez améliorer la qualité de vos projets sans ralentir la livraison.
J'accompagne les équipes PHP avec des audits ciblés et des formations concrètes. Architecture, tests, industrialisation et pratiques d'équipe, chaque intervention est adaptée à votre contexte.
© Jean-François Lépine, 2010 - 2026