Votre outil numérique n'est pas adopté : ce n'est pas (que) la résistance au changement
Vous avez déployé un nouvel outil. Les équipes ont été formées. Trois mois plus tard, tout le monde l'utilise pour les validations officielles et garde son Excel pour le vrai travail. Ce n'est pas un problème culturel. C'est un signal précis sur la façon dont l'outil a été conçu.
Donatien Lefranc
Fondateur & Président, Leando
L'outil est là. L'Excel aussi.
Lundi matin. Votre responsable ADV ouvre le CRM pour encoder les commandes de la semaine. Il ouvre aussi son fichier Excel, comme d'habitude. Le CRM reçoit les données officielles : les commandes validées, les statuts nets. L'Excel reçoit les vraies informations : les commandes en attente de confirmation verbale, les clients qui ont négocié un tarif spécial vendredi dernier, les relances à planifier avant jeudi.
Ce double usage, vous le retrouvez dans beaucoup de PME. Parfois avec un CRM, parfois avec un ERP, parfois avec l'outil de ticketing que vous avez installé pour votre SAV. L'outil officiel est utilisé pour ce qu'il est censé couvrir. Le reste continue de vivre ailleurs, dans les fichiers personnels, les fils de messages Teams, les carnets.
Pourquoi les équipes ne signalent pas le problème
Elles ne se plaignent pas. Elles s'adaptent. Rapidement, silencieusement. Le double usage devient une habitude, une organisation qui tient à force d'ajustements tacites. Personne ne fait le lien entre la qualité des données dans l'outil et la façon dont cet outil a été pensé au départ.
Du côté du dirigeant ou du responsable de projet, le taux d'adoption faible est lu comme un signal culturel : les équipes résistent, elles ont du mal avec le changement, il faut les accompagner davantage. La deuxième session de formation est commandée. Les équipes y assistent, reprennent leur Excel.
Ce que le double usage dit vraiment
Le double usage est un signal précis, pas un signal d'ordre culturel. L'outil couvre les cas officiels : le flux théorique, la version propre du processus, les étapes prévues. L'Excel couvre le reste : les exceptions, les cas particuliers, les informations sans champ dédié, les états intermédiaires que le processus réel génère mais que personne n'avait prévus à la conception.
Ce n'est pas que l'équipe refuse l'outil. C'est que l'outil ne couvre pas ce que l'équipe fait vraiment. La distinction change tout à ce qu'on décide ensuite.
Le processus qu'on a décrit et le processus qui existe
Quand un outil est conçu ou paramétré, on demande aux équipes de décrire leur processus. Elles décrivent le processus tel qu'il devrait être, pas tel qu'il est. Ce n'est pas de la mauvaise foi. Personne ne décrit spontanément ses raccourcis, ses workarounds, ses conventions informelles. On raconte la version normative, celle qu'on croit attendue. L'outil est alors construit sur cette version. La version réelle continue de vivre en dehors.
La question qui biaise tout
« Comment ça se passe chez vous pour traiter une commande ? » La réponse est presque toujours le processus officiel. « Le commercial reçoit la demande, il l'encode dans le CRM, il génère un devis, il l'envoie au client. »
Ce que cette question ne capture pas : le commercial fait d'abord un rapide appel pour vérifier si la demande est sérieuse avant de toucher au CRM. Il enregistre la commande dans son fichier de suivi personnel en attendant la confirmation écrite. Il génère le devis depuis le modèle Google Docs affiné collectivement depuis dix-huit mois, parce que les modèles du CRM n'ont jamais couvert les cas avec remises variables. Il copie ensuite le numéro de devis dans son fichier de suivi.
Ce processus fantôme, personne ne l'a documenté. Il s'est construit organiquement, par adaptation collective au fil du temps. Il est efficace à sa façon. L'outil officiel ne le sait pas, parce qu'il n'a jamais été conçu pour le voir.
« Souvent ce ne sont pas des sujets tech. C'est souvent un sujet organisationnel, systémique, et ensuite en effet technologique. »
Pourquoi observer est différent de demander
Observer, c'est passer une matinée dans l'équipe, regarder travailler, poser des questions en temps réel sur ce qu'on voit. « Pourquoi vous ouvrez ce fichier-là ? » « Qu'est-ce qui se passe si le client change d'avis à ce stade ? » « D'où vient ce statut que je vois dans votre tableur mais pas dans l'outil ? »
Les processus fantômes remontent. Non pas parce que les équipes les cachaient, mais parce qu'ils sont tellement intégrés dans le quotidien qu'ils n'auraient jamais émergé par une question directe en atelier.
Chez Hydroconsult, un bureau d'étude offshore de 50 personnes en Bretagne, les dirigeants étaient persuadés d'avoir besoin d'un outil précis, qu'ils avaient identifié. Ce qu'ils avaient besoin en réalité, c'était d'une vision claire de comment leur information circulait vraiment dans l'entreprise, et de deux ou trois frictions réelles qui coûtaient de l'énergie à leurs équipes chaque semaine. La demande initiale n'était pas inexacte. Elle était incomplète, parce qu'elle partait des symptômes visibles, pas des processus observés.
Ce que ça produit de partir du processus réel
Cartoon Prod organise des soirées de stand-up dans toute la France. Pour chaque soirée, plusieurs contrats artistes à générer, plusieurs communications à préparer et envoyer. Un processus répétitif, avec des variantes que des ateliers classiques de recueil de besoins auraient probablement lissées.
L'approche a été simple : faire parler le dirigeant de son quotidien réel. Comment il préparait les contrats. Avec qui il travaillait. Ce qui générait des allers-retours. Ce qui partait parfois dans le mauvais sens et forçait des corrections. Trois ateliers d'observation et de mapping ont produit une image fidèle du processus, avec ses variantes, ses cas particuliers, ses points de friction concrets.
« On est parti juste modéliser son processus, lui faire parler de son quotidien : quels étaient les différents éléments, comment il communiquait avec les artistes, qu'est-ce qui générait parfois des allers-retours. »
Pourquoi le ROI s'est matérialisé
L'outil livré en deux semaines correspondait exactement au processus observé, pas à une version idéalisée que personne ne pratiquait vraiment. Résultat : pas d'Excel en parallèle, pas de contournement, pas d'itérations correctives pour couvrir les cas oubliés. Le ROI estimé à 6-7 mois s'est tenu parce que l'outil était utilisé à plein dès la mise en production.
C'est la différence entre un outil que les équipes adoptent parce qu'il ressemble à leur travail réel, et un outil qu'on doit revendre à chaque réunion d'équipe.
Pour structurer votre SI avant de choisir ou de construire un outil : comment moderniser le SI d'une PME sans tout casser.
Ce que vous pouvez faire avant le prochain déploiement
Observer avant de configurer
Si vous pilotez un projet d'outil ou une refonte de processus, la question à poser avant toute configuration est directe : avez-vous passé du temps à observer les équipes travailler, ou avez-vous organisé des ateliers de recueil de besoins ? Les deux ne produisent pas les mêmes informations.
Les ateliers capturent le processus normé. L'observation capture le processus réel. Ce n'est pas une contrainte supplémentaire sur le planning. C'est un gain de temps sur l'ensemble du projet. Un outil aligné sur le réel dès le départ n'a pas besoin de trois itérations correctives et de deux relances de formation avant d'être vraiment adopté.
L'étape concrète à faire cette semaine : choisissez une équipe, bloquez une matinée, observez sans grille de questions. Notez ce qui se passe vraiment : les fichiers ouverts en parallèle, les messages Teams qui remplacent un champ absent dans l'outil, les étapes que personne ne fait dans l'ordre officiel. Ce sont ces décalages qui alimentent un brief d'outil juste, pas le processus théorique.
Pour comparer les options avant de construire ou d'acheter : no-code, SaaS ou sur mesure, le bon choix selon votre stade.
Le signal le plus fiable est le double usage. Si vos équipes utilisent l'outil officiel pour ce qui est visible (validations, envois formels) et gardent un Excel en parallèle pour le vrai travail, c'est rarement un problème de formation. C'est presque toujours un problème d'alignement entre l'outil et les processus réels de vos équipes. Une deuxième session de formation ne résoudra pas ce type de friction.
Votre outil est en place. Vos équipes travaillent à côté ?
Le diagnostic des processus réels prend une semaine. Il identifie les décalages entre ce que vos équipes font vraiment et ce que vos outils attendent d'elles. C'est ce qui manquait avant le déploiement.
Analyser nos processus réels