Cahier des charges et devis : application Deliveroo

Ce modèle sert à cadrer une application du type Deliveroo avant de demander un devis. Il reprend la structure du cahier des charges et les fourchettes du guide des prix : 120 000 à 300 000 € HT, hors TVA, pour un périmètre de complexité élevée. Modèle générique de cahier des charges, prix.

Lien entre les écrans

Pourquoi ces pages s’enchaînent : la boucle Hooked

Une app qui devient une habitude n’est pas une galerie d’écrans. C’est une boucle de quatre temps, décrite par Nir Eyal dans Hooked (2014). Chaque écran en prépare un autre. C’est ça qu’il faut écrire dans le CDC, pas « faire comme Deliveroo ». Présentation de l’auteur.

1. Temps 1 · Déclencheur

   Ce qui fait ouvrir l’app. Externe : une notification, une pub, la faim, un SMS. Interne : l’ennui, la peur de rater, l’habitude de « checker ». Sans déclencheur écrit, l’écran d’accueil n’est qu’une affiche.

   Chez Deliveroo. Interne : la faim, la paresse, « on a déjà commandé ici ». Externe : push « tes restos », SMS de suivi, créneau Plus. La promesse store (restos ET courses) est déjà un choix de déclencheur : une ou deux faims.

2. Temps 2 · Action

   Le geste le plus simple en attendant la récompense : un swipe, une recherche, le bouton Continuer d’une leçon, un créneau cliqué. Si ce geste demande un compte, un KYC et une carte bancaire, ce n’est plus une action : c’est un mur.

   Chez Deliveroo. Ouvrir, chercher, ajouter, payer. UIguana le montre : on voit le catalogue AVANT le login. L’action précède l’investissement. Forcer le compte à l’ouverture casse ce que Deliveroo a lissé.

3. Temps 3 · Récompense variable

   On ne sait pas exactement ce qu’on va obtenir. Un match ou rien. Un plat réussi ou tiède. Une leçon facile ou un cœur perdu. C’est la variabilité qui fait revenir, pas le dégradé.

   Chez Deliveroo. ETA, qualité du plat, promo qui passe ou pas, coursier en avance ou en retard. Le suivi live est la récompense qu’on attend après le paiement. Côté coursier : le tarif avant acceptation, le ledger.

4. Temps 4 · Investissement

   L’utilisateur laisse quelque chose qui charge le prochain déclencheur : favoris, carte tokenisée, streak, photos de profil, adresse « maison ». Cet écran a l’air secondaire. C’est lui qui transforme une visite en habitude.

   Chez Deliveroo. Adresse, carte, favoris, Plus, historique. Côté coursier : documents KYC, véhicule, heatmap (où se placer). Plus change le prochain déclencheur : « c’est gratuit de se faire livrer ». Sans resto (tablette), rien de tout ça n’a de source.

Le lien, en une phrase. La recherche (2) rend vraie la promesse (1). Les offres (3) sont la récompense variable. Les courses (4) sont un autre métier. Le suivi (5) est la récompense après paiement. Plus (6) est l’investissement. Rider (7-10) est l’autre boucle, sans laquelle le pin du suivi est un mensonge.

Catalogue et code « premier panier » visibles sans compte. Login (Apple, Google, Facebook, e-mail) quand on veut les favoris et les remises. C’est le flux public UIguana signup-login.

L’investissement recharge le déclencheur du lendemain (favori, série, carte, notif). Si vous ne savez pas quel investissement V1 vous demandez, vous construisez une visite, pas une app. C’est ça qu’une agence chiffre, pas le rayon des coins.

Les écrans côté client, fonction par fonction

Fiche App Store « Deliveroo : Faites-vous livrer », store France. Ce sont des visuels marketing autour d’un vrai écran. On lit l’écran (champs, états, règles), pas le burger. Chaque vue dit quel temps Hooked elle porte, et pourquoi la suivante existe.

Écran 01 · client · Déclencheur

Promesse store : restos et courses, deux catalogues

