Parcours de modernisation

Remplacer une application PowerBuilder par une architecture moderne.

Q: Quel langage cible pour migrer PowerBuilder ?

Trois options principales. .NET Core : choix naturel si écosystème Microsoft dominant, syntaxe C# proche de PowerScript. TypeScript + React/Angular : cible web moderne, ouverture mobile, voir Delphi vers TypeScript pour les patterns. Java + Spring Boot : si SI Java dominant. PowerBuilder vers .NET reste le plus fréquent en pratique, notamment via Appeon PowerServer qui propose une transition assistée.

Q: Combien coûte une migration PowerBuilder ?

Le coût dépend de trois variables mesurées au cadrage : le nombre de DataWindows et leur complexité (une DataWindow porte à la fois le SQL, la mise en page et les règles de validation), le volume de logique métier dans les scripts PowerScript, et le choix de la cible entre frontend web et desktop. La cartographie exhaustive des DataWindows est faite dès l'Intake : c'est elle qui sert de base au chiffrage. Cadrage initial gratuit, de 30 minutes à 2 heures.

Q: Access a-t-il déjà livré une migration PowerBuilder ?

Non, pas à ce jour. Nous l'assumons explicitement plutôt que de présenter une capacité comme une réalisation. La méthodologie ATLAS s'applique néanmoins aux modernisations 4GL legacy avec un excellent fit — notre parcours Delphi en démontre l'application sur un langage très proche. Nous proposons un diagnostic PowerBuilder de 2 à 3 semaines sur votre code réel avant tout engagement, pour mesurer la productivité effective et calibrer un chiffrage de programme fiable.

Q: Appeon PowerServer est-il une solution ou un palier ?

Un palier utile, pas une solution finale. Appeon PowerServer permet d'exposer une application PowerBuilder existante en web (.NET ou JavaScript) sans réécriture complète, en encapsulant les DataWindows. Avantages : modernisation rapide, préservation du code métier PowerScript, moindre investissement initial. Inconvénients : dépendance éditeur unique, dette PowerBuilder préservée, coûts de licence Appeon, limites d'évolution. Notre position : Appeon PowerServer est utile comme palier temporaire pour exposer rapidement en web pendant un programme de migration complet vers .NET / Java / TypeScript — pas comme cible finale.

Q: Comment ATLAS garantit la parité fonctionnelle sur PowerBuilder ?

Quatre disciplines combinées. (1) Cartographie exhaustive des DataWindows dès la phase E2 Discovery (SQL sources, colonnes calculées, règles de validation, événements). (2) Tests de caractérisation écrits en amont sur le legacy PowerBuilder : la suite caractérise le comportement avant qu'on touche au code cible. (3) Runs parallèles PowerBuilder / cible sur jeux de données client avec comparaison automatique — objectif > 99 % d'équivalence sur les chemins critiques. (4) Registre interne de discordances classées selon une grille CRITIQUE / ADAPTATION / COSMÉTIQUE : chaque écart documenté, pondéré, arbitré et classé. Voir la méthodologie ATLAS complète.

Migration d'applications PowerBuilder (PowerScript, DataWindow, PBL) vers .NET Core, TypeScript ou Java, sous méthodologie ATLAS. Capture des écrans, tests de caractérisation, migration pattern par pattern, audit de parité, exposition API REST pour intégration cloud et workflows agentiques.

Chiffres clés

30-50%

part de l'effort UI total représentée par le portage des DataWindows (à inclure dans le chiffrage initial)

50-150

DataWindows dans un parc PowerBuilder courant, toutes cartographiées dès la phase Intake

Par lots

livraison incrémentale, durée définie au cadrage

Méthodologie ATLAS appliquée

Du cadrage au déploiement, cinq phases structurées.

Chaque phase regroupe une ou plusieurs des dix étapes ATLAS. Aucune phase ne démarre tant que la précédente n'a pas livré son artefact validé. La méthodologie ATLAS rend la migration AS/400 prévisible et auditable.

