Framework Agentic OS Claude Code : Comment j’ai conçu le mien

J’ai passé six mois à traiter Claude Code comme un stagiaire très rapide. Intelligent, infatigable, parfois brillant — et distrait exactement aux moments qui me coûtaient le plus de temps. Chaque session commençait avec moi en train de réexpliquer la même tonalité de marque, la même structure de dossier, les mêmes règles que j’avais déjà notées à trois autres endroits. Chaque compétence que je développais vivait en vase clos. Chaque automatisation que je mettais en place fonctionnait parfaitement… jusqu’au moment où il fallait la transmettre à quelqu’un qui n’avait jamais ouvert un terminal.

Puis, j’ai arrêté de construire des outils isolés et j’ai commencé à bâtir un système.

Ce que je vais détailler ici, c’est le framework d’agentic OS Claude Code sur lequel je me suis arrêté après avoir démonté et reconstruit ma stack trois fois durant le premier trimestre 2026. Ce n’est pas un produit. Ce n’est pas un plugin. C’est un schéma d’architecture qui transforme Claude Code, d’un simple assistant de codage, en quelque chose qui s’apparente à un système d’exploitation personnel — un système qui se souvient, exécute de façon cohérente, et peut facilement être confié à des clients qui n’ont jamais ouvert un terminal de leur vie.

La perspective qui m’a ouvert cette voie était simple : la plupart des configurations de Claude Code échouent au même endroit, sur trois points clés. La mémoire, la cohérence et l’accès. Comblez ces trois lacunes, et l’outil cesse d’être un simple outil. Il devient une infrastructure.

Les trois lacunes présentes dans chaque configuration Claude Code

Avant que l’architecture prenne tout son sens, le problème qu’elle résout doit être clairement défini. Car si vous utilisez Claude Code depuis plus de quelques semaines, vous avez probablement ressenti ces trois lacunes sans forcément les nommer.

Première lacune : la mémoire. Claude Code est sans état entre les sessions, à moins que vous ne lui fournissiez un endroit où stocker ce qu’il apprend. CLAUDE.md aide, mais ce n’est qu’un seul fichier qui essaie de remplir le rôle d’une armoire de classement. Dès que vous souhaitez que l’agent se souvienne des préférences d’un client, de l’historique d’un projet, ou d’une décision prise il y a trois semaines, vous vous retrouvez à devoir tout réexpliquer. La plupart des gens entendent “mémoire” et pensent immédiatement à une pipeline RAG complète avec Pinecone ou des embeddings vectoriels Supabase. Pour 90 % des workflows, c’est exagéré. Ce dont vous avez besoin, c’est de la persistance, pas d’une recherche sémantique sur un million de documents.

Deuxième lacune : la cohérence. Demandez à Claude Code d’écrire un article de blog un lundi, vous obtiendrez un résultat. Faites la même demande le vendredi, et le résultat sera différent — ton, structure, pied de page… La variance n’est pas la faute du modèle. C’est un problème d’ingénierie de prompt déguisé en problème de modèle. Sans compétences structurées qui encodent comment vous voulez que le travail soit réalisé, chaque appel est un nouveau coup de dés. Les skills et automatisations règlent ce problème, mais seulement s’ils sont organisés comme dans une véritable opération, pas juste déposés au hasard dans un dossier plat ~/.claude/skills/.

Troisième lacune : l’accès. C’est celle dont personne ne parle car les fondateurs techniques ne la ressentent pas. Mais si vous avez déjà tenté de passer Claude Code à un collègue non technique, à un client, ou même à votre propre cerveau à 22h quand vous n’avez pas envie de taper claude --continue --session-id foo, vous l’avez vécue. Le terminal est un fossé. Pour vous, c’est une fonctionnalité. Pour tous les autres, c’est un mur.

Le framework agentic OS, c’est ce que l’on obtient lorsqu’on cesse de traiter ces trois lacunes séparément et qu’on choisit de les résoudre ensemble.

Ce qu’est réellement un OS agentique

