La confiance existe déjà, elle est humaine
Un marchand qui cherche un module ne manque pas d’options, il en a trop.
La recherche marchande est sans ambiguïté : trouver le bon module est la
première douleur exprimée. Surcharge de choix, filtres qui ne parlent pas
le langage du besoin, fiches difficiles à comparer, et la peur récurrente
de casser la boutique en installant le mauvais module.
Le signal décisif n’était pas la douleur, c’était le contournement. Face
à ce mur, le marchand quitte le back-office : Google, sa communauté, ou
les quelques modules que son agence lui conseille. Une recommandation de
confiance existe déjà dans sa vie. Elle est humaine, installée depuis des
années, et pardonnée quand elle se trompe. L’assistant ne se bat pas
contre le vide : il se bat contre elle, avec une tolérance à l’erreur
quasi nulle.
Deux lectures du même sujet
La marketplace d’Addons PrestaShop est un pilier économique de
l’écosystème : chaque module vendu fait vivre un éditeur et la
plateforme. La lecture naturelle du sujet suivait cette pente : un
assistant qui recommande des modules, c’est un canal de mise en avant de
plus.
La recherche disait autre chose. Les études externes compilées, encore à
consolider, convergent : une mise en avant commerciale cachée crée un
sentiment de manipulation ; la même mise en avant, assumée et étiquetée,
renforce la confiance sans tuer l’intérêt. Le vrai risque n’était donc
pas de rater des ventes. C’était qu’une seule suggestion perçue comme
vendue désactive la confiance dans l’assistant entier, y compris pour
tout ce qu’il fait déjà bien.
La pertinence plafonne le revenu, jamais l’inverse
Trois options étaient sur la table. Suivre la pente commerciale, revenu
d’abord : rentable à court terme, intenable dès la première suggestion
perçue comme vendue. Refuser toute dimension commerciale : irréaliste,
l’écosystème finance le produit. Ou inverser la hiérarchie : la
pertinence d’abord, le revenu en effet de bord, la transparence assumée.
La troisième option a été actée en binôme avec le produit et documentée
au journal de décisions : l’assistant aide le marchand à trouver le bon
module pour un besoin qu’il exprime. Jamais un module recommandé
au-dessus d’un autre significativement plus adapté, et la nature de
chaque suggestion reste visible. Le fil rouge qui a guidé toutes les
décisions suivantes tient en une phrase : se comporter comme une agence
de confiance, pas comme un vendeur.
Cette décision n’a pas été prise une fois pour toutes. La pente
commerciale est revenue dans les échanges en cours de route ; le cadre
documenté a servi de point d’appui pour la re-poser. Un pivot de ce type
est un cadre tenu dans le temps, pas un acquis.
Des règles vérifiables plutôt qu’une intention
Un principe qui reste une intention cède à la première pression. Le
pivot a donc été traduit en règles dont chacune se vérifie dans
l’interface. La recommandation vient après la réponse au besoin, jamais
à la place. Deux recommandations par conversation au maximum, trois
modules affichés au plus. Les modules déjà installés ou incompatibles
n’apparaissent pas. La nature de chaque suggestion est affichée. Et
quand rien de fiable ne correspond, l’assistant le dit : un état vide
honnête plutôt qu’une suggestion médiocre. Le benchmark du marché a
situé l’exigence : aucun produit observé ne réunit ces trois gestes,
nommer la nature de la recommandation, donner la raison décisive, savoir
dire non.
Restait à protéger le cadre contre sa propre érosion. Un garde-fou
métrique à seuil complète les règles : si le taux de retours négatifs
sur les messages avec recommandation franchit son seuil, une action est
déclenchée, même si les indicateurs business sont au vert. Une mesure
anti-illusion l’accompagne : les modules encore actifs trente jours
après installation. Un module installé puis désinstallé est un succès
commercial et un échec utilisateur ; le compter comme une victoire
reviendrait à mesurer la dérive comme un progrès.
Une page Figma restée vide
Un cadre de ce type ne se prouve pas en maquette. Un produit
conversationnel se juge en mouvement : états de réflexion du modèle,
latence, erreur de flux en pleine réponse, installation qui échoue à
mi-chemin. Ce sont ces moments qui décident de la confiance, et aucune
image figée n’en rend compte. Les parcours ont donc été conçus
directement en code, dans un playground jouable branché sur les vrais
composants du produit ; la page Figma du projet est restée vide.
Le playground rejoue une dizaine de scénarios typés, du besoin explicite
à l’objectif business, avec leurs états de succès, d’erreur et de
recovery. La carte de recommandation existe en trois déclinaisons, du
format compact au format déplié, et un configurateur fait varier les
contenus et exporte la source de chaque variante. Chaque règle du cadre
devient ainsi vérifiable état par état, en cliquant, pas en la
supposant.
Ce mode de livraison a changé la conversation avec l’équipe de
développement. La revue de flow s’est faite dans le navigateur, en
manipulant. À la fin, les développeurs ont récupéré des composants et un
contrat de données explicite, pas des maquettes à interpréter, avec une
réserve dite telle quelle : les composants sont prêts, rien n’est
plug-and-play, l’intégration reste à câbler. Claude Code a servi de
binôme de fabrication sur tout le chantier ; la vitesse d’itération en
code a rendu tenable ce qui aurait demandé des semaines d’allers-retours
de maquettes.
Le cadre a filtré chaque compromis
La valeur d’un cadre se lit dans les compromis qu’il impose. Quatre sont
documentés.
La barre de progression d’installation est simulée, faute de données
réelles. Plutôt qu’inventer un pourcentage, l’animation montre les
étapes réelles, téléchargement puis installation, sans précision qu’on
n’a pas.
L’achat ne se fait pas dans l’assistant. Pour un module payant, le
parcours renvoie vers la fiche de la marketplace : les cas de
tarification sont trop nombreux pour être traités proprement dans un
panneau de conversation, et un achat mal géré coûterait plus de
confiance qu’un renvoi assumé.
Le modèle choisit en partie ce qu’il affiche. Les règles de tri et de
filtrage vivent pour partie dans les instructions données au LLM, pas
dans le code : rien n’y est acquis par défaut, chaque garde-fou doit
être vérifié en conditions réelles.
Enfin, la première version exploite la recherche existante du catalogue
dans un contexte conversationnel, sans construire de moteur de
recommandation. Aligner cette attente avec les parties prenantes fait
partie du travail de design autant que les écrans.
Un chantier en cours, écrit comme tel
Ce cas n’est pas un bilan. Au moment où ces lignes sont écrites, le
chantier est en cours côté PrestaShop : aucune métrique d’usage
n’existe, et le go collectif de fin de discovery n’est pas signé.
Trois hypothèses critiques attendent leur verdict, chacune outillée avec
ses signaux de mesure. La première : en affichant la nature de la
recommandation, la raison décisive et les signaux de confiance, le
marchand installe au lieu de retourner vers son agence. La deuxième, la
plus risquée : la recherche du catalogue fonctionne par mots-clés et
c’est le modèle qui filtre ; si la pertinence n’est pas au rendez-vous,
une seule suggestion hors sujet suffit à détruire la confiance. La
troisième, le pari du pivot lui-même : la transparence construit l’usage
répété sans faire chuter la conversion.
Dans six mois, ces trois lignes auront une réponse. La question qui
comptera alors n’est pas de savoir si les parcours étaient réussis :
c’est de savoir si le cadre a tenu quand les chiffres sont arrivés.
Mon mandat s’est achevé en août 2026, avant le go collectif. La discovery
a été transmise avec ses instruments : le playground rejouable, le cadre
de recommandation documenté, le garde-fou métrique, les hypothèses
outillées. C’est précisément pour ce genre de passage de main qu’un
principe se traduit en règles vérifiables plutôt qu’en conviction orale.
