J'ai Construit Mon Système d'Exploitation IA Avec Claude Code

Pendant neuf ans, j'ai essayé chaque stack de productivité sur le marché. Notion. ClickUp. Obsidian par-dessus Notion. Sunsama connecté au Calendar. Sept abonnements SaaS simultanés qui promettaient tous d'être la « source unique de vérité » et aucun ne l'a jamais été. La vérité honnête est qu'aucun de ces outils ne pensait réellement avec moi — ils ne faisaient que stocker des choses que j'avais déjà pensées.

Cela a changé il y a trois mois quand j'ai reconstruit l'intégralité de mon workflow dans un seul outil : Claude Code. Pas comme assistant de programmation. Comme système d'exploitation. Un vrai — avec des skills, des routines, des agents cloud programmés, un wiki de connaissances en markdown et des tableaux de bord en direct qui tirent des données de ClickUp, Stripe, QuickBooks, Fireflies et Slack à la demande.

Voici le plan complet. Les frameworks que j'ai utilisés (les Trois M et les Quatre C), les sept blocs de données avec lesquels j'ai commencé, la structure exacte du dépôt, les skills que j'ai publiés en premier, et le système de notation d'audit que j'exécute chaque dimanche matin pour vérifier si le système d'exploitation IA Claude Code se comporte réellement comme tel.

Si vous essayez de coller ChatGPT plus Zapier plus sept tableaux de bord ensemble et vous demandez pourquoi vous vous sentez toujours occupé — voici ce que je construirais à la place, sachant ce que je sais maintenant.

Pourquoi les stacks de productivité m'ont déçu en 2026

Voici ce que personne ne m'a dit quand j'ai acheté mon quatrième template Notion. Le goulot d'étranglement en 2026 n'est pas le stockage d'information. C'est la récupération d'information au moment de la décision. Quand un client envoie un email à 16h47 demandant pourquoi le livrable trois a deux jours de retard, je n'ai pas besoin d'ouvrir mon « second cerveau ». J'ai besoin d'une réponse en neuf secondes.

Les outils de productivité traditionnels partagent tous le même défaut fatal — ils supposent que je suis le moteur. L'outil stocke. Je pense. Je croise les références. Je synthétise. J'écris l'email. La page Notion ne rédige pas la réponse. La tâche ClickUp ne rapproche pas de la facture Stripe. La transcription Fireflies ne fait pas remonter la seule décision d'un appel de 47 minutes qui compte vraiment cette semaine.

Quand les premiers runtimes d'agents utiles sont apparus — Anthropic a lancé le Claude Agent SDK fin 2025, puis a ouvert les skills comme primitif de première classe, puis a publié des routines hébergées dans le cloud le 14 avril 2026 — le coût de construction de son propre système s'est effondré. Ce qui nécessitait auparavant un stack à $40K avec Zapier-plus-Make-plus-trois-ingénieurs tient maintenant dans un seul dépôt de fichiers markdown.

J'ai donc supprimé la moitié de mon stack SaaS et recommencé de zéro. Le résultat est ce que j'appelle un AIOS : un système d'exploitation IA qui pense avec moi, pas derrière moi.

Ce qu'est réellement un AIOS (et ce qu'il n'est pas)

Un système d'exploitation a trois tâches. Gérer les ressources. Servir d'intermédiaire entre vous et votre matériel. Exécuter des programmes en votre nom quand vous le demandez.

Un système d'exploitation IA fait la même chose — mais les ressources qu'il gère sont cognitives. Vos contextes. Vos décisions. Vos relations. Vos projets. Le matériel qu'il médiatise est votre cerveau plus les dizaines d'APIs SaaS sur lesquelles tourne votre entreprise. Les programmes qu'il exécute sont des skills, des routines et des tâches programmées qui tournent que vous soyez à votre bureau ou endormi.

C'est la partie que les gens ratent. Un AIOS n'est pas un chatbot avec de la mémoire. Ce n'est pas un remplacement de Notion. C'est un runtime qui maintient votre contexte, possède vos connexions, expose vos capacités sous forme de skills nommés et les exécute selon une cadence que vous définissez.

Quatre propriétés séparent un vrai AIOS d'un template de prompt sophistiqué :

1. Il maintient votre contexte entre les sessions. Plus besoin de réexpliquer qui vous êtes.
2. Il se connecte aux données en direct. Il tire de vos vrais outils, pas d'exportations obsolètes.
3. Il expose des capacités comme des skills nommés et réutilisables. Pas des prompts à usage unique.
4. Il s'exécute selon sa propre cadence. Certains skills vous les déclenchez ; d'autres tournent seuls à 6h du matin.

Si un système que vous construisez ne fait pas les quatre, vous avez un chatbot. Utile — mais pas un système d'exploitation.

La bonne nouvelle : Claude Code vous donne déjà le runtime gratuitement. Le travail est dans l'architecture que vous construisez à l'intérieur. Ce qui m'amène aux deux frameworks qui ont tout organisé pour moi.

