25 KiB
25 KiB
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/), solutionOmika.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
- 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.
- Le chef d'équipe / planificateur (desktop) : planifie les rendez-vous, suit l'agenda de l'équipe, affecte les collaborateurs.
- Le back-office / administratif : gère clients, dossiers, documents, modèles de rapports et d'e-mails, paramètres métier.
- 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)
- Activation de licence → session sécurisée → shell.
- Consultation de l'agenda (jour) et du détail d'un RDV.
- Consultation/recherche/filtre des interventions (actif/archivé).
- Création / modification / archivage d'une intervention (offline).
- Ajout de photos / documents sur intervention (offline).
- Saisie du temps (offline, rattachée à une intervention ou un RDV).
- Génération de rapports (modèles Word/RTF → PDF) et e-mails (modèles
- SMTP) — backend.
- Synchronisation manuelle mobile ↔ serveur.
- 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) |
| 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)
- 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.
- Offline-first robuste : SQLite local + Outbox + synchronisation idempotente avec retry — les techniciens travaillent partout (sous-sol, zone blanche, chantier).
- Fiabilité de la sync : GUID de transaction, réconciliation d'identités, pas de doublon, rejet terminal propre (pas d'écrasement silencieux).
- Multi-plateforme, un seul code : Android, iOS, desktop avec Avalonia.
- Monétisation native : licence par appareil, activation sécurisée, jetons signés — le produit est « vendable » tel quel.
- Rapports & e-mails intégrés : modèles personnalisables, DOCX→PDF, SMTP avec images inline — sans outil externe.
- Sécurité sérieuse : token HMAC-SHA256, PBKDF2-SHA256, secure storage, aucune exposition des PK/chemins serveur au mobile.
- Exploitabilité : centre de diagnostic + télémétrie OpenTelemetry pour un support professionnel (orientation SaaS).
- Qualité : ≈ 3 900 tests automatisés, 0
TODO/NotImplementedException, documentation abondante. - 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.svgLogo_mobile.svgLogo_secondaire_blanc.svgLogo_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
- « 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).
- « Vos techniciens travaillent partout » — offline-first, photos, documents, temps saisis sur le terrain, synchronisation automatique.
- « Du RDV au rapport, sans ressaisie » — cycle complet intégré (planning → intervention → temps → compte rendu → rapport → e-mail).
- « Un produit vendable et sécurisé » — licence par appareil, activation, rôles et droits, jetons signés.
- « Exploitable et supportable » — centre de diagnostic, télémétrie, monitoring (orientation SaaS).
- « 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 suiviElementModifie/ElementSupprimesont 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.