L’ère du harness d’agents : pourquoi l’orchestration multimodèle devient la véritable plateforme d’IA

Pendant l’essentiel de l’essor de l’IA générative, le récit public a porté sur les modèles : quel laboratoire affichait les meilleurs résultats aux tests de référence, quel nombre de paramètres impressionnait le plus, quel chatbot semblait le plus affûté ce mois-ci. Ce récit n’est pas faux, mais il est incomplet. Fin octobre 2026, Microsoft et GitHub ont rendu explicite une couche plus discrète : ce qui transforme réellement un modèle en travail agentique utile, c’est le harness, l’environnement d’exécution qui enveloppe les modèles d’instructions, de contexte, d’outils, de bacs à sable, de routage et de gouvernance.

Le 28 octobre, Microsoft a annoncé que le Microsoft Copilot harness, né au sein de GitHub et qui fait déjà fonctionner les expériences Copilot dans l’ensemble du groupe, serait proposé via Microsoft Foundry. Le même jour, la conférence GitHub Universe a mis en scène l’orchestration multimodèle sous le nom de Copilot Fusion et a rattaché à ce harness la continuité des sessions, les agents dans le cloud et la fenêtre Agents de VS Code. Le message était sans détour : qui veut jouer la carte du multimodèle a besoin d’un excellent harness pour mener à bien un travail réel.

Cet article s’en tient à cette couche de plateforme (la boucle de l’agent, le routage multimodèle, les bacs à sable, MCP et les compétences, et la question de savoir qui contrôle l’environnement d’exécution) et à la manière dont elle s’articule avec le basculement vers le work OS et les trois champs de bataille que sont le navigateur, l’IDE et l’OS, que nous avons cartographiés précédemment.

Ce qu’est réellement un harness

La définition de Microsoft a le mérite de la simplicité. Si le modèle fournit l’intelligence, le harness est tout ce qui l’entoure : la couche d’orchestration qui donne à un agent les bonnes instructions, le bon contexte, le bon environnement d’exécution et les bons contrôles pour accomplir un travail significatif. Un harness digne d’être commercialisé, ajoute l’entreprise, prend en charge des standards ouverts tels que MCP et les compétences d’agents (agent skills), ainsi que des plug-ins d’agents.

Ce cadrage compte, car il déplace le produit. Un modèle de pointe est un ingrédient. Une fenêtre de discussion est une surface. Le harness est l’atelier : il décide de la façon dont une tâche est découpée, du modèle qui traite chaque fragment, des outils qui peuvent être appelés, de l’endroit où le code s’exécute, de la manière dont les échecs sont relancés, de la durée de vie d’une session et de ce qu’une entreprise peut auditer a posteriori.

Il explique aussi pourquoi en construire un est difficile. Les modèles se renouvellent. Les écosystèmes d’outils se renouvellent. Latence, coût en jetons et qualité s’arbitrent différemment selon les charges de travail. Maintenir un routeur et une chaîne d’évaluation couvrant plusieurs fournisseurs est éprouvant si chaque équipe produit invente les siens. Le pari de Microsoft est que le harness conçu par GitHub pour des développeurs exigeants peut être transformé en produit pour tous via Foundry, sous forme de SDK à télécharger ou de service géré dans le cloud : les clients apportent leurs instructions, leurs compétences, leurs outils et leur choix de modèles, tandis que Microsoft exécute la boucle de l’agent et le bac à sable, gouvernance et optimisation comprises.

Le déclic du 28 octobre : Foundry et Universe

Microsoft Foundry et un environnement d’exécution Copilot commun à tout le groupe

Dans le billet de l’Official Microsoft Blog présentant le harness, Tina Schuchman, vice-présidente chargée de Foundry, et Vladimir Fedorov, directeur technique de GitHub, décrivent un environnement d’exécution déjà adopté dans tout le groupe. Il fait fonctionner Copilot Code, Copilot Studio, l’application GitHub Copilot, l’interface en ligne de commande, VS Code et d’autres produits. Sa mise à disposition dans Foundry est présentée comme un moyen, pour les développeurs et les entreprises, de construire en mode entièrement géré des agents qui raisonnent, utilisent des outils et accomplissent des tâches complexes et de longue durée, sans changer de harness chaque fois qu’ils changent de modèle.

Plusieurs affirmations techniques méritent d’être relevées, car elles définissent le récit de plateforme :

