Omika/docs/ESTIMATION_EFFORT_DEVELOPPEMENT.md

# Estimation de l'effort de développement — Projet Omika (ex-BATIK)

> **Objet** : estimer le temps qu'aurait nécessité le développement de ce projet **réalisé entièrement par un humain** (sans IA), afin de confronter cette estimation à l'hypothèse posée :
> **« 28 jours avec activité ≈ 28 journées actives × 6 h = 168 h »**.
>
> **Date d'analyse** : 11 septembre 2026 · **Méthode** : mesures objectives du livrable + reconstruction de la chronologie réelle + estimation bottom-up par composant, croisée par un modèle de productivité.
> **Aucun fichier du projet n'a été modifié.**

---

## 1. Verdict en une page

| Question | Réponse |
|---|---|
| Les 28 jours d'activité sont-ils réels ? | **Oui, et vérifiables.** Le projet a été construit du **06/08/2026 au 11/09/2026**, avec **22 jours réellement actifs** (tous du mardi au vendredi ; aucun lundi, aucun week-end). |
| Les 168 h décrivent-elles bien le travail effectué ? | **Oui, comme temps de travail *assisté par IA*.** Les mesures donnent ≈ **200 à 210 h** d'activité outillée, soit l'ordre de grandeur de 28 × 6 h. |
| Ces 168 h sont-elles une estimation valable du **développement humain** ? | **Non.** Pour produire ce livrable à la main, l'estimation est de **≈ 630 à 1 000 jours-homme**, valeur centrale **≈ 800 jours-homme** (≈ **3 800 à 6 000 h**, centrale ≈ 4 800 h). |
| Écart avec l'hypothèse | **×22 à ×36**, valeur centrale **≈ ×29**. |
| Traduction projet | 1 développeur senior seul : **≈ 3 à 4,5 ans**. Petite équipe de 3 : **≈ 13 à 21 mois**. |

**En une phrase** : les 28 jours mesurent correctement le **temps écoulé pour piloter une IA** qui a produit le code ; ils ne mesurent pas — et ne peuvent pas mesurer — l'**effort de développement humain équivalent**, qui se situe autour de **800 jours-homme**.

---

## 2. Méthode et pourquoi trois approches

Une estimation unique sur un projet de cette taille n'est pas fiable. Trois méthodes indépendantes ont été croisées :

1. **Mesure du livrable** (ce qui existe réellement : lignes, composants, tables, endpoints, tests, documentation, corpus legacy analysé).
2. **Reconstruction de la chronologie** (horodatages des fichiers, journaux de session des assistants, journaux de build/test) → mesure de l'effort réellement écoulé.
3. **Estimation bottom-up** par composant (5 analyses indépendantes par couche), puis **contre-vérification par un modèle de productivité** (lignes effectives / jour-homme).

**Convention** : 1 jour-homme (j-h) = **6 h de travail effectif**, conformément à l'hypothèse posée.

**Nature de l'estimation** : il s'agit du coût de **reproduction à neuf de l'existant, à qualité et périmètre identiques**, en incluant conception, tests et documentation — c'est-à-dire ce qu'un humain aurait dû fournir.

---

## 3. Ce que contient réellement le livrable (mesuré)

### 3.1 Volumétrie du code

| Périmètre | Fichiers | Lignes |
|---|---|---|
| `src/Omika.Core` (domaine, contrats, services, sync mobile) | 321 | 16 229 |
| `src/Omika.Data` (HFSQL, bi-schéma Batik/Omika) | 267 | 36 197 |
| `src/Omika.App` (UI Avalonia) | 136 + 51 `.axaml` | 14 402 + 7 728 |
| `src/Omika.App.Local` (SQLite, SyncEngine, Outbox) | 136 | 13 613 |
| `src/Omika.Api` (web service) | 24 | 3 549 |
| `src/Omika.Worker` (service de synchronisation) | 8 | 1 106 |
| Hôtes Desktop / Android / iOS | 5 | 106 |
| **Sous-total production** | **897 `.cs` + 51 `.axaml`** | **85 202 C# + 7 728 XAML** |
| `tests/Omika.Tests` | 164 | 43 824 |
| `tools/` (17 sondes de rétro-ingénierie) | 25 | 2 893 |
| **TOTAL code** | **≈ 1 137** | **≈ 139 650** |

