À quoi ressemble l’excellence en ingénierie à l’ère de l’IA ?

Lisez la transcription :

Nous essayons d’utiliser un programme pour transcrire nos podcasts. Merci de pardonner les fautes de frappe, le robot n’étant pas fiable à 100 %.

Hannah Clark : On en rigole beaucoup, mais l’ère de l’IA semble avoir signé l’arrêt de mort de tous les métiers de la tech. Cette année, tant de postes ont disparu que je m’étonne de ne pas avoir été invitée à plus de funérailles ! Le product management est mort, la recherche utilisateur est morte, et pire que tout, l’ingénierie logicielle est morte. Je prêche sans doute un convaincu, mais toute personne qui pense vraiment que l’ingénierie logicielle est morte parce que votre LLM du coin peut coder n’est clairement pas ingénieur lui-même.

Mon invité aujourd’hui, Anish Dhar, fondateur de Cortex.io irait même jusqu’à dire que l’ingénierie est loin d’être morte. Elle n’a fait que grandir. Ancien ingénieur chez Uber, Anish a fondé Cortex pour simplifier la compréhension des bases de code complexes. Ingénieur lui-même et s’adressant principalement à des ingénieurs, il est témoin d’une véritable évolution de l’excellence en ingénierie ainsi qu’un décalage entre l’ancienne et la nouvelle façon de la mesurer. Nous avons partagé des réflexions de nouvelle génération sur la mesure et l’évaluation de l’excellence en ingénierie, ainsi qu’un avis tranché sur la tendance du « vibe coding » et sa place dans le débat. Allons-y.

D’ailleurs, nous proposons ce type de conversations chaque semaine, alors si cela vous intéresse, abonnez-vous dès maintenant. C’est parti.

Ravi de vous retrouver sur le podcast The CPO Club. Aujourd’hui, je reçois Anish Dhar, fondateur de Cortex.io.

Anish, merci de prendre le temps d’échanger avec moi aujourd’hui.

Anish Dhar : Merci beaucoup pour l’invitation.

Hannah Clark : Peux-tu nous parler un peu de ton parcours et de ce qui t’a mené à ton poste actuel ?

Anish Dhar : Bien sûr. Je suis le cofondateur et PDG de Cortex.io. Nous avons démarré l’entreprise il y a environ six ans, mais auparavant j’étais ingénieur chez Uber. J’ai vraiment commencé ma carrière là-bas et nombre de difficultés que j’y ai rencontrées m’ont inspiré pour la création de Cortex.

Deux de mes amis très proches y ont également trouvé des défis similaires. Uber possède une architecture de services interne massive. En tant qu’ingénieur, il était très difficile de capter les différentes parties du code, surtout à mon arrivée. Il y avait énormément de services en développement. Cette complexité extrême m’a poussé à discuter avec l’un de mes amis, ingénieur dans une toute petite startup nommée Lend.

Ils n’avaient qu’une centaine d’ingénieurs alors qu’Uber en comptait plus de mille. Pourtant, nous étions confrontés aux mêmes difficultés pour organiser et comprendre l’architecture de nos services. Cela a fait tilt : si Uber, à très grande échelle, et une startup qui débute sur les microservices rencontrent les mêmes problèmes, c’est que l’industrie tout entière doit y faire face.

Nous avons donc décidé de lancer l’entreprise, participé à la promotion Winter 20 de Y Combinator, et aujourd’hui, nous venons de réaliser notre série C et sommes utilisés par plusieurs centaines d’entreprises qui utilisent Cortex pour gérer leur complexité.

Hannah Clark : Incroyable parcours, et c’est toujours fascinant de voir une entreprise naître d’un problème que l’on connaît intimement.

Justement, nous allons parler de l’excellence en ingénierie et de ce que cela signifie dans la tech actuelle. C’est évidemment une question que tu as côtoyée de près tout au long de ton parcours. Pour commencer, comment définis-tu l’excellence en ingénierie en 2025, et pourquoi est-ce devenu une priorité pour les CTO et VP ingénierie ?

