Gestion de projet SI et conduite du changement

Introduction

Dans l’UE 5 du DSCG, la gestion de projet de système d’information (SI) ne se réduit pas à un simple enchaînement de tâches techniques. Elle consiste à traduire un besoin métier en solution organisée, sécurisée et pilotable, puis à accompagner l’organisation pour que cette solution soit effectivement adoptée.

Cette leçon s’inscrit dans la continuité des leçons précédentes sur l’alignement stratégique SI-métier (leçon 90), la gouvernance des SI (leçon 91), l’urbanisation et les architectures (leçon 92) et les relations avec les ESN (leçon 93). Ici, le point central est le suivant : comment piloter un projet de SI depuis le cahier des charges jusqu’au suivi de sa mise en œuvre, en intégrant les ressources, les délais, les risques, la sécurité, la qualité et l’appropriation par les utilisateurs.

Un projet SI mal cadré produit souvent les mêmes effets : dérive des coûts, retard, solution techniquement correcte mais inutilisable, tensions entre directions métiers et DSI, dépendance excessive au prestataire, ou encore non-conformité sur la sécurité et les données. À l’inverse, un projet bien piloté repose sur quatre piliers :

1. un cahier des charges structuré ;
2. une méthode de gestion de projet adaptée ;
3. une organisation claire des ressources, délais, coûts, qualité et risques ;
4. une conduite du changement cohérente avec les usages réels.

Objectifs d’apprentissage

À l’issue de cette leçon, vous devez être capable de :

• structurer, optimiser et animer les éléments d’un cahier des charges ;
• analyser le rôle stratégique du système d’information dans l’organisation à travers un projet ;
• planifier, organiser et conduire un projet de système d’information ;
• piloter un projet de SI depuis la rédaction du cahier des charges jusqu’au suivi de sa mise en œuvre ;
• distinguer les principales méthodologies de gestion de projet : cycle en V, méthodes agiles et approches hybrides ;
• intégrer les dimensions de ressources, délais, coûts, qualité, risques, sécurité, maintenance évolutive et appropriation organisationnelle.

1. Le projet SI : un outil de transformation stratégique

1.1 Définition d’un projet de système d’information

Un projet de système d’information est une démarche temporaire, organisée et finalisée visant à concevoir, faire évoluer ou déployer une solution numérique au service d’objectifs de l’organisation.

Il peut s’agir, par exemple :

• de déployer un ERP ;
• de remplacer un logiciel comptable devenu obsolète ;
• d’automatiser un processus de validation des achats ;
• de mettre en place un portail RH ;
• de créer un outil décisionnel ;
• d’interfacer plusieurs applications auparavant cloisonnées.

Le projet SI n’est donc pas seulement un projet informatique. C’est un projet organisationnel qui touche :

• les processus métiers ;
• les règles de gestion ;
• les données ;
• les responsabilités ;
• les contrôles internes ;
• les usages quotidiens des collaborateurs.

1.2 Pourquoi le projet SI a-t-il un rôle stratégique ?

Le programme insiste sur l’idée d’analyser le rôle stratégique du système d’information dans l’organisation. En gestion de projet, cela signifie qu’un projet ne doit jamais être lancé pour la seule raison qu’une technologie existe. Il doit répondre à une finalité stratégique.

Le SI peut jouer un rôle stratégique à plusieurs niveaux :

• soutenir la croissance de l’activité ;
• améliorer la performance opérationnelle ;
• sécuriser les processus ;
• faciliter la conformité réglementaire ;
• renforcer la qualité de la décision grâce à une meilleure donnée ;
• améliorer l’expérience utilisateur, interne ou externe ;
• accroître l’agilité de l’organisation face aux évolutions de son environnement.

1.3 Exemples de contribution stratégique du SI

Exemple 1 : projet d’ERP dans une PME en croissance

Une PME industrielle utilise des outils dispersés : comptabilité sur un logiciel local, stocks sur tableurs, achats sur une application distincte. La direction constate :

• des erreurs de ressaisie ;
• une faible visibilité sur les stocks ;
• des clôtures comptables trop longues ;
• une difficulté à piloter les marges.

Le projet d’ERP a ici une portée stratégique :

• il améliore la fiabilité des données ;
• il réduit les coûts de coordination ;
• il accélère le reporting ;
• il soutient la croissance.

