6 leviers pour réussir le déploiement d’un projet IT

Levier 1. Pour que votre projet IT ait un sens, pointez-le vers le bon horizon

La transformation digitale des entreprises constitue l’un de leurs grands défis actuels. Le poids de la technique, l’ampleur du travail à réaliser sur les données, la part d’IA réelle ou supposée, les infrastructures, le développement logiciel, l’intégration de la solution dans son environnement, la cybersécurité, la conformité juridique dans la gestion des données ou encore la formation des utilisateurs constituent des travaux si complexes, si exigeants et engageants qu’ils monopolisent l’attention de tous. Au risque de perdre de vue l’essentiel : ce projet IT, en vue de quoi ? Qu’en attend l’entreprise, le site, la direction qui le lance ? Or, ce n’est pas en regardant sous le capot d’une voiture qu’on voit le mieux le chemin à parcourir. 

Bien sûr, chaque projet s’accompagne de promesses mille fois entendues : « fluidifier », « automatiser », « accélérer ». Cependant, quels sont, au-delà des outils et de ses fonctionnalités, les résultats concrets qu’il doit permettre d’atteindre ? Comment le déploiement d’un CRM va-t-il soutenir concrètement l’action des commerciaux ? Comment un nouveau logiciel de paie va-t-il permettre de réduire les erreurs et de baisser le coût de production de celle-ci ? 

Il est fondamental pour l’entreprise qui envisage de lancer un projet IT d’être au clair sur ces objectifs, sur ce que le déploiement applicatif doit apporter. Sans se payer de mots, sans surestimer ces résultats. En identifiant aussi le « prix à payer » de façon réaliste, à la fois pendant le projet et après. 

Ce qui conduit à un changement de perspective : considérer le projet comme une transformation profonde des pratiques et fonctionnements d’un service ou d’une entreprise, laquelle passe par l’implantation d’un nouvel outil IT. Il s’agit de considérer l’outil non comme une finalité, mais comme un moyen à intégrer dans le cadre d’une performance globale.  Cette finalité claire devient alors la pierre angulaire à la fois du pilotage du projet, mais aussi de la communication autour de celui-ci. 

Levier 2. Concevoir le projet de déploiement IT dans toutes ses dimensions

Sur ce site industriel, une GMAO a été déployée au sein de la maintenance. Cependant, deux ans après, le taux de remplissage reste autour de 30%. Les mainteneurs ont perçu dans le projet une volonté de « flicage de leur temps », et absolument pas la potentielle facilitation de leur travail. De plus, ils ressentent comme une contrainte les allers-retours entre l’atelier et leur bureau pour renseigner l’outil. Celui-ci a bien été déployé, mais les résultats visés ne sont pas au rendez-vous. 

Pour les atteindre, les pratiques devront évoluer. Très souvent aussi l’organisation, les missions voire le métier de certains acteurs. Ces évolutions peuvent nécessiter de nouvelles compétences – comme celle de l’analyse des données de maintenance. La qualité des données et des IA injectées dans l’outil doit aussi être sécurisée pour fiabiliser les résultats. Les impacts environnementaux pris en considération pour veiller à la cohérence de la politique RSE de l’entreprise.

Réussir le déploiement d’une nouvelle application revêt donc des dimensions Techniques qui dépassent l’applicatif lui-même. Mais aussi des dimensions Données, Organisationnelles, Sociales, Environnementales et Économiques bien sûr. Que le pilote du projet et ses commanditaires doivent veiller à « tenir ensemble ».

Cette complexité, qui s’ajoute à celle de l’outil, peut paraître très contraignante : « on a déjà beaucoup à faire ». Cependant, l’ignorer peut mettre à risque le projet. Et la prendre en compte ouvre aussi des opportunités. Comme celle d’apporter sur leur terrain des compensations aux contraintes posées par l’outil. Par exemple en organisant la polyvalence sur différents postes lorsque l’outil impose une trop grande spécialisation.

Levier 3. Équilibrer les contraintes entre technique et équipes

Bien souvent, le déploiement d’un nouvel outil part du principe que l’ensemble des contraintes qu’il amène s’imposent à tous. En partie parce que la rigidité des solutions – en particulier des solutions « sur étagère » – est très forte. Mais aussi parce que les budgets de ces projets, déjà très conséquents, sont calculés au plus juste. Le projet peut demander de remonter les difficultés, mais dès que les régler dépasse un certain montant, on renonce. 

