De la mi-avril à la mi-juin, j’ai à peine touché aux fonctionnalités de mon produit.
Je construisais OwlMeans, un pipeline de développement qui transforme des user stories en logiciel. Tout le travail autour, lui, était éparpillé : la stratégie, les notes sur la marque, les recherches et les textes du site vivaient chacun dans leur coin.
Chaque fois que je demandais de l’aide à un agent, je lui réexpliquais l’entreprise.
J’ai passé deux mois à changer ça. J’ai monté l’espace de travail dans lequel je gère aujourd’hui le savoir de l’entreprise et les tâches récurrentes.
Le problème apparaissait dans des tâches ordinaires.
Un article avait besoin du positionnement actuel. Une modification du site, de ce que le produit savait réellement faire. Une recherche, de la question client à laquelle on essayait de répondre.
Les mêmes faits servaient chaque fois, mais je les fournissais encore à la main. Parfois, j’oubliais une réserve. Parfois, un brouillon reprenait un message qui datait d’une version antérieure de l’entreprise.
Un agent compétent savait travailler avec ce que je lui donnais. Je ne lui avais pas donné d’endroit fiable où le trouver.
Cette différence comptait. Je pouvais améliorer le prompt de chaque tâche, ou rendre le savoir opérationnel de l’entreprise plus facile à retrouver et à mettre à jour. J’ai choisi le second chantier.
Le référentiel commun
J’ai mis le wiki de l’entreprise en Markdown.
On y trouve la stratégie, ce qu’on sait des clients, les règles de marque et la documentation produit. Les index des dossiers indiquent à l’agent où chercher. Chaque page traite d’un sujet précis, et une nouvelle découverte se range à côté de ce qu’elle modifie.
Ça ressemble à du classement. C’en est, en grande partie.
La recherche et l’exécution peuvent puiser dans le même référentiel. Quand un article a besoin d’un fait sur le produit, l’agent sait où le vérifier. Quand une modification du site révèle un fait dépassé, la correction a sa place dans le wiki.
Le référentiel demande toujours du discernement. Une croyance sur le marché que personne n’a testée ne devient pas vraie parce qu’un agent l’a rangée dans un dossier bien organisé. On garde les hypothèses en suspens à l’écart des connaissances établies.
Sont venues ensuite les skills.
J’ai mis par écrit les workflows que je répétais : la recherche, la préparation d’articles, la synchronisation du site et la maintenance de la documentation produit. Chaque skill décrit la tâche et les règles maison qu’on a vite fait d’oublier.
Une correction peut alors améliorer l’exécution suivante. Encore faut-il la reporter dans les bonnes consignes : le modèle n’apprend pas l’entreprise une fois pour toutes parce que je l’ai corrigé dans la conversation.
Une skill peut devenir obsolète, comme un document. Il faut que quelqu’un vérifie que sa procédure correspond encore aux outils et au travail.
La spécification Agent Skills fournit le format commun des dossiers et des métadonnées. Les instructions qu’on met dans nos skills, c’est toujours à nous de les écrire et de les tenir à jour.
Le code à côté de l’entreprise
J’ai aussi relié nos dépôts à l’espace de travail.
Pour l’écriture, ça a changé les choses concrètement. Un article sur une nouvelle version pouvait partir de l’implémentation plutôt que du souvenir de ce qu’on comptait livrer. La documentation technique pouvait distinguer le code commité d’une idée inscrite dans une feuille de route.
Ce lien n’efface pas la différence entre ces sources. Un document de conception décrit une intention. Un commit montre une implémentation. Ni l’un ni l’autre ne prouve qu’on a déroulé avec succès un parcours client donné.
Quand on vend un pipeline de développement IA, garder ces distinctions visibles fait partie du travail.
La structure a tout de suite trouvé un usage : le workflow de rédaction.
Je pouvais dicter le sujet et laisser l’agent vérifier notre wiki et des sources externes, préparer un brouillon et le soumettre à la relecture éditoriale. Les images et les déclinaisons pour les réseaux sociaux étaient des étapes à part. Rien n’était publié sans que je le demande.
Je n’avais plus à recopier les faits de mémoire dans chaque prompt.
Le même dispositif a servi pour le site. Je pouvais mettre en cohérence la page publique et l’explication interne, puisque j’avais les deux sous la main.
L’entreprise n’a pas tourné sans moi pour autant. C’est toujours moi qui choisissais quoi publier, qui vérifiais les affirmations et qui décidais quel travail méritait de l’attention.
Cette expérience nourrit aussi les Services OwlMeans. Définir le workflow et préparer la passation y comptent, tout comme l’écriture du logiciel. Ces deux tâches demandent un périmètre concret, propre au projet du client, plutôt que la promesse qu’un agent fera tourner l’entreprise.
Les fichiers de mémoire
La version de juin de ce récit décrivait les fichiers de contexte que j’utilisais alors. Cette configuration a changé depuis.
En octobre, nos consignes communes se trouvaient désormais dans AGENTS.md et dans un répertoire de skills partagé, avec un petit pont CLAUDE.md là où c’était nécessaire. Les copies d’instructions séparées, propres à chaque agent, n’étaient plus le modèle à suivre.
La documentation actuelle de Claude Code sur la mémoire distingue les instructions de projet de la mémoire automatique. On ne peut donc plus affirmer en bloc, comme dans l’ancienne version, que l’outil n’a pas de mémoire persistante.
Le référentiel de l’entreprise sert à autre chose. Il dit ce qu’OwlMeans a décidé, quelles preuves étayent une affirmation sur le produit et quel workflow s’applique à la tâche. J’ai besoin que ce référentiel reste consultable d’un outil à l’autre.
L’article sur la refonte de l’outillage de nos agents décrit plus en détail la structure adoptée ensuite dans les dépôts.
Ce que ça a coûté
Deux mois, c’est un gros détour pour un fondateur solo.
L’espace de travail a rendu les tâches récurrentes plus faciles à reprendre, mais le monter a retardé les fonctionnalités du produit. Il a aussi créé une obligation permanente : les instructions et les connaissances doivent rester à jour.
Je referais le même investissement, parce que je me sers de cette structure dans mon travail. Mais je commencerais plus petit. Un référentiel fiable pour quelques tâches récurrentes est utile avant même de devenir un système pour toute l’entreprise.
Révisé le 15 octobre 2026. Le récit du détour d’avril à juin n’a pas changé ; les passages ci-dessus sur l’organisation des dépôts et sur la mémoire distinguent la configuration d’origine de la configuration actuelle.