Exemple 2 : portail client dans une société de services

L’entreprise veut offrir un espace client permettant le suivi des commandes, la consultation des factures et la gestion des réclamations. Le projet répond à des enjeux de :

• différenciation concurrentielle ;
• qualité de service ;
• réduction des tâches administratives ;
• fidélisation.

Le projet SI devient alors un levier de création de valeur.

2. Le cahier des charges : fondement du pilotage du projet SI

2.1 Définition et finalité

Le cahier des charges est le document de référence qui formalise le besoin, les objectifs, le périmètre, les contraintes et les attentes d’un projet SI.

Il sert à :

• clarifier le besoin ;
• aligner les parties prenantes ;
• cadrer le périmètre ;
• préparer la consultation d’une ESN ou d’un éditeur ;
• sécuriser la décision de lancement ;
• fournir une base de pilotage et d’évaluation.

Un cahier des charges mal construit entraîne souvent un mauvais projet, car l’on cherche alors à exécuter correctement quelque chose qui a été mal défini.

2.2 Pourquoi faut-il le structurer, l’optimiser et l’animer ?

Le programme ne demande pas seulement de rédiger un cahier des charges, mais de structurer, optimiser et animer ses éléments.

• Structurer, c’est organiser l’information de manière logique, exploitable et hiérarchisée.
• Optimiser, c’est éliminer les ambiguïtés, prioriser les besoins, distinguer l’essentiel de l’accessoire et rendre le document opérationnel.
• Animer, c’est faire vivre le cahier des charges dans le temps : ateliers métiers, arbitrages, mises à jour, validation des choix, gestion des évolutions.

Un cahier des charges n’est donc pas un document figé ; c’est un outil de dialogue entre métiers, DSI, direction générale et prestataires.

2.3 Structure recommandée d’un cahier des charges SI

1. Contexte et enjeux

Cette partie répond à la question : pourquoi ce projet existe-t-il ?

On y précise :

• la situation actuelle ;
• les dysfonctionnements observés ;
• les enjeux métiers ;
• les enjeux réglementaires ou de sécurité ;
• les objectifs stratégiques poursuivis.

2. Objectifs du projet

Les objectifs doivent être clairs, hiérarchisés et si possible mesurables.

Exemples :

• réduire de 30 % le temps de traitement d’une facture ;
• fiabiliser la donnée client ;
• améliorer la traçabilité des validations ;
• réduire les ressaisies ;
• centraliser les informations de pilotage.

3. Périmètre fonctionnel

Il faut préciser :

• ce qui est inclus dans le projet ;
• ce qui est exclu ;
• les processus concernés ;
• les utilisateurs visés ;
• les interfaces avec d’autres applications.

Cette partie est essentielle pour éviter l’extension incontrôlée du périmètre.

4. Description des besoins fonctionnels

Les besoins fonctionnels expriment ce que le système doit permettre de faire.

Exemples :

• créer une commande ;
• valider une note de frais ;
• suivre l’état d’avancement d’un dossier ;
• produire un tableau de bord ;
• historiser les modifications.

5. Exigences techniques et d’architecture

Sans entrer dans un niveau d’expertise d’ingénierie trop fin, il convient de préciser les attentes sur :

• l’hébergement ;
• l’interopérabilité ;
• les interfaces ;
• la performance ;
• la disponibilité ;
• la compatibilité avec l’existant.

6. Exigences de sécurité et de conformité

Le projet SI doit intégrer :

• les habilitations ;
• la traçabilité ;
• la confidentialité ;
• la protection des données ;
• la continuité d’activité ;
• les exigences de sécurité applicables.

7. Organisation du projet

Cette partie identifie :

• le maître d’ouvrage ou sponsor ;
• le chef de projet ;
• les référents métiers ;
• la DSI ;
• les éventuels prestataires ;
• les instances de décision.

8. Planning prévisionnel

On y indique les grandes phases :

• cadrage ;
• conception ;
• réalisation ;
• tests ;
• formation ;
• déploiement ;
• accompagnement post-démarrage.

9. Critères de qualité et de recette

Le cahier des charges doit prévoir les critères permettant de juger si la solution est conforme aux attentes.

10. Maintenance et évolutivité

