Service privé et distinct du Registre National du Commerce et des sociétés tenues par les greffiers des tribunaux de commerce. Informations fournies par le Groupement d’intérêt économique des greffiers des tribunaux de commerce (G.I.E. INFOGREFFE)

Backlog

Mise à jour 06/10/2025 Gestion de projet

Backlog (Gestion de projet) : définition, rôle et bonnes pratiques

Définition synthétique

Le backlog est une liste structurée et priorisée d'éléments de travail nécessaires à la conception, l'évolution et la maintenance d'un produit ou d'un service. Utilisé principalement dans des contextes Agiles et en particulier dans Scrum, le backlog contient des besoins exprimés sous forme d'éléments variés - user stories, epics, tâches techniques, corrections de bugs et éléments de dette technique - et sert de source unique pour prioriser le travail à réaliser.

Rôle et responsabilités

Le backlog est l'outil principal du Product Owner pour traduire les attentes des parties prenantes en items exploitables par l'équipe de développement. Il joue plusieurs rôles opérationnels :

  • Conserver l'ensemble des besoins connus et des évolutions possibles;
  • Prioriser les éléments en fonction de la valeur métier, du risque, du coût et des dépendances;
  • Servir de base pour la planification des sprints et la préparation des releases;
  • Fournir une visibilité pour les parties prenantes et faciliter la communication entre métiers et technique.

Contenu typique d'un backlog

Un backlog contient des éléments hétérogènes :

  • Epics - grands ensembles fonctionnels à découper;
  • User stories - besoins utilisateur rédigés pour être estimés et implémentés;
  • Tâches techniques - travaux d'infrastructure, refactoring;
  • Bugs - anomalies identifiées et prioritaires à corriger;
  • Imprévus et demandes réglementaires - urgences à intégrer selon le contexte.

Différence avec le cahier des charges

Contrairement au cahier des charges, souvent figé et produit en début de projet, le backlog est un artefact évolutif. Les principales différences :

  • Périmètre : le cahier des charges fixe un périmètre initial ; le backlog évolue en continu;
  • Granularité : le cahier des charges peut être large et descriptif ; le backlog contient des éléments exploitables et estimables;
  • Cycle de vie : le cahier des charges est statique ; le backlog est itératif et est raffiné régulièrement;
  • Budget et pilotage : le cahier des charges sert de référence contractuelle ; le backlog sert au pilotage opérationnel et à l'adaptation.

Construction et entretien du backlog

Construire un backlog efficace implique plusieurs étapes et artefacts. Le Product Owner collecte les besoins, les traduit en user stories et les hiérarchise. Le processus inclut :

  • Identification des grandes fonctionnalités (features) puis découpage en epics et stories;
  • Estimation des stories (story points, t-shirt sizing) via des techniques comme planning poker;
  • Affinage régulier lors de sessions de refinement pour maintenir la qualité et la préparation des items;
  • Définition claire des critères d'acceptation et usage d'une Definition of Ready et d'une Definition of Done pour garantir la livrabilité.

Priorisation : méthodes et critères

La priorisation est au cœur de la valeur produit. Elle combine plusieurs critères :

  • Valeur métier et satisfaction client;
  • Coût et effort d'implémentation;
  • Risque technique et dépendances;
  • Contraintes réglementaires ou opportunités commerciales.

Techniques courantes de priorisation :

  • MoSCoW (Must, Should, Could, Won't) pour trier rapidement la criticité;
  • WSJF (Weighted Shortest Job First) pour optimiser le ratio valeur / délai;
  • RICE pour pondérer Reach, Impact, Confidence, Effort;
  • Analyse Kano pour distinguer fonctionnalités différenciantes et basiques.

Exemple pratique de priorisation

Considérons un backlog pour une application mobile de commandes :

  • Story A : correction d'un paiement bloquant - priorité haute (Must);
  • Story B : ajout d'une fonctionnalité de notation des produits - priorité moyenne (Should), forte valeur mais effort moyen;
  • Story C : refactoring du module de recherche - priorité basse (Could) si le reste est stable;
  • En appliquant WSJF, Story A a un coût de retard élevé et un faible effort relatif, elle est placée en tête.

Indicateurs et gestion opérationnelle

Pour piloter un backlog, on suit des métriques clés :

  • Velocity - nombre de story points livrés par sprint, utile pour planifier;
  • Lead time et cycle time - mesurent le délai entre création et livraison;
  • Taux de churn du backlog - proportion d'éléments ajoutés/supprimés, indicateur de stabilité;
  • Ratio bugs vs features - permet d'ajuster l'attention portée à la qualité.

Le maintien nécessite des sessions régulières de refinement (par exemple 5-10% du temps d'une équipe), des revues de priorités avant chaque planification de sprint et une archivage/tri des éléments obsolètes.

Cas pratiques et exemples concrets

  • Cas 1 - Startup : backlog court, items orientés MVP, priorisation par validation marché rapide. Fréquence de raffinement élevée pour intégrer retours utilisateurs.
  • Cas 2 - Produit mature : backlog long avec dette technique. Priorisation équilibrée entre nouvelles fonctionnalités, maintenance et réduction de dette.
  • Cas 3 - Projet réglementaire : éléments réglementaires remontés en urgence, priorisation réactive et création de swimlanes pour isoler ces items.

Bonnes pratiques et pièges à éviter

Bonnes pratiques :

  • Maintenir le backlog visible et accessible à toutes les parties prenantes;
  • Garder une hiérarchie claire (epics -> stories -> tâches);
  • Prioriser régulièrement en s'appuyant sur données et feedbacks réels;
  • Estimer et préparer les items avant de les planifier (Definition of Ready);
  • Mesurer l'impact des livrables pour ajuster la priorisation.

Pièges fréquents :

  • Transformer le backlog en simple dumping ground sans priorisation;
  • Confondre backlog produit et backlog sprint - le Sprint Backlog contient uniquement les éléments sélectionnés pour le sprint en cours;
  • Laisser le backlog vieillir sans nettoyage, ce qui réduit sa valeur décisionnelle;
  • Ne pas impliquer l'équipe technique dans l'estimation, menant à des engagements irréalistes.

Conclusion opérationnelle

Le backlog est un artefact vivant au cœur de la gestion Agile. Bien construit et entretenu, il permet d'aligner valeur métier et capacité de livraison, d'orienter les choix de priorisation et de rendre le pilotage du produit transparent. Sa valeur dépend autant de sa structure que de la discipline de son entretien : raffinement régulier, métriques adaptées et prise de décision basée sur la valeur permettent d'en faire un puissant levier stratégique.