Ce qu’on voit. Visuel marketing, pas un écran de prod : burger, poke, sushis. Le texte fige deux verticales (« Restos et courses livrés chez vous »).

Ce que le CDC doit figer. Tranchez V1 : restauration seule, ou restauration + courses. Le modèle de stock n’est pas le même (menu du jour vs SKU rayon, substitutions, rupture). Si les deux sont « inclus », le devis double le back-office marchand.

Lien vers l’écran suivant. Les deux catalogues promis doivent pouvoir se chercher (écran 2). Sinon cette affiche est un mensonge de périmètre.

Qui

Client grand public, première ouverture.

Données

Aucune encore. Dès l’écran suivant : adresse, GPS.

Hors V1

Dark stores, alcool, pharmacie : hors V1 sauf exigence écrite.

Écran 02 · client · Action

Recherche : trois onglets, taxonomie, catégories

Ce qu’on voit. Écran Rechercher, onglets Tout / Restaurants / Commerces, grille « Parcourir par catégorie » (Pizza, bowls). Champ, retour, fermeture.

Ce que le CDC doit figer. Index de recherche (nom, plat, catégorie), facettes, géolocalisation pour le « près de moi ». Deux inventaires (resto vs commerce) dès cet écran. État vide, faute de frappe, zéro résultat dans la zone.

Lien vers l’écran suivant. Sans offres (écran 3), la recherche est un annuaire. Les facettes et l’ETA préparent la récompense variable.

Qui

Client qui sait déjà ce qu’il veut, ou qui explore.

Données

Requête, historique de recherche, position.

Hors V1

Recherche vocale, scan de ticket : Won’t V1.

Écran 03 · client · Récompense variable

Offres : seuil de panier, remise, ETA, favoris

Ce qu’on voit. Liste Offres : « Commandez pour 20 € / Profitez de 50 % », ETA 20-30 min, cœur favori, filtre.

Ce que le CDC doit figer. Moteur promo : éligibilité (montant min, zone, créneau), cumul, affichage du reste à payer. L’ETA n’est pas un texte : c’est un calcul dispatch ( dist resto-client, charge coursiers). Favoris = compte + sync.

Lien vers l’écran suivant. Le cœur favori est déjà un investissement. L’écran 4 (courses) n’est pas un habillage de cet écran : c’est un autre stock.

Qui

Client chasseur de promo.

Données

Paniers, codes, restaurant_id, heart list.

Hors V1

Cashback multi-enseignes, coupons influenceurs : hors V1.

Écran 04 · client · Déclencheur

Courses à domicile : autre métier que le resto

Ce qu’on voit. Sac courses Deliveroo, slogan « Faites-vous livrer vos courses à la maison ». Pas d’UI de rayon, mais la verticale est posée.

Ce que le CDC doit figer. Si V1 courses : catalogue SKU, poids, substitutions, rupture, créneau, éventuellement froid. Le marchand n’édite pas un menu : il édite un stock. Back-office distinct du restaurant.

Lien vers l’écran suivant. Autre déclencheur (faim de courses, pas de resto). Le suivi (écran 5) est commun : une commande, un pin, quel que soit le stock.

Qui

Client courses, pas le même panier moyen ni la même fréquence.

Données

SKU, lots, éventuellement CB + age-gate alcool.

Hors V1

Drive piéton, click-and-collect magasin : Won’t sauf brief.

Écran 05 · client · Récompense variable

Suivi live : fenêtre d’ETA, carte, aide

Ce qu’on voit. Carte, pin coursier et pin client, barre de progression, « 19:50-20:05 », statut « en cours de livraison », bouton Aide, fermer.

Ce que le CDC doit figer. Machine d’états (acceptée, en préparation, en route, livrée, échec). Position temps réel, recalcul d’ETA, file d’aide (chat ou téléphone). Permissions GPS côté coursier. Hors-ligne, retard, adresse introuvable : écrans d’erreur, pas un toast.

Lien vers l’écran suivant. Récompense qu’on attend après le paiement : l’ETA bouge. Plus (écran 6) change cette récompense (livraison offerte) et recharge le déclencheur.

