Application mobile
La première question n’est pas laquelle, c’est s’il en faut une
Beaucoup de projets d’application mobile se règlent mieux par un site conçu pour le téléphone. Quand une vraie application se justifie, l’essentiel du travail est ailleurs : dans l’API qui la nourrit.
- L’arbitrage posé avant le devis, pas après
- API REST, gRPC ou GraphQL sur mesure
- Interface web mobile en VueJS ou React
- Hébergée sur notre infrastructure, en France
Le principe
Trois réponses, et une seule s’appelle « application »
Le site conçu pour le téléphone
C’est la réponse qui convient le plus souvent, et de loin. Consulter, réserver, commander, remplir un formulaire, suivre un dossier : tout cela se fait très bien dans un navigateur, sur un site pensé pour un écran de téléphone.
L’avantage est décisif : rien à installer, rien à faire valider, une seule version à maintenir. Un lien suffit à y accéder, et une correction est en ligne dans la minute. Beaucoup d’entreprises paient une application pour découvrir que leurs clients ne l’installent pas — le coût d’entrée d’une installation est très supérieur à celui d’un lien.
L’application installable
Entre les deux, il existe une réponse intermédiaire : une application web que l’on ajoute à l’écran d’accueil, qui s’ouvre en plein écran et fonctionne en partie hors connexion. On garde le déploiement instantané du web et l’on gagne la présence sur le téléphone.
Elle couvre une bonne part des usages internes — un outil pour des équipes en déplacement, une saisie sur le terrain — sans le cycle de publication ni les règles des magasins d’applications.
Quand une vraie application se justifie
Trois cas, assez francs : un besoin hors connexion durable, l’usage de capteurs ou de matériel que le navigateur n’atteint pas correctement, ou des notifications qui font partie du service et pas du confort.
Si vous êtes dans l’un d’eux, l’arbitrage est fait. Sinon, le web mobile vous coûtera moins cher à construire comme à faire vivre, et nous vous le dirons.
Ce qui décide vraiment du projet
Dans tous les cas, ce qui porte l’application n’est pas l’écran : c’est l’API et ce qu’il y a derrière. Comptes et authentification, données synchronisées, règles métier, montées de version qui ne cassent pas les appareils restés sur une ancienne version.
C’est cette partie que nous construisons — en Symfony, Python, Java, Kotlin, Go ou Node.js, exposée en REST, gRPC ou GraphQL — et que nous hébergeons sur notre infrastructure, en France. C’est aussi la partie qui survit à un changement de technologie côté écran, et qui représente l’essentiel de la valeur.
Un point à ne pas confondre
Une application front de type SPA n’est pas une application mobile, et son référencement est très complexe, souvent impossible : elle convient à ce qui n’a pas besoin d’être indexé — un espace client, un outil métier. Si votre contenu doit être trouvé sur les moteurs, c’est un site qu’il vous faut, éventuellement doublé d’une application.
L’arbitrage
Trois réponses selon le besoin
-
Site conçu pour le téléphone
Consulter, réserver, commander, suivre. Rien à installer, une seule version à maintenir, une correction en ligne dans la minute. La bonne réponse dans la majorité des cas.
-
Application installable
Une application web ajoutée à l’écran d’accueil, en plein écran, utilisable en partie hors connexion. Sans cycle de publication ni règles de magasin.
-
Application native
Justifiée par un besoin hors connexion durable, l’usage de capteurs ou de matériel, ou des notifications qui font partie du service. Trois cas, pas davantage.
-
L’API qui la nourrit
REST, gRPC ou GraphQL, en Symfony, Python, Java, Kotlin, Go ou Node.js. C’est la partie qui porte les règles métier et qui survit aux changements d’écran.
-
Comptes et synchronisation
Authentification, droits, données synchronisées entre appareils, et des montées de version qui ne cassent pas les téléphones restés en arrière.
-
Hébergement et exploitation
Sur notre infrastructure, en France : dimensionnement, sauvegarde, supervision et astreinte. Une application dont l’API tombe ne sert plus à rien.
Questions fréquentes
Application mobile : vos questions
Une autre question ? Le support répond directement, sans intermédiaire, de 9h à 12h et de 14h à 17h.
Ai-je vraiment besoin d’une application ?
Trois besoins la justifient : fonctionner durablement hors connexion, accéder à des capteurs ou du matériel que le navigateur atteint mal, ou envoyer des notifications qui font partie du service. En dehors de ces cas, un site conçu pour le téléphone rend le même service pour bien moins cher — et sans demander une installation à vos utilisateurs.
Pourquoi insistez-vous sur l’API ?
Parce que c’est là que se trouve la valeur et la durée. L’écran change — technologie, mode, refonte ; les comptes, les règles métier et les données restent. Une API bien construite sert successivement un site, une application installable puis une application native, sans être refaite à chaque fois.
Une application se référence-t-elle sur Google ?
Non, et c’est une confusion coûteuse. Le contenu d’une application n’est pas indexé comme celui d’un site ; c’est d’ailleurs aussi vrai d’une application front de type SPA, dont le référencement est très complexe, souvent impossible. Si vous voulez être trouvé, il faut un site — l’application vient éventuellement en plus.
Combien ça coûte ?
Sur devis, et l’écart entre les trois réponses est considérable : un site conçu pour le téléphone, une application installable et une application native publiée sur les magasins n’ont pas le même ordre de grandeur, ni le même coût récurrent. C’est pourquoi nous posons l’arbitrage avant le chiffrage.
Et pour un usage interne, sur le terrain ?
C’est souvent le meilleur terrain pour une application installable : vos équipes s’en servent tous les jours, il n’y a personne à convaincre d’installer quoi que ce soit, et vous évitez le cycle de publication des magasins. Le sujet rejoint alors celui de l’outil métier.
Décrivez l’usage, pas la technologie
Qui s’en sert, où, avec quelle connexion, et pour faire quoi. Ces quatre réponses désignent la bonne solution — et elle est souvent plus simple qu’une application.