ORMIT™-OpenJava · Agents IA

D’Oracle Forms aux agents IA. Migrer les règles, pas les écrans.

ORMIT™-OpenJava migre vos formulaires Oracle Forms vers React ou Angular et garde exécutables chaque déclencheur, chaque validation et chaque procédure. Vos employés travaillent dans les nouveaux écrans, et n’importe quel agent IA exploite la même application, sous les mêmes règles, par un connecteur ouvert.

Télécharger le livre blanc Voir comment ça fonctionne

93 types de déclencheurs Oracle Forms
232 fonctions intégrées
Chaque sauvegarde validée deux fois

2026 : l’année où le marché a réévalué le logiciel

Les agents font sortir le travail de l’écran.

Le logiciel d’entreprise se vend par utilisateur, et un agent qui exécute un processus n’occupe aucune licence. Début 2026, les investisseurs en ont tiré les conséquences. Puis le marché a tranché : le logiciel sans agents est réévalué à la baisse, celui qui les intègre garde sa valeur.

−25 %

Indice S&P Software & Services, du 12 janvier au 23 février 2026

285 G$

Valeur boursière effacée en une seule séance, après la sortie des modules d’agents

+41 %

Le même indice, de son creux du 13 avril au 12 octobre 2026, revenu à ses sommets de l’année

Sources : The Batch (DeepLearning.AI), 27 février 2026; CNBC, 3 septembre 2026; 24/7 Wall St., 13 octobre 2026.

40 %

des applications d’entreprise intégreront des agents IA spécialisés par tâche d’ici la fin de 2026

Contre moins de 5 % en 2025.

2025 : moins de 5 %Fin 2026 : 40 %

Source : Gartner, 26 août 2025.

>40 %

des projets d’IA agentique seront annulés d’ici la fin de 2027

Coûts qui s’envolent
Valeur d’affaires floue
Contrôle des risques insuffisant

Les organisations qui exploitent Oracle Forms ont déjà ce contrôle : les règles de leurs formulaires.

Source : Gartner, 25 juin 2025.

L’IA de demain est un bureaucrate

Comme les poissons vivent dans les océans et les singes dans les forêts, les IA vivent dans les bureaucraties.

Yuval Noah Harari, Tanner Lecture on Human Values, Université d’Oxford, 2026 (traduction RENAPS)

Ce n’est pas un outil entre nos mains. C’est un agent qui a ses propres mains.

Yuval Noah Harari, même conférence (traduction RENAPS)

Les bureaucraties qui tournent sur Oracle Forms

Une bureaucratie, c’est tout système qui permet à des inconnus de se faire confiance à grande échelle : une banque, un assureur, la facturation d’un hôpital, les permis d’un ministère, une paie. Depuis trois décennies, une grande partie de ces systèmes sont bâtis sur Oracle Forms : un déclencheur sur chaque événement, une validation sur chaque champ, une procédure derrière chaque bouton.

Le prêt sur lequel il statueWHEN-VALIDATE-RECORD
La réclamation qu’il règleWHEN-VALIDATE-RECORD
La facture qu’il comptabiliseWHEN-VALIDATE-RECORD
Le congé qu’il approuveWHEN-VALIDATE-RECORD

Le bureaucrate IA n’arrivera pas dans un nouveau système. Il arrive dans le vôtre. Il n’est accepté que s’il obéit aux règles, et les organisations qui exploitent Oracle Forms les ont déjà. Toute la question est de savoir si la migration les conserve.

Le piège de la réécriture

Une réécriture reproduit l’écran. Les règles se perdent en chemin.

Demandez à une équipe Oracle Forms où se trouvent les règles d’affaires, et 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, écrite sur vingt ans, et personne n’en a la liste complète.

Ce que voit la spécification

Toute réécriture, à la main ou par une IA qui génère du code, part d’une spécification rédigée à partir des écrans.

L’écran
La liste de valeurs
La sauvegarde
Le déclencheur que personne n’a demandé

Ce qu’applique le formulaire

Derrière le même écran :

