Implémentation de logiciels : phases, rôles et formation en entreprise

Pourquoi une implémentation structurée des logiciels est décisive

L'introduction d'un nouveau logiciel va bien au-delà d'une simple installation technique. Elle englobe tous les processus liés à son utilisation : mise en œuvre technique, démarrage et acceptation par les collaborateurs. À ce titre, elle figure parmi les tâches les plus exigeantes du management du changement.

La charge de travail dépend de l'étendue de l'application et de la taille de l'entreprise. Pour un nombre réduit d'utilisateurs et un périmètre d'utilisation clairement délimité, une planification allégée suffit. En revanche, si plusieurs départements, sites ou partenaires externes sont concernés, la coordination, les besoins de concertation et l'effort de formation augmentent considérablement.

Dans les PME suisses et les entreprises de construction, le cadre présente des spécificités : le bureau et le chantier doivent travailler avec les mêmes données, et il convient de respecter les exigences spécifiques au secteur ainsi que les prescriptions légales – dans le bâtiment, par exemple, les règles relatives à la taxe sur la valeur ajoutée. Le succès ne dépend pas uniquement du logiciel, mais aussi d'une préparation minutieuse, d'une attribution claire des rôles et de la formation du personnel.

Phases de l'implémentation logicielle : de l'analyse de l'existant à l'optimisation

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

Les guides destinés aux PME suisses indiquent des valeurs de référence pour les premières étapes : environ deux à quatre semaines pour l'analyse de l'existant et l'identification des besoins, trois à six semaines pour l'analyse des exigences et quatre à huit semaines pour l'étude de marché et la sélection du système. Il s'agit de valeurs indicatives, non de directives rigides ; elles varient selon la taille de l'entreprise, le nombre de départements concernés et l'ampleur de la migration des données.

L'importance cruciale d'une planification rigoureuse apparaît clairement à travers les risques : les guides sur l'introduction des ERP rapportent, en s'appuyant sur 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 l'inclusion consciente de marges de manœuvre, font donc partie intégrante de chaque phase.

Risques liés aux projets ERP : état des lieux en Suisse

Clarifier précisément les objectifs et les exigences

Tout commence par la question des résultats que 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, à titre d'exemple, la réduction de 20 % du temps administratif consacré aux tâches administratives 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 servant ultérieurement à l'évaluation du système.

La définition des objectifs repose sur une analyse de l'existant : tous les processus métier existants sont documentés, les points faibles et les potentiels d'amélioration identifiés. Des entretiens avec les collaborateurs de tous les départements permettent de dresser un tableau complet du fonctionnement actuel. Qui omet cette étape évalue ensuite les systèmes sans base de comparaison fiable.

L'analyse de l'existant aboutit au cahier des charges. Celui-ci distingue les exigences fonctionnelles (que doit faire le système ?), les exigences techniques (par exemple matériel, interfaces et performances) et les exigences organisationnelles (par exemple support, formation et maintenance). Au sein de ces groupes, on différencie les obligations impératives, souhaitables et facultatives. Il convient également de prendre en compte les besoins futurs, le potentiel de croissance, ainsi que les particularités sectorielles et les prescriptions réglementaires.

Des objectifs et 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. Les contenus et les exercices peuvent être directement dérivés des processus priorisés.

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

Dès le début, les ressources sont planifiées de manière réaliste – temps, personnel et budget. Cela inclut une équipe projet représentant tous les départements pertinents et une direction de projet disposant de pouvoirs suffisants. Sans compétence décisionnelle, la direction de projet reste dépendante des concertations, et le projet perd en dynamisme.

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 la planification et le calcul des coûts, de la conduite de chantier pour les applications mobiles sur site et le contrôle simplifié des rapports journaliers, ainsi que de la comptabilité pour la facturation et le controlling.

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

Les utilisateurs clés (Key-Users) ou champions servent de lien entre le projet et le personnel : des collaborateurs issus de l'opérationnel quotidien qui découvrent le système tôt, soutiennent leurs collègues et remontent les retours d'expérience au projet. Les circuits de décision, les responsabilités en matière de tests et la question de savoir qui formera les autres doivent être clarifiés tôt et consignés par écrit.

Big Bang ou déploiement progressif : choisir sa stratégie

