Libellés de statut du flux de travail : 7 statuts clairs pour votre équipe

Pourquoi des statuts flous ralentissent le travail

Des libellés de statut vagues créent une confusion qui ressemble à du travail inutile. Les gens font avancer des éléments, mais personne n’est sûr de ce qui a réellement changé. Un ticket marqué « In Progress » peut vouloir dire « j’ai commencé à y penser », « je suis bloqué » ou « j’ai fini et j’attends la revue », selon la dernière personne qui l’a touché.

Ce décalage entraîne trois problèmes prévisibles : retouches, transferts manqués et notifications bruyantes. Si un statut n’indique pas ce que la personne suivante doit faire, le travail rebondit. Si un passage de relais est caché derrière un libellé vague, il reste en attente jusqu’à ce que quelqu’un le remarque. Si tout le monde met à jour les statuts juste pour « signaler » une activité, votre fil devient flou et les vrais changements sont faciles à rater.

Un autre symptôme courant est qu’un même libellé est utilisé différemment selon les écrans. Un coéquipier utilise « Ready » pour dire « prêt pour revue ». Un autre l’emploie pour « prêt à commencer ». Un responsable qui consulte le tableau ne sait plus si l’équipe attend, travaille ou a terminé.

L’objectif n’est pas de décrire chaque cas particulier. L’objectif est de rendre le chemin normal évident avec peu de statuts et des significations claires. Quand les statuts sont cohérents partout, vous obtenez des transferts plus rapides et moins de questions du type « est-ce que c’est vraiment fini ? »

Si votre équipe ne sait pas par où commencer, visez 5 à 7 statuts qui couvrent la majeure partie du travail : un pour les nouveaux éléments, un pour le travail actif, un pour le travail en attente ou bloqué, un pour la revue ou l’approbation, et un pour fini. Ajoutez des détails seulement après que l’essentiel est stable et que tout le monde utilise les mêmes significations.

Ce qu’un libellé de statut doit (et ne doit pas) signifier

Un libellé de statut est une promesse partagée sur ce qui se passe ensuite. Quand quelqu’un change un statut, tout le monde doit pouvoir prédire l’étape suivante sans poser de question de suivi.

Les bons libellés décrivent la réalité courante du travail, pas l’opinion de quelqu’un. Si le libellé est vrai, l’équipe peut dire si l’élément avance, attend ou est bloqué, et qui doit le reprendre.

Un statut n’est pas la même chose que la priorité, l’assignation, la catégorie ou des notes de progression. Ces champs peuvent importer, mais les mélanger au statut rend celui-ci peu fiable.

Il aide aussi de séparer « état » et « étape ». L’état est ce qui est vrai maintenant (par exemple « bloqué : réponse client »). L’étape est l’endroit du processus où se trouve l’élément (par exemple « review »). Vous pouvez les combiner, mais quand un seul statut essaie de décrire les deux, il devient souvent vague.

Un statut utile doit déclencher une de ces trois choses :

• Un prochain propriétaire (qui le prend)
• Une prochaine action (ce qui se passe ensuite)
• Une condition d’attente (ce que vous attendez)

Petit test : quelqu’un peut-il lire le libellé dans une vue liste réduite et savoir quoi faire ensuite ? Si la réponse est « ça dépend », le libellé cache probablement une décision qui devrait être prise ailleurs (règles de priorité ou assignation, par exemple).

Combien de statuts utiliser et pourquoi 5–7 fonctionne

Un système de statuts doit rendre le travail facile à lire d’un coup d’œil. Trop de statuts et les gens arrêtent de faire confiance à ce qu’ils voient. Trop peu et vous perdez le détail nécessaire pour gérer les transferts.

Pour la plupart des équipes, 5 à 7 statuts est le juste milieu. Cela tient sur un écran, marche bien sur un tableau Kanban ou une simple vue en liste, et donne suffisamment d’information pour répondre aux questions quotidiennes : qu’est‑ce qui est bloqué, qu’est‑ce qui est en cours, et qu’est‑ce qui attend une revue.

Garder l’ensemble restreint réduit aussi la « chasse au statut » (deviner lequel des 12 choix convient), facilite les rapports et vous force à garder priorité, propriétaire et type comme champs séparés.

Les noms peuvent varier, et c’est normal. Une équipe dira « In Progress », une autre dira « Doing ». Ce qui ne peut pas varier, c’est la signification. Si « In Review » signifie parfois « en attente de QA » et d’autres fois « en attente d’un client », votre tableau devient du bruit.