### 3.2 Qualité et densité réelle du code

Analyse ligne à ligne (hors lignes vides, commentaires, accolades et déclarations) :

| Nature | Lignes | Commentaire |
|---|---|---|
| **Logique réelle** | **71 357** | algorithmes, SQL, sync, règles métier |
| **Déclaratif / boilerplate** | **33 485** | modèles, DTO, entités, interfaces, attributs, propriétés auto |
| **Balises XAML** | **7 249** | mise en page et design system |
| **Total brut** | **166 478** | |

Sur les 118 classes de modèles HFSQL (11 846 lignes), **seules 377 lignes sont de la logique** : le reste est déclaratif, et **107 des 118 fichiers sont auto-générés** par `tools/generate_models.py` depuis le dictionnaire de compatibilité. C'est un point important : ce volume ne se traduit pas en effort humain proportionnel.

### 3.3 Completude du livrable (facteur rassurant pour l'estimation)

- **0 `NotImplementedException`**, **0 `TODO` réel**, **0 `HACK`/`FIXME`**, **0 test ignoré** dans tout `src/`.
- 8 agrégats métier documentés `VERIFIED` (CRUD complet testé sur bases réelles).
- Réserves identifiées (à traiter avant production, non comptées ci-dessous) : base SQLite locale **non chiffrée**, jeton Bearer stocké **en clair**, pas de rate limiting sur les endpoints publics de licence, pas de framework de validation.

### 3.4 Surface fonctionnelle

| Indicateur | Valeur |
|---|---|
| Projets dans la solution | 13 |
| Écrans applicatifs distincts | **29** |
| ViewModels / Vues XAML / contrôles personnalisés / convertisseurs | 42 / 51 / 14 / 15 |
| Endpoints HTTP | **97** |
| Tables HFSQL physiques distinctes manipulées | **65** (118 classes de modèles, 113 attributs `[HfSqlTable]`) |
| Couples table-rubrique mappés (dictionnaire de compatibilité) | **720** |
| Méthodes publiques de repositories | **≈ 330** |
| Instructions SQL brutes | **≈ 500** |
| Transactions explicites | 186 |
| Bases HFSQL distinctes (Business / Service / WebService / Licence / Sync) | 4-5 |
| Tables SQLite locales + repositories locaux | 29-30 / 18 |
| Tests | **2 038** méthodes (2 020 `[Fact]`, 18 `[Theory]`) |
| Fakes / stubs écrits à la main (aucune lib de mock) | 100+ |
| Documentation produite | **≈ 8 200 lignes** rédigées (22 documents) + dictionnaire de compatibilité JSON **19 021 lignes** + maquette HTML 593 lignes |

### 3.5 Ampleur du legacy rétro-ingénieré

| Corpus | Lignes |
|---|---|
| `docs/BATIK.md` (export WINDEV du legacy `Isis_BO`) | 303 801 |
| `docs/OMIKA.md` (export WINDEV de la refonte `Batik`/Omika) | 271 909 |
| Documentation des 3 web services / services legacy | 24 582 |
| **Total corpus legacy analysé** | **≈ 600 300 lignes** |

Système legacy à remplacer (mesuré dans les exports) : **≈ 1 600 procédures** (1 009 + 614 comptées), **140 fenêtres** `FEN_*`, **≈ 380 classes**, **46 états d'impression**, **48 / 58 tables** selon la génération (59 en union), **3 web services / services**, **4 variantes clients**. Soit un capital de développement historique estimé à **10-20 personnes-années sur ~8 ans**.

---

## 4. Chronologie réelle du projet (mesurée, pas déclarée)

### 4.1 Fenêtre et jours actifs

Le projet a été intégralement créé entre le **06/08/2026** et le **11/09/2026** (aucun contenu antérieur : tous les fichiers du dépôt — code *et* documentation — portent une date ≥ 06/08/2026).

