Du PowerPoint au système vivant : ce que le conseil doit désormais laisser chez le client

Pendant des décennies, le livrable a matérialisé la valeur du conseil : un rapport, une présentation au comité de direction, une recommandation structurée. L'IA ne rend pas ces formats inutiles. Elle rend en revanche beaucoup plus difficile de confondre le document qui restitue le travail avec la capacité que le client achète réellement.

La transformation la plus importante n'est donc pas le passage du PowerPoint à l'agent IA. C'est le passage d'un livrable conçu comme la fin de la mission à un dispositif qui continue à aider le client à décider, agir, mesurer ou apprendre après le départ des consultants.

La thèse défendue ici est la suivante : le bon livrable de demain n'est pas nécessairement un logiciel. C'est une capacité durable. Selon le problème, elle peut prendre la forme d'un agent supervisé, d'un dashboard actualisable, d'un simulateur, d'une méthode instrumentée, ou encore d'un document, lorsque le besoin est précisément de fixer une décision. Ce qui change, c'est le test final : qu'est-ce que le client saura encore faire, vérifier ou faire évoluer lorsque l'équipe de conseil ne sera plus là ?

En bref

• •Le corpus disponible montre un déplacement réel du conseil vers des artefacts opérationnels, des actifs réutilisables et des prestations plus continues.
• •Il ne démontre pas pour autant la disparition du PowerPoint, ni la supériorité systématique d'un agent ou d'une plateforme.
• •La technologie peut même créer une nouvelle dépendance si elle n'est accompagnée ni d'un propriétaire chez le client, ni de règles de gouvernance, ni de transfert de compétences.
• •La vraie rupture se situe donc moins entre document statique et outil numérique qu'entre restitution et capacité transférée.

Le PowerPoint n'est pas le problème

Une partie du conseil décrit aujourd'hui explicitement le passage « du document au système vivant » : des livrables prenant la forme de dashboards interactifs, d'agents supervisés, de simulateurs ou de plateformes capables d'être actualisés après la mission, prolongés par un delivery plus itératif — cadrage sur les résultats attendus, preuve rapide, puis éventuellement exploitation et amélioration continues.

Cette évolution mérite toutefois d'être interprétée avec prudence.

Le problème historique n'est pas qu'un cabinet produise un PowerPoint. Une présentation peut parfaitement être le bon objet pour cristalliser un choix stratégique, documenter les options d'un comité exécutif ou conserver la trace d'un arbitrage. Le problème apparaît lorsque la valeur s'arrête à la restitution, alors que la mission prétendait modifier durablement une manière de décider ou d'opérer.

Une recommandation sur la politique tarifaire qui finit dans un deck est fragile si les équipes ne savent pas reproduire l'analyse trois mois plus tard. Un nouveau modèle opérationnel reste théorique si personne ne sait mesurer les écarts au modèle cible. Une stratégie commerciale est incomplète si les équipes doivent rappeler le cabinet à chaque nouvelle simulation.

L'IA rend cette faiblesse plus visible parce qu'elle réduit le coût de fabrication d'une partie de l'analyse et de sa mise en forme. Elle déplace donc la question vers l'après : qu'est-ce qui reste une fois l'analyse produite ?

Ce que les données montrent réellement : l'impact du conseil peut survivre à la mission

Une étude NBER publiée en 2025 apporte un point de repère intéressant, même si elle ne porte pas sur l'IA. À partir de données administratives belges couvrant 2002 à 2023, les auteurs estiment qu'après le recours au conseil en management ou stratégie, la productivité du travail des entreprises clientes augmente en moyenne de 3,6 % sur cinq ans ; les salaires moyens augmentent également de 2,7 %. Les missions observées sont généralement ponctuelles et durent moins d'un an.

Ce que cela montre : les effets d'une intervention de conseil peuvent persister bien après la fin du contrat. La valeur du conseil ne se réduit donc manifestement pas à la consommation immédiate de l'équipe externe.

