ADKAR #4 : Knowledge & Ability — Le piège du savoir faire

C'est le moment où tout semble aller bien. Les équipes comprennent pourquoi le changement est nécessaire — l'Awareness est là. Elles ont envie d'y participer — le Desire est construit. On a passé du temps avec chaque personne, écouté les résistances, trouvé les leviers individuels.

Et maintenant, on les forme.

On organise des sessions. On distribue des manuels. On met en ligne des vidéos. On fait des quiz, des certifications, des attestations de fin de formation. Tout le monde est formé. On coche la case. Le projet est en bonne voie.

Sauf que non. Parce que ce que la plupart des projets appellent "formation", c'est en réalité du Knowledge. Et le Knowledge, ce n'est que la moitié du chemin.

Le piège fondamental : Knowledge ≠ Ability

Dans le modèle ADKAR, le Knowledge et l'Ability sont deux étapes distinctes — et c'est une des distinctions les plus importantes du modèle entier.

Le Knowledge, c'est le savoir théorique. La connaissance des nouvelles procédures, la compréhension du nouveau système, le fait de savoir ce qu'il faut faire. C'est ce qu'on mesure avec un QCM en fin de formation.

L'Ability, c'est la capacité réelle à exécuter. C'est être capable de réaliser la tâche dans les conditions réelles de travail, avec les contraintes du quotidien — le stress, les délais, les interruptions, les cas particuliers qu'on n'a pas vus en formation.

Entre les deux, il y a un fossé que les projets de changement sous-estiment systématiquement. Et c'est ce fossé qui explique pourquoi tant de transformations échouent après la phase de formation.

Un exemple concret. Former quelqu'un à utiliser un nouveau logiciel de gestion de commandes — le Knowledge — ça prend deux jours. Mais que cette personne soit capable de traiter les commandes du lundi matin sous pression, avec des clients au téléphone et des cas à la marge qu'elle n'a jamais vus — l'Ability — ça peut prendre des semaines, voire des mois.

Et pourtant, la plupart des projets calent leur calendrier sur la fin de la formation, pas sur la fin de la montée en compétence réelle.

Construire le Knowledge : les bonnes pratiques

Le Knowledge, c'est le domaine où la plupart des organisations savent faire. Mais même là, il y a des façons de le faire bien et d'autres de le faire mal.

Ce qui marche

La formation adaptée au rôle. Tout le monde n'a pas besoin de tout savoir. Une formation unique pour tous les profils produit des gens qui connaissent la moitié des choses, mais pas les bonnes. Le Knowledge doit être ciblé : commercial, opérateur, manager, support — chaque rôle a son périmètre.

La formation juste-à-temps. Former les gens trop tôt, c'est leur faire perdre leur temps. Ils oublient avant d'avoir pu pratiquer. Le meilleur moment pour le Knowledge, c'est juste avant d'en avoir besoin. Pas trois mois avant le déploiement.

Le blended learning. Mélanger les formats : présentiel pour les concepts clés, vidéo pour les démos, documentation écrite pour la référence, e-learning pour l'auto-rythme. Chaque personne apprend différemment.

Le parrainage. Associer chaque personne formée à un collègue plus expérimenté qui fait le lien entre la formation et le terrain. C'est le pont naturel entre Knowledge et Ability.

Ce qui ne marche pas

Le "formation catalog". "On a 15 modules de formation disponibles, les gens s'inscrivent." Sans accompagnement, sans obligation, sans lien avec le calendrier du projet, les modules restent vides.

La formation one-shot. Une session de deux jours, puis plus rien. Le Knowledge ne s'acquiert pas en une fois — il se consolide par la répétition, les piqûres de rappel, les mises à jour.

L'absence de documentation terrain. Le manuel de 200 pages qu'on imprime et qu'on distribue — personne ne le lit. Le vrai Knowledge utile, c'est la fiche réflexe de 2 pages sur le poste de travail.

Construire l'Ability : là où le bât blesse

L'Ability est l'étape la plus négligée du modèle ADKAR, probablement parce qu'elle est la plus difficile à mesurer et la plus longue à construire.

Le temps est le facteur critique

Le premier ingrédient de l'Ability, c'est le temps. Pas le temps de la formation — le temps de la pratique. Le temps de faire des erreurs, de les corriger, de recommencer. Le temps de développer les automatismes.

La plupart des projets de changement ne prévoient pas ce temps. Le déploiement est calé, date butoir. On forme en J-15, on bascule à J0, et on attend que ça marche. Mais les gens n'ont pas eu le temps de développer l'Ability. Résultat : la productivité chute, les erreurs s'accumulent, la frustration monte — et tout le travail sur l'Awareness et le Desire s'effondre sous la pression du quotidien.

