⚡ WinDev – RAD, WLanguage, HFSQL & Déploiement

HFSQL vs PostgreSQL : choix d’architecture, perf, transactions & verrous

1) Décision rapide (pragmatique)

Contexte	Recommandation	Pourquoi
App métier CRUD “simple”, parc local	HFSQL Classic	setup rapide, faible friction.
Multi-utilisateurs + centralisation + sécurité	HFSQL Client/Server	central, mieux en concurrence.
SI “enterprise”, reporting, BI, intégrations	PostgreSQL	standard, écosystème, perf, tooling.
Cloud, HA, observabilité, DevOps mature	PostgreSQL	réplication, backups, monitoring.
Offline mobile + sync	Hybride	local store + remote SQL.

Règle d’or : choisis le moteur “qui colle au mode d’exploitation”. Le CRUD rapide ≠ l’industrialisation cloud/BI.

2) “Features” qui changent tout

Thème	HFSQL	PostgreSQL
Outillage intégré RAD	Très fort	Outillage externe
Standardisation / recrutement	Moyen	Très fort
BI / analytics / SQL avancé	Moyen	Excellent
Observabilité / tuning	Correct	Excellent
HA / réplication / cluster	Variable	Écosystème riche

                            IDEO-Lab pattern (conseillé) :
                            - UI -> Service -> DAL
                            - DAL abstrait : HFSQL OU PostgreSQL
                            => tu peux migrer sans réécrire l’UI.

Perf = requêtes + index + pagination

                            3 erreurs qui tuent :
                            1) charger 50 000 lignes dans une table UI
                            2) filtrer côté UI au lieu du serveur
                            3) ORDER BY sur colonne non indexée

Index “juste” (exemples)

                            - CUSTOMER.Email (lookup)
                            - ORDER(CustomerId, CreatedAt DESC) (liste + tri)
                            - ORDER_LINE(OrderId) (jointures)

Un index composite doit refléter le WHERE + ORDER BY.

Pagination stable (anti-sauts)

                            Pagination "stable" :
                            ORDER BY CreatedAt DESC, Id DESC

                            Page 1: limit=50
                            Page 2: offset=50 (OK)
                            OU mieux (keyset pagination) :
                            WHERE (CreatedAt, Id) < (:lastCreatedAt, :lastId)
                            LIMIT 50

Keyset pagination = meilleure perf sur grosses tables (évite OFFSET coûteux).

Cache (quand oui / quand non)

Objet	Cache ?	Durée
Référentiels (pays, statuts)	Oui	minutes/heures
Résultats de recherche user	Parfois	courte
Données transactionnelles	Prudence	cohérence

Transactions : modèle “courtes et atomiques”

                            UseCase: CreateOrder
                            - validate (hors tx)
                            - begin tx
                            - insert order
                            - insert lines
                            - insert audit
                            - commit

Valider avant la transaction (réduit le temps de lock).
Éviter les écrans qui “ouvrent” une tx puis attendent l’utilisateur.
Centraliser l’accès data (DAL) pour contrôler tx/locks.

Verrous : symptômes & fixes

Symptôme	Cause	Fix
UI “freeze” sur Save	tx longue / lock	valider avant tx + commit rapide
Deadlocks	ordre d’accès tables variable	ordre stable + tx courtes
Timeouts aléatoires	index manquant	index sur WHERE + tri

                            Pattern anti-deadlock :
                            Toujours toucher les tables dans le même ordre :
                            CUSTOMER -> ORDER -> ORDER_LINE -> AUDIT

Architecture hybride (le meilleur des 2 mondes)

                    Cas typique :
                    - Offline (mobile / terrain) : stockage local (HFSQL/équivalent)
                    - Central (entreprise)       : PostgreSQL
                    - Sync                       : queue + idempotency + conflits gérés

Sync “robuste” (minimal)

Queue locale d’opérations (Create/Update/Delete).
Idempotency key (rejeu safe).
Retry exponentiel + journal des échecs.
Conflits : version/timestamp + stratégie.

Conflits : 4 stratégies

                            1) Last-write-wins (simple)
                            2) Merge champs (si possible)
                            3) Server-authoritative (serveur gagne)
                            4) Human resolution (cas rares)

