Votre problème de formation à l’IA peut venir des processus

« Plus de formation à l’IA » est une demande qui nécessite d’abord un diagnostic

Lorsque les managers constatent une adoption décevante de l’IA, Markus McKay-Fleisch entend souvent la même solution proposée : « mon équipe n’adopte pas les nouveaux outils comme je l’espérais, donc nous avons besoin de plus de formation pour corriger cela ». McKay-Fleisch, qui dirige l’enablement IA des services professionnels chez Smartsheet, a passé vingt ans dans la formation des adultes et les deux dernières années spécifiquement centrées sur l’adoption de l’IA dans ce domaine. S’exprimant récemment lors d’AI4, il a proposé une autre question de départ : « quel résultat cherchez-vous à obtenir ? »

Ce résultat compte, car les entreprises regroupent régulièrement plusieurs mesures différentes sous la notion d’adoption. Des formations obligatoires peuvent produire des taux de complétion élevés alors que les employés utilisent à peine le produit. Un usage fréquent de l’IA peut créer un autre problème lorsque les employés choisissent systématiquement les modèles les plus coûteux jusqu’à ce que la finance demande à l’enablement de réduire la consommation. Les employés peuvent aussi reconstruire avec succès leurs propres workflows, tout en laissant ces pratiques isolées et sans jamais les diffuser dans l’organisation.

Ces exemples distinguent la complétion, l’usage, les dépenses et l’amélioration dans le travail, car chacun peut évoluer indépendamment. Une demande de « plus de formation à l’IA » devient utile une fois que les dirigeants ont établi quelle mesure est décevante et ce que les employés doivent être capables d’accomplir en conséquence. Tant que ce diagnostic n’existe pas, d’excellents indicateurs d’apprentissage peuvent coexister avec un problème métier inchangé.

Les données pointent vers un déficit d’application

Cette distinction entre activité d’apprentissage et résultats dans le travail apparaît dans le rapport 2026 AI Readiness Gap de Docebo. L’éditeur de logiciels de formation Docebo, qui a un intérêt commercial à ce que les organisations investissent dans la formation, a mené cette étude via Centiment auprès de 2 000 répondants aux États-Unis, au Royaume-Uni, au Canada, en France, en Allemagne et en Italie. Il en ressort que 85 % ont déclaré que la formation reçue ne les aidait pas à utiliser l’IA dans leur rôle. Un répondant sur cinq n’a reçu aucune formation à l’IA, de sorte qu’une partie de ces 85 % décrivait une absence d’instruction ; même en mettant conceptuellement ce groupe de côté, une majorité avait reçu quelque chose qu’elle ne parvenait pas à traduire dans son travail.

La manière dont les équipes formation utilisent l’IA aide à situer une partie de ce problème d’application. Parmi les responsables formation de l’étude Docebo, 79 % utilisent l’IA pour des tâches incluant la génération de contenu, tandis que seulement 9 % ont déclaré que leur organisation avait utilisé l’IA pour redéfinir un workflow. Les fonctions formation peuvent devenir beaucoup plus rapides pour produire des contenus alors que le poste sous-jacent, ses transferts et ses décisions restent largement inchangés. Une production de cours plus rapide a un effet limité lorsque le problème se situe dans la conception du travail.

Le point de vue de la direction ajoute une autre mesure à ce même problème global de préparation. L’AI Impact Survey 2026 de Grant Thornton a couvert 950 dirigeants d’entreprise dans dix secteurs, plus le private equity, avec un travail de terrain mené du 23 février au 18 mars. Seuls 12 % considéraient leur main-d’œuvre comme pleinement prête pour l’IA, 81 % supplémentaires la décrivaient comme assez ou majoritairement prête, et 97 % reconnaissaient une forme de difficulté d’adoption. Les dirigeants peuvent donc percevoir une préparation globale tout en signalant des obstacles à l’adoption.