| Indicateur | Valeur |
|---|---|
| Période calendaire | 37 jours |
| Jours ouvrés (lun-ven) dans la période | 27 |
| **Jours réellement actifs** | **22** |
| Jours avec écriture de code source | 21 |
| Jours actifs hors mardi-vendredi | **0** |
| Jours ouvrés actifs / jours ouvrés disponibles | **22 / 22 (100 %)** |

Motif parfaitement net : activité du **mardi au vendredi** ; les 5 lundis et tous les week-ends de la période sont **inactifs**. Les 22 jours « mardi-vendredi » de la fenêtre ont **tous** été travaillés.

### 4.2 Volume de travail outillé

| Source de mesure | Valeur |
|---|---|
| Sessions d'assistant CodeWhale (07/08 → 20/08) | 17 sessions, **2 515 messages humains**, 607 M tokens, 52 140 s de temps de génération |
| Sessions d'assistant DSH (20/08 → 11/09) | 31 sessions, 442 messages humains, 769 711 événements, 183,6 Mo compressés |
| Amplitude horaire des journées (horodatages) | **8 h à 13 h** de fenêtre, moyenne ≈ 9,6 h/jour |
| Campagnes de build/test laissées dans le dépôt | **108 journaux**, 36 exécutions de tests |
| Croissance de la suite de tests | **260 → 1 859 tests** en 36 exécutions successives |
| Effort outillé total estimé | **≈ 200 à 210 h** |

### 4.3 Points de contrôle sur l'hypothèse « 28 jours × 6 h »

- **Les 28 jours** : la mesure donne 22 jours actifs. Le chiffre de 28 est légèrement supérieur mais du **bon ordre de grandeur** ; il a vraisemblablement été obtenu en comptant aussi les journées de faible activité (12-14/08 : builds et mise en place VPN ; 28/08 ; 04/09).
- **Les 6 h/jour** : les journées réellement observées couvrent 8 à 13 h d'amplitude. 6 h de travail **effectif** net est donc une hypothèse prudente et plausible.
- **Conclusion partielle** : *28 jours × 6 h = 168 h est une description correcte et même plutôt prudente du travail assisté par IA.*

---

## 5. Estimation de l'effort humain — décomposition bottom-up

Cinq analyses indépendantes par couche, chacune fondée sur le code réel, les preuves et la complexité intrinsèque.

