Ce que les chiffres d’utilisation de l’IA ne disent pas

La décision déterminante en matière d’IA est de savoir qui peut changer le travail

Une équipe peut avoir accès à l’IA et ne toujours pas avoir l’autorisation d’améliorer la livraison. Si chaque modification du workflow exige l’approbation d’un comité, l’équipe reste responsable des résultats tandis que les dirigeants contrôlent la manière dont elle peut les atteindre. Pour un dirigeant qui vise des gains à l’échelle de l’entreprise, la décision clé porte sur le niveau d’autorité dont disposeront les équipes pour modifier le travail et sur les preuves qu’elles devront ensuite produire.

Le modèle d’adoption conventionnel laisse cette décision en suspens. Les organisations achètent des outils, conservent les procédures existantes et rendent compte du nombre de licences ou de l’usage, alors même que l’efficacité reste faible, que la compétitivité progresse lentement et que la qualité demeure coûteuse. L’usage individuel de l’IA peut rendre certaines tâches plus simples ou plus rapides. Pour transformer ces gains en performance d’entreprise, les dirigeants doivent examiner comment des tâches plus rapides deviennent du travail effectivement réalisé, des coûts plus faibles et de meilleurs résultats business.

Les retours à l’échelle de l’entreprise justifient d’examiner la refonte des workflows

Les résultats financiers donnent aux dirigeants une raison d’examiner ce lien. McKinsey indique que 39 % des organisations constatent un impact lié à l’IA sur l’EBIT, ou résultat avant intérêts et impôts, la plupart faisant état d’un impact inférieur à 5 %. Acheter et déployer l’IA laisse donc une question business majeure sans réponse : l’investissement modifie-t-il l’économie du travail qu’il soutient ?

Les conclusions du MIT ramènent cette question au niveau des projets pilotes individuels. L’institut a constaté que la plupart des projets pilotes d’IA générative en entreprise ne produisaient aucun retour mesurable sur le P&L, ou compte de résultat, et a attribué ces faibles résultats à des difficultés d’intégration et à un déficit d’apprentissage. Un projet pilote peut montrer qu’un outil exécute une tâche alors que l’organisation peine encore à l’intégrer aux opérations quotidiennes. La valeur financière dépend de ce qui se passe ensuite.

Les difficultés d’intégration peuvent commencer avec la structure du workflow existant. Une organisation divise le travail en étapes en partant du principe que des personnes exécuteront chaque étape manuellement, puis ajoute un modèle d’IA tout en conservant la séquence. Le modèle peut accélérer une activité, mais les transferts, revues et décisions environnants se poursuivent comme avant. Les personnes apprennent à utiliser l’outil dans le cadre de responsabilités et de procédures établies, tandis que le processus conserve une grande partie de son coût et de ses délais d’origine.

Les conclusions de McKinsey rendent ici la refonte des workflows pertinente : les entreprises les plus performantes dans la capture de l’impact de l’IA étaient presque trois fois plus susceptibles d’avoir fondamentalement modifié leurs workflows. La relation observée est une association entre de meilleures performances et une refonte. Elle donne aux dirigeants une pratique précise à examiner lorsque l’investissement déçoit.

Le MIT et McKinsey traitent de différentes dimensions du problème de management. Le MIT relie les faibles retours des projets pilotes à des difficultés d’intégration et d’apprentissage, tandis que McKinsey relie un impact plus fort à des changements substantiels de workflow. Leurs conclusions portent sur des mesures différentes et doivent rester distinctes. Pour comprendre dans quelle mesure un développeur individuel gagne à avoir accès à l’IA, les dirigeants ont besoin de preuves au niveau des tâches.

Les expériences de Metr montrent pourquoi la productivité exige une mesure rigoureuse

La question au niveau des tâches a produit un résultat frappant dans l’essai randomisé de Metr au début de 2025. L’organisation de recherche sur l’IA a étudié des développeurs expérimentés en open-source et a fait varier le fait qu’ils puissent ou non utiliser l’IA. Lorsque l’IA était autorisée, l’exécution des tâches prenait environ 19 % de temps en plus, alors même que les développeurs pensaient avoir réalisé le travail environ 20 % plus vite. Leur expérience d’utilisation de l’outil allait dans la direction opposée à leur performance mesurée.

Cet écart est important, car la confiance dans un outil peut devenir un substitut informel à l’évaluation. Le jugement d’un développeur selon lequel l’IA l’a aidé peut décrire avec justesse la manière dont le travail a été vécu tout en déformant le temps réellement nécessaire. Ainsi, des dirigeants s’appuyant sur le seul enthousiasme auraient tiré une conclusion erronée sur la vitesse d’exécution des tâches dans cet essai.

Lorsque Metr a répété l’expérience plus tard en 2025, les estimations ont changé de sens. Parmi les 10 développeurs revenus de l’étude initiale, l’estimation suggérait que le travail était réalisé environ 18 % plus vite. L’amélioration estimée parmi les 47 développeurs nouvellement recrutés était d’environ 4 %. Il s’agissait de groupes distincts ; combiner leurs estimations en un seul résultat masquerait donc les différences entre les participants.

