Le PO Technique : le profil qui va redéfinir les équipes produit

Un développeur chevronné équipé de Claude Code ou d'un outil d'IA agentique similaire peut aujourd'hui réaliser une fonctionnalité dans son intégralité : modèle de données, API, frontend, logs, analytics. Ce qui était autrefois le travail coordonné de plusieurs spécialistes peut désormais être conduit par une seule personne. Mais cette puissance de réalisation ne vaut rien sans une compréhension profonde de ce qu'on construit et pourquoi. Et c'est là qu'un profil encore méconnu va prendre une importance considérable : le PO Technique.

Deux compétences, deux trajectoires très différentes

Les réflexes techniques : une barrière qui s'abaisse

Quand un développeur réalise une fonctionnalité de bout en bout aujourd'hui, il doit maîtriser un ensemble de réflexes techniques : concevoir un endpoint propre, penser aux tests automatisés dès le départ, valider que l'architecture est cohérente avec le reste du système, anticiper les cas limites. Ces réflexes s'acquièrent en années de pratique et distinguent un développeur junior d'un développeur confirmé. Mais ces barrières sont en train de s'abaisser significativement grâce à l'émergence de skills dédiées dans des outils comme Claude Code. Ces skills fonctionnent un peu comme les containers Docker il y a quelques années : on va chercher sur étagère une brique qui embarque exactement les bonnes pratiques dont on a besoin, alors qu'il aurait fallu des jours pour les construire soi-même. Besoin de générer une API REST avec les bons patterns ? Une skill s'en charge. Besoin d'ajouter des tests unitaires qui couvrent les cas limites ? Idem.

Ces réflexes techniques ne vont pas disparaître complètement. Il faudra toujours quelqu'un capable de valider que le code généré tient la route, que l'architecture ne dérive pas, que la dette technique reste sous contrôle. Mais la barre d'entrée pour produire du code correct et bien structuré va considérablement baisser. Je ne serais d'ailleurs pas surpris que ces skills finissent par être directement intégrées dans les moteurs eux-mêmes — les LLM ou les CLI — rendant ces bonnes pratiques automatiques plutôt qu'optionnelles. Dans ce contexte, la pure compétence technique va perdre de sa rareté. Et ce qui était autrefois le principal critère de valeur d'un développeur va progressivement céder sa place à autre chose.

Ce qui restera indispensable : comprendre ce qu'on construit

Réaliser une fonctionnalité à la vitesse de l'IA agentique, c'est impressionnant. Mais réaliser la bonne fonctionnalité, de la bonne manière, pour les bonnes raisons, c'est une toute autre affaire. Et c'est là que la compréhension produit devient le vrai facteur différenciant. Il ne s'agit pas simplement de comprendre les écrans à implémenter ou les composants du design system à utiliser. Il faut comprendre pourquoi cette fonctionnalité existe, ce que les utilisateurs en attendent réellement, ce dont l'équipe de Data Analyse aura besoin en aval pour mesurer son impact, les contraintes de l'infrastructure de production qui vont influencer les choix d'implémentation. Un développeur qui comprend tout ça va produire un résultat radicalement meilleur qu'un développeur qui se contente d'implémenter une spec.

Soyons cash : un développeur qui ne s'intéresse qu'au code et pas à son produit va perdre beaucoup de valeur dans les années qui viennent. Quand l'IA agentique permet de coder 10 fois plus vite, la partie "coder" n'est plus ce qui crée le plus de valeur. C'est la partie "savoir quoi coder" qui fait la différence. Un développeur qui comprend les enjeux business, qui anticipe les besoins des utilisateurs, qui dialogue avec les équipes Sales et Support pour comprendre les vrais points de douleur — celui-là sera irremplaçable. Celui qui attend qu'on lui donne une spec détaillée pour commencer à travailler ne sera probablement pas remplacé quand il partira.

Le PO Technique : un profil qui existe déjà

Ce profil de développeur avec une forte compréhension produit n'est pas une invention théorique. J'en croise régulièrement chez mes clients sous différentes appellations. Ce sont des développeurs expérimentés — confirmés voire seniors — qui se sont pris au jeu de faire le lien entre la technique et le produit. Souvent, ils ont commencé par un rôle adjacent : Scrum Master, Delivery Owner, ou Proxy Product Owner dans certaines organisations. Issus des équipes d'engineering, ils ont une vue très claire du produit parce qu'ils ont participé à sa construction depuis le début. Ils connaissent les contraintes techniques, comprennent les choix d'architecture, et ont développé en parallèle une vraie culture produit en s'intéressant aux besoins des utilisateurs et des clients.