Avec la stratégie du « Big Bang », le basculement s'effectue pour toute l'entreprise à une date fixe. Les terminaux – tablettes, ordinateurs portables, smartphones – sont généralement équipés du nouveau logiciel durant un week-end ou pendant d'autres périodes non travaillées. Tous les départements et sites travaillent dès lors simultanément avec le nouveau programme.

L'avantage est évident : 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 inférieurs, car il n'est pas nécessaire de payer et de maintenir deux applications.

Le principal inconvénient : tous les employés doivent s'adapter d'un seul coup, ce qui peut entraîner des difficultés d'intégration et d'acceptation.

Avec la méthode itérative, l'introduction se fait étape par étape. Au départ, seuls certains collaborateurs ou départements travaillent avec le nouveau programme ; en cas de succès, le basculement est progressivement étendu à toute l'entreprise. L'ancien et le nouveau logiciel fonctionnent d'abord en parallèle, jusqu'à ce que l'application précédemment utilisée soit désactivée. Dans le secteur de la construction, il peut être judicieux d'étendre l'utilisation aux partenaires de projet, si ceux-ci y sont disposés.

Le choix dépend de plusieurs critères : taille et structure de l'entreprise, criticité des processus concernés, disponibilité des ressources internes pour les tests et la formation, ainsi que capacité à migrer les données et les interfaces.

Une exploitation parallèle accroît la sécurité, mais exige un double effort de saisie et de contrôle pendant la période de transition. Qui évalue realistiquement la charge pesant sur le personnel choisit la stratégie adaptée à son entreprise – non celle qui correspond à un idéal 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 par les collaborateurs est déterminante ; c'est pourquoi les personnes concernées sont impliquées tôt. Des ateliers ou des enquêtes permettent de recueillir les attentes de toutes les parties prenantes et d'en déduire un concept de formation. Dès 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 la base des procédures qu'il utilise réellement au quotidien – la conduite de chantier sur la saisie mobile sur site, la comptabilité sur la facturation et les analyses, la direction de projet sur la planification et le calcul des coûts. Les utilisateurs clés ou champions agissent alors comme multiplicateurs : ils sont formés en premier lieu et de manière approfondie, puis accompagnent leurs collègues dans les activités quotidiennes.

Après le go-live, un accompagnement reste nécessaire : support accessible, courtes sessions de recyclage, matériel d'apprentissage compréhensible et interlocuteurs pour les questions. L'introduction ne s'achève pas avec la session 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 donc la formation du personnel comme un point distinct, aux côtés de la définition des objectifs, de la clarification des exigences ainsi que de la planification budgétaire et temporelle.

Communication, acceptation et évitement de l'IT fantôme

L'acceptation ne résulte pas d'une directive, mais d'une implication. Informer tôt les collaborateurs concernés, aligner les attentes et exposer ouvertement l'utilité concrète pour leur propre travail permet de réduire les résistances. Les retours du personnel doivent être pris au sérieux et intégrés aux décisions ; les questions ouvertes sur le « pourquoi » trouvent 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. Le fait 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 activités quotidiennes figure parmi les tâches principales des départements IT.

Si l'informatique interne n'est pas impliquée dans les nouveaux projets, une IT fantôme incontrôlée apparaît rapidement – favorisée par le fait que de nombreuses solutions peuvent aujourd'hui être souscrites directement en tant que services SaaS et mises à disposition des collaborateurs sans passer par l'IT.

L'entreprise contrecarre cela par des règles claires : une vue d'ensemble des applications autorisées, des points de contact définis pour les nouveaux besoins et un canal simple permettant de transmettre les suggestions d'amélioration et les réclamations à l'équipe projet. Ainsi, les services spécialisés et l'IT restent en dialogue, et les exigences issues 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

Avec le go-live commence la véritable épreuve de vérité. La procédure suivante a fait ses preuves : recueillir les feedbacks 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 apparaît qu'un processus fonctionne différemment en pratique par rapport à ce qui était prévu, on ne force pas le logiciel à s'adapter, mais on remet en question et affine le processus.

L'optimisation continue n'est pas un accessoire, mais une composante fixe de l'implémentation logicielle. 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 analyses, de suivre les points ouverts avec le support et de mettre en œuvre les améliorations par petites étapes compréhensibles.

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