Les boutiques de Ramon n’avaient pas besoin d’assistants identiques, copiés d’un dossier à l’autre. Elles avaient besoin d’une base opérationnelle commune capable de conserver ce que l’entreprise apprenait, tout en séparant les instructions, identifiants et contextes clients de chaque marque.
Éléments probants à la publication : au moins trois boutiques Shopify dans le contexte opérationnel ; six agents configurés et 40 connexions vérifiées le 30 mai 2026 ; les connexions Gmail, Shopify, Track123, Meta Ads et Drive propres à chaque boutique restaient prêtes côté prestataires plutôt que présentées publiquement comme actives.
L’entreprise
Ramon Gloor développait et exploitait plusieurs marques e-commerce suisses et allemandes, avec au moins trois boutiques Shopify et d’autres à venir. Chaque boutique avait ses propres demandes clients, son catalogue, ses lancements et ses décisions créatives.
Le support à lui seul traversait plusieurs systèmes. Il fallait ouvrir la bonne boîte Gmail, retrouver la commande Shopify correspondante, vérifier le suivi dans Track123 ou une application propre à la boutique, puis répondre dans le fil d’origine. Les adresses suisses ou allemandes incomplètes ajoutaient un autre parcours de décision entre informations de facturation, données client et annuaires.
La contrainte
Chaque boutique vivait dans une configuration d’automatisation isolée. Instructions, corrections, logique du support, étapes de lancement et enseignements créatifs devaient être dupliqués. Lorsqu’une marque résolvait un problème réutilisable, les autres ne pouvaient pas hériter de cette connaissance en toute sécurité.
La contrainte centrale était la fragmentation de la mémoire. Une couche commune pouvait réduire les doublons, mais une couche commune mal conçue aurait mélangé marques, identifiants et données clients. L’architecture devait assurer à la fois réutilisation et séparation.
Pourquoi les outils existants ne suffisaient pas
Shopify détenait les commandes. Gmail détenait les conversations. Les outils de suivi détenaient l’état des expéditions. Les connaissances créatives et de lancement vivaient ailleurs. Aucun de ces produits ne définissait ce qui relevait de la connaissance globale, quelle règle appartenait à une boutique ou comment une nouvelle marque devait hériter des compétences éprouvées sans hériter de l’état privé d’une autre.
La couche opérationnelle manquante exigeait un référentiel commun, des configurations par boutique, des rôles spécialisés et une méthode reproductible pour créer un nouvel espace de marque isolé. Les connexions prestataires devaient ensuite être activées boutique par boutique, sans être présumées actives au seul motif que l’architecture existait.
Cartographie de la transformation
Avant
Assistant marque A | assistant marque B | assistant marque C -> corrections dupliquées -> Ramon réconcilie les connaissances de chacun
Après — architecture prête côté prestataires
Compétences et mémoire partagées -> routeur de marque -> configuration isolée de boutique -> agent spécialiste -> validation ou action prestataire -> dossier propre à la marque
La connaissance globale peut être réutilisée. Les dossiers clients, identifiants et décisions de boutique restent dans leur périmètre respectif.
Un processus de bout en bout
Le parcours suivant décrit le support conçu une fois les prestataires de la boutique activés ; la source ne prétend pas que ces appels prestataire étaient actifs au moment de la publication.
- Entrée : un e-mail client arrive dans le compte Gmail propre à une boutique.
- Identification de la marque : le système détermine le bon espace de marque et charge sa configuration de boutique.
- Contexte de commande : le parcours support retrouve la commande Shopify correspondante et la source de suivi autorisée pour cette boutique.
- Aide à la décision : la connaissance support partagée et la politique propre à la boutique sont appliquées sans exposer le contexte client d’une autre marque.
- Validation humaine : l’opérateur vérifie les modifications d’adresse sensibles, les exceptions ou les réponses sortantes jusqu’à ce que chaque parcours d’action soit prouvé séparément.
- Sortie : un projet de réponse ou une action de résolution d’adresse est préparé dans le bon contexte de marque.
- Trace : l’enseignement réutilisable peut rejoindre la mémoire commune, tandis que les identifiants et données clients restent isolés.
Ce qui a changé
- Construit : mémoire commune, compétences e-commerce réutilisables, dossiers de configuration par boutique, référentiel de connaissances, six agents spécialistes, structure Mission Control et fabrique d’agents de marque.
- Connecté : l’environnement vérifié comprenait le runtime OpenClaw, Command Center, gbrain, le routage des modèles et les connexions agent/espace.
- Testé : le 30 mai 2026, six agents et 40 connexions ont été observés, avec les espaces et structures de compétences attendus.
- Fondation vérifiée : la base opérationnelle et le routage des agents étaient actifs. Cela ne transforme pas les connecteurs boutique prêts côté prestataire en processus e-commerce de bout en bout vérifiés.
- Utilisé activement : la source ne conserve aucune preuve d’usage régulier boutique par boutique ; cette page ne le revendique donc pas.
- Dépendance prestataire ou client restante : Gmail, Shopify, Track123, Meta Ads, Google Drive et les identifiants propres à chaque boutique doivent être activés et prouvés pour chaque marque.
- Résultat financier communiqué par le client : aucun résultat conservé.
Preuves
- Contexte opérationnel : au moins trois boutiques Shopify, d’autres marques étant prévues.
- Preuve agents : six agents configurés — main/Ava, support, opérations, lancement, création et stratégie.
- Preuve de routage : 40 connexions observées le 30 mai 2026.
- Preuve d’architecture : espaces distincts, configuration boutique et structures de compétences partagées présents.
- État honnête : la base est prête côté prestataires ; le texte public ne décrit pas les intégrations boutique comme actives avant une preuve par boutique.
La technologie — en dernier
La base fonctionne sur un VPS natif avec OpenClaw, Caddy, un service Command Center actif, un proxy de facturation, gbrain, le routage OpenRouter, Apify, Kie.ai et des compétences e-commerce. Chaque espace contient ses propres consignes, outils, projets et configuration de boutique. Le référentiel commun organise marques, support, opérations, marketing, recherche produit, manuels et stratégie créative. Les adaptateurs sont conçus pour relier Gmail, Shopify, Track123, Meta Ads et Google Drive boutique par boutique.
Témoignage client
Aucun témoignage textuel étayé par la source n’est publié pour ce cas. Les preuves portent sur l’architecture vérifiée, le nombre d’agents et le nombre de connexions ; RECAST ne fabrique pas un témoignage à partir d’un résumé de projet.
Transformation suivante
Découvrez comment Scaling Webinars a coordonné huit départements dans un même contexte opérationnel partagé. Les deux systèmes séparent le travail des spécialistes tout en préservant une mémoire commune, mais leurs frontières opérationnelles diffèrent.
Obtenez votre feuille de route IA
Si chaque nouvelle marque exige de copier les mêmes automatisations fragiles, la première question de conception est ce qui doit être partagé et ce qui doit rester isolé. Réservez un audit IA gratuit pour tracer cette frontière avant d’ajouter un autre bot au niveau de la boutique.
Sources
OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, page 1.RECAST_WEBSITE_MASTER_BLUEPRINT.md, sections 6.5, 10.4, 11 et 58.- Ramon n’apparaît pas dans
RECAST_CASE_STUDIES_2026_UPDATED.pdf; le document détaillé constitue la source conservée pour ce cas.