Deux assistants peuvent utiliser un modèle comparable et produire des expériences très différentes. Microsoft met désormais à disposition dans Foundry le système qui orchestre le travail de ses agents Copilot, annonce l’entreprise le 28 octobre. Ce « harness », développé à partir du travail des équipes GitHub, gère le déroulement d’une tâche au-delà de la seule réponse du modèle.
Dans sa présentation officielle, Microsoft insiste sur une architecture capable de fonctionner avec plusieurs familles de modèles. L’objectif annoncé est de permettre aux développeurs et aux entreprises de construire des agents qui utilisent des outils et exécutent des tâches longues, sans reconstruire toute l’orchestration à chaque changement de modèle.
Le modèle propose, l’environnement organise
Un modèle produit des réponses et peut aider à choisir une action. Autour de lui, un système doit encore donner accès aux bons outils, transmettre les informations utiles et suivre ce qui a été réalisé. C’est ce travail d’organisation qui devient central lorsqu’une demande nécessite plusieurs étapes.
Répondre et terminer une tâche ne sont pas la même chose. Un assistant peut expliquer comment préparer un rapport sans créer le document. Il peut aussi créer un fichier, mais oublier de vérifier ses données ou son format. Pour l’utilisateur, la différence se voit dans le résultat livré, pas dans le nom du modèle affiché.
Le multi-modèle change la comparaison des solutions
Une plateforme qui peut faire appel à plusieurs modèles offre davantage de possibilités d’adaptation. Cela ne garantit pas qu’elle choisira toujours le meilleur compromis pour votre usage. Il faut encore comprendre les règles de sélection, les coûts et les limites de chaque parcours.
Pour comparer deux propositions, partez donc de la même tâche réelle. Donnez les mêmes documents et définissez ce qui doit être livré. Notre dossier sur l’évaluation des réponses d’un assistant IA aide à distinguer une démonstration convaincante d’un résultat vérifiable.
Une tâche longue doit avoir une fin reconnaissable
« Occupe-toi de mes documents » laisse trop de place à l’interprétation. « Prépare un tableau des contrats arrivant à échéance, avec une référence pour chaque date » donne un résultat contrôlable. Le périmètre permet de savoir ce qui a été accompli et ce qui manque encore.
Ajoutez les critères de vérification : documents à utiliser, période couverte et format attendu. Si une information est absente, demandez qu’elle soit signalée plutôt que complétée au hasard. Cette préparation reste utile quelle que soit la sophistication du système d’orchestration.
Le temps gagné commence souvent dans la définition du travail.
Les outils accessibles déterminent aussi les risques
Un agent limité à la lecture ne dispose pas du même pouvoir qu’un agent autorisé à modifier un logiciel métier ou à envoyer un message. Le choix des connexions doit donc suivre la tâche, et non l’envie de rendre le système le plus autonome possible.
Notre article pour choisir une première tâche à confier à un agent en entreprise propose cette démarche progressive. Commencez par un résultat que vous savez relire et par des actions dont vous comprenez les conséquences. L’architecture gérée ne retire pas le besoin de définir les droits.
Un test utile peut porter sur une tâche courte et répétitive : préparer une première synthèse à partir de documents autorisés, par exemple. Définissez ce qui sera évalué avant l’essai : sources reprises, erreurs repérées, temps de correction et actions nécessitant un accord. Changer de modèle devient alors une comparaison observable plutôt qu’un choix fondé uniquement sur une démonstration.
Prévoyez également un responsable lorsque l’agent rencontre une situation ambiguë. Qui valide une action externe ? Qui examine une réponse incohérente ? Une architecture capable d’orchestrer plusieurs modèles doit rester compréhensible pour les personnes qui utilisent le résultat au quotidien. C’est cette organisation qui rend un déploiement réellement exploitable.
Ce que l’annonce apporte aux utilisateurs professionnels
Pour les équipes qui développent des agents, Microsoft propose de mutualiser une partie du travail technique. Pour les personnes qui les utiliseront, la question reste concrète : le service indique-t-il son avancement, expose-t-il ses limites et fournit-il un résultat dont on peut vérifier la provenance ?
Demandez une démonstration avec un cas incomplet ou une exception, pas seulement un exemple idéal. Observez si l’agent s’arrête, explique le problème et conserve les étapes déjà réalisées. L’annonce du 28 octobre rappelle que la qualité d’un agent dépend du système entier. Le modèle compte, mais l’organisation du travail, les accès et la vérification du résultat comptent aussi dans l’expérience finale.