Ces dirigeants identifient aussi la formation comme une contrainte réelle, ce qui donne au diagnostic une utilité pratique. La gouvernance et la conformité arrivaient en tête de leurs explications de la sous-performance de l’IA à 46 %, tandis que l’insuffisance de formation arrivait en deuxième position à 31 %. Environ 34 % ont également identifié la formation comme le domaine d’investissement le plus sous-financé de leur organisation. L’instruction à l’IA peut mériter davantage d’investissement même lorsque les faibles résultats ont une autre cause principale.

L’interprétation de Grant Thornton affine la distinction : une formation de sensibilisation produit de la familiarité, tandis que la capacité exige que les personnes réalisent effectivement le travail. Les conclusions de Docebo montrent séparément que les employés peinent à appliquer ce qu’ils reçoivent et que la refonte des workflows reste peu fréquente. Pour le L&D, la décision utile consiste à déterminer quel obstacle un investissement dans la formation est censé lever.

Diagnostiquer le travail avant de prescrire de la formation

Identifier cet obstacle commence par le résultat de travail, car l’IA générative modifie une raison ancienne de l’instruction logicielle. Pendant environ trente ans, la formation en entreprise a consacré des efforts importants à la connaissance des plateformes : où les boutons avaient été déplacés, quelles fonctionnalités existaient et comment fonctionnait la navigation. Microsoft à lui seul a généré une petite industrie autour de ce type d’instruction. L’IA générative fait de plus en plus du langage l’interface, de sorte que les utilisateurs peuvent décrire un résultat souhaité et souvent adresser une question de type « comment faire » à un assistant intégré ou à un modèle généraliste utilisant une documentation d’aide publique.

À mesure que cette interface évolue, McKay-Fleisch soutient que les obstacles restants concernent de plus en plus la compréhension de l’organisation et le jugement humain. Il distingue la refonte du workflow, qui modifie la manière d’atteindre un résultat, de la transformation par l’IA, qui inclut les structures, les rôles et les compétences entourant ce travail. Les équipes d’enablement peuvent enseigner des compétences, mais modifier la chaîne d’approbation d’un département, attribuer la responsabilité et imposer des standards de revue exigent généralement une autorité située ailleurs. La conception du curriculum commence donc par l’identification du type d’obstacle présent.

La première situation est celle d’un résultat qui n’a jamais été nommé. Un dirigeant peut signaler que l’usage a augmenté ou diminué sans disposer d’un résultat précis que l’équipe devrait désormais être capable d’atteindre. Les employés expérimentent alors sans objectif de travail, et leur activité finit par être interprétée comme une adoption faible parce que personne n’a établi de définition de la réussite au niveau du travail. L’intervention de McKay-Fleisch consiste en une session de travail avec le dirigeant pour définir un résultat mesurable et remonter ensuite jusqu’à la capacité nécessaire pour le produire.

Une fois qu’un résultat existe, la deuxième situation est celle d’un workflow inchangé. L’IA peut être introduite dans un processus dont la structure reflète des contraintes que l’IA a supprimées, comme des chaînes d’approbation dimensionnées selon d’anciens délais de rédaction, des transferts créés parce que deux personnes travaillaient autrefois dans des outils différents, ou des cycles de revue construits autour de schémas d’erreurs humaines plutôt que des erreurs produites par les modèles. Le processus peut alors pénaliser les employés pour la vitesse créée par le nouveau système. McKay-Fleisch recommande une cartographie des processus avec la fonction propriétaire du workflow, car l’enablement n’a pas l’autorité unilatérale pour le refondre.

Lorsque le workflow lui-même fonctionne, une troisième situation apparaît quand une expertise utile existe déjà mais ne circule pas. Un fort écart de performance entre collègues utilisant des outils identiques signale que des power users ont peut-être développé des méthodes efficaces, alors que ces méthodes restent dans des fichiers de projet personnels et des onglets de navigateur. Une autre session générale consacre alors du temps de formation à des personnes qui ont déjà résolu le problème. McKay-Fleisch recommande plutôt d’extraire ces pratiques, de les diffuser et d’intégrer les connaissances des power users dans ce que produit l’enablement.

