Backlog : définition, traduction et utilisation (agile et supply chain)

Le mot backlog est un faux ami que l’on retrouve dans de nombreux contextes professionnels, et qui peut prêter à confusion. Selon que vous travaillez en gestion de projet agile ou en supply chain, il désigne deux réalités très différentes. Je vous propose dans ce guide de découvrir les deux acceptions principales du backlog, leurs différences, comment le gérer et le prioriser efficacement.

Backlog : définition et traduction

Littéralement, backlog se traduit en français par “arriéré” ou “en attente”. Mais selon le contexte, le mot prend deux sens très différents.

• En gestion de projet agile (méthode Scrum notamment), le backlog désigne la liste priorisée des fonctionnalités à développer sur un produit ou un service. On parle alors de Product Backlog.
• En supply chain et industrie, le backlog désigne le carnet de commandes en attente, c’est-à-dire les commandes clients qui n’ont pas encore été honorées. On parle aussi de commandes en arriéré.

Ces deux acceptions partagent une logique commune : il s’agit d’une liste de tâches ou de demandes en attente de traitement, qu’il faut prioriser et exécuter dans un ordre pertinent. Mais leurs enjeux, leurs outils et leurs profils utilisateurs sont totalement différents.

Le backlog en supply chain et industrie

Commençons par l’acception la plus pertinente pour le monde industriel.

Définition

En supply chain, le backlog correspond au stock de commandes clients non encore livrées. Il peut s’agir de commandes en cours de production, de commandes en attente de matière première, ou tout simplement de commandes accumulées que l’entreprise n’a pas la capacité d’honorer immédiatement.

Un backlog industriel peut être un bon signal (commercialement, ça veut dire que la demande est forte) comme un mauvais signal (opérationnellement, ça veut dire que les délais s’allongent et que le service client se dégrade). Le rôle de la supply chain est de piloter ce backlog pour qu’il reste dans une zone saine.

Comment se pilote un backlog supply chain ?

Le pilotage du backlog mobilise plusieurs métiers et outils. L’ordonnanceur et le planificateur de production sont en première ligne : ils décident dans quel ordre les commandes du backlog seront lancées en production, en fonction des priorités clients, des contraintes capacitaires et des matières disponibles. Le demand planner anticipe l’évolution du backlog en croisant prévisions et capacités.

Les outils mobilisés sont principalement l’ERP (qui contient le carnet de commandes), les APS (Advanced Planning and Scheduling type SAP IBP, Kinaxis, o9), les MES (Manufacturing Execution System) sur le terrain et de plus en plus des outils de demand sensing pilotés par IA.

Les bons indicateurs pour piloter le backlog

Pour suivre la santé d’un backlog supply chain, plusieurs KPI sont utiles :

• Backlog en volume (nombre d’unités) ou en valeur (montant en €)
• Backlog en équivalent jours de production (rapport entre le backlog et la capacité quotidienne)
• Âge du backlog (depuis combien de jours les commandes attendent)
• Taux de service client (OTIF, On Time In Full)
• Évolution du backlog dans le temps (tendance à la hausse ou à la baisse)

Un backlog qui gonfle de manière continue est un signal fort : soit la capacité doit être augmentée, soit la demande doit être contenue, soit les processus doivent être revus.

Le backlog en gestion de projet agile (Scrum)

C’est l’acception la plus connue en gestion de projet logiciel et produit.

Définition du Product Backlog

Dans la méthode agile Scrum, le Product Backlog est une liste évolutive et priorisée des fonctionnalités à développer sur un produit ou un service. Il sert d’outil central pour recueillir l’ensemble des besoins du client, les organiser et planifier leur réalisation au fil des sprints.

Le backlog peut contenir différents types d’éléments : des User Stories (description courte d’une fonctionnalité du point de vue de l’utilisateur), des Epics (grandes fonctionnalités qui se découpent en plusieurs User Stories), des Features, des bugs à corriger, des dettes techniques à résorber, etc.

Backlog vs cahier des charges : la différence

On confond souvent ces deux notions, pourtant elles sont très différentes.

Un cahier des charges est rédigé en début de projet, son périmètre est figé, et son budget porte sur un ensemble de fonctionnalités définies à l’avance. C’est typique d’une approche en cycle en V ou en mode forfaitaire.

Un backlog, à l’inverse, est créé au lancement puis évolue en continu. Son périmètre n’est pas figé et son budget porte sur un ensemble de ressources mobilisées sur une durée définie (le sprint). C’est typique d’une approche agile.

Qui gère le Product Backlog ?

