Que signifie l’ingénierie 10X pour les responsables de programmes techniques ?

Galen Low : Les responsables de programmes techniques ne sont généralement pas censés écrire du code, mais de nos jours, ce n’est pas non plus le cas des ingénieurs logiciels, du moins pas à la main. La question n’est donc pas nécessairement de savoir si les responsables de programmes techniques devraient savoir coder. La question est plutôt la suivante : quel niveau de compréhension est nécessaire pour permettre aux responsables de programmes techniques de faire évoluer la valeur qu’ils apportent dans un monde où les équipes qui les entourent utilisent l’IA pour avancer cinq, dix, voire parfois cinquante fois plus vite qu’il y a seulement quelques années ?

Pour comprendre comment le rôle de responsable de programme technique évolue dans l’industrie logicielle actuelle, j’ai invité un vice-président chargé de la livraison et des opérations d’ingénierie, qui a dirigé des équipes de responsables de programmes techniques dans des organisations telles que Dell et Google, ainsi que dans d’autres environnements logiciels rapides et en forte croissance. Nous allons explorer ensemble tout ce qui concerne les compétences demandées aujourd’hui aux responsables de programmes techniques, ainsi que la manière dont les responsables de la livraison peuvent défendre la valeur de leur équipe lorsque la direction évolue.

Nous parlerons également de la manière dont les responsables du recrutement peuvent évaluer les candidats à un poste de responsable de programme technique pendant le processus de recrutement, et de l’impact que pourrait avoir la disparition de ce rôle. J’espère que cet épisode vous plaira.

Bienvenue dans le podcast du Digital Project Manager, l’émission qui aide les responsables de la livraison à travailler plus intelligemment, à livrer plus efficacement et à diriger leurs équipes avec assurance à l’ère de l’IA. Je suis Galen et, chaque semaine, nous plongeons dans des stratégies concrètes, des tendances émergentes, des cadres éprouvés et, à l’occasion, quelques récits de guerre venus du front des projets. Que vous pilotiez d’immenses projets de transformation, que vous gériez des flux de travail liés à l’IA ou que vous essayiez simplement de garder le chaos sous contrôle, vous êtes au bon endroit.

Et si vous appréciez ce que vous entendez de notre part ces derniers temps, pensez à nous suivre là où vous nous écoutez et, pourquoi pas, à nous laisser un avis. Très bien, passons à l’épisode.

Satish Menon : Bonjour, Galen. Merci pour cette invitation. Je suis ravi d’être ici.

Galen Low : Voici le petit plan que j’ai préparé pour nous aujourd’hui. Tout d’abord, je voulais vous poser une question quelque peu controversée, dont mes auditeurs aimeraient beaucoup connaître votre point de vue. Ensuite, j’aimerais utiliser cette question comme prisme pour examiner trois sujets.

Je voulais d’abord étudier la manière dont le rôle de responsable de programme technique est bouleversé, en particulier dans le domaine des logiciels. Nous pourrions parler de la manière dont les responsables de département et les chefs d’équipe peuvent défendre la valeur de leurs responsables de programmes techniques. Nous pourrions également nous pencher sur les conséquences de l’hybridation des rôles entre les responsables d’équipes logicielles et les responsables de programmes techniques.

Qu’en pensez-vous ?

Satish Menon : Excellent. J’ai hâte d’en parler.

Galen Low : Parfait. Commençons. Voici ma question provocatrice pour lancer la discussion. Les responsables de programmes techniques affirment qu’ils n’ont pas besoin de savoir coder pour apporter de la valeur. Pourtant, de nombreux dirigeants du secteur technologique semblent ne pas être d’accord. Selon eux, l’IA signifie désormais que le responsable d’une équipe d’ingénierie logicielle et le responsable de programme technique ne font plus qu’un.

Alors, qui a raison ? L’IA a-t-elle créé des conditions qui rendent raisonnable, pour les organisations, d’attendre des responsables d’équipes logicielles qu’ils soient également responsables de programmes techniques, et inversement ?

Satish Menon : Vous conviendrez avec moi que le rôle de l’ingénieur logiciel a connu de nombreuses transformations récemment, n’est-ce pas ?