Anish Dhar : C’est une excellente question. Chez Cortex, nous avons remarqué que cette notion s’est longtemps focalisée sur l’expérience développeur. L’expérience développeur reste un élément clé de toute organisation de développement : il s’agit de choses simples, comme faciliter l’intégration des nouveaux arrivants pour qu’ils soient connectés efficacement à GitHub et aux outils, ou encore que les infrastructures soient prêtes pour limiter le dépannage ou les étapes intermédiaires à la mise en production.

Cependant, nous avons vu ces dernières années un glissement de l’expérience développeur vers ce que nous appelons l’excellence en ingénierie. La différence majeure ? L’excellence en ingénierie fait le lien entre les différentes équipes techniques et les résultats business de l’organisation.

On pense à des équipes SRE, sécurité, productivité développeur, expérience développeur, mais aussi à l’impact de leur travail sur les objectifs de l’entreprise. C’est cela, la clé : relier les initiatives techniques à des retombées que le business valorise vraiment.

Prenons l’exemple d’une organisation axée sur la fiabilité client : une expérience utilisateur fiable génère davantage de revenus car le produit sera plus utilisé. L’équipe SRE pourra, dans cette logique d’excellence, mettre en place une checklist de pré-production que tous les services devront valider avant déploiement, afin de s’aligner sur les standards de l’organisation. On voit bien comment une action SRE contribue à un objectif business réel.

Il est donc crucial de penser les initiatives sous cet angle, car cela renforce leur valeur, les aligne avec les attentes business, et c’est précisément le cœur de l’excellence en ingénierie.

Hannah Clark : Intéressant… Et c’est, j’imagine, comme tu l’as sûrement déjà expliqué, un voyage sans fin où de nombreux métiers travaillent de concert.

Parle-moi de votre framework : quels en sont les piliers ? Comment abordez-vous l’excellence chez Cortex ?

Anish Dhar : Tu as raison, c’est vraiment un chemin sans fin. Beaucoup de nos clients, qu’ils soient start-ups IA natives ou grands groupes avec un lourd héritage technique, mettent en place des initiatives autour de l’excellence en ingénierie. Cela nécessite une approche réfléchie sur ce qui a du sens pour l’entreprise et quel impact sur ses objectifs business.
D’un point de vue méthodologique, la définition démarre selon moi par l’excellence business. C’est-à-dire par les grands objectifs : stimuler l’innovation et réduire le time-to-market, baisser les coûts et gagner en efficacité, et généralement en troisième : améliorer la qualité produit et la satisfaction client.

Sous ce niveau, on retrouve les piliers de l’excellence en ingénierie, à travers diverses équipes expertes qui lancent des initiatives pour soutenir ces ambitions : vélocité, efficacité, sécurité, fiabilité… On retrouve aussi des sous-catégories, comme un plan de migration sécurité ou la mise en place d’un processus de gestion d’incidents.

À la base de tout, il y a ce que nous appelons les « 4 C » : visibilité complète, amélioration continue, expérience développeur cohérente, et enfin, propriété claire. Sans ownership ni compréhension précise des différentes parties de votre code ou de vos services, difficile d’avancer. Les portails internes sont souvent, sinon indispensables, au moins des fondations solides pour comprendre l’écosystème et piloter l’excellence en ingénierie.

Hannah Clark : Je voudrais approfondir ce que tu dis sur la mesure de la performance : il existe une certaine tension autour de la productivité des développeurs, de la mesure par indicateurs comme le nombre de lignes de code, qui reste parfois controversée. Comment un leader technique doit-il appréhender ce sujet de manière plus holistique, en intégrant ces fameux « C » et au-delà ?

Anish Dhar : Oui, c’est une vraie question. Pendant longtemps, beaucoup d’entreprises ont mesuré la productivité par le nombre de lignes de code ou les métriques DORA, avec différents frameworks simplifiant la notion de productivité… et il y a une part de vérité là-dedans, non ? Clairement, un nombre de lignes écrites n’est pas un bon indicateur : si vous livrez 0 lignes chaque trimestre, c’est qu’il y a un vrai souci. Et parfois, comparer les équipes sur ces métriques reste intéressant.

