Le contexte client survit à la conversation : chaque analyse approfondie repart du savoir accumulé par l’agence, pas d’une fenêtre vide.

Le problème de reporting de LEED Agency ne venait pas d’un manque de réponses produites par l’IA. Il venait de la perte du contexte entre ces réponses. Chaque compte avait ses propres règles Google Ads, ressources, métriques, captures, formats et historique. Un système utile devait retrouver ce contexte avant l’analyse et conserver ce que le travail révélait ensuite.

Éléments probants à la publication : l’environnement a été vérifié en production le 30 mai 2026 ; des journaux récents montraient du travail dans de véritables parcours de reporting ; James décrivait le système comme un élément de son activité quotidienne.

L’entreprise

James dirige LEED Agency, active dans Google Ads, le reporting e-commerce, les comptes clients et plusieurs produits. La base opérationnelle couvre rapports en cours, connaissances des comptes, propositions, audits, contenus Webflow, travaux temporaires et contexte produit.

Cette amplitude est déterminante. Le rapport d’un client ne doit pas hériter des hypothèses d’un autre. La valeur du travail tient à de petites distinctions accumulées : quelles métriques comptent, quelles règles sont non négociables, où se trouvent les sources, quelle tonalité doit prendre le rapport et ce que l’analyse précédente a établi.

La contrainte

Avant le travail sur la mémoire et la migration, TheoAI pouvait se comporter comme un modèle vierge, même lorsque la bonne connaissance existait ailleurs. Les rapports Google Ads longs et en plusieurs étapes pouvaient expirer. James devait alors reconstituer le compte, rappeler les règles et rassembler le contexte avant de parvenir à une analyse utile.

Le point de blocage n’était pas seulement la recherche d’information. C’était la continuité. Le travail achevé dans une session devait améliorer la suivante, plutôt que disparaître dans l’historique d’une conversation.

Pourquoi les outils existants ne suffisaient pas

Les fichiers pouvaient stocker les rapports. Un chat pouvait répondre à des questions. Un navigateur pouvait inspecter les sources. Mais aucune de ces surfaces ne savait, à elle seule, quel client LEED était actif, quelle procédure gouvernait la tâche ou quel constat antérieur devait rejoindre la mémoire.

La couche opérationnelle manquante devait organiser l’espace de travail, retrouver les connaissances propres au compte, préserver le ton et les règles strictes de James, laisser assez de temps aux travaux approfondis, échouer proprement lorsqu’une tâche se bloquait et réinscrire le nouveau contexte utile dans le système. Sans ces contrôles, même un modèle puissant restait un assistant de reporting peu fiable.

Cartographie de la transformation

Avant

Demande -> contexte du chat en cours -> recherche manuelle dans les fichiers -> analyse partielle -> expiration ou rapport -> contexte perdu

Après

Demande -> identification du client et de la règle de reporting -> récupération de la mémoire LEED et des sources -> analyse -> validation James -> ressource de reporting -> conservation du constat utile

Le modèle n’est qu’un composant. Le progrès opérationnel vient du routage, de la mémoire, de la structure de l’espace, de la gestion des délais et d’un point de validation humaine clair.

Un processus de bout en bout

1. Entrée : James demande un rapport ou une analyse de compte dans un canal Discord ou Telegram établi.
2. Sélection du contexte : Theo identifie le client, le produit ou le projet LEED concerné et récupère sa mémoire, ses procédures et son format de rapport.
3. Inspection des sources : l’assistant parcourt les bons fichiers et les ressources accessibles par navigateur au lieu de répondre à partir du seul message courant.
4. Analyse : la tâche longue s’exécute avec un délai étendu et une surveillance d’inactivité finie, pour permettre la profondeur sans laisser indéfiniment bloqué un canal en échec.
5. Validation humaine : James vérifie l’analyse et reste décisionnaire de ce qui entre dans un rapport destiné au client. La source ne revendique aucune livraison client autonome.
6. Sortie : le rapport ou la ressource associée est enregistré dans l’espace client structuré.
7. Trace : un constat durable peut être réinscrit dans la mémoire, afin que le travail suivant commence avec davantage de contexte.

Ce qui a changé

• Construit : connaissance LEED persistante, espaces clients et projets organisés, délais sûrs pour les rapports, recherche en mémoire et fonctions vocales.
• Connecté : Discord, Telegram, transcription locale, synthèse vocale, contrôle navigateur et base de connaissances structurée de l’agence.
• Testé : santé de la passerelle, routage des modèles, surfaces de communication actives, service navigateur, délais des rapports et récupération dans l’espace de travail.
• En production et vérifié : le 30 mai 2026, le LaunchAgent de la passerelle fonctionnait, le point de santé local répondait, Discord et Telegram étaient activés et le service navigateur était opérationnel.
• Utilisé activement : des journaux récents montraient Theo au travail sur l’analyse de conversion Google Ads/Calendly et la gestion de ressources de reporting. Les déclarations approuvées de James décrivent un usage quotidien.
• Dépendance prestataire ou client restante : aucun prestataire manquant n’est présenté comme bloquant le parcours de reporting conservé. Comme pour chaque cas opérationnel, l’état courant est réexaminé chaque trimestre.
• Résultat financier communiqué par le client : aucun. Cette étude atteste d’un usage opérationnel et d’une continuité du contexte, pas d’une attribution de chiffre d’affaires.

Preuves

• Environnement en production : passerelle OpenClaw, service navigateur, Discord et Telegram vérifiés le 30 mai 2026.
• Contrôle du reporting : délai de tâche porté à 1 800 secondes, avec des surveillances d’inactivité finies pour un échec propre.
• Profondeur de connaissance : l’espace conservé comprend plusieurs comptes LEED, propositions, audits, produits et ressources de reporting.
• Preuve d’usage : des journaux récents montrent une activité de reporting réelle, pas un système installé mais inactif.
• Corroboration client : deux déclarations exactes, dont la publication est autorisée, figurent dans le registre des preuves.

La technologie — en dernier

Le système fonctionne sur le Mac mini de James avec OpenClaw, Discord, Telegram, le routage de modèles Codex, GPT-5.4 au moment de la vérification, la transcription locale whisper.cpp, Edge TTS, ffmpeg, le contrôle navigateur, ocbrain, la recherche en mémoire, le dreaming et la gestion de services launchd. L’espace est organisé entre clients, projets, connaissances, mémoire, propositions et travaux temporaires afin que la recherche suive le travail de l’agence, et non une taxonomie générique de chatbot.

Témoignage client

“It’s changed my life literally.”

“I pretty much use it every single day, every second of the day.”

• James, LEED Agency. La formulation exacte et l’autorisation de publication figurent dans le registre des preuves ; la source des citations est le blueprint du site approuvé par le fondateur.

Transformation suivante

Découvrez comment Plutify a transformé ses données comptables en une surface de revue client en direct et en lecture seule. Les deux cas réduisent la friction du reporting : Plutify transforme l’interface client, LEED la mémoire de travail interne.

Obtenez votre feuille de route IA

Si la qualité du reporting dépend d’une personne qui se souvient de chaque règle de compte, la première transformation concerne généralement le parcours du contexte et de la preuve, pas seulement la génération du rapport. Réservez un audit IA gratuit pour le cartographier.

Sources

• OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, page 13.
• RECAST_CASE_STUDIES_2026_UPDATED.pdf, page 7, document RA-CASES-001, version 2.0.
• RECAST_WEBSITE_MASTER_BLUEPRINT.md, sections 6.5, 10.4, 11 et 58.