L’expression « OS agentique » est souvent employée à tort et à travers. Voici ce que j’entends par là dans ce contexte précis : une architecture où Claude Code sert de moteur d’exécution, une couche mémoire persistante assure la continuité, un système hiérarchique de compétences garantit la cohérence, et un tableau de bord offre un point d’entrée aux utilisateurs non familiers du terminal.

Quatre couches. C’est tout le concept.

┌─────────────────────────────────────────────┐
│  Dashboard / Command Center (Next.js)       │  ← accès
├─────────────────────────────────────────────┤
│  Skills + Automations (local + distant)     │  ← cohérence
├─────────────────────────────────────────────┤
│  Memory Layer (Obsidian vault, Markdown)    │  ← mémoire
├─────────────────────────────────────────────┤
│  Claude Code (engine)                       │  ← exécution
└─────────────────────────────────────────────┘

La force de cette architecture, c’est que chaque couche a un rôle unique, et aucune ne s’oppose aux autres. Claude Code fait déjà ce pour quoi il excelle : raisonner, écrire du code, exécuter des tâches en plusieurs étapes. Obsidian gère la persistance, car il fonctionne déjà comme un système de fichiers basé sur Markdown — exactement le format natif de lecture et d’écriture de Claude Code. Les skills et automatisations transforment les prompts ponctuels en workflows fiables. Le dashboard enrobe l’ensemble dans une interface cliquable.

Je veux souligner l’élément qui m’a le plus surpris en concevant tout cela : le dashboard est l’élément qui change la donne pour les utilisateurs non techniques, mais c’est aussi celui qui a radicalement transformé ma propre façon de travailler. On en reparlera plus loin. Gardez cette idée en tête pour la suite.

Première couche : Mémoire sans RAG

Je vais commencer par la partie qui m’a demandé le plus de reprises.

J’ai passé deux week-ends en février à construire une vraie couche mémoire RAG pour Claude Code. Supabase comme base vectorielle, embeddings OpenAI, un serveur MCP personnalisé permettant à Claude d’effectuer des recherches sémantiques. Ça fonctionnait. Mais c’était totalement surdimensionné par rapport à ce dont j’avais réellement besoin, à savoir « se souvenir de ce qu’on a décidé mardi dernier ».

J’ai tout supprimé et remplacé par un coffre Obsidian. Toute la couche a pris environ 40 minutes à mettre en place.

Voilà pourquoi Obsidian fonctionne particulièrement bien comme couche mémoire IA pour Claude Code :

• Les coffres Obsidian ne sont que des dossiers de fichiers Markdown. Aucun format propriétaire. Aucune base de données. Pas de couche de synchronisation à surveiller. Claude Code lit et écrit le Markdown nativement, ce qui signifie que le « système mémoire » consiste littéralement en un simple accès au système de fichiers.
• La création de liens façon wiki ([[note-name]]) apporte une structure sans schéma. Claude peut suivre les liens comme le ferait un humain, parcourant les fils d’idées d’une note à l’autre.
• C’est gratuit, local et portable. Si je décide de remplacer Claude Code par Codex CLI ou n’importe quel autre outil qui sortira le mois prochain, ma couche mémoire me suit. Aucun verrouillage propriétaire.
• Obsidian rend lui-même le coffre lisible et agréable pour les humains. Si je veux relire ce que l’agent a rédigé, inutile d’interroger une base de données. J’ouvre Obsidian et je lis.

La structure de mon coffre ressemble à ceci :

~/vault/
├── _claude/
│   ├── CLAUDE.md              # contexte global, chargé à chaque session
│   ├── session-logs/          # événementiel de chaque exécution
│   └── decisions/             # justification des choix effectués
├── clients/
│   └── [client-name]/
│       ├── brief.md
│       ├── brand-voice.md
│       └── delivered/
├── projects/
│   └── [project-name]/
└── knowledge/
    ├── claude-code-patterns.md
    └── skills-registry.md