Mais la discussion a changé : au-delà des chiffres, la question est “comment embarquer les ingénieurs pour qu’ils s’approprient et améliorent ces indicateurs ?” Là est la vraie difficulté. N’importe qui peut interroger l’API GitHub pour obtenir une photo des performances de l’équipe. Mais leur montrer les chiffres et dire “améliorez ce KPI” n’a aucun sens pour un ingénieur qui se focalise sur des résultats concrets pour le business.

Désormais, les CTO cherchent surtout à relier l’excellence aux enjeux business et à retranscrire les indicateurs dans le langage de ce qui a du sens à l’échelle de l’équipe ou du produit.

La productivité du développeur s’inscrit désormais dans une logique où les métriques racontent une histoire cohérente pour l’entreprise, tandis que l’enjeu pour l’équipe est de rattacher cette histoire à leur quotidien : qu’est-ce que cela implique dans mon travail ?

C’est vraiment le principal changement que j’observe.

Hannah Clark : Est-ce que tu constates l’abandon progressif de certaines méthodes d’évaluation ou KPIs obsolètes ? Quelle serait la nouvelle école de l’évaluation, as-tu des exemples précis ?

Anish Dhar : Oui. Je pense qu’on peut voir la productivité à travers deux prismes : les métriques d’entrée (input) et les métriques de sortie (output). Les output, ce sont les frameworks classiques, comme les DORA, qui ambitionnent de donner une vue globale sur la performance d’une équipe.

La plupart des organisations souhaitent voir et suivre ces métriques, mais le vrai enjeu reste « comment les influencer concrètement ». Chez nos clients, ce qui fait la différence, c’est la prise en compte des input metrics, qui influencent directement les output metrics.

Par exemple, prenons la fréquence de déploiement. C’est un super indicateur, parce que le rythme de déploiement prédit souvent la capacité à livrer vite, donc à distancer la concurrence. Si une entreprise choisit ce KPI, ok, on affiche ce tableau de bord, on en fait un objectif collectif : “nous déployons deux fois par semaine, passons à quatre”. Mais côté ingénieur, comment agir à son échelle, sur les services dont il est responsable ?

Déployer plus vite suppose-t-il plus d’anomalies ? Est-ce que la fiabilité va baisser ? Beaucoup de paramètres entrent en jeu, et c’est là que les input metrics deviennent indispensables.

Un exemple de client : O’Reilly. Ils suivaient leur fréquence de déploiement grâce à Cortex, et ils se sont rendu compte qu’il fallait non seulement pousser à livrer plus vite, mais aussi installer des garde-fous et des guidelines claires sur la fiabilité. En effet, vouloir aller plus vite augmentait la probabilité de bugs. Ils ont donc mis en place une checklist de préparation à la mise en production, représentant huit ou neuf « input metrics » pour évaluer la santé du processus de déploiement.

Ces indicateurs sont, par exemple : un système d’astreinte bien en place, un build qui passe, des tests fonctionnels sur vos services, etc. Cela a permis aux ingénieurs d’avoir des repères concrets pour leurs services. Résultat : augmentation progressive de la fréquence de déploiement (de 2 à 4 fois par semaine pour les services critiques), et baisse des incidents.

Pour résumer, aujourd’hui les entreprises comprennent qu’il faut combiner une vision “output” et “input” pour traduire cela dans le quotidien des développeurs et progresser sur la productivité.

Hannah Clark : Oui, c’est beaucoup plus complet et global. Changeons légèrement d’angle tout en restant sur le sujet du “livrer plus vite”. Impossible d’évoquer l’ingénierie de 2025 sans parler du « vibe coding ».

Parlons de ces outils IA qui transforment actuellement les workflows de développement. Je t’ai entendu dire qu’on ne pouvait pas “vibe coder” jusqu’à un million d’utilisateurs par jour : vrai hot take ? Selon toi, quelle est la réalité face au buzz — l’IA pour le développement à l’échelle production ?