Pour maintenir des significations cohérentes, créez une source de vérité : un court doc d’équipe avec chaque statut, ce qu’il signifie et les règles d’entrée et de sortie. Gardez‑le assez court pour être lu en deux minutes. Puis utilisez ce même ensemble partout où le travail est affiché.

Un ensemble simple de 7 statuts pour débuter

Si vous voulez des libellés qui restent clairs dans le temps, commencez par un petit ensemble qui répond à trois questions : qui en est responsable maintenant, que se passe‑t‑il ensuite et à quoi ressemble le « fait ». Voici un ensemble simple de 7 statuts qui fonctionne pour la plupart des équipes sans trop de détails.

Règle clé : n’utilisez pas « Waiting » seul. Si quelque chose est bloqué, appelez‑le Blocked et nommez la dépendance dans la note (par exemple « Blocked: response client » ou « Blocked: accès accordé »).

Définitions pour chaque statut (avec règles d’entrée et de sortie)

Des libellés clairs fonctionnent mieux quand chacun répond à une question simple : qu’est‑ce qui est vrai maintenant ?

New

Ce qui est vrai : l’élément a été saisi, mais personne ne l’a encore évalué.

Ce qui n’est pas vrai : la priorité, la portée ou le propriétaire ne sont pas définis.

Entrée : une demande est soumise.

Sortie : quelqu’un la lit et la passe à Triaged.

Exemple : « Un agent support enregistre un rapport de bug avec une capture d’écran. »

Triaged

Ce qui est vrai : l’équipe comprend suffisamment la demande pour la router et confirmer qu’elle est valide.

Ce qui n’est pas vrai : elle est prête à commencer.

Entrée : quelqu’un ajoute le contexte de base (résumé, impact, zone affectée).

Sortie : elle est soit préparée pour le travail (Ready), soit rejetée intentionnellement (traitée en dehors du workflow, pas comme un statut).

Exemple : « Le PM la marque comme un vrai bug et note les étapes pour reproduire. »

Ready

Ce qui est vrai : on peut commencer sans information manquante.

Ce qui n’est pas vrai : le travail n’a pas commencé.

Entrée : les critères d’acceptation sont clairs et les dépendances en place.

Sortie : une personne commence le travail et réalise la première modification significative (In Progress).

Exemple : « Les champs du formulaire et les règles de validation sont convenus. »

In Progress

Ce qui est vrai : un travail actif est en cours.

Ce qui n’est pas vrai : il attend dans une file.

Entrée : quelqu’un le prend en charge et commence.

Sortie : il est assez avancé pour être vérifié (In Review) ou il rencontre une dépendance (Blocked).

Exemple : « Un développeur implémente le nouveau menu de statut et sauve la logique. »

In Review

Ce qui est vrai : l’élément est en cours de vérification (revue par un pair, QA ou approbation d’un stakeholder).

Ce qui n’est pas vrai : de nouvelles fonctionnalités sont encore ajoutées.

Entrée : l’exécutant le soumet pour vérification.

Sortie : il est approuvé et répond à la définition de fait de l’équipe (Done), ou il retourne avec des retours (In Progress).

Exemple : « QA confirme que cela fonctionne sur le web et le mobile. »

Blocked

Ce qui est vrai : le travail ne peut pas continuer à cause d’une dépendance précise et nommée.

Ce qui n’est pas vrai : l’élément est simplement de moindre priorité.

Entrée : l’assigné rencontre une dépendance qu’il ne peut pas résoudre seul.

Sortie : la dépendance est levée et le travail reprend (généralement In Progress).

Exemple : « Blocked: attente d’accès aux logs de production. »

Done

Ce qui est vrai : l’élément répond aux critères d’acceptation convenus et est livré ou prêt à être livré.

Ce qui n’est pas vrai : il nécessite encore revue, test ou suivi.

Entrée : la revue passe et les étapes de release sont complétées (selon la définition de votre équipe).

Sortie : aucune ; rouvrir lance un nouveau cycle avec une raison claire.

Exemple : « La correction est en production et le bug ne se reproduit plus. »

Étape par étape : créez votre système de statuts en 60 minutes

Vous pouvez réparer des statuts désordonnés en une réunion ciblée. L’objectif n’est pas un modèle parfait, mais un ensemble partagé d’étiquettes qui correspond à la façon dont le travail bouge réellement, avec des règles que l’équipe peut reproduire.

Une session de travail de 60 minutes (avec un résultat)

