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.

Je m'en suis rendu compte en branchant Claude Code sur les trois outils de la startup e-santé que je co-pilote. L'idée de départ était modeste : ranger des fichiers. Je n'ai pas rangé que des fichiers. Un dossier de subvention que tout le monde croyait déposé ? Resté en brouillon dans Gmail. Sans destinataire, sans pièces jointes, depuis trois jours. Une relance à un financeur ? Jamais arrivée : l'adresse était morte et le bounce dormait dans la boîte de réception depuis des semaines, au milieu des newsletters.

Voilà comment chaque brique se branche, avec les pièges rencontrés. Et il y en a eu.

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

Premier vrai mur, et il est vicieux. Après l'authentification :

rclone lsd societe:
# ... rien.

Rien. J'ai failli conclure que le compte n'avait accès à rien et passer à autre chose. 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. Si vous concluez "le Drive est inaccessible" à ce stade, vous passez à côté de tout.

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

Une fois l'accès posé, Claude a fait l'inventaire. 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 là pour décorer : il ne remplace jamais un fichier local plus récent. Quand quelqu'un est en train d'éditer un document dans Word, c'est lui qui a raison. Pas le Drive.

L'erreur que j'ai faite : rclone link

Confession. Pour partager un document à mon associée, j'ai utilisé rclone link. Pratique, ça renvoie une URL.

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. Je m'en suis aperçu une heure plus tard, grâce au badge "Externes" dans l'interface Drive. Une heure pendant laquelle un document de la boîte était lisible par quiconque avait l'URL. Personne ne l'avait, on a vérifié. La sueur froide, elle, était bien réelle.

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évoyez 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, et c'est exactement ce qu'on veut.

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 qui se balade 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 genre de message qui ne vous donne strictement rien à vous mettre sous la dent.

Le scope qui empoisonne tout

Deux heures de debug. Deux heures que je ne reverrai pas, alors voilà la réponse toute cuite : 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. Le token est empoisonné à la racine.

J'ai tenté le pinning de scopes dans la config Claude Code (oauth.scopes, disponible depuis la v2.1.64). La session en cours l'a ignoré et a redemandé les cinq scopes. Tant pis.

La solution qui marche : court-circuiter le MCP et faire son propre flow OAuth avec les scopes minimaux. C'est 40 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 : tout fonctionne 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

C'est là que ça devient intéressant. Trois découvertes, du plus banal au plus gênant.

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

Les brouillons fantômes. En vérifiant l'avancement d'un dossier de subvention, Claude a remarqué 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 (le domaine de l'hôpital avait migré), une demande de bourse (boîte générique morte). Des démarches comptées comme faites qui n'avaient juste... 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. C'est brutal mais c'est comme ça.

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

Le board de suivi 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 des courses :

• 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 avait bounce. 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. Avec des checklists dont les étapes déjà accomplies sont cochées, le board affiche enfin une progression qui correspond à la réalité.

Les règles qui rendent le système vivable

Brancher une IA sur la boîte mail et les documents d'une société, ça ne se fait pas sans garde-fous. Les nôtres ont été forgés en une journée d'incidents plus ou moins évités :

1. Aucun envoi automatique. Claude rédige des brouillons, point. Les mails attendent dans le dossier Brouillons 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, concrètement

Une matinée de mise en place, dont les deux tiers à débugger OAuth, soyons honnêtes. 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. C'est 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.

Trois connecteurs, des scopes serrés, des règles claires, une mémoire qui capitalise. Le reste, c'est de la conversation.