LLM à l’état de l’art pour équipes de développement : analyse statistique et perspectives

26 mars 2026 Guillaume Deconde

Introduction

Bien que l’invention des neurones formels date de 1943 [1], ce sont les réseaux sémantiques qui ont mené l’intelligence artificielle (IA) de son premier âge d’or (1956-1974) jusqu’à sa première « hibernation » (1974-1980), marquant également la fin de l’optimisme concernant les promesses du connexionnisme (c’est-à-dire l’approche en sciences cognitives considérant les phénomènes mentaux comme pouvant être modélisés à partir de réseaux d’unités simples, typiquement, des neurones [2]) . De fait, après une période d’enthousiasme vraisemblablement démesuré, les investissements se sont taris. C’est le paradoxe de Moravec [3] : les raisonnements de haut niveau sont plus faciles à reproduire et simuler par une machine que des processus perceptifs ou moteurs (reconnaissance de formes notamment).

C’est pourquoi ce sont les systèmes experts, basés sur des ontologies et des moteurs d’inférences, qui ont remis l’IA et ses financements sur le devant de la scène. Ils ont même mené à la renaissance du connexionnisme via l’émergence des réseaux de neurones récurrents (1980-1987). Hélas, les investissements massifs qui les ont accompagnés n’ont, une fois encore, pas eu les effets escomptés. C’est ainsi que le soufflé est retombé (bulle économique), plongeant ainsi l’IA dans sa seconde hibernation (1987-1993).

Cependant, l’opiniâtreté de certain·e·s chercheur·euse·s et la loi de Moore ont permis par la suite d’engranger un certain nombre de succès (parmi lesquels la victoire de Deep Blue sur le champion d’échecs Gary Kasparov), offrant ainsi un regain d’intérêt pour l’IA à l’orée des années 2000.

C’est dans ce contexte qu’est apparu l’apprentissage profond [4], avec ses premières applications grand public telles que les assistants virtuels, et plus récemment, des IA dites « génératives », basées sur les célèbres LLM (Large Language Models – grands modèles de langage). Leur efficacité a permis à chacun·e d’expérimenter l’impression qu’il n’est (presque) plus possible de faire la différence entre la réponse d’un humain et celle d’une machine (ce que l’on nomme « test d’imitation » ou plus communément, test de Turing). Désormais, l’IA semble durablement s’installer dans les usages domestiques et professionnels.

C’est donc fort logiquement, en cordonniers bien chaussés, que les développeur·euse·s se sont emparé·e·s de cette innovation pour les assister dans l’exercice de leur métier.

Contexte

Le champ d’application des LLM est excessivement vaste (génération d’images ou de vidéos, synthèse et reconnaissance vocales, représentation vectorielles, etc.), mais dans la mesure où l’expertise de Zenika relève spécialement du développement informatique, porter notre attention sur les seuls modèles génératifs appliqués au développement informatique a du sens, aussi bien pour nous, en tant que cabinet de conseil, que pour nos client·e·s et lecteur·rice·s de ce blog.

Tous ces LLM ne se valent pas, et leur complexité de conception intrinsèque fait qu’il n’est plus possible pour un opérateur humain d’en comprendre finement le fonctionnement (ils sont basés sur des réseaux de neurones gigantesques et des milliards de paramètres) . Ils font désormais figure de boîtes noires. Dès lors, comment évaluer que tel ou tel modèle est meilleur qu’un autre ?

C’est justement ce sur quoi s’est penchée une équipe menée par Carlos Jimenez [5]. Pour tenter de répondre à cette question, ils ont développé en 2023 le SWE-bench (SoftWare Engineering – Benchmark). C’est un banc d’essai utilisé pour évaluer les capacités des modèles d’IA à résoudre de vrais problèmes de programmation.

Il teste si une IA peut lire un bug ou une issue d’un dépôt GitHub, en comprendre le code, le modifier pour produire un patch correct et faire passer avec succès les tests du projet. Concrètement, il mesure la capacité d’une IA à faire un travail d’ingénierie logicielle.

