8 boîtes mail, 4 IA, un seul serveur MCP : retour d'expérience d'un dirigeant

Pendant des mois, mes IA ont été brillantes et à moitié aveugles. Capables de challenger un business plan en trois minutes, incapables de savoir ce qu'un client m'avait écrit mardi, si j'avais un créneau jeudi ou où se trouvait la dernière version d'un document.

Le problème venait de la plomberie. J'ai donc pris deux jours pour la refaire : un serveur MCP maison qui donne à mes quatre IA l'accès à mes 8 boîtes mail, avec les agendas et les Drive qui vont avec. Cet article montre comment c'est construit, ce que ça change au quotidien, ce que j'ai interdit, et la méthode pour faire pareil. Il ne remplace pas un tuto, mais vous saurez exactement quoi demander à un développeur, ou à votre IA.

Le problème : un compte par outil

Quand on porte plusieurs casquettes, on finit avec plusieurs identités numériques. Chez moi : la boîte d'Odessia, celle de ma holding, ma boîte perso, et une adresse par mission ou par partenaire, parce qu'un client qui vous confie un rôle de Fractional COO vous donne souvent une adresse chez lui. Total : 8 comptes, une partie sur Google Workspace ou Gmail, le reste en IMAP classique.

Derrière chaque compte Google, il y a aussi un agenda et un Drive. Les rendez-vous d'une mission sont dans l'agenda de la mission, les livrables dans le Drive du client. Le contexte d'un dossier est éclaté entre trois outils, sur un compte parmi huit.

Les connecteurs natifs de Claude ou de ChatGPT ont été un vrai progrès, mais dans mon usage ils me limitaient à un compte par outil. Mon IA voyait une boîte sur huit, et je copiais-collais le reste. Ce schéma résume la situation, avant et après.

MCP en deux minutes

MCP, pour Model Context Protocol, est un standard ouvert lancé par Anthropic fin 2024 et adopté depuis par l'essentiel de l'écosystème, OpenAI compris. Il définit une façon commune pour une IA de se brancher sur des outils et des données externes. L'analogie la plus juste reste la prise USB-C : on construit la prise une fois, et toutes les IA compatibles peuvent s'y brancher.

Trois notions suffisent pour comprendre le reste de l'article :

• Le client MCP, c'est l'application d'IA : Claude, ChatGPT, un agent comme Hermes ou OpenClaw.
• Le serveur MCP, c'est le programme que j'ai construit. Il fait le lien entre l'IA et les services réels (Gmail, IMAP, Google Agenda, Google Drive).
• Les outils, ce sont les actions que le serveur met à disposition, chacune avec un nom, une description et des paramètres. Par exemple « chercher des emails » ou « créer un brouillon ».

Au démarrage, l'IA lit la liste des outils et leurs descriptions. Ensuite, quand vous lui demandez quelque chose, elle choisit seule quel outil appeler et avec quels paramètres. Voici à quoi ressemble un appel réel, quand je demande de retrouver les échanges récents sur un sujet :

{
  "tool": "search_emails",
  "arguments": {
    "accounts": "all",
    "query": "comité mensuel newer_than:30d",
    "limit": 10
  }
}

Le serveur interroge les 8 boîtes en parallèle, fusionne les résultats et renvoie chaque email avec son compte d'origine. L'IA sait donc toujours d'où vient une information, ce qui compte au moment de répondre depuis la bonne adresse.

L'architecture

Le dispositif tient en cinq couches. Le schéma se lit de haut en bas, de la question posée à l'IA jusqu'aux boîtes mail.

Les clients IA

Claude et ChatGPT se connectent au serveur comme à un connecteur personnalisé, à partir d'une URL. Hermes et OpenClaw le déclarent dans leur configuration MCP. Une seule adresse pour les quatre.

Le tunnel Cloudflare

Le serveur tourne sur une machine Ubuntu chez moi. Plutôt que d'ouvrir un port sur ma box, j'utilise un tunnel Cloudflare : c'est la machine qui établit une connexion sortante vers Cloudflare, et le trafic redescend par ce canal. Rien n'est exposé directement sur internet, et je profite de la protection du réseau Cloudflare.

La passerelle authentifiée

Le tunnel n'arrive jamais directement sur le serveur MCP. Il arrive sur une passerelle qui vérifie l'authentification de chaque requête. Une requête qui n'est pas authentifiée s'arrête là. Le serveur MCP, lui, n'écoute qu'en local.

Le serveur MCP unifié

C'est le cœur du dispositif. Il tient un registre des comptes, chacun avec un identifiant court, et expose 23 outils. Chaque outil d'écriture exige qu'on lui dise explicitement sur quel compte agir. Les outils de recherche, eux, peuvent interroger un compte, plusieurs, ou tous.

Les connecteurs par type de compte

Tous les comptes ne se pilotent pas de la même façon, et c'est la partie la plus technique du projet. Les comptes Google passent par les API officielles de Gmail, d'Agenda et de Drive, avec une autorisation OAuth. Les comptes IMAP passent par le protocole IMAP standard, avec un mot de passe d'application. Les possibilités ne sont pas les mêmes, et le serveur l'expose clairement à l'IA grâce à un outil qui décrit les capacités de chaque compte.

Les 23 outils

Voici la liste complète, regroupée par famille. Elle dit beaucoup de choses, y compris par ce qui n'y figure pas.