Parfois aussi, les contraintes sont regardées par certains dirigeants comme une opportunité d’imposer à leurs équipes des fonctionnements qu’ils n’ont pas pu leur faire adopter. Ainsi « l’entreprise R », qui compte plus de 5000 salariés et a repris plusieurs sites en 3 ans, peine à standardiser ses processus. Envisageant de déployer un outil IT, ses dirigeants renoncent à une lourde démarche de refonte des process métiers, pour utiliser le projet IT comme levier de standardisation. Pensé comme technique, porté par une SS2I, le projet fait peu de cas des fonctionnements en place, et notamment les spécificités locales. “Quand on retire le sparadrap tout d’un coup, cela fait moins mal” pensaient les dirigeants. Mais le projet va se heurter aux résistances de nombreux acteurs. Plus de deux ans après le lancement, les salariés ne se retrouvent toujours pas dans l’outil, le management n’obtient pas les gains espérés sur le pilotage de l’activité et de nombreux spécifiques sont toujours en développement. 

Sans aller jusqu’à ces extrêmes, il est fréquent que les « résistances » des acteurs soient vues comme autant de freins, inévitables mais à dépasser coûte que coûte… sans voir la souffrance au travail qui grandit et affaiblit durablement le projet et probablement la mobilisation pour de futures initiatives.

A l’inverse, l’entreprise qui veut mener à bien dans les meilleures conditions son projet aura intérêt à demander de la souplesse non pas seulement aux collaborateurs, mais aussi au fournisseur de l’outil. Pour réduire les contraintes inutiles pour les utilisateurs, améliorer l’ergonomie, mais aussi développer des fonctionnalités nouvelles utiles aux yeux des équipes. Pour identifier les limites à poser aux prescriptions que donne l’outil et préserver l’appréciation humaine là où elle fait sens. En acceptant d’investir des sommes raisonnables dans certaines adaptations, plutôt que de voir des fichiers Excell et des fonctionnements dégradés fleurir. De nouvelles solutions de génie logiciel permettent justement, aujourd’hui, de renforcer la part de sur mesure, en maîtrisant les coûts à court comme à moyen terme. 

Il s’agit de retrouver des marges de manœuvre, qui permettront de mettre en place une transformation dans laquelle se retrouveront le plus d’acteurs possibles. 

Levier 4. Aller tôt vers ceux qui risquent de souffrir

Comme toute transformation, les projets IT repoussent très souvent le moment où il faudra dire aux équipes ce qui les attend. On définit le cahier des charges, on choisit le fournisseur, on prépare le déploiement et même la formation, en associant très peu les utilisateurs finaux. 

La méthode classique « d’accompagnement du changement SI » préconise à juste titre une analyse d’impact du projet sur l’ensemble des dimensions, y compris organisationnelles et sociales. Cependant, elle est souvent faite en chambre, au mieux en sollicitant brièvement quelques « key users », par crainte d’inquiéter avant d’avoir tout défini. Ainsi ce projet de déploiement d’un ERP dans un réseau de concessionnaires automobiles se prépare uniquement avec les équipes rapprochées du patron du réseau, qui n’ont qu’une vision partielle des impacts concrets, et n’auront guère à les subir. 

Nous préconisons de faire l’inverse : de communiquer le plus tôt possible sur le projet – même avant le choix du prestataire. De communiquer régulièrement sur son avancement. De réaliser les analyses d’impact AVEC les utilisateurs. De les associer à la préparation de l’arrivée de l’outil. D’identifier avec eux les contraintes à remonter aux équipes techniques, les évolutions de pratiques ou de fonctionnement à embarquer, les garanties à donner. De regarder en face les risques de désengagement, de RPS, et leurs impacts sur la qualité des fonctionnements et notamment sur celle de la donnée. 

Dans ce centre de gestion d’une mutuelle, fortement syndiqué, le déploiement de « briques d’ERP » sur la partie retraite a été repoussé. Mais le déploiement s’étant fait dans pratiquement toutes les autres entités du groupe, le site va devoir « y passer ». Sa direction nous sollicite pour réaliser une analyse d’impact … avec les gestionnaires des différents services, et leurs managers. Celle-ci fait ressortir que les impacts ont été largement sous-estimés dans les phases amont du projet : refonte de certains processus, modification de certains métiers, problèmes d’ergonomies vont devoir être accompagnés ou corrigés. Par exemple dans une équipe, des gestionnaires qui géraient en autonomie les dossiers d’adhérents traiteront demain uniquement les points techniques que le logiciel ne peut traiter. L’autonomie, mais aussi le sentiment de « suivre des adhérents » sont remis en cause. Au-delà même de ces changements concrets, de nombreuses craintes et interprétations sur le projet et les « desseins » plus lointains qu’il cacherait, se font jour. Alors que l’équipe de direction s’apprête à déployer. 

