Livrable : définition, exemples et différence avec le jalon

Un livrable est un résultat concret, vérifiable, produit par un projet et remis à quelqu’un : un client, un service interne, une direction. Le mot est partout dans la gestion de projet, mais il reste souvent flou dans les plannings : on y trouve des activités déguisées en livrables, des livrables sans critère d’acceptation, des jalons confondus avec ce qu’ils marquent. Ce guide donne la définition, des exemples par secteur, la différence entre livrable, jalon, objectif et tâche, et une méthode pour définir, rédiger, valider et suivre les livrables d’un projet.

Livrable : définition en gestion de projet

Par définition, un livrable (deliverable en anglais) est tout produit, service ou résultat mesurable qu’un projet doit fournir pour atteindre son objectif. Il est unique, identifiable, et il existe à la fin d’un travail : on peut le montrer, le tester, le lire, le compter. La remise du dernier livrable marque la fin du projet. Quatre caractéristiques le distinguent d’une simple activité :

• Il est tangible ou au moins vérifiable : un document, un logiciel, un bâtiment, une équipe formée, une décision documentée.
• Il a un destinataire : quelqu’un le reçoit, l’utilise ou le valide.
• Il est le résultat d’un travail, pas le travail lui-même : « rapport d’audit remis » est un livrable, « auditer » est une tâche.
• Il est soumis à des critères d’acceptation : on sait à l’avance ce qui permettra de le déclarer conforme.

Livrable interne ou externe, tangible ou intangible

On classe habituellement les livrables selon deux axes. Le premier est le destinataire. Les livrables externes sont ceux que reçoit le client ou le commanditaire : un produit, un rapport, un système migré. Ils sont souvent contractuels. Les livrables internes — spécification, plan de tests, script de migration, kit de formation — servent à produire les premiers ; ils restent dans l’équipe mais conditionnent tout le reste. Le second axe est la nature du résultat.

• Tangible : un objet ou un fichier que l’on peut remettre — maquette, prototype, ouvrage, application, dossier de conception.
• Intangible : un résultat réel mais non matériel — une équipe formée, un processus déployé, une certification obtenue, une décision arbitrée. On le rend vérifiable par une preuve : feuille d’émargement, attestation, procès-verbal.
• L’erreur classique consiste à ne suivre que les livrables externes et à découvrir, trois semaines avant l’échéance, qu’il manque un livrable interne dont personne n’était responsable.

Exemples de livrables par type de projet

Les livrables dépendent du secteur, mais la logique est la même partout : chaque phase du projet produit un résultat que quelqu’un attend. Voici des exemples courants.

Livrable, jalon, objectif ou tâche : quelle différence ?

Les quatre notions sont constamment confondues, et la confusion se voit dans le planning. Un livrable est une chose produite — un nom. Une tâche est le travail qui la produit — un verbe. Un jalon est une date qui marque un état et ne porte aucun travail en propre. Un objectif est le bénéfice attendu, que les livrables rendent possible sans le garantir. Un planning utile contient les quatre : le livrable dit ce qui est dû, les tâches disent comment il sera construit, le jalon dit quand il est attendu, l’objectif dit pourquoi.

Définir les livrables d’un projet à partir du WBS

Parce qu’ils sont des noms, les livrables constituent une bien meilleure base de découpage que les activités. La structure de découpage du projet (WBS) part de ce que le projet doit, puis décompose chaque élément jusqu’à pouvoir l’estimer. La méthode tient en six étapes.

1. Relire le périmètre : contrat, note de cadrage, cahier des charges. Chaque engagement écrit correspond à au moins un livrable externe.
2. Lister les livrables externes, puis, pour chacun, les livrables internes nécessaires pour le produire (études, spécifications, tests, formations).
3. Décomposer les livrables trop gros en lots de travaux jusqu’à obtenir des éléments estimables en charge et en durée. C’est le WBS proprement dit.
4. Vérifier la règle des 100 % : la somme des livrables et des lots de travaux doit couvrir tout le périmètre, ni plus ni moins.
5. Attribuer un responsable unique à chaque livrable et un validateur côté commanditaire.
6. Dater chaque livrable et le rattacher à un jalon du planning : c’est ce lien qui permettra ensuite de suivre l’avancement.

Rédiger une fiche livrable : le modèle à réutiliser

Un livrable bien défini tient sur une fiche d’une page. Elle sert de référence pendant toute la production et évite les discussions de fin de projet. Voici les rubriques minimales.

• Nom : court, au singulier, formulé comme un résultat (« Manuel utilisateur v1 », pas « Rédaction du manuel »).
• Description : ce que contient le livrable, ce qu’il ne contient pas, le format et le support (fichier, application, ouvrage, session).
• Critères d’acceptation : les conditions objectives qui permettent de le déclarer conforme — exhaustivité, tests passés, conformité à une norme, taux d’erreur maximal.
• Responsable : la personne qui répond de sa production, une seule.
• Validateur : la personne ou l’instance qui l’accepte, et le délai de validation.
• Date : échéance de remise et jalon associé.
• Dépendances : livrables ou décisions qui doivent exister avant, et ceux qui en dépendent.
• Version : brouillon, relu, définitif. Découper un gros livrable en versions successives vaut souvent mieux que de le découper en morceaux.

Valider un livrable : critères d’acceptation et recette

