Votre pilote IA mesure-t-il le coût du processus complet ?

L’usage généralisé de l’IA n’est pas encore devenu une valeur à l’échelle de l’entreprise

Une démonstration d’IA peut montrer qu’une tâche fonctionne tout en laissant la décision d’investissement en suspens. Des employés pris individuellement peuvent gagner du temps, mais le passage à l’échelle exige des preuves que l’ensemble des opérations améliore les résultats de l’entreprise. L’enquête mondiale 2025 de McKinsey montre l’écart entre l’usage généralisé et l’impact à l’échelle de l’entreprise, mesuré par le bénéfice avant intérêts et impôts, ou EBIT. McKinsey vend des services de conseil, notamment un accompagnement à l’adoption de l’IA, de sorte que la demande en stratégie et mise en œuvre de l’IA profite à son activité.

Le passage de l’expérimentation à la production présente aussi des difficultés au-delà de l’IA générative, qui crée du contenu comme du texte et des images. Gartner a constaté qu’en moyenne 41% des prototypes d’IA générative atteignaient la production, contre 42% des prototypes d’IA non générative. Gartner vend des études et des conseils aux acheteurs de technologies, ce qui lui donne un intérêt commercial à aider les organisations à prendre ces décisions d’investissement. Ces taux de mise en production similaires suggèrent que les deux catégories rencontrent des difficultés de déploiement : un projet pilote réussi laisse encore en suspens la question de savoir comment l’organisation exploitera le système.

Le passage à l’échelle exige un business case pour l’ensemble du workflow

Ces questions de déploiement changent la manière dont les dirigeants doivent évaluer les gains de productivité d’un projet pilote. Un business case de passage à l’échelle doit prendre en compte le retour sur l’ensemble du workflow, y compris les contrôles, l’intégration, la validation et la responsabilité. L’expérimentation peut avancer rapidement parce qu’une petite équipe sélectionne les entrées, traite manuellement les exceptions et juge directement les sorties. En production, l’organisation doit fournir ces conditions de manière répétée dans le cadre des opérations courantes.

Le fonctionnement répété modifie donc l’évaluation selon six dimensions : les données, le workflow, la revue, l’intégration, l’évaluation et l’accès. Une démonstration peut montrer qu’une sortie est utile tout en laissant sans réponse la manière dont les enregistrements actuels parviennent au système, qui peut y accéder, qui examine le résultat et comment celui-ci revient dans les logiciels opérationnels. Chaque question non résolue crée un travail que quelqu’un devra financer et prendre en charge. Les gains pour un utilisateur peuvent donc créer des obligations ailleurs.

Un meilleur modèle peut améliorer la qualité des sorties ou réduire les coûts de génération, mais le workflow a toujours besoin d’informations fiables, de contrôles, d’évaluation et d’une autorité clairement définie. Avant d’approuver une extension, les dirigeants doivent identifier qui fournit l’information, qui accepte la sortie et qui intervient lorsque le système échoue. Ces responsabilités déterminent si la tâche démontrée peut devenir une opération répétable. Elles doivent figurer dans le business case parce qu’elles influent sur l’approbation, le coût récurrent et la responsabilité.

Une sortie fiable commence par des données en direct fiables

La première exigence opérationnelle est une information qui reste exploitable lorsque le projet pilote passe sur des systèmes en direct. L’enquête 2026 RSM Middle Market AI a classé la qualité des données comme principal frein signalé, suivie des préoccupations de sécurité et de confidentialité. L’intégration des systèmes legacy et les lacunes en talents figuraient également en bonne place. RSM fournit des services de conseil, notamment un accompagnement à la mise en œuvre technologique, de sorte que les entreprises investissant dans des solutions à ces problèmes représentent une opportunité commerciale pour le cabinet.

La préparation des données apparaît également dans les recherches de Gartner et dans l’étude 2026 State of AI de NVIDIA. Les résultats portent sur des populations et des questions différentes, de sorte que chacun doit conserver sa propre portée. NVIDIA fournit du matériel et des logiciels de calcul pour l’IA, et en tire un bénéfice commercial lorsque les organisations étendent le déploiement de l’IA.

Les prévisions d’abandon de Gartner concernent les projets sans données prêtes pour l’IA. Pour une décision de financement, la question est de savoir si le workflow proposé peut obtenir des informations cohérentes et suffisamment à jour dans des conditions d’exploitation réelles. Un projet pilote peut laisser cette question sans réponse en utilisant un export propre, une base de connaissances sélectionnée ou un petit échantillon de tickets.

