Microsoft a annoncé le 28 octobre 2026 la disponibilité en aperçu public de son Copilot harness dans Foundry Agent Service. Le mot « harness » peut sembler technique, mais l’idée est simple : un modèle fournit une capacité de raisonnement ; la couche d’orchestration transforme cette capacité en travail suivi. Elle prépare le contexte, appelle les bons outils, applique les règles d’autorisation, conserve l’état de la tâche et coordonne les étapes jusqu’au résultat. Pour les créateurs, Community Managers, entrepreneurs, étudiants et professionnels francophones, cette annonce apporte surtout une grille de lecture. Comparer uniquement les modèles ne suffit plus. La valeur d’un agent dépend de tout le système qui l’entoure et des preuves qu’il produit.

Ce que Microsoft a lancé

Le Copilot harness est proposé en aperçu public dans Microsoft Foundry Agent Service. Microsoft le présente comme une exécution gérée pour des agents capables de raisonner, d’utiliser des outils et de mener des tâches complexes ou longues. L’entreprise indique que cette base est issue de la technologie développée par GitHub et qu’elle alimente plusieurs expériences Copilot.

Le service réunit quatre blocs : des compétences réutilisables, des outils connectés, une exécution permettant de travailler avec des fichiers ou du code et de déléguer des tâches bornées, puis des définitions d’agents conservées avec le code source. Le développeur choisit un modèle compatible et apporte ses instructions, ses connaissances et ses outils ; Microsoft gère la boucle d’agent et l’environnement isolé.

Le modèle n’est qu’une pièce du système

Un modèle peut proposer une étape, mais il ne décide pas seul comment une organisation l’autorise à lire un fichier, modifier une fiche ou reprendre après une interruption. Le harness organise ces opérations. Il prépare les informations utiles, transmet les demandes d’outil, récupère les résultats et maintient l’état de la mission.

Cette distinction explique pourquoi deux produits utilisant un modèle proche peuvent donner des résultats très différents. L’un fournit le bon document, limite les permissions et vérifie la sortie ; l’autre envoie trop de contexte, appelle un outil inadéquat ou recommence une action déjà effectuée. La qualité visible dépend autant de l’orchestration que du modèle.

Trois conséquences concrètes pour les petites équipes

Premièrement, choisissez une procédure avant de choisir un modèle. Pour préparer une veille, décrivez les sources autorisées, la période, les critères de sélection, le format et les points qui exigent une validation. Une compétence réutilisable peut ensuite porter cette méthode d’un agent à l’autre.

Deuxièmement, séparez la recherche de l’action. Un Community Manager peut autoriser l’agent à repérer des commentaires sans réponse et à préparer des brouillons, tout en gardant la publication manuelle. Un entrepreneur peut lui faire vérifier des factures et signaler les écarts sans lui permettre d’effectuer un paiement.

Troisièmement, mesurez le travail terminé. Notez le temps total, les erreurs, les reprises et les validations humaines. Un agent rapide qui nécessite vingt minutes de correction ou déclenche deux fois la même action n’est pas un progrès opérationnel.

Les tâches longues exigent des points de reprise

Microsoft annonce aussi la disponibilité générale de la résilience pour les agents hébergés. Lorsqu’une tâche de plusieurs heures ou jours est interrompue, Foundry peut la redémarrer avec son entrée d’origine. L’application doit toutefois enregistrer les étapes terminées et les résultats intermédiaires pour reprendre au bon endroit.

Cette nuance est importante : l’historique de conversation ne suffit pas à restaurer un travail. Si l’agent crée un rapport, envoie une notification ou modifie un autre système, il doit vérifier si l’action existe déjà avant de la répéter. Pour une automatisation éditoriale, cela signifie conserver un identifiant unique, un statut et la preuve du lien publié avant tout nouvel envoi.

Multi-modèle ne veut pas dire résultat automatiquement meilleur

Microsoft affirme que le harness peut fonctionner avec plus de vingt modèles de pointe et permettre l’usage de sa propre clé. Cette souplesse évite de reconstruire toute l’orchestration lorsqu’un modèle change. Elle ne dispense pas d’évaluer chaque combinaison. Un modèle moins coûteux peut suffire pour classer des demandes, tandis qu’un travail de recherche complexe peut nécessiter davantage de raisonnement.

La bonne méthode consiste à définir un jeu de cas réels, puis à comparer exactitude, coût, délai et temps de correction. Le routeur doit aussi être contrôlé : l’organisation doit savoir quel modèle traite quelle donnée et selon quelles règles.

Un premier test accessible

Choisissez une mission réversible qui utilise deux outils au maximum. Exemple : chaque matin, lire une liste de contenus, vérifier la présence d’une source et préparer un tableau des éléments incomplets. Définissez une sortie simple : VALIDÉ ou BLOQUÉ, le critère concerné et l’action attendue. Interdisez toute publication automatique pendant le test.

Faites tourner le processus sur dix anciens dossiers, dont plusieurs contiennent une erreur connue. Vérifiez que l’agent retrouve le bon contexte, respecte les permissions, ne transforme pas une absence de preuve en certitude et ne répète pas une action. Ce test évalue le système réel, pas une démonstration idéale.

Conclusion : évaluer l’agent autour du modèle

Le Copilot harness confirme une évolution de fond : la compétition se déplace du modèle isolé vers le système capable de l’encadrer. Pour adopter un agent, examinez cinq éléments : procédure, contexte, outils, permissions et reprise après incident. Commencez par une tâche réversible, conservez des identifiants uniques et exigez une preuve avant chaque action externe. Le meilleur modèle n’est pas toujours le meilleur agent ; le meilleur agent est celui dont le travail peut être compris, vérifié et arrêté.