Offre 02
Une application sur les deux stores, tenue dans la durée
Nous concevons, développons et publions des applications iOS et Android. Un même code alimente les deux plateformes, ce qui réduit le travail sans rien retirer à ce que voit l’utilisateur. Et parce qu’une application ne s’arrête pas le jour de sa publication, nous prenons en charge ce qui vient après : correctifs, mises à jour et montées de version des systèmes.
Notre approche
Pourquoi nous procédons ainsi.
Nous développons en React Native avec Expo : une seule base de code, deux applications natives à l’arrivée, et des interfaces qui respectent les conventions de chaque plateforme plutôt que de plaquer les mêmes écrans partout. Le multiplateforme n’est pas un dogme pour autant. Certains usages — traitement vidéo, capteurs, Bluetooth, extensions et widgets système — se codent en natif, et nous le disons au cadrage plutôt qu’au milieu du développement.
Une application n’est pas un site de plus. Elle s’installe, elle occupe de la place, elle demande une mise à jour, elle passe devant un comité de revue avant chaque publication et elle doit survivre à la prochaine version d’iOS comme d’Android. C’est un engagement dans la durée, et c’est la première chose que nous examinons avec vous — parfois pour conclure qu’un site mobile bien fait rendrait le même service.
Ce que ça comprend
Le détail, poste par poste.
iOS et Android depuis un même code
Un socle React Native et Expo, des écrans conformes aux habitudes de chaque plateforme, et du natif là où l’usage l’exige vraiment.
- Une base de code unique pour les deux plateformes, testée sur appareils réels
- Navigation, gestes et composants conformes aux conventions iOS et Android
- Modules natifs quand une fonction le demande, décidés et annoncés au cadrage
- Accessibilité : tailles de texte respectées, libellés lus par les lecteurs d’écran
- Mode clair et mode sombre alignés sur le réglage du téléphone
Publication sur l’App Store et Google Play
La partie que personne n’aime et qui bloque le plus de projets : les comptes, les fiches, les déclarations et la revue.
- Comptes développeur Apple et Google ouverts au nom de votre entreprise
- Certificats, signatures et identifiants d’application configurés proprement
- Fiches rédigées : titre, description, mots-clés, captures d’écran aux bons formats
- Déclarations de confidentialité et classification d’âge remplies honnêtement
- Dépôt, passage en revue, et reprise des retours en cas de refus
Les fonctions courantes
Ce que la plupart des applications demandent, développé une fois et bien : nous partons de votre usage, pas d’un catalogue de fonctions.
- Comptes et authentification, y compris connexion par Apple ou par courriel
- Notifications, avec réglage fin de ce que l’utilisateur accepte de recevoir
- Mode hors connexion et synchronisation au retour du réseau
- Paiement dans l’application, selon les règles des magasins
- Liens profonds : une URL ouvre le bon écran, y compris depuis un courriel
- Partage, favoris, recherche et autres briques attendues d’une application moderne
Le back-end dédié
Une application isolée ne va pas loin. Nous livrons l’API et les données qui la font vivre, avec de quoi les administrer sans nous.
- API dédiée, documentée, versionnée
- Base de données dimensionnée pour votre usage réel
- Tableau d’administration : contenus, comptes, notifications, exports
- Environnement de test séparé de la production
- Sauvegardes et procédure de restauration éprouvée, pas seulement écrite
Après la publication
Le premier jour sur les stores est un début. Les systèmes changent une fois par an, les règles des magasins plus souvent que ça.
- Correctifs et mises à jour publiées au fil des retours d’utilisateurs
- Suivi des plantages, avec la trace qui permet de reproduire le problème
- Montées de version iOS et Android, testées avant que vos utilisateurs les subissent
- Adaptation aux changements de règles des magasins
- Reprise possible par une autre équipe : code lisible, dépôt propre, mise en route documentée
Ce que vous recevez
Vérifiable, à la fin de la mission.
- Une application publiée sur l’App Store et sur Google Play, sous vos comptes développeur
- Le code source complet, avec son historique, sur votre dépôt
- Une API et une base de données dédiées, avec un environnement de test séparé de la production
- Un tableau d’administration pour gérer contenus, comptes et notifications sans nous solliciter
- Les fiches des magasins rédigées : descriptions, captures, déclarations de confidentialité
- Une procédure de mise à jour documentée : comment une nouvelle version part en revue puis en ligne
Déroulé
Comment nous procédons
Cadrage du périmètre
Ce que l’application doit faire dans sa première version, et surtout ce qu’elle ne fera pas encore. Une première version courte se publie, s’essaie avec de vrais utilisateurs et se corrige ; une première version exhaustive ne sort jamais.
Parcours et socle technique
Écran par écran, le parcours est dessiné avant d’être codé. En parallèle, le socle est posé : navigation, comptes, API, environnements. C’est le moment où l’on tranche ce qui reste multiplateforme et ce qui passera en natif.
Développement par versions installables
Vous recevez des versions installables au fil de l’eau, par TestFlight côté Apple et par les canaux de test de Google Play côté Android. Les retours arrivent pendant le développement, quand les corriger coûte encore peu.
Publication et suivi
Dépôt sur les deux magasins, passage en revue, correction des remarques, puis mise en ligne. Ensuite, le suivi : plantages, retours d’utilisateurs, correctifs et montées de version.
Questions fréquentes
Les questions qui reviennent, et nos réponses.
- Faut-il une application ou un site mobile ?
- Souvent, un site mobile bien fait suffit — il se trouve dans les moteurs de recherche, s’ouvre depuis un lien, ne demande aucune installation et ne passe devant aucun comité de revue. L’application se justifie quand l’usage est répété, quand vous avez besoin de notifications qui arrivent vraiment, d’un fonctionnement hors connexion, d’un accès au matériel du téléphone, ou d’une place sur l’écran d’accueil de vos clients. Nous posons la question avant de vendre l’application, et la réponse « un site suffit » est une réponse valide.
- Combien de temps avant la publication ?
- Cela dépend entièrement du périmètre, et nous ne donnons pas de durée avant de l’avoir cadré avec vous — une estimation lancée à l’aveugle n’engage personne et se retourne toujours contre le projet. Une fois le périmètre écrit, nous annonçons un calendrier et nous nous y tenons. Reste la revue des magasins, qui ajoute son propre délai et que personne ne maîtrise, ni vous ni nous.
- Qui possède les comptes des stores ?
- Vous. Les comptes développeur Apple et Google sont ouverts au nom de votre entreprise, avec vos moyens de paiement et vos accès. Nous y sommes invités le temps de la mission, avec les droits nécessaires et rien de plus. Si nous ouvrons les comptes pour vous, ils vous sont transférés — une application publiée sous le compte du prestataire est un problème qui se découvre toujours au pire moment.
- L’application peut-elle réutiliser notre site ou notre système existant ?
- Oui, et c’est souvent le bon choix. Si vous disposez déjà d’une API, d’une base de données ou d’un back-office, nous nous branchons dessus plutôt que de le reconstruire. Nous vérifions au cadrage ce que l’existant peut porter et ce qui doit être ajouté, notamment l’authentification et les notifications, qui manquent presque toujours à un système pensé pour le web seul.
Les autres offres
Un même interlocuteur d’un bout à l’autre.
Parler de votre projet
Un courriel suffit.
Écrivez-nous en quelques lignes : votre activité, ce que vous cherchez à obtenir et l’échéance qui compte pour vous. Nous répondons en français ou en anglais, avec un avis franc — y compris lorsque la réponse honnête est qu’une autre offre, ou aucune, vous servirait mieux.