Les frictions entre les chefs de produit et les ingénieurs sont l’un des problèmes les plus prévisibles dans les équipes logicielles, et l’un des plus systématiquement mal gérés.
PMs a l'impression que les ingénieurs repoussent tout sans proposer d'alternatives. Les ingénieurs ont l'impression que le PMs s'engage sur les délais et la portée sans comprendre la complexité technique. Les deux parties ont généralement raison sur les angles morts de l'autre partie, et toutes deux ont généralement tort sur les intentions de l'autre partie.
Les rétrospectives de sprint standard résolvent rarement ce problème car elles ont tendance à rester dans les limites de l'équipe. Ingénieurs rétro avec des ingénieurs. Débriefing PMs avec PMs. La tension interfonctionnelle s'accumule jusqu'à ce qu'elle éclate lors d'une réunion de planification ou d'un délai non respecté.
Une rétrospective dédiée à l'ingénierie produit met les deux perspectives dans la même pièce avec une structure qui rend la conversation productive plutôt que combative.
Les quatre points de friction récurrents
Avant de concevoir la rétrospective, il est utile de nommer honnêtement les tensions. Dans la plupart des équipes, ils se regroupent en quatre catégories.
1. Des exigences qui semblent claires mais ne le sont pas
Un PM rédige une spécification qu’il considère comme approfondie. Un ingénieur le lit et pose quinze questions. Le PM donne l’impression que l’ingénieur pinaille. L’ingénieur a l’impression que le PM n’a pas réfléchi aux cas extrêmes.
Le problème fondamental est rarement la paresse des deux côtés. PMs et les ingénieurs pensent les produits différemment. PMs pense aux parcours des utilisateurs et aux résultats commerciaux. Les ingénieurs réfléchissent aux flux de données, à la gestion des états et aux modes de défaillance. Une spécification complète d’un point de vue est pleine de lacunes d’un autre.
2. Vitesse vs qualité
PMs est responsable de l'expédition à temps. Les ingénieurs sont responsables en cas de panne en production. Ces incitations vont dans des directions opposées, et aucune n’est fausse.
Le conflit se manifeste sous forme de débats sur la réduction de la portée, la couverture des tests, la rigueur de la révision du code et l'opportunité de prendre des raccourcis techniques. Sans discussion explicite sur ces compromis, chaque partie suppose que l’autre ne se soucie pas de ce qui compte.
3. Dette technique
Les ingénieurs voient la dette s’accumuler et veulent avoir le temps d’y remédier. PMs constate un retard dans les fonctionnalités destinées aux utilisateurs et peine à justifier un travail invisible pour les clients. Résultat : la dette est reportée jusqu’à ce qu’elle commence à provoquer des incidents, auquel cas tout le monde s’accorde à dire qu’elle aurait dû être traitée plus tôt.
4. Estimations et prévisibilité
PMs doit communiquer les délais aux parties prenantes. Les ingénieurs hésitent à donner des estimations parce qu’ils connaissent le degré d’incertitude qui existe. Le PM entend « Je ne veux pas m'engager » et l'ingénieur entend « dites-moi simplement ce que je veux entendre ». Aucune des deux interprétations n’est exacte.
Mise en place de la rétrospective
Exécutez-le tous les trimestres ou après les versions majeures. Une fréquence mensuelle est trop fréquente : les schémas ont besoin de temps pour se développer.
Qui participe : Chefs de produit, responsables techniques et ingénieurs seniors. Gardez le groupe de 6 à 10 personnes. Si le groupe est plus nombreux, la conversation devient performative.
Durée : 90 minutes. Les rétrospectives interfonctionnelles prennent plus de temps que celles impliquant la même équipe, car vous avez besoin de temps pour construire une compréhension commune, et pas seulement pour faire ressortir les problèmes.
Facilitation : Utilisez un facilitateur neutre, idéalement quelqu'un qui n'est pas un PM ou un ingénieur de l'équipe. Un responsable de l'ingénierie, un Scrum master ou quelqu'un d'une autre équipe fonctionne bien. Le travail de l'animateur est d'éviter que la conversation ne devienne un débat et de s'assurer que les deux parties se sentent entendues.
Une structure qui fonctionne
Partie 1 : Collection double perspective (20 minutes)
Demandez au PMs et aux ingénieurs d'écrire indépendamment des cartes répondant aux trois mêmes invites :
- Qu'est-ce qui a bien fonctionné dans notre collaboration ce trimestre ?
- Où la friction nous a-t-elle ralentis ?
- Que souhaiteriez-vous que l'autre partie comprenne mieux ?
La troisième invite est la plus importante. Cela fait apparaître des hypothèses et des frustrations qui restent normalement tacites.
Collectionnez toutes les cartes de manière anonyme. C'est important : les gens écrivent plus honnêtement lorsque leur nom n'est pas joint, en particulier en cas de tensions interfonctionnelles.
Partie 2 : Discussion thématique (40 minutes)
Regroupez les cartes par thèmes. Les plus courants incluent : la clarté des exigences, le processus d’estimation, les décisions de priorisation, les lacunes en matière de communication et la gestion technique des dettes.
Pour chaque thème, évitez la tentation de débattre pour savoir qui a raison. Demandez plutôt :
- Pourquoi chaque partie optimise-t-elle ? (Habituellement, les deux parties ont des objectifs légitimes qui sont en tension.)
- Où le transfert s'interrompt-il ? (La plupart des frictions se produisent aux frontières entre les rôles, et non à l'intérieur de ceux-ci.)
- De quelles informations chaque partie manque-t-elle ? (De nombreux conflits sont en fait des asymétries d'information déguisées.)
Partie 3 : Accords spécifiques (30 minutes)
Ne partez pas avec de vagues intentions. Partez avec des accords de travail spécifiques auxquels les deux parties s'engagent.
Les bons accords de travail sont :
- Observable -- Vous pouvez savoir s'ils se produisent ou non.
- Bilatéral -- Les deux parties changent quelque chose, pas seulement une partie exigeant l'autre.
- Time-boxed -- Essayez-les pendant un trimestre et évaluez.
Voici des exemples d’accords qui ont tendance à fonctionner :
Pour la clarté des exigences : "PMs et les responsables techniques passeront 30 minutes ensemble avant qu'une spécification de fonctionnalité ne soit partagée avec l'ensemble de l'équipe, en particulier pour identifier les cas extrêmes et les contraintes techniques."
Pour l'estimation : "Les ingénieurs fourniront des estimations de plage (meilleur des cas/probable/pire des cas) au lieu d'estimations ponctuelles, et PMs communiquera la plage aux parties prenantes au lieu de seulement le meilleur des cas."
Pour la dette technique : "20 % de la capacité de chaque sprint est réservée aux travaux prioritaires d'ingénierie. PMs n'attribue pas cette capacité et les ingénieurs n'ont pas besoin de justifier des éléments individuels, mais les ingénieurs partagent un résumé trimestriel du temps consacré."
Pour les discussions sur la portée : "Lorsque la portée doit être coupée, le PM propose ce qu'il faut couper et l'ingénieur propose comment simplifier. Les deux options sont discutées avant de décider."
Gérer les conversations difficiles
Certains sujets font systématiquement dérailler les rétrospectives interfonctionnelles. Voici comment les gérer.
"Nous n'avons jamais le temps pour la dette technique." Ne débattez pas de l'importance de la dette technique. Demandez-vous plutôt : quel est le coût de la dette actuelle ? Si les ingénieurs peuvent signaler des incidents spécifiques, des ralentissements ou des problèmes rencontrés par les développeurs causés par l’endettement, la conversation passe de l’abstrait au concret. PMs répond aux données d'impact, et non aux appels abstraits pour la qualité du code.
"Les exigences continuent de changer." Les exigences changent parce que le marché change, les commentaires des utilisateurs arrivent et les parties prenantes modifient les priorités. La question n’est pas de savoir si les exigences changeront, mais plutôt de savoir comment les changements seront communiqués et à quelle date ils arriveront dans le processus. Focus sur le processus : à quel moment du développement le périmètre doit-il être considéré comme gelé ? Quelle est la voie à suivre pour les modifications ultérieures ?
"L'ingénierie sous-estime toujours." Inversez la situation : l'équipe suit-elle la précision des estimations au fil du temps ? Sinon, commencez. Après quelques sprints de données, la conversation passe des accusations aux modèles. Peut-être que l'équipe sous-estime systématiquement un type de travail spécifique (intégrations, migrations) et est précise sur d'autres. C’est exploitable.
"PMs ne comprend pas à quel point c'est complexe." C'est souvent vrai, et c'est aussi le travail de l'ingénieur de rendre la complexité visible. Si un ingénieur dit « c'est difficile » et que le PM entend « c'est difficile », rien ne change. Si l'ingénieur dit "cela nécessite des modifications de trois services, une migration de base de données et présente un risque de temps d'arrêt en cas d'échec de la migration", le PM peut en fait raisonner sur le compromis.
À quoi ressemble le bien au fil du temps
Après trois ou quatre de ces rétrospectives, vous devriez constater des changements concrets :
- Moins de surprises dans la planification du sprint car PMs et les responsables techniques s'alignent plus tôt
- Des conversations plus honnêtes sur les compromis plutôt que sur les confrontations passives-agressives
- Réduction des retouches car les exigences sont explorées sous les deux angles avant le début du développement
- La dette technique est traitée progressivement au lieu d'être différée jusqu'à ce qu'elle provoque une crise
- Les estimations deviennent plus précises car l'équipe se calibre par rapport aux performances passées
L’objectif n’est pas d’éliminer les tensions entre le produit et l’ingénierie. Une certaine tension est saine : cela signifie que les deux parties défendent ce qui compte. Le but est de rendre cette tension productive plutôt que corrosive.
Essayez NextRetro gratuitement -- Facilitez les rétrospectives interfonctionnelles avec une collecte de cartes anonyme et des flux de travail de discussion structurés.
Dernière mise à jour : février 2026
Temps de lecture : 7 minutes