Ce benchmark est important parce que les benchmarks de code précédents testaient essentiellement des problèmes simples pouvant être résolus en quelques lignes. SWE-bench teste quant à lui des tâches réalistes impliquant la compréhension du projet entier. C’est donc beaucoup plus proche du travail réel d’un·e développeur·euse. C’est pourquoi SWE-bench verified est devenu le standard de l’évaluation des IA appliquées au développement informatique du fait de la validation humaine des 500 problèmes identifiés. Ainsi, il permet de calculer un score de performance des modèles d’IA correspondant au taux de problèmes résolus correctement. Le score est donc compris entre 0 (c’est-à-dire aucun problème résolu) et 1 (c’est-à-dire que les 500 problèmes sont résolus, score qui n’existe pas à l’heure où nous écrivons ces lignes).

Il mesure donc la capacité d’une IA à corriger de vrais bugs dans de vrais projets logiciels.

Problématique

SWE-bench possède un leaderboard public [6]. C’est un classement qui compare les performances de différents modèles d’IA sur un même benchmark, selon les mêmes critères d’évaluation (i.e même pipeline, même version), ce qui garantit la comparabilité.

A la date du 13 mars 2026, le graphique présentant l’évolution des scores au benchmark par les modèles d’IA du marché au fil du temps se présente ainsi.

Les modèles y apparaissent sous forme de points correspondant aux coordonnées de leur score en fonction de leur date de mise sur le marché, en vert ou en violet, suivant qu’ils soient open source ou propriétaires.

La ligne bleue représente la « frontière de l’état de l’art » (State Of The Art, SOTA), c’est-à-dire la performance maximale atteinte par un modèle sur une période donnée, jusqu’à ce qu’il soit dépassé par un modèle plus récent et plus performant.

L’examen de cette courbe donne l’impression qu’elle suit une tendance logarithmique, c’est-à-dire que l’amélioration de la performance s’amenuise au fil du temps : élevée au départ (les « marches » de l’escalier sont hautes et courtes), elle tend à diminuer par la suite (les marches deviennent moins hautes et plus longues). Si tel était le cas, cela signifierait qu’à terme, les modèles devraient finir par plafonner. Cela ne serait a priori pas surprenant. Depuis le rapport Meadows [7] de 1972, on sait que la croissance ne peut pas être infinie, du fait des limites planétaires, et la pression environnementale des infrastructures sur lesquelles l’IA s’appuie les rend difficilement soutenables dans le temps. De fait, l’amélioration constante de la puissance de calcul des machines semble récemment ralentie, comme le montre les graphiques ci-après, issus des travaux de Jaime Sevilla et de son équipe [8] (bien qu’à ce stade de leur analyse, ils manquent de données pour en être certains).

Cependant, la frontière de l’état de l’art ne tient compte que des meilleurs modèles à un moment donné, et ne prend pas en considération tous les autres modèles qui n’ont jamais été à l’état de l’art, c’est-à-dire meilleurs que tous les autres existant au moment de leur mise en production. Or, un modèle peut être meilleur que beaucoup d’autres, passés et actuels, sans pour autant n’avoir jamais été à l’état de l’art.

