# Module 7 — Protocoles et interopérabilité : API, connecteurs, MCP ## Section 1 — Démarrer ### Comment utiliser ce cours Ce module représente environ **7 heures** de travail. Chemin conseillé : 1. **Lisez les chapitres 1 à 5** (la métaphore de la prise, API/connecteur/MCP) — 100 minutes. 2. **Faites la démonstration commentée du chapitre 6** (lire un schéma d'architecture) — 30 minutes. 3. **Réalisez l'atelier du chapitre 7** (cartographier l'architecture Banque Méridienne) — 90 minutes. 4. **Étudiez l'exemple travaillé du chapitre 8**, puis **produisez votre livrable** (chapitre 9) — 60 minutes. 5. **Faites les mini-exercices et le quiz** (chapitre 10), vérifiez avec les **corrigés en annexe D** — 30 minutes. 6. **Parcourez la FAQ (chapitre 11)** et gardez la **fiche mémo (annexe A)**. > **Conventions de lecture.** Les blocs à chasse fixe sont des **schémas, prompts ou extraits techniques** à lire (et fournis dans `scripts/`). Les encadrés « Piège », « Bonne pratique », « Le saviez-vous » et ⚠️ « Attention » signalent un point clé. ------------------------------------------------------------------------ ### Fiche du module | Rubrique | Valeur | |----|----| | Module | 7 — Protocoles et interopérabilité (API, connecteurs, MCP) | | Palier | Avant-garde (Praticien) | | Durée | 7 heures | | Prérequis | Module 6 validé | | Plateforme d'atelier | Copilot Studio (industrialisation) ; conception sur Claude | | Compétence clé visée | Lire une architecture connectée et ses points d'intégration | | 3 promesses portées | Productivité (l'IA agit dans les outils) + sécurité (chaque connexion est une porte) | | Votre livrable | Schéma d'architecture connectée + tableau des autorisations | | Validation | Quiz ≥ 75 % + schéma conforme à la grille (14/20) | ------------------------------------------------------------------------ ## Section 2 — Comprendre ### Ch.1 — Pourquoi l'interopérabilité est le cœur du métier ## 1.1 La valeur vient de ce à quoi l'IA est connectée Un modèle seul ne fait que parler. Sa valeur en entreprise vient de ce à quoi il est **connecté** : Microsoft 365, Dynamics 365, le SIRH, la base clients. Comprendre les protocoles, c'est comprendre où se crée la **productivité** (l'IA agit dans les outils réels), où se logent les **risques de sécurité** (chaque connexion est une porte) et où se joue la dépendance fournisseur. C'est le module qui permet de vendre de l'**intégration** — son cœur de métier — plutôt qu'un gadget isolé. ## 1.2 Lire avant de construire Vous n'allez pas construire l'intégration (c'est le rôle des spécialistes Power Platform). Vous allez apprendre à la **lire** : reconnaître les composants, le sens des flux, les points de rupture et les autorisations. C'est ce qui vous permet d'arbitrer, de chiffrer et de défendre une architecture. > **Idée force du module.** Chaque connexion crée de la valeur **et** ouvre une porte. L'art de l'interopérabilité, c'est de brancher juste ce qu'il faut, proprement et sous contrôle. > > **Le saviez-vous ?** Le protocole **MCP (Model Context Protocol)** vise à devenir la « prise universelle » entre les modèles et les outils de l'entreprise — comme l'USB a unifié les périphériques. Il réduit le coût d'intégration et la dépendance à un connecteur propriétaire. ------------------------------------------------------------------------ ### Ch.2 — Objectifs et compétences visées À l'issue de ce cours, vous serez capable de : 1. **Distinguer** API, connecteur et MCP, et expliquer ce que chacun apporte. 2. **Lire** un schéma d'architecture connectée (déclencheur, modèle, connexions, flux). 3. **Cartographier** les points d'intégration d'un cas et leurs autorisations. 4. **Identifier** les points de rupture et de risque de chaque connexion. ------------------------------------------------------------------------ ### Ch.3 — Pourquoi ça compte pour votre organisation | Promesse | Comment l'interopérabilité la sert | |----|----| | Productivité ×3 | L'IA agit dans les outils réels (créer une tâche, notifier) — pas seulement répondre | | Réduction des coûts | MCP et connecteurs réduisent le coût et le délai d'intégration | | Sécurité / conformité | Chaque connexion est une porte : on l'authentifie et on la borne | ------------------------------------------------------------------------ ### Ch.4 — Concepts et vocabulaire clés - **API (interface de programmation)** — porte standardisée par laquelle deux logiciels se parlent. C'est par API qu'un système IA lit ou écrit dans une application. - **Connecteur** — composant prêt à l'emploi qui relie l'IA à une application précise (ex. connecteur SharePoint, connecteur Dynamics) sans développement lourd. - **MCP (Model Context Protocol)** — protocole standard permettant à un modèle de découvrir et d'utiliser des outils et des sources de façon uniforme, comme une **prise universelle**. Il réduit le coût d'intégration et la dépendance à un connecteur propriétaire. - **Interopérabilité** — capacité de composants hétérogènes à fonctionner ensemble grâce à des standards partagés. - **Webhook / déclencheur** — mécanisme par lequel un événement (nouvel e-mail, nouveau ticket) déclenche automatiquement une action IA. - **Authentification / autorisation (OAuth, identité Entra)** — qui a le droit d'accéder à quoi ; pierre angulaire de la sécurité d'une intégration. > **Piège classique.** Confondre **API** et **connecteur**. L'API est la prise brute (il faut un adaptateur par appareil) ; le connecteur est l'adaptateur prêt à l'emploi ; MCP vise la prise universelle. ------------------------------------------------------------------------ ### Ch.5 — Comprendre en profondeur ## 5.1 La métaphore de la prise Imaginez vos appareils électriques. Une **API**, c'est une prise propriétaire : pour chaque appareil, il faut le bon adaptateur, configuré à la main. Un **connecteur**, c'est un adaptateur tout prêt pour un appareil donné (le connecteur Dynamics, le connecteur SharePoint). **MCP**, c'est l'ambition d'une **prise universelle** : un seul standard que tous les outils comprennent, pour brancher le modèle sans réinventer l'adaptateur à chaque fois. ## 5.2 Lire un schéma d'intégration Un schéma d'architecture connectée se lit en repérant quatre éléments : le **déclencheur** (l'événement qui lance tout), le **modèle** (qui interprète/décide), les **connexions** (vers quelles applications), et le **sens des flux** (qui lit, qui écrit). Une fois ces quatre éléments identifiés, vous comprenez n'importe quelle architecture. ## 5.3 Points de rupture et de risque Chaque connexion peut casser : panne d'API, changement de version, quota dépassé, connecteur indisponible. Et chaque connexion est un **risque de sécurité** : elle donne un accès. D'où la règle : **chaque connexion = une autorisation explicite et bornée.** ## 5.4 Chaque connexion porte une autorisation À chaque connexion correspond une question : **qui s'authentifie, avec quels droits, sur quelles données ?** Un assistant qui peut *lire* les e-mails est moins risqué qu'un assistant qui peut *envoyer* des e-mails au nom de quelqu'un. Le principe du **moindre privilège** s'applique : ne donner que le strict nécessaire. **Mini-exercice 5.A.** Un assistant doit lire les nouveaux tickets et créer une tâche dans le CRM. Quelles sont les deux autorisations distinctes, et laquelle est la plus sensible ? *(Corrigé en annexe D.)* ------------------------------------------------------------------------ ## Section 3 — Pratiquer ### Ch.6 — Démonstration commentée : lire une architecture connectée Le dossier `scripts/` contient un schéma d'architecture (`architecture_cas.txt`). Ouvrez-le et suivez la lecture. ## 6.1 Le schéma à lire `[Déclencheur] Nouvel e-mail dans Outlook (M365) | v [Modèle IA] extrait l'objet, classe la demande, résume | +--> [Connecteur Dynamics 365] crée une tâche (écriture) | +--> [Connecteur Teams] notifie l'agent (écriture) | [Autorisations] lecture Outlook · écriture Dynamics · écriture Teams · identité Entra` ## 6.2 Lire organe par organe - **Déclencheur** : l'arrivée d'un e-mail (un *webhook* sur Outlook). - **Modèle** : interprète l'e-mail (classification + résumé) — la partie « intelligence ». - **Connexions** : deux écritures, vers Dynamics 365 (créer une tâche) et vers Teams (notifier). - **Flux** : lecture depuis Outlook, écriture vers Dynamics et Teams. - **Autorisations** : lire Outlook, écrire Dynamics, écrire Teams — chacune via l'identité Entra. **Où est MCP ?** Aujourd'hui, ces connexions passent par des connecteurs Power Platform. Demain, un serveur MCP exposerait ces mêmes outils de façon standard, réduisant le coût d'intégration et la dépendance à un connecteur précis. > **Bonne pratique.** Quand vous lisez une architecture, posez-vous toujours : « combien de portes ouvre-t-on, et chacune est-elle strictement nécessaire ? ». Une porte de trop est une faille de trop. ------------------------------------------------------------------------ ### Ch.7 — Mode opératoire détaillé (action par action) ## 7.0 Prérequis de l'atelier - les **fichiers du module** : `scripts/architecture_cas.txt` (schéma), `scripts/connecteur_pseudo_config.txt` (pseudo-config), `scripts/mcp_exemple.txt` (exemple MCP) ; - un **compte Claude** pour structurer votre lecture (atelier de conception) ; - environ **90 minutes** + le gabarit du schéma (chapitre 9). > Vous n'avez **rien à exécuter** : ces fichiers sont des supports de lecture et de cartographie. ## 7.1 Atelier — étape 1 : cartographier l'architecture (cas Banque Méridienne) **Cas.** Banque Méridienne veut un assistant qui, à partir d'un e-mail entrant (Outlook/M365), crée automatiquement une tâche dans Dynamics 365 et notifie l'agent dans Teams. 1. Ouvrez `scripts/architecture_cas.txt` et repérez les quatre éléments (déclencheur, modèle, connexions, flux). 2. Reproduisez le schéma dans votre livrable, en précisant pour chaque connexion si elle est en **lecture** ou en **écriture**, et le type (API / connecteur / MCP). 3. Au besoin, faites-vous aider par Claude pour structurer (prompt `01_lecture_architecture.txt`). **Checklist de vérification — étape 1.** Avant de passer à l'étape 2, assurez-vous que : - \[ \] le déclencheur, le modèle et chaque connexion sont identifiés ; - \[ \] le sens des flux (lecture/écriture) est précisé ; - \[ \] vous distinguez API, connecteur et MCP. ## 7.2 Atelier — étape 2 : autorisations et risques 1. Pour chaque connexion, remplissez le tableau « connexion → autorisation requise → risque » (modèle dans `scripts/connecteur_pseudo_config.txt`). 2. Appliquez le **moindre privilège** : chaque autorisation est-elle strictement nécessaire ? Une écriture est-elle bornée (ex. créer une tâche, mais pas supprimer) ? **Checklist de vérification — étape 2.** Avant de produire votre livrable, assurez-vous que : - \[ \] chaque connexion a une autorisation et un risque associés ; - \[ \] le principe du moindre privilège est appliqué ; - \[ \] vous savez expliquer en une phrase l'intérêt de MCP. > \[!WARN\] **Attention — chaque connexion est une porte.** Une intégration mal bornée (un assistant qui peut envoyer des e-mails ou supprimer des données sans limite) est un risque majeur. Donnez toujours le **strict nécessaire** et faites valider les autorisations par la sécurité du client. Vous approfondirez au Module 9. ## 7.3 Industrialisation Microsoft Copilot Studio Ce schéma s'industrialise dans **Copilot Studio** (l'agent), avec les **connecteurs Power Platform** (Outlook, Dynamics, Teams) et l'**identité Entra** pour les autorisations. C'est un terrain naturel pour un partenaire Microsoft. Le rôle de l'orchestrateur (Module 2) est ici tenu par le flux Power Automate / l'agent Copilot. ## 7.4 Bonnes pratiques et pièges - Lisez toute architecture par : déclencheur · modèle · connexions · flux. - Une connexion = une autorisation explicite et bornée. - Appliquez le moindre privilège. - Préférez les standards (connecteurs, MCP) au sur-mesure fragile. **Mini-exercice 7.A.** Citez un point de rupture possible de la connexion vers Dynamics 365 et comment s'en prémunir. *(Corrigé en annexe D.)* ------------------------------------------------------------------------ ### Ch.8 — Exemple travaillé : architecture connectée Banque Méridienne ## 8.1 Le schéma `[Déclencheur] Nouvel e-mail Outlook (webhook M365) -> [Modèle IA] classe + résume l'e-mail -> [Connecteur Dynamics 365] crée une tâche (écriture bornée : créer uniquement) -> [Connecteur Teams] notifie l'agent (écriture : message)` ## 8.2 Tableau connexion → autorisation → risque | Connexion | Type | Flux | Autorisation requise | Risque principal | |----|----|----|----|----| | Outlook (M365) | Connecteur | Lecture | Lire les e-mails de la boîte dédiée | Accès trop large à d'autres boîtes | | Dynamics 365 | Connecteur | Écriture | Créer une tâche (pas supprimer) | Création de tâches erronées / en masse | | Teams | Connecteur | Écriture | Poster un message dans un canal | Notifications intempestives / fuite d'info | | Identité | Entra (OAuth) | — | Compte de service à droits minimaux | Compte sur-privilégié = clé passe-partout | ## 8.3 Note sur MCP > Aujourd'hui : trois connecteurs Power Platform distincts. Demain : un serveur MCP exposant « lire e-mail », « créer tâche », « notifier » de façon standard — moins de code d'intégration, moindre dépendance à un connecteur précis, et un seul point à sécuriser. > > **Pourquoi cet exemple est bon.** Les 4 éléments sont identifiés ; chaque connexion a une autorisation **bornée** et un risque ; le moindre privilège est appliqué (créer ≠ supprimer) ; l'apport de MCP est expliqué. ------------------------------------------------------------------------ ## Section 4 — Livrable & évaluation ### Ch.9 — Votre livrable ## 9.1 Consigne Produisez un **schéma d'architecture connectée** du cas Banque Méridienne (déclencheur, modèle, chaque connexion avec son type API/connecteur/MCP, sens des flux) **et** un tableau « connexion → autorisation requise → risque ». ## 9.2 Grille de notation (sur 20 — seuil : 14/20) | Critère | Points | |-----------------------------------------------------|--------| | Schéma : déclencheur, modèle, connexions distingués | 6 | | Sens des flux (lecture/écriture) précisé | 3 | | Tableau autorisation + risque par connexion | 5 | | Moindre privilège appliqué (autorisations bornées) | 3 | | Intérêt de MCP expliqué en une phrase | 3 | ## 9.3 Checklist avant de déposer - \[ \] Mon schéma distingue déclencheur, modèle et connexions. - \[ \] Le sens des flux est indiqué pour chaque connexion. - \[ \] Chaque connexion a une autorisation **et** un risque. - \[ \] Les autorisations sont bornées (moindre privilège). - \[ \] J'explique l'apport de MCP en une phrase. Déposez votre schéma sur le canal Teams (ou portfolio) avant J+2. ------------------------------------------------------------------------ ### Ch.10 — Auto-évaluation ## 10.1 Quiz (seuil : 4 bonnes réponses sur 5) 1. Quelle est la différence entre une API et un connecteur ? 2. Qu'apporte MCP par rapport à un connecteur propriétaire ? 3. Pourquoi chaque connexion est-elle un risque de sécurité ? 4. Qu'est-ce qu'un webhook / déclencheur ? 5. Qu'est-ce que le principe du moindre privilège ? Répondez par vous-même, **puis** vérifiez avec l'**annexe D**. ## 10.2 Auto-positionnement Reportez votre niveau sur la grille d'auto-évaluation, ligne « Protocoles et intégration ». ------------------------------------------------------------------------ ### Ch.11 — Points de vigilance : les pièges fréquents de ce module Avant de continuer, prenez 2 minutes pour vérifier les 3 confusions les plus fréquentes sur ce module — même après un score correct au quiz, elles reviennent souvent dans la pratique. | Piège fréquent | Pourquoi c'est trompeur | Comment corriger | |----|----|----| | Confondre **API** et **connecteur** | Les deux notions se ressemblent mais ne jouent pas le même rôle dans l'architecture | Pensez à la métaphore de la prise : brute (API), adaptateur (connecteur), universelle (protocole standard) | | Oublier les **autorisations** | Une connexion mal cadrée ouvre un accès plus large que nécessaire | Chaque connexion est une porte — elle doit toujours avoir une autorisation bornée | | Ne pas distinguer **lecture** et **écriture** | Les deux paraissent équivalentes mais n'ont pas le même niveau de risque | L'écriture (envoyer, supprimer) est toujours plus risquée que la lecture | Si l'une de ces confusions vous parle, revisitez **Ch.4 — Concepts et vocabulaire clés** ou **Ch.6 — Démonstration commentée** avant de passer au module suivant. ### Ch.12 — Questions fréquentes (FAQ) **« Dois-je savoir coder une API ? »** Non. Vous devez savoir *lire* une architecture et raisonner sur les connexions et les autorisations. Le code est l'affaire des spécialistes Power Platform que vous saurez piloter. **« MCP est-il déjà utilisable ? »** C'est un standard récent en plein essor. Retenez le principe (prise universelle) ; en attendant sa généralisation, les connecteurs Power Platform font le travail. **« Pourquoi tant insister sur les autorisations ? »** Parce qu'une intégration mal bornée est la première cause d'incident de sécurité. Une connexion donne un pouvoir ; le moindre privilège limite les dégâts en cas de problème. **« Le client a peur que “l'IA accède à tout”. »** C'est l'occasion de rassurer : on ne branche que le strict nécessaire, chaque accès est tracé et borné. C'est exactement la posture de sécurité (Module 9). ------------------------------------------------------------------------ ### Ch.13 — Pour aller plus loin - Reprenez une intégration de **votre** quotidien (ex. un flux Power Automate) et lisez-la avec la grille déclencheur/modèle/connexions/flux. - Pour chaque connexion, demandez-vous : autorisation strictement nécessaire ? bornée ? - Suivez l'actualité de **MCP** : c'est un standard qui va structurer le métier d'intégration. **Et ensuite — Module 8 :** vous concevez une **chaîne de traitement agentique** de bout en bout — l'aboutissement du palier Avant-garde, où tout ce que vous avez appris se combine en un workflow. ------------------------------------------------------------------------ ## Annexes (ressources) ### Mémo · Prompts · Glossaire · Corrigés - **API** = prise brute · **connecteur** = adaptateur prêt · **MCP** = prise universelle. - **Lire une architecture :** déclencheur · modèle · connexions · sens des flux. - **Chaque connexion = une porte** → autorisation explicite, bornée, moindre privilège. - **Lire ≠ écrire :** une écriture (envoyer, supprimer) est plus risquée qu'une lecture. - **Standards \> sur-mesure fragile.** # Annexe B — Vos prompts et fichiers du module Dans `prompts/` : `00_contexte_projet_claude.txt`, `01_lecture_architecture.txt`. Dans `scripts/` : `architecture_cas.txt` (schéma), `connecteur_pseudo_config.txt` (pseudo-config + tableau autorisations), `mcp_exemple.txt` (exemple MCP). À **lire**, pas à exécuter. # Annexe C — Glossaire express | Terme | En une phrase | |-----------------------|-------------------------------------------------| | API | Porte standardisée entre deux logiciels | | Connecteur | Adaptateur prêt à l'emploi vers une application | | MCP | Prise universelle modèle ↔ outils | | Webhook / déclencheur | Un événement lance une action | | OAuth / Entra | Qui a le droit d'accéder à quoi | | Moindre privilège | Ne donner que le strict nécessaire | # Annexe D — Corrigés **Mini-exercice 5.A.** Les deux autorisations : (1) **lire** les nouveaux tickets ; (2) **écrire** (créer une tâche) dans le CRM. La plus sensible est l'**écriture** : elle modifie le système et peut créer des données erronées ; elle doit être bornée (créer uniquement, pas supprimer). **Mini-exercice 7.A (exemple).** Point de rupture : un **changement de version de l'API Dynamics** ou un **quota dépassé** peut casser la création de tâches. Prémunition : surveiller les notifications de version, prévoir une gestion d'erreur (réessai, alerte) et un repli (mettre l'e-mail en file d'attente). **Quiz — corrigé.** 1. L'API est la porte brute (adaptateur à configurer) ; le connecteur est un adaptateur prêt à l'emploi vers une application précise. 2. MCP standardise l'accès aux outils (« prise universelle »), réduisant le coût d'intégration et la dépendance à un connecteur propriétaire. 3. Parce qu'elle donne un accès (lire/écrire) : mal bornée, elle expose des données ou permet des actions non souhaitées. 4. Un mécanisme par lequel un événement (nouvel e-mail, ticket) déclenche automatiquement une action. 5. Ne donner à chaque connexion que les droits strictement nécessaires, pour limiter les dégâts en cas de problème.