Créer son AI Chief of Staff (simplement) avec Claude Code

En 2026, monter un Chief of Staff IA sur Telegram m'a pris 30 minutes avec un outil que j'utilise au quotidien. J'ai mis des mois à y arriver, non pas parce que c'est compliqué, mais parce que j'ai commencé par les mauvaises solutions. Cet article retrace ce chemin : les impasses, l'architecture qui tourne aujourd'hui en prod, les usages réels avec les frictions comprises, et un guide pour démarrer.

Je ne suis pas chercheur en IA. Je ne publie pas de papers. Je code des trucs pour moi le week-end et je dirige une boîte de conseil Produit et IA.

Mais depuis quelques mois, je suis obsédé par une idée simple : avoir un assistant IA qui tourne 24/7 depuis mon téléphone. Pas une session qu'on ouvre et qu'on ferme, mais un VRAI agent. Quelque chose qui répond quand je lui envoie un message Telegram depuis les transports, entre deux réunions, ou à 23h quand j'ai une tâche admin qui traîne.

J'ai mis des mois à y arriver - non pas parce que c'est compliqué, mais parce que j'ai beaucoup expérimenté et tâtonné. 

Cet article, c'est le retour d'expérience honnête de ce chemin, avec les erreurs, les impasses, et finalement la solution qui tourne en prod aujourd'hui. Et une tentative de casser quelques mythes qui commencent à m'agacer sur LinkedIn.

• Sur les "dizaines d'agents qui tournent la nuit"
• Ce qu'est vraiment un agent IA personnel
• Ce que j'ai essayé, et pourquoi ça n'a pas marché
• La solution : Claude Code + Telegram
• L'architecture, dans le détail
• Ce que fait l'agent aujourd'hui, frictions comprises
• Guide : 30 minutes pour démarrer
• Prochaines étapes
• Conclusion

J'ai "dix agents qui tournent la nuit"

On a tous vu ce post LinkedIn avec la photo du bureau à 2h du matin : "J'ai lancé 14 agents en parallèle cette nuit. Ils ont produit 3 mois de roadmap, refactorisé le backend et rédigé ma newsletter."

Vraiment fascinant... Si j'omet le fait que personnellement j'ai toujours du mal à comprendre l'utilité concrète de dizaines d'agents qui s'activent sans supervision humaine. À moins d'essayer de recoder HubSpot en une nuit, j'ai du mal à voir le cas d'usage personnel qui justifie cette complexité.

Il y a aussi une confusion sémantique qu'on ne démêle jamais assez. Quand vous utilisez Claude.ai ou ChatGPT aujourd'hui, vous interagissez déjà techniquement avec de multiples agents en coulisses. Des dizaines de modèles et de sous-systèmes sont sollicités à chaque requête. C'est masqué, et c'est très bien ainsi. De la même façon, quand Claude Code décide seul de lancer une recherche web ou d'appeler un outil MCP, il orchestre des comportements multi-agents, depuis une seule fenêtre de terminal.

Mon avis : pour 90% des cas d'usage personnels et professionnels, cette sophistication est superflue. Une seule session Claude Code bien configurée suffit. L'interaction reste simple.

C'est ça, la vraie ambition d'un Chief of Staff IA personnel. Pas 14 agents, mais un seul, bien contextualisé, connecté à vos vrais outils.

Ce qu'est vraiment un agent IA personnel

Dans la journée d'un CEO de PME, les sollicitations sont innombrables. Les projets s'accumulent, et une question revient sans cesse : qu'est-ce que je fais maintenant ? Qu'est-ce que je peux déléguer ? Qu'est-ce que je peux ignorer sans que ça me coûte quelque chose plus tard ?

C'est à la fois frustrant et chronophage.

L'idée derrière le "Chief of Staff IA personnel" est simple : avoir un assistant disponible 24/7 depuis son téléphone, capable d'exécuter des tâches concrètes, trier des emails, maintenir une liste de tâches, réserver un cours de sport, générer un PDF administratif, sans avoir besoin d'ouvrir un ordinateur. En somme, dépasser la session Claude.ai qu'on ouvre et ferme et mettre en place un processus qui tourne en permanence et qui répond sur Telegram quand on en a besoin. Un projet infiniment plus actionnable que le fantasme des 14 agents.

Ce que j'ai essayé, et pourquoi ça n'a pas marché