Anish Dhar : Oui, grand sujet du moment. Toutes les entreprises tech réfléchissent à intégrer ou ont déjà adopté des assistants de code IA comme Cursor par exemple. Même notre équipe chez Cortex en utilise dans ses routines de développement.

Ce que nous observons en interne, et chez nos clients, c’est que ces assistants sont excellents pour valider rapidement une idée, prototyper des interfaces en front ou passer de la théorie à la maquette. Cela fonctionne à merveille si l’on veut esquisser une solution, ou si on est entrepreneur et qu’on souhaite concrétiser rapidement un concept. Cette phase de prototypage rapide connaît un essor phénoménal grâce à l’IA.

Mais, dans la réalité, le code généré par vibe coding ne saurait alimenter un système de production supportant des millions d’utilisateurs. C’est mon expérience : au mieux, le vibe coding correspond à un ingénieur junior qui apprend à coder, tandis que pour concevoir et opérer des architectures à grande échelle, on a encore besoin de seniors maîtrisant l’architecture système et la robustesse en production. L’IA progresse à une vitesse folle, et il serait périlleux de parier contre, mais à aujourd’hui, aucune grande entreprise ne met son système critique en prod grâce au vibe coding.

Cela dit, la productivité s’améliore réellement grâce aux assistants IA, mais sur des tâches différentes de celles mises en avant par le buzz.

Hannah Clark : C’est un point de vue qui parlera à beaucoup de pros qui voient l’excitation du grand public autour de l’accessibilité de leur métier grâce à l’IA… Mais ce n’est pas pour autant que la disruption est immédiate.

C’est important d’en parler. Pour les responsables qui doivent arbitrer entre investissement dans des outils IA et effectifs, quels sont tes conseils ? Comment évaluer l’impact de l’IA sur la productivité et l’intégrer au budget ?

Anish Dhar : Question complexe, multi-facettes. D’abord, du point de vue macro, les leaders techniques qui freinent l’accès à ces outils se privent d’un avantage sur le long terme. Car dans dix ans, la majeure partie du code initial sera assistée par IA, permettant de prototyper et d’itérer dix fois plus vite qu’avant, sans se soucier de la scalabilité ou d’optimisation : cela change la donne pour toute équipe qui lance de nouveaux produits.

Les organisations qui laissent leurs équipes explorer ces outils l’intègrent jusque chez les non-techniques : chef de produit, data scientists, TPM, qui comprennent la technique et peuvent désormais prototyper ou interagir plus efficacement. C’est pour moi une raison suffisante pour allouer du budget à ces expérimentations.

La vraie question reste celle du gain réel de productivité. Toutes les entreprises se la posent : Cortex est souvent acheté avec Copilot, et les clients veulent mesurer si la promesse de « 3 à 4 fois plus de productivité » est réelle. Or, il ne suffit pas d’observer la fréquence de déploiement. Peut-être qu’on va plus vite, mais au détriment de la qualité et de la fiabilité ? Il faut adopter une approche globale en croisant les métriques output et input…

L’enjeu business demeure : est-ce que l’assistant IA aide vraiment à franchir un cap crucial ? Il faut du temps pour cerner les leviers, mais le pire serait de succomber au buzz, acheter des milliers de licences et six mois plus tard, n’avoir aucun impact ! Il faut une stratégie claire pour piloter l’introduction des outils et effectuer régulièrement des revues d’impact.

Hannah Clark : Je partage cet avis. Il y a énormément de pression pour maîtriser ces outils et trouver leur juste place dans le workflow, dans toutes les équipes. Et parfois, l’écart entre volume de production et qualité reste immense : il est crucial d’être intentionnel, pas seulement en ingénierie. Les outils doivent s’intégrer de manière à renforcer notre capital humain, pas juste réduire les effectifs d’un coup de baguette magique.

