Vos Oracle Forms contiennent déjà le guide de vos agents IA
Toute organisation qui veut confier une part de ses opérations à des agents IA se heurte à la même question : qu'est-ce qui empêche l'agent de faire ce qu'il ne devrait pas faire ? Pour les propriétaires d'applications Oracle Forms, l'essentiel de la réponse existe déjà. Il se trouve dans les déclencheurs et le PL/SQL de leurs formulaires, écrits et peaufinés depuis des décennies.
La vraie question, c'est de savoir si votre migration conserve ces règles ou si elle les laisse derrière, avec les anciens écrans.
Où vivent vraiment vos règles d'affaires
Demandez à une équipe Oracle Forms où se trouvent les règles d'affaires : elle vous montrera les paquetages de la base de données. La moitié de la réponse est là. L'autre moitié est dans les formulaires eux-mêmes :
- des déclencheurs WHEN-VALIDATE-ITEM qui refusent une date hors de la période ouverte;
- des déclencheurs PRE-INSERT qui dérivent une valeur que l'utilisateur ne saisit jamais;
- des déclencheurs KEY-COMMIT qui appellent un paquetage dans un ordre précis;
- des propriétés qui rendent un élément non modifiable une fois l'enregistrement comptabilisé.
Une grande application en contient des milliers, écrits sur vingt ans par des gens aujourd'hui à la retraite. Personne n'en a la liste complète. Ensemble, ces règles décident de ce qu'est une transaction valide, de qui peut modifier quoi et du moment où une écriture est refusée.
C'est précisément ce dont un agent IA a besoin pour qu'on lui fasse confiance dans un système transactionnel. Vos formulaires contiennent déjà son guide.
Pourquoi une réécriture perd les règles dont l'agent a besoin
Toute réécriture, manuelle ou par une IA qui génère du code, part d'une spécification. Cette spécification est rédigée à partir des écrans et des flux de travail évidents. Les règles sont découvertes plus tard, un incident à la fois.
Prenons un formulaire qui refuse une date de comptabilisation hors de la période comptable ouverte. La réécriture reproduit l'écran, la liste de valeurs et la sauvegarde, mais pas le déclencheur, parce que personne ne l'a demandé.
- Avec une personne au clavier, l'erreur apparaît à la fin du mois et elle est corrigée.
- Avec un agent qui passe des centaines d'écritures par jour, la même lacune produit des centaines d'écritures dans une période fermée avant que quiconque y jette un œil.
La règle dont l'agent avait le plus besoin est justement celle que la réécriture a laissé tomber. Garder les anciens écrans et ajouter un assistant IA à côté ne règle pas le problème non plus : l'assistant aide l'opérateur à saisir plus vite, mais il ne change pas qui fait le travail.
Migrer les règles, pas les écrans
ORMIT™-OpenJava ne réinterprète pas un formulaire. Il le migre. Chaque déclencheur, validation et procédure devient du TypeScript qu'OFCS (Oracle Forms Compatibility Service), le service de compatibilité Oracle Forms au cœur d'ORMIT™-OpenJava, exécute exactement là où Oracle Forms l'exécutait : dans le navigateur pendant que l'utilisateur travaille, et dans un serveur de validation Node.js, sans écran.
La conversion elle-même est déterministe. Elle repose sur l'arbre syntaxique abstrait du formulaire; elle n'est pas générée par un modèle. L'IA travaille autour, pour les tests et pour des réparations contrôlées, révisées par des personnes, jamais comme convertisseur.
En chiffres, OFCS reproduit 93 types de déclencheurs Oracle Forms, déclenchés au moment où Forms les déclenche. Il offre 232 fonctions intégrées au code migré et prend en charge 240 propriétés Oracle Forms. Chaque sauvegarde est validée deux fois : dans le navigateur, puis dans le serveur de validation avant la base de données. La logique des paquetages, les contraintes et les privilèges restent dans votre base Oracle, et OFCS est livré avec son code source.
Une règle, deux appelants : l'employé et l'agent
Voici ce qui compte pour les agents. Du point de vue du formulaire, un agent IA est un appelant de plus, sans écran. Le connecteur ouvert (MCP) est conçu pour que l'agent travaille le formulaire comme un employé : il lit les blocs et les éléments du formulaire, saisit des valeurs dans l'ordre de navigation pour que la validation de chaque élément s'exécute, appuie sur ses boutons, puis valide la transaction. Chacune de ces actions passe par OFCS.
Refuse une date de comptabilisation hors de la période comptable ouverte.
Appliquée avant la base Oracle, la même pour tous.
Quand un déclencheur refuse une saisie, l'agent reçoit le message du formulaire lui-même et s'arrête, comme un employé s'arrêterait devant le même message. Contourner l'écran ne permet pas de contourner les règles.
Sûr par construction, sous les mêmes règles que vos employés
Comme l'agent passe par les règles du formulaire, les contrôles découlent de la façon dont la migration est bâtie. Ce ne sont pas des consignes ajoutées à l'agent après coup :
- Aucun chemin à lui. L'agent n'atteint la base de données que par le connecteur et les règles du formulaire, jamais en les contournant.
- Une identité propre. Son propre compte de base de données, avec seulement les privilèges dont son processus a besoin, jamais les identifiants d'un employé.
- Une trace de chaque action. Chacune est journalisée avec la règle par laquelle elle est passée, l'agent qui l'a proposée et la personne qui l'a approuvée.
- Une personne approuve. L'agent prépare, un employé approuve : la séparation des tâches qu'attendent les vérificateurs reste en place.
Aucune capacité ne dépend de la justesse du modèle : le modèle propose, les règles décident, et une personne approuve. C'est important, car Gartner prévoit que plus de 40 % des projets d'IA agentique seront annulés d'ici la fin de 2027, en raison de coûts qui s'envolent, d'une valeur d'affaires floue et de contrôles des risques insuffisants (Gartner, 25 juin 2025). Les propriétaires d'Oracle Forms disposent déjà de ce contrôle : les règles de leurs formulaires.
Ce que ça change pour vous
- Vos formulaires sont un actif. Leurs déclencheurs et leur PL/SQL forment le guide dont un agent IA a besoin.
- Choisissez une migration qui garde les règles exécutables. Une réécriture faite à partir des écrans risque de perdre justement les règles dont les agents dépendent.
- Une seule migration pour les deux. L'application qu'utilisent vos employés est celle qu'exploite n'importe quel agent IA, le vôtre, celui d'un éditeur de plateforme ou celui de RENAPS, sans deuxième migration.
- Commencez par un processus. Choisissez-en un qui a du volume et des règles claires, faites d'abord travailler l'agent en observation et mesurez les résultats avant d'aller plus loin.
- Déjà migré avec ORMIT™-OpenJava ? Votre application tourne déjà sur OFCS, avec les mêmes règles. La première étape consiste à choisir un processus.
Notre livre blanc, D'Oracle Forms aux agents IA, va plus loin : le virage du marché en 2026, le piège de la réécriture, la façon dont OFCS garde les règles exécutables, l'offre en deux volets, les contrôles sûrs par construction et la première étape, avec une source pour chaque chiffre et chaque citation.
Télécharger le livre blanc D'Oracle Forms aux agents IA
Pour voir comment fonctionne la migration elle-même, consultez la page produit ORMIT™-OpenJava.
À suivre dans cette série : pourquoi les règles comptent plus que les écrans, comment un seul déclencheur devient un outil pour un agent, les garde-fous qui maintiennent l'agent dans les règles, une feuille de route concrète et les mythes les plus répandus sur Oracle Forms et les agents IA.