Pourquoi vos équipes n'utilisent pas votre nouveau système

Cas d'école. Une entreprise signe le contrat d'un nouveau système. Analyse, migration des données, tests, formation, livraison. Six mois plus tard, le commercial envoie ses devis depuis son propre classeur Excel, la production tient son planning sur un disque partagé et la comptable exporte les données pour les traiter ailleurs.

Le système tourne pourtant, les intégrations font circuler les données, le prestataire a rempli le cahier des charges. Et il s'agit malgré tout d'un échec, sauf qu'il ne se manifeste pas comme une panne, mais comme un silence.

L'implémentation est le moment où le logiciel fonctionne. L'adoption est l'état dans lequel l'organisation s'en sert. Entre ces deux points se trouve l'essentiel de la valeur que les entreprises perdent, et le budget lui consacre rarement une ligne.

Pourquoi vos équipes travaillent toujours sur Excel six mois plus tard

Le jour de la mise en production, Excel bat le nouveau système sur tout ce qui compte pour l'utilisateur : coût d'apprentissage nul, retour immédiat, structure libre, erreur sans trace. Le nouveau système offre des données consolidées, une traçabilité et une vision d'ensemble pour la direction. Ce sont des avantages pour l'entreprise, pas pour la personne qui doit envoyer ses commandes avant ce soir.

L'outil de diagnostic le plus utile tient donc en une phrase : si un collaborateur a besoin d'Excel à côté du système pour arriver à utiliser le système, le problème n'est pas forcément chez le collaborateur. Un classeur parallèle ne naît pas de la paresse, l'entretenir coûte du temps et fait courir un risque. Celui qui en tient un malgré tout affirme par là que le système seul revient plus cher que le système plus un classeur en supplément. Chacun de ces fichiers est une réclamation formalisée contre l'interface et la recherche utilisateur la moins chère dont l'entreprise dispose.

Dans son article de 1989, fondement du Technology Acceptance Model, Fred Davis écrit que les gains de performance sont souvent bloqués par le refus des utilisateurs d'accepter et d'utiliser les systèmes disponibles. Dans ses deux études menées auprès de 152 utilisateurs, la facilité d'utilisation perçue ressortait comme une cause probable de l'utilité perçue : ce qui se manipule difficilement ne paraît pas utile. L'échantillon est réduit et le travail ancien, ce n'est pas une prédiction, seulement le sens de la relation.

L'adoption est le dénominateur du retour sur investissement

Le coût est fixe et connu le jour de la signature. Le bénéfice n'apparaît qu'à partir du moment où quelqu'un travaille réellement dans le système. Un système dont l'adoption est nulle a un retour nul, quel qu'en soit le prix. Un système adopté à moitié fait pire que la moitié : l'entreprise paie à la fois les licences et l'entretien des processus parallèles, sans disposer d'une source unique de vérité.

Le rapport ERP 2026 du Panorama Consulting Group donne la même image, une enquête menée auprès de 170 organisations dont le chiffre d'affaires annuel médian s'élève à 200,5 millions de dollars. Selon lui, les difficultés liées aux ERP tiennent le plus souvent à une propriété des processus mal définie, à une faible adoption par les utilisateurs et à un défaut d'alignement des objectifs. Le véritable défi n'est pas le choix du prestataire, mais le fait que l'organisation fonctionne autrement après la mise en production.

Le prix de ce silence se calcule par un produit simple : temps multiplié par fréquence, par nombre de personnes, par coût. Prenez une opération qui prend plus de temps dans le nouveau système qu'auparavant, et multipliez l'écart par le nombre de répétitions quotidiennes, le nombre de personnes concernées et le coût horaire. Le résultat est la somme que l'entreprise paie chaque jour pour une seule décision de conception d'interface, et en même temps le plafond d'un budget raisonnable pour la corriger. J'ai déroulé la même arithmétique dans mon article expliquant pourquoi le bon design n'est pas une décoration, mais une façon pour l'entreprise d'économiser du temps et de l'argent.