Checklist “choix moteur + perf” (à imprimer)

✅ Requêtes principales listées (top 20) + index associés.
✅ Pagination partout (aucun écran ne charge “tout”).
✅ DAL unique + requêtes paramétrées.
✅ Transactions courtes + ordre stable d’accès tables.
✅ Logs perf : temps requête, temps tx, corrId.
✅ Backups + test restore + plan rollback.
✅ Monitoring : latence, locks, erreurs, saturation I/O.

1.1 WinDev : philosophie RAD & positionnement

WinDev = RAD “productivité d’abord”

WinDev (PC SOFT) est un environnement de développement RAD (Rapid Application Development) : designer d’UI + événements + accès données + génération d’exécutables / web / mobile avec une forte intégration outillée (éditeur, debug, générateurs, assistants, packaging).

RAD

IDE + Générateurs

HFSQL & SQL

Déploiement assisté

Catégorie (comme tu demandais)

Terme	Classement	Notes
WinDev	Suite RAD / IDE	Pas un “framework” : c’est un environnement + générateurs + runtime.
WLanguage	Langage	Langage maison (procédures + OO), orienté productivité et événementiel.
HFSQL	SGBD	Stockage intégré possible + mode client/serveur selon besoins.

RAD vs Framework (ex: Django)

Un framework (Django) est une librairie structurante. WinDev est une factory : conception visuelle + code + runtime + packaging.

                            RAD (WinDev)
                            - Designer UI (fenêtres/pages) + événements
                            - Assistants (BDD, CRUD, états, sécurité)
                            - Génère des artefacts (exe / web / mobile)
                            - Runtime + déploiement guidé
                            - Fort couplage outillage ⇢ productivité

                            Framework (Django)
                            - Code first (Python), structure imposée
                            - Outils additionnels (admin, ORM)
                            - Déploiement via stack externe (Nginx/Gunicorn/…)
                            - Plus ouvert/interop, plus “engineering”

Heuristique : si ton besoin = application métier CRUD + délais courts + équipe orientée Windows, WinDev brille. Si ton besoin = écosystème web/cloud large + CI/CD + architecture distribuée, un framework web “code-first” est souvent plus flexible.

Cas d’usage “WinDev est très fort”

Apps métier : gestion, ERP light, back-office, CRM, workflow interne.
CRUD rapides : écrans + listes + formulaires + états/exports.
Connexion SI : bases SQL, web services, fichiers plats, imports.
Contextes Windows : déploiement poste à poste / parc entreprise.
Maintenance long terme : cohérence outillage + assistant “convention” RAD.

Cas d’usage “prudence”

Web “très moderne” (front SPA complexe, design system fin, micro-frontends).
Architectures cloud-native (K8s, events, polyglotte) si l’équipe est très DevOps.
Interop très large (SDKs open-source spécifiques, libs ML, etc.).

Checklist décision (10 questions)

#	Question	Si “Oui” →
1	Projet CRUD dominant ?	WinDev excellent.
2	Délais très courts / prototypes rapides ?	WinDev excellent.
3	Équipe orientée outillage Windows ?	WinDev naturel.
4	Need CI/CD cloud complexe ?	Planifier intégration outillage.
5	Front web UX “pixel perfect” ?	Évaluer alternatives web.
6	Lots d’intégrations standards (SQL/HTTP) ?	WinDev ok.
7	Contraintes perf extrêmes ?	Bench + arch data.
8	Fort besoin d’open-source libs ?	Interop à valider.
9	Migration legacy (Access/Excel/…) ?	WinDev très utile.
10	Long terme multi-équipes ?	Normes + composants.

Forces typiques

Time-to-Market : assistants + génération + conventions.
Outillage intégré : debug, états, data binding, UI builder.
Cycle data-centric : analyse ↔ fichiers ↔ requêtes ↔ écrans.
Déploiement : packaging orienté entreprise.

Le cœur WinDev : procédures + événements + data.

Limites typiques (à gérer)

