# Omika — Analyse complète du projet (base pour le site web marketing)

> **Objet** : fournir une compréhension profonde du code source du projet **Omika**
> pour concevoir un site web de vente de l'application. Ce document croise
> l'architecture, les fonctionnalités réelles implémentées, la stack technique,
> le modèle de données et les différenciateurs, avec — pour chaque point — la
> preuve dans le code.
>
> **Sources** : code source (`src/`), solution `Omika.slnx`, documentation
> (`docs/*.md`), maquette UX (`docs/maquetteOmika.html`), fichiers de projet.
>
> **Statut du produit au moment de l'analyse** : version `1.0.0`, socle
> fonctionnel **solide et très avancé côté serveur/API**, application mobile
> **offline-first en progression** (consultation complète + écriture
> Intervention + documents/photos + saisie des temps), enrichi d'un
> **centre de diagnostic** d'exploitation.

---

## 1. Résumé exécutif (pitch)

**Omika** est une application de **gestion des interventions terrain**
(field service management) destinée aux entreprises de dépannage, maintenance,
installation et travaux (CVC, plomberie, électricité, couverture, SAV, etc.).
Elle couvre tout le cycle : **clients → sites → dossiers → interventions →
rendez-vous/planning → suivi des temps → documents/photos → comptes rendus →
rapports → e-mails**, avec une application **mobile offline-first** (Android,
iOS) et une console **desktop** (Windows/macOS/Linux).

Points de vente majeurs :

- **Migration réussie d'un logiciel métier legacy** (WinDev « Batik », ~15 ans
  d'existant) vers une **stack .NET moderne** sans casser la base de données
  existante (HFSQL de PC SOFT) — c'est un argument de confiance fort.
- **Offline-first** : les techniciens travaillent sans réseau ; la
  synchronisation est **fiable, idempotente et asynchrone**.
- **Multi-plateforme** : une seule base de code (Avalonia) pour Android, iOS et
  desktop.
- **Monétisation intégrée** : activation par **licence**, verrouillage par
  appareil, jetons signés — le produit est prêt à être vendu.
- **Exploitabilité** : un **centre de diagnostic** + télémétrie OpenTelemetry
  pour le support et l'exploitation.

---

## 2. Qu'est-ce qu'Omika ? (positionnement produit)

| Élément | Valeur |
|---|---|
| **Nom** | Omika |
| **Slogan / positionnement** | « Interventions terrain » (maquette `docs/maquetteOmika.html`) |
| **Catégorie** | Gestion d'interventions / Field Service Management / CRM terrain |
| **Usage** | Suivi des interventions techniques chez les clients, du RDV au rapport |
| **Public cible** | Sociétés de services techniques (artisans, PME, groupes) |
| **Éditeur historique** | Applilogik (URLs de licence `*.applilogik.fr`) |
| **Ancêtre** | Batik / Isis_BO (WinDev), décliné pour plusieurs clients (SLAMM, Bouvard, Artisans Partenaires, Batigest) |

Le cœur métier : **l'intervention** est l'agrégat central. Autour gravitent les
**clients**, **contacts**, **sites/lieux**, **dossiers** (groupes
d'interventions), **rendez-vous** (planning individuel et d'équipe), **suivi des
temps**, **documents/photos**, **comptes rendus**, **rapports** (modèles
personnalisables), **e-mails** (modèles + SMTP), **collaborateurs/équipes**,
**rôles et droits d'accès**, et **paramètres métier** configurables.

---

## 3. Historique et contexte : du WinDev au .NET

Le projet est une **réécriture** d'un logiciel historique WinDev :

| | Génération 1 (legacy) | Génération 2 (ce dépôt) |
|---|---|---|
| Langage | WinDev (WLanguage) | C# / **.NET 10** |
| Base de données | HFSQL (PC SOFT) | HFSQL **inchangée** + SQLite (mobile) |
| Interface | Fenêtres WinDev | **Avalonia** (Desktop / Android / iOS) |
| Web service | `Batik_WS_Com_Mob`, `Batik_WS_Lic_Mob` | **Omika.Api** (ASP.NET Core) |
| Service de sync | `Omika_S_Comm_DEV` (WinDev) | **Omika.Worker** (.NET) |

