Applications Mobiles

Des applications mobiles que l'on garde sur son téléphone

Multiplateforme par défaut, natif lorsque cela se justifie vraiment — et, avant tout, une réponse honnête sur la nécessité même d'une application.

Commencez par savoir si une application est nécessaire

La chose la plus utile que nous puissions faire au début d'un projet mobile, c'est le remettre en question. Une application est un second produit à concevoir, publier, soumettre à validation, mettre à jour et maintenir, sur deux plateformes, indéfiniment. Ce coût se justifie quand l'application le mérite, et se gaspille quand un bon site mobile aurait rendu le même service.

Une application se justifie quand les gens y reviennent souvent, quand le téléphone lui-même est nécessaire — notifications, appareil photo, localisation, lecture de codes, usage réellement hors ligne — ou quand l'application est le produit et non sa vitrine. Si l'objectif est d'être trouvé, d'expliquer votre métier et de recueillir des demandes, un site web est le meilleur investissement, et nous le dirons.

Lorsqu'une application s'impose, la question suivante est comment la construire. Pour la plupart des applications d'entreprise, la réponse est le multiplateforme : un seul code pour iOS et Android, généralement d'un tiers à moitié moins cher que de tout construire deux fois. Le natif se justifie dans des cas précis, et nous vous dirons si le vôtre en fait partie.

Comment nous construisons

Applications multiplateformes (React Native et Flutter)

Un seul code, les deux plateformes. Pour l'immense majorité des applications d'entreprise, l'écart de performance avec le natif est assez faible pour que les utilisateurs ne le remarquent jamais, tandis que l'économie sur la construction et la maintenance est substantielle et durable.

Nous retenons React Native par défaut, car il partage compétences et souvent code avec une stack React côté web — ce qui pèse davantage sur cinq ans que n'importe quel test de performance. Flutter s'impose lorsque l'interface est le produit : animation soutenue, système de conception identique au pixel sur les deux plateformes.

  • Un seul code pour iOS et Android
  • React Native par défaut, Flutter quand l'interface est le produit
  • Compétences partagées avec la stack web
  • Une mise à jour touche les deux plateformes

Natif iOS et Android

Swift et Kotlin, développés par plateforme. C'est plus coûteux à réaliser et environ deux fois plus à maintenir : il faut donc une raison qui dépasse la préférence.

Ces raisons existent : interfaces à forte charge graphique ou 3D, réalité augmentée ou vision par ordinateur sur l'appareil, besoin d'une API de plateforme dès sa sortie, ou produits où la latence est l'essentiel — outils professionnels de photo et d'audio. Si vous êtes dans ce cas, nous vous le dirons.

  • Swift pour iOS, Kotlin pour Android
  • Accès complet aux API de la plateforme dès le premier jour
  • Le bon choix pour le graphique, la RA et la latence critique
  • Nous assumons clairement le surcoût de construction et de maintenance

Quand une application web est la meilleure réponse

Le natif n'est plus le point de départ. Une application web progressive se trouve dans les moteurs de recherche, s'ouvre depuis un lien, n'exige aucune installation, évite la commission des stores et se met à jour dès la publication.

Elle concède du terrain : accès profond au matériel, tâches en arrière-plan, et les notifications restent plus limitées sur iOS que sur Android. Une bonne réponse fréquente consiste à avoir les deux : une application web pour la portée, et une application native légère pour ceux qui l'utilisent chaque jour.

  • Trouvable en recherche, sans installation
  • Ni commission de store ni attente de validation
  • Mise à jour dès la publication
  • Se combine bien avec une application native ciblée

Mode hors ligne et temps réel

Les téléphones perdent le réseau. Une application qui présuppose la connexion échoue précisément là où les équipes de terrain travaillent : sous-sols, entrepôts, zones rurales, en déplacement. Le hors-ligne d'abord signifie que l'application reste utilisable et se réconcilie au retour du réseau.

Le difficile, c'est la réconciliation, pas la mise en cache : décider ce qui se passe quand deux personnes ont modifié le même enregistrement hors ligne. Nous définissons cette règle avec vous plutôt que de laisser la dernière écriture l'emporter en silence.

  • Utilisable sans connexion
  • Règles de synchronisation et de conflit arrêtées en amont
  • Mises à jour en temps réel là où elles comptent
  • Des notifications qui respectent l'attention des gens

Publication sur les stores et la suite

Entrer sur l'App Store et Google Play est un processus avec ses propres règles : consignes de validation, déclarations de confidentialité, formulaires de sécurité des données, classification par âge, versions de test pour votre équipe.

Et cela continue ensuite. Apple et Google publient des versions du système chaque année et relèvent périodiquement les exigences minimales : une application laissée en l'état finit par ne plus être acceptée. La maintenance n'est pas optionnelle, et nous en annonçons le coût avant de vous engager.

  • Soumission à l'App Store et à Google Play
  • Déclarations de confidentialité et de sécurité des données
  • Versions de test pour l'équipe avant publication
  • Mises à jour système et SDK après le lancement

Votre entreprise a-t-elle besoin d'une application ?

La version honnête. Bien des entreprises qui nous demandent une application seraient mieux servies autrement, et il est moins coûteux de s'en apercevoir maintenant.