L’usage par Smartsheet de Claude Projects montre aussi comment ces solutions isolées peuvent révéler un problème de responsabilité. McKay-Fleisch a examiné plus de 50 projets distincts d’employés dans la finance, le support client, les ventes et les RH, tous cherchant à produire des présentations et des supports conformes à la marque. Aucun de ces plus de 50 projets ne provenait du marketing. Les employés avaient identifié un besoin réel et construit indépendamment des solutions sans reconnaître que l’expertise, les contenus source et la capacité à maintenir la solution appartenaient déjà ailleurs dans l’organisation.

Cette duplication va au-delà de la qualité des prompts, car la capacité manquante est une connaissance de l’organisation. De meilleures instructions à un modèle n’apprennent pas à un employé à identifier le propriétaire organisationnel d’un problème avant de créer une nouvelle solution locale. Les employés doivent aussi comprendre où se situent l’autorité et l’expertise durable, puis y relier une expérimentation locale utile. Une fois cette connaissance identifiée, la formation peut la diffuser ; la responsabilité elle-même reste une décision organisationnelle.

La quatrième situation est une rupture de la discipline de revue. McKay-Fleisch qualifie la génération bon marché et non contrôlée de « slop cannon » : les gens peuvent créer de grandes quantités de contenu à coût minimal et les transmettre sans les évaluer eux-mêmes. Les indicateurs des producteurs peuvent s’améliorer parce que le volume augmente et que le temps de cycle diminue, mais le coût de vérification du résultat est alors transféré à ses destinataires. Les plaintes de ces destinataires peuvent donc révéler un problème masqué par les mesures de productivité de l’équipe productrice.

Une recherche de BetterUp Labs et du Social Media Lab de Stanford, publiée dans Harvard Business Review en septembre dernier, a mesuré un phénomène connexe que les chercheurs ont appelé « workslop ». Quarante pour cent des employés ont déclaré avoir reçu du workslop au cours du mois précédent. Chaque incident prenait au destinataire environ deux heures à traiter, ce que les chercheurs ont valorisé à environ 186 dollars par employé et par mois. La génération à bas coût modifie l’économie de la revue en transférant une partie de son coût au destinataire.

Ce transfert de coût peut aussi affaiblir la qualité de la revue, car les destinataires n’ont pas choisi le travail, n’en perçoivent pas nécessairement l’intention initiale et ne disposent pas toujours d’un moyen de le renvoyer. L’intervention de McKay-Fleisch consiste en un standard de revue avant transfert, appliqué par les managers. Il recommande aussi de confronter les producteurs à fort volume au coût aval intégré dans leurs indicateurs apparemment solides. La décision managériale devient alors explicite : déterminer où se situe la responsabilité de la qualité.

Ces quatre situations donnent à la demande initiale de formation un sens plus précis. Un faible usage peut commencer par un résultat non défini ; une IA insérée dans d’anciens processus appelle un travail sur le workflow ; des power users isolés et des dizaines de projets personnels qui se chevauchent révèlent des problèmes de connaissance et de responsabilité ; des contenus non relus déplacent les coûts vers l’aval. Un usage excessif de modèles coûteux peut de même nécessiter des orientations liées au comportement précis que la finance veut modifier. L’intervention découle de l’état opérationnel plutôt que de l’étiquette générique d’une adoption faible.

Certains « écarts de compétences » viennent de l’architecture

Le diagnostic doit aussi couvrir l’architecture technique, car un comportement utilisateur identique peut produire des résultats différents selon l’endroit où un employé utilise l’IA. Un employé peut travailler via un assistant intégré à une application, entraîné sur la documentation de cette plateforme et opérant avec les données réelles de l’utilisateur. Un autre peut utiliser un modèle généraliste qui accède à cette même plateforme via un protocole de connexion, c’est-à-dire une manière standard pour les systèmes d’échanger des requêtes et des informations. Les différences entre ces environnements peuvent apparaître à l’employé comme un problème d’« écart de compétences » alors même que le système sous-jacent détermine le résultat.