Faites venir une personne de chaque rôle qui touche le travail (demandeur, exécutant, relecteur, approbateur). Partagez l’écran avec votre tableau actuel ou votre liste.

D’abord, cartographiez le workflow réel (pas l’idéal). Choisissez un élément typique et suivez ce qui se passe réellement, y compris le temps d’attente. Écrivez les étapes comme des verbes simples (« rédiger », « relire », « approuver »). Si une étape arrive rarement, notez‑la comme une branche.

Ensuite, supprimez les doublons et renommez les libellés flous. Fusionnez les libellés qui veulent dire la même chose (« In Progress » vs « Doing »). Renommez les termes vagues (« Pending ») en quelque chose d’actionnable (« Blocked: réponse de Sam »). Si vous ne pouvez pas expliquer un libellé en une phrase, il n’est pas prêt.

Puis ajoutez des définitions avec règles d’entrée et de sortie. Pour chaque statut, écrivez ce qui doit être vrai pour y entrer et ce qui doit être vrai pour en sortir. Restez bref. Exemple : « In Review entre quand le travail est soumis, sort quand les retours sont traités et que le relecteur approuve. »

Après cela, choisissez des propriétaires pour chaque passage de relais. Chaque statut devrait avoir un propriétaire par défaut (un rôle suffit). Cela empêche les éléments de stagner. Exemple : les éléments en « In Review » sont la responsabilité du relecteur, pas de la personne qui a fait le travail.

Enfin, testez sur 10 éléments récents et ajustez. Prenez 10 éléments terminés ou actifs des dernières semaines et attribuez à chacun un statut à chaque point dans le temps. Si vous vous disputez souvent, vos libellés se chevauchent. Si vous ne pouvez pas placer un élément, il vous manque un statut ou vous mélangez deux idées en une.

Après la réunion, publiez les définitions en un seul endroit et faites correspondre les libellés partout où les gens les voient.

Garder les statuts cohérents entre les écrans web et mobile

Si un statut signifie une chose sur le web et quelque chose de légèrement différent sur mobile, les gens cessent d’y faire confiance. Ils commencent à demander dans le chat, à revérifier les détails ou à créer leur propre « vrai statut » dans les commentaires. Le but des libellés de statut est une vérité partagée, pas de la décoration.

Traitez le statut comme un champ partagé avec une source de vérité unique. Le même libellé doit apparaître avec la même orthographe, casse et signification partout : listes, écrans de détail, notifications, exports et push.

Règles petites-écrans qui fonctionnent vraiment

Les écrans mobiles pénalisent les noms longs et le faible design visuel. Un statut qui va pour un tableau de bureau peut devenir un badge tronqué et confus sur un téléphone.

• Gardez les noms courts (1–2 mots si possible).
• Utilisez des couleurs cohérentes, mais ne comptez jamais uniquement sur la couleur.
• Concevez en tenant compte du libellé le plus long afin que rien ne soit tronqué en fragments illisibles.
• Gardez l’ordre cohérent sur toutes les plateformes.
• Évitez des libellés « presque identiques » comme « In Progress » vs « Working ». Choisissez‑en un.

Le placement compte aussi. Placez le statut près du titre sur l’écran de détail pour qu’il soit vu avant la description complète. En vue liste, affichez‑le toujours au même endroit.

Les bases de l’accessibilité aident tout le monde. La couleur est un indice, pas le message. Affichez toujours le texte du libellé et envisagez une icône simple (comme une coche pour Done) afin que les personnes utilisant un lecteur d’écran ou ayant des troubles de la vision distinguent rapidement le sens.

Erreurs courantes qui font dériver les statuts

Les statuts dérivent quand ils cessent de signifier « où est le travail » et commencent à signifier « comment les gens se sentent à son sujet ». Dès que cela arrive, votre tableau semble animé, mais personne ne peut lui faire confiance.

Une cause courante est trop de libellés pour chaque petite étape. Si une tâche peut bouger trois fois en une heure, les gens arrêtent de la mettre à jour ou choisissent un statut « à peu près correct ». Un petit ensemble marche mieux quand chaque mouvement reflète un vrai changement de préparation ou de responsabilité.

Un autre point de dérive est le mélange de différentes dimensions dans un même champ. Priorité et urgence importent, mais elles appartiennent à des champs séparés, pas au statut. Si « Urgent » est un statut, il concurrencera « In Review » et vos rapports perdront de leur sens.

Surveillez ces schémas :

