The analyst who didn’t change her title

A few weeks ago, I was talking with an HR business partner in a mid-sized organization. She was describing the situation of an HR analyst on her team: same title for three years, same salary band, same job description.

Except her work had changed.

Before GenAI, this analyst spent about 40% of her time compiling data, formatting reports, drafting first versions of policies, and preparing presentations for committees. Today, these tasks are cut in half: some disappear entirely, others accelerate. She now spends that recovered time validating AI outputs, formulating more precise prompts, contextualizing recommendations for managers, and acting as a bridge between raw data and human decision-making.

Her title: HR Analyst. Her job description: unchanged. Her actual work: profoundly different.

This gap between the administrative container (the job) and operational reality (the tasks) is at the heart of what GenAI produces in organizations. And it is this gap that makes the traditional job description insufficient as a unit for managing work. This phenomenon is well documented: Selenko et al. (2022) show that workers’ professional identity is tested precisely because the title does not change while the tasks transform profoundly.

The job: a useful but static administrative container

The job description is not an arbitrary invention. It was designed to meet real needs: pay equity, clarity of responsibilities, legal compliance, workforce planning. In a world where work changes slowly, it serves these purposes well.

But the job description is a container. It describes a set of responsibilities, required competencies, and performance expectations at a given point in time. It is, by construction, static. It is typically reviewed once every two or three years in most organizations. And it is written in terms of what the job demands, not in terms of what work actually entails day-to-day.

This model worked because work itself changed at a manageable pace. A financial analyst in 2010 did essentially the same work as in 2005. Tools changed (Excel, then BI tools), but the fundamental tasks remained relatively stable: collect data, analyze, synthesize, present.

GenAI breaks with this pace. Not because it invents a new type of work, but because it intervenes directly at the task level, with a speed and reach that traditional HR cycles cannot absorb.

The World Economic Forum makes this clear in the Future of Jobs Report: 39% of workers’ core competencies will change or become obsolete by 2030. And 63% of employers identify skills shortages as their primary obstacle to growth. These numbers do not speak to jobs disappearing. They speak to tasks shifting, competencies moving, work recomposing — often without the job title or description changing at all.

Where GenAI actually acts: the tasks

To understand GenAI’s impact, you have to look one level below. Not the job. The tasks.

A task is the elementary unit of work: writing an email, analyzing a dataset, preparing a presentation, conducting an interview, validating an invoice, responding to a support ticket. Jobs are aggregates of tasks. And it is these aggregates that HR systems have been built around.

But GenAI does not operate at the aggregate level. It operates at the task level. And depending on each task’s characteristics, its effect varies. Dell’Acqua et al. (2023)’s work on the “jagged technological frontier” illustrates this precisely: GenAI excels spectacularly at certain tasks and is counterproductive at others. The boundary between what the tool does well and what it does poorly is not straightforward.

We can distinguish at least three distinct effects.

Reduction. Some tasks are accelerated to the point where they cease to be significant time constraints. Drafting a first version, compiling data from multiple sources, reformatting documents, generating summaries: these tasks do not disappear, they compress. A task that took two hours now takes twenty minutes, with equivalent or better quality output.

Amplification. Other tasks see their scope expand. An HR analyst who could previously review ten candidate profiles per hour can now review fifty, provided they maintain quality judgment on each recommendation. Capacity increases, but responsibility for judgment remains intact. Brynjolfsson et al. (2023) document that this amplification effect is strongly differentiated by initial skill level: less experienced workers benefit more in relative terms, while experts retain advantages that GenAI does not fully compensate for.

Creation. GenAI generates new tasks that did not exist before. Formulating effective prompts. Validating AI outputs (which requires understanding what AI does and what it might miss). Detecting hallucinations in specialized business contexts. Governing tool use within the team. These new tasks require competencies that job descriptions have not yet named.

This triptych — reduction, amplification, creation — occurs in the same job, often in the same week. And it produces a phenomenon that research is beginning to document: an employee can see overall performance increase thanks to GenAI while experiencing increased cognitive load related to validating and supervising outputs. Shao et al. (2025), in a daily longitudinal study published in the Journal of Management, show this empirically: on any given day, the same employee can benefit from substantial cognitive gains from AI AND suffer from information overload that degrades post-work recovery. Both effects coexist, on the same person, at the same time.

Standard adoption metrics (usage rates, time saved, tickets resolved) do not capture this duality. They measure the gain. They do not measure the invisible cost.

Competencies become more unstable, more contextual, and more hybrid

If tasks change at the speed of GenAI, the competencies needed to accomplish them change too.

GenAI accelerates an already-underway phenomenon: competencies become less stable, more contextual, and more hybrid.

Less stable. The useful lifespan of a specific technical competency shortens. Mastering a specific software counted for a lot ten years ago. Today, what matters more is the ability to quickly learn a new tool, understand its limitations, and integrate it into an existing workflow. Gobeil-Proulx (2021) already identified this in the Quebec context: competencies that endure are AI literacy, ability to work in interdisciplinary teams, creativity and complex problem-solving — not fixed technical competencies.

More contextual. The same competency can have vastly different value depending on organizational context. The ability to formulate effective prompts is useful everywhere, but its specific value depends on available tools, business processes, sector, and an organization’s regulatory constraints. In Quebec in 2024–2025, only 12.7% of enterprises used AI for production purposes, according to Statistics Quebec. This low figure does not mean AI competencies are unimportant: it means their value is very unevenly distributed across sectors and organizational maturity. Mehdi and Morissette (2024) refine this reading by estimating, through econometric analysis of the Canadian labour market, differentiated exposure levels across professional categories, with results that strongly nuance global projections.

More hybrid. GenAI values hybrid profiles — a compensation specialist who understands the implications of AI compensation algorithms, or a learning leader who knows how to design human content AND evaluate what an LLM can or cannot do in that context. These profiles do not fit neatly into a job family box.

What this demands of HRIS: moving from profile to workflow

This is where HRIS start to break down.

HRIS have been built to manage profiles. An employee has a job. That job has required competencies. The employee declares or acquires those competencies. We measure the gap. We prescribe training.

This model assumes work is relatively stable, that you can describe it once and manage it thereafter. It also assumes competencies are relatively stable attributes of individuals: you either have them or you do not, and you accumulate them progressively.

What organizations need is not a better competency profile. It is a capacity to dynamically read real work: understand which tasks are actually being accomplished, how they evolve, what competencies emerge as critical, and how those competencies distribute across the organization.

That’s a different kind of goal. It requires data beyond self-reporting, taxonomies that capture semantic relationships between competencies rather than simply classifying them, and governance that allows maintaining this reading in real-time.

Some HRIS vendors are advancing in this direction. Workday Skills Cloud, with its 47,000+ standardized competencies (Workday, 2022) and self-learning ontological approach, is probably the most documented example. The principle is this: instead of asking employees to fill out their profile, the system infers their probable competencies by analyzing their projects, training, assessments, and internal movements. It maps semantic relationships between competencies, similarly to how human neural networks function: multidimensional relationships rather than rigid hierarchy.