Pourquoi on a longtemps toléré que le logiciel interne soit mauvais

Le logiciel grand public se bat pour chaque clic, parce que l'utilisateur peut partir. Le logiciel interne dispose d'un utilisateur captif et il est acheté par quelqu'un qui ne travaille pas dedans. Les critères de sélection sont la matrice fonctionnelle, le prix, les références et les intégrations. Personne n'ajoute au tableau une ligne sur le temps qu'il faut à un nouvel arrivant pour saisir sa première commande, et le prestataire optimise ce qui est noté.

Le Nielsen Norman Group décrit les applications d'entreprise complexes comme des outils au service d'objectifs peu structurés, manipulés par des spécialistes hautement qualifiés qui investissent beaucoup d'attention et de temps dans leur travail et ont donc besoin d'une annulation fiable et d'une récupération après erreur. Il rappelle aussi le paradoxe de l'utilisateur actif : les gens commencent à se servir d'un outil avant de chercher à le comprendre. C'est un argument contre la formation comme principal levier d'adoption.

Conduite du changement, formations et charge cognitive

La conduite du changement prépare l'organisation à changer sa façon de travailler, ce n'est ni un e-mail groupé ni une formation de deux heures avant le lancement. Dans une étude menée auprès de plus de 2 600 praticiens, Prosci a mis en relation la qualité de la conduite du changement et l'atteinte des objectifs du projet : avec un programme excellent, 88 % des projets ont atteint ou dépassé leurs objectifs, contre 13 % avec un programme faible. Il s'agit d'une corrélation, pas d'une expérience, mais l'écart est trop large pour être balayé. Selon le Panorama Consulting Group, moins d'un quart des organisations déclarent par ailleurs un effort intensif de conduite du changement.

L'autre moitié du problème est la charge cognitive, c'est-à-dire la quantité de ressources mentales nécessaires pour piloter le système. Le Nielsen Norman Group la divise en charge intrinsèque, qui appartient à la tâche, et charge extrinsèque, qui consomme de l'attention sans aider à comprendre le contenu. La seconde ne manque pas dans les systèmes internes : écrans surchargés, champs sans intérêt pour le rôle concerné, termes issus du modèle de données au lieu du vocabulaire maison. La formation ne l'élimine pas, l'entreprise la paie à chaque nouvelle recrue. La conception l'élimine une fois pour toutes.

Dans un article signé par des chercheurs de Gartner, la Harvard Business Review indique qu'en 2022 un salarié moyen a vécu dix changements d'entreprise planifiés, contre deux en 2016, et le remplacement d'un système obsolète figure parmi les types de changement cités. Votre projet n'est pas en concurrence avec l'inaction, mais avec neuf autres changements.

Résistance au changement ou logiciel légitimement mauvais

C'est ici que les entreprises commettent l'erreur la plus coûteuse du projet. Quand les équipes n'utilisent pas le système, la direction y voit une résistance au changement et ajoute de la pression et une formation de plus. Si le logiciel est réellement mauvais, la pression n'augmentera pas l'adoption, elle déplacera simplement les tableurs parallèles hors de vue et l'entreprise perdra jusqu'à l'information sur le problème. Distinguer ces deux situations ne coûte pourtant pas cher.

Où la résistance se concentre. Si elle s'étale en couche fine dans toute l'entreprise, il s'agit plutôt du changement. Si elle se loge dans un seul rôle, il s'agit de la conception : c'est précisément le mode opératoire de ce rôle que le système ne prend pas en charge.
Comment l'objection est formulée. « Je n'en veux pas » est une posture. « Je ne sais pas où enregistrer une affaire quand le client paie un acompte et que la facturation part sur une troisième société » est un rapport de bug.
Qui refuse. Si ce sont vos collaborateurs les plus performants qui reviennent à Excel, c'est-à-dire ceux qui gagneraient le plus à aller plus vite, l'hypothèse de la posture est faible.
Ce que dit le temps par tâche. Mesurez la même opération avant et après la mise en production. Si elle prend plus de temps, la résistance est rationnelle.