Chiffres clés du legacy rétro-ingénieré (source : `docs/ESTIMATION_EFFORT_DEVELOPPEMENT.md`) :

- ~**600 000 lignes** de corpus legacy analysé (2 générations WinDev + 3 web services) ;
- ~**1 600 procédures**, **140 fenêtres**, ~**380 classes**, **46 états d'impression** ;
- schéma HFSQL : **48 → 58 tables**, **720 rubriques** mappées.

**Règle d'or du projet** : la base HFSQL existante **n'est jamais modifiée**
(aucune table/collonne ajoutée ou supprimée). Le nouveau code lit/écrit dans les
tables existantes. Cela garantit une **cohabitation sans risque** avec
l'ancien système et une bascule progressive.

> **Argument commercial** : « On remplace votre vieux logiciel sans toucher à
> vos données. » C'est rare et rassurant pour un acheteur qui a 15 ans
> d'historique.

---

## 4. Cible, personas et cas d'usage

### 4.1 Personas

1. **Le technicien / intervenant terrain** (mobile) : consulte son agenda du
   jour, ouvre la fiche intervention, prend des photos, ajoute des documents,
   saisit son temps, consulte le client/site/contact, travaille **sans réseau**.
2. **Le chef d'équipe / planificateur** (desktop) : planifie les rendez-vous,
   suit l'agenda de l'équipe, affecte les collaborateurs.
3. **Le back-office / administratif** : gère clients, dossiers, documents,
   modèles de rapports et d'e-mails, paramètres métier.
4. **L'exploitant / le support** : utilise le centre de diagnostic
   (`Diagnostics.Web`) pour suivre la santé du parc, les erreurs, la
   synchronisation, la télémétrie.

### 4.2 Cas d'usage couverts (de bout en bout)

1. Activation de licence → session sécurisée → shell.
2. Consultation de l'agenda (jour) et du détail d'un RDV.
3. Consultation/recherche/filtre des interventions (actif/archivé).
4. **Création / modification / archivage d'une intervention** (offline).
5. **Ajout de photos / documents** sur intervention (offline).
6. **Saisie du temps** (offline, rattachée à une intervention ou un RDV).
7. Génération de **rapports** (modèles Word/RTF → PDF) et **e-mails** (modèles
   + SMTP) — backend.
8. **Synchronisation** manuelle mobile ↔ serveur.
9. **Diagnostic** du parc et de la sync (support).

---

## 5. Inventaire fonctionnel (le cœur du marketing)

> État réel par module. Légende : ✅ opérationnel · 🟡 partiel/backend · ⬜ en projet.

### 5.1 Référentiels (données de base)

| Fonction | État | Preuve dans le code |
|---|---|---|
| **Clients** (fiche, liste, adresses) | ✅ API + 🟡 mobile (lecture) | `ClientService`, `ClientEndpoints`, `ClientDetailView` |
| **Contacts / personnes** (rôles, civilité, tel, e-mail) | ✅ API + 🟡 mobile (lecture) | `ContactService`, `ContactEndpoints`, `ContactDetailView` |
| **Sites / lieux** (adresse, GPS prévu) | ✅ API + 🟡 mobile (lecture) | `SiteService`, `SiteEndpoints`, `SiteDetailView` |
| **Sociétés** | ✅ | `Societe` (entité), `SocieteDto` |
| **Collaborateurs** | ✅ API + 🟡 mobile (lecture) | `CollaborateurService`, `CollaborateurEndpoints` |
| **Équipes** | ✅ API | `EquipeService`, `EquipeEndpoints` |
| **Rôles & droits d'accès** | ✅ | `Role`, `DroitAcces`, `Permission`, `MobileIdentityProvider` |
| **Paramètres métier** (types, statuts, civilités, catégories…) | ✅ | `ParametreMetier`, `ReferenceDataService`, `ReferenceDataEndpoints` |

### 5.2 Dossiers & interventions