WHEN-VALIDATE-ITEMrefuse une date de comptabilisation hors de la période comptable ouverte
PRE-INSERTdérive une valeur que l’utilisateur ne saisit jamais
KEY-COMMITappelle un paquetage dans un ordre précis
Propriété d’élémentrend un élément non modifiable une fois l’écriture comptabilisée

Une règle perdue, et ce qu’elle coûte avec un agent

Un formulaire 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

L’erreur apparaît à la fin du mois, et elle est corrigée.

Avec un agent Illustration

Des centaines d’écritures par jour : la même lacune produit des centaines d’écritures dans une période fermée avant que quiconque s’en aperçoive.

VoieCe que deviennent les règles

Réécriture, à la main ou par IARedécouvertes plus tard, un incident à la fois.

Un assistant grefféIntactes, mais le travail reste manuel : l’assistant aide à saisir plus vite, il ne change pas qui fait le travail.

Oracle APEX 26.1 : formulaires analysés en spécification, puis reconstruitsLes déclencheurs deviennent de la documentation, et les outils de l’agent sont du code nouveau.

ORMIT™-OpenJavaChaque déclencheur, validation et procédure devient du TypeScript qu’OFCS exécute exactement là où Oracle Forms l’exécutait, pour l’employé comme pour l’agent.

Sources : Oracle, mai 2026, Announcing Oracle APEX 26.1 General Availability; Oracle, 1er octobre 2026, Modernization Forms to APEX Skill.

Migrer les règles, pas les écrans

L’agent et l’employé passent par les mêmes règles.

OFCS (Oracle Forms Compatibility Service), au cœur d’ORMIT™-OpenJava, exécute en TypeScript les règles d’un formulaire migré : dans le navigateur pendant que l’utilisateur travaille, et dans un serveur de validation Node.js, sans écran. Pour le formulaire, un agent IA n’est qu’un appelant de plus, sans écran.

Un employé enregistre une écriture valide depuis l’écran Web.
OFCS exécute les règles du formulaire, et la base de données reçoit la sauvegarde.
Un agent tente une écriture que le formulaire interdit, par le connecteur.
Le formulaire refuse. L’agent reçoit le message du formulaire lui-même et s’arrête.

Un refus du formulaire arrête l’agent comme il arrêterait un employé.

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é.
Chaque sauvegarde validée deux fois
Dans le navigateur pendant que l’utilisateur travaille, puis dans le serveur de validation avant la base de données. Contourner l’écran ne permet pas de contourner les règles.

OFCS en chiffres

Le moteur qui garde vos règles exécutables.

OFCS reproduit le comportement d’Oracle Forms là où le formulaire l’attend, et il est livré avec son code source.

93
types de déclencheurs Oracle Forms
Reproduits par OFCS, déclenchés au moment où Forms les déclenche.
232
fonctions intégrées d’Oracle Forms
Offertes au code migré.
240
propriétés Oracle Forms
Prises en charge par OFCS.
2×
validations de chaque sauvegarde
Dans le navigateur, puis sur le serveur avant la base de données.

Prouvé par des tests

Les tests de bout en bout sont rédigés à partir du PL/SQL d’origine, et conservés seulement s’ils échouent sur une copie volontairement brisée du formulaire.

3 906tests automatisés d’OFCS
2 369tests du backend Java
303scénarios de bout en bout, exécutés sur React et Angular

Navigateur ✓→Serveur de validation Node.js ✓→BD Oracle

Une conversion déterministeLa conversion repose sur l’arbre syntaxique abstrait du formulaire; elle n’est pas générée par un modèle. L’IA travaille autour : les tests, et des réparations contrôlées, révisées par des personnes.
Livré avec le code sourceOFCS est livré avec son code source, sous une licence qui n’expire pas.
Votre base Oracle reste en placeLa logique des paquetages, les contraintes et les privilèges restent dans Oracle. Chaque écriture s’exécute sous l’identité Oracle de son appelant.

La même migration, deux produits de plus

L’application que vous migrez est celle qu’exploitent les agents.