C’est passionnant de voir tout le monde chercher la bonne réponse en même temps, même si cela rend l’époque déroutante quand on travaille dans la tech. À propos de la généralisation de l’IA dans le développement et de la recherche de qualité : comment maintenir code review, sécurité, fiabilité, tout en restant à la pointe de l’innovation et en tirant le meilleur des outils ?

Chez Cortex par exemple, quelle est votre approche ?

Anish Dhar : Très bonne question. Je dirais que l’idée que l’IA remplace les ingénieurs est farfelue. Ce qui change, c’est que pour démarrer, on pourra se permettre de recruter moins d’ingés – car à l’itération, l’IA fait gagner considérablement de temps et permet de tester plein d’idées. Mais en prod réelle, dire que les entreprises embauchent moins grâce à l’IA, c’est plutôt bon pour la presse à sensation !

Hannah Clark : Sans citer de noms, hein…

Anish Dhar : (rires) Oui ! Mais globalement, le recrutement d’ingénieurs restera crucial. Concernant l’impact de l’IA sur fiabilité, sécurité… honnêtement, c’est l’une des plus grandes inconnues. Cela effraie – à raison – beaucoup d’équipes SRE, sécurité, Excellence Opérationnelle : ces outils augmentent la surface de code, donc la complexité globale du système. Plus on construit avec l’IA, plus on perd en compréhension fine du code : lors d’un incident, comment diagnostiquer rapidement si tout n’a pas été écrit et validé par l’équipe ?

C’est là le principal point faible aujourd’hui, et cela rend la base “visibilité / propriété” encore plus indispensable à l’excellence en ingénierie. Plus votre code est co-généré par IA, moins vous avez de maîtrise sur les responsabilités et la visibilité : cela inquiète beaucoup les équipes sécurité-fiabilité. Avec Cortex, nous le vivons aussi : tout code généré par IA est explicitement annoté et relu avec attention. On observe aussi la montée du “test assisté par IA”. Cela reste délicat : l’IA fait du bien, mais un système où 80 % est généré automatiquement, c’est un futur compliqué en cas d’incident ou de faille sécurité…

Hannah Clark : Tout à fait, il y a un besoin fort de supervision supplémentaire pour accompagner la massification de la production. Un exemple récent : le VP produit de Mastercard Gateway expliquait que l’IA accélère la complétion des formulaires réglementaires pour rentrer sur des marchés, mais qu’il faut autant de vigilance et d’ownership sur ce qui est envoyé. Être rapide, oui ; être redevable, tout autant.

C’est un goulot d’étranglement logistique pour beaucoup d’équipes, y compris en ingénierie, avec la montée en puissance de l’IA ! Il faut souligner ce point : tenir la cadence, c’est bien, mais être responsable du même niveau, c’est tout aussi crucial. Merci beaucoup pour cet échange si riche. Dernière question : où peut-on te suivre en ligne, Anish ?

Anish Dhar : Je suis sur LinkedIn et Twitter, en cherchant mon nom, vous me trouverez. Cortex est aussi présent sur LinkedIn.

Nous organisons d’ailleurs des sommets Engineering Excellence partout dans le monde, rejoignez-nous si l’un passe près de chez vous ! C’est un plaisir de fédérer une communauté autour de ces sujets parfois complexes mais essentiels, auxquels chaque entreprise est confrontée.

Nous avons aussi lancé notre conférence IDPCON dédiée à l’excellence en ingénierie, avec des speakers venues de tous types d’entreprises et de nombreux développeurs. Ça se tient à New York en octobre : venez nous rencontrer si vous êtes du coin !

Hannah Clark : C’est parfait. Merci beaucoup, on mettra le lien en description, et merci pour le temps que tu nous as consacré aujourd’hui !

Anish Dhar : Merci à vous, c’était super.

Hannah Clark : Merci à toutes et tous pour votre écoute. Pour encore plus d’analyses, de guides pratiques et d’avis sur les outils du marché, abonnez-vous à notre newsletter sur theproductmanager.com/subscribe. D’autres entretiens comme celui-ci sont disponibles en vous abonnant au CPO Club via votre appli de podcasts préférée.