Comment l'IA redéfinit le Product Management et la qualité produit

Chaque conversation sur l'IA semble finir de la même façon.

Quelqu'un prédit que les Product Managers vont disparaître. Un autre affirme que les équipes d'engineering vont fondre de moitié. Un troisième insiste : les boîtes qui adoptent l'IA aujourd'hui dépasseront forcément toutes les autres demain.

Dans les organisations produit, pourtant, les conversations sont souvent bien plus pragmatiques. Les dirigeants cherchent à comprendre où l'IA crée vraiment de la valeur, quels workflows s'améliorent réellement, comment les rôles évoluent, et quelles parties du développement produit restent fondamentalement inchangées.

C'est cet écart entre le discours public et la réalité du terrain qui a rendu cette discussion si intéressante.

J'ai échangé avec Geoffrey Janvier, Nathalie Edlinger et Arthur Rougier pour explorer comment l'IA transforme les organisations Produit et Engineering de l'intérieur. À eux trois, ils ont dirigé des équipes dans des startups, des scale-ups et certains des plus grands éditeurs de logiciels d'Europe, en expérimentant l'IA dans le développement produit, l'engineering, le leadership et le design d'organisation. Leur expérience donne une vision concrète de ce qui change aujourd'hui, au-delà du buzz.

‍

Au fil de la discussion, une idée est revenue sans cesse.

L'IA accélère sans aucun doute le code, la documentation et beaucoup de tâches individuelles. Mais son impact le plus fort vient de la façon dont elle transforme la collaboration entre les équipes.

Les Product Managers passent moins de temps à écrire des spécifications détaillées et plus de temps à créer un contexte partagé. Les ingés passent de l'écriture de chaque ligne de code à la revue, l'orchestration et le pilotage de systèmes de plus en plus autonomes. Les dirigeants arrêtent de penser en gains de productivité individuels et commencent à repenser le fonctionnement de toute l'organisation.

Les boîtes qui tirent le plus de valeur de l'IA combinent des modèles puissants avec de nouvelles façons de travailler. Quand les équipes repensent leur manière de collaborer, la transformation devient autant organisationnelle que technologique.

Disclaimer : les choix d'organisation et les solutions techniques partagés dans cette newsletter ne sont pas faits pour être copiés-collés tels quels. Garde toujours en tête le contexte de ta boîte avant d'adopter quelque chose qui marche ailleurs ! 😊

‍

Les meilleurs Product Leaders redeviennent des builders

L'une des idées les plus fortes de la discussion : l'IA ne rend pas le Produit moins stratégique. Elle change l'endroit où les leaders produit passent leur temps.

Ces dix dernières années, les Product Managers seniors et les CPOs se sont peu à peu éloignés de l'exécution. À mesure que les organisations grandissaient, leur rôle s'est de plus en plus concentré sur la priorisation, la gestion des parties prenantes et l'alignement de l'organisation. La discovery se terminait souvent par une spécification transmise à l'Engineering, et transformer une idée en quelque chose de concret dépendait de la capacité de développement disponible. L'IA commence à supprimer cette dépendance.

Geoffrey y voit une nouvelle forme d'indépendance pour les équipes Produit. Au lieu de dépendre des ingés pour chaque prototype, proof of concept ou première expérimentation, les Product Managers peuvent désormais valider leurs idées seuls. Ils peuvent explorer différentes pistes, écarter les concepts faibles et itérer plusieurs fois avant d'impliquer l'Engineering. Quand les ingés rejoignent le processus, les hypothèses produit ont déjà été testées, ce qui leur permet de concentrer leur expertise sur la construction de solutions avec plus de confiance et d'impact.