Couplage outillage : l’IDE influence les patterns de code.
Écosystème : moins de libs communautaires qu’un langage mainstream.
Architecture : risque “spaghetti event-driven” sans discipline de couches.
Web moderne : selon besoin UI, arbitrer WebDev vs stack JS.

                            Risque majeur en RAD :
                            - code métier dans les events UI
                            - accès BD direct depuis les fenêtres
                            - duplication de logique
                            => Solution : couches + procédures + modules + conventions

Modèle mental recommandé (IDEO-Lab)

                    ┌─────────────────────────────── UI ────────────────────────────────┐
                    │ Fenêtres / Pages / Champs / Tables / Boutons                      │
                    │ Events: Init, Click, Modify, Validate, Display...                 │
                    └───────────────┬───────────────────────────────────────────────────┘
                    ▼
                    ┌──────────────────────────── Procédures ────────────────────────────┐
                    │ Services métier (validation, règles, calculs, workflow)            │
                    │ DTO/Structs + mapping UI <-> modèle                                │
                    └───────────────┬───────────────────────────────────────────────────┘
                    ▼
                    ┌──────────────────────────── Data Access ───────────────────────────┐
                    │ HFSQL (HReadSeek/HAdd/HModify)  OU  SQL (requêtes paramétrées)     │
                    │ Transactions, retries, pagination, index                           │
                    └───────────────┬───────────────────────────────────────────────────┘
                    ▼
                    ┌─────────────────────────── Intégrations ───────────────────────────┐
                    │ REST/SOAP, fichiers, queues, annuaires, SSO, systèmes legacy       │
                    └────────────────────────────────────────────────────────────────────┘

Règle d’or : un event UI ne fait que “collecter / afficher”, et délègue le reste à des procédures métier testables.

1.2 WLanguage : syntaxe, typage & patterns

Essentiels (style “code lisible”)

                            // Variables
                            sName is string = "IDEO-Lab"
                            nCount is int = 0

                            // Conditions
                            IF nCount = 0 THEN
                            Info("First run")
                            END

                            // Boucles
                            FOR i = 1 _TO_ 10
                            Trace("i=" + i)
                            END

                            // Procédure (fonction)
                            PROCEDURE ComputeTax(nAmount is numeric) : numeric
                            RESULT nAmount * 0.20

Pattern : préfixes simples (s/n/b/dt…) ou typage explicite partout — choisis 1 convention et tiens-la.

Chaînes / format / dates

                            // Concat / format
                            s = "User: " + sName
                            s2 = StringBuild("Order %1 - %2 €", nId, nTotal)

                            // Dates
                            dtNow is DateTime = DateTimeSys()
                            dToday is Date = DateSys()

                            // Comparaison & calculs (à centraliser)
                            IF dToday > dDeadline THEN
                            Error("Late")
                            END

Conseil : centraliser la logique de formatage (montants, dates) dans un module utilitaire.

Tableaux / listes / boucles sûres

                            arr is array of string
                            Add(arr, "A")
                            Add(arr, "B")

                            FOR EACH s OF arr
                            Trace(s)
                            END

                            // Dictionnaire / map (selon versions)
                            map is associative array of int
                            map["k1"] = 10
                            Trace(map["k1"])

Pour la perf : éviter les concatenations en boucle sans buffer (préférer StringBuild / accumulateur).

Structures (DTO) : séparer UI et data

                            stCustomer is Structure
                            Id is int
                            Name is string
                            Email is string
                            END

                            PROCEDURE UiToCustomer() : stCustomer
                            st is stCustomer
                            st.Name = EDT_Name
                            st.Email = EDT_Email
                            RESULT st

Idéal pour : validation, tests, sérialisation JSON, mapping DB.

Objets : encapsuler la logique métier

                            MyService is Class
                            PROCEDURE SaveCustomer(st is stCustomer) : boolean
                            END

                            PROCEDURE MyService.SaveCustomer(st is stCustomer) : boolean
                            IF NOT ValidateCustomer(st) THEN
                            RESULT False
                            END
                            // Appel DAL
                            RESULT CustomerDAL.Save(st)

Objectif : rendre le code testable, éviter le “tout dans la fenêtre”.

Modules / composants réutilisables