• Le multimodèle par conception. Le harness est conçu pour fonctionner avec plusieurs familles de modèles, plus de 20 modèles de pointe ainsi que l’utilisation de ses propres clés (BYOK), de sorte que le travail peut être aiguillé vers le modèle adapté à chaque tâche plutôt que d’imposer partout un modèle par défaut.
• Un environnement d’exécution en Rust. Microsoft indique avoir récemment porté l’environnement d’exécution du harness en Rust, avec une réduction de la charge liée aux sessions et du délai d’obtention du premier jeton, et revendique à ce titre des « performances de premier plan dans le secteur ».
• Une posture ouverte et interopérable. Les plateformes restent suffisamment ouvertes pour que les clients puissent recourir à d’autres harness et frameworks ; l’argument est celui de la commodité et de l’amélioration partagée, non d’un verrouillage strict qui interdirait les solutions concurrentes.
• Des améliorations cumulatives. Améliorer le harness une fois profite à toutes les surfaces qui s’appuient sur lui : un argument classique d’effet d’entraînement propre aux plateformes.

GitHub Universe : Fusion, sessions et système de livraison logicielle

Dans le discours d’ouverture d’Universe, Jay Parikh, vice-président exécutif de CoreAI chez Microsoft, présente GitHub comme un système complet de livraison logicielle pour les développeurs et pour leurs agents. Les développeurs fixent le cap et en restent responsables ; les agents mettent en œuvre et vérifient ; ce qui compte, c’est le travail achevé, et non davantage de code pour lui-même.

Dans cette vision, Copilot Fusion constitue l’annonce phare en matière d’orchestration multimodèle. Des tâches différentes appellent des modèles différents, et les développeurs ne devraient pas avoir à gérer chaque choix de modèle pour obtenir le bon résultat au bon prix. Fusion évalue ce dont une tâche a besoin en matière de raisonnement, de génération de code, de débogage et d’utilisation d’outils, puis choisit comment l’exécuter sur un ou plusieurs modèles. GitHub cite l’Artificial Analysis Coding Agent Index : Fusion Max y obtient un score à moins de deux points de celui d’Opus 5.5 Max, pour un coût deux fois moindre et un temps par tâche réduit de 40 %.

Autour de Fusion gravitent des produits qui n’ont de sens que si un harness commun existe en dessous :

• Les Copilot projects exécutent le travail des agents sur plusieurs dépôts, dans des sessions parallèles entièrement gérées, avec un point unique pour suivre l’avancement et décider des étapes suivantes.
• La continuité des sessions permet à une même session d’agent dans le cloud de passer de l’application GitHub Copilot à VS Code, à l’interface en ligne de commande et au Web : on la lance depuis son téléphone lors de la réunion du matin, on la pilote depuis son poste, on la consulte sur github.com, pendant que l’agent poursuit son travail dans le cloud.
• Les Copilot automations créent dans un dépôt des flux de travail fondés sur l’IA, déclenchés manuellement, par un événement ou selon un calendrier, et capables de tirer les leçons de leurs résultats pour proposer des améliorations soumises à validation humaine.
• Copilot code review Max vise une revue plus approfondie lorsqu’une modification l’exige ; GitHub affirme avoir obtenu le meilleur score F1 sur ReviewBench pour les problèmes de gravité élevée, les versions Lite et Balanced étant conservées pour la rapidité au quotidien.
• La formule commerciale. Depuis ce jour, les clients de GitHub Enterprise peuvent utiliser les fonctions Copilot sans abonnement Copilot distinct et payer les crédits d’IA qu’ils consomment, une offre en libre-service étant annoncée prochainement.

Le journal des modifications de VS Code publié le même jour rend le harness concret pour les développeurs : le Copilot harness, bâti sur le Microsoft Copilot SDK, devient le choix par défaut pour les nouvelles sessions, aussi bien dans l’éditeur que dans la fenêtre Agents. Les sessions dans le cloud peuvent démarrer dans VS Code et se poursuivre dans l’application Copilot, sur mobile, sur github.com ou dans Copilot CLI ; des messages privés Slack ou Teams peuvent basculer vers ces mêmes clients. Un Agent Host isole les sessions des fenêtres individuelles, de sorte que le travail se poursuit après la fermeture d’un dossier. Une fonction expérimentale d’utilisation de l’ordinateur peut interagir avec des applications de bureau, après approbation application par application. Un protocole ouvert, l’Agent Host Protocol (AHP), permet à des clients tiers de rester synchronisés avec les sessions en cours. Un Customization Marketplace (en préversion) rassemble compétences, serveurs MCP et plug-ins. Les Copilot connectors (en préversion) apportent du contexte issu de services comme Slack, Notion et Microsoft Learn sans installer de serveur MCP local.