Ce que cela ne montre pas : l'étude ne permet pas d'attribuer ces effets à un type précis de livrable, encore moins à un agent, un dashboard ou un transfert de compétences. Elle porte essentiellement sur une période antérieure à la vague actuelle d'IA générative. Elle ne permet donc absolument pas de conclure qu'un « système vivant » produit plus de valeur qu'un rapport.

C'est précisément là que commence la réflexion organisationnelle : si l'impact peut durer, quels mécanismes permettent à une intervention extérieure de modifier durablement les comportements, les décisions ou les processus internes ?

Le livrable n'est qu'une partie de la réponse.

Trois signaux montrent néanmoins que les frontières bougent

Les pratiques actuelles des grands cabinets ne constituent pas une preuve représentative du secteur. Elles donnent en revanche des indications intéressantes sur la direction prise par certaines offres.

McKinsey : de l'outil interne à une architecture que le client peut s'approprier

McKinsey a développé Lilli comme plateforme interne permettant d'interroger le patrimoine de connaissances du cabinet. McKinsey indique que 72 % de ses collaborateurs utilisent la plateforme et fait état de gains allant jusqu'à 30 % sur la recherche et la synthèse. Plus intéressant pour notre sujet : le cabinet explique utiliser l'expérience acquise avec Lilli pour aider des clients à construire leurs propres systèmes comparables et propose une version de l'architecture sous-jacente pour certains usages clients. Il s'agit ici de chiffres et d'informations publiés directement par McKinsey, donc déclaratifs.

Ce cas ne prouve pas que tous les clients doivent disposer de leur propre Lilli. Il montre quelque chose de plus limité : un actif initialement conçu pour augmenter les consultants peut devenir un objet de transfert vers l'organisation cliente.

La logique change alors. La connaissance du cabinet n'est plus seulement utilisée pour produire une recommandation ; elle participe à la construction d'un mécanisme permettant au client d'accéder plus durablement à ses propres connaissances.

Deloitte et HPE : co-construire un outil utilisé dans la fonction finance

Deloitte et Hewlett Packard Enterprise déclarent avoir co-développé « CFO Insights », une solution combinant IA générative et agents sur la plateforme Zora AI de Deloitte. Deloitte présente par ailleurs Zora comme une architecture pouvant être fournie en SaaS ou installée dans les environnements cloud ou on-premise des clients.

Là encore, il s'agit d'un cas présenté par le fournisseur lui-même. Il ne fournit pas une évaluation indépendante du ROI et ne permet pas de généraliser.

Mais l'objet commercial est révélateur : le résultat de la relation de conseil n'est plus exclusivement une recommandation adressée au CFO. Il peut devenir un dispositif que la fonction finance continue à utiliser.

PwC : l'actif de conseil devient couche d'orchestration

PwC commercialise désormais un « agent OS » conçu pour orchestrer des agents provenant de plusieurs fournisseurs et les intégrer aux processus de l'entreprise, avec des fonctions de supervision. La plateforme est annoncée compatible avec un ensemble de systèmes et de fournisseurs comme Microsoft, AWS, Google Cloud, OpenAI, Anthropic, Salesforce, SAP ou Workday. Il s'agit, ici encore, d'une description commerciale publiée par PwC, non d'une démonstration indépendante de performance.

Le signal organisationnel est néanmoins intéressant : le cabinet ne vend plus seulement son expertise sur la manière d'organiser des agents. Il cherche aussi à fournir l'infrastructure permettant d'opérer cette organisation.

Ces cas ne permettent pas d'annoncer « la fin du livrable ». Ils montrent la montée d'un continuum nouveau entre conseil, logiciel, intégration et exploitation.

Ce continuum change aussi la manière de facturer

La transformation des livrables n'est pas indépendante du modèle économique.