01Phase 1
Cadrage
Étapes ATLAS
E1 Intake · E2 Discovery · E2b Spécification fonctionnelle
Comprendre le patrimoine PowerBuilder : projets, écrans, DataWindow, PBL, DataStores, intégrations bases de données. Reconstituer une analyse fonctionnelle à partir du code. Définir périmètre, contraintes, critères de réussite, choix de l'architecture cible (.NET / Java / TypeScript, SPA web vs WinForms).
Livrable de phase
Inventaire patrimoine + spec fonctionnelle + chiffrage avec fourchette assumée
02Phase 2
Capture & dépendances
Étapes ATLAS
E2e Capture · E3 Mapping des dépendances
Cartographie exhaustive des DataWindows (SQL sources, colonnes calculées, règles de validation, événements onChange/onBlur), des PBL packages, des scripts PowerScript, des dépendances DataStores partagés. Identification des intégrations bases (SQL Anywhere, Sybase ASE, Oracle) à migrer.
Livrable de phase
Bench de DataWindows et écrans de référence + cartographie complète dépendances
03Phase 3
Architecture cible
Étapes ATLAS
E4 Architecture cible · E4b Tests pré-migration
Concevoir l'architecture cible : .NET Core / Java Spring Boot / TypeScript Node.js, base PostgreSQL ou SQL Server cloud, conteneurisation, exposition API REST documentée OpenAPI, frontend SPA séparé ou WinForms. Stratégie cloud et observabilité. Préparer la suite de tests de caractérisation.
Livrable de phase
Architecture cible signée + suite de tests + maquettes UI si refonte web
04Phase 4
Migration & parité
Étapes ATLAS
E5 Migration · E6 Validation parité
Traduire pattern par pattern : DataWindow → AG Grid/Telerik/JavaFX TableView, PowerScript → C#/Java/TypeScript, DataStores → entités/repositories, PBL → packages cibles. Migration incrémentale par sous-système, runs parallèles, audit de parité signé sur chaque lot.
Livrable de phase
Code cible + audit de parité par sous-système + registre de discordances tracé
05Phase 5
Déploiement & transfert
Étapes ATLAS
E7 Livraison
Mise en service progressive avec coexistence PowerBuilder ↔ cible pendant la transition (durée définie au cadrage selon le profil de risque), bascule par lot, exposition des API REST aux workflows cloud et aux intégrations tierces, transfert d'exploitation à l'équipe cliente avec documentation et pair-programming.
Livrable de phase
Application cible en production + API exposées + équipe cliente autonome + plan de maintenance

Voir la méthodologie ATLAS complète →

Au cœur de la méthode ATLAS

L'IA pour comprendre le PowerBuilder, pas pour le traduire.

Le DataWindow de PowerBuilder n'a aucun équivalent dans les plateformes cibles : il combine dans un seul objet la requête SQL, la mise en page, les règles de validation et le comportement de mise à jour. Les outils de conversion le reproduisent sous forme de grilles génériques, en perdant les règles de validation qu'il portait. La traduction automatique de bout en bout n'est pas une méthode de modernisation, c'est un transfert de dette.

Notre méthode est inverse. ATLAS repose sur plusieurs lectures du code d'origine, menées selon plusieurs angles. Ici, ce que nous relisons en priorité : chaque DataWindow, pour en extraire séparément la requête, les règles de validation et le comportement de persistance, ainsi que les bibliothèques PBL et leurs dépendances croisées. L'IA intervient comme accélérateur de compréhension, pour déchiffrer des années de logique métier accumulée, rétro-documenter des branches non commentées, expliciter l'intention derrière le code. Elle ne décide pas et ne traduit pas. Elle éclaire le travail de l'architecte, qui conçoit ensuite l'architecture cible et pilote la migration pattern par pattern, sous audit de parité.

Cette compréhension exige encore des humains qui connaissent les technologies d'origine. C'est notre avantage : là où l'Europe et l'Amérique du Nord font face à une vague de départs en retraite sur ces compétences, la Tunisie conserve des développeurs PowerBuilder et PowerScript expérimentés, couplés à des architectes modernes. Ensemble, ils assurent la continuité entre l'intention métier d'origine et le système cible.

Qui est concerné

Contexte métier et enjeux de modernisation.

PowerBuilder : un legacy qui survit dans la finance et les ERP sectoriels

PowerBuilder (Sybase puis Appeon) reste présent dans les PME ETI, les banques régionales, les assurances mutualistes et les ERP sectoriels développés entre 1995 et 2010. Sa force historique : la DataWindow, un composant qui combinait modèle de données, présentation et interactivité dans un seul objet — extrêmement productif pour les applications métier transactionnelles. Sa faiblesse aujourd'hui : éditeur peu actif, expertise rare, architecture client-serveur incompatible avec mobile et web. La modernisation n'est plus une option à long terme.

Pourquoi moderniser maintenant

Trois forces poussent à la migration. Premièrement, la disparition progressive des développeurs PowerBuilder : les profils formés dans les années 2000 partent en retraite ou se reconvertissent, et la relève est inexistante en école. Deuxièmement, l'incompatibilité structurelle avec les canaux modernes (mobile, web responsive, intégrations API) qui force des contournements coûteux. Troisièmement, la fragilité d'Appeon PowerBuilder (édition actuelle) comme éditeur unique : tout investissement futur dépend de la santé d'un seul fournisseur. La méthodologie ATLAS cadre cette modernisation de façon prévisible.