L’élément clé est _claude/CLAUDE.md. Ce fichier est le point d’entrée de Claude Code dans le coffre — une table des matières pour l’agent. Il indique à Claude où se trouvent les briefs clients, où consigner les journaux de session, dans quels fichiers sont stockées les décisions à ne jamais contredire. À chaque session, l’agent lit ce fichier en premier, puis navigue vers la partie du coffre dont il a besoin.

Pour la plupart des lecteurs, si vous hésitez entre « construire un système RAG » ou « configurer un coffre Obsidian » — commencez par le coffre. Vous pourrez toujours ajouter le RAG plus tard, lorsque vous atteindrez une échelle où la recherche sémantique devient réellement pertinente. Je n’en ai pas encore eu besoin, et cela fait trois mois que j’utilise cette configuration pour quatre marques et plus de 230 contenus. Si vous voulez une argumentation plus détaillée, j’ai déjà écrit sur Obsidian en tant que mémoire persistante de Claude Code et sur pourquoi un coffre de connaissances plat surpasse un pipeline RAG dans la plupart des workflows.

Une précision avant de poursuivre — la couche mémoire n’est pas optionnelle dans ce framework. Sans elle, la couche skills n’a rien à quoi s’ancrer. La cohérence suppose d’être cohérent par rapport à quelque chose. Voilà le lien avec la prochaine section.

Couche Deux : Compétences et Automatisations, Structurées comme un Organigramme

C’est à cette couche que la plupart des tentatives d’OS agentique sombrent dans le chaos.

L’erreur que je vois sans cesse — et que j’ai moi-même commise un temps — c’est de balancer chaque compétence dans un dossier à plat. ~/.claude/skills/post-writer, ~/.claude/skills/research, ~/.claude/skills/social-scheduler, trente autres encore. Puis d’essayer de se rappeler laquelle fait quoi, au moment où vous en avez besoin six semaines plus tard.

La solution est de cesser de penser aux compétences comme à de simples scripts, et de commencer à les concevoir comme des rôles dans une équipe.

Voici la hiérarchie que j’ai adoptée :

Fonctions : ce sont les grands domaines de travail. « Production de contenu ». « Recherche ». « Opérations client ». « Veille de marque ». Ce ne sont pas des compétences — ce sont des catégories auxquelles une compétence appartient.

Compétences : ce sont les tâches atomiques et réutilisables à l’intérieur d’une fonction. Dans « production de contenu », j’ai par exemple blog-post-writer, image-brief-generator, social-distribution-package. Chaque compétence accomplit une chose avec efficacité. Chacune dispose de son propre fichier SKILL.md détaillant à quel moment Claude doit l’activer, quels sont ses inputs, et ce qu’elle produit.

Sous-compétences : elles prennent en charge le travail spécialisé qu’une compétence parente leur délègue. blog-post-writer possède des sous-compétences pour la phase de recherche, l’adaptation de la voix, le structuring SEO et l’auto-évaluation. Le parent orchestre ; les sous-compétences exécutent.

Automatisations : ce sont des compétences dotées de déclencheurs. Même compétence, mais qui fonctionne désormais sur un planning ou se lance automatiquement lorsqu’un événement survient. Les automatisations planifiées sont pilotées par cron. Les automatisations à la demande se déclenchent via un clic depuis le dashboard ou un hook directement dans Claude Code.

Claude Code a lancé plus tôt cette année un plugin de création de compétences sur la marketplace officielle qui gère la majeure partie de l’ossature. En exécutant /plugin install skill-creator depuis Claude Code, vous profitez d’un workflow guidé : description de la compétence, tests sur des entrées réelles, itérations sur le prompt, puis enregistrement dans votre dossier skills. L’écosystème autour de cela est immense — les marketplaces communautaires sur tonsofskills.com et claudemarketplaces.com recensaient des milliers de plugins et d’agents en avril 2026, et la plupart s’intègrent sans difficulté à cette hiérarchie si vous les classez par fonction.

