Français
Architecture d’entreprise · HCM

Remplacer PeopleSoft par Workday : intégrer plus de 200 systèmes d’entreprise

L’histoire d’une transformation HCM dans l’une des cinq grandes banques canadiennes — et de l’architecture d’intégration qui a permis de remplacer la plateforme de référence sans perturber la paie, la sécurité, les déclarations fiscales, l’identité ni aucun des plus de 200 autres systèmes connectés.

12 min de lecture Par SEYSO SERVICES INC

200+

Systèmes intégrés

Tier-1

Banque canadienne

API+File

Intégration hybride

0

Cycles de paie manqués

Pourquoi les transformations HCM échouent (et notre approche différente)

La plupart des transformations HCM n’échouent pas dans la couche HCM. Workday et SuccessFactors sont des plateformes matures — leurs fournisseurs maîtrisent leur métier. Elles échouent aux frontières, dans les intégrations. Le SIRH est la colonne vertébrale reliant paie, fiscalité, finances, sécurité, identité, annuaire, gouvernance, formation, performance, mobilité, déplacements, dépenses et de nombreux processus métier spécifiques. Remplacez cette colonne sans soigner ses connexions, et tout le corps se désarticule.

Lorsque nous avons repris le programme, l’inventaire révélait plus de 200 systèmes intégrés, principalement accumulés en dix ans de liaisons ponctuelles point à point vers la base PeopleSoft. Certaines étaient des extractions nocturnes de fichiers, d’autres des services SOAP en temps quasi réel ou des vues directes en lecture seule du schéma PeopleSoft. Quelques-unes — découvertes seulement lors d’investigations approfondies — étaient des procédures stockées non documentées.

Le problème architectural n’était pas « comment passer à Workday », mais « comment raccorder 200 intégrations à une nouvelle plateforme dotée d’un modèle d’API entièrement différent, dans un délai compté en trimestres, sans manquer une paie ».

La stratégie d’intégration à quatre couches

Nous avons classé chacune des plus de 200 intégrations dans l’un de quatre modèles et défini une architecture cible pour chacun. La majeure partie du programme s’est ensuite déroulée de façon balisée.

  1. Intégrations API en temps réel. Les systèmes d’identité, de sécurité et d’annuaire consomment les événements Workday par services web REST/SOAP. Les nouvelles embauches parviennent à Active Directory, aux systèmes d’habilitation et aux flux de revue des accès en quelques minutes.
  2. Lots basés sur des fichiers. La paie, les déclarations fiscales, l’administration des retraites et de nombreux systèmes historiques consomment des extractions planifiées. Nous avons standardisé un modèle unique de fichier sortant avec un versionnage strict, afin que les changements futurs des consommateurs ne se répercutent pas sur tout le parc.
  3. Passerelles middleware. Quelques systèmes attendaient l’ancien contrat PeopleSoft et ne pouvaient pas être modifiés dans nos délais. Nous les avons reliés via le middleware d’intégration d’entreprise, traduisant les données Workday dans l’ancien format pour laisser le consommateur inchangé.
  4. Retrait direct. Un nombre surprenant d’intégrations étaient inactives — créées des années auparavant, détenues par des équipes passées à autre chose et consommées par des systèmes retirés. Nous les avons désactivées. (Cela fait toujours gagner plus de temps que prévu.)

La façade API Workday

Workday offre de nombreuses API, mais impose ses conventions. Il expose des services SOAP basés sur WSDL pour presque tout, ainsi que des points d’accès REST modernes pour les fonctions récentes. La bonne approche est de les encapsuler — jamais d’exposer Workday directement aux consommateurs internes.

Nous avons créé une fine façade d’intégration devant Workday : un catalogue interne de services REST traduisant le vocabulaire métier de la banque (employé, rôle, centre de coûts, responsable) en objets natifs Workday. Cette façade héberge authentification, autorisation, limitation de débit, nouvelles tentatives, idempotence et audit. Les consommateurs n’ont pas à apprendre Workday — et si Workday introduit une rupture de compatibilité, seule la façade change.

Pour les lectures volumineuses (organigrammes, correspondances de rôles, parcours hiérarchiques), nous répliquons les données Workday dans un stockage de lecture actualisé par les EIB sortants Workday et les abonnements aux événements. Les consommateurs par lots interrogent la copie ; le tenant Workday actif n’est pas surchargé.

Authentification unique et mobile, réalisés une seule fois

Deux initiatives transversales faisaient partie du programme, car les reporter aurait doublé leur coût.

La première était le SSO sur l’ensemble de Workday . Fédération SAML du fournisseur d’identité de la banque vers Workday sur ordinateur et mobile, associée à un accès conditionnel selon le risque de session. Une connexion pour les utilisateurs ; contrôle centralisé des sessions et piste d’audit claire pour la sécurité.

La seconde était le mobile via AirWatch (désormais Workspace ONE) comme EMM. Workday Mobile est déployé via AirWatch avec contrôles de politique — interdiction de copier-coller des données sensibles, accès conditionnel, effacement à distance des appareils perdus. Le déployer avec la bascule HCM a évité de reprendre le mobile après la mise en service.

Bascule : progressive, parallèle, réversible

Pour un système pilotant la paie et les déclarations fiscales, une bascule globale n’est pas envisageable. Nous avons fonctionné en parallèle pendant un cycle de paie complet : PeopleSoft et Workday produisaient leurs résultats simultanément, la façade d’intégration alimentait l’aval depuis PeopleSoft (alors système de référence) et un moteur de rapprochement comparait chaque enregistrement entre les deux SIRH. Les écarts étaient triés quotidiennement.

La bascule s’est faite domaine par domaine : d’abord les RH de base, puis la rémunération, le suivi du temps et enfin les talents. Pour chacun, le système de référence ne changeait qu’après une exécution parallèle sans anomalie. Le retour arrière était scripté — aucune phase ne commençait sans issue testée.

Ce qu’une entreprise peut en retenir

  • L’inventaire avant l’architecture. Les six premières semaines ont servi à découvrir toutes les intégrations — lectures de schémas, tâches planifiées, procédures non documentées. Sautez cette étape et vous découvrirez les surprises pendant la bascule.
  • Encapsulez le SaaS. Ne laissez jamais les consommateurs internes se coupler directement aux WSDL Workday. La fine façade d’intégration est l’élément le plus précieux que nous avons construit.
  • Des répliques de lecture pour les gros consommateurs. Les tenants Workday supportent mal les sollicitations massives de données organisationnelles. Répliquez, puis lisez.
  • Échelonnez la bascule. Domaine par domaine, avec exécution parallèle et rapprochement — pas tout à la fois.
  • Intégrez SSO et mobile en cours de programme. Les réaliser avec la bascule coûte beaucoup moins cher que les ajouter après.

Vous entreprenez cela dans votre entreprise ?

SEYSO a conçu et dirigé des migrations HCM, ERP et SaaS dans de grandes banques et entreprises. Si vous planifiez une bascule majeure vers Workday, SuccessFactors ou un autre SaaS avec de nombreuses intégrations historiques, parlons-en. La cartographie des intégrations constitue toujours l’essentiel du travail — et c’est notre spécialité.

Vous prévoyez une migration SaaS majeure ?

Échangez avec des architectes qui ont dirigé des transformations Workday HCM dans de grandes banques.