Comment construire votre assistant personnel IA étape par étape avec Claude Code, MCP et un bot Telegram (tutoriel 2026)

Par l'équipe de Kiwop · Agence Digitale spécialisée en Développement Logiciel et Intelligence Artificielle appliquée pour clients mondiaux en Europe et aux États-Unis · Publié le 19 avril 2026 · Dernière mise à jour : 19 avril 2026

TL;DR — Tutoriel étape par étape pour monter votre assistant personnel IA sur Claude Code MCP comme stack de base : quatre canaux (IMAP, Gmail, Slack, Telegram), briefings automatiques à 08h00 et 19h00, bot bidirectionnel et commandes slash. Environ 500 lignes de Python, zéro dépendance payante au-delà de l'abonnement Claude Max x20. Setup complet en 60-90 minutes en suivant les étapes.

Ceci est le second article de la série sur le PA de Kiwop. Le premier, D'OpenClaw à PA avec Claude Code et MCP, explique pourquoi nous l'avons construit après le changement de politique d'Anthropic du 4 avril 2026. Ce tutoriel montre comment nous l'avons construit, avec le code réel que nous avons en production depuis deux semaines. À la fin, vous aurez un assistant personnel IA fonctionnel sur votre machine, avec la même architecture que nous utilisons chaque jour dans l'agence. Le dépôt de référence est disponible sur https://github.com/purroy/majordomo.

Ce n'est pas une démo jouet. Il traite du courrier de production, un vrai agenda, des messages Telegram depuis le mobile et des briefings qui atterrissent à 08h00 et 19h00 sans intervention humaine. La philosophie est minimaliste à dessein : chaque pièce fait une seule chose, la colle entre les pièces, c'est Unix, et les secrets ne touchent jamais le disque en clair.

Ce que vous allez construire

À la fin du tutoriel, votre PA aura quatre canaux opérationnels et une architecture délibérément simple.

Les quatre canaux actifs du PA sont :

• Courrier IMAP/SMTP propre : pour la boîte mail corporate de votre domaine (mail.votreentreprise.com), lue avec des scripts Python sur la bibliothèque standard de Python. Lecture, triage, rédaction et envoi avec confirmation explicite.
• Google Workspace (Gmail + Calendar + Drive) : à travers les serveurs MCP officiels — vous pouvez ajouter d'autres similaires comme Outlook/Microsoft 365 si votre organisation l'utilise.
• Slack : DM et mentions, via le serveur MCP officiel de Slack pour Claude.
• Telegram : un bot bidirectionnel qui est à la fois canal de sortie (briefings) et d'entrée (vous parlez au PA depuis le mobile).

Le stack technique se compose de quatre couches. Claude Code comme moteur conversationnel. Des connecteurs MCP pour tout ce qui dispose d'un officiel (Google + Slack). Des scripts Python propres pour les trous que MCP ne couvre pas (IMAP et Telegram). Et launchd (sur macOS) ou systemd/Task Scheduler (sur Linux/Windows) pour le démarrage et les déclencheurs programmés.

Le coût marginal réel est zéro sur l'abonnement Claude Max x20 que vous payez déjà pour le développement. Les ~500 lignes de Python sont à vous — aucune dépendance installable, uniquement la bibliothèque standard. Il n'y a pas de backend, pas de base de données, pas de Docker. Tout l'état persistant vit dans des fichiers locaux et dans le trousseau du système d'exploitation.

À haut niveau, l'architecture suit trois principes qu'il convient d'expliciter avant de plonger dans le code. Le premier est que Claude Code est le moteur mais n'est pas propriétaire de l'état : vos prompts sont dans des fichiers Markdown versionnables dans votre propre dépôt, vos secrets sont dans le trousseau du système, vos briefings sont des fichiers sur disque. Si demain vous vouliez changer de moteur, il suffirait de remplacer les appels à claude --print par une autre CLI équivalente. Le deuxième est que MCP fait le gros du travail quand il existe un serveur officiel (Google, Slack) et que vous n'écrivez du code que lorsqu'il n'y en a pas (IMAP, Telegram). Le troisième est que la sécurité vit dans trois couches indépendantes — OAuth du MCP, Keychain de macOS et règle de confirmation dans les prompts — de sorte que compromettre l'une ne compromet pas le système.

