🧱 PowerBuilder — RAD “DataWindow” (CRUD massif)

PowerBuilder — overview “densifié” (DataWindow, architecture DB-centric, modernisation)

Mental model (à retenir)

DataWindowcomposant “dataset↔UI↔DB updates” (productivité CRUD)

SQL-firstrequêtes, transactions, curseurs, locks : la DB est au centre

Apps lourdesbeaucoup d’écrans métiers, beaucoup de règles de saisie

Legacy SIdurée de vie longue, évolution progressive, stabilisation

Modernisationwrapping services + strangler + réécriture ciblée

Pourquoi PowerBuilder reste présent

Raison	Effet	Conséquence
Coût de remplacement	SI stable + gros périmètre	maintenance plutôt que rewrite
CRUD massif	écrans + grilles + états	productivité historique
DB cœur métier	SQL proche, transactions maîtrisées	tuning “DB-centric”

Positionnement “très fort sur CRUD / DataWindow”

PowerBuilder (image) :
- tu construis vite des écrans data-centric (listes, grilles, formulaires)
- la DataWindow fait le gros du boulot : binding, update, validation, rendering
- tu codes la logique métier + navigation + contrôles
- la DB est le centre : perfs = SQL + index + transactions + réseau

En 2025 :
- on le rencontre surtout en maintenance/modernisation
- l’enjeu = sécuriser + stabiliser + sortir du client/serveur “pur”

Le piège : laisser des clients “trop intelligents” parler trop directement à la DB sans contrôle central.

Décision rapide (maintenir vs moderniser)

Maintenir si : usage stable, ROI de refactor > rewrite, contraintes métiers fortes.
Moderniser si : besoin web, sécurité, exposition API, montée en charge, UX moderne.

1.1 Définition — PowerBuilder, son ADN RAD, et pourquoi DataWindow a changé la donne

Définition “engineering”

PowerBuilder est un environnement RAD conçu pour accélérer la création d’applications métier data-centric. Sa signature : DataWindow — un composant qui encapsule une requête, un dataset, un rendu UI (table, formulaire), et une logique d’update vers la base. Résultat : des écrans CRUD et des grilles construits très vite.

DataWindow

SQL-first

CRUD massif

SI lourd

Les briques typiques

Brique	Rôle	Erreur fréquente
DataWindow	dataset + UI + update	charger “tout” sans pagination
Business logic	contrôles, règles, flux	logique dispersée dans 80 écrans
DB connections	transactions, commits	transactions trop longues (locks)
Reports/exports	sorties métier	batch non contrôlés (perfs)

Promesse (cadrée)

Promesse PowerBuilder :
- fabriquer vite des écrans data-centric et “opérationnels”
- manipuler des données avec une productivité élevée
- s’appuyer sur SQL/DB comme source de vérité

Condition de réussite (sinon legacy douloureux) :
- architecture : limiter l'accès DB direct depuis UI
- discipline : logique métier centralisée / réutilisable
- transactions courtes (locks)
- tests & build reproductible

Une app PB “spaghetti” devient très chère à moderniser : la discipline est la seule assurance.

Forces (ce qui reste impressionnant)

Force	Pourquoi	Résultat
CRUD / grilles	DataWindow “fait le job”	beaucoup d’écrans vite
SQL natif	culture DB	contrôle fin (si bien géré)
Apps lourdes	ergonomie ops	outil back-office efficace

Domaines où on le rencontre encore

- SI bancaires / assurance (back-office)
- industrie (gestion dossiers, stocks, référentiels)
- administration interne (process “data-heavy”)
- systèmes où la DB est centrale et stable

Limites / risques

UX / Web : pas conçu nativement pour expérience web moderne.
Dette : logique dispersée, duplication, couplage UI↔DB.
Sécurité : clients historiques avec accès DB direct (risque + gouvernance).
Compétences : rareté relative des profils (dépendance interne).

Anti-pattern “legacy”

- chaque écran a ses règles copiées/collées
- SQL en dur partout
- transactions longues
- pas d’API / pas de couche service
- build non reproductible

=> modernisation = chantier

Remède

- centraliser : "services" (API) + règles partagées
- réduire le couplage UI↔DB
- observer : hotspots SQL + locks + temps écran
- plan modernisation progressive (strangler)

Décision (maintien vs transformation)

Question	Si “Oui”	Sinon
Le SI est stable et rentable ?	maintenir + refactor ciblé	plan modernisation
Besoin web/API urgent ?	strangler + services	maintenance ok
Risque sécurité DB ?	isoler via middle-tier	durcir accès
Volumétrie écrans énorme ?	migration progressive “screen by screen”	rewrite plus simple possible

