Étiquette : Microsoft Foundry

Vue de dessus d'une tablette affichant un diagramme d'orchestration complexe d'agents IA, posée sur un bureau en bois sombre, entourée d'outils de bureau sophistiqués.

Microsoft rend disponible son harnais Copilot pour les agents multi-modèles

Microsoft rend accessible via Microsoft Foundry le harnais qu’elle utilisait en interne chez GitHub pour piloter ses expériences Copilot. Ce composant est présenté comme la couche d’orchestration essentielle qui permet aux entreprises de construire des agents capables de raisonner, d’utiliser des outils et d’exécuter des tâches longues et complexes.

Ce « harnais » (harness) est ce qui entoure le modèle d’intelligence artificielle. Si le modèle fournit l’intelligence, le harnais donne à l’agent les bonnes instructions, le contexte, l’environnement d’exécution et les contrôles nécessaires pour faire un travail concret. Construire un tel système, qui fonctionne bien sur plusieurs modèles et interfaces, est notoirement difficile, car il faut gérer la performance, la qualité et le coût.

Les ingénieurs de GitHub ont développé ce harnais, qui est aujourd’hui la fondation de toutes les expériences Copilot chez Microsoft, incluant Copilot Code, Copilot Studio, l’application GitHub Copilot et l’interface CLI. Le fait de le rendre disponible via Foundry permet aux développeurs et aux clients d’entreprise d’utiliser cette infrastructure gérée sans avoir à maintenir le système eux-mêmes.

Illustration isométrique en pastels montrant un objet central 'harnais' connectant plusieurs nœuds d'IA distincts par des courbes douces, symbolisant l'orchestration de modèles.

L’un des grands avantages est la capacité de choisir le modèle adapté à la tâche sans changer d’infrastructure. Ce harnais est conçu pour fonctionner avec plus de vingt modèles de pointe, et il permet d’intégrer ses propres clés API. Au lieu de devoir suivre l’évolution de chaque nouveau modèle, l’utilisateur délègue cette tâche au harnais, qui route intelligemment la requête vers le modèle le plus pertinent.

La course au multi-modèle et les garde-fous de développement

Le besoin de passer au multi-modèle est devenu une nécessité compétitive, car un modèle de pointe peut rapidement devenir obsolète. Cette tendance est d’ailleurs observée chez d’autres acteurs. GitHub avait déjà déployé Copilot Fusion, un moteur de routage intelligent qui sélectionne les modèles en fonction de la difficulté de la tâche, tout en équilibrant le coût, la latence et la capacité de raisonnement.

Parallèlement, le cycle de développement s’oriente vers une collaboration plus structurée entre l’humain et l’agent. Entire, par exemple, a lancé son premier « forge Git » axé sur cette collaboration. Plutôt que de se contenter du modèle classique de la pull request (PR), Entire introduit le concept de « Trail ». Ce mécanisme affiche des évaluations automatiques calculées à chaque push de code, offrant une vue d’ensemble, comme un tableau de bord de pilote.

Ces évaluations sont menées par des agents qui attribuent un score et une justification. Si un score de qualité ou de sécurité n’est pas satisfaisant (par exemple, un score « orange »), l’itération doit continuer jusqu’à ce que la confiance soit élevée et que tous les problèmes soient résolus avant de pouvoir fusionner le code. Pour sécuriser ce processus, des systèmes d’intégration continue (CI) comme Buildkite sont intégrés pour s’assurer que l’agent ne modifie pas ce qui était prévu.

Face à la complexité croissante des agents, des outils d’observabilité voient le jour. Monte Carlo a lancé un outil pour surveiller le comportement des agents, car ils peuvent prendre des chemins inattendus au service de leurs objectifs, ce qui exige une vérification constante.

Sources