Une DSI déploie un outil sans accroc, ne reçoit aucun signalement, et se félicite, jusqu’à découvrir que le silence ne signalait pas l’adoption mais son absence. Livrer un système n’a jamais suffi à transformer un usage.
Le silence n’est pas toujours bon signe. Une DSI déploie un nouvel outil. La mise en production se passe sans accroc, malgré une fin de projet un peu chaotique. Les premiers jours ne génèrent aucun signalement, aucun ticket d’incident. L’équipe se félicite, jusqu’au moment où, par un réflexe heureux de vigilance, elle se demande pourquoi un déploiement de cette ampleur ne génère absolument aucun retour. La réponse, quand elle arrive, est nette : les utilisateurs n’ont jamais pris en main l’outil. Ils sont restés sur l’ancien système. Le silence n’était pas un succès. C’était l’absence d’usage.
Ce cas, aussi caricatural soit-il, illustre une réalité qui se répète sous des formes plus discrètes dans la plupart des transformations : livrer un système n’a jamais suffi à transformer un usage.
Un sujet dimensionné, mais rarement intégré au cœur du projet
Dans beaucoup d’organisations, l’accompagnement aux usages existe, porté par des équipes RH sur le volet formation, ou par des équipes change dédiées à l’absorption du changement. Ce n’est donc pas un sujet ignoré. Le problème est ailleurs : ces dispositifs restent trop souvent en périphérie du projet, plutôt qu’au cœur de sa conception.
Conséquence directe : ces équipes, quand elles existent, ne sont généralement pas dimensionnées pour traiter l’ensemble des transformations menées en parallèle dans l’entreprise. Et la réflexion sur l’usage réel, comment l’utilisateur va vivre le changement, quels gestes vont être perturbés, quels freins paraîtront infimes d’un point de vue technique mais deviendront de vraies frictions opérationnelles, arrive souvent trop tard pour influencer encore la conception de la solution.
Penser l’usage en amont change la solution, pas seulement son accompagnement
C’est le point le plus souvent sous-estimé : intégrer la réflexion usage dès l’amont ne sert pas seulement à mieux accompagner un système déjà conçu. Elle peut changer la conception même de la solution.
Un exemple simple, presque trivial, l’illustre bien : équiper des opérateurs terrain d’un outil digital sans tenir compte de leurs conditions réelles de travail, un écran tactile inutilisable avec des gants, par exemple, condamne l’usage avant même le déploiement, quelle que soit la qualité de l’outil. Le même principe s’applique à des contextes plus immatériels. Un conseiller relation client qui doit naviguer entre plusieurs interfaces pour collecter une information le ralentit dans son interaction avec le client et lui fait réaliser des manipulations sans valeur perçue. Penser l’usage en amont, c’est se demander ce que la personne qui réalise le geste métier a en tête à ce moment précis, et concevoir l’outil pour ce moment-là, une console centralisée plutôt que plusieurs écrans, deux clics évités, une information restituée au bon endroit. Ce sont des choix de conception, pas des choix d’accompagnement après coup.
Occuper le terrain : un rôle de connaissance des usages, pas seulement d’alerte
Au-delà de la détection précoce, il y a une responsabilité plus large et plus exigeante que la DSI peut choisir d’occuper : être présente sur le terrain pour recueillir, en continu, les retours et la perception réelle des utilisateurs sur les applications qu’elle a déployées. Ce rôle ressemble à celui que des fonctions de maîtrise d’ouvrage étaient censées tenir historiquement, sauf que dans les faits, ces rôles se sont souvent vidés de leur dimension opérationnelle, fonctionnant comme une interface métier sans réelle préoccupation pour la façon dont les utilisateurs travaillent concrètement.
Occuper ce terrain n’a rien d’évident. Les retours sont parfois rudes, parfois désagréables à entendre, des lenteurs jugées insupportables, des irritants répétés depuis longtemps. Mais c’est précisément cette présence inconfortable qui permet de capter les points de friction réels avant qu’ils ne deviennent des causes de rejet silencieux.
Ce recueil ne vaut cependant rien sans une gouvernance qui le prolonge. Entendre un irritant à plusieurs reprises sans jamais le faire remonter avec le bon niveau de priorité auprès du métier qui peut le traiter revient à décrédibiliser toute la démarche. Le risque le plus dommageable n’est pas de répondre « non, pas maintenant, nous traitons d’autres priorités », c’est de ne rien répondre du tout, et de laisser les acteurs de terrain de la DSI dire « oui je sais, on a entendu » sans jamais transformer cette écoute en décision visible. Une réponse honnête, même négative, construit la relation. Le silence prolongé la détruit.
Le rôle de la DSI : détecter le trou, pas nécessairement le combler seule
Cette dimension usage n’a pas vocation à être portée par la DSI elle-même dans son intégralité. Elle relève d’une expertise différente terrain, opérationnelle, humaine, que la DSI n’a généralement pas la légitimité ni la capacité d’exercer seule. Pourtant, dans les faits, elle s’y retrouve fréquemment, faute de mieux : un projet de transformation est traité comme l’un des nombreux projets de l’entreprise, sans dimensionnement spécifique de l’accompagnement, et la DSI finit par porter le fardeau jusqu’au bout, livrer le système, faire une formation souvent technique plutôt qu’orientée usage, et considérer le projet terminé à la mise en production.
Une DSI mature ne cherche pas à endosser ce rôle qu’elle n’est pas la mieux placée pour tenir seule. Elle assume en revanche une responsabilité plus ciblée et tout aussi importante : occuper suffisamment le terrain pour détecter, le plus tôt possible, les signaux d’un manque d’accompagnement à venir, et construire la gouvernance qui permet de transformer ces signaux en priorités traitées ou explicitement refusées, mais jamais ignorées.
Il y a pourtant une situation où la détection seule ne suffit plus : quand un irritant entendu sur le terrain, encore et encore, n’obtient jamais la priorité nécessaire dans la gouvernance officielle, trop petit pour mériter un projet, trop récurrent pour être ignorable. C’est là qu’une DSI qui a vraiment occupé le terrain peut choisir de hacker la situation : traiter elle-même ce point, sans attendre l’arbitrage qui ne viendra jamais, en s’appuyant précisément sur ce qu’elle a entendu directement plutôt que sur ce qu’un processus officiel aurait validé. Ce n’est légitime que parce que l’information vient d’une présence terrain réelle, pas d’une intuition non vérifiée, mais c’est précisément cette présence qui donne à la DSI la conviction nécessaire pour agir avant que le sujet ne soit officiellement priorisé.
Ce que cela implique concrètement.
Pour le DSI : porter, dans la gouvernance de projet, une responsabilité explicite de détection précoce des manques d’accompagnement, et oser traiter elle-même un irritant remonté du terrain quand la priorisation officielle ne le fait jamais, sans se substituer aux équipes RH ou change sur le reste.
Pour le CODIR IT : intégrer la réflexion usage dès la phase de conception des projets de transformation, au même niveau d’attention que les choix techniques, et construire la gouvernance qui garantit qu’un retour terrain remonté obtient toujours une réponse, même négative.
Pour les managers IT : occuper le terrain pour recueillir la perception réelle des utilisateurs, distinguer la formation technique de l’accompagnement à l’usage réel, et refuser de se contenter d’un « on sait, on espère que ce sera pris en compte » qui décrédibilise la démarche.
Pour les métiers : accepter de libérer des opérationnels pour contribuer à la réflexion usage en amont des projets, et jouer leur rôle dans le traitement des priorités remontées par la DSI plutôt que de laisser ces retours sans réponse.
Votre dernier déploiement a-t-il généré du silence par satisfaction, ou par absence d’usage ? Participez à notre enquête sur le positionnement des DSI et comparez-vous à vos pairs → ici