Capacité Access — méthodologie transposable, POC sur votre code à la demande

Access International n'a pas livré à ce jour de programme de modernisation PowerBuilder client. La capacité est néanmoins réelle : la méthodologie ATLAS (10 étapes, 9 principes, registre interne de discordances classées) s'applique aux modernisations 4GL legacy avec un excellent fit — notre parcours Delphi en démontre l'application sur un langage très proche (Pascal, VCL, FireDAC partagent l'esprit RAD de PowerBuilder). Nous proposons un diagnostic PowerBuilder de 2 à 3 semaines sur votre code réel avant tout engagement de programme, pour mesurer la productivité effective et calibrer le chiffrage de façon fiable.

Plateforme source

PowerBuilder (PowerScript, DataWindow, PBL, Appeon PowerServer)

PowerBuilder↗

Cible technologique

.NET Core 8 ou Java 21 ou TypeScript, PostgreSQL ou SQL Server, REST API, frontend SPA ou WinForms selon contexte

.NET Core 8↗TypeScript↗PostgreSQL↗SQL Server↗Java 21↗

Alternatives technologiques

Comparer les trajectoires cibles.

.NET Core 8 + C# + SQL Server + frontend SPA ou WinForms

Choix le plus fréquent en pratique : C# est syntaxiquement proche de PowerScript, écosystème Microsoft dominant en PME/ETI cibles PowerBuilder, Appeon PowerServer propose une transition assistée. WinForms si besoin desktop préservé.

Java 21 + Spring Boot + PostgreSQL + frontend SPA

Quand le SI cible est dominé par Java ou que la portabilité multi-OS (Linux serveur) est requise. Distance syntaxique PowerScript-Java plus grande que PowerScript-C#.

TypeScript + React/Angular + Node.js + PostgreSQL

Quand l'objectif est une vraie modernisation web cloud-native (mobile-first, multi-canal, ouverture aux workflows cloud et IA). Voir les patterns dans Delphi vers TypeScript.

Appeon PowerServer (transition assistée)

Palier temporaire pour exposer PowerBuilder en web et REST sans réécriture complète. Utile pour gagner du temps avant programme de migration complet, pas comme cible finale (dette PowerBuilder préservée).

Repère de cadrage

Durée et équipe type pour ce parcours.

Une migration PowerBuilder se planifie par lots fonctionnels successifs, dont la cadence est définie au cadrage selon le volume de DataWindows et la cible choisie (.NET, TypeScript, Java). Cellule type : architecte PowerBuilder-cible, tech lead langage cible, des développeurs cible, un développeur PowerBuilder senior pour la connaissance métier (essentiel en début de programme), un UX designer pour la refonte ergonomique web, un QA, un DBA. La composition et l'effectif ne sont pas fixés à l'avance : ils sont déterminés à l'issue du POC et du cadrage, une fois le travail réel mesuré. L'effort UI sur les DataWindows représente typiquement 30 à 50 % de l'effort total — il doit être inclus dans le chiffrage initial, pas découvert en cours de programme.

Défis

Transformer les DataWindow (composant clé combinant SQL + UI + validation + calculs dérivés) vers leurs équivalents modernes sans casser la cohérence métier.
Porter la logique PowerScript vers le langage cible (.NET, Java, TypeScript) en préservant les comportements et le cycle de vie des objets.
Choisir l'interface cible : SPA web (React, Angular), WinForms .NET si desktop préservé, ou architecture mixte selon les écrans.
Moderniser les bases historiques (SQL Anywhere, Sybase ASE, Oracle) vers PostgreSQL managé ou SQL Server cloud.

Approche ATLAS

Capture exhaustive du patrimoine PowerBuilder : écrans, DataWindow (SQL sources, colonnes calculées, règles de validation, événements), DataStores, PBL packages, scripts PowerScript, intégrations bases de données.
Suite de tests de caractérisation écrite en amont sur le legacy : jeux de données représentatifs, scénarios de saisie/consultation, validation des calculs dérivés.
Migration pattern par pattern documentée : DataWindow → AG Grid + Form web (TypeScript), Telerik Grid en .NET, ou JavaFX TableView en Java. PowerScript → C# / Java / TypeScript avec mapping explicite. PBL → packages cibles.
Runs parallèles PowerBuilder / cible avec audit de parité signé, exposition systématique de la logique métier en API REST pour ouvrir aux workflows cloud (Azure Logic Apps, n8n, Power Automate, agents IA).