Nathalie a illustré ce changement avec un exemple concret tiré de sa propre équipe. Comme beaucoup d'organisations produit, ils avaient accumulé des dizaines de petites améliorations dont tout le monde reconnaissait qu'elles rendraient le produit meilleur, sans qu'aucune n'arrive jamais en haut de la roadmap. Les initiatives plus grosses passaient toujours avant. Dès que le développement assisté par l'IA a permis au Produit de contribuer directement aux petits changements, ces améliorations oubliées depuis longtemps sont soudain devenues faisables. Prise seule, chaque modification était presque invisible. Ensemble, elles ont créé une expérience utilisateur nettement meilleure. La valeur venait du déblocage d'un travail que personne n'avait jusque-là la capacité de traiter.

Arthur pense que cette évolution renforce l'essence du Produit plutôt qu'elle ne la change. Comme le logiciel devient plus facile à construire, l'avantage concurrentiel se déplace vers la capacité à comprendre assez bien les clients pour identifier les bonnes opportunités. Les Product Managers passent moins de temps à traduire des idées en spécifications exhaustives et plus de temps à observer les utilisateurs, à rassembler du contexte et à valider des hypothèses. L'IA sait remarquablement bien générer des solutions, mais seulement si quelqu'un lui donne le bon problème à résoudre.

Mises bout à bout, ces visions mènent à la même conclusion. Le rôle du Product leadership s'élargit. Les meilleurs leaders produit combineront une compréhension profonde des clients avec assez d'autonomie technique pour explorer des idées seuls, apprendre plus vite et apporter à l'Engineering des opportunités déjà étayées par des preuves plutôt que par l'intuition.

‍

Le contexte devient la nouvelle spécification produit

Pendant des années, l'une des responsabilités clés du PM était de traduire les problèmes clients en spécifications détaillées. Meilleure était la spécification, plus fluide était la delivery. Des organisations produit entières se sont optimisées autour de ce passage de relais, en affinant user stories, cas limites et critères d'acceptation pour réduire l'incertitude avant que l'engineering commence à construire.

La discussion suggère que ce modèle devient discrètement obsolète.

La discussion a mis en lumière une évolution du rôle des spécifications. Les grands modèles de langage ne dépendent pas de longs documents d'exigences ; ils dépendent du contexte. Comme l'a souligné Nathalie, un système d'IA peut produire des résultats remarquablement bons quand il comprend le problème qu'il résout, pour qui il le résout et les contraintes dans lesquelles il doit travailler. La qualité de ce contexte compte souvent plus que la mise en forme ou le niveau de détail de la spécification.

Arthur a prolongé cette idée en décrivant l'évolution du rôle de Product Manager. Comme l'IA aide de plus en plus sur les idées d'implémentation, l'exploration d'interfaces et la génération de solutions, les Product Managers peuvent consacrer plus de temps à comprendre les clients. Observer les utilisateurs pendant l'onboarding, découvrir pourquoi les équipes sales bricolent des contournements et repérer les signaux subtils qui révèlent des besoins non couverts restent des parties essentielles de la discovery produit. Ces insights humains apportent le contexte qui permet aux équipes comme aux systèmes d'IA de construire de meilleurs produits.

Cela change la nature du travail produit. L'avantage concurrentiel vient de plus en plus d'une compréhension riche des clients, du business et du produit lui-même. Ce contexte devient la base sur laquelle l'IA s'appuie pour produire des résultats utiles. Plus le contexte est riche, plus les résultats sont pertinents. Quand le contexte est incomplet, l'IA peut encore produire un travail convaincant, mais elle a bien plus de chances de passer à côté du vrai problème.

Fait intéressant, Geoffrey a relié cette évolution à un changement d'organisation plus large. Si les équipes Produit peuvent valider des idées seules et que l'IA peut prendre en charge une part croissante de l'exécution, l'engineering n'attend plus que les spécifications arrivent. Produit et Engineering convergent alors progressivement vers le même objectif : réduire l'incertitude avant d'engager des ressources importantes. Dans ce monde, la spécification cesse d'être l'artefact central. La compréhension partagée devient l'actif qui compte le plus.

Vu sous cet angle, le rôle de Product Manager continue d'évoluer. À mesure que l'IA s'intègre au développement produit au quotidien, l'accent passe de la documentation des solutions à la création de clarté. Les Product Managers deviennent responsables de capter la réalité client, de formuler les bonnes questions et de donner aux humains comme à l'IA le contexte nécessaire pour prendre régulièrement de bonnes décisions.