| Fonction | État | Preuve |
|---|---|---|
| **Dossiers** (regroupent des interventions) | ✅ API + 🟡 mobile (lecture) | `DossierService`, `DossierEndpoints`, `DossierDetailView` |
| **Interventions** (création/modif/archive) | ✅ **bout en bout offline** | `InterventionService`, `InterventionSyncOperationHandler`, `InterventionEditView` |
| Recherche d'interventions | ✅ mobile (locale) + API | `MobileInterventionSearchService`, `InterventionsView` |
| Filtre actif / archivé | ✅ | `EstArchive` |
| Actions d'intervention | ✅ | `ActionIntervention`, `ActionInterventionDto` |
| États d'intervention | ✅ | `EtatIntervention`, `EtatInterventionDto` |
| Checklists | ✅ | `Checklist`, `ChecklistItem` |
| **Compte rendu** (signé électroniquement client + technicien, devis conforme, réserves) | 🟡 backend | `CompteRenduService`, `CompteRenduEndpoints` |

### 5.3 Planning & rendez-vous

| Fonction | État | Preuve |
|---|---|---|
| **Agenda du jour** (RDV) | ✅ mobile | `AgendaView`, `AgendaViewModel` |
| Navigation jour précédent/suivant | ✅ | `AgendaDayDisplayItem` |
| **Détail d'un RDV** | ✅ mobile (lecture) | `RendezVousDetailView` |
| **Agenda d'équipe** | 🟡 (maquette + API) | `AgendaEquipeView`, `RendezVousEndpoints` |
| CRUD rendez-vous | 🟡 backend (API) | `RendezVousService`, `CreateRendezVousRequest` |
| Participants / contacts d'un RDV | ✅ | `ParticipantRendezVous`, `RDV_Collaborateur`, `RDV_Contact` |
| Annulation (motifs) | ✅ modèle | `AnnulationRendezVous` |

### 5.4 Suivi des temps

| Fonction | État | Preuve |
|---|---|---|
| Consultation des temps | ✅ mobile (liste) | `SuiviTempsLocalService`, `SuiviTempsViewModel` |
| **Saisie de temps** (offline-first) | ✅ | `SuiviTempsCreateView`, `SuiviTempsCreateViewModel`, `SuiviTempsSyncOperationHandler` |
| Référentiel « type de temps » local | ✅ | `IParametreMetierLocalService.GetTypeTempsAsync()` |
| Validation métier (champ `Valide`) | 🟡 backend | `SuiviTempsService` |

### 5.5 Documents & photos

| Fonction | État | Preuve |
|---|---|---|
| Liste des documents d'une intervention | ✅ mobile | `InterventionDocumentsView` |
| **Ajout photo/document (offline)** | ✅ | `OutboxService` + `DocumentGuid` + `SyncEngine` |
| Téléchargement à la demande | ✅ | `MobileDocumentService`, `GET /api/documents/{guid}` |
| Ouverture offline (cache) | ✅ | `DocumentCacheService` |
| Visionneuse photo | ✅ | `PhotoViewerView` |
| Éditeur d'image | ✅ | `ImageEditorView` (SkiaSharp) |
| Optimisation des photos | ✅ | `PhotoOptimizationSettings`, SkiaSharp |
| Lecture EXIF (date réelle de prise de vue) | ✅ | `MetadataExtractor` |

### 5.6 Rapports & e-mails (backend)

| Fonction | État | Preuve |
|---|---|---|
| **Modèles de rapport** (Word/RTF) | ✅ | `ModeleRapportService`, `ModeleRapport` |
| **Modèles d'e-mail** | ✅ | `ModeleMailService`, `ModeleMail` |
| Mots-clés / rubriques de substitution | ✅ | `MotClefService`, `RubriqueSubstitutionEngine` |
| **Génération DOCX → PDF** | ✅ | `DocumentGenerationService`, `RapportPdfService`, `DocumentFormat.OpenXml` |
| Pré-remplissage des champs depuis la base | ✅ | `RapportChampService`, `RapportChampEndpoints` |
| **Envoi d'e-mail (SMTP)** | ✅ | `EmailCreationService`, `MailKitEmailSender` (MailKit) |
| Images inline dans les e-mails | ✅ | `EmailImageInliner`, `EmailDocxRenderer` |
| Conversion RTF/HTML | ✅ | `RtfPlainText`, `DocxHtmlConverter` |
| Écrans mobile rapport/e-mail | ⬜ (maquette uniquement) | `RapportChampsView`, `NouveauEmailView` (partiels) |