Bien évidemment, le SWE-bench verified consiste en un nombre fini de tâches à réaliser (500, en l’occurrence), et il n’est pas exclu que ce jeu de tâches-tests finisse par ne plus être adapté à comparer les modèles d’IA dans leur capacité à produire du code pour résoudre des problèmes de développement informatique : la méthode d’évaluation constitue en soi une limite artificielle, alors même que les tâches de développement sont possiblement amenées à évoluer, ce dont ce benchmark ne pourra pas rendre compte (sans quoi les comparaisons entre modèles passés, actuels et futurs en seraient biaisées). De surcroît, notre propos n’est pas d’interroger la fiabilité de ce benchmark en tant que telle, notamment liée au risque de contamination par la présence potentielle des réponses aux tâches dans les données d’entraînement (sachant que leur disponibilité sur le web rend ce risque prégnant). Par ailleurs, notre propos n’est pas non plus de déterminer quelles sont les tâches qui permettent de discriminer les modèles entre eux : réussissent-ils tous les mêmes tâches les plus « faciles » pour eux, et se distinguent-ils sur certaines tâches plus rarement résolues, ou bien ont-ils des spécificités qui les rendent respectivement efficaces sur certaines tâches et pas d’autres ? Cette question, centrale, mériterait de faire l’objet d’un article dédié pour lequel nous ne disposons pas des données brutes, ni du temps nécessaire (cette analyse serait titanesque).

L’objectif de cet article est donc multiple :

Analyser cette notion de frontière de l’état de l’art afin d’en déterminer la tendance (est-ce que des outils statistiques confirmeront ou pas notre intuition d’amenuisement de la performance ?)
Déterminer comment les autres modèles se situent vis-à-vis de cette frontière,
Identifier quels facteurs sont susceptibles d’en expliquer la performance,
Envisager raisonnablement des perspectives pour les évolutions à venir de ces modèles.

Car, in fine, de nombreu·x·ses collègues s’interrogent sur l’essor des IA génératives et la transformation de leurs métiers, voire même, leur éventuelle disparition. Il nous semble donc pertinent de proposer une analyse étayée sur une projection de l’obtention du score de 100% au SWE-bench verified par les IA, dans le sens où cela répond à des interrogations légitimes du moment.

Toutefois, notre propos n’est pas d’envisager ces prévisions d’évolutions sous l’angle de leurs potentielles conséquences sociétales et environnementales, dont nous restons cependant conscient des risques.

Analyse

Pour mener cette étude, nous avons téléchargé les données du leaderboard du SWE bench verified. A la date de rédaction de cet article, 71 LLM avaient été audités, dont la date de mise en production n’était connue que pour 58 d’entre eux, du 8 mai 2024 au 16 février 2026.

Il contient les informations suivantes :

Le nom du modèle et sa version,
Le nom de son éditeur,
La taille de son modèle,
La taille de sa fenêtre de contexte,
Les tarifs en input et output (en dollars par millions de token),
La date de mise en production du modèle,
Le type de license (propriétaire ou open source),
Et le score au SWE bench verified.

Ces données sont résumées comme suit :

Tendances des modèles à l’état de l’art

Pour avoir une vision plus objective de l’évolution à venir des performances des LLM au SWE-bench verified, nous analysons les données brutes avec un tableur, ainsi qu’avec Jamovi, un logiciel d’analyses statistiques adossé à R. L’idée étant de déterminer quelle est la meilleure courbe de tendance permettant d’anticiper les performances à venir des LLM.

L’ajustement de la courbe de tendance est assez bon (c’est ce que mesure le coefficient de détermination ou R², ici de .77 – si R²=1, alors tous les points seraient alignés sur la fonction – par convention, en statistique, on n’écrit pas le 0 avant la virgule ou le point, ce n’est pas un oubli !). Si cette courbe résume bien l’évolution du score des LLM au SWE bench verified, les meilleurs modèles devraient couvrir la totalité des épreuves du benchmark dans 7614 jours (soit la bagatelle de presque 21 ans).

Hélas, cette prévision n’a aucune valeur : elle anticipe un événement qui aurait lieu dans plus de 20 ans à partir de données qui remontent à moins de 2 ans. Or, pour reprendre cette citation de Winston Churchill : “Plus vous saurez regarder loin dans le passé, plus vous verrez loin dans le futur.” Bien malin·e serait celui ou celle qui pourrait imaginer de quoi le monde sera capable (ou pas) à si longue échéance…

C’est pourquoi le modèle linéaire semble être une meilleure alternative à la tendance logarithmique, puisque son ajustement est plus élevé (R²=.82).