Module utilitaire : dates, strings, formatters, logs.
Composant UI : liste paginée, formulaire standard, popup.
DAL : accès data unique, requêtes paramétrées, transactions.
Service : règles métier, workflow, orchestration.

                            UI Event -> Service -> DAL -> DB
                            (UI ne connaît pas les détails DB)

Robustesse : erreurs, logs, “fail fast”

Pattern “Result + Error” (simple)

                            PROCEDURE TrySaveCustomer(st is stCustomer, sErr is string by reference) : boolean
                            sErr = ""
                            IF st.Name = "" THEN
                            sErr = "Name required"
                            RESULT False
                            END
                            // ...
                            RESULT True

À standardiser : “valider → exécuter → log → retourner”.

Pattern “Exceptions contrôlées” (si dispo)

                            TRY
                            // Action critique
                            CATCH e
                            // Log + message user
                            END

Idée : n’exposer au user que des messages utiles, garder les détails en logs.

1.3 Architecture : couches, modules, conventions “anti-spaghetti”

Découpage minimal viable (MV-Layers)

Couche	Rôle	Exemples
UI	Écran, navigation, saisie, feedback.	Fenêtres, pages, tables, champs.
Service	Règles métier + orchestration.	Validation, calcul, workflow, droits.
DAL	Accès données centralisé.	Requêtes paramétrées, CRUD, transactions.
Infra	Interop, logs, config, crypto.	HTTP, auth, fichiers, secret vault, trace.

WinDev “scale” très bien si tu imposes ce découpage dès le départ.

Erreurs courantes

SQL dans le click d’un bouton.
Validation dispersée dans 12 events différents.
Formats / conversions copiés-collés partout.
Absence de DAL ⇒ duplication, bugs, perf imprévisible.

                            Anti-pattern:
                            BTN_Save.Click -> HAdd(Customer) -> Info("OK")

                            Pattern:
                            BTN_Save.Click -> st = UiToDTO()
                            -> ok = CustomerService.Save(st)
                            -> UI affiche résultat

Règles de dépendance (simples et efficaces)

                    UI      -> Service (OK)
                    Service -> DAL     (OK)
                    DAL     -> DB      (OK)
                    UI      -> DAL     (NO)
                    DAL     -> UI      (NO)

Convention de nommage (exemple)

                            CustomerService.*
                            CustomerDAL.*
                            CustomerDTO / stCustomer
                            UiCustomerMapper.*
                            Log.*
                            Cfg.*

Bonus : “Use-Cases”

                            UseCase: CreateCustomer
                            - validate input
                            - check uniqueness
                            - start tx
                            - insert customer
                            - insert audit log
                            - commit

Diagrammes (ASCII) : flux UI → Data

                    [Window/Page]
                    │ (events)
                    ▼
                    [Mapper UI→DTO] ──► [Service] ──► [DAL] ──► [HFSQL/SQL]
                    ▲                   │           │
                    │ (msg)             ▼           ▼
                    [UI Feedback]     [Auth/Rules]  [Transactions/Index]

Flux WebDev (session)

                    Browser -> WebDev Page -> Server Procedures -> DAL -> DB
                    │
                    └-> Session / Cookies / Auth

Checklist “projet propre” (à coller sur un mur)

✅ 1 DAL par domaine (CustomerDAL, OrderDAL…)
✅ 1 service par domaine + use-cases
✅ DTO/Structures pour découpler UI
✅ Validation centralisée
✅ Logs (niveau info/err) + identifiant de corrélation
✅ Transactions explicites sur opérations multi-tables
✅ Index définis selon requêtes (pas “au hasard”)
✅ Politique d’erreurs : message user vs détail technique

2.1 Projet WinDev : analyse, fenêtres/pages, composants & organisation

L’Analyse = schéma de données (data-centric)

L’analyse structure : fichiers/tables, rubriques/champs, relations, index, contraintes. Elle sert de source de vérité pour générer/relié UI + requêtes + traitements.

                            Entités typiques :
                            - CUSTOMER (Id, Name, Email, Status)
                            - ORDER (Id, CustomerId, Total, CreatedAt)
                            - ORDER_LINE (OrderId, ProductId, Qty, Price)
                            Index :
                            - CUSTOMER.Email (unique)
                            - ORDER.CustomerId + CreatedAt (range)