McKay-Fleisch utilise une tâche concrète pour mettre en évidence cette distinction : demander à l’IA de créer un tableau de bord identifiant les projets qui sont dans les temps, à risque ou en retard, regroupés par portefeuille et par responsable. Selon lui, le résultat devrait être identique quelle que soit la surface IA, c’est-à-dire l’interface IA visible par l’utilisateur, qui reçoit la demande. Sur de nombreuses plateformes aujourd’hui, ce n’est pas le cas. L’instruction par prompt ne peut pas corriger une différence de résultat créée par l’architecture sous-jacente.

Lorsque l’architecture crée cette différence, l’enablement peut tout de même guider l’usage sans traiter l’instruction comme le remède principal. Son équipe peut établir quelle surface IA produit de manière fiable quel résultat de travail et orienter les employés vers cette surface pour la tâche correspondante. Envoyer indistinctement les personnes vers des interfaces incohérentes enseigne une autre leçon, car des échecs répétés peuvent les amener à conclure que les outils d’IA, en tant que catégorie, ne sont pas fiables. Une autre surface aurait pu accomplir la même tâche avec succès.

La variable technique suivante est le contexte que la plateforme fournit à l’utilisateur. Donner à un modèle généraliste accès à des données métier lui donne les données, tandis que le sens, la structure et le comportement spécifique à l’application peuvent encore devoir être fournis séparément. Certaines plateformes apportent cette compréhension côté serveur grâce à des jeux d’instructions réutilisables partagés par les utilisateurs connectés. Smartsheet appelle son implémentation « native skills », selon McKay-Fleisch.

Comme McKay-Fleisch travaille chez Smartsheet, sa description des « native skills » est aussi le récit d’un fournisseur sur sa propre implémentation et sa valeur. Le contexte fourni côté serveur réduit la quantité de connaissance applicative que les employés doivent eux-mêmes exprimer. Lorsqu’une plateforme laisse ce travail à l’utilisateur, le prompt engineering et le context engineering deviennent des compétences déterminantes ; le context engineering consiste à fournir les informations et les instructions dont un modèle a besoin pour interpréter et exécuter une tâche de manière fiable. Dans cet environnement, une formation importante est une exigence technique liée à la conception du système.

Cette décision d’architecture rejaillit directement sur la conception du curriculum. Les responsables L&D et enablement doivent établir comment chaque fournisseur fournit le contexte applicatif et de données, car la réponse détermine la quantité de connaissances que les employés doivent apporter eux-mêmes et quelle surface IA convient à un résultat donné. Le constat de Grant Thornton selon lequel la formation est sous-financée reste pertinent ici : un financement supplémentaire peut cibler les cas où l’architecture laisse aux employés un travail critique de contextualisation.

Le décalage organisationnel frappe le plus durement sous la direction générale

Le déploiement technique aide aussi à expliquer pourquoi les dirigeants peuvent être fortement en désaccord sur le fait de savoir si la même main-d’œuvre est prête. Grant Thornton a constaté que 39 % des DSI et CTO décrivaient leur main-d’œuvre comme pleinement prête pour l’IA, contre 7 % des COO, soit un écart de 32 points. La direction technologique voit souvent le déploiement, les intégrations fonctionnelles et l’usage consigné. Les opérations sont plus susceptibles de juger la préparation à l’aune de l’amélioration réelle du travail.

Cette différence de perspective se poursuit lorsque les dirigeants identifient qui a le plus besoin de soutien. Grant Thornton a rapporté la répartition suivante :

Cette répartition du soutien est importante, car les personnes qui prennent les décisions organisationnelles signalent un besoin d’aide nettement moindre au niveau de la direction générale que dans les groupes qui vivent avec ces décisions dans les workflows quotidiens. Présenter la préparation principalement comme un déficit de capacité des employés oriente alors la remédiation vers les équipes de première ligne et les managers intermédiaires. Le résultat, le workflow, la responsabilité, les pratiques de revue et la configuration technique peuvent rester inchangés pendant que les employés reçoivent un programme supplémentaire.

Cette réponse correspond aussi à la manière dont l’enablement IA est couramment financé comme formation aux outils, alors même que l’obstacle historique de la connaissance des plateformes évolue. Lorsque le L&D reçoit une demande générée par un problème de processus, d’architecture ou de management, le mécanisme dont il dispose peut façonner le diagnostic. Des problèmes relevant des opérations, de la technologie ou du management peuvent ainsi arriver sous la forme de demandes visant à enseigner quelque chose aux employés. La responsabilité doit être établie avant que cette demande puisse devenir une intervention utile.