‍

Ce sont les organisations qui créent la valeur de l'IA

À un moment, la conversation s'est complètement éloignée du Produit.

La discussion a moins porté sur les prompts, les copilotes ou les assistants de code, et davantage sur une question que tout dirigeant se pose en ce moment : où est le ROI ?

Étonnamment, aucun des trois invités n'a affirmé que l'IA génère déjà des retours spectaculaires dans les entreprises établies. Bien au contraire. Ils ont décrit des organisations qui expérimentent beaucoup, adoptent de nouveaux outils à un rythme impressionnant et suscitent beaucoup d'enthousiasme, tout en peinant encore à démontrer un impact business mesurable.

Geoffrey y voit une phase naturelle de l'adoption de l'IA. La plupart des boîtes investissent encore pour apprendre comment ces technologies s'intègrent à leur propre environnement, expérimentent de nouveaux workflows et identifient où l'IA crée une vraie valeur. Comme pour tout changement opérationnel important, les gains de productivité apparaissent progressivement, à mesure que les équipes adaptent l'organisation du travail et que les nouvelles pratiques entrent dans le quotidien.

C'est aussi pour ça que Geoffrey est revenu à plusieurs reprises sur l'organisation plutôt que sur les outils. Donner à chaque salarié l'accès au dernier assistant IA ne change pas fondamentalement le fonctionnement d'une boîte. Si les équipes continuent à travailler avec les mêmes process, les mêmes passages de relais et les mêmes goulots d'étranglement, l'IA accélère simplement une partie de la chaîne avant de buter sur la contrainte suivante. Le goulot se déplace. Il ne disparaît pas.

Nathalie a partagé un point de vue proche, sous un angle plus opérationnel. Mesurer l'IA uniquement en temps gagné passe à côté d'une grande partie du tableau. Parfois, l'IA permet un travail qui ne se faisait tout simplement pas avant. Parfois, elle améliore la qualité du travail existant. Parfois, elle permet aux équipes de tester des idées qui auraient été abandonnées avant, parce qu'elles étaient trop petites pour justifier un effort d'engineering. Aucun de ces gains n'est facile à capturer dans un tableur, et pourtant ils s'accumulent dans le temps pour donner un produit nettement meilleur.

Arthur a ajouté une autre dimension à la discussion en questionnant la pression que ressentent beaucoup d'organisations à déployer l'IA partout à la fois. Selon lui, beaucoup de boîtes cherchent encore des cas d'usage au lieu de résoudre des problèmes concrets. La tentation se comprend. Chaque annonce donne l'impression que les concurrents vont plus vite. Mais adopter l'IA sans avoir d'abord identifié où elle crée un vrai levier mène souvent à des expérimentations coûteuses, avec peu d'impact durable.

Mis bout à bout, leurs arguments suggèrent que l'impact de l'IA va au-delà de la productivité individuelle et touche le fonctionnement de l'organisation dans son ensemble. La plus grande valeur apparaît quand les boîtes repensent la façon dont les équipes collaborent, dont les décisions se prennent et dont le travail circule de l'idée à la production. Dans ce contexte, l'IA agit comme un catalyseur du changement organisationnel, qui encourage de nouvelles façons de travailler en parallèle de l'adoption technologique. Les organisations qui font évoluer à la fois leurs pratiques et leurs systèmes sont les mieux placées pour en tirer tout le potentiel.

‍

Les nouveaux goulots d'étranglement

Chaque rupture technologique promet la même chose : les équipes iront plus vite.

La réalité est généralement plus compliquée.

Au fil de la discussion, les trois invités sont tombés d'accord : l'IA augmente fortement la capacité d'exécution. Le logiciel s'écrit plus vite. Les prototypes se construisent en quelques heures au lieu de plusieurs semaines. Les équipes Produit peuvent valider des idées seules. Sur le papier, chaque étape du process de delivery devient plus efficace.

