PrestaShop · janvier 2026 – août 2026
La mise en relation marchands-agences du portail Expert PrestaShop, cadrée par un audit de la donnée et prouvée en code dans le navigateur
Capacité démontrée · Dérisquer une promesse produit en arbitrant sur la preuve plutôt que sur l'intention
Wireframe volontaire · les écrans réels se montrent sur demande
Contexte
Le portail Expert de PrestaShop met en relation les marchands et les agences du programme Expert. La première version de l'annuaire des agences, fraîchement en ligne, restait passive : le marchand y cherche seul, sans aide à la décision, sur des fiches héritées d'une migration depuis l'ancien outil partenaires que personne n'avait fiabilisées. Perfect Match doit transformer cet annuaire en moteur de mise en relation : le marchand décrit son projet, les bonnes agences lui sont proposées.
Problème adressé
La crédibilité du matching repose entièrement sur la donnée agence. Or ce stock de fiches migrées n'a jamais été validé par les agences : services mappés automatiquement, champs vides, déclaratif non confirmé. Promettre les bonnes agences sur cette base, c'est risquer de recommander du bruit, de décevoir le marchand et de déstabiliser les agences. Le vrai sujet n'était pas de dessiner un parcours de matching : c'était de décider sur quoi ce matching pouvait honnêtement tourner.
Mon rôle
Head of Product Design du portail, en binôme avec le produit : reprendre une discovery arrêtée six mois plus tôt, cadrer les deux parcours (marchand et agence), définir les règles de matching avec le produit et la data, concevoir les écrans en code. Sans autorité sur la donnée elle-même : les questions de fiabilité se tranchent sur pièces par la personne qui y a accès, pas par le design.
Approche
Auditer avant de dessiner. Chaque critère de matching envisagé a été classé (filtre éliminatoire, critère de pertinence, critère de départage) avec sa source, sa fiabilité et son comportement en cas d'absence. Les règles d'algorithme ont été posées avec le produit et la data à partir de cette matrice. Puis la même exigence de preuve a été appliquée aux écrans : les deux parcours construits en playground jouable dans le dépôt du produit, avec PUIK et Claude Code, et revus dans le navigateur plutôt qu'en maquette.
Décision clé
Résultats
Implication AI
Claude Code a servi d'outil de conception : les écrans des deux parcours ont été produits en Vue avec PUIK, le design system open source de PrestaShop, sur des branches dédiées, dans un playground isolé sur données mockées, sans API ni authentification. L'orchestration s'appuie sur des règles écrites dans le dépôt (conventions de code, périmètre autorisé, états à couvrir, revue avant merge) : l'IA exécute vite, la direction design et les arbitrages restent humains.
Preuves
Ces visuels sont des wireframes volontaires : le travail réel vit dans des démos jouables, qui se montrent en direct. Demandez à les voir .
Perfect Match promet au marchand de décrire son projet pour recevoir les bonnes agences, au lieu de chercher seul dans une liste. Derrière la promesse, un héritage : des fiches agences issues d’une migration depuis l’ancien outil partenaires, des services mappés automatiquement, des champs vides. Les explorations produit qui ont précédé convergeaient sur le même constat : le déficit de confiance existe des deux côtés. Le marchand veut des preuves au moment de choisir ; l’agence apparaît sur des projets hors de son calibre, sur la base d’une fiche qu’elle n’a jamais construite. Ce déficit ne se règle pas avec un filtre de plus. Il se règle en décidant ce que le produit peut promettre avec la donnée dont il dispose vraiment.
La discovery avait été arrêtée en cours de route six mois plus tôt. Sa reprise a d’abord été un recadrage. La lecture initiale faisait du parcours marchand le sujet : un brief, une page de résultats, un algorithme. Insuffisant : sans donnée agence fiable, ce parcours promet un match qu’il ne peut pas tenir. Le cycle a donc été cadré sur deux cas d’usage indissociables et hiérarchisés : le parcours marchand, dérisqué en priorité parce qu’il porte la promesse, et la donnée agence, instrumentée parce qu’elle seule peut la tenir. Deux populations d’agences ont été distinguées dès ce cadrage : l’agence historique, dont la fiche migrée doit être réappropriée avant tout matching, et la nouvelle agence, qui construit la sienne de zéro.
Ce cadrage a fait remonter un désaccord réel : la donnée migrée était-elle fiable ? Une lecture disait oui, les fiches sont largement remplies. L’autre disait non, remplie ne veut pas dire validée, et matcher sur du déclaratif non confirmé revient à matcher sur du bruit. Plutôt que de trancher au feeling, la divergence a été inscrite comme telle au journal de décisions du chantier, avec un arbitrage sur pièces par la personne qui a accès à la donnée. Un désaccord nommé vaut mieux qu’un consensus mou : dans six mois, l’équipe saura pourquoi la règle a été posée, pas seulement laquelle.
L’intuition de départ voulait qu’un bon matching exige de nouveaux champs : taille de projet gérée, budget, disponibilité. Il suffisait de demander aux agences de les remplir. Cette hypothèse méritait d’être vérifiée avant de dessiner quoi que ce soit. Chaque signal disponible ou envisagé a donc été passé en revue et classé en trois familles : les filtres éliminatoires qui excluent du pool, les critères de pertinence qui classent, les critères de départage qui tranchent entre bons candidats. Et pour chacun, quatre questions : la donnée existe-t-elle, d’où vient-elle, est-elle prouvée ou déclarative, que se passe-t-il quand elle manque.
Le résultat contredisait le plan. Les champs posés au départ étaient les plus fragiles de la matrice : déclaratifs, invérifiables, et la disponibilité se périme en quelques semaines. À l’inverse, des signaux déjà prouvés dormaient dans l’existant : le classement de l’annuaire, le niveau d’expertise attribué par le programme, les certifications vérifiées.
Le dilemme était posé. Première option : attendre la nouvelle donnée, demander aux agences de remplir les champs manquants, et lancer un matching riche sur du déclaratif dont la fiabilité resterait invérifiable. Seconde option : lancer plus sobre, uniquement sur la donnée prouvée, en assumant un matching moins fin mais dont chaque règle se défend. Le raisonnement a tenu en une question : que rencontrera le marchand au lancement ? Avec un stock de fiches incomplètes, un matching exigeant en donnée exclut des agences pour une migration qu’elles n’ont pas choisie, et vide les pages de résultats.
La décision : la première version tourne exclusivement sur la donnée prouvée existante, et les champs déclaratifs n’arrivent qu’ensuite, en affinage. Une règle par défaut complète le dispositif : une donnée absente donne un score neutre et n’exclut jamais, hors filtres durs. Conséquences directes : le lancement ne dépend plus d’une collecte encore hypothétique, la réappropriation de la fiche migrée devient le point de départ du parcours agence, et les cas limites deviennent des écrans à concevoir en premier.
La même logique a été appliquée à la conception. Une maquette aurait montré le parcours où tout va bien : trois belles agences, des profils complets, un match évident. La réalité du lancement, c’est de la donnée incomplète, des zones presque vides, des briefs sans correspondance. Les deux parcours ont donc été construits en playground jouable dans le dépôt du produit, en Vue avec PUIK, le design system open source de PrestaShop. Claude Code a produit les écrans dans un cadre défini au préalable ; la direction design, les arbitrages et la revue sont restés humains. Quand un composant manquait au design system, il devenait un candidat proposé au système plutôt qu’une divergence locale : on ne consomme pas un design system, on l’alimente.
La page de résultats s’est conçue à partir des cas limites. Aucune agence ne correspond au brief : l’écran le dit, propose d’élargir la recherche et renvoie vers la liste complète. La shortlist est incomplète : elle affiche ce qui existe, annonce le nombre, ne gonfle rien. Dans un deck de maquettes, ces états sont les frames que personne n’ouvre. Dans un playground, ce sont des situations sur lesquelles la revue bute, comme buterait un marchand. La revue produit a changé de nature : l’équipe ne commente plus une intention, elle éprouve un comportement.
La feature est en vol. Des critères de succès sont posés sur la complétion du brief, l’acceptation de la shortlist et la progression des fiches agences, mais aucun chiffre d’adoption n’existe à l’heure d’écrire ces lignes, et rien de plus ne sera avancé ici. Ce qui est acquis tient en trois points : un modèle de pertinence dont chaque règle est traçable jusqu’à un fait, un lancement calibré sur la donnée que le produit possède vraiment, et une pratique de revue en playground qui déborde déjà ce chantier pour devenir une habitude d’équipe. La question qui comptera dans six mois n’est pas de savoir si les écrans étaient réussis : c’est de savoir si la règle du score neutre a suffi à protéger la confiance pendant que le stock de fiches se fiabilise.
Mon mandat s’est achevé en août 2026. Le chantier a été transmis avec ses instruments : le playground rejouable, le journal de décisions, les critères de succès posés. Une conception qui ne survivrait pas à ce passage de main n’aurait pas mérité le mot.
Enseignement
Une promesse produit ne vaut que la preuve qui la porte. La donnée réelle, l'écran réel, l'état réel : tout arbitrage rendu sur autre chose est une intention, et une intention ne protège personne au lancement.
Dernière mise à jour · août 2026
Écrit avec terquedad colombiana, dans le sud de la France.
Pas avec amour, avec du contexte et un agent patient.
Encore en train d'apprendre.
© 2026 Tous droits réservés.