Résultats attendus

Application cible conforme aux standards modernes : injection de dépendances, tests unitaires, observabilité, conteneurisation.
Suite de tests de non-régression automatisée, réutilisable pour les évolutions futures.
Documentation des patterns DataWindow migrés livrée avec le registre interne de discordances classées.
Donnée et logique métier exposées en API REST, consommables par workflows cloud et agents IA — l'application client-serveur devient un service composable.

Pièges identifiés et réponse ATLAS

Ce que nous avons appris sur ce chemin de migration.

Piège 01

Sous-estimer la complexité des DataWindows. Une DataWindow combine SQL, présentation, validation, calculs dérivés — la migration naïve casse souvent la cohérence.

Réponse ATLAS

Cartographie exhaustive des DataWindows dès l'Intake : SQL sources, colonnes calculées, règles de validation, événements onChange/onBlur. Chaque DataWindow est portée vers son équivalent moderne (AG Grid + Form web, Telerik Grid en .NET, JavaFX TableView en Java) avec validation par composant. Tests de parité ligne par ligne sur jeux production.

Piège 02

Migrer un script PowerScript à la fois sans repenser l'architecture. Le résultat est un Java/C#/TypeScript qui hérite de la dette PowerBuilder.

Réponse ATLAS

Découpage par bounded context métier lors de la phase d'architecture cible. Les scripts PowerScript liés sont regroupés en services cohérents, les DataStores partagés deviennent des entités/repositories. Cette refactorisation structurelle est séparée de la parité fonctionnelle — phase distincte après bascule.

Piège 03

Choisir WinForms .NET par défaut sans réévaluer le besoin desktop. Pour la plupart des applications PowerBuilder, le besoin desktop original (intégration Windows, mode déconnecté) n'est plus structurant.

Réponse ATLAS

Réévaluation systématique du besoin desktop vs web en phase E4 Architecture cible. Si une vraie modernisation est souhaitée, frontend SPA séparé (React, Angular) avec backend .NET/Java. WinForms uniquement si besoin desktop avéré et écosystème Microsoft.

Piège 04

Migrer code-pour-code sans repenser l'exposition de la logique métier. On rate alors l'opportunité de transformer l'application client-serveur en services consommables par des workflows cloud, des agents IA ou des intégrations tierces.

Réponse ATLAS

Architecture cible orientée API REST dès la phase E4 : exposition de la logique métier en endpoints documentés (OpenAPI), avec authentification standard (OAuth2, JWT), versioning, observabilité. L'UI consomme l'API comme n'importe quel autre client — cloud workflow, n8n, Power Automate, agent IA. C'est ce qui justifie la migration au-delà de la simple dette technique.

Piège 05

Déclarer la migration terminée après la conversion de code, sans valider les workflows utilisateurs réels ni la parité fonctionnelle sur les jeux de données du client.

Réponse ATLAS

Principe E7 — validation navigateur et workflow métier obligatoire avant livraison. Runs parallèles PowerBuilder / cible sur les transactions clés, comparaison automatique des résultats, audit de parité avec registre interne de discordances classées selon une grille CRITIQUE / ADAPTATION / COSMÉTIQUE. Aucune bascule sans parité prouvée.

Expertise associée

Legacy to Cloud

Voir les modules, services et cas d'usage.

Méthodologie propriétaire

Méthodologie ATLAS

10 étapes, 9 principes, parité prouvée.

Composition de la cellule

Une cellule spécialisée pour ce parcours de modernisation.

Plusieurs profils distincts, mobilisés sur la durée du programme. Reproduire cette cellule en interne est rarement réaliste — la pénurie des compétences legacy et la profondeur d'expertise ATLAS rendent l'externalisation structurellement plus rapide et moins risquée.

Durée

Définie au cadrage selon volume DataWindows et interface cible

Volume

Déterminé à l'issue du POC et du cadrage

Profils

Architecte PowerBuilder ↔ cible

Pont entre PowerScript/DataWindow et l'écosystème cible (.NET, Java, TypeScript), cartographie patterns, design API REST

Tech Lead langage cible

C# (.NET Core), Java (Spring Boot) ou TypeScript (Node.js), patterns de traduction PowerScript→cible, traçabilité ligne à ligne

Développeurs cible