Si c’est bien le cas, l’équation de la droite nous permet d’envisager que dans un délai de 710 jours après le début des mesures (dans 3 mois donc, autant écrire demain), les meilleurs modèles d’IA réussiront la totalité des 500 épreuves du SWE bench verified.

Pour finir, intéressons-nous à la courbe de tendance en loi de puissance. Celle-ci expliquant actuellement le mieux l’évolution de la puissance de calcul des IA [9], on ne peut ignorer que les performances des IA sont intimement liées à la puissance de calcul des infrastructures qui les sous-tendent. On constate qu’effectivement, son ajustement aux données est excellent, puisque supérieur à R²=.90.

Si cette hypothèse s’avérait exacte, c’est aux alentours de 1700 jours que les premiers LLM atteindraient 100% de réussite au SWE bench verified, soit un peu plus de 4,5 ans (du moyen terme donc).

Dans ce dernier cas également, on peut s’interroger sur la pertinence de la prévision, dont la durée prédite excède largement celle de l’historique.

De surcroît, le problème est que le coefficient de détermination n’est véritablement adapté qu’à évaluer l’adéquation de modèles linéaires à leurs données, et il n’est pas exclu que la loi de puissance leur soit sur-ajustée, de telle sorte que le R² nous dissimule la réalité des choses. Afin de contourner ce problème, nous souhaitons nous appuyer sur deux autres métriques à même de compenser ce biais :

le MAPE (Mean Absolute Percentage Error, erreur moyenne absolue en pourcentage), calculé ainsi [10]:

A _t représente le score observé,
F _t la valeur prévue par la courbe de tendance.
Leur différence est divisée par la valeur réelle A _t . La valeur absolue de ce ratio est additionnée pour chaque point (score et date correspondant à un LLM) et divisée par le nombre d’e points d’observations n.

Le sMAPE, qui est aussi une mesure d’erreur normalisée (un pourcentage) exprimant la précision des prévisions. Contrairement au MAPE, il est symétrique car il divise l’erreur par la moyenne des valeurs réelles et prédites (pour simplifier, une erreur positive y vaut autant qu’une erreur négative) :

Puisque ce sont des erreurs qui sont mesurées, plus ces valeurs sont basses et meilleur est le modèle.

	Logarithmique	Linéaire	Puissance
MAPE	0,180603278	0,15822828	0,111105637
sMAPE	0,183850046	0,1385956	0,106241004

L’examen de ces nouveaux indicateurs confirme bien l’ajustement supérieur de la fonction puissance à la frontière de l’état de l’art des LLM appliqués au SWE bench verified.

Tendances pour tous les modèles

Toutefois, comme nous l’avons précédemment signalé, le score seul ne nous permet pas de savoir quelles tâches, parmi les 500 du benchmark, ont été accomplies ou pas par les différents LLM évalués. Par conséquent, l’analyse des seuls modèles à l’état de l’art est forcément incomplète, pour ne pas dire biaisée. C’est pourquoi nous reproduisons l’analyse précédente sur l’ensemble de ceux-ci.

On constate que l’ajustement de la fonction logarithmique diminue drastiquement (R²=.40, ce qui est normal, plus il y a de points et plus il est difficile à la fonction de s’y ajuster). Dans l’optique de cette tendance, il faudrait 8369 jours pour que les LLM, en moyenne, résolvent les 500 problèmes du benchmark, soit presque 23 ans (attention, il s’agit bien d’une tendance globale, prenant en considération tous les LLM, les meilleurs comme les moins bons).

Comme précédemment, l’ajustement linéaire donne un meilleur résultat (R²=.52, quoique restant modeste), permettant d’anticiper un succès moyen à l’ensemble des épreuves du benchmark dans 9,5 mois.

Pour finir, la courbe de tendance puissance, présente quant à elle un R² légèrement plus bas que la fonction linéaire. Si elle était la plus adaptée, on pourrait raisonnablement imaginer que les 500 tâches soient entièrement couvertes, en moyenne, dans 5 ans et 8 mois.

