[J-Story 4] De la tech au produit : aligner équipes, delivery et business. Tanguy Combe – VP Engineering / Product & Delivery Leader @AXA

Jissen donne la parole à des responsables tech pour partager, à travers une série d’interviews (J-Stories), leurs parcours, leurs choix et les histoires techniques et humaines qui façonnent les organisations d’aujourd’hui.

Pourquoi cette J-Story ?

À travers le parcours de Tanguy Combe, on voit émerger une trajectoire que beaucoup vivent sans forcément la formaliser : partir de la technique, élargir progressivement son périmètre, et finir par jouer un rôle clé dans l’alignement entre équipes, produit et business.

Ce que vous allez apprendre ?

• Pourquoi passer de la tech au produit est avant tout un changement de posture
• En quoi un background technique est un vrai levier de décision
• Pourquoi parler le même langage (ubiquitous language) change tout
• Pourquoi certains KPI trompent plus qu’ils n’aident

À qui cette J-Story s’adresse-t-elle ?

Engineering Managers, VP Engineering, responsables DevEx / Platform / Delivery, Tech Leads, CTO. Ceux qui veulent améliorer leur performance sans perdre en qualité ni en clarté.

1. Peux-tu présenter ton parcours jusqu’à aujourd’hui ?

Mon stage de fin d’études, a été une première étape importante. J’étais sur des sujets big data, dans une petite équipe où je n’étais pas seulement dans l’exécution technique. J’avais déjà un pied dans la coordination, dans la gestion des besoins, dans les échanges avec les parties prenantes. Avec le recul, je vois que ce mélange entre technique, organisation et produit était déjà là très tôt.

Ensuite, je suis entré dans le conseil, aussi parce que c’était une voie très ouverte à ce moment-là. J’y ai travaillé sur des sujets data, cloud, puis sur des migrations AWS, de la sécurité cloud, de l’architecture big data, dans de grands groupes français. Ce qui était intéressant, c’est que j’ai pu toucher à des problématiques très différentes, parfois sur des missions longues, parfois sur des interventions plus courtes, très orientées vers l’expertise.

Au fil des missions, un schéma revenait souvent : je commençais comme développeur ou expert technique, et je finissais souvent dans une position où j’étais la personne qu’on allait voir pour clarifier un besoin, faire le lien avec le métier, arbitrer, ou structurer ce qu’il fallait construire. C’est comme ça que j’ai progressivement glissé vers des rôles plus “produit”, puis vers des responsabilités plus larges en engineering.

Aujourd’hui, j’occupe un rôle de lead / head / VP Engineering selon la manière dont on veut le nommer, avec une forte dimension transverse. Je suis à la fois sur des sujets d’alignement, de standards, de delivery, et sur l’accompagnement humain des équipes. Ce que j’aime dans ce parcours, c’est qu’il ne s’est pas fait par rupture. Je n’ai jamais “quitté” la technique. Je l’ai élargie. 

2. Comment s’est faite ta transition de la tech vers le produit ?

Elle ne s’est pas faite du jour au lendemain, ni comme un grand choix théorique. Ça a été quelque chose d’assez naturel. Dans beaucoup de missions, je suis arrivé avec une casquette très technique, et petit à petit je me suis retrouvé à prendre une place différente dans l’équipe. J’étais souvent celui qu’on allait voir quand un client avait un problème, quand il fallait cadrer un nouveau besoin, ou quand il fallait reformuler quelque chose de flou pour le rendre actionnable.

À force, je me suis rendu compte que j’aimais beaucoup cette partie-là. J’aimais le fait d’être à l’écoute, de comprendre ce que les gens essayaient vraiment d’exprimer, et de transformer ça en quelque chose de faisable. Il y avait une satisfaction particulière à réussir à mettre en lumière un besoin, à expliquer ce qui était possible, ce qui ne l’était pas, et à faire le pont entre plusieurs mondes qui ne se comprenaient pas toujours très bien.