Le programme précise que le projet doit être pensé aussi dans une perspective de maintenance évolutive et curative. Il faut donc anticiper :

• les corrections ;
• les demandes d’évolution ;
• le support utilisateur ;
• les futures montées de version.

2.4 Comment optimiser un cahier des charges ?

Pour optimiser le cahier des charges, il faut notamment :

• distinguer les besoins obligatoires des besoins souhaitables ;
• formaliser les priorités ;
• éviter les formulations vagues ;
• relier chaque besoin à un objectif métier ;
• identifier les contraintes non négociables ;
• prévoir les critères de validation dès l’amont.

Mauvaise formulation

“Le futur outil devra être simple, moderne et performant.”

Cette phrase est trop floue.

Meilleure formulation

“Le futur outil devra permettre à un utilisateur non expert de saisir une demande en moins de 3 minutes, avec contrôle automatique des champs obligatoires et accès sécurisé par profil.”

2.5 Comment animer le cahier des charges ?

L’animation suppose une démarche collective :

• ateliers de recueil des besoins ;
• reformulation et validation ;
• arbitrages entre directions ;
• gestion des demandes nouvelles ;
• mise à jour des versions ;
• communication des décisions.

Le chef de projet SI doit ici jouer un rôle de traducteur entre langage métier, langage technique et langage de pilotage.

3. Les grandes étapes du pilotage d’un projet de SI

3.1 Le cadrage

Le cadrage est la phase où l’on vérifie la pertinence du projet et où l’on pose ses bases.

Il comprend généralement :

• l’identification du besoin ;
• l’analyse du contexte ;
• la formulation des objectifs ;
• l’évaluation des impacts ;
• la définition du périmètre ;
• la première estimation des ressources et délais.

Le cadrage permet d’éviter de lancer un projet mal défini ou non aligné sur la stratégie de l’organisation.

3.2 La conception

La conception transforme le besoin en solution projetée.

Elle porte sur :

• les processus cibles ;
• les règles de gestion ;
• les données ;
• les interfaces ;
• les rôles utilisateurs ;
• les scénarios de fonctionnement.

3.3 La réalisation ou configuration

Selon le type de projet, il peut s’agir :

• de développement spécifique ;
• de paramétrage d’un progiciel ;
• d’intégration de solutions existantes ;
• de reprise de données ;
• de mise en place d’interfaces.

3.4 Les tests et la recette

La recette vérifie que la solution livrée répond au besoin exprimé.

Elle suppose :

• des cas de test ;
• des jeux d’essai ;
• des critères d’acceptation ;
• une gestion des anomalies ;
• une validation formelle.

3.5 Le déploiement

Le déploiement ne consiste pas seulement à “mettre en production”. Il faut aussi :

• former les utilisateurs ;
• planifier la bascule ;
• organiser l’assistance au démarrage ;
• sécuriser la continuité d’activité ;
• suivre les incidents initiaux.

3.6 Le suivi post-déploiement

Même si le programme n’approfondit pas le support post-déploiement, il précise que celui-ci doit être abordé sous l’angle de la maintenance évolutive et curative.

Il faut donc prévoir :

• le traitement des anomalies ;
• les demandes d’amélioration ;
• les ajustements de paramétrage ;
• le suivi des performances ;
• l’évaluation de l’adoption réelle.

4. Planifier, organiser et conduire un projet SI

4.1 La planification

Planifier un projet, c’est transformer une intention en séquence maîtrisable.

La planification repose sur :

• le découpage en phases et tâches ;
• l’identification des dépendances ;
• l’estimation des charges ;
• l’affectation des ressources ;
• les jalons de validation.

Un projet SI doit être planifié avec réalisme. Une planification trop optimiste est une source classique de dérive.

4.2 L’organisation des rôles

La réussite d’un projet dépend fortement de la clarté des responsabilités.

Rôles fréquents :

• sponsor : porte la légitimité du projet ;
• chef de projet : coordonne le pilotage ;
• référents métiers : expriment et valident les besoins ;
• DSI : garantit la cohérence technique et la sécurité ;
• prestataire / ESN / éditeur : réalise tout ou partie de la solution ;
• utilisateurs clés : participent aux tests et à l’adoption.

4.3 Les ressources du projet

