Portail Expert : remplacer un outil avec une squad de trois

Remplacer l’outil sans l’équipe standard

Le portail Expert devait remplacer Impartner dans une fenêtre courte. La décision de quitter l’outil avait déjà été instruite : le sujet n’était plus de convaincre l’organisation qu’un portail maison était nécessaire, mais de le livrer sans recréer une organisation projet lourde autour de lui. Le versant stratégique de cette décision est raconté dans l’étude de cas Refonte du portail Expert : instruire une décision stratégique par la preuve. Ici, le sujet est la mécanique de livraison qui a rendu cette décision exécutable.

Le produit livré n’avait pas une seule surface. Il y avait un front public, l’annuaire des agences visible par les marchands sur experts.prestashop.com/fr/agences, et un back-office privé pour les agences, accessible seulement avec un compte depuis experts.prestashop.com/fr/connexion. Cette séparation compte pour le récit : ce qui est public peut être pointé ; ce qui relève de l’espace agence reste montré en wireframes.

L’équipe coeur tenait en trois rôles : une PM, un tech lead orienté backend, et moi côté design. À cette taille, le modèle classique du handoff devenait un risque en soi. Si la PM rédigeait, que le design produisait des maquettes, puis que le développement reconstruisait les écrans en interprétant les écarts, la mécanique aurait consommé trop de temps et trop d’attention.

Il fallait remplacer l’outil, mais aussi remplacer la façon de produire.

Le piège du handoff

Le handoff fonctionne quand l’équipe peut absorber la traduction entre les métiers. Ici, cette traduction aurait été le coût caché du projet : reprendre les écrans, expliquer les états, corriger les espacements, arbitrer les cas vides, vérifier le multilingue, réouvrir les sujets après intégration.

Ce n’était pas un problème de bonne volonté. C’était un problème de mécanique. Chaque passage de relais ajoutait une couche d’interprétation au moment où l’équipe avait besoin de réduire les ambiguïtés.

La décision structurante a donc été de déplacer une partie du design dans le produit lui-même. Figma est resté utile pour clarifier l’intention, partager une direction ou garder une trace. Mais la source de vérité de l’interface est devenue le code.

Trois rôles plus nets

La PM n’a pas été remplacée par un prompt. Son rôle est devenu plus exigeant : expliciter le problème, les règles métier, les décisions ouvertes et les compromis acceptables. Le brief n’était pas un ticket jeté de l’autre côté du mur, mais un objet vivant que l’IA pouvait aider à challenger parce qu’il était suffisamment clair.

Le tech lead n’est pas intervenu seulement à la fin pour relire. Son travail a commencé avant la génération : poser les conventions, structurer les instructions, clarifier les frontières entre frontend, backend et API, rendre la base de code praticable. L’un des apprentissages les plus nets du chantier est venu d’une erreur initiale : trop d’instructions globales, trop d’architecture injectée au même endroit, et l’IA mélangeait les responsabilités. Le correctif n’a pas été de “mieux demander”. Il a été de mieux cadrer.

Côté design, le rôle a changé de nature. Les décisions d’interface, de densité, de hiérarchie et d’états n’étaient plus uniquement décrites dans une maquette. Elles étaient travaillées dans le front, corrigées dans le navigateur, committées, puis reprises par le développement quand l’intégration API le nécessitait.

Cette redistribution n’a pas supprimé les métiers. Elle a supprimé une partie de la traduction entre eux. La PM ne devenait pas designer, le design ne devenait pas backend, le tech lead ne devenait pas garant de chaque micro-décision visuelle. Chacun gardait sa souveraineté, mais le relais se faisait sur des artefacts plus exécutables.

Du ticket à la prod, un chemin balisé

Le chantier tenait parce que la trajectoire était répétable. Chaque sujet passait par le même chemin : ticket Jira, branche dédiée, décomposition, code, revue, commit et PR, merge, preprod, prod.

La décomposition était une étape de conception à part entière. Avant la première ligne, il fallait nommer la feature, les fichiers cibles, les états attendus, les points d’intégration et les questions bloquantes. Ce moment protégeait le reste du flow : l’IA pouvait produire vite parce que le problème avait été réduit à une surface claire.