Les Trois M : Mentalité, Méthode, Machine

Avant tout code, toute structure de dossiers, tout skill — trois couches. Passez-les et la construction s'effondre en semaine deux. J'ai appris cela à la dure quand ma première tentative s'est transformée en 31 fichiers markdown désorganisés que même Claude ne pouvait pas naviguer.

Mentalité

Le changement de mentalité est petit mais porteur : l'IA n'est pas un distributeur automatique. C'est un mentor.

Un distributeur automatique prend une pièce et donne un snack. Vous demandez, vous obtenez. Un mentor prend la question, vous en pose trois en retour, vous fait défendre votre raisonnement et vous dit parfois que la question elle-même est mauvaise. C'est la relation que vous voulez avec votre AIOS. Vous ne voulez pas un système qui dit toujours oui. Vous en voulez un qui dit « avant de rédiger cette proposition, êtes-vous sûr que le niveau de prix B convient au stade de ce client ? Sa dernière facture était de 2 400 € ».

Cela semble philosophique. C'est profondément pratique. Chaque skill que vous écrivez est configuré par défaut soit pour « exécuter la demande » soit pour « interroger la demande d'abord ». Un système mentor est construit sur le second mode.

Méthode

La méthode est le playbook de comment vous et l'AIOS travaillez ensemble. Le mien a quatre règles :

• Planifier avant d'exécuter. Chaque skill non trivial retourne d'abord un plan. J'approuve le plan, puis il exécute.
• Citer la source. Chaque affirmation est liée à un fichier, une transcription ou une réponse d'API. Pas de feeling.
• Mettre à jour le wiki. Chaque décision significative devient un fichier markdown que les sessions futures peuvent lire.
• Auditer selon une cadence. Score hebdomadaire des Quatre C (plus à ce sujet ci-dessous). Le chiffre ne ment pas.

Ces règles vivent dans le CLAUDE.md racine de mon dépôt AIOS. Chaque session Claude Code les lit automatiquement.

Machine

La machine est le stack réel — l'IDE, le dépôt, les skills, les connecteurs, le planning cron. Nous construirons la machine dans un instant. Le point des Trois M est que Mentalité et Méthode passent en premier. Si vous allez directement à la Machine, vous construirez un distributeur automatique plus rapide. Ce qui est précisément ce que j'ai fait la première fois.

Les Quatre C : La véritable architecture

Là où les Trois M parlent de comment vous pensez, les Quatre C parlent de ce que vous construisez. Context. Connections. Capabilities. Cadence. Dans cet ordre exact. Ils ont une dépendance séquentielle — vous ne pouvez pas sauter en avant.

Context (la fondation)

Context est tout ce que le système sait sur vous. Votre entreprise, vos clients, vos objectifs, votre ton, vos décisions, vos contraintes. Sans Context, l'AIOS traite chaque prompt comme un premier rendez-vous.

Context vit en markdown. Toujours markdown. Karpathy avait raison quand il a dit que le format adapté aux LLM est du texte brut dans un dossier que vous contrôlez — il y a un gain d'efficacité de tokens de 70x par rapport à RAG et aux bases de données vectorielles pour les bases de connaissances à échelle personnelle, et c'est plus facile à déboguer parce que vous pouvez lire les fichiers vous-même.

Connections

Une fois que le système sait qui vous êtes, il doit atteindre le monde. Connections sont vos APIs et intégrations — ClickUp, Google Workspace, Fireflies, Slack, Stripe, QuickBooks. Sans Connections, l'AIOS est un carnet intelligent. Avec Connections, il peut lire votre calendrier en direct, tirer les revenus d'hier, scanner les transcriptions de ce matin et agir.

Capabilities

Capabilities sont des skills — des compétences nommées et réutilisables que le système peut exécuter. « Rédiger un plan quotidien. » « Auditer mon score des Quatre C. » « Générer le calendrier de contenu de la semaine prochaine à partir de mes commentaires YouTube. » Chacun est un dossier avec un fichier SKILL.md. Le modèle de divulgation progressive d'Anthropic signifie que des centaines de skills peuvent siéger dans votre dépôt et seul le pertinent est chargé dans le contexte pour toute tâche donnée.

Cadence

Cadence détermine quand les choses tournent. Certains skills vous les déclenchez ("/daily-plan"). Certains tournent par cron ("chaque lundi 6h00, auditer la semaine dernière"). Certains vivent dans le cloud et répondent aux événements GitHub. Cadence est ce qui transforme un assistant intelligent en un système d'exploitation qui travaille pendant que vous dormez.

La dépendance séquentielle est ce que la plupart des gens font mal. Vous ne pouvez pas avoir de Cadence utile sans Capabilities. Vous ne pouvez pas construire de Capabilities utiles sans Connections. Vous ne pouvez pas utiliser Connections intelligemment sans Context. Alors nous les construisons dans l'ordre. Un à la fois. Sans sauter.

C'est aussi là qu'intervient l'audit — mais je garde le barème de notation pour la fin, après que nous ayons effectivement construit la chose.