But an ontology is not a strategy. And a Skills Cloud deployed without governance, without a culture of competency sharing, and without real connection to development and mobility decisions, remains a sophisticated cataloging tool — not a transformation lever.

This will be the subject of Part 2.

Skills-based organization: a possible answer, not magic

The concept of skills-based organization (SBO) is not new. It has been circulating in HR circles for over a decade. What changes with GenAI is its urgency.

The core pitch of SBO is simple: if competencies are the unit of value in modern work — more than degrees, more than titles, more than tenure — then all talent management logic should be organized around them. Internal mobility, development, acquisition, workforce planning: all pivot on competency rather than job.

The data is encouraging. According to a 2024 Deloitte report synthesized by HR Grapevine, SBO organizations outperform peers across every measured indicator: talent placement (+107%), anticipating change (+57%), innovation (+52%), achieving objectives (+63%), and positive employee experience (+79%).

What is clear, however, is that SBO is an architectural response to work volatility: a way to build the organization so it can adapt faster than its own job descriptions. Facing GenAI, this adaptability has obvious value.

What is less clear is what a true SBO strategy actually demands: reliable data infrastructure, governance of competency signals, organizational culture that values mobility over retention, and rigor in measurement that exceeds adoption dashboards. Most organizations thinking they are doing SBO are actually doing competency cataloging with a nice name.

What if a list of competencies is not enough?

This first part has set the diagnosis: GenAI is shifting work at the task level, precisely where HRIS and job descriptions fall short. The logical question follows — if competencies are becoming the relevant unit of management, why do so few organizations manage to turn that into a real strategy?

That’s what we’ll explore in Part 2: why so many organizations have a skills catalog but so few have an actual skills-based approach — and what separates a taxonomy from an ontology.

References

L’analyste qui n’a pas changé de titre

Il y a quelques semaines, je discutais avec une partenaire d’affaires RH dans une organisation de taille moyenne. Elle me décrivait la situation d’une analyste RH de son équipe : même titre depuis trois ans, même niveau salarial, même fiche de poste.

Sauf que son travail, lui, avait changé.

Avant la GenAI, cette analyste passait environ 40 % de son temps à compiler des données, formater des rapports, rédiger des premières versions de politiques, et préparer des présentations pour les comités. Aujourd’hui, ces tâches sont réduites de moitié : certaines disparaissent complètement, d’autres sont accélérées. Elle passe désormais ce temps récupéré à valider des outputs IA, à formuler des prompts plus précis, à contextualiser des recommandations pour les gestionnaires, et à jouer un rôle de pont entre les données brutes et la décision humaine.

Son titre : Analyste RH. Sa fiche de poste : inchangée. Son travail réel : profondément différent.

Ce décalage entre le contenant administratif (le poste) et la réalité opérationnelle (les tâches) est au cœur de ce que la GenAI produit dans les organisations. Et c’est ce décalage qui rend la fiche de poste traditionnelle insuffisante comme unité de gestion du travail. Ce phénomène est bien documenté : Selenko et al. (2022) montrent que l’identité professionnelle des travailleurs est mise à l’épreuve précisément parce que le titre ne change pas alors que les tâches, elles, se transforment profondément.

Le poste : un contenant administratif utile, mais figé

La fiche de poste n’est pas une invention arbitraire. Elle a été conçue pour répondre à des besoins réels : équité salariale, clarté des responsabilités, conformité légale, planification des effectifs. Dans un monde où le travail change lentement, elle remplit bien ce rôle.

Mais la fiche de poste est un contenant. Elle décrit un ensemble de responsabilités, de compétences requises et d’attentes de performance à un moment donné. Elle est, par construction, statique. Elle est révisée en moyenne une fois tous les deux ou trois ans dans la plupart des organisations. Et elle est rédigée en termes de ce que le poste demande, pas en termes de ce que le travail implique réellement au quotidien.

Ce modèle a fonctionné parce que le travail lui-même changeait à un rythme gérable. Un analyste financier en 2010 faisait essentiellement le même travail qu’en 2005. Les outils changeaient (Excel, puis des outils BI), mais les tâches fondamentales restaient relativement stables : collecter des données, analyser, synthétiser, présenter.

La GenAI rompt avec ce rythme. Pas parce qu’elle invente un nouveau type de travail, mais parce qu’elle intervient directement au niveau des tâches, avec une vitesse et une capillarité que les cycles RH traditionnels ne peuvent pas absorber.

Le Forum Économique Mondial l’estime clairement dans son Future of Jobs Report : 39 % des compétences fondamentales des travailleurs actuels changeront ou deviendront obsolètes d’ici 2030. Et 63 % des employeurs identifient la pénurie de compétences comme leur principal obstacle à la croissance. Ces chiffres ne parlent pas de postes qui disparaissent. Ils parlent de tâches qui basculent, de compétences qui se déplacent, de travail qui se recompose, souvent sans que le titre ou la fiche de poste ne bougent.

Où la GenAI agit réellement : les tâches

Pour comprendre l’impact de la GenAI, il faut regarder un niveau plus bas. Pas le poste. Les tâches.

Une tâche est l’unité élémentaire du travail : rédiger un courriel, analyser un jeu de données, préparer une présentation, conduire une entrevue, valider une facture, répondre à un ticket de support. Les postes sont des agrégats de tâches. Et c’est sur ces agrégats que les systèmes RH ont été construits.

Or la GenAI n’opère pas au niveau de l’agrégat. Elle opère au niveau de la tâche. Et selon les caractéristiques de chaque tâche, son effet varie. Les travaux de Dell’Acqua et al. (2023) sur la « frontière technologique irrégulière » illustrent précisément ce point : la GenAI excelle dans certaines tâches de façon spectaculaire, et est contre-productive dans d’autrese. La frontière entre ce que l’outil fait bien et ce qu’il fait mal n’est pas droite.

On peut distinguer au moins trois effets distincts.

Réduction. Certaines tâches sont accélérées à tel point qu’elles cessent d’être des contraintes de temps significatives. La rédaction d’une première ébauche, la compilation de données depuis plusieurs sources, la reformatation de documents, la génération de résumés : ces tâches ne disparaissent pas, elles se compressent. Une tâche qui prenait deux heures en prend maintenant vingt minutes, avec un output de même qualité ou meilleure.

Amplification. D’autres tâches voient leur portée s’élargir. Un analyste RH qui pouvait auparavant traiter dix profils de candidats par heure peut maintenant en traiter cinquante, à condition de maintenir la qualité du jugement sur chaque recommandation. La capacité augmente, mais la responsabilité du jugement reste entière. Brynjolfsson et al. (2023) documentent que cet effet d’amplification est fortement différencié selon le niveau de compétence initial : les travailleurs moins expérimentés bénéficient davantage en termes relatifs, tandis que les experts conservent des avantages que la GenAI ne compense pas entièrement.

Création. La GenAI génère des tâches nouvelles qui n’existaient pas. La formulation de prompts efficaces. La validation d’outputs IA (ce qui exige de comprendre ce que l’IA fait et ce qu’elle peut rater). La détection d’hallucinations dans des contextes métier spécialisés. La gouvernance de l’usage des outils au sein de l’équipe. Ces nouvelles tâches requièrent des compétences que les fiches de poste n’ont pas encore nommées.