Ils sont passés de l’écriture manuelle du code, qui constituait auparavant le goulot d’étranglement, à l’utilisation actuelle du codage intuitif et d’outils d’IA capables de générer du code à une vitesse dix fois, voire cent fois supérieure. Le problème s’est alors déplacé vers le cycle de revue, notamment celui des demandes d’intégration : leur taille a augmenté. La charge s’est donc déplacée vers la supervision humaine de ce que l’IA génère dans les logiciels.

De la même manière que nous observons un changement dans le flux de travail, la vitesse et les responsabilités des ingénieurs logiciels, une adaptation similaire doit avoir lieu du côté des responsables de programmes techniques. Par exemple, il y a trois à cinq ans, une grande partie du travail consistait à établir le plan, puis à répondre aux questions suivantes : quel est l’état d’avancement ? Où en sommes-nous ? Comment les dépendances s’alignent-elles ? Quels sont les risques et comment pouvons-nous les atténuer ? Comment l’assurance qualité progresse-t-elle ? L’aspect assurance qualité de notre projet est-il sur la bonne voie et présente-t-il un risque ? Il fallait également surveiller les bogues, leur réduction, la couverture des tests, et ainsi de suite.

À cette époque, ces tâches étaient réalisées manuellement ou semi-manuellement par les responsables de programmes techniques. Puis, il y a quatre ou cinq ans, nous avons commencé à transformer ce fonctionnement avec Jira et Atlassian. Une fois le plan établi, l’état d’avancement remontait automatiquement et les responsables de programmes techniques pouvaient consulter les tableaux de bord afin d’évaluer ce qui était rouge ou jaune, puis commencer à s’impliquer dans la résolution des problèmes.

Le rôle a donc évolué. Il ne s’agissait plus seulement d’établir un plan, mais aussi de recueillir des informations, de produire des rapports d’avancement et de risques, et de faciliter leur atténuation. Désormais, les tableaux de bord en temps réel indiquent l’état d’avancement et, lorsque nous voyons du rouge ou du jaune, je coordonne toutes les activités de résolution de problèmes.

Aujourd’hui, avec l’IA, les responsables de programmes techniques disposent de possibilités supplémentaires. Si vous examinez les outils utilisés actuellement, vous avez Jira d’un côté, GitHub, où le code est écrit, et BrowserStack, où sont gérées la qualité et les étapes de déploiement.

En triangulant les informations provenant de ces trois outils, ou d’autres outils utilisés, vous obtenez des tableaux de bord plus riches, des données plus complètes et une analyse plus approfondie des risques et des problèmes. Le rôle évolue ainsi. Nous n’avons plus besoin d’identifier manuellement ce qui est rouge ou jaune. Nous pouvons utiliser l’IA pour trianguler les données issues de plusieurs outils et repérer les bons signaux afin d’identifier les zones rouges et jaunes bien mieux qu’auparavant.

Galen Low : J’aime beaucoup cette idée du déplacement du goulot d’étranglement, tout en reconnaissant qu’il s’agit en réalité de deux goulots d’étranglement différents.

Du côté de l’ingénierie, les développeurs passent moins de temps à écrire manuellement du code. Ils travaillent avec Cursor, avancent plus vite, et le goulot d’étranglement se déplace vers la revue. Lorsqu’on parle d’un responsable d’équipe d’ingénierie, cela signifie qu’il doit effectuer davantage de revues, n’est-ce pas ?

Le goulot d’étranglement se déplace. Il y a probablement davantage de revues et plus de code à superviser. Ils apportent de la valeur en maintenant le flux de travail en mouvement et en résolvant rapidement les problèmes liés au code. Mais cela ne crée pas nécessairement une capacité supplémentaire leur permettant d’assurer ensuite la gestion d’un programme technique.

De l’autre côté, le goulot d’étranglement concernait auparavant la collecte d’informations et de mises à jour. Aujourd’hui, notre rôle est lui aussi bouleversé. Nous utilisons d’autres outils, comme vous l’avez mentionné, Jira et l’IA. Une partie de cette automatisation nous rapproche de la résolution des problèmes au lieu de nous laisser attendre des informations toute la journée et de disposer soudainement du temps nécessaire pour superviser une équipe d’ingénierie logicielle.

J’aime cette façon de le présenter. Les deux domaines sont bouleversés, mais cela ne signifie pas qu’ils doivent être réunis. Ce sont deux fonctions distinctes.