Dans un entretien publié en 2026, le CEO de BCG indique que trois quarts des plus grands projets IA du cabinet comportent désormais une composante de rémunération variable liée à des résultats. Il précise immédiatement qu'à l'échelle de l'ensemble des activités de BCG, la proportion de missions utilisant ce type de mécanisme reste nettement inférieure à un tiers. Cette donnée est déclarative et provient du dirigeant du cabinet ; elle ne décrit donc pas l'ensemble du marché.

La nuance est importante.

L'IA ne provoque pas soudainement la naissance du value-based pricing : ces contrats existaient auparavant. Mais lorsqu'un cabinet fournit un dispositif qui continue à générer, mesurer ou influencer un résultat, il devient plus naturel de discuter usage, disponibilité, performance, licence ou outcome, plutôt que seulement jours consommés.

C'est aussi pourquoi l'asset-based consulting prend de la place dans les réflexions du secteur : diagnostics automatisés, agents sectoriels, plateformes, cockpits, jeux de données ou méthodes réutilisables deviennent des actifs à maintenir, versionner et parfois monétiser dans le temps.

Le cabinet se rapproche alors d'une activité de produit. Et avec elle apparaissent des problèmes que le deck n'avait pas : maintenance, propriété intellectuelle, sécurité, coût d'exploitation, versions, support et obsolescence.

Le piège : remplacer le « deck qui dort » par « l'agent qui dort »

Il serait facile d'en déduire qu'un bon cabinet doit désormais terminer chaque mission par un agent ou une plateforme.

Ce serait reproduire exactement l'erreur que l'IA est censée corriger : confondre transformation et équipement.

Un panel de trente entreprises observées pour leurs signaux organisationnels — non représentatif — le montre dans un autre contexte : plusieurs entreprises ont intégré de l'IA sans refondre fondamentalement leur organisation. L'outil peut donc progresser sans que les droits de décision, les responsabilités ou la division du travail évoluent réellement.

Un agent remis à un client peut subir le même sort qu'un rapport oublié.

Il suffit qu'aucune équipe n'en soit propriétaire, que les données cessent d'être actualisées, que personne ne sache interpréter les alertes, que le fournisseur du modèle change ses conditions ou que le processus métier évolue. L'objet reste techniquement disponible, mais la capacité organisationnelle a disparu.

Un système vivant n'est vivant que si l'organisation qui l'utilise sait le faire vivre.

C'est pourquoi la notion importante n'est pas « livrable technologique », mais capacité opérable.

Ce que le conseil devrait réellement laisser derrière lui

Une mission qui prétend transformer durablement une organisation devrait chercher à laisser cinq couches de valeur.

Un raisonnement transmissible. Le client doit comprendre les hypothèses, les critères et les arbitrages qui conduisent à une décision. L'IA ne réduit pas cette exigence : elle la renforce. Un résultat produit rapidement mais impossible à expliquer devient difficile à défendre.

Un mécanisme de réutilisation. Ce peut être un modèle de calcul, un simulateur, une grille, un workflow, un agent ou simplement une méthode suffisamment formalisée pour être rejouée sans reconstruire toute l'analyse.

Une preuve observable. Un système utile doit rendre visible ce qu'il produit : données sources, indicateurs, hypothèses, qualité, taux d'erreur, éventuelles exceptions — avec traçabilité, versioning des sources et prompts, tests et contrôle humain lorsque les artefacts IA deviennent opérationnels.

Une responsabilité interne. Quelqu'un chez le client doit savoir qui actualise, valide, arrête ou fait évoluer le dispositif. Sans propriétaire, un actif vivant devient rapidement un actif orphelin.

Une capacité humaine. Le client doit disposer de personnes sachant utiliser le mécanisme, en contester les résultats et le modifier lorsque son environnement change.

Cette dernière couche est probablement la plus importante.

Car un cabinet peut laisser derrière lui le meilleur simulateur du marché tout en augmentant la dépendance de son client. À l'inverse, une simple méthode, correctement comprise, pratiquée et intégrée au fonctionnement de l'entreprise, peut produire des effets durables.

Le « système vivant » n'est donc pas toujours un agent

