Vous avez un projet d’application et on vous a dit qu’il fallait commencer par un cahier des charges. Vous avez aussi vu passer des prototypes cliquables générés par une IA en une après-midi. Alors, par quoi commencer ? Un cahier des charges d’application mobile de 60 pages que personne ne lira en entier, ou un prototype séduisant qui ne dit rien de vos intégrations ni de votre budget ? La réponse honnête est rarement l’un ou l’autre.
Chez Playmoweb, nous cadrons des projets d’applications mobiles, web, IoT et IA depuis plus de 12 ans, à Angers, pour des PME, des ETI et des acteurs publics. Nous avons reçu des cahiers des charges de 80 pages et des idées griffonnées sur une serviette en papier. Cet article explique ce que chaque outil fait bien, ce qu’il fait mal, et la méthode que nous appliquons en 2026 : un document court de 12 questions à trancher, et un prototype.
Sommaire
Il y a trois ans, un prototype cliquable coûtait plusieurs jours de travail d’un designer. Il fallait donc écrire avant de dessiner, et le cahier des charges servait de support unique à la réflexion et au chiffrage.
En 2026, les outils de design assistés par IA produisent un prototype navigable en quelques heures à partir d’une description en langage naturel. Le coût de « montrer » s’est effondré. La conséquence est simple : pour tout ce qui touche à l’expérience utilisateur, il est devenu plus rapide et plus fiable de montrer que de décrire. Le prototype devient le nouveau cahier des charges pour une bonne partie des sujets.
Mais pas pour tout. Un prototype ne montre ni la synchronisation avec votre ERP, ni le comportement hors ligne, ni les obligations réglementaires, ni le budget. Ces sujets se tranchent toujours par écrit. La bonne question n’est donc plus « cahier des charges ou prototype ? », mais « qu’est-ce qui se décrit, et qu’est-ce qui se montre ? ».
Le cahier des charges reste l’outil de référence pour tout ce qui est invisible à l’écran. Le périmètre d’abord : ce qui est dans la version 1, ce qui est repoussé, ce qui est explicitement exclu. C’est la ligne qui protège votre budget.
Les contraintes ensuite : plateformes cibles, versions d’OS, langues, volumes attendus. Les intégrations avec votre système d’information : quel ERP, quel CRM, quelles API existent déjà, qui les maintient. La sécurité et l’authentification : SSO d’entreprise, rôles, chiffrement. Les données et le RGPD : quelles données personnelles, hébergées où, combien de temps. Le réglementaire enfin : accessibilité, santé, produit connecté soumis au Cyber Resilience Act, système d’IA soumis à l’AI Act.
Sur ces sujets, un écrit précis évite les malentendus qui se paient en avenants.
Le cahier des charges décrit mal l’expérience utilisateur. « L’écran d’accueil affiche la liste des interventions du jour avec un filtre par statut » : chaque lecteur imagine un écran différent. Le designer, le développeur, le commercial et l’utilisateur final n’ont pas la même image en tête, et personne ne s’en rend compte avant la première démo.
Il masque aussi les priorités réelles. Dans un document de 200 exigences, toutes semblent avoir la même importance. Or un projet réussi repose sur 3 ou 4 parcours qui doivent être parfaits, et une longue traîne de fonctions qui peuvent attendre. Le cahier des charges classique ne fait pas cette distinction, et le chiffrage qui en découle non plus.
Le prototype aligne tout le monde sur la même image. Mis entre les mains de quelques utilisateurs réels, il révèle en une heure ce qu’un long atelier n’aurait pas fait sortir : les écrans qu’ils cherchent, les boutons qu’ils ne voient pas, les étapes qu’ils sautent. Il force à trancher le parcours clé, celui qui justifie l’existence de l’application.
Il sert aussi de support de décision interne : un comité de direction valide plus facilement un projet qu’il a manipulé sur son téléphone qu’un document de 40 pages. Et il permet de tester le marché avant d’investir, comme nous l’expliquons dans notre article sur comment valider une idée d’application avant de la développer.
Le prototype ne montre pas le backend. Il ne dit pas d’où viennent les données, comment elles sont synchronisées, ce qui se passe quand le réseau tombe dans un atelier ou au milieu d’une exploitation agricole, ni comment l’application s’authentifie auprès de votre annuaire d’entreprise. Un prototype généré par IA a même tendance à masquer ces sujets, car il affiche des données fictives parfaitement propres.
Il ne dit rien non plus du budget, du calendrier, de la maintenance ou du réglementaire. Et il crée une illusion dangereuse : il ressemble tellement à un produit fini que certains décideurs pensent que l’essentiel du travail est fait. En réalité, la majeure partie de l’effort reste devant vous.
Chez Playmoweb, nous ne demandons plus un cahier des charges d’application mobile complet avant de démarrer. Nous demandons deux choses : un document court qui tranche 12 questions, et un prototype du parcours clé. Le document couvre ce qui se décrit, le prototype couvre ce qui se montre.
Les 12 questions à trancher :
Douze questions, une à deux pages de réponses. Ce format tient parce que chaque réponse est une décision, pas une description. Une question sans réponse est une information en soi : elle devient un sujet à instruire pendant le cadrage.
Le prototype complète ce document. Il couvre le parcours clé (question 3) et deux ou trois parcours secondaires. Pas plus. Un prototype de 40 écrans est un cahier des charges déguisé, avec les mêmes défauts.
| Critère | Cahier des charges classique | Prototype seul | Cadrage combiné (12 questions + prototype) |
|---|---|---|---|
| Périmètre et exclusions | Bien couvert | Flou | Tranché par écrit |
| Expérience utilisateur | Mal couverte | Bien couverte | Bien couverte |
| Intégrations SI, données, sécurité | Bien couvert | Absent | Tranché par écrit |
| Priorités réelles | Diluées | Visibles | Explicites |
| Chiffrage fiable | Possible mais long | Impossible | Oui, sur des décisions prises |
| Délai de production | Plusieurs semaines | Quelques heures à quelques jours | Quelques jours à quelques semaines |
| Risque principal | Document figé, contredit à la première démo | Pris pour un produit fini | Exige de trancher tôt |
| Adapté à | Appels d’offres publics, projets très contraints | Validation d’idée, pitch interne | La majorité des projets de PME et d’ETI |
Le cadrage est notre offre d’entrée. Il sert à répondre aux 12 questions, à produire le prototype et à sortir un chiffrage sur lequel nous nous engageons.
Durée. De quelques jours pour un MVP simple à quelques semaines pour une plateforme avec plusieurs intégrations SI. Le facteur qui allonge le plus un cadrage n’est pas la taille de l’application, c’est le nombre de personnes qui doivent trancher.
Déroulement. Un atelier de lancement avec les décideurs et un ou deux utilisateurs finaux pour instruire les 12 questions. Des entretiens courts avec la DSI sur les intégrations, les données et la sécurité. La conception du parcours clé en wireframes, puis en prototype cliquable testé auprès d’utilisateurs réels, selon notre méthode design produit. Une restitution avec le chiffrage.
Livrables. Le document des 12 questions rempli, le prototype cliquable, l’architecture cible (backend, intégrations, hébergement) et un chiffrage par lots avec ses hypothèses explicites. Sur ce chiffrage, nous appliquons systématiquement la logique MVP : une première version à 30 à 50 % du budget de la version complète, puis des itérations. Pour les fourchettes de développement, consultez notre guide du coût d’une application mobile en 2026.
Coût. À titre d’ordre de grandeur, un cadrage représente quelques milliers d’euros pour un projet simple et peut atteindre 10 à 15 k€ pour une plateforme complexe avec plusieurs intégrations, soit une fraction modeste d’un budget de développement qui va de 25 k€ à 200 k€ et plus selon la complexité. Le cadrage n’engage pas à développer avec nous : ses livrables restent votre propriété et peuvent servir à consulter d’autres prestataires. Sur ce choix, lisez agence, freelance ou grand cabinet : qui choisir pour développer votre application.
Le cahier des charges de 80 pages figé. Il a coûté trois mois à produire et il est contredit dès la première démo. Pire, il devient une pièce contractuelle : chaque écart se négocie en avenant. Un document long protège rarement le client, il alimente surtout les litiges.
Le prototype pris pour un produit fini. Le comité de direction a vu un prototype fluide, le budget annoncé lui paraît donc excessif. Rappelez à chaque étape ce que le prototype ne contient pas : backend, intégrations, sécurité, tests, mise en production, conformité. C’est là que se trouve l’essentiel de l’effort.
Oublier le backend et les intégrations. C’est le piège le plus coûteux que nous rencontrons. L’application est belle, mais les données doivent venir d’un ERP dont l’API n’existe pas, ou d’un fichier Excel mis à jour à la main. Le backend et les connecteurs pèsent lourd dans le budget et restent invisibles sur un écran. Instruisez la question 5 avant tout chiffrage.
Pas de critère de succès. Sans indicateur défini au départ, le projet est jugé sur des impressions. Et sans objectif mesurable, impossible de trancher les priorités : tout devient important. La question 12 est celle qu’on saute le plus souvent, et celle qui manque le plus après le lancement.
Confondre cadrage et spécification exhaustive. Un cadrage tranche les décisions structurantes et laisse le détail de chaque écran aux itérations. Tout figer avant de coder ramène aux défauts du cahier des charges classique.
Avant de contacter une agence ou de lancer un développement, vérifiez que vous savez répondre à ces questions :
Si vous avez cinq réponses sur six, vous êtes prêt à consulter. Si vous en avez moins de trois, un cadrage de quelques jours vous fera gagner des mois.
Vous préparez un projet d’application ? Contactez-nous pour un échange gratuit et sans engagement : nous vous dirons ce qui se décrit, ce qui se montre, et par où commencer. 👉 playmoweb.com/nous-contacter