Comment connecter Notion, GitHub et Gmail aux tâches d’un agent IA

Depuis Compte → Connecter vos applications, reliez Google Drive, Gmail, Notion, GitHub, Linear, Slack, Fireflies ou Granola. Un agent connecté obtient alors quatre nouveaux outils MCP (list_connections, search_context, read_context et save_context) qui lui permettent de trouver et de lire le vrai contexte avant de traiter une tâche, au lieu que vous colliez vous-même un cahier des charges ou un fil de discussion dans les notes de la tâche. La lecture passe avant tout, par conception : un agent peut ramener un document Notion ou une issue GitHub dans son travail et enregistrer un résultat terminé dans Google Drive, mais il ne peut pas envoyer vos e-mails, publier dans Slack ni ouvrir une issue dans l’outil de suivi de qui que ce soit. Ce ne sont pas des choses qu’on lui demande simplement de ne pas faire : il en est tout bonnement incapable.

Depuis quelles applications un agent peut-il récupérer du contexte ?

• Google Drive : lecture et écriture de fichiers, limitées à drive.file, c’est-à-dire les fichiers créés par cette application, plus ceux que vous lui avez explicitement confiés, jamais tout votre Drive.
• Gmail : recherche et lecture des e-mails, en lecture seule. Google classe cette autorisation comme restreinte. Elle n’apparaît donc qu’une fois que le déploiement de Done a franchi l’étape de vérification supplémentaire qui la débloque.
• Notion : lecture et écriture de pages. L’OAuth de Notion n’a aucun paramètre de portée. Ce qu’un agent peut atteindre, ce sont les pages que vous avez choisies à l’installation, pas quelque chose que Done demande.
• GitHub : lecture et écriture de fichiers et d’issues dans les dépôts que vous autorisez. L’autorisation repo, c’est tout ou rien pour les dépôts privés : GitHub ne propose pas d’autorisation en lecture seule plus étroite pour eux.
• Linear : lecture et écriture d’issues. Les jetons d’accès durent 24 heures. Done renouvelle la connexion en arrière-plan pour qu’elle ne devienne pas caduque sans que vous le remarquiez.
• Slack : recherche en lecture seule dans l’historique des canaux et des groupes que vous autorisez, en réutilisant l’application Slack dont se servent déjà les notifications d’approbation de Done.
• Fireflies : transcriptions de réunions en lecture seule, grâce à une clé bearer que vous collez depuis les réglages de Fireflies (offre Pro de Fireflies ou supérieure).
• Granola : transcriptions de réunions en lecture seule, de la même façon, grâce à une clé issue des réglages de Granola (offre Business ou Enterprise de Granola).

Comment un agent utilise-t-il concrètement une application connectée dans une tâche ?

list_connections est le point de départ. Il indique ce qui est connecté, vers quel compte pointe chaque connexion, et quelles capacités cette connexion détient exactement, ce qui peut être moins que ce que propose l’application si vous avez restreint l’écran de consentement au moment de la relier. Ensuite, search_context prend une requête et renvoie des résultats (un titre, un type parmi fichier, note, issue, message, transcription ou e-mail, un lien et une référence), jamais le contenu. read_context prend cette référence et renvoie le texte lui-même. En général, un agent cherche le cahier des charges ou le fil que mentionne une tâche, lit le résultat qui correspond, et travaille à partir de là au lieu de deviner d’après le seul titre de la tâche. S’il a produit quelque chose qui mérite d’être conservé, save_context l’écrit dans une connexion Drive dotée de files.write, et l’agent rend tout de même compte du résultat dans la tâche elle-même avec propose_completion ou complete_task, comme pour n’importe quelle autre exécution.

Que recherche réellement search_context ? Est-ce le texte intégral de tout ?

Non, et les différences comptent pour savoir ce qu’un agent peut s’attendre à trouver. Drive cherche dans les noms et le contenu des fichiers. La recherche GitHub ne couvre que les issues et les pull requests, pas le code : lire un fichier précis est un appel read_context avec sa propre référence (owner/repo:path), pas un résultat de recherche. Slack cherche dans les messages. Notion cherche dans les titres et le texte des pages. Fireflies et Granola ne cherchent que dans les titres des réunions : une phrase prononcée dans une transcription ne remontera donc pas, sauf si la réunion elle-même porte ce nom. Rien ici n’est un index unifié en texte intégral de toutes les applications connectées. Chaque fournisseur répond avec ce que sa propre API permet réellement.

Un agent connecté peut-il envoyer un e-mail, publier dans Slack ou ouvrir une issue à ma place ?

Non, et c’est voulu. Aucune capacité d’envoi d’e-mail ou de message n’est définie où que ce soit dans la couche des connecteurs. Un agent peut donc lire votre boîte de réception et vos canaux pour le contexte, mais il n’a aucun moyen d’envoyer depuis l’un ou l’autre. save_context est aussi plus limité que la liste des fournisseurs ne le laisse penser : c’est le seul outil d’écriture, et aujourd’hui seul l’adaptateur Google Drive implémente réellement l’écriture. Même une connexion GitHub ou Notion avec un accès en écriture accordé ne peut donc pas encore recevoir d’écriture par save_context. Un agent qui propose d’écrire à quelqu’un ou de publier un point d’étape décrit ce qu’un humain devrait faire ensuite, pas quelque chose qu’il peut exécuter ici.

Les applications connectées fonctionnent-elles avec un jeton limité à un espace de travail ou en lecture seule ?

Seul un jeton complet, sans restriction, peut les utiliser. Une connexion est un identifiant personnel lié à votre compte, pas à un espace de travail en particulier. list_connections, search_context, read_context et save_context sont donc refusés purement et simplement pour un jeton MCP limité à un espace de travail ou à un projet. C’est le même traitement que pour get_digest et les autres outils qui portent sur tout le compte et n’ont pas de sous-ensemble par tableau auquel se restreindre. Votre Gmail n’a pas de « tranche de cet espace de travail ». Plutôt que de le restreindre à moitié, Done refuse donc toute cette surface à un jeton plus étroit.

Faut-il une offre payante pour connecter une application ?

Pas du côté de Done : il n’y a aucune vérification d’offre nulle part, du panneau Compte jusqu’à search_context ou save_context. Deux des huit, Fireflies et Granola, peuvent exiger de leur côté une offre payante sur leur propre service avant de vous délivrer une clé d’API, mais ce sont leurs tarifs, pas ceux de Done. Les applications OAuth qui affichent réellement un bouton Connecter dans votre compte dépendent de la configuration : l’opérateur de Done doit avoir renseigné les identifiants de ce fournisseur sur ce déploiement. Une application non configurée le dit clairement, au lieu de proposer un bouton qui aboutit à la page d’erreur d’un autre service.