En septembre, profitez de 2 mois offerts sur Djaboo avec le code : DJABOO26 → J'en profite
Jalons de projet : définir, vérifier et suivre 2026

Jalons de projet : définir, vérifier et suivre 2026

5/5 - (562 votes)

Vous avez posé des jalons sur votre planning, et pourtant le retard se découvre d’un coup, au dernier moment. C’est souvent parce que vos jalons ne sont pas des jalons : ce sont des dates.

Ce qu’un jalon sert à faire, et ce qu’il n’est pas

Un jalon sert à marquer un moment précis dans la vie d’un projet où l’équipe, le client ou la direction doit répondre à une question simple : est-ce que ce projet peut continuer sur la même trajectoire, ou faut-il corriger quelque chose avant d’aller plus loin ? C’est cette fonction de contrôle et de décision qui donne au jalon sa valeur. Sans elle, un jalon n’est qu’un point sur une ligne du temps, et personne ne s’y arrête vraiment.

On l’utilise pour trois raisons principales. D’abord, pour structurer le projet : au lieu d’une longue liste de tâches sans repère visible, les jalons découpent le travail en phases que tout le monde comprend d’un coup d’œil. Ensuite, pour déclencher des décisions : chaque jalon est l’occasion de confirmer que le projet avance dans la bonne direction, d’engager la prochaine dépense, de prévenir le client ou de corriger une dérive avant qu’elle devienne coûteuse. Enfin, pour communiquer : un jalon bien nommé donne à toutes les parties prenantes un langage commun pour parler de l’avancement du projet sans avoir à lire un planning complet.

Ce qu’un jalon n’est pas mérite d’être dit clairement, parce que la confusion entre ces notions est à l’origine d’une grande partie des problèmes de pilotage. Un jalon n’est pas une tâche : une tâche est un travail à réaliser, avec une durée et des ressources à mobiliser. Un jalon n’est pas un livrable : un livrable est un objet concret que l’on remet, un document, un prototype, un rapport finalisé. Un jalon n’est pas non plus une simple échéance : une échéance est une date dans un calendrier, sans aucune question ni décision associée. Si vous ne savez pas quelle question votre jalon pose, et qui doit y répondre, c’est une échéance, pas un jalon.

Pour que cette distinction soit utile dès le départ, la charte de projet est un bon outil : elle force à définir, avant même que le travail commence, ce qui sera considéré comme réussi à chaque étape, et à nommer les responsables de chaque validation. Poser ces questions en amont évite de les découvrir au pire moment, quand le retard est déjà là.

Le jalon est une décision, pas une date

C’est le cœur de tout ce que vous lisez ici. Un jalon n’est pas « le 15 juin ». Un jalon, c’est « le 15 juin, on décide si on passe à la phase suivante, si on corrige le périmètre, ou si on arrête le projet ». La date n’est qu’un rendez-vous. Ce qui compte, c’est ce qui se décide à ce rendez-vous.

Posez-vous cette question devant chaque jalon de votre planning : que décide-t-on ce jour-là ? Si la réponse est « on regarde où on en est », ce n’est pas un jalon, c’est une réunion de suivi. Si la réponse est « on valide les maquettes et le client peut commander la fabrication », vous avez un vrai jalon, avec une décision concrète, un responsable, et un impact financier. Si rien ne se décide au moment où on l’atteint, alors ce n’est pas un jalon : c’est une échéance de plus dans un calendrier déjà plein, et personne ne la regardera.

Les décisions que porte un jalon se regroupent en cinq types. Continuer sur la même trajectoire, ce qui signifie que les critères sont remplis et que la phase suivante peut démarrer. Corriger avant de continuer, ce qui signifie qu’une partie du travail est à revoir avant d’avancer. Arrêter le projet, ce qui est une décision rare mais parfaitement légitime quand les conditions initiales ont changé. Engager la prochaine dépense, ce qui concerne souvent les projets client où la facturation est liée à l’atteinte d’un jalon. Prévenir le client d’un écart, ce qui évite qu’il découvre un retard au dernier moment et doive adapter précipitamment ses propres plans.

Un projet de trois mois avec quinze jalons n’a en réalité aucun jalon : il a quinze dates. Si chaque semaine amène un nouveau jalon, personne ne prend le temps de vraiment s’arrêter, de réunir les bonnes personnes, et de prendre une décision réelle. Le projet avance en pilotage automatique jusqu’au moment où un retard majeur surgit, souvent trop tard pour être absorbé sans dommage sur le budget ou la livraison finale.