Voici un petit journal de bord honnête de mes trois tentatives : OpenClaw, agent codé from scratch, et finalement la bonne solution, celle que j'aurais dû tester en premier.

OpenClaw : le candidat idéal... sur le papier

Quand OpenClaw est apparu (le projet s'appelait encore Clawdbot, puis Moltbot), ça semblait être exactement ce que je cherchais. Un gateway open source qui connecte n'importe quel LLM à WhatsApp, Telegram, Discord et 20 autres apps. Sans compter un système de skills extensibles, une communauté qui explosait et 150 000 étoiles GitHub en quelques semaines. Le projet parfait pour construire un assistant personnel.

J'ai essayé trois fois : 

• Tentative 1 : trop tôt. Le système était encore instable à ses débuts, et j'ai abandonné rapidement.

• Tentative 2 (VPS) : j'ai voulu faire les choses bien (VPS sécurisé, configuration propre, modèles cloud du marché). Derrière, OpenClaw s'est révélé être un aspirateur à tokens redoutable. En quelques minutes, la mauvaise gestion de la fenêtre de contexte faisait exploser les seuils maximums des APIs. Inexploitable, et ça indépendamment de la question du coût.

• Tentative 3 (Mac dédié, LLM local) : MacBook dédié, modèles locaux via Ollama. J'ai commencé par llmfit pour identifier ce qui pouvait tourner sur la machine. J'ai testé trois modèles, de plus en plus compacts. Les timeouts étaient systématiquement atteints, quelle que soit la taille du modèle. Le log qui résume deux semaines de debug :

Profile ollama:default timed out. Trying next account...
reason=timeout provider=ollama/qwen3:8b

N'ayant pas 3k€ à mettre dans un mac mini de dernière génération, j'ai abandonné la piste OpenClaw.

L'agent, from scratch, hébergé sur GCP : trop de friction

En parallèle, j'ai exploré le développement custom : un agent hébergé sur GCP, d'abord avec LangChain/LangGraph, puis avec Pydantic AI. Alors oui, ça fonctionne, mais la surcouche de travail pour réimplémenter une logique agentique from scratch est énorme comparé à l'utilisation directe de Claude Code. Pour un usage quotidien personnel, il n'y a vraiment pas photo.

La décision finale : aller à la simplicité

Après tout ça, la conclusion s'imposait. Je suis un power user de Claude Code, j'utilise l'outil tous les jours dans mon terminal. Il a accès au disque, il exécute des scripts et sa capacité de raisonnement est excellente. Et surtout : j'ai un abonnement Claude Max à 100€/mois que je paye déjà. Autant l'utiliser à fond, sur des modèles cloud qui fonctionnent vraiment.

L'idée de créer vos propres agents vous intéresse ? Thiga Academy propose une formation dédiée à la création d'agents IA pour le Product Management avec la construction d'un agent PO qui rédige vos user stories depuis un PRD et les pousse dans votre backlog, en une session.

La solution : Claude Code + Telegram

Anthropic a publié en mars 2026 les "Channels" dans Claude Code, un plugin officiel qui connecte une session Claude Code à Telegram, Discord ou iMessage. Le système est bidirectionnel : Claude reçoit les messages et répond sur le même canal.

Ce qui rend cette approche différente de tout ce que j'avais testé, c'est que l'installation est triviale ! Tout passe par des commandes /plugin dans Claude Code. L'authentification utilise le compte Claude Max existant, aucune clé API supplémentaire n'est donc nécessaire. La persistance se gère avec tmux, une session qui ne s'éteint jamais. Et il y a un paramètre qui change tout pour un usage quotidien : --dangerously-skip-permissions.

Ce flag mérite une explication. Quand on code avec Claude Code, les demandes de validation à chaque action sont une sécurité utile. Quand on pilote un assistant personnel par Telegram, c'est un frein constant et pénible. Ce flag supprime ces confirmations pour les commandes bash, grep, curl, Python, tout ce qui est basique. Certes un peu dangereux en théorie, mais parfaitement raisonnable quand on est le seul utilisateur sur son propre Mac, avec une allowlist Telegram stricte.

L'architecture finale est d'une simplicité désarmante :

Telegram → Plugin Claude Code → Claude (Max) → réponse Telegram
                    ↑
              tmux (session persistante)

Résultat : pas de gateway externe, ni de LLM local à faire tourner ou de JSON à éditer à la main à 23h.

L'architecture, dans le détail

Une fois le setup de base en place, les vraies questions d'architecture arrivent. J'ai appliqué ici les principes que j'utilise dans mes projets avec gstack, notamment passer par le plugin Office Hours pour challenger la vision du produit et réduire aux fonctionnalités vraiment importantes avant de construire quoi que ce soit.

Philosophie : MVP d'abord

L'ensemble du système repose sur Claude Code dans le terminal comme runtime natif. Pas d'application custom, pas de framework, pas de serveur, pas de Docker. Pour l'instant, tout tient dans un dossier git avec des fichiers Markdown, du JSON et des scripts shell. Sans être un choix d'architecture définitif, cette approche volontairement minimaliste permet de démarrer vite et d'ajuster en fonction des besoins réels qui émergent. Base de données, stockage vectoriel, mémoire structurée : ça viendra si le besoin se confirme.

Les skills : le mécanisme central

Les skills sont des fichiers SKILL.md dont la description indique à Claude dans quel contexte les charger. Quand une requête correspond à la description d'un skill, ses instructions rejoignent la conversation en cours, comme si elles avaient toujours été là.

C'est différent des sous-agents, qui s'exécutent dans une fenêtre de contexte séparée et ne retournent que leur résultat final.

Et c'est différent des hooks, qui se déclenchent sur des événements système (chaque sauvegarde de fichier, chaque appel d'outil) plutôt que sur le contenu d'une requête. Trois mécanismes distincts, conçus pour être combinés.

