Quand la planification classique atteint ses limites
Les organisations qui utilisent HERMES pour piloter leurs projets disposent d’un cadre de gouvernance solide: quatre phases clairement délimitées (Initialisation, Concept, Réalisation, Introduction), des quality gates (points de contrôle formels où le mandataire valide la poursuite du projet) et un reporting standardisé. Ce cadre garantit la visibilité stratégique, mais il laisse une question ouverte: comment l’équipe organise-t-elle concrètement son travail entre deux jalons?
La réponse habituelle consiste à découper les phases en lots de tâches assignées individuellement, avec des échéances intermédiaires et un suivi par diagramme de Gantt. Cette approche fonctionne quand le périmètre est stable et parfaitement défini dès le départ. Dès que les exigences évoluent en cours de route ou arrivent de manière continue, le plan initial devient un obstacle plutôt qu’un guide.
Kanban, méthode de gestion visuelle du flux de travail héritée du système de production Toyota, propose une alternative concrète. Plutôt que de planifier l’ensemble du travail en amont, Kanban rend visible ce qui est en cours, limite la charge simultanée et optimise le débit de l’équipe.
HERMES comme conteneur, Kanban comme moteur
La clé de l’articulation entre les deux approches repose sur une distinction simple: HERMES opère au niveau de la gouvernance du projet, Kanban au niveau de l’exécution par l’équipe. Les deux niveaux n’interfèrent pas l’un avec l’autre.
HERMES définit les phases, les livrables attendus, les rôles de gouvernance (mandataire, chef de projet, comité de pilotage) et les moments de décision. Il répond à la question «quoi livrer et quand décider?». Kanban répond à la question «comment l’équipe traite-t-elle le travail au quotidien?».
Cette séparation n’est pas une improvisation: HERMES reconnaît officiellement que la méthode interne de l’équipe peut être agile, sans imposer un cadre spécifique. L’équipe peut adopter Kanban, Scrum ou SAFe à l’intérieur des phases HERMES. Le cadre de gouvernance fonctionne comme une «boîte noire» autour de l’exécution: il vérifie les résultats aux quality gates sans prescrire la manière dont ils sont produits.
Un tableau pour matérialiser le flux
Un tableau Kanban dans un projet HERMES se construit à partir du processus réel de l’équipe. Un exemple courant comprend sept colonnes: INBOX pour les nouvelles demandes, DESIGN pour l’analyse, READY FOR DEV pour les éléments spécifiés et prêts, IN PROGRESS pour le travail en cours, IN TESTING pour la vérification, REVIEW pour la validation finale et DONE pour les éléments terminés.
Chaque colonne porte une limite de WIP (Work In Progress, c’est-à-dire le nombre maximum d’éléments pouvant s’y trouver simultanément). Ces limites sont le mécanisme central de Kanban: elles empêchent l’équipe de se disperser sur trop de tâches à la fois et rendent immédiatement visibles les goulots d’étranglement.
Les éléments qui circulent sur ce tableau sont des user stories (descriptions d’exigences formulées du point de vue de l’utilisateur final). Ils proviennent du backlog tenu par le product owner et progressent de gauche à droite au fil de leur traitement.
Tirer le travail plutôt que le pousser
Le fonctionnement du tableau repose sur le principe pull (principe de tirage): un élément n’avance à l’étape suivante que lorsque quelqu’un y est disponible pour le prendre en charge. Personne ne pousse du travail vers une colonne déjà saturée.
En mode push classique, un chef de projet distribue les tâches selon un planning préétabli. Si trois éléments arrivent simultanément en test alors qu’un seul testeur est disponible, la file d’attente gonfle, les délais dérapent et la pression monte sans que le problème soit visible avant qu’il ne devienne critique.
En mode pull, la limite de WIP de la colonne IN TESTING empêche cette accumulation. Le testeur tire un nouvel élément quand il termine le précédent. Si la colonne amont (IN PROGRESS) est pleine et que personne en aval ne tire, l’équipe voit immédiatement le blocage et peut réagir: réaffecter des ressources, résoudre un problème technique ou remonter un obstacle au chef de projet.
Spécifier juste à temps
L’un des changements les plus significatifs qu’apporte Kanban dans un projet HERMES concerne le moment où les exigences sont détaillées. L’approche traditionnelle consiste à produire un cahier des charges exhaustif en phase de Concept, puis à le dérouler en Réalisation. Cette séquence génère deux problèmes récurrents: les spécifications détaillées trop tôt deviennent obsolètes, et l’effort de spécification initiale retarde le début du travail productif.
Avec Kanban, l’équipe pratique la spécification juste-à-temps (just-in-time specification): les exigences sont décrites grossièrement lorsqu’elles entrent dans le backlog, puis détaillées au moment où elles passent en colonne DESIGN, c’est-à-dire quand l’équipe s’apprête à les traiter. Ce flux peut démarrer dès la phase de Concept, ce qui permet à l’équipe de commencer à produire des résultats concrets avant que l’ensemble des exigences soit figé.
Cette approche ne signifie pas l’abandon de toute planification. Les quality gates HERMES restent en place: à la fin de chaque phase, le mandataire valide que les livrables attendus sont conformes. Le niveau de détail de la planification change, pas le niveau d’exigence de la gouvernance.
Ce que cela change concrètement
Les retours de terrain montrent plusieurs effets mesurables. Le délai entre l’entrée d’une exigence dans le flux et sa mise en production peut descendre à environ deux semaines, contre plusieurs mois dans un mode séquentiel classique. Le reporting bi-hebdomadaire devient naturel puisque le tableau Kanban fournit en permanence une image fidèle de l’avancement. Les parties prenantes constatent que leurs demandes sont prises en charge de manière visible et prévisible, ce qui renforce leur engagement dans le projet.
Pour le comité de pilotage, rien ne change: il continue de recevoir les rapports HERMES aux jalons prévus. Le chef de projet traduit les données du tableau Kanban en indicateurs de gouvernance (avancement, consommation budgétaire, risques) sans que le comité ait besoin de comprendre le fonctionnement interne de l’équipe.
Quand choisir Kanban dans un projet HERMES
Kanban n’est pas la seule option agile compatible avec HERMES. Scrum fonctionne également dans ce cadre, avec ses sprints à durée fixe et ses cérémonies régulières. Le choix entre les deux dépend de la nature du flux de travail.
Kanban convient mieux quand les exigences arrivent de manière continue sans regroupement naturel en itérations, quand les priorités changent fréquemment ou quand l’équipe gère simultanément du développement et de la maintenance. Scrum est plus adapté quand le projet bénéficie d’un rythme régulier et d’un product owner capable de prioriser un backlog stable pour chaque sprint.
Dans tous les cas, la règle est la même: HERMES fournit le conteneur de gouvernance, la méthode interne reste le choix de l’équipe. Les pratiques fondamentales de Kanban sont détaillées dans le Kanban Guide de Kanban University, et la documentation officielle HERMES décrit les modalités d’intégration agile dans le cadre de gouvernance.