L’écart devient visible lorsqu’une équipe illustrative relie son projet pilote réussi à des systèmes en direct contenant des doublons et des définitions incompatibles. Certaines informations se trouvent derrière un service SOAP fragile, une interface d’échange de messages structurés, tandis que d’autres enregistrements résident dans un système de planification des ressources de l’entreprise vieux de 15 ans. Un travail qui a demandé deux semaines pour être prototypé peut alors exiger un effort d’intégration sur plusieurs trimestres. La tâche du modèle reste la même, mais l’alimentation de ses entrées est devenue un engagement d’ingénierie substantiel.

Cet engagement change ce que la démonstration a établi. Un export préparé peut montrer qu’un modèle exécute une tâche tout en laissant sans réponse l’accès continu à des informations comparables. Les équipes disposant d’un accès limité ou d’une capacité d’intégration réduite sont donc désavantagées lorsque l’approbation commence par l’exigence d’une démonstration. Produire la preuve peut être simple, même si reproduire ses conditions d’entrée en production reste difficile.

L’accès continu exige aussi un accord sur la signification des enregistrements. Si deux systèmes définissent différemment le même client, ajuster le prompt ne permet pas d’établir quelle définition l’entreprise considère comme faisant autorité. Les doublons peuvent amener la récupération, c’est-à-dire le processus consistant à aller chercher les informations pertinentes, à renvoyer des informations contradictoires, tandis que des enregistrements obsolètes peuvent rendre opérationnellement fausse une réponse pourtant clairement rédigée. La qualité des réponses peut donc changer même si le prompt reste le même.

Pour maîtriser cette variation, établissez une source faisant autorité pour chaque entité importante, comme un client ou un compte. Définissez un contrat de données : un accord couvrant la structure et la signification des informations échangées. Maintenez à jour le contexte récupéré et fixez des attentes en matière de latence de récupération, c’est-à-dire le temps nécessaire pour obtenir les enregistrements requis. Ces exigences rendent la signification des enregistrements et le temps d’accès suffisamment prévisibles pour que le workflow puisse en dépendre.

Un accès prévisible doit aussi résister aux changements apportés aux systèmes qui fournissent les enregistrements. Lorsqu’une application amont modifie un champ ou une interface, les applications qui utilisent cette information ont besoin d’un moyen contrôlé de continuer à fonctionner. La maintenance de l’interface devient une partie de la livraison dès lors que l’IA se connecte aux systèmes d’enregistrement. Cet entretien consomme de la capacité d’ingénierie et affecte la planification des releases pendant toute l’exploitation du système.

La gouvernance détermine les comportements autorisés

Un accès fiable soulève la question opérationnelle suivante : quels enregistrements le système d’IA peut-il récupérer et utiliser ? Prenons le cas d’un Copilot pour agent de support qui fonctionne bien dans un sandbox, mais qui nécessite des informations personnellement identifiables, ou PII, en production. Ses suggestions doivent être traçables, et quelqu’un doit maintenir ses prompts, ses politiques et ses évaluations. Ces obligations affectent à la fois l’approbation initiale et l’exploitation continue.

La rédaction de réponses aux clients montre comment ces obligations traversent les frontières entre applications. Le système peut combiner un enregistrement de gestion de la relation client, ou CRM, avec l’historique des tickets, puis écrire un brouillon dans un système d’enregistrement. L’approbation dépend donc des champs qu’il peut lire, des informations qui doivent être masquées et des enregistrements de prompts et de sorties qui doivent être conservés. Choisir un modèle laisse à l’organisation ces décisions d’accès et de responsabilité.

L’organisation peut rendre ces décisions vérifiables en exprimant la gouvernance sous forme d’exigences opérationnelles. Les équipes d’ingénierie et de risque doivent voir le comportement autorisé et les contrôles qui l’appliquent avant le début de l’usage courant. Chaque contrôle doit aussi avoir un responsable qui l’entretient et intervient lorsqu’il échoue.

Ces contrôles deviennent particulièrement déterminants avec l’IA agentique, des systèmes qui récupèrent des informations, invoquent des outils logiciels et exécutent des actions à travers les applications. Les autorisations limitent leurs actions, tandis que les logs enregistrent ce qu’ils ont réellement fait. Les responsables désignés enquêtent ensuite et réagissent lorsqu’une action provoque un problème. La gouvernance doit donc façonner l’architecture et son fonctionnement dès le départ.

La validation doit se poursuivre après le déploiement

L’autorisation d’exploiter laisse encore ouverte la question de savoir si le système se comporte de manière acceptable dans le workflow prévu. L’étude 2026 State of AI de NVIDIA a montré que 38% identifiaient la pénurie d’experts en IA comme un défi majeur. Le constat distinct de RSM sur les lacunes en talents concerne une population d’enquête différente. Pour une équipe de mise en œuvre, les besoins en effectifs doivent inclure des personnes capables de tester, d’évaluer et de maintenir le comportement de l’IA pendant l’exploitation.

