Agents de code : lire l’empreinte des patches

Un agent de code peut afficher un taux de réussite et laisser une question entière sans réponse : qu’a-t-il réellement modifié pour résoudre les tâches ?

Le score donne un résultat. Le patch montre le geste.

Parsimony propose une lecture complémentaire des patches déjà publiés dans plusieurs tableaux publics. Il ne relance pas les tests et ne juge pas la qualité du code. Il compare le code avant et après, puis décrit l’empreinte syntaxique des changements. Présentez séparément la réussite, la quantité de code, la complexité et la couverture.

L'essentiel à retenir

Parsimony analyse des patches publiés par DeepSWE, SWE-bench Verified, SWE-bench Live et d’autres tableaux publics. Le projet compare le code avant et après sans l’exécuter. Il compte les éléments syntaxiques ajoutés ou retirés, appelés « coding units » : instructions, appels, comparaisons, noms ou littéraux. Les commentaires, la mise en forme, la ponctuation et la longueur des noms ne sont pas comptés. Il peut aussi examiner la complexité ajoutée à travers les branches, les boucles et les fonctions.

Si votre prestataire vous remet un rapport d’évaluation d’un agent de code, demandez un tableau complémentaire limité aux patches réussis et mesurables. Lisez ensuite cinq colonnes séparément : réussite, empreinte, complexité, couverture et limites. Une petite empreinte ne prouve ni la qualité, ni la maintenabilité, ni la sécurité. Une empreinte plus grande ne prouve pas davantage un problème. Le rapport sert à formuler des questions de revue sur les modifications publiées. Il ne remplace ni les tests, ni l’examen du code, ni l’analyse du contexte de chaque tâche.

Le problème que ça résout

Un taux de réussite répond à une question binaire : combien de tâches du périmètre évalué ont été résolues selon le dispositif utilisé ? Il ne décrit pas la forme des changements produits.

Placez cette différence dans sa propre colonne. Pas un verdict automatique. Une seconde dimension du rapport.

Parsimony fournit cette dimension en mesurant le code ajouté et retiré au niveau syntaxique. Le projet écarte ce qui modifierait le volume visuel sans modifier de la même manière la structure du programme : commentaires, espaces, ponctuation ou noms plus longs. Le lecteur obtient ainsi une mesure centrée sur les éléments du code, plutôt qu’un simple comptage de lignes.

L’outil peut également décrire la complexité ajoutée par les branches, les boucles et les fonctions. Demandez où se trouvent les écarts : dans quelles tâches, dans quelle famille de patches, dans quel langage ou dans quel benchmark.

La limite doit rester visible dans le même document. Parsimony n’exécute pas le code. Il part de réparations publiées, réussies et mesurables. Certaines tentatives ne peuvent pas être analysées. Demandez que chaque tableau nomme les tâches et les entrées qu’il présente.

Ce que c'est concrètement

Parsimony est un projet Python sous licence MIT. Le dépôt réunit un site web, un analyseur, des données publiées, une méthode documentée et les éléments nécessaires à la reconstruction des analyses. Un décideur peut demander à son équipe technique de reprendre la structure du rapport et d’y rattacher chaque résultat à son périmètre.

L’unité de base est la « coding unit ». Elle correspond à un élément syntaxique du programme : une instruction, un appel, une comparaison, un nom ou un littéral. Parsimony compte les unités ajoutées et retirées entre la version précédente du code et le patch publié.

Ce choix ne transforme pas la mesure en note de qualité. Il déplace simplement le regard. Une différence de mise en forme ne pèse pas comme un nouvel appel ou une nouvelle condition. Un commentaire ajouté ne pèse pas comme une boucle. Le rapport décrit l’empreinte du changement selon cette méthode.

Les tableaux séparent les benchmarks et les langages. Ils peuvent présenter des mesures brutes ou des mesures relatives sur des tâches communes. Les données publiées restent accessibles, ce qui permet à une équipe technique de rattacher une synthèse à son périmètre d’analyse.

La complexité constitue une autre lecture. Parsimony peut relever l’ajout de branches, de boucles et de fonctions. Ces éléments ne sont pas des défauts en eux-mêmes. Leur présence signale seulement qu’un patch introduit une structure qu’une revue peut localiser et examiner.

Comment s'en servir

Prenons une hypothèse concrète : votre prestataire vous remet un rapport d’évaluation d’un agent de code. Le document contient un taux de réussite global et quelques commentaires. Demandez une annexe consacrée aux patches publiés, puis imposez une lecture en étapes distinctes.

Étape 1 : fixer le périmètre du tableau

Demandez le nom du benchmark, le langage, l’ensemble de tâches, la période des données et le dispositif d’agent utilisé. Faites préciser si les lignes portent sur toutes les tentatives, sur les réparations réussies ou uniquement sur les réparations réussies et mesurables.

Notez ces éléments en tête du rapport. Placez chaque moyenne sous le benchmark, le langage, les tâches et le dispositif auxquels elle se rapporte.

Étape 2 : isoler le taux de réussite

Conservez le taux de réussite dans une colonne dédiée. Ne le fusionnez pas avec une mesure de taille du patch. Il indique le résultat observé par le tableau public et son dispositif d’évaluation. Parsimony ne relance pas les tests qui ont produit ce statut.

Demandez aussi comment les tentatives non mesurables apparaissent dans le rapport. Une absence de mesure n’est pas une empreinte nulle. Elle doit rester une catégorie distincte.

Étape 3 : lire l'empreinte ajoutée et retirée

Ajoutez le nombre de coding units ajoutées et retirées. Demandez une distribution par tâche, pas seulement une moyenne générale. Faites apparaître les écarts et les patches situés aux extrêmes sans leur attribuer automatiquement une cause.

