Comment je fais tourner une entreprise IA à moi tout seul avec Claude Code

Une entreprise IA solo tient debout quand vous arrêtez de traiter le modèle comme un autocomplete un peu plus malin et que vous commencez à le traiter comme une main-d'œuvre à plusieurs niveaux : un modèle rapide et pas cher qui tient la boucle principale, un modèle puissant qui exécute le gros du travail, et vous, en haut, qui faites la seule chose qu'aucun des deux ne peut faire à votre place — le jugement. Tout ce qui suit, c'est comment ça se traduit sur ma machine, un mardi normal.

Je ne dirige pas une équipe. Je fais tourner Claude Code comme hub central, je branche dessus mes vrais outils, et je garde une poignée d'habitudes qui empêchent l'ensemble de partir en résultats confiants mais faux. Voici l'installation, morceau par morceau.

Orchestrer léger, exécuter fort

La règle qui fait tenir l'économie du truc : ne jamais faire tourner le plus gros modèle pour tout.

Ma boucle principale tourne sur un modèle rapide et peu coûteux. C'est elle qui réfléchit : découper une tâche, trancher les questions d'architecture, relire ce qui revient, me parler, et traiter les modifications d'une ligne pour lesquelles lancer un subagent coûterait plus cher que ça ne rapporte. L'exécution lourde — implémentation multi-fichiers, debug profond, longues chaînes d'appels d'outils, refactors — part vers un modèle plus puissant via des subagents. Le travail purement mécanique — recherche de code, transformations en masse, inventaires de fichiers, recherche documentaire — va au modèle le plus petit capable de le faire correctement.

Ce qui ne se délègue jamais : le jugement. L'orchestrateur relit systématiquement le résultat d'un subagent avant de considérer quoi que ce soit comme terminé — il lit le diff, vérifie l'affirmation sur pièce, confirme que le fichier dit vraiment ce que le résumé prétend qu'il dit.

Cette règle ne vit pas dans ma tête, elle vit dans mon fichier d'instructions global, donc chaque session sur la machine en hérite automatiquement :

## Work process — orchestrate by difficulty, delegate to save the main loop

- Keep on the main loop: architecture/design decisions, deep single-threaded
  debugging, reviewing/synthesizing subagent results, final answers.
- Delegate (parallel) with model: sonnet — independent chunks that run
  concurrently: multi-file edits, per-item transforms, search-and-apply.
- Delegate (mechanical) with model: haiku — code search, file inventories,
  bulk find/replace, simple verifications, doc lookups.
- Always review delegated output before reporting done.

Cette dernière ligne est celle qui compte vraiment. Déléguer déplace la frappe au clavier. Ça ne déplace jamais la responsabilité.

La mémoire, c'est un fichier, pas une impression

Une session d'IA a une continuité nulle par défaut. Fermez le terminal, et le modèle oublie que votre activité a jamais existé. Le correctif n'est pas une fenêtre de contexte plus grande — c'est d'écrire les choses, dans le repo, en fichiers texte, exactement comme vous formeriez une nouvelle recrue au lieu d'espérer qu'elle lise dans vos pensées.

Mon installation a trois couches :

• Un fichier d'instructions racine, lu au début de chaque session — qui je suis, comment cette machine est configurée, les règles qui ne changent jamais.
• Un dossier mémoire, un fait par fichier, étiqueté par type : ce qui est vrai sur moi (localisation, statut fiscal, préférences), les corrections données une fois et qui doivent rester acquises, l'état de projets en cours qui n'est pas déductible du code, et des pointeurs vers les systèmes externes que j'utilise.
• Un fichier index, une ligne par mémoire, chargé à chaque session pour qu'une conversation toute neuve puisse scanner l'état de mon monde en quelques secondes et ne récupérer que ce qui est pertinent.

Quand quelque chose change, la mémoire est mise à jour ou supprimée — un fait faux n'est pas laissé à pourrir, il est retiré. Cette discipline est ce qui transforme un modèle sans état en quelque chose qui capitalise au lieu de repartir à zéro chaque matin. La cinquantième session est nettement plus utile que la première, pas parce que le modèle est devenu plus intelligent, mais parce que le contexte l'est devenu.

Les skills sont des workflows packagés, pas des prompts jetables

Tout ce que je me surprends à réexpliquer une troisième fois devient un skill : une procédure nommée et réutilisable que le modèle charge à la demande, au lieu que je retape des instructions de mémoire.

Ceux que j'utilise vraiment, tous les jours ou toutes les semaines :