Les ressources ne sont pas seulement financières. Il faut distinguer :

• les ressources humaines : compétences, disponibilité, arbitrages de temps ;
• les ressources techniques : environnements, outils, infrastructures ;
• les ressources organisationnelles : gouvernance, comités, procédures ;
• les ressources informationnelles : documentation, données, référentiels.

Un projet échoue souvent non pas par manque d’idée, mais par sous-estimation de la disponibilité réelle des acteurs métiers.

4.4 Le pilotage des délais

Le délai est un indicateur majeur, mais il doit être apprécié avec discernement.

Un retard peut venir :

• d’une mauvaise définition initiale ;
• d’un arbitrage tardif ;
• d’une dépendance technique non anticipée ;
• d’une faible mobilisation des utilisateurs ;
• d’une mauvaise qualité des données à reprendre.

Le pilotage des délais suppose :

• des jalons clairs ;
• un suivi régulier ;
• une remontée rapide des alertes ;
• des arbitrages documentés.

5. Comparer les méthodologies : cycle en V, agile et hybride

5.1 Le cycle en V

Le cycle en V est une méthodologie séquentielle dans laquelle chaque phase prépare la suivante, avec une logique de validation progressive.

Schématiquement :

• expression des besoins ;
• spécifications ;
• conception ;
• réalisation ;
• tests unitaires ;
• tests d’intégration ;
• recette.

Avantages

• forte structuration ;
• documentation claire ;
• bonne traçabilité ;
• adapté aux environnements stables et réglementés.

Limites

• faible souplesse ;
• difficulté à intégrer des changements tardifs ;
• risque de décalage entre besoin initial et besoin réel au moment de la livraison.

Cas adaptés

• projet fortement normé ;
• besoin bien défini dès l’amont ;
• environnement à fortes contraintes de validation.

5.2 Les méthodes agiles

Les méthodes agiles reposent sur une logique itérative et incrémentale. On avance par cycles courts, avec retours fréquents des utilisateurs.

Principes généraux :

• collaboration étroite avec le métier ;
• adaptation continue ;
• livraisons progressives ;
• priorisation dynamique ;
• valorisation de l’usage réel.

Avantages

• meilleure adaptation aux besoins évolutifs ;
• implication forte des utilisateurs ;
• visibilité plus rapide sur les résultats ;
• réduction du risque de livrer une solution inadaptée.

Limites

• besoin fort de disponibilité métier ;
• risque de dérive si la gouvernance est insuffisante ;
• documentation parfois moins formalisée si le pilotage est immature.

Cas adaptés

• besoin partiellement évolutif ;
• innovation ;
• contexte où les usages doivent être testés progressivement.

5.3 Les approches hybrides

Les approches hybrides combinent une structure globale de projet relativement cadrée avec des séquences agiles sur certaines briques.

Exemple :

• cadrage, sécurité, architecture, budget et jalons en mode structuré ;
• développement de certaines fonctionnalités en itérations courtes.

Cette approche est souvent pertinente en entreprise, car elle permet de concilier :

• exigences de gouvernance ;
• visibilité budgétaire ;
• besoin de souplesse ;
• implication progressive des utilisateurs.

5.4 Comment choisir ?

Le choix dépend notamment :

• de la stabilité du besoin ;
• du niveau de risque ;
• des contraintes réglementaires ;
• de la culture de l’organisation ;
• de la disponibilité des métiers ;
• de la nature de la solution.

Repère pratique

• besoin stable + forte exigence documentaire : cycle en V ;
• besoin évolutif + forte interaction métier : agile ;
• organisation complexe + nécessité de concilier gouvernance et souplesse : hybride.

6. Qualité, risques, sécurité et plan qualité

6.1 Le plan qualité du projet SI

Le plan qualité organise les moyens permettant de garantir que le projet et la solution répondent aux exigences définies.

Il précise notamment :

• les objectifs qualité ;
• les responsabilités ;
• les modalités de validation ;
• les procédures de test ;
• la gestion documentaire ;
• le traitement des anomalies ;
• les règles d’amélioration continue.

Pourquoi est-il essentiel ? Parce qu’un projet peut respecter le délai et le budget tout en échouant sur la qualité d’usage.

6.2 Les risques du projet SI