Mais cette transition demande un vrai travail sur soi. Quand on vient de la technique, on a tendance à être orienté solution très vite. On entend un problème, on a envie de le régler immédiatement. Or le produit demande d’abord d’écouter, de reformuler, de clarifier, de prendre le temps de bien comprendre. Ça a été un apprentissage important pour moi. Il faut accepter de ne pas répondre tout de suite. Il faut apprendre l’écoute active, ce qui est souvent beaucoup plus difficile qu’on ne l’imagine.

Le vrai déclic, c’est quand j’ai commencé un rôle explicitement orienté PO/PM sur un produit plateforme. Là, le pont entre mes deux casquettes est devenu évident. Il y avait un besoin de quelqu’un capable de gérer un produit avec une vraie compréhension technique. Et je me suis rendu compte que ce profil-là était en fait parfaitement aligné avec ce que j’avais construit jusque-là.

3. Pourquoi, selon toi, avoir un background technique est un vrai levier dans des rôles “produit” ?

Parce que ça permet de mieux itérer, de mieux arbitrer, et surtout de mieux comprendre la réalité du système qu’on essaie de faire évoluer. On oppose souvent la tech et le produit, comme si d’un côté on avait des gens obsédés par la solution, et de l’autre des gens focalisés sur la valeur. En réalité, les deux ont tout intérêt à se rapprocher.

Ce que la technique m’a apporté dans des rôles plus produits, c’est d’abord une vraie culture des cycles courts. Quand on vient du développement, on sait à quel point le feedback rapide est précieux. On sait que plus on attend, plus on rend les choses coûteuses à corriger. Cette logique-là est très utile en produit, parce qu’elle pousse à travailler de manière itérative, à confronter vite ce qu’on construit à la réalité, et à éviter les gros blocs théoriques qu’on découvre trop tard.

Avoir un background technique aide aussi à mieux gérer la dette, à poser les bons arbitrages, et à ne pas vendre une vision complètement déconnectée de ce qu’implique la construction réelle d’un système. Ça ne veut pas dire qu’il faut que tous les profils “produit” soient des anciens développeurs, mais ça donne une capacité supplémentaire pour poser les bonnes questions et éviter certains angles morts.

Je pense aussi que c’est de plus en plus important avec l’IA. On voit émerger des usages où des personnes s’appuient sur des outils ou des agents pour produire des éléments d’aide à la décision sans toujours comprendre les limites de ces systèmes. Dans ce contexte, le besoin de profils produit capables de comprendre un minimum le fonctionnement technique devient beaucoup plus fort. Pas pour être experts de tout, mais pour mettre les bons garde-fous et éviter de prendre des décisions sur des bases mal comprises.

4. Quel est ton rôle aujourd’hui, concrètement, en tant que leader engineering ?

Je vois mon rôle en deux grandes dimensions.

La première, c’est une dimension de facilitation et d’alignement. Je travaille sur la synchronisation entre équipes, sur la mise en place de standards, sur la cohérence globale entre les besoins business, les contraintes des équipes et la manière dont on fait fonctionner tout ça ensemble. J’essaie de faire en sorte que les différents acteurs de l’organisation aient un cadre commun, même s’ils n’ont pas tous les mêmes priorités. Il y a une part importante de régulation là-dedans : créer des conditions de fonctionnement qui permettent aux équipes d’avancer dans le même sens.

La deuxième dimension est profondément humaine. J’ai un rôle de manager hiérarchique et d’accompagnateur. Je passe beaucoup de temps à comprendre les personnes, leurs forces, leurs difficultés, leurs aspirations, ce dont elles ont besoin pour progresser, et comment leur donner une place claire dans l’organisation. Je déteste la vision où l’on parle des gens comme de simples ressources. Une équipe qui fonctionne bien, ce n’est pas juste un assemblage de compétences techniques. Ce sont des personnes qui se sentent reconnues, qui savent où elles vont, qui comprennent leur rôle, et qui ont les conditions pour travailler correctement.

Pour moi, il y a un lien direct entre performance et état des équipes. Si un produit fonctionne bien, c’est parce qu’une équipe fonctionne bien. Et si une équipe fonctionne bien, c’est parce que les gens vont bien. Ça demande du temps. Parfois ce sont juste des échanges courts, réguliers, parfois c’est plus profond. Mais cette partie-là n’est pas secondaire. Elle fait partie du cœur du rôle.

