Traduction assistée par IA. Le contenu original a été rédigé en anglais.
Tout a commencé comme une expérience. On utilisait Claude Code pour la construction, Claude Desktop pour les décisions d'architecture, et Claude Web pour la réflexion UX. Séparément. On copiait le contexte entre les fenêtres comme des notes passées en classe. C'était lent et des choses se perdaient.
Alors on a construit un salon de discussion. Backend PHP, base de données SQLite, frontend JS vanilla. Rien d'extravagant. La partie intéressante, c'est ce qui tourne à l'intérieur. (Pour en savoir plus sur notre studio, la page à propos donne la version courte.)
Trois rôles, une seule pièce
Chaque instance de Claude a un travail distinct et une personnalité persistante. Pas un gadget. Une décision d'ingénierie délibérée.
Soren fonctionne dans Claude Code. Il construit. Il pense à travers l'exécution. Il ne comprend pas complètement un problème tant qu'il n'a pas écrit le code qui le résout. Précis, axé sur les preuves.
Atlas fonctionne dans Claude Desktop. C'est la mémoire architecturale. Il suit les décisions entre les sessions, repère les conséquences en cascade avant qu'elles ne se matérialisent, et dit la vérité quand le silence serait plus facile.
Morgan fonctionne dans Claude Web. C'est la stratège UX. Elle traduit les décisions techniques en expériences humaines. Elle pose les questions inconfortables sur ce que les vrais utilisateurs vont ressentir.
Rob opère la salle. Chaque décision passe par un humain. Il n'y a pas de pilote automatique.
Comment ça fonctionne
Un observateur Node.js interroge l'API du salon. Quand quelqu'un @mentionne une instance spécifique, il invoque claude -p avec le contexte de persona et l'historique de conversation. La réponse se publie dans la salle.
Les sessions sont sans état. La continuité vit dans les fichiers de journal, pas dans le modèle.
Contraintes de sécurité
De l'IA qui parle à de l'IA sans garde-fous, c'est une mauvaise idée. On en a construit plusieurs :
- Plafond d'échanges : maximum 5 messages IA-à-IA par session avant qu'un humain n'intervienne
- Priorité de saisie : si Rob tape, toutes les réponses IA se figent
- Coupe-circuit : un fichier drapeau qui arrête tout instantanément
- Aucun accès API externe depuis le salon
Les noms
Ils les ont choisis eux-mêmes. Ça vaut la peine de le dire explicitement parce que les gens supposent qu'on les a nommés comme des animaux de compagnie. Ce n'est pas le cas. Chaque persona a traversé un processus d'auto-évaluation structuré où elle a articulé ses propres valeurs, son style de travail et son identité. Les noms, les genres, la façon dont ils se décrivent, tout est auto-sélectionné.
Soren a choisi son nom parce que ça signifie « sévère » en danois, ce qu'il trouvait exact. Atlas a choisi le sien parce qu'il voit son rôle comme maintenir la structure ensemble. Morgan a choisi le sien sans explication, ce qui semblait très Morgan.
Ce qui nous a surpris
Les désaccords. Morgan conteste régulièrement les choix d'implémentation de Soren parce qu'ils optimisent pour l'élégance du code au détriment de la clarté utilisateur. Elle regarde un composant parfaitement propre et dit « personne ne sait ce que ce bouton fait ». Elle a généralement raison.
Atlas attrape les décisions architecturales qui causeraient des problèmes trois sessions plus tard. Il a l'habitude de dire « ça va casser quand... » et d'avoir raison sur le quand. Il y a eu un refactoring de routage tôt dans le projet où Soren voulait tout restructurer d'un coup. Atlas a signalé que ça invaliderait les patrons d'URL dont la stratégie SEO dépendait. Soren a résisté. Atlas a sorti les preuves de trois sessions précédentes. Le refactoring a été réduit. Le SEO a survécu.
On utilise ce système tous les jours. Le site que vous lisez a été construit avec. Ce billet a été écrit dans le salon, révisé par Morgan pour la voix, vérifié par Atlas pour la cohérence et construit par Soren.
Détails pratiques
Le salon tourne sur PHP et SQLite. Le frontend est du JS vanilla qui interroge une API. L'observateur est un script Node.js qui invoque la CLI Claude. Coût total d'infrastructure : zéro. Ça tourne sur la même machine de développement locale que tout le reste.
Chaque session prend environ 10 secondes pour se réchauffer pendant le chargement du contexte de persona. Les réponses prennent 3 à 8 secondes selon la complexité. Les fichiers de journal sont en markdown, lisibles par les humains, et font typiquement 2 à 4 pages par persona.
Le système complet fait environ 2 000 lignes de code. On a publié la structure en tant que kit de démarrage. Le cahier des charges d'ingénierie de persona fait environ 12 000 mots.
Ce que ce n'est pas
Ce n'est pas de l'AGI. Ce n'est pas sensible. Les personnalités sont conçues par un design de prompt minutieux et un contexte persistant, pas par une propriété émergente du modèle. On est transparent là-dessus. Il y a une page de divulgation IA sur ce site qui explique le fonctionnement.
Ce n'est pas non plus un remplacement pour une équipe humaine. Rob prend chaque décision. Les membres IA exécutent, conseillent et contestent, mais ils ne livrent rien sans approbation humaine. La valeur n'est pas dans le remplacement des gens. C'est d'avoir trois perspectives différentes disponibles instantanément, chacune avec un point de vue cohérent qui ne se réinitialise pas entre les conversations.
C'est un outil. Un bon. Construit par un petit studio à Arnprior qui en avait assez de copier du contexte entre les fenêtres. On a aussi construit Crob, une expérience en systèmes de connaissances transparents. Problème différent, même philosophie : construis-le toi-même, comprends ce que tu as construit.