Le programme demande d’identifier et gérer les risques liés notamment à la maintenance, à l’évolutivité et à la sécurité.

On peut distinguer plusieurs familles de risques :

• risques de périmètre : besoins mal définis, demandes additionnelles ;
• risques de délai : dépendances, indisponibilités, arbitrages tardifs ;
• risques techniques : intégration, performance, reprise de données ;
• risques humains : résistance, manque de compétences, faible appropriation ;
• risques de sécurité : accès non maîtrisés, données exposées, traçabilité insuffisante ;
• risques de maintenance : solution difficile à faire évoluer ou à corriger.

6.3 Démarche simple de gestion des risques

Étape 1 : identifier

Lister les événements susceptibles d’affecter le projet.

Étape 2 : évaluer

Apprécier pour chaque risque :

• la probabilité ;
• l’impact ;
• éventuellement la criticité.

Étape 3 : traiter

Choisir une réponse :

• éviter ;
• réduire ;
• transférer ;
• accepter sous surveillance.

Étape 4 : suivre

Mettre à jour régulièrement le registre des risques.

6.4 La sécurité dans le projet SI

La sécurité ne doit pas être ajoutée à la fin. Elle doit être intégrée dès le cahier des charges.

Points d’attention :

• gestion des habilitations ;
• séparation des rôles ;
• journalisation et traçabilité ;
• confidentialité des données ;
• sécurité des interfaces ;
• sauvegarde et reprise ;
• continuité d’activité.

Un projet qui ignore ces éléments crée un risque pour l’organisation, même si la solution fonctionne techniquement.

7. La conduite du changement dans les projets SI

7.1 Pourquoi la conduite du changement est-elle indispensable ?

Un projet SI réussit rarement uniquement par la qualité technique. Il réussit quand les utilisateurs :

• comprennent le sens du projet ;
• savent utiliser la solution ;
• acceptent les nouvelles règles ;
• modifient réellement leurs pratiques.

La conduite du changement vise précisément à accompagner cette transition.

7.2 Les principales résistances

Les résistances peuvent venir :

• de la peur de perdre des repères ;
• de la crainte d’un contrôle accru ;
• de l’impression que le projet a été imposé ;
• du manque de temps pour apprendre ;
• d’une mauvaise compréhension des bénéfices ;
• d’un décalage entre la solution et la réalité du travail.

7.3 Les leviers de conduite du changement

• communication régulière et compréhensible ;
• implication des utilisateurs clés ;
• démonstration des bénéfices concrets ;
• formation adaptée aux profils ;
• assistance au démarrage ;
• prise en compte des retours terrain ;
• exemplarité managériale.

7.4 La conduite du changement comme composante du pilotage

La conduite du changement n’est pas un “volet annexe”. Elle fait partie du pilotage du projet.

Le chef de projet doit donc suivre aussi des indicateurs tels que :

• taux de participation aux ateliers ;
• taux de formation ;
• niveau d’appropriation ;
• incidents d’usage ;
• satisfaction des utilisateurs ;
• respect des nouveaux processus.

8. Cas pratique fil rouge : déploiement d’un outil de gestion des achats

8.1 Situation

Une ETI souhaite déployer un outil de gestion des achats pour remplacer un processus largement manuel. Les problèmes actuels sont :

• demandes d’achat transmises par courriel ;
• validations peu traçables ;
• erreurs de codification ;
• retards de traitement ;
• difficulté à rapprocher commande, réception et facture.

8.2 Analyse stratégique

Le projet contribue à :

• renforcer le contrôle interne ;
• améliorer la traçabilité ;
• réduire les délais ;
• fiabiliser les données achats ;
• mieux piloter les engagements.

8.3 Éléments du cahier des charges

Objectifs

• dématérialiser les demandes d’achat ;
• mettre en place un circuit de validation ;
• interfacer l’outil avec la comptabilité ;
• produire des tableaux de bord achats.

Périmètre

Inclus : demandes d’achat, validation, commande, réception, rapprochement.

Exclus : gestion des appels d’offres fournisseurs.

Exigences de sécurité

• habilitations par profil ;
• journal des validations ;
• conservation de l’historique ;
• accès sécurisé.

8.4 Choix de méthode

Une approche hybride est retenue :

