Implémenter un logiciel : phases, rôles et formation en entreprise

Pourquoi une implémentation structurée du logiciel est décisive

L'implémentation 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, mise en service et acceptation par les collaborateurs. À ce titre, elle figure parmi les tâches les plus exigeantes de la gestion 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 champ d'application clairement délimité, une planification allégée suffit. Si plusieurs départements, sites ou partenaires de projet 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, des conditions cadres spécifiques s'appliquent : le bureau et le chantier doivent travailler avec les mêmes données, et les prescriptions sectorielles ainsi que légales doivent être respectées – dans le secteur de la construction, il s'agit par exemple des 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 répartition claire des rôles et de la formation du personnel.

Phases de l'implémentation du logiciel : 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 détermination des besoins, analyse des exigences avec cahier des charges, recherche de marché et sélection du système, implémentation avec mise en production (go-live) ainsi que 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 indicatives pour les premières étapes : 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 la recherche de marché et la sélection du système. Il s'agit de valeurs indicatives, non de prescriptions 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 soigneuse apparaît clairement au regard des risques : les guides sur l'implémentation d'ERP rapportent, en citant 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 intégrées, font donc partie intégrante de chaque phase.

Clarifier proprement les objectifs et les exigences

Au début se pose 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 par exemple la réduction de 20 % des temps administratifs 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, et 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 commerciaux existants sont documentés, les points faibles et les potentiels d'optimisation identifiés. Des entretiens avec les collaborateurs de tous les départements permettent d'obtenir une image complète du déroulement actuel. Celui qui saute cette étape évalue ensuite les systèmes sans base de comparaison fiable.

L'analyse de l'existant aboutit au cahier des charges. Il distingue les exigences fonctionnelles (que doit faire le système ?), les exigences techniques (par exemple matériel, interfaces et performance) et les exigences organisationnelles (par exemple support, formation et maintenance). Au sein de ces groupes, on différencie les exigences obligatoires, souhaitées et optionnelles. Les exigences futures et le potentiel de croissance, ainsi que les particularités sectorielles et les prescriptions réglementaires, doivent également être pris en compte.

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 pour la formation ultérieure. Les contenus et les exercices peuvent être directement dérivés des processus priorisés.

Priorisation des objectifs selon la méthode SMART (exemple pour les entreprises de construction)

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

Dès le début, les ressources sont planisées de manière réaliste – temps, personnel et budget. Cela inclut une équipe projet avec des représentants de 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 vitesse.

Les départements 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, de la conduite de chantier pour les applications mobiles sur le chantier et le contrôle simple 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 la plus importante pour 67 % des entreprises pour les départements informatiques, suivies de près par le soutien aux départements spécialisés dans les activités quotidiennes avec 47 %. Les départements informatiques doivent donc non seulement fournir des solutions techniques, mais aussi agir en tant que médiateurs et intégrer activement les départements spécialisés dans les projets.

Les utilisateurs clés ou champions servent de lien entre le projet et le personnel : des collaborateurs issus du quotidien opérationnel qui apprennent tôt à connaître le système, soutiennent leurs collègues et remontent les retours d'expérience dans le projet. Les circuits de décision, les responsabilités pour les tests et la question de savoir qui formera ultérieurement doivent être clarifiés tôt et consignés par écrit.

Big Bang ou implémentation progressive : choisir la stratégie

Avec la stratégie Big Bang, le basculement pour toute l'entreprise a lieu à une date fixe. Les terminaux – tablettes, ordinateurs portables, smartphones – sont généralement équipés du nouveau logiciel pendant un week-end ou à d'autres moments où le travail est interrompu. Tous les départements et sites travaillent désormais 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 plus faibles, car il n'est pas nécessaire de payer et de maintenir deux applications.

Le plus grand inconvénient : tous les employés doivent changer 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'implémentation se fait étape par étape. Au début, seuls certains employés 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 prêts.

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 augmente la sécurité, mais exige un double effort de saisie et de contrôle pendant la période de transition. Celui qui évalue de manière réaliste la charge pesant sur le personnel choisit la stratégie qui convient à 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 implémentation réussie, l'acceptation par les collaborateurs est décisive ; 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é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 proches des 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 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 alors comme multiplicateurs : ils sont formés en premier et en profondeur, puis accompagnent leurs collègues dans le quotidien professionnel.

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'implémentation 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 donc la formation des collaborateurs 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 éviter l'IT fantôme

L'acceptation ne naît pas d'une instruction, mais de l'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 dans les décisions ; les questions ouvertes sur le « pourquoi » reçoivent des réponses, au lieu d'être ignorées.

L'informatique assume ici un rôle de médiateur entre les départements 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 départements spécialisés dans les activités 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 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'informatique.

Une entreprise contrecarre cela avec 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 propositions d'amélioration et les plaintes à l'équipe projet. Ainsi, les départements spécialisés et l'informatique 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 dans l'équipe, clarifier les problèmes avec le fournisseur, adapter les processus de travail et vérifier les objectifs définis au début. S'il apparaît qu'un processus fonctionne différemment dans la pratique par rapport à la planification, ce n'est pas le logiciel qui est tordu, mais le processus qui est remis en question et affiné.

L'optimisation continue n'est pas un accessoire, mais une composante fixe de l'implémentation 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'implémentation. Cela inclut l'examen régulier de l'utilisation, la consultation des évaluations, le suivi des points ouverts du support et la mise en œuvre d'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 les points techniques et organisationnels ouverts avec le fournisseur. – Adapter les processus et les responsabilités à la nouvelle façon 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.