Une requête, pas à pas

Pour rendre tout ça concret, voici ce qui se passe quand je tape une seule phrase : « Prépare mon comité de jeudi avec le client A. » Je n'indique ni compte, ni dossier, ni outil. L'IA enchaîne les appels seule.

Rien de tout ça n'est spectaculaire pris isolément. Mais c'est exactement le travail de recherche et de préparation qui grignote une journée de dirigeant, et que je fais désormais faire en une phrase.

Ce que ça change au quotidien

Les garde-fous

La décision la plus importante du projet n'a rien de technique. Mes IA peuvent lire, chercher, classer, rédiger des brouillons et déposer des fichiers. Elles ne peuvent pas envoyer un email, ni en supprimer un. Ces fonctions n'existent pas dans le serveur : même une IA qui se tromperait de bonne foi ne pourrait pas les déclencher.

Le raisonnement est simple. Une IA qui se trompe dans un brouillon, je le vois à la relecture. Une IA qui envoie un mail au mauvais destinataire, ou qui supprime un message qu'elle a jugé inutile, c'est irréversible. J'ai donc borné la marge d'erreur à ce que je peux rattraper. L'IA prépare le parapheur, je signe.

Le reste des règles découle de la même logique :

• Pas d'envoi, pas de suppression, pas de partage de fichiers, pas de modification d'agenda.
• Toute écriture exige un compte explicite. Le serveur ne devine jamais l'adresse d'expédition d'un brouillon.
• Chaque résultat de recherche porte son compte d'origine, pour éviter de répondre à un client depuis la mauvaise adresse.
• Si un compte ne répond pas, les autres continuent de fonctionner, et l'erreur est signalée compte par compte.
• Le serveur n'écoute qu'en local. Tout accès extérieur passe par le tunnel puis par la passerelle authentifiée.

La méthode, en six étapes

Si vous voulez reproduire le dispositif, ou le faire construire, voici l'ordre que je recommande. Le code est la partie la plus rapide : l'IA l'a écrit avec moi en grande partie. Les décisions, elles, vous reviennent.

1. 01Faire l'inventaire. Lister les comptes, leur type (Google ou IMAP), et ce dont vous avez besoin sur chacun : mails seulement, ou aussi agenda et Drive.
2. 02Ouvrir les accès. Pour les comptes Google, créer un projet dans la console Google Cloud, activer les API Gmail, Agenda et Drive, et autoriser chaque compte en OAuth avec les droits les plus réduits possibles. Pour les comptes IMAP, générer un mot de passe d'application.
3. 03Écrire la liste des outils avant d'écrire le code. Ce que l'IA aura le droit de faire, et surtout ce qu'elle n'aura jamais le droit de faire. C'est la décision qui conditionne tout le reste.
4. 04Construire un seul serveur avec un registre de comptes. Chaque outil prend un identifiant de compte en paramètre, et les recherches acceptent « tous les comptes ».
5. 05Héberger et exposer proprement. Une machine qui reste allumée (chez vous ou sur un petit serveur loué), un tunnel Cloudflare, une passerelle qui exige une authentification. Jamais le serveur en accès direct.
6. 06Brancher les clients IA. Ajouter l'URL comme connecteur personnalisé dans Claude et dans ChatGPT, et déclarer le serveur dans la configuration des agents comme Hermes ou OpenClaw. Puis tester chaque outil, compte par compte.

Est-ce que je le conseillerais à un dirigeant ?

Pas à la plupart. Si vous avez une seule boîte mail et un seul outil IA, les connecteurs natifs suffisent largement. Ils sont maintenus par l'éditeur, sécurisés par défaut, et ne vous demandent rien.

Un serveur maison a des coûts qu'on oublie de compter : deux jours de mise en place pour quelqu'un à l'aise avec la technique, davantage sinon, une machine qui doit rester allumée, des autorisations qui expirent et qu'il faut renouveler. Et surtout, la sécurité devient votre responsabilité, puisque vous ouvrez un accès à vos emails, ceux de vos clients compris.

En revanche, ça vaut largement l'effort si vous cochez plusieurs de ces cases :

• Vous gérez plusieurs entités, plusieurs mandats ou plusieurs missions, chacun avec son adresse.
• Vous utilisez plusieurs outils IA et vous ne voulez pas reconfigurer vos accès dans chacun.
• Une part importante de votre temps part dans la recherche d'information plutôt que dans la décision.
• Vous avez quelqu'un, en interne ou à l'extérieur, capable de maintenir le dispositif.

Le contexte, nouveau facteur limitant de l'IA

Ce projet m'a confirmé une conviction. Les modèles sont devenus assez bons pour l'essentiel des usages d'un dirigeant. Le facteur limitant, aujourd'hui, est l'accès au contexte : les mails, les agendas, les documents, les outils métier. Une IA moyenne qui voit tout votre dossier sera plus utile qu'une IA géniale qui n'en voit qu'un huitième.

Et la barrière technique s'est effondrée. Il y a deux ans, ce projet aurait demandé plusieurs semaines de développement. Il m'a pris deux jours. Reste à décider ce qu'on veut vraiment confier à ses outils, et ce qu'on garde.

C'est le genre de chantier que j'aborde avec les dirigeants que j'accompagne : partir de leurs flux réels, repérer où l'information se perd, et brancher l'IA là où elle retire vraiment de la friction, avec des garde-fous posés dès le départ.