Ce triptyque (réduction, amplification, création) se produit dans le même poste, souvent sur la même semaine. Et il produit un phénomène que la recherche commence à documenter : un employé peut voir sa performance globale augmenter grâce à la GenAI tout en subissant une surcharge cognitive accrue liée à la validation et à la supervision des outputs. Shao et al. (2025), dans une étude longitudinale journalière publiée dans le Journal of Management, le montrent empiriquement : sur une même journée, le même employé peut bénéficier de gains cognitifs substantiels grâce à l’IA ET souffrir d’une surcharge informationnelle qui dégrade sa récupération post-travail. Les deux effets coexistent, sur la même personne, en même temps.

Les métriques d’adoption habituelles (taux d’utilisation, temps économisé, tickets résolus) ne captent pas cette dualité. Elles mesurent le gain. Elles ne mesurent pas le coût invisible.

Les compétences deviennent plus instables, plus contextuelles et plus hybrides

Si les tâches changent à la vitesse de la GenAI, les compétences nécessaires pour les accomplir changent avec elles.

La GenAI accélère un phénomène déjà à l’œuvre : les compétences deviennent moins stables, plus contextuelles, et plus hybrides.

Moins stables. La durée de vie utile d’une compétence technique spécifique raccourcit. Maîtriser un logiciel précis comptait pour beaucoup il y a dix ans. Aujourd’hui, ce qui compte davantage, c’est la capacité à apprendre rapidement un nouvel outil, à en comprendre les limites, et à l’intégrer dans un flux de travail existant. Gobeil-Proulx (2021) l’identifiait déjà dans le contexte québécois : les compétences qui résistent sont la littératie en IA, la capacité à travailler en équipe interdisciplinaire, la créativité et la résolution de problèmes complexes, pas les compétences techniques figées.

Plus contextuelles. La même compétence peut avoir une valeur très différente selon le contexte organisationnel. La capacité à formuler des prompts efficaces est utile partout, mais sa valeur spécifique dépend des outils disponibles, des processus métier, du secteur, et des contraintes réglementaires de l’organisation. Au Québec, en 2024-2025, seulement 12,7 % des entreprises utilisaient l’IA à des fins de production, selon Statistique Québec. Ce chiffre faible ne signifie pas que les compétences IA sont peu pertinentes : il signifie que leur valeur est très inégalement distribuée selon les secteurs et la maturité des organisations. Mehdi et Morissette (2024) affinent cette lecture en estimant, par analyses économétriques sur le marché du travail canadien, les niveaux d’exposition différenciés selon les catégories professionnelles, avec des résultats qui nuancent fortement les projections globales.

Plus hybrides. La GenAI valorise les profils hybrides — un spécialiste en rémunération qui comprend les implications des algorithmes de compensation IA, ou une chargée de formation qui sait concevoir des contenus humains ET évaluer ce qu’un LLM peut ou ne peut pas faire dans ce contexte. Ces profils n’entrent pas facilement dans une case de famille d’emploi.

Ce que ça demande aux SIRH : passer du profil au flux de travail

C’est là que les SIRH commencent à coincer.

Les SIRH ont été construits pour gérer des profils. Un employé a un poste. Ce poste a des compétences requises. L’employé déclare ou acquiert ces compétences. On mesure l’écart. On prescrit de la formation.

Ce modèle suppose que le travail est relativement stable, qu’on peut le décrire une fois et le gérer ensuite. Il suppose également que les compétences sont des attributs relativement stables des individus : on les a ou on ne les a pas, et on les accumule progressivement.

Ce dont les organisations ont besoin, ce n’est pas d’un meilleur profil de compétences. C’est d’une capacité à lire le travail réel dynamiquement : comprendre quelles tâches sont réellement accomplies, comment elles évoluent, quelles compétences émergent comme critiques, et comment ces compétences se distribuent dans l’organisation.

C’est une ambition architecturale différente. Elle exige des données qui vont au-delà des autodéclarations, des taxonomies qui capturent les relations sémantiques entre compétences plutôt que de simplement les classifier, et une gouvernance qui permette de maintenir cette lecture à jour.

Certains éditeurs de SIRH avancent dans cette direction. Workday Skills Cloud, avec ses 47 000+ compétences normalisées (Workday, 2022) et son approche ontologique auto-apprenante, est probablement l’exemple le plus documenté. Le principe est le suivant : au lieu de demander à l’employé de remplir son profil, le système infère ses compétences probables en analysant ses projets, ses formations, ses évaluations, ses mouvements internes. Il cartographie les relations sémantiques entre compétences, de façon similaire au fonctionnement des réseaux neuronaux humains : des relations multidimensionnelles plutôt qu’une hiérarchie rigide.

Mais une ontologie n’est pas une stratégie. Et un Skills Cloud déployé sans gouvernance, sans culture du partage des compétences, et sans connexion réelle aux décisions de développement et de mobilité, reste un outil de catalogage sophistiqué, pas un levier de transformation.

Ce sera le sujet du Volet 2.

La skills-based organization : une réponse possible, pas magique

Le concept d’organisation fondée sur les compétences (skills-based organization, SBO) n’est pas nouveau. Il circule dans les milieux RH depuis plus d’une décennie. Ce qui change avec la GenAI, c’est son urgence.

L’argument central de la SBO est simple : si les compétences sont l’unité de valeur dans le travail moderne, plus que les diplômes, plus que les titres, plus que l’ancienneté, alors toute la logique de gestion des talents devrait être organisée autour d’elles. La mobilité interne, le développement, l’acquisition, la planification des effectifs : tout pivoté sur la compétence plutôt que sur le poste.

Les données sont encourageantes. Selon un rapport Deloitte 2024 synthétisé par HR Grapevine, les organisations SBO surpassent leurs pairs sur tous les indicateurs mesurés : placement des talents (+107 %), anticipation du changement (+57 %), innovation (+52 %), atteinte des résultats (+63 %) et expérience employé (+79 %).

Ce qui est clair, en revanche, c’est que la SBO est une réponse architecturale à la volatilité du travail : une façon de construire l’organisation pour qu’elle puisse s’adapter plus rapidement que ses propres fiches de poste. Face à la GenAI, cette adaptabilité a une valeur évidente.

Ce qui est moins clair, c’est ce qu’une stratégie SBO demande vraiment : une infrastructure de données fiable, une gouvernance du signal de compétences, une culture organisationnelle qui valorise la mobilité plutôt que la rétention, et une discipline dans la mesure qui dépasse les tableaux de bord d’adoption. La plupart des organisations qui pensent faire du SBO font en réalité du catalogage de compétences avec un beau nom.

Et si une liste de compétences ne suffisait pas ?

Ce premier volet a posé le diagnostic : la GenAI déplace le travail au niveau des tâches, là où les SIRH et les fiches de poste n’atteignent pas. La question qui suit est logique — si les compétences deviennent l’unité de gestion pertinente, pourquoi si peu d’organisations réussissent à en faire une vraie stratégie ?

C’est ce qu’on explorera au Volet 2 : pourquoi tant d’organisations ont un catalogue de skills et si peu ont une vraie approche skills-based — et quelle est la différence entre une taxonomie et une ontologie.

