Pourquoi vos équipes résistent aux projets SI (et ce qu’un BA peut y faire)
- Pourquoi la résistance est un signal analytique, pas un problème humain
- Les trois formes de résistance les plus courantes en milieu institutionnel
- Le rôle concret d’un Business Analyst dans leur résolution
La résistance n’est pas le problème : c’est le symptôme
Quand une direction lance un projet SI et que les équipes terrain freinent, la réaction naturelle est de qualifier le problème de « résistance au changement » et de commander une formation. C’est une erreur de diagnostic.
Dans la quasi-totalité des cas observés en milieu hospitalier et bancaire, la résistance exprime quelque chose de précis : les équipes savent, souvent mieux que la direction, que le projet tel qu’il est conçu ne correspond pas à la réalité de leurs pratiques. Elles résistent parce qu’elles ont raison.
Un projet SI qui rencontre une résistance forte en phase de déploiement a presque toujours un problème d’analyse en amont : des besoins mal qualifiés, des flux de travail incompris, des contraintes opérationnelles ignorées dans les spécifications.
Point clé : La résistance est un indicateur de qualité d’analyse. Plus elle est forte, plus le cahier des charges mérite d’être revu avant de continuer le déploiement.
Les trois formes de résistance en milieu institutionnel
1. La résistance passive : « On fait comme avant »
C’est la plus courante et la plus difficile à détecter. Les équipes utilisent le nouveau système en façade mais maintiennent leurs anciens processus en parallèle : tableurs Excel cachés, échanges par email en dehors du workflow officiel, doubles saisies non documentées.
Cette forme de résistance signale que le nouveau système ne couvre pas un besoin réel que l’ancien remplissait, souvent un besoin informel jamais formalisé dans les spécifications. C’est la raison pour laquelle une phase d’audit et de cartographie AS-IS est indispensable avant toute rédaction de cahier des charges.
2. La résistance active : « Ce système ne fonctionnera pas »
Elle se manifeste par des objections répétées en réunion, un taux d’adoption très faible aux premiers sprints, parfois une remontée formelle auprès de la direction. Elle est inconfortable pour les équipes projet, mais précieuse : elle identifie les utilisateurs clés qui ont une vision claire des limites du système.
Un Business Analyst expérimenté traite ces profils comme des sources d’information prioritaires, pas comme des obstacles à contourner.
3. La résistance silencieuse : « On dit oui, on ne fait rien »
La plus dangereuse. Les équipes valident formellement les livrables en phase de recette, sans les tester réellement. Le problème ne remonte qu’en production, souvent plusieurs mois après le déploiement, quand le coût de correction a considérablement augmenté.
Attention : Une recette fonctionnelle validée par des utilisateurs qui n’ont pas testé les scénarios réels n’est pas une recette. C’est une signature de complaisance qui déplace le problème sans le résoudre.
Ce qu’un Business Analyst fait différemment
La plupart des chefs de projet traitent la résistance comme un problème de communication : plus de réunions, plus de formations, plus de newsletters internes. Un Business Analyst senior l’aborde comme un problème analytique.
Concrètement, cela se traduit par trois types d’actions préventives :
- Cartographie des pratiques réelles avant toute spécification : entretiens semi-directifs avec les utilisateurs terrain, observation des workflows en conditions réelles, pas seulement des réunions avec les responsables
- Identification des « utilisateurs clés négatifs » dès le cadrage : les personnes dont la résistance serait la plus impactante, pour les impliquer en priorité dans la définition des exigences
- Critères d’acceptance co-construits avec les équipes métier avant le début du développement : quand les utilisateurs ont contribué à définir ce qu’est un livrable acceptable, leur résistance à la recette diminue structurellement
En pratique : Sur un projet intranet conduit dans un hôpital universitaire suisse de 13 000 collaborateurs, la phase de cartographie AS-IS a permis d’identifier 14 processus informels non documentés qui auraient généré une résistance majeure si le système les avait ignorés. Ces processus ont été intégrés dans les spécifications avant le début du développement.
La conduite du changement commence avant le projet, pas après
L’erreur la plus fréquente dans les institutions est de traiter la conduite du changement comme une phase distincte, déclenchée au moment du déploiement. À ce stade, il est trop tard pour modifier les fondamentaux du système.
La conduite du changement efficace est intégrée dès la phase de cadrage SI : elle commence par écouter les équipes avant de décider, par inclure leurs contraintes réelles dans les spécifications, et par définir des indicateurs d’adoption mesurables dès le début du projet.
C’est ce que le pilotage de transformation SI couvre dans sa dimension humaine : pas de la communication descendante, mais une intégration structurée des parties prenantes dans le processus de décision.
Questions fréquentes
La résistance est-elle inévitable dans tout projet SI ?
Non. Elle est inévitable quand les besoins réels n’ont pas été analysés. Un projet dont les spécifications sont construites avec les utilisateurs terrain génère structurellement moins de résistance, parce que le système livré correspond aux pratiques réelles.
Comment distinguer une résistance légitime d’un blocage irrationnel ?
La résistance légitime s’accompagne toujours d’arguments concrets : « ce workflow ne correspond pas à notre pratique parce que… ». Le blocage irrationnel est diffus et ne produit pas d’arguments précis. Dans la quasi-totalité des cas rencontrés en milieu institutionnel, la résistance était légitime.
Quelle est la différence entre conduite du changement et formation ?
La formation apprend aux utilisateurs à utiliser un outil. La conduite du changement s’assure que l’outil correspond aux pratiques des utilisateurs. La première est une réponse à court terme. La seconde est une approche structurelle qui doit commencer en phase de cadrage.
À quel stade faut-il impliquer un Business Analyst dans un projet SI ?
Le plus tôt possible. Idéalement avant toute décision technique ou choix d’outil. La valeur d’un BA est maximale en phase d’analyse et de cadrage : c’est là que les erreurs de conception coûtent le moins cher à corriger.
Ce type d’approche est-il adapté aux petites institutions ?
Oui. La cartographie des processus et la co-construction des critères d’acceptance s’adaptent à toute taille d’organisation. Un projet de 10 utilisateurs mal analysé génère les mêmes problèmes de résistance qu’un projet de 1 000.
Votre projet SI rencontre de la résistance ?
Un échange de cadrage permet de qualifier rapidement si le problème vient de l’analyse des besoins ou d’un autre facteur. Sans engagement.
Prendre rendez-vous
