Qu’est-ce qu’un backlog ? Le guide du fondateur non technique

Un backlog est la liste priorisée de tout ce qu’il reste à construire dans votre produit. Pourquoi il vous appartient, à vous et non à votre développeur, et comment le lire et le prioriser sans lire une seule ligne de code.

Camila a ouvert le Trello que l’agence avait partagé avec elle et a compté. Deux cent quarante cartes. Chacune avec une étiquette rouge marquée « important ». Elle a fait défiler l’écran une minute, refermé l’ordinateur et compris deux choses à la fois : elle n’avait aucune idée de ce qui sortirait le mois suivant et, pire, personne d’autre non plus. Pendant six mois, elle avait traité ce backlog comme une affaire de l’équipe technique. Ce backlog était, en réalité, son produit.

Un backlog est la liste priorisée de tout ce qu’il reste à construire dans un produit : nouvelles fonctionnalités, corrections, améliorations et ajustements, rangés dans l’ordre où ils doivent être faits. Dans le logiciel, c’est le registre unique du travail à venir. Tous ceux qui construisent votre produit y prennent la tâche suivante. Si le backlog est confus, le produit sort confus. C’est pourquoi il ne peut pas être un détail que vous déléguez et ne regardez plus jamais.

Ce qu’est un backlog, concrètement

Oubliez une seconde la définition du manuel Scrum. En pratique, le backlog est l’endroit où vit tout ce que vous avez promis de construire et pas encore construit. L’écran de connexion sociale demandé en réunion mardi. Le bug dont votre premier client s’est plaint. L’intégration du moyen de paiement qui bloque le lancement. L’idée venue sous la douche et envoyée au développeur à 23 h. Tout cela devient un élément du backlog, ou devrait le devenir.

Deux choses tournent souvent mal chez les fondateurs non techniques, et elles sont opposées. La première : vous traitez le backlog comme la liste de tâches privée du développeur, vous ne l’ouvrez jamais, et vous découvrez trop tard que ce qui était construit n’est pas ce que vous imaginiez. La deuxième : vous y déversez chaque idée qui vous passe par la tête, le board gonfle à deux cents éléments, et personne ne peut plus dire ce qui compte. Dans les deux cas, le résultat est le même. Vous avez perdu le contrôle de la chose la plus chère que votre entreprise produit.

Le backlog n’est pas une liste de tâches. C’est une file de décisions.

Voici le basculement qui sépare ceux qui se servent du backlog de ceux dont il se sert. Un élément de backlog n’est pas une tâche. C’est un pari. Chaque carte dit, implicitement : « ceci vaut plus la peine d’être construit maintenant que tout ce qui est en dessous ». Quand vous placez « notifications push » au-dessus de « exporter le rapport en PDF », vous n’avez pas rangé deux tâches. Vous avez décidé qu’un client attendra plus longtemps le rapport pour qu’un autre reçoive le push d’abord. C’est une décision d’affaires, pas une décision technique.

C’est pourquoi l’ordre compte plus que le contenu. Un backlog avec les bons éléments dans le mauvais ordre construit le mauvais produit, en plus lentement. Et ordonner est justement le travail qu’un fondateur peut faire sans savoir coder, parce que le critère de tri est la valeur pour l’entreprise, et de ça vous vous y connaissez mieux que n’importe quel développeur.

À qui appartient le backlog ?

La question qui revient le plus est « qui fait le backlog produit ». La réponse courte et inconfortable : vous. Il y a une différence entre qui maintient le backlog et qui en est propriétaire. Le développeur, le product manager ou l’agence maintiennent le board : ils écrivent les cartes avec le détail technique, estiment l’effort, découpent un gros élément en trois plus petits, ferment ce qui est livré. C’est le « comment ». Mais le propriétaire du backlog est celui qui décide la priorité, le « quoi » et le « pourquoi ». Dans une entreprise de dix personnes sans PM, ce propriétaire est le fondateur. Ça ne se sous-traite pas.

