L'envie d'arrêter de tout faire moi-même, et de monter une vraie équipe IA qui s'organise comme une mini-entreprise, avec une assistante principale, des chefs de pôle, et des consultants spécialisés.
D'OpenClaw à mon propre OS, en passant par Paperclip
Dans le journal #2, je racontais comment Anthropic avait coupé l'accès subscription à OpenClaw et comment j'avais migré mes workflows vers Cowork en urgence. Dans le #3, j'analysais la sortie de Claude Managed Agents comme la suite logique de cette séquence. Dans le #4, je racontais ma tentative de construire JunaPilot avec Paperclip, et pourquoi j'avais fini par bifurquer sur Claude Design + Claude Code en direct.
Ce billet, c'est la continuité de tout ça.
Après la coupure d'OpenClaw, j'avais besoin d'un endroit où piloter mes agents perso. Cowork fait le job pour les tâches simples, mais j'avais perdu la finesse de configuration d'OpenClaw. Paperclip avait l'air d'être le bon candidat — multi-agents, persona-driven, exactement la direction que je voulais prendre.
J'ai vraiment aimé le système proposé par Paperclip. L'idée du CEO qui recrute son équipe, les agents qui se spécialisent, l'orchestration. C'est intelligent.
Mais en pratique, j'ai bloqué sur deux choses :
- Le design et l'UX : agents en silos, contexte qui se perd entre eux, interface confuse où tu sais jamais où les choses se passent. J'avais déjà détaillé ça dans le billet précédent.
- Une exigence de précision : je voulais un système qui me ressemble, qui s'adapte exactement à ma façon de bosser. Pas un produit généraliste que je devrais contorsionner.
Donc plutôt que de chercher l'outil parfait, j'ai décidé de construire le mien. En reprenant ce qui me plaisait dans Paperclip (la métaphore organisationnelle, les agents spécialisés) et en réglant ce qui me bloquait (le design, la mémoire, le multi-tâches).
Le résultat s'appelle Skalv-OS : un OS agentique personnel, qui tourne sur mon serveur, qui s'organise comme une petite entreprise. C'est de ça dont je veux te parler aujourd'hui.
Le problème que je voulais résoudre
Depuis quelques mois, j'utilise l'IA partout : mails de mairie, veille Warhammer, code, comptes rendus de réunion, audits SEO pour Juna. Mais à chaque fois c'était la même histoire : un assistant, un sujet à la fois. Tu lui parles de SEO, il fait du SEO. Tu lui parles de mairie, il oublie le SEO. Tu reviens sur le SEO le lendemain, il a tout oublié.
Je perdais du temps à re-contextualiser systématiquement. Et surtout, je n'avais pas l'impression d'avoir une équipe. J'avais un outil que je sollicitais à la demande.
Les outils existants échouent (pour moi) sur 4 points :
Trop générique. Un assistant qui sait tout faire ne sait rien faire bien. Pour une boutique Etsy d'impression 3D, c'est pas la même musique que pour faire du SEO Coca-Cola.
Pas de mémoire structurée. La plupart des outils mémorisent un peu, oublient beaucoup. Surtout, ils mémorisent dans leur format à eux, hors de mon contrôle. Si demain je change d'outil, je perds tout.
Pas de séparation des rôles. Quand tu mélanges "réponds à mes mails de mairie" avec "analyse le SEO de ma boutique" dans le même chat, le contexte s'embrouille et la qualité baisse.
Bloqué sur du synchrone. Tu lances une analyse qui prend 5 minutes, tu attends. Pendant ce temps tu peux pas demander autre chose. Mauvaise UX quand tu jongles entre plusieurs activités.
L'idée : un mini-cabinet personnel. Une assistante principale qui me connaît, qui sait à qui passer mes demandes selon les sujets, qui tient à jour la mémoire de l'ensemble. Et derrière elle, des spécialistes qu'elle appelle quand il faut.
La métaphore qui change tout : une mini-entreprise
Le déclic, c'est quand j'ai arrêté de penser "chatbot" et que j'ai commencé à penser "organisation".
Dans une vraie entreprise, tu n'as pas un seul interlocuteur qui sait tout faire. Tu as :
- Un CEO (moi) qui décide de ce qui doit être fait
- Une assistante principale qui prend les appels, route les demandes, garde la mémoire de qui fait quoi
- Des responsables de pôle qui pilotent leur domaine (commercial, technique, marketing…)
- Des consultants externes qu'on appelle quand on a besoin d'une expertise précise (un expert SEO, un avocat, un comptable)
C'est devenu le modèle de Skalv-OS. Chaque rôle est incarné par un agent IA distinct, avec ses propres connaissances, sa propre mémoire, son propre champ d'action.
Le casting de Skalv-OS
Dwayna — la cheffe des opérations
Dwayna, c'est mon point d'entrée unique. Quand je lance le système, c'est elle qui m'accueille. Elle connaît mes pôles d'activité, elle connaît mes contacts récurrents, elle sait à qui passer une demande selon le sujet.
Exemple type :
"Dwayna, audit SEO de ma boutique Juna, niveau standard, c'est pour moi en interne."
Elle identifie le pôle (Juna), elle identifie le besoin (SEO), elle lance le consultant SEO, et elle me dit "OK c'est parti, je suis dispo pour autre chose."
Elle ne fait pas le travail elle-même. Elle route. Comme une bonne assistante.
Les responsables de pôle
Chaque activité importante a son responsable. Pour l'instant j'ai créé celui de Juna, et les autres arrivent : Mairie de Biville, SK Systems, Wargame & Caux.
Chaque responsable de pôle connaît :
- L'état courant de son activité (priorités du moment, dossiers actifs)
- Les contacts clés du pôle
- Les contraintes spécifiques (par exemple : pour la mairie, rien ne s'envoie sans ma validation)
- L'historique des décisions importantes
Quand je lui parle de son pôle, on n'a pas besoin de re-poser le contexte à chaque fois. Il sait déjà.
Les consultants externes
Ce sont des spécialistes invocables à la demande, transverses à tous les pôles : un consultant SEO, un consultant copywriter, un consultant qui challenge mes idées façon Y Combinator, etc.
Quand un responsable de pôle a besoin d'une expertise, il invoque le bon consultant. Le consultant fait son boulot, livre son rapport, repart.
C'est exactement comme dans une vraie boîte : tu ne formes pas un expert SEO en interne pour une mission par trimestre, tu prends un freelance.
Comment ça fonctionne au quotidien
Le scénario type, depuis hier :
9h12. Je lance le système. Dwayna me dit bonjour, me résume ce qui s'est passé hier, mentionne les missions terminées dont je n'ai pas encore eu le résultat.
"Audit SEO de juna-shop.fr, en background, niveau standard."
Elle confirme : mission lancée, le consultant SEO bosse, elle est dispo pour autre chose.
"Au fait, crée le pôle Wargame pendant que ça tourne. Voici les infos de base : président de l'asso, on organise des rencontres Warhammer 40K, on a une vingtaine de membres…"
Elle pose deux trois questions de clarification, puis crée toute la structure : un responsable de pôle Wargame, sa fiche de poste, son contexte, ses contacts à pré-référencer.
Pendant ce temps, l'audit SEO tourne sans m'embêter.
Dix minutes plus tard : "Au passage, l'audit SEO est terminé. Score 67/100. Rapport stocké dans le wiki Juna. Tu veux les détails, ou on enchaîne sur des recommandations ?"
C'est ça la vraie différence avec un chatbot classique. Le système gère plusieurs choses en parallèle, garde la mémoire structurée, et route les demandes au bon spécialiste sans que je doive m'en occuper.
Ce qui se passe sous le capot (très brièvement)
Je vais pas faire un cours technique, mais quelques principes pour ceux que ça intéresse.
Tout vit dans un seul dossier sur mon serveur (~/skos/), versionné dans un dépôt Git. Si je clone ce dossier sur une autre machine, j'emporte toute ma mémoire avec. Pas de dépendance à un service tiers qui pourrait fermer demain.
La mémoire est en markdown pur. Pas de base de données exotique, pas de format propriétaire. Des fichiers texte lisibles, organisés en cinq couches :
- Le contexte global du système
- Le vault long terme (la mémoire "wiki" de tout ce qui mérite d'être retenu)
- Le contexte de chaque pôle (l'état courant)
- La mémoire propre à chaque agent (ses décisions, ses patterns appris)
- Le journal quotidien
Les agents fonctionnent par-dessus Claude (Anthropic) en utilisant Claude Code comme moteur. Quand Dwayna délègue une mission à un consultant, elle ne le "chatte" pas, elle lance une vraie session de travail en arrière-plan qui tourne dans son propre processus. Le consultant fait son boulot pendant des minutes, parfois plus, et écrit son rapport dans le système de fichiers. Dwayna récupère le résultat quand il est prêt.
C'est ce qui me permet de continuer à parler à Dwayna pendant qu'une analyse tourne en parallèle.
Et pour ceux qui pensent à la sécurité : tout est self-hosted sur mon propre serveur Kimsufi. Mes données ne sortent pas, je décide qui voit quoi.
Ce que ça m'apporte concrètement
Deux semaines que je l'utilise, voilà ce qui change :
Plus de re-contextualisation. Quand je parle de Juna, le système sait déjà ce qu'est Juna. Quand je parle de Mme Dupont, il sait si c'est Mme Dupont de la mairie ou Mme Dupont la cliente Juna. C'est bête mais c'est énorme.
Vraiment en parallèle. Avant, demander une analyse SEO bloquait ma session pendant 5-10 minutes. Maintenant je lance, je passe à autre chose, je récupère le résultat plus tard. C'est ce qui change le plus mon ressenti.
Une vraie mémoire long terme. Les décisions importantes sont consignées. Quand je reviens sur un sujet 3 semaines plus tard, je retrouve où on en était. Pas besoin de me souvenir de tout dans ma tête.
Un séparation propre des préoccupations. Le responsable Juna ne se mélange pas avec le responsable Mairie. Chacun reste dans son scope, donne des réponses adaptées à son contexte, ne se laisse pas distraire par des sujets qui ne le concernent pas.
De la cohérence dans le temps. Si Dwayna apprend que je préfère que les emails à la mairie soient toujours validés avant envoi, elle s'en souvient pour toutes les prochaines missions du pôle Mairie. C'est noté dans sa mémoire, c'est appliqué automatiquement.
Ce qui a été dur honnêtement
Je ne vais pas te raconter que c'était simple. Quelques galères :
Penser une vraie architecture. C'est tentant de tout balancer dans un seul gros prompt système. Mauvaise idée. La séparation des rôles, la mémoire structurée, les conventions de nommage — tout ça demande de la conception. J'ai pivoté trois fois en cours de route quand je voyais qu'un pattern ne tenait pas.
Trouver le bon équilibre synchrone / asynchrone. Premier réflexe, tout faire synchrone (je demande, j'attends, je récupère). Mauvais réflexe quand tu veux jongler entre 4 activités. Le passage en asynchrone (le système gère plusieurs choses en parallèle) a été un vrai pivot architectural.
Discipliner les agents. Un agent IA, par défaut, c'est créatif et bavard. Pour que Dwayna soit factuelle et concise, il a fallu écrire précisément son rôle, son style, ses limites. Sans ça, elle se mettait à inventer ou à sur-expliquer.
Tester en conditions réelles. Tu peux concevoir le système le plus élégant du monde, c'est l'usage qui te dit ce qui marche. J'ai cassé et reconstruit plusieurs fois.
Pourquoi ça concerne tout le monde, pas que les devs
Je suis dev, donc forcément je l'ai construit moi-même. Mais le principe s'applique à n'importe qui qui gère plusieurs activités en parallèle.
Pense aux gens que tu connais qui ont une vraie charge mentale :
- L'élu local qui jongle entre mandat, vie pro, vie perso
- L'entrepreneur qui pilote plusieurs activités en parallèle
- Le freelance qui gère ses clients, sa compta, sa prospection, sa veille
- Le dirigeant de PME qui n'a pas d'assistante mais en aurait bien besoin
- Le parent solo qui gère le boulot, les enfants, l'intendance, l'administratif
Pour tous ces profils, avoir une assistante IA qui :
- Connaît ta vie et tes priorités
- Route tes demandes au bon spécialiste
- Mémorise les décisions importantes
- Fonctionne pendant que tu fais autre chose
…c'est un vrai changement de vie. Pas un gadget.
Ce que j'en retire pour mes clients SK Systems
Tout ce que j'apprends sur Skalv-OS, je peux l'appliquer ailleurs.
Une PME qui pilote plusieurs marques, plusieurs canaux, plusieurs équipes : elle a besoin de la même chose. Pas un chatbot générique. Une infrastructure agentique pensée pour son organisation.