Introduction d'un logiciel : phases, rôles et formation en entreprise

Pourquoi une introduction structurée du logiciel est cruciale

L'introduction d'un nouveau logiciel va bien au-delà d'une simple installation technique. Elle englobe tous les processus liés à l'utilisation d'une nouvelle application : la mise en œuvre technique, la mise en service et l'acceptation par les collaborateurs. Elle fait ainsi partie des tâches les plus exigeantes du change management.

L'ampleur d'un projet dépend de la portée de l'application et de la taille de l'entreprise. Ceux qui ont peu d'utilisateurs et un domaine d'application clairement délimité s'en sortent avec une planification allégée. En revanche, si plusieurs services, sites ou partenaires de projet externes sont concernés, les besoins en coordination, en concertation et en formation augmentent considérablement.

Dans les PME suisses et les entreprises de construction, des conditions-cadres particulières s'ajoutent : le bureau et le chantier doivent travailler avec les mêmes données, et les prescriptions spécifiques au secteur ainsi que les exigences légales doivent être respectées – dans le bâtiment, par exemple, les règles relatives à la taxe sur la valeur ajoutée. L'expérience montre que le succès ne dépend pas uniquement du logiciel, mais tout autant d'une préparation minutieuse, de rôles clairement attribués et de la formation du personnel.

Phases de l'introduction du logiciel : de l'analyse de l'existant à l'optimisation

Dans la pratique, des phases récurrentes se sont imposées, telles que décrites dans les guides pour les PME suisses : préparation et élaboration de la stratégie, analyse de l'existant et détermination des besoins, analyse des exigences avec cahier des charges, étude du marché et sélection du système, introduction avec mise en service (go-live), ainsi que stabilisation et optimisation continue. Elles ne se déroulent pas toujours strictement les unes après les autres, mais elles offrent une structure fiable pour la planification, le budget et les responsabilités.

Pour les premières étapes, ces guides indiquent des valeurs de référence : environ deux à quatre semaines pour l'analyse de l'existant et la détermination des besoins, trois à six semaines pour l'analyse des exigences et quatre à huit semaines pour l'étude du marché et la sélection du système. Ce sont des valeurs indicatives, pas des directives rigides ; selon la taille de l'entreprise, le nombre de services concernés et l'ampleur de la migration des données, ces délais peuvent varier.

L'importance d'une planification rigoureuse est illustrée par les risques : les guides sur l'introduction d'un ERP rapportent, en référence à des études, que jusqu'à 75 % de tous les projets ERP dépassent les coûts prévus ou les délais impartis. Une planification réaliste des ressources et des échéances, ainsi que des marges de manœuvre consciemment prévues, font donc partie intégrante de chaque phase.

Clarifier proprement les objectifs et les exigences

Au départ se pose la question de savoir quels résultats l'entreprise souhaite atteindre avec le nouveau logiciel. La formulation d'objectifs mesurables selon la méthode SMART a fait ses preuves. Une liste de contrôle pour les entreprises de construction suisses cite par exemple l'objectif de réduire les charges administratives de 20 % dans un délai de six mois. Les orientations typiques dans les entreprises de construction sont l'optimisation des processus, un meilleur contrôle des coûts et une communication plus efficace entre le bureau et le chantier. Les objectifs sont priorisés selon leur importance et leur urgence, puis consignés dans un catalogue de critères pour l'évaluation ultérieure du système.

La base de la définition des objectifs est une analyse de l'existant : tous les processus métier existants sont documentés, les points faibles et les potentiels d'optimisation sont identifiés, et des entretiens avec les collaborateurs de tous les services permettent d'obtenir une image complète du déroulement actuel. Quiconque saute cette étape évalue ensuite les systèmes sans base de comparaison fiable.

L'analyse de l'existant débouche sur le cahier des charges. Il distingue les exigences fonctionnelles (que doit fournir le système ?), les exigences techniques (matériel, interfaces et performances, par exemple) et les exigences organisationnelles (support, formation et maintenance, par exemple). Au sein de ces groupes, on différencie les exigences obligatoires, souhaitables et facultatives. Il faut également anticiper les exigences futures et le potentiel de croissance, ainsi que les spécificités sectorielles et les prescriptions réglementaires.