Pourtant, ça ne rend pas automatiquement les organisations plus rapides.

Ça change simplement l'endroit où elles ralentissent.

Arthur l'a illustré avec des exemples de boîtes qui expérimentent le développement logiciel AI-native. Des agents autonomes génèrent désormais une part importante de l'implémentation, pendant que les ingés guident, relisent et affinent le résultat. Ce nouveau workflow peut accélérer fortement la delivery, au point que certaines équipes bouclent en un seul sprint un travail qui prenait avant un trimestre entier.

Mais un autre problème apparaît vite. Le goulot se déplace en amont.

Les Product Managers doivent soudain fournir un contexte bien plus riche. Les designers doivent produire des systèmes plus clairs. Les revues deviennent plus exigeantes. Les mises en production demandent une gouvernance plus solide. L'Engineering va plus vite, mais chaque interface autour de l'Engineering devient plus critique.

Geoffrey observe exactement le même phénomène à l'échelle de l'organisation. L'une des plus grosses erreurs des dirigeants est de ne mesurer que la productivité d'une seule fonction. Si les développeurs deviennent deux fois plus productifs pendant que le Produit, la QA ou le DevOps continuent de fonctionner exactement comme avant, la boîte n'a pas résolu son problème, elle l'a simplement déplacé.

Il décrit l'adoption de l'IA comme une transformation globale plutôt qu'une optimisation locale. Chaque amélioration crée une pression ailleurs dans le système. Tant que l'organisation n'évolue pas dans son ensemble, les gains restent limités, parce qu'une autre équipe finit par devenir la contrainte.

C'est aussi pour ça que Geoffrey a insisté à plusieurs reprises sur le reskilling. À mesure que l'IA s'intègre au développement produit au quotidien, chaque discipline évolue avec elle. Les ingés passent plus de temps à relire et à orchestrer. Les Product Managers se concentrent davantage sur la création de contexte et la validation des opportunités. Les équipes qualité se spécialisent de plus en plus dans l'évaluation de systèmes probabilistes plutôt que de logiciels déterministes. Chaque fonction s'adapte à mesure que les nouvelles façons de travailler redessinent la manière de construire les produits.

Nathalie a ajouté une nuance importante. L'IA élargit l'éventail des modèles d'organisation possibles pour les équipes produit, au lieu de les faire converger vers un modèle unique. Pendant des années, les boîtes ont débattu du ratio idéal entre Product Managers et ingés : un PM pour cinq ingés, un pour huit, un pour deux. Désormais, ces choix refléteront de plus en plus le contexte de chaque organisation, la complexité de son produit et ses façons de travailler.

Ces débats risquent de perdre de plus en plus leur intérêt.

Chaque organisation adoptera l'IA à sa manière. Certains Product Managers deviendront très techniques et passeront une grande partie de leur temps à travailler avec des systèmes d'IA. D'autres resteront concentrés sur des problèmes clients complexes, où la discovery continue de primer sur l'exécution. La forme des équipes reflétera de plus en plus la nature du produit, plutôt qu'un benchmark copié sur une autre boîte.

Au fond, la discussion fait ressortir une leçon plus large sur l'adoption de l'IA. Quand la technologie accélère, les forces et les faiblesses du modèle opérationnel d'une organisation deviennent plus visibles. Les boîtes qui repensent la circulation du travail entre les équipes arrivent à amplifier les bénéfices dans le temps, alors que les organisations qui se concentrent sur l'accélération d'une seule fonction voient souvent des contraintes apparaître ailleurs dans le système.

Autrement dit, l'IA fait remonter la complexité organisationnelle à la surface, en montrant comment le travail, les décisions et la collaboration circulent dans la boîte.

‍

Les boîtes AI-native partent avec un avantage injuste

En fin de conversation, la discussion s'est éloignée des équipes pour aller vers une question plus large : qui va le plus profiter de l'IA dans les prochaines années ?