Étape 1 : Les données du plan — Sept blocs Tier-Un

Avant tout dossier, tout code, tout skill — je me suis assis et j'ai listé chaque type d'information que mon travail touche. Puis je les ai impitoyablement réduits à sept blocs. Sept, parce que c'est à peu près la limite avant que le système commence à ressembler à un labyrinthe. Les vôtres pourraient être six ou huit. L'exercice compte plus que le nombre.

Mes sept blocs Tier-Un :

1. Revenus — Paiements Stripe, grand livre QuickBooks, MRR, créances
2. Clients — liste de clients, statut, dernier contact, valeur vie client, livrables actuels
3. Calendrier — Feed Google Calendar, cette semaine, les deux prochaines semaines, blocs récurrents
4. Communication — Fils Gmail, DMs Slack, notifications de commentaires à suivre
5. Tâches — Listes ClickUp par projet, liste du jour, liste de la semaine, éléments bloqués
6. Réunions — Transcriptions Fireflies, décisions extraites, éléments d'action extraits
7. Connaissances — le wiki lui-même : clients, produits, décisions, références, leçons

Chaque skill que j'écris touche au moins un de ces blocs. Souvent trois ou quatre. La liste des blocs est devenue le contrat : si une question ne peut pas être répondue à partir de l'un de ces sept, mon AIOS n'a pas le droit de l'inventer. Il me dit soit quel bloc remplir, soit il demande. Pas d'hallucination parce que la forme des données est finie et nommée.

Ça semble ennuyeux. C'est de loin l'étape la plus importante. Si vous la sautez, vous construirez des skills qui tirent de partout et votre contexte deviendra de la bouillie. Les blocs forcent la discipline.

Étape 2 : VS Code, Claude Code et la structure du dépôt

La machine elle-même est honteusement simple. VS Code comme éditeur. Claude Code (npm install -g @anthropic-ai/claude-code) comme runtime. Un seul dépôt Git comme système d'exploitation entier.

Voici la structure exacte de dossiers que j'utilise :

aios/
├── CLAUDE.md                    # prompt système racine : mentalité + méthode
├── .env                          # clés API (gitignored)
├── .gitignore
├── .cloud/                       # configs de routines cloud (synchronisées avec Anthropic cloud)
│   └── routines/
├── context/                      # les sept blocs, en markdown
│   ├── revenue.md
│   ├── customers.md
│   ├── calendar.md
│   ├── communication.md
│   ├── tasks.md
│   ├── meetings.md
│   └── knowledge/                # le wiki LLM vit ici
│       ├── clients/
│       ├── products/
│       ├── people/
│       └── _index.md
├── decisions/                    # un .md par décision importante, daté
│   └── 2026-04-19-pricing-tier-update.md
├── references/                   # référence statique : SOPs, guides de marque, prompts
│   └── brand-voice-mejba-me.md
├── archives/                     # choses de plus de ~90 jours
└── .claude/
    ├── skills/                   # skills personnels (locaux)
    │   ├── onboard/
    │   ├── daily-plan/
    │   ├── four-cs-audit/
    │   ├── linkedin-post/
    │   └── youtube-comment-analysis/
    └── agents/                   # sous-agents

Cinq règles gouvernent ce layout, et j'ai enfreint chacune d'entre elles une fois et je l'ai regretté :

• Le CLAUDE.md racine est court. Moins de 200 lignes. Il se charge à chaque session — le gonfler et vous saignez des tokens.
• Les fichiers context/ sont les blocs. Un fichier par bloc, maximum 800 lignes, puis diviser.
• decisions/ est en ajout seul. Ne modifiez jamais un fichier de décision. Nouvelle décision, nouveau fichier, daté.
• archives/ existe pour une raison. Tout ce qui a plus de ~90 jours et n'est pas activement référencé y va. Le système ne devrait pas relire vos pensées de janvier chaque mai.
• .cloud/ se synchronise avec Anthropic. Ne mettez que les routines cloud et les skills que vous voulez exécutables en sessions cloud. Les skills locaux restent dans .claude/skills/.

La distinction .cloud/ compte. Les routines cloud d'Anthropic (preview de recherche ouverte le 14 avril 2026) n'accèdent qu'aux skills au niveau projet commitées dans le dépôt. Les skills personnels dans ~/.claude/skills/ ne voyagent pas. Si vous voulez qu'une routine exécute un skill sur l'infrastructure d'Anthropic pendant la nuit, ce skill doit être enregistré dans le dépôt.

Si vous n'avez jamais configuré un dépôt Claude Code avant, mon guide de configuration des équipes d'agents couvre les bases plus en détail. À partir d'ici, je suppose que vous avez claude qui fonctionne dans un dossier vierge.

Étape 3 : Le skill d'onboarding — Apprendre au système qui vous êtes

Le premier skill que j'ai construit ne fait rien d'impressionnant. Il m'interviewe. C'est tout.