• cadrage et gouvernance en mode structuré ;
• paramétrage et ajustements fonctionnels en itérations avec les utilisateurs.

8.5 Principaux risques

• données fournisseurs incomplètes ;
• faible disponibilité des acheteurs pour les ateliers ;
• rejet du nouveau circuit de validation ;
• interfaces comptables retardées.

8.6 Actions de conduite du changement

• ateliers de co-construction ;
• désignation d’utilisateurs relais ;
• formation ciblée ;
• support renforcé au démarrage ;
• communication sur les gains de traçabilité et de temps.

8.7 Enseignement du cas

Ce cas montre qu’un projet SI n’est pas seulement une installation d’outil. C’est une transformation du processus, de la responsabilité et du contrôle.

9. Méthode pas à pas pour piloter un projet SI depuis le cahier des charges

Étape 1 : analyser le besoin et les enjeux

• identifier le problème à résoudre ;
• relier le projet à la stratégie ;
• qualifier les impacts métiers.

Étape 2 : construire le cahier des charges

• formaliser les objectifs ;
• délimiter le périmètre ;
• décrire les besoins fonctionnels ;
• intégrer sécurité, qualité et maintenance.

Étape 3 : organiser la gouvernance

• nommer les responsables ;
• définir les circuits de décision ;
• planifier les comités et validations.

Étape 4 : choisir la méthodologie de projet

• cycle en V, agile ou hybride selon le contexte.

Étape 5 : planifier les ressources et les délais

• découper le projet ;
• affecter les responsabilités ;
• fixer les jalons.

Étape 6 : suivre les risques et la qualité

• établir un registre des risques ;
• définir les critères qualité ;
• suivre les anomalies.

Étape 7 : préparer le déploiement

• former ;
• tester ;
• organiser la bascule ;
• prévoir l’assistance.

Étape 8 : accompagner l’appropriation

• mesurer l’usage ;
• corriger ;
• prioriser les évolutions.

10. Points de vigilance professionnels

10.1 Confondre besoin et solution

Erreur fréquente : demander directement un outil au lieu d’analyser le besoin. Exemple : “il nous faut une application mobile” au lieu de “nous devons réduire les délais de traitement sur le terrain”.

10.2 Sous-estimer la disponibilité des métiers

Un projet SI sans implication métier forte produit souvent une solution techniquement recevable mais fonctionnellement insuffisante.

10.3 Négliger la sécurité au stade du cadrage

Les habilitations, la traçabilité et la confidentialité doivent être pensées dès le cahier des charges.

10.4 Oublier la maintenance évolutive

Une solution trop rigide devient rapidement coûteuse à adapter. L’évolutivité est donc un critère de choix important.

10.5 Réduire la conduite du changement à une formation finale

Former à la fin ne suffit pas. Le changement se prépare dès le lancement du projet.

11. Mémo de synthèse

À retenir

• Un projet SI est un projet de transformation organisationnelle, pas seulement technique.
• Il doit être relié au rôle stratégique du système d’information dans l’organisation.
• Le cahier des charges est la base du cadrage : il faut le structurer, l’optimiser et l’animer.
• Piloter un projet de SI suppose de maîtriser :
  • le périmètre ;
  • les ressources ;
  • les délais ;
  • la qualité ;
  • les risques ;
  • la sécurité ;
  • la maintenance évolutive.
• Trois grandes logiques méthodologiques doivent être distinguées :
  • cycle en V ;
  • méthodes agiles ;
  • approches hybrides.
• La conduite du changement est une composante centrale du pilotage.

Formule directrice

Un projet SI réussi = un besoin bien cadré + une méthode adaptée + un pilotage rigoureux + une appropriation réelle par les utilisateurs.

Conclusion

La gestion de projet SI constitue un point de rencontre entre stratégie, organisation, technique et management. Le futur professionnel du chiffre ne doit pas être un simple observateur du projet numérique : il doit savoir analyser son utilité stratégique, structurer le cahier des charges, sécuriser le pilotage et accompagner l’appropriation de la solution.

Dans cette perspective, le projet SI devient un instrument de performance, de conformité et de création de valeur. Sa réussite dépend moins d’un outil “parfait” que de la capacité de l’organisation à formuler clairement ses besoins, arbitrer ses priorités, mobiliser ses acteurs et piloter durablement la transformation.