### 5.7 Synchronisation & hors-ligne

| Fonction | État | Preuve |
|---|---|---|
| **Mode hors-ligne** (SQLite locale) | ✅ | `omika.db`, `LocalDatabase`, `SnapshotApplier` |
| **Moteur de synchronisation** | ✅ | `SyncEngine` |
| **Outbox** (file des changements) | ✅ | `OutboxService`, `OutboxRepository` |
| **Idempotence** (pas de doublon) | ✅ | `OperationId` + `ISyncOperationStatusStore` |
| **Retry** (max 30, rejet terminal) | ✅ | `SyncProcessor`, `MaxRetryCount=30` |
| **Snapshot** agenda serveur → mobile (RDV ±14 j + interventions/contacts liés) | ✅ | `MobileSnapshotService`, `MobileSnapshotResponse` |
| Chargement « à la demande » des fiches (client/site/dossier/document/temps) | ✅ | `MobileInterventionSearchService`, endpoints `/api/*` |
| Réconciliation d'identités (GUID mobile ↔ PK) | ✅ | `MobileIdentityReconciliationService`, `MobileEntityIdentityResolver` |
| État de sync affiché (Pending/Rejected) | ✅ | `SynchronisationView`, `PendingSyncItem` |

### 5.8 Licence & sécurité

| Fonction | État | Preuve |
|---|---|---|
| **Activation par licence** (code client + n° licence) | ✅ | `LicenseService`, `LicenseActivationView` |
| **Inscription par QR code signé** (RSA-SHA256, `kid`) | ✅ | `EnrollmentQrCodec` |
| Validation / révocation | ✅ | `POST /api/license/validate` |
| **Verrouillage par appareil** | ✅ | `AssignDeviceAsync` (`LI_IDMobile`) |
| **Jeton signé** HMAC-SHA256 (stateless, 2 segments) | ✅ | `TokenService`, `MobileAuthMiddleware` |
| Codes d'erreur métier | ✅ | `LicenseErrorCodes` (14 codes E0xxx/E1xxx/E2xxx/E3xxx) |
| Stockage sécurisé du token (Keystore/Keychain/secure storage) | ✅ | `PlatformSecureTokenStore` |
| Authentification back-office (PBKDF2-SHA256) | ✅ | `DiagnosticPasswordHasher`, `BackOfficeAuthEndpoints` |

### 5.9 Exploitation & support (Diagnostic Center)

| Fonction | État | Preuve |
|---|---|---|
| **Portail web d'exploitation** | ✅ | `Omika.Diagnostics.Web` (Dashboard, Diagnostics, Erreurs, Traces, Synchronisation, Telemetry, Parc, Versions, Référentiel) |
| Gestion des clients diagnostics (serveurs) | ✅ | `ClientCode` + `ApiKey` |
| **Gestion des utilisateurs** (rôles Support/Admin) | ✅ | `DiagnosticUserAuthenticator`, page `/Users` |
| Base PostgreSQL dédiée | ✅ | `omika_diagnostics` (Npgsql) |
| **Télémétrie** (traces/logs/métriques) | ✅ | `Omika.Observability.External` (OpenTelemetry, OTLP) |
| **Outbox de diagnostic** (buffering hors-ligne) | ✅ | `Omika.Core/Observability/Outbox` |
| Forwarding vers le centre central | ✅ | `Omika.Core/Observability/Forwarding` |

---

## 6. Architecture technique

### 6.1 Stack