Références

When the ERP Stops Being a Tool and Becomes a Colleague

Two years ago, talking about an “AI assistant” in an ERP meant, at best, a chatbot capable of answering “how many vacation days do I have left?” Today, the three market leaders — Workday, SAP, Oracle — promise agents capable of generating a requisition, orchestrating an HR-IT onboarding, closing a financial month, or producing a budget variance report with minimal human supervision.

This is a genuine qualitative leap. And it is also a minefield.

On one side, the anticipated benefits are concrete and measurable. On the other, the blind spots in vendor discourse are systematic, and recent scientific literature is only beginning to name them. For an executive who needs to decide in 2026 what to do with this wave — embrace it, defer it, frame it — clarity comes neither from marketing decks nor from academic reviews in isolation. It comes from the intersection of both.

This blog post offers precisely that intersection. I will give you neither vendor hype nor academic skepticism. I offer a dual reading: that of a practitioner who deploys these platforms with clients, and that of a doctoral student working on this very subject.

The Distinction That Changes Everything: AI Agent vs. Agentic AI

Before going further, a conceptual detour is necessary. The words used by vendors today are vague enough to muddle the entire debate.

A taxonomy published in Information Fusion in 2026 by Sapkota, Roumeliotis, and Karkee proposes a structuring three-generation distinction.

Generation 1 — Generative AI. These are large language models like GPT-4, Claude, or Gemini. They produce text, code, summaries. They do not “do” anything inside your system.

Generation 2 — AI agents. Specialized modules capable of executing a specific task via an API call or integration. An agent that creates a leave request. An agent that reconciles an invoice. An agent that answers an HR question. Useful, but essentially reactive and task-specific.

Generation 3 — Agentic AI. Multi-agent systems capable of dynamically decomposing a complex task, retaining context from one day to the next, coordinating multiple specialized agents, and operating with significant autonomy in evolving environments.

This distinction is not an academic quirk. It has a direct operational implication. An AI agent that makes a single well-defined step is governed like an integration. An agentic system that orchestrates multiple subtasks, negotiates with other agents, and learns over time is governed like an employee. The nature of control, responsibility, and risk shift to a different level entirely.

When Workday presents Sana as “the new front door of work,” when SAP formally distinguishes its deterministic Joule Skills from its autonomous Joule Agents, or when Oracle introduces its Fusion Agentic Applications as “a new class of outcome-driven applications” — they are all describing, in their own vocabulary, this passage from Generation 2 to Generation 3.

Keep that in mind. It is the lens that makes the rest readable.

Workday, SAP, Oracle: Three Strategic Bets, Not One Race

Once this taxonomy is in place, you stop comparing features to features. You compare theories of change. And here, the three vendors diverge radically.

Methodological note: the comparative points below are based on public vendor communications and field observations at the time of writing. This landscape is moving quickly.

What Vendors Won’t Tell You (But Research Reveals)

This is where my dual perspective matters most. Vendor decks do an admirable job covering architecture, technical governance, and projected ROI. They are remarkably silent on what recent academic research identifies as the true success or failure factors in an agentic deployment.

What Academia Doesn’t See (But the Field Reveals)

The symmetry is necessary. If vendors have their blind spots, so does the academic literature — and some of them are massive.

Four Questions to Ask Before You Sign

If you are a CHRO, CIO, VP Finance, or VP Transformation and need to decide in 2026 what to do with agentic AI in your ERP, here are the four questions I recommend asking before signing anything.

1. Which processes actually warrant controlled delegation? Do not start with “which agent should we buy.” Start by mapping your processes along three axes — frequency, friction, and risk. The best candidates for the first wave are high-frequency, high-friction, moderate-risk processes. HR self-service, expenses, helpdesk, requisitions, onboarding, minor cash management. Not the monthly financial close. Not payroll. Not high-regulatory-impact transactions.

2. What lived indicators will you track, in addition to management KPIs? ROI, time saved, and tickets reduced are necessary but insufficient. Add at minimum three lived indicators — perceived cognitive load, sense of control over one’s work, and the coping strategies employees mobilize. These measures are not exotic. They have existed in HRM and IS research for years. They are absent from vendor dashboards. You will need to build them yourself — and that is precisely what will distinguish a successful deployment from a costly one.

3. What agent governance beyond the purchase? If your agents are digital colleagues, who supervises them? Who validates their access rights? Who decides on their decommissioning? Who measures their budget footprint? Workday with ASOR, SAP with Cloud Identity Services, and Oracle with its RBAC frameworks offer different mechanisms. The right choice depends on the maturity of your IT function and your tolerance for governance industrialization.

4. What is the real economics beyond the proof of concept? Consumption-based models make pilots attractive and large-scale deployments unpredictable. Before signing, require a realistic simulation of your full-load annual cost — including premium LLMs, third-party connectors, API calls, and customization overages. Ask explicitly for the list of situations that trigger additional billing. You will be surprised.

The Practitioner-Researcher Stance

To close, a word about the lens that allowed me to write this article.

I co-lead a Workday consulting firm. Every week, I see Quebec and Canadian organizations facing exactly the choices I have just described. I participate in real deployments, with their successes and their failures.

I am also a doctoral student working on the transformation of knowledge work by generative AI in an Industry 5.0 context. I spend a significant part of my time reading recent scientific research and confronting theoretical frameworks with field observations.

This dual stance is not comfortable. It forces you to acknowledge the limits of both worlds. Field practice alone produces compelling narratives that do not generalize. Science alone produces rigorous frameworks that are often inoperable. It is the back-and-forth between the two that creates value — for clients, for teams, and, I believe, for the discipline itself.

If you have read this far, you probably share that intuition. You know that the next ERP wave will be won neither in marketing nor in theory. It will be won in the quality of the intersection between what research teaches us and what the field forces us to understand.

I will always have more questions than answers. But it is that back-and-forth between theory and field that makes agentic deployments succeed.

Scientific References

Sapkota, R., Roumeliotis, K. I., & Karkee, M. (2026). AI Agents vs. Agentic AI: A Conceptual Taxonomy, Applications and Challenges. Information Fusion, 126, 103599. https://doi.org/10.1016/j.inffus.2025.103599

Shao, Y., Huang, Z., Song, Y., Wang, M., Song, Y. H., & Shao, R. (2025). Using Augmentation-Based AI Tool at Work: A Daily Investigation of Learning-Based Benefit and Challenge. Journal of Management, 51(8), 3352–3390. https://doi.org/10.1177/01492063241266503

Haase, J., Kremser, W., Leopold, H., Mendling, J., Onnasch, L., & Plattfaut, R. (2024). Interdisciplinary Directions for Researching the Effects of Robotic Process Automation and Large Language Models on Business Processes. Communications of the Association for Information Systems, 54(1), 579–604. https://doi.org/10.17705/1CAIS.05421

Sarferaz, S. (2025). Implementing Conversational AI Into ERP Software. IEEE Access, 13, 160238–160250. https://doi.org/10.1109/ACCESS.2025.3608477