Pour formuler correctement la décision portée par un jalon, une formule simple fonctionne dans tous les contextes : « À ce jalon, on décide si [condition vérifiée] pour [action qui suit]. » Par exemple : « À ce jalon, on décide si les spécifications fonctionnelles sont validées par le client pour lancer le développement. » Ou encore : « À ce jalon, on décide si les tests de recette sont concluants pour programmer la mise en production. » Cette formule force à nommer la condition et l’action, ce qui suffit à distinguer un vrai jalon d’une date ordinaire ajoutée par habitude de planification.

Le critère de franchissement, ce qui rend un jalon vérifiable

Un jalon se vérifie, il ne se déclare pas. C’est la deuxième idée centrale de cet article, et elle change radicalement la façon dont vous devez construire votre plan de jalons. Écrire « phase 1 terminée » sur son planning ne veut rien dire, parce que celui qui a fait le travail est aussi celui qui juge qu’il est fini. Nous avons tous tendance à considérer notre travail comme terminé un peu avant qu’il ne le soit vraiment, surtout sous pression calendaire.

Un critère de franchissement est une condition, formulée avant que le jalon ne soit atteint, qui répond à une question binaire : oui ou non, le jalon est atteint ou il ne l’est pas. Il n’existe pas de « presque atteint » pour un jalon. Soit le critère est rempli, soit il ne l’est pas. Et ce critère doit pouvoir être contrôlé par quelqu’un d’autre que celui qui a produit le travail : un client, un responsable, un collègue d’une autre équipe ou d’une autre discipline.

Sans ce critère, le jalon est franchi par optimisme. L’équipe note « phase 1 OK » dans son suivi, continue vers la phase suivante, et le retard ne se voit pas. Il s’accumule en silence. Et il apparaît d’un coup au jalon suivant, quand il est trop tard pour corriger sans impact sur le budget ou la livraison finale. C’est ce qu’on appelle l’effet tunnel : le projet avance sans signal d’alarme, et le problème surgit au dernier moment, quand toutes les options simples ont disparu.

Voici un tableau de huit jalons formulés de façon vague, avec leur version vérifiable et le critère binaire qui manquait à l’origine.

Jalon mal formulé Problème Critère binaire manquant Version vérifiable
Phase 1 terminée Qui juge que c’est terminé, et sur quelle base ? Quels livrables précis, validés par qui ? Les trois livrables de phase 1 ont été signés par le responsable client
Avancement satisfaisant Subjectif, non mesurable, interprétable par chacun Quel niveau d’avancement est requis à cette date ? Toutes les tâches planifiées jusqu’à la semaine 4 sont marquées terminées dans le suivi partagé
Maquettes en cours de validation « En cours » n’est ni oui ni non La validation est-elle obtenue ou non ? Le client a retourné son bon pour accord écrit sur les trois gabarits principaux
Équipe prête pour le démarrage Prête selon qui, selon quels critères concrets ? Quelles conditions définissent « prête » de façon observable ? Les accès aux ressources nécessaires sont actifs et le rôle de chaque membre est confirmé par écrit
Budget globalement respecté « Globalement » autorise toutes les interprétations Quel seuil d’écart est acceptable pour continuer ? Les dépenses engagées sont inférieures ou égales au budget prévu à cette étape, sans dépassement constaté
Développement presque fini « Presque » n’est pas un critère opposable Quelles fonctions ou quelles tâches restent à compléter ? Toutes les fonctionnalités listées dans le périmètre initial sont livrées, testées et sans anomalie bloquante
Client informé Informé de quoi, comment, et a-t-il accusé réception ? Quelle réponse concrète attendait-on du client ? Le client a accusé réception du rapport d’avancement et confirmé la date du jalon suivant par écrit
Livraison effectuée Effectuée ne veut pas dire acceptée par le client Le client a-t-il accepté la livraison sans réserve ? Le procès-verbal de réception est signé par le client, sans réserve majeure en suspens

Rédiger un critère de franchissement demande une dizaine de minutes par jalon. Cette dizaine de minutes se rentabilise au centuple si elle évite un retard non détecté. La formule la plus simple est : « Ce jalon est atteint quand [personne ou entité] a [action concrète et vérifiable], confirmé par [trace écrite]. » Le sujet doit être une personne réelle, l’action doit être observable sans interprétation, et le résultat doit exister quelque part : un email, un formulaire signé, une ligne dans un compte rendu.