La migration livre des écrans pour vos employés. La même application, avec les mêmes règles, est celle qu’un agent IA exploite par un connecteur ouvert. Sans seconde migration.

1L’application devient opérable

Un connecteur ouvert (MCP), ou les mêmes opérations en ligne de commande ou par une simple API, avec une identité propre à l’agent et un journal de chaque action.

2L’agent fait le travail

Processus par processus, un agent propose, et vos employés supervisent et approuvent, sur l’application que vous avez déjà.

L’offre

Une application que tout agent peut exploiter.

Une migration vers les agents ne remplace pas un écran par une fenêtre de clavardage. Elle change ce que vous achetez, en deux volets, sur une seule source de règles.

1Volet 1
Prêt pour les agents

Livré avec la migration, ou ajouté à celle-ci. Un connecteur ouvert expose le formulaire migré à un agent : ses blocs, ses éléments, ses listes de valeurs et ses boutons, dans l’ordre propre au formulaire. Chaque appel passe par OFCS et par les règles du formulaire.

Quel agent
N’importe lequel : le vôtre, celui d’un éditeur de plateforme, celui d’Oracle ou celui de RENAPS.

Identité
Celle de l’agent, avec seulement les privilèges de base de données dont son processus a besoin. Chaque action est consignée avec la règle par laquelle elle est passée.

Comment c’est prouvé
Testé comme le reste de la migration : le test du refus, l’identité, le journal. Aucun modèle n’a besoin d’avoir raison.
- MCP
- Ligne de commande
- API simple
- Identité propre
- Journal des actions
2Volet 2
Processus confiés à un agent

Un processus à la fois, un agent prend le travail en charge sous supervision : il propose, un employé approuve, les règles s’appliquent. Vous choisissez l’agent et le modèle, et vous fixez le rythme.

Quel agent
Celui de RENAPS, ou celui choisi au volet 1.

Qui décide
Vos employés approuvent avant que quoi que ce soit ne compte.

Comment c’est mesuré
La précision sur les cas ambigus, le coût et le temps par exécution, et la part des cas qui n’ont plus besoin d’une personne.
- D’abord en observation
- Approbation humaine
- Coût mesuré

Trois façons d’exécuter un processus

Déplacer un cas change qui agit, jamais ce qui est permis.

Un programme, un agent IA ou une personne à l’écran : les trois passent par les mêmes règles OFCS.

Un programme
Pour quels cas
Les chemins qui n’exigent aucun jugement : les lignes qu’une règle peut rapprocher seule, les écritures dont chaque champ est connu.
Qui approuve
Personne, comme aujourd’hui. Les règles s’appliquent.
Un agent IA
Pour quels cas
Les cas ambigus : un paiement qui correspond presque, une réclamation à laquelle il manque un document, une demande qui exige une décision dans le cadre des règles.
Qui approuve
Un employé, qui voit ce que l’agent propose et pourquoi.
Une personne à l’écran
Pour quels cas
Là où un écran sert encore : la saisie au clavier à haut volume, et les exceptions que l’agent ne peut pas régler.
Qui approuve
Comme aujourd’hui.

OFCSLes mêmes règles sous les trois

Les règles disent ce que le formulaire refuse. Elles ne disent pas quel rapprochement est le bon quand plusieurs sont valides : c’est la colonne de l’agent, et c’est pourquoi l’approbation n’est pas facultative.

Un exemple concret

Le rapprochement bancaire, avec un agent dans la boucle.

Un formulaire présent dans la plupart des services financiers. L’application migrée garde ses règles : quelles lignes peuvent être rapprochées automatiquement, quels comptes une écriture peut toucher, ce qui rend un rapprochement complet.

Les règlesrapprochent les lignes qu’elles reconnaissent, comme elles le font déjà.
L’agentpropose un rapprochement pour les autres lignes, avec son raisonnement.
L’employéapprouve ou corrige chaque proposition.
La comptabilisationpasse par les déclencheurs de commit du formulaire : ce que le formulaire refusait reste refusé.

La journée de l’employé passe de la saisie de chaque ligne au règlement des exceptions.