Sans cette capacité, les équipes Security, Legal et Risk peinent à déterminer si le système répond aux exigences de l’organisation. Des attentes floues compliquent aussi la réponse aux incidents, car les personnes peuvent ne pas être d’accord sur le fait qu’une sortie était une erreur ou un comportement attendu. La pression du temps, une couverture de test incomplète et un accès limité à des données représentatives accroissent cette incertitude. Une démonstration ne peut pas trancher la question si ses exemples omettent des défaillances importantes pour le workflow.

L’exemple d’un grand modèle de langage, ou LLM, qui rédige des notes de version à partir d’enregistrements Jira et de pull requests en montre la conséquence. Les pull requests proposent des modifications de code, et le résumé généré peut être bien rédigé tout en omettant une modification cassante qui oblige les utilisateurs à changer leurs implémentations. Le support reçoit alors les problèmes qui en résultent. Le temps de revue devient donc une décision budgétaire, car l’automatisation du brouillon laisse en place le travail de vérification et les risques associés.

Pour rendre la vérification répétable, attribuez un responsable de l’évaluation et définissez des seuils de réussite/échec en fonction des conséquences d’un échec. Les mesures peuvent inclure l’exactitude, l’ancrage factuel (dans quelle mesure une réponse est étayée par les enregistrements sous-jacents), la latence de réponse et la fréquence à laquelle les personnes passent outre le système. Les risques du workflow et l’usage prévu doivent déterminer quelles mesures comptent. La validation devient alors un travail d’ingénierie récurrent avec une exigence explicite en matière d’effectifs.

L’évaluation récurrente a besoin d’un processus de réponse après la mise en production. Lorsque le comportement dérive, c’est-à-dire lorsque les performances s’écartent du niveau accepté, l’équipe doit savoir quelle action déclenche un seuil non atteint. Un petit groupe réunissant produit, ingénierie, sécurité et le responsable métier peut traduire les risques business en contrôles mesurables. Le groupe doit mettre à jour ces contrôles à mesure que les prompts, les modèles et les politiques changent, car l’approbation d’une configuration n’établit pas son acceptabilité dans la durée.

Mesurez le coût complet et financez les conditions de création de valeur

L’évaluation récurrente s’ajoute au coût du workflow de rédaction pour le support client présenté plus haut, aux côtés du routage, de la rédaction expurgée, de l’échantillonnage d’assurance qualité et de la correction urgente de brouillons erronés mais formulés avec assurance. Ensemble, ces activités peuvent absorber le temps gagné lors de la rédaction de chaque ticket. La décision d’investissement a donc besoin d’une mesure du processus complet. Mesurer uniquement l’étape automatisée laisse l’organisation incapable d’évaluer son retour opérationnel.

Le premier sprint de développement après une démonstration peut révéler des travaux d’intégration, de revue et de gestion des incidents omis du budget du projet pilote. Les mesures d’usage peuvent masquer ce changement : prompts par jour, démonstrations réalisées et licences achetées montrent de l’activité tout en laissant hors du décompte la gestion des autorisations et la revue humaine. Un système très utilisé peut donc sembler réussi avant que son coût d’exploitation soit compris. Le business case doit relier cette activité à un résultat défini.

La recherche documente cette difficulté à évaluer la valeur financière. Les réponses de chefs de projet dans une étude du troisième trimestre 2025 ont identifié le retour sur investissement, ou ROI, peu clair et les ressources limitées comme des obstacles à l’adoption. L’étude 2026 State of AI de NVIDIA a séparément montré que 30% identifiaient un ROI peu clair comme un défi majeur. Ces deux constats portent sur la difficulté à établir un retour valable de la mise en œuvre.

La recherche de Gartner d’avril 2026 ajoute une comparaison des dépenses. Seuls 39% des responsables technologiques interrogés étaient convaincus que leurs investissements actuels dans l’IA amélioreraient la performance financière. Les organisations déclarant des initiatives d’IA réussies investissaient jusqu’à quatre fois plus dans les fondations, en pourcentage du chiffre d’affaires, que celles déclarant de mauvais résultats. Gartner incluait parmi ces fondations la qualité des données, la gouvernance, des personnes préparées à travailler avec l’IA et la conduite du changement.

