Vous avez déployé un nouvel outil. Mais les usages ont-ils réellement changé ?

Transformation numérique — Quand le déploiement ne suffit pas à produire la transformation

Le nouvel outil est disponible.

Les agents ont reçu leurs accès.

Une formation a été organisée.

Les procédures ont été mises à jour.

La communication interne a accompagné le lancement.

Quelques semaines plus tard, le projet peut sembler terminé.

Pourtant, une question reste souvent sans réponse :

Les usages ont-ils réellement changé ?

Car entre déployer un outil et transformer une pratique, il existe parfois un écart considérable.

Et c’est précisément dans cet espace que se joue une grande partie de la réussite des projets de transformation.

Un outil déployé n’est pas nécessairement un outil adopté

La transformation numérique des organisations publiques s’accompagne de nombreux nouveaux outils : plateformes collaboratives, applications métier, services numériques, outils de gestion, solutions d’intelligence artificielle, dispositifs de cybersécurité ou nouveaux environnements de travail.

Ces outils peuvent être performants.

Leur déploiement peut être techniquement réussi.

Et pourtant, quelques mois plus tard, certains constats apparaissent.

Les anciennes pratiques persistent.

Certaines fonctionnalités sont peu utilisées.

Des agents développent leurs propres contournements.

Des fichiers parallèles continuent de circuler.

Certaines équipes adoptent rapidement le nouvel environnement tandis que d’autres restent attachées à leurs habitudes.

Ce phénomène ne signifie pas nécessairement que l’outil est mauvais ou que les utilisateurs « résistent au changement ».

Il révèle quelque chose de plus intéressant :

un nouvel outil ne crée pas automatiquement de nouveaux usages.

Déployer ≠ adopter ≠ transformer

Ces trois étapes sont souvent confondues.

Déployer

C’est rendre la solution disponible.

L’outil fonctionne, les accès existent, les infrastructures sont opérationnelles.

Adopter

C’est commencer à l’utiliser réellement.

Les agents comprennent son intérêt et l’intègrent progressivement dans leurs pratiques.

Transformer

C’est lorsque l’outil contribue effectivement à modifier une manière de travailler, de collaborer, de décider ou de rendre un service.

La réussite technique se mesure donc assez facilement.

La réussite d’usage demande d’observer autre chose.

Que font réellement les utilisateurs une fois le projet déployé ?

Pourquoi les usages ne suivent-ils pas toujours ?

Nous expliquons parfois les difficultés d’adoption par un manque de formation.

La réponse semble alors évidente : former davantage.

Mais le problème peut se trouver ailleurs.

Un agent peut parfaitement savoir utiliser une fonctionnalité et ne pas l’intégrer à son quotidien.

Pourquoi ?

Parce que l’ancienne méthode lui semble plus rapide.

Parce que l’outil ajoute une étape.

Parce qu’il ne comprend pas encore ce qu’il gagne à changer.

Parce que le nouvel usage ne correspond pas complètement à sa réalité métier.

Parce que son équipe continue de fonctionner selon les anciennes pratiques.

Parce que certaines situations n’ont jamais été abordées pendant la formation.

Ou simplement parce que comprendre un outil ne signifie pas encore savoir quand, pourquoi et comment l’utiliser dans une situation réelle.

La question n’est donc plus seulement :

« Les agents savent-ils utiliser l’outil ? »

Elle devient :

« Qu’est-ce qui doit changer dans leurs pratiques pour que cet outil produise réellement de la valeur ? »

Passer de la formation à l’expérience d’usage

Une formation classique peut être parfaitement adaptée lorsqu’il faut découvrir une interface, comprendre des fonctionnalités ou apprendre une procédure.

Mais lorsqu’un projet cherche à faire évoluer des pratiques, transmettre des informations ne suffit pas toujours.

Il faut parfois permettre aux utilisateurs d’expérimenter les nouveaux usages.

Prenons un exemple.

Une collectivité déploie un nouvel outil collaboratif.

Nous pouvons expliquer :

où se trouvent les fonctionnalités,

comment créer un espace,

comment partager un document,

comment attribuer une tâche.

Mais nous pouvons également placer les agents face à une situation :

« Vous devez préparer un projet impliquant quatre directions différentes. Comment allez-vous organiser le travail collectif ? »

L’utilisateur doit alors décider.

Créer un espace partagé ?

Envoyer des documents par courriel ?

Attribuer des responsabilités ?

Centraliser les échanges ?

Organiser le suivi ?

Il ne découvre plus simplement les fonctions d’un outil.

Il expérimente une nouvelle manière de travailler.

Et cette différence est fondamentale.

Concevoir à partir des situations réelles

Chez Lian Studio, nous préférons donc commencer par les usages plutôt que par l’outil.