La raison pour laquelle la structure hiérarchique importe n’est pas purement esthétique. C’est que la logique de routage de Claude Code s’en trouve nettement améliorée lorsque les compétences sont bien organisées. Lorsque l’agent doit choisir quelle compétence activer, la décision s’opère dans la fenêtre de contexte. Un dossier plat de 60 compétences gaspille des tokens sur la désambiguïsation. Une hiérarchie de quatre fonctions, chacune avec six à huit compétences, chacune dotée de sous-compétences nommées, permet à l’agent de cibler rapidement la bonne solution.

Pour approfondir la structure hiérarchique, j’en ai détaillé la décomposition dans mon playbook des équipes d’agents Claude Code et le guide avancé des compétences d’agent. Ce sont deux articles satellites de celui-ci.

Automatisation locale vs distante : la décision qui compte vraiment

Une fois les skills créés, la question suivante, c’est où les exécuter. C’est à ce stade que beaucoup de projets s’embrouillent, car la distinction entre automatisation locale et distante ne repose pas sur la complexité, mais sur ce à quoi le skill doit accéder.

Les automatisations locales s’exécutent sur votre machine. Elles ont accès à votre système de fichiers, à vos CLIs installées, à votre coffre-fort Obsidian local, à vos dépôts git, à vos enregistrements d’écran, en bref tout ce qui se trouve sur votre poste. Elles exigent que vous soyez connecté. Si votre ordinateur portable est en veille, elles le sont aussi.

Les automatisations distantes s’exécutent dans le cloud — généralement via les Claude Routines, qu’Anthropic a déployées dans le cadre de l’abonnement à 20 $/mois, puis largement étendues dans la mise à jour d’avril 2026. Elles fonctionnent indépendamment de votre machine. Pas d’accès au système de fichiers, ni aux CLIs locales, mais aussi aucune dépendance à votre connexion.

L’arbre décisionnel que j’utilise tient littéralement en cette question : est-ce que ce skill a besoin d’accéder à quelque chose en local ? Oui ? Alors local. Non ? Alors distant. Pas besoin d’y passer des heures.

Exemples concrets :

Candidats à l’automatisation locale :

• Workflows de recherche approfondie chaînant Firecrawl CLI pour le scraping, Notebook LM pour la synthèse, et rédigeant la sortie dans une note Obsidian. Ils nécessitent des CLIs locales et un accès au système de fichiers local — ça doit être local.
• Pipelines vidéo-vers-blog où je télécharge une vidéo, la transcris localement, passe la transcription à Claude Code, et sauvegarde l’article dans content/mejba.me/[slug].md. Les fichiers sont en local. L’automatisation aussi.
• Refactoring de codebase où Claude Code modifie les fichiers du dépôt sur le disque.
• Review design basée sur screenshots qui capture une fenêtre de navigateur locale et la transmet à l’agent.

Candidats à l’automatisation distante :

• Recherche web quotidienne + rapport qui cherche les actus IA chaque matin à 6h, compile une synthèse et la pousse dans un dépôt GitHub au format Markdown. Aucun élément local. Tout se passe dans le cloud. Je me lève, git pull, je lis la veille.
• Surveillance de marque planifiée — cherche chaque heure les mentions d’une marque cliente sur le web et enregistre toute nouveauté dans une base Notion. Flux 100% cloud.
• Rédaction de newsletter depuis un flux RSS chaque dimanche soir, livrée comme brouillon sur Ghost ou Beehiiv via API. Pas d’état local.
• Recherche de leads et rédaction de prospection — extraction nocturne d’une liste de leads, recherche sur chaque entreprise, rédaction d’un email personnalisé, laissé en brouillon pour validation humaine.

La raison pour laquelle cette distinction est cruciale : le coût et la fiabilité. Un échec d’automatisation distante à 3h du matin ne coûte rien — elle recommence simplement. Une automatisation locale qui tombe à 3h du matin reste morte jusqu’à votre réveil. Mais les automatisations locales peuvent accomplir ce que les distantes ne pourront jamais, parce qu’elles opèrent directement dans votre environnement de travail.

