Oracle Forms n’est pas « juste du code »

Les applications Oracle Forms sont de véritables écosystèmes où interface, logique et interactions de données sont étroitement imbriquées. Pour un œil non initié, cela peut ressembler à de simples écrans avec un peu de code. En réalité, c’est bien plus complexe :

• Types d’items : Oracle Forms (12c) prend en charge environ 40 types distincts d’items, chacun avec ses comportements et propriétés spécifiques.
• Types de triggers : Plus de 150 types de triggers, qui contrôlent tout, des frappes clavier à la navigation, en passant par les commits, validations et interactions utilisateur.
• APIs / Procédures intégrées (Built-ins) : Plus de 500 routines intégrées comme GO_BLOCK, EXECUTE_QUERY, COPY_VALUE, chacune ayant un rôle précis dans le comportement de l’application.
• Attributs & Propriétés : Chaque item peut avoir 50 à 70 attributs ou propriétés, dont la configuration influence directement la logique métier et les flux de travail.

Multipliez cela par des centaines ou milliers de Forms, et vous obtenez un paysage applicatif où la logique métier est profondément encodée dans des milliers de micro-comportements.

Ajoutez à cela le modèle transactionnel (logique de commit/rollback, relations maître-détail, édition multi-enregistrements), et vous réalisez qu’Oracle Forms n’est pas qu’un simple framework. C’est une plateforme opérationnelle contenant des décennies de savoir-faire métier.

C’est pourquoi les tentatives de migration avec des IA génériques échouent rapidement : il ne s’agit pas seulement de générer du code, mais de transporter l’ensemble de ces règles interconnectées sans les casser.

Le rôle des assistants de codage IA

Les outils d’IA agentiques comme Codex, Jules, Claude ou Devin sont puissants en soi. Ils peuvent :

• Générer ou refactoriser du code React/Angular.
• Suggérer des tests unitaires.
• Accélérer le « dernier kilomètre » de polissage du code.

Mais voici le problème : ils ne comprennent pas Oracle Forms.

• Aucun parsing natif des artefacts Forms (.fmb, .mmb, .pll, .olb).
• Aucune connaissance des built-ins ni des triggers et de leurs interopérabilités.
• Aucun modèle transactionnel intégré.

Pour démarrer, il faudrait extraire, aplatir et réécrire toute la logique métier à la main :

• Les analystes devraient mapper manuellement les triggers vers des événements UI ou services équivalents.
• Les développeurs devraient réécrire les built-ins dans des constructions spécifiques aux frameworks.
• Les équipes devraient reconstruire les flux métier de zéro.

Ce qui ressemble à de « l’automatisation IA » devient rapidement une réingénierie manuelle à grande échelle.

L’ampleur du problème

Prenons un portefeuille Oracle Forms de taille moyenne :

• 600 Forms
• 1 600 triggers
• 40 bibliothèques PLL
• 10 000 appels de built-ins
• 20 000+ attributs et propriétés

Avec une approche IA, chacun de ces éléments doit être :

1. Extrait
2. Interprété
3. Réécrit en logique React/Angular + backend
4. Validé manuellement (individuellement et dans ses interdépendances)

Cette approche est non seulement chronophage, mais elle introduit un risque d’erreur énorme. Même de petites erreurs d’interprétation peuvent provoquer des interruptions opérationnelles, des incohérences de logique métier, une non-conformité réglementaire ou des problèmes d’intégrité des données.

Comment ORMIT™-OpenJava relève ces défis

Des outils spécialisés comme ORMIT™-OpenJava (OOJ) de RENAPS combinent des accélérateurs IA avec des règles déterministes adaptées aux migrations Oracle Forms. OOJ automatise la conversion vers des backends Java avec des frontends React/Angular, en préservant triggers, built-ins, propriétés et sémantique transactionnelle.

