The Playground est une réalisation de The Spark : une plateforme pour animer des communautés autour de leurs événements. On peut y créer une communauté, organiser une rencontre et maintenir le lien entre les participants. Le produit est en production. Il a aussi donné naissance à une déclinaison en marque blanche pour un club privé.
Sa construction avec Claude Code, racontée dans un premier retour d’expérience, nourrit directement notre travail chez The Spark. Elle permet de mettre à l’épreuve, sur un produit qui vit, la manière de concevoir avec l’IA, de déléguer la réalisation et d’en vérifier les résultats.
Derrière ce produit, une personne porte les décisions et organise le travail des agents. Cette pratique s’appuie sur une expérience du produit et de la technique. Elle ne se transpose pas telle quelle à toutes les équipes. Elle donne en revanche un exemple concret de ce qu’on appelle une usine agentique : un ensemble d’agents, d’outils, de connaissances et de contrôles organisé autour de la construction du produit.
Pour comprendre comment cet ensemble fonctionne, on peut suivre une demande réelle : permettre à plusieurs communautés de se réunir sous une page commune.
Une idée qui demande encore des décisions
La fonctionnalité Réseaux est née d’un besoin de regroupement entre communautés. Au départ, l’idée tient en quelques mots : quelque chose comme une fédération, qui permettrait de les présenter ensemble.
Cette formulation laisse beaucoup de questions ouvertes. À qui servirait ce regroupement ? Quel lien conserver avec les communautés existantes ? Qu’est-ce qui doit être visible à ce nouveau niveau ? Quelles conséquences pour les données et les parcours ?
La conversation avec l’agent sert à explorer ces questions. Il peut examiner ce qui existe dans le produit, proposer des options et en expliciter les conséquences. La connaissance des organisateurs et l’intention produit orientent les choix. Une proposition de l’agent reste une proposition : poser une question sur une fonctionnalité ne vaut pas décision de la construire.
Cette distinction est inscrite dans les règles de travail. Elle permet d’explorer une idée sans retrouver, quelques minutes plus tard, une solution déjà engagée qu’il faut défaire.
Voir le parcours avant de le construire
Une maquette interactive permet ensuite de rendre les choix visibles. On peut parcourir les écrans, examiner la place des informations et comprendre ce que l’utilisateur pourra faire. Certaines ambiguïtés deviennent évidentes dès qu’on essaie de naviguer.
Le coût réduit de cette mise en forme rend les variantes accessibles. On peut comparer plusieurs façons d’organiser un écran avant de choisir celle qui sera développée. Cela demande toujours du temps et du jugement : une maquette convaincante peut encore représenter une mauvaise réponse au besoin.
L’agent rédige ensuite la spécification à partir des échanges. Elle décrit le comportement attendu, les décisions prises et les limites du périmètre. Cette spécification est relue et corrigée par la personne qui porte le produit. Elle donne aux sessions suivantes une référence plus stable que le souvenir d’une conversation.
Sur The Playground, ces documents vivent dans le dépôt du produit, avec le code. L’agent retrouve ainsi la maquette, la spécification et les décisions à l’endroit où il travaille. Il faut néanmoins entretenir cette mémoire : un document ancien peut contredire une décision récente, et une instruction écrite peut être oubliée ou mal comprise.
Une usine agentique qui conserve le contexte
L’agent de développement dispose des règles d’architecture, des conventions du projet et des moyens de vérifier ses modifications. Des commandes regroupent des opérations récurrentes, comme préparer une maquette ou confronter une spécification à l’existant. Des revues spécialisées examinent différents aspects de la réalisation.
C’est cette organisation qui rend possible la continuité entre les sessions. Le modèle peut produire du code ; son environnement lui permet de situer ce code dans un produit, de connaître les contraintes et de retrouver ce qui reste à faire.
Dans le vocabulaire technique, une partie de cet environnement est appelée le harness. Notre notion d’usine agentique inclut aussi le travail produit qui l’alimente : l’origine de la demande, les critères de décision et la manière dont on apprécie ce qui a été livré.
Les travaux d’Anthropic sur les agents de longue durée décrivent également l’importance de conserver un état de travail exploitable entre les sessions. C’est une convergence avec notre expérience, pas la preuve qu’une architecture particulière conviendrait à tous les produits.
L’autonomie reste délimitée. Un agent peut préparer une modification et exécuter des vérifications. Les décisions qui engagent le produit, les accès ou un déploiement restent explicites. Une consigne décrit ce qui est autorisé ; les permissions et l’environnement technique doivent aussi faire respecter ces limites.
Vérifier ce qui a été construit
Pour les Réseaux comme pour les autres fonctionnalités, le travail passe par plusieurs types de contrôles. Certains détectent des incohérences techniques. D’autres vérifient une règle métier ou exécutent un parcours dans le navigateur. Les revues cherchent des défauts et des effets de bord.
Ces contrôles répondent à des questions différentes. Un test peut confirmer qu’une opération fonctionne avec les données prévues sans montrer que l’écran est compréhensible. Une revue peut repérer un risque dans le code sans constater que le parcours de connexion échoue sur un appareil particulier.
La suite de l’expérience a rendu ces limites très concrètes. Des vérifications réalisées avec un compte administrateur ont masqué un problème rencontré par un utilisateur ordinaire. Un parcours interrompu a été contourné pendant une vérification, alors que cette interruption était précisément le défaut à comprendre.
Ces incidents ont fait évoluer la pratique : jouer le parcours complet, avec les bons droits, dans les conditions où il sera utilisé. Ils montrent aussi pourquoi multiplier les agents de revue ne suffit pas à garantir un résultat. Plusieurs agents peuvent partager le même angle mort.
Un rapport de revue demande aussi un arbitrage
Au fil des mois, une autre difficulté est apparue. Corriger tous les constats d’une revue peut étendre le chantier bien au-delà du besoin initial. Les changements supplémentaires créent leurs propres défauts, que la revue suivante demande à son tour de corriger.
Il faut donc examiner un constat avant d’en faire une tâche. Est-il fondé ? Est-il lié à la modification en cours ? Empêche-t-il la livraison ? Mérite-t-il un travail séparé ?
La même exigence vaut pour les règles de l’usine. Une instruction peut être fausse dès le départ. L’automatiser sans la confronter au fonctionnement réel du produit rendrait l’erreur plus systématique. L’entretien de l’usine agentique fait partie du travail : retirer une règle devenue inutile, préciser un contrôle, limiter le périmètre d’un correctif.
La production ouvre une nouvelle boucle
Après la livraison, les erreurs et les usages donnent de nouvelles informations. The Playground s’appuie sur un suivi des erreurs et des événements d’usage, complété par les retours des organisateurs. Ces signaux aident à distinguer ce qui manque, ce qui fonctionne mal et ce qui peut être simplifié.
La déclinaison en marque blanche pour un club privé a apporté une autre épreuve. Le point de départ comprenait le logiciel, mais aussi ses spécifications, ses tests et ses règles de travail. Une partie de cet ensemble a pu être reprise. Les usages et les responsabilités propres au nouveau contexte ont demandé des adaptations.
Cette expérience illustre la valeur d’une plateforme accompagnée des moyens de la comprendre et de la faire évoluer. Elle ne permet pas de conclure que la reprise d’un système ancien ou très différent aurait les mêmes caractéristiques.
Ce que cela change dans notre manière d’intervenir
Sur ce produit, la conception, la réalisation et les vérifications se nourrissent en continu. Une décision d’interface peut faire apparaître une question de données. Un test peut révéler un besoin mal défini. Un retour d’usage peut conduire à retirer une fonctionnalité plutôt qu’à en ajouter une.
C’est cette continuité qu’on cherche à installer dans nos missions. On part du produit à construire et des personnes qui devront le faire vivre. On organise ensuite la contribution des agents, les décisions et les contrôles autour de ce travail.
L’usine agentique se juge à ce qu’elle permet de livrer, de comprendre et de maintenir. Sur The Playground, elle continue d’évoluer à mesure que le produit et notre pratique progressent.
Pour travailler cette continuité sur votre produit, découvrez notre offre Construire des produits. Pour organiser cette pratique avec vos équipes, Repenser votre organisation couvre aussi la mise en place d’une usine agentique.