DataWindow — le cœur de PowerBuilder (dataset ↔ UI ↔ DB updates) : patterns, risques, bonnes pratiques

Mental model

DataWindow = "mini framework data-centric" :
- une source (SQL / stored proc)
- un dataset (rows/columns)
- un rendu UI (grid/form/labels)
- une logique d’update (insert/update/delete)
- des validations (type, formats, règles)

Résultat :
- fabriquer vite des écrans CRUD et listes

Ce que ça change

En dev web classique :
- tu codes UI + binding + validation + persistence

Avec DataWindow :
- tu configures beaucoup (et tu codes l’exception)

Donc :
- productivité énorme sur CRUD
- mais discipline nécessaire (sinon charge/perf)

Patterns (robustes)

Pattern 1 — “Paged list” (anti-charge)

But : éviter "SELECT *" + 200k lignes.

- filtrer par critères
- pagination (par pages)
- colonnes minimales
- lazy load détails sur action utilisateur

Pattern 2 — “Validate then commit”

- valider champs (UI)
- valider règles métier (service)
- commit court (transactions courtes)
- journaliser erreurs (corr_id)

Pattern 3 — “Service wrapper”

Objectif : sortir du DB direct.
- UI (PB) appelle un service
- service appelle DB, applique règles
- DB credentials uniquement côté service

Résultat :
- sécurité + gouvernance + audit

Pattern 4 — “Read model / Write model”

- lecture optimisée (vue, index)
- écriture validée (proc/service)
- réduit conflits et locks

Performance (les pièges DataWindow)

Piège	Symptôme	Fix
Dataset énorme	écran lent, mémoire	pagination + colonnes minimales
Update en batch non cadré	locks, timeouts	transactions courtes, batch size
SQL non indexé	temps DB	index, plans, stats
N+1 queries	réseau saturé	jointures/vues, préchargement ciblé

Quality gates (obligatoires sur legacy)

Chaque DataWindow a un contrat (inputs, filtres, pagination).
Pas de “SELECT *” en prod.
Temps écran mesuré (p95) + budget de latence DB.
Transactions courtes, commits explicités, rollback propre.
Erreurs standard (message utilisateur + corr_id support).
RBAC cohérent (écran ≠ autorisation DB).

Architecture — du client/serveur DB-direct au n-tiers (service layer) : modèle de modernisation

Topologie 1 — client/serveur “pur” (legacy)

[PowerBuilder Client]  --->  [Database]
- logique répartie côté client
- accès DB direct
- sécurité : complexe (credentials distribués)

Topologie 2 — n-tiers (cible)

[PB UI] -> [Service/API Layer] -> [Database]
- credentials DB centralisés
- règles métier réutilisables
- audit + rate limit + monitoring
- plus facile à exposer au web

Service layer : pourquoi c’est le pivot

Service layer = "ré-architecture sans tout réécrire"

Apporte :
- sécurité (DB creds jamais côté client)
- gouvernance (RBAC, audit)
- standardisation erreurs (corr_id)
- performance (caching, pooling)
- ouverture (web, microservices, ETL)

Idée :
- la UI devient “plus fine”
- la DB devient “moins exposée”

Étapes de modernisation (pragmatiques)

Cartographier : écrans/DataWindows critiques + flux DB.
Isoler : 10 endpoints “service” sur les opérations critiques.
Basculer : PB UI → services pour ces opérations (1 périmètre).
Répéter : “strangler” écran par écran.
Ouvrir : web / BI / mobile sur les mêmes services.

CRUD massif — pourquoi PowerBuilder tient encore dans certains SI (écrans, grilles, règles)

Ce que “CRUD massif” signifie (réel)

- 300 à 2000 écrans métiers (oui…)
- nombreux référentiels (clients, produits, règles)
- grilles de saisie (bulk)
- validations complexes et historiques
- reporting/export pour l’opérationnel

La migration est coûteuse surtout à cause du nombre d’écrans, pas du “langage”.

Stratégie “screen-by-screen”

- identifier top 20% écrans (usage)
- encapsuler règles dans services
- remplacer écrans progressivement :
  - web
  - autre RAD
  - desktop modern
- garder la DB stable pendant transition

SQL & transactions — le vrai “moteur” (locks, commits, erreurs, concurrence)

Règles d’or (DB-centric)

- transactions courtes
- commits explicites et justifiés
- indexation alignée avec filtres réels
- éviter requêtes “fourre-tout”
- observabilité : plan SQL + temps DB + p95 écran

