Les points de repère à garder avant de lancer le suivi
- Un jalon marque une décision, pas une simple tâche en cours.
- Les jalons les plus utiles couvrent le cadrage, l'architecture, les tests, la recette, le déploiement et le passage en exploitation.
- Sur un projet logiciel de taille moyenne, 6 à 9 jalons majeurs suffisent souvent pour garder un pilotage lisible.
- En agile, on continue d'utiliser des jalons, mais à un niveau de gouvernance différent des sprints.
- Un bon jalon doit être observable, daté, porté par un responsable et associé à une conséquence claire.
Un jalon n'est pas une tâche, c'est un point de décision
Je distingue toujours trois choses: la tâche, le livrable et le jalon. Une tâche consomme du temps; un livrable produit quelque chose de tangible; un jalon constate qu'un état attendu est atteint et qu'on peut prendre une décision. Cette différence paraît théorique, mais elle change tout dans un projet logiciel.
| Terme | Rôle | Exemple |
|---|---|---|
| Jalon | Point de décision ou de validation | Architecture validée |
| Livrable | Résultat concret remis à un acteur | Cahier des charges, module, rapport de tests |
| Tâche | Action à exécuter pour avancer | Corriger un bug, rédiger une spécification, configurer un environnement |
| Porte de validation | Autorisation de passer à l'étape suivante | Go/no-go avant mise en production |
Un sprint review, par exemple, est un rituel; le jalon, lui, est la décision qu'on prend à partir de ce rituel. Je me range à une définition simple: un jalon décrit un état attendu à un instant donné, pas la manière de l'atteindre. C'est pour cela qu'il sert si bien le pilotage de projet: il transforme l'avancement en repères vérifiables, pas en impressions.
Où placer les jalons dans le cycle de vie logiciel
Sur un projet de taille moyenne, je vise souvent 6 à 9 jalons majeurs. C'est assez pour suivre le risque sans transformer le planning en roman, et assez peu pour que chaque jalon déclenche vraiment une décision. La cadence varie, mais dans la pratique un cadrage prend souvent 1 à 2 semaines, une conception sérieuse 2 à 4 semaines, puis les cycles de construction et de tests se découpent en incréments plus courts.| Phase | Jalon utile | Ce que je vérifie | Ce que cela débloque |
|---|---|---|---|
| Cadrage | Charte de projet validée | Périmètre, budget, sponsor, risques majeurs | Lancement du design et allocation des ressources |
| Conception | Architecture validée | Choix techniques, sécurité, intégrations, contraintes non fonctionnelles | Début du développement |
| Construction | Premier incrément stable ou MVP prêt | Fonctionnalités cœur, dette technique acceptable, dépendances majeures maîtrisées | Accès aux tests d'intégration ou à la recette partielle |
| Tests | Sortie de phase de test | Anomalies bloquantes corrigées, non-régression validée, performance acceptable | Go/no-go vers la recette métier |
| Déploiement | Mise en production autorisée | Plan de rollback, supervision, support, communication prête | Passage en production |
| Exploitation | Transfert en run terminé | Documentation, formation, SLA, support et responsabilités clarifiés | Clôture projet et prise en charge par l'exploitation |
Dans un contexte réglementé, j'ajoute volontiers un jalon de conformité ou de sécurité avant la mise en production. Sur un produit plus orienté valeur métier, je concentre les décisions sur les releases et les risques d'exploitation. L'hypercare, c'est la période de surveillance renforcée juste après la mise en production; je la traite souvent comme un jalon à part entière parce qu'elle conditionne la clôture propre du projet.
Les jalons changent selon la méthode de delivery
Le bon réflexe n'est pas d'opposer agile et classique, mais de choisir le niveau de contrôle adapté au risque. J'utilise les mêmes principes de jalon, mais pas avec la même granularité selon que je suis en cascade, en agile ou dans un modèle hybride.
| Approche | Comment j'utilise les jalons | Ce qu'il faut éviter | Quand c'est pertinent |
|---|---|---|---|
| Cascade | Jalons en fin de phase avec validation formelle | Rigidité excessive et validation tardive des risques | Projets très dépendants, réglementés ou à forte visibilité budgétaire |
| Agile | Jalons liés aux releases, aux versions prêtes et aux seuils de risque | Confondre la sprint review avec un jalon de gouvernance | Produits dont le périmètre évolue et où la valeur se construit par incréments |
| Hybride | Stage-gates pour le pilotage, sprints pour la livraison | Dupliquer le reporting sans ajouter de décision utile | La plupart des projets IT en entreprise |
Une sprint review est un rituel de travail; un jalon de pilotage, c'est autre chose. En agile, je garde des points de contrôle, mais je les place plutôt sur les releases, la qualité, l'architecture ou le passage en exploitation. En d'autres termes, je ne supprime pas la gouvernance, je l'adosse à la livraison réelle. La Definition of Done, c'est le cadre qui dit qu'un incrément est vraiment terminé; elle évite précisément les faux terminés.
Comment rédiger un jalon qui tient la route
Un jalon mal formulé devient vite une source de débat. Je préfère une formulation courte, observable et reliée à une décision concrète. Si je ne peux pas prouver qu'il est atteint, ou si personne ne peut dire ce qu'on fait après, je considère que le jalon est mal défini.
| Formulation floue | Formulation exploitable | Pourquoi ça change tout |
|---|---|---|
| Architecture avancée | Architecture validée par l'équipe technique, la sécurité et le responsable produit | On sait qui décide et sur quelle base |
| Tests en bonne voie | Tests d'intégration terminés et anomalies bloquantes corrigées | Le critère devient vérifiable |
| Produit prêt | Recette métier signée et plan de déploiement approuvé | Le go/no-go devient clair |
- Je formule un état observable, pas une impression d'avancement.
- Je nomme le décideur, sinon le jalon reste théorique.
- Je définis une preuve simple: document signé, ticket fermé, test passé, validation enregistrée.
- Je relie le jalon à une conséquence claire: on continue, on corrige ou on replanifie.
Un jalon sans conséquence n'est qu'un label décoratif. Dans mes projets, je vérifie aussi que les critères de sortie sont compatibles avec la réalité de l'équipe: si le jalon exige dix validations pour une décision mineure, il ralentit plus qu'il ne sécurise.
Comment je pilote les jalons sans alourdir l'équipe
Le pilotage doit rester simple. Je préfère un tableau de bord qui tient sur une page, avec 5 champs lisibles: jalon, date cible, état, blocage principal et décision attendue. Au-delà de 7 indicateurs, on commence souvent à surveiller beaucoup sans mieux décider.Dans un projet dynamique, je cadence les revues toutes les 1 à 2 semaines. Pour un programme plus stable, une revue mensuelle peut suffire. L'essentiel est de ne pas laisser un jalon glisser sans arbitrage: un retard n'est pas seulement un décalage de date, c'est parfois un signal sur le périmètre, la qualité, la dépendance externe ou la conformité.
- Je clarifie le rôle de chacun avec un RACI, c'est-à-dire la matrice qui indique qui réalise, approuve, consulte et informe.
- Je garde un journal de décision pour éviter de rejouer les mêmes débats à chaque comité de pilotage.
- Je traite séparément les retards isolés et les retards structurels: un jalon qui glisse seul ne raconte pas la même chose qu'une série de glissements.
- Je rattache chaque point de contrôle à un risque précis, sinon il devient du reporting pour le reporting.
Le comité de pilotage ne doit pas vérifier l'activité au kilomètre. Son rôle est d'arbitrer le périmètre, le budget, les priorités et les exceptions. C'est là que les jalons deviennent utiles: ils donnent un support concret à la décision, pas une couche de formalité supplémentaire.
Les erreurs qui font dérailler le pilotage
Les mêmes pièges reviennent d'un projet à l'autre. Je les vois surtout quand l'organisation veut rassurer trop vite ou quand elle confond cadence de suivi et maîtrise du risque.
- Trop de jalons : le planning se fragmente, les revues se multiplient et plus personne ne sait lesquels comptent vraiment.
- Des jalons flous : si le nom du jalon ne décrit pas un état vérifiable, il devient difficile à défendre.
- Des jalons qui ne déclenchent rien : un point de passage sans décision ne sert qu'à produire du bruit.
- Une absence de propriétaire : si personne n'est responsable de la preuve et de l'arbitrage, le jalon reste orphelin.
- L'oubli de l'exploitation : beaucoup de projets s'arrêtent mentalement au go-live alors que le vrai risque commence parfois après.
- La dette technique ignorée : un jalon fonctionnel peut masquer un risque de performance, de sécurité ou de support.
- Le plan jamais mis à jour : dès que le périmètre change, les jalons doivent être recalibrés, sinon le planning devient fiction.
Je préfère supprimer un jalon inutile que garder un faux repère. Un projet logiciel bien piloté n'est pas un projet rempli de contrôles; c'est un projet où les contrôles sont rares, clairs et réellement utiles.
La grille simple que je garde pour fermer un plan de jalons
Avant de figer un plan de jalons, je me pose toujours trois questions. Si l'une d'elles reçoit une mauvaise réponse, je reformule le jalon ou je le retire.
- Ce jalon réduit-il un risque réel ou sert-il seulement à afficher de l'avancement ?
- Peut-on prouver objectivement qu'il est atteint ?
- La décision associée change-t-elle vraiment la suite du projet ?
Si la réponse est non à l'une de ces questions, je ne garde pas le jalon tel quel. C'est souvent cette sobriété qui permet de garder un projet logiciel lisible, de protéger l'énergie de l'équipe et de transformer le suivi en véritable outil de pilotage plutôt qu'en simple exercice de reporting.