Tous les éléments du Product Backlog sont accessibles à l’ensemble des acteurs du projet. Mais la responsabilité de prioriser le backlog et d’accepter ou refuser les éléments revient au Product Owner. C’est lui qui se renseigne auprès des parties prenantes, traduit leurs besoins en éléments de backlog et décide de l’ordre dans lequel ils seront traités.

L’équipe de développement (les développeurs et tech lead) intervient pour estimer la complexité de chaque élément (en story points), proposer des solutions techniques et alerter sur la dette technique. Le Scrum Master veille au bon fonctionnement de la démarche.

Comment définir un Product Backlog efficace ?

La création d’un bon backlog se prépare en amont du premier sprint. Plusieurs étapes structurent ce travail.

Tout d’abord, il faut définir clairement les objectifs du produit et la vision portée par le Product Owner. Cette vision doit être suffisamment précise pour guider les arbitrages, et suffisamment souple pour intégrer les apprentissages au fil des sprints.

Ensuite, il faut identifier les acteurs et les utilisateurs cibles. Le backlog ne se construit pas dans le vide : il doit refléter les besoins réels de personnes réelles.

Puis on liste les fonctionnalités attendues, en les classant par valeur. Une fonctionnalité de forte valeur est généralement peu coûteuse, rapide à implémenter et facile à adapter. Une fonctionnalité de faible valeur demande au contraire un développement complexe, long et coûteux. Le backlog priorisé fera apparaître en haut les fonctionnalités à forte valeur, et en bas celles à plus faible valeur.

Enfin, on affine progressivement les éléments : les fonctionnalités situées en haut du backlog (qui seront travaillées dans les prochains sprints) doivent être précises et estimées, tandis que celles du bas peuvent rester volontairement floues.

Comment gérer son Product Backlog ?

La gestion d’un backlog tient en quelques principes simples mais exigeants.

Le nettoyage régulier (backlog grooming ou refinement) est indispensable. Sans cet entretien, le backlog se transforme rapidement en cimetière à idées : des centaines d’éléments dorment sans jamais être traités, et l’équipe perd toute lisibilité. Un nettoyage régulier permet de conserver uniquement les fonctionnalités pertinentes, de découper les Epics en User Stories actionnables, et de réestimer celles qui ont vieilli.

Limiter le nombre d’éléments est une bonne pratique. Plutôt que d’empiler les idées dans le backlog, il vaut mieux maintenir une liste à part (parking lot) pour les idées non encore priorisées. Cela évite la surcharge cognitive et garde le backlog actionnable.

Tenir un calendrier précis de cérémonies (backlog grooming, sprint planning, sprint review) permet de concentrer les efforts sur ce qui compte. La cérémonie de backlog refinement, idéalement organisée une fois par sprint, sert à faire le point avec l’équipe et à préparer le sprint suivant.

S’appuyer sur un logiciel spécialisé apporte un vrai gain de productivité. Les outils les plus utilisés en 2026 sont Jira (le leader historique), Linear (très populaire dans les scale-ups tech), Asana, ClickUp, Monday ou Notion pour des contextes plus légers. Tous proposent des fonctionnalités d’estimation, de priorisation, de roadmap et de reporting.

Pourquoi prioriser un backlog ?

La priorisation est une étape clé pour plusieurs raisons.

Elle permet d’abord de mieux investir ses ressources. En développant en priorité les fonctionnalités à plus forte valeur, on maximise le ROI du projet tout en maîtrisant les délais et le budget.

Elle permet ensuite de livrer régulièrement de la valeur au client. C’est l’un des principes fondamentaux de l’agile : livrer souvent, par incréments. Un backlog bien priorisé garantit que chaque sprint apporte de la valeur visible.

Enfin, elle permet une bonne gestion des risques. Identifier ce qui est urgent ou critique évite les mauvaises surprises en fin de projet. Une excellente communication entre toutes les parties prenantes est ici un facteur clé de succès.

Plusieurs méthodes existent pour prioriser un backlog. Les deux plus utilisées sont MoSCoW et WSJF.

MoSCoW : une méthode agile éprouvée

Développée par le consultant Dai Clegg, MoSCoW est sans doute la méthode de priorisation la plus populaire en gestion de projet. Son principe : dépasser la simple notion d’importance pour aligner toutes les parties prenantes sur quatre niveaux de priorité. Les lettres M, S, C, W désignent ces quatre niveaux (les “o” minuscules de MoSCoW sont là pour la prononciation) :