Un livrable sans critère d’acceptation est une source de conflit. Sans lui, « terminé » signifie livré pour le fournisseur et satisfaisant pour le client, et ces deux définitions coïncident rarement. La validation — la recette, dans les projets IT et industriels — suit toujours le même chemin.

• Les critères sont écrits avant la production, pas au moment de la remise, et acceptés par les deux parties.
• Le validateur est nommé : chef de projet côté client, référent métier, comité de pilotage pour les livrables structurants.
• La revue est bornée dans le temps : un délai de validation (souvent 5 à 10 jours ouvrés) au-delà duquel l’absence de réponse vaut acceptation, si le contrat le prévoit.
• Le résultat est tracé : procès-verbal de recette, réserves listées et datées, décision consignée.
• Un livrable refusé revient en production avec ses réserves ; il n’est pas « presque fini », il est en cours.

Suivre l’avancement d’un livrable

L’avancement d’un livrable ne se mesure pas au temps écoulé mais à son état. Un cycle de vie simple suffit, à condition de l’appliquer partout de la même façon.

• Non démarré : la fiche existe, les dépendances ne sont pas levées.
• En cours : la production a commencé ; l’avancement se lit sur les tâches qui le produisent, en charge consommée ou en pourcentage physique.
• Remis : le livrable est transmis au validateur, la période de revue commence.
• En recette : réserves en cours de traitement.
• Accepté ou refusé : décision tracée, avec date et signataire.

Sur un projet de taille moyenne, la liste des livrables avec leur état constitue souvent le meilleur tableau de bord pour le commanditaire : elle répond à « où en est-on ? » sans exposer le détail des tâches. C’est aussi la base du reporting en comité de pilotage.

Les erreurs fréquentes avec les livrables

• Le livrable flou : « site web » sans dire quelles pages, quelles langues, quel hébergement. Il sera livré incomplet ou sur-spécifié.
• Pas de critère d’acceptation : la validation devient une négociation.
• Confondre le livrable et l’activité : « réunions hebdomadaires » ou « accompagnement » ne sont pas des livrables ; le compte rendu ou le plan d’accompagnement en sont.
• Le livrable trop gros : impossible à relire d’une traite, il est accepté tard et mal. Si un relecteur compétent ne peut pas se forger un avis en moins de deux heures, découpez-le en versions.
• Aucun responsable, ou plusieurs : à deux responsables, personne ne répond.
• Oublier les livrables internes : la formation, la reprise des données, le plan de bascule apparaissent au dernier moment.
• Ne pas relier le livrable au planning : son échéance vit dans un fichier séparé et dérive sans que personne ne le voie.

Dans FoxPlan

Dans FoxPlan, les livrables sont portés par les tâches et les jalons du planning Gantt : chaque livrable a une date, un responsable et des dépendances visibles au même endroit que le calendrier. Les fichiers sont rattachés à la tâche, les exigences suivies dans leur module dédié, et l’avancement se lit sur la tâche qui produit le livrable. La validation se décide en séance du comité de pilotage, avec ordre du jour et décision consignée, ce qui fait de l’acceptation un fait tracé sur le projet plutôt qu’un courriel à retrouver.

Voir comment faire dans la documentation FoxPlan ↗

Questions fréquentes

Qu’est-ce qu’un livrable en gestion de projet ?

Un livrable est un résultat concret et vérifiable qu’un projet produit et remet à un destinataire : document, logiciel, ouvrage, équipe formée. Il se distingue d’une tâche, qui est le travail nécessaire pour le produire. Chaque livrable a un responsable, une date et des critères d’acceptation.

Quelle est la différence entre un jalon et un livrable ?

Le livrable est une chose produite, le jalon est une date qui marque un état du projet. Le jalon « recette signée » n’a ni durée ni travail propre ; il constate que le livrable « application recettée » a été accepté. Dans un planning, un jalon important est presque toujours associé à la remise ou à la validation d’un livrable.

Quels sont des exemples de livrables ?

Dans un projet informatique : cahier des charges, maquettes, application en production, documentation. Dans le bâtiment : permis de construire, plans d’exécution, ouvrage réceptionné. En marketing : charte graphique, campagne diffusée, rapport de performance. Un livrable peut aussi être immatériel, comme une équipe formée ou une certification obtenue.

Comment présenter un livrable ?

Présentez-le à partir de sa fiche : le nom, ce qu’il contient, les critères d’acceptation convenus et l’état de chacun, les réserves éventuelles. Montrez le résultat lui-même plutôt que le travail réalisé, et terminez par la décision attendue du validateur : accepter, accepter avec réserves ou refuser.

Qui valide un livrable ?

Le validateur est désigné dans la fiche livrable, avant la production : chef de projet côté commanditaire, référent métier ou comité de pilotage pour les livrables structurants. Il vérifie les critères d’acceptation et trace sa décision dans un procès-verbal de recette, avec les réserves éventuelles.

Un livrable peut-il être immatériel ?

Oui. Une formation dispensée, un processus déployé ou une certification obtenue sont des livrables intangibles. Pour rester vérifiables, ils s’accompagnent d’une preuve : feuille d’émargement, attestation, procédure publiée. Le critère d’acceptation porte alors sur cette preuve.

Pour aller plus loin avec FoxPlan

• Planification et diagramme de Gantt
• Les jalons d’un projet
• La structure de découpage du projet (WBS)
• Le comité de pilotage