Idéalement avec passé client-serveur (Delphi, VB.NET, C#) pour comprendre le modèle objet PowerBuilder ; formation cible si nécessaire

Développeur PowerBuilder senior

Connaissance métier accumulée, lecture du code legacy, lever les ambiguïtés d'interprétation en début de programme (essentiel)

UX designer & frontend

Refonte ergonomique web (React, Angular), responsive, accessibilité — uniquement si cible web (non requis pour WinForms)

DBA & migration data

Migration des bases SQL Anywhere, Sybase ASE, Oracle vers PostgreSQL ou SQL Server cloud, audit parité données

QA & parité fonctionnelle

Bench de tests de caractérisation, comparaison legacy/cible, validation des audits ATLAS

Questions fréquentes

Ce que les décideurs demandent sur ce parcours.

Quel langage cible pour migrer PowerBuilder ?+

Trois options principales. .NET Core : choix naturel si écosystème Microsoft dominant, syntaxe C# proche de PowerScript. TypeScript + React/Angular : cible web moderne, ouverture mobile, voir Delphi vers TypeScript pour les patterns. Java + Spring Boot : si SI Java dominant. PowerBuilder vers .NET reste le plus fréquent en pratique, notamment via Appeon PowerServer qui propose une transition assistée.

Combien coûte une migration PowerBuilder ?+

Le coût dépend de trois variables mesurées au cadrage : le nombre de DataWindows et leur complexité (une DataWindow porte à la fois le SQL, la mise en page et les règles de validation), le volume de logique métier dans les scripts PowerScript, et le choix de la cible entre frontend web et desktop. La cartographie exhaustive des DataWindows est faite dès l'Intake : c'est elle qui sert de base au chiffrage. Cadrage initial gratuit, de 30 minutes à 2 heures.

Access a-t-il déjà livré une migration PowerBuilder ?+

Non, pas à ce jour. Nous l'assumons explicitement plutôt que de présenter une capacité comme une réalisation. La méthodologie ATLAS s'applique néanmoins aux modernisations 4GL legacy avec un excellent fit — notre parcours Delphi en démontre l'application sur un langage très proche. Nous proposons un diagnostic PowerBuilder de 2 à 3 semaines sur votre code réel avant tout engagement, pour mesurer la productivité effective et calibrer un chiffrage de programme fiable.

Que deviennent les DataWindows complexes (sub-DataWindows, computed columns dynamiques) ?+

Chaque DataWindow est analysée individuellement en phase Discovery pour identifier sa complexité réelle. Les DataWindows simples (présentation tabulaire, validation basique) se migrent vers AG Grid ou Telerik en quelques heures par écran. Les DataWindows complexes (sub-DataWindows imbriquées, computed columns dynamiques, événements onChange en cascade) nécessitent un travail d'analyse approfondi pour identifier les patterns équivalents (composants imbriqués, formules réactives côté frontend, hooks API). L'effort moyen par DataWindow varie de 0,5 à 5 jours-homme selon la complexité — c'est pourquoi la cartographie exhaustive en phase E2 est non négociable.

Appeon PowerServer est-il une solution ou un palier ?+

Un palier utile, pas une solution finale. Appeon PowerServer permet d'exposer une application PowerBuilder existante en web (.NET ou JavaScript) sans réécriture complète, en encapsulant les DataWindows. Avantages : modernisation rapide, préservation du code métier PowerScript, moindre investissement initial. Inconvénients : dépendance éditeur unique, dette PowerBuilder préservée, coûts de licence Appeon, limites d'évolution. Notre position : Appeon PowerServer est utile comme palier temporaire pour exposer rapidement en web pendant un programme de migration complet vers .NET / Java / TypeScript — pas comme cible finale.

Comment ATLAS garantit la parité fonctionnelle sur PowerBuilder ?+

Quatre disciplines combinées. (1) Cartographie exhaustive des DataWindows dès la phase E2 Discovery (SQL sources, colonnes calculées, règles de validation, événements). (2) Tests de caractérisation écrits en amont sur le legacy PowerBuilder : la suite caractérise le comportement avant qu'on touche au code cible. (3) Runs parallèles PowerBuilder / cible sur jeux de données client avec comparaison automatique — objectif > 99 % d'équivalence sur les chemins critiques. (4) Registre interne de discordances classées selon une grille CRITIQUE / ADAPTATION / COSMÉTIQUE : chaque écart documenté, pondéré, arbitré et classé. Voir la méthodologie ATLAS complète.

Vous évaluez une modernisation PowerBuilder ?

Trois manières de démarrer — du diagnostic court au programme complet. Access n'a pas encore livré de migration PowerBuilder client : nous l'assumons explicitement et proposons un diagnostic 2-3 semaines sur votre code avant tout engagement de programme.

Diagnostic PowerBuilder (2-3 semaines) →Expertise Legacy to Cloud →Modèle Build-Operate-Transfer →

Réalisations