Transformer un site web en app pour mobile

Bonjour,

J'aimerais savoir comment ça se passe pour « transformer » un site web en applications mobiles, si possible une pour iOS et une pour Android.
Pour le moment ce n'est que de la curiosité, je voulais savoir ce que ça implique avant de décider si je me lance ou pas...

L'objectif est très simple: l'utilisateur ouvre l'app, et la page d'accueil du site s'affiche sur un genre de navigateur embarqué.
En gros un navigateur normal (donc probablement Safari ou Chrome), sauf qu'il est toujours en plein écran, et qu'il n'y a ni possibilité d'ouvrir une URL hors du site, ni barre d'adresse, ni de boutons suivant/précédent, ni accès aux favoris/signets/marques-page, etc.

ON va supposer que la page d'accueil est responsive (même si ce n'est pas encore gagné), et que quand on la lance sur l'app elle pourra peut-être légèrement différer de la version navigateur normal, mais les différence se limiteraient à la page d'accueil uniquement.
Par exemple je pense virer le texte d'introduction expliquant le but du site si on l'ouvre depuis l'app, c'est logique puisque si on l'a télécharger c'est qu'on sait déjà de quoi il s'agit; et en parralèle ça donne plus de place pour les actions intéressantes.

Évidemment il faut que l'accès aux API HTML5/JavaScript reste possible, et que l'utilisateur puisse créer un compte / se logger comme sur le site original (donc support des cookies), sinon ça n'a aucun intérêt.

1. Est-ce que c'est possible ? J'ai entendu vaguement parler de Cordova qui ferait ce genre de job mais j'ignore réellement comment s'y prendre. Jusqu'à maintenant j'ai plutôt l'impression qu'il sert à afficher des pages HTML/CSS/JavaScript locales, et non pas se trouvant sur un site web atteignable de façon classique.
2. Est-ce que l'application résultante sera accessible avec VoiceOver et TalkBack ? En partant évidemment du principe que le site web original l'est
3. De quoi faut-il tenir compte pour pouvoir être ajouté sur l'AppStore et le PlayStore ?
4. Qu'en est-il si je propose des options payantes ? Pour le moment j'ai prévu de passer par paypal
5. J'aimerais éviter la publicité par contre, même les annonces Google; sur le site original j'en ai pas prévu.

Vous allez très logiquement me demander: quel serait l'intérêt de télécharger l'app plutôt que d'aller sur le site directement avec le navigateur ?
En fait, absolument aucun !

En réalité mon seul but ce serait de simplifier la vie de mes futurs potentiels utilisateurs car je sais que certains:
1 - Ont peur ou ne savent pas utiliser leur navigateur sur leur mobile, alors qu'ils n'ont aucun problème à installer et utiliser des apps provenant des stores
2 - Parce qu'une app a quand même un petit avantage, le fait que l'écran soit totalement dédié à l'app et qu'il y a jamais de boutons propres au navigateur

Merci pour vos réponses

Bonjour Quentin, pour avoir publié plusieurs app en cordova/phonegap je vais essayer de te répondre au mieux.