Distinguer le jalon, la tâche, le livrable et l’échéance

Ces quatre notions coexistent dans tout projet, et les confondre crée des plannings qui semblent rigoureux mais ne pilotent rien. Voici comment elles se distinguent dans la pratique, avec leur rôle exact et ce qui se passe quand chacune est atteinte.

Notion Ce que c’est Qui s’en occupe Ce qui se passe quand c’est atteint
Jalon Un point de contrôle lié à une décision. Durée nulle. Formule binaire : atteint ou non atteint. Il marque un passage, pas un travail. Un décideur externe à l’équipe qui a produit le travail : client, direction, responsable projet Une décision est prise et documentée : continuer, corriger ou arrêter. Le projet change d’état officiellement.
Tâche Un travail à réaliser, avec une durée, des ressources assignées et un responsable. Elle consomme du temps et de l’énergie. Un membre de l’équipe projet, identifié nommément dans le plan de travail La tâche est fermée dans le suivi. Elle contribue à l’atteinte d’un jalon ou à la production d’un livrable.
Livrable Un objet concret remis à une partie prenante : document, prototype, maquette, rapport, code source, formation. L’équipe projet, sous la supervision du chef de projet. Sa validation peut déclencher un jalon. Il est remis au destinataire. Il peut être accepté, refusé ou soumis à corrections. Son acceptation peut constituer le critère d’un jalon.
Échéance Une date dans le calendrier, sans condition associée ni décision liée. Elle peut être contractuelle ou informelle. Personne en particulier : c’est une contrainte calendaire, pas un acte de pilotage La date passe. Rien ne se décide automatiquement. Elle peut devenir un problème si aucune vérification n’est prévue à cette occasion.

Un exemple concret pour ancrer ces quatre distinctions. Vous pilotez la refonte du site vitrine d’un client. La rédaction des textes est une tâche, confiée à un rédacteur, avec une durée de deux semaines. Le document Word livré au client est un livrable. La date du 30 inscrite dans le contrat comme limite pour remettre les textes est une échéance. Le moment où le client confirme par écrit que les textes sont validés et que la phase graphique peut démarrer : voilà le jalon. Quatre notions, quatre rôles distincts, un seul exemple de projet ordinaire.

Savoir faire cette distinction change la façon dont vous construisez votre planning. Si vous glissez des jalons partout, y compris sur des tâches banales ou des livrables intermédiaires sans enjeu de décision, vous créez une structure qui donne l’illusion d’un suivi rigoureux mais qui génère en réalité du bruit et de la fatigue. Réservez les jalons aux moments où quelque chose se décide vraiment, et le planning retrouve sa lisibilité.

Combien de jalons poser, et où les placer

Il n’y a pas de nombre universel, mais il y a une logique simple. Un jalon utile se place là où une décision doit être prise avant de pouvoir continuer. Si le projet peut avancer sans qu’une décision soit prise à un moment donné, ce moment n’a pas besoin d’un jalon. C’est aussi direct que ça.

Pour un projet court, de un à trois mois, deux à quatre jalons sont suffisants pour piloter avec rigueur. Pour un projet de durée moyenne, de trois à douze mois, six à dix jalons permettent un pilotage serré sans alourdir le processus de validation. Au-delà d’un an, on distinguera les jalons majeurs, ceux qui portent une décision de direction ou une validation client, des jalons intermédiaires, qui servent de points de contrôle de l’équipe sans nécessairement impliquer le client à chaque fois.

Pour savoir où les placer, partez des points de passage obligés de votre projet. Où est-ce que le travail ne peut pas continuer sans une validation externe ? Où est-ce qu’une décision doit être prise avant d’engager une dépense significative ? Où est-ce que le client attend une confirmation avant de planifier ses propres actions en parallèle ? Ces moments sont vos jalons naturels. Pensez aussi à votre plan de charge : si une phase mobilise toute l’équipe pendant plusieurs semaines, il est judicieux de poser un jalon au début de cette phase pour s’assurer que les conditions de démarrage sont réunies avant que les ressources soient engagées.

Évitez de poser des jalons à intervalles réguliers, toutes les deux semaines par exemple, comme si la régularité suffisait à créer de la structure. Un jalon posé par habitude, sans question ni décision associée, est un jalon fantôme. Il est coché automatiquement, personne ne s’y arrête vraiment, et il n’apporte aucune information sur l’état réel du projet. Ce qui compte, c’est la pertinence du moment choisi, pas la régularité du calendrier.