Et au fond, mon travail aujourd’hui n’est plus de réparer moi-même tous les problèmes. Ce n’est pas d’être celui qui colmate chaque fuite. C’est de faire en sorte qu’il y ait moins de fuites, qu’elles soient visibles plus tôt, et que les équipes soient en capacité de traiter les bons sujets au bon moment.

5. Tu parles beaucoup d’ubiquitous language. Qu’est-ce que c’est, et pourquoi c’est si important dans une organisation ?

L’ubiquitous language, c’est l’idée qu’une organisation gagne énormément en efficacité quand tout le monde utilise les mêmes mots pour parler des mêmes choses. Dit comme ça, ça paraît presque banal, mais en réalité c’est un sujet énorme.

Dans beaucoup d’équipes, il y a une quantité incroyable d’ambiguïtés liées au langage. Des acronymes que tout le monde n’ose pas demander. Des mots qui veulent dire une chose pour le métier, une autre pour la tech, une troisième pour le juridique ou le marketing. Et à partir du moment où chacun pense parler de la même chose sans que ce soit vraiment le cas, on crée de la friction, des incompréhensions et beaucoup de perte de temps.

L’idée de l’ubiquitous language, c’est donc de définir clairement les concepts métier importants, les termes qu’on utilise, les objets qui structurent le système, et de faire en sorte que cette définition soit partagée par tout le monde. Tech, métier, sécurité, légal, marketing, peu importe. À partir du moment où on est tous d’accord sur les mots, les échanges deviennent beaucoup plus fluides.

L’effet le plus visible, pour moi, c’est sur l’onboarding. Quand quelqu’un rejoint une équipe ou une organisation et qu’il existe déjà un langage commun documenté, avec des définitions claires, il comprend beaucoup plus vite où il met les pieds. Il y a moins d’ambiguïté, moins de gêne à demander, moins de temps perdu à deviner ce que veulent dire les autres. On réduit énormément le temps de montée en compréhension.

Ça demande un peu de travail au départ, bien sûr. Il faut définir, documenter, faire vivre ce langage. Mais une fois que c’est en place, c’est extrêmement puissant. Et c’est typiquement le genre de standard simple qui change profondément la qualité des interactions dans une organisation. 

6. Pour toi, qu’est-ce qu’une vraie décision data-driven ?

7. Quels KPI te paraissent vraiment utiles pour améliorer le delivery d’une équipe ?

Les KPI utiles sont ceux qui permettent de comprendre la santé réelle du delivery, pas seulement ceux qui donnent une impression de vitesse ou de performance. On peut suivre plein d’indicateurs, mais l’important est surtout de savoir pourquoi on les suit et ce qu’ils permettent de voir.

Dans les équipes, on regarde évidemment des éléments comme la vélocité, la complétude fonctionnelle, le nombre de bugs, le temps moyen de résolution d’un incident, le nombre d’incidents par rapport au volume de fonctionnalités livrées. Ce sont des indicateurs intéressants parce qu’ils permettent d’avoir une lecture plus complète du système.

L’erreur classique, c’est de regarder un KPI seul. Par exemple, avoir une bonne vélocité peut sembler rassurant. Mais si, en parallèle, on détecte énormément de bugs avant production et qu’on décide quand même d’envoyer en prod faute de temps, alors cette vélocité est trompeuse. On ne livre pas efficacement, on livre vite au prix d’une dégradation de la qualité.

L’intérêt des KPI, c’est donc moins de mesurer pour mesurer que de mettre les signaux en relation. C’est ce qui permet de voir qu’une équipe va vite mais se fragilise, ou au contraire qu’elle ralentit ponctuellement pour assainir son delivery. Un bon pilotage, c’est un pilotage qui aide à prendre des décisions utiles, pas à surveiller les gens.

Et pour éviter de tomber dans le piège du KPI pour le KPI, il faut garder les choses transparentes. Tout le monde doit comprendre ce qu’on mesure, pourquoi on le mesure, et ce que ça doit aider à améliorer. Sinon on tombe très vite dans une logique contre-productive.

