Plutify disposait déjà des données financières. La transformation consistait à les rendre utiles au client sans transformer QuickBooks en expérience client. RECAST a construit une couche de pilotage en lecture seule qui présente les chiffres dans le langage de Plutify, isole les données de chaque client et renvoie les questions non résolues vers l’équipe du cabinet.
Éléments probants à la publication : environ 40 clients sous abonnement mensuel dans le contexte opérationnel ; lecture QuickBooks en direct attestée ; refus des requêtes non authentifiées par les routes protégées ; actions d’écriture et d’envoi volontairement bloquées.
L’entreprise
Saadi Sabah dirige Plutify Bookkeeping, au service d’environ 40 clients e-commerce sous abonnement mensuel. Les livres étaient à jour dans QuickBooks Online, mais l’expérience de revue restait dominée par des rapports PDF ou Excel mensuels et par la complexité de l’interface comptable.
Pour Plutify, le produit ne se limitait pas à une comptabilité exacte. Il comprenait la capacité du client à comprendre sa situation, comparer des périodes, poser une question utile et savoir quand le jugement du cabinet devenait nécessaire.
La contrainte
Les rapports statiques offraient un instantané, pas une surface opérationnelle. QuickBooks détenait les données sources, mais restait trop dense et trop orienté comptabilité pour constituer une expérience de revue claire et aux couleurs du cabinet pour chaque client.
Il en résultait des frictions évitables : faible consultation des rapports, explications répétées et absence d’un endroit constant où passer d’un chiffre à une question éclairée.
Pourquoi les outils existants ne suffisaient pas
Remplacer QuickBooks aurait ajouté du risque sans résoudre le bon problème. Exporter des fichiers plus élégants aurait conservé le délai et le caractère unidirectionnel de l’expérience existante.
La couche manquante devait lire la source comptable de référence, isoler chaque client, présenter une vue standardisée des KPI et des finances, expliquer la configuration et le contexte du rapport, escalader ce qu’elle ne pouvait traiter et empêcher l’assistant de modifier les livres ou d’envoyer du contenu sans validation. La bonne frontière consistait à ouvrir d’abord la lecture, puis à gouverner les actions.
Cartographie de la transformation
Avant
QuickBooks -> export mensuel -> PDF ou Excel -> interprétation isolée par le client -> question par e-mail -> Saadi reconstruit le contexte
Après
Lecture QuickBooks en direct -> vue financière isolée par client -> revue des périodes et KPI -> question de type CFO -> réponse ou escalade -> décision Saadi
Toute future modification, exportation, exécution planifiée ou transmission externe demeure hors du parcours actif jusqu’à ce que ses identifiants, sondes, responsable de validation et preuves QA soient complets.
Un processus de bout en bout
- Entrée : un client authentifié accède au portail Plutify et sélectionne la période concernée.
- Lecture des données : le service récupère les données QuickBooks Online autorisées par le parcours de lecture en direct.
- Présentation : le portail affiche les tableaux financiers standardisés, KPI et contexte du rapport pour ce client.
- Question : le client pose une question de type CFO depuis la même surface de revue.
- Action système : CFO Chat explique le contexte disponible, ébauche une structure de rapport ou guide l’étape suivante sans modifier QuickBooks.
- Validation humaine : une question sans réponse ou exigeant du jugement est transmise à l’équipe de Saadi. Toute écriture, exportation, activation cron ou transmission reste bloquée.
- Trace : l’état du portail et les brouillons de processus préservent le sujet et sa prochaine action sans franchir la frontière d’absence d’écriture.
Ce qui a changé
- Construit : portail client aux couleurs de Plutify, modèle multiclient, authentification, vues financières, rapports, surfaces d’intégration, brouillons de processus et CFO Chat.
- Connecté : parcours de lecture QuickBooks Online en direct, stockage local chiffré des identifiants et préparation du broker Google OAuth de Recast.
- Testé : santé applicative, contrôles d’authentification, comportement des API protégées, métadonnées de connexion QBO, état des données en direct et signaux d’erreur récents.
- En production et vérifié : l’état des données QBO en direct était vrai et l’application saine au point d’audit conservé.
- Utilisé activement : la source prouve une fondation produit active et des lectures comptables en direct. Elle n’atteste pas encore d’un usage régulier par les 40 clients ; cette page ne le revendique donc pas.
- Dépendance prestataire ou client restante : certaines notions financières et formulations d’état d’intégration devaient être affinées. Écritures QBO ou Google, exportations, exécutions planifiées et envois restent bloqués en attente des identifiants, sondes, validations et QA.
- Résultat financier communiqué par le client : aucun. Le nombre de clients décrit le contexte opérationnel du cabinet, pas un résultat causé par le système.
Preuves
- Contexte opérationnel : environ 40 clients e-commerce sous abonnement mensuel.
- Réception des données : métadonnées de connexion QuickBooks présentes et état des données en direct vrai.
- Contrôle d’accès : les routes API protégées ont rejeté les accès non authentifiés.
- Santé système : l’application était saine, sans signal d’erreur récent au moment de l’audit conservé.
- Frontière honnête : les lectures sont actives ; écritures, exportations, planifications et envois restent soumis à validation.
La technologie — en dernier
La pile fonctionne sur un VPS appartenant au client, derrière nginx et HTTPS. Elle combine un service de tableau de bord Python, des bundles front-end React/Vite, un état SQLite, l’authentification multiclient, les parcours de lecture QuickBooks Online en direct, un stockage chiffré des identifiants, le support du broker Google OAuth et un routage CFO Chat enrichi par Claude. Les API protégées et les contrôles de préparation prestataire rendent la frontière sans écriture exécutoire plutôt que rhétorique.
Témoignage client
Aucun témoignage textuel étayé par la source n’est publié pour ce cas. Les preuves conservées portent sur le produit, le contrôle d’accès et les données en direct ; RECAST n’invente pas une réaction pour remplir un modèle.
Transformation suivante
Découvrez comment LEED Agency a construit une mémoire de reporting persistante autour des règles et sources propres à chaque compte. Plutify transforme la surface de revue client ; LEED transforme la surface d’analyse interne.
Obtenez votre feuille de route IA
Si la donnée source est fiable mais que l’expérience client dépend encore des exportations et des explications, la prochaine couche utile peut se placer au-dessus du système de référence au lieu de le remplacer. Réservez un audit IA gratuit pour tracer cette frontière.
Sources
OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, page 22.RECAST_CASE_STUDIES_2026_UPDATED.pdf, page 18, documentRA-CASES-001, version 2.0.RECAST_WEBSITE_MASTER_BLUEPRINT.md, sections 10.4, 11 et 58.