Relevé bancaire · rapprochementIllustration

Règlement de cartes2 480,00Rapproché par une règle✓ Comptabilisé
Paiement fournisseur, virement12 300,00Rapproché par une règle✓ Comptabilisé
Chèque 104821 150,00Agent : facture INV-2291même montant, même bénéficiaireApprouvé✓ Comptabilisé
Virement, paiement partiel7 940,00Agent : 2 postes ouvertsle total correspondCorrigé par l’employé✓ Comptabilisé
Frais bancaires35,00Rapproché par une règle✓ Comptabilisé
Dépôt sans référence3 000,00Agent : encaissement clientposte ouvert le plus procheApprouvé✗ Refusé par le formulaire : période fermée

Règles : 3 lignes · Propositions de l’agent : 3 lignesComptabilisées : 5 · Refusée par le formulaire : 1

Sûr par construction

Les contrôles découlent de la façon dont la migration est bâtie.

Ils ne sont pas ajoutés à l’agent après coup.

Identité et responsabilité
Son propre compte de base de données, seulement les privilèges dont son processus a besoin, jamais les identifiants d’un employé. L’agent prépare, un employé approuve : la séparation des tâches qu’attendent les vérificateurs. Chaque action 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 confiance progressive
L’organisation fixe le rythme, processus par processus.
1. 1Observation : propositions comparées au travail des employés
2. 2Chaque action approuvée
3. 3Seules les exceptions approuvées
Vos données, votre région, votre modèle
Avec Amazon Bedrock ou Google Cloud Vertex AI, les requêtes et les résultats restent dans votre compte infonuagique et votre région. Rien n’est envoyé à un service d’IA grand public, et le modèle peut être remplacé, y compris par un modèle ouvert exécuté sur votre propre infrastructure.
Un coût mesuré
Chaque action d’un agent a un coût. RENAPS ne le chiffre qu’une fois mesuré sur un vrai formulaire, par exécution, et vous décidez si vous payez l’IA sur votre propre compte infonuagique ou par l’abonnement.
Le test du refus
Quand l’agent tente ce que le formulaire interdit, la réponse est la même que pour une personne : le formulaire refuse, l’agent reçoit le message du formulaire, le signale, et ne le contourne pas.

La couche de contexte que demande Gartner

Un formulaire migré la contient déjà.

La plateforme de contexte d’IA de Gartner, quatrième de ses tendances stratégiques pour 2027, compte trois composantes. Les règles sont la seule qu’aucun éditeur de plateforme ne peut écrire pour vous : elles n’existent que dans vos formulaires.

Composante selon GartnerCe qu’elle contientDans une application migrée
SémantiqueOntologie, indicateurs, règles, responsabilités, politiques
Les règles : chaque déclencheur, validation et procédure du formulaire, en TypeScript qu’exécute OFCS. Pas une description des règles. Les règles elles-mêmes.
État opérationnelEntités, conditions de l’environnement, données au bon moment
Les blocs, éléments et listes de valeurs du formulaire, et les enregistrements vivants de votre base de données Oracle, lus par les requêtes qu’exécute le formulaire lui-même.
ProvenanceTraçabilité des données, des processus, des décisions, des actions et des résultats
Le journal des actions du volet Prêt pour les agents : pour chaque action, la règle par laquelle elle est passée, ce que l’agent a proposé et la personne qui l’a approuvée.

Gartner recommande de « séparer les règles d’affaires passives des traces de décision actives, générées par les machines ». Les règles sont du code qui ne change pas quand l’agent s’exécute; le raisonnement de l’agent est une trace conservée à côté, et il ne devient jamais une règle. OFCS alimente une plateforme de contexte; il ne la remplace pas.

Source : Gartner, 20 octobre 2026, Top 10 Strategic Technology Trends for 2027 (citation traduite par RENAPS).

La première étape

Commencer par un processus. Finir avec des chiffres.

La première étape, c’est la migration elle-même, puis le connecteur, puis un processus. Elle réutilise ce que produit déjà chaque migration RENAPS.