L'agent tourne aujourd'hui avec 12 skills :

Opus + Haiku en tandem

Deux modèles cohabitent dans le système selon la nature de la tâche. Opus, le cerveau, pour tout ce qui demande du jugement : le brief matinal, le triage d'emails, la conversation libre. Haiku, le bras, pour l'exécution mécanique : écrire dans un JSON, lancer un script.

Le driver principal de ce choix est la latence plus que le coût. Haiku répond en 1-2 secondes sur Telegram. Opus, moins pressé, prend 5-10 secondes. Sur un assistant personnel qu'on utilise depuis son téléphone, la différence se ressent vraiment.

Les sous-agents pour les tâches mécaniques

Pour certaines tâches purement exécutives, l'agent principal délègue à des sous-agents Haiku spécialisés. La logique, telle que la décrit la documentation Claude Code, est celle-ci : un sous-agent s'exécute dans sa propre fenêtre de contexte séparée, traite sa tâche de façon indépendante, et retourne uniquement le résultat à l'agent principal. C'est le bon choix quand la tâche est autonome, qu'elle n'a pas besoin de l'intégralité du contexte conversationnel, et que seul le résultat importe. Par exemple un sous-agent pour l'écriture dans les fichiers de données, un autre pour les scripts d'intégration externe et encore un troisième pour la génération de PDFs.

Flat JSON pour l'instant

La persistance se fait dans des fichiers JSON versionnés dans git, avec des atomic writes (.tmp + rename) pour éviter la corruption. Pour un utilisateur unique au stade MVP, c'est largement suffisant. Je ne suis pas contre les bases de données par principe, mais j'ai fait un choix pragmatique pour démarrer.

La connectique MCP

Google Calendar, Gmail et Granola (notes de meetings) via les connecteurs MCP intégrés à Claude Code d'un côté, et Telegram via un plugin local de l'autre. C'est là que réside la vraie valeur : un agent n'a d'intérêt que s'il est connecté aux outils qu'on utilise vraiment au quotidien.

Infrastructure Mac always-on

Quatre éléments assurent la disponibilité permanente : tmux pour la persistance de session, pmset pour empêcher la mise en veille, un adaptateur USB RJ45 pour s'affranchir du wifi (qui peut décrocher la nuit), et LaunchAgent macOS pour les crons, pas crontab, que macOS tue en veille.

Ce que fait l'agent aujourd'hui, frictions comprises

Voici l'état des fonctionnalités en production, à date, avec les limites honnêtes de chacune.

Triage d'emails, deux fois par jour

Deux fois par jour, l'agent analyse ma boîte Gmail et produit trois catégories : le spam résiduel, les emails informatifs dont il extrait l'essentiel avant d'archiver, et les emails qui méritent une réponse de ma part, pour lesquels il rédige un draft et le sauvegarde. Il n'envoie jamais sans mon accord explicite.

