Aller au contenu
Agence Application Mobile
06 32 64 24 80 Parler de mon projet
Demander un avis 06 32 64 24 80
Expertise CDC

Cahier des charges et devis : application Gmail

Par Lucas Kacem De Vincenzi · mise à jour le 21 août 2026


Ce modèle sert à cadrer une application du type Gmail 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.

Cahier des charges et fourchette de devis pour une application du type Gmail (productivité).

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 Gmail ». 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 Gmail. Le besoin qui fait ouvrir Gmail : un rendez-vous, une commande, une alerte, une habitude. Écrivez-le en une phrase dans le CDC. Si vous ne savez pas, le projet n’est pas mûr.

  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 Gmail. Le geste quotidien de Gmail (réserver, acheter, envoyer, tracker). Il doit tenir en peu de taps. Tout ce qui est compte, KYC, carte, vient après ou autour, pas devant sans raison.

  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 Gmail. Ce que la personne obtient, et ce qu’elle ne contrôle pas tout à fait : un créneau, un match, un résultat, une livraison à l’heure. Nommez la variabilité. Un écran « succès » figé n’en est pas une.

  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 Gmail. Ce qu’on laisse dans l’app et qui fera revenir : fiche, favoris, historique, paiement, contenus créés. C’est souvent le back-office, pas le pixel.

Le lien, en une phrase. Pour Gmail, reliez les écrans dans cet ordre : qu’est-ce qui fait ouvrir, quel geste, quelle surprise, qu’est-ce qu’on laisse. Un écran qui ne porte aucun de ces quatre temps est probablement de la décoration. On le coupe de la V1.

Tranchez : que peut-on faire sans compte ? L’action d’abord, l’investissement ensuite, est le schéma le plus lisible (voir le signup Deliveroo sur UIguana).

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.

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.

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 Gmail, sur quel territoire, avec quel volume au lancement. Pour Gmail, é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 : mail

Pour une application du type Gmail, le module « mail » 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 « mail » 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, « mail » se décompose : conception de l’écran, design, développement client, API, tests, éventuelle file d’attente. Un forfait unique « mail » dans un devis est illisible. Demandez l’éclatement. La fourchette d’ensemble pour une application du type Gmail reste 120 000 à 300 000 € HT, palier le plus fréquent pour ce type d’app, pas le tarif de ce module isolé.

Module : labels

Pour une application du type Gmail, le module « labels » 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 « labels » 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, « labels » se décompose : conception de l’écran, design, développement client, API, tests, éventuelle file d’attente. Un forfait unique « labels » dans un devis est illisible. Demandez l’éclatement. La fourchette d’ensemble pour une application du type Gmail reste 120 000 à 300 000 € HT, palier le plus fréquent pour ce type d’app, pas le tarif de ce module isolé.

Module : recherche

Pour une application du type Gmail, le module « recherche » 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 « recherche » 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, « recherche » se décompose : conception de l’écran, design, développement client, API, tests, éventuelle file d’attente. Un forfait unique « recherche » dans un devis est illisible. Demandez l’éclatement. La fourchette d’ensemble pour une application du type Gmail 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 Gmail, 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 Gmail ?

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 Gmail

Avant d’écrire à une agence au sujet de une application du type Gmail, 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 Gmail, n’inventez pas un cinquième document : remplissez celui-là.

Pièges, toujours les mêmes, aussi pour une application du type Gmail : 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

Avis technique gratuit

Faites relire ce périmètre

30 minutes : on vous dit ce qui manque dans le CDC, le palier de prix, et si le clone de l’app analogique est un piège. Sans engagement.

Ou par téléphone 06 32 64 24 80

Sans engagement. Pas de démarchage, pas de liste de diffusion.