Pris dans leur ensemble, les annonces du 28 octobre relevaient moins de l’avalanche de fonctionnalités que d’une déclaration : l’environnement d’exécution est le produit.

Anatomie de la couche de plateforme

La boucle de l’agent

Tout système d’agents sérieux converge vers une boucle : rassembler le contexte, planifier ou choisir l’étape suivante, appeler des outils ou produire des artefacts, observer les résultats, puis poursuivre ou s’arrêter pour solliciter un humain. Le harness est propriétaire de cette boucle. Lorsque Microsoft affirme qu’il « exécute la boucle de l’agent et le bac à sable », l’entreprise revendique la maîtrise de la machine à états qui assure la cohérence d’une tâche de longue durée à travers les appels de modèles, les échecs d’outils et les changements de surface.

C’est pourquoi la continuité des sessions est une fonction du harness et non un simple agrément d’interface. Si la boucle vit dans le cloud, sous un environnement d’exécution géré, refermer son ordinateur portable ne doit pas interrompre le travail. Si elle ne vit que dans le processus d’un éditeur local, elle s’interrompra.

Le routage multimodèle

Le routage est le cœur économique et qualitatif de l’ère du harness. Un modèle excellent en raisonnement approfondi peut se révéler trop lent ou trop coûteux pour des modifications courantes ; un modèle de code rapide peut être faible en planification. L’affirmation publique de Fusion (une qualité proche de celle des meilleurs modèles, pour un coût deux fois moindre et un temps nettement réduit, sur un indice public d’agents de programmation) correspond exactement à ce que les acheteurs veulent entendre : l’orchestration comme levier d’optimisation des coûts et de la latence, et pas seulement comme artifice de qualité.

Le discours de Microsoft sur Foundry va plus loin : s’en remettre à l’éditeur pour évaluer les nouveaux modèles et router intelligemment, plutôt que de reconstituer cette équipe scientifique dans chaque entreprise. La confiance que les clients accorderont à cette boîte noire sera l’une des questions déterminantes des achats en 2027.

Bacs à sable et autorisation d’agir

Les agents prennent de la valeur lorsqu’ils peuvent agir : modifier des fichiers, lancer des tests, manipuler des commandes sur le bureau, mettre à jour des tickets. Ils deviennent dangereux pour la même raison. Les bacs à sable, les étapes de validation et les contrôles de politique d’usage ne sont donc pas des fonctions accessoires : ils font la différence entre une démonstration et une plateforme déployable. L’expérimentation d’utilisation de l’ordinateur dans VS Code est révélatrice : chaque application requiert une approbation, les organisations peuvent désactiver la fonction par politique, et la capacité est présentée comme expérimentale. C’est le harness qui fait ici œuvre de produit : il expose la puissance tout en laissant configurable le périmètre des dégâts possibles.

MCP, compétences et frontière ouverte d’un environnement d’exécution fermé

Le Model Context Protocol se présente comme un port USB-C pour les applications d’IA : une manière standard de relier les assistants aux données, aux outils et aux flux de travail. Les Agent Skills, spécifiées sur agentskills.io, conditionnent des flux de travail réutilisables sous forme de répertoires comportant un fichier SKILL.md obligatoire (nom et description dans un en-tête YAML, suivis d’instructions en Markdown) et, en option, des scripts, des références et des ressources, chargés par divulgation progressive. L’extension officielle MCP Skills (io.modelcontextprotocol/skills, SEP-2640 au statut Final) rattache ce format aux ressources MCP via skills/list, skills/get et resources/read, avec des contrôles d’intégrité sur les manifestes et les empreintes.

Le billet de Microsoft consacré au harness cite explicitement MCP et les compétences d’agents comme des standards que tout harness sérieux doit prendre en charge. La place de marché et les connecteurs de GitHub en offrent la traduction commerciale : découverte et contexte en un clic, toujours encadrés par la politique de l’entreprise. La tension stratégique est nette. Les protocoles ouverts rendent les outils et les compétences portables ; un harness géré rend la boucle captive. La portabilité en périphérie et la force d’attraction au niveau de l’environnement d’exécution : c’est le schéma classique des plateformes.

Qui contrôle l’environnement d’exécution ?

Le contrôle du harness détermine bien plus que des chiffres de latence. Il détermine :