La comparaison porte sur l’investissement rapporté au chiffre d’affaires et sur les résultats déclarés ; elle n’établit pas qu’un niveau plus élevé de dépenses de fondation cause le succès, ni ne compare les budgets absolus. Pour un workflow particulier, les dirigeants doivent encore juger ce que ces dépenses rendent possible. La préparation des données peut soutenir une livraison répétable, la gouvernance peut autoriser un usage approuvé, et des équipes préparées peuvent soutenir l’exploitation. Ces exigences consomment des ressources tout en créant les conditions dans lesquelles l’application peut produire de la valeur.

Financer ces conditions est compatible avec une évaluation financière stricte. Traiter chaque coût de fondation comme une dépense à réduire peut compromettre le workflow que l’organisation entend exploiter. Pourtant, une organisation bien préparée peut quand même choisir un mauvais cas d’usage. La décision doit donc prendre en compte à la fois les fondations nécessaires et la valeur de l’application spécifique.

Trois erreurs stratégiques empêchent cette évaluation. Une équipe peut choisir une application séduisante sans la relier à une contrainte opérationnelle mesurable. Elle peut omettre l’intégration, la revue, le monitoring et la gestion des exceptions dans son estimation. Ou elle peut laisser non définies les preuves justifiant l’extension, la révision ou l’arrêt, permettant à l’activité de se poursuivre sans critère de décision.

Pour établir ce critère, commencez par un goulot d’étranglement connu et une mesure principale de résultat. Enregistrez une baseline pré-IA afin que le workflow existant et celui proposé puissent être comparés selon la même définition du succès. La baseline donne un sens business aux gains de temps ou aux améliorations de qualité. Elle précise aussi quel résultat opérationnel l’investissement est censé modifier.

Une fois le résultat défini, décidez quelles fondations livrer ce trimestre et quels travaux différer. Le prochain livrable peut être un accès fiable aux données, un harnais d’évaluation (une configuration répétable pour exécuter des tests), du monitoring ou un processus de revue. Choisissez-le en fonction de ce qu’exige le prochain test significatif. Cette séquence concrétise l’investissement et met en évidence le travail nécessaire avant qu’une autre release puisse être évaluée.

Avant de financer cette release, convenez d’un kill gate : un point de décision où les résultats sont comparés à des critères prédéfinis de résultat et d’économie, avec l’autorité d’arrêter. Le package opérationnel doit inclure un accès aux données borné avec journalisation, une interface d’intégration fiable, une évaluation dotée en effectifs et un responsable de workflow comptable de ses actes. La demande de financement doit expliquer comment l’organisation soutiendra ces responsabilités en plus de la fonctionnalité. Elle doit aussi indiquer comment la baseline et le kill gate gouverneront la décision suivante.

Utilisez ces critères pour autoriser l’extension lorsque les résultats mesurés du workflow justifient l’investissement complet. Révisez lorsqu’un changement identifié a une chance crédible d’améliorer le résultat, et arrêtez lorsque le workflow ne peut pas satisfaire aux exigences convenues de résultat et d’économie. Cela donne aux dépenses de fondation un objectif précis : permettre un test équitable d’une valeur répétable. Les applications qui restent non économiques une fois ces coûts pris en compte doivent être arrêtées.

Une responsabilité claire donne aux employés un workflow exploitable

Un responsable comptable de ses actes doit aussi définir comment les employés peuvent utiliser le système dans le cadre d’un travail à conséquences. L’enquête 2026 Middle Market AI de RSM a montré que 36% des organisations avaient pleinement intégré l’IA dans leurs processus centraux. Des gains de productivité individuels peuvent donc se produire alors que les dispositifs opérationnels plus larges restent inchangés. Le simple accès à l’outil laisse les employés avoir besoin de règles pour examiner les sorties et agir en conséquence.

La refonte du workflow répond directement à cette question opérationnelle. La recherche 2025 de McKinsey a montré que 21% des répondants utilisant l’IA générative déclaraient que leurs organisations avaient fondamentalement repensé au moins certains workflows. Parmi les attributs organisationnels testés par McKinsey, la refonte des workflows présentait la relation la plus forte avec l’impact sur l’EBIT à l’échelle de l’entreprise. Cette relation n’établit pas une causalité, mais elle donne aux dirigeants une raison d’examiner la manière dont le travail est autorisé parallèlement aux décisions d’accès.

Lorsque l’autorisation reste floue, l’évitement et l’usage dissimulé peuvent coexister. Certains employés refusent des outils dont ils ne peuvent pas résoudre les risques, tandis que d’autres les utilisent en dehors d’une supervision prise en charge. Des ingénieurs peuvent coller des extraits dans des outils de chat publics, la sécurité découvrant ensuite ce comportement. C’est du shadow AI : un usage en dehors de processus organisationnels auditables et pris en charge, qui peut découler des mêmes règles manquantes que celles qui découragent l’adoption visible.