Locks / concurrence (pièges legacy)

Pièges :
- écran ouvert = transaction non close
- batch update massif = locks longs
- “select then update” sans stratégie

Fix :
- commits courts
- “optimistic locking” quand possible
- batch size
- retry contrôlé

Contrat d’erreurs (supportable)

- user_message : clair
- tech_message : log
- code : VALIDATION | CONFLICT | LOCK | TECH
- corr_id : support

Objectif :
- réduire le “debug au téléphone”

Maintenance d’un SI PowerBuilder — refactor, dette, tests, build reproductible, compatibilité

La réalité “SI lourd”

Stabilité opérationnelle > nouvelles features.
Compatibilité OS/DB/drivers/outils build.
Refactor incrémental (sans casser).
Documentation minimale : flux, écrans, DB objects, dépendances.

Top 10 chantiers rentables

Build reproductible (versions, deps).
Cartographie DataWindows critiques.
Standard erreurs + corr_id.
Centraliser règles partagées.
Durcir accès DB.
Mesurer perfs SQL (hotspots).
Réduire transactions longues.
Automatiser tests “happy path”.
Mettre une couche service pour opérations critiques.
Plan de modernisation progressif (strangler).

“Debt radar” (symptômes)

- duplication de logique (copier/coller)
- SQL en dur partout
- écrans très couplés à la DB
- absence de standards
- temps écran non mesuré
- incidents récurrents “aléatoires”
- release risquée (pas de test)

=> ce sont des signaux de modernisation

Sécurité & gouvernance — risques historiques (DB direct) et modèle de durcissement (services, RBAC, audit)

Risque “legacy” #1 : DB credentials côté client

Si le client se connecte directement :
- distribution de secrets DB
- contrôle d’accès hétérogène
- audit incomplet
- surface d’attaque large

Le pivot sécurité = service layer (DB creds uniquement côté serveur).

Modèle de durcissement (pragmatique)

1) Séparer lecture/écriture
2) Centraliser accès DB via services
3) RBAC côté services (pas seulement UI)
4) Audit : qui / quoi / quand (corr_id)
5) Rotation secrets + moindre privilège
6) Segmenter réseau (DB non exposée)

Modernisation / migration — stratégies réalistes (wrap, strangler, screen-by-screen, coexistence)

4 stratégies (choisir selon contexte)

Stratégie	Idée	Quand
Wrap services	API autour DB/logic	urgence sécurité / ouverture web
Strangler	remplacer par morceaux	beaucoup d’écrans
Rewrite ciblé	réécrire 20% critique	ROI rapide
Rewrite total	nouveau SI	rare, si dette extrême

Plan “6 mois” (très pragmatique)

M1 : cartographie + hotspots SQL + risques sécurité
M2 : service layer (10 endpoints) + auth/RBAC + audit
M3 : migrer 5 écrans critiques vers services
M4 : construire un front web pilote (ou autre UI) sur mêmes services
M5 : industrialiser ALM (dev/test/prod, release, tests)
M6 : étendre “screen by screen” + KPI adoption + réduction incidents

Risques (à anticiper)

Inertie métier : écran historique “indispensable”.
Écrans cachés : usage réel non documenté.
Couplage DB : trop de règles dans UI/SQL.
Perf : nouveaux services doivent être dimensionnés (pooling, cache).

Performance — tuning DB-centric (SQL, index, pagination, batch, réseau)

Les 7 leviers les plus rentables

Levier	Mesure	Action
Plans SQL	top slow queries	index + stats + réécriture
Pagination	rows per screen	page size + filtres
Colonnes	payload	sélection minimale
Transactions	lock time	commits courts
Batch	update throughput	batch size + fenêtre
Réseau	round-trips	éviter N+1
Cache	hit ratio	référentiels en cache

Mini protocole d’audit perf (2 jours)

- instrumenter : temps écran + temps DB + rows loaded
- extraire top 30 queries
- vérifier index + stats + cardinalités
- identifier 10 DataWindows "gros datasets"
- appliquer : pagination + colonnes minimales + filtres
- re-mesurer p95

ALM / releases — build reproductible, environnements, dépendances, “no-touch-prod”

Build reproductible (la priorité #1)

Objectif :
- reconstruire la même version à l’identique

Actions :
- figer versions (compilo, libs, drivers)
- documenter dépendances
- automatiser build si possible
- artefacts signés / hash

Environnements

Minimum legacy :
- DEV : développement
- TEST : validation + perf
- PROD : exécution

Règle :
- DB migrations contrôlées
- credentials distincts

Release “safe”

1) build + tag version
2) tests fonctionnels (happy path)
3) sauvegarde DB + plan rollback
4) déploiement
5) smoke tests
6) monitoring post-release