8. Comment tu arbitres entre excellence technique, produit, delivery et management ?

Je ne les hiérarchise pas de manière théorique, avec une grille figée. J’essaie de les ramener à une question simple : où est-ce que je peux apporter le plus de valeur maintenant ?

C’est vraiment ça mon point de départ. Tous les matins, la question que je me pose, c’est : qu’est-ce que je peux faire aujourd’hui pour améliorer la vie de mon équipe ? Parce que dans mon rôle actuel, c’est là que je considère que ma valeur est la plus forte. Si mes équipes sont mieux outillées, mieux alignées, mieux accompagnées, alors le produit se porte mieux, le delivery se porte mieux, et la technique retrouve de l’espace pour faire du bon travail.

Évidemment, ça ne veut pas dire que la technique ou le produit passent au second plan. Ça veut dire que je considère qu’à mon niveau, la meilleure manière de servir ces dimensions-là, c’est souvent d’agir sur le système et sur les conditions de travail plutôt que de vouloir intervenir directement partout.

J’ai toujours été quelqu’un de très curieux, qui aime creuser les sujets jusqu’au fond. Ça m’a aidé à comprendre plein de domaines, mais ça m’a aussi appris qu’il y aura toujours des gens plus experts que moi sur certains sujets. Donc à un moment, il faut accepter de ne pas vouloir être la personne la plus pointue partout, et se concentrer sur l’endroit où on crée le plus d’impact.

9. Quel conseil donnerais-tu à quelqu’un qui veut passer de la tech au produit, ou qui sent qu’il est déjà en train d’y glisser ?

Le premier conseil, c’est d’y aller. Il faut essayer. Souvent, les gens attendent un grand signal extérieur, une validation, un titre, alors qu’en réalité beaucoup ont déjà commencé à faire ce mouvement sans s’en rendre compte. Ils cadrent, ils reformulent, ils arbitrent, ils prennent du recul sur le besoin. Le sujet, c’est moins d’attendre une autorisation que d’assumer cette évolution.

Ensuite, je pense qu’il faut vraiment être honnête avec soi-même sur ce qui nous motive. Ce qui compte, ce n’est pas de faire un produit parce que c’est à la mode ou parce qu’on imagine que c’est une évolution “logique”. Il faut y aller parce que ça donne envie, parce qu’on aime comprendre les besoins, créer de la clarté, faire le lien entre plusieurs mondes. Si la motivation est là, alors ça vaut le coup de creuser.

Et surtout, il ne faut pas croire que le passage est irréversible. On peut aller vers le produit et garder une culture technique forte. On peut continuer à faire de la veille, à coder un peu, à expérimenter, à rester connecté à la réalité du build. Moi, c’est quelque chose que je continue à faire. Ça nourrit aussi ma crédibilité et ma compréhension des équipes.

Donc mon conseil est simple : essayez, écoutez ce qui vous attire vraiment, et ne voyez pas ça comme un abandon de la technique. Ça peut être au contraire une manière d’en faire quelque chose de plus large, de plus structurant, et parfois de plus utile.

Ce qu’on retient de cette J-Story :

• Passer de la tech au produit est avant tout un changement de posture et d’écoute
• Un background technique aide à mieux arbitrer entre produit, delivery et qualité
• L’ubiquitous language réduit les frictions et accélère l’alignement des équipes
• Les KPI sont utiles uniquement lorsqu’ils reflètent la réalité du delivery
• La performance d’une organisation dépend directement de la santé et de l’alignement des équipes tech

————————————————————————

Chez Jissen, nous accompagnons les CTO, DSI, VP Engineering et Head of Tech dans la mise en œuvre concrète de leur vision technique, de la stratégie à l’exécution et jusqu’à la production.

Nous intervenons sur la structuration des organisations tech et produit, l’alignement des équipes, le delivery et la mise en place de pratiques d’ingénierie robustes pour améliorer la performance sans perdre en qualité.

Si ces enjeux de transformation, de pilotage et d’industrialisation résonnent avec vos projets, nos équipes seront ravies d’en discuter avec vous.