Ci-dessous l'étude de Prosci confirme : les organisations qui prévoient une période de transition avec double activité (ancien ET nouveau système en parallèle) réussissent beaucoup mieux leur changement. Parce qu'elles donnent aux gens le temps de construire l'Ability sans mettre en danger leur performance.

Le coaching est indispensable

Le deuxième ingrédient de l'Ability, c'est le coaching. La formation donne le Knowledge. Le coaching développe l'Ability. C'est quelqu'un qui regarde la personne faire, qui corrige, qui montre une autre façon, qui rassure quand ça coince.

Le coaching ne se décrète pas — il se prépare. Il faut former les coachs, les outiller, leur donner du temps pour ça. Dans les meilleurs projets de changement, chaque nouvel utilisateur a un coach attitré pendant les premières semaines post-déploiement.

L'environnement doit suivre

Troisième ingrédient : l'environnement. On peut avoir le Knowledge et le temps et le coaching — si l'environnement de travail ne permet pas de mettre en pratique, l'Ability ne se construit pas.

Ça peut être un système trop lent, des accès qui ne sont pas en place, un processus qui n'a pas été adapté, des données qui n'ont pas été migrées proprement. L'Ability, c'est aussi la responsabilité de l'organisation de créer les conditions de la pratique.

La différence entre "savoir faire" et "faire vraiment"

Un test simple pour savoir si l'Ability est acquise : la personne réalise-t-elle la tâche sous pression, avec des distractions, sans avoir besoin de consulter la documentation ?

Si la réponse est non, l'Ability n'est pas là. Peu importe si elle a réussi le test de fin de formation — le test n'était pas dans les conditions réelles.

Le cas particulier des changements complexes

Plus le changement est complexe, plus le fossé Knowledge-Ability est large. Pour un changement simple — changer un mot de passe, modifier une procédure administrative — le fossé est quasi nul. On explique, on fait, c'est bon.

Pour un changement complexe — adopter un nouveau système d'information, transformer un processus métier, changer de modèle opérationnel — le fossé est énorme. Le Knowledge peut s'acquérir en quelques heures ou jours. L'Ability prend des semaines ou des mois.

C'est pourquoi les projets qui durent 6 mois et qui prévoient 2 semaines de formation tombent systématiquement dans le piège Knowledge-Ability. Ils sous-estiment d'un facteur 5 à 10 le temps nécessaire à l'Ability.

Le lien avec les étapes précédentes

Un des pièges les plus fréquents dans le déploiement d'ADKAR, c'est de sauter les étapes pour arriver directement au Knowledge : "On les a formés, donc ils sont prêts."

Si l'Awareness n'est pas construite, la formation n'a aucun sens. Les gens apprennent sans savoir pourquoi. Si le Desire n'est pas construit, la formation est inefficace. Les gens écoutent sans intégrer.

Mais l'inverse est aussi vrai : si le Knowledge et l'Ability sont négligés, tout le travail sur l'Awareness et le Desire devient une promesse non tenue. "Vous m'avez convaincu de changer, vous m'avez donné envie, mais vous ne m'avez pas donné les moyens." La frustration qui en résulte est pire que la résistance initiale.

Le test du Knowledge et de l'Ability

Pour le Knowledge : "Pouvez-vous m'expliquer comment faire X avec le nouveau système ?" Si la personne peut expliquer clairement, le Knowledge est là.

Pour l'Ability : "Pouvez-vous le faire maintenant, sous mes yeux, sans aide ?" Si la personne peut exécuter correctement — même lentement — l'Ability est en voie d'acquisition. Si elle peut le faire rapidement, sans hésitation, sans erreur, et dans des conditions normales de travail — l'Ability est acquise.

La différence entre les deux tests, c'est la différence entre la théorie et la pratique. Et c'est exactement cette différence qui sépare un projet de changement qui coche des cases d'un projet qui transforme vraiment.

Dans le prochain épisode

Le Knowledge est construit. L'Ability est en place. Les gens savent et peuvent. Le changement est déployé. On pourrait croire que le travail est fini.

C'est là que la plupart des projets commettent leur dernière erreur : ils oublient le Reinforcement. Et sans Reinforcement, le changement s'érode. Les vieilles habitudes reviennent. Six mois après le déploiement, tout est à refaire.

Dans le prochain article : comment faire durer le changement, pourquoi le Reinforcement est l'étape la plus oubliée, et les techniques concrètes pour qu'un changement tienne dans le temps.

🎙️ Podcast : Écouter (7 min)