Au final, lorsque l’on prend en considération tous les LLM, c’est le modèle linéaire dont les prévisions s’écartent le moins des valeurs observées, bien que cette supériorité par rapport aux deux autres modèles soit ténue.

	Logarithmique	Linéaire	Puissance
MAPE	0,285242982	0,240031079	0,24003108
sMAPE	0,217184975	0,161943092	0,19056993

C’est pourquoi il nous semble que le modèle linéaire est, à ce stade de notre analyse, le plus adapté à prédire l’évolution à venir des capacités des LLM au développement informatique.

Cette prévision semble assez réaliste, quand on songe qu’il y a moins de 2 ans, DeepSeek 2.5 ne résolvait même pas 17% des tâches du SWE bench verified, alors qu’aujourd’hui, Claude Opus 4.5 en résous plus de 80%.

Le modèle prédictif Prophet, développé par Meta et conçu pour détecter automatiquement les changements de tendance (donc les variations de la “pente”) aboutit peu ou prou à la même conclusion, tout en modélisant les paliers et sauts technologiques qui jalonnent l’évolution des LLM (chaque palier étant presque marqué par une progression exponentielle !).

Comparaisons entre modèles à l’état de l’art et les autres

Afin de mieux cerner cette notion “d’état de l’art”, nous analysons les écarts entre les modèles et ceux à l’état de l’art, au moment de leur sortie. Pour ce faire, nous calculons quatre nouvelles variables :

Le ratio de performance, ratio perf = score du modèle / score “état de l’art” en cours (pour les modèles à l’état de l’art, le ratio de performance est calculé à partir du score “état de l’art” précédent, par conséquent, ce ratio est inférieur à 1 pour les modèles qui ne sont pas à l’état de l’art, et supérieur ou égal à 1 pour les modèles à l’état de l’art).
Le retard sur l’état de l’art, c’est-à-dire combien de jours un modèle aurait-il dû sortir plus tôt pour être à l’état de l’art (les modèles à l’état de l’art ont donc un retard de zéro),
Le gain sur le restant, c’est-à-dire le pourcentage de problèmes supplémentaires résolus ou non par un modèle, vis-à-vis de l’état de l’art.
Le prix en fonction de la performance :
- Le tarif en input en fonction du score (input $ / score),
- Le tarif en output en fonction du score (output $ / score).

Pour commencer, nous examinons les corrélations entre les différentes variables dont nous disposons concernant les modèles. Les corrélations se lisent ainsi : elles mesurent l’intensité de la relation linéaire entre 2 variables par une valeur comprise entre -1 et +1. La corrélation est positive quand les 2 mesures varient dans le même sens (quand l’une augmente, l’autre aussi), et négative quand elles varient en sens opposé. C’est ce qu’illustre la droite de régression affichée, entourée d’une zone colorée représentant l’erreur standard, c’est-à-dire la zone de variabilité potentielle de cette droite (pour faire simple). La valeur p indique le pourcentage de chance de se tromper si l’on affirme que 2 variables sont “liées”, c’est-à-dire corrélées (quand l’une varie, l’autre varie également, dans un sens ou dans l’autre). Pour qu’une corrélation soit considérée comme significative, par convention, on veut avoir moins de 5% de chances de se tromper.

On constate que plus les scores augmentent et plus le ratio entre les scores des modèles et ceux de l’état de l’art tend vers 1 (graphique de gauche), alors même que ce ratio reste stable dans le temps (graphique de droite). Cela signifie que les compétiteurs s’approchent de plus en plus de l’état de l’art à mesure qu’il augmente, de sorte que la différence entre les deux s’amenuise.

En conséquence, le retard sur l’état de l’art diminue, à la fois en fonction de l’amélioration du score et du ratio de performance qui y est lié.