Je répartis le framework à environ 60/40 en faveur du local, mais c’est lié à mon activité. Si votre métier est surtout SaaS, CRM, email et outils cloud-native, la balance penchera nettement vers le distant. J’ai détaillé ailleurs les canaux d’automatisation cloud de Claude Code et la première build de Claude Routines que j’ai livrée sur Opus 4.7 si vous souhaitez approfondir l’un ou l’autre sujet.

Couche Quatre : Le dashboard est tout l'intérêt

C'est ici que je veux faire une pause et une confession.

Quand j'ai entendu pour la première fois « créer un dashboard au-dessus de Claude Code », ma réaction a été celle d’un ingénieur : pourquoi ajouter une interface graphique à un outil en ligne de commande que j’utilise parfaitement ? Le terminal va plus vite. Je peux chaîner les commandes. Je peux créer des alias. Un dashboard, ça ressemble à une friction en plus, maquillée en accessibilité.

Cette réaction était erronée. Construire le dashboard a bouleversé ma manière d'utiliser Claude Code, bien plus que n'importe quel autre composant du framework.

Voici ce que je n’avais pas compris. Le terminal est optimisé pour le moment où l’on démarre une tâche. Démarrage à froid, concentration totale, café à la main — on tape la commande, c’est parti. Mais le terminal est catastrophique pour les moments entre les tâches. Vérifier ce que les automatisations nocturnes ont produit. Surveiller un job de recherche longue durée. Transmettre l’invocation d’une skill à un collègue qui ne code pas. Jeter un œil à ce qui a tourné la veille, en déjeunant. Pour toutes ces situations, un dashboard s’impose.

Ce que j’ai construit, c’est une simple app Next.js 15 qui tourne localement et expose cinq éléments :

1. Lanceur de skills — chaque skill de ma hiérarchie apparaît comme un bouton, groupé par fonction. Je clique, je remplis un petit formulaire (client, projet, paramètres), et c’est parti. Le dashboard appelle Claude Code avec la bonne commande.
2. Routines à venir — affiche tout ce qui est prévu de tourner dans les 24 prochaines heures. Je détecte les erreurs avant qu’elles ne se produisent, pas après.
3. Activité récente — un flux de tout ce que Claude a fait sur les 48 dernières heures, extrait du dossier session-logs dans mon coffre Obsidian. Chaque entrée pointe vers le log complet.
4. Utilisation du système — dépenses de tokens par skill par jour, par modèle. Cela m’aide à détecter les automations qui brûlent en douce des tokens Opus là où Haiku suffirait.
5. Boîte de réception des sorties — tout ce que Claude a produit en attente de ma relecture. Brouillons d’articles, rapports de recherche, mails à valider.

Le dashboard fait environ 800 lignes de TypeScript. Rien de complexe. Ce qui change tout, ce n’est pas le code — c’est l’évolution opérationnelle. Quand tout devient un bouton, je délègue autrement. Je délègue davantage. Je délègue à un collègue qui n’aurait jamais touché à Claude Code en ligne de commande.

Et c’est ce dernier point qui ferme vraiment la brèche d’accès. Je peux pointer un client vers le dashboard, dire « cliquez ici pour générer un brouillon de votre rapport hebdomadaire », et il tire profit de Claude Code sans jamais savoir ce que c'est. Là, on passe de l’« outil » à « l’infrastructure ».

Si vous travaillez en solo, construisez le dashboard pour vous, avant de penser aux clients. Vous serez surpris de voir à quel point votre propre comportement évolue dès que les frictions disparaissent.

Un parcours de construction pratique que vous pouvez réellement suivre

Assez parlé d’architecture. Voici la séquence que je suivrais si je devais recommencer aujourd’hui, pensée pour quelqu’un qui utilise déjà Claude Code quelques fois par semaine.