Construire les jalons en partant de la fin

L’erreur courante est de construire son plan de jalons en partant du début : on pose un jalon de lancement, puis on ajoute des jalons au fil des phases, en essayant d’être complet. Le problème de cette approche est qu’elle produit des jalons qui correspondent à des habitudes de planification plutôt qu’à de vraies décisions. On se retrouve avec des jalons « fin de conception », « début de développement », « première version » qui jalonnent le projet sans y introduire de vraie logique de décision ou de critère de franchissement.

Une méthode plus efficace consiste à partir de la fin. Quelle est la condition finale qui marque la réussite du projet ? Formulez-la comme un critère vérifiable : « Le client a signé le procès-verbal de réception finale sans réserve. » C’est votre dernier jalon. Ensuite, remontez vers le présent en vous posant à chaque fois la même question : qu’est-ce qui doit être vrai juste avant ce jalon pour qu’il soit atteignable ? Cette approche, que certains appliquent sous forme de retroplanning, produit des jalons dont chacun est nécessaire à l’atteinte du suivant. Vous obtenez une chaîne de décisions cohérente, pas une liste de dates posées par intuition.

Cette méthode a un autre avantage décisif : elle fait apparaître les jalons manquants. Si vous remontez depuis la fin et que vous identifiez une décision critique qui n’a jamais été formalisée dans votre plan, c’est que vous avez un angle mort dans votre pilotage. Mieux vaut le découvrir à la planification qu’au moment où le client attendait une livraison et où l’équipe réalise qu’une validation essentielle n’a jamais eu lieu.

Le jalon de lancement, celui que tout le monde oublie

La réunion de lancement d’un projet est souvent traitée comme une formalité conviviale : on se retrouve, on présente les équipes, on parcourt le planning ensemble, et on démarre. Personne ne se demande si cette réunion constitue elle-même un jalon, avec ses propres critères de franchissement. C’est pourtant l’un des jalons les plus importants, parce que tout ce qui vient après repose sur ce qu’il valide.

Posez-vous la question : qu’est-ce qui doit être vrai pour que le projet puisse vraiment démarrer sur des bases solides ? Le contrat est signé. Le périmètre est acté par les deux parties, par écrit. Les accès nécessaires sont ouverts. Le budget est confirmé et disponible. La disponibilité des personnes clés est vérifiée sur les premières semaines. Si l’une de ces conditions n’est pas remplie au moment de la réunion de lancement, le projet démarre sur des bases fragiles, et vous le paierez plus tard, souvent au pire moment.

Formuler un critère de franchissement pour le jalon de lancement force à vérifier ces conditions avant de démarrer, plutôt que de les supposer acquises. C’est aussi le moment de s’assurer que tout le monde comprend de la même façon les objectifs, les livrables attendus, les jalons à venir et les règles de fonctionnement. Un projet qui commence sans cet alignement produit des surprises désagréables à mi-parcours, quand chaque partie réalise qu’elle avait une représentation différente du résultat final.

Le critère de franchissement du jalon de lancement peut ressembler à ceci : « Le contrat est signé, le périmètre du projet est acté par écrit par les deux parties, les accès aux outils et aux ressources nécessaires sont confirmés, et les responsables de chaque équipe ont été présentés et ont confirmé leur disponibilité pour les quatre premières semaines. » Si l’un de ces points manque, la réunion de lancement a bien eu lieu, mais le jalon de lancement n’est pas atteint. La différence est importante.

Qui constate le franchissement, et qui décide ensuite

Ces deux questions doivent avoir une réponse écrite pour chaque jalon, avant que ce jalon ne soit atteint. Si personne n’est désigné pour constater le franchissement, le jalon sera déclaré atteint par celui qui a intérêt à ce que le projet avance. Ce n’est pas de la mauvaise volonté, c’est une réaction humaine naturelle face à la pression calendaire. Mais le résultat est identique : un jalon franchi sans vérification réelle.

La personne qui constate le franchissement doit être différente de celle qui a produit le travail. Ce peut être le client, dans le cas d’une validation de livrable. Ce peut être le responsable de projet, dans le cas d’un jalon interne de fin de phase. Ce peut être un collègue d’une autre équipe, si le jalon porte sur la qualité d’un travail technique ou éditorial. L’essentiel est que cette personne soit désignée avant que le jalon ne soit atteint, et qu’elle soit informée de son rôle et des critères qu’elle doit vérifier.