La discussion a ouvert une perspective plus large sur l'avantage concurrentiel. Geoffrey a expliqué que l'accès à la technologie IA se généralise. Les organisations peuvent désormais expérimenter avec les mêmes modèles de pointe, les mêmes assistants de code et, de plus en plus, les mêmes agents autonomes. À mesure que ces capacités deviennent accessibles, la différenciation dépend de plus en plus de la façon dont les boîtes les intègrent à leurs produits, leurs workflows et leurs organisations.

La vraie différence est ailleurs.

Les boîtes AI-native conçoivent leur organisation avec l'IA au cœur de la façon de travailler dès le premier jour. Les process, les rôles et la prise de décision évoluent avec ces capacités, ce qui crée des modèles opérationnels qui intègrent pleinement l'IA au quotidien, sans être freinés par des structures héritées.

Les entreprises établies font face à un autre défi.

La plupart ont passé des années à optimiser la collaboration entre Produit, Design, Engineering et Opérations. Ces process ont été conçus pour un monde où le logiciel coûtait cher à construire et où la capacité d'engineering était la principale contrainte. L'IA change cette hypothèse. Construire devient moins cher, itérer devient plus rapide et de nouveaux goulots apparaissent. Pourtant, beaucoup d'organisations continuent de mesurer leur succès avec la même gouvernance, les mêmes cycles de validation et les mêmes rituels de delivery.

C'est pour ça que la transformation paraît souvent plus lente dans les grandes organisations. La technologie peut être déployée en quelques semaines, alors que changer les habitudes, les responsabilités et les incentives prend des mois, voire des années. Geoffrey a souligné que cet écart explique pourquoi beaucoup de boîtes peinent à démontrer des retours significatifs malgré de gros investissements dans l'IA. La capacité d'une organisation à absorber le changement détermine de plus en plus la valeur qu'elle peut tirer de l'IA.

Arthur a ajouté un éclairage important. Les entreprises établies entrent dans l'ère de l'IA avec des actifs précieux : des relations clients de longue date, une expertise métier profonde et des années de connaissance produit accumulée. Une fois traduites dans le contexte riche dont les systèmes d'IA ont besoin, ces forces deviennent une puissante source de différenciation. Les organisations qui comprennent vraiment leurs clients sont bien placées pour obtenir des résultats plus pertinents, parce qu'elles donnent à l'IA un contexte ancré dans l'expérience du terrain.

Nathalie a ramené la discussion à l'exécution. Quelle que soit leur taille, les organisations qui progressent le plus vite sont celles où les équipes sont encouragées à expérimenter en continu. Les capacités de l'IA évoluent toutes les quelques semaines, ce qui rend vite obsolètes les plans à long terme. Les organisations gagnantes construisent des boucles d'apprentissage plutôt que des playbooks figés. Elles testent, s'adaptent et partagent ce qui marche dans toute la boîte, en acceptant que la meilleure pratique d'aujourd'hui puisse être obsolète dans un mois.

Mises bout à bout, ces visions donnent une lecture plus équilibrée du paysage concurrentiel. Les boîtes AI-native profitent de modèles opérationnels conçus autour de l'IA dès le départ, alors que les entreprises établies apportent une connaissance client riche, des produits matures et des équipes expérimentées. À mesure que la technologie évolue, l'avantage concurrentiel vient de plus en plus de la capacité d'une organisation à apprendre, à s'adapter et à repenser en continu sa façon de fonctionner.

‍

N'optimise pas l'organisation d'hier

S'il y a un avertissement qui est revenu sans cesse pendant la discussion, c'est celui-ci : beaucoup de boîtes abordent l'IA comme un projet technologique alors qu'elle devrait être traitée comme une transformation de l'organisation.

Cet état d'esprit est à l'origine de presque toutes les erreurs des dirigeants.

La première est d'adopter l'IA sans problème clair à résoudre. La pression pour « faire quelque chose avec l'IA » est énorme, et beaucoup d'organisations y répondent en déployant des copilotes, en expérimentant des agents ou en lançant des initiatives internes simplement parce que tout le monde fait pareil. La technologie fonctionne souvent exactement comme prévu, mais l'impact business reste difficile à identifier parce qu'aucune contrainte importante n'a été levée au départ.