Semaine une : mémoire. Installez Obsidian (gratuit, obsidian.md). Créez un coffre (vault). Mettez en place l’arborescence de dossiers évoquée ci-dessus. Rédigez votre _claude/CLAUDE.md en cinq sections : qui vous êtes, les marques/projets sur lesquels vous travaillez, l’emplacement des fichiers, la façon dont l’agent doit rédiger, ce qu’il ne doit jamais faire. Ne vous compliquez pas la tâche. Vous le réécrirez trois fois le premier mois de toute façon. Ensuite, orientez Claude Code vers ce coffre — soit en lançant Claude Code depuis le répertoire du coffre, soit en indiquant le chemin du coffre dans votre CLAUDE.md global. Exécutez quelques tâches réelles pour voir ce que l’agent restitue.

Semaine deux : deux compétences. Sélectionnez les deux tâches que vous effectuez le plus souvent. À titre personnel, il s’agissait de « rédiger un article de blog à partir d’un résumé vidéo » et « générer un kit de diffusion social à partir d’un article ». Installez le plugin skill-creator via /plugin dans Claude Code. Utilisez-le pour esquisser chaque compétence. Testez chaque compétence cinq fois sur des inputs réels. Faites évoluer le prompt jusqu’à obtenir un résultat cohérent. Déposez ces compétences dans votre dossier personnel de compétences.

Deux compétences suffisent pour savoir si le framework correspond vraiment à votre flux de travail. N’en développez pas plus tant que celles-ci ne sont pas fiables.

Semaine trois : une automatisation. Choisissez une compétence qui bénéficierait d'un déclenchement programmé ou à la demande. Si elle requiert des fichiers locaux, branchez-la en tâche cron locale appelant Claude Code en mode headless. Sinon, utilisez Claude Routines pour la planifier dans le cloud. Une automatisation. Laissez-la tourner une semaine. Ajustez la planification. Corrigez les cas limites.

Semaine quatre : dashboard v0. Construisez la version la plus simple possible. Cinq boutons qui exécutent Claude Code en shell. Pas d’authentification, pas de base de données, tourne sur localhost:3000. Si le frontend n’est pas votre point fort, la compétence frontend-design de Claude Code générera tout à partir d’une simple description. Ma v0 se résumait à un unique composant React. La finition est venue plus tard.

À partir de la semaine cinq : ne développez que ce qui le mérite. Ajoutez une compétence dès qu’un schéma récurrent apparaît. Ajoutez une automatisation lorsque vous vous surprenez à exécuter une compétence en boucle aux mêmes horaires. Ajoutez un bouton au dashboard si vous souhaitez déléguer une tâche ou éviter de taper sans cesse la même commande. Ne développez pas pour développer. Le framework valorise la retenue : chaque compétence ajoutée est un coût de contexte-prompt que l’agent paie à chaque décision d’exécution.

Si vous souhaitez un guide pas à pas plus détaillé sur le volet « équipes d’agents », mon guide de configuration des équipes d’agents Claude Code couvre la hiérarchie des compétences bien plus en profondeur que je ne peux le faire ici.

Ce que la plupart des guides de construction se trompent

Je souhaite signaler trois points que je retrouve souvent dans d’autres articles sur les agentic OS et qui, à mon sens, sont erronés, ou du moins incomplets, après trois mois d’utilisation réelle.

« Il vous faut du RAG. » Non, ce n’est pas nécessaire. Pas à l’échelle de la plupart des opérateurs individuels ou des petites équipes. Un coffre Obsidian bien organisé avec 500 notes sera plus efficace qu’une base de données vectorielle avec un million d’embeddings, car l’organisation même fait office de système de récupération. Le RAG prend tout son sens lorsque l’on effectue des recherches sur des dizaines de milliers de documents dont la structure est imprévisible. Si vous pouvez prévoir la structure, privilégiez-la aux vecteurs. Lorsque j’atteindrai l’échelle où la recherche sémantique devient essentielle, je l’ajouterai comme une couche supplémentaire. Pas avant.