Ces deux estimations ultérieures comportaient également une forte incertitude statistique. Leurs intervalles de confiance, c’est-à-dire les plages exprimant l’incertitude autour des effets estimés, chevauchaient zéro, incluant à la fois une accélération possible et un ralentissement possible. La direction de l’effet restait donc incertaine pour chaque groupe. Les pourcentages seuls donneraient une vision incomplète des résultats.

La participation a introduit un problème de mesure distinct. Dans l’expérience ultérieure de Metr, une part croissante des développeurs a refusé de participer parce que l’expérience les obligeait à passer la moitié de leur temps à travailler sans IA. Ceux qui acceptaient cette contrainte pouvaient différer des développeurs qui jugeaient l’accès trop important pour y renoncer. La contrainte a donc influé sur les développeurs que l’expérience pouvait mesurer.

La sélection des tâches a encore restreint le travail évalué. Dans l’expérience ultérieure de Metr, entre 30 % et 50 % des participants ont admis avoir retenu les tâches pour lesquelles ils souhaitaient particulièrement l’IA ; l’expérience a donc manqué le travail dont ils attendaient le plus de bénéfices de l’assistance. Metr a considéré son estimation comme une borne inférieure : le gain réel était probablement plus élevé, mais l’organisation ne pouvait pas quantifier de combien. Cette interprétation tient compte de l’effet probablement baissier de la sélection tout en laissant intacte l’incertitude statistique.

Les deux expériences montrent comment l’évaluation peut induire en erreur dans des directions différentes. Dans le premier essai, les impressions des développeurs surestimaient leur performance ; dans l’expérience ultérieure, les décisions de participation et les tâches retenues ont probablement sous-estimé le bénéfice mesuré. Même une organisation spécialisée dans la mesure de l’IA a eu du mal à déterminer clairement l’ampleur de l’effet. Ces comportements décrivent les réponses des développeurs aux restrictions expérimentales sur l’accès et la soumission des tâches ; ils offrent donc une base étroite pour interpréter l’expérience.

Pour une entreprise, la question suivante est de savoir comment les gains au niveau des tâches affectent la livraison. Les conclusions ultérieures laissent place à une aide individuelle utile sans établir que les participants ont fondamentalement repensé leurs workflows. Une transformation à l’échelle de l’organisation n’est donc pas nécessaire pour chaque tâche d’IA bénéfique. Les retours à l’échelle de l’entreprise exigent un lien supplémentaire : les améliorations apportées à certaines activités doivent se traduire par une meilleure livraison et de meilleurs résultats financiers.

La refonte exige une responsabilité de bout en bout et l’autorisation de supprimer des étapes

Pour établir ce lien, une équipe doit d’abord définir ce que son travail est censé accomplir. Elle peut ensuite reconsidérer la séquence à la lumière de ce que l’IA rend possible, en se demandant quelles étapes contribuent encore au résultat. La finalité ouvre le processus au changement. Partir de la procédure héritée pousse l’équipe à la préserver tout en accélérant des tâches isolées.

Reconsidérer la séquence crée une opportunité de supprimer des coordinations et des revues dont le processus révisé n’a plus besoin. Parmi les candidates figurent les transferts inutiles, les niveaux de revue qui ont perdu leur fonction et les étapes justifiées par l’hypothèse que des personnes exécuteraient le travail à vitesse humaine. Chaque suppression doit être reliée à un effet business mesurable. Les revues et validations qui servent encore un objectif utile doivent être maintenues.

La responsabilité de bout en bout confie à quelqu’un la responsabilité de porter ces jugements sur un segment complet de travail. Lorsque l’IA réduit une coordination auparavant répartie sur tout un département, une personne ou une petite équipe peut être en mesure d’assumer la responsabilité de ce segment. Le gain proposé vient autant d’un changement dans la manière dont les responsabilités s’articulent que d’une exécution plus rapide des activités individuelles. Les dirigeants peuvent tester cette conception à l’aune des résultats ; la taille de l’équipe, à elle seule, ne garantit aucune amélioration.

Une telle responsabilité exige des droits de décision explicites : les décisions opérationnelles qu’une équipe est autorisée à prendre. Une équipe ne peut pas repenser son travail de manière significative si chaque ajustement doit revenir à un comité de pilotage qui préserve l’organisation d’origine. Les dirigeants doivent préciser quelles décisions l’équipe contrôle et la tenir responsable des conséquences. Sinon, ils lui assignent un objectif de performance tout en conservant les contrôles procéduraux qui la limitent.

Le décalage devient concret lorsqu’une équipe ne peut pas supprimer des niveaux de validation, assumer la responsabilité d’un segment complet de travail ou agir sans décisions prises ailleurs. Dans chaque cas, l’équipe reste responsable d’un résultat qui dépend de choix hors de son contrôle. Définir l’autorité en même temps que l’objectif donne à l’équipe un moyen d’assumer ses responsabilités. Les dirigeants peuvent alors évaluer les changements à travers le travail livré.

