Comment utiliser Claude Code comme assistant personnel (avec MCP)

Claude Code associé à MCP, c’est puissant, mais ça s’accompagne d’une vraie friction : il faut être à l’aise avec le terminal, comprendre la configuration des serveurs MCP, gérer les périmètres et les permissions, et maintenir un contrat explicite pour chaque workflow.

C’est là qu’intervient Notis.

Notis : la même puissance, sans la complexité

Notis te donne les capacités d’assistant personnel de Claude Code + MCP, mais via une interface conversationnelle que tu sais déjà utiliser.

Au lieu d’écrire des commandes CLI et de gérer des serveurs MCP, tu parles simplement à Notis :

• Envoie un message en marchant

• Transfère un fil Slack

• Laisse un vocal

• Ton assistant le transforme en actions dans tes outils

Toutes les intégrations (Notion, Slack, GitHub, Drive) fonctionnent dès le départ. Pas de terminal. Pas de fichiers de configuration. Juste une conversation naturelle qui fait avancer les choses.

Si tu veux l’assistant sans la complexité, jette un œil ici : https://notis.ai/

Claude Code comme assistant personnel (pas seulement un outil de code)

La plupart des gens découvrent Claude Code comme « le truc qu’on lance dans un terminal pour aider à coder ». C’est vrai, mais c’est incomplet.

Claude Code devient intéressant quand tu arrêtes de raisonner en « je demande au modèle, j’obtiens une réponse » et que tu commences à raisonner en « je délègue un workflow ». La CLI est le poste de pilotage. Ton repo, tes docs, tes tickets et tes agendas forment la matière de travail. MCP est la prise qui permet à Claude d’atteindre d’autres systèmes en toute sécurité.

Si tu as déjà rêvé d’un assistant façon bras droit capable de vraiment faire les parties ennuyeuses à ta place, Claude Code + MCP est l’une des briques les plus propres dont on dispose aujourd’hui.

Ce qu’est vraiment Claude Code

Claude Code est l’outil de workflows agentiques d’Anthropic, que tu pilotes en ligne de commande. Il est conçu pour faire plus que discuter : il peut planifier, lire et écrire des fichiers, lancer des outils et maintenir une session pendant qu’il itère.

Le détail important, ce n’est pas que ce soit « une CLI pour Claude ». Le détail important, c’est que c’est un environnement d’exécution d’agent avec des permissions d’outils, une gestion de sessions et une interface prévisible que tu peux scripter.

Cette combinaison le rend utile comme assistant personnel, parce que le travail d’assistant personnel tient rarement en un seul prompt. C’est en général une séquence.

Le modèle mental de « l’agent en CLI »

Un agent en CLI, c’est une boucle.

Tu donnes un objectif à Claude Code. Il décide de ce dont il a besoin ensuite. Il demande l’accès aux outils quand c’est nécessaire. Il exécute. Il vérifie les résultats. Il recommence jusqu’à ce que la tâche soit terminée ou que tu l’arrêtes.

Quand ça marche bien, tu n’es pas en train « d’écrire des prompts ». Tu supervises.

Cette supervision peut être légère ou stricte selon ta tolérance à l’autonomie. Claude Code te donne les réglages pour ça, et c’est pourquoi il est plus sûr que l’approche bricolée du « je donne juste mes clés API au modèle » que beaucoup de gens réinventent sans le vouloir.

Pour démarrer vite : mode interactif vs mode headless

Claude Code a deux modes d’usage qui comptent pour un usage d’assistant.

Le mode interactif, c’est celui que tu utilises quand tu veux collaborer. Tu es dans un aller-retour, et tu peux réorienter rapidement quand le contexte est flou.

Le mode headless, c’est celui que tu utilises quand tu veux automatiser. Tu lances une commande, elle s’exécute et tu récupères le résultat.

Voici la différence d’ambiance.

En mode interactif, tu lances Claude Code et tu restes dans la session :

claude

En mode headless, tu le traites comme une fonction d’assistant que tu appelles :

claude -p "Summarize today’s changes and draft a release note" \
  --output-format json

Ce second mode, c’est ce qui te permet de commencer à construire tes propres « commandes d’assistant ». Il devient aussi la colonne vertébrale des tâches cron, des GitHub Actions ou des petits scripts qui appellent Claude Code à la demande.

La pièce manquante : le Model Context Protocol (MCP)

MCP fait le pont entre un assistant qui « sait des choses » et un assistant qui peut « agir sur des systèmes ».

MCP est un protocole ouvert pour connecter les LLM à des outils et à des sources de données externes de façon structurée. En pratique, un serveur MCP expose des capacités, et Claude Code peut les appeler comme des outils.

Si tu as déjà utilisé des plugins, MCP te semblera familier, mais le cadrage est meilleur : au lieu que chaque app d’IA réinvente son format d’intégration, MCP cherche à rendre les intégrations portables.