Qui

Client après paiement. Coursier en parallèle (autre app).

Données

Trajet, timestamps, éventuellement photo de dépôt.

Hors V1

Appel vocal in-app, partage de trajet familial : option, pas V1 par défaut.

Écran 06 · client · Investissement

Deliveroo Plus : abonnement, livraison offerte

Ce qu’on voit. Paywall violet : réductions, livraison offerte, « sans engagement ».

Ce que le CDC doit figer. Abonnement : prix TTC, période, résiliation, droits (frais de livraison à 0 sous conditions). Facturation : Store (IAP Apple/Google) ou PSP web. Les stores prennent 15-30 % si IAP. Écrivez le canal. Essai, grâce, échec de prélèvement.

Lien vers l’écran suivant. On paie pour que le prochain déclencheur soit plus doux. Sans les écrans coursier (7 à 10), le pin de l’écran 5 n’a pas d’émetteur.

Qui

Client récurrent.

Données

Statut d’abonnement, moyen de paiement tokenisé.

Hors V1

Plusieurs paliers Plus / Pro : un seul palier en V1.

Écrans coursier (app Rider)

Seconde fiche store : Deliveroo Rider. Bundle distinct. Sans ces écrans, le suivi live client est un mensonge : personne n’envoie la position.

Écran 07 · coursier · Action

Carte coursier : zone, disponibilité, véhicule

Ce qu’on voit. App Rider : carte, polygone de zone, point bleu (moi), menu. Promesse store : vélo, scooter, voiture selon pays.

Ce que le CDC doit figer. Seconde application (bundle distinct). Toggle en ligne / hors ligne, géorepérage, type de véhicule, documents (pièce, assurance, KBIS si auto-entrepreneur). Sans cette app, le suivi client de l’écran 5 n’a pas de source.

Lien vers l’écran suivant. Se mettre en ligne n’a de sens que si le tarif apparaît avant d’accepter (écran 8). Sinon l’action est un saut dans le vide.

Qui

Coursier. Compte KYC, pas un user grand public.

Données

Position haute fréquence, statut, véhicule.

Hors V1

Voiture : pas tous les pays, le store le dit. Le CDC aussi.

Écran 08 · coursier · Récompense variable

Revenus : ledger par course, tarif avant acceptation

Ce qu’on voit. Écran Revenus : 207,24 €, 37 commandes, lignes Sushi Bar 4,86 €, Carrefour 6,17 €. Le store précise : voir destination et tarif avant d’accepter, selon pays.

Ce que le CDC doit figer. Règle de rémunération écrite (fixe + distance + surge). Afficher le tarif AVANT acceptation est une exigence métier, pas un détail UI. Historique, export, contestation d’une course. Comptabilité auto-entrepreneur.

Lien vers l’écran suivant. Le ledger est la récompense variable (4,86 € vs 6,17 €). La heatmap (écran 9) est l’investissement qui vise un meilleur tirage.

Qui

Coursier qui décide de prendre ou non.

Données

Montants, pourboires, frais, identifiant de course.

Hors V1

Pourboire in-app client : module à part, dit oui ou non en V1.

Écran 09 · coursier · Investissement

Carte de demande : hexagones, créneaux de pointe

Ce qu’on voit. Heatmap « Très forte demande » jusqu’à 19:45, 20:00, 20:30, 21:00. Grille hexagonale sur la zone.

Ce que le CDC doit figer. Incitations : bonus de zone, multiplicateur, quota. Données de demande agrégées (pas la position des clients). Expiration du créneau. Un clone V1 peut s’en passer : bonus manuel. Un clone « comme Deliveroo » ne le peut pas.

Lien vers l’écran suivant. Se placer, c’est investir du temps. Ça ne sert que si le virement (écran 10) arrive. Un clone V1 peut remplacer la heatmap par un bonus horaire saisi à la main.

Qui

Coursier qui choisit où se placer.

Données

Agrégats de commandes ouvertes, jamais le détail client.

Hors V1

IA prédictive 24 h : Won’t V1. Un bonus horaire saisi par l’ops suffit à tester.

