Pourquoi vos équipes n’utilisent pas le SI livré
- Les vraies raisons pour lesquelles un SI livré n’est pas adopté
- Ce que l’analyse UX d’un système institutionnel révèle que les specs n’avaient pas prévu
- Comment intégrer l’expérience utilisateur dans la phase de spécifications, pas après
Un système validé en recette peut très bien ne pas être utilisé
La recette fonctionnelle valide que le système fait ce que les spécifications décrivent. Elle ne valide pas que ce que les spécifications décrivent correspond aux pratiques réelles des utilisateurs. Ce sont deux choses différentes, et confondre les deux est l’une des erreurs les plus coûteuses dans le pilotage de projets SI institutionnels.
Un utilisateur qui valide une fonctionnalité en recette le fait souvent dans un contexte artificiel : il teste un scénario préparé, dans un environnement de test, sans la pression du travail réel. Ce même utilisateur, mis face au système en production avec ses propres données, dans ses conditions de travail habituelles, peut se retrouver bloqué sur des points que personne n’avait anticipés.
Signal d’alarme : Si vos équipes ont développé des « astuces » pour contourner certaines étapes du nouveau système dès les premières semaines de déploiement, ce ne sont pas des problèmes de formation. Ce sont des problèmes de conception fonctionnelle.
Les cinq causes réelles de non-adoption
1. Le flux de travail du système ne correspond pas au flux réel
Le SI a été conçu sur la base des processus tels qu’ils devraient fonctionner selon les procédures officielles. Les utilisateurs fonctionnent selon des processus réels, qui divergent souvent des procédures sur des points précis. Quand le système impose le chemin officiel, les utilisateurs qui travaillent autrement se retrouvent bloqués ou obligés de contourner.
La solution n’est pas de former les utilisateurs à suivre les procédures officielles. C’est de comprendre, lors de la phase d’analyse fonctionnelle, pourquoi les procédures officielles ne sont pas suivies et si les processus réels sont plus efficaces.
2. La charge cognitive est sous-estimée
Un système peut être fonctionnellement complet et cognitivement épuisant à utiliser. Trop d’étapes pour accomplir une action simple, des terminologies qui ne correspondent pas au vocabulaire métier, des interfaces qui demandent de mémoriser des séquences non intuitives. Dans des environnements à forte charge comme les hôpitaux, cette friction cognitive n’est pas acceptable : les utilisateurs reviennent aux outils qu’ils maîtrisent.
3. Les cas d’usage minoritaires mais critiques ont été ignorés
Les spécifications couvrent généralement les cas nominaux : ce qui arrive le plus souvent. Les cas d’exception, qui représentent peut-être 10% des situations mais 40% de la charge de travail réelle, ont été traités en bas de priorité ou ignorés. Pour les utilisateurs qui gèrent régulièrement ces situations, le nouveau système est moins efficace que l’ancien.
4. La migration des données a créé des incohérences
Lors d’une migration, les données de l’ancien système sont rarement propres. Des champs mal mappés, des historiques tronqués, des références obsolètes : les utilisateurs découvrent ces incohérences en production et perdent confiance dans le système. Un travail de qualification des données en amont de la migration, intégré dans les spécifications techniques, prévient la majorité de ces problèmes.
5. La formation a couvert l’outil, pas le changement de pratique
Former les utilisateurs à utiliser un nouveau SI, c’est leur montrer où cliquer. Ce n’est pas les aider à comprendre pourquoi leurs pratiques de travail vont changer et comment le nouveau système s’intègre dans leur quotidien. Sans cette dimension, les utilisateurs savent utiliser le système mais ne voient pas l’intérêt de l’adopter.
Erreur fréquente : Commander une formation complémentaire six mois après le déploiement pour régler un problème d’adoption est souvent inefficace. Si les utilisateurs n’adoptent pas le système, la formation n’est probablement pas le problème.
Ce qu’une analyse UX d’un SI institutionnel révèle
L’analyse UX appliquée à un système d’information institutionnel ne se limite pas aux interfaces graphiques. Elle couvre l’ensemble de l’expérience de l’utilisateur dans son interaction avec le système : les flux de travail, les temps de réponse, la cohérence des terminologies, la gestion des erreurs et les cas d’exception.
Conduite après déploiement, cette analyse produit un diagnostic précis des frictions : quelles étapes génèrent le plus d’abandon, quels profils utilisateurs rencontrent le plus de difficultés, quels cas d’usage sont systématiquement contournés. Ces données permettent de prioriser les corrections avec une logique d’impact mesurable plutôt qu’une logique de demandes individuelles.
Conduite en amont, lors de la phase de prototypage ou de recette, elle prévient ces problèmes avant que le système soit déployé. C’est l’usage le plus efficace : quelques sessions d’observation avec des utilisateurs représentatifs révèlent des points de friction que des semaines de spécifications n’avaient pas identifiés.
En pratique : Dans un projet de refonte documentaire pour une institution publique genevoise, trois sessions d’observation de 90 minutes avec des utilisateurs terrain ont révélé deux flux de travail critiques absents des spécifications. Intégrés avant le développement, ils ont évité un cycle complet de correctifs post-déploiement.
Intégrer la dimension utilisateur dès les spécifications
La meilleure façon de prévenir les problèmes d’adoption est de ne pas séparer la conception fonctionnelle et l’expérience utilisateur. Les deux doivent être traitées dans la même phase, avec les mêmes parties prenantes.
Concrètement, cela signifie que les cas d’usage rédigés dans le cahier des charges incluent non seulement le scénario fonctionnel mais aussi les conditions dans lesquelles il sera exécuté : charge de travail de l’utilisateur à ce moment, outils utilisés en parallèle, niveau d’expertise attendu, contraintes de temps. Ces éléments de contexte sont indispensables pour concevoir un système qui sera réellement adopté.
Questions fréquentes
Quand est-il trop tard pour corriger un problème d’adoption ?
Il n’est jamais trop tard, mais le coût augmente avec le temps. Une correction six mois après déploiement est significativement moins coûteuse qu’une refonte deux ans plus tard, quand des pratiques de contournement sont devenues la norme dans l’organisation. La priorité est de diagnostiquer précisément les causes avant de décider d’une action corrective.
Comment distinguer un problème de formation d’un problème de conception ?
Un problème de formation se manifeste par des erreurs dans l’utilisation des fonctionnalités existantes. Un problème de conception se manifeste par un contournement systématique de certaines fonctionnalités, ou par l’utilisation d’outils alternatifs pour accomplir des tâches que le système devrait couvrir. Le deuxième type nécessite une analyse fonctionnelle, pas une formation.
L’analyse UX est-elle pertinente pour des systèmes internes non grand public ?
Oui, et souvent davantage. Les utilisateurs de systèmes grand public peuvent choisir de ne pas utiliser un service mal conçu. Les utilisateurs de systèmes institutionnels n’ont pas ce choix : ils développent des contournements, ce qui crée des problèmes de qualité de données, de sécurité et de traçabilité bien plus coûteux à terme.
Combien de sessions d’observation utilisateur sont nécessaires pour un diagnostic utile ?
Entre trois et huit sessions selon la diversité des profils utilisateurs. Au-delà de huit sessions avec le même profil, les retours nouveaux se raréfient. L’enjeu est de couvrir les profils les plus différents, pas d’accumuler des sessions avec des utilisateurs similaires.
Votre SI souffre d’un problème d’adoption ?
Un diagnostic fonctionnel permet d’identifier précisément les causes et de prioriser les corrections selon leur impact réel sur les équipes.
Prendre rendez-vous
