Architecte PowerBuilder ↔ cible
Pont entre PowerScript/DataWindow et l'écosystème cible (.NET, Java, TypeScript), cartographie patterns, design API REST
Loading...
Loading...
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.
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.
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).
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.
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.
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.
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.
Les outils de conversion automatique de code legacy produisent du code qui compile, mais qui reste illisible et non maintenable : les patterns d'origine sont recopiés tels quels, sans idiomatisation, avec des dépendances à une runtime propriétaire. Mis en production sans re-caractérisation complète, ce code n'est ni fiable ni évolutif. 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 legacy, menées selon plusieurs angles : flux de données, règles métier, dépendances, cas limites. L'IA intervient ici comme accélérateur de compréhension — pour déchiffrer des décennies 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 (cloud, base de données, services) et pilote la migration pattern par pattern, sous audit de parité.
Cette compréhension exige encore des humains qui connaissent les langages legacy. C'est notre avantage : là où l'Europe et l'Amérique du Nord font face à une vague de départs en retraite des développeurs mainframe et legacy, la Tunisie conserve un vivier de développeurs expérimentés (COBOL, Delphi, PowerBuilder, RPG…). Couplés à des architectes et développeurs modernes formés à la méthode ATLAS, ils assurent la continuité entre l'intention métier d'origine et le système cible.
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.
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.
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.
.NET Core 8 ou Java 21 ou TypeScript, PostgreSQL ou SQL Server, REST API, frontend SPA ou WinForms selon contexte
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é.
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#.
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.
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).
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.
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.
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.
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.
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.
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éé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.
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.
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.
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.
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.
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.
Pont entre PowerScript/DataWindow et l'écosystème cible (.NET, Java, TypeScript), cartographie patterns, design API REST
C# (.NET Core), Java (Spring Boot) ou TypeScript (Node.js), patterns de traduction PowerScript→cible, traçabilité ligne à ligne
Idéalement avec passé client-serveur (Delphi, VB.NET, C#) pour comprendre le modèle objet PowerBuilder ; formation cible si nécessaire
Connaissance métier accumulée, lecture du code legacy, lever les ambiguïtés d'interprétation en début de programme (essentiel)
Refonte ergonomique web (React, Angular), responsive, accessibilité — uniquement si cible web (non requis pour WinForms)
Migration des bases SQL Anywhere, Sybase ASE, Oracle vers PostgreSQL ou SQL Server cloud, audit parité données
Bench de tests de caractérisation, comparaison legacy/cible, validation des audits ATLAS
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.
Pour une application PowerBuilder de cinquante à cent cinquante DataWindows en co-delivery nearshore, comptez 800 k€ à 1,5 M€ sur 12 à 18 mois. Coût supérieur à Delphi sur volumes équivalents car les DataWindows sont plus complexes à porter (combinent SQL + UI + validation). Voir les modèles de delivery.
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.
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.
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.
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.
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.