21 KiB
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 :
- Mesure du livrable (ce qui existe réellement : lignes, composants, tables, endpoints, tests, documentation, corpus legacy analysé).
- Reconstruction de la chronologie (horodatages des fichiers, journaux de session des assistants, journaux de build/test) → mesure de l'effort réellement écoulé.
- 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, 0TODOréel, 0HACK/FIXME, 0 test ignoré dans toutsrc/. - 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 :
- 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.
- É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.