« Il faut développer chaque skill soi-même. » L’écosystème communautaire autour de Claude Code en 2026 est immense, et la majorité des guides n’en rendent pas compte. Le marketplace officiel Anthropic dispose de plugins vérifiés. Les marketplaces communautaires en listent des milliers de plus. Avant de développer une skill à partir de zéro, cherchez-la. J’ai remplacé trois de mes premières skills artisanales par des versions communautaires qui étaient meilleures. Le framework porte sur votre hiérarchie et votre couche mémoire — les skills individuelles peuvent venir de partout.

« Le tableau de bord est pour les non-techniciens. » À moitié vrai. Il s’adresse aux non-techniciens et à vous, à chaque moment où vous n’êtes pas à votre clavier en pleine concentration. J’utilise plus mon propre dashboard que quiconque dans mon équipe. Présenter cela comme une simple question « d’accessibilité pour les clients » ne rend pas justice à ce qu’une bonne UI de centre de commande apporte à celui ou celle qui l’a conçue.

Où ce framework atteint ses limites

L’honnêteté m’oblige à en nommer les limites.

Le framework suppose que vous disposez d’un workflow digne d’être encodé. Si vous travaillez sur des expérimentations ponctuelles — pics de recherche, problèmes inédits, exploration réellement créative — la surcharge des skills et des automatisations ne fera que vous ralentir. Pour les tâches créatives, j’ouvre encore simplement Claude Code, sans CLAUDE.md, sans skills, sans vault, et je le laisse tourner à l’état brut. L’agentic OS est conçu pour le travail répétable. Assurez-vous que ce que vous encodez est réellement répétable avant de le formaliser.

Il suppose aussi que vous prenez la peine de le maintenir. Les skills évoluent au fil du temps. Des prompts optimisés pour Opus 4.5 peuvent nécessiter un nouvel ajustement pour Opus 4.7. Les automatisations se brisent quand les APIs externes changent. Je consacre environ deux heures par semaine à la maintenance du framework lui-même — principalement pour mettre à jour les prompts quand le comportement du modèle change et élaguer les skills que je n’utilise plus. Ce coût de maintenance est bien réel. Si vous construisez le framework puis l’abandonnez trois mois, attendez-vous à retrouver du délabrement.

Et il suppose que vous faites confiance à Claude Code pour agir de façon autonome. Le dashboard facilite le déclenchement des skills sans y réfléchir. Les automatisations tournent sans surveillance. Si vous n’intégrez pas de points de revue dans les skills eux-mêmes, vous découvrirez tôt ou tard qu’un agent a expédié quelque chose qui n’aurait pas dû l’être. Les garde-fous doivent être inclus à l’intérieur même des définitions de skills : étapes d’auto-évaluation, barrières de vérification des outputs, conditions d’arrêt explicites. Un framework qui fonctionne vite sans contrôle est un framework qui vous fera honte à l’échelle.

Le Changement Qui Compte Vraiment

Il y a six mois, mon utilisation de Claude Code se résumait à une pile d’onglets dans le terminal et un fichier CLAUDE.md qui grossissait de 40 lignes chaque semaine. Ça fonctionnait. Mais cela ne produisait aucun effet cumulatif. Chaque nouvelle tâche impliquait de charger un contexte vierge, chaque nouveau client signifiait un fichier de plus dans un dossier que j’ouvrais à peine, chaque bon prompt que j’écrivais restait coincé dans l’historique du shell jusqu’à être effacé.

Le framework agentic OS a changé la dynamique du cumul. Une mémoire dans le vault signifie que ce que j’ai appris en mars reste exploitable en avril. Les skills permettent au prompt que j’ai optimisé pour un client de devenir celui que j’exécute pour les vingt suivants. Les dashboards font passer le travail de « Mejba doit lancer ça lui-même à 22h » à « n’importe qui dans l’équipe peut cliquer sur ce bouton ».

L’écart entre un outil puissant et une infrastructure réellement utile tient rarement à l’outil lui-même. Claude Code est capable de tout cela depuis ses premières versions. Ce qui manquait, c’était l’architecture autour. Mémoire. Cohérence. Accès. Une fois ces trois piliers réunis, tout change dans le calcul de ce que vous pouvez exécuter en solo — ou avec une mini-équipe.

