Lundi matin, 9h15. Trois chefs de projet me ping en même temps. Le client A veut son prototype pour jeudi. Le client B a 'juste une petite modification' (spoiler : c'est jamais petit). Le client C menace de ne pas signer la prochaine tranche si on ne lui livre pas la feature promise il y a six semaines. Et moi, j'ai un backlog de 74 tickets que personne n'a touché depuis le sprint planning de la semaine dernière. Ca, c'est la réalité de 90% des agences digitales que je croise. Pas la théorie Agile propre des conférences. La vraie vie.
Pourquoi votre backlog ressemble à une décharge
Le problème n'est pas le volume de travail. Le problème, c'est l'absence de critère de priorisation partagé. Chaque PM défend son projet, chaque client crie au feu, et le lead tech navigue à vue en fonction de ce qui saigne le plus. Résultat : les tâches à fort impact mais sans deadline criante s'accumulent en bas du backlog. Pour toujours.
J'ai audité une agence de 18 personnes à Bordeaux en 2024. Leur backlog Jira comptait 340 tickets ouverts. En filtrant par 'dernier commentaire > 60 jours', on en a trouvé 112 que personne ne regardait plus. Autant dire des zombies. Le CTO estimait à 4 ETP le coût de maintenance mentale de ce bazar. Quatre équivalents temps plein. Juste pour gérer l'anxiété de la liste.
Les méthodes qui marchent vraiment (et celles qu'on oublie vite)
MoSCoW : simple, mais mal utilisé
Must have, Should have, Could have, Won't have. Tout le monde connaît. Personne ne l'applique correctement. Le piège classique : les clients mettent tout en 'Must have' parce qu'ils ne comprennent pas que ça engage votre capacité de sprint. La correction : faire valider le MoSCoW avec un budget de points. Vous avez 40 points par sprint. Chaque Must have coûte des points. Le client arbitre lui-même quand le budget est épuisé. Franchement, ça change tout dans la dynamique.
RICE : le cadre que j'aurais voulu connaître plus tôt
RICE, c'est Reach x Impact x Confidence / Effort. Un score numérique par ticket. Ca paraît froid, mais ça tue les débats d'ego en réunion. Vous n'avez plus à convaincre le fondateur que sa feature 'géniale' est en fait un Could have. Le score parle. J'ai vu une équipe produit réduire son temps de sprint planning de 2h30 à 45 minutes en trois sprints après adoption du RICE. Le secret : remplir les scores en asynchrone sur Notion avant la réunion, pas pendant.
On a arrêté de se battre en réunion le jour où on a décidé que c'était le score RICE qui décidait, pas le titre de la personne qui parlait le plus fort. Notre burn rate a baissé de 22% en deux mois. -- Directeur de production, agence e-commerce, Lyon, 2025.
La capacité réelle : le chiffre que personne ne calcule
Voilà un angle mort massif. Les agences planifient sur une capacité théorique. 5 devs x 5 jours x 8h = 200 heures de sprint. En vrai ? Après les standups, la revue de code, les appels clients non planifiés, les bugs de prod qui tombent un mardi à 14h, vous êtes autour de 120 à 140 heures de travail productif. Soit 30 à 40% de perte sèche.
Calculer sa vélocité réelle sur 6 sprints glissants est non négociable. Clynt permet de croiser les heures timées par projet avec la capacité plannifiée, ce qui donne une lecture honnête de l'écart. Sans ce chiffre, vous surengagez à chaque sprint, vous livrez en retard, et vous perdez en crédibilité client. C'est mécanique.
Prioriser entre projets : le vrai défi des agences multi-clients
La priorisation intra-projet, c'est gérable. La priorisation inter-projets, c'est là que ça devient politique. Qui décide que le projet du client A passe avant celui du client B cette semaine ? Si la réponse est 'celui qui appelle le plus', vous avez un problème de gouvernance, pas un problème de méthode.
Une règle simple que j'ai vue fonctionner : pondérer par marge brute x risque de churn. Un projet à faible marge avec un client volatile descend mécaniquement dans la pile. Un projet à forte marge avec un client stratégique qui renouvelle chaque année monte. Ca fait grincer des dents au début. Mais ça aligne les décisions opérationnelles avec la stratégie réelle de l'agence.
- Calculer la marge brute par projet chaque semaine, pas chaque trimestre
- Attribuer un score de risque churn (1-5) à chaque compte client actif
- Multiplier les deux pour obtenir un indice de priorité inter-projets
- Réviser cet indice en comité de direction toutes les deux semaines, pas plus
Le backlog de l'agence vs le backlog client : ne pas mélanger
Erreur fréquente : tout mettre dans le même outil. Les tâches internes (refonte du template de devis, migration de Pennylane, formation Figma pour les juniors) et les tickets clients cohabitent dans le même Jira ou Linear. Ca crée une confusion permanente sur la priorité. Les tâches internes perdent toujours contre l'urgence client. Résultat : la dette interne explose.
La solution ? Deux backlog distincts avec un rituel dédié. Un comité interne mensuel de 30 minutes pour avancer les chantiers maison. Sans ce rituel sanctuarisé, votre agence continuera de tourner avec des process de 2019 parce que 'on a pas le temps'. J'ai suivi une agence parisienne qui a mis six mois à migrer son système de reporting client vers Clynt simplement parce que le projet interne se faisait systématiquement écraser par les urgences clients. Quand ils ont sanctuarisé deux demi-journées par mois, la migration a pris trois semaines.
Sprint planning : raccourcir sans sacrifier la qualité
Le sprint planning dure trop longtemps dans 80% des agences que je croise. Deux heures pour décider ce qu'on fait la semaine prochaine, c'est absurde. Si vous avez un backlog bien priorisé avec des scores RICE à jour et une vélocité historique connue, le sprint planning devrait prendre 30 à 45 minutes. Point.
Le temps restant peut aller à l'affinage (backlog refinement), qui est souvent bâclé ou absent. C'est pourtant là que se joue la qualité des estimations. Un ticket mal affiné en sprint planning, c'est deux jours de travail supplémentaires non prévus. Multipliez par douze tickets mal fichus et vous comprenez pourquoi votre sprint déborde systématiquement.
Le rituel des 15 minutes du vendredi
Chaque vendredi à 17h, le PM passe 15 minutes à nettoyer le backlog : archiver les tickets zombies, mettre à jour les scores, faire remonter les tickets affinés en haut de la pile. Pas une réunion. Pas un cérémonial. Juste un PM avec son café et son outil de gestion. Cette discipline hebdomadaire vaut mieux que n'importe quelle rétrospective mensuelle sur 'pourquoi notre backlog est mal tenu'.
FAQ
Quelle méthode de priorisation est la mieux adaptée à une petite agence de moins de 10 personnes ?
MoSCoW avec budget de points reste le plus accessible pour les petites structures. Il ne nécessite pas d'outil spécifique et peut s'appliquer dans un simple Notion ou tableur. L'essentiel est de fixer la règle du jeu avec le client dès le kick-off projet, pas en cours de route.
Comment convaincre un client que sa demande urgente n'est pas prioritaire ?
Montrez-lui le backlog priorisé avec les impacts business chiffrés. Un client rationnel comprend que sa feature 'urgente' qui touche 3 utilisateurs passe après une correction qui impacte 800 commandes par jour. Si votre contrat prévoit des SLA clairs sur les niveaux d'urgence, c'est encore plus simple : on applique le contrat, point.
Faut-il vraiment séparer le backlog produit du backlog opérationnel de l'agence ?
Oui, sans hésitation. Mélanger les deux crée une hiérarchie implicite où tout ce qui est client prime toujours sur l'interne. Vos tâches d'amélioration continue n'auront jamais de place si elles concourent directement contre les urgences clients. Deux espaces distincts, deux rituels distincts, deux horizons temporels distincts.
Comment suivre la vélocité réelle d'une équipe en agence multi-projets ?
Croisez les heures effectivement timées sur les tickets livrés avec la capacité planifiée sur six sprints glissants. Des outils comme Clynt permettent de visualiser cet écart par projet et par profil, ce qui permet d'ajuster les engagements futurs avec des données réelles plutôt que des intuitions. La vélocité par profil (dev junior vs senior, designer vs stratège) est souvent plus utile que la vélocité d'équipe agrégée.