Pour autant, quand on regarde l’évolution au fil du temps (et c’est là tout l’intérêt de faire cette analyse sur plusieurs axes différents), ce retard augmente paradoxalement, ce qui confirme bien notre première impression de “plafond” dans l’évolution de la performance des modèles. L’évolution des scores donne l’impression qu’elle tend à se “tasser” (les marches de la frontière de l’état de l’art deviennent de moins en moins hautes et de plus en plus longues – et donc, le retard sur l’état de l’art augmente).

S’agissant du gain sur les tâches restantes, s’il semble diminuer avec le temps, il n’y est pourtant pas significativement corrélé. On peut donc le considérer comme stable.

Cela signifie que si le nombre de tâches non résolues parmi les 500 diminue avec le temps (c’est-à-dire que le score augmente), la proportion de nouvelles tâches résolues reste stable (par exemple, s’il ne restait que 2 tâches non résolues, en en résolvant une, on apporte un gain de 50% sur le restant, comme si l’on en avait traité 10 sur une vingtaine restante quelques temps auparavant).

Pourtant, plus les scores augmentent et le ratio de performance tend vers 1 (voire le dépasse), et plus le gain sur les tâches non résolues augmente.

Comment interpréter ce paradoxe ? Il illustre le fait que la frontière de l’état de l’art devient de plus en plus floue : les modèles tendent à se rapprocher des modèles à l’état de l’art, ce qui rend l’avantage concurrentiel de ces derniers de moins en moins différenciant.

Dans cette optique de rapprochement des performances des modèles au fil du temps, il est très intéressant de se pencher sur l’évolution du rapport prix/performance (en input et en output) afin de mieux en différencier les avantages :

On constate sans surprise que l’excellence à un prix ! Être à l’état de l’art coûte beaucoup plus cher en sortie que de se contenter de modèles moins performants. Et cette différence tend à s’accroître (graphique de gauche ci-après). En entrée, les meilleurs modèles tiraient encore leur épingle du jeu il y a quelques mois. Désormais, les autres LLM sont en moyenne moins chers, bien que la différence soit minime (graphique de droite ci-dessous).

Les rapports prix/performance des modèles à l’état de l’art baissent moins rapidement que ceux des autres modèles, alors même que ces derniers tendent à réduire l’écart (en termes de scores) avec les meilleurs. Or notre analyse ne serait pas complète si elle ne prenait pas en considération ces variables de prix : rouler dans une Koenigsegg Jesko Absolut (la voiture la plus rapide du monde) pour 3,5 millions d’euros vaut-il le coup quand on peut rouler dans une Porsche 911 turbo S (probablement bien assez rapide) pour “seulement” 275 400,00 € (prix client conseillé) ?

Analyse causale

Si tenter de lire l’avenir pour essayer de devenir meilleur peut avoir quelque utilité (pour peu que la boule de cristal soit un tableur…), cet exercice ne permet pas d’identifier les causes de l’amélioration des performances des modèles. Car le temps qui passe (et pendant lequel les LLM s’améliorent) n’est pas une cause en soit : c’est une période, un “conteneur” dans lequel se déroulent les phénomènes, sans pour autant les expliquer. C’est pourquoi, dans l’optique d’améliorer nos prévisions d’évolution des LLM appliqués au développement informatique, nous désirons mettre en lumière leurs facteurs de performance.

Il existe une forte corrélation entre le délai (c’est-à-dire la date de mise en production du modèle ramenée en nombre de jours à partir de la date de sortie du premier modèle évalué – DeepSeek 2.5 le 8 mai 2024) et le score. C’est ce que notre première analyse a mis en évidence en identifiant la relation linéaire entre le temps et le score.

De façon assez surprenante, la taille du modèle n’est pas corrélée au score :

En réalité, il est difficile de conclure dans la mesure où la taille (Size) n’est disponible que pour 21 modèles du jeu de données (et uniquement les modèles ouverts, les modèles propriétaires protégeant possiblement cette information), ce qui est peu pour une analyse corrélationnelle. On constate cependant que plus la taille augmente et plus le score augmente aussi, mais les données sont trop dispersées pour que le lien soit statistiquement significatif.

