Le mirage du Go-Live : pourquoi un projet ne commence vraiment qu’après le déploiement.

Lors du séminaire de présentation du nouvel outil, tout semble prêt pour le lancement.
Les fonctionnalités sont là, le projet est officiellement lancé.

Pourtant, au moment des premières démonstrations, une réalité apparaît déjà :
une partie de l’équipe continue d’utiliser un fichier Excel partagé.

Pas parce que l’outil est mauvais.
Mais parce que la réalité du quotidien n’a pas été prise en compte.

Et dans les projets de transformation, les freins se nichent souvent dans les détails.

Cette scène est loin d’être exceptionnelle.
Dans beaucoup d’organisations, la réussite d’un projet de déploiement d’outil est encore définie de manière très simple :

l’outil est livré, la fonctionnalité est disponible, le projet est considéré comme terminé.

Pourtant, sur le terrain, la réalité est souvent différente.

L’organisation pense avoir livré un outil.
En réalité, elle ouvre une nouvelle phase d’adaptation des pratiques de travail.

Le vrai projet commence dans la majorité des cas… après le déploiement.

Le décalage entre la solution et le terrain.

Dans de nombreux projets, l’objectif initial est clair : répondre à un besoin fonctionnel, comme structurer certaines informations ou simplifier un processus. Sur le papier, ces objectifs sont souvent parfaitement cohérents.

Mais une question essentielle apparaît rapidement : est-ce que la solution correspond réellement aux besoins quotidiens des utilisateurs ?

Dans la salle de projet, tout semble cohérent.

Sur le terrain, les utilisateurs reviennent parfois vers Excel, simplement parce que c’est l’outil qu’ils connaissent déjà.

Une fonctionnalité peut être techniquement pertinente.

Mais si les utilisateurs ne perçoivent pas clairement comment elle s’intègre dans leur quotidien, son adoption restera limitée.

Dans ce type de situation, les équipes ne rejettent pas forcément l’outil. Elles l’ignorent simplement.

L’autopsie d’un cas classique : l’outil d’onboarding*.

Prenons l’exemple d’un nouvel outil d’onboarding client. L’outil permet de structurer la collecte d’informations et de sécuriser certaines données techniques. Du point de vue du projet, l’objectif est rempli. Mais du point de vue des utilisateurs, cet outil facilite-t-il réellement leur quotidien ? Réduit-il certaines frictions opérationnelles ou ajoute-t-il simplement une nouvelle étape dans un processus déjà complexe ? Un outil peut être parfaitement conçu… et rester inutilisé.

La vraie question n’est pas : “Est-ce que l’outil fonctionne ?”

Mais : “Est-ce que quelqu’un a réellement envie de l’utiliser lundi matin ?”

* L’onboarding client est l’équivalent de ce que nous appelons plus couramment l’entrée en relation ou “l’intégration de nouveaux clients”. C’est une étape clé dans la relation commerciale qui marquera le début d’une histoire entre vos clients et votre société.

La pyramide de Maslow de l’adoption

Pour comprendre les mécanismes d’adoption, il faut se rendre à l’évidence : une fonctionnalité ne sera réellement utilisée que si les utilisateurs comprennent pourquoi elle existe et en quoi elle améliore leur travail.

L’adoption repose sur une logique très proche de celle décrite par la pyramide de Maslow appliquée aux usages.

Si l’utilisateur ne perçoit pas clairement le bénéfice dans son quotidien, l’outil restera secondaire. Il faut donc connecter la solution aux problématiques concrètes du terrain et montrer l’impact positif sur le travail des équipes. Parler du travail réel plutôt que des objectifs théoriques est souvent beaucoup plus efficace.

3 leviers pour hacker l’adoption dès le départ

Avec le recul, plusieurs pratiques permettent de favoriser l’adoption dès le départ:

1. Intégrer les utilisateurs très tôt : Cela passe par des interviews, des phases de tests régulières et des recettes fonctionnelles réalisées par les équipes métier. Cette approche permet de confronter la solution aux réalités opérationnelles.
2. Armer les « Key Users » : Ces utilisateurs référents jouent un rôle essentiel. Au moment du déploiement, ils deviennent souvent de véritables ambassadeurs, les “Avengers” de la solution. Parce qu’ils connaissent les réalités opérationnelles, ils peuvent expliquer l’outil à leurs collègues et rassurer sur les changements. L’outil cesse alors d’être perçu comme un projet purement technique. Il devient un outil porté par les utilisateurs eux-mêmes.
3. Instaurer un comité de pilotage transverse : Dans certains projets, cela permet à chaque service d’exprimer ses contraintes et ses attentes. Les décisions deviennent alors plus collectives et mieux comprises.

Redéfinir la réussite (et le rôle du Chef de Projet).

La réussite d’un projet de déploiement d’outils ne peut pas se limiter à la livraison d’une fonctionnalité. Elle doit être évaluée à travers des indicateurs d’usage, tels que le taux d’utilisation réel, le volume de tickets de support, ou encore le niveau de satisfaction des utilisateurs.

Dans ce type de projet, le rôle du chef de projet dépasse largement la coordination technique. Il devient un facilitateur de transformation.

Le chef de projet devient souvent le tampon entre trois mondes qui ne parlent pas la même langue :

• l’IT
• les métiers
• la direction.

Un projet n’appartient ni à l’IT, ni à l’équipe projet.

Il appartient avant tout aux utilisateurs qui devront l’utiliser au quotidien.

Paradoxalement, l’un des meilleurs indicateurs de réussite apparaît parfois longtemps après la fin officielle du projet. Lorsque des utilisateurs continuent de revenir vers le chef de projet plusieurs mois ou années plus tard parce qu’ils le considèrent encore comme leur référent, cela signifie souvent que le projet a réussi à créer une véritable relation de confiance autour du changement.

---

Julie Guerin

Julie Guerin est cheffe de projet interne spécialisée dans les projets de transformation organisationnelle et l’optimisation des processus dans des environnements SaaS B2B. Elle accompagne les organisations dans le déploiement d’outils et l’évolution des pratiques de travail, avec une attention particulière portée à l’adoption par les utilisateurs.

Son parcours, qui combine expérience en relation client et pilotage de projets transverses, lui permet d’aborder la transformation sous l’angle des usages réels et de la coordination entre équipes métiers et équipes techniques.

Julie intervient notamment sur des projets impliquant ERP, CRM et transformation des processus internes, en plaçant l’alignement entre stratégie, organisation et outils au cœur de la réussite des projets.

À travers ses publications, elle partage des retours d’expérience concrets sur la conduite du changement, l’adoption des outils et les enjeux humains des transformations organisationnelles.