Le Nielsen Norman Group y ajoute un constat contre-intuitif : les erreurs d'inattention frappent surtout les personnes qui exécutent la tâche de façon routinière, parce qu'un travail bien rodé mobilise moins d'attention. Il fournit aussi la phrase à afficher au mur de chaque réunion sur les systèmes internes : si l'erreur a été aussi facile à commettre, la faute en revient au concepteur. Une hausse du taux d'erreur chez les utilisateurs expérimentés après la mise en production n'est pas un signal sur leur compétence, mais sur l'interface.

La conception concerne les utilisateurs, pas seulement leurs managers

Le manager décrit le processus tel qu'il devrait être. L'utilisateur sait à quoi il ressemble vraiment. La différence tient aux exceptions : le client qui demande une facturation scindée, le fournisseur qui envoie un PDF au lieu de données. Le chemin principal se ressemble partout, l'argent et la friction se logent dans les exceptions, que le manager ne traite pas et ne connaît donc pas.

McKinsey apporte sur ce point une donnée issue de son enquête sur les transformations numériques : lorsque les collaborateurs proposent eux-mêmes des idées sur les endroits où la numérisation pourrait aider, les répondants rapportent un succès 1,4 fois plus souvent, et la redistribution des rôles et des responsabilités en cohérence avec les objectifs de la transformation multiplie par 1,5 la probabilité de réussite. Impliquer les gens n'est pas un geste culturel, c'est une variable de l'équation.

La démarche coûte peu : une demi-journée assis à côté de personnes occupant des rôles différents, à observer où elles hésitent et ce qu'elles contournent. Cela ne ressortira jamais d'un atelier, car au bout d'un moment plus personne n'a conscience de ses contournements.

La conclusion honnête est souvent désagréable pour le prestataire. Il arrive que le verdict soit de ne rien construire : il faut supprimer le processus, il suffit de mieux configurer l'outil que l'entreprise paie déjà, ou d'acheter deux modules de moins. Un processus marginal, avec quelques cas par mois, doit rester dans un tableur avec un propriétaire clairement désigné, parce que le développement ne serait jamais rentabilisé. L'ordre des étapes n'est pas fortuit : supprimer, simplifier, automatiser, étendre. Le développement sur mesure a du sens là où le processus constitue un avantage concurrentiel ou un goulot d'étranglement, pas là où il existe simplement un tableur. J'ai développé ce point dans un article expliquant qu'une entreprise est un seul produit et que chaque mauvais processus en est la dette technique.

Quatre décisions de conception qui déterminent l'adoption

La divulgation progressive (progressive disclosure). L'interface montre d'abord les options courantes et ne rend les options avancées accessibles qu'à la demande. Jakob Nielsen la décrit comme une technique qui améliore trois des cinq composantes de l'utilisabilité : la facilité d'apprentissage, l'efficacité d'usage et le taux d'erreur. Il y ajoute un second principe : ce qui figure sur l'écran d'accueil est ce qui compte pour l'utilisateur. Le premier écran est une affirmation sur les priorités de l'entreprise, et la plupart des systèmes affirment que tout est prioritaire en même temps.
Des valeurs par défaut pertinentes. Une valeur par défaut est une décision que l'entreprise prend une fois, au lieu de la laisser reprendre par chacun à chaque enregistrement. Un bon défaut n'est pas un champ vide, mais la valeur correcte la plus fréquente. Le Nielsen Norman Group y range aussi le réaffichage des données déjà saisies et des libellés empruntés au vocabulaire de l'entreprise, pas aux colonnes de la base de données.
La prévention des erreurs (error prevention). L'interface doit être conçue pour que l'erreur soit impossible, ou du moins qu'elle ne soit pas facile. Le Nielsen Norman Group recommande quatre stratégies : des contraintes utiles, des suggestions de valeurs, de bons défauts et un traitement indulgent des saisies. Une erreur interceptée à la saisie coûte une seconde, la même erreur au moment de la facturation coûte des heures de travail et une part de la relation client.
Des interfaces par rôle (role-based interface). Une seule base de données, des écrans différents. Le magasinier n'a pas besoin de voir la marge, et chaque champ superflu pèse sur tous ceux qui ne le renseigneront pas. Le Nielsen Norman Group rappelle que tout utilisateur finit par atteindre un plateau d'efficacité, où l'usage supplémentaire ne fait plus progresser la performance. Ce sont les accélérateurs qui font franchir ce plafond : raccourcis clavier, macros, gestes.