Je l'ai appelé onboard. Quand j'exécute /onboard, Claude parcourt environ 40 questions sur les sept blocs — quel est mon modèle d'affaires, qui sont mes cinq meilleurs clients, quel est mon taux horaire, quelle est ma voix de marque, à quoi ressemble une « bonne semaine », ce que je ne poursuis délibérément pas, quels sont mes non-négociables. Chaque réponse va dans le fichier de contexte correspondant en markdown structuré.

Pourquoi guidé par entretien ? Parce que si je m'asseyais pour écrire customers.md de zéro, je procrastinerais trois semaines. La conversation n'a pas de friction. Le skill transforme mes paroles en contexte structuré que le système peut utiliser pour toujours.

Voici le SKILL.md abrégé :

---
name: onboard
description: Interview the user across the seven AIOS buckets and populate the context/ folder with structured markdown. Use when the user types /onboard or asks to set up their AIOS for the first time.
---

# Onboarding Skill

You are interviewing the user to populate their AI operating system's context.
Work through the seven buckets in order: Revenue, Customer, Calendar,
Communication, Tasks, Meetings, Knowledge.

For each bucket:
1. Ask 4-7 specific questions, one at a time.
2. After each answer, restate what you heard in one sentence.
3. When the bucket is done, write the markdown file to context/[bucket].md.
4. Show the user the file. Ask if anything's wrong before continuing.

Rules:
- Never invent answers. If the user doesn't know, write "TBD" with a date.
- Cite the source of every fact (e.g., "per user, 2026-04-15").
- Keep each context file under 800 lines. If longer, split.

Output format: structured markdown with H2 sections per topic, bulleted facts.

C'est tout. ~25 lignes y compris le frontmatter. Le skill ne se charge que quand il est appelé, coûte essentiellement zéro tokens au démarrage de session et produit la fondation dont tout le reste dépend. Après avoir exécuté /onboard une fois, chaque session future commence en sachant exactement qui je suis et sur quoi je travaille.

C'est aussi le bénéfice le plus sous-estimé du primitif de skills : vous pouvez écrire un skill dont le seul travail est de peupler le contexte que les futurs skills liront. Le système s'auto-amorce.

Étape 4 : La couche Connections — Connectez vos vrais outils

C'est là que la plupart des builds d'AIOS personnel stagnent. Les gens imaginent qu'ils ont besoin d'un serveur MCP personnalisé pour chaque outil. Ce n'est pas le cas. Dans 90% des cas, la bonne réponse est un appel API direct depuis un skill, avec les identifiants dans .env.

J'expliquerai pourquoi j'ai choisi API-first plutôt que MCP, puis je passerai en revue les intégrations réelles.

Pourquoi API > MCP pour des connections à échelle personnelle

Les serveurs MCP sont merveilleux pour les systèmes d'agents distribués où plusieurs clients ont besoin d'un protocole partagé. Pour un AIOS personnel où vous contrôlez les deux bouts, les serveurs MCP ajoutent un overhead de tokens — le schéma d'outils de chaque serveur est chargé dans le contexte que vous l'utilisiez ou non. Un appel direct curl ou fetch dans un skill ne coûte rien jusqu'à ce que le skill tourne.

Règle générale à laquelle je suis arrivé : si un outil est utilisé par plus de trois skills et je veux qu'il soit accessible depuis n'importe quelle session sans prompting, j'écris un wrapper MCP. Sinon, appel API brut depuis le skill concerné. Pour un AIOS solo, cela signifie que presque tout reste en appel API brut.

Les intégrations réelles que j'ai câblées

La discipline du .env

Chaque clé API dans .env. .env est dans .gitignore. Sans exception. Si vous avez un jour comme moi en 2022 poussé un .env sur GitHub — vous savez que le scanner de secrets de GitHub vous attrape en quelques minutes, votre clé est révoquée et vous passez un samedi à faire tourner les identifiants. Ne soyez pas le moi de 2022.

Pour Stripe et QuickBooks, j'utilise des clés restreintes/lecture seule pour tout ce que l'AIOS fait de façon autonome. Les opérations d'écriture nécessitent une session interactive où j'approuve l'action. Ce n'est pas de la paranoïa — c'est le même principe que de ne pas donner un accès en écriture à la production à un ingénieur junior le premier jour.

Comptes AIOS dédiés