La personne qui décide après le franchissement est parfois la même, parfois différente. Sur un jalon « continuer ou corriger » avant une dépense importante, c’est souvent le dirigeant ou le commanditaire du projet qui décide, sur la base du constat établi par le responsable de projet. Sur un jalon de validation de livrable, c’est le client qui décide si le travail correspond à ce qui était attendu. Sur un jalon interne de fin de phase, c’est le chef de projet qui décide si l’équipe peut engager la suite.

Documenter ce constat et cette décision est aussi important que de les prendre. Un compte rendu de réunion associé à chaque jalon important sert de référence contractuelle si une contestation survient plus tard. Il permet aussi de comprendre, une fois le projet terminé, pourquoi certaines décisions ont été prises à tel ou tel moment, et d’en tirer des enseignements pour les projets suivants.

Ce qui se passe quand un jalon n’est pas atteint

Un jalon non atteint n’est pas un échec en soi. C’est une information. Et une information obtenue au bon moment vaut beaucoup plus que la même information obtenue trop tard. Si votre plan de jalons fonctionne correctement, vous apprenez qu’un jalon n’est pas atteint avant d’avoir engagé les ressources et les dépenses de la phase suivante. C’est précisément pour cela que les jalons existent.

La première chose à faire est de ne pas déclarer le jalon atteint quand il ne l’est pas. Cette tentation est forte, surtout quand le retard est faible et qu’on veut éviter une conversation difficile avec le client ou la direction. Mais déclarer un jalon atteint alors que son critère de franchissement n’est pas rempli, c’est avancer en sachant que les fondations de la phase suivante sont instables. Le retard se retrouvera amplifié au jalon suivant, avec moins de marge pour l’absorber.

La deuxième chose est d’évaluer l’impact rapidement et honnêtement. De combien de temps le jalon est-il décalé ? Quelles sont les tâches qui dépendent de ce jalon ? Quel est l’impact sur les jalons suivants et sur la date de livraison finale ? Cette évaluation doit être faite dans les heures qui suivent la constatation du retard, pas dans les jours qui suivent. Chaque heure de délai dans l’évaluation est une heure de moins pour trouver une solution acceptable.

La troisième chose est de décider qui doit être informé, et comment. Le client doit savoir si le retard affecte un jalon visible pour lui et si sa propre organisation est impactée. La direction doit savoir si le budget est menacé ou si une décision de ressources est nécessaire. L’équipe doit savoir si ses priorités changent dans les prochains jours. Informer tôt, c’est se donner le temps de proposer des options. Informer tard, c’est se retrouver en gestion de crise sans marge de manœuvre.

Enfin, il faut réviser le plan de jalons pour tenir compte du décalage. Non pas en supprimant les jalons manqués comme s’ils n’avaient pas existé, mais en recalculant les dates des jalons suivants et en vérifiant que les critères de franchissement restent pertinents dans la nouvelle configuration. Un projet qui dérape légèrement sur le premier jalon peut récupérer si les ajustements sont faits immédiatement. Un projet qui dérape sur chaque jalon sans que personne ne révise le plan livre en retard une prestation que le client ne comprend plus.

Les jalons que le client voit, et ceux qui restent internes

Tous les jalons ne sont pas faits pour être partagés avec le client. Certains portent des décisions purement internes : est-ce que l’équipe est prête à démarrer la prochaine phase ? Est-ce que la qualité du travail produit jusqu’ici est suffisante pour avancer sereinement ? Est-ce que les charges ont été correctement estimées pour la suite ? Ces jalons sont utiles pour piloter le projet, mais les présenter au client ajouterait de la complexité sans lui apporter de valeur.

Les jalons visibles par le client sont ceux qui portent une décision qui le concerne directement : validation d’un livrable, confirmation d’une date de livraison, accord sur un changement de périmètre, réception finale. Ces jalons doivent être formulés avec une attention particulière, parce qu’ils constituent les points de référence contractuels du projet. Si le contrat prévoit un paiement à l’atteinte d’un jalon, ce jalon doit être rédigé avec la même précision que le contrat lui-même, sans ambiguïté sur ce qui doit être vrai pour le considérer atteint.

