Entretiens avec les parties prenantes
Entretiens fondateur et fleuriste, analyses sur l'opération existante, cartographie du parcours client pour les acheteurs de cadeaux US et UE, portée de la politique de substitution.
Étude de cas · Distribution · Fleuristerie
FlowDelivery — découverte pour une paire d'applications de fleuristerie
Comment nous avons mené une découverte complète pour FlowDelivery — un produit mobile jumelé client-et-fleuriste couvrant l'analyse, l'UX et l'architecture système, avec un catalogue adapté aux stocks, des cartes de produits dynamiques, un paiement client en trois étapes et un modèle de données unifié qui répond aux attentes des publics US et UE sous RGPD et CCPA dès le premier jour.
Le brief — concevoir un produit jumelé avant d'écrire une seule ligne de code
Les fondateurs de FlowDelivery sont venus nous voir avec une paire coordonnée de produits mobiles à concevoir : une application côté client pour commander des bouquets avec livraison, et une application fleuriste interne pour gérer l'assortiment et suivre la disponibilité des composants. Les deux applications devaient partager un modèle de données pour que la visibilité du catalogue reflète le stock en temps réel sans intervention manuelle, et l'expérience client devait compresser la décision d'achat de bouquet — historiquement un achat à haute anxiété — en un paiement en trois étapes. Le profil d'acheteur couvre les États-Unis et l'Union européenne pour la livraison de fleurs : des acheteurs de cadeaux qui arrivent avec moins de deux minutes d'attention, un filtre de goût visuel fort et une vraie attente que ce qu'ils voient sur la carte du produit soit ce qui arrive chez le destinataire. Les approches MVP code-first ont été éliminées dès le début car les règles d'inventaire, la politique de substitution et la réconciliation du catalogue multi-stores ne peuvent pas être déduites des écrans seuls — un premier build reconstruit généralement le modèle de données deux ou trois fois dans les six premiers mois. Les modèles de marketplace prêts à l'emploi ont été éliminés car leur modèle de bouquet-en-tant-que-produit suppose un catalogue SKU plat et ne peut pas représenter la structure de recette-de-composants que la fleuristerie requiert réellement. Le résultat est un package de découverte piloté par Figma — cartographie du parcours client, modèle de données typé, spécification OpenAPI, prototype cliquable, tokens de design, table de politique de substitution et document de remise découverte-à-build. Le package est l'artefact qu'une équipe de build peut utiliser pour cadrer un build à prix fixe, et que le fondateur peut utiliser pour évaluer des propositions de fournisseurs sur un pied d'égalité.
Points clés du projet
Découverte complète — analyse, UX, architecture
Catalogue intelligent avec visibilité adaptée aux stocks
Cartes de produits dynamiques avec prix en direct
Paiement client en trois étapes
Application d'inventaire et de substitution fleuriste
Modèle de données unifié entre les applications
Spécification OpenAPI + collection Postman
Cadrage RGPD + CCPA US & UE
Les chiffres clés
Un aperçu de ce que la découverte FlowDelivery a livré dans l'application client, l'application fleuriste et le modèle de données partagé lors de son premier cycle.
2produits mobiles jumelés conçus en parallèle — client et fleuriste — partageant un seul modèle de données typé
3étapes de paiement pour le flux client — panier, sélection de livraison, paiement — correspondant à la durée d'attention de l'acheteur de cadeaux
0métriques d'utilisateurs ou de revenus fabriqués dans cette étude de cas — uniquement des faits de découverte
1spécification OpenAPI couvrant chaque point de terminaison entre les deux applications et le backend partagé
1table de politique de substitution par recette de bouquet — préserve l'identité visuelle quand un composant se fait rare
6–10 sem.fenêtre de livraison typique pour un package de découverte de produit jumelé comparable
Pourquoi la conception pilotée par la découverte plutôt que le MVP code-first et les modèles prêts à l'emploi
La décision de méthodologie domine tous les autres choix architecturaux sur un produit client-et-opérateur jumelé. Nous avons choisi un processus de découverte piloté par Figma produisant un modèle de données typé, une spécification OpenAPI et un prototype cliquable avant qu'aucun code de production ne soit écrit, car les compromis s'alignent parfaitement avec la façon dont un produit client-et-fleuriste jumelé échoue réellement quand il est précipité. Un MVP code-first reconstruit généralement le modèle de données deux ou trois fois dans les six premiers mois car les règles d'inventaire et la politique de substitution ne peuvent pas être déduites des écrans seuls — et chaque reconstruction coûte plus que la phase de découverte aurait coûté. Les modèles de marketplace prêts à l'emploi ont été éliminés car leur modèle de bouquet-en-tant-que-produit suppose un catalogue SKU plat et ne peut pas représenter la structure de recette-de-composants que la fleuristerie requiert.
Le troisième candidat, une passe de wireframes UX pure sans architecture, est un moyen légitime d'économiser des coûts — mais pour un produit client-et-opérateur jumelé, le modèle de données est le produit, et une passe de wireframes qui n'aborde pas le modèle de données typé et le contrat d'API laisse l'équipe de build inventer les deux. Le package de découverte — cartographie du parcours client, modèle de données typé, spécification OpenAPI, collection Postman, bibliothèque de composants avec tokens de design, prototype cliquable et enregistrement de décision d'architecture — est ouvert et citable de bout en bout, sans chaîne de fournisseur ou de modèle qui verrouille l'équipe de build dans une seule méthodologie.
| Dimension | Découverte-piloté (FlowDelivery) | MVP code-first | Modèle prêt à l'emploi |
|---|---|---|---|
| Taux de retouche | Faible — modèle de données et API validés en conception | Élevé — deux ou trois reconstructions du modèle de données typiques | Caché — les contraintes du modèle imposent la forme |
| Qualité de la spécification | OpenAPI + Postman + cartographie du parcours | Déduite du code à mesure qu'il est livré | Documentée par le fournisseur ; variable |
| Clarté de l'architecture | ADR pour chaque compromis significatif | Implicite ; dépend de l'équipe | Définie par le fournisseur ; opaque |
| Délai jusqu'à l'artefact investissable | 6–10 semaines — finançable sur un prototype | 3–6 mois — dépend du rythme de build | 2–4 semaines — mais indifférencié |
| Coût du changement | Faible — changer la spécification, pas le code | Élevé — refactorisation du code à chaque itération | Limité par la flexibilité du modèle |
| Portabilité fournisseur | Élevée — la spécification est agnostique à l'équipe de build | Faible — le code est couplé à l'équipe de build | Zéro — verrouillé au fournisseur |
| Adéquation de conformité (US & UE) | Conçue — consentement dans le flux utilisateur | Ajoutée après le lancement | Contrôlée par le fournisseur ; variable |
Références de méthodologie : Initiative OpenAPI, Documentation Figma, Centre d'apprentissage Postman.
Conception de l'application client — catalogue intelligent et paiement en trois étapes
L'application client est conçue autour d'un catalogue intelligent qui cache les bouquets dont les fleurs composantes sont indisponibles plutôt que de laisser un acheteur tomber amoureux d'un arrangement qu'il ne peut pas avoir aujourd'hui. Les cartes de produits dynamiques recalculent le prix depuis le coût actuel des marchandises plutôt que de lire un cache dénormalisé, pour que le prix que l'acheteur voit sur la carte soit le prix qu'il paie à la caisse. La hiérarchie de la carte place le visuel en premier (une grande photo avec un recadrage cohérent), le prix prêt pour le destinataire en deuxième et l'affordance de fenêtre de livraison en troisième — l'ordre des décisions qu'un acheteur de cadeaux prend réellement dans la fenêtre d'attention de moins de deux minutes.
Le paiement est en trois étapes — panier, sélection de livraison, paiement — et chaque étape est réversible sans perdre le contexte précédent. La première étape montre le panier avec des badges de substitution si une recette est en limite de disponibilité ; la deuxième étape choisit l'adresse du destinataire, la fenêtre de livraison et une bascule optionnelle de remise sans contact ; la troisième étape est le paiement avec support de carte enregistrée et rachat en un tap. L'ensemble du flux est mobile-first, les tokens de design sont documentés dans une bibliothèque Figma, et le prototype est assez cliquable pour les tests utilisateurs sans écrire de code. L'application client est la surface que notre pratique de développement d'applications mobiles porte dans la phase de build.
Conception de l'application fleuriste — inventaire, recettes, politique de substitution
L'application fleuriste est le cœur opérationnel du produit et la partie qui, mal faite, coule l'application client en un mois. Le fleuriste voit le même modèle de données que voit le client, de l'autre côté : une liste de recettes de bouquets, les composants que chaque recette requiert, l'inventaire en direct des tiges et accessoires, et une politique de substitution par recette qui permet au fleuriste de définir des échanges approuvés qui préservent l'identité visuelle. Quand un composant se fait rare, le catalogue recalcule automatiquement la disponibilité ; les recettes qui peuvent être réalisées avec des substitutions montrent un badge discret côté client, tandis que les recettes qui ne peuvent pas du tout être réalisées sont cachées jusqu'au réapprovisionnement de l'inventaire.
L'édition des bouquets et des prix se trouve dans l'application fleuriste sous un formulaire typé qui émet des mises à jour validées vers le backend partagé. Un changement dans le nombre de composants d'une recette, un prix ou une règle de substitution se propage au catalogue client en quelques secondes — pas de synchronisation manuelle. Là où la spécification initiale du fondateur appelait à une fonctionnalité coûteuse, nous avons proposé une alternative plus légère qui maintenait la fonctionnalité complète tout en réduisant le budget et le délai : le recalcul de disponibilité en direct est l'exemple canonique, remplaçant un tableau de bord prévu par store par une seule liste à recalcul automatique. L'ensemble de l'architecture est livré dans le cadre de notre pratique de développement de logiciels sur mesure.
Posture de confidentialité, spécification prête pour l'audit et conception du consentement
La posture de confidentialité de FlowDelivery était une décision de conception avant d'être une bannière. La spécification minimise les données personnelles par conception : l'application client ne conserve que ce qui est nécessaire pour le paiement, la livraison et le rachat, et l'application fleuriste ne conserve rien sur l'acheteur au-delà d'un nom de destinataire et d'une adresse cadré par une seule livraison. Le modèle de données encode des fenêtres de rétention par entité pour que l'équipe de build dispose de conseils explicites sur la durée de conservation d'un enregistrement de commande livrée et sur ce qu'il faut purger.
La conception du consentement fait partie du package de découverte, pas un ajout post-lancement. Le flux client affiche un consentement granulaire de style RGPD pour les utilisateurs dans l'Union européenne et une divulgation de style CCPA « Ne pas vendre ou partager mes informations personnelles » pour les utilisateurs en Californie dans la même étape de paiement. L'architecture est construite pour s'aligner avec les obligations du RGPD pour les utilisateurs dans l'Union européenne et du CCPA / CPRA pour les utilisateurs en Californie et aux États-Unis — et pour faire du travail de confidentialité de la phase de build un exercice de documentation plutôt qu'une refonte architecturale.
Posture de conformité : Aligné RGPD · Prêt ISO 27001 · SOC 2 Type II en cours · Compatible HIPAA · CCPA reconnu.
Méthodologie de livraison
Une découverte en cinq phases qui a conduit FlowDelivery d'un pitch fondateur en une ligne à une spécification finançable et prête pour le build pour la paire d'applications client-et-fleuriste.
Modèle de données & API
Modèle de données typé pour les bouquets, recettes, composants, inventaire, commandes et substitutions ; spécification OpenAPI ; collection Postman exercitant chaque point de terminaison.
UX & prototype
Prototype de l'application client avec paiement en trois étapes, prototype de l'application fleuriste avec gestion des recettes et de l'inventaire, bibliothèque de composants Figma, tokens de design.
Politiques & recalcul
Politique de substitution par recette, logique de recalcul de disponibilité, cadrage de confidentialité prêt pour l'audit, conception du consentement adapté à la région pour le lancement US et UE.
Remise & cadrage
Enregistrements de décisions d'architecture, package de remise à l'équipe de build, cadre d'évaluation des fournisseurs pour le fondateur et document de cadrage à prix fixe pour le build.
Cadrage du build, évaluation des fournisseurs et aller aux investisseurs
Le package de découverte de FlowDelivery a été délibérément conçu comme un artefact à plusieurs usages. Le premier public est l'équipe de build — interne ou externe — qui peut utiliser le modèle de données typé, la spécification OpenAPI, la collection Postman et le prototype cliquable pour cadrer un build à prix fixe avec confiance et sans prime de dérive de périmètre. Le deuxième public est le fondateur, qui peut utiliser le même package pour évaluer des propositions de fournisseurs sur un pied d'égalité — chaque fournisseur voit la même spécification, rend une offre contre le même périmètre, et le fondateur n'est plus dans la position peu enviable de comparer des pommes et des oranges entre des documents aux couleurs des fournisseurs. Le troisième public est les investisseurs : un prototype cliquable qui démontre un produit crédible sans le coût ou le risque d'un build code-first est un artefact finançable, en particulier pour un fondateur non-technique allant à un tour seed. Nous avons documenté chaque compromis d'architecture significatif comme un ADR — granularité de la politique de substitution, cadence de recalcul de l'inventaire, sélection du prestataire de paiement, granularité de la fenêtre de livraison — pour que le fondateur dispose d'une réponse défendable quand un investisseur ou un fournisseur demande « pourquoi de cette façon et pas autrement ». Là où la spécification initiale du fondateur appelait à une fonctionnalité coûteuse, nous avons proposé une alternative plus légère qui maintenait la fonctionnalité complète tout en réduisant le budget et le délai ; ces substitutions sont documentées comme des compromis de périmètre que le fondateur peut revoir quand le produit mûrit.
Lancement aux États-Unis et dans l'Union européenne
La découverte de FlowDelivery a été structurée pour un lancement en base de code unique dans les publics US et UE. La conception de l'application client sert des acheteurs de cadeaux en Californie, à New York, au Texas, en Floride et à Washington aux États-Unis, et des acheteurs de cadeaux aux Pays-Bas, en Allemagne, en France, en Irlande et en Suède dans l'UE, sans fork de la base de code par région. Les flux de consentement sont adaptés à la région au niveau de la conception : les clients de l'UE et l'EEE reçoivent un écran de consentement granulaire de style RGPD avec des bascules séparées pour les analyses de produit optionnelles ; les clients de Californie reçoivent une divulgation de style CCPA « Ne pas vendre ou partager mes informations personnelles » dans la même étape de paiement. Les pratiques de traitement des données sont alignées avec le RGPD pour les utilisateurs européens et avec le patchwork de confidentialité des États américains — CCPA / CPRA (Californie), VCDPA (Virginie), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) et Oregon CPA. Comme le modèle de données minimise les données personnelles par conception et encode des fenêtres de rétention par entité, la conformité régionale se réduit à une divulgation honnête et un flux de consentement propre plutôt qu'à une ségrégation des données par juridiction.
La phase de build est architecturée pour se déployer dans les régions UE et US en parallèle — Pays-Bas, Allemagne, France, Suède et Irlande pour la couverture UE ; US East et US West pour l'Amérique du Nord — pour que la paire d'applications serve les deux marchés avec une faible latence dès le lancement. Le modèle de politique de confidentialité livré avec le package de découverte documente l'architecture ci-dessus, citant les obligations RGPD et les obligations CCPA de Californie directement. L'équipe de découverte est répartie sur le fuseau CET et travaille avec un chevauchement Est-US (9h–13h ET) pour les entretiens avec les parties prenantes, les révisions de prototype et les conversations sur les ADR — le fuseau qui permet à un fondateur basé aux États-Unis et à une équipe de découverte UE de partager quatre heures de chevauchement en direct chaque jour. Le package de découverte sert un lancement US & UE comme une spécification unifiée.
Livrables de découverte et feuille de route de build
Conception de découverte
Prototypage UX
Figma
Architecture système
Architecture de l'information
Design de service
Cartographie du parcours client
Conception du modèle de données
Spécification API REST
OpenAPI
Collections Postman
Bibliothèque de composants
Tokens de design
Design mobile-first
Modèle de données d'inventaire
Paiement en trois étapes
Catalogue adapté aux stocks
Politique de substitution
La feuille de route active de développement de logiciels sur mesure pour FlowDelivery — une fois que la découverte remet au build — comprend les clients iOS et Android côté client, le client Android fleuriste, un backend Symfony ou Laravel derrière la spécification OpenAPI, un worker de recalcul de disponibilité, une intégration de prestataire de paiement avec Stripe et Apple Pay / Google Pay, et une couche de routage de livraison qui choisit le fleuriste avec le moins de friction par commande. Un niveau B2B pour les cadeaux d'entreprise aux États-Unis et dans l'UE est cadré comme une extension de phase deux, avec le sous-système d'habilitations déjà structuré pour l'affectation multi-destinataire. Les plans d'infrastructure comprennent une future évaluation indépendante de préparation intégrée dans la feuille de route cloud & DevOps, plus un pipeline analytique structuré qui respecte le flux de consentement dès le premier jour.
Mener une découverte similaire — parlons-en
Si vous planifiez un produit client-et-opérateur jumelé, une marketplace ou toute plateforme où le modèle de données est le produit et une spécification agnostique à l'équipe de build est le bon point de départ pour les publics US et UE, nous avons mené ce processus de découverte de bout en bout et pouvons réduire considérablement le délai jusqu'à l'artefact investissable. L'équipe technique et de conception derrière FlowDelivery fait partie de YuSMP Group. Nous travaillons à prix fixe pour les découvertes bien définies et avec des équipes dédiées pour la livraison continue dans la phase de build, avec un horaire CET et une fenêtre garantie de chevauchement Est-US (9h–13h ET) pour les points quotidiens, les révisions de prototype et les conversations sur les ADR.
Questions fréquentes
Quel est le coût de la découverte pour un produit mobile client plus opérateur jumelé ?
Une découverte ciblée couvrant l'analyse, la conception UX, l'architecture système et le modèle de données partagé pour un produit client plus opérateur jumelé coûte généralement entre 35 k€ et 90 k€. L'ajout d'un prototype Figma cliquable, d'une spécification OpenAPI, d'une collection Postman, d'une bibliothèque de composants avec tokens de design et d'un package de remise découverte-à-build porte une découverte de spécification complète à 95 k€–180 k€. Les principaux facteurs de coût sont la cartographie du parcours client, la conception du modèle de données et le travail sur la politique de substitution et d'inventaire qui prévient les retouches dans la phase de build.
Pourquoi mener une découverte avant d'écrire du code sur un produit marketplace ?
Un MVP code-first sur un produit client plus opérateur jumelé reconstruit généralement le modèle de données deux ou trois fois dans les six premiers mois car les règles d'inventaire, la politique de substitution et la réconciliation du catalogue multi-stores ne peuvent pas être déduites des écrans seuls. La conception pilotée par la découverte produit un modèle de données typé, un contrat d'API et un prototype UX avant qu'aucun code de production ne soit écrit, ce qui comprime la phase de build, réduit les retouches et donne au fondateur un artefact finançable pour les conversations avec les investisseurs bien avant la première ligne de Swift ou Kotlin.
Comment concevoir un catalogue adapté aux stocks pour une application de livraison de fleurs ?
Un catalogue adapté aux stocks est une décision de modèle de données avant d'être une décision d'interface. Chaque bouquet est une recette de fleurs composantes ; le catalogue calcule la disponibilité par recette en joignant l'inventaire en direct dans les emplacements du fleuriste et cache les recettes dont les composants sont indisponibles. Les cartes de produits dynamiques recalculent le prix depuis le coût actuel des marchandises plutôt que de lire un cache dénormalisé. Une table de politique de substitution par recette donne au fleuriste une liste d'échanges approuvés qui préserve l'identité visuelle quand un composant se fait rare.
Que contient un package de remise piloté par la découverte ?
Un package de remise piloté par la découverte contient une cartographie du parcours client, un modèle de données typé avec relations et contraintes, une spécification OpenAPI, une collection Postman qui exercite chaque point de terminaison, une bibliothèque de composants Figma avec tokens de design, un prototype cliquable couvrant les flux prioritaires et un enregistrement de décision d'architecture écrit par compromis significatif. Le package est l'artefact qu'une équipe de build — interne ou externe — peut utiliser pour cadrer un build à prix fixe avec confiance et qu'un fondateur peut utiliser pour évaluer des propositions de fournisseurs sur un pied d'égalité.
Combien de temps prend la découverte pour un produit client plus opérateur jumelé ?
Une découverte ciblée pour un produit client plus opérateur jumelé prend généralement 6 à 10 semaines. Les deux premières semaines sont des entretiens avec les parties prenantes et des analyses sur l'opération existante ; les semaines trois à six couvrent le modèle de données, la spécification d'API et le prototype UX ; les deux à quatre dernières semaines sont la politique de substitution, la logique de recalcul de l'inventaire et le package de remise découverte-à-build. Le renforcement prêt pour l'audit de la spécification résultante — cadrage des secrets et de la confidentialité, conception du consentement adapté à la région — doit être budgétisé dans la dernière semaine.
Cas connexes
Plus de projets marketplace & de plateformes mobiles
Écosystème de livraison de courses
Application client, application préparateur, panneau d'administration pour une chaîne d'épicerie régionale — processus logistique conçu de zéro.
Voir le cas →
Malish
Application mobile de marketplace locale pour une chaîne d'articles pour enfants hors ligne — catalogue flexible, synchronisation des stocks en ligne.
Voir le cas →
ZipIt
Marketplace de pièces auto plus CRM vendeur — recherche VIN, inventaire multi-sites.
Voir le cas →Services associés
Développement d'applications mobiles
Applications iOS, Android et multiplateformes natives avec des pipelines de release prêts pour les stores.
En savoir plus →
Développement SaaS
Plateformes SaaS multi-locataires avec SSO, facturation, résidence des données épinglée par région. SOC 2 en cours.
En savoir plus →
Augmentation d'effectifs IT
Ingénieurs seniors intégrés dans votre Jira et vos points quotidiens en deux semaines. Horaire CET avec chevauchement Est-US.
En savoir plus →Planifier un projet similaire
Réserver un appel de découverteDemander une proposition
Partagez quelques détails et un consultant senior vous répondra dans un délai d'un jour ouvré.