Des copilotes aux collègues à l'AAAI : l'écart entre la recherche agentive et la production
Basé sur le panel de l'AAAI 2026 « From Copilots to Co-Workers: What Changes When AI Writes, Reads, and Reasons About Code? » — Singapour, 27 janvier 2026
Lors de l'atelier de l'AAAI 2026 sur les agents d'IA collaboratifs, un panel de chercheurs et de praticiens de Microsoft, Mistral, National University of Singapore (NUS), LinkedIn et Amazon Web Services (AWS) s'est réuni pour comparer leurs observations sur ce qui se passe réellement lorsqu'on tente de déployer des agents de programmation en production. Pas si ça fonctionne (ce débat est clos), mais ce qui casse, ce qui surprend, et ce qui doit être reconstruit en cours de route.
Panélistes :
- Shengyu Fu — Partner Applied Science Manager, Microsoft CoreAI. Dirige une équipe de recherche appliquée en IA pour le code qui pilote l'innovation dans GitHub Copilot, des complétions aux agents de programmation.
- Abhik Roychoudhury — Provost's Chair Professor of Computer Science, National University of Singapore. Fellow de l'ACM, rédacteur en chef d'ACM TOSEM. Dirige le groupe Trustworthy and Secure Software Engineering, avec des contributions couvrant la réparation sémantique de programmes, l'inférence de spécifications, les tests fuzz et AutoCodeRover.
- Baptiste Rozière — Dirige l'équipe de génération de code chez Mistral AI. Auparavant chez Meta AI, où il a contribué à Llama et dirigé Code Llama.
- Alborz Geramifard — Distinguished Scientist chez LinkedIn
- Omer Tripp — Principal Applied Scientist chez AWS
La recherche actuelle optimise principalement pour la capacité, tandis que la production optimise pour la fiabilité, le coût, la latence, la confiance et l'adéquation organisationnelle.
Il existe un schéma familier en IA pour le développement logiciel. Un article démontre des résultats impressionnants sur un banc d'essai. Une équipe tente de le déployer. Puis le vrai travail commence, non pas sur le modèle, mais sur tout ce qui l'entoure : la couche d'orchestration qui décide quand invoquer quel modèle, l'architecture de coûts qui maintient l'inférence viable à grande échelle, le budget de latence qui déterminera si un développeur attend ou abandonne, le cadre d'évaluation qui indique si l'agent aide réellement ou génère simplement du bruit plausible, et la surface de confiance (les explications, les pistes d'audit et les points d'interruption) qui déterminera si quelqu'un délèguera du vrai travail à l'agent.
Les panélistes ont fait ressortir, à plusieurs reprises et sous différents angles, que les défis du déploiement d'agents de programmation sont fondamentalement différents des défis liés à leur construction en laboratoire. La recherche optimise pour la capacité. La production optimise pour la fiabilité, le coût, la latence, la confiance et l'adéquation organisationnelle — simultanément. Et cet écart n'est pas un problème unique. Il se manifeste à plusieurs niveaux distincts, chacun avec ses propres leçons durement apprises.
Le premier défi est architectural. Lorsque les modèles étaient limités, le clavardage était un mode d'interaction naturel. Shengyu Fu (Microsoft) a décrit comment, une fois que VS Code a livré le clavardage dans Copilot, il était tentant de croire que le système était complet — la rédaction de requêtes semblait résumer toute l'histoire. Cette illusion ne survit pas à des modèles plus performants. À mesure que le raisonnement et l'utilisation d'outils se sont améliorés, les agents ont commencé à exécuter des actions à plusieurs étapes, à invoquer des outils de manière autonome et à s'autovérifier. Les défis sont passés de l'ingénierie de requêtes à l'orchestration, à la conception de systèmes et à l'évaluation. Les équipes qui n'ont pas reconnu cela tôt ont payé le prix en travail de reprise plus tard.
Dans ce paradigme agentif moderne, la spécialisation architecturale peut aider. Par exemple, GitHub Copilot utilise des sous-agents dédiés pour des tâches comme la recherche de code, réservant les modèles de raisonnement coûteux là où ils comptent vraiment. Mais cette spécialisation introduit ses propres problèmes. Chaque transfert entre agents ajoute de la latence, et à mesure que le contexte traverse plusieurs étapes, l'information se dégrade. À l'échelle de dizaines de millions de lignes de code, réduire les coûts exige une conception au niveau du système, pas simplement le remplacement par un modèle moins coûteux.
La façon dont les utilisateurs perçoivent cette latence a également évolué. En 2025, la vitesse était l'indicateur de la qualité. En 2026, les utilisateurs étaient disposés à attendre plus longtemps en échange de plus d'autonomie sur des requêtes complexes et de solutions plus complètes. La barre est passée de « répondre rapidement » à « en gérer plus pour que je n'aie pas à le faire ». Abhik Roychoudhury (NUS) a décrit comment les premières équipes d'agents, y compris la sienne, ont fortement optimisé le coût d'inférence à l'aide de techniques d'analyse de programmes. Ce qui a surpris plusieurs, c'est la rapidité avec laquelle la préparation organisationnelle a dépassé le coût comme contrainte limitante. Trois ans plus tôt, à l'International Conference of Software Engineering (ICSE), de nombreuses entreprises affirmaient catégoriquement que les LLM ne toucheraient jamais leur code. Cela s'est inversé une fois que les développeurs ont constaté les gains de productivité. Le coût comptait moins que la volonté, et avec le bon échafaudage, a ajouté Abhik, une qualité supérieure à moindre coût est atteignable.
Point à retenir : la recherche vous donne la capacité; la production exige une architecture équilibrant coût, latence et qualité — et c'est cette architecture qui constitue l'essentiel du véritable travail d'ingénierie.
Le deuxième niveau de l'écart concerne le fait de savoir si votre agent est réellement bon, et de l'améliorer au fil du temps.
L'apprentissage par renforcement est un choix naturel, mais il se heurte à des murs d'infrastructure avant des murs algorithmiques. L'apprentissage par renforcement devrait être l'approche évidente pour entraîner des agents de programmation qui posent des actions dans des environnements. En pratique, les problèmes les plus difficiles sont des problèmes d'ingénierie. Alborz a décrit l'expérience de LinkedIn qui a traité l'entraînement d'agents comme un problème entièrement piloté par l'apprentissage par renforcement. L'utilisation GPU/CPU est devenue un défi systémique — les builds et l'exécution sont intensifs en CPU, créant des déséquilibres avec des grappes d'entraînement centrées sur le GPU. Recueillir des trajectoires tout en entraînant des modèles en parallèle a introduit une complexité de coordination. Des signaux de récompense naïfs ont invité au piratage de récompense : les agents ont appris à supprimer des tests pour paraître réussis.
De plus, pour atteindre la mise à l'échelle, LinkedIn a utilisé des machines virtuelles où chaque pod est une ardoise vierge. Les premières conceptions qui effectuaient des extractions git complètes à chaque étape ont saturé le système. La mise en cache et une hygiène stricte des artefacts sont devenues essentielles. À grande échelle, ils ont exécuté près de 800 problèmes, chacun exécuté plusieurs fois, générant des trajectoires en ligne. Shengyu a fait écho à des expériences similaires chez Microsoft : l'apprentissage par renforcement agentif est bien plus difficile que l'apprentissage par renforcement pour la complétion, en raison des trajectoires longues et des appels de modèle répétés. Baptiste a confirmé que Mistral a observé le même schéma : les environnements d'apprentissage par renforcement exigent significativement plus de CPU que les grappes de pré-entraînement.
Le consensus des trois organisations : les environnements d'apprentissage par renforcement évolutifs constituent la couche d'infrastructure manquante pour l'IA agentive. Actuellement, c'est une contrainte d'ingénierie, pas une frontière algorithmique.
Les bancs d'essai d'évaluation sont saturés et s'éloignent de la réalité. SWE-Bench a dominé l'évaluation en 2025, mais dès 2026, il s'est révélé structurellement désaligné avec la façon dont les développeurs utilisent réellement les agents. Alborz a souligné que les bancs d'essai fonctionnent généralement sur un seul dépôt, alors que le vrai travail s'étend sur plusieurs dépôts. Abhik a insisté sur le fait que la plupart des bancs d'essai mesurent l'écriture de code, alors que la lecture de code, la compréhension de l'intention et l'analyse d'impact sont tout aussi importantes mais largement non mesurées. Baptiste a ajouté que la justesse seule ne différencie pas les agents, car le respect des instructions et la généralisation comptent tout autant. Omer a soutenu que nous devrions optimiser pour les conditions de production, pas les contextes de laboratoire. Les entreprises construisent des bancs d'essai internes sur du code propriétaire, mais des normes partagées pour l'évaluation agentive font toujours défaut, et pour des systèmes déployés comme GitHub Copilot, les charges de travail agentives manquent encore de signaux quantitatifs clairs.
Point à retenir : l'évaluation et l'infrastructure d'entraînement sont les deux couches manquantes. Les bancs d'essai doivent aller au-delà de la justesse sur un seul dépôt pour saisir la lecture de code, les flux de travail multi-dépôts et le respect des instructions. Les environnements d'apprentissage par renforcement évolutifs sont la couche d'entraînement manquante, et chaque équipe qui a essayé s'est heurtée au même mur d'ingénierie, pas algorithmique.
Le troisième niveau concerne ce qui se passe autour de l'agent : comment les humains interagissent avec lui, comment la confiance se construit et ce que devient le rôle humain.
La latence et l'auditabilité deviennent déterminantes pour le produit. Omer a établi une distinction nette entre deux types de latence. La latence d'autocomplétion (le délai pendant qu'une IA suggère la prochaine ligne au fur et à mesure que vous tapez) est tolérable dans des limites raisonnables parce qu'elle s'inscrit dans un flux existant. La latence de délégation est fondamentalement différente : quand vous confiez une tâche entière à un agent et qu'il travaille de manière autonome sur plusieurs étapes, vous ne tapez plus à ses côtés, vous attendez simplement. Cette attente se couple immédiatement à l'auditabilité : les utilisateurs veulent savoir ce que l'agent fait, s'il est bloqué et s'ils peuvent l'interrompre. Ces questions déterminent si un système semble digne de confiance ou opaque.
La qualité est plus que la justesse. Abhik a redéfini la qualité selon deux dimensions sous-estimées. Premièrement, le rapport signal-bruit : l'agent respecte-t-il l'attention du développeur, ou génère-t-il du bruit qui exige un effort de filtrage? Un agent qui produit dix suggestions dont une seule est utile impose un coût caché, même si chaque suggestion est techniquement correcte. Deuxièmement, l'explicabilité : l'agent peut-il justifier des décisions inattendues? Un comportement surprenant est acceptable si le raisonnement est lisible. Dans ce cadre, la qualité devient inséparable de la confiance.
La vérification atterrit dans un juste milieu pratique. La vérification formelle reste hors de portée pour la plupart des systèmes. Le panel a convergé vers une alternative pragmatique : le développement piloté par les Specs (extraire des spécifications du code généré afin que les humains n'aient pas à revisiter les implémentations), les tests basés sur les propriétés (les modèles sont bien adaptés à leur génération, et ils servent d'explications exécutables), et la révision de code assistée par l'IA (utiliser l'IA pour encadrer l'IA, afin que les humains puissent se concentrer sur la logique métier).
Le rôle humain change, il ne disparaît pas. Une question du public a saisi une anxiété commune : comment les développeurs juniors devraient-ils progresser quand les agents écrivent une grande partie du code? L'ensemble de compétences émergent se concentre sur la lecture et la révision du code (plus importantes que l'écriture), la délégation (savoir quoi automatiser et ce qui exige un jugement humain), les tests et la validation (qui se déplacent au centre du rôle du développeur), et la résolution de l'ambiguïté (les humains restent la colle là où les spécifications sont incomplètes). NUS construit déjà des cours autour de ces principes. Comme l'a dit Alborz : s'il était étudiant, il redoublerait d'efforts sur la résolution de l'ambiguïté. Cette compétence restera précieuse même à mesure que les abstractions vont et viennent.
Point à retenir : la confiance est le produit, et elle se construit par l'auditabilité, la discipline du rapport signal-bruit et l'explicabilité. Le rôle humain passe de l'écriture de code au jugement, à la délégation et à la résolution de ce que les agents ne peuvent pas régler.
Le panel n'était pas purement théorique. Plusieurs exemples concrets ont émergé de la façon dont les équipes réduisent l'écart entre la recherche et la production :
Spécialisation architecturale chez GitHub Copilot. Plutôt que d'acheminer tout par un seul modèle coûteux, Copilot utilise des sous-agents dédiés pour des tâches comme la recherche de code, réservant les modèles de raisonnement puissants aux problèmes complexes. Cela permet d'atteindre une qualité supérieure à moindre coût grâce à la conception système plutôt qu'à la substitution de modèle.
L'infrastructure d'apprentissage par renforcement de LinkedIn. Pour entraîner des agents par apprentissage par renforcement à grande échelle, LinkedIn a construit un environnement utilisant des machines virtuelles comme ardoises vierges, avec une mise en cache agressive et une hygiène des artefacts. Les premières conceptions qui effectuaient des extractions git complètes à chaque étape ne pouvaient pas évoluer. Le système final a exécuté environ 800 problèmes avec une génération de trajectoires en ligne — un investissement d'infrastructure important qui a précédé tout gain algorithmique.
Le rééquilibrage de calcul de Mistral. L'équipe de Baptiste a découvert que les environnements d'apprentissage par renforcement pour les agents de code exigent bien plus de CPU que ce pour quoi leurs grappes de pré-entraînement étaient conçues. Reconnaître cela comme un problème d'infrastructure (et non algorithmique) a été l'idée clé.
La refonte du programme d'études de NUS. L'équipe d'Abhik construit des cours qui reflètent la nouvelle réalité : la lecture de code comme compétence essentielle, la délégation aux agents comme compétence, les tests comme élément central, et l'utilisation responsable des agents d'IA comme exigence.
La comparaison par paires pour l'étalonnage des juges. Alborz a proposé de construire des jeux de données dans le style « ce code est meilleur que cet autre code » — relativement peu coûteux à créer, et suffisant pour que les juges apprennent des classements relatifs fiables même quand l'étalonnage absolu est difficile.
L'IA qui révise l'IA. L'équipe de Shengyu chez Microsoft est parmi les premières à travailler sur la révision de code assistée par l'IA, où des agents de révision de code vérifient la cohérence à l'aide de spécifications, de résumés, de comportements attendus et de tests. L'objectif : que les humains se concentrent sur la logique métier tandis que l'IA gère la vérification structurelle.
Le panel a fait émerger plusieurs fils qui constituent des domaines de travail actifs mais loin d'être résolus :
Environnements d'apprentissage par renforcement évolutifs. C'était le point de consensus le plus fort. Chaque équipe qui a tenté l'apprentissage par renforcement pour la programmation agentive s'est heurtée au même mur d'infrastructure. Construire des environnements qui reflètent la diversité du monde réel — plusieurs dépôts, de vrais systèmes de build, une exécution réaliste — à l'échelle nécessaire pour l'entraînement par apprentissage par renforcement est la couche manquante.
Méta-évaluation : juger les juges. Si un juge IA note une modification de code, comment savoir si cette note est fiable? L'explication est proposée comme la prochaine couche de confiance, où un système devrait produire une note fiable et des commentaires de haute qualité, pour rendre plausible l'expédition automatique au-delà d'un seuil de confiance. Mais établir cette fiabilité est la partie difficile.
Extraction de spécifications à partir du code généré. L'ambition à long terme est de récupérer l'intention directement à partir du code généré afin que les humains n'aient pas à revisiter les implémentations. Cela relie le développement piloté par les Specs à l'analyse d'impact et à la compréhension de la façon dont les changements se propagent dans une base de code.
La régénération remplaçant la réparation. Si le code peut être régénéré à faible coût, pourquoi le maintenir? C'est une idée provocatrice avec des implications profondes sur la façon dont nous pensons la longévité des logiciels, la rétrocompatibilité et la dette technique.
Normes d'évaluation partagées. Les entreprises construisent des bancs d'essai internes sur du code propriétaire, mais la communauté manque de normes partagées pour évaluer les systèmes agentifs. Les bancs d'essai publics sont saturés; ce qui les remplacera devra saisir le respect des instructions, la généralisation, la lecture de code et les flux de travail multi-dépôts.
Juges personnalisables. Différentes organisations se préoccupent de choses différentes lors de la révision de code — gravité, style, ordonnancement, problèmes cosmétiques. Des juges uniformes ne fonctionneront pas à grande échelle. La voie à suivre exige des juges pouvant être ajustés au contexte organisationnel.