Dans le vocabulaire du Scrum Guide, ce rôle s’appelle Product Owner, et la règle est claire : une seule personne répond de l’ordre du backlog. Vous n’avez pas besoin d’adopter Scrum pour respecter le principe. Vous devez juste accepter que si cinq personnes peuvent réordonner la file, personne n’a rien décidé. Choisissez qui tient le stylo. Si vous n’avez pas de PM de confiance, le stylo est le vôtre.

À quoi ressemble un backlog sain : la forme d’entonnoir

Un bon backlog n’est pas une liste plate de deux cents éléments également détaillés. Il a une forme d’entonnoir.

En haut se trouvent les cinq ou dix éléments qui seront construits ensuite. Ceux-là sont coûteux à préparer et valent le coût : bien écrits, avec des critères d’acceptation clairs, prêts pour que quelqu’un les prenne et commence demain. Au milieu se trouvent les éléments du mois ou des deux mois à venir, esquissés mais pas figés. Et tout au fond se trouvent les idées éparses, une ligne chacune, certaines qui ne quitteront jamais le papier. C’est sain. Le fond du backlog est votre cimetière d’idées, et les idées bon marché à noter doivent être bon marché à jeter.

L’anti-modèle, c’est le board de Camila : deux cent quarante cartes, toutes au même niveau de détail, toutes « importantes ». Un backlog comme ça n’est pas un inventaire de travail. C’est un monument à l’indécision. La règle pratique : plus l’élément est haut, plus il doit être détaillé ; plus il est bas, plus il peut rester vague. Si vous rédigez une spécification minutieuse pour une chose qui ne sortira peut-être que dans huit mois, vous dépensez la ressource la plus rare de l’entreprise, l’attention de celui qui décide, au mauvais endroit.

Comment prioriser sans lire de code : le test du mois prochain

L’objection que tout fondateur non technique soulève : « comment je priorise si je ne sais pas ce que chaque chose coûte à construire ? ». Vous n’en avez pas besoin. Prioriser, c’est la division de deux colonnes : valeur pour l’entreprise et effort de construction. L’effort, vous le demandez. La valeur, vous la définissez.

Demandez au développeur une estimation grossière d’effort, en tailles de t-shirt : S, M ou L. Personne n’a besoin de fixer des heures. Vous apportez l’autre moitié, la valeur, et de ça vous vous y connaissez : combien de clients ça débloque, combien de revenu en dépend, ce qui est une promesse faite à un investisseur ou à un client-clé. Croisez les deux. Commencez par ce qui est à forte valeur et faible effort, laissez ce qui est à fort effort et faible valeur mourir au fond de l’entonnoir.

Quand la liste reste à égalité, appliquez le test du mois prochain : si une seule chose pouvait sortir le mois prochain, laquelle ? Répondez, mettez-la en haut, et répétez la question pour ce qui reste. C’est une question si simple qu’elle sonne bête, et c’est celle qui expose sur-le-champ quand « tout est prioritaire », qui est la même phrase que « rien n’est prioritaire ». Pour transformer cette file en une séquence que vous communiquez à l’équipe et aux associés, la roadmap produit est l’outil suivant ; et pour choisir entre des éléments de même taille, une méthode formelle de priorisation des fonctionnalités aide.

Les signes d’un backlog malade

Vous n’avez pas besoin d’être technique pour diagnostiquer un mauvais backlog. Les symptômes se voient à l’œil nu :

• Tout est P1. Si toute étiquette est rouge, vous n’avez pas priorisé, vous avez peint. Une file où tout est urgent n’est pas une file.
• Éléments fossilisés. Des cartes d’il y a six mois que personne n’ouvre ni ne supprime. Un backlog est vivant. Ce qui ne sera pas fait devrait être supprimé, pas gardé par politesse.
• Bug et fonctionnalité dans le même tas. Corriger ce qui a cassé et une idée nouvelle sont des décisions de nature différente et se disputent une attention différente. Les mélanger cache ce qui est de la dette de ce qui est de l’ambition.
• Vous ne trouvez pas où vit une promesse. Vous avez garanti à un client que l’export sort en mars et vous ne pouvez pas pointer la carte. Si la promesse n’est pas dans le backlog, elle n’existe pas pour celui qui construit.
• Le board grossit, le produit non. Deux cents éléments dedans, deux en ligne par mois. Le backlog est devenu un entrepôt, et un entrepôt n’est pas de la priorisation.

