Pendant trois ans, nous avons appris à mieux parler aux modèles d’intelligence artificielle.

Nous avons travaillé nos formulations. Nous avons structuré nos demandes. Nous avons ajouté des exemples, précisé le rôle attendu, défini le format de sortie et répété, parfois jusqu’à l’absurde, qu’il ne fallait surtout pas inventer de réponse.

Nous avons appelé cela le Prompt Engineering.

Puis nous avons compris que la qualité d’une réponse ne dépendait pas seulement de la question posée. Elle dépendait aussi de tout ce que le modèle pouvait voir au moment de répondre : l’historique de la conversation, les documents disponibles, les données de l’entreprise, les instructions permanentes, les outils accessibles et les résultats des actions précédentes.

Nous sommes alors entrés dans l’ère du Context Engineering.

Mais une nouvelle étape est désormais franchie.

Lorsqu’un agent doit travailler pendant plusieurs minutes, explorer plusieurs sources, utiliser différents outils, corriger ses propres erreurs, produire plusieurs livrables et poursuivre un objectif au-delà d’un simple échange conversationnel, ni le prompt ni le contexte ne suffisent plus.

Il faut organiser le travail de l’agent.

Il faut contrôler sa boucle d’exécution.

Il faut décider ce qu’il doit observer, planifier, exécuter, vérifier, mémoriser et reprendre.

C’est précisément le rôle du Harness Engineering.

Et depuis le 3 août 2026, cette notion n’est plus réservée aux agents de développement logiciel les plus avancés. Microsoft a annoncé la disponibilité générale du GitHub Copilot harness dans Microsoft Copilot Studio. Malgré son nom, il ne s’agit pas d’intégrer GitHub Copilot aux agents métier ni de transformer Copilot Studio en outil de développement logiciel. Il s’agit d’un nouveau harness d’orchestration proposé par Copilot Studio, issu des technologies agentiques développées autour de GitHub Copilot et désormais adapté à l’automatisation de processus métier complexes.

Trois niveaux d’ingénierie pour trois niveaux de complexité

Le Prompt Engineering, le Context Engineering et le Harness Engineering ne sont pas trois modes qui s’annulent ou se remplacent.

Ils constituent plutôt trois couches successives.

