Développement d'applications mobiles
iOS, Android et multiplateforme — conçues pour les appareils et connexions de vos utilisateurs réels, pas pour le smartphone haut de gamme posé sur le bureau du développeur.
Une application mobile n'est qu'en partie ce qui se trouve sur le téléphone. L'application visible représente généralement un tiers du travail ; le reste, c'est le back-end avec lequel elle dialogue, la logique de synchronisation qui encaisse une perte de connexion, l'authentification, l'infrastructure de notifications et le processus de publication qui fait passer les mises à jour dans deux stores.
C'est pourquoi les applications chiffrées uniquement à l'écran dérapent. Un écran de connexion, c'est un après-midi ; une connexion qui gère le renouvellement des jetons, les changements d'appareil, le déverrouillage biométrique et le mot de passe oublié sur deux plateformes, c'est quinze jours.
Nous construisons pour les conditions réelles — appareils milieu de gamme, connectivité intermittente et utilisateurs qui n'attendront pas un premier chargement lent. La tolérance au hors ligne est conçue dès le départ, pas ajoutée après la première plainte.
La première vraie décision, et celle qui pèse le plus sur le coût. Voici comment nous choisissons.
| Native (Swift / Kotlin) | Multiplateforme (React Native / Flutter) | Application web progressive | |
|---|---|---|---|
| Idéal quand | Forte intégration à l'appareil, ou la performance est le produit | Fonctionnalités standard, deux plateformes, un budget | La portée compte plus que les fonctions de l'appareil |
| Coût relatif | Le plus élevé — deux bases de code | Modéré — une base de code, un peu de travail par plateforme | Le plus faible — c'est un site web |
| Accès à l'appareil | Tout, immédiatement | Presque tout ; les nouveautés de l'OS peuvent arriver plus tard | Limité — pas d'accès matériel profond |
| Présence dans les stores | Oui | Oui | Non (installable, mais non référencée) |
| Vitesse de mise à jour | Revue du store à chaque fois | Revue du store, plus mises à jour à distance pour le JS | Immédiate — vous maîtrisez le déploiement |
| Cas typiques | Réalité augmentée, traitement vidéo, synchronisation hors ligne complexe | La plupart des applications métier et grand public | Outils internes, usage peu fréquent |
Nous recommandons le multiplateforme pour la plupart des applications métier et le disons clairement — développer deux fois la même application se justifie rarement par le résultat.
Des applications que l'on utilise pour faire un travail, plus souvent que des applications que l'on feuillette.
Applications terrain et opérationnelles
Pour le personnel qui travaille loin d'un bureau — listes de tâches, saisie, signatures, photos, lecture de codes-barres — conçues pour continuer à fonctionner quand le réseau disparaît.
Applications clients
Comptes, commandes, réservations, suivi et support là où les clients regardent déjà. Généralement le versant mobile d'un portail que nous avons aussi construit.
Applications e-commerce
Navigation, panier et paiement avec les moyens attendus sur votre marché, plus des notifications liées à de vrais événements de commande plutôt qu'à des envois marketing.
Back-end & API
Le côté serveur de l'application — modèle de données, API, authentification, notifications et interface d'administration utilisée par votre équipe. Construit avec l'application, par la même équipe.
Modernisation d'applications
Sauver des applications bloquées sur des frameworks plus maintenus ou abandonnées par une équipe précédente, y compris récupérer les fiches des stores et les clés de signature.
Publication & gestion des stores
Fiches des stores, soumissions en revue, déploiements progressifs, suivi des plantages et travail continu de mise à niveau des OS qui empêche une application de casser en silence.
Chacun de ces points est chiffré explicitement dans nos estimations, car les laisser implicites, c'est ainsi que les projets d'applications doublent.
Hors ligne et synchronisation
Décider ce qui fonctionne sans connexion, ce qui est mis en file d'attente, et ce qui se passe quand deux appareils ont modifié le même enregistrement. C'est le domaine le plus sous-estimé du développement d'applications.
Authentification sur plusieurs appareils
Renouvellement des jetons, déverrouillage biométrique, expiration de session, changement d'appareil et récupération de compte. Simple dans le cas nominal, et une longue traîne de cas ailleurs.
Notifications push
Deux plateformes, deux services d'envoi, des parcours d'autorisation, des liens profonds vers le bon écran, et la différence entre une alerte utile et une désinstallation.
Revue des stores et publications
Apple et Google rejettent tous deux des versions pour des raisons qui ne sont pas dans votre code. Nous prévoyons les cycles de revue dans le planning au lieu de traiter un rejet comme une surprise.
Cinq étapes. Vous voyez l'application sur un vrai appareil dès la troisième.
- 01
Cadrage
Ce que l'application doit faire, qui l'utilise dans quelles conditions et quelles plateformes doivent réellement être couvertes. Nous recommandons une approche et dimensionnons le travail.
- 02
Design
Les parcours d'abord, puis les écrans, en suivant les conventions de chaque plateforme plutôt qu'en imposant un seul design aux deux. Un prototype cliquable avant le code.
- 03
Développement
Des itérations de deux semaines avec une version de test sur votre appareil à la fin de chacune. Back-end et application avancent ensemble, pour que l'intégration ne soit pas une phase finale.
- 04
Bêta
TestFlight et tests internes Play avec de vrais utilisateurs sur de vrais appareils. Rapports de plantage et analytics branchés avant le lancement, pas après.
- 05
Lancement & maintenance
Soumission aux stores, déploiement progressif, puis le travail continu : mises à jour des OS, abandons de SDK et évolutions issues de l'usage réel.
Une application demande une maintenance qu'un site web ne demande pas — les deux plateformes publient chaque année des changements d'OS qui cassent des choses. Nous serons explicites sur ce coût récurrent avant que vous ne commenciez.
Pour la plupart des applications métier et grand public, le multiplateforme avec React Native ou Flutter vous donne les deux plateformes pour à peu près le coût d'une seule, sans différence perceptible pour les utilisateurs. Optez pour le natif quand l'application dépend d'une forte intégration à l'appareil, d'une haute performance soutenue ou des fonctions d'une plateforme dès leur sortie. Nous en recommanderons un lors du cadrage et expliquerons le compromis plutôt que de choisir par défaut le plus facturable.
Démarrer un projet
Qui l'utilise, où et sur quoi. Nous reviendrons avec une approche, un ordre de grandeur de coût et les parties qui coûteront cher.
- Réponse sous un jour ouvré
- Séance de cadrage gratuite, sans engagement
- Le document de cadrage vous appartient dans tous les cas