Mais jusqu'ici, ces profils étaient paradoxalement sous-exploités. Par manque de temps et de bande passante, ils étaient cantonnés à des tâches classiques de Product Owner : rédaction de user stories, discussions avec les parties prenantes, tests fonctionnels, priorisation du backlog. À la fin du processus, ils communiquaient une spec facilement actionnable par les équipes techniques. C'est déjà un apport considérable — la qualité de ces specs est souvent bien meilleure que celle d'un PO sans background technique. Mais il restait de la latence, de la perte d'information entre la spec et l'implémentation, des allers-retours pour clarifier des détails. Avec l'IA agentique, cette dernière friction disparaît : ils vont pouvoir mettre en pratique directement et en toute autonomie ce qu'ils ont compris de leur produit, sans intermédiaire.

Trois personnes au lieu de trente

Le ratio habituel dans une équipe produit bien rodée, c'est environ un Product Owner pour 7 à 10 développeurs. Une équipe typique de 3 PO et 25 développeurs livre à un certain rythme. Remplacez cette équipe par 3 PO Techniques équipés d'outils d'IA agentique et les résultats sont saisissants. Nous avons pu tester récemment avec une équipe que j'accompagne la création d'un backoffice complet. L'estimation initiale, faite par l'équipe avec un workflow classique, frôlait les 40 jours-homme. Tout a été réalisé en 2 jours-homme, et nous sommes même allés un peu plus loin que le périmètre initialement prévu. C'est un facteur 20 sur une feature réelle, pas un benchmark artificiel.

Ce chiffre n'est pas magique — il s'explique par la suppression de toute la latence organisationnelle. Plus de handoff entre PO et développeur, plus d'attente de priorisation, plus d'allers-retours pour clarifier une spec. Le PO Technique comprend le besoin, le formule et le réalise dans un flux continu. Évidemment, ça ne signifie pas que toutes les features se prêtent à ce mode de fonctionnement. Les sujets à forte complexité technique ou architecturale nécessiteront toujours des développeurs spécialisés. Mais pour une part significative du backlog — back-offices, intégrations, CRUD, dashboards — ce mode de fonctionnement est redoutablement efficace. Et ça va mécaniquement rebattre les cartes de comment nous dimensionnons et structurons nos équipes produit et technique.

Ce que ça change pour les CTO et CPO

Les implications sont profondes. Côté recrutement d'abord : les processus qui évaluent principalement les compétences techniques pures vont devoir évoluer. Ce qu'il faudra détecter chez un candidat, c'est son appétence produit, sa capacité à comprendre un besoin business, sa curiosité pour les usages. Un développeur moyen techniquement mais excellent en compréhension produit aura plus de valeur qu'un excellent technicien qui ne s'intéresse pas à ce qu'il construit. C'est un renversement majeur des critères de sélection.

Côté organisation ensuite : les frontières entre équipe produit et équipe technique vont continuer à s'estomper. Les PO Techniques sont les pionniers de cette convergence. Ces profils font d'ailleurs souvent d'excellents managers par la suite — leur double culture leur permet de dialoguer aussi bien avec la direction produit qu'avec les équipes d'engineering. Ils accèdent naturellement à des fonctions de Head of Product voire de CPO. Les identifier tôt dans votre organisation, les accompagner dans cette montée en compétences produit, et leur donner les outils pour exprimer leur plein potentiel va devenir un avantage compétitif majeur dans les prochaines années.

En résumé

L'IA agentique ne rend pas les développeurs obsolètes. Elle rend obsolète l'idée qu'un développeur peut se contenter de coder sans comprendre ce qu'il construit. Le PO Technique — ce profil hybride issu de l'engineering avec une vraie culture produit — est celui qui va tirer le meilleur parti de ces outils. En combinant compréhension du besoin et capacité de réalisation autonome, une petite équipe de ces profils va produire ce qui nécessitait auparavant des dizaines de personnes. Pour les CTO et CPO, l'enjeu est clair : identifier ces profils, les faire grandir, et repenser vos organisations autour de cette nouvelle réalité.