Pour les cas retenus, demandez à l’équipe technique d’indiquer quels éléments syntaxiques expliquent l’empreinte : appels, comparaisons, noms, littéraux ou instructions. Le chiffre devient alors une porte d’entrée vers le patch concerné.

Étape 4 : séparer taille et complexité

Ajoutez des colonnes propres aux branches, boucles et fonctions introduites. Comparez ces colonnes à l’empreinte totale, puis demandez à l’équipe technique de localiser les structures de contrôle dans les patches concernés.

La question à poser n’est pas « quelle valeur est bonne ? ». Demandez plutôt où la complexité apparaît, quelle tâche l’a produite et quelle partie du patch la porte.

Étape 5 : vérifier la couverture

Faites afficher le nombre de réparations publiées, le nombre de réparations réussies, le nombre de patches mesurables et le nombre de cas exclus. Demandez la raison des exclusions lorsqu’elle est disponible.

Présentez la couverture à côté du résultat. Gardez les absences dans une catégorie distincte. Demandez aussi si les mesures relatives reposent bien sur des tâches communes entre les entrées comparées.

Étape 6 : ouvrir quelques patches ciblés

Sélectionnez avec l’équipe technique plusieurs cas : un patch à faible empreinte, un autre à forte empreinte, un cas avec complexité ajoutée et un cas non mesurable. Demandez une note factuelle pour chacun : tâche, fichiers touchés, éléments syntaxiques ajoutés ou retirés, branches, boucles, fonctions et statut publié.

Ne déduisez pas la qualité depuis le volume. Limitez la revue à ce que les agrégats désignent dans le code avant et après.

Étape 7 : écrire les limites dans la conclusion

Terminez le rapport par une section qui distingue explicitement ce que Parsimony mesure et ce qu’il ne mesure pas. Mentionnez l’absence de nouvelle exécution des tests et les tentatives non mesurables. Faites aussi nommer les tâches et les entrées présentes dans chaque tableau.

Présentez la conclusion en trois lignes séparées : résultat observé, empreinte observée, limites du corpus. Ne transformez pas ces lignes en note composite si la méthode ne la définit pas.

Ce que ça coûte vraiment

Parsimony n’affiche pas de prix de service dans les éléments présentés ici. Dans votre cahier des charges, comptez le travail nécessaire pour produire et lire un rapport délimité.

Côté technique, il faut relier les données publiées au benchmark, au langage et aux tâches concernés. Il faut aussi identifier les patches mesurables, conserver les exclusions et présenter séparément les mesures brutes et relatives lorsque les deux sont utilisées. Une comparaison relative demande un ensemble de tâches communes clairement indiqué.

Côté décisionnel, demandez un tableau qui conserve les dimensions suivantes : réussite, coding units ajoutées, coding units retirées, branches, boucles, fonctions, couverture et limites. Confiez ensuite à l’équipe technique la revue des cas situés aux extrêmes.

Inscrivez quatre livrables dans la demande : le périmètre documenté, les colonnes de mesure, la liste des exclusions et le rattachement des agrégats à quelques patches. Le dépôt fournit une méthode et des données publiées. Demandez au rapport de préciser comment elles ont été sélectionnées et présentées.

Pour qui ce n'est pas

Parsimony ne convient pas comme réponse unique à une décision sur un agent de code. Il ne relance pas les tests, n’observe pas l’exécution du programme et ne mesure pas la maintenabilité, la qualité, le coût futur ou la sécurité.

Ce n’est pas non plus un classement universel. Les tableaux distinguent benchmarks et langages. Le classement décrit seulement les réparations réussies et mesurables du périmètre retenu.

L’outil ne fournit pas de règle selon laquelle moins de code serait meilleur. Ne concluez pas depuis la seule taille d’un patch. Utilisez-la pour sélectionner les questions suivantes et les cas à ouvrir.

Source : https://github.com/La5u/Parsimony

FAQ

Parsimony remplace-t-il le taux de réussite ?

Non. Le taux de réussite et l’empreinte des patches répondent à deux questions différentes. Le premier décrit les tâches résolues selon le dispositif publié. La seconde décrit les éléments syntaxiques ajoutés ou retirés dans les réparations mesurables.

Une petite empreinte indique-t-elle un meilleur patch ?

Non. Parsimony précise que moins de code ne signifie pas meilleur code. Une petite empreinte peut être signalée dans le rapport, puis examinée dans le patch. Elle ne constitue pas une mesure de qualité, de maintenabilité ou de sécurité.

Pourquoi compter des unités syntaxiques plutôt que des lignes ?

La méthode écarte les commentaires, la mise en forme, la ponctuation et la longueur des noms. Elle compte des éléments du programme comme les instructions, appels, comparaisons, noms et littéraux. Le rapport porte ainsi sur la structure syntaxique ajoutée ou retirée.

Que demander si certains patches ne sont pas mesurables ?

Demandez leur nombre, leur place dans le corpus et la raison de l’exclusion lorsqu’elle est disponible. Gardez-les séparés des empreintes nulles. Le classement de Parsimony porte sur les réparations à la fois réussies et mesurables.

Peut-on comparer directement deux lignes d'un tableau ?

Vérifiez d’abord le benchmark, le langage et les tâches communes. Demandez au rapport d’afficher ce périmètre près des résultats.

Quel livrable demander à une équipe technique ?

Demandez un tableau complémentaire sur les patches réussis et mesurables, avec réussite, unités ajoutées et retirées, branches, boucles, fonctions, couverture et exclusions. Ajoutez une revue factuelle de quelques patches ciblés et une section séparée sur les limites.

---

Publié le 9 novembre 2026.

Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.