Attribuer un responsable à la refonte des workflows, puis décider quoi enseigner

La question de la responsabilité devient concrète avec la refonte des workflows par l’IA. McKay-Fleisch recommande d’identifier explicitement qui en est responsable ; chez Smartsheet, il a assumé cette responsabilité pendant un temps avant que l’entreprise ne recrute quelqu’un pour ce rôle. De nombreuses organisations n’ont pas de responsable explicite sur ce sujet. Quand la refonte n’appartient à personne, les demandes migrent vers les équipes L&D et enablement les plus proches, même si ces fonctions peuvent ne pas avoir autorité sur les processus qui doivent changer.

À partir de ce problème de responsabilité, McKay-Fleisch formule une prescription organisationnelle précise : les RH devraient revendiquer délibérément la refonte des workflows, avec le budget et l’autorité nécessaires. Son argument repose sur ce que la refonte détermine : quels rôles existeront, ce que ces rôles exigeront et quelles voies d’accès les employés auront vers eux. Les décisions technologiques peuvent avoir des conséquences sur les rôles, faisant de la conception des workflows une décision liée aux personnes. Selon lui, les RH devraient agir avant que la responsabilité organisationnelle ne se fixe ailleurs et ne laisse la fonction comptable de la capacité sans contrôle correspondant sur la conception du travail.

Pour une équipe d’enablement, cette prescription se traduit par une règle de fonctionnement plus étroite pour la prochaine demande. Demander d’abord un résultat de travail mesurable ; puis identifier le workflow contenant ce résultat et la personne ou la fonction qui en est responsable. Ces réponses établissent si l’intervention relève de la formation, de la conception des processus, du management ou de la technologie. Lorsqu’elles pointent vers la formation, l’équipe peut enfin préciser ce que les employés doivent être capables de faire et concevoir une instruction ciblée autour de ce travail.

Points clés

• Diagnostiquer les demandes de formation à l’IA : les équipes L&D peuvent commencer par le résultat de travail mesurable qu’un manager veut améliorer. La complétion, l’usage, les dépenses et la performance métier peuvent évoluer indépendamment, de sorte que la cible détermine si la formation est la bonne intervention.
• Combler le déficit d’application : la formation à l’IA ne se traduit souvent pas dans le travail quotidien des employés, tandis que la refonte des workflows reste peu fréquente. Les équipes formation peuvent relier l’instruction à des capacités métier précises et mesurer si les employés exécutent ensuite le travail différemment.
• Diagnostiquer d’abord le travail : des résultats non définis, des workflows obsolètes, une expertise isolée et des pratiques de revue faibles peuvent tous apparaître comme des problèmes d’adoption. La fonction propriétaire du workflow concerné peut identifier la contrainte avant que le L&D n’engage des ressources dans un nouveau programme.
• Prendre en compte l’architecture de l’IA : les interfaces IA peuvent produire des résultats différents à partir de la même demande, car les plateformes fournissent des données, un contexte et une connaissance applicative différents. Les équipes technologie et enablement peuvent tester les surfaces IA par rapport à des résultats de travail précis et former les employés au contexte qu’ils doivent réellement fournir.
• Réconcilier la préparation au sein de la direction : les responsables technologiques peuvent voir un déploiement réussi alors que les opérations voient un travail à peine amélioré. Les DSI, CTO et COO peuvent aligner les mesures de préparation sur les résultats des workflows et la performance des employés plutôt que de s’appuyer principalement sur la disponibilité ou l’usage.
• Attribuer explicitement la refonte des workflows : la refonte des workflows par l’IA a besoin d’un responsable ayant l’autorité de modifier les processus, les rôles et les responsabilités. Les RH peuvent assumer ce rôle lorsque c’est pertinent, tandis que le L&D concentre son investissement sur les écarts de capacité que l’instruction peut réellement traiter.