L’analyste métier à l’ère des agents IA

L’IA peut générer le plan d’un cas d’utilisation en moins d’une minute, transformer une idée simple en prototype de base en une heure et produire la documentation des exigences en une fraction du temps qu’elle prenait auparavant. Ce changement est déjà visible dans l’analyse métier quotidienne, les praticiens utilisent l’IA pour préparer les séances d’élucidation, rédiger les exigences et identifier les lacunes avant la validation. Si l’on ne regarde que ces livrables, la conclusion semble évident: l’analyste métier disparaît.

I do not share that conclusion. I have worked in business and IT analysis, solution design and digital transformation for years, watching continuous change and different stages of adaptation. What is disappearing is not the role. What is disappearing is its periphery. And that is something entirely different.

Ce que fait un analyste

When you ask a customer what they need, they tell you what they want. Those are not always the same thing. Not because they do not understand their own work – they simply cannot always articulate their needs well enough. Routine activities often go unmentioned because customers perform them automatically, every day. Edge cases are easily missed because people tend to remember them only when they occur.

Les connexions entre les départements sont perçues d’un point de vue personnel, pas nécessairement du point de vue global. Et lorsqu’un client décide de modifier plusieurs systèmes simultanément, il ne voit souvent pas que changer un système modifie presque toujours aussi un processus.

Le travail de l’analyste n’est pas de consigner ce que le client a dit. Il s’agit de découvrir ce que le client n’a pas exprimé, et de continuer à poser des questions jusqu’à ce que tout apparaisse. L’analyste trace les connexions, les dépendances et les conséquences à travers les systèmes, les données et les processus métier.

That is a diagnostic capability, not an administrative activity.

Trois orientations pour les analystes métier

The boundaries of business analysis have never been fixed. Analysts have long moved into product ownership, project management and more technical roles. AI is simply accelerating that movement by reducing the time required for routine deliverables.

Une récente enquête Gartner a révélé que plus de la moitié des organisations avaient redessiné ou redéfini des rôles à cause de l’IA, tandis que 78 % des responsables RH ont convenu que les flux de travail et les rôles devront permettre de réaliser la valeur de leurs investissements en IA.

From my observations and direct experience, three main trajectories are taking shape.

1. Vers le produit et le métier

Analysts who enjoy shaping products may move into broader roles spanning product ownership, business analysis and delivery coordination. Such combinations already exist, particularly in smaller teams. As AI reduces the time spent producing routine artifacts, the boundaries between these responsibilities are likely to become more fluid.

This should not mean handing four jobs to one person simply because AI can write the documents. The opportunity lies in bringing together responsibilities that already depend on the same understanding of customer needs, product priorities and business outcomes.

This direction also requires a stronger understanding of data. Analytical work has often focused on processes, functionality and requirements while leaving the data layer in the background. AI systems make that separation increasingly difficult.

An analyst who understands both the business context and the data can recognize when a model is correctly answering the wrong question. That may happen because the available data does not represent the situation accurately, the business definition behind a metric has changed or the original question was poorly framed.

AI can help almost anyone create a dashboard or report. Interpreting what the result means for a particular business, at a particular moment, still requires context and judgement. Forrester describes a similar change across software roles, with AI moving time away from repetitive artifact production and toward activities such as validation, orchestration and control.

2. Vers le prototypage technique

Analysts with a strong affinity for development may be able to speak with a customer and then build a working prototype – not merely a mock-up, but something the customer can test and validate.

This changes requirements validation: customers can interact with an idea instead of trying to interpret it from a document. Misunderstandings can surface earlier, while changes are still relatively inexpensive to make.

But a prototype is not a production system.

Security, integration, scaling and performance under load are not solved by “AI helps me code”. Building enterprise software for production requires a different level of engineering expertise. Some analysts may gradually develop those skills and move closer to production-level development. It is a considerably more demanding path than rapid prototyping suggests, but it is a realistic one.

3. Vers la gestion de projet et de livraison

Analysts already coordinate customer discussions, contribute to estimates and manage questions around scope, requirements and change. That creates a natural overlap with project management.

On smaller projects, one person may be able to combine analytical and coordination responsibilities because both depend on understanding scope, stakeholders and dependencies. That can shorten communication paths and make it easier to connect day-to-day delivery decisions with the original business need.

This does not make the project manager redundant. On larger projects, where coordinating people, risks and dependencies is genuinely complex, project management remains a specialist discipline. The blended approach makes sense only where the scope allows it.

The distinction matters. AI may reduce the effort required to create plans, meeting summaries or status reports, but producing those artifacts was never the full value of project management either.

Ce qui distingue ceux qui s’y débrouillent bien

All three directions require analysts to move beyond familiar role boundaries. Curiosity gives them the willingness to test new tools and approaches. Continuous learning prevents what I think of as knowledge debt: the gradual accumulation of outdated assumptions and skills, much like technical debt in a legacy system.

Perhaps most important, however, is the ability to verify. Analysts are accustomed to asking “Is this actually correct?” before asking “Is this done?” In an environment full of fluent, professionally presented AI outputs, that habit becomes more valuable.

AI can produce incorrect answers in a confident and persuasive form – a pattern highlighted by MIT Sloan researchers as one of the key reasons human oversight remains essential. Its outputs can be structured, fluent and polished.

Failure does not happen at the point of using AI. It begins when a plausible output is accepted without verification.

La question n’est pas de savoir si les analystes métier disparaîtront

Many articles about the future of the analyst role are written as predictions. This is not a prediction. It is an observation: the role is changing as it always has. What is different this time is the speed – and the fact that its periphery is becoming accessible to almost anyone.

A developer can use AI to conduct requirements analysis. A manager can use it to generate user stories. They may not do either particularly well, but an analyst whose value rests solely on producing deliverables will have a difficult time.

What remains at the center of the role is the ability to uncover unstated needs, connect business and technical contexts, verify outputs and see connections that the customer cannot. According to IIBA’s 2025 Global State of Business Analysis Report, 74% of practitioners say AI is positively affecting their careers, while human skills such as communication, strategic thinking and adaptability are becoming more important.

The question is not whether business analysis will disappear. It is what remains when its periphery becomes available to everyone.

The answer is the judgment that takes years of practice, varied projects and experience with failure to develop. It is the ability to recognize that a documented requirement is incomplete, a working prototype solves the wrong problem, or a polished answer rests on a false assumption.

That is the part of business analysis that cannot be acquired quickly.