- L’ingénierie logicielle, au sens traditionnel du terme, arrive à son terme, et un paradigme d’ingénierie produit fondé sur l’IA émerge
- L’ingénieur produit est un rôle hybride entre product manager et développeur full stack, un builder autonome et orienté résultats qui prend en charge l’ensemble du cycle, de la conception au déploiement
- Ces profils, fondés sur une approche AI-native, des compétences en T et une pensée centrée sur les KPI, s’organisent non plus par équipe mais par fonctionnalité, avec une responsabilité end-to-end sur l’onboarding, le paiement, les notifications, etc.
- Côté produit, ils s’occupent de l’idéation, de l’analyse de marché, de la recherche utilisateur et du design produit ; côté ingénierie, ils prennent en charge l’architecture, la conception des systèmes, le développement frontend et backend
- L’IA devient un outil particulièrement puissant dans les domaines définissables et déterministes (D&D), et les organisations pourraient évoluer d’un triangle PM-designer-ingénieur classique vers une structure de collaboration ingénieur produit + IA
Background
- L’ingénierie logicielle traditionnelle n’est plus vraiment pertinente
- La dernière rupture de paradigme fondamentale remonte à 1972, lorsque Dennis Ritchie a présenté le langage C
- Depuis, les avancées n’ont été, pour l’essentiel, que des optimisations et abstractions destinées à faciliter l’écriture et la transformation du code machine
- Pendant longtemps, la productivité a été évaluée selon l’efficacité temporelle et spatiale du code, sa longueur et son interprétabilité
- Nous sommes désormais entrés dans un paradigme entièrement nouveau, et il est peu probable que nous revenions à l’époque du “raw coding” d’autrefois
- John Carmack a récemment indiqué que les meilleurs outils de création allaient désormais passer du code écrit à la main à un guidage par l’IA
- Il devient donc important pour les ingénieurs de développer des “product skills” et d’exploiter les meilleurs outils
- L’ingénierie logicielle va progressivement évoluer vers la Product Engineering
Qu’est-ce qu’un Product Engineer (PE) ?
- Un rôle hybride entre product manager et ingénieur logiciel full stack
- Un profil responsable de l’ensemble du cycle produit, directement lié à la réussite ou à l’échec du produit
- Principales caractéristiques de l’ingénieur produit :
- AI-native : utilise les LLM non comme un simple complément, mais comme un outil central
- Compétences en T : une forte expertise en ingénierie, combinée à une compréhension large du produit, de la donnée et du design
- Orientation résultats : responsable des KPI comme la rétention, le taux de conversion ou le taux d’activation
- Capacité d’exécution autonome : capable de passer d’une idée → un document de cadrage → un design → un déploiement avec un minimum de supervision
- Évolution de la structure des équipes
- Les ingénieurs produit forment de petites lean teams très qualifiées
- Au lieu d’une séparation frontend/backend/infrastructure, l’organisation se fait autour du produit et des fonctionnalités (feature squad)
- L’alignement ne se fait plus par stack, mais par outcome
- Exemple : une personne gère l’onboarding, une autre le paiement, une autre encore les notifications
- Chacun prend en charge l’ensemble de la fonctionnalité, de l’UX jusqu’à la couche de données, de bout en bout
- En d’autres termes, la structure passe des équipes “frontend/backend/infrastructure” à des “squads autonomes par fonctionnalité”
- L’ingénieur produit a deux dimensions :
- La dimension produit (pré-développement, pre-development)
- La dimension ingénierie (développement et post-développement, in/post-development)
The Product
- La dimension produit du rôle d’ingénieur produit recouvre en partie le travail traditionnel du product manager, c’est-à-dire la responsabilité du cadrage et de la direction du produit
- Product Ideation (idéation produit)
- Processus qui consiste à définir et préciser les fonctionnalités clés du produit, sa proposition de valeur (Value Proposition) et ses utilisateurs cibles
- Il permet d’établir clairement la raison d’être du produit et le public visé, afin de poser les bases des développements futurs
- Mind-mapping (cartographie mentale)
- Permet de schématiser et visualiser les idées ou tâches dérivées d’un concept central afin de comprendre la vision d’ensemble
- Sert d’outil pour partager et faire progresser les idées au sein de l’équipe
- Brainstorming
- Processus consistant à noter individuellement des idées, puis à les partager avec d’autres pour les améliorer, les compléter et les valider
- La collaboration permet d’amplifier la diversité et la créativité des idées
- Discovery
- Démarche visant à explorer les besoins des clients et à étudier les opportunités du marché pour trouver un produit aligné à la fois avec les objectifs business et la valeur utilisateur
- Elle inclut les entretiens utilisateurs, l’analyse concurrentielle et les études de marché
- Selection (priorisation)
- Consiste à décider quelles fonctionnalités ou quels projets traiter en priorité à partir de la direction stratégique, des objectifs business, des besoins clients et des tendances du marché
- L’objectif est d’identifier le plan d’exécution le plus efficace dans un contexte de ressources limitées
- Market Analysis (analyse de marché)
- Vise à analyser l’environnement de marché dans lequel s’inscrit le produit, ainsi que la concurrence, la taille du marché, les opportunités et les menaces
- Sert à définir le positionnement du produit et sa stratégie de croissance
- User Research (recherche utilisateur)
- Processus d’analyse approfondie des comportements, besoins et points de douleur des utilisateurs
- Permet d’obtenir une base factuelle pour améliorer l’expérience utilisateur à partir de données
- Product Design (design produit)
- Comprend le design UI/UX, le design de service, le design d’interaction et les tests utilisateurs
- La réalisation de prototypes et les tests itératifs garantissent une expérience conviviale
- Ces responsabilités relevaient historiquement du product manager, mais l’ingénieur produit les exécute de manière plus agile à l’aide d’outils IA
- L’IA a des limites pour générer des idées réellement nouvelles, mais elle est très puissante pour examiner des patterns existants ou compléter des réflexions répétitives
- L’essentiel est que la vision produit reste pilotée par l’humain, et que l’IA soit utilisée comme soundboard pour affiner et corriger les idées
The Engineer
- La dimension ingénierie du rôle d’ingénieur produit correspond à l’étape où les spécifications définies sont réellement exécutées et implémentées
- Elle couvre quatre grands domaines :
- Architecture logicielle : décisions structurelles
- System design : définition et spécification du système
- Développement frontend : mise en œuvre du design visuel et de l’interface utilisateur
- Développement backend : optimisation de la logique métier et conception de la base de données
- Bien sûr, d’autres sujets d’ingénierie comme les tests, le monitoring ou l’intégration de l’IA sont importants, mais dans la majorité des projets, la priorité reste de construire et déployer rapidement un produit SLC (Simple, Lovable, Complete)
- Les LLM de code excellent particulièrement dans les environnements définissables et déterministes (D&D), ce qui donne à l’IA une contribution encore plus forte sur le versant ingénierie
-
Planning
- La planification est l’étape clé pour utiliser efficacement l’IA
- Si l’intention du projet est fournie à l’IA sous forme d’exigences bien structurées, la qualité du code s’améliore fortement sur le long terme
- Définir des Rules permet à l’IA codeuse de se référer en continu à des consignes de niveau système
- Exemples : règles de mise à jour de la documentation, journalisation des changements d’architecture, style de code, critères de test
- Exemple de structure de règles :
- Synchronisation des documents
/docs, du README et du CHANGELOG
- Rédaction d’un ADR (Architecture Decision Record) lors des changements majeurs de dépendances ou d’architecture
- Génération de clients API avec OpenAPI Generator, en utilisant le template TypeScript axios
- Accès aux données via le repository pattern, standardisation du traitement des erreurs
- Définition claire des critères de tests unitaires, d’intégration et E2E
- Dans la plupart des IDE, cela peut être généré automatiquement avec
/Generate Cursor Rules
-
Software Architecture
- L’architecture correspond à des décisions qui constituent la colonne vertébrale de la codebase ; comme le coût du changement y est élevé, il faut être prudent dès le départ
- Points à considérer :
- Monolithe vs microservices, serverless vs conteneurisation
- Gestion des dépendances, définition des frontières d’intégration
- Modularisation et séparation des préoccupations
- Protocoles de communication comme REST, GraphQL, gRPC ou event bus
- Stratégies de scalabilité (scale horizontal, etc.)
- Rôle de l’IA :
- Comparer les avantages et inconvénients de patterns d’architecture alternatifs
- Générer des diagrammes avec Mermaid.js
- Rédiger une première version d’ADR
- Mais la décision finale exige jugement humain et expertise métier
-
System Design
- Le system design consiste à concrétiser l’architecture en la définissant sous forme de services réels, flux de données, machines à états et interfaces
- Travaux principaux :
- Définition des API et des frontières de services
- Modélisation des données et conception des flux entre les couches
- Stratégies de gestion des erreurs et de reprise après incident
- Modélisation des transitions d’état et des workflows asynchrones
- Rédaction de documents de conception et revue des edge cases
- Usages possibles de l’IA :
- Génération d’un premier brouillon de conception
- Simulation de problèmes de concurrence et d’edge cases
- Rédaction d’interfaces API, de schémas et de machines à états
- Comparaison de patterns de conception et retours critiques
- Aider à valider la conception comme un “ingénieur junior”
-
Frontend Engineering
- Le frontend prend en charge le design visuel et l’implémentation des fonctionnalités côté client
- L’IA se montre particulièrement performante dans l’écosystème JS, notamment avec des frameworks largement utilisés comme React
- Conseils pour améliorer les résultats de l’IA :
- Fournir à l’IA des guidelines de marque (polices, couleurs, espacements, règles responsive) sous forme de captures d’écran ou de documentation
- Utiliser une config Tailwind, des variables CSS, etc. pour générer un code UI cohérent
- Il est aussi possible d’essayer des outils de conversion Figma-to-code (comme Tempo)
- En donnant à l’IA des définitions de composants répétitifs et des règles responsive, il devient plus facile de produire une UI cohérente avec la marque
-
Backend Engineering
- Le backend prend en charge l’implémentation de la logique métier, la conception de la base de données, la construction et l’optimisation des API
- L’IA est particulièrement efficace pour les tâches définissables et déterministes (D&D)
- Techniques efficaces :
- Import de documentation : importer directement dans l’IDE les spécifications API et documents techniques afin que l’IA puisse s’y référer, ce qui réduit les hallucinations
- Utilisation d’un workspace : dans les projets où frontend et backend sont séparés, réunir les dossiers pour fournir davantage de contexte et aider l’IA à mieux comprendre la structure globale du projet
General Tips for the Product Engineer
-
Always work at the frontier
- Il est important de toujours utiliser les modèles les plus récents
- Les derniers modèles peuvent comprendre des projets plus vastes grâce à des fenêtres de contexte plus larges
- Ils apportent aussi des améliorations en raisonnement, réduction des hallucinations et stabilité accrue
-
Use thinking mode
- Activer le Thinking mode améliore fortement la qualité des réponses du modèle
- Si l’option existe, elle devrait toujours être activée
- Si ce n’est pas pris en charge, on peut obtenir un effet similaire en incluant le mot “ultrathink” dans le prompt
-
Be hyper-specific
- Quand on demande quelque chose à l’IA, il faut être très précis et explicite
- Il faut impérativement inclure l’objectif, les contraintes, les décisions de design, les extraits de code pertinents, les chemins de fichiers et les noms de composants
- Exemple de bon prompt :
- Ajouter un suivi analytics au formulaire de
/src/pages/SignUp.tsx
- Quand l’utilisateur clique sur ‘Submit’, envoyer l’événement
sign_up_started via la fonction trackEvent()
- L’événement doit être debounced
- Inclure le domaine e-mail de l’utilisateur (ex.
gmail.com) comme propriété
-
Provide visual context
- Dans le travail frontend, fournir un contexte visuel est particulièrement important
- Les LLM de code comprennent déjà les images ; joindre des captures d’écran de design ou des captures de messages d’erreur liés à un bug permet à l’IA de résoudre le problème plus rapidement
-
Work in small iterations
- Plutôt que de confier une grosse tâche d’un coup à l’IA, il faut la découper en petites itérations
- Il est efficace d’implémenter d’abord la fonctionnalité de base, puis de l’améliorer progressivement
- Il vaut mieux formuler les prompts sous forme de plusieurs instructions clairement définies
-
Stay curious
- Il existe sur Internet une grande quantité de conseils et d’exemples de prompt engineering
- Participer à des communautés ou réseaux pertinents permet de découvrir les techniques les plus récentes et d’adopter rapidement les meilleures pratiques d’usage
Closing thoughts
- Malgré la révolution de l’IA, certaines compétences ne seront pas remplacées à court terme, ou prendront même davantage de valeur
- Maîtrise des outils CLI (ex. : git)
- Git reste l’outil le plus efficace pour gérer les versions du code et suivre l’historique des changements
- Comme la fiabilité du code généré par l’IA reste limitée, la capacité à revenir à un état antérieur ou à repartir de zéro est essentielle
- La maîtrise d’outils CLI comme Git va donc devenir de plus en plus importante
- Fondamentaux de l’ingénierie
- Capacité à gérer la dette technique et à préserver la modularité et l’encapsulation du code
- L’IA ne garantit pas toujours la cohérence du style de code (naming conventions, principe DRY, modularité)
- La capacité des ingénieurs à faire respecter eux-mêmes ces principes de base prendra donc encore plus de valeur
- Cela dit, à long terme, cette situation pourrait évoluer à mesure que l’IA écrira une part croissante du code
- Forte capacité de communication
- La capacité à rédiger clairement et de façon structurée des documents, prompts et spécifications crée un fort effet de levier
- L’IA n’infère pas l’intention comme un humain ; elle exécute ce qui lui est demandé, donc la clarté est indispensable
- De bonnes spécifications, des prompts bien définis et une documentation rigoureuse améliorent la productivité et la qualité des livrables
- Déplacement du pouvoir dans l’organisation
- Les tâches techniques seront progressivement prises en charge par l’IA, ce qui correspond bien à leur nature D&D (Definable & Deterministic)
- À mesure que l’exécution devient peu coûteuse et banalisée, la capacité à piloter l’IA et à packager les résultats pour les présenter à la direction et aux actionnaires prend davantage de valeur
- Dans les grandes entreprises, l’exécution réelle est peu visible et seuls les résultats sont transmis ; la mise en récit stratégique et le packaging des résultats peuvent donc devenir déterminants en matière d’influence
- Il est possible que les managers capables d’aligner et de transmettre ces résultats gagnent plus de pouvoir que celles et ceux qui implémentent directement la technologie
- Perspective d’évolution de la structure organisationnelle
- Plus l’entreprise est nouvelle (startup), plus le rôle d’ingénieur produit a des chances d’être adopté rapidement
- Au fil de la croissance, si l’IA gagne en autonomie, la structure traditionnelle en triangle PM-designer-ingénieur pourrait s’affaiblir
- À la place, une nouvelle topologie d’équipe pourrait émerger : de petits pods pilotés par des ingénieurs produit dotés d’un fort sens du produit, assistés par des AI copilots couvrant toute la stack
References
Aucun commentaire pour le moment.