Product Engineer : le nouveau rôle qui fusionne toutes les spécialités

La fin du développement en silos : un changement de paradigme

Pendant des décennies, la production logicielle a reposé sur une logique de spécialisation poussée à l'extrême. D'un côté, les développeurs front-end. De l'autre, les développeurs back-end. Entre les deux, des designers UX, des architectes, des experts sécurité, des DevOps. Chaque discipline constituait un silo, chaque transmission entre équipes générait un délai, chaque délai accumulait de la friction. L'analogie est frappante : le bûcheron abat, le débardeur transporte, le scieur transforme… chacun attend l'autre.

Ce modèle, qui paraissait optimal dans un monde où la production manuelle de code était la seule option viable, est aujourd'hui remis en question de manière fondamentale. Non pas par une amélioration incrémentale des pratiques existantes, mais par un changement de nature dans la façon dont le logiciel est conçu, produit et maintenu.

L'IA générative agentique ne vient pas simplement accélérer un développeur dans sa spécialité. Elle rend possible quelque chose d'inédit : un seul ingénieur augmenté capable de couvrir l'intégralité d'une chaîne de valeur logicielle. C'est dans ce contexte qu'émerge un nouveau profil, le Product Engineer, et une nouvelle organisation, la Sandwich Team. Ces deux concepts ne sont pas de simples ajustements cosmétiques du métier. Ils représentent une reconfiguration profonde de la manière dont les équipes tech créent de la valeur.

L'anti-pattern du code manuel : pourquoi l'amélioration continue ne suffit plus

Il est tentant, face à l'émergence des outils IA, de chercher des gains marginaux. Utiliser GitHub Copilot pour compléter du code plus vite. Générer des tests automatiquement. Accélérer la rédaction de documentation. Ces usages sont utiles, mais ils restent dans la logique de l'ancienne époque : on produit toujours du code manuellement, l'IA vient simplement en soutien ponctuel.

La position portée chez SFEIR est plus radicale. Comme le formule Didier Girard : « Écrire du code est désormais un anti-pattern. On ne doit plus produire de code manuellement. » Cette affirmation, qui peut sembler provocatrice, porte une logique implacable. Si l'IA agentique est capable de produire du code de qualité à partir d'un contexte bien structuré, alors le temps passé à écrire manuellement chaque ligne est du temps mal investi. C'est de l'ébavurage, pour reprendre la métaphore industrielle : on corrige les sorties au lieu de configurer correctement la machine en amont.

L'objectif affiché n'est pas un gain de 10 ou 20 % de productivité. C'est un facteur 10x. Un changement d'échelle dans la création de valeur métier. Pour atteindre ce niveau, il faut abandonner l'idée d'optimiser l'existant et accepter de reconstruire la méthodologie depuis ses fondations.

Cela implique notamment de distinguer deux approches radicalement différentes dans la manière de travailler avec l'IA :

• L'approche Spec-Driven (2025) : on demande à l'IA d'ajouter une fonctionnalité isolée. L'IA l'implémente, mais sans cohérence systémique. Résultat : une verrue logicielle collée sur la façade de l'application.
• L'approche Issue-Based (2026) : on signale un manque, un bug, une amélioration. L'IA analyse l'existant, utilise le contexte disponible pour produire une solution cohérente avec l'architecture et les règles métier. Résultat : une évolution qui renforce la cohérence du système.

Cette distinction n'est pas anecdotique. Elle détermine si l'IA devient un accélérateur ou une source de dette technique supplémentaire.

Le Context Engineering : le nouvel actif stratégique de l'IT

Si l'IA prend en charge la production du code, la question légitime qui se pose immédiatement est : quelle est alors la valeur ajoutée de l'ingénieur ? La réponse tient en deux mots : context engineering.

Le cœur de la valeur ne réside plus dans la capacité à écrire du code syntaxiquement correct et performant. Il réside dans la capacité à construire et maintenir un environnement structuré qui permet à l'IA de produire des résultats pertinents, cohérents et conformes aux exigences métier. Cet environnement comprend :