Satish Menon : Il existe également un autre aspect. Un responsable ou directeur de l’ingénierie logicielle est chargé de faire livrer par son équipe un code de qualité, sécurisé, accessible et performant, avec une bonne vélocité.

La vélocité s’améliore aujourd’hui grâce à l’IA. Mais si vous leur demandez également de prendre en charge les aspects transversaux de cette livraison — les dépendances avec les autres équipes logicielles, la couverture des tests, les équipes d’assurance qualité, les tests d’intégration système, la performance, l’évolutivité et le respect des délais clients — cela représente une charge supplémentaire importante.

Il faut aussi prendre en compte les livrables des équipes d’infrastructure, de gestion des branches, de DevOps, ainsi que les attentes du terrain, la documentation technique et les messages destinés aux équipes commerciales et aux clients. Tous ces aspects transversaux doivent être pris en charge par quelqu’un. Je pense que les responsables de programmes techniques, avec l’aide de tous ces outils, peuvent le faire beaucoup plus efficacement et rapidement, mais le travail doit être réalisé.

Si vous attendez des directeurs et responsables de l’ingénierie logicielle qu’ils s’en chargent également, vous leur imposez une charge supplémentaire. Il faut aussi penser à l’analogie de la sécurité routière. Nous avons les services chargés de délivrer les permis, d’immatriculer les véhicules et de faire connaître les règles de circulation. Mais nous avons également la police autoroutière, qui délivre des contraventions et veille à ce que les personnes qui enfreignent les règles soient sanctionnées grâce à des contrôles aléatoires ou systématiques.

Il faut ces deux éléments pour qu’un système fonctionne correctement. On ne peut pas se contenter de délivrer les permis, d’immatriculer chaque véhicule et d’enseigner la conduite sûre en espérant ensuite obtenir un bon résultat. Il faut des contrôles et des contrepoids.

Galen Low : J’aime vraiment cette idée, car une grande partie des rôles évolue actuellement grâce à l’automatisation, notamment la gestion des programmes techniques et l’ingénierie logicielle. On entend parfois que les organisations peuvent automatiser les cadres et les règles afin que chacun les suive simplement.

Mais comme vous le dites, ce n’est pas ce que les humains font le mieux. Il y aura toujours des personnes qui rencontreront des problèmes, qui contourneront volontairement les règles ou qui ne comprendront pas les priorités. Il faut donc toujours quelqu’un pour accompagner le processus.

Moins qu’avant, certes, mais cette fonction conserve sa valeur. De nombreuses pièces doivent s’assembler pour livrer un produit logiciel, et seule une partie concerne la qualité du code. Le reste relève de l’orchestration transversale nécessaire pour que tout soit livré au bon moment.

Si vous êtes occupé à gérer une équipe d’ingénieurs logiciels, à mener des entretiens individuels, à gérer leur carrière, à auditer la qualité du code et à résoudre des problèmes techniques, cela devient difficile à concilier avec la responsabilité de la livraison. Il faudrait arbitrer entre deux priorités importantes.

Satish Menon : Tout à fait. La gestion des dépendances et la coordination entre plusieurs équipes restent essentielles. Les responsables de programmes techniques peuvent utiliser les outils disponibles pour identifier les signaux précurseurs, comprendre les risques et faciliter la résolution des problèmes avant qu’ils ne deviennent coûteux.

Galen Low : C’est une excellente transition. Le rôle évolue, sous l’effet de l’IA et des changements dans le développement logiciel, mais aussi parce que de nombreuses professions se transforment. Quelles sont aujourd’hui vos attentes envers vos équipes de responsables de programmes techniques ?

Satish Menon : Les ingénieurs logiciels travaillent dix fois, voire cent fois plus vite qu’avant. Nous devons en faire autant.

Nous devons cesser de produire des rapports manuels ou de recueillir manuellement l’état d’avancement. Nous devons utiliser des tableaux de bord automatisés et en temps réel, puis vérifier les signaux rouges et jaunes en les comparant aux données d’autres outils.

Par exemple, si Jira indique qu’un élément est presque terminé, mais que l’évaluation de GitHub et de Claude ne correspond pas, cela constitue un signal d’alerte. En examinant le cycle de développement — de l’écriture initiale du code aux validations, aux demandes d’intégration et aux revues — nous pouvons détecter rapidement qu’il existe une incohérence avec le rapport Jira.