Interop SQL externe

Même si tu utilises HFSQL, beaucoup de SI branchent PostgreSQL / Oracle / MySQL.

                            Recommandation IDEO-Lab :
                            - définir un DAL unique
                            - requêtes paramétrées
                            - pagination standard
                            - "read model" vs "write model" si besoin

Pattern : 1 “source data” + 1 “cache local HFSQL” (offline / perf) si nécessaire.

Arborescence mentale (simple) : ce qu’on range où

                    Projet WinDev
                    ├─ Analyse (data model)
                    ├─ Fenêtres (UI desktop) / Pages (WebDev)
                    ├─ États (reporting, impressions, exports)
                    ├─ Procédures
                    │   ├─ Services (métier)
                    │   ├─ DAL (data access)
                    │   ├─ Utils (format, logs, crypto)
                    │   └─ Integrations (HTTP, files, SSO)
                    ├─ Classes / Collections
                    └─ Composants internes (UI réutilisable)

Artefact	Rôle	Bon usage
Fenêtre/Page	UX + événementiel	aucune règle métier lourde
Procédure	logique réutilisable	validation, use-cases, DAL
État	report	préparer dataset via Service/DAL
Composant	UI + logique locale	patterns d’écran récurrents

Composants : “industrialiser” WinDev

Composant liste paginée standard (filtre / tri / export).
Composant “Form Guard” (validation uniforme + messages).
Composant “Audit Banner” (trace, version, env, user).
Composant “Error Modal” (erreurs métier, codes, corrId).

                            But :
                            - accélérer
                            - homogénéiser
                            - réduire bugs (mêmes patterns partout)

Template de procédure “use-case”

                            PROCEDURE UC_CreateOrder(st is stOrder, sErr is string by reference) : boolean
                            sErr=""

                            // 1) validate
                            IF NOT OrderRules.Validate(st, sErr) THEN RESULT False END

                            // 2) tx
                            IF NOT DAL.BeginTx(sErr) THEN RESULT False END

                            // 3) write
                            IF NOT OrderDAL.Insert(st, sErr) THEN DAL.Rollback(); RESULT False END
                            IF NOT AuditDAL.Log("ORDER_CREATE", st.Id, sErr) THEN DAL.Rollback(); RESULT False END

                            // 4) commit
                            IF NOT DAL.CommitTx(sErr) THEN RESULT False END
                            RESULT True

Normes d’équipe (les 8 règles qui évitent 80% des dérives)

UI = affichage + collecte, jamais de SQL direct.
DAL unique, requêtes paramétrées, pagination standard.
Validation centralisée (un module Rules).
Transactions explicites sur opérations multi-tables.
Logs systématiques (corrId + user + action).
Gestion d’erreurs uniforme (codes métier).
Composants UI réutilisables (éviter copier-coller d’écrans).
Convention de nommage stable (Service/DAL/DTO).

2.2 UI Designer & événements : cycle de vie, validations, UX

Événementiel : où mettre quoi ?

Cycle typique

                            Window Init:
                            - charger context (user, env)
                            - initialiser champs
                            - binder la grille (read)

                            Button Save Click:
                            - Ui -> DTO
                            - Service.Save(dto)
                            - afficher succès/erreur

Le bouton ne “sait pas” comment sauver, il “demande” au service.

Table des events (mapping)

Event	But	Interdit
Init/Opening	préparer UI	logique métier lourde
Modify	micro-validation	accès DB
Validate	validation UI	transactions
Click	orchestration	SQL brut partout

Validation : 3 niveaux (UI / métier / data)

                    Niveau 1 - UI : champs obligatoires, formats simples (email)
                    Niveau 2 - Métier : règles (ex: crédit, statut, droits)
                    Niveau 3 - Data : contraintes (unique, FK, tx, lock)