La bonne forme dépend de la décision ou du travail que la mission cherche à améliorer.

Cette grille évite de transformer « système vivant » en échelle de maturité où l'agent serait nécessairement supérieur au document.

Un conseil d'administration qui doit décider d'une acquisition n'a pas forcément besoin d'un agent permanent. Il a besoin d'un dossier robuste et défendable.

Une direction pricing appelée à réviser ses prix chaque semaine a probablement davantage besoin d'un simulateur et d'un processus de décision réutilisable.

Une fonction support confrontée chaque jour à des milliers de demandes peut, elle, tirer parti d'un agent supervisé.

Le format doit suivre la nature de la décision, pas la mode technologique.

Ce changement oblige les cabinets à devenir partiellement des éditeurs, sans oublier qu'ils restent des cabinets

Dès qu'un cabinet laisse un actif opérationnel chez son client, la mission ne s'arrête plus totalement avec la restitution.

Qui maintient l'agent ? Qui adapte le simulateur à une nouvelle réglementation ? Qui vérifie que la donnée alimente toujours correctement le dashboard ? Qui finance une migration lorsqu'un fournisseur de modèle change ? Qui répond lorsque la recommandation automatique devient erronée ?

Ces questions rapprochent le cabinet du fonctionnement d'un éditeur ou d'un managed service.

Cela impose logiquement de gérer certains livrables comme des produits : propriétaire identifié, jeux de tests, protocoles de sécurité, versioning, maintien en condition opérationnelle, modèle de licence et arbitrage régulier entre maintenance et arrêt.

Mais il existe un risque symétrique.

Un cabinet obsédé par la « productisation » peut finir par ne chercher que des problèmes suffisamment standardisables pour utiliser ses assets. Le problème client devient alors l'occasion de vendre la plateforme, plutôt que la plateforme un moyen de résoudre le problème.

La différenciation du conseil reste précisément sa capacité à travailler dans des situations où le contexte, les rapports de pouvoir, les arbitrages et les comportements humains comptent.

Le système vivant ne doit donc pas supprimer le jugement du consultant. Il doit éviter de gaspiller ce jugement dans la reconstruction permanente de ce qui peut être codifié.

La question de la dépendance devient centrale

Un paradoxe apparaît ici.

Pour le client, le meilleur transfert est celui qui augmente son autonomie.

Pour le cabinet, un actif récurrent peut au contraire créer abonnement, consommation et revenus réguliers.

Ces deux intérêts ne sont pas nécessairement incompatibles. Mais ils doivent être explicités.

Un dashboard hébergé uniquement dans l'environnement du cabinet, impossible à exporter, peut prolonger la relation commerciale tout en réduisant l'autonomie du client. Un agent dont les prompts, les règles et les données sont opaques peut devenir une nouvelle boîte noire. Un simulateur exigeant chaque trimestre une intervention du cabinet pour changer trois hypothèses n'est pas vraiment une capacité transférée.

La question devient donc presque contractuelle :

Que peut encore faire le client le lendemain où il décide de ne plus travailler avec nous ?

Un cabinet peut légitimement protéger ses actifs préexistants et son patrimoine intellectuel, en distinguant les actifs du cabinet, les actifs co-créés et les données appartenant au client.

Mais le transfert de capacité suppose au minimum de rendre explicites les règles d'usage, les responsabilités, la réversibilité et le niveau d'autonomie réellement acquis.

Sans cela, le « système vivant » risque surtout de devenir un contrat vivant.

La nouvelle compétence rare : concevoir l'après-mission

Pour un partner ou un manager, cette évolution modifie la manière même de cadrer une mission.

Il ne suffit plus de demander : « Quel sera notre livrable final ? »

La meilleure question devient : « quelle capacité doit exister chez le client après la mission, et qu'est-ce qui doit rester humain pour qu'elle fonctionne ? »

Cette formulation oblige à penser beaucoup plus tôt à l'exploitation.