Aguinis, H., Beltran, J. R., & Cope, A. (2024). How to Use Generative AI as a Human Resource Management Assistant. Organizational Dynamics, 53(1), 101029. https://doi.org/10.1016/j.orgdyn.2024.101029

Acharya, D. B., Kuppan, K., & Divya, B. (2025). Agentic AI: Autonomous Intelligence for Complex Goals—A Comprehensive Survey. IEEE Access, 13, 18912–18936. https://doi.org/10.1109/ACCESS.2025.3532853

Islam, M. S., Islam, M. I., Mozumder, A. Q., Khan, M. T. H., Das, N., & Mohammad, N. (2025). A Conceptual Framework for Sustainable AI-ERP Integration in Dark Factories: Synthesising TOE, TAM, and IS Success Models for Autonomous Industrial Environments. Sustainability, 17(20), 9234. https://doi.org/10.3390/su17209234

Brynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence [Working Paper]. Stanford Digital Economy Lab. https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/

Quand l’ERP cesse d’être un outil et devient un collègue

Il y a encore deux ans, parler d’« assistant IA » dans un ERP signifiait au mieux un chatbot capable de répondre « combien de jours de vacances me reste-t-il ? ». Aujourd’hui, les trois géants du marché — Workday, SAP, Oracle — promettent des agents capables de générer une réquisition, d’orchestrer un onboarding HR-IT, de fermer un mois comptable ou de produire un rapport d’écart budgétaire avec un minimum de supervision humaine.

C’est un saut qualitatif réel. Et c’est aussi un terrain miné.

D’un côté, les bénéfices anticipés sont concrets et mesurables. De l’autre, les angles morts du discours vendor sont systématiques, et la littérature scientifique récente commence tout juste à les nommer. Pour un dirigeant qui doit décider en 2026 ce qu’il fait de cette vague — l’embrasser, la temporiser, la cadrer — la lucidité ne se trouve ni dans les decks marketing ni dans les revues de littérature isolément. Elle se trouve à l’intersection des deux.

Cette publication de blog propose précisément ce croisement. Je ne vous offrirai ni hype vendor ni scepticisme académique. Je vous propose une lecture double, celle d’un praticien qui déploie ces plateformes chez des clients et celle d’un étudiant au doctorat qui travaille sur ce sujet.

La distinction qui change tout : AI agent versus agentic AI

Avant d’aller plus loin, un détour conceptuel s’impose. Les mots utilisés par les éditeurs sont aujourd’hui flous au point de brouiller le débat.

Une taxonomie publiée dans Information Fusion en 2026 par Sapkota, Roumeliotis et Karkee propose une distinction structurante en trois générations.

Génération 1 — L’IA générative. Ce sont les grands modèles de langage comme GPT-4, Claude ou Gemini. Ils produisent du texte, du code, des résumés. Ils ne « font » rien dans votre système.

Génération 2 — Les AI agents. Modules spécialisés capables d’exécuter une tâche précise via un appel d’API ou une intégration. Un agent qui crée une demande de congé. Un agent qui rapproche une facture. Un agent qui répond à une question RH. Utiles, mais essentiellement réactifs et task-spécifiques.

Génération 3 — L’agentic AI. Système multi-agents capables de décomposer dynamiquement une tâche complexe, de mémoriser le contexte d’une journée à l’autre, de coordonner plusieurs agents spécialisés et d’opérer avec une autonomie significative dans des environnements évolutifs.

Cette distinction n’est pas un caprice de chercheur. Elle a une implication opérationnelle directe. Un AI agent qui fait un seul saut bien défini se gouverne comme une intégration. Un système agentic qui orchestre plusieurs sous-tâches, négocie avec d’autres agents et apprend dans la durée se gouverne comme un employé. La nature du contrôle, la nature de la responsabilité et la nature des risques changent de niveau.

Quand Workday présente Sana comme « la nouvelle porte d’entrée du travail », quand SAP distingue formellement ses Joule Skills déterministes de ses Joule Agents autonomes, ou quand Oracle introduit ses Fusion Agentic Applications comme « une nouvelle classe d’applications outcome-driven », ils décrivent tous, dans leur grammaire propre, ce passage de la génération 2 à la génération 3.

Retenez-le. C’est la lentille qui rend le reste lisible.

Workday, SAP, Oracle : trois paris stratégiques, pas une seule course

Une fois cette taxonomie posée, on cesse de comparer des fonctionnalités à fonctionnalités. On compare des théories du changement. Et là, les trois éditeurs divergent radicalement.

Précision méthodologique : les éléments comparatifs ci-dessous reposent sur des communications publiques d’éditeurs et des observations terrain au moment de la rédaction. Ce paysage évolue rapidement.

Ce que les vendors ne vous diront pas (mais que la recherche révèle)

C’est ici que ma double casquette prend tout son sens. Les decks vendors couvrent admirablement l’architecture, la gouvernance technique et le ROI projeté. Ils sont remarquablement silencieux sur ce que la recherche académique récente identifie comme les vrais facteurs de réussite ou d’échec d’un déploiement agentic.

Ce que l’académie ne voit pas (mais que le terrain révèle)

La symétrie est nécessaire. Si les vendors ont leurs angles morts, la littérature académique en a aussi, et certains sont massifs.

Quatre questions à se poser avant de signer

Si vous êtes DRH, CIO, VP Finance ou VP Transformation et que vous devez décider en 2026 ce que vous faites de l’agentic AI dans votre ERP, voici les quatre questions que je vous recommande de poser avant de signer quoi que ce soit.

1. Quel processus mérite vraiment une délégation contrôlée ? Ne commencez pas par « quel agent acheter ». Commencez par cartographier vos processus selon trois axes — fréquence, friction, risque. Les bons candidats à la première vague sont les processus à forte fréquence, forte friction et risque modéré. Self-service RH, dépenses, helpdesk, réquisitions, onboarding, gestion de cash mineur. Pas le processus de clôture financière mensuelle. Pas la paie. Pas les transactions à fort impact réglementaire.

2. Quels indicateurs vécus mesurera-t-on, en plus des KPI managériaux ? Le ROI, le temps gagné et les tickets réduits sont nécessaires mais insuffisants. Ajoutez au minimum trois indicateurs vécus — la charge cognitive perçue, le sentiment de contrôle sur son travail et les stratégies de coping mobilisées par les utilisateurs. Ces mesures ne sont pas exotiques. Elles existent dans la littérature scientifique en GRH et en SI depuis des années. Elles sont absentes des dashboards vendors. Vous devrez les construire vous-même, mais c’est précisément ce qui distinguera un déploiement réussi d’un déploiement coûteux.

3. Quelle gouvernance des agents au-delà de l’achat ? Si vos agents sont des collègues numériques, qui les supervise ? Qui valide leurs droits d’accès ? Qui décide de leur retrait ? Qui mesure leur empreinte budgétaire ? Workday avec ASOR, SAP avec Cloud Identity Services et Oracle avec ses cadres RBAC offrent des dispositifs différents. Le bon choix dépend de la maturité de votre fonction SI et de votre tolérance à l’industrialisation de la gouvernance.