Écran 10 · coursier · Investissement

Paiement coursier : virement, délai, historique

Ce qu’on voit. « Paiement envoyé ! » sous un jour ouvré, lien vers l’historique. Cadence hebdo ou bihebdo selon le pays.

Ce que le CDC doit figer. Wallet ou virement (IBAN), KYC, calendrier, échec de virement, seuil mini. PSP (Stripe Connect ou équivalent). Mentions légales travailleur indépendant / salarié selon le droit français : le CDC ne triche pas sur le statut.

Lien vers l’écran suivant. IBAN, KYC, calendrier. C’est l’investissement qui recharge le déclencheur coursier (« je me mets en ligne demain »). Sans ça, les hexagones sont du décor.

Qui

Coursier, admin finance.

Données

IBAN, pièces KYC, mandats.

Hors V1

Avance sur salaire, carte de paiement instantanée : option.

S’inscrire : cinq écrans, dans l’ordre

Deliveroo laisse chercher avant de demander un compte. Voici le parcours d’inscription, lu dans l’ordre. Le flux complet est aussi sur UIguana.

On parcourt le catalogue (action). On crée un compte quand on veut une remise ou des favoris (investissement). Cet investissement recharge le déclencheur du lendemain : « tes restos », le code, Plus.

Étape 1. Home : « Selected location », recherche, onglets Restaurants / Groceries, code £12 first order, Morrison’s Daily. On parcourt déjà. Lien. L’action précède l’investissement. Un clone qui met le login en écran 1 casse ce que ce flux a lissé.

Étape 2. « Let’s get you logged in. » Apple, Google, Facebook, e-mail. T&Cs et Privacy en bas. Croix pour fermer. Lien. Le texte avoue le deal : favoris + remises contre un compte. SSO = prestataires, DPA, échec d’un provider. La croix : on peut encore rester guest.

Étape 3. « Sign up or log in with email », champ, Continue inactif visuellement tant que c’est vide, clavier iOS. Lien. État vide, validation, clavier qui mange la CTA. Accessibilité : label, erreur, autocomplete email.

Étape 4. Adresse remplie, croix de purge du champ, bouton Continue teinté. Lien. Le bouton ne s’allume que si le format tient. CDC : règles de validation, message d’erreur, pas un toast muet.

Étape 5. Même e-mail, bouton remplacé par un spinner. Plus de clavier. Lien. État de chargement, timeout, « e-mail déjà pris » vs « compte créé ». C’est ici que la session (cookie, token) naît, et que le prochain déclencheur (favoris, push) devient possible.

Les trois faces, une seule commande

Une commande client déclenche : ticket resto (temps de préparation, rupture), offre coursier (tarif, trajet), puis suivi. Copier uniquement l’app client, c’est livrer une vitrine. Le dispatch est le produit.

Face	App / canal	Sans ça, ça casse
Client	com.deliveroo.orderapp	Recherche, panier, paiement, suivi, éventuellement Plus.
Coursier	com.deliveroo.riderapp	Disponibilité, acceptation, GPS, ledger, virement.
Restaurant	Tablette / web (pas de capture store ici)	Ack commande, temps de prep, rupture, impression ticket.

Ressources officielles pour ce type de projet

Les captures de cette page suffisent à poser le CDC. Pour aller au fond des règles de conception et de publication, ces références font foi.

• Human Interface Guidelines (Apple). Les règles de conception iOS que la validation App Store applique réellement.
• Android Developers, section Design. Composants, navigation et qualité attendus côté Google Play.
• Documentation Firebase. Authentification, notifications, données temps réel : les briques standard d’un back-end mobile.
• Application mobile (Wikipédia). Le panorama de référence : natif, hybride, web, histoire et enjeux.

Cahier des charges : les quatre blocs

Un CDC lisible sépare contexte, périmètre, contraintes et recette. Sans critère d’acceptation, ce n’est pas un CDC.

1. Contexte

