DreamOracle : comment nous avons mené un produit grand public de zéro à la mise en ligne
DreamOracle est une plateforme d'interprétation de rêves que nous avons construite de bout en bout pour Distr'Action : conception, identité visuelle…
Par Laurent Maréchal · · 6 min de lecture
Il y a une différence fondamentale entre livrer un outil interne à une entreprise et lancer un produit grand public. Dans le premier cas, les utilisateurs sont captifs, ils n'ont pas le choix. Dans le second, ils peuvent partir en trois secondes. C'est exactement ce que ce projet nous a forcés à intégrer à chaque étape. DreamOracle est une plateforme d'interprétation de rêves avec journal personnel, installable directement sur téléphone, développée pour Distr'Action, studio spécialisé en production audio et création de contenus. Voici comment ça s'est construit, ce qui a coincé, et ce que vous pouvez en tirer si vous portez un projet similaire.
Le point de départ : une idée claire, une exécution à inventer
Le brief était précis dans son intention : créer une plateforme grand public autour de l'interprétation des rêves, avec un journal personnel intégré et une expérience mobile fluide. Pas un prototype, pas un MVP bancal. Un produit fini, utilisable, distribuable. Ce type de commande ressemble à du développement classique. Ce n'en est pas. Dès les premières discussions, il est apparu que le code n'était qu'une partie du problème. Il fallait aussi décider comment le produit allait se présenter, comment il allait se comporter sur un écran de téléphone sans passer par un store, et comment il allait trouver ses premiers utilisateurs. Trois sujets que beaucoup de projets repoussent à plus tard, et qui finissent par tuer le lancement.
Ce que nous avons construit techniquement
La stack choisie repose sur Next.js côté front et Prisma sur PostgreSQL côté données. Ce choix n'est pas anodin : Next.js permet de gérer à la fois le rendu côté serveur et les pages statiques, ce qui compte pour la performance perçue sur mobile. Prisma simplifie la gestion du schéma de base de données et les migrations, ce qui évite les erreurs silencieuses quand le modèle évolue.
Le point technique le plus structurant du projet est l'application web progressive, installable sur iOS et Android sans passer par l'App Store ni le Play Store. Concrètement, l'utilisateur visite le site, son navigateur lui propose d'installer l'application sur son écran d'accueil, et il se retrouve avec une icône et une expérience plein écran. Ce n'est pas une application native, mais pour la majorité des usages, la différence est imperceptible. Et le gain en distribution est considérable : pas de validation de store, pas de délai, pas de commission.
Nous avons aussi développé un générateur de visuels intégré, qui produit des images liées aux rêves interprétés. C'est ce type de détail qui transforme un outil fonctionnel en produit qu'on a envie de partager.
L'identité visuelle : ce qu'on sous-estime toujours
Un produit grand public sans identité visuelle cohérente, c'est un produit qui ne convainc pas avant même d'être essayé. Nous avons livré une suite complète en SVG : logo, icônes, palette, typographie, éléments d'interface. Tout en vectoriel, pour que chaque format soit couvert sans perte de qualité, du favicon à l'écran de chargement de l'application installée.
Ce travail prend du temps. Il demande des allers-retours. Et il est souvent sacrifié dans les projets qui manquent de budget ou de calendrier. Le résultat, dans ces cas-là, c'est un produit qui fonctionne mais qui ne rassure pas l'utilisateur. Sur un marché grand public, la confiance se joue aussi visuellement, surtout au premier contact.
L'acquisition : la partie qu'on remet toujours à demain
C'est le sujet que presque tous les projets sous-estiment. On pense que si le produit est bon, les gens vont venir. Ce n'est pas comme ça que ça fonctionne. Nous avons intégré la réflexion sur l'acquisition dès la phase de conception, pas en bout de chaîne. Cela a influencé des choix techniques — la structure des URLs, les balises méta, la vitesse de chargement — et des choix de design — les écrans d'onboarding, les points de partage naturels dans le parcours.
La campagne d'acquisition a été construite en parallèle du développement, pas après. C'est une contrainte organisationnelle, mais elle évite de se retrouver avec un produit prêt et aucun plan pour le faire connaître. Si vous portez un projet similaire et que vous cherchez à comprendre comment structurer cette chaîne, notre page réalisations donne une vue d'ensemble des projets que nous avons menés de bout en bout.
Ce qui a coincé et ce que ça nous a appris
Le principal point de friction a été la gestion des contraintes propres aux PWA sur iOS. Apple impose des limitations sur certaines fonctionnalités des applications web progressives — notifications push, accès à certains capteurs, comportement du cache — qui n'existent pas sur Android. Nous avons dû adapter plusieurs choix de conception pour garantir une expérience cohérente sur les deux systèmes, sans promettre des fonctionnalités qui auraient été dégradées sur une partie des appareils.
L'autre apprentissage concerne le générateur de visuels. Intégrer de la génération d'images dans un flux utilisateur demande de gérer des temps de réponse variables et des cas d'erreur visibles. Nous avons travaillé les états de chargement et les messages d'erreur avec autant de soin que les écrans principaux. Ce n'est pas spectaculaire, mais c'est ce qui fait la différence entre un produit qui frustre et un produit qu'on utilise à nouveau.
Si votre projet implique des traitements automatisés ou des flux complexes, notre section dédiée à l'automatisation détaille comment nous abordons ces sujets.
Ce que vous pouvez transposer dans votre projet
DreamOracle est consultable directement : voir la réalisation DreamOracle. Mais au-delà du produit lui-même, voici ce que ce projet illustre concrètement.
Si vous portez un produit destiné au grand public — pas un outil interne, pas un prototype — vous avez besoin d'une chaîne complète : conception, design, développement, mise en marché. Ces quatre étapes sont interdépendantes. Couper l'une d'elles revient à fragiliser les trois autres. La conception sans design donne un produit qui fonctionne mais qui ne convainc pas. Le développement sans réflexion sur l'acquisition donne un produit que personne ne trouve. Le design sans conception solide donne une belle coquille vide.
Ce que les équipes sous-estiment le plus systématiquement, c'est le design et la mise en marché. Pas le code. Le code, on sait qu'il prend du temps. Les deux autres, on pense pouvoir les expédier. Ce projet nous a confirmé que c'est là que se joue l'essentiel.
Si votre produit touche à des traitements de données personnelles ou à des fonctionnalités d'IA, notez que la conformité au règlement européen sur l'IA devient un sujet concret pour les PME : Audityo accompagne les entreprises sur la conformité EU AI Act, ce qui peut être utile à anticiper dès la phase de conception.
Conclusion
DreamOracle est en ligne, installable sur téléphone, ouvert au public. Ce résultat est le fruit d'une chaîne complète menée sans raccourci. Si vous avez un projet produit qui suppose cette même ambition, la meilleure façon de savoir ce que ça implique concrètement pour vous, c'est d'en parler directement. Nous proposons un rendez-vous de découverte de trente minutes, offert et sans engagement, pour évaluer ensemble ce que votre projet demande réellement et comment le structurer.