Friction réelle : le MCP Gmail officiel fourni avec Claude Desktop fonctionne correctement en lecture, mais ne permet pas de déplacer ou d'archiver des emails nativement. Pour un vrai triage avec actions d'écriture, j'ai dû aller chercher un MCP Gmail tiers non-officiel. C'est aussi la fonctionnalité qui prend le plus de temps à affiner : la qualité des drafts s'améliore avec le contexte accumulé, mais on n'y est pas encore.

To-do list dynamique

Basée sur mes derniers meetings Granola et mon agenda Google Calendar, l'agent maintient une to-do list priorisée que je peux modifier à la demande depuis Telegram. Simple et efficace !

Réservations et tâches du quotidien

Sur une commande depuis Telegram, l'agent peut réserver des créneaux sportifs, interagir avec des services tiers, gérer des rappels. Le gain de temps n'est pas toujours colossal, mais ça démontre concrètement que l'agent peut agir dans le monde réel, pas seulement répondre à des questions.

Tâches administratives automatisées

Déclarations mensuelles, génération de PDFs, préparation de messages récurrents... L'agent traite ça en autonomie : il génère le document, prépare le message, et je n'ai plus qu'à valider pour envoyer.

Friction réelle sur les crons : les tâches planifiées dans Claude Code ne persistent que pendant la durée de vie d'une session, soit 7 jours maximum. Pour des tâches récurrentes vraiment fiables, j'ai contourné le problème avec un LaunchAgent macOS. Un fichier .plist dans ~/Library/LaunchAgents/ déclenche un script shell lun-ven à 7h57, qui appelle claude -p /brief. Claude démarre, exécute le skill, envoie le récap sur Telegram, et se ferme. L'avantage sur les crons Claude Code : le LaunchAgent survit aux redémarrages et se relance même si le Mac était en veille.

Le chantier en cours : /now

La fonctionnalité sur laquelle je travaille le plus en ce moment. L'idée : envoyer /now sur Telegram, et que l'agent propose immédiatement la tâche la plus pertinente à traiter en tenant compte de l'agenda, des emails en attente, de la to-do list et surtout du moment de la journée. Le comportement change selon l'heure : le matin, on pousse les tâches de fond qui demandent de la concentration. L'après-midi, on privilégie les actions courtes et les réponses rapides. En soirée, on bascule sur ce qui peut être délégué ou préparé pour le lendemain.

Le problème que ça résout est réel : passer dix minutes à se demander quoi faire dans trente minutes, c'est inefficient. Et c'est exactement le type de cas d'usage qui justifie de construire son propre agent plutôt qu'un outil générique. Un outil générique ne peut pas savoir que vous avez une présentation demain, trois emails en attente de réponse et une énergie moyenne à 16h un jeudi.

Guide : 30 minutes pour démarrer