Qui utilise une application du type Deliveroo, sur quel territoire, avec quel volume au lancement. Pour Deliveroo, écrivez les personas (côté client et côté opération), le canal d’acquisition et ce qui existe déjà (Excel, WhatsApp, un outil du marché).

2. Périmètre fonctionnel

Modules à trancher un par un. Ce qui n’est pas listé n’est pas inclus. Chaque module ci-dessous est une exigence, un écran (ou un lot d’écrans), un bout de back-office et un critère d’acceptation. On nomme le système, on ne recopie pas l’interface.

Module : trois faces

Pour une application du type Deliveroo, le module « trois faces » n’est pas une ligne de devis magique. Dans le CDC, écrivez : qui s’en sert (rôle), depuis quel écran on y entre, quelle donnée est lue ou écrite, quel état vide, quel état d’erreur, qui l’administre. Si « trois faces » implique un prestataire (paiement, SMS, carte, vidéo), nommez-le ou exigez un choix argumenté. Hors périmètre : dites ce que ce module ne fera pas en V1, sinon il s’étendra tout seul au moment de la recette.

Côté chiffrage, « trois faces » se décompose : conception de l’écran, design, développement client, API, tests, éventuelle file d’attente. Un forfait unique « trois faces » dans un devis est illisible. Demandez l’éclatement. La fourchette d’ensemble pour une application du type Deliveroo reste 120 000 à 300 000 € HT, palier le plus fréquent pour ce type d’app, pas le tarif de ce module isolé.

Module : commandes

Pour une application du type Deliveroo, le module « commandes » n’est pas une ligne de devis magique. Dans le CDC, écrivez : qui s’en sert (rôle), depuis quel écran on y entre, quelle donnée est lue ou écrite, quel état vide, quel état d’erreur, qui l’administre. Si « commandes » implique un prestataire (paiement, SMS, carte, vidéo), nommez-le ou exigez un choix argumenté. Hors périmètre : dites ce que ce module ne fera pas en V1, sinon il s’étendra tout seul au moment de la recette.

Côté chiffrage, « commandes » se décompose : conception de l’écran, design, développement client, API, tests, éventuelle file d’attente. Un forfait unique « commandes » dans un devis est illisible. Demandez l’éclatement. La fourchette d’ensemble pour une application du type Deliveroo reste 120 000 à 300 000 € HT, palier le plus fréquent pour ce type d’app, pas le tarif de ce module isolé.

Module : paiement

Pour une application du type Deliveroo, le module « paiement » n’est pas une ligne de devis magique. Dans le CDC, écrivez : qui s’en sert (rôle), depuis quel écran on y entre, quelle donnée est lue ou écrite, quel état vide, quel état d’erreur, qui l’administre. Si « paiement » implique un prestataire (paiement, SMS, carte, vidéo), nommez-le ou exigez un choix argumenté. Hors périmètre : dites ce que ce module ne fera pas en V1, sinon il s’étendra tout seul au moment de la recette.

Côté chiffrage, « paiement » se décompose : conception de l’écran, design, développement client, API, tests, éventuelle file d’attente. Un forfait unique « paiement » dans un devis est illisible. Demandez l’éclatement. La fourchette d’ensemble pour une application du type Deliveroo reste 120 000 à 300 000 € HT, palier le plus fréquent pour ce type d’app, pas le tarif de ce module isolé.

Module : suivi GPS

Pour une application du type Deliveroo, le module « suivi GPS » n’est pas une ligne de devis magique. Dans le CDC, écrivez : qui s’en sert (rôle), depuis quel écran on y entre, quelle donnée est lue ou écrite, quel état vide, quel état d’erreur, qui l’administre. Si « suivi GPS » implique un prestataire (paiement, SMS, carte, vidéo), nommez-le ou exigez un choix argumenté. Hors périmètre : dites ce que ce module ne fera pas en V1, sinon il s’étendra tout seul au moment de la recette.

Côté chiffrage, « suivi GPS » se décompose : conception de l’écran, design, développement client, API, tests, éventuelle file d’attente. Un forfait unique « suivi GPS » dans un devis est illisible. Demandez l’éclatement. La fourchette d’ensemble pour une application du type Deliveroo reste 120 000 à 300 000 € HT, palier le plus fréquent pour ce type d’app, pas le tarif de ce module isolé.

