Conduite de projet

Nous intervenons pour piloter vos projets informatique / web / data, ou pour vous prêter main forte pour ces projets.

Quelques retours d’expérience

Avant de décrire plus loin les phases d’activités d’un projet, voici quelques leçons qui nous viennent du retour d’expérience :

  1. Cela vaut le coup de questionner la demande, spécialement quand elle est un peu instable. Qui demande le projet et pourquoi ? Si un projet important est assis sur une demande instable ou dont l’objectif est incertain, il y a un risque… d’effondrement complet.
  2. Si on remplace un système existant, il y a un risque spécifique. Les demandeurs vont systématiquement oublier ou minimiser ce qui fonctionne déjà dans ce système : ça coule de source pour eux, ils sont avides de ce qu’ils n’ont pas. Mais pour ceux qui créent le nouveau système, aucune des fonctions de l’ancien ne coule de source si elle n’est pas décrite dans « les spécs ».
  3. Un projet peut répondre à un nouveau besoin. Un projet peut mettre en oeuvre une nouvelle technologie (nouvelle au sens de « pas encore connue par l’équipe concernée »). Mais quand on répond à un nouveau besoin par une nouvelle technologie, comment savoir où on va ? Il y a là un danger particulier à maîtriser.


Voici maintenant une revue des différentes phases d’activité d’un projet. Elles ne sont pas forcément séquentielles. Si l’on procède par un certain nombre de « sprints » dans le cadre de méthodes agiles, chacun d’entre eux  passera ou non par ces différentes phases.

Les spécifications ( « les spécs » )

La conduite de projet informatique, ce sont en premier les activités suivantes :

  • Recueillir les besoins et les demandes, les hiérarchiser
  • Déterminer le contour du projet, sa justification, l’avoir ensuite présente à l’esprit pour pouvoir la vérifier tout au long de la vie du projet ( cf la méthodologie PRINCE 2 dont c’est l’un des principes clés).
  • Valider le projet auprès des demandeurs
  • Réaliser le Cahier de spécifications fonctionnelles.

Mais qu’est-ce que c’est que le Cahier de spécifications fonctionnelles alias Cahier Des Charges (CDC) ou Business Requirements Document (BRD) ? C’est un document qui recueille les besoins ou spécifications, dont chacun doit posséder les qualités suivantes :

  • Nécessaire : il s’agit de concentrer les ressources disponibles sur ce qui est indispensable
  • Unitaire : chaque point concerne une seule demande
  • Validée : acceptée et revendiquée par les participants du projet
  • À jour : en accord avec la situation actuelle des besoins, de la technologie, du contexte économique et technique du projet
  • Réaliste : chaque demande doit être faisable en fonction de l’ambition et des moyens du projet
  • Compréhensible : ce qui se conçoit bien s’énonce clairement et se réalise aisément
  • Non technique : les exigences sur les moyens techniques de réalisation, sur la façon de faire, relèvent de la phase d’architecture, de recherche de solutions et ne sont pas des spécifications fonctionnelles.

Le choix de solution

Les activités de choix de solution sont les suivantes :

  • Rechercher les solutions, les alternatives possibles
  • Maquetter, prototyper des éléments de solutions, établir des « Proofs of Concept » pour aider au choix d’architecture
  • Choisir l’architecture cible

La mise en oeuvre

C’est la partie centrale du projet. Les méthodes agiles (Scrum, XP, …) ont notamment pour but de fluidifier cette phase, d’éviter l’effet tunnel d’une mise en oeuvre que l’on attend trop longtemps. La clé est de procéder à des livraisons régulières. Quand on pousse encore un peu la logique on arrive au principe CICD : Continuous Integration, Continuous Development.

Les activités :

  • Animer et suivre la mise en oeuvre du projet : Plan d’actions, Gestion des risques, Gestion du périmètre, Gestion des coûts ;
  • Planifier et suivre les plans d’action
  • Faire : Réaliser, Développer, Intégrer, Interfacer, …
  • Formaliser la documentation de projet

Le démarrage ou « Go live »

  • Gérer la mise en place : Former, Mettre en place, Démarrer
  • Organiser et démarrer la phase de maintenance
  • Clôturer le projet, Formaliser les retours d’expérience.

🙂