Skip to main content
Key Takeaways

Friction liée à l’outil: Lorsqu’un outil de gestion de projet génère plus de travail qu’il n’en fait gagner, il est temps de reconsidérer son utilisation.

Problèmes d’adoption: Un faible engagement de l’équipe et une mauvaise intégration peuvent indiquer le besoin de changer d’outil pour plus de fonctionnalités.

Complexité des solutions d’entreprise: Des workflows rigides dans les outils d’entreprise peuvent freiner la productivité, incitant à des options plus simples.

Savoir quand changer: Évaluez les outils pendant trois à six mois ; des problèmes persistants peuvent nécessiter un changement.

Rester en place: Un léger mécontentement ne justifie pas un changement ; évaluez si les bénéfices surpassent la perturbation du changement.

Changer d’outil de gestion de projet n’est jamais une décision prise à la légère. Les coûts de migration, les courbes d’apprentissage, la résistance des équipes — rien n’est anodin. Mais il arrive un moment où la friction de rester dépasse celle de partir. 

Les responsables de la gestion de projet et des opérations qui sont passés par là vous diront qu’après coup, les signes sont souvent évidents. Le plus difficile est de les reconnaître en temps réel et d’agir en conséquence.

Quand l’outil génère plus de travail qu’il n’en fait gagner

Le test le plus fondamental de tout outil de gestion de projet est simple : facilite-t-il le travail ou le complique-t-il ? Matthew Fox, chef de projet principal et spécialiste des opérations chez Fox Consulting, l’explique clairement. « Si vous constatez que votre personnel consacre plus de temps à travailler sur l’outil qu’avec l’outil, c’est un signal d’alerte », affirme-t-il.

Unlock for Free

Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.

Step 1 of 2

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form

Il ajoute que lorsqu’un outil « crée beaucoup de friction », engendre des solutions de contournement et accapare une grande partie de la semaine de l’équipe, c’est qu’il y a un problème. « Un outil doit soutenir le travail en cours, pas créer de la friction quand nous essayons d’accomplir nos tâches. » 

Un outil doit soutenir le travail en cours, pas créer de la friction quand nous essayons d’accomplir nos tâches.

Matthew Fox

Matthew Fox

Matthew Fox, chef de projet principal et spécialiste des opérations chez Fox Consulting

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join. <br><br>

Join the DPM community for access to exclusive content, practical templates, member-only events, and weekly leadership insights - it’s free to join.

This field is for validation purposes and should be left unchanged.
Name*
This field is hidden when viewing the form

Quand l’outil fonctionne… mais juste à peine

Parfois, le problème n’est pas qu’il manque à l’outil des fonctionnalités de gestion de projet essentielles, c’est que leur utilisation relève du parcours du combattant. Julia Rajic, directrice générale chez Point Blank, l’a vécu avec Resource Guru. « En théorie, il pouvait tout faire ce dont nous avions besoin », raconte-t-elle, « mais pour réellement arriver à obtenir cela, c’était comme arracher des dents. » 

La plateforme manquait de flexibilité au quotidien pour son équipe — comme la gestion aisée d’intérimaires ou le simple glisser-déposer pour ajuster les plannings. L’administration, explique-t-elle, « était bien plus compliquée qu’il n’aurait fallu ». Lorsqu’un outil requiert autant d’efforts juste pour fonctionner, il cesse d’être une solution.

Lorsque les lacunes fonctionnelles rencontrent un échec d’adoption

Un changement d’outil ne se produit que rarement pour une seule raison. Rajic évoque un autre changement que son équipe a mené — le passage de monday.com à Asana — où la décision résultait d’une combinaison entre des fonctionnalités manquantes et un manque d’adhésion de l’équipe. « Beaucoup de discussions à propos du départ de monday portaient sur la gestion des ressources », explique-t-elle. « Ce n’était vraiment pas très performant pour la gestion des ressources. » 

Mais la fonctionnalité n’explique pas tout. L’agence n’avait jamais vraiment été correctement formée à monday.com, ce qui a limité l’adoption. « Il y avait beaucoup de réactions du type : ‘Je n’aime pas, c’est nouveau, je refuse de l’utiliser’ », s’amuse Rajic. « Donc l’adoption n’a pas atteint le niveau nécessaire pour que ce soit efficace. » Quand un outil échoue sur les deux tableaux, il devient alors difficile d’argumenter contre un changement. Mais la leçon à retenir est la suivante : si votre équipe n’est pas disposée à s’investir dans la prise en main d’un nouvel outil, ou si votre organisation ne peut consacrer de ressources à cette adoption, il vaut peut-être mieux rester sur l’existant. 

