Conduite du projet

Nous voici au terme du cours, et à l'endroit qui, en réalité, l'a traversé de bout en bout. Le projet n'est pas un dernier chapitre ajouté aux autres : le projet est l'UE. Depuis la première semaine, en équipe de trois ou quatre, vous avez conduit un logiciel modeste — gestion de bibliothèque, de scolarité, de tournoi — et chaque bloc du cours y a ajouté une couche : le cahier des charges après le bloc III, la conception au bloc IV, les tests au bloc V, Git dès le début.

Ce chapitre traite la conduite de ce projet : ce qui fait qu'un ensemble de techniques devient un logiciel livré, à plusieurs, dans le temps. Car un projet n'est pas la somme de ses techniques — c'est leur orchestration.

Constituer l'équipe

Un projet à plusieurs commence par une évidence souvent négligée : se répartir clairement rôles et responsabilités. Le chapitre 1 a nommé les rôles — client, analyste, concepteur, développeur, testeur, chef de projet ; dans une équipe de trois ou quatre, chacun en cumule plusieurs, et ils tournent au fil du projet.

Deux écueils à éviter, aux extrêmes opposés :

• le passager clandestin : un membre qui ne contribue pas, et dont l'absence n'est visible que trop tard. Le découpage en tâches nommées (plus bas) et les points d'avancement le rendent visible tôt.
• le héros solitaire : un membre qui fait tout, court-circuite les autres, et devient le seul à connaître le code — un risque énorme s'il tombe malade la veille de la soutenance. La revue de code (chapitre 6) et Git (chapitre 9) diffusent la connaissance dans l'équipe.

Le rappel du chapitre 1 vaut plus que jamais : la plupart des difficultés d'un projet sont humaines et organisationnelles avant d'être techniques. Une équipe qui communique bat une équipe plus compétente qui ne se parle pas.

Découper en tâches et planifier

On ne pilote pas « faire la bibliothèque » : c'est trop gros pour être estimé, réparti, ou suivi. On le découpe en tâches petites, nommées, dont on peut dire quand elles sont finies. Ce découpage rend le projet à la fois estimable (combien de temps pour chaque tâche ?) et répartissable (qui prend quoi ?).

Les tâches ne sont pas indépendantes : certaines ont des pré-requis. On ne teste pas l'emprunt avant de l'avoir codé, on ne code pas avant d'avoir le diagramme, ni le diagramme avant le cahier des charges — c'est le cycle de vie (chapitre 2) à la maille de la tâche. En ordonnant les tâches selon leurs dépendances, on obtient un ordre de réalisation valide, et surtout on repère ce qui peut se faire en parallèle : deux membres écrivant « classe Livre » et « classe Abonné » en même temps. C'est ce parallélisme, une fois le travail découpé et ordonné, qui permet à une équipe d'aller plus vite qu'une personne seule. L'exercice vous fait construire cet ordonnancement.

La planification, à votre niveau, reste simple : la liste des tâches, leur ordre, qui fait quoi, et une estimation grossière. Un tableau partagé (le suivi des tâches du chapitre 9) suffit. L'important n'est pas la précision du plan — elle est illusoire — mais d'avoir un cap commun et de savoir où l'on en est.

Les points d'avancement

Un plan ne survit jamais intact au contact de la réalité. Les points d'avancement — réguliers et courts — servent à confronter le plan à ce qui s'est réellement passé : qu'est-ce qui est fini, qu'est-ce qui est en retard, qu'est-ce qui bloque quelqu'un ? C'est la mêlée de Scrum (chapitre 3), ramenée à l'échelle de votre projet.

Leur vertu principale est de rendre les problèmes visibles tôt, quand ils sont encore petits — même logique que « détecter au plus tôt » (chapitre 2). Un membre bloqué depuis trois jours qui n'ose pas le dire, une tâche sous-estimée, une intégration qui ne se fait pas : autant de dérives qu'un point hebdomadaire attrape avant qu'elles ne compromettent la soutenance. Ce qui tue les projets étudiants, ce n'est pas la difficulté technique, c'est le silence — chacun avance dans son coin et l'on découvre à la fin que rien ne s'assemble.

Documenter le projet

La documentation n'est pas une corvée de fin de projet : c'est un outil de travail continu. Deux niveaux, déjà croisés au chapitre 6 :

• la documentation pour l'utilisateur : comment installer et se servir du logiciel (un fichier README : à quoi il sert, comment le lancer) ;
• la documentation pour l'équipe : les choix de conception, l'architecture, les décisions prises et leurs raisons — ce qui permet à un membre de reprendre le travail d'un autre.

À votre niveau, l'essentiel tient dans un bon README, un cahier des charges tenu à jour, et les diagrammes UML utiles (chapitre 5). La règle du chapitre 6 s'applique : une documentation qui ment (parce qu'elle n'a pas suivi le code) est pire que pas de documentation. Mieux vaut peu, mais juste et à jour.

Soutenance et démonstration

Le projet se clôt par une soutenance : présenter le travail, et surtout le démontrer en fonctionnement. C'est un exercice à part entière, et il se prépare.

