La conduite du changement

Au sommaire

• Pourquoi changer après tout ?
• Complexité et imprédictibilité
• Conseils de navigation en terrain mouvant
• Articles qui devraient vous intéresser

Pourquoi changer après tout ?

« Rien n’est permanent, sauf le changement », affirmait Héraclite il y a 25 siècles déjà. Quelle phrase caractérise mieux que celle-là l’industrie informatique contemporaine ? La technologie, les usages, les besoins, les compétiteurs et le marché changent continuellement. C’est dans ce contexte mouvant et incertain qu’évoluent les projets informatiques. Tel un organisme vivant contraint de s’adapter pour survivre[1] dans un environnement en perpétuelle évolution, un système informatique devra, lui aussi, évoluer faute de dépérir. Maintenir la satisfaction des utilisateurs à un niveau à peu près constant, sans même parler de l’accroître, nécessite des évolutions permanentes. Des fonctionnalités qui, hier encore, étaient des options de confort deviennent rapidement des standards.

Des quintaux d’ouvrages de management prétendent nous inculquer les bonnes pratiques de la conduite du changement. Il faut pourtant se rendre à l’évidence, la panacée n’existe pas. La réalité cruelle c’est qu’il n’y a pas de méthode ! Cette absence de recette sur étagère ne doit pas cependant nous conduire au désespoir mais plutôt nous interroger sur les causes profondes des difficultés à surmonter.

Complexité et imprédictibilité

Dans le cadre d’un projet IT, on cherche d’ordinaire à planifier de manière aussi précise que possible les tâches à accomplir, à anticiper les impacts du nouveau système sur les utilisateurs et à identifier enfin les besoins de formation. Pourtant, si l’on examine le taux d’échec[2] des grands projets de transformation, force est de constater qu’il y a dans cette approche une forme de déni de réalité. Parmi les causes de ces échecs à répétition, figurent selon nous deux spécificités des systèmes informatiques trop souvent niées.

1. La première est liée à l’idée de complexité, un terme hélas trop galvaudé pour que nous puissions nous dispenser d’une brève définition. Les scientifiques en proposent plusieurs mais dans notre contexte, celui des projets de transformation IT, nous parlerons de système « complexe » dès lors qu’aucun individu n’est en mesure, à lui seul, d’en concevoir une vision globale et exhaustive. Qu’il s’agisse par ailleurs du système existant ou du résultat de la transformation envisagée. La vision d’un tel système n’est tout au plus qu’un agrégat de visions partielles, parfois même contradictoires, des parties prenantes concernées : architectes, utilisateurs, développeurs, DSI ou DG. A titre d’exemple, les dépendances entre les sous-systèmes sont rarement connues avec précision. Elles résultent en effet d’un historique oublié de décisions prises par des responsables différents confrontés à une multitude d’options technologiques. Cette absence de vision globale est en réalité inhérente aux SI dans le contexte technologique fébrile actuel et n’est nullement le symptôme d’une quelconque incompétence. Certes la modélisation du système et la formalisation du besoin restent utiles mais, pour un système complexe, elles ne permettront pas une planification détaillée du projet. Pas davantage qu’une connaissance de la dynamique de l’atmosphère ne permet de prévoir le temps qu’il fera d’ici une année.
2. La seconde caractéristique des systèmes informatiques, qui les distingue nettement d’autres systèmes complexes, est qu’ils n’existent jamais indépendamment d’un environnement social dont ils modifient l‘équilibre. Ils induisent en effet une redistribution des responsabilités et des pouvoirs. Il arrive aussi que l’utilisation qui est faite du système ne soit pas celle prévue par ses concepteurs et nécessite en retour des modifications nécessaires. De toutes ces rétroactions du corps social dépendra en dernier ressort l’acceptation ou le refus du changement.

En réalité, les démarches usuelles de planification du changement, très cartésiennes, ont une double origine. Elles procèdent d’une part d’un désir bien naturel de causalité, prévoir l’avenir en effet rassure. D’autre part elles constituent des adaptations souvent trop naïves de démarches qui ont fait leur preuve dans contextes industriels aux contraintes très différentes de celles d’une DSI. Les cabinets d’architecture du BTP en constituent un bon exemple, en atteste l’usage immodéré qui est fait dans l’IT de concepts comme les patterns de conceptions ou de processus d’industrialisation en tous genres.

Ces démarches planifiées à l’excès sous-estiment donc deux sources d’imprévisibilité propres à l’IT : d’une part le foisonnement des technologies qui, de fait, en rend la maîtrise complète illusoire (trop souvent les choses sont faites pour la première fois), d’autre part l’imprévisibilité des comportements humains lorsque leur statut social est impacté.