Elle change également la composition des équipes. Construire un simulateur robuste exige de relier expertise métier, données et expérience utilisateur. Mettre un agent en production exige des compétences d'intégration, d'évaluation et de gouvernance. Transférer une méthode exige pédagogie et conduite du changement.

Cela ne signifie pas que tous les consultants doivent devenir développeurs.

Cela signifie que la frontière entre « analyse », « design du dispositif », « implémentation » et « adoption » devient moins étanche.

Le cabinet doit savoir quand s'arrêter au conseil, quand construire, quand s'allier à un acteur technologique et quand organiser explicitement le transfert vers les équipes internes.

Ce que les données ne permettent toujours pas d'affirmer

À ce stade, aucune des sources examinées ne permet de démontrer que les missions laissant un agent ou un dashboard produisent systématiquement plus de valeur que celles se concluant par un rapport.

Les exemples actuels de cabinets développant des plateformes montrent surtout une évolution de l'offre. Les chiffres de performance publiés par les cabinets ou leurs partenaires restent souvent déclaratifs. Les données académiques disponibles sur les effets du conseil mesurent des résultats globaux mais n'identifient pas le rôle causal du format de livrable.

Il serait donc prématuré d'annoncer la mort du PowerPoint.

La déduction raisonnable est plus précise : plus le problème traité est continu, répétitif, mesurable et dépendant de données qui évoluent, moins un document statique peut suffire à lui seul. À l'inverse, plus le problème porte sur un arbitrage singulier, politique ou irréversible, plus un document structurant la décision peut conserver toute sa valeur.

Le basculement n'est pas idéologique. Il dépend du problème.

Auto-diagnostic : votre prochaine mission laissera-t-elle réellement quelque chose derrière elle ?

• •Le problème traité est-il ponctuel, ou continu après la fin de la mission ?
• •Avons-nous défini la capacité que le client doit posséder à la sortie, et pas seulement le livrable à remettre ?
• •Le client pourra-t-il rejouer l'analyse ou la décision avec de nouvelles données ?
• •Les hypothèses, sources et règles de décision resteront-elles accessibles et compréhensibles ?
• •Si nous livrons un agent ou un simulateur, existe-t-il des tests, des seuils de contrôle et un mécanisme de supervision humaine ?
• •Un propriétaire clairement identifié chez le client aura-t-il la responsabilité de faire vivre le dispositif ?
• •Les équipes savent-elles modifier ou challenger ce que nous leur laissons ?
• •Avons-nous distingué clairement notre propriété intellectuelle, les actifs co-créés et les données ou configurations appartenant au client ?
• •Le client sait-il ce qui se passe si les modèles, fournisseurs, données ou contraintes réglementaires changent ?
• •Notre dispositif augmente-t-il réellement l'autonomie du client, ou seulement sa dépendance à notre cabinet ?
• •Avons-nous prévu comment mesurer l'usage et la valeur après la restitution ?
• •Si le meilleur résultat de la mission reste finalement un document, pouvons-nous expliquer précisément pourquoi il est suffisant ?

La conviction

Le conseil ne doit pas chercher à laisser systématiquement plus de technologie chez ses clients.

Il doit chercher à laisser plus de capacité.

Parfois, cette capacité sera technologique : un agent, un cockpit, un simulateur ou une plateforme.

Parfois, elle sera organisationnelle : une nouvelle boucle de décision, des indicateurs, des rôles et des droits d'arbitrage.

Parfois, elle sera humaine : des managers capables d'utiliser le dispositif, d'en challenger les résultats et de continuer à progresser sans le cabinet.

Le PowerPoint devient insuffisant lorsque la mission porte sur un problème vivant et que le document ne sait pas vivre avec lui.

Mais l'agent devient tout aussi insuffisant lorsqu'il est remis sans propriétaire, sans gouvernance et sans personnes capables de le superviser.

La transformation du livrable n'est donc pas le passage du slide au software. C'est le passage de la recommandation à l'autonomie opérationnelle.