Agents multi-modèles : gouverner le routage avant de déléguer les actions
Changer de modèle sans reconstruire un agent peut faciliter son exploitation. Pour une entreprise belge ou française, la décision reste à encadrer : quelles données chaque modèle reçoit-il, que se passe-t-il lors d’un repli et qui autorise une action métier ?
1. Ce que Microsoft annonce le 28 octobre
Microsoft annonce la mise à disposition du Copilot harness dans Microsoft Foundry. Cette couche d’orchestration fournit aux agents instructions, contexte, environnement d’exécution et contrôles. L’éditeur décrit une prise en charge de plusieurs familles de modèles, de MCP et des compétences d’agents, ainsi qu’un SDK téléchargeable et une exécution cloud gérée par Foundry. Dans cette dernière formule, Microsoft indique opérer la boucle de l’agent et son environnement isolé ; le client apporte instructions, outils et choix de modèles.
2. Ce que cela change pour les entreprises belges et françaises
La piste opérationnelle consiste à comparer une orchestration gérée avec la maintenance d’une boucle interne. Pour une PME, commencer par un processus borné, par exemple préparer une réponse à partir d’un corpus autorisé, et mesurer la charge de supervision. Pour une ETI, un grand groupe ou une administration, demander avant tout pilote les conditions d’accès, les régions, les coûts et les responsabilités de support applicables au service retenu. L’annonce ne suffit pas à qualifier un déploiement de souverain.
3. Analyse Underside : le routage devient une décision de gouvernance
Notre recommandation est de définir une liste de modèles autorisés pour chaque classe de données et chaque outil. Tester le cas où le modèle prévu devient indisponible : le repli doit respecter le même périmètre de traitement ou arrêter l’exécution. Pour un RAG, appliquer les droits documentaires avant de transmettre le contexte et examiner aussi les données présentes dans les journaux. La liberté de choix entre modèles doit être démontrée sur le workflow réel, avec ses contraintes de confidentialité.
4. Connecter Odoo sans déléguer les règles métier
Pour un pilote Odoo Entreprise en Belgique ou en France, séparer recherche, brouillon et écriture. Proposer un scénario de recette : l’agent consulte une commande avec un compte dédié, prépare une modification, puis attend une approbation avant l’appel d’écriture. Tester un refus d’accès entre sociétés, une expiration de session et une reprise après interruption. Vérifier qu’une reprise ne crée pas deux commandes. Ce scénario est une recommandation d’intégration Underside, pas une fonctionnalité Odoo annoncée par Microsoft.
5. Une recette comparant qualité et maîtrise
Constituer un jeu de dossiers représentatifs en français et en anglais, avec réponses attendues et cas interdits. Comparer les modèles sur la justesse, le coût par dossier, le délai, les appels d’outils et les validations nécessaires. Conserver les versions de configuration et les décisions de routage pour reproduire un incident. Avant l’ouverture aux utilisateurs, exiger un test de révocation et une procédure permettant d’arrêter les actions tout en conservant les preuves utiles.
Recommandation opérationnelle : valider une matrice « classe de données × modèle × outil × action autorisée ». Un test de repli, un test de reprise sans doublon et un refus d’accès doivent réussir avant toute écriture métier.
Cadrer un projet d’IA gouvernée