| # | Composant | Contenu | Basse | Haute | Central |
|---|---|---|---|---|---|
| 1 | **Analyse & rétro-ingénierie legacy** | Inventaire des 2 générations, rétro-ingénierie du schéma HFSQL (48 → 58 tables, 720 rubriques, zombies, mappings de types, liaisons), lecture du code WINDEV (≈ 1 600 procédures, 140 fenêtres, ≈ 380 classes), rétro-ingénierie des 3 web services (206 procédures), sondage réel OLE DB, rédaction des specs (architecture, 7 lots, modèle canonique, CRUD) | 50 | 80 | 60 |
| 2 | **`Omika.Core`** | Domaine (38 entités, 5 value objects, 21 commandes), 125 DTO, 61 interfaces, 17 services CRUD, moteurs document/rapport (PDF/DOCX, parseur RTF/CP1252, parseur JSON WINDEV 305 l.), **Services/Mobile** (licence AES-256 rétro-ingénierée, jeton HMAC-SHA256, résolution d'identité GUID↔PK, snapshot, sync idempotente) | 55 | 96 | 80 |
| 3 | **`Omika.Data` — couche HFSQL** | 20 classes de connexion (dualité **ODBC / OLE DB `PCSOFT.HFSQL`**), 118 modèles physiques, 29 classes de mapping, **19 repositories Batik + 20 Omika + 22 adaptatifs**, ≈ 330 méthodes, ≈ 500 requêtes SQL brutes, 186 transactions, détection de schéma par canaris, dérivation MD5 des mots de passe de fichiers HFSQL, topology 4 bases | 230 | 380 | 300 |
| 4 | **`Omika.App` + `Omika.App.Local`** | 29 écrans, 42 ViewModels, design system 755 l., 14 contrôles, 15 convertisseurs, Shell responsive 2 layouts, 3 hôtes plateformes ; côté local : schéma SQLite 29-30 tables, 18 repositories, **SyncEngine** (4 étapes, états, reprise après crash), **Outbox**, **réconciliation d'identité A→B + 5 réécrivains de payloads**, SnapshotApplier atomique, offline-first multi-entités, documents multipart | 148 | 189 | 170 |
| 5 | **`Omika.Api`** | 97 endpoints, DI multi-connexions, middleware Bearer, service de permissions + périmètre planning, licence (activation/validation + émission de jeton), sync (3 endpoints), bootstrap, documents base64, emails/rapports | 20 | 30 | 25 |
| 6 | **`Omika.Worker`** | Boucle de polling, ordonnancement CREATE→UPDATE→DELETE, déduplication intra-cycle, **idempotence à 2 niveaux** (OperationId + résultat terminal MobLog), transaction unique multi-bases, isolation par opération, retry/rejet, 4 handlers (dont refus explicite de tout SUCCESS par défaut) | 10 | 16 | 13 |
| 7 | **Suite de tests** | 2 038 tests, 43 824 lignes, 100+ fakes ADO.NET/HTTP écrits à la main, fixtures `WebApplicationFactory`, intégrations **réelles** HFSQL (7 fichiers, cycle CREATE→UPDATE→ARCHIVE→ROLLBACK), **E2E multi-processus** (HTTP → API → TOSRV → Worker externe → MobReception → handler → MobLog → statut) | 50 | 80 | 65 |
| 8 | **Outils de sondage** | 17 programmes d'investigation (audit de schéma, audit de modèle, dérivation de mots de passe, idempotence, détection N+1, résolution d'identité) | 3 | 6 | 5 |
| | **Sous-total composants (après dédoublonnage des tests et de la rétro-ingénierie déjà comptés en ligne 1)** | | **531** | **812** | **≈ 670** |

### 5.1 Charges transverses (non attribuables à un composant)

| Poste | Justification | Basse | Haute | Central |
|---|---|---|---|---|
| Architecture & conception globale | 13 projets, protocole de sync mobile, stratégie bi-schéma Batik/Omika, multiplateforme, modèle d'identité canonique | 10 | 20 | 15 |
| Environnement & infrastructure | Serveur HFSQL, installation et déverminage des providers ODBC **et** OLE DB `PCSOFT.HFSQL`, accès VPN (FortiClient installé les 12-13/08), SDK/émulateur Android, chaîne iOS, bases de test BATIK_TEST / OMIKA_TEST, configuration de développement | 15 | 30 | 22 |
| Intégration & débogage | 36 campagnes de tests successives (260 → 1 859 tests), cycles réels contre bases réelles, E2E multi-processus, correction d'encodage Windows-1252, contournement des limites du provider (marshalage `DateOnly`, colonnes calculées, padding `\0` des mémos) | 40 | 70 | 55 |
| Pilotage, clarification du besoin, validation | Documents de lot avec points d'arrêt et divergences (« STOP » sur la base Licence), matrices de couverture CRUD, points de validation fonctionnelle | 20 | 40 | 28 |
| Packaging, service Windows, builds mobiles | Service Windows du Worker, APK Android, déploiement desktop | 10 | 20 | 15 |
| **Sous-total transverse** | | **95** | **180** | **≈ 135** |

### 5.2 Total

| | Basse | Haute | **Central** |
|---|---|---|---|
| Composants | 531 | 812 | 670 |
| Transverse | 95 | 180 | 135 |
| **TOTAL (jours-homme)** | **≈ 630** | **≈ 1 000** | **≈ 800** |
| **TOTAL (heures à 6 h/j)** | **≈ 3 780 h** | **≈ 6 000 h** | **≈ 4 800 h** |
| **TOTAL (personnes-années à 1 400 h)** | 2,7 | 4,3 | **3,4** |

---

## 6. Contre-vérification par la productivité

Modèle indépendant : lignes **effectives** produites ÷ productivité réaliste d'un développeur senior (code final, intégré et débogué, hors temps de réunion).

