Tutos, news et aides informatiques

Publié le par Publié dans WINDOWS

DESCRIPTION :

Il n’existe pas toujours un connecteur prêt à l’emploi dans la galerie pour vos outils métier. Votre entreprise utilise peut-être une application maison, un ERP spécifique, une base de données propriétaire ou un système legacy que Microsoft et ses partenaires ne couvrent pas. Dans ce cas, il faut mettre les mains dans le cambouis et créer un connecteur sur mesure.

Cet article est orienté admin avancé et développeur. On va voir les trois approches pour créer un connecteur custom (Microsoft 365 Agents Toolkit, Copilot Connectors SDK, API Graph directe), puis comment développer un serveur MCP pour connecter une source de données en mode fédéré. C’est l’article le plus technique de la série, mais j’ai essayé de le rendre accessible même si vous n’êtes pas développeur à temps plein.

NB : Si vous êtes un admin pur sans appétence développement, cet article vous sera quand même utile pour comprendre ce qui est possible et pouvoir spécifier un besoin à votre équipe dev ou à un prestataire.

Cet article est le huitième d’une série de 10 articles dédiés à Microsoft Copilot sur Infonovice.fr.

Voici le programme complet de la série :

Bonne lecture !

!!!! Avant de lire cet article. Personnellement, je ne suis pas développeur et je n’avais pas toutes les connaissances techniques pour rédiger cet article. C’est pourquoi j’ai été assisté de l’IA pour m’aider à compiler les liens que j’ai trouvé sur Internet, mélangé aux connaissances minimales que j’avais sur le sujet et mes recherches. Cette combinaison IA + Connaissances personnelles + Recherches a permis la rédaction de cet articles. J’évoquerais donc les grandes lignes sans pour autant remplacer un développeur. Pour plus d’informations, je vous invite à prendre contact avec vos équipes de développement. !!!

Ma source de départ => Build your first custom Microsoft 365 Copilot connector – Microsoft Graph | Microsoft Learn

Quand créer un connecteur custom ?

Avant de vous lancer dans un développement, assurez-vous que c’est réellement nécessaire. Voici les cas où un connecteur custom est pertinent :

  • Aucun connecteur n’existe dans la galerie pour votre source de données.
  • Votre source de données est une application métier interne développée sur mesure.
  • Vous avez besoin d’un contrôle total sur le schéma, les métadonnées, les ACL ou la logique d’ingestion.
  • Vous utilisez une API propriétaire qui nécessite une logique de transformation spécifique.
  • Vous avez des données dans une base de données on-premises qui n’est pas couverte par les connecteurs Microsoft-built.

Dans tous les autres cas, privilégiez un connecteur préconfigured de la galerie. Les connecteurs custom offrent plus de flexibilité, mais ils nécessitent du développement, de la maintenance et une gestion des quotas d’éléments indexés.

Les trois méthodes pour créer un connecteur synchronisé custom

Microsoft propose trois approches pour créer un connecteur synchronisé personnalisé, du plus assisté au plus libre.

Méthode 1 : Microsoft 365 Agents Toolkit (recommandé)

C’est la méthode la plus récente et celle que Microsoft recommande pour les nouveaux développements. Le Microsoft 365 Agents Toolkit (ATK) inclut un template de connecteur Copilot directement dans Visual Studio Code.

Ce que fait le template (Définition : Un template est un modèle que l’on peut utiliser pour déployer de nouveaux connecteurs) :

Le template scaffold un connecteur complet qui :

  • Se connecte à une source de données (le template utilise l’API GitHub comme exemple, mais vous pouvez le remplacer par n’importe quelle API).
  • Définit un schéma avec les propriétés et labels sémantiques.
  • Ingère les données dans Microsoft Graph via l’API Copilot Connectors.
  • Peut être lancé localement via F5 (debug) ou déployé dans Azure Functions pour une exécution planifiée.

NB : Un scaffold est une structure de départ déjà prête, comparable au squelette du projet, qui permet de créer plus facilement un connecteur complet.

Structure du projet :

Le template génère un projet avec trois dossiers principaux à personnaliser :

  • src/custom/ : Le code qui va chercher les données dans votre source et les transforme au format attendu. C’est ici que vous remplacerez l’appel GitHub par l’appel à votre API métier.
  • src/references/ : La définition du schéma du connecteur (propriétés, types, labels sémantiques). À adapter à la structure de vos données.
  • src/models/ : Les modèles de données internes et la configuration.