Comment mesurer l'adoption

L'adoption ne se mesure pas au ressenti d'une réunion. Définissez ce jeu d'indicateurs avant le lancement, pour avoir un point de comparaison.

Adoption. Part des utilisateurs visés ayant réalisé une opération clé dans le système sur la période donnée. Pas les connexions, se connecter n'est pas travailler.
Utilisateurs actifs dans le temps. Un pic après la formation, suivi d'une baisse, est le portrait d'un système que les gens ont essayé puis abandonné.
Temps par tâche. Sur les opérations les plus fréquentes, mesuré avant et après la mise en production. Entrée directe dans le produit décrit plus haut.
Taux d'erreur. Corrections, annulations, interventions manuelles, documents à refaire.
Tickets au support. Non pas leur nombre, mais le rapport entre « je ne sais pas comment faire » et « le système ne me laisse pas faire ». Le premier relève de l'onboarding, le second de la conception.
Nombre de tableurs parallèles. L'indicateur le plus sincère : le tableur ne disparaît que lorsque le système est plus rapide que lui.

Ces chiffres mettent en regard le coût d'une correction de l'interface et le coût de la friction que l'entreprise paie chaque mois. C'est avec la même arithmétique que j'ai comparé les cas où un bon système interne se rentabilise plus vite qu'un nouveau salarié.

Le tableau de bord de direction et l'interface de travail ne doivent pas se ressembler

Le tableau de bord répond à la question de savoir comment l'entreprise se porte. On le lit, et il supporte quelques secondes de chargement. L'interface de travail répond à la question de savoir quoi faire maintenant de cette commande. Elle s'ouvre des dizaines de fois par jour, on y saisit des données, elle a besoin de vitesse, de clavier et de prévention des erreurs. Conçues de la même manière, elles donnent deux produits médiocres.

Un mécanisme politique se cache derrière cela. C'est le tableau de bord que l'on montre en présentation, il reçoit donc l'attention des designers et le budget. L'écran de travail n'est jamais montré, alors que c'est précisément là que l'argent se crée et se perd. Le budget de conception doit suivre la fréquence d'utilisation, pas le niveau hiérarchique de celui qui regarde l'écran.

Ce qu'il faut retenir

Inscrivez l'objectif d'adoption et sa méthode de mesure dans le cahier des charges avant de signer le contrat. Sans indicateur d'usage, le prestataire n'a aucune raison de s'en occuper.
Mesurez le temps par tâche sur les opérations les plus fréquentes avant la mise en production. Sans valeur de départ, ni l'amélioration ni la dégradation ne sont démontrables.
Faites l'inventaire des tableurs parallèles. Chacun est un cahier des charges pour corriger un processus ou une interface, plus précis que tout ce qui sort d'un atelier.
Avant la prochaine formation, demandez-vous si vous formez vos équipes au travail ou au contournement d'une mauvaise interface. Le premier est un investissement, le second un coût récurrent.
Avant de commander du développement, vérifiez si le problème ne se règle pas en supprimant une étape, en simplifiant le processus ou en configurant mieux l'outil que vous payez déjà. Le diagnostic coûte moins cher que l'implémentation.