Un de ces signes est du bruit. Trois ou plus et vous n’avez pas un backlog, vous avez une liste de souhaits que personne ne gère.

Backlog, roadmap et périmètre : qui est qui

Trois mots que les fondateurs confondent, et qui font des travaux différents. Le backlog est la liste priorisée de tout ce qui reste, vivante et réordonnable à tout moment. La roadmap est la lecture de cette liste dans le temps, la séquence que vous montrez aux associés et aux clients. Et le périmètre est la frontière : ce qui entre et, plus important, ce qui reste hors d’un projet. Le backlog alimente la roadmap ; le périmètre définit d’où viennent les éléments qui entrent dans le backlog. Quand ces trois choses deviennent un seul tableur en désordre, c’est là que le projet commence à gonfler sans que personne n’ait décidé.

Le backlog est là où votre produit devient concret, élément par élément, décision par décision. Le traiter comme une affaire de l’équipe technique, c’est céder le volant de la chose la plus chère que vous construisez. Il est à vous. La bonne nouvelle, c’est que la partie difficile, décider ce qui compte, est justement celle qui n’exige pas de code.

Foire aux questions

Que signifie backlog ?

Backlog est un mot anglais qui veut dire « accumulation » ou « travail en attente ». Dans le développement logiciel et la gestion de produit, il est devenu le nom de la liste priorisée de tout ce qu'il reste à construire ou corriger dans un produit. C'est un terme utilisé sans traduction dans toute l'industrie tech.

Qui fait le backlog produit ?

Celui qui maintient le board au quotidien est en général le développeur, le product manager ou l'agence. Mais le propriétaire de la priorité, celui qui décide l'ordre, est une seule personne : le Product Owner. Dans les petites startups sans PM, ce rôle revient au fondateur. Maintenir est technique ; prioriser est une décision d'affaires, et ça ne se sous-traite pas.

Qu'est-ce qu'un product backlog ?

C'est le type de backlog le plus courant dans le logiciel : la liste officielle et vivante de tout ce dont un produit a besoin, des nouvelles fonctionnalités aux corrections. Il diffère du « sprint backlog », qui est la petite tranche du product backlog que l'équipe s'engage à faire dans un cycle court d'une ou deux semaines.

Qu'est-ce qu'un backlog d'entreprise ou de clients ?

Hors du logiciel, « backlog » apparaît dans d'autres contextes : en ventes, c'est le volume de commandes closes et pas encore livrées ; en finance, le revenu contracté et non reconnu ; en support, la file de tickets clients ouverts. La logique est la même partout : du travail déjà engagé qui n'a pas encore été accompli. Ce guide traite du backlog produit.

Comment créer un backlog de zéro ?

Rassemblez au même endroit tout ce qui a déjà été promis ou demandé : fonctionnalités, bugs, idées. Séparez les corrections des nouveautés. Pour chaque élément, définissez la valeur pour l'entreprise ; demandez à l'équipe une estimation grossière d'effort en S, M ou L. Ordonnez par valeur sur effort et appliquez le test du mois prochain pour départager. Ne détaillez bien que les éléments du haut. Des outils comme Trello, Jira ou Linear font l'affaire ; la discipline de prioriser compte plus que l'outil.

Un backlog et une roadmap sont-ils la même chose ?

Non. Le backlog est la liste priorisée et vivante de ce qui reste. La roadmap est la séquence de cette liste dans le temps, le document qui communique l'ordre et le moment approximatif des livraisons aux associés et aux clients. Le backlog alimente la roadmap ; il ne la remplace pas.