Pattern “ValidateThenSave”

                            st = UiToDTO()
                            IF NOT Rules.Validate(st, sErr) THEN
                            Error(sErr)
                            RETURN
                            END
                            IF NOT Service.Save(st, sErr) THEN
                            Error(sErr)
                            ELSE
                            Info("OK")
                            END

Message user vs message technique

                            User: "Email déjà utilisé"
                            Log : "Unique constraint CUSTOMER.Email violated (corrId=... user=...)"

UX “métier” efficace (très WinDev)

Listes paginées + recherche instantanée + tri multi-colonnes.
Formulaires en sections (header → détails → pièces jointes).
Raccourcis clavier, focus management, validation inline.
Exports (PDF/Excel) depuis un dataset stable (Service/DAL).
Historique / audit (qui a modifié quoi, quand).

RAD = gagner du temps sur la mécanique, le réinvestir dans l’UX métier.

State & navigation : unifier le “contexte”

                    Contexte global (ex):
                    - userId, role, tenantId
                    - env (DEV/REC/PROD)
                    - corrId (pour logs)
                    - locale/timezone

                    Navigation:
                    - passer un DTO ou un Id, pas 12 variables

3.1 HFSQL & Data Access : modèle, CRUD, transactions

HFSQL : idées clés

Mode Classic (fichier local) : simple, rapide à démarrer.
Mode Client/Server : centralisation + concurrence + sécurité.
Accès via fonctions HF (lecture, recherche, ajout, modif).

                            CRUD (pseudo-code style):
                            - HReadSeekFirst(File, Key, value)
                            - HAdd(File)
                            - HModify(File)
                            - HDelete(File)

Index : ce qui compte vraiment

Besoin	Index recommandé	Note
Recherche par email	CUSTOMER.Email	unique si possible
Liste des commandes d’un client	ORDER(CustomerId, CreatedAt)	supporte range + tri
Lookup par id	PK	évident

La perf = requête + index + pagination. Le reste est secondaire.

SQL externes : PostgreSQL / MySQL / Oracle (pattern stable)

                    Recommandation IDEO-Lab :
                    - requêtes paramétrées (jamais concat SQL)
                    - DAL unique
                    - timeouts & retries contrôlés
                    - mapping DB->DTO (pas DB->UI)

Requête paginée (concept)

                            SELECT *
                            FROM ORDERS
                            WHERE CustomerId = :cid
                            ORDER BY CreatedAt DESC
                            OFFSET :off ROWS FETCH NEXT :limit ROWS ONLY

Concurrence

                            - transactions courtes
                            - éviter verrous longs
                            - index sur colonnes filtrées
                            - isolation adaptée (read committed souvent)

DAL minimal (CRUD + requêtes métier)

                    CustomerDAL
                    - GetById(id)
                    - GetByEmail(email)
                    - Insert(stCustomer)
                    - Update(stCustomer)
                    - Search(filter, paging)

                    OrderDAL
                    - ListByCustomer(customerId, paging)
                    - InsertOrderWithLines(stOrder, arrLines)

Le DAL peut cacher HFSQL ou SQL : l’UI ne change pas.

Transactions : règles simples

Une transaction pour une intention métier (ex: créer commande + lignes + audit).
Transaction courte : valider avant, puis écrire vite, puis commit.
Rollback sur toute erreur ; log avec corrId.

                    UC_CreateOrder:
                    - validate
                    - begin tx
                    - insert order
                    - insert lines
                    - insert audit
                    - commit

3.2 Requêtes & performance : index, pagination, cache, verrous

Index = perf prédictible

Symptôme	Cause fréquente	Fix
Liste lente	Pas d’index sur filtre	Index sur colonnes WHERE
Tri lent	ORDER BY non couvert	Index composite (filter, sort)
Recherche textuelle lente	LIKE %x%	stratégie fulltext / normalisation

Pagination (ne jamais charger 100k lignes)

                    UI:
                    - pageSize (20/50/100)
                    - offset/pageNumber
                    - tri stable (CreatedAt DESC, Id DESC)
                    - totalCount si nécessaire (attention perf)

Cache : 3 niveaux

UI : cache de page (rafraîchissement bouton).
Service : cache “read-only” de référentiels (listes statiques).
Data : index / matérialisation / cache DB (selon moteur).