Le principe de base est effectivement d'utiliser un composant webview qui permet de se servir du browser interne de l'OS et de le faire fonctionner en mode kiosque (plein écran, sans menu/barres d'outils). Ce sera IOS Safari pour Ios et Android browser pour Android (qui peut varier selon les revendeurs)

On peut coder l'app pour chaque système (en java pour android et objective-c/swift pour IOS) ou utiliser cordova qui permettra de ne faire que du HTML/javascript et se chargera des aspects propriétaire pour toi lors du build.

a écrit :
1. Est-ce que c'est possible ? J'ai entendu vaguement parler de Cordova qui ferait ce genre de job mais j'ignore réellement comment s'y prendre. Jusqu'à maintenant j'ai plutôt l'impression qu'il sert à afficher des pages HTML/CSS/JavaScript locales, et non pas se trouvant sur un site web atteignable de façon classique.

Techniquement c'est possible. On verra les problèmes cependant au point 3. Oui cordova sert une application web embarquée. Mais il suffit de faire une app très basique qui lance window.location = mon_url au chargement.

a écrit :
2. Est-ce que l'application résultante sera accessible avec VoiceOver et TalkBack ? En partant évidemment du principe que le site web original l'est

Là je sèche, je dois bien avouer ne pas avoir la réponse. De prime abord je dirais oui, mais cette réponse ne vaut rien.

a écrit :
3. De quoi faut-il tenir compte pour pouvoir être ajouté sur l'AppStore et le PlayStore ?

Pour le play store, de pas grand chose hormis ce qui paraît évident (l'app fonctionne, le contenu est légal, ce n'est pas une arnaque, n'embarque pas de logiciels malveillants, etc.)
Pour l'AppStore, c'est une autre paire de manche. Il y a des guidelines strictes tant sur le visuel que le fonctionnel. Apple demande aussi une valeur ajoutée par rapport à une web app mobile, et si votre app se contente de packager une web app online, vous expliquera (avec raison) comment faire un lien vers votre url sur votre mobile. Il y a très peu de chance que l'application telle que tu la conçois soit publiée sur IOS. Il faut penser à utiliser au moins l'un des avantages d'une app mobile: utilisation offline, utilisation des outils natifs (caméra, scanner, géoloc, notifications, etc.), payements inapp, etc.

a écrit :
4. Qu'en est-il si je propose des options payantes ? Pour le moment j'ai prévu de passer par paypal

Il faudra obligatoirement passer par les fonctionnalités des stores pour cela, ainsi que de s'affranchir de conditions de validation plus strictes. Je ne l'ai jamais fait donc je n'en sait pas plus.

a écrit :
5. J'aimerais éviter la publicité par contre, même les annonces Google; sur le site original j'en ai pas prévu.

Il suffit de ne pas en mettre

Merci pour tes réponses.

Concernant l'accessibilité, j'ai tellement d'applications sur mon iPhone qui ressemblent bizarrement à des pages web avec des pub Google que je me dis qu'elles ont été forcément faites avec un outil comme Cordova.
D'où ma supposition que ça produit effectivement des apps accessibles, toutefois sans avoir aucune certitude puisque je n'ai jamais vu aucun test sérieux, ni personne me confirmant que son app était bien faite avec cet outil.

Pour l'ajout à l'appstore, tu confirmes ce que j'avais imaginé.
S'agissant d'un jeu, le premier avantage évident avec l'app sera que l'utilisateur n'aura aucun risque de sortir de la zone par inadvertance dans le feu de l'action p.ex. en touchant la barre d'état, ou la barre en bas...
C'est loin d'être anodin mais je pense que peu de personne peuvent le comprendre.

Pour les options payantes, quand tu dis que tu dois obligatoirement passer par les fonctionnalités des stores, ça veut dire quoi concrètement ?
a. qu'il faut que ceux qui sont sur l'app iOS soient obligés de passer par l'appstore (en engraissant grassement Apple au passage) et qu'ils ne puissent pas passer par autre chose
ou b. même réponse que a. mais en plus devoir renoncer à tout autre système de payement sur les autres plateformes ? (ça signifierait plus de possibilité d'acheter par paypal sur le site en version PC par exemple)


Merci.

Je m'y suis intéressé, et apparemment la webview est compatible avec Talkback depuis Android 4. Et compatible avec VoiceOver. Je vais faire quelques tests je pense.

a écrit :

C'est loin d'être anodin mais je pense que peu de personne peuvent le comprendre.

Je vois. Le problème est que ce n'est pas moi mais Apple qu'il faut convaincre. Et la seule manière de savoir si ça passe c'est de tester.

Sinon, une vraie app en local a d'autres avantages, phonegap/cordava dispose apparemment d'un plugin permettant d'avoir accès aux infos d'accessibilité du système ou de faire parler directement VoiceOver/TalkBack: https://github.com/phonegap/phonegap-mobile-accessibility.

Pour le paiement, il fait effectivement passer par Google Play / AppStore, chacun a des conditions d'utilisation stricte sur le sujet. Graisser la patte de Paypal, Apple ou Google, ça ne fait pas grandes différences. Par contre le système centralisé est quand même bien plus agréable pour les utilisateurs.

a écrit :
Sinon, une vraie app en local a d'autres avantages, phonegap/cordava dispose apparemment d'un plugin permettant d'avoir accès aux infos d'accessibilité du système ou de faire parler directement VoiceOver/TalkBack:

Ah oui, ça fait un vrai gros avantage en plus. C'est beaucoup plus fiable de faire parler le lecteur d'écran directement, plutôt que de se fier
1 - soit à aria-live, qui est très capricieux ou qui ne lit pas toujours tout, et qui est un peu plus lent
2 - à Web Speech API, car les deux voix peuvent parler en même temps et il n'y a aucun moyen de le savoir ou de l'éviter

Par contre, arrête-moi si je me trompe, mais même pour pouvoir faire une app iPhone/iPad avec Cordova/PhoneGap, il faut quand même posséder un mac avec XCode pour pouvoir la compiler ? En tout cas c'est ce que je comprends de ce que j'ai déjà lu...

a écrit :
Graisser la patte de Paypal, Apple ou Google, ça ne fait pas grandes différences.

Heu si, quand même. Paypal te prend quelque chose comme 4%. Ca reste une taxe relativement acceptable par rapport au service rendu. Ca serait sûrement beaucoup plus compliqué de traiter directement avec une vraie banque, surtout si les montants ne sont pas faramineux (je n'imagine pas faire du micropaiement à coups de 2€ avec une banque classique).

D'après ce que j'ai lu, Apple ramasse 30% par contre. C'est juste... indécent.

QuentinC a écrit :
Par contre, arrête-moi si je me trompe, mais même pour pouvoir faire une app iPhone/iPad avec Cordova/PhoneGap, il faut quand même posséder un mac avec XCode pour pouvoir la compiler ? En tout cas c'est ce que je comprends de ce que j'ai déjà lu...

Cordova est un toolkit qui permet de construire ton app (c'est du node.js). Par contre pour faire le build il lui faudra les SDK des systèmes. qui s'obtient au travers d'xcode pour IOS et qui s’installe indépendamment sur tout OS pour Android. Par contre Phonegap est un service d'Adobe construit autour de Cordova et qui permet quelques facilités, notamment le build en ligne sans avoir besoin de maintenir des SDK localement. Par contre le service est payant, il existe cependant une version gratuite limité à 1 app, ou la version complète gratuite pour ceux étant déjà clients Adobe (creative suite, etc.).

Encore une chose, pour soumettre et publier son App chez Apple, il faut un compte développeur Apple qui est payant lui aussi.

QuentinC a écrit :
D'après ce que j'ai lu, Apple ramasse 30% par contre. C'est juste... indécent.

En effet, par contre 15% dès la seconde année je crois. Mais cela n'est pas juste une taxe pour le service de paiement, l'AppStore diffuse et vends ton app, c'est une marge de commerçant. On peut discuter de la marge mais ça ne peut se comparer à Paypal.

Quoi qu'il en soit depuis le début jusqu'à la publication de l'app, la route est longue. C'est parfois compliqué (Surtout chez la pomme), il faut investir en temps et en argent.

QuentinC a écrit :

Pour les options payantes, quand tu dis que tu dois obligatoirement passer par les fonctionnalités des stores, ça veut dire quoi concrètement ?
a. qu'il faut que ceux qui sont sur l'app iOS soient obligés de passer par l'appstore (en engraissant grassement Apple au passage) et qu'ils ne puissent pas passer par autre chose
ou b. même réponse que a. mais en plus devoir renoncer à tout autre système de payement sur les autres plateformes ? (ça signifierait plus de possibilité d'acheter par paypal sur le site en version PC par exemple)

Sur ce point, Apple est devenu plus qu’intransigeant (pour rester poli).

L'entreprise où je travaille propose un abonnement. Afin de contourner Apple et ses 30% de commission (ils se mettent bien), nous avons essayé de diriger les utilisateurs vers notre site internet afin qu'ils s'abonnent. Cela a fonctionné un temps mais depuis quelques mois, Apple a durci le ton concernant son service In-App Purchase. Si ton service est payant, quelqu'en soit la manière, ils compteront toucher leur commission.

a écrit :
Encore une chose, pour soumettre et publier son App chez Apple, il faut un compte développeur Apple qui est payant lui aussi.

Ca, je savais. 100$ par année sauf erreur.

a écrit :
L'entreprise où je travaille propose un abonnement. Afin de contourner Apple et ses 30% de commission (ils se mettent bien), nous avons essayé de diriger les utilisateurs vers notre site internet afin qu'ils s'abonnent. Cela a fonctionné un temps mais depuis quelques mois, Apple a durci le ton concernant son service In-App Purchase. Si ton service est payant, quelqu'en soit la manière, ils compteront toucher leur commission.

Qu'est-ce que ça signifie au final ? Que celui qui s'abonne sur le site ne doit pas pouvoir accéder à ton contenu payant depuis son iPhone et réciproquement ?
Ou alors ça m'oblige à m'abonner deux fois si je veux pouvoir accéder au même contenu indifféremment sur PC ou dans l'app iOS ?

a écrit :
Par contre Phonegap est un service d'Adobe construit autour de Cordova et qui permet quelques facilités, notamment le build en ligne sans avoir besoin de maintenir des SDK localement. Par contre le service est payant, il existe cependant une version gratuite limité à 1 app, ou la version complète gratuite pour ceux étant déjà clients Adobe (creative suite, etc.).

Aha, ce n'était pas clair la différence entre les deux, merci pour les précisions.

à 10$/mois pour juste s'éviter d'installer le machin chez soi ça me donne l'impression à priori dêtre quand même cher payé; mais s'ils le font et que ça marche, c'est sûrement parce que ça doit probablement être sacrément chronophage et ch### à faire.
Au moins on peut tester le service gratuitement en publiant une app. La condition c'est qu'elle fasse moins de 50 Mo. Pour un jeu c'est assez peu en fait, mais si on externalise un maximum sur un site web ça doit quand même être largement jouable.


Du coup je vais peut-être commencer par essayer ce service, ça ne m'engage à rien à part créer un compte Adobe qui ne servira qu'à ça.

a écrit :
Quoi qu'il en soit depuis le début jusqu'à la publication de l'app, la route est longue. C'est parfois compliqué (Surtout chez la pomme), il faut investir en temps et en argent.

Ca a l'air oui. J'ai clairement raté le contour app mobile dans mes projets perso. Ca fait déjà 2 ou 3 ans qu'on me le suggère, voire réclame...

Bonjour, nous sommes une jeune société spécialisée dans la transformation de site internet en application Android et iOs. Toutes nos applications intègrent les notifications, écran splashscreen et sont convertibles avec les derniers téléphones (iPhone X, Android 9 Pie en ce moment). Toutes les infos sont sur notre site : https://webtoapp.io (email contact@webtoapp.io).
Modifié par WebToApp (12 Dec 2018 - 13:03)

salut,

pour transformer un site web en app (android et/ou IOS) tu as Progressive Web App

tu pourras lui donner l'apparence d'une App classique y mettre un splashScreen, un system de push et une icone sur le bureau.

Apple à même assoupli sa politique vis à vis des PWA.