Comment réussir vos projets Oracle HCM Cloud avec Redwood et Visual Builder Studio (VBS) ?

Dans l’écosystème Oracle HCM Cloud, Redwood modernise l’expérience utilisateur et fait évoluer la manière de personnaliser les interfaces. Pour adapter cette nouvelle expérience aux besoins de chaque entreprise, Oracle met à disposition Visual Builder Studio (VBS), sa plateforme de développement et d’extension.

Pour les entreprises, cela soulève des questions très concrètes : comment adapter les processus existants, faut-il revoir l’organisation interne, et comment sécuriser les déploiements ?

Abderrahmane LAFTISSI, consultant Oracle HCM chez SQORUS, partage ce qu’il observe sur le terrain et ses conseils pour maîtriser Redwood et VBS.

Qu’est-ce qui change avec Redwood et VBS dans la façon de personnaliser Oracle HCM ?

Redwood et VBS sont deux notions distinctes. Redwood, c’est la nouvelle expérience utilisateur commune aux applications Oracle Fusion : des écrans modernes, épurés et intuitifs, pensés pour simplifier le quotidien des collaborateurs, des managers et des équipes RH.

Visual Builder Studio vient en complément. C’est l’outil qui permet d’adapter cette expérience à chaque entreprise. Il sert à faire évoluer les pages Redwood existantes (ajouter une règle de gestion, proposer une valeur par défaut, rendre un champ obligatoire ou le masquer) et, quand le besoin le justifie, à créer de nouvelles expériences. Cela va du réglage simple au développement plus poussé.

Ce nouveau modèle demande de nouvelles compétences. Les équipes doivent maîtriser la gestion de versions avec Git, le travail en branches (locales et distantes) et les déploiements d’un environnement à l’autre.

Concrètement, quelles sont les étapes clés pour configurer et initialiser un projet VBS ?

Un projet VBS ne se lance pas en quelques clics. Il faut le créer, le rattacher aux environnements Oracle HCM et l’organiser avec méthode, pour éviter les conflits. La démarche repose sur cinq étapes clés.

• L’audit de l’existant : la première étape consiste à analyser ce qui existe déjà, avant toute configuration. Y a-t-il des projets VBS ? Des extensions de pages standards ou de nouvelles applications ? Quelles méthodes de travail ont été utilisées ? Les réponses indiquent s’il vaut mieux repartir d’un nouveau projet ou s’appuyer sur l’existant.
• Le cadrage client : cette étape permet de préciser avec le client l’usage de ses environnements, leurs versions, ses référents et ses développeurs, ainsi que le déroulement de ses mises en production.
• La définition du modèle opérationnel : c’est l’étape la plus importante. Qui développe, qui valide, qui publie ? Comment les développements passent-ils d’un environnement à l’autre ? Tout doit être clair avant d’aller plus loin.
• L’ouverture des accès et des rôles : les accès ne sont ouverts qu’une fois le cadre défini et validé.
• La communication : l’équipe projet se réunit pour présenter le modèle et l’organisation. La construction démarre à ce moment-là.

Comment arbitrez-vous entre les personnalisations simples et les développements avancés dans VBS ?

Le choix du niveau de personnalisation dépend avant tout du besoin. Les règles métier déclaratives permettent de répondre à de nombreux cas sans recourir à du développement spécifique : définir une valeur par défaut, masquer un champ, le rendre obligatoire ou ajouter un contrôle de cohérence. Ces solutions restent plus simples à maintenir et limitent les risques liés aux évolutions de la plateforme.

Le point de vigilance porte surtout sur les développements avancés : logique spécifique, code ou appels à des systèmes externes. Le mode avancé de VBS reprend les possibilités du mode Express et les complète. Ces développements peuvent être pertinents lorsque le besoin le justifie, mais ils nécessitent d’évaluer les risques de maintenance et les impacts potentiels des futures mises à jour. Le rôle de l’intégrateur est aussi d’anticiper ces risques et de prévoir des solutions de repli pour préserver la continuité des processus.

Quel est l’impact des mises à jour d’Oracle sur les extensions Redwood déployées via VBS, et comment sécuriser les tests de non-régression ?

Dans Oracle HCM Cloud, les mises à jour suivent un cycle trimestriel. C’est le fonctionnement normal du SaaS, qui nécessite d’anticiper les impacts sur les extensions.
Le modèle d’extension de VBS permet de mieux encadrer les personnalisations que certaines approches historiques. En s’appuyant sur les mécanismes prévus par Oracle, l’impact des évolutions de la plateforme peut être mieux maîtrisé. Les personnalisations spécifiques nécessitent une vigilance accrue et des tests adaptés.

Après chaque mise à jour de l’environnement de test, les équipes peuvent exécuter des scénarios ciblés pour vérifier que les personnalisations fonctionnent toujours comme prévu. L’automatisation facilite la répétition de ces contrôles à chaque cycle de mise à jour.

Quels sont les écueils que vous observez chez les clients abordant Redwood/VBS, et quelle démarche d’accompagnement préconisez-vous ?

Le premier écueil consiste à reproduire l’existant à l’identique : certaines entreprises activent la nouvelle interface et y reportent leurs anciennes personnalisations. Elles passent alors à côté de ce que Redwood apporte : une expérience utilisateur repensée. C’est pourtant l’occasion de revoir les parcours RH, de les simplifier et de faire de l’outil un allié du quotidien plutôt qu’une contrainte.

Le deuxième écueil consiste à démarrer sans modèle opérationnel clairement défini. Sans règles précises, plusieurs personnes peuvent intervenir sur une même page, écraser mutuellement leurs modifications ou déployer des changements en production sans validation préalable. Résultat : des conflits, de la frustration et une perte de temps importante.

Pour éviter ces écueils et faire de Redwood un levier de transformation, un accompagnement structuré est nécessaire. Il porte à la fois sur les compétences techniques, notamment la gestion des versions et des branches, et sur l’organisation des équipes, côté intégrateur comme côté client. La rigueur investie au démarrage se retrouve ensuite dans la maintenabilité, et laisse aux équipes le temps de se concentrer sur la valeur apportée aux utilisateurs.

FAQ