Prérequis et coût réel

Avant de commencer, vérifiez que vous avez ce qu'il faut. Le tutoriel suppose macOS parce que c'est ce que nous utilisons, mais il y a une section à la fin sur comment le porter sous Linux ou Windows.

Exigences de compte et d'abonnement :

• Claude Max x20 d'Anthropic : l'abonnement "for power users", environ 200 dollars/mois. Claude Code est inclus et constitue le moteur du PA.
• Compte Google Workspace avec les permissions pour autoriser Gmail, Calendar et Drive via OAuth.
• Workspace Slack où vous avez un compte (pas besoin d'être admin pour le MCP de lecture de vos propres DM et mentions).
• Un domaine de messagerie sur IMAP si votre boîte principale n'est pas Gmail (optionnel — si tout votre courrier est Gmail, sautez l'Étape 3).
• Compte Telegram (gratuit) pour créer le bot via @BotFather.

Exigences système :

• macOS 14+ avec Homebrew installé (pour le flux de base du tutoriel).
• Python 3.11+ (fourni avec macOS récent ; sinon, brew install [email protected]).
• CLI Claude Code installé : npm i -g @anthropic-ai/claude-code ou via brew.
• Terminal avec permissions Full Disk Access si vous voulez que launchd puisse exécuter les briefings sans demander d'autorisation répétée.

Coût mensuel projeté, détail honnête :

Le point clé : le coût marginal du PA est nul si vous avez déjà Claude Max. Si vous ne l'avez pas et que vous l'achèteriez uniquement pour le PA, le calcul change — vous devriez évaluer si le gain de temps vous compense 200 dollars/mois. Pour toute personne qui utilise déjà Claude Code en développement, la réponse est en général oui de manière triviale.

Le temps estimé pour compléter le tutoriel depuis zéro, en comptant les OAuth et le débogage inévitable, est de 60 à 90 minutes. Si vous ne voulez que les trois premiers canaux (sans Telegram ni briefings programmés), vous descendez à 30-40 minutes.

Étape 1 : structure de base du projet

Le PA vit dans un répertoire propre en dehors de tout autre projet. La première décision est où le placer. Nous utilisons ~/Dev/PA par convention — remplacez-le si vous préférez un autre chemin. Le dépôt de référence complet est disponible sur https://github.com/purroy/majordomo — utilisez-le si vous vous perdez à une étape.

Le .gitignore doit exclure tout ce qui contient des données personnelles — briefings, brouillons de courrier, état du bot :

Maintenant le fichier le plus important du dépôt : CLAUDE.md. Il définit la persona de l'assistant, la langue par défaut, et la règle de confirmation qui est le cœur de la sécurité du PA.

La règle de confirmation est non négociable. Elle distingue un PA que vous pouvez laisser entre les mains d'un modèle de langage de celui qui va vous envoyer un courriel embarrassant quand il interprétera mal un "oui" d'il y a deux tours. Nous l'avons testée pendant tout mars sans un seul faux positif.

Commit initial :

Étape 2 : connecter les serveurs MCP