| Nature | Lignes effectives | Productivité retenue | Jours-homme |
|---|---|---|---|
| Déclaratif / boilerplate (modèles, DTO, entités, interfaces) | 33 485 | 250-400 l./j | 84-134 |
| Logique de production (SQL, sync, métier, UI) | 43 158 | 60-120 l./j | 360-719 |
| Logique de test | 28 199 | 100-180 l./j | 157-282 |
| XAML (mise en page, design system) | 7 249 | 80-150 l./j | 48-91 |
| Documentation rédigée (`docs/*.md`) | 8 169 | 250-500 l./j | 16-33 |
| Dictionnaire de compatibilité (JSON/CSV, produit par outillage) | ≈ 19 300 | outillé | 5-10 |
| **Sous-total production** | **≈ 139 500** | | **670-1 269** |

Ce sous-total **ne comprend pas** la rétro-ingénierie du legacy (≈ 600 000 lignes lues pour ≈ 139 500 lignes produites) ni les charges transverses. En intégrant un abattement raisonnable pour ces postes déjà couverts par la ligne « analyse legacy », on converge vers :

- **Fourchette du modèle de productivité : ≈ 600 à 1 100 j-h**
- **Fourchette du bottom-up : ≈ 630 à 1 000 j-h**

Les deux méthodes **convergent vers une valeur centrale de l'ordre de 800 jours-homme**, ce qui donne confiance dans l'ordre de grandeur.

---

## 7. Mise en perspective avec l'hypothèse de 168 h

| Grandeur | Valeur |
|---|---|
| Effort assisté par IA mesuré (réel) | ≈ 200-210 h |
| Hypothèse utilisateur (28 j × 6 h) | **168 h** |
| Effort humain équivalent estimé (central) | **≈ 4 800 h** (800 j-h) |
| **Écart central** | **≈ ×29** |
| Écart minimal (hypothèse basse 630 j-h vs 168 h) | **×22** |
| Écart maximal (hypothèse haute 1 000 j-h vs 168 h) | **×36** |

### Pourquoi l'écart est aussi important (et pourquoi ce n'est pas une erreur)

En ≈ 210 h de travail outillé, le projet a produit **≈ 194 000 lignes** (code, tests, documentation, artefacts) — soit **≈ 925 lignes par heure**. Un développeur humain produit, selon la nature du code, **5 à 50 lignes par heure** de code final intégré et débogué.