4. Quelle économie réelle au-delà du POC ? Les modèles à la consommation rendent les pilotes attractifs et les déploiements à grande échelle imprévisibles. Avant de signer, exigez une simulation réaliste de votre coût annuel à pleine charge, avec les LLM premium, les connecteurs tiers, les appels API et les surcoûts de personnalisation. Demandez explicitement la liste des situations qui basculent vers une facturation additionnelle. Vous serez surpris.

La posture du praticien-chercheur

Pour conclure, un mot sur la lentille qui m’a permis d’écrire cet article.

Je co-dirige une firme de conseil Workday. Je vois chaque semaine des organisations québécoises et canadiennes confrontées aux choix que je viens de décrire. Je participe à des déploiements concrets, avec leurs réussites et leurs ratés.

Je suis aussi étudiant au doctorat sur la transformation du travail du savoir par l’IA générative en contexte d’Industrie 5.0. Je passe une part significative de mon temps à lire la recherche scientifique récente et à confronter les cadres théoriques aux observations terrain.

Cette double posture n’est pas confortable. Elle oblige à reconnaître les limites des deux mondes. Le terrain seul produit des récits convaincants mais peu généralisables. La science seule produit des cadres rigoureux mais souvent inopérants. C’est le va-et-vient entre les deux qui crée de la valeur — pour les clients, pour les équipes, et, je le crois, pour la discipline elle-même.

Si vous avez lu jusqu’ici, vous partagez probablement cette intuition. Vous savez que la prochaine vague ERP ne se gagnera ni au marketing ni à la théorie. Elle se gagnera dans la qualité du croisement entre ce que la recherche nous apprend et ce que le terrain nous oblige à comprendre.

J’aurai toujours plus de questions que de réponses. Mais c’est ce va-et-vient entre théorie et terrain qui rend les déploiements agentic réussis.

Références scientifiques

Sapkota, R., Roumeliotis, K. I., & Karkee, M. (2026). AI Agents vs. Agentic AI : A Conceptual Taxonomy, Applications and Challenges. Information Fusion, 126, 103599. https://doi.org/10.1016/j.inffus.2025.103599

Shao, Y., Huang, Z., Song, Y., Wang, M., Song, Y. H., & Shao, R. (2025). Using Augmentation-Based AI Tool at Work : A Daily Investigation of Learning-Based Benefit and Challenge. Journal of Management, 51(8), 3352–3390. https://doi.org/10.1177/01492063241266503

Haase, J., Kremser, W., Leopold, H., Mendling, J., Onnasch, L., & Plattfaut, R. (2024). Interdisciplinary Directions for Researching the Effects of Robotic Process Automation and Large Language Models on Business Processes. Communications of the Association for Information Systems, 54(1), 579–604. https://doi.org/10.17705/1CAIS.05421

Sarferaz, S. (2025). Implementing Conversational AI Into ERP Software. IEEE Access, 13, 160238–160250. https://doi.org/10.1109/ACCESS.2025.3608477

Aguinis, H., Beltran, J. R., & Cope, A. (2024). How to Use Generative AI as a Human Resource Management Assistant. Organizational Dynamics, 53(1), 101029. https://doi.org/10.1016/j.orgdyn.2024.101029

Acharya, D. B., Kuppan, K., & Divya, B. (2025). Agentic AI : Autonomous Intelligence for Complex Goals—A Comprehensive Survey. IEEE Access, 13, 18912–18936. https://doi.org/10.1109/ACCESS.2025.3532853

Islam, M. S., Islam, M. I., Mozumder, A. Q., Khan, M. T. H., Das, N., & Mohammad, N. (2025). A Conceptual Framework for Sustainable AI-ERP Integration in Dark Factories : Synthesising TOE, TAM, and IS Success Models for Autonomous Industrial Environments. Sustainability, 17(20), 9234. https://doi.org/10.3390/su17209234

Brynjolfsson, E., Chandar, B., & Chen, R. (2025). Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence [Working Paper]. Stanford Digital Economy Lab. https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/

Vue d’ensemble

Tout a commencé comme un problème d’intégration Workday ordinaire — mais l’expérience a rapidement dérivé vers une autre question : pouvait-on concevoir et livrer une orchestration complète principalement en langage naturel ?

L’objectif n’était pas de construire quelque chose de parfait. Il s’agissait de voir jusqu’où on pouvait pousser cette approche dans un scénario réel : synchroniser une Time Off Service Date depuis les données du worker vers un custom object, de façon sûre et avec suffisamment d’observabilité pour diagnostiquer les échecs.

Ce qui a rendu l’expérience intéressante, c’est la méthode de livraison. Nous avons pu concevoir, valider, construire, déployer et déboguer l’orchestration principalement en langage naturel, en utilisant un ensemble de skills IA spécialisés plutôt qu’un assistant générique.

En pratique, cela ressemblait à recréer un Workday Orchestration Copilot.

Pourquoi cette idée est devenue d’actualité

Le déclencheur n’était pas un enthousiasme abstrait pour l’IA. C’était un changement concret sur la plateforme.

Quand Workday a rendu le Workday Developer CLI généralement disponible, cela a changé la forme pratique du workflow de livraison. Selon l’annonce officielle, WDCLI est devenu l’interface en ligne de commande unifiée pour construire, tester, valider et déployer les applications Workday Integration et Extend sur l’ensemble du cycle de vie applicatif. L’annonce soulignait également des capacités clés : uploader des apps vers App Hub, les télécharger, les déployer sur des tenants, les promouvoir entre environnements, et s’authentifier de façon programmatique via un modèle de system user sécurisé.

C’était important parce que cela créait une surface de livraison crédible centrée sur le terminal, pour les builders Workday. Une fois que Workday lui-même avait rendu le cycle de vie CLI réel, la question logique suivante était simple : si la plateforme peut désormais être pilotée depuis le terminal, une pile d’agents en langage naturel peut-elle devenir la couche opérationnelle qui pilote ce cycle de vie ?

C’est à ce moment que le projet a cessé d’être un simple exercice d’orchestration et a commencé à ressembler à une expérience de construction d’un équivalent de Workday Orchestration Copilot.

Sources :

• Annonce Workday Community : Product Update: Workday Developer CLI now Generally Available
• Démo produit : Workday CLI GA Demo on Vimeo

La pile de skills

Le workflow reposait sur un ensemble restreint de skills ciblés. Chacun avait la responsabilité exclusive d’une partie du problème, et c’est cette séparation qui a rendu le système fiable.

Du besoin métier à une conception fonctionnelle

La première étape n’était pas la génération de code. C’était la découverte du tenant.

En utilisant les skills orientés WQL, nous avons confirmé quelles data sources et quels alias existaient réellement dans le tenant, comment la Time Off Service Date pouvait être lue, et à quoi ressemblait le champ du custom object du point de vue de la récupération. Cela importait parce que les intégrations Workday échouent souvent quand les équipes supposent que le tenant correspond aux exemples génériques.

Une fois le contrat de données clarifié, le skill d’orchestration a aidé à traduire le besoin en un flux concret :

• lire les lignes de workers via WQL
• boucler sur chaque résultat
• comparer les valeurs source et cible
• appeler une suborchestration uniquement quand une mise à jour est requise
• émettre des integration messages pour la traçabilité

