« Il nous faut une appli RA » : souvent le mauvais point de départ
Presque tous les lancements de projet RA partent de la même hypothèse : ça doit être une application. Parfois, c'est le bon choix. Souvent, ce ne l'est pas, et l'obligation d'installer quelque chose est précisément ce qui tue l'expérience avant que quiconque ne la voie.
La vraie question n'est pas « application ou pas d'application » — c'est comment la personne rencontre réellement l'expérience, et si lui demander d'installer quelque chose au préalable survit à ce moment de contact.
Le calcul de friction à l'installation que personne ne fait
Si quelqu'un découvre votre expérience RA via une publicité, un QR code sur un emballage, une bannière de salon professionnel ou une publication sur les réseaux sociaux, le tunnel honnête ressemble à ceci : voir, vouloir essayer, tomber sur un écran de téléchargement sur un app store, et — pour l'immense majorité des gens — abandonner immédiatement. Une RA de découverte qui exige une installation perd la majeure partie de son audience avant même que l'expérience ne se charge.
WebXR et des outils comme 8th Wall résolvent exactement ce problème : de la RA directement depuis un navigateur, lancée depuis un lien ou un QR code, sans installation, opérationnelle en quelques secondes. Pour une campagne d'essayage produit, une démo de salon, ou tout ce dont l'enjeu est « essayez ça maintenant, où que vous soyez », supprimer l'étape d'installation n'est pas un confort superflu — c'est la différence entre des gens qui essaient et des gens qui font défiler sans s'arrêter.
Où la RA native l'emporte vraiment
La RA native, construite avec ARKit et ARCore au sein d'une application complète, justifie sa complexité dans des situations différentes :
Vos utilisateurs ont déjà l'application ouverte régulièrement. L'application d'achat d'une enseigne de meubles, une appli de bricolage vers laquelle les gens reviennent à chaque projet — l'essayage propulsé par la RA est une fonctionnalité qui vient s'ajouter à une relation déjà existante, et non quelque chose qui exige une nouvelle installation juste pour voir un produit.
Vous avez besoin d'un suivi qui persiste entre les sessions. Des ancrages à l'échelle de la pièce qui se souviennent de l'emplacement où un objet virtuel a été placé, des mesures qui doivent rester précises sur plusieurs visites — cela exige une intégration système plus profonde qu'un bac à sable de navigateur ne peut offrir.
Vous avez besoin de capacités spécifiques au matériel. La détection de profondeur LiDAR sur les iPhones récents, l'occlusion précise (les objets virtuels se dissimulant correctement derrière les objets réels), ou le suivi des mains sur Meta Quest sont soit indisponibles, soit nettement dégradés dans un contexte navigateur. Si l'expérience dépend de cette fidélité, le natif est la seule option viable.
Choisir le moteur une fois la plateforme connue
Pour les jeux mobiles, la RA casual et la majorité des projets multiplateformes, Unity 6 est le choix par défaut — un outillage mature, un large support des appareils, et un vaste écosystème de plugins pour les SDK RA. Unreal Engine 5 se justifie quand la fidélité visuelle est l'enjeu central : vitrines 3D haut de gamme, visualisation produit cinématique, tout ce dont la qualité du rendu est explicitement l'image de marque. Pour une portée navigateur sans installation, Three.js et WebXR couvrent la 3D interactive et la RA qui doivent être accessibles en un tap, pas en un téléchargement.
Apple Vision Pro et Meta Quest occupent une catégorie à part : des applications natives visionOS/RealityKit et des builds natifs pour Quest, pour des expériences véritablement immersives à l'échelle de la pièce, qu'un écran de téléphone ou un onglet de navigateur ne peuvent pas reproduire — simulations de formation, revues de conception spatiale, tout ce dont l'enjeu est d'être à l'intérieur de l'expérience plutôt que de la regarder à travers un rectangle.
Un test simple avant de se lancer
Posez une seule question : cette expérience sera-t-elle rencontrée une seule fois, par quelqu'un qui prend une décision rapide, depuis une publicité ou un lien — ou s'agit-il d'une fonctionnalité récurrente pour des gens qui ont déjà votre application ouverte ? Ponctuel et rapide → WebXR, sans installation, en supprimant chaque point de friction entre le moment où on la voit et celui où on l'essaie. Récurrent et natif de l'application → intégrez-la à l'expérience native en laquelle vos utilisateurs ont déjà confiance.
Inverser les deux est l'erreur coûteuse la plus fréquente des projets RA : construire une application native complète pour une campagne marketing ponctuelle qui ne demandait aucune friction, ou construire une démo navigateur pour une fonctionnalité qui devait persister et s'intégrer à une application que les gens utilisent déjà au quotidien.
Ce que ça coûte
Un jeu mobile casual ou une expérience RA de marque — WebXR ou native — démarre généralement autour de $15,000. Les titres 3D multijoueurs et les builds RV complets, avec l'ingénierie supplémentaire liée au netcode, à la physique et à l'optimisation spécifique au casque, démarrent à partir de $50,000+.
En résumé
Ne partez pas du principe qu'il faut « construire une application ». Demandez-vous plutôt comment la personne arrive réellement à l'expérience, et laissez cette réponse déterminer la plateforme. Notre équipe jeux, RA et RV définit le moteur et le mode de diffusion — WebXR, mobile natif, ou un build Vision Pro/Quest — en fonction de la manière dont votre audience spécifique rencontrera réellement l'expérience, et non de la plateforme qui sonne le mieux dans un pitch deck.