• Des spécifications détaillées et versionnées
• Des règles métier explicitement documentées
• Des décisions d'architecture enregistrées et justifiées
• Des standards de qualité et de sécurité codifiés
• Des conventions de nommage et de structure claires

Un contexte bien construit supprime les hallucinations de l'IA, réduit les itérations inutiles et garantit la conformité des sorties dès la première génération. C'est la différence entre une machine mal réglée qui produit des pièces défectueuses et une machine précisément calibrée qui sort des composants conformes à chaque cycle.

Ce travail de context engineering suit un workflow structuré en cinq phases :

• Plan : transformer les idées en plans d'implémentation détaillés avant toute génération de code.
• Work : exécuter via des worktrees et un task tracking précis, en laissant l'IA agentique produire le code.
• Review : valider les sorties via une revue de code multi-agents avant tout merge.
• Compound : documenter les apprentissages pour enrichir le contexte des prochains cycles.
• Repeat : chaque cycle informe et accélère le suivant.

Ce dernier point est fondamental. Dans une approche d'ingénierie cumulative, chaque unité de travail rend les suivantes plus faciles. Le savoir est codifié de manière à être réutilisable, à la fois par l'IA et par les membres de l'équipe. C'est l'opposé exact d'une utilisation de l'IA qui accumule la dette technique à chaque feature ajoutée. La règle d'or est simple : maintenir une qualité maximale aujourd'hui pour garantir la vélocité de demain. Et pour cela, le contexte doit être versionné dans Git, traité comme un asset vivant au même titre que le code lui-même.

Concrètement, cela signifie que 80 % du temps d'un ingénieur augmenté est consacré à la planification et à la revue, et seulement 20 % à l'exécution. C'est une inversion complète du rapport traditionnel au travail de développement.

Le Product Engineer : la fusion des spécialités en un seul rôle

C'est dans ce nouveau paradigme que le Product Engineer prend tout son sens. Ce profil n'est pas un développeur full-stack amélioré. Ce n'est pas non plus un product manager qui sait coder. C'est un rôle nouveau, rendu possible par l'IA agentique, qui assume la responsabilité de la chaîne complète de création d'une application : UX, UI, front-end, API, back-end et sécurité.

Là où un Software Engineer traditionnel maîtrisait une ou deux spécialités et collaborait avec des experts pour le reste, le Product Engineer devient ce que la stratégie SFEIR appelle un App Owner : une seule personne augmentée, responsable de la vision et de la production de 80 % de l'application via l'IA.

Ce changement est symbolisé par une évolution de métaphore. Hier, un bûcheron abattait les arbres, un débardeur les transportait, un scieur les transformait. Demain : la machine abat, ébranche et sort le bois seule. Le bûcheron coordonne la production totale. Le Product Engineer n'exécute plus chaque tâche individuellement. Il configure, dirige, arbitre et valide. Il est le garant de la cohérence systémique de l'application.

En pratique, les compétences d'un Product Engineer couvrent plusieurs dimensions :

• Compréhension produit profonde : capacité à transformer des besoins métier en spécifications techniques exploitables par l'IA.
• Maîtrise du context engineering : savoir construire, maintenir et versionner un environnement de contexte structuré.
• Culture de la qualité : compétences en revue de code, en architecture et en sécurité pour valider les sorties de l'IA.
• Orchestration agentique : capacité à piloter des workflows IA multi-agents de manière efficace.
• Vision système : pensée architecturale permettant de maintenir la cohérence de l'ensemble, même lorsque les contributions viennent partiellement de l'IA.

Ce profil n'efface pas la valeur de l'expertise technique. Il la réoriente. Un excellent développeur back-end qui devient Product Engineer n'abandonne pas sa maîtrise des systèmes distribués ou de la performance des bases de données. Il l'utilise différemment : pour construire un contexte d'une précision et d'une profondeur que seule cette expertise permet, pour détecter les erreurs subtiles dans les sorties de l'IA, pour prendre les décisions d'architecture que l'IA ne peut pas arbitrer seule.