Par contre, la taille du contexte est faiblement, mais significativement, corrélée au score.

On constate néanmoins que cet effet du contexte sur le score s’amenuise pour les fenêtres contextuelles de très grande taille. Ce problème a été pointé par Jimenez et son équipe, qui ont constaté, dans le sillage de travaux précédents, que de trop grands contextes pouvaient stocker du “bruit” non lié à la résolution d’un problème, et ainsi, étaient de nature à diminuer la performance des modèles.

De fait, les modèles à l’état de l’art bénéficient d’une amélioration de leurs performances liée à l’augmentation de la taille de leurs fenêtres contextuelles sans pour autant atteindre le maximum actuel. On ne peut donc pas exclure que ce soit l’une des clés de leur performance : faire mieux avec moins, paradoxalement (cf. graphique ci-après).

Il est intéressant de constater que si le score augmente au fil du temps, exception faite du contexte (et cela même sans tenir compte des plus grosses fenêtres)…

… ce n’est pas le cas des autres variables, notamment les tarifs.

C’est pourquoi on constate que le prix du million de tokens en sortie (output $) n’est pas corrélé au score. Cependant, si l’on censure la variable output$ de ses valeurs extrêmes, la corrélation devient visible.

Cette dernière considération s’applique aussi au prix du million de tokens en entrée, pour peu que l’on en censure aussi les valeurs extrêmes.

Que ce soit en input ou en output, avec ou sans les valeurs extrêmes, on constate que les modèles à l’état de l’art sont plus chers que les autres…

… Alors même que leurs performances ne sont pas beaucoup plus élevées (la différence entre les 2 n’est pas statistiquement significative).

Si bien sûr, il n’y a aucun lien de causalité direct entre ce prix et la performance (une corrélation n’est pas une causalité), on peut légitimement penser qu’un meilleur modèle pourra se vendre plus cher, ou que, à l’inverse, un modèle plus coûteux à mettre en oeuvre sera potentiellement meilleur, ce qui se traduira par un prix plus élevé. C’est pourquoi on constate une corrélation élevée entre les tarifs et la taille du modèle.

Pour conclure cette partie, les facteurs de la performance des modèles nous restent à ce stade très largement méconnus – ou pour le moins, absents de ce jeu de données. On pensera aux données d’entraînement des modèles, non évaluées, aussi bien en termes de qualité que de quantité, ainsi qu’aux caractéristiques physiques des infrastructures (GPU) et leur architecture (parallélisation), etc.

On constate néanmoins que les tarifs en input et output sont très corrélés entre eux (beaucoup plus qu’avec la taille du modèle), effet d’autant spectaculaire si l’on en censure les valeurs extrêmes :

Ceci plaide, selon nous, en faveur d’une stratégie des éditeurs de LLM en matière de pricing, en fonction de leurs objectifs marketing (puisque le seul facteur commun entre les deux est d’avoir été décidés par l’éditeur), et indépendamment de la taille de leurs modèles. Cette stratégie prend notamment forme dans le choix du modèle ouvert ou propriétaire.

Analyse par type de licence

C’est pourquoi nous souhaitons poursuivre notre exploration de ce jeu de données en changeant d’unité d’analyse, et en se plaçant au niveau des éditeurs, en ce qu’ils proposent des modèles ouverts ou propriétaires.

Il apparaît en premier lieu que les modèles propriétaires, plus nombreux que les modèles ouverts, se sont révélés plus souvent à l’état de l’art que leurs concurrents.

Là où les licences ouvertes de distinguent véritablement des licences propriétaires, c’est sur leur coût, aussi bien en entrée qu’en sortie.

C’est ce qui justifie que les modèles à l’état de l’art soient plus coûteux que les autres : ils sont pour l’essentiel des modèles propriétaires.