Use-cases & anti-usecases — où PowerBuilder est encore “ROI”, et où il faut basculer

Use-cases (réalistes)

Maintenance et évolution d’un back-office existant (écrans nombreux).
Refactor “sécurité + perf” sans changer l’outil utilisateur.
Modernisation progressive : PB UI conservée, services ajoutés.
Migration “screen-by-screen” vers web / autre UI.

Anti-usecases (plutôt éviter)

Produit web public moderne, mobile-first, UX très custom.
API-first cloud-native avec microservices/observabilité stricte (possible via service layer, mais alors PB n’est plus central).
Refonte totale sans cartographie : risque projet très élevé.

La bonne question : “moderniser l’architecture” plutôt que “changer l’outil”.

Tradeoffs — productivité CRUD vs modernité web, dette, compétences, stratégie

Tradeoffs (table)

Choix	Gains	Coûts	Mitigation
Garder PB	stabilité + vitesse CRUD	dette + rareté skills	refactor + documentation + formation
Service layer	sécurité + ouverture web	chantier archi	strangler progressif
Rewrite	architecture moderne	coût/risque	cibler 20% critique
Migration écran	progressif	durée	KPI + priorisation usage

Quickstart (audit 10 jours) — cartographie + hotspots + sécurité + build reproductible + plan modernisation

Plan 10 jours (SI existant)

Jour	Objectif	Livrable	Critère
J1–J2	Cartographie	top écrans/DataWindows + flux	80% usage couvert
J3–J4	Perf DB	top queries + index gaps	hotspots identifiés
J5	Transactions/locks	liste transactions longues	plan réduction
J6	Sécurité	risques DB direct + plan durcissement	priorisé
J7	Build	build reproductible documenté	rebuild ok
J8	Standards	conventions + erreurs + corr_id	adoptable
J9	Modernisation	stratégie (services/strangler)	pragmatique
J10	Roadmap	plan 6 mois + KPI	validable

KPI (modernisation)

- p95 temps écran (top 20)
- incidents / mois (avant/après)
- % opérations via services (vs DB direct)
- backlog migration écrans
- taux d’adoption (utilisateurs actifs)

Cheat-sheet PowerBuilder — anti-galère (DataWindow, SQL, transactions, sécurité, modernisation)

25 règles “prod”

Cartographier les DataWindows critiques (usage).
Pagination obligatoire sur listes lourdes.
Éviter “SELECT *” et colonnes inutiles.
Mesurer p95 temps écran + temps DB.
Top slow queries → index/stats/réécriture.
Transactions courtes (locks).
Batch updates : batch size + fenêtre.
Standardiser erreurs (VALIDATION/LOCK/TECH) + corr_id.
Centraliser règles partagées (éviter duplication).
Réduire SQL “en dur” partout.
Durcir accès DB (moindre privilège).
Éviter DB credentials côté client (si possible).
Introduire service layer pour opérations critiques.
RBAC côté serveur/service, pas seulement UI.
Audit : qui fait quoi (au minimum sur opérations sensibles).
Build reproductible (versions figées).
DEV/TEST/PROD distincts.
Plan rollback DB (backup, scripts).
Documentation : flux + dépendances + runbook.
Refactor hebdo (duplications).
Strangler : écran par écran, priorisé usage.
Exposer des APIs propres pour web/BI.
Ne pas réécrire tout sans cartographie.
POC perf avant bascule majeure.
KPI modernisation suivis mensuellement.

Résumé (à coller dans IDEO-Lab)

PowerBuilder = RAD DB-centric historique
- force : DataWindow (CRUD + grilles + updates DB)
- encore présent dans des SI lourds (maintenance/modernisation)
- enjeux : perfs SQL, transactions/locks, sécurité (DB direct), build reproductible
- modernisation gagnante : service layer + strangler “screen-by-screen”
Positionnement : WinDev old-school + super composant data-centric

🧱 PowerBuilder — RAD “DataWindow” (CRUD massif, SI lourds)

PowerBuilder — définition & pourquoi ça a dominé

DataWindow (le “killer feature”)

Architecture (n-tiers, services)

CRUD massif : écrans “métier” lourds

SQL & Data Access

Maintenance SI lourd

Sécurité & gouvernance

Modernisation / migration

Performance (DB-centric)

ALM / releases

Use-cases & anti-usecases

Tradeoffs

Quickstart (audit 10 jours)

Cheat-sheet PowerBuilder