La Sandwich Team : l'organisation qui rend tout cela possible

Le Product Engineer ne travaille pas dans un vide organisationnel. Le modèle qui l'accompagne est ce que SFEIR appelle la Sandwich Team, et son nom illustre parfaitement sa structure.

La Pizza Team, modèle popularisé par Spotify et repris dans de nombreuses organisations tech, reposait sur des équipes de 6 à 8 personnes, pluridisciplinaires, autonomes. Ce modèle était une réponse intelligente à la complexité de coordination des grandes équipes. Mais il conservait une limite fondamentale : la coordination interne. 8 personnes, c'est 28 paires de relations à gérer. C'est des réunions de synchronisation, des délais de transmission, des désalignements possibles à chaque interface.

La Sandwich Team repose sur un principe radicalement différent : 1 personne augmentée, zéro délai de coordination interne. Le Product Engineer constitue le cœur de l'équipe. L'IA agentique est son partenaire constant, comblant les lacunes de compétences et démultipliant sa capacité de production. Autour de ce noyau gravitent des contributeurs spécialisés qui interviennent ponctuellement, représentant environ 20 % des contributions, guidés par le contexte versionné dans Git.

L'image du sandwich est éloquente : le Product Engineer est la tranche du milieu, dense et substantielle, prise en sandwich entre l'IA en dessous (qui produit) et les experts en dessus (qui contribuent ponctuellement). Chaque couche a son rôle, mais c'est la couche centrale qui donne sa cohérence à l'ensemble.

Ce modèle présente plusieurs avantages structurels :

• Élimination des temps morts : plus de file d'attente entre une demande front-end et une réponse back-end. Le Product Engineer gère les deux.
• Responsabilité claire : un seul owner signifie une seule source de vérité sur les décisions produit et techniques.
• Réduction du bus factor : le contexte étant versionné et explicite, le savoir ne réside plus dans la tête d'une seule personne mais dans un système accessible.
• Scalabilité asymétrique : on peut multiplier le nombre de Sandwich Teams sans multiplier la complexité de coordination proportionnellement.

La transition vers ce modèle ne signifie pas licencier des développeurs spécialisés. Elle signifie réorganiser leur contribution. Les experts en sécurité, en performance, en architecture système continuent d'apporter une valeur considérable — mais en tant que contributeurs ponctuels qui enrichissent le contexte partagé, plutôt qu'en tant que maillons d'une chaîne séquentielle.

La Stack AI-Ready : les fondations techniques du changement

Pour que le Product Engineer puisse exercer son rôle et que la Sandwich Team fonctionne à plein régime, le substrat technique doit évoluer en conséquence. C'est la notion de Stack AI-Ready : un ensemble de choix technologiques, d'outillage et de pratiques qui permettent à l'IA agentique de s'intégrer naturellement dans le cycle de développement.

Une stack AI-Ready ne se réduit pas à l'intégration d'un assistant de code dans l'IDE. Elle implique plusieurs niveaux de préparation :

• Structuration du contexte : l'adoption de formats lisibles par l'IA (Markdown structuré, spécifications en prose, Architecture Decision Records) comme langage de base de la documentation technique.
• Versionning du contexte : traiter les fichiers de contexte comme du code source, avec les mêmes pratiques de gestion de version, de revue et de merge.
• Orchestration agentique : disposer d'outils permettant de coordonner plusieurs agents IA sur des tâches complexes, avec des mécanismes de revue inter-agents avant intégration.
• Observabilité des sorties IA : mettre en place des mécanismes permettant de tracer, auditer et évaluer la qualité des contributions générées par l'IA, notamment pour des enjeux de sécurité et de conformité.
• Pipelines de validation automatisée : des suites de tests suffisamment robustes pour que le Product Engineer puisse faire confiance aux sorties de l'IA sans vérification manuelle systématique ligne par ligne.

