# Kare / Oskare — Positionnement produit & écart GMAO

> Analyse issue d'une cartographie du code (juillet 2026) : 61 modèles Prisma, ~46 microservices, 4 apps front (`registre`, `audit`, `backoffice`, `landing` ; `amiante` et `ssi` en coquilles vides).

---

## 1. Ce qu'on a aujourd'hui

Le produit couvre, autour du **registre de sécurité dématérialisé** :

- **Conformité réglementaire** : règles avec périodicité `rrule` (calendaire ou réglementaire), échéances par site (`SiteRule.dueAt`) et par personne (`UserRule` — habilitations/formations), statuts de conformité (à l'heure / à risque / en retard), relances automatiques par cron.
- **Interventions = de vrais ordres de travail** : préventif / curatif / formations, workflow complet (à programmer → planifié → exécuté → validé), dates prévues vs réelles, planification automatique du préventif (routines auto-créatrices), signature prestataire, vérification par le gestionnaire, boucle de levée de réserves (action prestataire → décision client).
- **Patrimoine technique** : installations techniques, équipements (état, disponibilité, fabricant, position sur plan), plans/étages avec placement d'items, QR codes terrain.
- **Spécifique sécurité ERP** : commissions de sécurité (convocation, signature, PV, décision), registre des travaux (Cerfa, notices, réception), formations/exercices du personnel, main courante, anomalies/observations/prescriptions avec export PDF.
- **Écosystème** : prestataires + contacts + contrats, GED, calendrier, dashboard, mobile terrain, portail prestataire sans compte, multi-établissements, extraction d'anomalies par IA depuis les rapports PDF, app d'audit sur plans.

## 2. Le type réel de l'application

On est une **plateforme de gestion de la conformité réglementaire du bâtiment** (catégorie anglo-saxonne : *facility compliance management*), avec un **socle GMAO préventive intégré**.

Le déclencheur de tout n'est ni la panne ni le coût : c'est **l'obligation réglementaire et son échéance**. C'est ce qui nous distingue structurellement :

| Catégorie | Déclencheur central | Exemples |
|---|---|---|
| GMAO (CMMS) | La maintenance et son coût | Twimm, Bob! Desk, MaintainX, DIMO Maint |
| EAM | La valeur et le cycle de vie de l'actif | IBM Maximo, HxGN EAM, CARL Source |
| **Nous** | **L'obligation réglementaire et son échéance** | Kare |

Commissions de sécurité, PV, registre des travaux, formations obligatoires : aucune GMAO généraliste n'a ça.

### EAM ? Non

Un EAM = GMAO **plus** gestion financière du cycle de vie des actifs (acquisition, amortissement, TCO, capex, fiabilité), en général pour l'industrie. On en est encore plus loin que de la GMAO, et ça ne correspond ni à nos clients (retail, collectivités, hôtellerie, enseignement) ni à notre ADN (anciens sapeurs-pompiers, conformité ERP).

## 3. Est-on loin d'une GMAO ?

Non — sur le **cœur processus** (planification/exécution), on y est à ~70 % : ordres de travail, préventif auto-planifié, correctif via anomalies, contrats prestataires, calendrier, mobile, historique par équipement. C'est le **volet ressources et économie** qui manque :

| Manque | État actuel dans le code |
|---|---|
| **Coûts & budgets** | Aucun champ coût/prix/budget dans tout le schéma (même `ContractDocument` n'a pas de montant). |
| **Stock & pièces détachées** | Seule trace : la valeur `inStock` de la disponibilité équipement. Pas d'inventaire ni de mouvements. |
| **Main-d'œuvre interne** | Modèle presta-centrique. Pas de temps passé, de taux horaire, de plan de charge. |
| **Demandes d'intervention (ticketing)** | Partiel : anomalies via QR code mobile, mais pas de boucle demandeur ni de file d'arbitrage. |
| **Achats** | Devis/factures = simples types de documents GED, pas d'objets avec statuts liés au flux. |
| **KPIs maintenance** | Dashboard orienté conformité, pas MTBF/MTTR/disponibilité/coûts. |
| **Maintenance conditionnelle** | Déclenchement uniquement calendaire (`rrule`) ; pas de compteurs, relevés, IoT. |

## 4. Workflows des briques manquantes

### 4.1 Demandes d'intervention (ticketing occupants)

1. Un occupant/salarié constate un problème (porte coupe-feu bloquée, fuite) et le déclare — QR code, portail ou email, sans compte.
2. La demande arrive dans une **file d'arbitrage** chez le gestionnaire, qui la qualifie : doublon ? urgence ? couverte par un contrat ?
3. Décision : rejet (avec motif) ou conversion en ordre de travail (chez nous : intervention curative).
4. Le demandeur est notifié à chaque étape et à la clôture — cette boucle de retour fait la valeur du ticketing.

**Chez nous** : la brique la plus proche d'exister. L'anomalie créée par QR code fait déjà les étapes 1–3. Il manque l'identité du demandeur, la file d'arbitrage dédiée et la notification de retour.

### 4.2 Coûts

La fondation de tout le reste — sans coûts, ni budget ni KPIs économiques ne sont possibles. Chaque ordre de travail accumule des **lignes de coût**, puis on agrège.

1. À la création de l'intervention : coût estimé éventuel (le devis).
2. Pendant/après l'exécution : le réel en lignes typées — main-d'œuvre (heures × taux horaire), pièces, prestation externe (montant facture), déplacement.
3. À la clôture : coût total réel vs estimé sur l'intervention.
4. Agrégation : par équipement (« cet ascenseur m'a coûté 8 400 € sur 2 ans »), par site, par type (préventif vs correctif), par période.

**Décision métier débloquée** : réparer ou remplacer (historique de coûts vs valeur de remplacement) ; renégociation des contrats prestataires.

**Chez nous** : un modèle `CostLine` rattaché à `Intervention` (et indirectement `Equipment`/`Site`), un taux horaire sur les profils, un montant sur `ContractDocument`. Peu de modèle pour beaucoup de valeur.

### 4.3 Budgets

Le budget vit **au-dessus** des coûts — n'a de sens qu'une fois 4.2 en place.

1. En début d'exercice, définition d'enveloppes : par site/établissement, par catégorie (préventif / correctif / travaux / formations), par an.
2. Chaque ligne de coût validée **consomme** l'enveloppe correspondante automatiquement.
3. Alertes aux seuils (80 %, 100 %) — comme nos relances d'échéances, mais sur un montant au lieu d'une date.
4. Fin d'exercice : réel vs budget ; le réel de l'année N sert de base pour budgéter N+1.

**Objets** : `Budget` (périmètre, période, catégorie, montant) + lien depuis les lignes de coût.

**Chez nous** : pour les clients multi-établissements (grande distribution, collectivités), sans doute l'argument de vente le plus fort du lot — « combien me coûte la conformité par magasin ».

### 4.4 Achats (devis → commande → facture)

Aujourd'hui devis et factures sont de simples types de documents en GED. Le workflow GMAO en fait des objets avec statuts :

1. Un besoin naît d'une intervention (correction hors contrat, remplacement d'équipement).
2. Demande de devis à un ou plusieurs prestataires — on a déjà `Company`, les contacts, l'envoi d'emails ; extension naturelle du portail prestataire `/p/*`.
3. Devis reçus, comparés, validés — avec seuil d'approbation éventuel (au-delà de X €, validation par un responsable).
4. Bon de commande émis, prestation réalisée, facture reçue.
5. Rapprochement facture ↔ commande ↔ intervention ; la facture génère la ligne de coût.

**Chez nous** : le workflow le plus lourd de la liste. Une version « light » (devis rattaché à l'intervention avec statut proposé/accepté/refusé + montant ; facture rattachée avec montant) suffit à alimenter les coûts sans construire un module achats complet.

### 4.5 Stock & pièces détachées

1. Référentiel d'articles (référence, fournisseur, prix unitaire, stock mini/maxi) et emplacements de stockage.
2. Le technicien consomme des pièces sur une intervention → mouvement de sortie + ligne de coût automatique.
3. Stock sous le mini → suggestion de réapprovisionnement → commande → réception = mouvement d'entrée.
4. Inventaires périodiques pour recaler.

**Chez nous** : la brique la **moins** prioritaire. Notre cible fait exécuter par des prestataires qui apportent leurs pièces. Seul cas pertinent : les consommables sécurité (blocs BAES, extincteurs, ampoules) — un « stock light » sans module achats.

### 4.6 Main-d'œuvre interne

1. Techniciens internes avec compétences/habilitations — on a déjà diplômes et qualifications via `UserRule`, un vrai acquis.
2. Affectation avec plan de charge (qui est dispo cette semaine, qui est surchargé).
3. Sur mobile : exécution avec checklist et **déclaration de temps** (feuille de temps ou pointage — nos `actualStart/End` en sont l'embryon).
4. Temps validé × taux horaire = ligne de coût main-d'œuvre.

**Chez nous** : écart modéré — `Intervention.assignedTo` accepte déjà un user. Manquent la déclaration de temps, le taux et la vue plan de charge.

### 4.7 KPIs maintenance

Pas un workflow : une conséquence des données ci-dessus. Certains sont **déjà calculables** :

- **Calculables aujourd'hui** : ratio préventif/correctif (types d'intervention), taux de respect des échéances (`SiteRule`), délai de résolution des anomalies (`observedAt` → `resolvedAt`), taux d'interventions en retard.
- **Besoin des coûts** : coût de maintenance par site/m²/équipement, réel vs budget, coût préventif vs correctif.
- **Besoin de plus de granularité** : MTBF/MTTR propres (horodater panne/remise en service), taux de disponibilité des équipements.

Un « dashboard maintenance » à côté du dashboard conformité serait un quick win crédibilisant le positionnement GMAO.

### 4.8 Maintenance conditionnelle (compteurs)

Ajoute un second déclencheur à côté du calendrier :

1. Compteurs sur les équipements (heures de fonctionnement, cycles, relevés).
2. Relevés saisis à la main (le QR code s'y prête) ou remontés par capteurs IoT.
3. Règle de déclenchement « toutes les 500 h » ou « si valeur > seuil » → création automatique d'intervention, comme nos routines auto-créatrices sur le calendrier.

**Chez nous** : le moteur `Routine` est déjà conçu pour « déclencheur → auto-création » ; ce serait un deuxième type de déclencheur, pas une refonte. Besoin client faible à court terme (la conformité réglementaire est calendaire par nature).

## 5. Positionnements possibles

1. **Assumer la niche : « le registre de sécurité augmenté »** (positionnement actuel du site vitrine). Défendable, différenciant, mais marché plafonné au réglementaire ERP.
2. **« Plateforme de conformité bâtiment » multi-registres** — élargir aux autres obligations : amiante/DTA et SSI (déjà en roadmap, apps en coquilles vides), accessibilité, légionelle, DUERP. Le moteur règles/échéances/preuves est déjà générique : extension la plus naturelle.
3. **« GMAO réglementaire » (compliance-first CMMS)** — attaquer le marché GMAO bâtiment par l'angle conformité, en ajoutant coûts, ticketing et un peu de stock. Chemin le plus court vers un marché plus gros.
4. **CAFM light / gestion technique de patrimoine** — plans, équipements localisés, audit sur plans, GED : les briques y sont, mais ça nous éloigne de notre différenciation.

**Lecture recommandée : 2 + 3 combinés** — « la plateforme qui transforme les obligations réglementaires du bâtiment en plan de maintenance exécuté et prouvé ». La conformité reste la porte d'entrée (personne ne nous bat là-dessus), la GMAO devient l'extension naturelle une fois le client équipé.

## 6. Ordre logique de construction

Les dépendances imposent presque l'ordre :

1. **Coûts** — rien ne marche sans (4.2).
2. **Budgets** — la valeur multi-établissements (4.3).
3. **Ticketing** — on en a déjà ~70 % (4.1).
4. **Devis/factures light** — alimente les coûts sans module achats complet (4.4).
5. **Main-d'œuvre interne** — selon la demande client (4.6).
6. **Stock, compteurs** — en dernier : briques d'une GMAO industrielle, pas d'une plateforme de conformité bâtiment (4.5, 4.8).

En parallèle, le **dashboard maintenance** (4.7) est un quick win dès que les premières briques coûts existent.