Autrement dit, l'écart ne vient pas d'une sous-estimation des 28 jours : il vient du fait que **l'IA a produit du volume à une cadence qu'un humain ne peut pas atteindre**, en particulier sur tout ce qui est mécanique et répétitif :
- 107 modèles de tables générés automatiquement ;
- 125 DTO et 61 interfaces quasi déclaratifs ;
- 2 038 tests dont une large part de structure répétitive ;
- 8 200 lignes de documentation rédigée + un dictionnaire de 19 000 lignes ;
- les 289 classes de mapping et la duplication bi-schéma Batik/Omika (15 800 lignes d'implémentations jumelles).

Un humain qui aurait fait ce projet « à la main » n'aurait pas produit ces 194 000 lignes : il aurait pris des raccourcis (génération de code, factorisation, moins de tests, moins de documentation). **C'est pourquoi l'estimation retenue est celle de la reproduction du périmètre et de la qualité observés, et non une simple conversion lignes → heures.**

---

## 8. Traduction en scénarios projet

| Scénario | Durée |
|---|---|
| **1 développeur senior seul** (à ~220 j-h/an) | **≈ 2,9 à 4,5 ans** (central ≈ 3,6 ans) |
| **2 développeurs** | ≈ 1,5 à 2,3 ans |
| **Petite équipe de 3** (1 senior + 2 confirmés, coordination incluse) | **≈ 13 à 21 mois** |
| **Équipe de 4-5** (dev + analyste + QA à temps partiel) | ≈ 9 à 14 mois |

Répartition indicative d'une équipe de 3 : 1 senior sur le socle Data/sync/identité (≈ 300 j-h), 1 développeur sur l'UI et le local (≈ 200 j-h), 1 développeur sur le Core/API/Worker/tests (≈ 200 j-h), plus l'analyse legacy (≈ 60 j-h) et le transverse (≈ 135 j-h) partagés.

---

## 9. Sensibilité, limites et précautions d'usage

### 9.1 Ce qui fait varier le résultat

| Facteur | Impact |
|---|---|
| **Périmètre des tests** | C'est le premier levier : 2 038 tests et 100+ fakes représentent ≈ 50-80 j-h. Un projet sans cette discipline tombe de 10-15 %. |
| **Rétro-ingénierie du legacy** | 50-80 j-h d'analyse pure, non compressibles, et prérequis à tout le reste. |
| **Dualité de schéma Batik/Omika** | ≈ 15 800 lignes d'implémentations jumelles : c'est le principal multiplicateur de coût de la couche Data. |
| **Documentation** | ≈ 8 200 lignes rédigées + dictionnaire produit : 21-43 j-h selon l'exigence. |
| **Maturité visée** | Le livrable n'est pas encore « production mobile » (chiffrement de la base locale, coffre de jeton, rate limiting, validation). Une version durcie ajouterait **+15 à +30 j-h**. |
| **Connaissance préalable** | L'estimation suppose l'apprentissage du legacy HFSQL **inclus**. Un développeur déjà expert HFSQL/OLE DB pourrait gagner 10-15 %. |

### 9.2 Limites de l'estimation

- **Aucun dépôt Git** : la chronologie a été reconstruite à partir des horodatages de fichiers, des journaux de session et des journaux de build ; elle est cohérente mais ne remplace pas un historique de commits.
- **Les messages humains comptés** (2 515 + 442) incluent les messages de pilotage d'outil ; ils mesurent l'intensité de la supervision, pas des heures de développement.
- **Les estimations par composant proviennent de cinq analyses distinctes** avec des hypothèses propres ; le dédoublonnage (tests et rétro-ingénierie comptés une seule fois) a été appliqué explicitement, mais une incertitude de ±10 % subsiste sur les frontières entre lots.
- **Le code a été produit par IA** : il peut contenir des défauts non détectés par la suite de tests. Un humain repartant de zéro pourrait rencontrer des difficultés différentes — mais il n'aurait pas non plus à découvrir et corriger ces défauts.

### 9.3 Recommandation de présentation

Si l'objectif est de communiquer un chiffre défendable, distinguer explicitement **deux mesures qui ne répondent pas à la même question** :

1. **Temps de production assistée par IA** : **≈ 28 jours d'activité, ≈ 170-210 h** — mesure du temps de pilotage et d'itération réel.
2. **Équivalent de développement humain** : **≈ 630 à 1 000 jours-homme (≈ 3 800 à 6 000 h)**, valeur centrale **≈ 800 j-h (≈ 4 800 h)** — mesure de l'effort qu'aurait exigé la construction du même livrable sans IA.

Présenter le premier chiffre comme du « temps humain de développement » conduirait à une sous-évaluation d'un facteur **≈ 25 à 30**, ce qui fragiliserait l'ensemble de l'estimation si elle devait être auditée.

---

## 10. Synthèse finale

| | Valeur |
|---|---|
| Jours d'activité mesurés | **22** (hypothèse posée : 28) |
| Heures assistées par IA mesurées | **≈ 200-210 h** (hypothèse posée : 168 h) |
| **Effort humain équivalent (estimation)** | **630 – 1 000 j-h** |
| **Valeur centrale retenue** | **≈ 800 j-h ≈ 4 800 h ≈ 3,4 personnes-années** |
| Écart avec l'hypothèse de 168 h | **×22 à ×36 (central ≈ ×29)** |
| Traduction la plus parlante | **1 développeur senior : ≈ 3 à 4,5 ans · équipe de 3 : ≈ 13 à 21 mois** |

**L'hypothèse « 28 jours × 6 h » n'est pas réaliste comme estimation de développement humain**, mais elle est cohérente comme mesure du temps réellement passé à produire le projet **avec l'aide d'une IA**.