C'est la partie qui m'a pris le plus de temps à comprendre. Pour Slack, Fireflies et (quand c'est possible) Google Workspace, j'ai créé un compte de service dédié utilisé uniquement par l'AIOS. Pourquoi ? Parce qu'au moment où vous laissez votre AIOS publier sur Slack en tant que vous, chaque notification Slack apparaît dans votre journal d'audit comme des actions que vous avez effectuées. C'est un désordre pour la traçabilité et pire si vous devez un jour déboguer si vous avez envoyé le message ou votre AIOS.

Le compte dédié s'appelle « Mejba (AIOS) » et a un avatar clairement différent. Quand il publie dans un canal, tout le monde sait que c'est l'AIOS. Quand je publie, c'est moi. Les équipes de conformité et votre futur vous remercient votre vous présent.

Pour plus de détails sur la sécurisation des identifiants d'agents et des webhooks, mon guide d'onboarding sécurisé des agents IA couvre le modèle de menaces en détail.

Étape 5 : Capabilities — Les skills qui gagnent vraiment leur place

C'est la section qui m'a pris le plus de temps dans la construction réelle, et celle sur laquelle on me pose le plus de questions. Les skills sont là où l'AIOS cesse d'être théorique et commence à vous faire gagner des heures. Je montrerai la structure, puis je passerai en revue cinq vrais skills que j'ai publiés.

Anatomie du SKILL.md

Selon la documentation officielle des skills d'Anthropic, chaque skill est un dossier contenant au minimum un fichier SKILL.md avec :

---
name: kebab-case-name
description: One-sentence trigger description. Claude reads this to decide when to use the skill.
allowed-tools: Read, Write, Bash, WebSearch  # optional
---

# Skill Name

[Instructions Claude follows when this skill loads]

## When to use
## What to do
## Output format
## Constraints

Gardez SKILL.md en dessous de 500 lignes selon la recommandation d'Anthropic. Besoin de plus ? Ajoutez REFERENCE.md, EXAMPLES.md ou des scripts exécutables dans le même dossier. Claude ne charge les fichiers supplémentaires que quand il en a réellement besoin — c'est le modèle de divulgation progressive et la raison pour laquelle vous pouvez exécuter des centaines de skills sans consommer de tokens.

Skill 1 : /daily-plan

Le skill qui a prouvé sa valeur en premier. Chaque matin à 6h30 (déclenché par cron) il produit un plan quotidien d'une page qui :

• Lit context/calendar.md et le feed en direct de Google Calendar pour aujourd'hui
• Lit context/tasks.md et tire les 8 principales tâches ClickUp pondérées par échéance + priorité
• Scanne les transcriptions Fireflies d'hier pour les éléments d'action engagés
• Croise avec decisions/ pour tout ce que j'ai dit vouloir revoir cette semaine
• Rédige un plan en 3 blocs : bloc de travail profond, bloc de communications, bloc administratif
• L'écrit dans daily/2026-04-19.md et m'envoie un résumé sur Slack à 7h00

Temps gagné par jour : ~20 minutes du surcoût « par quoi je commence », avec des choix de priorité mesurables meilleurs parce que le système sait réellement ce à quoi je me suis engagé lors de l'appel client de mardi dernier.

Skill 2 : /linkedin-post

J'écris un post LinkedIn presque tous les jours. La première version de ce skill produisait de la bouillie générique. La version actuelle lit :

• context/knowledge/brand-voice-mejba-me.md (mes règles de voix)
• Les 30 derniers jours de posts LinkedIn que j'ai réellement publiés (tirés via export)
• Le plan d'aujourd'hui daily/[date].md, plus le fichier de décision le plus récent
• URL optionnelle que l'utilisateur passe

Il retourne trois brouillons dans trois angles différents — contrarian, récit, tactique — et indique à quel post précédent chaque brouillon ressemble le plus en style. J'en choisis un, j'édite, je publie. ~12 minutes pour un post terminé contre les 35 que ça prenait avant.

Skill 3 : /youtube-comment-analysis

Je reçois quelques centaines de commentaires YouTube par semaine sur mes vidéos. La plupart sont du bruit. Certains sont de l'or pour des idées de contenu. Ce skill tire les commentaires des 7 derniers jours via l'API YouTube Data, les regroupe par thèmes, fait ressortir les trois fils avec le plus d'engagement et propose des angles de contenu pour chacun. Tourne le dimanche soir. L'idée vidéo du mardi est généralement choisie à partir de ce résultat.

Skill 4 : /slide-deck

Pour les propositions clients. Lit le fichier du client dans context/knowledge/clients/[slug].md, la portée du deal dans context/customers.md et un template de diapositives dans references/. Produit un plan structuré en markdown, puis génère des slides Marp. A réduit un workflow de deck de 90 minutes à 25.

Skill 5 : /four-cs-audit

C'est le skill qui audite l'AIOS lui-même. Nous y reviendrons dans un instant car c'est celui qui transforme l'ensemble du système en boucle de rétroaction. Pour l'instant : il note Context, Connections, Capabilities et Cadence chacun sur 25 et écrit le résultat dans audits/[date].md.

Skill 6 : /level-up

Jumeau de l'audit. Lit le dernier fichier d'audit, identifie la dimension avec le score le plus bas et propose les trois actions à plus fort impact pour améliorer ce score avant l'audit de la semaine prochaine. C'est ainsi que le système me dit quoi construire ensuite.

J'ai ~22 skills au total maintenant. La liste grandit de 1 à 3 par semaine. Certains meurent vite parce qu'ils ne gagnent pas leur place. C'est normal. Un skill est un fichier markdown de 30 lignes — le coût d'en écrire un est si bas que « supprimer et réécrire » bat « planifier soigneusement ».

Étape 6 : Cadence — Routines, Cron et le cloud

Les skills vous les déclenchez. Les routines tournent toutes seules. C'est ce qui fait passer un AIOS d'utile à autonome.

Routines locales vs. cloud

Deux variantes d'exécution programmée existent depuis mai 2026 :

• Tâches programmées locales — votre laptop les exécute via cron ou un job launchd qui invoque claude en mode headless. Fonctionne bien si votre laptop est allumé. Ne fonctionne pas s'il ne l'est pas.
• Routines cloud — hébergées par Anthropic, ouvertes en preview de recherche le 14 avril 2026. Tournent sur l'infrastructure d'Anthropic, continuent de fonctionner quand votre laptop est fermé, configurées sur claude.ai/code/routines ou via /schedule.

Selon la propre documentation des routines d'Anthropic, chaque routine est une configuration Claude Code sauvegardée — un prompt, un ou plusieurs dépôts et un ensemble de connecteurs. Les déclencheurs peuvent être programmés (cron ou langage naturel comme « chaque lundi 6h »), API (HTTP POST avec bearer token) ou événements GitHub (PRs, releases). Limites du plan en preview : Pro 5/jour, Max 15/jour, Team et Enterprise 25/jour.

Ma cadence actuelle

La limite de boucle de 3 jours mérite une note. Les tâches longues qui bouclent indéfiniment brûleront votre budget de tokens plus vite que prévu. Je plafonne tout skill de boucle à 3 jours max, avec une condition de sortie stricte. Pour du travail véritablement à long terme, programmez une nouvelle routine — ne laissez pas une session tourner pendant une semaine.

Programmation en langage naturel

La commande /schedule accepte le langage naturel. « Exécute /four-cs-audit chaque dimanche à 7h et envoie-moi le résultat sur Slack. » Cela se traduit en une expression cron en coulisses. Vous n'avez plus besoin de mémoriser la syntaxe cron. (Bien que connaître 0 7 * * 0 ne fasse pas de mal.)

Monitoring et débogage

Chaque routine écrit un journal d'exécution dans .cloud/runs/[date]/[routine-name].md (ou son équivalent cloud visible sur claude.ai/code/routines). Je passe en revue les exécutions échouées une fois par semaine. Le mode de défaillance le plus courant de loin est les limites de taux d'API — Stripe est le plus gros coupable. La correction est presque toujours « ajouter un délai de 200ms entre les appels » ou « regrouper la requête ».

Si une routine échoue trois fois de suite, je suis pingé sur Slack. L'échec silencieux est pire que l'échec bruyant.

Pour en savoir plus sur l'automatisation du travail récurrent spécifiquement avec la couche de programmation de Claude Code, mon tutoriel sur les vérifications SEO via routines montre le même modèle appliqué à un seul domaine.

Le wiki de connaissances LLM — Mon second cerveau à la Karpathy

C'est la partie de mon AIOS qui m'a le plus surpris. Je m'attendais à ce que les skills et les routines soient la victoire. Ce qui a réellement changé ma façon de penser est le wiki.

Fin 2025, Andrej Karpathy a publié le gist du LLM Wiki — un modèle où au lieu de fourrer des notes dans une base de données vectorielle, vous maintenez des fichiers markdown simples dans un dossier et laissez le LLM les lire directement. VentureBeat a couvert l'approche peu après. L'affirmation benchmarkée, répétée à travers les implémentations, est d'environ 70x plus efficace en tokens que RAG pour les bases de connaissances à échelle personnelle qui tiennent dans la fenêtre de contexte d'un modèle.

J'héberge mon wiki sous context/knowledge/ et le visualise via Obsidian pour la vue graphe. Claude Code lit les mêmes fichiers directement via le système de fichiers.

Ce qui va dans le wiki

• Clients — un fichier par client, avec tous les faits pertinents, l'historique, les décisions, les normes de communication
• Produits — chaque produit/service que je vends, avec le positionnement, les niveaux de prix, les objections courantes
• Personnes — recommandations, fournisseurs, collaborateurs, avec le contexte relationnel
• Leçons — choses que j'ai apprises à la dure, écrites pour que le futur moi ne répète pas l'erreur
• Décisions — chaque décision non triviale, datée, avec le raisonnement préservé

Pourquoi markdown bat une base de données vectorielle à cette échelle

Trois raisons qui comptent dans l'usage quotidien :

1. Vous pouvez le lire. Quand quelque chose semble faux, vous faites cat sur le fichier. Avec une base de données vectorielle vous interrogez des embeddings.
2. Le LLM peut le réécrire proprement. L'intuition entière de Karpathy était que les LLMs sont maintenant assez bons pour maintenir un wiki, pas juste le consulter. Le mien réorganise ses propres fichiers chaque semaine.
3. Il charge du texte exact dans le contexte. Pas de flou de similarité d'embeddings. Le modèle voit le fichier et raisonne dessus.

Pour une couverture plus approfondie de ce modèle spécifique, voir Obsidian + Claude Code comme mémoire persistante et l'approche super-skills qui combine le wiki de Karpathy avec les primitifs de skills de Claude Code.

Le wiki m'a pris environ trois week-ends à peupler. C'est maintenant la partie la plus référencée de mon AIOS et la partie que je perdrais en dernier.

Artefacts et tableaux de bord — Extractions en temps réel

Parfois je ne veux pas un chat. Je veux un tableau de bord. Les skills peuvent retourner des artefacts Claude — des panneaux interactifs HTML/JS qui se rendent dans la vue chat et se rafraîchissent à la demande en relançant les appels API sous-jacents.

Mes cinq tableaux de bord les plus utilisés :

• MRR Pulse — Revenus Stripe des 30/60/90 derniers jours, taux de churn, principaux clients contributeurs
• AR Aging — Factures impayées groupées par 0-30 / 31-60 / 60+ jours
• Client Health — Pour chaque client actif : jours depuis le dernier contact, statut actuel des livrables, bloqueurs ouverts ClickUp
• Densité de calendrier — 14 prochains jours, % de temps en réunions vs travail profond, codé par couleur
• Backlog de décisions — Chaque tag « TBD » ou « à revoir avant X » de decisions/ qui est en retard

Chacun est un skill qui récupère des données en direct et rend un artefact. Pas d'outil de tableau de bord SaaS. Pas de service tiers. Les données vivent là où elles vivent ; le tableau de bord est généré à la demande. Le coût total se mesure en appels API, pas en frais d'abonnement.

La boucle quotidienne et hebdomadaire

Voici le rythme qui a émergé après environ six semaines. Je le montre parce que la boucle est le système. Sans elle, vous avez un joli dossier de markdown.

Quotidien

Hebdomadaire

Le système tourne que je sois impliqué ou non. Les audits me forcent à m'impliquer le dimanche matin. C'est toute la boucle.

La notation d'audit des Quatre C — Comment je sais que ça marche vraiment

Chaque dimanche à 7h le skill /four-cs-audit tourne et me donne un nombre sur 100. Vingt-cinq points chacun pour Context, Connections, Capabilities, Cadence. Le nombre est brutal parce qu'il devrait l'être.

Barème de notation (simplifié)

Context (sur 25)

• Les 7 blocs peuplés et mis à jour dans les 14 derniers jours : 15 pts
• Le wiki a ≥1 fichier par client/produit actif : 5 pts
• Pas de tags « TBD » de plus de 30 jours : 5 pts

Connections (sur 25)

• Chaque intégration testée dans les 14 derniers jours : 4 pts chacune (max 20)
• Tous les identifiants dans .env, aucun dans les skills : 5 pts

Capabilities (sur 25)

• ≥10 skills fonctionnels : 5 pts
• Chacun des 5 skills les plus utilisés a tourné avec succès ≥3 fois cette semaine : 15 pts
• ≥1 nouveau skill publié dans les 14 derniers jours : 5 pts

Cadence (sur 25)

• ≥1 routine quotidienne qui tourne : 5 pts
• ≥1 routine hebdomadaire qui tourne : 5 pts
• Audit + level-up tournent automatiquement : 10 pts
• Zéro échec silencieux (chaque échec vous a pingé) : 5 pts

Mon premier audit (vrais chiffres)

Quand j'ai noté mon AIOS pour la première fois — six semaines après le début de la construction — il a atterri à 54,5/100 :

• Context : 18/25 — Les blocs étaient peuplés mais le wiki avait trois fichiers clients « TBD » de plus d'un mois
• Connections : 16/25 — Stripe et ClickUp étaient solides, l'OAuth QuickBooks avait échoué depuis 9 jours et je ne l'avais pas remarqué
• Capabilities : 15,5/25 — 12 skills construits, mais 4 d'entre eux je ne les avais jamais utilisés depuis la semaine un
• Cadence : 5/25 — J'avais des jobs cron mais pas de vraies routines cloud, et l'échec silencieux de QuickBooks prouvait que mon monitoring était cassé

54,5 sur 100. Après six semaines de travail. Ce chiffre a été le retour le plus utile que le système m'ait jamais donné. Il m'a dit exactement où me concentrer en semaine sept (corriger le monitoring, mettre en place les routines cloud, tuer les quatre skills morts).

En semaine dix, j'étais à 81. L'audit est la boucle de rétroaction qui fait que tout s'améliore avec le temps. Sans lui, j'aurais continué à construire des skills que personne — moi inclus — n'utilisait réellement.

Mon avis — Les leçons qui m'ont pris trois mois à gagner

Six semaines dedans, j'ai failli abandonner. La productivité a empiré avant de s'améliorer. Je passais 12 heures par semaine sur l'AIOS lui-même au lieu du travail client, et les premiers skills ne gagnaient pas encore leur place. C'est le creux de productivité et il est réel. Planifiez-le.

La forme est approximativement :

• Semaines 1-3 : Net négatif. Vous construisez, déboguez, peuplez le contexte, apprenez les particularités de Claude Code.
• Semaines 4-7 : Seuil de rentabilité. Les premiers skills commencent à faire gagner du temps réel. Le système vous connaît assez pour être utile.
• Semaines 8+ : Gains composés. Chaque nouveau skill prend moins de temps à construire parce que vous réutilisez le contexte. Chaque routine ajoute de la marge à votre semaine.

En semaine dix, je récupérais ~14 heures par semaine de surcoût administratif. En semaine douze, ~19. Le creux est le droit d'entrée. Payez-le volontairement, pas par accident.

Trois autres leçons que je me tatouerais sur l'avant-bras si je pouvais :

1. Visez 30-75% d'automatisation par tâche, pas 100%. Essayer d'automatiser complètement le travail créatif produit un output plat. Essayer d'automatiser complètement la prise de décision produit des systèmes fragiles. Le point idéal est d'automatiser les parties corvée d'une tâche — recherche, rédaction, mise en forme, synchronisation de statut — et de garder les parties de jugement humaines. Un workflow automatisé à 50% exécuté de façon consistante bat un workflow automatisé à 100% qui casse toutes les trois semaines.

2. Traitez l'AIOS comme un mentor, pas comme un distributeur automatique. Déjà dit. Je le redis. Les skills qui m'ont le plus appris sont ceux qui ont repoussé. /daily-plan est génial parce qu'il refuse parfois de planifier ce que je lui ai demandé et explique pourquoi (« vous vous êtes engagé au travail profond sur le livrable Acme lors de l'appel de mardi — déplacer la réunion dans ce bloc contredit cet engagement »). Un distributeur automatique aurait simplement déplacé la réunion.

