• Concours de circonstances : un bref échantillon de mon parcours
• Pourtant, je peux encore mettre un peu les doigts dans le code
• Même en tant que PO, comprendre les sujets techniques est important
• Marcher sur deux jambes

§Concours de circonstances : un bref échantillon de mon parcours

J’ai débuté ma carrière professionnelle il y a près de 10 ans, en tant que développeur (plus de 15 ans, si on compte l’alternance).

Très tôt, j’ai eu l’opportunité de rencontrer des utilisateurs de mes produits. Sans vraiment le réaliser, je fonctionnait en mode produit, sans vraiment m’en rendre compte, et sans véritable méthodologie. Pourtant, dès que j’ai commencé à travailler sur des sujets plus larges, dans des équipes plus grandes, j’ai petit à petit perdu cette opportunité.

Il est alors arrivé un moment où je me suis demandé : « À quoi peut donc bien servir le code que j’écris ? Qui se sert de cette application ? »

J’ai alors eu l’opportunité de rencontrer des Product Manager senior, qui m’ont permis de comprendre qu’est-ce que le Produit, et quels sont les bonnes méthodologies Produit.

Ce qu’on appelle le Product Management consiste à faire le pont entre la stratégie de l’entreprise, les clients (et utilisateurs), et les équipes techniques. La stratégie de l’entreprise nous donne la direction à suivre (sur la base des études de marché et du positionnement de l’entreprise), tandis que les clients et utilisateurs nous donnent justement leurs besoins. Nous devons donc comprendre à qui nous rendons service, et pourquoi est-ce que nous leur rendons service, pour ensuite comprendre qu’est-ce qui leur manque pour améliorer leur satisfaction. Enfin, la patte technique permet de comprendre ce qui est complexe à intégrer, ce qui l’est moins.

Après avoir mis tout ça bout à bout, on va pouvoir prioriser les opportunités (un besoin identifié comme étant gérable à l’instant donné), et les planifier (en organisation agile, on les planifie sur le prochain sprint, ou l’un des prochains). Enfin, on va pouvoir accompagner les développeurs (au sens Scrum du terme, donc les experts techniques en général) jusqu’au déploiement de la solution, en passant par la conception technique, l’implémentation et la qualification de la solution.

J’ai fait cette découverte qui a entraîné un virage majeur dans ma carrière au printemps 2022. Quelques mois avant le moment où « IA » est devenu un buzzword à la mode. En effet, ChatGPT a sorti GPT-3.5 le 30 novembre 2022. Le séisme a un peu tardé à arriver en France (courant 2023, je penses), mais il n’a pas manqué d’ébranler le monde des développeurs : GPT 3.5 a rapidement démontré des capacités d’automatisation du code bien au-delà des outils antérieurs. Ensuite sont arrivés Claude Code, OpenClaw, etc. Désormais, « vibecoder » n’est plus un gros-mot (du moins, par les « early adopters » des nouveautés IA). Aujourd’hui, une recherche avec « artificial intelligence engineer » centré sur l’Île-de-France donne plusieurs centaines de résultats (et encore, en retirant les métiers centrés sur l’IA de la recherche, sinon ça chiffre plusieurs milliers d’offres).

En ce qui me concerne, ce n’est pas avant 2024 que j’ai perçu son impact dans le cadre professionnel. En particulier, nous avons commencé à voir émerger les développeurs « augmentés par l’IA » de loin. Et rapidement, j’ai saisi que le métier n’aurait plus grand chose à voir : J’avais partagé de nombreux retours sur Claude Code, et mes propres expériences sur Opencode.ai.

Et ce n’est qu’un aperçu de ce que promet l’IA. Ulrich du Café Viennois l’a montré avec son invité nicolas, Co-founder @spawnr_dev (solution de vibecoding français) sont allés beaucoup plus loin : les développeurs (et même sans expertise technique) vont devenir des orchestrateurs d’agents IA… Le métier de développeur a ainsi subit une mutation décisive… alors même que je m’en éloignait.

§Pourtant, je peux encore mettre un peu les doigts dans le code

Je vous ai partagé juste au dessus mon article sur Opencode.ai. C’était une expérimentation isolée. J’en ai mené d’autres, depuis, avec Claude Code, avec Azure Foundry, etc. Et pas que moi : dans mon entourage proche, des gens sont près de publier de superbes applications vibecodées (bon ok, mon avis est biaisé 😁).

En fait, l’IA ne nous dispense pas de nous pencher sur le code. En effet, l’IA est perfectible : elle peut commettre des erreurs subtiles, fournir une solution qui s’écarte du but recherché, introduire des failles de sécurité, etc. Tout ceci peut entraîner des coûts importants, comme la suppression de données critiques, ou l’exposition d’informations sensibles.

Dans ces conditions, nous autres les humains, nous devons développer des connaissances fondamentales qui nous permettrons de correctement piloter l’IA.

1. Formulation : savoir demander et expliquer ce qu’on attend de l’IA.
2. Validation : savoir vérifier ce que l’IA produit
3. Investigation : savoir déboguer quand ça casse
4. Sécurité : Savoir repérer les risques et potentielles failles
5. Intégration : Savoir composer des solutions à partir de briques générées par l’IA, ou dans l’environnement où le code généré sera exécuté…

Concrètement, nous devons toujours savoir comment fonctionne le système sous le capot, pour pouvoir corriger ses erreurs !

Et moi ça me convient très bien : orchestrer les IA, utiliser mon expertise pour piloter les agents, et bien entendu, continuer ma veille technique 😎

§Même en tant que PO, comprendre les sujets techniques est important

Dans la théorie du Scrum, le PO est responsable du backlog : il identifie les besoins, les priorises, conçoit la solution fonctionnelle avec les experts, planifie les sprints avec le Scrum Master et les experts, s’assure de la valeur livrée, …

Mais voilà, dans le lot, on a la conception de la solution. Certes sous l’angle fonctionnel, mais le choix dépend en grande partie des contraintes techniques : comment fonctionne le produit à l’instant donné, quel est le coût d’implémentation de la solution, quelles zones d’ombre persistent, … Nous pouvons être amenés à « challenger » ce que proposent les experts, c’est-à-dire voir avec eux s’il n’y a pas d’autres technos qui permettraient d’arriver à un meilleur résultat et/ou plus facilement, ce qui implique de comprendre, et connaître le sujet.

Même une recherche rapide sur LinkedIn confirme la montée en puissance de l’expertise technique chez les Product Owner.

§Marcher sur deux jambes

Au final, je me rends compte que, même si je ne pourrais plus jamais « coder » moi-même (mes agents le feront pour moi), je pourrais toujours cultiver ma curiosité technique et valoriser mes connaissances techniques tout en stimulant mon expertise produit :

• Pour collaborer efficacement avec les experts techniques.
• Pour concevoir des solutions pertinentes, face aux besoins de mes clients.
• Pour moi même « vibecoder » des solutions qui marchent (au moins pour valider mes hypothèses sur le marché)

L’IA ne me remplace pas. Elle m’augmente.