Faut-il développer deux fois, pour iPhone et pour Android ?

Pas nécessairement. Les technologies multiplateformes permettent d’écrire l’essentiel une seule fois, avec un accès complet au matériel. Le développement natif séparé se justifie quand l’exigence de fluidité ou l’usage du matériel le demandent.

Faut-il obligatoirement passer par l’App Store et Google Play ?

Non. Pour une application réservée à vos équipes, il existe des modes de distribution interne qui évitent la relecture et les délais. Pour une application destinée au public, le passage par les magasins est obligatoire.

Combien de temps avant la première mise en ligne ?

Cela dépend du nombre de parcours et de l’étendue du fonctionnement hors connexion. Retenez surtout un élément que presque tout le monde oublie dans son planning : à la durée de développement s’ajoute le délai de relecture d’Apple et de Google, et la possibilité qu’une première version soit refusée.

L’application marchera-t-elle sans réseau ?

Si votre métier l’exige, oui. C’est prévu dès la conception, avec des règles écrites pour savoir quoi faire quand deux personnes ont modifié la même chose hors connexion. Ajouté après coup, le hors connexion oblige à reprendre une grande partie de l’application.

Que prévoit la maintenance après lancement ?

Elle couvre le suivi des erreurs, les évolutions des systèmes mobiles, la sécurité, la compatibilité des API et la planification des versions. iOS et Android sortent une version majeure par an, et elles cassent parfois des fonctions.

Terrain et parcours clients

Applications mobiles d’entreprise

Une application qu’on utilise debout, dehors, avec une main, parfois sans réseau. Nous concevons les applications mobiles métier de vos équipes sur le terrain, de vos partenaires ou de vos clients, celles qui doivent rester fiables là où le réseau ne l’est pas.

Du cadrage à la mise en ligne sur les magasins d’applications, depuis Tarbes, Marrakech et Dover.

Nous contacter

Quelle technologie

Une application mobile, oui, mais laquelle ?

C’est la première question, et elle a des conséquences sur le budget, le délai et ce que vous pourrez faire ensuite. Voici les options réelles.

Le développement natif

Une application écrite séparément pour iOS et pour Android. La meilleure fluidité et l’accès complet au matériel. C’est aussi ce qui coûte le plus cher, puisqu’il y a deux applications à écrire, puis à entretenir.

Le multiplateforme

React Native ou Flutter : un seul code pour les deux systèmes, avec accès au matériel. C’est le compromis retenu par une grande partie des applications métier.

L’application web installable

Un site conçu pour le mobile, qu’on ajoute à l’écran d’accueil. Pas de magasin, mise à jour immédiate, budget plus bas. En contrepartie, l’accès au matériel est limité et le hors connexion reste sommaire.

Nous comparons les besoins d’expérience, les capacités de l’appareil, le fonctionnement hors connexion, la distribution et le coût de maintenance sur la durée. Pas une préférence de technologie.

Hors connexion

Travailler sans réseau, et ce qui se passe au retour

Faire fonctionner une application hors connexion est la partie facile, puisqu’il suffit de garder les données sur l’appareil. La partie difficile arrive au retour du réseau. Deux personnes ont modifié la même fiche pendant qu’elles étaient déconnectées. Laquelle gagne ?

Il n’y a pas de bonne réponse générale, seulement une bonne réponse pour votre métier. Sur un relevé d’intervention, la dernière saisie l’emporte probablement. Sur un stock, certainement pas, car il faut additionner les mouvements. Sur un devis signé, il faut refuser la modification et prévenir.

Les données, les règles de synchronisation, les conflits et les limites du mode hors connexion se définissent donc dès la conception. Une synchronisation silencieuse qui perd une saisie détruit la confiance en une semaine.

Sécurité

Le téléphone se perd

Une application mobile est une porte d’entrée vers votre système, et elle voyage dans une poche. Nous limitons donc ce qui sort de vos serveurs et nous contrôlons les autorisations côté service, jamais seulement dans l’application, qui peut être inspectée.

Les échanges avec vos services prévoient explicitement les cas réels : plusieurs versions de l’application installées en même temps, réseau qui coupe au milieu d’un envoi, reprise après erreur. Un téléphone qui perd le réseau pendant une transmission est la situation normale, pas l’exception.

Le terrain

Le vrai terrain, pas le bureau