Bien évidemment, les modèles économiques des LLM, suivants qu’ils soient fermés ou ouverts diffèrent considérablement, et les services associés que proposent les IA propriétaires dépassent largement la seule puissance de calcul. Il faut cependant souligner que la modération tarifaire du modèle ouvert ne se fait pas au détriment de la performance ramenée au prix.

Car au final, les licences ouvertes se révèlent légèrement plus performantes que les modèles fermés, bien que cette différence ne soit pas statistiquement significative (c’est-à-dire qu’elle n’est due qu’aux fluctuations du hasard).

Cette (petite) différence s’explique notamment parce que les modèles ouverts sont sortis en moyenne plus récemment que leurs homologues propriétaires.

Quoi qu’il en soit, le type de licence n’est désormais plus synonyme d’une moindre performance. Au contraire, la tendance montre que tous les modèes tendent à rejoindre la frontière de l’état de l’art.

Conclusion

Au terme de cette étude, on mesure à quel point la question n’est plus de savoir si les LLM réussiront un jour les 500 tâches du SWE Bench verified, ni même de savoir quand, parce que cela arrivera probablement dans quelques mois, sans faire de la futurologie de comptoir. A cet égard, notre travail n’apporte rien à la publication récente d’Anthropic concernant les métiers menacés par l’IA, parmi lesquels ceux de l’informatique figurent en tête de liste [11] (cf. la zone bleue du graphique ci-après) :

S’agit-il d’une “vraie” menace (destruction de postes, réduction de l’embauche des juniors) ou seulement d’un risque de transformation du métier, notre analyse ne peut pas répondre à cette question (mais ce n’était pas son objectif). Néanmoins, ce SWE bench verified est, comme son nom l’indique, vérifié par des humains. En conséquence, notre capacité à juger de la pertinence des IA, fussent-elles de simples assistants, restera cruciale (à moins de déléguer la validation des machines à d’autres machines, auquel cas nous aurions franchi un cap supplémentaire dans la délégation de nos compétences). Toutefois, la question des limites de ce benchmark de 500 tâches, dont la liste est pour l’instant figée, se pose déjà. Ces tâches resteront-elles représentatives du quotidien d’une équipe de développement ? N’y a-t-il pas un risque de surapprentissage ou plus trivialement, de faire en sorte que ces IA réussissent ce test, au détriment de leur réelle amélioration (loi de Goodhart [12]) ?

Par ailleurs, si l’on omet qu’un LLM a moins besoin de travailler qu’un·e développeur·euse ou que son éditeur pour vivre, la question du prix à payer (social et environnemental) sera très certainement pondérée par son coût (c’est-à-dire son tarif). A ce titre, les modèles ouverts semblent tirer leur épingle du jeu, dans un contexte géopolitique tendu où le sujet de la souveraineté du traitement des données et de leur hébergement redevient crucial. En cela, les métiers de l’informatique ont encore quelques belles années devant eux pour gérer ces architectures, au-delà des seules compétences de développement. Reste que les modèles propriétaires, en proposant un service d’IA sur étagère ont pour eux la facilité d’accès (pour peu que l’on s’acquitte du ticket d’entrée). L’IA deviendra-t-elle une “commodité”, au même titre que l’électricité – dont on ne se préoccupe plus du coût tant elle est essentielle – ou que les emails, service indispensable à la gratuité apparente ?

Reste la question de la rentabilité de ces modèles : les modèles ouverts seront-ils suffisamment chers pour être rentables, les modèles propriétaires seront-ils suffisamment abordables pour être vendables, bref : une nouvelle bulle économique va-t-elle éclater ? Qui vivra saura, mais pendant qu’OpenAI a hissé ses revenus à 20 milliards de dollars [13], il a déclaré une perte opérationnelle de 17 milliards [14].

A ce titre, l’étude de Anthropic semble témoigner d’un enthousiasme modéré des collaborateurs à scier la branche sur laquelle ils sont assis (cf. la zone rouge du graphique précédent) [15].