L’exemple d’un Copilot d’astreinte ou de support montre comment l’absence de règles affecte les décisions pendant un incident. L’outil recommande une action, mais l’opérateur ne peut pas l’étayer parce que les runbooks et les règles d’escalade n’ont pas changé. Sous pression, le commandant d’incident rejette la recommandation. Les utilisateurs peuvent alors juger l’IA inefficace alors même que le workflow n’a jamais établi si la recommandation était consultative, si son exécution était autorisée, ni quelles preuves l’une ou l’autre décision exigeait.

La résolution de cette incertitude commence par les utilisateurs autorisés, les sorties acceptables, les responsabilités de revue et la gestion des incidents. Les processus de contrôle du changement et de réponse doivent distinguer les suggestions que les personnes peuvent examiner des actions qu’elles peuvent exécuter. Les runbooks et les circuits d’escalade doivent refléter ces décisions. La formation peut expliquer les règles qui en résultent, mais l’attribution de l’autorité et des exigences de preuve relève de la responsabilité de l’organisation.

Une politique d’usage légère liée aux classes de données aide les employés à appliquer ces limites dans le travail courant. Le responsable du workflow doit être comptable de la qualité et de l’adoption, afin que les employés disposent d’un processus pris en charge pour gérer le risque. Lorsque l’adoption est faible, vérifiez si ce processus est praticable et autorisé. Demander davantage d’enthousiasme laisse le déficit de responsabilité sans réponse.

Faites correspondre la prochaine intervention à la release bloquée

Le déficit de responsabilité est une contrainte possible, de sorte que la première intervention doit suivre les éléments de preuve sur ce qui bloque la livraison. Prenons trois projets pilotes menés en parallèle : l’un continue de circuler entre revues d’approbation, un autre échoue lorsqu’il rejoint des enregistrements en direct, et un troisième n’a pas de définition du succès. Leur appliquer à tous le même programme d’amélioration retarde le travail dont chacun a besoin. Leurs symptômes différents exigent des points de départ différents.

Pour choisir un point de départ, examinez les journaux d’incidents et les constats d’audit SOC 2, qui proviennent d’une évaluation des contrôles organisationnels. Identifiez le symptôme, établissez ce qui empêche la release, puis sélectionnez une intervention qui y répond. Les cinq catégories ci-dessous fournissent une structure de diagnostic ; un projet pilote individuel peut n’en rencontrer que certaines.

Utilisez le diagnostic pour sélectionner le plus petit changement de fondation qui permette un test significatif dans la prochaine release. Une équipe peut avoir besoin d’une interface stable avant de pouvoir tester le fonctionnement en direct ; une autre peut avoir besoin d’un responsable de l’évaluation avant que de nouveaux développements soient utiles. Les équipes disposant d’un accès limité, d’une capacité d’intégration réduite ou d’effectifs de validation restreints peuvent alors orienter leurs efforts rares vers leur contrainte spécifique. La prochaine demande de financement peut nommer le test bloqué, l’intervention qui le rend possible et la personne responsable de la livraison.

Recap

Un projet pilote d’IA réussi établit qu’une tâche peut fonctionner dans des conditions sélectionnées. L’extension exige un jugement différent : savoir si l’organisation peut exploiter l’ensemble du workflow de manière fiable et avec un retour valable. Ce jugement doit inclure le coût de fourniture des données en direct, du maintien des contrôles, de la revue des sorties et de la gestion des exceptions.

Pour les dirigeants, la prochaine décision porte donc moins sur la rapidité avec laquelle il faut passer l’IA à l’échelle que sur la contrainte à résoudre avant d’engager davantage de capital. Un projet pilote bloqué par des enregistrements incohérents nécessite un investissement différent de celui qui attend une approbation d’accès ou qui manque d’une mesure convenue du succès. Le financement doit traiter la barrière spécifique et produire des preuves pour la décision suivante.

Exigez que chaque demande d’extension nomme le responsable du workflow comptable de ses actes, le résultat mesuré par rapport à une baseline pré-IA et le coût opérationnel complet. Convenez à l’avance des résultats qui justifient l’extension, la révision ou l’arrêt. Cela donne aux équipes la possibilité d’apprendre sans permettre à l’expérimentation de devenir un engagement indéfini.

Des fondations fiables rendent possible un test équitable ; elles ne garantissent pas une application valable. Passez à l’échelle lorsque les résultats mesurés justifient l’investissement complet, et arrêtez lorsqu’ils ne le justifient pas.