Qui décide vraiment ce qui arrive jusqu’à vos utilisateurs

Vous avez un pipeline qui fonctionne. Les tests passent. Les builds sont verts. Le bouton de déploiement est là, sous vos yeux, qui attend. Mais personne ne clique.

Pourquoi ? Parce qu’il faut bien que quelqu’un décide si cette version-là doit vraiment atteindre les utilisateurs. Cette décision n’est pas technique. C’est une décision produit et de coordination. Et si elle n’est pas prise clairement, votre pipeline tourne en rond.

Deux rôles gèrent cette décision : le product manager et le release manager. Ce ne sont pas la même personne, et ils ne font pas le même travail. Mais ensemble, ils répondent à la question que votre système CI/CD ne peut pas répondre : « Est-ce que ça doit sortir maintenant ? »

Le Product Manager décide ce qui est construit

Le product manager n’écrit pas de code et ne pilote pas les pipelines. Son travail consiste à comprendre ce dont les utilisateurs et le métier ont réellement besoin, puis à traduire cela en travail pour l’équipe technique. Dans un contexte CI/CD, ce rôle compte avant même qu’une ligne de code soit écrite.

Le product manager décide quelle fonctionnalité part dans le prochain sprint, laquelle est reportée, et laquelle est abandonnée. Cette décision impacte directement la fluidité de votre delivery.

Si le product manager priorise une fonctionnalité trop grosse, l’équipe technique est submergée et la release dérape. Si les priorités changent trop souvent, les développeurs jettent du travail à moitié fait. Un bon product manager comprend que la priorisation ne consiste pas seulement à choisir « ce qui est le plus important ». C’est aussi « ce qui peut réellement être terminé et livré dans un délai réaliste ».

C’est là que le product manager et le système CI/CD interagissent. Un pipeline rapide ne sert à rien si l’équipe travaille constamment sur le mauvais sujet. Le travail du product manager est de s’assurer que le pipeline est alimenté avec des tâches bien définies, correctement dimensionnées et alignées sur les besoins des utilisateurs.

Le Release Manager coordonne le moment de la mise en production

Le release manager est la personne qui coordonne quand et comment une release a lieu. Parfois c’est un rôle dédié. Parfois il est tourné entre ingénieurs DevOps ou leads techniques. La fonction reste la même : s’assurer que tout le monde est prêt avant qu’une version parte en production.

Que coordonne concrètement un release manager ?

D’abord, le calendrier des releases. L’équipe utilise-t-elle un calendrier fixe, comme tous les jeudis à 14h ? Ou bien sortent-ils dès qu’une fonctionnalité est terminée ? Les deux approches fonctionnent, mais le release manager s’assure que tout le monde connaît le rythme en vigueur.

Ensuite, la préparation technique. Tous les changements sont-ils fusionnés dans la branche principale ? Tous les tests sont-ils verts ? La migration de base de données a-t-elle été exécutée sur l’environnement de staging ? Ces vérifications semblent basiques, mais elles sont souvent oubliées quand chacun suppose que quelqu’un d’autre s’en est chargé.

Troisièmement, la communication. L’équipe support sait-elle qu’un changement arrive ? Le marketing est-il prêt si la nouvelle fonctionnalité nécessite une annonce ? Une release qui surprend les autres équipes crée le chaos, même si le code est parfait.

Le release manager mène également la décision go/no-go. C’est le moment où tout le monde se réunit, souvent dans un chat rapide ou une courte réunion, et décide si la release a lieu ou est reportée. Si un bug critique vient d’être découvert, le release manager dit « on stoppe ». Si tout semble sûr, le release manager donne le feu vert.

Comment ces deux rôles travaillent avec l’équipe technique

Le product manager et le release manager n’opèrent pas en vase clos. Ils interagissent en permanence avec l’équipe technique.

Le product manager discute avec les développeurs pour comprendre l’effort nécessaire à une fonctionnalité. Une fonctionnalité qui semble simple à une personne non technique peut nécessiter des semaines de travail. Le product manager a besoin de cet input pour prendre des décisions de priorité réalistes.

Le release manager parle avec la QA pour savoir si les tests sont suffisants. Il parle avec la DevOps pour savoir si l’infrastructure est prête pour une nouvelle version. Il parle avec le product manager pour savoir si un retard sur une fonctionnalité impacte le plan global de release.

Dans les équipes matures, cette interaction devient plus fluide grâce à des pratiques comme les feature flags. Avec les feature flags, le product manager peut contrôler quelles fonctionnalités sont actives pour quels utilisateurs sans attendre un calendrier de release. Le release manager ressent aussi moins de pression car le code est déjà en production, même s’il n’est pas encore actif.

Mais les feature flags ne sont pas magiques. Ils nécessitent toujours de la coordination. Les flags qui s’accumulent sans être nettoyés deviennent une dette technique. Le product manager et le release manager doivent suivre quels flags existent, lesquels sont actifs, et lesquels peuvent être supprimés.

Ces rôles ne sont pas des garde-barrières

Il est facile de voir le product manager et le release manager comme des obstacles. Les développeurs veulent livrer. Le pipeline est prêt. Pourquoi attendre que quelqu’un dise oui ?

Mais ces rôles existent pour éviter le travail gaspillé. Imaginez des développeurs qui codent pendant des jours, pour découvrir que la fonctionnalité ne correspond pas à ce dont les utilisateurs ont réellement besoin. Ou imaginez l’équipe prête à déployer, mais le marketing n’a pas préparé l’annonce. Les deux situations gaspillent des efforts et créent de la frustration.

Le product manager empêche le premier scénario en s’assurant que l’équipe construit la bonne chose. Le release manager empêche le second scénario en s’assurant que l’organisation est prête à recevoir la nouvelle version.

Checklist pratique pour les Product et Release Managers

Si vous endossez l’un de ces rôles, ou si vous travaillez avec des personnes qui les occupent, voici une courte checklist pour garder la delivery fluide :

• Avant le sprint planning : Confirmez que la fonctionnalité est bien définie et dimensionnée de manière réaliste. Si elle est trop grosse, découpez-la.
• Avant d’écrire du code : Parlez aux développeurs des estimations d’effort. Ne supposez pas qu’une fonctionnalité est petite parce qu’elle semble simple.
• Avant le merge : Vérifiez que tous les changements sont revus et testés. Ne laissez pas le « on corrigera plus tard » devenir la norme.
• Avant le jour de la release : Confirmez que les équipes support, marketing et autres savent que la release a lieu. Les surprises créent le chaos.
• Avant le go/no-go : Vérifiez les résultats des tests, le statut des migrations et les problèmes connus. Si quelque chose n’est pas clair, reportez.
• Après la release : Suivez les feature flags encore actifs. Nettoyez-les avant le prochain cycle de release.

Ce qu’il faut retenir

Un pipeline rapide ne sert à rien si les mauvaises fonctionnalités sont construites ou si l’organisation n’est pas prête à les recevoir. Le product manager et le release manager ne sont pas là pour vous ralentir. Ils sont là pour s’assurer que lorsque vous appuyez sur le bouton, cela a vraiment du sens.