1. Quels modèles sont de premier rang. Une liste déroulante de plus de 20 modèles paraît ouverte ; ce sont les choix par défaut du routeur et sa batterie d’évaluations qui déterminent les modèles réellement utilisés pour la plupart des tâches.
2. Où résident la mémoire et l’état des sessions. La continuité entre téléphone, IDE, interface en ligne de commande et Web est un levier de fidélisation autant qu’une commodité.
3. Quels outils sont faciles d’accès. Places de marché, connecteurs et serveurs MCP adoubés déterminent ce que les agents peuvent faire dès le premier jour.
4. À quoi ressemble la sécurité. Les réglages par défaut des bacs à sable, la politique d’utilisation de l’ordinateur, les listes de plug-ins autorisés et les journaux d’audit relèvent du harness, et non des poids du modèle.
5. Qui capte la marge. La facturation au crédit des fonctions Copilot pour GitHub Enterprise déplace le centre de gravité commercial vers un travail d’agent mesuré à l’usage, exécuté sur la boucle d’un autre.

C’est pourquoi l’ère du harness se rattache directement à nos analyses précédentes. Dans Des chatbots au work OS, l’assistant devient le lieu où le travail commence et s’achève ; les connecteurs et un MCP capable d’écrire transforment la conversation en poste de commande. Dans Navigateur, IDE et OS : les trois champs de bataille des interfaces IA, l’IDE montrait déjà que la valeur se concentre sur la revue, la gouvernance et le système de référence. Le harness est le chaînon manquant : l’environnement d’exécution qui permet à n’importe quelle surface (work OS, IDE ou hôte d’agents du système d’exploitation) de faire fonctionner des agents multimodèles sans réinventer l’orchestration.

Ce qu’il faudra surveiller

Quelques tests concrets montreront si le harness devient réellement la plateforme :

• La transparence des évaluations. La référence de Fusion à Artificial Analysis est un début ; les entreprises demanderont que le routage soit explicable tâche par tâche et revendiqueront le droit de passer outre le routeur.
• Les portes de sortie. L’affirmation de Microsoft selon laquelle on peut recourir à un autre harness n’a de valeur que si l’exportation des compétences, des configurations d’outils et de la sémantique des sessions est effective.
• Les compétences multifournisseurs. Si les Agent Skills sur MCP deviennent aussi banales que les conteneurs, la concurrence se déplacera vers la fiabilité et le prix.
• Les charges hors programmation. La programmation s’y prête en premier parce que les modifications de code sont vérifiables ; l’ambition agentique plus large de Foundry doit encore faire ses preuves sur des processus d’entreprise ordinaires, menés à bien en toute sécurité et à grande échelle.
• La force d’attraction des infrastructures. Les ajouts d’infrastructure revendiqués par GitHub pour 2026 (4 millions de cœurs de processeur, 160 Po de stockage à haut débit, 50 Tbit/s de capacité réseau, ainsi qu’une migration vers Azure sur plusieurs régions) rappellent aux acheteurs que les plateformes d’agents sont aussi des plateformes capitalistiques.

Le modèle n’est pas le produit

Les modèles de pointe continueront de progresser par bonds. C’est précisément pourquoi lier son entreprise à un modèle unique érigé en plateforme est une stratégie fragile. La couche durable est celle qui peut changer de modèle, maintenir la boucle en fonctionnement, isoler les effets de bord, parler MCP et compétences, et améliorer toutes les surfaces qui y sont rattachées lorsque l’environnement d’exécution progresse.

Les annonces du 28 octobre n’ont pas inventé cette idée. Elles l’ont industrialisée : le harness multimodèle de GitHub, éprouvé sur le terrain, standardisé dans l’ensemble de Copilot, ouvert via Foundry et intégré à des produits qui considèrent les agents comme des travailleurs à part entière. À l’ère du harness d’agents, la véritable plateforme d’IA n’est ni la fenêtre de discussion ni les poids du modèle. C’est l’environnement d’exécution qui décide de la manière dont l’intelligence est planifiée, encadrée et facturée.

À lire aussi

• Des chatbots au work OS : comment les assistants IA avalent le SaaS d’entreprise
• Navigateur, IDE et OS : les trois champs de bataille des interfaces IA
• L’ère des agents permanents : Claude Duet, Muse Wonder et Perplexity Teammates

Images : illustrations originales créées pour AndBeyond.Tech ; aucun logo ni aucune personne réelle n’y figurent.