• Un skill de planification matinale qui lit mon calendrier, mes priorités du moment et l'état de mes projets actifs, et me remet le plan de la journée avant même mon café.
• Un skill de clôture de session qui persiste ce qui vaut la peine d'être retenu, met à jour le fichier d'instructions, et signale ce qui traîne — fichiers non commités, pull requests ouvertes, jobs encore en cours. Celui-ci est open source, tout le monde peut l'installer.
• Un moteur de blog complet — écrire, réécrire, structurer, briefer, auditer, générer du schema, repackager — noté selon une grille pensée pour le classement dans les moteurs de recherche et la visibilité de citation par les IA.
• Un skill de packaging vidéo qui transcrit une vidéo locale et génère tout le pack de mise en ligne : titres SEO, description prête à coller, miniatures.
• Des skills de recherche qui vont d'une vérification rapide jusqu'à un rapport multi-sources, vérifié fait par fait, avec contre-vérification contradictoire des affirmations.

En installer un depuis la marketplace tient en deux lignes :

/plugin marketplace add Wecko-ai/claude-skills
/plugin install closing@wecko-skills

Les skills, c'est comment un opérateur solo obtient de la constance. Le process d'un freelance vit généralement dans sa tête, appliqué un peu différemment à chaque fois, oublié sous la pression d'un deadline. Écrit comme un skill, il s'exécute pareil à 9h du matin ou à minuit.

MCP : les portes entre le modèle et le monde réel

Un modèle qui ne sait que lire et écrire des fichiers dans un repo est un stagiaire très rapide, enfermé dans une pièce. Les serveurs MCP sont les portes qui le sortent de cette pièce — ils laissent la boucle agir sur les systèmes qu'une activité fait vraiment tourner, pas juste décrire ce qu'elle ferait si elle le pouvait.

Ceux qui sont branchés dans ma boucle quotidienne : Google Calendar, pour que le modèle lise mes engagements réels et planifie autour au lieu de deviner ; Gmail, pour chercher, rédiger et étiqueter ; Google Search Console, pour le trafic, les quick wins et la dégradation de contenu sur les sites que je fais tourner ; une API de recherche pour des vérifications profondes, sourcées et à jour ; et un canal de messagerie qui me permet d'atteindre toute l'installation depuis mon téléphone — envoyer une photo, recevoir une réponse structurée, sans ordinateur portable.

Rien de tout ça ne remplace le jugement sur ce qu'on envoie ou ce qu'on croit dans une réponse. Ça veut juste dire que le modèle n'est plus limité à conseiller — il peut consulter le calendrier lui-même, rédiger le vrai mail, aller chercher les vrais chiffres.

La vérification, c'est tout le filet de sécurité

Les subagents sont rapides et confiants. La confiance n'est pas la justesse, et l'écart entre les deux est exactement l'endroit où une activité solo se brûle si personne ne surveille.

Donc l'habitude est non négociable : lire le diff avant qu'il ne soit mergé. Vérifier le chiffre sur pièce avant qu'il n'atterrisse dans un rapport. Confirmer qu'un fichier existe vraiment avant de croire un résumé qui l'affirme. Ça coûte presque rien comparé à l'alternative — livrer en toute confiance quelque chose de faux à un client, ou en production, parce que le rapport d'un subagent semblait plausible. C'est la seule étape de tout le pipeline que je refuse de déléguer, et c'est ce qui permet au reste de tourner à la vitesse de la machine sans devenir imprudent.

Ce que ça a réellement produit

Rien de tout ça n'est théorique. Ce workflow est ce qui a permis à un CLI sans dépendance, qui détecte le meilleur LLM local pour votre machine, de passer d'idée à package npm publié puis à un tap Homebrew en une seule session. C'est comme ça qu'une marketplace ouverte de skills Claude Code a été construite — le skill de clôture mentionné plus haut a été la première chose publiée dessus. C'est la même boucle derrière un pipeline de montage vidéo qui transforme des rushes bruts en timeline de montage, sous-titres et shorts verticaux, un bot de coaching qui vit dans Telegram, un outil de synchronisation de notes, et les systèmes de contenu et de SEO derrière plusieurs sites web, chacun dans son propre repo avec son propre fichier d'instructions, pour que l'assistant charge le bon contexte dès qu'on change de dossier.

L'organigramme, c'est : un modèle pas cher pour la réflexion à faible enjeu, un modèle puissant pour l'exécution, des fichiers pour la mémoire, des skills pour le process, MCP pour la portée — et un humain qui ne s'arrête jamais de lire le diff.

Envie que ça tourne dans votre propre activité

Si tout ça ressemble à l'écart entre ce que votre équipe voudrait que l'IA fasse et ce qu'elle fait vraiment au quotidien, c'est exactement ce que je vous aide à combler :

• Intégration IA — j'audite comment votre équipe travaille vraiment et je construis les agents, automatisations et RAG dedans.
• Coaching développeur — coaching individuel ou en équipe sur exactement ce workflow : agentic coding, Claude Code, MCP, habitudes de vérification incluses.
• Formation Build-with-AI — ateliers pratiques et cohortes qui se terminent avec quelque chose de live, pas un jeu de slides.