Module : restaurants

Pour une application du type Deliveroo, le module « restaurants » n’est pas une ligne de devis magique. Dans le CDC, écrivez : qui s’en sert (rôle), depuis quel écran on y entre, quelle donnée est lue ou écrite, quel état vide, quel état d’erreur, qui l’administre. Si « restaurants » implique un prestataire (paiement, SMS, carte, vidéo), nommez-le ou exigez un choix argumenté. Hors périmètre : dites ce que ce module ne fera pas en V1, sinon il s’étendra tout seul au moment de la recette.

Côté chiffrage, « restaurants » se décompose : conception de l’écran, design, développement client, API, tests, éventuelle file d’attente. Un forfait unique « restaurants » dans un devis est illisible. Demandez l’éclatement. La fourchette d’ensemble pour une application du type Deliveroo reste 120 000 à 300 000 € HT, palier le plus fréquent pour ce type d’app, pas le tarif de ce module isolé.

3. Contraintes

Stores (iOS, Android ou les deux), langues, pays, RGPD, hébergement UE, accessibilité (EAA depuis juin 2025), comptes développeur, environnements. Si c’est flou ici, ça devient un avenant.

4. Recette

Jeux de tests, délai de retour, nombre d’allers-retours inclus, recette stores. « Jusqu’à satisfaction » n’est pas un critère.

Lire un devis pour ce type d’application

Les fourchettes nationales restent celles du guide : MVP 15 000 à 40 000 € HT, application d’ambition moyenne 40 000 à 120 000 €, projet complexe 120 000 à 300 000 €. Pour une application du type Deliveroo, le palier le plus fréquent est 120 000 à 300 000 € HT. Détail poste par poste sur le guide des prix et la grille de lecture des devis.

Un devis lisible sépare conception, design, développement iOS/Android, backend, tests, publication stores et forfait de suivi. Si ces postes sont fusionnés, on ne compare rien. Acompte usuel : 30 à 40 % à la commande. TVA 20 % en sus.

Stores, données personnelles, planning

App Store et Google Play : compte développeur (99 USD/an côté Apple, 25 USD une fois côté Google), fiche, captures, politique de confidentialité, âge, pays. Les commissions 15 % ou 30 % taxent le chiffre d’affaires après publication, pas le budget de fabrication.

RGPD : finalités, base légale, durée de conservation, sous-traitants (hébergement, paiement, analytics, push). À écrire avant le devis. Depuis juin 2025, l’EAA pèse sur beaucoup d’applications grand public : une ligne « l’app sera accessible » ne suffit pas.

Un calendrier réaliste pour un MVP se compte en mois, pas en semaines, dès qu’il y a deux stores, un back-office et un paiement. Le devis doit dater les jalons (maquettes, recette interne, soumission stores).

Pièges fréquents

• Copier les écrans d’une app connue sans écrire les règles métier (modération, litiges, KYC, commissions).
• Oublier le back-office : la plupart des coûts se cachent là, pas dans l’écran « swipe ».
• Sous-estimer notifications, paiements, temps réel et recettes stores.
• Ignorer la maintenance : 15 à 20 % du budget de fabrication par an, déjà posé dans le guide prix.

Questions fréquentes

Combien coûte une application du type Deliveroo ?

Fourchette la plus fréquente pour ce périmètre : 120 000 à 300 000 € HT, hors TVA, France. Le chiffre exact dépend des modules retenus, pas du nom de l’app copiée.

Faut-il du natif ou du multiplateforme ?

Le CDC tranche. Native iOS + Android double une partie du développement. Flutter ou React Native réduit ce double emploi, au prix de contraintes stores et de perf. Aucune stack n’est « gratuite ». Écrivez le choix, ou demandez deux chiffrages.

Peut-on partir d’un white-label ?

Parfois, pour un MVP. Le CDC doit alors lister ce que le white-label ne fait pas. Les applications type marketplace, rencontre ou VTC sortent vite du cadre d’un thème prêt à l’emploi.