La deuxième erreur est de mesurer le succès uniquement à travers la productivité individuelle. Faire gagner trente minutes par jour à un Product Manager ou aider un ingé à coder plus vite, ça impressionne, mais ces gains se traduisent rarement en meilleurs résultats si le reste de l'organisation continue de fonctionner de la même façon. Comme l'a expliqué Geoffrey tout au long de la discussion, les optimisations locales produisent rarement des améliorations systémiques. Elles déplacent simplement la contrainte ailleurs.

Autre thème récurrent : la tentation de garder les façons de travailler existantes en ajoutant l'IA par-dessus. Beaucoup d'organisations produit s'appuient encore sur des process conçus quand la capacité d'engineering était rare et le développement logiciel bien plus lent. Ces workflows comprennent souvent plusieurs étapes de validation, une documentation abondante et des passages de relais séquentiels entre équipes. L'IA accélère l'exécution, mais ces structures organisationnelles restent exactement là où elles étaient. Très vite, elles deviennent le principal obstacle à la vitesse.

La conversation a aussi remis en question une hypothèse plus subtile : l'idée que l'IA réduirait l'importance de la compréhension client. En réalité, c'est l'inverse qui semble se produire. Comme générer des solutions devient plus facile, identifier le bon problème a plus de valeur que jamais. Les équipes qui passent moins de temps avec les clients et plus de temps à expérimenter avec l'IA découvrent souvent qu'elles produisent des livrables soignés sans augmenter la valeur pour le client. La qualité du prompt ne pourra jamais compenser l'absence d'une vraie compréhension produit.

La leçon la plus importante est peut-être qu'il n'y a pas de destination stable qui attend au bout de cette transformation. Chaque invité a souligné, à sa manière, que les capacités de l'IA évoluent trop vite pour des modèles d'organisation figés ou des playbooks définitifs. Les boîtes qui progressent le plus ne sont pas celles qui pensent avoir déjà trouvé la réponse. Ce sont celles qui remettent en question en continu leur façon de travailler, encouragent l'expérimentation dans les équipes et adaptent leur modèle opérationnel à mesure que la technologie évolue.

À bien des égards, c'est peut-être le plus grand changement de tous. À mesure que les capacités de l'IA progressent, les organisations qui renforcent en continu leur capacité d'adaptation sont celles qui débloquent le plus de valeur sur le long terme.

• L'IA rend le logiciel moins cher à construire. Elle donne encore plus de valeur à la compréhension client et au jugement stratégique.
• Les Product leaders les plus efficaces excellent dans la création d'un contexte riche, qui permet aux humains comme à l'IA de comprendre les problèmes, de prendre de meilleures décisions et de construire de meilleurs produits.
• L'IA élargit le rôle des Product Managers en leur donnant l'autonomie d'explorer, de prototyper et de valider des idées avant d'impliquer l'Engineering.
• Mesurer l'IA à travers la productivité individuelle passe à côté de l'essentiel. Les plus gros gains viennent d'une nouvelle façon de faire travailler les équipes ensemble.
• L'IA transforme la circulation du travail, déplace les goulots d'étranglement dans l'organisation et fait de la pensée systémique une compétence de plus en plus importante.
• Livrer plus vite ne crée de la valeur que si les équipes continuent à résoudre les bons problèmes clients.
• Les boîtes AI-native ont une longueur d'avance parce qu'elles conçoivent leur modèle opérationnel autour de l'IA dès le premier jour.
• Les entreprises historiques peuvent rattraper leur retard en s'appuyant sur ce que l'IA ne peut pas reproduire : la connaissance client, l'expertise métier et un solide jugement produit.
• Les boîtes qui gagneront n'auront pas forcément les meilleurs modèles. Elles auront les boucles d'apprentissage les plus rapides.
• L'IA est au fond un défi d'organisation. La technologie est le moyen, mais c'est le leadership qui détermine où la valeur se crée.