Premiere commit - Omika

docs/analyse-sources.md

@@ -0,0 +1,941 @@
+# Analyse des sources Windev Batik / OMIKA
+
+**Objet :** préparer la compréhension fonctionnelle et technique nécessaire à une future migration vers une application Avalonia et une API .NET, sans créer à ce stade ni projet, ni modèle, ni code applicatif.
+
+**Date d'analyse :** 6 août 2026  
+**Sources analysées :** `BATIK.md` et `OMIKA.md`
+
+---
+
+## 1. Périmètre et limites de l'analyse
+
+Le répertoire de travail fourni contient uniquement deux exports Markdown de documentation technique générée par WINDEV :
+
+- `BATIK.md`, qui documente en réalité le projet WINDEV **`Isis_BO`**, situé historiquement sous `D:\Projets Windev\Batik\WD30\Dev` ;
+- `OMIKA.md`, qui documente le projet WINDEV **`Batik`**, situé sous `D:\Projets Windev\Batik\Nouvelle Version\Batik`, mais dont l'initialisation définit le nom d'application **`Omika`**.
+
+## 2. Convention de nommage utilisée dans ce document
+
+Les noms des fichiers et des projets sont croisés. Pour éviter toute ambiguïté :
+
+| Désignation dans cette analyse | Source | Projet documenté | Interprétation |
+|---|---|---|---|
+| **Ancienne version / legacy Batik** | `BATIK.md` | `Isis_BO` | Ancien socle WINDEV, multi-configuration et historiquement utilisé pour Batik/Isis/SLAMM/Bouvard/Artisans Partenaires. |
+| **Nouvelle version WINDEV / OMIKA** | `OMIKA.md` | `Batik`, avec `cNomApp = "Omika"` | Refonte WINDEV plus récente, distincte de la future cible Avalonia/.NET. |
+
+
+## 3. Synthèse générale
+
+Les deux applications sont des applications WINDEV Windows de gestion d'interventions couvrant notamment :
+
+- l'authentification et les droits d'accès ;
+- les sociétés, collaborateurs et équipes ;
+- les clients, contacts, adresses et sites ;
+- les dossiers et interventions ;
+- le planning, les rendez-vous et leur affectation aux collaborateurs ;
+- le suivi des temps ;
+- les documents, comptes rendus, rapports et modèles de courriels ;
+- les paramètres métier et utilisateur ;
+- des intégrations avec Batigest, des bases externes, le mobile, un service de licence et SysLog.
+
+## 4. Structure générale observée
+
+### 4.1 Ancienne version / `BATIK.md` / projet `Isis_BO`
+
+#### Organisation logique
+
+L'ancien projet est organisé autour de plusieurs familles d'éléments :
+
+- `FEN_*` : fenêtres principales, fenêtres de choix, popups, login, agenda, saisie des temps, utilitaires ;
+- `FI_*` : fenêtres internes de fiches, listes, planning, tableaux de bord et paramétrage ;
+- `ETAT_*` : états d'impression et variantes clients, notamment SLAMM, GAP et Bouvard ;
+- `M*` : classes métier ou classes de mapping d'une entité ;
+- `MTableauDe*` : classes de collection ou de présentation tabulaire ;
+- `PFiche*` : classes de présentation/édition d'une fiche ;
+- `PTable*` : classes de présentation de listes ou tables ;
+- `COL_*` et `LIB_*` : collections de procédures globales ;
+- composants internes et externes, dont `COMP_SysLog` et `WDFAA`.
+
+La multiplication des classes `M*`, `MTableauDe*`, `PFiche*` et `PTable*` explique l'effectif élevé de 181 classes. Cette architecture semble s'appuyer sur une couche de présentation généralisée autour de chaque table, mais elle ne garantit pas une séparation nette entre domaine, accès aux données et interface.
+
+
+## 6. Description de la base de données
+
+### 6.1 Emplacement de la description
+
+La description complète de la base se trouve dans les analyses WINDEV documentées :
+
+- ancienne version : `Isis_BO.ana\Isis_BO.wda` ;
+- nouvelle version : `Batik.ana\Batik.wda`.
+
+Les parties « Schéma des données », « Dictionnaire des rubriques », « Groupes de fichiers », « Liaisons », « Connexions » et « Tables et rubriques » des deux documents constituent la source principale pour préparer un futur modèle de données .NET.
+
+### 6.2 Statistiques comparées
+
+| Mesure | Ancienne version | Nouvelle version OMIKA | Écart |
+|---|---:|---:|---:|
+| Génération de l'analyse | 314 | 367 | +53 |
+| Tables | 48 | 58 | +10 |
+| Rubriques | 720 | 872 | +152 |
+| Liaisons déclarées | 38 | 38 | 0 |
+| Connexions déclarées | 1 | 1 | 0 |
+| Groupes de fichiers | 2 | 2 | 0 |
+
+Les deux analyses utilisent une connexion de type **HFSQL Classic** nommée `ConnexionLocale`, associée à `<MAIN_HF_DIR>`. Les tables sont réparties au moins entre les groupes de protection `ProtectionStd` et `ProtectionPlus`.
+
+### 6.3 Tables de l'ancienne version — 48 tables
+
+`AccesEtDroit`, `Action`, `Adresse`, `BddExterne`, `CheckList`, `CheckList_Collab`, `Client`, `Client_Adresse`, `Client_BddExterne`, `Client_Lieu`, `Collaborateur`, `CompteRendu`, `Compteur`, `Document`, `DocumentNote`, `Dossier`, `Equipe`, `Equipe_Collaborateur`, `EtatIntervention`, `Intervention`, `Intervention_BddExterne`, `Intervention_ChampLibre`, `Intervention_Collaborateur`, `Intervention_Personne`, `Lieu`, `Lieu_Personne`, `MailCat`, `MailModele`, `MessageExterne`, `MessageInterne`, `Mobile`, `MobLog`, `MobReception`, `ModeleRapportMob`, `MotClef`, `ParametreApplication`, `ParametreMetier`, `ParametreMetierEntete`, `ParametreSysteme`, `ParametreUtilisateur`, `Personne`, `Planning_RDV`, `Planning_RDV_Personne`, `Societe`, `Societe_Collaborateur`, `SuiviDesTemps`, `Telephone`, `Utilisateur`.
+
+### 6.4 Tables de la nouvelle version — 58 tables
+
+`AccesEtDroit`, `Action`, `Adresse`, `BddExterne`, `CategorieAcces`, `CheckList`, `CheckList_Collab`, `Client`, `Client_Adresse`, `Client_BddExterne`, `Client_Lieu`, `Collaborateur`, `CompteRendu`, `Compteur`, `Doc_Aide`, `Document`, `DocumentNote`, `Dossier`, `ElementModifie`, `ElementSupprime`, `Equipe`, `Equipe_Collaborateur`, `EtatIntervention`, `Etats`, `Intervention`, `Intervention_BddExterne`, `Intervention_ChampLibre`, `Intervention_Personne`, `Lieu`, `Lieu_Personne`, `MailCat`, `MailModele`, `MessageExterne`, `MessageInterne`, `Mobile`, `MobLog`, `MobReception`, `ModeleRapport`, `ModeleRapportMob`, `MotClef`, `ParametreApplication`, `ParametreMetier`, `ParametreMetierEntete`, `ParametreSysteme`, `ParametreUtilisateur`, `Personne`, `Planning_RDV`, `Planning_RDV_Personne`, `RDV_Collaborateur`, `RDV_Contact`, `RDV_Planning`, `Role`, `RubriquesDocument`, `Societe`, `Societe_Collaborateur`, `SuiviDesTemps`, `Telephone`, `Utilisateur`.
+
+### 6.5 Delta de tables
+
+#### Tables ajoutées dans la nouvelle version
+
+- `CategorieAcces`
+- `Doc_Aide`
+- `ElementModifie`
+- `ElementSupprime`
+- `Etats`
+- `ModeleRapport`
+- `RDV_Collaborateur`
+- `RDV_Contact`
+- `RDV_Planning`
+- `Role`
+- `RubriquesDocument`
+
+#### Table supprimée du nouveau schéma
+
+- `Intervention_Collaborateur`
+
+Le solde est bien de dix tables supplémentaires.
+
+### 6.6 Rubriques des tables ajoutées
+
+La liste ci-dessous est issue des sections « Tables et rubriques » de `OMIKA.md`.
+
+#### `CategorieAcces`
+
+- `CAC_PKID`
+- `CAC_Cle`
+- `CAC_Libelle`
+- `CAC_Ordre`
+- `CAC_Mobile`
+- `CAC_AncienCode`
+- `CreationDate`
+- `CreationUser`
+- `ModifDate`
+- `ModifUser`
+- `CAC_Description`
+
+#### `Doc_Aide`
+
+- `DA_PKID`
+- `DA_Fenetre`
+- `DA_Champs`
+- `DA_Titre`
+- `DA_Contenu`
+- `DA_Tags`
+- `DA_TexteOriginal`
+- `ModifUser`
+- `ModifDate`
+
+#### `ElementModifie`
+
+- `EM_PKID`
+- `EM_Fichier`
+- `EM_Date`
+- `EM_IdUser`
+- `EM_IdEnrg`
+
+#### `ElementSupprime`
+
+- `ES_PKID`
+- `ES_NumEnrg`
+- `ES_IdEnrg`
+- `ES_Fichier`
+- `ES_IdUser`
+- `ES_DateHeure`
+- `ES_NumEnr_Id`
+
+#### `Etats`
+
+- `ETA_PKID`
+- `ETA_Groupe`
+- `ETA_Libelle`
+- `ETA_Ordre`
+- `ETA_Valeur`
+
+#### `ModeleRapport`
+
+- `MRP_PKID`
+- `MRP_Nom`
+- `MRP_Modele`
+- `MRP_EnvoiMob`
+- `MRP_Extra`
+- `CreationDate`
+- `CreationUser`
+- `ModifDate`
+- `ModifUser`
+
+#### `RDV_Collaborateur`
+
+- `RVC_PKID`
+- `RVC_GUID_RDV`
+- `RVC_GUID_Colb`
+- `RVC_DateDeb`
+- `RVC_DateFin`
+- `RVC_CleStatut`
+- `RVC_Responsable`
+- `RVC_TempsValide`
+- `RVC_DateExport`
+- `GUID`
+- `Archive`
+- `RVC_CR`
+- `RVC_Superposable`
+
+#### `RDV_Contact`
+
+- `RVCT_PKID`
+- `GUID`
+- `RVCT_GUID_Pers`
+- `RVCT_GUID_RDV`
+
+#### `RDV_Planning`
+
+- `RV_PKID`
+- `RV_IdSociete`
+- `RV_IdDossier`
+- `RV_IdInter`
+- `RV_CleType`
+- `RV_CleStatut`
+- `RV_Objet`
+- `RV_Description`
+- `RV_IdLieu`
+- `RV_SAV`
+- `RV_CleOrigineAnnu`
+- `RV_CleMotifAnnu`
+- `RV_RappelSMS`
+- `Archive`
+- `CreationDate`
+- `CreationUser`
+- `ModifDate`
+- `ModifUser`
+- `GUID`
+- `RV_Groupe`
+- `RV_PlusieursJours`
+- `RV_Date`
+
+#### `Role`
+
+- `R_PKID`
+- `R_Libelle`
+- `R_AncienCode`
+- `CreationDate`
+- `CreationUser`
+- `ModifDate`
+- `ModifUser`
+
+#### `RubriquesDocument`
+
+- `RD_PKID`
+- `RD_Nom`
+- `RD_Description`
+- `RD_Rubrique`
+- `RD_TypeMembre`
+- `RD_MasqueSaisie`
+- `RD_EnvoiMob`
+- `RD_BD`
+- `RD_Modifiable`
+- `RD_Groupe`
+- `RD_IdRubParent`
+- `RD_MembreMob`
+- `RD_Ordre`
+
+### 6.7 Évolutions de rubriques observées sur les tables communes
+
+Les principales évolutions visibles sont les suivantes :
+
+| Table | Évolutions notables observées dans OMIKA |
+|---|---|
+| `Action` | Ajout de `AC_CleTypeAction`. |
+| `Adresse` | Ajout de `AD_Adresse` et `GUID`. |
+| `Client` | Ajout de clés textuelles pour type, statut, apporteur, origine et mode de règlement, ainsi que `GUID`. |
+| `Client_Adresse` | Ajout de `CA_CleType`, `CA_Facturation` et `CA_Livraison`. |
+| `Collaborateur` | Ajout de `CO_CleCivilite`, `CO_CleStatut` et `GUID`. |
+| `CompteRendu` | Ajout d'une clé de type de signataire et d'un GUID de rendez-vous. |
+| `Document` | Ajout de clés textuelles de catégorie et d'état documentaire. |
+| `Dossier` | Ajout de clés textuelles de type et statut, plus `GUID`. |
+| `EtatIntervention` | Ajout de `EI_CleEtat`. |
+| `Intervention` | Ajout de clés textuelles de type et état, plus `GUID`. |
+| `Intervention_Personne` | Ajout d'une clé de rôle. |
+| `Lieu` | Ajout d'une clé de type et de `GUID`. |
+| `Lieu_Personne` | Ajout de clés de rôle et de type. |
+| `MailModele` | Ajout de données supplémentaires et d'un indicateur d'envoi mobile. |
+| `MessageExterne` | Ajout d'une rubrique de pièces jointes. |
+| `ParametreMetier` | Ajout de `PA_CLE` et d'une catégorie. |
+| `ParametreMetierEntete` | Ajout d'une catégorie et d'un type. |
+| `Personne` | Ajout de clés de civilité et de rôle, plus `GUID`. |
+| `Planning_RDV` | Ajout de clés textuelles de type, statut, origine et motif d'annulation. |
+| `Societe` | Ajout de `GUID` et d'un identifiant SIREN. |
+| `SuiviDesTemps` | Ajout de clés de type de temps et de rendez-vous, de notes collaborateur/administration et d'un GUID de rendez-vous/collaborateur. |
+| `Utilisateur` | Ajout d'une référence vers le nouveau rôle. |
+
+Cette liste cible les changements structurants utiles à la migration ; elle ne remplace pas un diff machine exhaustif des 872 rubriques.
+
+### 6.8 Tendances de modélisation
+
+#### Passage d'identifiants numériques à des clés stables
+
+La nouvelle version ajoute de nombreuses rubriques du type `*_Cle*`, souvent des chaînes de longueur 16. Les anciens identifiants numériques correspondants restent parfois dans l'analyse mais sont marqués **zombie**.
+
+Exemples documentés :
+
+- `CO_IDCivilite`, `CO_IDStatut` ;
+- `PE_IDCivilite`, `PE_IDRole` ;
+- `IN_IDTypeIntervention`, `IN_IDEtatIntervention` ;
+- `CL_IDType`, `CL_IDStatut`, `CL_IDApporteur`, `CL_IDApportOrigine`, `CL_IDModeReglement` ;
+- `LI_IDType` ;
+- anciens identifiants de type et statut de `Planning_RDV` ;
+- anciennes rubriques de type dans `SuiviDesTemps` ;
+- anciennes catégories/états du document.
+
+Cela suggère une stratégie de découplage des paramètres métier vis-à-vis des identifiants physiques. Pour la future API, il faudra déterminer quelle valeur constitue désormais la vérité métier : ancien identifiant, nouvelle clé, ou combinaison des deux durant une transition.
+
+#### Introduction des GUID
+
+Des GUID sont ajoutés sur plusieurs entités principales et sont centraux dans les nouvelles tables de rendez-vous. Cela paraît destiné à stabiliser l'identité entre bases, synchronisations ou clients, mais cette finalité doit être confirmée.
+
+#### Refonte du planning
+
+La coexistence de `Planning_RDV`, `Planning_RDV_Personne` et des nouvelles tables `RDV_Planning`, `RDV_Collaborateur`, `RDV_Contact`, combinée aux procédures de migration de `FEN_MaJParemApp`, indique une refonte progressive du modèle de rendez-vous.
+
+Le statut exact de cette coexistence est une question prioritaire :
+
+- ancien modèle encore actif ;
+- nouveau modèle actif avec compatibilité ;
+- migration partielle selon les clients ;
+- ou double écriture temporaire.
+
+---
+
+## 7. Liaisons et intégrité
+
+Les deux analyses déclarent 38 liaisons, mais leur composition évolue.
+
+### Liaisons ou associations notables de l'ancienne version
+
+- `Intervention` vers `Action` ;
+- `Intervention` et `Collaborateur` via `Intervention_Collaborateur` ;
+- `Planning_RDV` vers les personnes via `Planning_RDV_Personne` ;
+- relations client/adresse, client/lieu, lieu/personne, société/collaborateur, équipe/collaborateur ;
+- relations documentaires et intervention/personne ;
+- association entre modèles de mail et catégories.
+
+### Évolutions notables dans OMIKA
+
+- nouvelles associations entre `RDV_Planning` et `RDV_Collaborateur` ;
+- nouvelles associations entre `RDV_Planning`, `RDV_Contact` et `Personne` ;
+- disparition de la table `Intervention_Collaborateur` ;
+- nouvelles tables utilisant des GUID sans que toutes les relations soient nécessairement matérialisées par des contraintes HFSQL visibles.
+
+Le nombre total de liaisons restant identique malgré onze ajouts et une suppression de table suggère que certaines relations du nouveau modèle sont gérées par le code ou par des clés logiques plutôt que par des contraintes déclarées. Cette conclusion est une hypothèse à vérifier dans l'analyse physique et sur une base réelle.
+
+---
+
+## 8. Traitements métier identifiés
+
+### 8.1 Localisation générale
+
+Les traitements métier sont répartis dans quatre zones :
+
+1. les collections de procédures globales ;
+2. les classes `M*` et classes transverses ;
+3. les procédures locales des fenêtres et fenêtres internes ;
+4. les requêtes SQL écrites directement dans ces procédures.
+
+La future extraction vers une API ne pourra donc pas se limiter à convertir les classes. Il faudra également analyser les traitements d'événements, les boutons, les validations, les filtres, les requêtes et les effets de bord dans les fenêtres.
+
+### 8.2 Ancienne version — collections principales
+
+| Collection | Responsabilités observées |
+|---|---|
+| `COL_COMMUN` | Utilitaires métier, chargement de paramètres, gestion de sociétés/équipes/collaborateurs, compteurs, jours fériés, planning et rendez-vous. |
+| `COL_CONNEXION` | Connexions HFSQL, utilisateurs et groupes, droits de base, préparation des fichiers, contrôle utilisateur et structure. |
+| `COL_HFSQL` | Paramètres de connexion, lecture INI, ouverture de base, critères, requêtes et utilitaires HFSQL. |
+| `COL_DOCUMENT` | Chemins documentaires, fichiers, catégories et autorisations documentaires. |
+| `COL_IHM` | Filtres, tris, blocages, mappage de champs et services d'interface. |
+| `COL_THREAD` | Recherches ou chargements exécutés dans des threads. |
+| `COL_MOBILE` | Services ou synchronisations mobiles. |
+| `COL_VERSION` | Mise à niveau de paramètres et de structures selon la version. |
+| `LIB_ModelesEmails` | Construction de courriels, remplacement de balises et modèles. |
+| `LIB_Synchro` | Synchronisation avec Batigest ou sources externes. |
+| `COL_EXPORT` | Exports, notamment JSON. |
+| `COL_PrefAGD` | Préférences d'agenda. |
+| `COL_Visite` | Visites guidées. |
+| `COL_TEMPORAIRE` | Procédures temporaires ou expérimentales à auditer avant migration. |
+
+### 8.3 Nouvelle version — collections principales
+
+| Collection | Responsabilités observées |
+|---|---|
+| `Lib_InitProjet` | Chargement des caches globaux, rôles, paramètres, états, sociétés, collaborateurs, modèles de mail/rapport et aide. |
+| `Lib_Planning` | Création, modification et suppression de rendez-vous ; rendez-vous multi-jours ; groupes de collaborateurs ; contacts ; détection de conflits ; ressources et rendu du planning. |
+| `Lib_Parametres` | Lecture/écriture des paramètres application et système, chiffrement/déchiffrement, groupes de paramètres. |
+| `Lib_DroitsAcces` | Calcul et contrôle des droits. |
+| `Lib_Version` | Création/mise à jour des paramètres métier, catégories d'accès, états et version applicative. |
+| `LIB_HFSQL` | Fonctions HFSQL communes. |
+| `LIB_Documents` | Recherche et manipulation des fichiers et arborescences documentaires. |
+| `LIB_RubMailRapport` | Définition et substitution des rubriques de rapports/courriels. |
+| `LIB_ElementsModifies` | Suivi des modifications d'entités. |
+| `LIB_Surveille` | Surveillance HFSQL, file d'événements et rafraîchissement d'interface. |
+| `LIB_Batigest` | Intégration avec Batigest. |
+| `Lib_Email` | Envoi et préparation des courriels. |
+| `Lib_AppMobile` | Fonctions mobiles. |
+| `Lib_Commun` | Utilitaires et règles transverses. |
+| `Lib_UI`, `Lib_Champs`, `LIB_TypeChamp` | Abstraction partielle des champs et comportements UI. |
+| `LIB_Aide`, `LIB_VisitesGuidées` | Aide contextuelle et visites guidées. |
+
+### 8.4 Fenêtres et classes à forte valeur métier
+
+#### Authentification et sécurité
+
+- `FEN_Login`
+- ancienne version : `COL_CONNEXION`, `COL_HFSQL`, `MAccesEtDroit`, `MUtilisateur`, `PFicheUtilisateur`, `PTableUtilisateur`
+- nouvelle version : `ConnexionHFSQL`, `Droit`, `MAcces`, `MRole`, `MUtilisateur`, `Lib_DroitsAcces`, `Lib_InitProjet`
+
+#### Référentiels clients et sites
+
+- clients : `FEN_Fiche_Client`, `FI_Liste_Client`, `MClient`
+- contacts : `FEN_Fiche_Contact` ou `FI_Fiche_Personne`, `MPersonne_Ct` / `MPersonne`
+- sites/lieux : `FEN_Fiche_Site` ou `FI_Fiche_Lieu`, `MLieu`
+- adresses : `FEN_Fiche_Adresse`, `MAdresse`, `MAdresseClient`
+- sociétés : `FEN_Fiche_Societe`, `MSociete`
+- collaborateurs et équipes : `FEN_Fiche_Colb`, `MCollaborateur`, `FEN_Fiche_Equipe`, `MEquipe`
+
+#### Dossiers et interventions
+
+- `FEN_Fiche_Dossier`, `FEN_Fiche_Dossier_Creation`, `FI_Liste_Dossier`, `MDossier`
+- `FI_Fiche_Intervention`, tableaux de bord d'intervention, `MIntervention`
+- actions, comptes rendus, messages, documents et donneurs d'ordre associés
+
+#### Planning et rendez-vous
+
+- `FEN_Agenda`, `FI_Agenda`, `FI_Planning`, `FEN_Fiche_RDV`, `FI_RDV`, `FEN_RDV_Attente`
+- `MRDV`, `MRDV_Planning`, `MRDV_Colb`, `MRDV_Contact`
+- `Lib_Planning`
+
+Le code documenté gère notamment :
+
+- la création d'un rendez-vous simple ;
+- les rendez-vous de nuit ;
+- les rendez-vous répartis sur plusieurs jours ;
+- les rendez-vous affectés à plusieurs collaborateurs ;
+- la modification d'une occurrence ou d'un groupe ;
+- la détection de chevauchements non superposables ;
+- l'association de contacts ;
+- la synchronisation des données affichées dans le planning ;
+- les préférences de titre, description, bulle, heures visibles et granularité.
+
+#### Suivi des temps
+
+- `FEN_Suivi_Temps`
+- `FEN_Fiche_Suivi_Temps`
+- `FEN_Fiche_Suivi_Temps_RDV`
+- `FEN_Liste_Colb_Suivi_Temps`
+- `FI_Temps`
+- `MSuiviTemps`
+
+Les traitements incluent la saisie, la validation, la pondération, le rapprochement avec les rendez-vous et des totaux par type de temps ou type de rendez-vous.
+
+#### Documents, rapports et courriels
+
+- `FEN_Creation_Doc_Rub`
+- `FEN_Fiche_Document`
+- `FEN_Rapport_Document_Inter`
+- `FEN_Fiche_Modele_Rapport`
+- `FEN_Fiche_Modele_Mail`
+- `LIB_Documents`
+- `LIB_RubMailRapport`
+- `Lib_Email`
+- `MDocument`, `MModeleRapport`, `MModeleMail`, `MRubriqueDoc`
+
+Les documents peuvent dépendre de chemins configurables et d'une structure de répertoires par client, intervention ou site. Les modèles de rapports et de courriels utilisent des rubriques dynamiques et des substitutions de mots-clés.
+
+#### Intégrations
+
+- Batigest : connecteurs/classes et bibliothèques dédiées ;
+- bases externes : table `BddExterne`, classes de configuration et paramètres JSON ;
+- mobile : bibliothèques, tables `Mobile`, `MobLog`, `MobReception`, services web ;
+- licence : service web configuré dans le projet ;
+- SysLog : composant de journalisation ;
+- courriel local : composant spécifique dans OMIKA.
+
+### 8.5 Traitements de migration déjà présents dans OMIKA
+
+`FEN_MaJParemApp` est un élément essentiel pour comprendre la transformation de l'ancien modèle vers le nouveau. La documentation y recense notamment des procédures de :
+
+- mise à jour des tables ;
+- création de rubriques documentaires ;
+- mise à jour des adresses ;
+- génération ou mise à jour des GUID ;
+- migration des rendez-vous vers les nouveaux fichiers ;
+- traitement des rendez-vous groupés, individuels et multi-jours ;
+- mise à jour des profils et rôles ;
+- migration des paramètres métier ;
+- rapprochement entre comptes rendus et rendez-vous.
+
+`Lib_Version` complète ces traitements par des créations/mises à jour de paramètres, états et catégories d'accès. Ces deux zones devront être étudiées avant toute conception d'un script de migration .NET, car elles contiennent probablement le meilleur historique exécutable des transformations déjà décidées.
+
+---
+
+## 9. Constantes globales et configuration
+
+### 9.1 Ancienne version
+
+Les constantes sont réparties entre :
+
+- l'initialisation du projet `Isis_BO` ;
+- `COL_Constantes` ;
+- certaines collections métier, par exemple les paramètres et le planning ;
+- les variantes conditionnelles de compilation.
+
+Catégories observées :
+
+- version du projet ;
+- noms de produit et de fichiers INI ;
+- chemins et formats de répertoires documentaires ;
+- groupes d'utilisateurs HFSQL ;
+- identifiants de paramètres métier ;
+- constantes d'affichage et de planning ;
+- balises de signature de courriel ;
+- constantes de licence et de services ;
+- valeurs liées au chiffrement et aux comptes techniques.
+
+Le projet contient plusieurs configurations de compilation : Batik, Isis, SLAMM, Bouvard, Artisans Partenaires, utilitaire et récupération d'heures. Elles modifient notamment le produit, le fichier INI, le service de licence, les logos et certains comportements.
+
+### 9.2 Nouvelle version OMIKA
+
+Les constantes sont réparties entre :
+
+- l'initialisation du projet `Batik` ;
+- `LIB_ConstantesGlobal` ;
+- `ConnexionHFSQL` ;
+- `Lib_Parametres` ;
+- `Lib_Planning` ;
+- `Lib_Version` ;
+- diverses classes et fenêtres.
+
+Éléments structurants confirmés :
+
+- nom d'application `Omika` ;
+- répertoire et fichier `Omika.ini` ;
+- constantes de résultats oui/non et code d'erreur de blocage HFSQL ;
+- clés des paramètres métier ;
+- groupes de paramètres par domaine ;
+- options d'affichage du planning ;
+- noms de fenêtres et paramètres d'ouverture ;
+- constantes de droits et catégories d'accès.
+
+### 9.3 Point de sécurité
+
+Les deux documentations exposent des secrets, mots de passe techniques, clés de chiffrement et adresses de services directement dans le code source ou les exemples de configuration. Les valeurs ne sont volontairement pas reproduites dans ce document.
+
+Avant toute migration, il faudra :
+
+1. inventorier ces secrets et leurs usages ;
+2. les révoquer ou les faire tourner si nécessaire ;
+3. les retirer du code et de l'historique distribué ;
+4. les stocker dans une solution de secrets adaptée aux environnements .NET ;
+5. séparer strictement les configurations développement, recette et production.
+
+---
+
+## 10. Connexions HFSQL
+
+### 10.1 Connexion déclarée dans les analyses
+
+Les deux analyses décrivent une connexion `ConnexionLocale` de type **HFSQL Classic**, utilisant `<MAIN_HF_DIR>`. En exécution, le code reconfigure toutefois les fichiers vers une connexion HFSQL Client/Serveur.
+
+### 10.2 Ancienne version
+
+La construction de la connexion est distribuée entre `COL_HFSQL`, `COL_CONNEXION`, l'initialisation du projet et `FEN_Login`.
+
+Le fichier INI contient une section générale et une ou plusieurs sections de base. Les clés documentées incluent :
+
+- nombre de bases ;
+- ordre ;
+- serveur ;
+- port ;
+- nom de base ;
+- libellé logique ;
+- indicateur de chiffrement.
+
+Le flux d'ouverture observé est approximativement :
+
+1. lecture du fichier INI ;
+2. construction d'une liste de connexions ;
+3. sélection éventuelle d'une base dans `FEN_Login` ;
+4. création/configuration d'un objet `Connexion` ;
+5. configuration du provider Client/Serveur et de l'accès lecture/écriture ;
+6. affectation du serveur, du port, de la base et d'un compte technique ;
+7. `HChangeConnexion` pour les fichiers ;
+8. application des mots de passe de groupes de fichiers ;
+9. ouverture et contrôle de la structure ;
+10. contrôle de l'utilisateur applicatif et de ses droits ;
+11. éventuelle reconnexion avec l'utilisateur final.
+
+`COL_CONNEXION` contient également de la gestion d'utilisateurs et groupes HFSQL, des droits de base, des mises à jour de structure et des traitements de connexion des services mobiles.
+
+### 10.3 Nouvelle version OMIKA
+
+La logique est davantage encapsulée dans la classe `ConnexionHFSQL`, bien que des utilitaires restent dans `LIB_HFSQL` et le login.
+
+Le flux observé est :
+
+1. recherche de `Omika.ini` dans le répertoire commun global ;
+2. lecture des mêmes familles de clés `[CONFIG]` et `[BASE_n]` ;
+3. création d'un squelette de fichier INI si aucune configuration n'existe ;
+4. configuration d'une connexion Client/Serveur en lecture/écriture ;
+5. utilisation d'un chiffrement AES128 pour la connexion ;
+6. affectation des mots de passe aux groupes `ProtectionPlus` et `ProtectionStd` ;
+7. `HChangeConnexion("*", connexion)` ;
+8. ouverture de la base ;
+9. test d'ouverture d'une table pour détecter une configuration de chiffrement incorrecte ;
+10. création ou mise à jour de l'utilisateur HFSQL ;
+11. rattachement au groupe utilisateur ;
+12. reconnexion avec le compte utilisateur.
+
+La classe contient également une politique de mot de passe dérivé du login et une limitation des connexions pour les utilisateurs standards. Ces mécanismes devront être remis à plat dans la future architecture : l'API devra devenir le point de contrôle d'accès, et l'application Avalonia ne devrait pas recevoir des identifiants HFSQL privilégiés.
+
+### 10.4 Bases externes
+
+Les deux versions possèdent une table `BddExterne` avec des paramètres JSON. La nouvelle version ajoute :
+
+- `MConnexionBaseExt` ;
+- `FEN_Parametres_Base_Ext` ;
+- `FI_Configuration_BaseExt` ;
+- une structure `ST_ParamConfigBDExt` ;
+- `LIB_Batigest`.
+
+Les contrats exacts, moteurs de base, requêtes, modes d'authentification et responsabilités de synchronisation restent à inventorier dans les sources physiques et les configurations réelles.
+
+---
+
+## 11. Différences principales entre l'ancienne version Batik et OMIKA
+
+| Axe | Ancienne version | Nouvelle version OMIKA | Conséquence pour la migration |
+|---|---|---|---|
+| Projet WINDEV | `Isis_BO` | `Batik`, application `Omika` | Confirmer le référentiel fonctionnel réellement en production. |
+| Schéma | `Isis_BO.wda` | `Batik.wda` | Un diff officiel du schéma est indispensable. |
+| Tables/rubriques | 48 / 720 | 58 / 872 | Le nouveau modèle est plus riche et inclut des migrations en cours. |
+| Classes | 181 | 46 | L'ancienne architecture est très généralisée ; la nouvelle est plus compacte. |
+| Modèles de champs | 1 | 35 | OMIKA mise davantage sur la composition UI. |
+| États | 26 | 11 | Des variantes d'impression ont été supprimées, regroupées ou non reprises. |
+| Planning | `Planning_RDV` et tables associées | Coexistence de l'ancien modèle et de `RDV_Planning`/`RDV_Collaborateur`/`RDV_Contact` | Identifier le modèle cible réellement utilisé et les règles de double écriture. |
+| Accès | Profils/modules et classes générées | `Role`, `CategorieAcces`, `Droit`, `Lib_DroitsAcces` | Reconstituer une matrice de permissions fonctionnelle. |
+| Identifiants métier | Nombreux identifiants numériques | Clés textuelles et GUID ajoutés | Définir les identifiants publics de l'API et les mappings de migration. |
+| Modèles de rapport | Principalement états et modèles mobiles | Table `ModeleRapport`, rubriques documentaires et éditeurs dédiés | Prévoir un sous-chantier rapports/documents. |
+| Suivi des changements | Limité ou dispersé | `ElementModifie`, `ElementSupprime`, surveillance HFSQL | Comprendre les besoins de synchronisation, audit ou rafraîchissement. |
+| Aide | Fichier d'aide/visites | Table `Doc_Aide`, aide contextuelle et visites | Décider si ces données sont à migrer vers l'API ou restent côté client. |
+| Connexion | Collections globales et variantes de compilation | Classe `ConnexionHFSQL` plus centralisée | Ne pas reproduire l'accès direct HFSQL dans Avalonia ; passer par l'API. |
+| Logique métier | Classes de présentation + fenêtres + collections | Classes plus légères, bibliothèques, mais toujours beaucoup de logique dans les fenêtres | Prévoir une phase de caractérisation avant extraction. |
+| Configuration | Multiples INI et configurations compilées | `Omika.ini`, bases externes et paramètres en base | Formaliser une matrice de configuration par client/environnement. |
+
+---
+
+## 12. Risques et points de vigilance
+
+### 12.1 Champs zombie encore utilisés
+
+La documentation OMIKA recense de nombreux avertissements indiquant que des champs zombie sont encore référencés dans des fenêtres, classes et requêtes. Cela représente un risque de divergence entre :
+
+- la valeur historique ;
+- la nouvelle clé métier ;
+- les écrans encore non migrés ;
+- les scripts de mise à jour ;
+- les exports et états.
+
+Un inventaire automatisé des références à chaque champ zombie est prioritaire.
+
+### 12.2 Coexistence de deux modèles de rendez-vous
+
+Le planning est l'une des zones les plus complexes. Les tables historiques et nouvelles semblent coexister, avec des scripts de migration et plusieurs types de regroupement. Une erreur de compréhension pourrait entraîner des pertes d'affectations, contacts, heures ou comptes rendus.
+
+### 12.3 Logique métier dans l'interface
+
+Des règles métier, requêtes SQL et effets de bord résident dans les procédures locales des fenêtres. Une migration écran par écran sans extraction préalable du comportement risquerait de réécrire des règles de manière incohérente.
+
+### 12.4 Secrets codés en dur
+
+Les identifiants techniques et clés présents dans les sources constituent un risque de sécurité et empêchent une gestion propre des environnements.
+
+### 12.5 Threads non sécurisés
+
+La documentation OMIKA contient plusieurs avertissements sur des appels `ThreadExécute` non sécurisés, notamment dans les traitements documentaires, les courriels, les rapports et la surveillance. Ces traitements devront être redéfinis avec des primitives asynchrones .NET, une gestion d'annulation et une séparation claire entre opérations serveur et client.
+
+### 12.6 Fonctions de chiffrement conservées pour compatibilité
+
+Des avertissements indiquent l'usage de fonctions `Crypte`/`Décrypte` conservées pour compatibilité. Les données déjà chiffrées devront être identifiées pour éviter de les rendre illisibles lors de la migration.
+
+### 12.7 Couverture de tests insuffisante
+
+L'ancienne version possède un objet de test isolé mais pas de suite utile. La nouvelle documentation ne montre pas de couverture automatisée comparable. Il faudra créer des tests de caractérisation avant de déplacer les règles dans l'API.
+
+### 12.8 États et variantes client
+
+L'ancienne version contient de nombreux états spécifiques SLAMM, GAP et Bouvard. La nouvelle version en conserve moins. Il faut confirmer si les états supprimés sont obsolètes, remplacés ou encore requis par certains clients.
+
+---
+
+## 13. Hypothèses raisonnables
+
+Les éléments suivants sont des hypothèses, non des faits définitivement établis :
+
+1. `BATIK.md` représente le socle historique commun à plusieurs déclinaisons client, malgré le nom de projet `Isis_BO`.
+2. `OMIKA.md` représente une nouvelle version WINDEV progressivement rebaptisée Omika, et non encore la cible Avalonia.
+3. Les champs `*_Cle*` ont été ajoutés pour stabiliser les références aux paramètres métier indépendamment des identifiants numériques propres à une base.
+4. Les GUID ont été introduits pour faciliter la synchronisation, la déduplication ou l'identification interbases.
+5. `ElementModifie`, `ElementSupprime` et `LIB_Surveille` servent à la synchronisation ou au rafraîchissement distribué des écrans.
+6. `Role` et `CategorieAcces` constituent le nouveau mécanisme de permissions destiné à remplacer ou compléter `AccesEtDroit` et les anciens profils/modules.
+7. `RDV_Planning`, `RDV_Collaborateur` et `RDV_Contact` représentent le modèle cible du planning, tandis que `Planning_RDV` reste pour compatibilité ou migration.
+8. La réduction de 181 à 46 classes traduit l'abandon d'un framework de présentation généralisé plutôt qu'une réduction équivalente du périmètre métier.
+9. Une partie des variantes historiques est désormais portée par les données de paramétrage plutôt que par des configurations compilées.
+
+Toutes ces hypothèses doivent être vérifiées par lecture des fichiers WINDEV physiques, des configurations actives et d'une base représentative.
+
+---
+
+## 14. Zones encore inconnues
+
+### Dépôt et compilation
+
+- arborescence physique complète du dépôt ;
+- fichiers de projet et configurations réellement actives ;
+- gestion de versions et historique des migrations ;
+- dépendances externes non reprises dans les exports ;
+- scripts de build, d'installation et de mise à jour ;
+- déclinaisons exactes par client.
+
+### Données
+
+- version HFSQL serveur et mode de déploiement ;
+- volumes par table ;
+- distributions, valeurs nulles et doublons ;
+- enregistrements orphelins ;
+- statut réel des rubriques zombie ;
+- qualité et unicité des GUID ;
+- encodages et contraintes non visibles dans les extraits ;
+- bases encore non migrées vers OMIKA.
+
+### Règles métier
+
+- définition officielle de chaque statut, type et paramètre métier ;
+- règles de cycle de vie d'un dossier et d'une intervention ;
+- invariants de planning et de suivi des temps ;
+- règles de suppression, archivage et restauration ;
+- portée des transactions ;
+- comportement attendu lors des erreurs réseau ou de concurrence ;
+- règles spécifiques à chaque client.
+
+### Intégrations
+
+- contrat exact avec Batigest ;
+- formats et fréquence des échanges mobiles ;
+- contrat du service de licence ;
+- serveurs de courrier et modèles d'authentification ;
+- rôle opérationnel de SysLog ;
+- emplacement et sécurité des partages documentaires ;
+- moteurs et schémas des bases externes.
+
+### Expérience utilisateur
+
+- écrans réellement utilisés ;
+- fonctionnalités obsolètes ;
+- parcours prioritaires ;
+- exigences d'impression ;
+- raccourcis, comportements implicites et habitudes utilisateurs ;
+- besoins hors connexion éventuels.
+
+---
+
+## 15. Prochaines étapes recommandées
+
+### Étape 1 — Obtenir le dépôt source réel
+
+Récupérer une copie en lecture seule contenant au minimum :
+
+- les fichiers projets WINDEV ;
+- toutes les fenêtres, fenêtres internes, états, classes et collections ;
+- les analyses `.ana`/`.wda` ;
+- les composants internes et externes ;
+- les fichiers de configuration d'exemple expurgés ;
+- les ressources JSON et modèles ;
+- les configurations de compilation.
+
+### Étape 2 — Déterminer la référence fonctionnelle
+
+Faire valider explicitement :
+
+- quelle version est actuellement en production ;
+- quels clients utilisent l'ancienne ou la nouvelle version ;
+- quelles fonctionnalités de l'ancien projet n'ont pas été reprises dans OMIKA ;
+- si OMIKA doit être considéré comme la référence fonctionnelle de la migration Avalonia/API.
+
+### Étape 3 — Produire un inventaire de schéma machine-readable
+
+Exporter pour chaque analyse :
+
+- tables ;
+- rubriques ;
+- types et tailles ;
+- valeurs par défaut ;
+- clés simples/composées ;
+- index ;
+- contraintes et cardinalités ;
+- groupes de protection ;
+- champs zombie ;
+- rubriques ajoutées, supprimées et renommées.
+
+Le résultat devrait être un CSV ou JSON diffable, sans créer encore les modèles .NET.
+
+### Étape 4 — Valider les données réelles
+
+Sur une copie anonymisée :
+
+- compter les lignes ;
+- vérifier les GUID ;
+- comparer anciens identifiants et nouvelles clés ;
+- identifier les valeurs zombie encore alimentées ;
+- vérifier les orphelins ;
+- contrôler le modèle de rendez-vous ;
+- mesurer les tailles de mémos, documents et historiques.
+
+### Étape 5 — Cartographier les cas d'usage
+
+Documenter de bout en bout, avec les tables lues/écrites et les effets de bord :
+
+1. connexion et chargement des droits ;
+2. création/modification d'un client, contact et site ;
+3. création d'un dossier et d'une intervention ;
+4. création/modification d'un rendez-vous simple, groupé et multi-jours ;
+5. saisie et validation des temps ;
+6. génération d'un compte rendu et d'un rapport ;
+7. gestion documentaire ;
+8. envoi de courriel ;
+9. synchronisation Batigest/mobile ;
+10. archivage et suppression.
+
+### Étape 6 — Construire un catalogue des règles métier
+
+Pour chaque règle :
+
+- identifiant et description ;
+- source WINDEV précise ;
+- déclencheur ;
+- entrées ;
+- tables/rubriques ;
+- validations ;
+- sorties ;
+- effets de bord ;
+- message d'erreur ;
+- variantes client ;
+- test de caractérisation associé.
+
+### Étape 7 — Étudier les migrations existantes
+
+Auditer en priorité :
+
+- `FEN_MaJParemApp` ;
+- `Lib_Version` ;
+- les procédures liées aux GUID ;
+- les transformations de paramètres métier ;
+- les migrations d'adresses ;
+- le passage de l'ancien au nouveau modèle de rendez-vous ;
+- les mises à jour de profils/rôles.
+
+L'objectif est d'établir une table de correspondance fiable « ancien champ → nouveau champ » avant toute migration vers .NET.
+
+### Étape 8 — Inventorier les intégrations et secrets
+
+Créer une matrice contenant :
+
+- système externe ;
+- protocole ;
+- endpoint ;
+- authentification ;
+- données échangées ;
+- fréquence ;
+- sens du flux ;
+- reprise sur erreur ;
+- propriétaire ;
+- environnement ;
+- secret associé.
+
+Les valeurs sensibles doivent être expurgées de la documentation partagée.
+
+### Étape 9 — Mettre en place des tests de caractérisation
+
+Avant d'écrire l'API :
+
+- capturer des scénarios reproductibles ;
+- préparer des jeux de données anonymisés ;
+- vérifier les résultats WINDEV actuels ;
+- figer les règles critiques de planning, droits, temps, archivage, rapports et synchronisation.
+
+### Étape 10 — Définir ensuite les frontières de la future architecture
+
+Seulement après les étapes précédentes, il sera pertinent de proposer :
+
+- les domaines et agrégats ;
+- les contrats de l'API ;
+- la stratégie d'accès HFSQL ou de migration de base ;
+- les transactions ;
+- les identités publiques ;
+- les écrans Avalonia ;
+- la stratégie de coexistence et de bascule.
+
+Cette étape n'est volontairement pas réalisée dans le présent document.
+
+---
+
+## 16. Priorités d'analyse pour la suite
+
+### Priorité critique
+
+1. modèle de rendez-vous et scripts de migration ;
+2. champs zombie et correspondance avec les nouvelles clés ;
+3. authentification, droits et rôles ;
+4. secrets et accès HFSQL ;
+5. règles contenues dans les fenêtres ;
+6. intégration Batigest et bases externes.
+
+### Priorité haute
+
+1. dossiers/interventions ;
+2. suivi des temps ;
+3. documents, rapports et courriels ;
+4. archivage/suppression ;
+5. surveillance et synchronisation ;
+6. variantes client et états spécifiques.
+
+### Priorité secondaire
+
+1. aide contextuelle ;
+2. visites guidées ;
+3. thèmes et personnalisation UI ;
+4. utilitaires et écrans de démonstration ;
+5. éléments temporaires ou archivés.
+
+---
+
+## 17. Conclusion
+
+Les deux documentations fournissent suffisamment d'éléments pour identifier les grands domaines, les emplacements de la description HFSQL, les familles de traitements et les principales transformations entre l'ancien Batik et OMIKA.
+
+Le point le plus structurant est que la nouvelle version OMIKA a déjà engagé une migration interne importante : nouvelles clés métier, GUID, nouveau modèle de rendez-vous, nouveau système de rôles, suivi des modifications et composants UI réutilisables. Cette migration reste toutefois partiellement superposée à l'ancien modèle, comme le montrent les champs zombie encore utilisés et les tables de planning coexistantes.
+
+La prochaine phase ne doit pas encore consister à générer des modèles .NET. Elle doit d'abord transformer cette connaissance documentaire en inventaires vérifiables : diff de schéma, cartographie des cas d'usage, catalogue des règles, matrice d'intégrations et tests de caractérisation.