Prérequis : Claude Code v2.1.91+, abonnement Claude Max, Bun (curl -fsSL https://bun.sh/install | bash), tmux (brew install tmux).

1. Créer le bot Telegram

Ouvre Telegram, cherche @BotFather, envoie /newbot. Choisis un nom d'affichage et un username (qui finit par bot). BotFather retourne un token, garde-le précieusement.

2. Installer le plugin dans Claude Code

/plugin install telegram@claude-plugins-official
/reload-plugins

Si le plugin n'est pas trouvé : /plugin marketplace add anthropics/claude-plugins-official

3. Configurer le token

/telegram:configure TON_TOKEN_BOTFATHER

4. Lancer avec le channel actif

claude --dangerously-skip-permissions --channels plugin:telegram@claude-plugins-official

5. Appairer

Envoie un message à ton bot sur Telegram. Il répond avec un code d'appairage. Dans Claude Code :

/telegram:access pair <CODE>
/telegram:access policy allowlist

6. Session permanente avec tmux

tmux new-session -d -s assistant 'claude --dangerously-skip-permissions --channels plugin:telegram@claude-plugins-official'

# Alias pratiques dans .zshrc
alias aistart="tmux new-session -d -s assistant 'claude --dangerously-skip-permissions --channels plugin:telegram@claude-plugins-official'"
alias aistop="tmux kill-session -t assistant"
alias aiattach="tmux attach -t assistant"

7. No sleep Mac

sudo pmset -a sleep 0
sudo pmset -a disablesleep 1

8. Le CLAUDE.md, l'étape qu'on sous-estime

C'est le system prompt permanent de l'agent, lu automatiquement à chaque session. Sa qualité conditionne tout le reste :

# Contexte
Tu es mon Chief of Staff personnel. Je m'appelle [Prénom], [Titre] chez [Entreprise].

# Priorités quotidiennes
- Trier mes emails Gmail 2 fois par jour
- Maintenir ma to-do list depuis mon agenda et Granola
- Répondre à mes messages Telegram avec concision

# Règles
- Ne jamais envoyer d'email sans ma validation explicite
- Toujours en français sauf si je parle anglais
- Résumer avant d'agir sur les tâches complexes

Prochaines étapes

La mémoire persistante

C'est le chantier sur lequel je n'ai pas encore de réponse définitive. Claude Code dispose de mécanismes de mémorisation du contexte, les fichiers de projet, le CLAUDE.md, l'auto-memory entre sessions. C'est utile pour garder une continuité conversationnelle. Mais pour stocker ce qu'on voudrait que l'agent retienne vraiment sur le long terme, préférences, historique de décisions, contexte de projets anciens, ça ne suffit pas.

Deux pistes que j'explore. Obsidian comme vault de mémoire : un dossier de fichiers Markdown que Claude Code lit et écrit directement. Simple, transparent, versionnable. SQLite pour les données structurées : plus rigide, mais plus fiable pour des requêtes précises. Je ne sais pas encore quelle architecture va s'imposer, les deux sont probablement complémentaires. J'en saurai plus dans quelques semaines.

Les alternatives clés en main : une honnêteté nécessaire

Il existe des projets sérieux dans l'écosystème qui ciblent exactement ce cas d'usage. Deux méritent d'être mentionnés honnêtement.

• LettaBot (bâti sur Letta, ex-MemGPT) est probablement l'alternative la plus mature pour la mémoire persistante. Il supporte Telegram, Discord, WhatsApp et Signal depuis un seul agent avec une mémoire qui s'améliore vraiment au fil des conversations. Académiquement solide (Berkeley), financé, model-agnostic. Si la mémoire long terme est votre priorité absolue, c'est le projet à regarder en premier.

• Nanobot (22 000 étoiles, 4 000 lignes de Python) est l'antithèse d'OpenClaw : ultra-léger, 11 providers LLM, 8 canaux dont Telegram, mémoire persistante incluse. Son ambition déclarée est de devenir un "agent kernel" minimal que la communauté étend. Intéressant si vous préférez une codebase que vous pouvez lire et auditer en une heure.

• HermesAgent: Pas encore testé, mais semble très prometteur. 

Alors pourquoi avoir quand même choisi de construire le mien ? Parce qu'un assistant vraiment utile, ça demande une personnalisation que aucun template ne peut reproduire. Les commandes, les intégrations, le niveau d'autonomie accordé, la façon dont il triage les emails vs les demandes urgentes, tout ça reflète une organisation personnelle très spécifique. Un outil générique, même bien fait, part de zéro sur votre contexte. Le mien part de là où je suis.

C'est un pari. Je vous dirai dans quelques semaines si c'était le bon.

Ce qui m'impressionne encore avec Claude Code, c'est sa capacité à accompagner. Tu pars de zéro, il te guide. Tu fais une erreur, il t'aide à la corriger. Tu décris vaguement ce que tu veux construire, il t'aide à le préciser. La courbe d'apprentissage existe, mais elle est humaine.

La promesse du Chief of Staff IA personnel est réelle, et ce dès maintenant. Mais comme souvent la vraie valeur n'est pas tant dans la sophistication de la stack que dans la qualité du contexte qu'on donne à l'agent, dans les connectiques qu'on met en place, et dans la discipline qu'on développe pour déléguer les bonnes tâches. Au fond, un agent sans contexte, c'est Claude, l'interface en moins.

Un agent bien configuré, connecté à vos vrais outils, c'est une extension de vous-même qui devient plus utile chaque semaine. Le setup que je décris ici sera peut-être obsolète dans six mois quand les outils auront encore évolué. Mais la compétence à construire et calibrer ce genre de système, elle, restera.

Pour aller plus loin :

• Documentation officielle des Channels Claude Code
• Créer un agent IA sans savoir coder avec n8n - approche complémentaire pour profils moins techniques
• LettaBot, pour la mémoire persistante
• Formations IA — Thiga Academy