Un assistant capable de lire vos mails, de créer des boîtes et de corriger le DNS peut vous rendre bien des services. Mais il peut aussi supprimer la mauvaise boîte après avoir mal compris votre demande.
La question essentielle d’un serveur MCP pour le mail n’est donc pas ce que l’agent sait faire, mais ce qui se passe lorsqu’il se trompe. Les permissions et les restrictions qui entourent le serveur déterminent une grande partie des conséquences. Les capacités du modèle ne suffisent pas.
Voici ce qu’est un serveur MCP, les tâches qu’il permet d’effectuer sur une plateforme de mail et les mesures qui réduisent les risques : séparer les jetons, limiter les permissions, confirmer les opérations destructrices et conserver un journal d’activité. Aucune ne garantit à elle seule la sécurité d’un fonctionnement autonome.
Qu’est-ce qu’un serveur MCP ?
Le Model Context Protocol définit une manière commune pour un client IA de découvrir et d’appeler les outils d’un système externe. Le serveur MCP publie les outils avec leur nom, leur description et le schéma de leurs arguments. Le client présente ces informations au modèle. Lorsque celui-ci choisit un outil, le client exécute l’appel et lui renvoie le résultat.
L’intérêt est de ne pas dépendre d’un seul client. Un même serveur peut fonctionner avec Claude Desktop, Claude Code, Cursor, Windsurf et d’autres applications compatibles. Il faut néanmoins vérifier le transport, l’autorisation et les fonctions prises en charge. Le protocole réduit le travail propre à chaque application, mais ne dispense pas de configurer la connexion.
Cette organisation convient bien à une plateforme de mail : de nombreuses opérations sont déjà accessibles par API. Le serveur MCP les décrit sous forme d’outils au-dessus de l’API REST. Les restrictions ne relèvent donc pas uniquement de l’agent : l’API, le serveur et l’intégration côté client doivent les appliquer.
Ce qu’un agent peut faire via le serveur MCP
La version décrite dans le texte d’origine propose plus de 200 outils, répartis à peu près comme suit. Les outils effectivement disponibles dépendent de la version, de la configuration, des permissions et de l’offre :
| Domaine | Exemples |
|---|---|
| Domaines et DNS | Ajouter des domaines, consulter les enregistrements nécessaires, lancer des contrôles DNS, appliquer les réglages via Cloudflare et relancer la configuration DKIM |
| Boîtes mail | Créer, lister, modifier, suspendre, changer les mots de passe, gérer les alias et les transferts et restaurer depuis la corbeille |
| Messages | Lire, rechercher, envoyer, répondre, transférer, préparer des brouillons, programmer des envois, déplacer, marquer et signaler un spam ou un message légitime |
| Dossiers et règles | Créer et renommer des dossiers, gérer les filtres, charger du code Sieve et régler la réponse automatique |
| Contacts et calendrier | Créer et modifier des contacts et des groupes, importer et exporter, créer et modifier des événements |
| Drive | Parcourir, importer, déplacer, partager, effectuer des opérations groupées et gérer les mots de passe des appareils de synchronisation |
| Migration | Tester les connexions, lancer les imports, suivre la progression par dossier, annuler et réessayer |
| Délivrabilité | Consulter les synthèses des envois et des livraisons, ainsi que les rejets par destinataire avec la réponse SMTP du serveur de réception |
| Identité visuelle | Configurer la marque blanche par domaine, obtenir les CNAME nécessaires et vérifier le DNS |
| Support et facturation | Consulter les tickets, les factures et l’état de l’offre |
Certains outils évitent de communiquer des secrets au modèle. Les réglages d’un client mail peuvent être récupérés sous forme structurée : serveurs, ports et noms d’utilisateur pour Outlook, sans le mot de passe de la boîte. Des profils de configuration Apple Mail sont aussi disponibles. L’agent peut ainsi aider un salarié à configurer son mail sans connaître son mot de passe. D’autres outils peuvent manipuler des identifiants sensibles : vérifiez séparément leurs permissions et leurs réponses.
Pourquoi séparer les jetons
Pour les jetons statiques, une décision importante consiste à séparer l’accès à l’infrastructure de l’accès au contenu des messages. Les connexions OAuth doivent aussi respecter les permissions accordées lors de l’autorisation.
Jeton d’administration (tm_live_) | Jeton de messages (tm_msg_) | |
|---|---|---|
| Accès | Domaines, boîtes, DNS, transferts, facturation et migrations, dans les limites des permissions accordées | Contenu des messages, dossiers, pièces jointes, contacts et calendrier, dans les limites des permissions accordées |
| Ne permet pas directement | Lire le corps d’un message via l’API de messages | Créer une boîte ou modifier le DNS |
| Usage habituel | Script de création de ressources ou assistant d’administration | Assistant qui trie la boîte de réception |
La séparation limite l’étendue d’une erreur. Une automatisation qui crée les boîtes des nouveaux salariés n’a pas besoin de lire leurs mails. Un assistant qui prépare des réponses n’a pas besoin de supprimer un domaine. En revanche, des permissions administratives étendues permettant de gérer les jetons de messages, les mots de passe ou les transferts peuvent ouvrir un accès indirect au mail. Limitez les pouvoirs réels, pas seulement le type de jeton.
La fuite d’un jeton administratif reste donc un incident grave. Il ne lit pas directement le corps des messages, mais les conséquences dépendent de ce qu’il peut modifier ou créer.
Permissions générales et détaillées
Dans chaque type de jeton, les permissions restreignent davantage l’accès. OAuth combine des groupes compréhensibles par l’utilisateur avec des contrôles plus précis dans l’API.
Le schéma d’origine affichait cinq grands groupes de permissions sur l’écran de consentement : mail:read, mail:write, mail:admin, messages:read et messages:send. Une liste courte est plus facile à évaluer que des dizaines de détails. Des permissions supplémentaires existent désormais. Lisez donc l’écran réellement présenté : gérer les brouillons et envoyer des messages sont notamment des capacités distinctes.
L’API contrôle les permissions détaillées pour chaque opération. Lire les réglages de transfert et les modifier nécessite, par exemple, des autorisations différentes. Des groupes simples au moment d’accorder l’accès ne doivent pas remplacer les contrôles précis lors de l’exécution.
Les permissions dépendent aussi de l’offre et des droits actuels du compte. Dans la description d’origine, Nano se limite à la vérification d’adresses, Starter propose la lecture et la vérification, tandis que Pro et Agency ouvrent davantage d’opérations. Les droits actuels peuvent inclure des capacités supplémentaires, notamment pour Drive ou des services souscrits séparément. Vérifiez les permissions disponibles à la création du jeton plutôt que de vous fier au nom de l’offre.
En pratique, créez un jeton par automatisation, avec les permissions minimales nécessaires. Ne le réutilisez pas pour des tâches différentes. Un jeton partagé entre plusieurs scripts cumule leurs pouvoirs et empêche d’identifier facilement le script responsable d’une action. Consultez les permissions et les portées de l’API.
Confirmer les opérations destructrices
Une réponse assurée du modèle ne signifie pas qu’il a choisi la bonne ressource. S’y fier est particulièrement dangereux lorsqu’il s’agit de supprimer.
Pour supprimer une boîte, le premier appel crée une intention de suppression qui ne supprime rien. Elle décrit ce qui se produirait après confirmation et fournit des informations sur la ressource et les risques, notamment les éléments liés et les migrations actives. Elle expire par défaut après dix minutes. N’appliquez pas cette procédure aux domaines par supposition : leur suppression suit un autre mécanisme.
L’appel suivant confirme l’intention et exige un en-tête explicite de confirmation. Examiner les conséquences entre les appels est utile, mais ne garantit pas la protection : un agent disposant des deux outils peut effectuer les deux étapes. Si une validation humaine est nécessaire, organisez une approbation indépendante et restreignez l’accès à la confirmation.
La boîte supprimée passe d’abord dans la corbeille. Elle peut être restaurée pendant la durée de conservation, mais plus après sa purge définitive. Les domaines n’ont pas de corbeille équivalente. L’API refuse de supprimer un domaine avec des boîtes actives et exige de régler les relations avec les domaines alias. La suppression d’un compte a ses propres conséquences et ne devient pas réversible grâce à la procédure des boîtes.
L’envoi de messages et les migrations disposent de restrictions spécifiques. Consultez les protections et les intentions de suppression.
Idempotence et nouvelles tentatives
Après une expiration du délai d’attente, l’agent peut renouveler la requête, comme tout client. Si l’opération a réussi et que seule la réponse a été perdue, une nouvelle tentative naïve peut créer la ressource une seconde fois.
Pour les opérations concernées qui modifient des données, l’API utilise une clé d’idempotence. Renvoyez la même requête avec la même clé tant que le résultat est conservé. L’API peut alors retourner la réponse enregistrée au lieu de répéter l’opération. Modifier les données avec la même clé provoque un conflit : le mécanisme n’est pas une garantie illimitée contre les doublons. Cela compte aussi bien pour la création d’une boîte que pour l’envoi d’un message. Un envoi en double donne une mauvaise impression au client.
Les limites peuvent s’appliquer au jeton, au compte ou à la boîte. En cas de rejet pour dépassement, le client doit respecter Retry-After et patienter. Les opérations destructrices ont des limites plus strictes. Elles freinent une boucle erronée, mais n’annulent pas les dégâts des actions déjà exécutées.
Le rôle du journal d’audit
Le tableau de bord affiche des événements d’audit avec le jeton, l’opération, la ressource et la date. La durée de conservation par défaut est de 90 jours. N’en déduisez pas que chaque appel est enregistré : la couverture dépend de l’opération et des réglages, et les lectures de messages peuvent être journalisées par échantillonnage.
Le journal ne sert pas seulement aux rapports. Il aide à reconstituer les actions quand vous ne pouvez pas observer l’agent en permanence. Par exemple, retrouver qui a configuré un transfert vers une adresse inconnue. Il ne remplace toutefois pas les restrictions d’accès et ne contient pas nécessairement assez d’informations pour répondre à toute question.
Il aide aussi à repérer une activité inattendue d’un jeton. Révoquer un jeton particulier limite les futurs appels de cette automatisation. Les actions déjà réalisées et les autres identifiants encore actifs doivent être examinés séparément.
Des automatisations utiles
Les tâches les plus intéressantes sont souvent les plus ordinaires.
Arrivées et départs des salariés.Un nouvel arrivant a besoin d’une boîte, d’alias, de groupes et d’instructions de configuration. Un départ impose de retirer les accès et de décider du transfert et de l’archivage. L’automatisation aide à suivre une liste de contrôle, mais son résultat reste à vérifier. Elle ne garantit pas une exécution correcte à chaque fois.
Création des domaines clients d’une agence.Ajouter le domaine, configurer le DNS, créer les boîtes, vérifier et produire un rapport. Ces étapes répétitives se prêtent à l’automatisation dans les limites des permissions convenues.
Suivi de la délivrabilité.Récupérer les rejets avec la réponse SMTP du serveur destinataire, regrouper les causes et relever les erreurs probables de configuration. Une synthèse hebdomadaire peut signaler un problème d’enregistrement SPF, sans garantir la détection de tous les défauts de livraison.
Supervision des migrations.Lancer un lot, suivre la progression par dossier, examiner les erreurs et produire un rapport de vérification. Une tâche terminée ne prouve pas que la copie est complète ; consultez la migration par lot.
Tri de la boîte de réception en lecture seule.L’agent peut résumer les messages et proposer des catégories. Ce jeton ne lui permet pas d’envoyer, mais pas non plus de modifier les marques sans permission d’écriture. Pour appliquer catégories et marques, n’accordez que les permissions nécessaires, sans droit d’envoi.
Ce qu’il faut éviter
N’accordez pas toutes les permissions à un jeton pour simplifier la configuration. Il pourrait rester actif des années plus tard avec des pouvoirs excessifs.
Ne laissez pas l’agent envoyer seul à des destinataires externes avant d’avoir évalué ses brouillons. Préparer un brouillon et envoyer nécessitent des permissions distinctes, même si certains groupes généraux peuvent réunir les deux. Vérifiez les permissions effectivement accordées.
Ne conservez pas de jetons dans le dépôt.Utilisez des variables d’environnement ou un gestionnaire de secrets exclu de Git. Vérifiez aussi que les secrets n’apparaissent pas dans les journaux ou les réponses des outils.
N’ignorez pas le journal d’audit.Consultez-le dès la première semaine. Comparez les événements aux actions attendues et identifiez les opérations qui ne sont pas enregistrées.
N’automatisez pas la suppression des domaines.Ils n’ont pas de corbeille. Ces opérations doivent faire intervenir une personne qui vérifie la ressource et les conséquences, plutôt que de reprendre la confirmation du modèle.
Questions fréquentes
Quels clients IA fonctionnent avec le serveur MCP ?
Les applications compatibles MCP, notamment Claude Desktop, Claude Code, Cursor et Windsurf. Le protocole simplifie l’intégration, mais il faut vérifier le transport, l’autorisation, la version du client et la configuration de la connexion.
L’agent peut-il lire mes mails ?
La lecture directe via l’API de messages nécessite un jeton de messages avec permission de lecture, ou une autorisation OAuth adaptée. Un jeton administratif ne lit pas directement le corps des messages. En revanche, des permissions étendues pour créer des jetons, changer des mots de passe ou régler les transferts peuvent ouvrir un accès indirect. Ne les accordez pas sans nécessité.
Qu’est-ce qui empêche l’agent de supprimer une ressource importante ?
Pour les boîtes, une intention de suppression expire par défaut après dix minutes, puis une confirmation exige un en-tête explicite. La boîte est restaurable depuis la corbeille avant sa purge définitive. Cela ne garantit pas une validation humaine. La suppression des domaines suit un autre mécanisme, sans corbeille, et ne devrait pas être autonome.
Le serveur MCP transmet-il mes mails au fournisseur d’IA ?
Les données obtenues par l’agent peuvent être transmises au modèle utilisé, selon le client et son lieu d’exécution. Avec un modèle cloud, cela peut impliquer un transfert à un fournisseur externe ; le traitement local est différent. Limitez l’accès, vérifiez les conditions de traitement et les voies indirectes d’accès au mail. Interdire la lecture directe ne suffit pas à garantir l’absence de fuite.
Faut-il un jeton distinct pour les opérations sur les messages ?
Les jetons statiques utilisent des types distincts pour l’infrastructure et les messages. Avec OAuth, les permissions accordées et les jetons créés pour la connexion entrent aussi en jeu. La séparation réduit le risque, mais ne rend pas sûres toutes les permissions administratives étendues.
Que se passe-t-il si l’agent atteint une limite ?
La requête est rejetée. Le client doit respecter Retry-After et réessayer plus tard si cela convient. Les limites des opérations destructrices sont plus strictes, mais ne garantissent pas qu’une boucle erronée s’arrête avant de provoquer des dégâts.
Puis-je voir ce que l’agent a fait la semaine dernière ?
Le journal du tableau de bord présente les événements enregistrés, le jeton et la ressource concernée. La conservation par défaut est de 90 jours. Tenez compte de la couverture et de l’échantillonnage de certaines lectures : tous les appels ne figurent pas nécessairement dans le journal.
L’accès au serveur MCP coûte-t-il un supplément ?
La description d’origine inclut l’API et MCP dans l’offre : Nano vise la vérification d’adresses, Starter propose des opérations limitées, Pro et Agency élargissent les capacités. Vérifiez les droits actuels du compte et les permissions disponibles. Les services supplémentaires, les crédits consommés et l’utilisation d’un modèle externe peuvent être facturés séparément.