De même, pour les tests, il faut examiner ce que BrowserStack indique concernant la qualité, le déploiement dans le nuage, les tests et la préproduction. En combinant ces informations, on obtient une évaluation plus riche.

Si nous ne nous adaptons pas à ces changements et à ces nouvelles façons de réfléchir à l’état du projet et à la création de valeur, notre rôle finira par devenir obsolète. Mais si nous évoluons avec eux, ce sont les personnes capables de s’adapter qui continueront à apporter le plus de valeur.

Galen Low : J’aime cette idée de permettre la montée en charge et la création de valeur. Il ne s’agit plus d’être un goulot d’étranglement parce que nos méthodes sont dépassées, mais de participer activement au fonctionnement des équipes et à la résolution des problèmes.

Satish Menon : Il existe tout un éventail de possibilités. Les responsables de programmes techniques très techniques peuvent parfois résoudre directement des problèmes techniques, mais ce n’est pas la norme. Un responsable de programme technique doit surtout comprendre, à partir d’un problème donné, quelle équipe est en difficulté, quelle aide lui manque et quelles autres équipes pourraient contribuer.

S’il existe une équipe plateforme en retard et que cela menace la livraison d’une fonctionnalité prioritaire, il faut s’assurer que le travail de cette équipe est priorisé. Il faut également être capable de réfléchir avec le responsable de l’ingénierie et de proposer des pistes concrètes.

Même une solution réalisée à 70 % peut constituer un excellent point de départ. Si vous arrivez avec des suggestions, que vous réunissez les bonnes personnes et que vous formulez clairement les prochaines étapes, vous réduisez le travail que les responsables techniques doivent accomplir eux-mêmes. C’est une contribution importante.

Galen Low : J’aime beaucoup cette expression de solutions réalisées à 70 %. Apporter quelque chose de partiellement élaboré, qui n’est pas définitif mais constitue un point de départ, peut accélérer la collaboration.

Satish Menon : Le responsable de programme technique ne réalise pas nécessairement lui-même le codage intuitif des démonstrations destinées aux clients. Il supervise plutôt le processus, coordonne les responsables produit et les ingénieurs, veille à la qualité des démonstrations et contribue à recueillir les exigences supplémentaires.

Galen Low : Tout le monde avance plus vite aujourd’hui, mais la collaboration reste précieuse. Une préversion de recherche ne peut pas être créée sans l’ingénierie. Les équipes produit, ingénierie et gestion de programmes doivent travailler ensemble pour comprendre la valeur, faire progresser le projet et réduire les risques liés à la livraison.

Satish Menon : Les premières démonstrations et préversions de recherche peuvent être produites rapidement grâce au codage intuitif réalisé par les ingénieurs, les responsables produit ou les équipes de conception. Nous ne sommes plus limités à la présentation de maquettes Figma pour expliquer le fonctionnement d’un produit.

Galen Low : Parlons du recrutement. Préféreriez-vous embaucher un ancien développeur devenu excellent responsable de programme, ou un responsable de programme expérimenté qui ne sait même pas ce qu’est une demande de fusion ?

Satish Menon : Comme je l’ai indiqué, les responsables de programmes techniques qui ont déjà codé possèdent souvent un avantage. Mais il existe des exceptions. Certains ont appris en travaillant étroitement avec des développeurs et en comprenant leur façon de travailler.

Je cherche donc surtout à évaluer le résultat. Peu importe qu’ils aient été développeurs auparavant ou qu’ils aient acquis cette compréhension par la suite : peuvent-ils parler efficacement le langage des ingénieurs, des responsables produit et des concepteurs ? C’est ce que j’évalue.

Cependant, les possibilités d’entrer aujourd’hui dans un rôle de responsable de programme technique logiciel sans expérience du code sont plus limitées. Il y a quinze ans, un responsable de programme matériel pouvait plus facilement rejoindre un projet logiciel et apprendre sur le terrain. Aujourd’hui, les entreprises recherchent davantage des personnes immédiatement opérationnelles.