Une application essayée uniquement sur un téléphone récent, en wifi, au bureau, donne une fausse impression. Les parcours sont donc étudiés sur des appareils et des réseaux représentatifs. Les écrans prioritaires, le poids des échanges, la consommation de ressources et les états dégradés sont suivis.

Nous soignons aussi les états dégradés, c’est-à-dire ce que l’application affiche quand cela ne marche pas. Un message clair au bon moment évite une erreur de saisie, et un appel à votre support.

La mise en ligne

Ce que personne ne dit sur les magasins

Apple et Google relisent chaque version avant de la publier. Cela prend en général de quelques heures à quelques jours, et une version peut être refusée pour un texte d’autorisation mal rédigé, une fonction jugée non conforme, ou une règle qui a changé entre-temps.

Une correction urgente n’est pas en ligne dans l’heure.
Il faut des comptes développeur à votre nom, chez Apple et chez Google, payants chaque année.
Vos utilisateurs ne mettent pas tous à jour en même temps : plusieurs versions coexistent, et vos services doivent le supporter.

La préparation des versions, les contrôles, les éléments de diffusion et le suivi après publication peuvent être intégrés à la mission.

De l’idée au magasin

Découverte

Qui s’en sert, où, sur quels appareils, avec quel réseau, et ce qui doit absolument marcher hors connexion.

Prototypage

Les parcours principaux sont maquettés et essayés sur un téléphone, pas sur un écran d’ordinateur. Les risques techniques sont levés là.

Réalisation

Par incréments que vous installez et utilisez réellement, sur de vrais appareils.

Mise en ligne

Dépôt sur les magasins, suivi des erreurs remontées, mesures d’usage, maintenance.

L’investissement

Ce qui fait le budget

Le nombre de systèmes visés, et l’approche retenue.
Le nombre et la complexité des parcours.
L’usage du matériel : photo, scan, localisation en continu, Bluetooth.
L’étendue du fonctionnement hors connexion, le poste le plus sous-estimé.
Les connexions avec vos systèmes existants.
Vos exigences de sécurité.
La stratégie de diffusion, magasins publics ou distribution interne.

Le cadrage sépare ce qui doit être dans la première version, les capacités reportables, et les besoins durables de maintenance.

Des applications livrées

ATMO Grand Est

Des capteurs nomades relèvent les données, le mobile les collecte et les transmet, puis elles sont centralisées et traitées. Android SDK, Ruby on Rails, traitement Python. Projet mené pour la Région Grand Est, dans le cadre d’INTERREG.

LDLC, parcs éoliens

Une application SaaS pour des équipes qui interviennent sur site. React et React Native, assistant IA, algorithmes Python sur un back-end Node.js.

« Toujours à l’écoute, et prêts à rendre service. C’est rare. »

Questions

Faut-il développer deux fois, pour iPhone et pour Android ?: Pas nécessairement. Les technologies multiplateformes permettent d’écrire l’essentiel une seule fois, avec un accès complet au matériel. Le développement natif séparé se justifie quand l’exigence de fluidité ou l’usage du matériel le demandent.
Faut-il obligatoirement passer par l’App Store et Google Play ?: Non. Pour une application réservée à vos équipes, il existe des modes de distribution interne qui évitent la relecture et les délais. Pour une application destinée au public, le passage par les magasins est obligatoire.
Combien de temps avant la première mise en ligne ?: Cela dépend du nombre de parcours et de l’étendue du fonctionnement hors connexion. Retenez surtout un élément que presque tout le monde oublie dans son planning : à la durée de développement s’ajoute le délai de relecture d’Apple et de Google, et la possibilité qu’une première version soit refusée.
L’application marchera-t-elle sans réseau ?: Si votre métier l’exige, oui. C’est prévu dès la conception, avec des règles écrites pour savoir quoi faire quand deux personnes ont modifié la même chose hors connexion. Ajouté après coup, le hors connexion oblige à reprendre une grande partie de l’application.
Que prévoit la maintenance après lancement ?: Elle couvre le suivi des erreurs, les évolutions des systèmes mobiles, la sécurité, la compatibilité des API et la planification des versions. iOS et Android sortent une version majeure par an, et elles cassent parfois des fonctions.

Évaluons les contraintes réelles de votre produit mobile

Partagez les usages, les environnements, les intégrations et les objectifs de diffusion. Nous préparerons une discussion centrée sur les choix structurants.