MCP ([Model Context Protocol](https://modelcontextprotocol.io/specification/2025-11-25)) est le standard ouvert qu'Anthropic a publié fin 2024 pour que les modèles de langage se connectent à des outils externes de manière uniforme. Un serveur MCP est un processus qui expose un ensemble de fonctions (lire des courriels, rechercher des fichiers, envoyer des messages) via un protocole commun ; un client MCP (comme Claude Code) le lance et consomme ces fonctions comme si elles étaient ses propres outils. Si vous voulez approfondir pourquoi MCP est la pièce qui débloque les agents IA en 2026, nous avons une analyse plus large dans WebMCP : votre site web préparé pour les agents IA.

Pour le PA nous activons quatre serveurs MCP officiels, tous les quatre publiés par Anthropic/Claude ou par les fournisseurs eux-mêmes :

• Gmail MCP : lecture, recherche et composition de courriels.
• Google Calendar MCP : agenda, création et modification d'événements.
• Google Drive MCP : recherche et lecture de fichiers.
• Slack MCP : lecture des DM, canaux et envoi avec confirmation.

La façon la plus simple de les configurer est à travers l'interface de Claude Code. Depuis la racine du projet (~/Dev/PA), lancez :

Dans la session interactive de Claude Code, ajoutez les serveurs MCP avec la commande /mcp add pour chacun. La commande lancera le flux OAuth correspondant dans le navigateur — autorisez avec le compte que vous voulez que le PA utilise, pas nécessairement votre compte personnel principal.

Sécurité du flux OAuth. Un aspect clé : les serveurs MCP officiels utilisent OAuth du navigateur, pas des identifiants sur disque. Votre refresh_token est conservé par le serveur MCP dans ses propres stockages chiffrés, pas par le PA. Cela signifie que si quelqu'un vole votre .claude/ ou votre dépôt, il n'obtient pas l'accès à votre Gmail — il devrait en plus compromettre le stockage du serveur MCP et, en dernière instance, votre Keychain macOS. La surface d'attaque reste circonscrite.

Une fois les quatre autorisés, vérifiez que Claude Code les détecte :

Vous devriez voir les outils disponibles groupés par service : mcp__claude_ai_Gmail__search, mcp__claude_ai_Google_Calendar__list_events, etc. La nomenclature suit le motif mcp__<server>__<tool>.

À ce stade, vous pouvez déjà demander au PA « qu'est-ce que j'ai aujourd'hui au calendrier ? » ou « cherche dans Drive le contrat avec le client X » et cela fonctionne. Ce qui manque, ce sont les deux canaux que MCP ne couvre pas bien : le courrier IMAP corporate et Telegram.

Étape 3 : scripts Python pour IMAP et Keychain

Si tout votre courrier est sur Gmail, cette étape est optionnelle. Si, comme nous, la boîte principale tourne sur un serveur IMAP propre (mail.kiwop.com dans notre cas), il faut écrire le pont.

L'architecture des scripts est délibérément petite. Un module interne _mail.py avec la logique commune (connexion IMAP, parsing, SMTP), et trois commandes minimales que le PA peut invoquer :

• mail_fetch.py : liste les UID récents ou non lus sous forme de JSON.
• mail_read.py : lit le corps complet d'un UID (sans le marquer comme lu — utilise BODY.PEEK).
• mail_send.py : envoie un courriel ou le sauvegarde comme brouillon.

Règle d'or sur les identifiants. Ne stockez jamais le mot de passe IMAP dans un fichier du repo ni dans une variable d'environnement persistante type ~/.zshrc. Le risque n'est pas théorique : chaque fois que vous partagez un script, faites un commit avec .env tracké ou installez une extension VS Code qui lit votre environnement, vous exposez des secrets. Sur macOS nous avons Keychain, un trousseau chiffré du système d'exploitation accessible via la commande security. Les scripts lisent l'identifiant à la volée quand ils en ont besoin et ne l'écrivent jamais sur disque.

D'abord, stockez les identifiants dans Keychain :

Les ports habituels : 993 pour IMAP sur SSL et 587 pour SMTP avec STARTTLS. Si votre fournisseur utilise SMTPS implicite, changez pour 465.

Maintenant le helper shell qui lit et écrit dans Keychain. Nous l'appelons scripts/keychain.sh :

L'équivalent Python utilise subprocess pour invoquer security :

Le fallback vers une variable d'environnement est délibéré : quand vous porterez ceci sous Linux (systemd), là security n'existe pas et vous utiliserez des env vars exportées depuis l'unit file, lues depuis un fichier avec permissions 600.

Avec Keychain connecté, le mail_fetch.py devient clair. C'est un CLI qui imprime du JSON pour que Claude Code le parse facilement :

mail_send.py ajoute une sauvegarde importante : sans le flag --yes, il sauvegarde le message comme .eml dans drafts/ et ne l'envoie pas. Seulement avec --yes explicite il sort par SMTP. Cela applique la règle de confirmation du CLAUDE.md au niveau du code, pas seulement du prompt — même si le modèle enfreignait la règle, le script n'enverrait pas.

Détail critique sur `BODY.PEEK`. Quand le PA « lit » un courriel pour le trier, il ne doit pas le marquer comme lu. Si vous le marquez, vous perdez votre boîte d'en attente comme signal visuel dans le client de messagerie. Le flag IMAP qui définit \Seen est BODY[] ; celui qui ne le définit pas est BODY.PEEK[]. Utilisez-le toujours dans mail_read.py.

Étape 4 : bot Telegram avec session persistante

Le bot Telegram est la pièce la plus intéressante du PA car il inverse le flux : au lieu que vous ouvriez un terminal et écriviez à Claude, Claude reçoit vos messages depuis le mobile.

Le plan : un daemon Python qui fait du long polling contre l'API de Telegram (sans besoin de webhook public), et chaque message qu'il reçoit il le transfère à claude --print avec une session exécutée dans le dépôt du PA. Claude exécute le prompt avec tous ses outils (MCP + scripts Python) et retourne la réponse. Le daemon la formate pour Telegram et la renvoie au chat.

Créer le bot prend deux minutes. Ouvrez Telegram, parlez à @BotFather, lancez /newbot, donnez-lui un nom et un username. Il vous renvoie un token type 123456:ABC-XYZ_.... Stockez-le dans Keychain puis détectez votre chat_id (l'ID de la conversation 1-à-1 entre vous et le bot) :

Maintenant le daemon. Le squelette de telegram_bot.py est celui-ci :

Trois détails non évidents du design.

Premièrement, whitelist de `chat_id` : la variable allowed_chat est votre propre chat et tout message d'un autre chat_id est écarté silencieusement. Si quelqu'un découvre le username de votre bot et lui envoie des messages, il ne répond pas. C'est la barrière la plus simple mais la plus efficace contre l'abus.

Deuxièmement, `--permission-mode bypassPermissions` : le daemon tourne sans demander de confirmation pour exécuter des scripts du repo car il n'y a pas d'humain devant qui puisse répondre. La sécurité ne vient pas des prompts de Claude Code, elle vient de ce que (a) le daemon ne répond qu'au chat_id whitelisté, (b) le PA a la règle de confirmation dans CLAUDE.md, et (c) les scripts sensibles comme mail_send.py exigent --yes au niveau du code.

Troisièmement, sessions éphémères par message. Chaque ask_claude génère un nouveau session-id avec uuid.uuid4(). Cela signifie que le bot ne maintient pas de mémoire de conversation entre les messages — chaque requête part de zéro avec votre CLAUDE.md et vos commandes chargées. La mémoire « longue » (vos préférences, signature, contacts prioritaires) vit dans memory/ comme des fichiers que Claude lit au démarrage de chaque session, pas dans la session elle-même. Cela évite d'accumuler du contexte obsolète et rend le comportement très prévisible.

Markdown compatible avec Telegram. Telegram ne rend pas le Markdown style GitHub (il ne comprend pas les tableaux, ne comprend pas les liens avec crochets dans de nombreux contextes, interprète mal certains caractères). Au lieu de lutter avec parse_mode: MarkdownV2 — qui vous oblige à échapper tous les caractères spéciaux et se casse facilement — nous utilisons un petit convertisseur vers du texte brut lisible (md_to_telegram.py) qui élimine la syntaxe Markdown en préservant la structure.

Pour le tester avant launchd :

Ouvrez Telegram, écrivez /ping à votre bot. Il devrait répondre pong. Envoyez ensuite « quelle heure est-il ? » — il devrait vous répondre avec l'heure actuelle en consultant le système via la session de Claude. Félicitations : vous avez déjà un PA accessible depuis le mobile.

Étape 5 : briefings programmés avec launchd

[`launchd`](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html) est le gestionnaire de processus et de tâches programmées de macOS. C'est l'équivalent de cron + systemd combinés en un seul système. Chaque tâche se définit dans un fichier XML (.plist) qui dit à macOS quoi exécuter, quand, et quoi faire en cas d'échec.

Nous allons créer trois launchd jobs :

1. Bot Telegram comme daemon permanent (KeepAlive: true).
2. Briefing matinal chaque jour à 08h00.
3. Briefing du soir chaque jour à 19h00.

D'abord le wrapper scripts/run_briefing.sh qui lance Claude Code en mode non interactif pour générer le briefing :

Maintenant le .plist du briefing matinal. Sauvegardez-le dans scripts/launchd/com.kiwop.pa-briefing-morning.plist :

Clé importante : le `PATH` explicite dans EnvironmentVariables. launchd n'hérite pas de votre PATH du shell, donc si vous ne le lui passez pas, claude ne sera pas disponible et le briefing échouera silencieusement. Incluez /opt/homebrew/bin (Apple Silicon), /usr/local/bin (Intel) et ~/.local/bin (si vous avez installé Claude Code via pip --user).

Dupliquez le fichier pour celui du soir en changeant morning pour evening et l'heure à 19. Et créez celui du bot Telegram :

Le trio RunAtLoad: true + KeepAlive: true + ThrottleInterval: 15 signifie : démarre à l'ouverture de session, redémarre s'il plante, et n'essaie pas de redémarrer plus vite que toutes les 15 secondes (pour éviter les boucles d'échec).

Pour activer les trois .plist :

Pour vérifier qu'ils sont actifs :

Vous devriez voir les trois entrées avec PID (pour le bot, qui tourne en continu) ou avec - (pour les briefings, qui ne tournent qu'à leurs heures).

Pour déclencher un briefing manuellement sans attendre 08h00 (utile pour le test) :

Étape 6 : commandes slash /morning, /evening, /inbox, /reply

Les commandes slash de Claude Code vivent dans .claude/commands/ comme fichiers Markdown. Chaque fichier est un prompt template que Claude exécute quand vous invoquez /nom dans la session. C'est la façon la plus propre d'encapsuler des flux répétitifs sans répéter le même prompt long à chaque fois.

Pour le PA nous définissons quatre commandes minimales : /morning, /evening, /inbox, /reply. Voici l'exemple de .claude/commands/morning.md :

Bonjour — <date>

Agenda du jour

• HH:MM–HH:MM · Titre · (lieu / participants)

Courrier (N non lus)

🔥 Feu : [UID] Expéditeur — Objet · contexte ⚠ Important : [UID] ... À revoir : [UID] ... Bruit : N items

Slack

🔥 ... ⚠ ...

Priorités suggérées

1. ...
2. ...
3. ...

La commande /reply est particulièrement importante car elle applique la règle de confirmation :

Remarquez le motif : la commande fait respecter la règle de confirmation au niveau du prompt (étape 5), et le script fait respecter la règle au niveau de l'exécution (le --yes obligatoire dans mail_send.py). Double couche. Si le modèle « oublie » l'étape 5, le script n'envoie pas. Si quelqu'un modifie le script pour contourner --yes, le prompt exige toujours la confirmation. C'est la même philosophie de défense en profondeur que nous recommandons dans les projets d'intégration de LLMs pour toute action à effets irréversibles.

Les quatre commandes de base sont suffisantes pour 90 % de l'utilisation quotidienne. Vous pouvez en ajouter d'autres : /schedule (créer des réunions), /book (planifier depuis une invitation), /auth (diagnostic de l'état des MCP).

Étape 7 : tester le setup end-to-end

Avec tout monté, place à une ronde de tests complète avant de le considérer fonctionnel. Voici la checklist que nous utilisons chez Kiwop chaque fois que nous répliquons le setup sur une autre machine :

1. MCP authentifiés. Dans une session Claude Code depuis ~/Dev/PA :

Les quatre serveurs doivent apparaître avec des tools disponibles. Si l'un dit « not authenticated », répétez le OAuth.

2. Courrier IMAP fonctionnel. Depuis le terminal :

Il devrait renvoyer un JSON avec vos trois courriels non lus les plus récents. S'il échoue avec imaplib.IMAP4.error, vérifiez Keychain et les ports.

3. Briefing manuel. Depuis une session interactive de Claude Code :

Génère un briefing complet. Ne doit pas prendre plus de 60 secondes.

4. Bot Telegram bidirectionnel. Depuis Telegram, à votre bot :

• /ping → pong (immédiat)
• « qu'est-ce que j'ai aujourd'hui au calendrier ? » → réponse avec l'agenda réel (30-40 secondes)

5. Logs de launchd sans erreurs.

Le telegram_bot.err.log doit avoir une ligne « Bot up. Allowed chat=... ». S'il y a un FATAL: secret read failed, vérifiez que Keychain a les items PA-telegram-bot-token et PA-telegram-chat-id.

6. Test à froid du briefing programmé.

Il doit avoir généré le briefing du jour et poussé une copie vers votre Telegram. Si Telegram ne reçoit pas, vérifiez les identifiants PA-telegram-* dans Keychain.

Problèmes courants et comment les diagnostiquer :

Une fois les six points de la checklist passés, le PA est prêt pour un usage quotidien. À partir d'ici tout est affinage : ajouter memory/ avec vos préférences de style, ajouter plus de commandes slash selon les flux que vous détectez répétitifs, ajuster les prompts de morning.md et evening.md à l'output exact qui vous est le plus utile.

Conseil pratique sur les sept premiers jours. Après l'avoir monté, le PA va faire des choses sous-optimales jusqu'à ce que vous découvriez ce qui lui manque comme contexte sur vous. Nous recommandons de commencer en mode « lecture seule » la première semaine : laissez-le générer des briefings, laissez-le trier l'inbox, mais n'utilisez pas encore /reply ni ne confirmez d'actions d'écriture. Pendant cette semaine vous détecterez des patterns à corriger — « il classe mal les courriels de ce client car il ne sait pas qu'il est VIP », « il résume trop les messages courts de Slack », « il marque comme bruit des choses qui pour moi sont importantes ». Toutes ces corrections vont dans memory/triage_rules.md et dans le CLAUDE.md. À partir du jour sept ou huit, quand le triage est consistant à 85-90 %, vous pouvez ouvrir l'usage d'écriture avec /reply et commencer à gagner du temps réel. Sauter cette phase de calibrage est l'erreur la plus courante et la cause principale d'abandons dans notre échantillon de personnes que nous avons aidées à le monter.

Variantes et scaling : Linux, Windows et tourner 24/7

Le tutoriel est écrit sur macOS parce que c'est là où nous travaillons, mais l'architecture est portable. Les quatre ajustements principaux :

Gestionnaire de processus.

Un unit systemd pour le bot Telegram sous Linux serait approximativement (~/.config/systemd/user/pa-telegram.service) :

Activation : systemctl --user daemon-reload && systemctl --user enable --now pa-telegram.service.

Stockage de secrets.

Le fallback aux variables d'environnement dans un fichier avec permissions 600 fonctionne sur les trois plateformes et est le dénominateur commun si vous voulez un code unique pour tous les systèmes.

launchd vs systemd, comparaison honnête :

Le faire tourner 24/7 sur un serveur distant ? C'est viable et nous l'avons testé. Le motif : un petit VPS Linux avec systemd faisant tourner le bot Telegram et les briefings programmés, plus une connexion IMAP/SMTP à la boîte, plus le CLI Claude Code authentifié avec votre compte Anthropic. Avantages : le PA répond même si votre portable est éteint. Inconvénients : le OAuth des serveurs MCP est plus délicat sans navigateur local (vous devrez faire le flux initial sur votre machine et copier le refresh token), et toute mise à jour du CLI Claude Code requiert SSH et déploiement. Pour la plupart des professionnels qui utilisent le Mac au quotidien, le maintenir en local est l'option avec le meilleur rapport simplicité/utilité.

Le saut vers un PA multi-utilisateur (un qui serve une équipe) n'est pas une variante du même tutoriel — c'est un SaaS et cela requiert des décisions architecturales très différentes (multi-tenancy, authentification, isolation de sessions). Si cela vous intéresse d'explorer cette voie, nous l'abordons dans les projets de développement d'agents IA sur mesure.

Deux extensions que nous avons vu fonctionner en pratique quand le PA de base est déjà stable. La première est un memory/ peuplé de fichiers Markdown que Claude charge à chaque session : un triage_rules.md avec vos critères exacts pour classer le courrier, un writing_style.md avec des exemples de courriels écrits par vous pour que les brouillons sonnent comme votre voix, un vip_contacts.md avec les adresses qui ne doivent jamais tomber en « bruit ». La seconde est un watcher de courrier en arrière-plan (un daemon similaire au bot Telegram, mais qui au lieu d'écouter Telegram écoute votre boîte IMAP) qui déclenche une notification quand un courriel marqué comme feu selon vos règles arrive — utile pour des flux où le briefing de 08h00 ne suffit pas. Les deux extensions se construisent avec la même philosophie que le reste : scripts courts, secrets dans Keychain, sessions éphémères de Claude Code.

Questions fréquentes

Combien coûte réellement la construction de ce PA ?

Si vous avez déjà Claude Max x20 (environ 200 USD/mois), le coût marginal du PA est nul. Les serveurs MCP sont gratuits, le bot Telegram tourne sur votre Mac sans hosting, et les scripts Python ne nécessitent pas de dépendances payantes. Si vous n'avez pas Claude Max, le calcul change : les 200 USD/mois sont l'investissement fixe. Le temps de construction en suivant ce tutoriel est de 60-90 minutes.

Est-il sûr de donner accès à mon courrier et calendrier à un PA construit ainsi ?

Oui, avec les conditions explicites suivantes. Premièrement, les serveurs MCP officiels s'authentifient par OAuth sans stocker votre mot de passe sur disque — le token vit dans un stockage chiffré du serveur MCP lui-même. Deuxièmement, les identifiants IMAP/SMTP sont dans le Keychain macOS (trousseau du système d'exploitation, chiffré), jamais dans des fichiers en clair. Troisièmement, le bot Telegram ne répond qu'au chat_id whitelisté et la règle de confirmation obligatoire dans CLAUDE.md empêche les actions d'écriture sans « oui » explicite. La surface d'attaque reste très circonscrite, comparable à celle de n'importe quel client de messagerie de bureau.

Qu'en est-il de la confidentialité des données ? Est-ce qu'Anthropic entraîne ses modèles avec mes courriels ?

Anthropic déclare publiquement (politique à 2026) que les données envoyées par API et par Claude Code ne sont pas utilisées pour entraîner les modèles. Pour du contenu régulé (santé, juridique avec secret professionnel, financier confidentiel), il convient de revoir les conditions spécifiques en vigueur et d'envisager si un PA sur infrastructure propre est plus approprié — auquel cas une solution de RAG d'entreprise peut être l'alternative correcte.

Peut-on intégrer WhatsApp dans ce PA ?

À avril 2026 il n'existe pas de MCP officiel de WhatsApp. Il y a des bridges non officiels (Matrix, Beeper, l'API WhatsApp Business Cloud de Meta elle-même) qui peuvent être connectés comme canal additionnel, mais tous ont des caveats : les bridges non officiels peuvent violer les ToS de Meta et être instables, et la Business Cloud API requiert un compte commercial vérifié. Notre recommandation pragmatique est d'utiliser Telegram comme canal mobile primaire.

Ce PA peut-il servir plusieurs utilisateurs ?

Non, par conception. Un PA est single-user : ses identifiants, sa mémoire, ses préférences et son CLAUDE.md pointent vers une seule personne. Pour des scénarios multi-utilisateurs (une équipe qui partage un assistant commun) l'architecture correcte est un SaaS multi-tenant avec isolation des données par utilisateur — pas une copie du PA avec des variables partagées. C'est une conversation totalement différente.

Fonctionne-t-il sans connexion Internet ?

Non. Claude Code requiert une connexion pour consulter le modèle, les serveurs MCP utilisent des API en ligne (Google, Slack, Telegram), et IMAP/SMTP évidemment aussi. Le PA décrit ici est un client qui orchestre des services cloud — pas un modèle local. Si vous avez besoin d'opération offline, c'est une refonte complète avec un LLM local (Llama, Mistral) tournant sur ollama ou similaire, avec des restrictions de qualité et de performance notables.

Combien de temps prend le PA pour son premier briefing matinal ?

Le run_briefing.sh complet prend entre 40 et 90 secondes selon la quantité de courrier à trier. La partie la plus lente est le fetch IMAP avec --with-body (une connexion par UID), suivi du raisonnement du modèle sur le triage. Si votre boîte est très grande (>50 non lus), cela peut monter à 2-3 minutes. Si c'est la première exécution et que le MCP de Calendar se réchauffe encore, ajoutez 5-10 secondes supplémentaires.

Puis-je le personnaliser pour mon flux concret ?

Oui, et c'est la philosophie du projet. Les fichiers clés à toucher : CLAUDE.md (persona, ton, règles), .claude/commands/*.md (flux concrets), memory/ (préférences persistantes, signature, contacts VIP, règles de triage). Le code Python ne doit rarement être touché sauf pour ajouter des comptes IMAP additionnels ou intégrer un nouveau canal. Commencez avec le setup de base fonctionnel avant de personnaliser — il est moins coûteux d'apprendre où personnaliser quand vous voyez déjà ce qui vous est superflu et ce qui vous manque.

Conclusion : 60 minutes entre vous et votre premier PA opérationnel

Nous utilisons ce PA chez Kiwop depuis deux semaines et la conclusion la plus honnête que nous puissions écrire est que le saut de productivité réel ne vient pas du modèle — il vient du design minimaliste autour du modèle. Claude Code, Opus 4.7, les serveurs MCP : c'est la partie chère que vous ne construisez pas vous-même. Les ~500 lignes de Python, la poignée de fichiers Markdown, les trois .plist de launchd — voilà ce que vous faites, et c'est ce qui convertit les capacités du modèle en un assistant utile pour votre journée.

Ce tutoriel a couvert le chemin complet depuis un répertoire vide jusqu'à un PA opérationnel avec quatre canaux et des briefings programmés. Le code de référence que nous avons utilisé est publié sur https://github.com/purroy/majordomo sous une licence permissive — clonez, forkez, adaptez. Ce n'est pas la seule manière de construire un PA en 2026, mais c'en est une dont nous savons qu'elle fonctionne parce que nous l'utilisons chaque matin à 08h00 avant d'allumer le Mac du travail.

Si pendant que vous suiviez le tutoriel vous avez trouvé un trou où votre cas concret a besoin de plus que ce stack de base — intégrations sur mesure avec votre CRM, un canal Teams, un MCP propriétaire pour votre ERP, ou directement un assistant multi-utilisateur pour toute votre équipe — chez Kiwop nous construisons ces pièces dans le cadre de nos services de développement d'agents IA et conseil en IA. Notre point de départ est toujours le même : des couches fines, découplées, agnostiques au fournisseur. Il n'y a rien dans ce tutoriel que vous ne puissiez répliquer vous-même en un après-midi, mais si le temps est plus cher que le coût de l'externalisation, contactez notre équipe et nous le faisons avec vous.

Le PA que vous avez maintenant tournant sur votre Mac est à vous. Personne ne peut le couper du jour au lendemain. Et cela, en 2026, est la propriété la plus précieuse que puisse avoir un agent IA appliqué au travail quotidien.