Verrous & concurrence

                    Règles:
                    - tx courtes
                    - éviter "read then write" sur longs écrans
                    - préférer "optimistic" (si possible) + checks
                    - logs pour diagnostiquer (temps tx)

WebDev : web apps, sessions, sécurité & déploiement

Pages WebDev : structure recommandée

                    Page:
                    - init (load model)
                    - events (actions)
                    - render (UI)
                    Service:
                    - rules, auth, dto mapping
                    DAL:
                    - data

Sessions : points de contrôle

Durée session + renouvellement.
Cookies sécurisés (Secure/HttpOnly/SameSite).
Anti-CSRF si formulaires sensibles.
Gestion multi-tenant (tenantId en session).

APIs : REST “propre” (contrats stables)

                    GET /api/customers?query=...&page=1&size=50
                    POST /api/orders
                    PATCH /api/customers/{id}

                    Réponses:
                    - status
                    - data
                    - error {code,message,corrId}

Déploiement web : checklist

Reverse proxy (TLS, compression, cache statics).
Logs d’accès + logs applicatifs.
Monitoring (CPU/RAM, latence, erreurs 4xx/5xx).
Build reproductible + versionning.

WinDev Mobile : offline, sync, build & stores

Arch mobile : même discipline de couches

                    UI (screens) -> Service -> DAL
                    DAL:
                    - local store (HFSQL/SQLite-like)
                    - remote API (REST)
                    Sync:
                    - queue + retries + conflict strategy

Offline : stratégie simple

Écritures en queue locale (opérations).
Sync en background (quand réseau OK).
Gestion conflits (timestamp / version / last-write-wins / merge).

Sécurité mobile

Tokens en stockage sécurisé (éviter clair).
Chiffrement local si données sensibles.
Pinning TLS si threat model exigeant.
Logs “safe” (pas de PII en clair).

Build & stores (checklist)

                    - version code / version name
                    - signing keys
                    - env (DEV/REC/PROD)
                    - endpoints par env
                    - crash reporting

4.1 APIs & interop : REST/SOAP/JSON/Webhooks/Auth

REST : contrat stable

                    Response standard:
                    {
                    "status": "ok|error",
                    "data": {...},
                    "error": {"code":"...", "message":"...", "corrId":"..."}
                    }

Les services WinDev/WebDev/Mobile doivent partager le même contrat JSON (même erreurs).

Auth : patterns

Token (JWT ou opaque) + refresh.
RBAC : rôles & permissions.
Audit des actions sensibles.

Webhooks : règles

                    - signature (HMAC)
                    - idempotency key
                    - retries exponentiels
                    - logs (corrId)

Interop fichiers (ETL léger)

Imports CSV/Excel : staging → validation → commit.
Exports : dataset stable + pagination + filtres.
Traçabilité : rapport d’import (ok/ko ligne).

4.2 Qualité : tests, logs, instrumentation, CI

Stratégie de tests “WinDev réaliste”

Unit : Rules + Services (sans UI).
DAL : tests sur DB de test (données seed).
UI : smoke tests + parcours critiques (limiter le coût).

                    But :
                    - tests sur la logique (où sont les bugs)
                    - UI : tests courts (où sont les regressions)

Logs : format standard

                    [ts] [level] [corrId] [user] [action] message
                    Ex:
                    2025-12-25T09:05:01Z INFO  c-8f31  u:42  ORDER_CREATE OK id=991 total=120.50
                    2025-12-25T09:05:02Z ERROR c-8f31  u:42  ORDER_CREATE DB timeout (retry=1)

Sans corrId, diagnostiquer en prod devient “archéologie”.

CI : pipeline minimal (même en RAD)

Build reproductible + version.
Tests unit/service.
Packaging (installer / web artifact).
Déploiement “staging” + smoke test.

Debug prod : approche

                    - logs + métriques (latence, erreurs)
                    - dashboards (top erreurs, top endpoints)
                    - rollback simple
                    - feature flags si possible

4.3 Sécurité : secrets, auth, crypto, durcissement, OWASP

Secrets : règles