Dans un cas concret avec un assureur européen, OOJ a atteint 99 % de préservation de la logique métier, réduit de 30 % le temps de traitement des sinistres, et diminué de 40 % les coûts de licences, tout en permettant l’évolutivité et en réduisant la dépendance fournisseur.

Là où un assistant IA générique est non déterministe, OOJ offre :

• Une prise en charge complète des triggers, built-ins et propriétés.
• La préservation de la logique métier dans une couche de services moderne.
• La génération de composants React avec validations, LOVs, flux maître-détail intégrés.
• La cohérence des commits/rollbacks et verrous Oracle.

En résumé, OOJ combine la vitesse de l’IA et la sécurité des règles déterministes, garantissant une migration fidèle, cohérente et optimisée pour un environnement open source.

Aspect	Assistants IA (Codex, Jules, Claude, Devin, etc.)	ORMIT™-OpenJava
Objectif principal	Outils généralistes de génération/refactorisation de code	Moteur spécialisé de migration Oracle Forms
Connaissance Oracle Forms	Non supportée	✅ Compréhension complète des artefacts Forms
Migration de logique métier	Réécriture manuelle des triggers/built-ins	✅ Extraction et préservation automatisées
Migration UI	Besoin d’une base manuelle, IA peut « polir »	✅ Génération UI React/Angular avec logique Forms préservée
Modèle transactionnel	Non pris en charge nativement	✅ Préservation de la sémantique transactionnelle Oracle
Scalabilité	Adapté aux prototypes ou petits périmètres	✅ Industrialisé pour 100s–1000s de Forms
Automatisation des tests	Peut générer des tests à partir de patterns	✅ Plans de tests générés et alignés sur les objets migrés
Gouvernance	Non déterministe, résultats variables	✅ Déterministe, reproductible et gouverné

Où l’IA reste utile

Il est important de souligner que ORMIT™-OpenJava ne produit pas un code “brouillon”. Bien au contraire : la migration génère un code React/Angular de haute qualité, maintenable, et prêt pour les 20 prochaines années.

Là où les assistants IA peuvent exceller, c’est après la migration, pour l’évolution et l’innovation :

• Ajout de nouvelles fonctionnalités sur la base migrée.
• Exploration d’améliorations UX ou de raffinements de design.
• Accélération du développement de nouveaux modules, API ou workflows.
• Génération de tests ou scripts supplémentaires pour l’amélioration continue.

En d’autres termes, l’IA est idéale pour les nouvelles évolutions fonctionnelles, pas pour la migration du cœur de la logique Oracle Forms.

Cette approche hybride — outil spécialisé pour la migration, IA pour les évolutions — offre le meilleur des deux mondes :

• Faible risque et préservation totale de la logique métier avec OOJ.
• Agilité élevée pour les innovations futures avec l’IA.

Avancer avec confiance

Migrer Oracle Forms ne consiste pas seulement à déplacer du code. Il s’agit de garantir que vos règles métier, workflows et intégrité des données restent intacts dans un environnement moderne et open source.

Les assistants IA généralistes peuvent être utiles pour l’expérimentation et l’innovation. Mais pour préserver des décennies de logique métier encodée, ils ne suffisent pas. C’est là que les outils spécialisés font toute la différence.

Avec ORMIT™-OpenJava, les organisations peuvent aborder la migration avec confiance :

• La logique métier est préservée, pas réinventée.
• Le code généré est pérenne et maintenable, prêt pour les 20 prochaines années.
• Le processus de migration est accéléré et maîtrisé, réduisant risques et incertitudes.

Pour beaucoup d’organisations, l’approche la plus efficace est hybride : utiliser des outils spécialisés pour le gros du travail, et tirer parti de l’IA pour les nouvelles fonctionnalités et évolutions futures. Cette combinaison réduit les risques tout en offrant l’agilité nécessaire pour l’avenir.

👉 Si votre organisation évalue la modernisation de ses Oracle Forms, parlons-en. Nous avons déjà aidé de nombreuses entreprises à réduire les risques et à accélérer leur passage de Forms vers React/Angular.