Tout gestionnaire en ingénierie l'a vécu : un projet techniquement actif — des tickets en cours, des commits qui s'accumulent — qui n'avance pourtant pas vraiment. Deux semaines plus tard, vous réalisez que moins a été accompli que prévu. L'équipe n'était pas inactive. Alors que s'est-il passé ?

En général : la dérive.

Ce qu'est vraiment la dérive

La dérive, ce n'est pas une équipe qui ne travaille pas. C'est une équipe qui travaille sans visibilité partagée et claire sur ce à quoi le progrès est censé ressembler maintenant — aujourd'hui, ou dans les deux ou trois prochains jours.

Dans les développements interdépendants, où le travail frontend dépend de contrats backend non finalisés, ou bien où deux flux doivent converger à un point d'intégration précis, la dérive est particulièrement coûteuse. Une dépendance qui n'est pas remontée avant le standup du vendredi aurait peut-être pu être débloquée le mardi — si quelqu'un avait su qu'il fallait poser la question.

Le problème du suivi uniquement hebdomadaire

Le suivi au niveau du sprint vous dit où vous en êtes à la fin de deux semaines. C'est trop tard pour intercepter le type de dérive qui se cumule en milieu de sprint.

Les rétrospectives vous disent ce qui a mal tourné une fois que c'est déjà terminé. Utiles pour apprendre, mais le projet a déjà payé le prix.

Ce dont vous avez besoin, c'est un mécanisme qui répond à une question de façon constante : avançons-nous vraiment en ce moment ?

Les jalons glissants sur 2 à 3 jours

La structure que nous utilisons est simple :

  • Au début de la semaine, définir des objectifs de jalons concrets pour chaque équipe ou flux de travail — à atteindre d'ici mercredi ou jeudi
  • Rendre les objectifs précis : pas « travail sur l'authentification » mais « flux OAuth complété et testé sur l'environnement de préproduction »
  • Rendre explicites les dépendances entre équipes : « le backend doit avoir l'endpoint utilisateur prêt avant que le frontend puisse continuer »
  • La communication quotidienne se concentre sur une seule chose : est-ce que les blocages émergent avant qu'ils ne dérivent ?

Ce n'est pas une nouvelle méthodologie. C'est l'application spécifique d'un principe simple : suivre le progrès à la granularité qui permet de détecter les problèmes avant qu'ils ne se cumulent.

À quoi ça ressemble en pratique

La planification du lundi établit la direction de la semaine et fixe les objectifs des 2 à 3 premiers jours. Les synchronisations quotidiennes — courtes, 10 à 15 minutes — répondent à trois questions : qu'avez-vous terminé, sur quoi travaillez-vous aujourd'hui, et qu'avez-vous besoin d'une autre équipe ?

Le jeudi est un point de contrôle des jalons : avons-nous atteint les objectifs de mi-semaine ? Si non, pourquoi — et qu'est-ce qui s'ajuste dans la deuxième moitié de la semaine ?

Le vendredi est la révision et l'examen des blocages : qu'est-ce qui est non résolu, qu'est-ce qui se reporte, et qu'est-ce que le prochain cycle doit prendre en compte ?

Rien de lourd. Aucune surcharge de processus. Juste assez de structure pour maintenir un modèle partagé et cohérent de l'état d'avancement.

Ce que nous avons observé

Quand les équipes ont une visibilité claire sur ce à quoi le progrès doit ressembler dans les deux à trois prochains jours, quelques choses se produisent naturellement :

  • Les dépendances sont remontées avant de bloquer le travail, et non après
  • Les blocages ne s'éternisent pas — il y a un moment quotidien pour les nommer
  • La communication s'améliore parce que les gens savent exactement ce dont ils ont besoin les uns des autres

Les projets ne livrent pas parce que les équipes travaillent plus dur. Ils livrent parce que le système donne à chacun une clarté constante sur ce à quoi avancer ressemble.

Parfois, vous attendez encore une clarification ou une dépendance externe. C'est la réalité. Mais au lieu que les choses dérivent, il y a toujours une prochaine étape claire et un chemin défini pour avancer.

C'est généralement la différence entre un projet qui dérive — et un qui livre.