3. L'audit bat la construction. Je suis sincèrement gêné par tout ce que j'ai construit avant de construire le skill d'audit. L'audit est ce qui a transformé l'AIOS d'un toolkit ingénieux en un système qui s'améliore lui-même. Si vous ne construisez qu'un seul skill de tout cet article, construisez l'audit.

Il y a aussi une méta-leçon qui vaut d'être dite à voix haute — construire cela ne m'a pas rendu plus productif du jour au lendemain. Cela m'a rendu plus honnête. Le score du dimanche ne ment pas. Vous ne pouvez pas vous convaincre que vous avez eu une super semaine quand l'audit dit Cadence est 5/25 et trois de vos routines ont échoué silencieusement.

Cela, plus que le temps gagné, est pourquoi je ne reviendrais jamais en arrière.

Questions fréquemment posées

Que signifie AIOS ?

AIOS signifie AI Operating System — un runtime personnel construit sur Claude Code qui maintient votre contexte, se connecte à vos outils en direct, expose des capacités comme des skills nommés et s'exécute selon une cadence que vous définissez. Contrairement à un chatbot, il gère des ressources cognitives entre les sessions et peut s'exécuter de façon autonome.

Faut-il être développeur pour construire un AIOS dans Claude Code ?

Vous avez besoin d'un confort de base avec le terminal, Git et l'édition de fichiers markdown. Vous n'avez pas besoin d'écrire du code de production — chaque skill est un fichier markdown avec un en-tête YAML. Si vous avez déployé un site WordPress ou utilisé VS Code, vous avez assez de base.

