BC-Bench: Evaluating Agentic Engineering in a Domain-Specific Language for ERP
Cet article introduit BC-Bench, un nouveau benchmark comprenant 101 tâches réelles dans le langage spécifique au domaine AL pour Microsoft Dynamics 365 Business Central, afin de démontrer que la performance de l'ingénierie agentique sur les benchmarks généraux ne se traduit pas de manière fiable dans les contextes ERP d'entreprise et souligne le besoin critique d'une évaluation spécifique au domaine.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Dans le monde du logiciel moderne, un nouveau type de travailleur a émergé : une intelligence artificielle capable d'écrire du code, de corriger des erreurs et de construire des programmes de manière autonome. Ces systèmes, souvent appelés agents de codage, ont été entraînés sur de vastes bibliothèques d'instructions écrites par des humains et ont fait preuve d'une compétence remarquable dans les langages de programmation à usage général comme Python. Ils peuvent résoudre des énigmes qui demandaient autrefois des heures de travail aux ingénieurs humains. Cependant, le monde réel des logiciels d'entreprise est rarement aussi simple. Une grande partie de l'infrastructure critique qui fait fonctionner le commerce mondial repose sur des langages spécialisés conçus pour des industries spécifiques, où les règles sont différentes, les outils sont uniques et les enjeux sont élevés. L'un de ces environnements est celui de la planification des ressources de l'entreprise (ERP), où les sociétés gèrent tout, de l'inventaire à la paie. Ici, le logiciel parle un langage appelé AL, un dialecte spécialisé utilisé pour faire fonctionner le système Microsoft Business Central. Pendant des années, il est resté incertain si ces puissants agents d'IA pourraient naviguer dans ce paysage complexe et propriétaire ou si leur succès dans le codage général était un phénomène qui s'estompait face aux contraintes réelles des entreprises.
Pour répondre à cette question, des chercheurs de Microsoft ont créé un nouveau terrain d'essai appelé BC-Bench. Ils n'ont pas inventé un puzzle théorique ; au lieu de cela, ils ont fouillé dans le code réel et vivant de deux énormes dépôts de logiciels qui alimentent de véritables entreprises. À partir de ces archives numériques, ils ont soigneusement sélectionné 101 tâches spécifiques que des ingénieurs avaient résolues par le passé. Il ne s'agissait pas d'exemples fictifs, mais de problèmes authentiques : un bug qui faisait échouer l'enregistrement d'un client, une fonctionnalité manquante dans un rapport de ventes, ou un test qui devait être écrit pour détecter une erreur. Les chercheurs ont ensuite demandé à plusieurs des agents d'IA les plus avancés au monde de tenter ces mêmes tâches. Les agents recevaient la description originale du problème, qui incluait parfois des captures d'écran de l'erreur, ainsi qu'un instantané du code tel qu'il existait avant la correction. Leur objectif était d'écrire les modifications de code exactes nécessaires pour résoudre le problème, tout comme le ferait un ingénieur humain. Le système exécutait ensuite le logiciel dans un environnement simulé pour voir si le nouveau code corrigeait réellement le problème sans rien casser d'autre.
Les résultats ont révélé un paysage où l'identité du modèle d'IA importait bien plus que l'outil spécifique utilisé pour effectuer le travail. Lorsque les chercheurs ont comparé différentes versions des agents, ils ont constaté que le choix du cerveau sous-jacent — le grand modèle de langage — avait un impact beaucoup plus important sur le succès que le choix de l'enveloppe logicielle, ou « harness », qui le guidait. Par exemple, l'un des modèles les plus récents, Claude Opus 4.6, a résolu près de 69 % des tâches de correction de bugs lorsqu'il était associé à un outil standard, tandis qu'une version plus ancienne du même modèle n'en a résolu qu'environ 58 %. En revanche, changer l'outil lui-même tout en gardant le même modèle n'a produit que des différences infimes et statistiquement insignifiantes. Cela suggère que pour ces tâches commerciales complexes, l'intelligence du modèle est le principal moteur de la réussite, et non l'interface spécifique qu'il utilise pour accéder au code.
La découverte la plus frappante fut peut-être que les améliorations observées dans les tests de codage général ne se traduisent pas automatiquement dans ce monde spécialisé. Dans le monde plus large de l'ingénierie logicielle, les nouveaux modèles montrent souvent des gains progressifs et prévisibles par rapport à leurs prédécesseurs. Pourtant, dans cet environnement commercial spécifique, un modèle qui avait récemment surpassé son prédécesseur sur les benchmarks généraux n'a pas montré le même avantage ici. Un modèle qui s'était nettement amélioré sur les tâches générales n'a pas performé mieux que son prédécesseur face à ces énigmes de logique métier. Cela indique que les compétences requises pour corriger un script Python générique ne sont pas les mêmes que celles nécessaires pour corriger un calcul financier dans un système métier spécialisé. La nature spécialisée du langage, avec ses règles strictes sur la façon dont les données circulent et dont la logique métier est validée, crée une barrière que l'entraînement général seul ne peut facilement surmonter.
Les chercheurs ont également examiné de près les raisons pour lesquelles les agents échouaient. Ils ont découvert que les machines échouaient rarement parce qu'elles ne pouvaient pas construire le logiciel ou parce que le code ne compilait pas ; ces obstacles techniques étaient facilement franchis. Au contraire, les échecs concernaient presque toujours la compréhension du problème. Dans près de la moitié des tentatives ratées, l'agent regardait la mauvaise partie du code, modifiant des fichiers qui n'avaient aucun rapport avec l'erreur. Dans un autre groupe important d'échecs, l'agent trouvait le bon fichier et la bonne section de code, mais appliquait tout de même la mauvaise logique, implémentant une solution qui semblait correcte mais qui ne corrigeait pas réellement la règle métier. Par exemple, un agent pouvait identifier correctement qu'un numéro de commande client manquait, mais écrivait ensuite un code qui assignait le mauvais type de numéro, laissant le système défaillant. Ces erreurs suggèrent que les agents peinent à naviguer dans le réseau profond et interconnecté des règles métier qui définissent le fonctionnement d'une entreprise, manquant souvent le contexte subtil qu'un ingénieur humain saisirait immédiatement.
La complexité de la tâche jouait également un rôle décisif. Lorsque la correction ne nécessitait que la modification d'un seul fichier ou d'un petit nombre de lignes, les agents étaient assez performants. Cependant, dès que la solution exigeait de modifier plusieurs fichiers ou d'écrire plus de quelques dizaines de lignes de code, le taux de réussite chutait brutalement. Cette chute était spectaculaire, la précision diminuant de plus de vingt points de pourcentage lorsque la tâche impliquait plus d'un fichier. Il semble que si ces agents peuvent gérer de petites réparations isolées, ils éprouvent encore des difficultés à coordonner des changements au sein d'un système vaste et interconnecté. De plus, le type de domaine métier importait ; les agents étaient plus performants pour corriger des problèmes de gestion des stocks que pour la logistique d'entrepôt, ce qui suggère que leurs données d'entraînement étaient plus riches dans certains domaines commerciaux que d'autres.
L'étude conclut que, bien que l'intelligence artificielle ait fait des progrès incroyables dans le codage général, le chemin vers une ingénierie entièrement autonome dans les environnements commerciaux spécialisés n'est pas encore clair. Les outils existent, et les modèles sont puissants, mais l'écart entre la capacité générale et la maîtrise spécifique au domaine reste important. Les chercheurs soulignent que pour progresser, l'industrie doit se concentrer sur ces benchmarks spécialisés plutôt que de se fier aux tests généraux. Ils précisent également que les limitations actuelles ne sont pas seulement une question d'intelligence brute, mais de capacité à comprendre le contexte, à naviguer dans des bases de code complexes et à appliquer la bonne logique métier. À mesure que ces systèmes évoluent, l'espoir est qu'ils apprendront éventuellement à naviguer dans les règles complexes des logiciels d'entreprise avec la même aisance qu'ils affichent désormais en programmation générale, mais pour l'instant, l'ingénieur humain reste essentiel pour les guider à travers les complexités du monde réel.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.