La revue n’était pas une relecture molle. Elle couvrait les tests, l’architecture, le CSS, l’i18n, TypeScript, le respect du design system, le playground et le format de commit. Puis le commit repassait par les garde-fous habituels : staging explicite, message conventionnel, hooks et CI. À chaque étape, un humain validait le cap, et un garde-fou cadrait le geste.

Le playground comme lieu de vérité

Le levier le plus important n’a pas été une page de démo. C’était un espace de travail : un playground de sections, accessible en développement, où chaque morceau du portail pouvait être vu dans ses états clés.

Un écran ne se limite jamais à son état idéal. Il a un état vide, un chargement, une erreur, une donnée partielle, une permission différente, une langue plus longue. Le playground rendait ces variations navigables sans attendre que tout le backend soit prêt. Le design pouvait donc avancer sur une expérience réelle, et le backend pouvait garder son attention sur les données, les règles et l’architecture.

La frontière était importante : les mocks restaient dans le cadre de développement, les appels API restaient la responsabilité de l’intégration, et le design system servait de contrainte par défaut. Le but n’était pas de bricoler plus vite. Le but était de produire un front suffisamment juste pour devenir une base de travail, pas une illustration.

La méthode née sur ce chantier a ensuite été formalisée comme un pattern à part entière : Playground-driven design. Le case study montre le contexte qui l’a fait émerger ; la méthode explique comment la répliquer sans copier-coller l’implémentation exacte.

Le cycle design front

Le cycle côté front reprenait le même pipeline que le développement, mais changeait le sens du mot coder. Ici, coder, c’était concevoir dans le médium final.

Premier temps : intention cadrée. Le travail commençait par un prompt qui posait le besoin, le but de l’écran, les contraintes de design system et les états à couvrir. Pas de feuille blanche, pas de génération lancée avant d’avoir réduit l’ambiguïté.

Deuxième temps : proposition IA. L’agent produisait un premier écran, jamais vide, déjà contraint par les composants existants. Cette première sortie n’était pas une réponse finale. C’était une matière manipulable.

Troisième temps : vibe design. L’itération se faisait sur l’écran réel. Hiérarchie, densité, rythme, clarté des libellés, équilibre des états : les corrections partaient du rendu, pas d’une spec abstraite. Des skills UX et UI pouvaient challenger la proposition, mais la décision restait humaine.

Quatrième temps : arbitrage et validation. Quand l’écran était juste, il repartait dans le flow commun : revue, commit, PR, merge, preprod, prod. Ce n’était pas sauter l’étape design. C’était déplacer l’itération design dans un médium plus exigeant, parce qu’il ne ment pas autant qu’une maquette.

Trois couches de garde-fous

Le système ne reposait pas sur une vigilance permanente. Il reposait sur trois couches.

La première était écrite : des instructions hiérarchisées, chargées par contexte, avec une séparation claire entre vision produit, conventions techniques et règles de design. L’erreur initiale avait été de trop concentrer dans un seul cadre. La correction a été de découper.

La deuxième était automatisée : conventions, type-check, lint, tests, build, hooks et CI. L’IA pouvait écrire vite parce que la base refusait mécaniquement une partie des sorties fragiles.

La troisième était visuelle : playground local, tests ciblés, revues spécialisées, comparaison directe avec les états attendus. Sans visibilité rapide, la vitesse de génération aurait seulement accéléré la découverte tardive des erreurs.

Une règle simple résumait aussi l’écriture front : PUiK d’abord, custom seulement quand le design system ne couvrait pas le besoin. Sortir du système devait être explicite, rare et justifiable. C’est cette contrainte qui rendait le produit maintenable après l’accélération.

Ce que l’IA a vraiment changé

L’IA a accéléré l’exécution, mais elle n’a pas porté la responsabilité du produit. Elle a généré, restructuré, proposé, corrigé, documenté. Les arbitrages sont restés humains : ce qui devait être visible, ce qui devait attendre, ce qui devait rester dans le design system, ce qui pouvait être mocké, ce qui devait être confié au backend.