Des objectifs et des exigences clairement définis ont un double effet : ils rendent la sélection du système compréhensible et fournissent la base de la formation ultérieure, car les contenus et les exercices peuvent être directement déduits des processus priorisés.

Rôles dans le projet : qui décide, qui teste, qui forme ?

Au début, les ressources sont planifiées de manière réaliste – temps, personnel et budget. Cela inclut une équipe de projet avec des représentants de tous les services pertinents et une direction de projet disposant de pouvoirs suffisants. Sans compétence décisionnelle, la direction du projet reste dépendante des concertations, et le projet perd de sa vitesse.

Les services spécialisés apportent leurs exigences concrètes. Dans une entreprise de construction, il s'agit typiquement de la direction de projet pour les exigences en matière de planification et de calcul, de la conduite de chantier pour l'utilisation d'applications mobiles sur le chantier et le contrôle simplifié des rapports journaliers, ainsi que de la comptabilité pour les exigences en matière de facturation et de controlling.

L'informatique joue un rôle de médiateur. L'étude Swiss IT 2025 montre que la sécurité informatique et la conformité sont, pour 67 % des entreprises, la tâche la plus importante des départements informatiques, suivies de près par le soutien aux services spécialisés dans les opérations quotidiennes avec 47 %. Les départements informatiques doivent donc non seulement fournir des solutions techniques, mais aussi agir en tant que médiateurs et impliquer activement les services spécialisés dans les projets.

En tant que lien entre le projet et le personnel, les utilisateurs clés ou champions servent d'intermédiaires : des collaborateurs issus du quotidien opérationnel qui apprennent à connaître le système très tôt, soutiennent leurs collègues et renvoient les retours de la pratique au projet. Les voies de décision, les responsabilités en matière de tests et la question de savoir qui formera ultérieurement doivent être clarifiées tôt et consignées par écrit.

Big Bang ou introduction progressive : choisir la stratégie

Avec la stratégie du Big Bang, la conversion pour l'ensemble de l'entreprise s'effectue à une date fixe. Les appareils terminaux – tablettes, ordinateurs portables, smartphones – sont généralement équipés du nouveau logiciel lors d'un week-end ou à d'autres périodes non travaillées ; tous les services et sites travaillent désormais simultanément avec le nouveau programme. L'avantage saute aux yeux : tout le monde utilise le même système, et aucun problème ne survient lors de l'échange de données entre l'ancienne et la nouvelle solution. De plus, les coûts sont généralement moindres, car il n'est pas nécessaire de payer et de maintenir deux applications. Le plus grand inconvénient : tous les collaborateurs doivent s'adapter d'un seul coup, ce qui peut entraîner des problèmes d'intégration et d'acceptation.

Avec la méthode itérative, l'introduction se fait étape par étape. Au début, seuls certains collaborateurs ou services travaillent avec le nouveau programme ; en cas d'utilisation réussie, la conversion est progressivement étendue à l'ensemble de l'entreprise. L'ancien et le nouveau logiciel fonctionnent d'abord en parallèle, jusqu'à ce que l'application utilisée jusqu'alors soit désactivée. Dans le secteur de la construction, il peut également être judicieux d'étendre l'utilisation aux partenaires de projet, à condition qu'ils y soient disposés.

Le choix dépend de plusieurs critères : la taille et la structure de l'entreprise, le caractère critique des processus concernés, la disponibilité des ressources internes pour les tests et la formation, ainsi que la capacité à migrer les données et les interfaces. Une exploitation parallèle augmente la sécurité, mais exige un double effort de saisie et de contrôle pendant la période de transition. Quiconque évalue de manière réaliste la charge du personnel choisit la stratégie qui convient à sa propre entreprise – et non celle qui correspond à une image idéale théorique.

Formation et développement des compétences : de l'utilisateur clé à l'ensemble du personnel

La formation ne commence pas seulement au moment du go-live. Pour une introduction réussie, l'acceptation des collaborateurs est déterminante, c'est pourquoi les personnes concernées sont impliquées très en amont. Des ateliers ou des sondages permettent de recueillir les attentes de toutes les parties prenantes et d'en déduire un concept de formation. Déjà dans le cahier des charges, la formation, le support et la maintenance sont définis comme des exigences organisationnelles.