Migrer avec ORMIT™-OpenJava
vers React ou Angular, comme le prévoit déjà le projet de migration. C’est l’étape qui garde les règles exécutables.
Rendre l’application prête pour les agents
Le connecteur, l’identité propre de l’agent et le journal des actions. Testé, pas mesuré : le test du refus, l’identité, le journal, avec n’importe quel agent et n’importe quel modèle.
Choisir un processus
qui a du volume et des règles claires : un rapprochement, la réception des réclamations, l’analyse de permis.
Rédiger ses cas d’utilisation
dans le cahier de cas d’utilisation que RENAPS demande avant toute preuve de concept. Il devient la liste de tâches de l’agent.
L’exécuter en observation
L’agent exécute les cas sur les formulaires migrés, d’abord en observation. Les tests de bout en bout rédigés à partir du PL/SQL d’origine notent chaque exécution.
Mesurer
la part des cas que l’agent règle, la part qu’il signale, le coût et le temps par exécution, et le temps que récupèrent vos équipes.
Décider
à quelle colonne appartient chaque cas : le programme, l’agent ou une personne à l’écran. Puis passer au processus suivant.

Questions

Ce que les clients demandent d’abord.

L’agent remplace-t-il mes employés?

Non. Il prend les cas que vos règles savent trancher et propose les autres. Vos employés passent de la saisie à la supervision et aux exceptions. La part du travail qui passe à l’agent se mesure processus par processus; elle n’est jamais promise d’avance.

Qu’est-ce qui empêche l’agent de faire une erreur coûteuse?

Les mêmes règles qui en empêchent vos employés : les déclencheurs, validations et procédures de vos formulaires, migrés en code exécutable par OFCS et appliqués avant la base de données. L’agent n’a pas de chemin à part vers la base, et il agit sous sa propre identité, avec les seuls droits de son processus, jamais ceux d’un employé. Un refus du formulaire l’arrête, et il rapporte le message du formulaire. Aucune capacité ne dépend de la justesse du modèle : le modèle propose, les règles décident, et une personne approuve.

Qui est responsable d’une écriture préparée par l’agent?

La personne qui l’a approuvée, comme aujourd’hui. L’agent prépare, l’employé approuve : la séparation des tâches qu’attendent vos vérificateurs reste en place, et chaque action est journalisée avec la règle par laquelle elle est passée, l’agent qui l’a proposée sous sa propre identité, et l’approbateur.

Où vont nos données?

Dans votre compte infonuagique et votre région. Avec Amazon Bedrock ou Google Cloud Vertex AI, les requêtes et les résultats restent dans votre compte et votre région. Rien ne passe par un service d’IA grand public, et rien ne dépend d’un seul modèle : vos règles migrées sont votre code, le connecteur suit un protocole ouvert, et le modèle peut être remplacé, y compris par un modèle ouvert exécuté sur votre propre infrastructure.

Peut-on utiliser notre propre agent, ou celui d’un éditeur de plateforme?

Oui. C’est le premier volet de l’offre : le connecteur expose l’application migrée à n’importe quel agent, sous les mêmes règles, avec une identité propre à l’agent et un journal de chaque action. L’agent de RENAPS est une option, pas une condition.

Nous ne sommes pas prêts pour les agents. Faut-il quand même migrer maintenant?

Oui. Oracle Forms suit son propre calendrier de support : selon les dates publiées par Oracle, le Premier Support de Forms 12c va jusqu’en décembre 2026, et celui de Forms 14.1.2 jusqu’en 2030. La migration vers React ou Angular est la première étape, et c’est elle qui garde les règles exécutables. L’agent s’ajoute ensuite, processus par processus, sans seconde migration.

Nous avons déjà migré avec ORMIT™-OpenJava. Qu’est-ce que ça change pour nous?

Votre application fonctionne déjà avec OFCS et les mêmes règles. La première étape, c’est le choix d’un processus.

Couverture du livre blanc RENAPS D’Oracle Forms aux agents IA

Livre blanc · octobre 2026