Une application se justifie lorsque

  • Les gens l'utilisent souvent — chaque semaine ou chaque jour
  • Le téléphone est nécessaire : notifications, appareil photo, localisation, lecture de codes, capteurs
  • Elle doit fonctionner sans réseau et se synchroniser ensuite
  • L'application est le produit, pas une vitrine
  • Il faut une présence sur l'écran d'accueil pour entretenir l'habitude

Un site web est un meilleur investissement lorsque

  • L'objectif est d'être trouvé, d'expliquer et de recueillir des demandes
  • Les gens s'en serviraient une ou deux fois par an
  • Le contenu change sans cesse et la recherche compte
  • Aucun budget n'est prévu pour la maintenance après le lancement
  • La raison principale est que les concurrents en ont une

Notre façon de travailler

Des cycles plus courts que sur le web, car la validation des stores s'intercale entre vous et vos utilisateurs.

  1. 01

    Cadrage

    Nous arrêtons à quoi sert l'application, qui l'utilise et ce que la première version doit impérativement faire. Ce qui peut attendre attend : une première version plus petite atteint plus tôt de vrais utilisateurs.

  2. 02

    Conception

    Écrans et parcours validés en prototype navigable, dans le respect des conventions de chaque plateforme plutôt qu'en imposant un même dessin aux deux.

  3. 03

    Développement et tests

    Des versions de test régulières sur vos propres appareils, pas seulement en simulateur, pour utiliser l'application sur le téléphone que vous avez en poche.

  4. 04

    Lancement et maintenance

    Nous prenons en charge la soumission et la validation, puis maintenons l'application à jour à mesure qu'iOS et Android évoluent.

Technologies

Nous choisissons la technologie en fonction de l'application, et non l'inverse, en restant sur des outils largement adoptés afin que l'application reste maintenable par toute équipe compétente.

Multiplateforme

React NativeFlutterTypeScript

Natif

SwiftKotlin

Backend

FirebaseAWS AmplifyAPI RESTNotifications push

Quand une application se justifie

Des situations où le téléphone apporte ce qu'un site web ne peut pas. Ces exemples illustrent le type de travail que nous menons.

Équipes de terrain

Des techniciens qui consignent interventions, photos et signatures sur place, travaillent hors ligne et se synchronisent une fois le réseau retrouvé.

Application compagnon pour vos clients

Une application destinée aux clients existants pour suivre commandes, rendez-vous ou livraisons, où la notification remplace une série de courriels.

Rendez-vous et fidélité

Des activités où l'on revient souvent, et où une icône sur l'écran d'accueil et un rappel valent mieux qu'un onglet de plus.

Lecture de codes et inventaire

Stocks, actifs ou billets vérifiés avec l'appareil photo du téléphone, quand l'alternative est un matériel dédié ou du papier.

Questions fréquentes

Combien coûte une application mobile ?

C'est le périmètre qui décide, pas la plateforme : nombre d'écrans, ampleur du backend, nombre d'intégrations. Le multiplateforme se situe généralement bien en dessous d'une double construction native, et c'est la raison principale d'en faire notre point de départ. Nous cadrons d'abord et annonçons un chiffre réel plutôt que d'estimer avant d'avoir compris l'application.

Multiplateforme ou natif ?

Multiplateforme pour la plupart des applications d'entreprise : les utilisateurs ne perçoivent pas la différence et vous divisez par deux la maintenance à long terme. Natif quand l'application est gourmande en graphismes, repose sur la réalité augmentée ou la vision sur appareil, exige des API tout juste publiées, ou lorsque la latence est le produit. Nous vous dirons franchement de quel côté se situe votre cas.

Nous faut-il une application ou un site suffit-il ?

Souvent un site suffit. Si les gens venaient une ou deux fois par an, ou si l'objectif est d'être trouvé et d'expliquer votre métier, un bon site mobile est un meilleur investissement. Une application se justifie par un usage répété, le besoin du matériel du téléphone, un usage réellement hors ligne, ou parce que l'application est le produit.

Combien de temps faut-il ?

Une première version ciblée demande généralement quelques mois, plus la validation des stores. Nous gardons délibérément cette première version réduite, car de vrais utilisateurs sur de vrais téléphones en disent davantage sur la suite qu'un mois de planification supplémentaire.

À qui appartiennent l'application et le code ?

À vous. Le code, les données et les fiches sur les stores appartiennent à votre entreprise. Nous publions sous vos comptes développeur et non sous les nôtres, afin que vous ne soyez jamais privés d'accès à votre propre application.

Combien coûte la maintenance après le lancement ?

Le mobile comporte un socle de coûts que le web n'a pas : iOS et Android sortent chaque année et relèvent périodiquement leurs exigences minimales, si bien qu'une application laissée en l'état finit par ne plus être acceptée. Nous convenons du dispositif de maintenance avant le lancement, pour que ce soit un coût connu et non une surprise.

Domaines liés

Des prestations qui font souvent partie du même projet.

Vous envisagez une application ?

Dites-nous ce qu'elle ferait et qui l'utiliserait. Vous aurez une réponse franche sur la pertinence d'une application et sur ce qu'il faudrait pour la construire.