Avant de concevoir un dispositif d’accompagnement, plusieurs questions nous intéressent :

Qui va utiliser cette solution ?

Dans quelles situations ?

Quelles pratiques existent aujourd’hui ?

Lesquelles voulons-nous faire évoluer ?

Quelles difficultés les utilisateurs rencontrent-ils ?

Quels nouveaux comportements souhaitons-nous rendre possibles ?

Qu’est-ce qui pourrait freiner leur adoption ?

À partir de là, l’accompagnement peut prendre des formes très différentes.

Une simulation.

Une mise en situation.

Un parcours interactif.

Un atelier.

Un Serious Game.

Des scénarios métier.

Un dispositif hybride.

Ou des ressources directement disponibles au moment où l’utilisateur en a besoin.

Le format vient ensuite.

L’usage recherché vient d’abord.

Cette orientation correspond directement aux cas d’usage que vous avez identifiés pour la verticale P1 « IA / Transformation numérique » : acculturation IA, adoption de nouveaux outils, cybersécurité et nouveaux usages auprès notamment des agents et managers. Ligne éditorial Lian Studio co…

Observer ce qui se passe après le lancement

Il existe également une autre étape essentielle : le terrain.

Trop souvent, la mesure d’un projet s’arrête à des indicateurs de déploiement.

Nombre de comptes créés.

Nombre de personnes formées.

Taux de connexion.

Modules terminés.

Ces données sont utiles.

Mais elles ne disent pas nécessairement si les pratiques ont changé.

Il faut donc observer les usages.

Quelles fonctionnalités sont réellement utilisées ?

À quels moments ?

Quelles pratiques antérieures persistent ?

Où apparaissent les difficultés ?

Quels contournements les agents inventent-ils ?

Quelles équipes adoptent plus rapidement la solution ?

Pourquoi ?

Qu’est-ce que les utilisateurs nous disent que le cahier des charges n’avait pas prévu ?

Ces observations transforment le déploiement en processus d’apprentissage pour l’organisation elle-même.

Et si nous expérimentions avant de généraliser ?

Pour une collectivité ou un acteur public, cette logique peut commencer avant même un déploiement à grande échelle.

Plutôt que :

CONCEVOIR → DÉPLOYER → FORMER

nous pouvons imaginer :

COMPRENDRE → PROTOTYPER → EXPÉRIMENTER → OBSERVER → AJUSTER → DÉPLOYER

Sur un service.

Un métier.

Quelques agents.

Une situation précise.

L’objectif n’est pas de retarder la transformation.

Au contraire.

Il s’agit d’apprendre suffisamment tôt pour éviter de découvrir les difficultés lorsque la solution est déjà généralisée.

Cette logique d’expérimentation avant généralisation constitue d’ailleurs l’un des axes structurants de votre programme éditorial destiné aux collectivités. Ligne éditorial Lian Studio co…

La transformation est d’abord une affaire d’usages

La technologie compte.

La qualité de l’outil compte.

La formation compte.

L’accompagnement au changement compte.

Mais le véritable indicateur de transformation se trouve ailleurs :

dans ce que les personnes font différemment après le projet.

Un service numérique n’est pas transformant parce qu’il existe.

Une IA n’est pas adoptée parce qu’elle est disponible.

Un outil collaboratif n’améliore pas la coopération parce qu’il a été installé.

Une nouvelle plateforme ne transforme pas automatiquement les pratiques parce que les utilisateurs ont suivi une formation.

La transformation apparaît lorsque la solution trouve sa place dans les situations réelles de travail.

Une autre manière d’accompagner la transformation

C’est aussi là que le Learning Design et l’Experience Design peuvent apporter quelque chose aux projets de transformation publique.

Non pas simplement pour « rendre une formation plus attractive ».

Mais pour concevoir les conditions permettant aux personnes de :

COMPRENDRE → EXPÉRIMENTER → DÉCIDER → PRATIQUER → RECEVOIR DU FEEDBACK → S’APPROPRIER

Nous ne cherchons alors plus uniquement à transmettre le fonctionnement d’un nouvel outil.

Nous cherchons à créer les expériences qui permettront aux nouveaux usages d’émerger.

La question à poser après chaque déploiement

Quelques mois après la mise en service d’un nouvel outil, il peut donc être utile de ne pas demander uniquement :

Combien de personnes l’utilisent ?

Mais aussi :

Qu’est-ce que cet outil leur permet aujourd’hui de faire différemment ?

La nuance peut sembler légère.

Elle change pourtant complètement la manière d’évaluer une transformation.

Parce qu’au fond, la réussite d’un projet numérique ne se mesure pas uniquement à ce qui a été déployé.

Elle se mesure à ce qui a réellement changé dans les usages.