Claude Code comme back-office : connecter Drive, Gmail et Trello pour piloter sa boîte

Trois outils, trois versions de la vérité

Dans une petite boîte, la réalité est éclatée en trois endroits. Le Drive contient les documents — ce qu'on a produit. Gmail contient les engagements — ce qu'on a dit, promis, envoyé, reçu. Trello contient les intentions — ce qu'on pense être en train de faire. Et ces trois versions divergent, toujours.

Google Drive : rclone plutôt que MCP

Premier réflexe : chercher un serveur MCP pour Drive. Mauvais réflexe. Pour de la gestion documentaire en masse (déplacer, renommer, synchroniser des centaines de fichiers), un protocole conversationnel est l'outil le moins adapté du monde. rclone fait ça depuis dix ans, en server-side, avec des transferts qui ne passent jamais par votre machine.

rclone config   # remote "societe" de type drive, OAuth dans le navigateur

Le piège du My Drive vide

Après l'authentification :

rclone lsd societe:
# ... rien.

De quoi conclure que le compte n'a accès à rien. Grosse erreur : les documents vivent ailleurs, dans deux espaces que rclone n'affiche pas par défaut.

# Les dossiers partagés avec le compte
rclone lsd societe: --drive-shared-with-me

# Les Drives partagés (anciens "Team Drives")
rclone backend drives societe:
# → [{"id": "0AxXXXXXXXXXXXX", "name": "DOCUMENTS"}]

# Et pour travailler dedans, la syntaxe connection string :
rclone tree "societe,team_drive=0AxXXXXXXXXXXXX:" --level 2

Dans une boîte qui utilise les Drives partagés (et toutes devraient), le My Drive de chacun est un désert. Conclure « le Drive est inaccessible » à ce stade, c'est passer à côté de tout.

Réorganiser 107 fichiers sans en télécharger un seul

L'inventaire n'était pas joli : 60 % des fichiers entassés dans un dossier « à trier », des doublons, quatre versions du même document stratégique, et des noms avec des retours à la ligne dans le nom de fichier (merci les exports Google Docs).

La réorganisation s'est faite en pur server-side : un script qui mappe chaque fichier vers une arborescence propre, en kebab-case, avec rclone moveto. 107 déplacements, zéro octet téléchargé. Et comme l'arborescence du Drive est désormais le miroir exact du dépôt git local, la synchronisation tient en une ligne :

rclone copy "societe,team_drive=0AxXXXXXXXXXXXX:" ./repo-docs/ -u

Le -u (update) n'est pas décoratif : il ne remplace jamais un fichier local plus récent. Quand quelqu'un édite un document dans Word, c'est lui qui a raison, pas le Drive.

L'erreur à ne pas faire : rclone link

Pratique, rclone link renvoie une URL de partage. Sauf que cette URL fonctionne parce que la commande vient de créer une permission « toute personne disposant du lien » sur le fichier. Un partage public, silencieux, sur un document interne. Repéré une heure plus tard grâce au badge « Externes » dans l'interface Drive.

La réparation : suppression de la permission via l'API, puis audit complet des permissions sur les 209 éléments du Drive (l'API renvoie du 403 de rate-limiting au bout de ~100 appels, prévoir un backoff). Verdict : un seul autre fichier exposé publiquement, un partage historique oublié. Révoqué aussi.

Règle gravée depuis dans la mémoire de Claude : jamais de rclone link, jamais de permission anyone. Pour référencer un fichier, on construit l'URL depuis son ID — elle ne fonctionnera que pour les membres du Drive.

Gmail : le MCP officiel de Google… et son piège