Ce n’était pas une simple génération de JSON. Cela nécessitait de comprendre les chemins d’exécution Workday, les règles de scope, les frontières de sous-flux et le comportement des nœuds API.

Validation API avant de faire confiance à l’orchestration

Avant de faire confiance à l’orchestration, nous avons validé la direction API directement.

En utilisant les outils de test API, nous avons confirmé que le service REST du custom object était le bon chemin de mise à jour, que la forme du payload était valide, et que le service attendait worker.id plutôt que employeeID. Cette séparation était importante : elle nous a permis de distinguer un problème d’orchestration d’un problème de contrat de service.

En d’autres termes, le projet a progressé parce que nous n’avons pas deviné. Nous avons validé chaque couche indépendamment.

WDCLI comme couche de livraison

Une fois l’orchestration en place, wdcli est devenu le mécanisme de livraison.

Cela a introduit ses propres apprentissages :

• la vraie racine de l’app devait être identifiée correctement
• les dossiers de documentation du projet n’étaient pas suffisants ; le code source de l’app Workday devait contenir appManifest.json
• wdcli app upload pouvait produire une sortie terminal contradictoire
• la vraie source de vérité était l’état de la version dans App Hub et l’état du build, pas le message terminal seul
• wdcli app deploy pouvait échouer avec une exception côté CLI tout en laissant une ambiguïté sur l’état réel de la plateforme

Cela a changé le workflow. Au lieu de supposer que la sortie CLI était authoritative, nous avons commencé à vérifier chaque upload via wdcli app versions et chaque build via wdcli app builds.

Cela a aussi révélé une conséquence architecturale utile du positionnement de WDCLI par Workday lui-même. L’annonce officielle cadrait explicitement WDCLI comme l’interface pour automatiser les pipelines de build et de test, et pour gérer le cycle de vie complet des apps via des workflows en ligne de commande. Une fois que c’était devenu réel, il était logique de concevoir la couche IA environnante autour de ces mêmes étapes :

• découvrir
• valider
• construire
• uploader
• déployer
• inspecter
• déboguer

C’est l’une des raisons pour lesquelles cette histoire est plus qu’une expérience de prompt one-off. Elle s’aligne sur la surface de livraison que Workday a lui-même choisi d’exposer.

Le moment où l’histoire est devenue intéressante

L’orchestration a compilé avec succès. L’upload a réussi. Le build a passé.

Puis le comportement en production a raconté une autre histoire.

Les integration messages indiquaient initialement que les enregistrements étaient mis à jour, mais quand nous avons vérifié les données cibles dans Workday, le champ restait vide. C’est là que le skill d’orchestration et l’approche de débogage sont devenus critiques.

Nous avons amélioré les integration messages pour qu’ils ne rapportent plus un succès de façon inconditionnelle. À la place, ils ont commencé à logger :

• l’identifiant du worker
• la valeur TOSD source
• le code de statut HTTP de la réponse
• le corps brut de la réponse API

Cette seule amélioration a changé complètement le processus de débogage.

La cause racine du 404

L’exécution suivante a exposé le vrai problème immédiatement.

L’API retournait un 404 avec une réponse indiquant que l’alias du tenant avait été traité comme une partie du chemin de la ressource. Le problème n’était pas la référence du worker, ni le payload. Le problème était le chemin REST lui-même.

Le nom du tenant avait été codé en dur dans le chemin API du custom object :

/customObject/v2/<tenant>/customObjects/timeOffServiceDate?updateIfExists=true

À l’intérieur d’un appel d’orchestration Workday en contexte de tenant, c’était incorrect. L’orchestration s’exécutait déjà dans le contexte du tenant, donc le nom du tenant ne devait pas apparaître dans le chemin REST.

Le correctif consistait à supprimer le segment tenant et à utiliser le chemin de service relatif au tenant :

/customObject/v2/customObjects/timeOffServiceDate?updateIfExists=true

C’était un exemple fort de pourquoi le succès du build ne suffit pas. L’orchestration a compilé parfaitement et a quand même échoué à l’exécution parce que le chemin de la requête était sémantiquement incorrect.

C’était aussi un exemple fort de pourquoi les skills spécialisés surpassent la résumé générique. Le skill d’orchestration savait qu’il fallait améliorer le logging autour de responseStatusCode et response.toString(). Une fois ces détails visibles dans l’integration event, l’erreur de runtime a cessé d’être mystérieuse.

L’orchestration finale

Après la découverte du tenant, la validation API, le débogage itératif et le correctif du chemin REST, voici l’orchestration qui tourne en production.

Le flux principal lit les workers via WQL, boucle sur chaque ligne, compare les valeurs source et cible, et délègue les mises à jour à la suborchestration uniquement quand nécessaire. La suborchestration gère l’appel REST, branche selon la réponse, et émet des integration messages structurés dans les deux cas — succès et échec.

Ce que le package montre

Le code d’orchestration, le snapshot de la racine de l’app, et les cinq skills utilisés dans ce projet sont disponibles sur demande. L’enjeu n’est pas simplement de dire « l’IA a aidé ». Il s’agit de montrer comment le workflow peut être lu, challengé et reproduit par un autre ingénieur.

Pourquoi cela ressemble à une histoire de Copilot

Ce qui vaut la peine d’être documenté ici, ce n’est pas seulement le correctif lui-même. C’est le processus.

Nous avons utilisé le langage naturel pour coordonner :

• la découverte des data sources
• la conception des requêtes WQL
• l’exécution WQL
• la validation API
• la conception de l’orchestration
• le débogage en production
• le packaging et le déploiement via WDCLI

C’est effectivement un workflow de copilot spécialisé pour Workday Extend.

Au lieu de demander à un modèle générique d’improviser sur chaque couche, nous avons utilisé des skills spécialisés portant chacun une connaissance opérationnelle d’une partie de la plateforme. Le résultat : un raisonnement plus fiable, un diagnostic plus rapide, et moins de fausses hypothèses.

La vue d’ensemble

Ce que cette expérience indique, c’est un pattern, pas un cas isolé.

Le langage naturel devient beaucoup plus précieux quand il est connecté à des skills spécialisés, des outils vérifiables, et des workflows tenant-aware. Dans ce cadre, l’IA ne génère pas seulement du texte. Elle aide à réaliser un vrai travail de livraison — conception, validation, déploiement, débogage.

Le timing compte aussi. La disponibilité générale de WDCLI a créé la surface pratique qui permet à ce type d’expérience d’avoir de l’importance. Une fois que le cycle de vie de la plateforme peut être piloté de façon crédible depuis le terminal, il devient raisonnable de placer une couche d’orchestration en langage naturel par-dessus.

C’est pourquoi cette histoire est plus grande qu’une seule orchestration. Elle montre comment une chaîne d’outils basée sur des agents peut fonctionner comme un Workday Orchestration Copilot pratique pour les builders utilisant Codex, Claude, Gemini, OpenCode ou des environnements agents similaires.

Nous continuerons à explorer cet espace — on a l’impression de n’avoir fait qu’effleurer la surface de ce que orchestration et langage naturel pourraient devenir dans Workday.

Overview

