Service:Service

Applications mobiles

Apps natives ou cross-platform (.NET MAUI, React Native) pensées offline-first et déployées sur les stores.

Ce que nous livrons

iOS & Android
Mode offline / sync
Publication App Store & Play Store
Push notifications, deep linking

iOSAndroidMAUI

Discuter de ce besoin Voir des réalisations

Le mobile pardonne moins que le web. Une application lente sur un ordinateur agace ; sur un téléphone, elle est désinstallée. Un bug sur le web se corrige en poussant une version ; sur les stores, il faut passer une revue, attendre, et espérer que les utilisateurs mettent à jour. Cette asymétrie change la façon dont il faut concevoir, tester et livrer.

Nous développons en .NET MAUI et en React Native, et parfois en natif quand le projet l'exige. Le cross-platform n'est pas un compromis honteux : sur une application de gestion, de saisie ou de consultation, il divise le coût par deux sans que l'utilisateur voie la différence. Il devient un mauvais choix dès qu'on touche à la caméra en temps réel, aux animations complexes ou aux capteurs de bas niveau. Nous vous dirons dans quelle catégorie vous êtes après avoir vu vos maquettes, pas avant.

Comment nous travaillons

Offline-first, et ce que ça implique

Concevoir hors ligne d'abord ne veut pas dire ajouter un cache à la fin. Cela veut dire que l'application écrit d'abord en local, puis synchronise, et que l'interface ne bloque jamais en attendant le réseau. Sur le terrain, cette différence est celle entre un technicien qui saisit son intervention dans un sous-sol et un technicien qui la ressaisit le soir de mémoire.

La partie difficile n'est pas le stockage local, elle est dans les conflits. Deux personnes modifient la même fiche hors ligne : qui gagne ? Nous traitons cette question au cadrage, avec vos utilisateurs métier, parce que la réponse dépend de votre activité et pas de la technique. Sur un inventaire, la dernière écriture peut l'emporter. Sur un dossier médical, sûrement pas. C'est le genre de décision qu'on ne peut pas rattraper après la mise en production.

Publier sur les stores, sans mauvaise surprise

Le premier passage en revue Apple prend entre deux jours et deux semaines, et le premier refus est la norme plutôt que l'exception. Les motifs les plus fréquents que nous rencontrons ne sont pas techniques : une politique de confidentialité absente, un compte de test qui ne fonctionne pas, une fonctionnalité que le validateur n'arrive pas à atteindre. Nous préparons ces éléments avant de soumettre, ce qui transforme trois allers-retours en un seul.

Nous mettons aussi en place la distribution interne dès le début, TestFlight côté iOS et les pistes fermées côté Play. Faire tester une application par vingt collègues pendant trois semaines avant la sortie publique coûte quelques heures de configuration, et évite la version 1.0.1 publiée en urgence le lendemain du lancement.

Notifications et liens profonds

Une notification push est le seul canal qui permet de reprendre contact avec un utilisateur qui a fermé l'application. C'est aussi le plus rapide pour se faire désinstaller. Nous les traitons comme une fonctionnalité produit, avec des règles de fréquence et un réglage par catégorie, et pas comme un tuyau technique ouvert à tous les vents.

Les liens profonds sont le pendant discret et souvent oublié : ils font qu'un lien reçu par courriel ouvre la bonne fiche dans l'application et pas la page d'accueil. Sans eux, chaque notification, chaque partage et chaque campagne renvoie l'utilisateur au point de départ, et le taux d'abandon en dit long.

Ce qui amène ici

Vos équipes de terrain travaillent dans des zones sans réseau fiable.
Vous avez une application web que les utilisateurs consultent à 70 % depuis un téléphone.
Une première version a été sous-traitée et vous n'avez ni les comptes des stores ni le code de signature.
Vous devez envoyer des notifications ciblées et vous n'avez aucun moyen de mesurer ce qu'elles rapportent.

Quand ce n'est pas la bonne prestation

Si votre application ne fait que consulter des informations en ligne, sans capteur, sans hors-ligne et sans notification, un site web bien conçu fera le même travail. Il n'y aura pas d'installation à demander, pas de revue de store, pas de deux versions à maintenir. La question à trancher n'est pas technique : elle est de savoir si vous avez besoin d'une icône sur l'écran d'accueil de vos utilisateurs.

Nous le disons avant de commencer, pas après.

Qualité mesurée

Tests automatisés écrits pendant le développement, pas après. Revue de code obligatoire avant toute fusion, y compris sur les correctifs d'une ligne. Analyse statique branchée sur la CI : si la couverture baisse ou qu'une vulnérabilité connue apparaît, la chaîne s'arrête et personne ne passe outre.

Livraison continue

Un environnement de recette déployé à chaque fusion, une démo à la fin de chaque itération, et un tableau d'avancement que vous consultez quand vous voulez sans avoir à le demander. Les mauvaises nouvelles arrivent tôt, quand il reste du temps pour décider quoi faire.

Transfert de savoir

Nous partons du principe que vous reprendrez la main. Les décisions d'architecture sont écrites et datées, la documentation vit dans le dépôt à côté du code, et vos développeurs travaillent en binôme avec les nôtres s'ils le souhaitent. À la fin, le code, les accès et l'historique vous appartiennent.

Aller plus loin:Service[3]

Un projet en tête ? Donnons-lui vie.

Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.

Discuter de ce besoin Voir les réalisations