Conduire un projet de système d’information

Un projet est une démarche temporaire visant un résultat défini, avec des ressources et des contraintes. Le fonctionnement quotidien du SI se poursuit pendant sa réalisation. Un projet de SI peut modifier une application, les données, les procédures et les rôles. Il ne consiste donc pas seulement à écrire du code. Son périmètre indique ce qui change et ce qui reste en dehors de la réalisation demandée.

Le responsable métier exprime le besoin et participe aux choix ; les utilisateurs décrivent leur travail et éprouvent les solutions ; l’équipe technique étudie et réalise ; le chef de projet coordonne les activités et le suivi. La direction arbitre les moyens et les priorités. Une personne peut cumuler plusieurs fonctions, mais les responsabilités doivent rester identifiables. La coopération suppose des informations partagées sur les décisions, les versions et les difficultés.

Le cahier des charges précise les besoins, les exigences, les contraintes et les conditions de vérification. Une exigence est une condition observable : une confirmation doit être refusée si le rendez-vous n’a pas été validé. La formule vague application moderne ne suffit pas. Les contraintes peuvent porter sur le budget, la date, la compatibilité ou les compétences disponibles. Une demande nouvelle se discute avec ses effets sur le périmètre, le coût et le calendrier.

Une tâche possède une durée, des ressources, un responsable et des dépendances. Une dépendance indique qu’un résultat est nécessaire avant de commencer une autre tâche. Un jalon marque une décision ou une vérification : validation du besoin, version testable, décision d’acceptation. Le jalon n’est pas une activité longue en lui-même. Un diagramme de Gantt situe les tâches dans le temps, mais la faisabilité dépend aussi de la disponibilité des personnes.

Le dossier suivant suppose des ressources suffisantes pour les tâches parallèles et aucune interruption. A consiste à valider les exigences pendant deux jours. B prépare l’application pendant trois jours après A. C prépare les données d’essai pendant deux jours après A. D réalise la recette pendant deux jours après B et C. Les nombres sur l’axe indiquent du temps écoulé depuis le début, pas des dates de calendrier.

Une tâche critique ne dispose pas de marge dans le planning étudié : un retard sur cette tâche peut retarder la fin du projet. Ce n’est pas nécessairement la tâche la plus difficile ni la plus coûteuse. La criticité peut évoluer quand les durées ou les dépendances changent. Plusieurs chemins peuvent être critiques. Si une même personne doit réaliser B et C sans pouvoir partager son temps, l’hypothèse de parallélisme doit être revue.

Le pilotage rapproche l’avancement et les ressources consommées d’une référence prévue. Une dépense doit être reliée à une période et à un périmètre. Le montant dépensé ne prouve pas le pourcentage de travail achevé. Une tâche peut coûter cher sans fournir le résultat attendu ; une économie apparente peut venir d’un report. Le suivi doit rendre visibles les réalisations, les difficultés et le reste à faire.

Le chef de projet recherche les causes avant de proposer un ajustement : besoin modifié, difficulté technique, ressource absente ou estimation initiale trop optimiste. Les options peuvent porter sur les moyens, l’échéance ou le périmètre. Ajouter une personne ne réduit pas mécaniquement la durée, car certaines tâches sont dépendantes et une coordination supplémentaire peut être nécessaire. Une réduction du périmètre doit préserver les exigences essentielles ou faire l’objet d’un arbitrage explicite.

Une démarche séquentielle stabilise des étapes successives. Des démarches itératives ou agiles organisent des cycles courts avec retours des utilisateurs et ajustements. Elles ne suppriment ni budget, ni responsabilités, ni vérification. Le choix dépend notamment de l’incertitude sur le besoin et des contraintes. Dans tous les cas, une communication régulière aide les acteurs à synchroniser leurs tâches et à éviter des décisions contradictoires.

La recette compare la réalisation aux exigences convenues. Chaque scénario précise l’état initial, les actions, le résultat attendu et l’observation obtenue sur une version identifiée. Une anomalie se décrit de manière reproductible. Après correction, le comportement concerné est vérifié à nouveau, avec les effets voisins pertinents. Le compte rendu distingue succès, échecs et tests non exécutés ; un test absent ne devient pas un succès.

Livraison, acceptation et bénéfices d’usage sont différents. La livraison remet une version ; l’acceptation correspond à une décision fondée sur les conditions du projet ; les bénéfices se mesurent dans l’activité après mise en usage. La formation, la reprise des données et l’assistance doivent donc être préparées. Une mise en service précipitée peut déplacer le travail vers les utilisateurs ou multiplier les erreurs malgré une application techniquement disponible.

Pour poursuivre : https://www.allostmg.fr/exercices.