La séparation entre jalons clients et jalons internes protège aussi l’équipe. Si chaque décision interne est exposée au client, le projet devient difficile à conduire : le client intervient sur des sujets qui ne le concernent pas, et l’équipe perd du temps à expliquer des arbitrages techniques qui n’ont aucune incidence sur le résultat final. Réserver au client les jalons qui le concernent directement clarifie les rôles et évite les malentendus qui consomment de l’énergie sans produire de valeur.

Pour gérer l’organisation de l’équipe autour de ces moments clés, un bon planning d’équipe permet d’anticiper les pics de charge et de s’assurer que les bonnes personnes sont disponibles au bon moment, aussi bien pour les jalons internes que pour les jalons clients. Un jalon mal anticipé dans le planning d’équipe est souvent un jalon raté, non pas parce que le travail n’était pas de qualité, mais parce que personne n’était disponible pour le vérifier à temps.

Suivre les jalons sans ajouter une réunion

L’une des résistances les plus fréquentes au suivi rigoureux des jalons est la crainte d’alourdir le projet avec des réunions supplémentaires. Cette crainte est compréhensible, mais elle repose sur une confusion : suivre les jalons ne veut pas dire organiser une réunion pour chaque jalon. Cela veut dire s’assurer qu’à la date prévue, quelqu’un vérifie le critère de franchissement et prend une décision, quelle qu’en soit la forme.

Cette vérification peut se faire en cinq minutes, dans un message écrit, si le critère est bien formulé. « Le client a-t-il retourné son bon pour accord ? » est une question à laquelle on répond par oui ou par non, sans réunion. Si la réponse est non, on sait immédiatement qu’il faut relancer le client ou recalibrer le calendrier. Si la réponse est oui, on note la date, on la communique à l’équipe, et on enclenche la phase suivante. Deux minutes, une décision, une trace écrite.

Pour les jalons qui nécessitent une discussion plus longue, intégrez-les aux réunions existantes plutôt que d’en créer de nouvelles. Si vous avez déjà un point d’équipe hebdomadaire, ajoutez un moment fixe pour passer en revue les jalons des deux semaines à venir. Si vous utilisez un tableau kanban pour suivre vos tâches, les jalons peuvent y être représentés comme des marqueurs visuels qui signalent les points de passage à ne pas manquer, sans nécessiter une colonne ou un processus dédié.

L’essentiel est de ne pas laisser passer une date de jalon sans qu’une action consciente ait eu lieu. Pas forcément une réunion formelle, mais au minimum une vérification, une décision, et une trace. Sans ce minimum, le jalon est franchi ou non franchi dans l’indifférence générale, et son utilité disparaît complètement. Un jalon qui passe inaperçu est pire qu’un jalon absent : il occupe une place sur le planning sans rien apporter.

Les jalons d’un projet interne, sans client et sans facture

Un projet interne, qu’il s’agisse d’une refonte des processus, d’une migration d’outils, du lancement d’une nouvelle offre ou de la mise en place d’un nouveau mode de fonctionnement, n’a pas de client pour poser des questions au bon moment. Il n’y a pas de contrat qui prévoit des paiements à l’atteinte de jalons. Et il n’y a pas toujours non plus de chef de projet clairement désigné avec un mandat précis. Pour toutes ces raisons, les projets internes sont particulièrement exposés à la dérive silencieuse.

C’est précisément là que les jalons sont les plus précieux. Sans la pression naturelle du client, c’est la structure du plan de jalons qui crée la discipline. Un jalon interne bien formulé force l’équipe à se demander, à une date précise, si l’avancement est réel ou seulement supposé. Il force aussi à désigner quelqu’un qui prend la décision de continuer ou de corriger, ce qui évite les situations où tout le monde se croit en avance jusqu’au moment où personne ne l’est plus.

Pour les projets internes menés dans un contexte itératif, les jalons peuvent s’articuler avec les cycles de travail. Chaque fin de période peut porter un jalon concret : non pas « la période est terminée », mais « les fonctionnalités ou les livrables prévus pour cette période sont opérationnels et validés par le commanditaire interne ». Pour aller plus loin sur cette articulation entre jalons et cycles courts, l’article sur la gestion de projet agile développe comment structurer des itérations sans perdre le fil de l’avancement global du projet.

Sur un projet interne, la décision portée par un jalon peut aussi concerner la priorité elle-même : ce projet mérite-t-il toujours l’attention et les ressources de l’équipe, compte tenu de ce qui s’est passé ce mois-ci dans l’activité ? Un jalon est le bon moment pour poser cette question ouvertement et pour en assumer la réponse, même si elle implique de suspendre temporairement le projet pour faire face à une urgence commerciale ou opérationnelle.