Par où commencer le CDC pour ce type d’app ?

Par les parcours, pas par les couleurs. Ouvrez, inscrivez, faites la première action qui justifie l’app (une course, un swipe, une leçon, une réservation). Chaque écran de ce parcours a une règle, un état vide, un état d’erreur. C’est ça que l’agence chiffre. Le modèle Word de ce guide a déjà les 12 cases. Remplissez-les avec ces parcours, pas avec « faire comme l’app connue ».

Combien de temps pour un MVP ?

En mois, pas en semaines, dès qu’il y a deux stores, un back-office et un paiement. Un devis qui promet six semaines pour ce périmètre a oublié la recette stores, les comptes développeur, ou les deux. Demandez les jalons datés : maquettes, recette interne, soumission, revue Apple/Google.

Qui détient le code et les comptes ?

Vous. Le CDC le dit : cession du code, dépôt Git remis, comptes stores à votre nom (ou transfert documenté). Une agence qui garde les accès « pour la maintenance » garde le levier. La maintenance se contractualise, elle ne s’accapare pas.

Faut-il iOS et Android dès la V1 ?

Le CDC tranche, avec un chiffre : part de vos utilisateurs sur chaque store. Un seul store en V1 coupe une partie du budget et du calendrier. Flutter ou React Native réduit le double emploi, au prix de contraintes. Écrivez le choix, ou demandez deux chiffrages.

Que faire des captures de la fiche store ?

Lire le flux, écrire l’exigence. Les images de cette page listent des systèmes (carte, matching, vies, prompts) que le Word doit nommer, reliés par la boucle Hooked. Ce n’est pas une maquette à recopier.

Pour un avis technique sur ce périmètre : prendre rendez-vous. Les classements d’agences restent sur les pages ville.

Atelier de cadrage pour une application du type Deliveroo

Avant d’écrire à une agence au sujet de une application du type Deliveroo, tenez l’atelier suivant. Seul, avec un associé, ou avec nous en 30 minutes. L’objectif n’est pas un roman. C’est douze réponses assez nettes pour que deux devis portent sur le même objet.

1. Phrase de vision. « Notre application permet à [cible] de [bénéfice] sans [friction] ». Si elle coince, le projet n’est pas mûr.
2. Trois à cinq objectifs chiffrés, et les non-objectifs. Ce que la V1 ne cherchera pas à faire.
3. Personas : deux à quatre. Désignez le prioritaire. Téléphone, fréquence, situation d’usage.
4. Must / Should / Could / Won’t. Le MVP, c’est la colonne Must. Rien d’autre.
5. Trois à cinq parcours, écran par écran, y compris hors réseau, sans compte, panier vide.
6. Contraintes : stores, langues, pays, hébergement UE, RGPD, EAA, comptes développeur.
7. Back-office : qui administre utilisateurs, contenus, commandes, exports. Souvent 30 à 40 % du budget.
8. Recette : jeux de tests, délai de retour, nombre d’allers-retours, recette stores.
9. Fourchette de budget, affichée. MVP 15 000 à 40 000 € HT, moyenne 40 000 à 120 000 €, complexe 120 000 à 300 000 €.
10. Maintenance : 15 à 20 % par an comme ordre de grandeur, à faire chiffrer à part.

Le détail, avec les captures d’écrans réels, est dans le cahier des charges. La lecture des réponses est dans le guide des devis. Les paliers sont dans le guide des prix. Pour une application du type Deliveroo, n’inventez pas un cinquième document : remplissez celui-là.

Pièges, toujours les mêmes, aussi pour une application du type Deliveroo : tout mettre en Must ; spécifier le bouton au lieu du besoin ; oublier le back-office ; taire le budget ; figer le Word comme un contrat alors que les bonnes agences le challengent. Celle qui n’a aucune question n’a pas lu. Celle qui a trop de questions hors cadre n’a pas le même projet que vous.

Autres modèles proches

• Cahier des charges et devis : application Uber Eats