La façon la plus simple de le voir, c’est celle-ci.

Sans MCP, Claude Code est puissant dans ton contexte local : tes fichiers, ton shell, ton repo.

Avec MCP, Claude Code devient un assistant transversal : il peut tirer du contexte d’un système, agir dans un autre et garder un plan cohérent.

Comment MCP fonctionne dans Claude Code

Claude Code peut se connecter à des serveurs MCP. Ces serveurs peuvent tourner en local sur ta machine, ou à distance derrière HTTP ou SSE.

Tu enregistres les serveurs avec la commande claude mcp, puis Claude peut les utiliser comme outils pendant l’exécution de l’agent.

Par exemple, ajouter un serveur MCP distant ressemble à ça :

claude mcp add notion --transport http https://mcp.notion.com/mcp

À partir de là, les capacités Notion exposées par ce serveur peuvent entrer dans la boîte à outils de l’agent.

Ce qui compte, ce n’est pas la commande exacte. C’est la frontière.

MCP rend les intégrations explicites. C’est toi qui choisis quels serveurs existent. Tu décides de leur périmètre. Tu peux les supprimer. Tu peux vérifier ce que l’agent a le droit de faire.

C’est ce qui transforme un « assistant qui peut tout faire » en « assistant qui fait exactement ce que j’ai approuvé ».

Les workflows que MCP débloque (Notion, Slack, GitHub, Drive)

Quand tu connectes Claude Code à des systèmes externes, tu peux arrêter de faire à la main le travail de liaison idiot.

Le travail de liaison classique, c’est : lire quelque chose à un endroit, le résumer, le traduire en tâche ailleurs, puis prévenir quelqu’un.

MCP te permet d’exprimer tout ça comme une seule mission déléguée.

Voici les workflows qui comptent vraiment dans la vraie vie.

Notion : une base de connaissances vivante qui se met à jour toute seule

Si ton assistant peut lire et écrire dans Notion, il cesse d’être un chatbot et devient un opérateur.

Une boucle concrète d’assistant personnel dans Notion ressemble à ça.

Tu captures une entrée brouillonne. Ça peut être la transcription d’un appel, un vide-cerveau ou un vocal.

Claude Code transforme cette entrée en livrables structurés : notes de réunion, actions à mener, points d’avancement de projet et documentation propre.

Puis il publie ces livrables dans les bonnes bases de données Notion, avec la bonne structure, sans que tu aies à copier-coller quoi que ce soit.

Le gain subtil, c’est la régularité. Les humains sont mauvais pour appliquer « la même mise en forme » à chaque fois. Un agent y excelle.

Slack : les décisions et le contexte ne s’évaporent plus

Slack, c’est là que les décisions se prennent, mais c’est aussi là que le contexte meurt.

Un assistant connecté à Slack peut faire deux choses à fort levier.

D’abord, retrouver le fil précis où la décision a été prise et en extraire l’état final, sans que ton cerveau doive relire trois jours d’échanges.

Ensuite, traduire ça en livrables en aval : une mise à jour de spec, une tâche, un message de relance ou un résumé pour quelqu’un qui n’était pas dans le canal.

Anthropic propose aussi des connecteurs Slack dans l’écosystème produit de Claude. L’idée clé pour toi reste la même dans tous les cas : ton assistant a besoin d’un accès cadré au contexte Slack pour être utile, et ce à quoi il a accès doit être évident.

GitHub : traite la « revue » comme une tâche déléguée

GitHub est déjà un moteur de workflows. Claude Code s’y intègre bien parce qu’il peut fonctionner avec les mêmes frontières que celles qui comptent pour les développeurs : repos, pull requests, diffs et CI.

Un workflow GitHub façon assistant personnel ressemble à ça.

Tu demandes à Claude Code de relire une PR selon les standards de ton projet.

Il inspecte le diff. Il vérifie les tests. Il cherche les risques. Il rédige des commentaires de revue.

Si tu veux que ça tourne sans avoir à y penser, Anthropic documente une intégration GitHub Actions pour Claude Code, qui revient en gros à « l’agent tourne dans le workflow de la PR ».

Ce n’est pas réservé aux grandes équipes. Si tu es fondateur solo, c’est comme avoir une deuxième paire d’yeux qui ne se fatigue jamais.

Google Drive : rends tes documents interrogeables au lieu de les oublier

Une bonne partie du travail d’« assistant personnel », c’est de la lecture.

Lire un doc, en extraire l’essentiel, créer les livrables de suivi, puis retrouver le doc plus tard.

Si tu branches le contexte Drive dans ton workflow d’assistant, tu peux faire des choses comme :

Tu déposes un doc de stratégie dans Drive. Tu demandes à Claude d’en extraire les décisions, les hypothèses et les questions ouvertes. Tu lui fais transformer tout ça en brief de projet dans Notion. Puis tu lui demandes de rédiger l’annonce Slack.