Nous aidons celle-ci et l’équipe projet à revoir leur communication, ajuster les formations – qui prévoyaient peu de mises en pratique – et s’organiser en « mode crise ». Nous accompagnons aussi les chefs d’équipe, inquiets et démunis, peu convaincus par le changement, pour faire face à la situation, retrouver le sens que le projet peut avoir malgré toutes les contraintes, accompagner leurs collaborateurs collectivement, mais aussi individuellement dans cette période critique. Après quelques mois, grâce à la mobilisation de chacun, le déploiement de l’outil a pu se faire sans grève et à la satisfaction des différents acteurs… même si nous sommes intervenus alors que le projet était déjà très avancé. 

Levier 5. Piloter en tenant ensemble toutes les dimensions

On l’a vu, le projet « IT » n’est pas que technique, mais organisationnel, social et économique. Et ces dimensions ne concernent pas que la cible, mais aussi le chemin.

Ainsi des sujets d’organisation vont se poser au projet lui-même : libérer des ressources pour le projet, s’organiser autrement dans les équipes pour tenir la double charge projet et opérationnelle, tenir compte de l’impact d’autres projets menés en parallèle.

Des sujets sociaux aussi : avoir un vrai dialogue social autour du projet, de l’évolution du contenu du travail (l’outil cherche à prescrire ce que tu dois faire, la personne se sentait utile…), préparer et accompagner les acteurs dans les nouvelles pratiques, les responsabiliser quant au niveau de rigueur à garantir (ex. qualité de la donnée), tenir compte des alertes, anticiper les mobilités, mettre en place des ressources temporaires pour absorber la charge projet. 

Enfin, la dimension économique restera clef : tenir les coûts du projet, anticiper et absorber les impacts sur l’activité, s’assurer que les changements délivrent la performance attendue. 

Levier 6. Pérenniser les effets du projet

Le projet ne s’achève pas lorsque l’outil est déployé. D’abord parce que s’ouvre alors la terrible période de fiabilisation, avec ses nombreux dysfonctionnements ou malfaçons à corriger en urgence, parce que l’outil est déjà en production, et que les utilisateurs sont en souffrance. Cette période sera d’autant mieux vécue qu’elle aura été annoncée à l’avance, anticipée et prise en compte dans les objectifs de performance et les ressources. Et que l’outil n’aura pas été survendu. 

C’est aussi le moment de pérenniser la gouvernance de la donnée et des IA du système pour sécuriser et fiabiliser les « outputs » et assurer que le système délivre la performance attendue dans la durée. 

 Il faut aussi consolider les évolutions d’organisation, finir d’assurer les montées en compétences, accompagner les collaborateurs qui ont le plus de mal avec l’outil, ainsi que les parties prenantes de l’écosystème pour fluidifier les évolutions de process et faciliter l’évolution des usages. Ce qui peut s’étendre au-delà de la période de fiabilisation. 

Puis, à un moment, il faudra savoir clore ce projet, qui aura mobilisé tant d’acteurs, requis tant d’énergie, généré tant de sueurs froides. Même (et surtout !) s’il a été douloureux, savoir annoncer qu’il est terminé est important pour tous. Et si possible, en réaliser un retour d’expérience, avec l’équipe projet, mais aussi des utilisateurs. Pour « vider la cuve » des douleurs, pour se féliciter des réussites, pour contempler les résultats, pour tirer les enseignements. Et ainsi conduire encore mieux le projet suivant. 

 

Comment faire échouer votre projet informatique ?

A la lumière de cet article, vous disposez aussi de clefs pour plonger votre projet informatique dans les plus grandes difficultés :  

• Focalisez-vous sur l’aspect technique. Le reste devrait suivre, et ceux qui ne suivent pas seront des réfractaires à la modernité.
• Restez vague sur les objectifs : il s’agit d’accélérer, de simplifier, de moderniser. Il sera toujours possible ensuite de trouver un sujet qui s’est amélioré.
• Préparez le déploiement avec une équipe resserrée, en évitant toute fuite. Les gens s’inquiètent toujours trop, alors autant repousser ce moment au plus tard.
• Utilisez l’outil pour contraindre les collaborateurs : c’est l’occasion unique de mettre au pas les fonctionnements déviants. Ne négociez rien, la technique s’imposera.
• Missionnez votre DSI pour réussir ce projet, avec mission d’importuner le moins possible ses collègues. Si le projet est une catastrophe, ce sera de son fait.
• Clôturez vite le projet pour passer au suivant. Il est encore plus prometteur !