• M – Must Have : les fonctionnalités indispensables sans lesquelles le produit n’est pas viable. Si elles manquent, le produit est un échec.
• S – Should Have : les fonctionnalités à forte valeur ajoutée mais qui ne sont pas vitales. Le produit peut être livré sans elles, même si ce serait dommage.
• C – Could Have : les fonctionnalités “de confort”, à réaliser si elles n’impactent pas les autres tâches et si le calendrier le permet.
• W – Won’t Have (this time) : les fonctionnalités non envisagées dans l’immédiat, mais qui pourraient être traitées plus tard.

C’est une méthode simple, rapide à mettre en œuvre, et qui fonctionne bien dans la majorité des contextes.

WSJF : une priorisation plus mathématique

WSJF (Weighted Shortest Job First), qu’on peut traduire par “le travail le plus court le plus rentable en premier”, est une méthode issue du framework SAFe (Scaled Agile Framework). Elle repose sur le concept de Cost of Delay (CoD), c’est-à-dire le coût du retard d’une fonctionnalité non livrée à temps.

Le WSJF se calcule selon la formule suivante :

WSJF = Cost of Delay / Job Size

Avec :

• Le Cost of Delay qui agrège trois composantes : la User-Business Value (valeur métier pour l’utilisateur), la Time Criticality (criticité temporelle de la fonctionnalité) et le Risk Reduction / Opportunity Enablement (réduction de risque ou ouverture d’opportunité).
• Le Job Size qui correspond à l’effort de travail estimé pour réaliser la fonctionnalité.

Plus la valeur du WSJF est élevée, plus l’élément est prioritaire. La logique est claire : on traite en premier ce qui a un fort coût de retard et qui demande peu d’effort. C’est une méthode très rationnelle, mais qui demande une vraie discipline dans l’estimation des composantes. Elle est particulièrement adaptée aux contextes SAFe et aux organisations qui scalent leurs pratiques agile.

D’autres méthodes utiles

Au-delà de MoSCoW et WSJF, plusieurs autres méthodes peuvent enrichir votre boîte à outils : la matrice valeur/effort (ou 2×2), le modèle Kano (pour distinguer les fonctionnalités basiques, attendues et enchanteresses), la RICE method (Reach, Impact, Confidence, Effort) très utilisée en product management. À chaque équipe de trouver la méthode la plus adaptée à son contexte.

IA et backlog : ce qui change en 2026

L’IA générative transforme la gestion du backlog en profondeur, aussi bien en agile qu’en supply chain.

En gestion de projet agile, les outils comme Jira, Linear ou ClickUp intègrent désormais des assistants IA qui aident à rédiger automatiquement des User Stories à partir de notes brutes, à estimer les efforts, à détecter les doublons et à proposer des arbitrages de priorisation. Le rôle du Product Owner se déplace : il ne rédige plus, il valide et arbitre.

En supply chain, l’IA permet de mieux anticiper l’évolution du backlog grâce au demand sensing, et d’optimiser automatiquement l’ordonnancement des commandes en fonction des contraintes capacitaires. Les outils APS de nouvelle génération (SAP IBP, Kinaxis, o9) intègrent ces capacités nativement.

Dans les deux cas, l’IA ne remplace pas les profils humains : elle les libère des tâches répétitives pour les concentrer sur l’arbitrage, le dialogue avec les parties prenantes et la conduite du changement.

Quels profils manipulent le backlog ?

En gestion de projet agile, ce sont principalement les Product Owners, Product Managers, Scrum Masters et Tech Leads qui manipulent le backlog au quotidien. Ce sont des profils très recherchés dans l’écosystème tech et digital.

En supply chain industrielle, le pilotage du backlog mobilise les ordonnanceurs, planificateurs de production, demand planners, supply chain managers et responsables ADV. Tous ces profils sont en tension sur le marché en 2026, avec des salaires qui montent de 5 à 9% par an. Pour aller plus loin, voir notre 👉 étude de rémunération dans la supply chain

Vous recrutez sur ces métiers ?

Le recrutement de profils supply chain capables de piloter un backlog (ordonnanceurs, planificateurs, supply chain managers) est l’un des plus tendus du marché en 2026.

Faites appel à un cabinet qui connaît vraiment les fourchettes du marché et les profils disponibles 👉 cabinet de recrutement spécialisé en supply chain

📞 Contactez Yann NABUSSET : 06 07 19 22 29 / yann@amalo.fr

Vous cherchez un poste en supply chain ?

Découvrez nos 👉 offres d’emploi en supply chain

Vous pouvez également nous envoyer une 👉 candidature spontanée

FAQ : Backlog

---

Article rédigé par Yann NABUSSET. Fondateur du cabinet de recrutement spécialisé AMALO.