L’intelligence artificielle génère aujourd’hui des études, des règles métier ou des dizaines de User Stories en quelques secondes. Cette vitesse produit une masse d’informations difficile à maîtriser. Je peux désormais explorer plusieurs hypothèses ou produire une première découpe très rapidement. Mais cette surproduction crée une impression trompeuse de cohérence : tout est bien écrit, mais les liens entre les éléments restent souvent fragiles.

J’ai donc remis le story mapping au centre de ma stack. J’avais besoin de retrouver un endroit où le produit pouvait être vu et discuté.

FeatureMap : la carte pour structurer le territoire

Pour organiser cette réflexion, j’utilise FeatureMap. C’est un outil en ligne dédié au story mapping. Au lieu d’empiler des tickets dans une liste plate, il permet de visualiser le produit en deux dimensions. L’axe horizontal représente le parcours de l’utilisateur (les activités et les grandes étapes), et l’axe vertical sert à prioriser les besoins et à découper les versions.

Je n’utilise pas FeatureMap comme un simple conteneur de tickets terminés. C’est un atelier vivant. Une carte déplacée raconte l’évolution de notre réflexion. Tant qu’une carte reste dans la zone de conception, je la modifie, je la divise ou je la supprime. Dès qu’elle passe au statut « À faire », elle devient un engagement stable pour le développement.

Le terrain dicte la carte : l’exemple du Village du Livre

J’utilise actuellement cette organisation sur un projet concret : la modernisation du système de gestion et de l’e-commerce du Village du Livre (LVDL). Cette entreprise vend des livres anciens et d’occasion. Nous intervenons sur toute la chaîne qui relie le livre physique à sa vente en ligne : la réception des ouvrages, la photographie, l’estimation du prix, l’impression des étiquettes et la diffusion sur les places de marché.

Dans ce type de projet, la discovery humaine reste irremplaçable. Nous avons observé les volumes et les manipulations sur place. Le patrimoine de LVDL est physique. Un livre peut rester stocké pendant trente ans avant d’être vendu. Cette réalité impose des contraintes qu’une IA ignore totalement.

Nous avons par exemple testé l’IA pour générer automatiquement des fiches produits sur un lot de 80 livres récents. Le résultat textuel était très bon. Mais sur le plan métier, seulement 52 fiches étaient validables. Certaines fiches d’ouvrages de plus de 200 pages n’en indiquaient qu’une seule, tandis que d’autres ne comportaient pas le classement Dewey indispensable à leur validation. La discovery permet de mesurer ce travail réel avant de valider une automatisation aveugle.

Ma stack de conception

La conception et la réalisation de ce produit s’appuient sur une répartition claire des rôles :

• Les équipes du client (LVDL) portent la connaissance du métier et valident les arbitrages.
• Chez BigMentor, je prends en charge la discovery, le framing et le découpage des versions.
• Julien (algor-it) prend en charge le développement technique.
• Les agents IA (comme Codex) explorent les sources, rédigent des brouillons et vérifient la cohérence documentaire.

Concrètement, mon espace de travail est un dépôt Git ouvert dans VS Code. Mon agent assistant y produit les études fonctionnelles, les décisions métier, les maquettes HTML et les autres fichiers Markdown du projet. Il dialogue avec FeatureMap par l’intermédiaire d’un serveur MCP dédié. Autour de lui, je peux mobiliser d’autres agents pour effectuer des contrôles ciblés sur les sources, les règles ou la cohérence documentaire.

FeatureMap offre la mémoire visuelle à laquelle accèdent le client, le Product Owner, le développeur et les agents assistants. Git conserve la mémoire documentaire et permet de reprendre le travail depuis n’importe où. L’IA circule entre les deux.

Le serveur MCP FeatureMap : le garde-fou de la méthode

Dans cette architecture, l’intégration de l’IA repose sur un composant technique fondamental : le serveur MCP (Model Context Protocol) dédié à FeatureMap.

Le protocole standardise la manière dont les agents IA interagissent avec des outils externes. Mais notre serveur ne se contente pas de transmettre des commandes à FeatureMap. Il agit comme une couche intelligente : il s’appuie sur les règles versionnées dans Git, les met à disposition des agents et contrôle leur application lorsqu’ils lisent ou modifient la story map. Il embarque ainsi les règles d’or de notre méthode et agit comme un garde-fou opérationnel.

Peu importe le rôle de l’agent (assistant du Product Owner, agent d’analyse côté client ou assistant au développement pour Julien), le serveur lui rappelle les mêmes règles du jeu. L’agent sait formellement qu’il a l’interdiction de modifier le contenu d’une carte passée au statut « À faire ». Si le besoin évolue, le serveur lui impose de proposer la création d’une nouvelle carte (une V2) plutôt que d’écraser silencieusement l’historique de la fonctionnalité. Ce cadre garantit la stabilité du travail de développement et empêche l’IA de prendre des décisions destructrices.

La carte s’écrit à plusieurs mains autour des US et des Enablers

La modélisation d’un produit repose sur une discussion constante entre les acteurs (client, Product Owner, développeur) autour des User Stories et des Enablers.

Il faut d’ailleurs tordre le cou à une idée reçue : une User Story ne produit pas forcément un écran d’interface. L’expérience de l’utilisateur, ce qu’il vit, peut très bien se traduire par la réception d’un e-mail, un bip sonore, une information vocale ou même une action purement manuelle.

Dans notre backlog, la règle est simple : tout ce qui n’est pas une US est un Enabler. Qu’il soit technique, lié à l’infrastructure, fonctionnel, UX ou commercial, l’Enabler permet au développeur (et à tout participant) d’exposer ses choix et d’inscrire ses décisions. C’est pour cette raison que la plupart de nos cartes sont écrites à plusieurs mains.