Quelques principes :

• la démonstration prime : montrer le logiciel qui marche vaut mille diapositives. Préparez un scénario de démonstration répété d'avance — rien de pire qu'une démo qui plante en direct faute d'avoir été testée (retour du chapitre 8 : « ça marche chez moi » ne suffit pas, pas même en soutenance).
• raconter une histoire : le besoin de départ, les choix faits et pourquoi, ce qui marche, ce qui reste à faire. Un jury préfère une équipe lucide sur ses limites à une équipe qui les cache.
• chacun parle : la soutenance reflète le travail d'équipe ; tous les membres présentent leur part.

La soutenance n'est pas qu'une évaluation : c'est l'occasion de prendre du recul sur ce qu'on a appris — techniquement, mais aussi sur la conduite d'un projet à plusieurs, qui est la vraie compétence de cette UE.

À vous

Le dernier exercice du cours est celui du chef de projet : découper le projet en tâches, respecter leurs dépendances, et en tirer un ordre de réalisation valide — tout en repérant ce qui peut se faire en parallèle entre coéquipiers.

C'est exactement le raisonnement que votre équipe a tenu, consciemment ou non, tout au long du semestre : transformer un « faire la bibliothèque » insaisissable en une suite de tâches réalisables, réparties et ordonnées.

Le graphe ci-dessous montre ces dépendances : chaque flèche signifie « doit être fini avant ». Les tâches d'une même colonne — « Classe Livre » et « Classe Abonné », ou « Tests » et « Interface » — ne dépendent pas l'une de l'autre et peuvent donc être menées en parallèle par deux membres.

// Le projet « gestion de bibliothèque », découpé en tâches. Chaque tâche a
// des PRÉ-REQUIS : des tâches qui doivent être finies avant de la commencer.
const TACHES = {
  "cahier des charges":   { deps: [] },
  "diagramme UML":        { deps: ["cahier des charges"] },
  "classe Livre":         { deps: ["diagramme UML"] },
  "classe Abonné":        { deps: ["diagramme UML"] },
  "emprunt (logique)":    { deps: ["classe Livre", "classe Abonné"] },
  "tests de l'emprunt":   { deps: ["emprunt (logique)"] },
  "interface":            { deps: ["emprunt (logique)"] },
  "démonstration":        { deps: ["tests de l'emprunt", "interface"] },
};

// ── À VOUS : ordonnancer les tâches ─────────────────────────────────────────
// Produire un ORDRE de réalisation où chaque tâche vient APRÈS ses pré-requis.
// Méthode : tant qu'il reste des tâches, prendre celles dont TOUS les
// pré-requis sont déjà faits, les ajouter à l'ordre, recommencer.
function ordonnancer(taches) {
  const faites = [];
  const restantes = new Set(Object.keys(taches));
  // à compléter :
  //   tant que restantes n'est pas vide :
  //     trouver une tâche dont tous les deps sont dans 'faites'
  //     l'ajouter à 'faites', la retirer de 'restantes'
  //   (si aucune n'est trouvable -> dépendance circulaire)
  return faites;
}

// ── Vérification ────────────────────────────────────────────────────────────
const ordre = ordonnancer(TACHES);
console.log("Ordre de réalisation :");
ordre.forEach((t, i) => console.log("   " + (i + 1) + ". " + t));

let valide = true;
const rang = Object.fromEntries(ordre.map((t, i) => [t, i]));
for (const [t, { deps }] of Object.entries(TACHES))
  for (const d of deps)
    if (!(rang[d] < rang[t])) { valide = false; console.log("   ✗ " + t + " avant son pré-requis " + d); }
console.log(valide && ordre.length === Object.keys(TACHES).length
  ? "Ordre valide : chaque tâche vient après ses pré-requis."
  : "Ordre invalide.");

Ce que ce cours vous laisse

Vous avez parcouru la vie d'un projet logiciel, et surtout vous l'avez vécue — un projet collectif tenu tout le semestre, chaque bloc du cours y ajoutant sa couche. Trois idées survivent à l'oubli des détails :

• construire du logiciel n'est pas programmer : c'est spécifier, concevoir, tester, versionner, coordonner — parce qu'un logiciel dure, grossit et passe entre plusieurs mains ;
• la qualité est un investissement, pas un luxe : lisibilité, conception, tests réduisent le coût dominant, la maintenance — et c'est le calcul du chapitre 1 ;
• les difficultés d'un projet sont d'abord humaines : communiquer, se répartir le travail, se relire, résoudre calmement les conflits — techniques comme humains.

Les grands sujets que ce cours n'a fait qu'effleurer — architecture logicielle, intégration continue, méthodes agiles avancées, tests automatisés à grande échelle — vous attendent en L2, L3 et au-delà. Mais le réflexe fondateur, lui, est acquis : on ne bâtit pas un logiciel comme on écrit un programme. Et la meilleure façon de l'apprendre restera toujours celle de cette UE — en le faisant, à plusieurs, sur un vrai projet.

À retenir