Votre équipe de développement ralentit : regardez ce qu’elle attend

Un ticket est commencé et terminé un mardi. La revue a lieu le jeudi : le relecteur était pris. L’équipe déploie le mardi, donc la modification part en production le mardi suivant. Une journée de travail, une semaine de délai. Doublez la vitesse de vos développeurs : vous gagnez une demi-journée, et la modification part toujours le mardi suivant.

L’exemple est fictif, le mécanisme ne l’est pas. Quand je cherche pourquoi une équipe ralentit, je commence par regarder ce qu’elle attend. Dans ce cas, tout se joue là : une revue, une validation, un créneau de mise en production, la disponibilité de la seule personne qui connaît ce module. Et le réflexe le plus répandu face à ce ralentissement, recruter, nourrit l’attente.

Je comprends le réflexe. Le retard d’une fonctionnalité est visible ; l’attente qui l’a produit ne l’est pas. Un dirigeant voit une équipe de six qui livre comme une équipe de trois, et la seule action qu’il peut prendre seul, sans entrer dans le code, c’est ajouter une personne.

Regardez maintenant ce que fait un nouvel arrivant pendant ses premiers mois. Il pose ses questions aux personnes que tout le monde sollicite déjà. Il produit du code que devra relire le relecteur déjà en retard. Il attend le même créneau de déploiement. Vous avez ajouté du travail au goulot sans l’élargir. Si le poste ne soulage pas ce goulot, l’intégration ne suffira pas à augmenter le débit de livraison. Si vous devez recruter malgré tout, faites-le par petites vagues, en préparant l’intégration.

Le ralentissement est dans tout ce qui entoure le ticket : la revue, la correction après un déploiement raté, les interruptions subies par l’expert, les réunions qui hachent la journée. Rien de cela n’apparaît dans une estimation. Tout apparaît dans la date de livraison.

Prenez quelques semaines, un périmètre stable, des tickets livrés normalement autant que des tickets en retard. Et séparez le temps travaillé du temps écoulé : un ticket ouvert dix jours, c’est rarement dix jours de développement. C’est un jour de développement et neuf jours d’attente.

Symptôme	Où regarder	Ce que je soupçonne
Code terminé, livraison tardive	Dates de revue, de validation, de déploiement des mêmes tickets	File d’attente en revue ou créneau de livraison rare
Tickets rouverts après livraison	Motifs de réouverture, incidents liés	Critères flous, parcours critiques sans tests
Une personne bloque plusieurs chantiers	Ce qui attend pendant son absence	Savoir trop concentré
Beaucoup commencé, peu terminé	Qui interrompt, et pourquoi	Trop de travail en cours
Un nouvel arrivant tarde à contribuer	Accès, installation, première livraison	Transmission incomplète
L’équipe livre mais s’épuise	Réunions, heures inhabituelles, départs	Un rythme qui ne durera pas

Le symptôme que je rencontre le plus souvent est le troisième : une personne par qui tout passe. Je n’en déduis pas de la mauvaise volonté : il faut regarder sa charge et la place qu’on lui propose après la transmission. Vous ne réglerez pas ça par une injonction à documenter, mais en lui donnant autre chose à porter. Et ne supprimez pas une revue lente avant de savoir ce qu’elle protège : vous déplaceriez le problème en production.

Pour sortir des impressions, il existe un cadre public. Le guide des métriques DORA, pour DevOps Research and Assessment, en retient cinq : le délai de changement du commit à la production, la fréquence de déploiement, le temps de rétablissement après un déploiement en échec, le taux d’échec des changements et le taux de reprise. Ces métriques décrivent le rythme et la stabilité de la livraison ; elles ne comptent pas les heures de développement. Une équipe qui déploie une fois par mois avec trois semaines entre le commit et la production a un problème d’attente, quel que soit le talent de ses développeurs.

Le radar de santé d’équipe reprend cette lecture en deux temps, rythme et stabilité. Deux questions portent directement sur la fréquence de déploiement et le temps de rétablissement, avec les paliers du rapport Accelerate State of DevOps 2024 ; deux autres s’en approchent, dont le temps entre un ticket et la production, qui commence plus tôt que le délai de changement : il inclut l’attente avant la première ligne de code. Précisément celle qui vous intéresse.

Deux réserves. Les réponses du radar sont des tranches déclarées, pas des valeurs tirées de vos outils. Et le guide prévient : ces métriques s’appliquent à une application ou à un service, dans son contexte. Elles servent à suivre son évolution, pas à mettre les équipes en concurrence ; comparer des applications très différentes peut induire en erreur. En faire des objectifs peut aussi pousser à optimiser les chiffres plutôt que le travail. Une équipe à qui l’on demande de déployer plus souvent déploiera plus souvent. Ce n’est pas la même chose que livrer plus.

Demandez à votre équipe pourquoi la dernière fonctionnalité a pris deux mois, et posez-vous la question de votre côté, séparément. Vous verrez la date promise et la date tenue. Elle verra la spécification modifiée deux fois, la revue attendue une semaine, la validation arrivée un vendredi soir. Personne ne ment. Vous ne regardez pas la même partie du ticket.

C’est à ça que sert la comparaison du radar de santé d’équipe : chacun répond sans voir l’autre, puis vous posez les deux radars côte à côte. Ce n’est ni un verdict, ni un classement des développeurs, ni une mesure DORA. C’est un prétexte à une conversation que personne n’ose ouvrir, avec un écart précis à expliquer. Pour chaque écart, revenez à une trace : une correction prête qui attend sa livraison, c’est de la dette organisationnelle ; une automatisation retenue parce qu’une décision n’arrive pas, c’est de la dette d’autonomie.

Ne lancez pas cinq chantiers. Prenez le goulot qui explique le plus de travail en attente et traitez-le seul : répartir les revues, écrire le chemin critique, clarifier une validation, limiter les tickets en cours. Un responsable, une date de relecture, une photo de la situation avant. À la relecture, regardez délais et stabilité ensemble : un ticket livré plus vite mais suivi d’un incident n’est pas un progrès, c’est un déplacement.

Avant de décider du profil à recruter et de sa date d’arrivée, je vérifierais si ce poste soulagera le goulot observé. Une personne capable de répartir les revues peut aider là où un développeur supplémentaire attendrait les mêmes validations. Les entretiens peuvent avancer pendant cet examen ; c’est l’effet attendu du recrutement qu’il faut préciser. Quand un regard extérieur aide à voir le goulot que l’équipe ne voit plus, c’est l’objet du diagnostic technique et organisationnel ; les situations d’organisation d’équipe décrivent ce sur quoi j’interviens.