Qu'a démontré l'expérience de deux semaines?

Le consultant Vaadin Jean-Christophe Gueriaud a utilisé Claude Code pour migrer la démo Summit d'Oracle vers Vaadin et Spring Boot. Le formulaire ORDERS contenait 183 éléments et 45 blocs de logique PL/SQL.

L'auteur décrit ouvertement les limites : PL/SQL simple, aucun paquetage à état ni SQL dynamique, et un processus de vérification plus rigoureux resté inachevé à la fin des deux semaines. Il rapporte également des omissions initiales et des changements délibérés au comportement de validation et de verrouillage. Lire l'expérience de Vaadin

C'est une exploration utile du développement assisté par IA. Le problème survient lorsque son titre accrocheur devient une hypothèse de planification pour une autre application, une autre portée et une autre norme d'acceptation.

« Deux semaines » nécessite une ligne d'arrivée définie. Est-ce un écran généré, une démonstration fonctionnelle, un flux d'affaires validé ou une mise en production? Ces jalons représentent des quantités de travail différentes.

Qu'est-ce qui détermine l'échéancier de migration Oracle Forms d'une entreprise?

Le nombre de formulaires est un point de départ. L'évaluation doit aussi établir comment ces formulaires interagissent et quels comportements l'entreprise exige.

Une application relativement petite peut être difficile à moderniser si ses flux dépendent fortement d'états partagés, de bibliothèques, de paquetages de base de données, d'intégrations externes et d'interactions utilisateur spécialisées.

Domaine	Ce que la migration doit établir
Validation et navigation	Les règles requises s'exécutent au bon moment, y compris lors des déplacements entre champs et enregistrements.
Transactions et concurrence	La sauvegarde, l'annulation et les mises à jour conflictuelles préservent le résultat d'affaires requis.
Flux inter-formulaires	Les paramètres, l'état partagé et les appels de bibliothèque se comportent correctement dans l'ensemble des flux.
Requêtes et relations maître-détail	La récupération, le filtrage et les opérations sur les enregistrements liés demeurent cohérents.
Intégrations	Les rapports, fichiers, services externes et l'authentification fonctionnent dans l'environnement cible.
Productivité des utilisateurs experts	Les raccourcis requis, les opérations de requête et les tâches répétitives demeurent efficaces.
Acceptation en production	La performance, la sécurité, le déploiement, la reprise et les tests d'affaires respectent les critères convenus.

 

Ce sont des catégories d'évaluation, non des affirmations selon lesquelles chaque application exige la même mise en œuvre.

L'échéancier dépend des comportements présents, de la couverture de l'approche de conversion, des exceptions nécessitant de l'ingénierie et de la capacité de l'organisation à valider le résultat.

Quand la simplification crée du travail ailleurs

Modifier le comportement d'une application peut être une décision de conception judicieuse. Mais elle doit être chiffrée et approuvée dans le cadre du projet.

Prenons un flux où les utilisateurs reçoivent actuellement une rétroaction de validation avant de quitter un champ. Déplacer cette rétroaction pour gagner du temps peut exiger des changements à la gestion des erreurs, aux calculs dépendants, aux instructions utilisateur et aux tests d'acceptation.

De même, modifier la gestion des transactions ou des sessions exige de revoir les flux qui dépendaient du comportement original.

La mise en œuvre initiale peut devenir plus simple pendant que le projet global gagne du travail supplémentaire.

Pour les utilisateurs experts, même une refonte techniquement correcte peut affecter le débit. Un écran de remplacement doit être évalué par rapport aux tâches que les utilisateurs effectuent de façon répétitive tout au long de la journée.

Une fonctionnalité retirée de la portée de conversion ne disparaît pas automatiquement de l'exigence d'affaires. Elle peut revenir sous forme de correction, de refonte, de travail d'intégration ou de formation. Une estimation crédible rend ce travail visible avant le début du projet.

Pourquoi un moteur de migration établi change l'échéancier

Préserver le comportement requis de Forms ne signifie pas que chaque client doit financer le développement d'un nouveau cadre de compatibilité.

Un moteur de conversion établi peut encoder les comportements pris en charge dans des règles de transformation réutilisables. L'effort d'ingénierie investi dans la compréhension et la mise en œuvre d'un modèle peut ensuite profiter aux migrations subséquentes.

RENAPS décrit cette approche dans son article précédent sur la migration Oracle Forms par IA par rapport à la conversion déterministe : ORMIT™-OpenJava applique des transformations prédéfinies aux constructions prises en charge, les tests d'application demeurant nécessaires.

La distinction est concrète. Les acheteurs devraient demander quels comportements la plateforme prend déjà en charge, comment cette couverture est démontrée, et ce qui se passe lorsque la source contient un modèle non pris en charge.

Le déterminisme seul ne prouve pas l'exactitude. Sa valeur vient de l'application constante de règles validées, d'une gestion explicite des exceptions et de preuves que les flux résultants répondent aux exigences.

L'IA peut tout de même contribuer à la mise en œuvre, à la documentation, au développement de tests et aux améliorations subséquentes. Son utilité doit être évaluée par rapport à l'effort total requis pour livrer une application acceptée.

Comment établir un échéancier crédible pour votre application

Avant d'accepter une estimation de migration, demandez cinq livrables concrets :

1. Un inventaire d'application : formulaires actifs, menus, bibliothèques, rapports, dépendances de base de données et intégrations.
2. Une évaluation de couverture : ce qui se convertit automatiquement, ce qui exige une adaptation et ce qui nécessite une enquête plus approfondie.
3. Une preuve de concept représentative : un flux d'affaires significatif avec des dépendances complexes.
4. Des critères d'acceptation explicites : le comportement requis, les changements permis et les preuves nécessaires à l'approbation.
5. Une estimation de livraison jusqu'à la production : conversion, correction, intégration, tests, acceptation utilisateur et déploiement.

Cela donne au projet une base de référence mesurable et facilite la comparaison des propositions des fournisseurs.

La leçon d'une expérience de deux semaines est que le développement assisté par IA mérite une évaluation sérieuse. La planification d'entreprise exige d'étendre cette évaluation à toute la portée de la livraison.

La mesure significative de la vitesse de migration est le temps requis pour obtenir une application acceptée en production.

Pour les organisations qui évaluent la modernisation d'Oracle Forms, une évaluation ORMIT™-Analyzer de RENAPS peut fournir le point de départ pour discuter de la portée de l'application, de la couverture de conversion et du travail nécessaire pour établir un plan de migration réaliste.