La pratique a été mesurée. Sur la fenêtre de reconstruction, le travail a représenté 206 heures de direction IA active, 235 commits et 21 458 actions IA pilotées. Ces chiffres ne prouvent pas que l’IA “fait le travail”. Ils prouvent plutôt qu’une grande partie de l’exécution peut être déplacée si le cadre est assez explicite pour rester contrôlable.

Les outils ont aussi changé en cours de route. Claude Code a porté une partie du chantier, Codex a pris une place croissante ensuite. Ce déplacement est révélateur : la méthode ne dépendait pas d’un outil unique. Elle dépendait de la capacité à écrire les règles du jeu, vérifier le résultat et corriger sans perdre la direction.

Ce que la squad a livré

La V1 du portail maison a été livrée pour le cutover de juin 2026. À mon départ, l’outil était en production : l’annuaire public côté marchands était accessible en ligne, et l’espace agence privé passait par une connexion. Le point important n’est donc pas seulement que l’ancien outil ait été remplacé. C’est que la nouvelle mécanique de travail ait laissé une base plus modifiable : des sections visibles, des états identifiés, des décisions d’interface versionnées, une séparation plus claire entre expérience front et intégration backend.

Dans une équipe aussi resserrée, cette clarté compte autant que la vitesse. La PM pouvait concentrer l’énergie sur les règles et les arbitrages. Le tech lead pouvait sécuriser les rails et les points durs. Le design pouvait avancer sans attendre que chaque donnée soit disponible, tout en restant dans le produit.

La boucle design-dev n’a pas disparu parce que les métiers auraient fusionné. Elle s’est raccourcie parce que chacun a pris une responsabilité plus nette.

Les premiers signaux après lancement

L’ancien outil imposait une contrainte majeure : une partie de la valeur restait invisible. Le programme savait qu’il existait une activité, mais il ne pouvait pas lire correctement les vues, les contacts, la qualification des demandes ou la dynamique réelle des agences.

Le nouveau portail a changé cette situation dès la mise en production. Sur la fenêtre du 1er juin au 31 juillet 2026, les premiers signaux deviennent observables : 247 partenaires connectés, dont 91 nouveaux et 156 réactivés ; 139 nouveaux comptes créés en self-service ; environ 36 marchands uniques ayant soumis un brief, pour 87 soumissions brutes ; 70 certifications achetées ; 211 abonnements actifs ; 417 stores vérifiés.

Ces chiffres ne sont pas une conclusion définitive. Ils disent surtout que le programme est sorti du brouillard. Ce qui était auparavant impossible à objectiver devient suivable, comparable, améliorable.

Perfect Match est la conséquence logique de ce nouveau socle, pas une preuve de production à revendiquer ici. L’ancien annuaire pouvait afficher des profils. Le nouveau portail peut structurer un brief marchand, qualifier le besoin, exploiter des données agence plus propres et préparer un matching plus crédible. Le point à valoriser est donc la capacité rendue possible par le portail, pas un statut de lancement Perfect Match.

Ce que le modèle ne prouve pas

Ce cas ne dit pas qu’une squad de trois suffit toujours à remplacer un outil. Il dit l’inverse : le modèle tient seulement si le périmètre V1 est borné, si la couche backend peut être isolée, si le design system couvre déjà une grande partie des besoins, si les instructions de travail sont traitées comme de l’infrastructure, et si quelqu’un vérifie vraiment ce que l’IA produit.

Sans ces conditions, l’accélération devient une dette.

La leçon durable est là : concevoir dans le code n’est pas une posture anti-Figma, ni une fascination pour l’IA. C’est une manière de supprimer une traduction quand cette traduction coûte plus cher que ce qu’elle protège. Dans ce chantier, la maquette restait utile quand elle clarifiait une décision. Le code devenait prioritaire quand il fallait vérifier un état, un rythme, une règle ou une interaction qui devait réellement tenir en production.