| Couche | Technologie |
|---|---|
| Langage / runtime | C# 13 / **.NET 10** |
| UI | **Avalonia 12.1.1** (Fluent, Inter, Skia) |
| MVVM | CommunityToolkit.Mvvm 8.4.2 |
| API | **ASP.NET Core** (Minimal API) + OpenAPI |
| Service de fond | `Microsoft.NET.Sdk.Worker` (BackgroundService) |
| Base serveur | **HFSQL (PC SOFT)** via **ODBC** + **OLE DB** |
| Base mobile | **SQLite** (Microsoft.Data.Sqlite) |
| Base support | **PostgreSQL** (Npgsql) |
| E-mail | **MailKit** (SMTP) |
| Documents | **DocumentFormat.OpenXml** (DOCX), conversion PDF |
| Images | **SkiaSharp** + **MetadataExtractor** (EXIF) |
| QR code | **QRCoder** + **ZXing.Net** (scan caméra Android) |
| Cartographie | **Mapsui** (composant carte) |
| Observabilité | **OpenTelemetry** (OTLP HTTP/protobuf) |
| Tests | **xUnit** (2 038 tests) |

### 6.2 Les projets (solution `Omika.slnx`)

| Projet | Rôle |
|---|---|
| `Omika.Core` | Cœur métier : domaine, DTO, services, sync mobile, observabilité |
| `Omika.Data` | Accès HFSQL : connexions (ODBC/OLE DB), repositories adaptatifs, modèles physiques, migration |
| `Omika.Api` | Web service REST (97 endpoints) |
| `Omika.Worker` | Service de synchronisation (arrière-plan) |
| `Omika.App` | UI Avalonia partagée (29 écrans) |
| `Omika.App.Desktop` | Hôte Windows/macOS/Linux |
| `Omika.App.Android` | Hôte Android |
| `Omika.App.iOS` | Hôte iOS |
| `Omika.App.Local` | Couche offline-first (SQLite + SyncEngine) |
| `Omika.Observability.External` | OpenTelemetry |
| `Omika.Diagnostics.*` | Centre de diagnostic (Core/Data/Api/Web/Worker) |
| `Omika.Tests`, `Omika.Diagnostics.Tests` | Tests xUnit |
| `tools/*` | Sondes de diagnostic HFSQL, générateur de modèles |

### 6.3 Topologie des flux

```
Mobile (Android/iOS) ──HTTP JSON + Bearer──► Omika.Api ──► écrit TOSRV (HFSQL Service)
                                                              │
Desktop (Windows) ───── accès HFSQL direct ─────────────────► │
                                                              ▼
                                                   Omika.Worker (boucle)
                                                   TOSRV → MobReception → handler
                                                   → MobLog (résultat terminal)
                                                              │
                                Omika.Core (métier) + Omika.Data (HFSQL)
```

