Dans les organisations qui fonctionnent encore en mode projet, engagements pris en amont, jalons contractualisés, scope figé, le Product Manager peut rapidement se retrouver à absorber la charge plutôt qu’à la questionner. Ce n’est pas le mode projet qui est en cause. C’est l’absence de raisonnement produit avant que les engagements soient pris.
C’est l’enseignement principal d’un chantier de refonte et mise en place d’un design system sur les emails mené chez un grand retailer : un projet de grande envergure (18 pays, 10 triggers, 310 deliveries) livré dans un environnement SAFe, qui illustre à la fois ce que l’approche produit apporte, et ce qu’elle révèle trop tard quand elle arrive après la contractualisation.
Cet article est issu d’un XO Product Café, un rituel interne dédié aux retours d’expériences des missions des consultants IKXO.
Le contexte : un projet bien cadré, un périmètre ambitieux
L’objectif de la mission : implémenter un design system pour les emails marketing automatisés. Des emails dits “triggers” (abandon panier, réachat, antichurn, anniversaire…) envoyés en moyenne à 12 millions de destinataires par mois à travers l’Europe.
Quatre objectifs produit clairs au démarrage :
– Harmoniser le visuel des emails.
– Passer à 100 % d’emails responsive.
– Améliorer la maintenabilité des templates.
– Donner de l’autonomie aux équipes pays.
La métrique de succès, elle, était un indicateur projet classique : 100 % du design system livré fin 2025.
Mode projet vs. approche produit : ce que ça change concrètement
Le mode projet et l’approche produit ne sont pas incompatibles. Mais ils engagent des postures très différentes.
En mode projet, la valeur réside dans l’exécution : identifier les dépendances en amont, définir des jalons clairs, savoir à qui s’adresser côté business sur chaque thématique. Ce sont des réflexes utiles et ils ont bien fonctionné sur ce chantier (approche France-first, processus de création standardisé, workflows de validation en batch).
En mode produit, la valeur réside dans le raisonnement amont : anticiper l’usage, la réutilisabilité, la maintenabilité avant de construire. Prioriser de manière éclairée plutôt qu’exécuter à marche forcée. Questionner comment on fait quelque chose pour que ça serve au-delà du jalon immédiat.
La tension entre les deux se matérialise surtout quand le scope dérape : demandes hors-scope intégrées au fil de l’eau, modifications tardives des fichiers de traduction par les pays, ajustements non répercutés entre la bibliothèque de composants et les templates emails…
En mode projet, la surcharge ne se négocie plus : elle se subit. En mode produit, on ne supprime pas la charge, on la questionne avant qu’elle soit contractualisée.
Ce qui a bien fonctionné : les réflexes projet au service du produit
Trois pratiques ont permis de tenir le cadre et d’avancer efficacement :
– L’approche France-first. Démarrer par la France a permis de créer des premiers composants testables, d’établir un “core model” de référence, et de user tester avant de déployer à l’international. En termes produit : réduire l’incertitude tôt, sur un périmètre contrôlé.
– Un processus de création standardisé. Depuis la récupération de l’email existant jusqu’à la création de la planche AEM, le processus a été rapidement adopté par les équipes techniques. La clarté du parcours a évité les allers-retours.
– Des jalons et des workflows Master. L’identification des dépendances dès le départ et la création de workflows pour valider les BAT en batch ont permis de tenir un rythme de livraison sur deux lots successifs.
Ce qui a moins bien fonctionné : les angles morts d’un projet sans raisonnement produit amont
La France n’est pas représentative des marchés moins matures
L’approche France-first a été un accélérateur. Mais elle a aussi créé un angle mort : les workflows diffèrent significativement d’un pays à l’autre, et les libellés n’ont pas été retravaillés pour chaque marché local. La version française a servi de base sans adaptation au contexte local. Résultat : des disparités structurelles qui auraient pu être anticipées.
Ce qu’une approche produit aurait permis : documenter explicitement les hypothèses faites sur les marchés non analysés, et les traiter comme des risques à instruire et non pas comme des acquis.
L’objectif déclaré ne correspondait pas à l’objectif réel
“Donner de l’autonomie aux équipes pays” était un objectif affiché. Mais les contraintes techniques sur la gestion des droits rendaient cet objectif techniquement inatteignable sans intervention manuelle. L’objectif était réel dans l’intention, pas dans les conditions.
Ce qu’une approche produit aurait permis : distinguer dès le démarrage les objectifs réalisables des objectifs aspirationnels, et éviter de porter comme un échec en fin de mission ce qui était structurellement impossible.
Pas de soft launch, pas de mesure d’impact
Le workflow et le message marketing n’ont jamais été remis en question. Aucun pilote n’a été conduit pour vérifier la pertinence ou l’impact des nouveaux emails avant déploiement généralisé. Le risque : une non-performance des emails qui n’aurait pas de lien avec la qualité du design system lui-même.
Ce qu’une approche produit aurait permis : proposer un POC sur un pays ou un trigger, mesurer l’impact avant de généraliser et ancrer la mission dans des outcomes, pas uniquement dans des outputs.
Les takeaways à retenir
1. Nommer le raisonnement produit dès le démarrage. Réutilisabilité, maintenabilité, anticipation de l’usage : ce ne sont pas des évidences. Les nommer explicitement dès le cadrage permet d’en faire des critères de décision auprès de la gouvernance, pas des intentions vagues.
2. Budgéter du temps tampon pour les dépendances pays. En mode projet, la dépendance aux équipes internationales est systématiquement sous-estimée : traductions livrées en retard, disponibilités variables, spécificités locales non documentées. Ce temps doit être prévu, négocié et visible dans le plan.
3. Qualifier et documenter les hypothèses implicites. À l’arrivée sur une mission, un audit rapide de ce qui a été supposé sur les marchés non analysés permet de rendre visibles les paris cachés et de les instruire plutôt que de les découvrir trop tard.
4. Distinguer objectif déclaré et objectif réel. Un objectif affiché sans les conditions techniques pour être atteint n’est pas un objectif, c’est une intention. La repérer tôt évite de la porter comme un échec en fin de mission, et ouvre la voie à une renégociation honnête du scope.
Conclusion
Le mode projet n’est pas l’ennemi de la qualité produit. Il est simplement incompatible avec l’improvisation amont. Ce chantier illustre que les réflexes produit : raisonnement aval, priorisation, questionnement de la valeur, ne s’appliquent pas à la place de la rigueur projet. Ils s’appliquent avant : avant que le scope soit contractualisé, avant que les hypothèses soient cristallisées, avant que la surcharge devienne inévitable.
C’est là que se joue la posture conseil premium : non pas dans la capacité à livrer dans les temps, mais dans la capacité à questionner ce qui est demandé avant de s’engager à le faire.