L’adoption [de monday.com] n’a pas été à la hauteur de ce dont nous avions besoin pour que ce soit un succès.

julia rajic

Julia Rajic

Directrice générale chez Point Blank

Quand l’outil d’entreprise devient de la paperasserie

Les plateformes d’entreprise comme Jira sont conçues pour la complexité — mais cette complexité peut se retourner contre vous. Ryan Gilbreath, chef de projet technique chez RTS Labs, a déjà observé ce phénomène. Concernant ce qui fait le succès ou l’échec d’une équipe sur Jira, il explique : « Je pense sincèrement que tout repose sur la façon dont l’administrateur JIRA l’a paramétré et les workflows mis en place. » Si les workflows sont trop rigides et que pour accéder à des documents ou collaborer avec d’autres équipes il faut multiplier les démarches, l’outil ne fait plus avancer le travail, il le freine.

« Si la configuration de [Jira] ralentit la dynamique, dit Gilbreath, je vais probablement sortir de Jira et utiliser autre chose, sûrement un tableur si besoin. » Qu’un chef de projet technique chevronné préfère volontairement revenir à un simple tableur en dit long sur l’ampleur avec laquelle un outil d’entreprise surconfiguré peut échouer à répondre aux besoins.

Si la configuration de [Jira] ralentit la dynamique, je vais probablement sortir de Jira et utiliser autre chose.

Ryan Gilbreath Headshot-90425

Ryan Gilbreath

Chef de projet technique chez RTS Labs

Combien de temps attendre avant de passer à l’action

Tout problème lié à un outil ne nécessite pas forcément un changement immédiat. Melody MacKeand, fondatrice de Melody MacKeand Consulting, préconise de laisser suffisamment de temps à l’optimisation des processus internes avant de conclure que l’outil est en cause. « J’essaye de prévoir un délai de trois à six mois pour redresser la barre », explique-t-elle. 

Si les mêmes soucis persistent passé ce délai, il peut être temps d’agir. Mais MacKeand admet également qu’il existe une raison moins tangible de procéder à un changement. « Si une équipe utilise une plateforme depuis longtemps, par exemple plus de 10 ans, parfois le simple fait de changer d’outil donne le sentiment d’être écouté ou que quelque chose change vraiment. Et dans ce cas, je suis tout à fait ouverte à ce changement d’outil. » Parfois, la valeur d’un changement n’est pas seulement opérationnelle : c’est aussi le signe pour l’équipe que la direction les écoute.

Si une équipe utilise une plateforme depuis longtemps, par exemple plus de 10 ans, parfois le simple fait de changer d’outil donne le sentiment d’être écouté.

Melody Mackeand

Melody MacKeand

Fondatrice, Melody MacKeand Consulting

Les arguments pour rester

Bien sûr, toute insatisfaction vis-à-vis d’un outil ne justifie pas de l’abandonner. Marissa Taffer, fondatrice et présidente de M. Taffer Consulting, nuance ce point de vue : « Je ne veux pas imposer à quelqu’un d’apprendre un nouvel outil juste pour le principe, dit-elle. S’il y a une vraie raison de changer, d’accord. Mais je ne ferai pas le changement uniquement parce que je pense que l’on pourrait mieux organiser le projet dans un autre système. » La migration vers un nouvel outil — le temps, la formation, la résistance — doit être équilibrée avec un bénéfice concret. Des améliorations marginales ne suffisent pas à justifier ce bouleversement.

S’il y a une vraie raison de changer [d’outil], d’accord. Mais je ne ferai pas le changement uniquement parce que je pense que l’on pourrait mieux organiser le projet dans un autre système.

marissa taffer photo

Marissa Taffer

Fondatrice et présidente de M. Taffer Consulting

On retrouve la même logique dans toutes ces perspectives : l’outil est là pour servir l’équipe, et non l’inverse. Lorsque la relation s’inverse — que la plateforme commence à consommer l’énergie, à gêner la progression ou à éroder la confiance — c’est le moment de réagir. Les PM qui gèrent ces choix avec finesse ne sont pas ceux qui ont l’arsenal technologique le plus impressionnant ; ce sont ceux qui savent quand il faut patienter et quand il faut changer.

Envie de recevoir plus d’analyses comme celles-ci ? Créez gratuitement un compte DPM pour lire de nouveaux points de vue d’autres experts.