Prérequis :

  • Visual Studio Code avec l’extension Microsoft 365 Agents Toolkit.
  • Node.js (pour le scaffold et l’exécution locale).
  • Un tenant Microsoft 365 avec une licence Copilot (pour les tests).
  • Un compte AI Administrator ou Global Admin pour l’enregistrement du connecteur.

NB : Après le déploiement, le connecteur apparaît dans le M365 Admin Center > Copilot > Connectors comme n’importe quel connecteur préconfigured. L’admin peut le gérer (crawl, schéma, visibilité) depuis l’interface graphique.

Méthode 2 : Copilot Connectors SDK (C# / gRPC)

Le Copilot Connectors SDK est l’approche « classique » pour créer un connecteur custom, particulièrement adaptée si votre équipe développe en C#.

Comment ça fonctionne :

Le SDK fournit un framework gRPC (Google Remote Procedure Call) qui s’intègre avec le Microsoft Graph Connector Agent (l’agent on-premises vu dans l’article 6). Concrètement :

  1. Vous écrivez un serveur gRPC en C# qui implémente la logique de récupération des données depuis votre source.
  2. Le serveur gRPC tourne sur la même machine que le Graph Connector Agent.
  3. Le Graph Connector Agent fait des requêtes gRPC à votre serveur pour récupérer les données.
  4. Le Graph Connector Agent ingère les données dans Microsoft Graph via les API cloud.

Composants du SDK :

  • Custom connector template : Un projet C# prêt à personnaliser (téléchargeable depuis Visual Studio Marketplace ou NuGet).
  • Graph Connector Agent : Le composant qui orchestre le crawl et l’ingestion (même agent que pour les connecteurs on-premises).
  • Test utility : Un outil de test avec des scénarios prébuilt pour valider votre connecteur avant le déploiement.

Quand utiliser le SDK plutôt que l’Agents Toolkit ?

  • Vos données sont on-premises et nécessitent le Graph Connector Agent.
  • Votre équipe est plus à l’aise en C# qu’en TypeScript/JavaScript.
  • Vous avez besoin de fonctionnalités avancées comme la traversée de structures arborescentes (dossiers, hiérarchies) ou la gestion de groupes externes pour les ACL non-Entra.

Méthode 3 : API Microsoft Graph Connectors (REST directe)

C’est l’approche la plus flexible mais aussi la plus manuelle. Vous utilisez directement l’API REST de Microsoft Graph pour créer et alimenter un connecteur, dans le langage de programmation de votre choix.

Les endpoints principaux :

  • /external/connections (externalConnection) : Créer et gérer les connexions. Une connexion est le conteneur logique de vos données externes.
  • /external/connections/{connectionId}/items (externalItem) : Créer, mettre à jour et supprimer les éléments de contenu dans la connexion.
  • /external/connections/{connectionId}/schema : Définir le schéma de données de la connexion.
  • /external/connections/{connectionId}/groups (externalGroup) : Gérer les groupes non-Entra pour les ACL (Salesforce, ServiceNow, etc.).

Flux typique de développement :

  1. Enregistrer une App Registration dans Entra ID avec les permissions ExternalItem.ReadWrite.All et ExternalConnection.ReadWrite.OwnedBy.
  2. Obtenir le consentement admin pour ces permissions.
  3. Créer la connexion via l’API (POST /external/connections).
  4. Définir le schéma avec les propriétés, types et labels sémantiques (POST /external/connections/{id}/schema).
  5. Ingérer les éléments un par un ou par lots (PUT /external/connections/{id}/items/{itemId}).
  6. Gérer les ACL pour chaque élément (qui peut voir quoi).
  7. Planifier les crawls (votre code doit gérer la logique de synchronisation : détection des ajouts, modifications, suppressions).

NB : Contrairement aux deux méthodes précédentes, l’API REST ne fournit pas de framework de crawl. C’est à vous de développer la logique d’orchestration (planification, gestion des erreurs, reprise après échec, crawls incrémentaux vs complets). C’est plus de travail, mais aussi plus de liberté.

Les bonnes pratiques pour les connecteurs synchronisés custom

Quelle que soit la méthode choisie, voici les recommandations de Microsoft pour maximiser la qualité des réponses Copilot basées sur vos données :

1. Appliquez tous les labels sémantiques pertinents. Au minimum : iconUrl, title, url. Ajoutez lastModifiedBy et lastModifiedDateTime si disponibles.

2. Enrichissez la propriété content. C’est le champ le plus important pour le grounding Copilot. Ingérez du texte riche (rich text) plutôt que du texte brut. Incluez le contexte pertinent (titres, sous-titres, métadonnées utiles).

3. Ajoutez un urlToItemResolver. Cela permet à Copilot de résoudre les liens partagés par les utilisateurs vers les External Items correspondants dans Graph. Sans ça, Copilot traite les liens comme des URLs web ordinaires.

4. Ajoutez des user activities. Les signaux d’activité utilisateur (qui a consulté quel élément, quand) améliorent le classement des résultats. Copilot peut ainsi privilégier les éléments récemment consultés par l’utilisateur.

5. Fournissez des descriptions significatives. Lors de la création de la connexion, la description aide Copilot à comprendre quand utiliser cette source.

6. Gérez les ACL avec rigueur. Si votre source de données utilise des groupes non-Entra (groupes Salesforce, profils ServiceNow, etc.), utilisez l’API externalGroup pour mapper ces groupes vers des identités Entra. C’est la seule façon de garantir que les permissions de la source sont respectées dans Copilot.

7. Surveillez votre quota d’éléments. Les éléments ingérés consomment un quota. Vérifiez votre quota disponible et anticipez les besoins de quota supplémentaire (achat possible via le M365 Admin Center).

Créer un serveur MCP pour un connecteur fédéré custom

Si votre besoin est plutôt un accès temps réel aux données (sans indexation dans Graph), ou si vos données sont trop sensibles pour être copiées dans Microsoft 365, la voie fédérée via MCP est l’alternative.

Rappel : Qu’est-ce qu’un serveur MCP ?

Comme vu dans l’article 6, un serveur MCP est un service web qui :

  • Reçoit des requêtes de recherche de la part de Copilot (le client MCP).
  • S’authentifie auprès de votre source de données avec les credentials de l’utilisateur (OAuth 2.0).
  • Interroge votre source et renvoie les résultats au format MCP.
  • Ne stocke aucune donnée côté Microsoft.

Architecture d’un serveur MCP custom

Le serveur MCP est hébergé et maintenu par vous (sur Azure, AWS, on-premises, peu importe). C’est lui qui fait le pont entre le protocole MCP parlé par Copilot et l’API native de votre application métier.

Les composants à développer

1. Le serveur MCP lui-même

Le serveur doit implémenter la spécification MCP (disponible sur https://spec.modelcontextprotocol.io/). En résumé, il doit exposer des endpoints capables de :

  • Recevoir des requêtes de recherche avec un contexte utilisateur.
  • Interroger votre source de données.
  • Renvoyer les résultats sous forme structurée (titre, contenu, URL, métadonnées).

Le choix du langage est libre. MCP est un protocole basé sur JSON-RPC, donc n’importe quel langage supportant HTTP et JSON convient (Python, Node.js, C#, Go, Java…).

2. L’authentification OAuth 2.0

Les connecteurs fédérés utilisent exclusivement OAuth 2.0 pour l’authentification. Votre serveur MCP doit :

  • Supporter le flow OAuth 2.0 Authorization Code (l’utilisateur s’authentifie via un navigateur).
  • Valider les tokens reçus.
  • Utiliser le token utilisateur pour interroger votre source de données (assurant que l’utilisateur ne voit que les données auxquelles il a droit dans le système source).

Si votre application métier ne supporte pas OAuth 2.0 nativement, vous devrez ajouter une couche d’authentification (par exemple via Azure AD Application Proxy, ou en implémentant un endpoint OAuth dans votre serveur MCP qui traduit vers le mécanisme d’authentification natif de votre application).

3. L’enregistrement dans le tenant

Pour que votre connecteur fédéré apparaisse dans le tenant, vous devez l’enregistrer comme un connecteur MCP personnalisé. Le processus exact est encore en évolution (au moment où j’écris, les connecteurs fédérés publiés sont Microsoft-published). La documentation Microsoft Learn est en cours de mise à jour pour les connecteurs fédérés custom.

NB : Au moment de la rédaction de cet article (avril 2026), la création de connecteurs fédérés custom est encore en phase d’adoption précoce. Les connecteurs fédérés disponibles dans la galerie sont publiés par Microsoft. Si vous envisagez de développer un serveur MCP custom, surveillez les mises à jour de la documentation Microsoft et les annonces dans le Message Center. Le SDK et les outils pour les connecteurs fédérés custom sont attendus dans les prochains mois.

Quand choisir un connecteur fédéré (MCP) vs synchronisé (Graph) ?

Les API de recherche Copilot

Pour les développeurs qui veulent exploiter les données indexées par les connecteurs dans leurs propres applications (au-delà de Copilot Chat et Microsoft Search), Microsoft propose deux API :

Copilot Search API

L’API Copilot Search permet d’effectuer des recherches sémantiques dans les données indexées par les connecteurs synchronisés, y compris les External Items de Microsoft Graph.

Cette API est utilisée en interne par Copilot Chat et Microsoft Search, mais elle est aussi disponible pour les développeurs via Microsoft Graph. Elle permet de :

  • Rechercher dans l’ensemble des données indexées (fichiers M365 + données externes des connecteurs).
  • Bénéficier de l’indexation sémantique (recherche par sens, pas seulement par mots-clés).
  • Filtrer par source (spécifier quels connecteurs inclure dans la recherche).

Copilot Retrieval API

L’API Copilot Retrieval est conçue pour le RAG (Retrieval-Augmented Generation). Elle permet de récupérer les passages de texte les plus pertinents pour enrichir le contexte d’un LLM.

C’est l’API que vous utiliserez si vous développez une application IA custom (hors Copilot) qui a besoin d’accéder aux données indexées dans votre tenant Microsoft 365 pour générer des réponses « grounded » (ancrées dans les données réelles).

NB : Ces API sont principalement destinées aux développeurs qui construisent des applications IA sur mesure. Pour la plupart des cas d’usage admin, les expériences Copilot Chat et Microsoft Search suffisent.

La délégation de la gestion des connecteurs custom

Un point pratique important pour les admins : comment déléguer la gestion des connecteurs custom à un AI Administrator sans passer par un Global Admin ?

Microsoft fournit un script PowerShell de délégation qui permet d’accorder au rôle AI Administrator les permissions nécessaires pour gérer les connecteurs custom. Sans ce script, certaines opérations sur les connecteurs custom (notamment la création de connexions via l’API) nécessitent des permissions Global Admin.

Le script est documenté sur Microsoft Learn : « Grant admin rights to AI Admins for connectors » (https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/connector-admin-delegation).

Après exécution du script, l’AI Administrator peut :

  • Créer des connexions pour les connecteurs custom.
  • Gérer le schéma et les paramètres de crawl.
  • Voir les statistiques d’indexation.
  • Déclencher des crawls manuels.

Le script ne délègue pas la capacité d’accorder le consentement pour les permissions Microsoft Graph Application. Cette opération reste du ressort du Privileged Role Admin ou Global Admin.

Résumé des méthodes de création

Conclusion

La création de connecteurs custom est un sujet avancé, mais il ouvre des possibilités considérables pour étendre Copilot à l’ensemble de votre patrimoine de données. Voici les points à retenir :

  • Trois méthodes pour les connecteurs synchronisés custom : Agents Toolkit (recommandé pour les nouveaux projets), Copilot Connectors SDK (C# / on-premises), et API Graph REST (contrôle total).
  • Les labels sémantiques et la propriété content sont les clés de la qualité du grounding Copilot. Investissez du temps dans la qualité du schéma.
  • Les serveurs MCP pour les connecteurs fédérés custom sont une voie prometteuse pour les données sensibles ou temps réel, mais l’outillage est encore en maturation.
  • La délégation de la gestion des connecteurs custom à l’AI Administrator est possible via un script PowerShell dédié.
  • Les API Copilot Search et Retrieval permettent d’exploiter les données indexées dans des applications IA custom.
  • Privilégiez toujours un connecteur préconfigured de la galerie quand il existe. Le custom, c’est puissant, mais c’est aussi du code à maintenir.

Dans le prochain article, on change de registre pour parler de la création et administration des agents IA avec Copilot Studio et Agent Builder : les 4 méthodes de création, les identités dans Entra, le monitoring de la consommation, et la transition vers Entra Agent ID.

Liens utiles :

Article rédigé en Avril 2026. Les outils et API décrits évoluent rapidement, notamment côté connecteurs fédérés custom. Consultez la documentation Microsoft Learn pour les dernières mises à jour.

Article précédent : [Déployer des connecteurs Copilot préconfigurés : Guide pratique] Article suivant : [Créer et administrer des agents IA avec Copilot Studio et Agent Builder]

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *