Avant d'ouvrir des connecteurs MCP à votre Chief of Staff IA, créez un registre de compétences approuvées

Quand on parle de risque IA à un dirigeant, il pense au modèle. Est-ce que Claude ou GPT va halluciner, est-ce qu'il va inventer un chiffre dans une note de board. C'est une vraie question, mais ce n'est plus là que se joue le danger opérationnel.

Le risque, aujourd'hui, c'est la chaîne d'outils branchée derrière le modèle. Le protocole MCP — le standard introduit par Anthropic et désormais adopté par OpenAI, Cursor et Copilot — permet de connecter un agent IA à vos outils métier et à vos données via un protocole unifié. C'est précisément ce qui rend un Chief of Staff IA utile: il touche à votre Gmail, votre HubSpot, votre Linear, votre Stripe.

C'est aussi ce qui le rend dangereux. Parce que MCP, par conception, n'impose aucune sécurité au niveau du protocole. Tous les contrôles doivent être posés à la couche applicative et à la couche gouvernance. Le protocole ouvre la porte; c'est à vous de décider qui passe, pour faire quoi, et comment vous coupez l'accès si ça dérape.

Brancher un agent sur vos outils sans encadrement, c'est donner à un stagiaire le trousseau de clés maître de l'organisation. Il peut, par accident ou non, accéder à des données sensibles, déclencher des actions non autorisées, et propager une erreur à grande échelle.

Un registre de compétences, ce n'est pas un document de politique interne rangé dans un dossier Notion. C'est un catalogue structuré et gouverné des compétences que l'IA a le droit d'exécuter — depuis la simple requête de données jusqu'à l'automatisation de workflow complexe — chacune avec des permissions définies, un versionnement et une piste d'audit.

Dans l'écosystème MCP, ça prend souvent la forme d'un MCP Registry: une couche qui gère le cycle de vie, la découvrabilité et la gouvernance des serveurs MCP et des outils qu'ils exposent.

Les attributs qui comptent vraiment, dans mon expérience à regarder des déploiements réels:

• Une gouvernance centralisée. Une source de vérité unique pour toutes les compétences accessibles à l'IA, avec une propriété claire et une gestion des changements. Pas dix listes éparpillées entre l'IT et chaque chef d'équipe.
• Des permissions granulaires. On précise quel agent peut utiliser quelle compétence, et sous quelles conditions. "Lire les deals HubSpot" et "modifier le statut d'un deal" ne sont pas la même autorisation.
• Un contrôle de version. On suit les changements dans le temps, on peut revenir en arrière, on peut auditer. Une compétence, ça se traite comme un composant logiciel.
• Une intégration au cycle de développement. Le registre est branché au SDLC pour une validation et une amélioration continues.

La logique est simple: on ne traite pas une compétence IA comme une fonctionnalité gadget. On la traite comme un composant en production.

L'erreur que je vois revenir le plus souvent: on branche d'abord, on gouverne ensuite. On ouvre les connecteurs en pilote, ça marche, l'équipe est enthousiaste, et la gouvernance devient un chantier de rattrapage qu'on ne finit jamais.

C'est l'inverse qu'il faut faire. Le registre est un prérequis, pas une finition.

Trois raisons concrètes. D'abord la conformité. Avec l'EU AI Act et la pression croissante sur la gouvernance IA, une organisation doit démontrer non seulement des contrôles techniques, mais aussi des processus auditables qui définissent quelles compétences et quelles actions un agent peut exécuter. Un registre fournit cet enregistrement clair et révisable des capacités autorisées.

Ensuite l'intégrité opérationnelle. Le registre garantit que seules des actions validées et pertinentes pour le métier sont exposées à l'IA. Ça réduit le risque qu'un workflow critique soit perturbé par accident — votre pipeline Pipedrive, vos relances de facturation Stripe, vos tickets Linear.

Enfin, les chiffres parlent. Les organisations dotées d'un registre de compétences centralisé rapportent jusqu'à 60 % d'actions IA non autorisées en moins par rapport à celles qui n'en ont pas. Et l'onboarding standardisé de nouvelles compétences réduit les délais d'intégration de 30 à 50 %. Gouverner d'abord, ce n'est pas freiner l'adoption — c'est l'accélérer proprement.

Prenons un cas concret. Votre Chief of Staff IA est branché sur Gmail, votre calendrier, HubSpot et Slack. Vous voulez qu'il trie votre boîte, qu'il prépare vos briefs de réunion, qu'il relance les fils qui tombent.

Sans registre, il a accès à tout. Il peut lire chaque email, modifier chaque deal, envoyer un message Slack à n'importe qui en votre nom. Le jour où une compétence mal définie déclenche un envoi groupé non voulu à votre liste de prospects HubSpot, vous découvrez le problème après coup, sans piste pour comprendre ce qui s'est passé.

Avec un registre, vous définissez précisément le périmètre. "Lire et classer les emails Gmail": autorisé. "Rédiger des brouillons de réponse": autorisé, mais l'envoi reste sous validation humaine explicite. "Mettre à jour une fiche de contact HubSpot": autorisé pour certains champs. "Modifier le statut d'un deal ou supprimer un enregistrement": non exposé, ou sous double validation.

Les actions sensibles exigent une validation humaine explicite. C'est le principe du moindre privilège appliqué à votre assistant: on accorde le minimum nécessaire, et on étend au fur et à mesure que la confiance se construit.

C'est exactement la frontière entre un vrai Chief of Staff et un gestionnaire de tâches. Un bon Chief of Staff sait ce qu'il a le droit de décider seul et ce qui doit remonter. Un registre de compétences, c'est cette frontière, écrite et révocable.

Voici la séquence que je recommande avant tout déploiement MCP en direction.

Le diagnostic. On cartographie les intégrations MCP existantes et prévues. On identifie les processus métier et les données critiques exposés au risque. On évalue les pratiques de gestion des compétences déjà en place.

La conception du registre. On définit la taxonomie des compétences — granularité, catégories, propriété. On établit les structures de gouvernance: workflows d'approbation, attribution des rôles. Et c'est un travail transverse, pas un projet IT en silo. On engage les propriétaires métier, l'IT, la sécurité et les utilisateurs finaux pour définir l'ensemble des compétences critiques, sûres et utiles.

Le durcissement sécurité. On impose une authentification robuste — OAuth 2.1 — et une autorisation pour chaque connecteur. On met en place des journaux d'audit et une supervision en temps réel. On définit les procédures d'escalade et de réponse aux incidents.

Le déploiement contrôlé. On pilote le registre avec un nombre limité de compétences et d'utilisateurs. On collecte les retours, on affine. Puis on étend progressivement à tous les connecteurs et agents.

L'amélioration continue. On gère le cycle de vie comme pour un composant logiciel classique: onboarding (valider avant d'exposer), monitoring (suivre usage, performance, incidents), retrait (décommissionner les compétences obsolètes ou risquées de façon contrôlée).

Le fil rouge: une compétence n'arrive jamais en production sans avoir été testée en sandbox, versionnée, et rendue révocable instantanément.

Trois écueils à éviter, parce que je les vois tout le temps.

Le premier, c'est de trop compter sur les contrôles techniques. Comme MCP n'embarque aucune sécurité native, la gouvernance et la supervision humaine ne sont pas négociables. Un OAuth bien configuré ne remplace pas un humain qui valide les actions sensibles.

Le deuxième, c'est de négliger les compétences humaines. Plusieurs études de leadership le martèlent: la maîtrise technique doit être complétée par de solides compétences humaines et managériales pour garantir un déploiement IA responsable. Le registre est un outil; il faut quelqu'un qui sache l'utiliser et arbitrer.

Le troisième, c'est d'ignorer la conduite du changement. Une implémentation réussie exige l'adhésion de tous, pas seulement de l'IT.

Ma recommandation pratique: commencez par les compétences à fort impact et à risque maîtrisé. Itérez vite, en méthode agile, à partir des retours du terrain. Et investissez dans la formation, côté technique comme côté métier.

C'est exactement la philosophie qu'on porte chez Moments. Un Chief of Staff IA qui touche à votre stack n'a de valeur que s'il est encadré — sinon vous échangez un gain de temps contre une dette de risque que vous paierez plus tard. La gouvernance des connecteurs n'est pas l'ennemie de la vitesse. C'est ce qui vous permet d'aller vite sans vous brûler.