Voici donc qui nous amène à formuler quelques…

Conseils de navigation en terrain mouvant

Le premier conseil, et le plus important aussi, est que face à ces facteurs d’imprévisibilités, il convient de remiser les méthodes planifiées du BTP pour en réhabiliter d’autres, plus adaptées à l’IT et plus proches sans doute des sciences expérimentales et de des sciences sociales. (1) La manière rationnelle de traiter les incertitudes n’est pas la planification mais l’expérimentation, même si la seconde n’exclut pas la première. Expérimenter, faire des erreurs, sont les seuls moyens pour accroitre la connaissance que l’on a d’un système ou d’une technologie inconnue. L’expérimentation réduit les incertitudes, et par là, améliore progressivement la prévisibilité que l’on a d’une situation. Dans la foulée, on réhabilitera aussi la créativité, souvent plus utile pour maîtriser l’imprévu qu’un respect tatillon des procédures et des plannings.

Pour un système complexe, une connaissance complète des dépendances entre constituants, même si elle était possible, ne permettrait pas de lever l’imprédictibilité qui l’affecte. C’est le fameux « effet papillon ». De petites causes, aux apparences parfois insignifiantes, peuvent avoir des conséquences importantes, notamment sur l’adéquation du SI à son environnement. Dès lors, toute velléité de prédiction à long terme s’apparente à une pratique des arts divinatoires. L’expérience montre par ailleurs que l’absence de proportionnalité, entre les causes et leurs effets, est d’autant plus marquée que les sous-systèmes sont fortement interdépendants. D’où notre second conseil : (2) on cherchera toujours à minimiser autant que possible les interdépendances entre les composantes d’un projet de transformation (qui est notre système complexe) qu’il s’agisse des outils, des pratiques ou des individus (qui sont les « constituants » du système).

Une autre conséquence importante et méconnue de la non-linéarité est que les approches incrémentales, qui procèdent par itérations successives de petites étapes dont chacune est sensée améliorer la situation, sont parfois inopérantes. (3) Marcher dans la bonne direction implique parfois d’accepter une dégradation temporaire de la situation. Contrairement à l’adage qui prétend qu’il faut systématiquement proscrire les approches bigbang, de petits bigbangs sont parfois indispensables. On parle alors d’innovation radicale. Selon les circonstances celle-ci peut prendre des tournures différentes : l’utilisation d’une technologie disruptive, un changement radical de méthodologie de développement (passage aux démarches agiles p.ex.) ou le remplacement d’une équipe rétive au changement par une autre qui le soutiendra activement.

Voilà qui nous amène enfin à notre dernier conseil. Il concerne la facette sociale de l’imprédictibilité déjà mentionnée. Dans un monde idéal (cf. note 1), tout changement s’inscrirait dans un vaste projet porteur de sens. Par sa capacité à transcender intérêts individuels, l’élan fédérateur suscité serait alors capable de vaincre progressivement toutes les résistances individuelles (pensons p.ex. à l’éradication d’une maladie, à la conquête du système solaire etc.). Dans le monde réel cependant, soumis à des contraintes de budget et de délais et non à une quête de sens, il en va autrement. Le plus souvent, ce souffle fédérateur fait défaut. Dès lors, pour maximiser les chances de succès d’un projet de transformation, deux caractéristiques des individus sont à prendre en compte : le degré d’adhésion au changement d’une part et leur capacité d’influence d’autre part. A l’encontre de l’intuition, l’expérience tend alors à démontrer qu’il ne faut pas chercher à convaincre une majorité d’individus du bien-fondé du changement mais qu’il est bien plus efficace de (4) s’appuyer sur les individus à la fois promoteurs du changement et dotés d’un pouvoir de décision. D’autre part, il faudra aussi neutraliser les individus doté d’un pouvoir mais qui sont opposés au changement. Et il ne faut pas se leurrer, faute d’investir suffisamment d’énergie pour mener ces deux types d’action, l’abandon pur et simple du projet de transformation pourrait bien s’avérer la décision la plus sage.

Article coécrit par Pirmin Lemberger et Manuel Alves

---

[1]L’adaptation pour rester compétitif est évidement l’injonction permanente du monde économique contemporain. Le lecteur espiègle pourra s’amuser à imaginer les mondes virtuels qui naîtraient d’une substitution, en guise de vertu cardinale, du mot de « coopération » à celui de « compétition ». Ou encore imaginer les conséquences d’un échange des termes « adaptation au marché » pour d’autres, comme « résistance au non-sens ou aux inégalités », qui ont été les objectifs d’autres sociétés en d’autres temps.
[2]Jusqu’à 68% des projets informatiques échouent selon certaines sources.