• Plusieurs libellés « presque finis » sans différence claire
• Libellés personnels ponctuels (« Waiting for Sam »)
• « In Progress » qui devient un parking lot
• Absence de règles d’entrée et de sortie écrites
• Nouveaux écrans montrant des noms ou un ordre différents

Pour prévenir la dérive, nommez un propriétaire pour l’ensemble des statuts et ne changez les libellés que rarement. Quand vous changez, écrivez ce qui a changé, pourquoi et ce que cela remplace.

Exemple : une demande du début à la fin

Un client écrit au support : « Sur mobile, la page historique de commandes affiche un état vide alors que j’ai des commandes. » Le support enregistre un élément qui deviendra une correction produit puis une release.

New : Le support capture des captures d’écran, les détails de l’appareil et ce que doit être l’état « correct ».

Triaged : Le propriétaire produit confirme que c’est un vrai bug, choisit où il appartient (app mobile, pas backend) et précise l’impact.

Ready : Les étapes pour reproduire sont confirmées et les critères d’acceptation sont clairs.

In Progress : Un ingénieur reproduit le problème, constate que l’API renvoie des données mais que l’écran les filtre mal, et commence la correction.

Blocked : L’ingénieur découvre que l’UI dépend d’un champ manquant sur d’anciens comptes et a besoin d’un changement backend. L’élément est marqué Blocked avec une note claire : « Blocked: backend needs legacy field mapping. »

In Review : Après résolution de la dépendance, QA vérifie iOS et Android et confirme que la page vide apparaît uniquement quand il n’y a réellement pas de commandes.

Done : La correction est approuvée et publiée (ou mise en file pour la prochaine fenêtre de release, si vous considérez cela comme done). Le support confirme en production et répond au client.

Remarquez ce qui évite la confusion : « Blocked » a une raison unique et une action suivante claire, et la responsabilité ne rebondit pas. N’importe qui ouvre l’élément et comprend qui a la balle.

Liste de contrôle rapide pour maintenir la cohérence de l’équipe

Si votre tableau semble désordonné, vous pouvez généralement en diagnostiquer la cause en 10 minutes.

Scan du tableau en 10 minutes

Parcourez le tableau et cherchez ces signaux :

• Chaque statut répond à : « Qu’est‑ce qui est vrai maintenant ? »
• Chaque statut a un propriétaire par défaut (un rôle suffit) et une action suivante claire
• Aucun statut n’a deux sens qui pourraient décrire le même élément en même temps
• Les éléments ne sont pas garés sans point de décision (s’ils peuvent rester des jours, ajoutez une règle de sortie)
• Les mêmes types de travail suivent les mêmes étapes de base, sauf exception écrite

Si les gens ne sont pas d’accord sur la place d’une carte, le statut chevauche un autre ou n’est pas assez défini.

Vérification web + mobile

Ouvrez le même workflow sur un téléphone et confirmez que les libellés tiennent dans les petits espaces.

• Les libellés sont courts et lisibles en vue liste (pas de troncature)
• Le texte est compréhensible sans dépendre de la couleur
• Les changements de statut sont validés par un propriétaire unique (lead d’équipe ou ops), pas décidés individuellement
• Les changements s’accompagnent d’une note brève pour éviter la dérive des définitions

Étapes suivantes : maintenir, mesurer et améliorer dans le temps

Les systèmes de statuts restent utiles quand vous les traitez comme un règlement : stables, mais révisés. L’objectif n’est pas de changer constamment, mais d’utiliser de manière cohérente.

Fixez une cadence légère, par exemple une revue mensuelle de 30 minutes avec une personne de chaque rôle impliqué. Apportez 5–10 éléments récents et cherchez les exceptions à corriger.

Quelques signaux simples à suivre :

• Temps passé en Blocked (et raison principale)
• Éléments qui rebondissent entre deux statuts
• Éléments restés inactifs au‑delà du délai normal

Quand quelque chose semble incorrect, résistez à l’idée d’ajouter tout de suite un nouveau statut. N’ajoutez un statut que si le nouvel état est vraiment différent, change ce que font les gens ensuite et se produit fréquemment. La plupart du temps, la solution est plus simple : resserrer la définition, ajouter une règle d’entrée ou clarifier la propriété.

Si vous intégrez le workflow dans un outil interne, traitez les statuts comme des données partagées plutôt que comme du texte spécifique à un écran. Dans AppMaster (appmaster.io), par exemple, vous pouvez définir le champ de statut une fois dans le Data Designer et le réutiliser sur les applications web et natives, ce qui aide à prévenir la dérive « ça veut dire autre chose sur mon téléphone ».