Une stack AI-Ready est aussi une stack dont la dette technique est maintenue sous contrôle strict. L'ingénierie cumulative n'est possible que si la base de code reste saine. Une application encombrée de code mort, de dépendances non maintenues et d'architectures inconsistantes résiste à l'IA — elle génère des hallucinations, des erreurs de contexte, des propositions incohérentes. Investir dans la qualité du codebase n'est plus seulement une question d'hygiène technique : c'est une précondition à l'efficacité de l'IA agentique.

Ce que cela implique concrètement pour les équipes en transition

Passer d'une organisation classique à un modèle Sandwich Team avec des Product Engineers ne se fait pas du jour au lendemain. C'est une transformation qui touche simultanément les compétences individuelles, les pratiques d'équipe, l'outillage et la culture organisationnelle. Voici comment SFEIR accompagne ses clients dans cette transition.

La première étape est souvent la plus difficile : accepter que l'optimisation de l'existant ne mène nulle part. Des équipes qui fonctionnent correctement avec leurs pratiques actuelles ont naturellement peu d'incentive à tout remettre en question. C'est pourquoi nous recommandons souvent de commencer par un projet pilote à périmètre limité, qui permet de démontrer le différentiel de vélocité de manière concrète et mesurable, sans mettre en risque la production existante.

Ensuite vient la phase de formation au context engineering. Cette compétence ne s'acquiert pas naturellement : elle demande de désapprendre des réflexes profondément ancrés, notamment celui de sauter directement dans le code. Les développeurs les plus expérimentés sont parfois les plus résistants — et les plus efficaces une fois convertis, parce que leur expertise technique leur permet de construire des contextes d'une précision et d'une richesse que les profils juniors ne peuvent pas atteindre.

La mise en place de la stack AI-Ready est souvent l'occasion d'un audit technique complet. Quelles parties du codebase sont suffisamment propres pour accueillir des contributions IA ? Quelles zones requièrent un travail préalable de refactoring ? Quels standards de documentation doivent être établis ? Cet audit débouche sur une feuille de route technique qui aligne préparation du codebase et montée en compétences des équipes.

Enfin, la transformation organisationnelle vers le modèle Sandwich Team demande un travail sur les rôles et les responsabilités. Identifier qui a le profil et l'ambition de devenir Product Engineer. Définir comment les experts spécialisés contribuent dans ce nouveau modèle. Mettre en place les rituels adaptés à cette nouvelle structure — moins de réunions de synchronisation, plus de revues de contexte et d'architecture.

SFEIR et la stratégie 10x : un engagement concret

La stratégie AI for IT portée par SFEIR n'est pas une vision théorique projetée sur nos clients. C'est d'abord une transformation que nous appliquons à nous-mêmes. Avec 850 consultants spécialisés en IA, Cloud et Data, SFEIR est à la fois un laboratoire et un accélérateur de cette transformation.

Nous investissons dans la formation de nos propres équipes au context engineering et à l'orchestration agentique. Nous expérimentons les modèles Sandwich Team sur nos projets internes. Nous construisons des frameworks de stack AI-Ready qui capitalisent sur nos expériences terrain pour offrir à nos clients des points de départ éprouvés plutôt que des architectures théoriques.

Notre conviction est que les organisations qui réussiront cette transition ne seront pas celles qui auront le plus d'outils IA, mais celles qui auront le mieux compris comment réorganiser leur manière de créer de la valeur autour de ces outils. Le Product Engineer n'est pas un titre sur une carte de visite. C'est l'incarnation d'une nouvelle relation entre l'ingénieur humain et la machine, où l'humain reprend le rôle stratégique qui lui appartient : définir le sens, garantir la qualité, orchestrer la production.

L'analogie finale est peut-être celle-là. La révolution industrielle n'a pas transformé les meilleurs artisans en chômeurs. Elle a transformé les meilleurs artisans en maîtres d'atelier, capables de superviser et d'orienter des machines qui produisaient à une échelle inimaginable auparavant. L'ingénierie logicielle est en train de vivre sa propre révolution industrielle. Les Product Engineers en seront les maîtres d'atelier.

Le mouvement est en marche. La question n'est pas de savoir si votre organisation fera cette transition, mais à quelle vitesse — et avec qui.