Mesurez le travail livré et récompensez les équipes qui changent la manière de le réaliser

Une fois que les équipes ont l’autorité d’agir, la mesure doit montrer ce que produisent leurs décisions. Le nombre de licences, les connexions et le pourcentage de collaborateurs utilisant l’IA aident les dirigeants à comprendre l’accès et la participation. La preuve de la valeur business exige une étape supplémentaire : montrer si le travail a été livré, si la demande a été satisfaite, si le chiffre d’affaires s’est amélioré ou si la qualité a progressé. Un conseil d’administration examinant un investissement dans l’IA a besoin de ce lien entre adoption et performance.

Les mesures fondées sur le travail rendent ce lien plus concret. Le temps de cycle montre combien de temps une unité de travail met entre le début et l’achèvement, tandis que le coût par unité montre ce que l’organisation dépense pour la produire. La production par personne indique combien chaque personne livre. Ensemble, ces mesures permettent aux dirigeants de tester l’amélioration revendiquée par une équipe par rapport aux changements du travail lui-même.

La qualité et le chiffre d’affaires prolongent cette évaluation, car une production plus rapide ou moins coûteuse peut malgré tout manquer l’objectif business. La qualité établit si l’augmentation de la production reste utile, tandis que le chiffre d’affaires relie le changement opérationnel à la performance commerciale. La bonne combinaison dépend du travail en cours de modification. Les dirigeants doivent exiger des preuves sur l’ensemble de ces mesures avant de considérer un projet pilote ou un déploiement comme un résultat business démontré.

La méthode d’évaluation compte autant que les mesures, comme l’illustrent les expériences de Metr. Les impressions des utilisateurs peuvent diverger de la performance mesurée, et les personnes comme les tâches incluses dans une évaluation peuvent en affecter le résultat. Les équipes doivent donc expliquer à la fois comment leurs résultats ont évolué et comment elles les ont évalués. Un chiffre favorable est plus utile lorsque les dirigeants comprennent quel travail et quels participants il représente.

Une revue d’investissement peut mettre cette discipline en pratique avec quelques questions opérationnelles. Quel travail a été livré, et quels résultats se sont améliorés de manière mesurable ? Quelles pratiques opérationnelles ont changé, et l’équipe avait-elle l’autorité de les changer ? Une aide individuelle utile peut justifier un investissement au niveau des tâches, tandis qu’une affirmation de transformation à l’échelle de l’entreprise exige la preuve qu’un travail modifié produit de meilleurs résultats business.

Même des preuves claires auront une influence limitée si les récompenses favorisent une activité visible mais peu utile, le maintien des effectifs ou l’obéissance à des procédures héritées. Ces incitations rendent la coordination inutile digne d’être protégée. Les dirigeants devraient récompenser les refontes de workflow réussies, une meilleure livraison avec moins de ressources et l’élimination par une équipe de son propre travail inutile. Réduire le travail évitable doit compter comme une réussite si l’on attend des personnes qu’elles s’y consacrent.

Reconnaître cette réussite exige de prêter attention à des résultats qui peuvent être moins visibles que les volumes d’usage ou la conformité procédurale. Une équipe qui livre davantage avec moins d’étapes peut générer moins d’activité visible alors même que sa performance s’améliore. Les dirigeants doivent examiner le travail achevé et les ressources qu’il a consommées afin que la suppression d’efforts soit reconnue. Sinon, les équipes qui préservent une activité inutile peuvent paraître plus productives que celles qui l’éliminent.

Points clés à retenir pour les dirigeants

• Reliez l’investissement dans l’IA aux changements de workflow : McKinsey a constaté que les entreprises les plus performantes dans la capture de l’impact de l’IA étaient presque trois fois plus susceptibles d’avoir fondamentalement modifié leurs workflows. Les revues d’investissement ont besoin de preuves montrant comment l’IA modifie le coût, la vitesse et la qualité du travail achevé.
• Testez soigneusement les affirmations de productivité : Dans le premier essai de Metr, les développeurs pensaient que l’IA les rendait plus rapides alors que les temps d’exécution mesurés augmentaient. Les responsables de l’évaluation doivent examiner la performance mesurée, l’incertitude statistique et les personnes ainsi que les tâches incluses dans l’évaluation.
• Donnez des droits de décision aux responsables des workflows : Les dirigeants doivent définir quelles validations, quels transferts et quelles décisions opérationnelles les équipes contrôlent. La responsabilité de bout en bout devient actionnable lorsque les équipes ont l’autorité de changer la manière dont elles livrent les résultats.
• Mesurez les résultats et récompensez le travail supprimé : Les responsables business doivent suivre le temps de cycle, le coût par unité, la production, la qualité et le chiffre d’affaires. Les incitations à la performance doivent reconnaître les équipes qui améliorent la livraison en éliminant le travail inutile.