Google a sorti son serveur MCP Gmail officiel (https://gmailmcp.googleapis.com/mcp/v1). Sur le papier c'est la voie royale : OAuth propre, outils de recherche et de brouillons, pas de code tiers avec un accès complet à la boîte.

La configuration côté GCP : activer gmail.googleapis.com et gmailmcp.googleapis.com, créer un client OAuth « Web application » avec une URI de redirection en port fixe (Claude Code utilise un port aléatoire par défaut, Google exige une correspondance exacte) :

claude mcp add --transport http \
  --client-id VOTRE_CLIENT_ID --client-secret \
  --callback-port 8765 \
  gmail https://gmailmcp.googleapis.com/mcp/v1

Authentification via /mcp, le navigateur s'ouvre, tout va bien. Et puis :

The caller does not have permission

Sur tous les outils. Même list_labels.

Le scope qui empoisonne tout

Le serveur MCP de Google annonce cinq scopes, dont gmail.metadata. Et l'API Gmail a une règle non négociable : dès qu'un token contient ce scope, le paramètre de recherche q et le format FULL sont refusés. Même si le token contient aussi gmail.readonly qui les autorise. Le scope le plus restrictif gagne, et le token est empoisonné à la racine.

Le pinning de scopes dans la config Claude Code (oauth.scopes, disponible depuis la v2.1.64) ne sauve pas la mise : la session en cours l'ignore et redemande les cinq scopes.

La solution qui marche : court-circuiter le MCP et faire son propre flow OAuth avec les scopes minimaux. Quarante lignes de Python — un listener HTTP local sur le port de callback, l'URL d'autorisation avec scope=gmail.readonly et rien d'autre, access_type=offline pour obtenir un refresh token, échange du code, sauvegarde.

url = "https://accounts.google.com/o/oauth2/v2/auth?" + urlencode({
    "client_id": CLIENT_ID,
    "redirect_uri": "http://localhost:8765/callback",
    "response_type": "code",
    "scope": "https://www.googleapis.com/auth/gmail.readonly",
    "access_type": "offline",
    "prompt": "consent",
})

Le token qui en sort fait exactement ce qu'on lui demande : recherche, lecture complète, pièces jointes, en appels REST directs. Un second token avec gmail.compose en plus ouvre la création de brouillons, et le refresh token rend le tout permanent.

Ce que Gmail révèle quand on le fouille vraiment

Les pièces jointes. Une requête has:attachment filename:pdf OR filename:docx a inventorié 46 messages contenant des documents, dont 38 fichiers absents du Drive : études payées à des cabinets, dossiers types envoyés par des financeurs, conventions signées. Tout dormait dans des fils de discussion.

Les brouillons fantômes. En vérifiant l'avancement d'un dossier de subvention, un détail troublant sur le mail « Dépôt du dossier complet » : labelIds: ['DRAFT']. Pas de destinataire, pas de pièces jointes. Le dossier que tout le monde croyait déposé n'était jamais parti.

Les bounces. La requête qui vaut de l'or :

from:(mailer-daemon OR postmaster) OR subject:("Delivery Status Notification")

21 résultats. Vingt-et-un mails jamais arrivés, dont personne n'avait traité les notifications d'échec. Parmi eux : une demande de prêt d'honneur (adresse erronée), un premier contact avec un centre de référence hospitalier (domaine migré), une demande de bourse (boîte générique morte). Des démarches comptées comme faites qui n'avaient jamais existé pour le destinataire.

Un mail envoyé n'est pas un mail arrivé. Ce contrôle est maintenant systématique dans chaque audit.

Trello : le plus simple des trois

Pas de MCP officiel (Atlassian n'a rien sorti pour Trello), mais le serveur communautaire de delorenj est solide :

claude mcp add trello -s user \
  -e TRELLO_API_KEY=xxx -e TRELLO_TOKEN=xxx \
  -e TRELLO_BOARD_ID=xxxxxxxx \
  -- npx -y @delorenj/mcp-server-trello

La clé API se génère sur trello.com/power-ups/admin (créer un Power-Up, générer le token à la main). Pas d'OAuth : le token donne accès à tous les boards du compte.

L'audit de cohérence : là où les trois sources se croisent

Le board affichait 9 cartes « en cours » et 15 « en attente ». La boîte mail racontait une autre histoire. La logique de vérification, carte par carte :

Résultat :

• 4 cartes « en cours » dont l'action était terminée depuis des semaines
• 3 cartes « en attente » en réalité débloquées : l'attestation attendue était arrivée, le contact avait répondu
• 1 carte passée à « terminé »… à tort, le mail ayant bouncé. Corrigée dans l'autre sens dès que le contrôle des bounces est entré dans la boucle
• 4 cartes manquantes pour des événements bien réels : un contrat signé via Docusign, une réunion à préparer, le fameux brouillon jamais envoyé

Chaque déplacement de carte s'accompagne d'un commentaire sourcé (« mail envoyé le X à Y, réponse reçue le Z ») et chaque carte créée par Claude porte un préfixe [CLAUDE]. On sait toujours qui a écrit quoi.

Les règles qui rendent le système vivable

Brancher une IA sur la boîte mail et les documents d'une société ne se fait pas sans garde-fous :

1. Aucun envoi automatique. Claude rédige des brouillons, point. Les mails attendent qu'un humain les relise et appuie sur le bouton.
2. Aucun document public. Pas de rclone link, pas de permission anyone, audit des permissions à chaque passage.
3. Traçabilité partout. Préfixe [CLAUDE] sur les cartes, commentaires sourcés, mention de la date de création automatique.
4. Scopes minimaux. gmail.readonly pour lire, gmail.compose pour les brouillons. Pas de gmail.send. Ce qu'un token n'autorise pas ne peut pas déraper, même sur une hallucination.
5. La mémoire capitalise. Chaque piège résolu (le scope empoisonné, le My Drive vide, les adresses mortes) est consigné dans la mémoire persistante de Claude Code.

Le dernier point est le plus sous-estimé. La différence entre un gadget et un outil de gestion, c'est qu'au troisième audit, Claude connaît les adresses qui bounce, la procédure de sync, les conventions de nommage et les règles de la maison. Il ne redécouvre pas, il vérifie.

Ce que ça change

Une matinée de mise en place, dont les deux tiers à débugger OAuth. Et depuis : « synchronise le Drive », « vois-tu des mails non délivrés ? », « l'avancement du board est-il cohérent ? », « pré-rédige les relances ». Des phrases qui produisent du travail vérifiable en quelques minutes.

Le plus précieux n'est pas le temps gagné sur le rangement, mais ce que le croisement des sources fait remonter : les trous entre ce qu'on croit et ce qui est. Le dossier en brouillon, les 21 bounces, les cartes mensongères — aucun de ces problèmes n'était visible depuis l'intérieur d'un seul outil. Il fallait être assis au milieu.