Galen Low : C’est une perspective très réaliste. Cela ne signifie pas que l’absence d’expérience d’une demande de fusion empêche automatiquement d’obtenir un poste, mais il faut être prêt à se former et à saisir toutes les occasions de parler le langage des équipes transversales.

Satish Menon : Certains responsables du recrutement se limitent à des questions situationnelles non techniques. Ce n’est pas mon approche. Je prépare une série de questions spécifiques pour évaluer les connaissances techniques attendues, en les adaptant au parcours du candidat et aux affirmations de son CV.

J’évalue la maîtrise technique du candidat, à la fois dans le domaine du produit qu’il a livré et dans le fonctionnement général du développement logiciel. J’ajoute ensuite des questions situationnelles portant sur les relations humaines et l’intelligence émotionnelle. Cette méthode d’entretien structurée et objective m’a été inspirée par Google.

Galen Low : Pouvez-vous nous donner un exemple de question situationnelle permettant d’évaluer les connaissances techniques d’un candidat ?

Satish Menon : Si une personne affirme avoir travaillé dans un environnement logiciel-service et avoir optimisé la livraison pour l’accélérer, je peux lui demander ce qui différencie la livraison d’un logiciel-service d’une livraison sur site, quels raccourcis ont été pris et pourquoi.

Je peux également lui demander de détailler un produit qu’elle a livré, les fonctionnalités concernées et la valeur apportée aux clients. Cela permet de vérifier qu’elle n’a pas seulement superposé un processus à un cycle de développement sans comprendre le produit lui-même.

Je pose aussi des questions sur le cycle de développement, les pratiques de DevOps, la différence entre la préproduction et la production, ainsi que les contrôles permettant d’éviter l’introduction de vulnérabilités de sécurité.

Galen Low : Si, à l’avenir, le rôle hybride de responsable d’équipe logicielle et de responsable de programme technique devenait dominant, quel serait son impact ?

Satish Menon : Nous devons nous concentrer sur ce que nous pouvons contrôler. Nous pouvons rester en avance sur les possibilités offertes par les outils et continuer à apporter de la valeur à la livraison des produits.

Il faut penser de manière transversale, multi-équipe et interdisciplinaire. C’est à l’intersection de plusieurs fonctions réunies pour livrer un produit que notre valeur est la plus importante.

Au niveau le plus simple, cela concerne plusieurs équipes d’ingénierie. Puis viennent l’ingénierie et l’assurance qualité, ensuite l’ingénierie, l’assurance qualité, le DevOps et la documentation technique. À un niveau supérieur, il faut coordonner les équipes produit avec les équipes commerciales, la réussite client, le support, les ingénieurs avant-vente et les services proposés aux clients.

Il faut également tenir compte des lancements, des messages marketing, des partenariats entre entreprises et des livraisons communes. Le rôle consiste à orchestrer tous ces éléments et à résoudre des problèmes transversaux de plus en plus vastes.

Galen Low : J’aime beaucoup cette idée. Nous sommes au centre de cette orchestration. Si le rôle est supprimé et devient uniquement centré sur l’ingénierie logicielle, nous perdons toute la valeur liée à la complexité, aux partenaires, aux équipes et aux disciplines différentes.

C’est pourquoi il doit rester distinct. Mais il exige une compréhension approfondie. Nous ne pouvons pas simplement cocher des cases et appliquer des cadres à des produits que nous ne comprenons pas. Nous devons savoir où se trouve la valeur, comment le produit est construit et comment contribuer à sa livraison de façon pertinente et efficace.

Satish, merci beaucoup pour le temps que vous m’avez accordé aujourd’hui. C’était passionnant. Où les auditeurs peuvent-ils en apprendre davantage sur vous ?

Satish Menon : Il suffit de me chercher sur LinkedIn.

Galen Low : Merci encore.

Satish Menon : J’ai beaucoup apprécié notre conversation, Galen. Merci pour cette occasion.

Galen Low : Très bien, tout le monde. C’est la fin de cet épisode du podcast du Digital Project Manager. Si cette conversation vous a plu, pensez à vous abonner sur la plateforme où vous nous écoutez. Et si vous souhaitez encore plus d’informations pratiques, d’études de cas et de guides opérationnels, créez un compte gratuit sur thedigitalprojectmanager.com.

À la prochaine, merci de nous avoir écoutés.