Nous développons des applications multiplateformes en React Native et Flutter — une équipe, une base de code, les deux stores — et nous sommes francs sur les cas où le natif reste le meilleur choix.
Les projets mobiles échouent plus souvent après le lancement que pendant. Le développement s'achève, l'application arrive sur les deux stores, puis les systèmes d'exploitation avancent. Apple et Google publient chacun une version majeure par an, déprécient des API selon un calendrier et modifient périodiquement ce que la revue accepte. Une application que personne n'entretient devient, en dix-huit mois environ, une application qui ne compile plus — et une mise à jour refusée à ce stade relève de la reconstruction, pas du correctif.
Le second problème récurrent consiste à considérer le réseau comme fiable. Les téléphones perdent le signal dans les ascenseurs, les trains et les bâtiments où le personnel de terrain travaille réellement. Une application qui suppose la connectivité produit des indicateurs de chargement, des saisies perdues et des appels au support. Le comportement hors ligne est une décision de conception prise tôt, pas une fonctionnalité ajoutée plus tard.
Ce sont autant des questions de budget que de technique. Nous préférons poser l'attente avant le démarrage du projet plutôt que de livrer quelque chose qui expirera discrètement.
React Native ou Flutter, selon les besoins de l'application et ce que votre équipe saura maintenir. Du code spécifique à une plateforme là où la différence compte vraiment, du code partagé partout ailleurs — c'est-à-dire presque partout.
Persistance locale, écritures mises en file d'attente et gestion des conflits, conçues d'après votre usage réel et non évacuées par hypothèse. Si vos utilisateurs travaillent en entrepôt, en sous-sol ou en véhicule, c'est ce qui sépare une application adoptée d'une application abandonnée.
Configuration de l'App Store et de la Play Console, signature, déclarations de confidentialité, fiches produit et cycle de revue. Les premières soumissions sont refusées assez souvent pour que l'expérience fasse gagner du temps réel sur le calendrier.
Segmentées, autorisées, et liées à des événements que les gens souhaitent vraiment connaître. L'autorisation de notification s'accorde une fois et se révoque définitivement : la première demande doit se mériter, pas se déclencher au lancement.
Les clients mobiles ont besoin d'API différentes de celles des navigateurs — moins d'allers-retours, des charges utiles plus légères, et un versionnage, puisqu'on ne peut pas forcer tout le monde à mettre à jour en même temps. Nous concevons l'API dans cet esprit ou adaptons celle qui existe.
Builds automatisés, déploiement progressif et remontée des plantages configurés dès le premier jour, pour qu'une mauvaise version se détecte depuis le tableau de bord plutôt que depuis un avis d'utilisateur.
Nous choisissons parmi celles-ci selon les besoins du projet et selon ce que votre équipe saura maintenir après la livraison — et non selon nos préférences. Lorsqu'une pile technique est déjà en place et saine, nous travaillons avec elle.
Techniciens, chauffeurs et inspecteurs qui saisissent leur travail loin d'un bureau. Les besoins sont généralement la saisie hors ligne, l'appareil photo, la localisation et un modèle de synchronisation qui survit à une perte de signal en plein formulaire.
Réservation, commande et gestion de compte, lorsque l'interaction est assez fréquente pour justifier une installation. Quand elle ne l'est pas, nous recommandons plutôt un site responsive bien construit, et nous vous épargnons le budget.
Une surface mobile posée sur un système que vous exploitez déjà. Le travail relève souvent davantage de la conception d'API et de l'authentification que de l'interface elle-même.
Outils pour les collaborateurs diffusés par distribution gérée plutôt que par les stores publics, ce qui retire entièrement le cycle de revue de votre chaîne de publication.
Le multiplateforme convient à la grande majorité des applications métier et coûte nettement moins cher à construire et à maintenir, puisqu'une seule équipe entretient une seule base de code. Le natif devient préférable quand l'application dépend fortement de matériel spécifique à une plateforme, exige une animation soutenue à haute fréquence d'images, ou constitue elle-même le produit et doit se comporter exactement comme la plateforme. Nous vous donnerons une recommandation franche pour votre cas plutôt qu'un choix par défaut.
Souvent non. Si les gens s'en servent quelques fois par an, l'installation est un obstacle et un site responsive les servira mieux pour une fraction du coût. Une application se justifie par la fréquence d'usage, par de véritables capacités de l'appareil — appareil photo, localisation, hors ligne, synchronisation en arrière-plan — ou par le besoin d'être présent sur l'écran d'accueil d'un téléphone.
Une première version ciblée demande généralement 8 à 14 semaines, publication sur les stores comprise. Les applications comportant un mode hors ligne important, des paiements ou des intégrations complexes prennent plus longtemps. La revue des stores ajoute des jours plutôt que des semaines une fois les comptes correctement configurés, même si une première soumission peut être plus longue.
Concrètement, deux à quatre publications par an : mises à jour des systèmes d'exploitation, montées de version des dépendances et des SDK, et changements périodiques des exigences des stores. C'est continu et non optionnel — une application non maintenue finit par ne plus compiler. Nous préférons que vous le budgétiez dès le départ.
Oui, et nous le recommandons. Votre entreprise doit détenir les comptes App Store et Play Console ainsi que les certificats de signature. Nous les mettons en place avec vous si vous ne les avez pas encore.
Envoyez-nous le problème et les contraintes que vous connaissez déjà. Nous reviendrons vers vous avec ce que nous pensons qu'il exige, une approche et un ordre de grandeur réaliste — ou pour vous dire que ce n'est pas un travail pour lequel nous sommes les bons.
Nous concevons et construisons la partie du produit que personne ne voit jusqu'à ce qu'elle casse : les API, les modèles de données, l'authentification et les intégrations qui tiennent une entreprise ensemble.
Nous concevons des interfaces à partir de preuves : ce que les gens cherchent à faire, là où ils échouent aujourd'hui, et ce que la réalisation peut raisonnablement porter.
Quand un logiciel du commerce impose des contournements à vos équipes, la facture se paie chaque jour en travail manuel. Nous construisons des systèmes qui épousent le processus que vous avez déjà.
