Service
Développement d'applications mobiles
Des applications qui continuent quand le réseau s'arrête.
Pour les équipes dont les utilisateurs ne sont pas assis à un bureau — personnel de terrain, conducteurs de travaux, équipes de livraison, commerciaux en déplacement — et pour les applications grand public où la première minute décide si elle est conservée. Ce qui compte ici techniquement, c'est le comportement hors ligne et la synchronisation, pas les écrans.
La décision
Quand c'est le bon choix.
La plupart des applications mobiles sont démontrées sur le wifi du bureau et utilisées sur une 4G capricieuse à l'entrée d'un chantier. C'est dans cet écart qu'elles échouent. Une application qui présuppose la connexion se verra reprocher d'avoir perdu des données qu'elle n'a jamais reçues — et une fois que le personnel de terrain ne lui fait plus confiance, il revient au papier, soit exactement le résultat que le projet devait empêcher.
La synchronisation est la partie difficile, et c'est en général celle qui a été cadrée en une phrase. Que se passe-t-il quand deux personnes modifient le même enregistrement hors ligne, quand un téléphone revient après trois jours, quand le serveur a entre-temps changé les règles. Ce sont des décisions de conception, et si personne ne les prend, l'application les prend elle-même, mal.
Nous arrêtons le modèle de conflit avant de construire, faisons du hors-ligne le cas normal plutôt que le cas d'erreur, et testons sur une connexion bridée plutôt que sur le wifi. Les écrans sont la moitié facile.
Ce que vous obtenez
Ce que couvre la mission.
Données en mode hors ligne d'abord
Le stockage local comme source de vérité pour la session, avec une file qui survit à la fermeture de l'application et une règle de conflit choisie délibérément.
Une synchronisation que vous pouvez inspecter
L'état de synchronisation est visible pour l'utilisateur et pour le support, si bien que « ça n'a pas été enregistré » devient une question avec une réponse.
Natif ou multiplateforme
Kotlin et Swift là où le matériel, le traitement en arrière-plan ou la performance l'exigent ; une base de code partagée là où l'application est surtout faite d'écrans et où l'économie est réelle.
Un traitement en arrière-plan qui tient
Synchronisation et envoi planifiés qui continuent sous les restrictions de batterie d'Android, testés sur les surcouches constructeurs qui les cassent.
Une authentification qui échoue proprement
Expiration des jetons correctement gérée — une session expirée déconnecte l'utilisateur au lieu de rejouer indéfiniment une requête morte.
Ingénierie des versions
Builds signés, déploiement progressif, remontée des plantages et invitations de mise à jour dans l'application, pour qu'une mauvaise version puisse être stoppée.
Stack
Avec quoi nous le construisons.
Choisis projet par projet. Rien n'est imposé par défaut ici, et l'équipe qui assurera la maintenance pèse autant que le problème.
Android
Kotlin avec Jetpack Compose, Room pour le stockage local, WorkManager pour la synchronisation en arrière-plan.
iOS
Swift avec SwiftUI, et la persistance native de la plateforme plutôt qu'une couche intermédiaire.
Multiplateforme
React Native ou Flutter là où l'application est portée par ses écrans et où une base de code divise réellement le travail par deux.
Backend
La même API que celle de votre plateforme web, versionnée pour qu'une ancienne application sur le terrain continue de fonctionner.
Distribution
Play Store et App Store, ou distribution d'entreprise gérée quand l'application est interne.
Comparaison
Multiplateforme ou natif.
La première vraie décision d'un projet mobile. Nous faisons les deux, donc ce tableau est le raisonnement réel et non un argumentaire en faveur de notre préférence.
| Critère | Multiplateforme | Natif |
|---|---|---|
| Convient le mieux à | Formulaires, listes, synchronisation — des applications qui sont surtout des écrans au-dessus d'une API | Caméra, localisation en arrière-plan, Bluetooth ou performance soutenue |
| Coût pour deux plateformes | À peu près un seul build, plus les finitions propres à chaque plateforme | Proche de deux builds, et deux bases de code à maintenir ensuite |
| Hors ligne et synchronisation | Tout à fait réalisable ; la conception de la synchronisation compte bien plus que le framework | Pareil — c'est une décision de modèle de données, pas de plateforme |
| Fonctions matérielles et système | Suffisant pour les cas courants ; tout ce qui sort de l'ordinaire demande de toute façon un module natif | Accès direct, et aucun pont à déboguer quand un constructeur change de comportement |
| Traitement en arrière-plan sous les restrictions de batterie d'Android | Faisable, mais les surcouches agressives des constructeurs doivent être testées dans les deux cas | Plus facile à maîtriser, et plus facile à diagnostiquer quand un appareil tue le processus |
| Maintenance à long terme | Une seule base de code, plus un framework avec son propre cycle de montée de version | Deux bases de code, mais chacune sur le chemin bien documenté de sa plateforme |
Comment cela se déroule
De la première conversation à la mise en ligne.
Indicatif pour un travail de cette nature. Le pilote n'est pas optionnel — rien n'est basculé tant que les utilisateurs n'ont pas dit que cela tient.
- 1 semaine
Cadrage
Nous arrêtons le modèle de conflit et le comportement hors ligne avant de concevoir quoi que ce soit. Rajouter l'un ou l'autre ensuite revient presque à tout réécrire.
- 4 à 8 semaines
Développement du socle
D'abord le stockage local, la file de synchronisation et le chemin de travail principal, testés sur une connexion bridée plutôt que sur le wifi du bureau.
- 2 à 3 semaines
Pilote sur le terrain
De vrais utilisateurs sur leurs propres téléphones — y compris les bas de gamme — pendant que le processus papier continue. C'est là que les hypothèses sur le hors-ligne se corrigent.
- 1 à 2 semaines
Publication
Soumission aux stores ou distribution gérée, déploiement progressif, remontée des plantages et invitation de mise à jour dans l'application pour qu'un mauvais build puisse être stoppé.
Après la mise en service
Ce qui change.
- Les équipes de terrain l'utilisent encore après le deuxième mois, et c'est la seule vraie mesure pour une application de terrain.
- « Ça n'a pas été enregistré » devient une question avec une réponse, parce que l'état de synchronisation est visible pour l'utilisateur et pour le support.
- Un téléphone resté trois jours hors ligne se réconcilie sans que personne ne perde son travail.
- Une ancienne version restée sur le terrain continue de fonctionner, parce que l'API est versionnée et non supposée à jour.
Décrit qualitativement à dessein. Nous ne publions pas de pourcentages d'amélioration que nous ne pouvons pas rattacher à un client nommé, avec son accord.
Questions
Questions fréquentes.
Natif ou multiplateforme — que devons-nous choisir ?
Si l'application est surtout faite de formulaires, de listes et de synchronisation, l'économie du multiplateforme est en général la bonne. Si elle dépend de la caméra, de la localisation en arrière-plan, du matériel Bluetooth ou d'une performance soutenue, le natif rentabilise son surcoût. Nous recommandons d'après ce que l'application fait réellement, pas d'après une préférence maison.
Fonctionnera-t-il sans internet ?
C'est prévu dès le départ là où l'usage l'exige. Les enregistrements sont écrits localement, mis en file et synchronisés au retour de la connexion, et cette file survit à la fermeture de l'application ou au redémarrage du téléphone.
Publiez-vous sur les stores pour nous ?
Oui, y compris les fiches des stores, les captures d'écran et les réponses aux avis. Les comptes restent à votre nom — nous ne détenons jamais le compte store d'un client.
Peut-il fonctionner avec notre système actuel ?
Oui. La plupart des applications mobiles que nous construisons sont une surface de terrain au-dessus d'un système déjà en place, et non un produit distinct avec ses propres données.
Pouvez-vous reprendre une application développée par quelqu'un d'autre ?
En général oui. Nous commençons par un examen rapide de la base de code, de la chaîne de publication et des comptes stores, puis nous revenons avec ce que cela demanderait. Si la réponse honnête est qu'une réécriture coûte moins cher que la reprise, nous le dirons et montrerons le raisonnement.
Avons-nous vraiment besoin d'une application, ou un site mobile suffirait-il ?
Un site responsive couvre beaucoup et coûte bien moins cher. Une application justifie son coût quand il vous faut du hors-ligne, un accès matériel, du traitement en arrière-plan ou des notifications push. Si rien de tout cela ne s'applique, nous vous orienterons vers la réponse la moins chère.