Cette approche est indispensable pour assurer une traçabilité totale. Le backlog conserve la trace des évolutions et des corrections, sans confondre l’histoire du besoin avec un journal technique de résolution des bugs. Il raconte ce que nous avons fait, et surtout pourquoi nous l’avons fait.

L’exemple de la diffusion du catalogue sur les places de marché illustre bien ce principe. Le besoin de départ semblait simple : publier les nouvelles fiches et maintenir leurs offres sur Amazon, eBay, le-livre.fr et les autres canaux utilisés par LVDL. Mais parler seulement de « place de marché » ne suffisait pas. LVDL peut, par exemple, utiliser plusieurs comptes Amazon, chacun avec ses propres produits, sa devise, sa règle tarifaire et sa configuration technique.

Nous avons donc introduit dans l’Enabler de modélisation le concept de « Destination de publication ». Une destination représente une configuration concrète d’un canal : un compte Amazon donné, un compte eBay ou le-livre.fr. Elle possède ses critères de sélection des produits, sa devise, sa règle de prix et son connecteur. Ce modèle permet au client de raisonner sur ses canaux de diffusion, tandis que le développeur dispose d’objets et de règles suffisamment précis pour construire le système.

Ce modèle ne vient pas d’un atelier isolé. Le client apporte la réalité de ses comptes, de ses règles commerciales et des produits qu’il veut diffuser. Le développeur confronte ces besoins aux différents types de connecteurs, aux API et aux flux FTP. L’IA nous aide à explorer les conséquences et à maintenir la cohérence du modèle. Les US traduisent ensuite ce travail en expériences concrètes : ajouter une destination, choisir ses produits, configurer son connecteur ou suivre les synchronisations.

Cette modélisation a également permis d’écarter plusieurs fausses bonnes idées générées par l’IA. Le système historique porte des millions de références et les taux de change varient tous les jours. Une règle algorithmique naïve proposait de recalculer et de republier toutes les offres au moindre changement de taux. L’Enabler a permis d’acter une décision pragmatique : nous conservons le dernier taux connu et nous laissons une surcote absorber les petites variations, sans déclencher de republication massive.

Ne pas mentir sur l’état du système

La confrontation entre la technique et l’expérience utilisateur permet aussi d’ajuster le vocabulaire. Lors de la synchronisation vers une place de marché, les flux techniques réagissent différemment. Une API peut répondre immédiatement, tandis que certains flux FTP ne renvoient aucune confirmation exploitable.

Afficher un statut « Succès » universel aurait été trompeur. Nous avons donc séparé l’état d’exécution interne du résultat métier. Quand plus aucune action automatique n’est attendue, la demande est marquée comme « Clôturée », que l’opération ait été confirmée, refusée ou simplement transmise. Pour le résultat réel, l’interface affiche explicitement des statuts comme « Transmise sans confirmation ». Le vocabulaire reflète strictement les limites techniques du système.

Le cycle complet

Dans la pratique, ce fonctionnement n’est pas une chaîne linéaire. Le terrain nourrit l’objectivation, puis l’étude et la modélisation. Les User Stories, les Enablers et les mockups entrent ensuite dans une boucle de conception : nous les confrontons, nous arbitrons, nous révisons et nous redécoupons jusqu’à obtenir un ensemble suffisamment cohérent pour donner une intention à une version.

Le développement ne conduit pas automatiquement à la mise en production. Lorsque nous estimons que la version a atteint un niveau de maturité suffisant, nous décidons de son passage vers la préproduction ou la production par la chaîne CI/CD. La story map rend aussi ce moment visible : elle montre ce qui relève encore de la conception, ce qui est engagé dans le développement et ce qui peut entrer dans le flux de déploiement.

Les tests et les retours du produit réel ne ferment pas le cycle. Ils produisent de nouveaux apprentissages qui reviennent nourrir le terrain, les décisions et une nouvelle boucle de conception.

Les versions portent une intention

La story map me permet de préparer les versions de livraison. Je regarde une version comme une étape du produit, avec une raison d’être et des critères de réussite.

Une ligne de type Feature rassemble toutes les capacités d’une fonctionnalité. Je répartis ensuite progressivement les cartes de cette Feature dans plusieurs versions (V1 : socle utilisable, V2 : enrichissement, etc.). Je conserve les fonctions futures dans la map, sans brouiller l’objectif de la version en cours de développement.

L’IA m’aide à explorer rapidement des idées et à fouiller des documents. La story map m’aide à faire le tri, à visualiser le chemin parcouru et à engager la discussion avec le client et l’équipe technique. Ce double dispositif protège la vision du produit.

Ce que je cherche à préserver

Cette organisation n’est pas une recette figée. Elle me permet surtout de conserver un fil visible entre ce que nous observons, ce que nous imaginons, ce que nous décidons et ce que nous déployons. L’IA accélère l’exploration, Git conserve la trace, la CI/CD automatise le passage vers les environnements, mais l’équipe reste responsable du moment où une hypothèse devient un engagement puis un produit réellement utilisé.

La story map est mon repère dans ce mouvement. Elle ne remplace ni la discussion, ni l’arbitrage, ni les tests. Elle rend leur enchaînement visible et permet aux acteurs du projet de comprendre où se trouve une décision, ce qui lui manque encore et ce que le produit réel nous oblige à revoir.

Cette manière de relier discovery et delivery continue d’évoluer avec le projet. Comment rendez-vous visible, dans vos équipes, le passage d’une idée explorée à une version suffisamment mature pour partir en préproduction ou en production ? Et où conservez-vous les apprentissages qui doivent nourrir la boucle suivante ?