sodimo

Chapitre 30 / 39

CRM

Statut : Planifié

Le CRM Sodimo est le joyau de cette mission. C’est une application TypeScript maison tournant sur Cloudflare (Worker + D1), s’inspirant largement de Twenty CRM et de Pipedrive, sans forker l’un ni l’autre. Conformément au chapitre 15 Principe 1 (fork conceptuel plutôt qu’adoption upstream), nous lisons ce que ces produits font, sélectionnons les fonctionnalités dont Rani a réellement besoin, et écrivons le nôtre.

Pourquoi ne pas forker Twenty ni auto-héberger Pipedrive

Les deux options échouent au test statique-à-la-livraison. Twenty est un produit OSS jeune et en mouvement rapide, avec une cadence de release qui casserait Sodimo dès la première migration de schéma sans ingénieur disponible. Pipedrive en auto-hébergement est un produit commercial hébergé, pas une option ; et la surface fonctionnelle upstream complète est bien au-delà de ce qu’utilise Rani. Notre propre CRM restreint — construit sur des primitives Cloudflare que Sodimo fera tourner de toute façon — est l’artefact plus sûr et moins coûteux à long terme.

Forme de l’application

Un seul Cloudflare Worker sert l’interface du CRM et son API interne. La base de données D1 du Worker contient tous les enregistrements CRM. Cloudflare Access (Google Workspace comme IdP) protège chaque route ; il n’y a pas de surface publique. Les outils MCP sur le Worker sodimo-core (voir ch42) lisent et écrivent dans le même D1 — l’interface CRM et MCP sont deux interfaces sur une seule base de données.

Fonctionnalités à la livraison

  • Vue pipeline Kanban. Glisser les deals entre les étapes. Les définitions d’étapes sont configurables par utilisateur, mais un ensemble par défaut est fourni avec l’image. C’est la fonctionnalité Pipedrive à laquelle Rani ne renoncera pas, confirmée dans (D-060, D-125 ANNOTÉS).
  • Fiches clients. Une ligne par client Sodiwin. Inclut les champs de contact, le résumé des dernières commandes, le solde AR, l’historique des visites, le palier de prix, et les cinq SKUs principaux par volume. Alimenté quotidiennement depuis Sodiwin — voir ch24 pour le schéma et le contrat ETL.
  • Enregistrements de deals et d’activités. Une ligne par deal ouvert ; commentaires liés, e-mails, notes, comptes-rendus de visite. Le fil d’activités est la fonctionnalité Pipedrive-et-Twenty que tout le monde attend.
  • Vues « Top du moment » modèles. Cinq vues pré-construites que l’équipe de Rani utilise quotidiennement : Top du moment quotidien, Suivis en retard, Clients à risque, Nouvelles opportunités, Tournée du jour. Paramètres modifiables ; un constructeur de tableau de bord généraliste est hors périmètre pour cette mission.
  • Automatisation Recouvrement. Les relances de retard de niveau 1 (faible valeur, premiers jours) s’envoient automatiquement avec Paul en BCC. Les niveaux supérieurs se glissent dans la file d’approbation de Paul avec un drapeau « escalade vers la direction » quand un seuil est franchi. Câblage complet dans ch42 (MCP) + ch34 (mail) ; le CRM est l’endroit où les humains voient et approuvent.
  • Cartes d’alerte delta. L’outil delta-alert écrit dans le pipeline sous forme de cartes Kanban — nouvelle chute de SKU, changement de volume au-dessus du seuil, rupture de cadence. La source de l’alerte vit dans D1 sur des vues dérivées de l’ETL (voir ch23).

Ce qu’il absorbe de Pipedrive

Pipedrive est décommissionné progressivement une fois que le CRM Sodimo s’avère stable en production — tests en conditions réelles, pas une bascule big-bang (D-061 ANNOTÉ). Les fonctionnalités absorbées avant la date de bascule : étapes pipeline et glisser-pour-avancer, fil d’activités, auto-attachement des fils d’e-mail à un deal, et le flux de rappels/séquences (ce que Pipedrive appelle « automatisations »).

Séparation de Sodiwin

Le CRM n’est pas une vue sur Sodiwin. Il n’y a pas d’interface Sodiwin intégrée, pas de requête Sodiwin en direct depuis le CRM, pas d’écritures Sodiwin depuis le CRM. Sodiwin est la boîte noire (voir ch14) ; le CRM est en aval de l’export quotidien. Si ce n’est pas dans D1 la nuit précédente, ce n’est pas dans le CRM aujourd’hui. Cette séparation est délibérée et Tom-direct (D-128 ANNOTÉ : « no sodiwin-in-crm. there is a clear layer of separation »).

Où ça vit

  • Dépôt : sodimo/mcp contient le schéma D1 et le code Worker. Un dépôt sodimo-crm séparé peut être créé si l’interface grandit suffisamment pour le justifier ; c’est une décision Semaine 2+, pas un bloqueur de livraison.
  • Données : base de données D1 partagée avec MCP et le registre d’exécution. Une base de données, une source de vérité pour l’état opérationnel de Sodimo.
  • Accès : crm.sodimo.eu, protégé par Cloudflare Access avec Google Workspace.
  • Comptabilité des tokens : chaque action CRM qui invoque un LLM (rédiger un e-mail de recouvrement, résumer un client, générer une vue quotidienne) écrit une ligne dans run_ledger conformément au chapitre 15 Principe 2.

Ce qui n’est pas dans le CRM à la livraison

  • Pas de constructeur de tableau de bord complet. Vues modèles uniquement ; le constructeur est un travail Mois 3+.
  • Pas d’application mobile. L’interface web sur un téléphone est l’histoire mobile pour cette mission.
  • Pas de moteur d’automatisation (règles « quand X alors Y » configurables par l’utilisateur). Différé à T+30 ; la Semaine 2 livre le Kanban avec des transitions manuelles (D-125 ANNOTÉ option B).
  • Pas d’écriture retour vers Sodiwin depuis le CRM. Les commandes sont saisies dans Sodiwin directement ou via l’agent computer-use (voir ch45), pas via le CRM.