Un plan de jalons complet pour un projet de trois mois

Voici un exemple concret de plan de jalons pour un projet type de trois mois : la création et le lancement d’un site web pour un client. Ce plan illustre comment articuler des jalons porteurs de décisions réelles, avec des critères vérifiables, sur une durée courte sans créer de jalons superflus.

Jalon Semaine Critère de franchissement Décision prise à ce moment Visible par le client
Lancement du projet Semaine 1 Contrat signé, périmètre acté par écrit par les deux parties, accès ouverts, équipe présentée et disponibilité confirmée pour les quatre premières semaines Le projet démarre officiellement. Les ressources humaines et budgétaires sont engagées. Oui
Validation des maquettes graphiques Semaine 4 Le client a retourné son bon pour accord écrit sur les maquettes des trois gabarits principaux, sans demande de modification structurelle Le développement front-end peut démarrer. Aucune modification de maquette ne sera acceptée sans avenant après ce jalon. Oui
Recette interne Semaine 9 Toutes les pages listées dans le périmètre initial sont développées et vérifiées par un testeur interne distinct du développeur, sans anomalie bloquante en suspens Le site est présenté au client pour recette. Le développement est considéré terminé côté équipe. Non
Recette client Semaine 10 Le client a transmis sa liste de corrections dans les cinq jours ouvrés. Aucune demande ne remet en cause le périmètre initial acté au lancement. Les corrections sont engagées. Si le périmètre est remis en question, un avenant est signé avant toute action. Oui
Corrections validées Semaine 11 Le client confirme par écrit que les corrections apportées sont conformes à sa liste de retours, et qu’aucune nouvelle demande n’est formulée Le site peut être mis en ligne. La facturation du solde peut être déclenchée contractuellement. Oui
Livraison finale Semaine 12 Le procès-verbal de réception est signé par le client sans réserve. Les accès définitifs au site lui ont été remis et confirmés fonctionnels. Le projet est clos. La garantie contractuelle commence. La facture finale est émise sans délai. Oui

Ce plan de six jalons pour douze semaines de travail est suffisant pour piloter un projet de cette taille avec rigueur. Chaque jalon porte une décision concrète. Chaque critère est formulé de façon binaire, sans marge d’interprétation. Le jalon de recette interne, en semaine 9, n’est pas partagé avec le client mais joue le rôle d’un filet de sécurité avant la présentation : il évite de découvrir les anomalies en même temps que le client.

Les erreurs qui reviennent et comment chacune se corrige

Certaines erreurs reviennent sur presque tous les projets, qu’ils soient pilotés par des équipes expérimentées ou par des dirigeants qui mènent leur premier projet client. Les identifier permet de les anticiper et de corriger le plan avant que le problème ne surgisse.

Erreur Ce qui se passe concrètement Comment la corriger avant qu’elle coûte
Trop de jalons posés sur le planning Un jalon par semaine. Personne ne s’y arrête vraiment. Ils sont cochés automatiquement sans vérification réelle. Le pilotage devient une formalité administrative. Réduire à 2 à 6 jalons pour un projet de trois mois. Réserver les jalons aux seuls moments où une vraie décision doit être prise.
Jalons sans critère de franchissement écrit Les jalons sont déclarés atteints par l’équipe qui a produit le travail, sans vérification externe. Le retard s’accumule en silence et surgit d’un coup au jalon suivant. Rédiger un critère binaire pour chaque jalon avant que le projet démarre. Le mettre par écrit dans le plan de projet, accessible à tous.
Aucune personne désignée pour constater le franchissement Quand la date arrive, personne ne sait qui doit vérifier. Le jalon passe sans action consciente, ni dans un sens ni dans l’autre. Pour chaque jalon, nommer une personne responsable de la vérification, différente de celle qui a produit le travail, avant le début du projet.
Jalon déclaré atteint par optimisme Le critère n’est pas complètement rempli, mais l’équipe avance pour ne pas retarder le projet. Le problème resurface au jalon suivant, amplifié. Appliquer le critère à la lettre, sans exception. Si le jalon n’est pas atteint, le dire immédiatement et recalibrer le calendrier dans les 24 heures.
Retard dissimulé au client pour éviter une conversation difficile L’équipe connaît le retard mais attend d’avoir une solution avant d’informer le client. Ce dernier découvre le retard trop tard pour adapter ses propres plans. Informer le client dès que le retard est connu, même sans solution complète. Proposer une date de mise à jour dans les 48 heures suivantes.
Jalons construits de la gauche vers la droite du planning Les jalons sont posés au fil des phases sans logique de fin. Des jalons inutiles s’accumulent en début de projet, et des jalons critiques manquent en fin de parcours. Construire le plan de jalons en partant du dernier jalon et en remontant vers le début. Chaque jalon doit être nécessaire à l’atteinte du suivant.
Confondre décaler la date du jalon et résoudre le problème On repousse la date du jalon en pensant avoir géré le retard. Mais si les critères ne sont pas remplis, changer la date ne résout rien au fond. Distinguer clairement « la date est décalée » de « le jalon n’est pas atteint ». Traiter les deux séparément : la date est une conséquence, le critère est le vrai sujet.