En quoi c'est différent de Notion AI ou ChatGPT avec mémoire ?

Trois choses : Claude Code lit votre vrai système de fichiers (pas d'étape d'upload), les skills tournent comme du code avec accès API (pas juste de la génération de texte), et les routines s'exécutent selon un planning que vous soyez devant votre laptop ou non. La mémoire de ChatGPT est l'un des quatre piliers (Context). Un AIOS, c'est les quatre.

Combien coûte l'exploitation d'un AIOS personnel ?

Claude Pro à 20$/mois couvre la plupart des usages personnels y compris 5 routines cloud par jour ; les plans Max étendent à 15 routines/jour. Les coûts d'API pour les outils connectés (Stripe, ClickUp, etc.) sont typiquement gratuits à volume personnel. Mon coût mensuel total tourne autour de ~45-80$ selon la charge de routines.

Combien de temps faut-il pour en construire un ?

Prévoyez 30-50 heures sur 4-8 semaines de travail à temps partiel pour atteindre une base utile. Attendez-vous à un creux de productivité en semaines 1-3, un seuil de rentabilité en semaine 5-7, et des gains composés après la semaine 8. Le guide pas à pas complet est dans les sections de construction ci-dessus.

Puis-je exécuter des routines cloud avec le plan Free ?

Non — les routines cloud nécessitent Pro, Max, Team ou Enterprise depuis mai 2026. Le plan Free peut encore exécuter des skills locaux et utiliser la programmation par cron sur votre propre machine.

Travaillons ensemble

Vous cherchez à construire des systèmes IA, automatiser des workflows ou faire évoluer votre infrastructure tech ? J'adorerais aider.

• Fiverr (builds personnalisés et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io