flowchart LR
    A[Prompt Engineering] --> B[Context Engineering]
    B --> C[Harness Engineering]

    A1[Formuler correctement<br/>une instruction] --> A
    B1[Fournir les bonnes<br/>informations au bon moment] --> B
    C1[Organiser et contrôler<br/>le travail de l'agent] --> C

Le Prompt Engineering travaille sur l’instruction.

Le Context Engineering travaille sur l’environnement informationnel de l’appel au modèle.

Le Harness Engineering travaille sur le système d’exécution qui encadre le modèle, ses outils, sa mémoire et sa progression dans le temps.

On pourrait résumer l’évolution ainsi :

Première étape : le Prompt Engineering

Le Prompt Engineering est la pratique consistant à rédiger des instructions suffisamment claires et structurées pour guider un modèle de langage vers le résultat attendu.

La documentation Microsoft le décrit comme un ensemble de techniques permettant d’orienter le modèle par la formulation de la tâche, les instructions, les exemples, les contraintes et la structure de sortie. Microsoft rappelle également que la construction d’un bon prompt reste difficile et qu’elle relève encore souvent davantage de l’expérience et de l’itération que d’une science parfaitement déterministe.

Un prompt élaboré peut contenir :

• un rôle;
• un objectif;
• un contexte explicatif;
• une tâche;
• des contraintes;
• des exemples;
• des critères de qualité;
• un format de réponse;
• des instructions en cas d’incertitude.

Par exemple :

Tu es un analyste financier spécialisé dans les petites entreprises canadiennes. Analyse les trois documents joints, relève les écarts entre le budget et les dépenses réelles, explique les trois causes principales et produis un tableau synthétique. N’invente aucune donnée manquante et indique clairement les limites de ton analyse.

Cette formulation est bien meilleure que :

Analyse mes finances.

Pour autant, même un excellent prompt présente une limite fondamentale : il ne peut utiliser que les informations accessibles au modèle au moment de son exécution.

Il ne garantit pas que les bons documents ont été sélectionnés.

Il ne garantit pas que les données les plus récentes ont été récupérées.

Il ne garantit pas que le modèle utilisera le bon outil.

Il ne garantit pas davantage que le résultat sera vérifié avant d’être livré.

Le Prompt Engineering améliore la demande. Il ne construit pas encore tout le système nécessaire pour accomplir la mission.

Deuxième étape : le Context Engineering

Le Context Engineering déplace le problème.

La question n’est plus seulement :

Comment devons-nous parler au modèle?

Elle devient :

Que doit savoir le modèle, que doit-il voir et à quoi doit-il avoir accès au moment précis où il doit prendre une décision?

Le contexte peut inclure :

• les instructions système;
• la demande de l’utilisateur;
• l’historique de la conversation;
• des documents récupérés par un système RAG;
• des données structurées;
• les préférences mémorisées de l’utilisateur;
• les permissions de l’utilisateur;
• la description des outils accessibles;
• les résultats des appels précédents;
• l’état courant d’un workflow;
• le plan de travail de l’agent;
• les erreurs déjà rencontrées;
• les éléments encore à traiter.

Microsoft Research présente le Context Engineering comme un champ consacré à la construction de contextes efficaces et économes, notamment par la sélection, la compression et l’organisation des informations données aux modèles. Les travaux de Microsoft étendent cette logique aux agents capables de choisir leurs outils, leur mémoire, leur calcul et leurs chemins d’exécution sur des tâches longues.

Autrement dit, un contexte utile n’est pas une accumulation anarchique de données.

Ce n’est pas :

Prenons tous les fichiers de l’entreprise et plaçons-les dans le prompt.

C’est une opération de sélection et de préparation.

flowchart TD
    U[Demande de l'utilisateur] --> R[Compréhension de l'intention]

    R --> S1[Recherche documentaire]
    R --> S2[Lecture de l'état du processus]
    R --> S3[Identification de l'utilisateur]
    R --> S4[Sélection des outils disponibles]

    S1 --> C[Construction du contexte utile]
    S2 --> C
    S3 --> C
    S4 --> C

    C --> M[Appel au modèle]
    M --> O[Réponse ou décision]

Le Context Engineering vise donc à placer les bonnes informations, dans le bon format, devant le bon modèle, au bon moment.

Cette discipline est devenue essentielle avec les systèmes RAG, les mémoires persistantes, Microsoft Graph, Microsoft IQ, les connecteurs, les outils MCP et les agents spécialisés.

Microsoft IQ, par exemple, est présenté comme une couche d’intelligence unifiée qui transforme des données brutes, des signaux et des connaissances organisationnelles en contexte métier sécurisé et réutilisable par Copilot et les agents. Cette couche respecte notamment les identités, les permissions, les étiquettes de sensibilité et les politiques existantes.

Mais là encore, une limite demeure.

Même correctement alimenté, le modèle continue généralement de travailler à l’intérieur d’un appel ou d’une séquence d’appels orchestrée par une application.

Quel composant décide de la prochaine action?

Qui conserve l’état du travail?

Qui vérifie qu’une étape est réellement terminée?

Qui réinjecte uniquement les informations nécessaires dans l’étape suivante?

Qui empêche l’agent de répéter indéfiniment la même action?

C’est ici que commence le Harness Engineering.

Qu’est-ce qu’un « harness »?

Le mot anglais harness signifie littéralement « harnais ».

L’image est utile : un harnais permet d’attacher une force à une structure, de la guider et de la rendre exploitable sans la laisser agir de manière incontrôlée.

Appliqué à l’intelligence artificielle, le harness est l’ensemble des mécanismes qui entourent un ou plusieurs modèles afin de transformer leur capacité de raisonnement en un système capable d’effectuer un travail.

GitHub formule cette distinction très clairement : le modèle fournit l’intelligence brute, tandis que le harness détermine la manière dont cette intelligence est appliquée. Il orchestre notamment les outils, le contexte et le workflow.

Le modèle est donc le moteur cognitif.

Le harness est le dispositif qui lui permet de travailler.

flowchart TB
    subgraph Harness["Harness agentique"]
        P[Planification]
        CTX[Gestion du contexte]
        MEM[Mémoire et état]
        TOOL[Sélection des outils]
        EXEC[Exécution]
        CHECK[Vérification]
        REC[Gestion des erreurs]
        GOV[Politiques et garde-fous]
    end

    LLM[Modèle de langage] <--> Harness

    Harness <--> DATA[Données et connaissances]
    Harness <--> API[API et connecteurs]
    Harness <--> AGENTS[Autres agents]
    Harness <--> FILES[Fichiers et artefacts]
    Harness <--> HUMAN[Intervention humaine]

Le harness peut notamment :

1. analyser l’objectif;
2. construire un plan;
3. décomposer le travail;
4. choisir les outils;
5. appeler le modèle;
6. exécuter une action;
7. lire le résultat;
8. mettre à jour l’état du travail;
9. vérifier si l’objectif est atteint;
10. corriger ou replannifier;
11. produire les artefacts;
12. arrêter la boucle.

C’est ce dispositif qu’il faut désormais concevoir, configurer, mesurer et gouverner.

Cette activité constitue le Harness Engineering.

Comment traduire Harness Engineering en français?

La traduction littérale serait :

ingénierie du harnais

Elle est fidèle au mot anglais, mais elle reste peu naturelle et assez opaque pour un public francophone.

Plusieurs traductions sont possibles :

• ingénierie du harnais agentique;
• ingénierie de l’environnement d’exécution;
• ingénierie du dispositif agentique;
• ingénierie de l’orchestration agentique;
• ingénierie du système d’exécution des agents.

Pour ma part, j’utiliserais :

Ingénierie du dispositif d’exécution agentique

Cette expression est moins courte, mais elle décrit plus précisément la réalité : nous concevons le dispositif qui permet à un agent de planifier, d’utiliser ses outils, de maintenir son état, de contrôler ses actions et de poursuivre un objectif.

Dans les échanges techniques, je conserverais cependant le terme Harness Engineering, accompagné de sa traduction lors de la première utilisation. Le vocabulaire anglophone est déjà installé dans GitHub et apparaît maintenant explicitement dans Copilot Studio.

Du modèle conversationnel à la boucle agentique

Un assistant conversationnel classique suit une mécanique relativement simple :

sequenceDiagram
    participant U as Utilisateur
    participant A as Assistant
    participant M as Modèle

    U->>A: Pose une question
    A->>M: Envoie le prompt et le contexte
    M-->>A: Produit une réponse
    A-->>U: Affiche la réponse

Un agent équipé d’un harness travaille différemment.

sequenceDiagram
    participant U as Utilisateur
    participant H as Harness
    participant M as Modèle
    participant T as Outils
    participant S as État et mémoire

    U->>H: Confie un objectif complexe
    H->>S: Initialise l'état du travail
    H->>M: Demande une analyse et un plan
    M-->>H: Propose un plan

    loop Jusqu'à résolution ou arrêt
        H->>S: Relit l'état courant
        H->>M: Demande la prochaine action
        M-->>H: Sélectionne une action
        H->>T: Exécute l'outil
        T-->>H: Retourne le résultat
        H->>S: Enregistre résultat et progression
        H->>M: Évalue le résultat
        M-->>H: Valide, corrige ou replannifie
    end

    H-->>U: Livre le résultat et les artefacts

La différence essentielle se trouve dans la boucle.

Le système ne demande pas simplement au modèle de générer une réponse. Il lui permet de progresser de manière contrôlée dans une succession d’étapes.

Cette boucle est souvent décrite sous des formes comme :

• observer;
• réfléchir;
• planifier;
• agir;
• vérifier;
• recommencer.

Ou encore :

stateDiagram-v2
    [*] --> Observer
    Observer --> Planifier
    Planifier --> Agir
    Agir --> Vérifier

    Vérifier --> Livrer: Objectif atteint
    Vérifier --> Planifier: Plan incomplet
    Vérifier --> Corriger: Erreur détectée
    Corriger --> Agir

    Livrer --> [*]

Le Harness Engineering consiste à déterminer comment cette boucle fonctionne réellement.

Ce que le Harness Engineering doit concevoir

1. La planification

L’agent doit pouvoir transformer un objectif général en un ensemble d’étapes suffisamment précises.

Par exemple :

Prépare un rapport sur les risques associés au renouvellement de notre fournisseur principal.

L’agent peut devoir :

1. identifier le fournisseur;
2. récupérer le contrat;
3. retrouver les incidents;
4. analyser les dépenses;
5. rechercher les dépendances opérationnelles;
6. comparer les solutions de remplacement;
7. produire une matrice de risques;
8. rédiger un rapport;
9. faire vérifier le rapport;
10. soumettre le résultat à un humain.

Le plan ne doit pas nécessairement être entièrement figé dès le début. Les informations découvertes peuvent conduire l’agent à le modifier.

2. La gestion de l’état

Une tâche longue ne peut pas dépendre uniquement de l’historique brut d’une conversation.

Le système doit conserver un état structuré :

objective: Évaluer le risque fournisseur
status: in_progress

completed_steps:
  - contrat récupéré
  - historique des incidents analysé

pending_steps:
  - analyser les dépenses
  - comparer trois fournisseurs alternatifs
  - produire la matrice de risques

artifacts:
  - contract-summary.md
  - incidents.csv

open_questions:
  - date exacte du prochain renouvellement
  - criticité du service pour les opérations

Cet état devient une représentation compacte et persistante du travail.

Il permet à l’agent de reprendre sa mission sans devoir conserver chaque phrase, chaque raisonnement et chaque résultat intermédiaire dans une seule fenêtre de contexte.

3. La construction dynamique du contexte

À chaque étape, le harness doit décider ce qu’il faut donner au modèle.

Lorsque l’agent analyse un contrat, il n’a pas nécessairement besoin de l’intégralité des journaux d’incidents.

Lorsqu’il compare les fournisseurs, il n’a pas besoin de recevoir toutes les versions intermédiaires du rapport.

Le harness peut donc construire une nouvelle fenêtre de travail à chaque étape :

flowchart LR
    STATE[État global du travail] --> SELECT[Sélection du contexte utile]
    DOCS[Documents disponibles] --> SELECT
    MEMORY[Mémoire] --> SELECT
    TOOLS[Outils accessibles] --> SELECT

    SELECT --> WINDOW[Fenêtre de contexte de l'étape]
    WINDOW --> MODEL[Modèle]
    MODEL --> RESULT[Résultat intermédiaire]
    RESULT --> UPDATE[Mise à jour de l'état]
    UPDATE --> STATE

Cette mécanique permet d’exécuter des tâches qui dépassent la capacité pratique d’une seule interaction.

Il faut toutefois être précis : Microsoft décrit officiellement le nouveau harness comme conçu pour le travail complexe de longue durée, les boucles agentiques, la planification, les problèmes dynamiques et les productions en plusieurs parties. L’annonce ne formule pas la capacité comme une garantie abstraite de « chaîner un nombre illimité de fenêtres de contexte ». La continuité dépend de la manière dont le harness gère l’état, la mémoire, les artefacts et la reconstruction du contexte.

4. L’utilisation des outils

Le modèle ne fait pas directement le travail.

Il décide généralement quelle action devrait être entreprise, puis le harness exécute l’outil autorisé.

Ces outils peuvent être :

• un connecteur Microsoft 365;
• une action Power Platform;
• un agent flow;
• une API;
• un serveur MCP;
• une fonction;
• un interpréteur de code;
• un navigateur;
• un environnement Windows;
• un autre agent;
• un système documentaire;
• un service de génération de fichiers.

Dans Copilot Studio, les agent flows peuvent être exposés comme outils. L’orchestrateur de l’agent peut alors les appeler pour récupérer des données ou effectuer des actions au nom de l’utilisateur.

Microsoft propose également des outils de type computer use, permettant à un agent d’interagir avec des applications web ou Windows à l’aide d’une souris et d’un clavier virtuels lorsque l’application ne fournit pas d’API exploitable.

Le rôle du Harness Engineering est alors de répondre à des questions très concrètes :

• Quel outil doit être disponible?
• Dans quelles conditions peut-il être utilisé?
• Quelles informations sont nécessaires pour l’appeler?
• Que faire s’il échoue?
• L’action est-elle réversible?
• Une validation humaine est-elle nécessaire?
• Le résultat doit-il être vérifié par un autre outil ou un autre agent?

5. La gestion des erreurs

Dans une simple conversation, une erreur produit souvent une mauvaise réponse.

Dans un processus agentique, une erreur peut modifier une donnée, envoyer un message, déplacer un fichier ou déclencher une opération métier.

Un bon harness doit donc reconnaître différentes catégories d’erreurs :

flowchart TD
    A[Action de l'agent] --> B{Résultat valide?}

    B -->|Oui| C[Mettre à jour la progression]
    B -->|Non| D{Type d'erreur}

    D --> E[Erreur temporaire]
    D --> F[Paramètre invalide]
    D --> G[Permission insuffisante]
    D --> H[Résultat ambigu]
    D --> I[Action sensible]

    E --> J[Réessayer avec temporisation]
    F --> K[Corriger les paramètres]
    G --> L[Demander une autorisation]
    H --> M[Rechercher des preuves supplémentaires]
    I --> N[Demander une validation humaine]

Le Harness Engineering introduit donc des notions classiques de l’ingénierie logicielle dans l’univers des agents :

• reprise sur erreur;
• limites de tentatives;
• temporisation;
• idempotence;
• transactions;
• compensation;
• journalisation;
• contrôle d’accès;
• validation;
• escalade humaine.

6. La vérification du travail

Un agent ne devrait pas être considéré comme fiable simplement parce qu’il a produit un résultat.

Il faut distinguer :

• la génération du résultat;
• la vérification du résultat.

Le harness peut prévoir différentes formes de contrôle :

• validation par schéma;
• test automatique;
• comparaison avec une source;
• relecture par un autre modèle;
• critique croisée entre modèles;
• vérification par un agent spécialisé;
• contrôle humain;
• évaluation par critères;
• calcul d’un score de confiance;
• blocage lorsque les preuves sont insuffisantes.

GitHub explique notamment que certaines capacités du harness peuvent utiliser plusieurs familles de modèles, par exemple en faisant critiquer le travail d’un modèle par un autre.

Ce principe est fondamental : le modèle qui produit le travail ne devrait pas toujours être le seul juge de sa qualité.

Pourquoi le Harness Engineering devient-il si important?

Les modèles deviennent interchangeables

Pendant longtemps, les discussions se sont concentrées sur le choix du meilleur modèle.

Mais deux produits utilisant le même modèle peuvent produire des résultats radicalement différents.

Pourquoi?

Parce que le modèle n’est qu’une partie du système.

Les performances dépendent aussi :

• des instructions;
• de la sélection du contexte;
• de la description des outils;
• de la boucle d’exécution;
• de la mémoire;
• des mécanismes de délégation;
• de la vérification;
• de la gestion des erreurs;
• de l’arrêt de la tâche.

GitHub a publié en juin 2026 une évaluation du GitHub Copilot agentic harness sur plusieurs modèles et benchmarks, principalement consacrés à des tâches d’ingénierie logicielle. Ces résultats documentent les caractéristiques du harness commun — orchestration des outils, gestion du contexte, choix des modèles et efficacité en jetons — mais ils ne doivent pas être interprétés comme une mesure directe des performances des agents métier créés dans Copilot Studio. Les performances d’un agent Copilot Studio doivent être évaluées dans son propre contexte, avec ses instructions, ses connaissances, ses outils, ses données et ses processus métier. GitHub souligne également que le même harness peut prendre en charge plus de vingt modèles issus de plusieurs familles.

La conséquence est importante :

L’avantage compétitif ne réside plus uniquement dans le modèle. Il réside aussi dans le système construit autour du modèle.

Les tâches agentiques dépassent la conversation

Une conversation répond.

Un agent travaille.

Lorsqu’un agent doit accomplir un processus métier complet, il doit maintenir une continuité opérationnelle.

Par exemple :

Analyse les dossiers reçus cette semaine, vérifie leur conformité, contacte les personnes dont le dossier est incomplet, mets à jour le système et prépare un rapport pour vendredi.

Cette mission ne peut pas être réduite à un unique prompt.

Elle nécessite :

• une liste de dossiers;
• une définition de la conformité;
• une boucle sur chaque dossier;
• plusieurs systèmes;
• une gestion des exceptions;
• des communications;
• un suivi d’état;
• un rapport consolidé.

Le Harness Engineering fournit l’architecture nécessaire pour transformer cette intention en processus contrôlé.

Les fenêtres de contexte restent une ressource limitée

Même lorsqu’un modèle accepte un contexte très important, il reste généralement inefficace de lui transmettre l’intégralité d’un projet à chaque étape.

Plus le contexte est volumineux :

• plus le coût peut augmenter;
• plus le traitement peut être lent;
• plus les informations importantes peuvent être noyées;
• plus la gestion des contradictions devient difficile;
• plus le système risque de répéter inutilement des données.

Le harness doit donc arbitrer entre mémoire, résumé, état structuré, documents externes et contexte immédiat.

Le problème n’est plus seulement la taille de la fenêtre de contexte.

Le problème est la qualité de ce que nous choisissons d’y placer.

Les actions exigent davantage de gouvernance que les réponses

Une réponse erronée est problématique.

Une action erronée peut être grave.

Un agent qui dispose d’outils doit être encadré par des politiques :

flowchart LR
    INTENT[Intention] --> POLICY{Action autorisée?}

    POLICY -->|Non| DENY[Refuser et expliquer]
    POLICY -->|Oui, faible risque| EXEC[Exécuter]
    POLICY -->|Oui, risque élevé| APPROVAL[Demander une approbation]

    APPROVAL -->|Approuvée| EXEC
    APPROVAL -->|Refusée| STOP[Arrêter]

    EXEC --> LOG[Journaliser]
    LOG --> VERIFY[Vérifier le résultat]

Le Harness Engineering ne doit donc pas être envisagé uniquement comme une optimisation des performances.

C’est aussi une discipline de sécurité, de contrôle et de responsabilité.

L’arrivée du GitHub Copilot harness dans Copilot Studio

Le 3 août 2026, Microsoft a annoncé la disponibilité générale du GitHub Copilot harness dans Copilot Studio.

Cette annonce officialise le nom d’une nouvelle capacité présentée en préversion durant les mois précédents.

Microsoft présente ce harness comme l’arrivée, dans Copilot Studio, de capacités d’orchestration, de raisonnement et d’exécution provenant de la même famille technologique que celle utilisée pour certaines expériences agentiques avancées, notamment GitHub Copilot coding agent et Copilot Cowork. Les agents créés restent néanmoins des agents Microsoft Copilot Studio : ils ne deviennent ni des agents GitHub Copilot ni des agents exclusivement destinés au développement logiciel.

Le moteur est destiné au travail :

• complexe;
• long;
• multi-étapes;
• multi-sources;
• multi-outils;
• comportant des décisions ambiguës;
• nécessitant une production en plusieurs parties.

Microsoft indique qu’il peut :

• planifier;
• raisonner sur des problèmes dynamiques;
• exécuter une boucle agentique;
• utiliser des skills;
• intégrer des workflows;
• se connecter à des outils;
• collaborer avec des agents d’autres plateformes;
• produire des résultats riches et composés de plusieurs artefacts.

Cette évolution avait été annoncée dès juin 2026 avec la nouvelle expérience Copilot Studio. Microsoft décrivait alors un nouvel orchestrateur construit sur un coding harness et une couche CLI, capable d’un meilleur respect des instructions, d’une exécution de tâches longues et d’une exécution récursive.

La documentation « What’s new » de Copilot Studio mentionnait également, en juin 2026, une nouvelle expérience utilisant le GitHub Copilot harness et un runtime d’orchestration amélioré pour la qualité des réponses et le raisonnement. Elle présentait cette expérience comme une préversion prête pour la production avant son passage en disponibilité générale annoncé le 3 août.

Copilot Studio dispose maintenant de trois harnesses

Microsoft précise que Copilot Studio prend désormais en charge trois harnesses.

flowchart TB
    CPS[Microsoft Copilot Studio]

    CPS --> CHAT[Copilot Chat harness]
    CPS --> STANDARD[Standard harness]
    CPS --> GITHUB[GitHub Copilot harness]

    CHAT --> CHATUSE[Personnalisation des expériences<br/>Microsoft 365 Copilot Chat]

    STANDARD --> STDUSE[Agents conversationnels<br/>Topics et scénarios structurés]

    GITHUB --> GHUSE[Processus agentiques complexes<br/>Travail long et multi-outils]

1. Copilot Chat harness

Il utilise le même type de harness que Microsoft 365 Copilot Chat.

Il convient particulièrement à la personnalisation des expériences conversationnelles intégrées à Copilot Chat.

2. Standard harness

C’est le moteur utilisé par la majorité des agents Copilot Studio historiques.

Il reste adapté aux agents conversationnels reposant notamment sur des topics, des embranchements et des scénarios relativement déterministes.

3. GitHub Copilot harness

Il s’agit du harness proposé par Copilot Studio pour les agents et les workflows qui nécessitent un raisonnement approfondi, plusieurs étapes, plusieurs outils, la manipulation de fichiers et l’exécution de processus métier complexes. Son nom reflète son origine technologique, mais son utilisation dans Copilot Studio ne nécessite pas que l’agent soit un agent de programmation ou qu’il soit publié dans GitHub.

Microsoft ne remplace donc pas brutalement le moteur existant.

L’éditeur propose plusieurs environnements d’exécution adaptés à différents besoins.

C’est une décision importante, car tous les agents n’ont pas besoin d’un harness long-horizon.

Quel harness utiliser?

flowchart TD
    START[Quel type d'agent voulez-vous créer?] --> Q1{Personnaliser principalement<br/>Microsoft 365 Copilot Chat?}

    Q1 -->|Oui| CHAT[Copilot Chat harness]
    Q1 -->|Non| Q2{Le processus est-il surtout<br/>conversationnel et structuré?}

    Q2 -->|Oui| STD[Standard harness]
    Q2 -->|Non| Q3{Le travail nécessite-t-il plusieurs étapes,<br/>outils, sources ou livrables?}

    Q3 -->|Oui| GH[GitHub Copilot harness]
    Q3 -->|Non| STD

Le GitHub Copilot harness est particulièrement pertinent lorsque :

• l’objectif ne peut pas être résolu par un seul appel;
• le plan doit évoluer pendant l’exécution;
• plusieurs outils doivent être utilisés;
• plusieurs fichiers doivent être analysés;
• des artefacts doivent être créés;
• l’agent doit maintenir un état de progression;
• les résultats intermédiaires doivent influencer les étapes suivantes;
• les décisions comportent une part d’ambiguïté;
• une boucle de vérification est nécessaire.

En revanche, il serait excessif de l’utiliser pour :

• répondre à une FAQ;
• retrouver une politique;
• déclencher une action simple;
• guider une conversation fortement scénarisée;
• exécuter un workflow entièrement déterministe.

Le meilleur harness n’est pas le plus puissant.

C’est celui qui correspond au problème.

Exemple : préparer un dossier de réponse à un appel d’offres

Imaginons un agent chargé de préparer une première version de réponse à un appel d’offres.

Le travail pourrait être organisé ainsi :

flowchart TD
    A[Réception de l'appel d'offres] --> B[Extraire les exigences]
    B --> C[Classer les exigences]
    C --> D[Rechercher les preuves internes]

    D --> E1[Références clients]
    D --> E2[Compétences disponibles]
    D --> E3[Certifications]
    D --> E4[Politiques de sécurité]
    D --> E5[Grille tarifaire]

    E1 --> F[Évaluer la couverture]
    E2 --> F
    E3 --> F
    E4 --> F
    E5 --> F

    F --> G{Informations manquantes?}

    G -->|Oui| H[Créer les demandes aux responsables]
    H --> I[Attendre ou obtenir les réponses]
    I --> F

    G -->|Non| J[Rédiger les sections]
    J --> K[Contrôler les exigences]
    K --> L[Produire le dossier]
    L --> M[Soumettre à validation humaine]

Un tel agent doit :

• analyser plusieurs fichiers;
• maintenir une grille d’exigences;
• rechercher des informations dans plusieurs systèmes;
• identifier les lacunes;
• interagir avec des personnes;
• attendre certaines réponses;
• reprendre le travail;
• produire plusieurs documents;
• vérifier la couverture;
• conserver une piste d’audit.

Le prompt initial ne constitue qu’une petite partie de la solution.

Le contexte doit être reconstruit pour chaque activité.

Le harness doit coordonner l’ensemble.

Les skills : une pièce essentielle du nouveau modèle

Le GitHub Copilot harness dans Copilot Studio peut utiliser des skills.

Dans la nouvelle expérience Copilot Studio, un skill est un ensemble modulaire et réutilisable d’instructions. Microsoft indique qu’un skill peut être créé une fois, ajouté à plusieurs agents et exporté sous forme de fichier Markdown ou de package.

Les skills permettent de sortir certaines compétences du prompt général de l’agent.

Par exemple :

• analyser un contrat;
• construire une matrice de risques;
• rédiger un courriel conforme;
• vérifier une proposition commerciale;
• préparer une synthèse de réunion;
• appliquer une méthode d’analyse précise.

flowchart LR
    AGENT[Agent principal] --> S1[Skill : analyser un contrat]
    AGENT --> S2[Skill : évaluer les risques]
    AGENT --> S3[Skill : produire un rapport]
    AGENT --> S4[Skill : vérifier la conformité]

    S1 --> TOOL1[Documents et recherche]
    S2 --> TOOL2[Données et règles]
    S3 --> TOOL3[Génération de fichiers]
    S4 --> TOOL4[Politiques et contrôles]

Le Harness Engineering comprend donc aussi l’organisation d’un catalogue de compétences :

• suffisamment spécialisées pour être fiables;
• suffisamment génériques pour être réutilisées;
• correctement décrites pour être sélectionnées;
• versionnées;
• testées;
• évaluées;
• gouvernées.

Harness Engineering et multi-agent

Le harness n’implique pas nécessairement plusieurs agents.

Un seul agent peut exécuter une boucle complexe en utilisant plusieurs outils.

Cependant, certaines missions se prêtent à une architecture multi-agent :

flowchart TD
    O[Agent orchestrateur]

    O --> A1[Agent de recherche]
    O --> A2[Agent d'analyse]
    O --> A3[Agent de rédaction]
    O --> A4[Agent de vérification]

    A1 --> K[Sources et connaissances]
    A2 --> D[Données]
    A3 --> F[Fichiers et artefacts]
    A4 --> P[Politiques et critères]

    A1 --> O
    A2 --> O
    A3 --> O
    A4 --> O

Dans ce cas, le harness doit notamment gérer :

• la délégation;
• la séparation des responsabilités;
• le partage du contexte;
• la synthèse des résultats;
• les conflits entre agents;
• les délais;
• la consommation;
• l’arrêt de la collaboration.

La documentation Copilot Studio indique que la nouvelle expérience permet également de connecter d’autres agents afin qu’un agent principal puisse déléguer les demandes à des spécialistes.

Le multi-agent ne doit toutefois pas devenir une fin en soi.

Créer cinq agents mal définis ne produit pas automatiquement un meilleur système qu’un seul agent correctement outillé.

Ce que cela change pour les créateurs Copilot Studio

Jusqu’à maintenant, beaucoup de créateurs Copilot Studio raisonnaient principalement en termes de :

• topics;
• déclencheurs;
• questions;
• variables;
• branches;
• actions;
• réponses.

Avec le GitHub Copilot harness, il faut ajouter de nouveaux objets mentaux :

• objectif;
• plan;
• état;
• progression;
• compétence;
• outil;
• artefact;
• preuve;
• boucle;
• critère d’arrêt;
• reprise;
• évaluation.

flowchart LR
    OLD[Conception conversationnelle] --> NEW[Conception agentique]

    OLD --> O1[Que doit répondre l'agent?]
    OLD --> O2[Quel topic doit se déclencher?]
    OLD --> O3[Quelle action doit être appelée?]

    NEW --> N1[Quel objectif doit être atteint?]
    NEW --> N2[Comment le travail est-il décomposé?]
    NEW --> N3[Comment l'état est-il conservé?]
    NEW --> N4[Comment le résultat est-il vérifié?]
    NEW --> N5[Quand l'agent doit-il s'arrêter?]

Le concepteur ne dessine plus uniquement une conversation.

Il conçoit un système de travail.

Une méthode pratique de Harness Engineering

Étape 1 — Définir le résultat observable

Évitez les objectifs vagues comme :

Aider l’équipe avec les contrats.

Préférez :

Produire, pour chaque contrat reçu, une fiche structurée contenant les parties, les dates importantes, les obligations, les clauses à risque, les informations manquantes et un lien vers les preuves utilisées.

Le résultat doit pouvoir être examiné.

Étape 2 — Définir les preuves de réussite

Pour chaque résultat, précisez :

• les champs obligatoires;
• les sources autorisées;
• les seuils de confiance;
• les contrôles;
• les conditions de rejet;
• les cas exigeant une validation humaine.

Étape 3 — Décomposer la mission

Identifiez les étapes possibles, sans nécessairement rendre le plan complètement rigide.

flowchart LR
    G[Objectif] --> T1[Tâche 1]
    G --> T2[Tâche 2]
    G --> T3[Tâche 3]

    T1 --> E1[Preuve attendue]
    T2 --> E2[Preuve attendue]
    T3 --> E3[Preuve attendue]

Étape 4 — Définir l’état minimal

Déterminez ce qui doit survivre entre deux étapes :

• objectif initial;
• plan courant;
• étapes terminées;
• étapes restantes;
• décisions prises;
• fichiers créés;
• erreurs;
• informations manquantes;
• approbations.

Étape 5 — Construire les outils

Chaque outil doit avoir :

• un nom explicite;
• une description non ambiguë;
• des paramètres validables;
• une sortie structurée;
• des permissions minimales;
• un comportement documenté en cas d’erreur.

Étape 6 — Concevoir les boucles

Déterminez :

• quand l’agent doit recommencer;
• combien de tentatives sont autorisées;
• quand il doit modifier son plan;
• quand il doit demander de l’aide;
• quand il doit arrêter le travail.

Étape 7 — Ajouter les points de contrôle humains

L’humain doit intervenir lorsqu’une action est :

• irréversible;
• financière;
• juridiquement engageante;
• susceptible d’affecter une personne;
• fondée sur des preuves insuffisantes;
• en dehors du niveau de confiance autorisé.

Étape 8 — Évaluer le processus complet

Il ne suffit plus d’évaluer la dernière réponse.

Il faut évaluer :

• la qualité du plan;
• la sélection des outils;
• le nombre d’actions;
• la consommation;
• la récupération après erreur;
• la qualité des preuves;
• le respect des permissions;
• la qualité des artefacts;
• la capacité à terminer;
• la reproductibilité.

GitHub explique évaluer son harness avec des benchmarks, des mesures issues d’utilisations réelles et des expérimentations en ligne, en contrôlant notamment les modèles, les fenêtres de contexte, les outils et les paramètres de raisonnement.

Le coût du Harness Engineering

Une boucle agentique plus puissante n’est pas gratuite.

Chaque itération peut entraîner :

• un appel au modèle;
• une utilisation de jetons;
• un appel à un outil;
• une recherche;
• une génération de fichier;
• une exécution de workflow;
• un appel à un autre agent;
• une évaluation supplémentaire.

Microsoft précise que les agents utilisant le GitHub Copilot harness dans Copilot Studio reposent sur une facturation à l’usage, indépendamment de la licence Microsoft 365 Copilot. Le coût dépend notamment des modèles choisis, du contexte organisationnel, des outils ajoutés et du temps d’exécution. Certaines expériences de création, de test et d’évaluation peuvent également entrer dans cette facturation à l’usage.

Le Harness Engineering doit donc intégrer une discipline économique :

flowchart TD
    Q[Prochaine action envisagée] --> V{Valeur attendue supérieure au coût?}

    V -->|Oui| A[Exécuter]
    V -->|Non| S{Une action moins coûteuse suffit-elle?}

    S -->|Oui| C[Choisir une solution plus légère]
    S -->|Non| H[Demander une décision humaine]

    A --> M[Mesurer coût et résultat]
    C --> M

Un agent qui boucle sans progresser n’est pas seulement inefficace.

Il peut devenir coûteux.

Les principaux risques

La boucle infinie

L’agent répète une recherche ou une action parce qu’il ne sait pas reconnaître que l’information n’existe pas.

La dérive d’objectif

Au fil des étapes, le travail s’éloigne de la demande initiale.

La perte de preuve

Le résultat final ne permet plus d’identifier les sources utilisées.

La mauvaise délégation

L’agent appelle un outil ou un sous-agent inadapté.

L’accumulation de contexte

Le système réinjecte trop d’informations et dégrade progressivement la qualité.

L’action prématurée

L’agent exécute une opération avant d’avoir obtenu une preuve ou une approbation.

L’évaluation complaisante

Le même modèle produit le résultat puis le valide sans contrôle indépendant.

Le coût non maîtrisé

L’agent multiplie les appels sans proportion avec la valeur du résultat.

Ces risques ne sont pas des accidents périphériques.

Ils constituent précisément les problèmes que le Harness Engineering doit traiter.

Une nouvelle séparation des responsabilités

On peut maintenant représenter une solution agentique en quatre couches principales :

flowchart TB
    UX[Expérience utilisateur]

    HARNESS[Harness<br/>Planification, boucle, état,<br/>outils, contrôle et reprise]

    MODELS[Modèles<br/>Raisonnement et génération]

    ENTERPRISE[Systèmes d'entreprise<br/>Données, API, workflows,<br/>applications et autres agents]

    UX <--> HARNESS
    HARNESS <--> MODELS
    HARNESS <--> ENTERPRISE

Le modèle ne devrait pas porter seul :

• la logique métier;
• la mémoire;
• la sécurité;
• la planification;
• l’autorisation;
• la récupération après erreur;
• la preuve de réussite.

Ces responsabilités doivent être réparties dans une architecture contrôlable.

C’est l’une des idées les plus importantes du Harness Engineering :

Ne demandez pas au modèle de remplacer l’architecture.

Ce que l’annonce de Copilot Studio signifie réellement

L’arrivée du GitHub Copilot harness dans Copilot Studio signifie que les créateurs d’agents disposent désormais d’un environnement conçu pour aller au-delà des assistants conversationnels traditionnels.

Ils peuvent créer des agents capables de :

• travailler sur des missions longues;
• décomposer un objectif;
• utiliser plusieurs outils;
• exploiter plusieurs sources;
• produire plusieurs artefacts;
• s’appuyer sur des skills;
• collaborer avec des workflows;
• déléguer à d’autres agents;
• adapter leur plan;
• poursuivre un travail à travers une boucle agentique.

Mais cette puissance ne rend pas automatiquement les agents fiables.

Elle déplace la responsabilité.

Lorsque nous construisions un chatbot, nous devions surtout écrire de bonnes réponses et organiser une bonne conversation.

Lorsque nous construisons un agent long-horizon, nous devons concevoir un système complet d’exécution.

La question n’est plus seulement :

Est-ce que l’agent répond correctement?

Elle devient :

Est-ce que l’agent accomplit correctement le travail, avec les bons outils, les bonnes permissions, les bonnes preuves, au bon coût et dans les limites que nous lui avons données?

Du Prompt Engineer au Harness Engineer

Le Prompt Engineer travaillait principalement sur les instructions.

Le Context Engineer travaille sur l’information disponible lors de chaque décision.

Le Harness Engineer travaille sur la totalité du dispositif qui permet au système de progresser.

flowchart LR
    PE[Prompt Engineer] -->|Conçoit| P[Instructions]
    CE[Context Engineer] -->|Conçoit| C[Contexte]
    HE[Harness Engineer] -->|Conçoit| H[Système d'exécution]

    P --> AG[Agent]
    C --> AG
    H --> AG

    AG --> R[Résultat vérifiable]

Cette nouvelle discipline mobilise des compétences issues de plusieurs domaines :

• intelligence artificielle;
• architecture logicielle;
• automatisation;
• conception de workflows;
• sécurité;
• gestion des identités;
• gouvernance des données;
• observabilité;
• évaluation;
• ingénierie de la connaissance;
• expérience utilisateur;
• analyse des processus métier.

Le Harness Engineering n’est donc pas une variante plus sophistiquée du Prompt Engineering.

C’est une forme d’architecture des systèmes agentiques.

Nous ne programmons plus seulement des réponses

Le Prompt Engineering nous a appris à mieux formuler nos intentions.

Le Context Engineering nous a appris à mieux alimenter le modèle.

Le Harness Engineering doit maintenant nous apprendre à mieux organiser le travail de l’intelligence artificielle.

Cette évolution marque un passage décisif :

flowchart LR
    A[Produire une réponse] --> B[Prendre une décision]
    B --> C[Exécuter une action]
    C --> D[Accomplir un processus]
    D --> E[Prouver que le travail est terminé]

Avec la disponibilité générale du GitHub Copilot harness dans Copilot Studio annoncée le 3 août 2026, Microsoft rend ce changement accessible aux créateurs d’agents métier.

Nous pouvons désormais utiliser Copilot Studio non seulement pour créer des conversations ou déclencher quelques actions, mais aussi pour bâtir des agents capables de progresser dans des processus plus longs, plus ambigus et plus complexes.

Cela ouvre des possibilités considérables.

Mais cela impose également une nouvelle exigence d’ingénierie.

Un modèle puissant ne suffit pas.

Un bon prompt ne suffit pas.

Une grande fenêtre de contexte ne suffit pas.

Pour qu’un agent réalise réellement un travail complexe, il faut concevoir tout ce qui l’entoure : son plan, ses outils, sa mémoire, ses boucles, ses contrôles, ses preuves et ses conditions d’arrêt.

Autrement dit, il faut lui construire un harness.

Et apprendre à l’ingénier.

Pour aller plus loin

Annonce officielle de Microsoft

More powerful agents and workflows for autonomous business processes: Introducing a new harness for Copilot Studio, publié par l’équipe Copilot Studio le 3 août 2026. Cette annonce présente la disponibilité générale du GitHub Copilot harness dans Copilot Studio, ses principaux usages et la coexistence des trois harnesses proposés par la plateforme.

https://techcommunity.microsoft.com/blog/copilot-studio-blog/more-powerful-agents-and-workflows-for-autonomous-business-processes-introducing/4542969

Documentation Copilot Studio

La page What’s new in Copilot Studio documente l’introduction de la nouvelle expérience, des skills, de la mémoire, de Microsoft IQ et de la connexion à d’autres agents.

https://techcommunity.microsoft.com/blog/copilot-studio-blog/meet-the-new-copilot-studio-rebuilt-for-more-complex-multi-step-work/4526488

Analyse technique de GitHub

L’article Evaluating performance and efficiency of the GitHub Copilot agentic harness across models and tasks décrit le rôle du harness GitHub Copilot, l’orchestration des outils, du contexte et des workflows, ainsi que les méthodes utilisées pour en mesurer les performances et l’efficacité.

https://github.blog/ai-and-ml/github-copilot/evaluating-performance-and-efficiency-of-the-github-copilot-agentic-harness-across-models-and-tasks

Ressource vidéo IBM Technology

La vidéo Harnesses in AI: A Deep Dive, présentée par Tejas Kumar sur la chaîne IBM Technology, offre une excellente explication pédagogique de la fonction d’un harness autour des modèles et des agents. Elle peut utilement compléter les sources techniques Microsoft et GitHub, même si l’annonce et les caractéristiques propres à Copilot Studio doivent être vérifiées dans les publications officielles de Microsoft.