Livrable · Pilote
On a audité le système réel de SOS Maintenance à partir d'un accès direct au Drive opérationnel : les dossiers partagés, le Roaster, l'Operation Tracking, le bloc financier, les licences, les maintenance reports. Le tout recoupé avec les deux briefs d'Arthur et son propre audit financier d'avril 2026.
Le but : comprendre comment la boîte gagne de l'argent et où sont les freins, avant de recommander quoi construire. On n'a pas refait un diagnostic de plus : on a cherché ce qui, une fois automatisé, tient dans le temps et scale.
L'objectif de SOS est clair. Gérer les urgences des villas de S&P Management, et dériver vers les gros chantiers pour la performance financière. La raison est stratégique : dépendre de S&P seul (qui représente aujourd'hui la quasi-totalité du chiffre) ne garantit pas la pérennité de la boîte. Tout le système, et le levier du maintenance report en particulier, sert cette diversification.
Un MR n'est pas un rapport : c'est un document de vente de travaux. Sur un rapport de maintenance réel (mai 2026) : 15 points relevés (6 interventions urgentes et 9 travaux à valider par le propriétaire), chacun documenté et photographié, pour un devis d'environ 68 000 THB de travaux. Chaque ligne est un travail à valider et facturer, et ces travaux sont de la rénovation (peinture, façades, corniches, remplacements), pas des dépannages d'urgence.
Inspection villa, puis MR (qui détecte N travaux), puis validation propriétaire, puis devis, puis interventions facturées, puis review before/after (preuve, marketing, QR satisfaction), puis fidélisation, puis nouveaux MR. Plus SOS produit de MR, plus il remplit son carnet de commandes.
Aujourd'hui ce cycle est semi-manuel : photos déposées à la main, rapport lancé manuellement, une villa à la fois. C'est le goulot de croissance numéro 1.
La saisonnalité commande le rythme. De novembre à février (haute saison locative), les villas sont occupées : peu de disponibilité pour la maintenance, l'activité est dominée par les urgences. De mars à octobre, les villas se libèrent et il faut remplir le planning de chantiers : c'est la fenêtre où le maintenance report prend toute sa valeur, en détectant de quoi combler les creux et lisser les rendements sur l'année.
Le pilotage proactif existe déjà, mais sur tableur. Un onglet de suivi liste les 110 villas du parc avec, pour chacune, son statut de maintenance report et son suivi préventif (climatisation, gouttières, robinets). L'état réel y est parlant : 26 villas ont un MR en attente (un carnet de commandes identifié qui dort), 18 ont un MR à jour, et le préventif climatisation n'est renseigné que sur 6 villas sur 110. Le potentiel est déjà cartographié ; ce qui manque, c'est de le faire tourner.
La planification vit dans trois outils distincts, à ne pas confondre : le Roaster (planning mensuel, fait une fois par mois, les jours de travail on / off de chaque technicien), le Schedule (planning au jour le jour, qui fait quoi, quand et où), et le OT money (le suivi des heures supplémentaires). L'état et la finance vivent dans l'Operation Tracking (une dizaine d'onglets). En externe : Hostfully (dispo des villas, environ 90 % du parc) et les relevés bancaires.
Les chiffres ci-dessous viennent de l'audit d'avril d'Arthur. Ils sont indicatifs et à réactualiser : avril était possiblement un mois atypique, chargé en Big Work.
Les montants exacts sont à réactualiser avec Arthur pour le livrable final.
La vitesse de production des MR plafonne la détection et la vente de travaux. C'est le frein numéro 1 au revenu.
Une intervention est saisie 3 fois ou plus (Tracking, Schedule, facturation), sur une quinzaine de fichiers, par 5 à 6 comptes.
Grilles visuelles, recopie quotidienne, formules cassées, heures non loggées. C'est le propre audit d'Arthur qui le constate.
Suivi hebdo abandonné, rapports limités à un mois. Sans automatisation, rien ne tient dans la durée.
L'entretien climatisation, récurrent et facturable, n'est renseigné que sur 6 villas sur 110 alors que tout le parc en aurait besoin.
Des arbitrages, pas une liste de souhaits. L'ordre reflète la valeur.
Capture terrain structurée (photos et notes taggées tier et emplacement), puis génération auto du rapport, puis envoi et suivi de validation, puis conversion des travaux validés en devis et interventions, puis review before/after. On démultiplie la capacité de vente, pas juste le confort.
Le socle devient une vraie base de données unique.
Une intervention entrée une fois, propagée partout : mission, planning, état, facture, MR.
Simple aujourd'hui, conçue pour absorber la TVA et la retenue à la source dès que le scaling l'imposera (détail en section 8).
Le MR détecte et propose l'entretien climatisation, ce qui en fait une offre récurrente quand SOS scale.
Auto-classer le tier, capter les photos à l'intake, dispatch interne Telegram, tableau de bord temps réel.
Le socle : une base Postgres managée (Supabase) plus une application sur-mesure, hébergée par le client, opérée par le Studio. Coût du socle : de l'ordre de 25 à 40 $ par mois.[1]
Vos données vivent sur l'infrastructure d'Arthur (pas la nôtre), elles sont exportables à tout moment, et le contrat garantit la réversibilité. Ce que l'hébergement client ne suffit pas à garantir : comme le Studio opère le système, notre accès technique doit être encadré par le contrat, borné et journalisé (détail en section 6). L'hébergement décide du lieu de la donnée, pas de qui peut la lire : les deux sont traités séparément.
Tout le système repose sur deux boucles qui alimentent la même base, reliées par un lien d'origine explicite. Sans ce lien, on ne saurait pas quel travail vient d'un MR (donc pas de traçabilité du retour sur investissement), et on créerait des doublons.
Entités : Villa (porte l'état MR et l'état préventif), MR, Intervention (avec source = réactif ou mr_id), Devis, Partner, Matériau. La villa est la source d'état : son statut se déduit de l'état de ses travaux, jamais tenu à la main dans un onglet parallèle. C'est ce qui remplace les quinze fichiers désynchronisés d'aujourd'hui.
La saisie unique reprend exactement le point d'entrée actuel (l'onglet Inhouse_revenue), mais structuré : une intervention capte qui saisit, le tier, la date, la villa, le ou les techniciens, la description, l'avancement (fait, planifié, en cours), le villa manager, la présence de photos et la durée.
Le montant n'est plus tapé à la main : il est dérivé de la grille de pricing interne (tarif selon le nombre de techniciens fois la durée fois le tier, avec la marge fois 2 déjà appliquée par SOS), plus les matériaux refacturés (segment Overhead & Profit) et la sous-traitance (segment Partner, +25 %). La grille de pricing est une table de configuration éditable : Arthur ajuste ses tarifs sans qu'on touche au code.
L'équipe saisit ce qu'elle a fait, le système calcule ce que ça coûte. Fini la ressaisie des montants et les formules cassées.
Le client héberge, le Studio opère. Ce partage crée une règle simple à tenir : héberger n'est pas protéger.
Comme le Studio opère le système, une clé d'administration technique (service_role) contourne par nature l'isolation par rôle. La protection ne peut donc pas reposer sur l'hébergement : elle repose sur trois piliers.
Le système manipule plusieurs catégories de données personnelles ou confidentielles :
Chaque catégorie fait l'objet d'un test d'isolation dédié avant la prod : on vérifie concrètement qu'un compte technicien ne lit ni la paie, ni la santé, ni le bancaire, ni l'Owner Report. L'isolation se prouve, elle ne se décrète pas. Le bancaire est sorti de la table lue par l'application : le rapprochement se fait sur un fichier exporté isolé, jamais d'accès direct au compte bancaire depuis l'app.
Les photos de MR sont des données personnelles : elles montrent des lieux, parfois des personnes, et portent une localisation. Le stockage de fichiers ne suit pas automatiquement l'isolation des tables : il faut donc un bucket privé, un accès par URL signée à durée de vie courte (pas d'URL publique permanente), et une policy de stockage testée au même titre que les tables.
La qualification PDPA des photos reste à confirmer sur source primaire, avec le juriste d'Arthur.
WhatsApp et Telegram sont des services tiers : ce qui y transite n'est pas couvert par le « client héberge ». Du sensible peut y circuler (adresses de villas, noms). Le bot Telegram est scopé au strict nécessaire (token en secret, on ne stocke que le champ métier extrait, jamais le message brut).
La base légale PDPA de la lecture d'un groupe, et l'information des personnes concernées, restent à confirmer avec le juriste d'Arthur.
Tout point de droit PDPA reste à recouper sur source primaire. On sert une architecture qui permet la conformité ; on ne tranche pas le droit thaï à la place du comptable ou du juriste d'Arthur.
Un dé-risquage déjà fait, sans écrire une ligne de code.
L'API WhatsApp officielle ne permet pas de lire un groupe tiers existant : ses fonctions de groupe se limitent à des groupes créés et possédés par le compte business, plafonnés et soumis à un seuil de volume hors de portée ici.[4]
Les passerelles non officielles (type whapi.cloud) y parviennent via la session WhatsApp Web, en zone grise, avec risque de bannissement du numéro : exclu d'un système pro durable.
L'intake reste un geste humain simple. L'automatisation se joue en interne : dispatch, suivi, MR. On a écarté le seul vrai morceau risqué avant de s'engager dessus.
Régime actuel, déclaré par SOS : pas de TVA, pas de retenue à la source, factures simplement numérotées. Le système gère ça nativement aujourd'hui.
Un point à cadrer avec le comptable, présenté factuellement. Le seuil de TVA thaï se déclenche sur le chiffre d'affaires (1,8 M THB par an, ou dès 300 000 THB sur un seul mois), pas sur le bénéfice, avec obligation de s'enregistrer dans les 30 jours du dépassement.[5] Sur la base du seul mois d'avril, le volume annualisé (environ 551 000 THB fois 12) dépasse déjà largement ce seuil. Savoir où SOS se situe exactement, et à quelle échéance l'enregistrement s'impose, relève de son comptable : c'est un point à clarifier avec lui, nous ne tranchons pas le fiscal.
Côté système, on conçoit la brique prête : TVA 7 % activable, retenue à la source activable sur le segment sous-traitance (Partner), numérotation en série, séparation HT / TVA. Tout reste désactivé jusqu'à la bascule, mais le scaling ne cassera pas la brique le jour venu.
Priorité validée avec Arthur. Chaque brique est un incrément durable de la vision finale (pas jetable), posé sur le socle (la saisie unique).
| # | Brique | Rôle |
|---|---|---|
| 1 | Pilier : saisie unique et chaîne MR / review | Le socle plus la chaîne MR automatisée (inclut l'archivage photos qui alimente le MR). C'est le coeur de valeur : l'investissement le plus lourd en amont, le retour via le carnet de commandes qu'il ouvre. |
| 2 | Tableau de bord temps réel | La vue vivante de l'état du parc et de l'activité. |
| 3 | Dispatch interne Telegram | Le relais des missions vers les techniciens, en interne, sans dépendre de WhatsApp. |
| 4 | Les briques à cash rapide | Plus tard, elles s'auto-financent (le revenu rentre vite) : préventif clim vendu via le MR, facturation automatique complète, relance du backlog de travaux en attente. |
Le levier le plus fort est le MR. D'après Arthur, un MR génère en moyenne de l'ordre de 40 000 THB de travaux (6 à 20 travaux détectés). Un rapport de maintenance réel récent (mai 2026, 15 points relevés) a débouché sur un devis de près de 68 000 THB : la moyenne de 40 000 THB est donc réaliste, et sans doute prudente. Le potentiel n'est d'ailleurs pas théorique : 26 des 110 villas ont déjà un MR en attente, un carnet identifié qui ne demande qu'à être produit et vendu. Ces travaux sont de la rénovation (peinture, façades, corniches, remplacements), pas des dépannages à quelques centaines de THB. Le taux de conversion proche de 100 % reste une estimation d'Arthur, à consolider dans le temps.
Plus SOS couvre de villas avec un cycle MR régulier, plus il détecte et vend de travaux.
Automatiser la chaîne MR lève le plafond de détection et de vente : aujourd'hui, la boîte ne peut inspecter et proposer qu'au rythme du manuel. Et c'est précisément de mars à octobre, quand les villas se vident et que le planning de chantiers a des creux à remplir, que ce plafond coûte le plus cher. Ce n'est pas une promesse d'encaissement mécanique.
Le revenu réellement encaissé suit ensuite deux limites bien réelles : la capacité technique (7 techniciens, dont l'allocation bascule vers les gros chantiers en saison, jusqu'à 5 sur 7, ne laissant que 2 techniciens aux urgences, le débordement d'urgence passant alors par des prestataires externes) et la trésorerie matériaux (la caisse doit avancer les matériaux avant d'être remboursée). Le MR ouvre le robinet ; le débit reste borné par les techniciens et le cash. C'est cette levée de plafond qu'on vend, pas un chiffre garanti.
Un potentiel de l'ordre de plusieurs centaines de milliers à environ 1,4 M THB par an à l'échelle du parc (environ 110 villas fois 5 à 8 climatisations fois 600 THB par entretien fois 2 passages par an), aujourd'hui presque entièrement dormant. Le ROI chiffré de chaque brique s'écrit avant son prix.
Valider cette direction, lancer le pilier (socle et MR) comme première preuve concrète, puis dérouler les briques au fil des preuves.