Vingt mille fonctionnaires britanniques ont reçu une licence Microsoft 365 Copilot, et le rapport de conclusions interministériel a fixé le résultat à 26 minutes gagnées par personne et par jour (Government Digital Service, 2025). Le chiffre circule depuis dans les présentations d'achat. Deux détails du même rapport changent ce qu'il peut porter : les participants l'ont produit en estimant eux-mêmes leur gain de temps quotidien à partir d'une série de fourchettes, et la section des conclusions indique qu'« en raison de contraintes expérimentales, il n'a pas été possible d'identifier comment le temps gagné a été utilisé ».
Puis le Department for Work and Pensions — l'un des ministères inclus dans ce même essai — a évalué sa propre cohorte face à un groupe de comparaison de collègues n'ayant jamais reçu de licence. Son estimation s'est établie à 19 minutes par jour sur huit tâches de routine (DWP, 2026).
Deux mesures d'un seul déploiement, publiées par le même gouvernement. L'écart qui les sépare est exactement l'écart entre un titre sur le temps gagné et un business case de pilote d'IA.
Ce que 20 000 licences ont réellement mesuré
L'expérimentation interministérielle s'est déroulée du 30 septembre au 31 décembre 2024, chaque organisation participante s'engageant sur au moins 1 000 licences (Government Digital Service, 2025). Au regard du standard habituel des données sur la productivité de l'IA, c'est un bon document : vaste, dans le secteur public, publié avec sa méthodologie, et ce n'est pas une étude de cas éditeur avec trois logos flatteurs en haut de page.
C'est sur la méthode qu'un responsable des opérations devrait ralentir. On a demandé aux participants d'estimer leur gain de temps quotidien moyen en choisissant parmi des fourchettes allant de « aucun ou moins de 5 minutes » à « plus d'une heure ». La moyenne de 26 minutes a été calculée à partir des points médians de ces fourchettes, la tranche supérieure étant traitée comme 60 minutes. Dix-sept pour cent n'ont constaté aucun gain de temps net. Plus de 70 % ont déclaré que Copilot réduisait le temps passé à chercher de l'information — ce qui est, comme le suggèrent des données ultérieures, le cas d'usage où l'outil est le plus visiblement utile et le moins conséquent économiquement.
L'instrument est donc une question de mémoire : combien de temps pensez-vous avoir gagné ? Cette question peut être posée à 20 000 personnes pour pas cher, et c'est pourquoi on la pose. Elle ne peut pas produire les deux chiffres sur lesquels tourne réellement un business case.
Les deux chiffres qu'une auto-déclaration ne peut pas donner
Le premier est le contrefactuel : ce qui serait advenu de ces tâches de toute façon, avec les mêmes effectifs, le même trimestre et aucune licence. Le second est la destination : où sont allées les minutes récupérées.
Sans le premier, vous mesurez l'enthousiasme en même temps que l'effet. Sans le second, vous mesurez un intrant et vous l'appelez un retour.
Le même déploiement, confronté à ceux qui n'en disposaient pas
L'évaluation du DWP fournit le premier de ces chiffres. Elle a utilisé une Seemingly Unrelated Regression face à un groupe de comparaison de non-utilisateurs, en contrôlant des variables démographiques, professionnelles et d'appétence pour l'IA, et a estimé 19 minutes par jour gagnées sur huit tâches de routine — statistiquement significatives dans toutes les spécifications. Les réductions les plus fortes par tâche concernaient la recherche d'information (26 minutes) et la rédaction d'e-mails (25 minutes). Quatre-vingt-dix pour cent des utilisateurs ont déclaré que Copilot leur avait fait gagner du temps, et 65 % se sont dits plus épanouis au travail (DWP, 2026).
Le DWP est tout aussi explicite sur sa propre limite : il ne s'agissait pas d'un essai randomisé contrôlé. Les licences ont été attribuées par ordre d'arrivée, de sorte que l'auto-sélection et le biais post-traitement sont des risques réels. Les licences sont allées aux plus enthousiastes.
Résistez à l'arithmétique ici. Les deux chiffres ne sont pas comparables — populations différentes, périmètre de tâches différent, méthode différente — et soustraire l'un de l'autre produit un nombre qu'aucun des deux documents ne soutient. Le résultat est structurel, pas numérique : le ministère qui a ajouté un groupe de comparaison a rapporté un chiffre plus faible que l'auto-estimation, dans un programme où les enthousiastes s'étaient sélectionnés eux-mêmes dans le traitement. C'est le sens dans lequel va la correction, et c'est le sens qui compte quand un éditeur vous tend un chiffre unique sans aucun groupe de contrôle à proximité.
La phrase qui devrait arrêter la réunion de budget
De tout le rapport interministériel, une ligne des conclusions est celle qui abîme le plus l'usage fait des 26 minutes : « en raison de contraintes expérimentales, il n'a pas été possible d'identifier comment le temps gagné a été utilisé ».
Une minute récupérée a trois destins possibles. Elle devient de la production. Elle est absorbée par une autre tâche. Ou elle devient du temps mort. Seul le premier apparaît dans un business case, et l'essai n'a pas pu les distinguer.
Ce n'est pas une particularité du secteur public. La première mesure fédérale et indépendante des éditeurs sur la même question a trouvé que, parmi les travailleurs américains ayant utilisé l'IA au travail la semaine précédente, 56 % situaient le temps supplémentaire qui aurait été nécessaire sans elle à deux heures par semaine ou moins ; 10 % ont déclaré aucun gain de temps, et 3 % ont dit que l'IA exigeait plus de temps (Bureau du recensement des États-Unis, 2026).
Deux heures par semaine, arrivant par minutes éparses, ne se consolident pas en un ETP réaffectable. Le test opérationnel est brutal : une tâche entière quitte-t-elle le bureau de quelqu'un ? Si la réponse est non, alors les heures multipliées par un coût chargé sont une figure de style, pas une prévision.
Pourquoi les minutes par utilisateur ne s'agrègent pas en un business case de pilote d'IA
Le problème de participation aggrave celui de la destination. L'enquête sur les attentes des consommateurs de la BCE rapporte le même résultat à deux altitudes : l'utilisateur médian d'IA gagne environ trois heures par semaine, soit à peu près 7,7 % du temps de travail médian — mais seuls 48,8 % des travailleurs à la fois utilisent l'IA et y gagnent du temps, ce qui ramène le gain d'efficacité à l'échelle de l'économie à environ 3,8 % (BCE, 2026).
Même enquête, mêmes répondants, et le chiffre est divisé par deux lorsque le dénominateur cesse d'être « les utilisateurs » pour devenir « toutes les personnes que vous payez ».
Les données de la BCE inversent aussi le schéma d'usage d'une manière qui devrait réordonner un pilote. La génération de code et le débogage rapportent près de huit heures par semaine — et environ 8 % des utilisateurs y appliquent l'IA. La recherche, la collecte d'information, la rédaction et la relecture sont les usages les plus courants et font gagner nettement moins. Le bénéfice phare de l'essai interministériel, moins de temps passé à chercher de l'information, se situe précisément dans la bande à faible rendement.
Ce qui signifie que le business case a besoin de trois intrants là où la plupart des présentations n'en ont qu'un : taux de participation, rendement par tâche, et un facteur de conversion explicite indiquant si les heures libérées deviennent de la production ou du temps mort. Chacun est observable avant un renouvellement. Aucun ne figure dans une moyenne de 26 minutes.
L'objection honnête
Trois limites, dites franchement.
L'auto-déclaration peut se tromper dans les deux sens — mais le sens mesuré n'a pas été clément. L'essai randomisé de METR sur des développeurs open-source expérimentés a trouvé que les outils d'IA du début 2025 les rendaient 19 % plus lents alors qu'ils croyaient avoir accéléré ; son enquête ultérieure auprès de 349 travailleurs techniques rapporte que les participants à cette étude avaient surestimé l'effet de l'IA sur la durée des tâches de 40 points de pourcentage en moyenne (METR, 2026). C'est une population étroite, travaillant sur des dépôts qu'elle connaît intimement, et l'ampleur ne se transpose pas à un back-office de taille intermédiaire. Elle établit quelque chose de plus modeste et toujours utile : un gain auto-estimé n'est pas un intrant conservateur.
Ces évaluations ne sont pas des échecs. Les deux ont trouvé des gains de temps réels et statistiquement significatifs, et le DWP a trouvé des effets d'épanouissement qui valent par eux-mêmes. La critique ne porte pas sur les essais — plus transparents que la plupart de ce qui se vend comme preuve — mais sur le travail qu'on demande au chiffre phare une fois qu'il a quitté le rapport.
Le secteur public n'est pas votre secteur. Le mix de tâches de la fonction publique, les contraintes d'achat et l'outillage de base sont spécifiques. L'actif transférable est le design de l'évaluation, pas les minutes. Ne transposez pas 26 ou 19 dans votre modèle ; transposez la question qui a produit le second.
Ce qu'il faut changer dans la conception du pilote avant le prochain renouvellement
Quatre gestes, dont aucun ne nécessite une nouvelle ligne budgétaire.
- Réservez un groupe de comparaison, et ne laissez pas les enthousiastes s'auto-sélectionner. La façon la moins chère de rendre défendable le chiffre d'un pilote est une cohorte, dans la même fonction, qui ne reçoit pas de licence pendant les mêmes 90 jours. La limite que le DWP énonce lui-même — attribution par ordre d'arrivée — est la partie à corriger : randomisez les licences au sein d'une équipe au lieu de les donner à ceux qui demandent les premiers.
- Nommez la destination avant le démarrage du pilote. Écrivez, poste par poste, quelle tâche précise est censée quitter le bureau de qui, et ce qui est censé remplir l'espace. Si la réponse est « les gens auront plus de temps », le pilote mesure la satisfaction, et devrait être budgété comme tel.
- Instrumentez une tâche, pas tout le déploiement. Choisissez deux tâches dont le temps de cycle est observable dans les systèmes et mesurez-les de bout en bout. Un écart défendable sur deux tâches vaut mieux qu'une moyenne d'enquête sur quarante.
- Évaluez le poste, pas l'effectif. La question de la destination doit être tranchée au niveau du poste, parce que c'est le niveau auquel le travail se déplace réellement. Le scoring d'augmentabilité sur l'organigramme de Scovai est une forme concrète de ce résultat — chaque poste noté de 0 à 100 % selon son degré d'augmentabilité, les rôles non couverts et le plan par poste découlant du même schéma.
Le gouvernement britannique a fait une chose inhabituelle : il a publié à la fois le chiffre flatteur et la méthode qui le relativise, puis il a laissé l'un de ses ministères corriger sa propre copie avec un groupe de comparaison. C'est un standard de preuve plus élevé que celui que la plupart des pilotes d'IA en entreprise privée atteignent jamais.
Alors avant de renouveler un bloc de licences ce trimestre, demandez une page : quelles tâches ont quitté quels bureaux, et qu'est-ce qui est arrivé dans l'espace libéré. Si personne ne peut écrire cette page, vous ne détenez pas un business case de pilote d'IA. Vous détenez une enquête de satisfaction avec des frais de licence attachés.