This started as a simple Workday integration problem — but quickly turned into an experiment: could we design and deliver a full orchestration mostly through natural language?

We didn’t set out to build something perfect. The goal was to see how far we could push this approach in a real scenario: synchronize a Time Off Service Date from worker data into a custom object, safely and with enough observability to diagnose failures.

What made it interesting was the delivery method. We were able to design, validate, build, deploy, and debug the orchestration primarily through natural language, using a set of specialized AI skills instead of a single generic assistant.

In practice, this felt like recreating a Workday Orchestration Copilot.

Why This Idea Became Timely

The trigger was not abstract enthusiasm about AI. It was a concrete platform shift.

When Workday made the updated Workday Developer CLI generally available, it changed the practical shape of the delivery workflow. According to Workday’s announcement, WDCLI became the unified command line interface to build, test, validate, and deploy Workday Integration and Extend apps across the application lifecycle. The official announcement also emphasized core capabilities such as uploading apps to App Hub, downloading them, deploying them to tenants, promoting them across environments, and authenticating programmatically through a secure system user model.

That mattered because it created a credible terminal-centered delivery surface for Workday builders. Once Workday itself made the CLI lifecycle real, the next logical question was straightforward: if the platform can now be managed through the terminal, can a natural-language agent stack become the operating layer that drives that lifecycle?

That is the moment when this project stopped looking like a simple orchestration exercise and started looking like an experiment in building an equivalent of a Workday Orchestration Copilot.

Sources:

• Workday forum announcement: Product Update: Workday Developer CLI now Generally Available
• Product demo: Workday CLI GA Demo on Vimeo

The Skill Stack

The workflow depended on a small set of focused skills. Each one owned a distinct part of the problem, and that separation is what made the whole system reliable.

From Business Need to Working Design

The first step was not code generation. It was tenant discovery.

Using the WQL-oriented skills, we confirmed which data source and aliases actually existed in the tenant, how the Time Off Service Date could be read, and what the custom object field looked like from a retrieval perspective. This mattered because Workday integrations often fail when teams assume the tenant matches generic examples.

Once the data contract was clearer, the orchestration skill helped translate the requirement into a concrete flow:

• read worker rows through WQL
• loop through each result
• compare source and target values
• call a suborchestration only when an update is required
• emit integration messages for traceability

This was not just JSON generation. It required understanding Workday execution paths, scoping rules, subflow boundaries, and API node behavior.

API Validation Before Blind Orchestration

Before trusting the orchestration, we validated the API direction directly.

Using API test tooling, we confirmed that the custom object REST service was the correct update path, that the payload shape was valid, and that the service expected worker.id rather than employeeID. That separation was important: it let us distinguish an orchestration problem from a service-contract problem.

In other words, the project moved forward because we did not guess. We validated each layer independently.

WDCLI as Delivery Layer

Once the orchestration was in place, wdcli became the delivery mechanism.

This introduced its own lessons:

• the real app root had to be identified correctly
• project documentation folders were not enough; the actual Workday app source had to contain appManifest.json
• wdcli app upload could produce contradictory terminal output
• the real source of truth was App Hub version state and build state, not the terminal message alone
• wdcli app deploy could fail with a CLI-side exception while still leaving ambiguity about the real platform state

That changed the workflow. Instead of assuming the CLI output was authoritative, we started verifying every upload through wdcli app versions and every build through wdcli app builds.

It also exposed a useful architectural consequence of Workday’s own WDCLI positioning. The announcement explicitly framed WDCLI as the interface for automating build and testing pipelines and for managing the end-to-end lifecycle of apps through command-line workflows. Once that became true, it made sense to design the surrounding AI layer around those same stages:

• discover
• validate
• build
• upload
• deploy
• inspect
• debug

That is one reason this story is more than a one-off prompt experiment. It is aligned with the delivery surface Workday itself chose to expose.

Where the Story Became Interesting

The orchestration compiled successfully. It uploaded successfully. The build passed.

Then runtime behavior told a different story.

The integration messages initially suggested that records were being updated, but when we checked the target data in Workday, the field remained blank. This is where the orchestration skill and the debugging approach became critical.

We improved the integration messages so they no longer reported success unconditionally. Instead, they logged:

• the worker identifier
• the source TOSD value
• the HTTP response status code
• the raw API response body

That one improvement changed the debugging process completely.

The 404 Root Cause

The next execution exposed the real issue immediately.

The API was returning a 404 with a response indicating that the tenant alias had effectively been treated as part of the resource path. The problem was not the worker reference, and it was not the payload. The issue was the REST path itself.

The tenant name had been hardcoded into the custom object API path:

/customObject/v2/<tenant>/customObjects/timeOffServiceDate?updateIfExists=true

Inside a tenanted Workday orchestration call, that was incorrect. The orchestration was already running in tenant context, so the tenant name should not have appeared inside the REST path.

The fix was to remove the tenant segment and use the tenant-relative service path:

/customObject/v2/customObjects/timeOffServiceDate?updateIfExists=true

This was a strong example of why build success is not enough. The orchestration compiled perfectly and still failed at runtime because the request path was semantically wrong.

It was also a strong example of why specialized skills outperform generic summarization. The orchestration skill knew to improve the logging around responseStatusCode and response.toString(). Once those details were visible in the integration event, the runtime error stopped being mysterious.

The Final Orchestration

After tenant discovery, API validation, iterative debugging, and the REST path fix, this is the orchestration that runs in production.

The main flow reads workers through WQL, loops through each row, compares source and target values, and delegates updates to the suborchestration only when needed. The suborchestration handles the REST call, branches on the response, and emits structured integration messages in both cases — success and failure.

What the Package Shows

The orchestration code, app-root snapshot, and the five skills used in this project are available on request. The point is not simply to say “AI helped.” The point is to show how the workflow can be read, challenged, and reproduced by another engineer.

Why This Feels Like a Copilot Story

What makes this worth documenting is not only the fix itself. It is the process.

We used natural language to coordinate:

• data-source discovery
• WQL query design
• WQL execution
• API validation
• orchestration design
• runtime debugging
• packaging and deployment through WDCLI

That is effectively a domain-specific copilot workflow for Workday Extend.

Instead of asking a generic model to improvise across every layer, we used specialized skills that each carried operational knowledge about one part of the platform. The result was more reliable reasoning, faster diagnosis, and fewer false assumptions.

The Bigger Picture

What this experiment points to is a pattern, not a one-off.

Natural language becomes much more valuable when it is connected to specialized skills, verifiable tools, and tenant-aware workflows. In that setup, AI is not just generating text. It is helping perform real delivery work across design, validation, deployment, and debugging.

The timing matters too. Workday’s WDCLI GA milestone created the practical surface area for this kind of experiment to matter. Once the platform lifecycle can be driven credibly from the terminal, it becomes reasonable to place a natural-language orchestration layer on top of it.

That is why this story is bigger than a single orchestration. It shows how an agent-based toolchain can function as a practical Workday Orchestration Copilot for builders using Codex, Claude, Gemini, OpenCode, or similar agent environments.

We’ll keep exploring this space — it feels like we’re just scratching the surface of what orchestration + natural language could become in Workday.