Si vous ne retenez qu’une chose de ce post, construisez le vault Obsidian. C’est cette action unique qui m’a débloqué plus de possibilités que les trois autres couches réunies, car elle constitue la base sur laquelle tout repose. Les skills ont besoin d’une mémoire pour rester cohérents. Le dashboard a besoin des logs de session à afficher. Les automatisations exigent un espace pour écrire des outputs lisibles par d’autres.

Votre Claude Code fonctionne bien aujourd’hui. La vraie question, c’est si la centième utilisation vous apportera plus de valeur que la première — ou si ce sera simplement la même chose, répétée cent fois.

Foire Aux Questions

Qu’est-ce qu’un framework d’OS agentique pour Claude Code ?

Un framework d’OS agentique est une architecture qui enveloppe Claude Code dans quatre couches — mémoire persistante, compétences hiérarchisées, automatisations locales et distantes, et un tableau de bord — afin que l’agent retienne le contexte entre les sessions, exécute les tâches de façon cohérente, et puisse être utilisé par des coéquipiers non techniques. Cela transforme Claude Code d’un simple outil en ligne de commande en une véritable infrastructure opérationnelle. La répartition architecturale complète est détaillée dans la section « Qu’est-ce qu’un OS agentique ? » ci-dessus.

Ai-je besoin d’une pipeline RAG pour donner de la mémoire à Claude Code ?

Non, la plupart des workflows n’ont pas besoin de RAG. Un coffre-fort Obsidian de notes Markdown structurées, avec un point d’entrée _claude/CLAUDE.md, confère à Claude Code une mémoire persistante sans la complexité des embeddings vectoriels. Claude Code lit nativement du Markdown, donc le coffre-fort sert à la fois de stockage et de mécanisme de récupération. N’ajoutez RAG que si vous avez besoin d’une recherche sémantique à travers des dizaines de milliers de documents non structurés.

Quelle est la différence entre les automatisations locales et distantes Claude Code ?

Les automatisations locales s’exécutent sur votre machine et peuvent accéder au système de fichiers, aux CLI locales et aux coffres Obsidian — elles sont idéales pour les pipelines de recherche, le travail sur les bases de code, et toute tâche impliquant des fichiers locaux. Les automatisations distantes s’exécutent dans le cloud via Claude Routines et fonctionnent indépendamment de votre machine — elles conviennent par exemple pour les recherches web programmées, la veille de marque, et les workflows nécessitant des API cloud. Règle de décision : si la compétence doit accéder à un élément local, exécutez-la en local.

En quoi les compétences Claude Code diffèrent-elles des plugins ?

Les plugins sont le format de distribution ; les compétences en sont le contenu. Un plugin est un dossier comportant un manifeste plugin.json qui peut regrouper une ou plusieurs compétences (fichiers SKILL.md) ainsi que des commandes slash et des hooks. Vous installez un plugin via la commande /plugin dans Claude Code, ce qui importe automatiquement ses compétences. Depuis avril 2026, le marketplace officiel d’Anthropic et les marketplaces communautaires comme tonsofskills.com hébergent des milliers de plugins et de compétences.

Des utilisateurs non techniques peuvent-ils réellement utiliser Claude Code via un tableau de bord ?

Oui, et c’est l’objectif pratique d’en créer un. Un tableau de bord Next.js local avec des boutons de compétence cliquables, l’activité récente et les routines à venir permet à tout le monde de déclencher des workflows Claude Code sans toucher au terminal. En arrière-plan, le tableau de bord exécute Claude Code — l’utilisateur ne voit que des boutons, des clics et des résultats. C’est ainsi que je transmets des compétences à mes clients et coéquipiers qui n’ont jamais ouvert un terminal.

Travaillons ensemble

Vous souhaitez créer des systèmes d’IA, automatiser des workflows ou faire évoluer votre infrastructure technique ? Je serais ravi de vous accompagner.

• Fiverr (réalisations sur mesure & intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions d’entreprise) : ramlit.com
• ColorPark (design & branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io