La question n’est pas de savoir quel système est « le meilleur ». L’idée, c’est que l’assistant peut passer d’un système à l’autre sans que ce soit toi qui serves de couche d’intégration.

Le plus important : périmètre et sécurité

Le moyen le plus rapide de te brûler avec des outils agentiques, c’est de zapper les contraintes ennuyeuses.

Claude Code te donne plusieurs couches de sécurité. Sers-t’en.

Les permissions d’outils sont la plus évidente. Claude Code prend en charge des listes d’autorisation et d’interdiction pour les outils, plus des demandes de permission quand il veut faire quelque chose de sensible.

Si tu vois une option comme --dangerously-skip-permissions, traite-la comme un accès à une base de données de production. Il y a des moments où tu peux l’utiliser en local, mais ça ne doit jamais être ton mode par défaut pour tout ce qui touche à de vrais comptes.

Le périmètre MCP est la deuxième couche.

Claude Code peut enregistrer les serveurs MCP à différents niveaux de portée. Choisir la portée revient à répondre à la question : « qui doit pouvoir utiliser cet outil, et où ? ».

La portée locale est idéale quand tu expérimentes ou quand l’outil est propre à un seul projet.

La portée projet est puissante pour les équipes, parce que tu peux partager la configuration MCP dans le repo, mais elle suppose de la confiance. Si un repo contient une définition de serveur MCP, tu dois la relire comme tu relirais un script qui tourne sur ta machine.

La portée utilisateur est utile pour les outils d’assistant personnel que tu veux avoir partout.

La troisième couche, c’est l’hygiène des identifiants.

Si un serveur MCP a besoin d’une clé API, préfère les variables d’environnement au code en dur. Préfère des tokens au périmètre restreint à des accès « admin sur tout ». Préfère des comptes de service séparés quand c’est possible.

Ça ressemble à du théâtre de sécurité jusqu’au jour où un agent essaie de faire quelque chose que tu n’avais pas prévu, parce que tu avais oublié qu’il y avait accès.

Comment voir Claude Code comme ton assistant personnel

Les gens échouent avec les assistants pour l’une de ces deux raisons.

Soit ils donnent à l’assistant un objectif vague en espérant qu’il lise dans leurs pensées.

Soit ils microgèrent chaque étape et ne le laissent jamais tourner.

Claude Code fonctionne au mieux quand tu rends le contrat explicite.

Le contrat a trois parties :

D’abord, l’objectif. C’est ce que « terminé » veut dire.

Ensuite, les outils autorisés et les limites. C’est ce à quoi l’assistant peut toucher.

Enfin, le livrable. C’est ce qui est créé, mis à jour ou publié.

Si tu veux que Claude Code se comporte comme un bras droit, traite-le comme tel. Donne-lui des missions récurrentes bien définies, et laisse-le prendre de l’élan de session en session.

Une bonne pratique consiste à stocker tes règles de fonctionnement dans un fichier du projet, pour que l’agent parte toujours des mêmes attentes. C’est là que tu mets ton style, tes préférences et tes définitions de « terminé ».

La réalité : Claude Code est puissant, mais complexe

Si tu as lu jusqu’ici, tu as vu ce que Claude Code + MCP sait faire. C’est vraiment puissant.

Mais soyons honnêtes sur la friction :

• Il faut être à l’aise avec les commandes terminal

• Il faut comprendre la configuration et le périmètre des serveurs MCP

• Il faut gérer les permissions d’outils et les couches de sécurité

• Il faut maintenir un contrat explicite pour chaque workflow

• Il faut gérer l’hygiène des identifiants et les tokens d’API

Pour les développeurs qui vivent dans le terminal, ça ne pose aucun problème. C’est même préférable.

Mais si ce que tu veux vraiment, c’est un assistant personnel à qui déléguer naturellement, sans surcharge de configuration, la complexité se met en travers de l’objectif.

Si tu veux l’assistant sans le terminal : essaie Notis

C’est exactement pour ça qu’on a construit Notis.

Notis te donne les mêmes capacités d’assistant personnel (connexion à Notion, Slack, GitHub, Drive et plus encore), mais par messagerie et à la voix.

Pas de terminal. Pas de configuration MCP. Pas de périmètres de permissions à gérer.

Juste de la délégation naturelle :

• « Prends ces notes de réunion et crée les tâches dans Notion »

• « Résume ce fil Slack et rédige une réponse »

• « Relis cette PR pour repérer les failles de sécurité »

Tu peux envoyer un texte, laisser un vocal en marchant ou transférer un fil. Ton assistant s’occupe du reste.

Toute la puissance de Claude Code + MCP, dans une interface conversationnelle qui donne l’impression d’écrire à un collègue.

Si ça te parle plus que de gérer des commandes CLI, jette un œil : https://notis.ai/