- Le **mobile** ne touche **jamais** HFSQL directement (toujours via l'API).
- Le **desktop** accède à HFSQL en direct (comportement historique conservé).
- L'API **reçoit** les opérations ; le Worker les **applique** de façon asynchrone.

### 6.4 Bases de données

| Base HFSQL | Rôle |
|---|---|
| Business / WebService | Données métier (Batik ou Omika) |
| Service | Table `TOSRV` (file d'entrée des opérations) |
| WebService | Tables `MobReception` + `MobLog` (file de travail + journal) |
| Licence | Tables `ClientBase`, `Licence`, `LicenceHisto` |
| PostgreSQL `omika_diagnostics` | Données du centre de diagnostic |
| SQLite `omika.db` | Copie locale offline sur mobile (29-30 tables) |

### 6.5 Compatibilité bi-schéma Batik ↔ Omika

Un mécanisme central (`ApplicationRuntimeContext`, `SchemaDetection`,
repositories **adaptatifs** `Adaptive*`) permet de lire **indifféremment une
base Batik (ancienne) ou Omika (nouvelle)**. Les modèles physiques sont
auto-générés depuis un dictionnaire machine-readable
(`docs/schema-compatibilite-batik-omika.json`) : 48 tables Batik + 58 tables
Omika, 720 couples table-rubrique, avec gestion des champs « zombie » et des
GUID. **Le mobile ne sait jamais quelle génération de base il utilise.**

---

## 7. Différenciateurs (arguments de vente)

1. **Migration sans douleur du legacy** : on conserve la base HFSQL et les
   données ; bascule progressive, double schéma Batik/Omika géré en interne.
2. **Offline-first robuste** : SQLite local + Outbox + synchronisation
   idempotente avec retry — les techniciens travaillent partout (sous-sol,
   zone blanche, chantier).
3. **Fiabilité de la sync** : GUID de transaction, réconciliation d'identités,
   pas de doublon, rejet terminal propre (pas d'écrasement silencieux).
4. **Multi-plateforme, un seul code** : Android, iOS, desktop avec Avalonia.
5. **Monétisation native** : licence par appareil, activation sécurisée, jetons
   signés — le produit est « vendable » tel quel.
6. **Rapports & e-mails intégrés** : modèles personnalisables, DOCX→PDF, SMTP
   avec images inline — sans outil externe.
7. **Sécurité sérieuse** : token HMAC-SHA256, PBKDF2-SHA256, secure storage,
   aucune exposition des PK/chemins serveur au mobile.
8. **Exploitabilité** : centre de diagnostic + télémétrie OpenTelemetry pour un
   support professionnel (orientation SaaS).
9. **Qualité** : ≈ 3 900 tests automatisés, 0 `TODO`/`NotImplementedException`,
   documentation abondante.
10. **Confidentialité par conception** : télémétrie pseudonymisée
    (HMAC-SHA256, tenant-scoped), liste de données interdites, whitelist —
    compatible RGPD et multi-tenant.

---

## 8. État d'avancement réel (honnêteté marketing)

Il est essentiel de **ne pas survendre**. État constaté dans le code :

- **Serveur / API** : très avancé — 97 endpoints couvrant la quasi-totalité du
  périmètre métier (clients, contacts, sites, dossiers, interventions, RDV,
  collaborateurs, équipes, suivi des temps, comptes rendus, documents, rapports,
  e-mails, référence, licence, sync, bootstrap, back-office).
- **Mobile (consultation)** : complet — agenda, interventions, dossiers,
  clients, sites, contacts, collaborateurs, documents/photos. Le périmètre de
  travail est en **offline** (snapshot agenda ±14 j) ; les autres référentiels
  sont chargés « à la demande » puis conservés en cache local.
- **Mobile (écriture)** : opérationnel pour **Intervention** (create/edit/
  archive), **documents/photos**, **suivi des temps** (création). Les écritures
  des autres entités (RDV, dossier, client, site, collaborateur, notes,
  compte rendu) sont **backend-ready** mais pas encore branchées à l'UI mobile.
- **Handlers de sync** : `Intervention` (create/update/archive),
  `SuiviTemps` (create), `RendezVous` (validation de temps / annulation),
  `NoteInterne`/`NoteAdministrative` (create) sont branchés ; les autres types
  d'entité (Client, Contact, Site, Dossier, Document…) passent par un fallback
  propre (`NO_HANDLER` → rejet explicite).
- **Licence serveur** : logique complète + tests verts, mais la **base Licence
  réelle** (topologie de déploiement) est un point de vigilance documenté
  (« STOP » dans `docs/LOT_SERVEUR_LICENCE.md`).

→ Le site doit présenter Omika comme une **plateforme moderne en cours de
finalisation**, avec un cœur serveur solide et une expérience mobile offline
déjà démontrable (démo de l'agenda, des interventions, des photos, de la
saisie de temps et de la synchronisation).

---

## 9. Chiffres clés (crédibilité)

| Indicateur | Valeur |
|---|---|
| Projets | 13 (+ suite Diagnostics) |
| Écrans applicatifs | ≈ 37 vues Avalonia (29 écrans distincts) |
| ViewModels / vues XAML | 42 / 51 |
| Endpoints HTTP | ≈ 97 (plus de 90 routes desktop + mobile) |
| Tables HFSQL manipulées | 65 (118 classes de modèles) |
| Couples table-rubrique mappés | 720 |
| Repositories (Batik + Omika + adaptatifs) | 19 + 20 + 22 |
| Instructions SQL brutes | ~500 |
| Tests automatisés | **≈ 3 900** (Omika.Tests ≈ 3 370 + Diagnostics.Tests ≈ 536) |
| Lignes de code (production) | ~85 200 C# + ~7 700 XAML |
| Lignes de test | ~43 800 |
| Corpus legacy analysé | ~600 000 lignes |
| Effort humain équivalent estimé | ~800 jours-homme (3-4 ans / 1 dev) |
| Version | 1.0.0 |

---

## 10. Assets disponibles pour le site web

Le dépôt contient déjà des éléments directement réutilisables :

- **Logos** (`src/Logos/`) :
  - `Logo_principal.svg`
  - `Logo_mobile.svg`
  - `Logo_secondaire_blanc.svg`
  - `Logo_secondaire_violet.svg`
- **Maquette UX complète** : `docs/maquetteOmika.html` — design system complet
  (couleurs, composants, thèmes clair/sombre, responsive mobile/desktop), 593
  lignes. Elle montre les écrans réels du produit (agenda, équipe,
  interventions, dossiers, clients, lieux, rapports, e-mails, paramètres).
- **Couleur de marque** : indigo `#4f46e5` (dégradé `#4f46e5 → #3730a3`), avec
  thème sombre `#0c1320` (extrait de la maquette).
- **Marque** : monogramme « OM », accroche « Interventions terrain ».

---

## 11. Angles et messages marketing suggérés

1. **« Votre ancien logiciel, enfin moderne »** — le remplacement de WinDev sans
   perdre les données (pérenne pour les acheteurs déjà équipés en Batik).
2. **« Vos techniciens travaillent partout »** — offline-first, photos,
   documents, temps saisis sur le terrain, synchronisation automatique.
3. **« Du RDV au rapport, sans ressaisie »** — cycle complet intégré
   (planning → intervention → temps → compte rendu → rapport → e-mail).
4. **« Un produit vendable et sécurisé »** — licence par appareil, activation,
   rôles et droits, jetons signés.
5. **« Exploitable et supportable »** — centre de diagnostic, télémétrie,
   monitoring (orientation SaaS).
6. **« Du sérieux industriel »** — .NET 10, tests automatisés, compatibilité
   double schéma, documentation.

### Proposition de pages pour le site

- **Accueil** : pitch + hero (maquette/logo) + bénéfices clés.
- **Fonctionnalités** : agenda/planning, interventions, documents/photos,
  suivi des temps, rapports & e-mails, synchronisation.
- **Mobile & offline** : démonstration du mode hors-ligne.
- **Sécurité & licence** : activation, rôles, jetons.
- **Exploitation / SaaS** : centre de diagnostic.
- **À propos / migration** : l'histoire Batik → Omika, compatibilité des
  données.
- **Tarifs / Contact** (à définir avec l'éditeur).

---

## 12. Limites et points de vigilance (à connaître avant de rédiger)

- Le produit est en **version 1.0.0**, encore en finalisation sur la partie
  écriture mobile de certaines entités (RDV, dossier, client, site, notes,
  compte rendu : backend prêt, UI mobile à brancher).
- La **migration Batik → Omika** (`MigrationService`) est un **squelette** :
  la conversion clés numériques → clés textuelles et le suivi
  `ElementModifie`/`ElementSupprime` sont prévus mais pas encore opérationnels.
- La **base de licence réelle** doit être validée sur la topologie de
  production (documenté, pas bloquant pour le code).
- La **suppression physique** (DELETE) est volontairement refusée au profit de
  l'**archivage** (traçabilité) — c'est aussi un argument (aucune perte).
- **Accès HFSQL via OLE DB** : Windows-only, dépendant des drivers PC SOFT
  installés sur l'hôte serveur.
- La conversion **DOCX → PDF** repose sur **LibreOffice headless**
  (`soffice --headless`) : prérequis de déploiement serveur à documenter.
- **Auth à deux vitesses** : les routes desktop/back-office s'appuient sur le
  réseau/hébergement (reverse proxy) plutôt que sur un rejet 401 par endpoint ;
  seules les routes `/api/*` vérifient le jeton.
- Durcissements à traiter avant une production large : base SQLite locale non
  chiffrée, jeton Bearer en clair (desktop), pas de rate-limiting sur les
  endpoints publics de licence (voir `docs/ESTIMATION_EFFORT_DEVELOPPEMENT.md`).

---

*Document généré à partir de l'analyse du code source (`src/`), de la solution
et de la documentation du dépôt `D:\Avalonia\Omika`.*