Ces sept erreurs partagent une même racine : un jalon traité comme une date plutôt que comme une décision. Corriger la définition de vos jalons, en leur associant systématiquement un critère, un responsable et une décision attendue, corrige presque toutes ces erreurs d’un coup, sans changer d’outil ni de méthode.

Djaboo et la gestion des jalons de projet

Djaboo est un logiciel de gestion tout-en-un conçu pour les TPE et PME. Il permet de gérer les projets, les clients, la facturation et les équipes depuis un seul espace de travail, sans compétence technique requise. Dans Djaboo, les jalons font partie intégrante du module projet.

Concrètement, un jalon appartient à un projet. Il porte un nom, une description, une date de début et une date d’échéance, un ordre d’affichage et une couleur. Les tâches du projet se rattachent à un jalon, ce qui permet de regrouper le travail par point de passage plutôt que par simple liste chronologique. Cette organisation donne une visibilité immédiate sur ce qui doit être accompli avant chaque jalon, aussi bien pour l’équipe que pour le dirigeant qui surveille l’avancement global.

Deux réglages distincts commandent ce que le client voit dans son espace dédié : l’un rend la description du jalon visible par le client, l’autre masque complètement le jalon de l’espace client. Cela permet de distinguer facilement les jalons internes de ceux que vous souhaitez partager avec votre client, sans avoir à gérer deux plannings séparés ou deux outils différents.

Voici ce que Djaboo ne fait pas encore, pour que vous puissiez vous organiser en pleine connaissance de cause. Un jalon n’a pas de statut dans Djaboo : il n’est ni ouvert ni franchi, et l’outil ne calcule aucun pourcentage d’avancement du jalon lui-même. Il n’existe pas de champ dédié au critère de franchissement : ce champ n’est pas prévu dans l’interface. Aucune dépendance n’existe entre deux jalons : rien n’empêche de travailler sur le jalon suivant si le précédent n’est pas atteint, rien ne se bloque et rien ne prévient automatiquement.

Ces limites ne rendent pas l’outil inutilisable pour un pilotage rigoureux, à condition d’adapter votre organisation. Le critère de franchissement s’écrit dans la description du jalon, puisque c’est le seul endroit disponible pour ce texte. Il devient alors visible par votre client si vous activez cette option, ce qui a l’avantage de rendre votre critère de validation partagé et consultable à tout moment. L’état d’avancement se lit en regardant les tâches rattachées au jalon plutôt qu’un pourcentage : si toutes les tâches liées à ce jalon sont terminées, le jalon est atteignable, et vous pouvez procéder à la vérification du critère. Le passage en revue des jalons se programme comme un rendez-vous fixe dans votre agenda : sans cette programmation, rien ne signalera qu’une date est passée sans décision prise.

Un jalon n’est pas une date inscrite sur un planning : c’est une décision attendue à un moment précis, formulée à l’avance, portée par une personne désignée, et vérifiable par quelqu’un d’autre que celui qui a produit le travail. Sans ces trois composantes, un jalon est une échéance parmi d’autres, et le retard ne se verra pas avant qu’il soit trop tard pour agir.

Formuler le critère de franchissement avant de démarrer le projet, construire vos jalons depuis la fin plutôt que depuis le début, et séparer clairement les jalons visibles par le client de ceux qui restent internes : ces trois habitudes transforment un planning ordinaire en véritable outil de pilotage. Les retards existent dans tous les projets. Ce qui change avec des jalons bien posés, c’est que vous les voyez assez tôt pour avoir le choix de votre réponse.

5/5 - (562 votes)