Les formations axées sur les rôles et les processus ont fait leurs preuves : chaque groupe apprend sur les flux qu'il utilise réellement au quotidien – la conduite de chantier sur la saisie mobile sur le chantier, la comptabilité sur la facturation et les évaluations, la direction de projet sur la planification et le calcul. Les utilisateurs clés ou champions agissent comme des multiplicateurs : ils sont formés en premier et de manière approfondie, puis accompagnent leurs collègues au quotidien.

Après le go-live, un accompagnement reste nécessaire : un support accessible, de courtes formations de rattrapage, du matériel d'apprentissage compréhensible et des interlocuteurs pour les questions. L'introduction ne s'achève pas avec la date de formation, mais seulement lorsque le nouveau logiciel est utilisé de manière fiable au quotidien. Une liste de contrôle pour les entreprises de construction suisses mentionne d'ailleurs la formation des collaborateurs comme un point à part entière, au même titre que la définition des objectifs, la clarification des exigences ainsi que la planification du budget et des délais.

Liste de contrôle pour une introduction réussie d'un logiciel dans les PME suisses

Communication, acceptation et éviter la shadow IT

L'acceptation ne s'obtient pas par directive, mais par l'implication. Quiconque informe tôt les collaborateurs concernés, aligne les attentes et expose concrètement l'utilité pour leur propre travail réduit les résistances. Les retours du personnel doivent être pris au sérieux et intégrés dans les décisions ; les questions ouvertes sur le pourquoi appellent une réponse, au lieu d'être ignorées.

L'informatique assume ici un rôle de médiateur entre les services spécialisés et la technique. Que ce rôle gagne en importance est montré par l'étude Swiss IT 2025 : outre la sécurité informatique et la conformité, le soutien aux services spécialisés dans les opérations quotidiennes figure parmi les tâches les plus importantes des départements informatiques. Si l'informatique interne n'est pas impliquée dans les nouveaux projets, une shadow IT incontrôlée se développe rapidement, favorisée par le fait que de nombreuses solutions peuvent aujourd'hui être directement souscrites en tant que service SaaS et mises à disposition des collaborateurs sans passer par l'informatique.

Une entreprise contrecarre cela avec des règles claires : un aperçu des applications autorisées, des points de contact définis pour les nouveaux besoins et un canal simple par lequel les propositions d'amélioration et les réclamations parviennent à l'équipe de projet. Ainsi, les services spécialisés et l'informatique restent en dialogue, et les exigences du quotidien deviennent visibles tôt, au lieu d'être corrigées a posteriori.

Après le go-live : vérifier l'utilisation, affiner les processus

Le go-live marque le début de l'épreuve du feu. La procédure suivante a fait ses preuves : recueillir les retours au sein de l'équipe, clarifier les problèmes avec le fournisseur, adapter les processus de travail et vérifier les objectifs définis au départ. S'il s'avère qu'un processus fonctionne différemment dans la pratique par rapport aux plans, on ne tord pas le logiciel, mais on remet en question et on affine le processus.

L'optimisation continue n'est pas un accessoire, mais une partie intégrante de l'introduction du logiciel. Dans les modèles de procédure établis, elle constitue la dernière phase après la préparation, la sélection et l'introduction. Cela implique de vérifier régulièrement l'utilisation, de consulter les évaluations, de suivre les points ouverts du support et de mettre en œuvre les améliorations par petites étapes compréhensibles.

Une liste de contrôle compacte pour la période après le go-live : – Comparer les objectifs de la phase de démarrage avec l'utilité réelle. – Recueillir et prioriser les retours de tous les services concernés. – Clarifier les points techniques et organisationnels ouverts avec le fournisseur. – Adapter les processus et les responsabilités à la nouvelle façon de travailler. – Maintenir les utilisateurs clés et le support à jour, mettre à jour le matériel d'apprentissage. – Vérifier l'utilisation et la qualité des données à intervalles réguliers. – Définir et planifier les prochaines étapes d'optimisation.