Ne jamais hardcoder mots de passe / tokens.
Fichiers de config par environnement.
Rotation + séparation des rôles (least privilege).

Authentification & autorisation

                    - RBAC: roles -> permissions
                    - audit des actions sensibles
                    - verrouillage brute-force
                    - MFA si contexte exigeant

Web (OWASP) : minimum

Validation entrée (server-side).
Anti-injection (SQL paramétré).
CSRF sur actions stateful.
Headers sécurité (CSP, HSTS si possible).

Durcissement (prod)

TLS partout, cipher policy.
Logs d’accès, alerting sur anomalies.
Principe du moindre privilège en DB.
Backups + test restore.

5.1 Packaging & déploiement : desktop, web, mobile

Desktop : installer, runtime, updates

                    Checklist :
                    - build versionné
                    - install (prérequis, runtime)
                    - config par env
                    - logs vers dossier standard
                    - update automatique (avec rollback)

Web : reverse proxy, scaling, observabilité

                    - TLS termination
                    - compression + cache statics
                    - logs d’accès + logs app
                    - healthchecks
                    - rollout / rollback

Mobile : build reproductible

                    - signing keys
                    - endpoints par env
                    - crash reporting
                    - store metadata

Ops : le “plan de prod” minimal

Item	But	Owner
Monitoring	latence/erreurs	Ops
Backups	RPO/RTO	DBA/Ops
Alerting	incident rapide	Ops
Runbooks	rollback/restart	Dev+Ops

Comparatif : principaux équivalents RAD à WinDev

RAD historiques (même ADN)

Produit	Pourquoi proche	Profil
Delphi (RAD Studio)	UI designer + event-driven + desktop	Dev “engineering” plus bas niveau
PowerBuilder	Data-centric + apps métier	Legacy SI (beaucoup d’entreprises)
Visual Basic (historique) / VBA	rapid dev + forms	petits outils internes
4D	outil intégré + data + UI	verticals / apps métiers

.NET (équivalents “modernes” côté Microsoft)

Stack	Équivalent de quoi	Note
WinForms/WPF	Desktop UI + events	plus “code-first”
ASP.NET	Web back	écosystème large
Power Platform	Low-code	rapide, gouvernance importante

Low-Code / No-Code (famille “RAD++”)

OutSystems / Mendix : plateformes enterprise (gouvernance, scaling).
Power Apps : intégration Microsoft / M365.
Retool : back-offices internes (rapid CRUD).
AppSheet : apps métiers simples (data-centric).

Low-code = très rapide mais attention : lock-in + limites d’architecture.

Carte de choix rapide

                    Besoin CRUD métier + Windows + délais courts      -> WinDev / Delphi / PowerBuilder
                    Besoin web/cloud + équipe DevOps + open-source   -> Framework (Django, Spring, .NET, Node)
                    Besoin très rapide + gouvernance enterprise      -> OutSystems / Mendix / Power Apps
                    Besoin back-office interne rapide                 -> Retool / WinDev / Django-admin

Cheat-sheet WinDev (résumé opérationnel)

10 règles “anti-galère”

UI ≠ métier ≠ data (couches).
DAL unique (paramétré, paginé).
Transactions courtes.
Validation centralisée (Rules).
Logs avec corrId.
Composants UI réutilisables.
Index définis par requêtes réelles.
Messages user propres, détails en logs.
Config par environnement.
Rollback simple.

Architecture “à copier”

                        UI Events -> Service -> DAL -> DB
                        |
                        +-> Auth/Rules/Logs/Config

Découpage modules

                        /Services
                        /DAL
                        /Rules
                        /DTO
                        /Utils (log, cfg, crypto)
                        /Integrations (http, files)

⚡ WinDev – RAD, WLanguage, HFSQL & Déploiement

WinDev en bref (RAD)

WLanguage (concepts)

Architecture & couches

Projet & arborescence

UI Designer & events

HFSQL & accès données

Requêtes & perf

WebDev (Web)

WinDev Mobile

APIs, services & interop

Qualité, tests, logs

Sécurité

Packaging & déploiement

Comparatif RAD

HFSQL vs PostgreSQL

Migration (Access/Excel)

CI/CD WinDev