Développement d'applications mobiles sur mesure : des outils pensés pour vos usages réels.
Votre activité continue en mouvement. Vos outils aussi.
Applications iOS et Android pour vos équipes terrain, vos commerciaux ou vos clients, reliées à votre logiciel métier : ce qui est saisi sur le téléphone arrive au bon endroit.
Schéma : sur le téléphone du technicien, le dossier I-2417 contient un compte rendu rédigé, trois photos, une signature recueillie à 14:28 et le statut Terminée. Chaque champ est envoyé au serveur, qui contrôle les champs, stocke les pièces et tient l'historique. Au bureau, le même dossier affiche le compte rendu reçu, les trois photos, la signature horodatée et le statut À valider, en attente d'une validation humaine.
Les situations où une application mobile simplifie le quotidien.
Une application se justifie quand le travail se fait loin d'un bureau, ou quand vos clients reviennent souvent. Pour un usage ponctuel, un site bien conçu suffit souvent.
Équipes terrain
Vos équipes saisissent sur place ce qu'elles retapent ensuite au bureau.
Interventions, livraisons
Une intervention ou une livraison doit laisser une trace : photo, document, signature.
Commerciaux
Vos commerciaux préparent devis et commandes chez le client, avec un catalogue et des conditions à jour.
Clients
Vos clients réservent, demandent ou suivent un service régulièrement, depuis leur téléphone.
Services
Une information doit arriver au bon moment : rendez-vous confirmé, commande prête, demande traitée.
Tous
Le réseau est incertain : sous-sol, chantier, route, zone rurale.
Quand ce n'est pas nécessaire
Un usage ponctuel, aucune fonction propre au téléphone, aucun besoin hors connexion : une application web adaptée au mobile suffit, sans installation ni publication sur les stores. Nous vous le disons dès le cadrage.
Pour vos équipes ou pour vos clients : deux usages, deux exigences.
Une application interne et une application publique ne se conçoivent pas de la même façon : ni les mêmes utilisateurs, ni la même distribution, ni les mêmes attentes.
Pour vos équipes
outils internes, équipes terrain, commerciaux
- Saisie et consultation de dossiers, de stocks, de plannings.
- Photos, documents et signatures, lorsque le métier l'exige.
- Fonctionnement hors connexion, si les lieux d'intervention le demandent.
- Distribution interne, sur des appareils fournis ou personnels, avec des comptes gérés par l'entreprise.
Exemple réalisé : l'application sur tablette des techniciens de COA Photovoltaïque, de la checklist d'intervention au rapport PDF, avec la signature du client.
Pour vos clients
services, réservations, demandes, suivi
- Parcours de réservation, de commande ou de demande, courts et sans ambiguïté.
- Compte client, historique, documents et notifications utiles.
- Publication sur l'App Store et Google Play, selon leurs règles.
- Accessibilité et mises à jour régulières, pour suivre les versions d'iOS et d'Android.
Exemples réalisés : la demande de vol privé envoyée depuis l'application d'Evolution Jet, puis traitée dans un back-office ; les profils, la compatibilité et la messagerie d'Evlenelim ; le parcours de chaussure sur mesure d'Adapt Shoes, relié au scan 3D des pieds.
Quelle forme d'application ?
Multiplateforme
Quand la choisirUn seul code pour iOS et Android. Le choix le plus courant pour une application métier ou un service client.
Ce qu'il faut savoirNous travaillons notamment avec React Native et Flutter ; l'accès aux fonctions de l'appareil passe par des modules éprouvés.
Native
Quand la choisirUne application par système, quand une fonction de l'appareil ou une exigence particulière le justifie.
Ce qu'il faut savoirDeux bases de code à maintenir : à réserver aux cas où l'écart compte vraiment.
Web mobile
Quand la choisirSans installation ni store, ouverte dans le navigateur du téléphone.
Ce qu'il faut savoirAccès plus limité aux fonctions de l'appareil et au hors connexion.
Le choix se fait au cadrage, selon les fonctions nécessaires, les utilisateurs et la maintenance que vous prévoyez.
Du terrain au bureau : sept gestes sur le téléphone, un dossier prêt à valider.
Scénario fictif : un technicien réalise un contrôle annuel chez un client. Choisissez une étape, coupez le réseau, et voyez ce que l'application garde sur le téléphone, ce qu'elle envoie, ce que le serveur traite et ce qui revient à une personne.
Étape 6 sur 7 · Synchroniser les informations
Étape 6 sur 7 : Synchroniser les informations. Réseau disponible. Bureau : dossier Reçu.
Sur le téléphone
I-2417
Dossier envoyé
Compte renduenvoyé
Photos3 / 3 envoyées
Signatureenvoyée
Accusé du serveurreçu à 14:32
Le téléphone attend l'accusé du serveur avant de vider sa file.
Synchronisé à 14:32
Où sont les données à cette étape
Téléphonestockage local
MissionFiche client
File d'envoien attente de réseau
aucun élément
Serveurcontrôles, stockage, historique
Compte renduPhotos ×3Signature
Bureauconsultation, validation
aucun élément
Le serveur fait foi : le téléphone ne garde que ce dont l'équipe a encore besoin.
Au bureau · back-office
Dossier I-2417Reçu
Compte rendureçu, complet
Photos3 / 3
Signaturehorodatée
Le serveur a contrôlé les champs obligatoires avant d'accepter l'envoi.
Sur le mobileLe téléphone envoie sa file, puis la vide une fois l'accusé reçu.
Côté serveurContrôle des champs, stockage des photos, horodatage, inscription à l'historique.
Une personneAucune action : rien n'est encore validé.
Scénario fictif, données fictives. Les fonctions présentées sont des possibilités, retenues ou non selon votre projet.
Hors connexion : ce que l'application garde, et ce qu'elle rattrape.
Une application peut continuer à fonctionner sans réseau, à condition de l'avoir prévu dès la conception. Quatre questions se règlent alors avec vous.
Le stockage local
Le téléphone ne garde que ce dont l'utilisateur a besoin pour travailler : ses missions, ses fiches, ses brouillons. Pour une durée définie, et effacé quand il n'est plus utile.
La synchronisation différée
Les saisies attendent dans une file sur l'appareil et partent au retour du réseau. Le téléphone ne vide sa file qu'après l'accusé du serveur : une coupure en plein envoi ne fait rien perdre.
Les conflits
Si un même dossier est modifié au bureau et sur le terrain pendant la coupure, une règle choisie à l'avance s'applique : le bureau tranche, la modification la plus récente l'emporte, ou le conflit est signalé à une personne.
Les limites
Certaines actions ont besoin du serveur : un paiement, une disponibilité en temps réel, une vérification. Elles restent indisponibles hors ligne, et l'application le dit clairement.
Un téléphone se perd. Les données qu'il garde se protègent : verrouillage, chiffrement selon le projet, effacement à distance quand les appareils sont gérés par l'entreprise. Voir la protection des accès et des données et notre page sur la protection des données.
Reliée à vos logiciels, sans double saisie.
Une application n'est utile que si ses données arrivent dans vos outils. Nous partons de ce qui existe chez vous, et de ce que vos logiciels permettent.
Votre logiciel métier ou une plateforme
L'application lit le planning, les fiches et les références ; elle renvoie comptes rendus, statuts et pièces. Le back-office peut être votre logiciel actuel ou une plateforme métier développée sur mesure.
Votre CRM ou votre ERP
Clients, catalogue, commandes, stocks : l'application commerciale ou le service client s'appuie sur les données de votre CRM ou ERP, sans base parallèle à tenir à jour.
Les échanges entre logiciels
Quand votre outil propose une interface de programmation, l'application l'utilise ; sinon, nous étudions un export ou un intermédiaire. Le détail relève des API et intégrations.
Les comptes et les accès
Une seule identité pour le mobile et le bureau lorsque c'est possible, avec des droits par rôle. Voir l'authentification et la gestion des accès.
L'intelligence artificielle peut aussi y trouver sa place : un agent IA prépare par exemple un brouillon de compte rendu à partir des notes du technicien, qui le relit avant l'envoi.
De la maquette aux stores, puis dans la durée.
Une application se construit avec ceux qui l'utiliseront, puis se maintient : les systèmes des téléphones changent chaque année.
Cadrage
Utilisateurs, appareils, situations d'usage, données à connecter, contraintes de déploiement : le périmètre est écrit avant de dessiner.
Maquettes testées
Les écrans principaux sont essayés par de vrais utilisateurs, dans leurs conditions : debout, dehors, pressés.
Développement par versions
Chaque version est utilisable et testée ; les fonctions s'ajoutent par ordre de priorité.
Publication
Sur l'App Store et Google Play, selon leurs règles et leur vérification, ou en distribution interne pour une application réservée à vos équipes.
Maintenance
Compatibilité avec les nouvelles versions d'iOS et d'Android, corrections, évolutions, selon l'engagement convenu. Les serveurs relèvent de l'hébergement et de la maintenance.
Possible, ou compris ?
Techniquement envisageable
- Appareil photo et documents
- Signature à l'écran
- Géolocalisation, si l'usage la justifie et avec l'accord de l'utilisateur
- Notifications
- Fonctionnement hors connexion
- Synchronisation avec vos logiciels
Compris dans votre projet
Ce que comprend la prestation est écrit au devis puis au contrat : les fonctions retenues, les appareils et versions pris en charge, la publication, la durée et le niveau de maintenance. Une possibilité technique n'est pas une fonction incluse tant qu'elle n'y figure pas.
Questions fréquentes sur les applications mobiles
Les questions qui reviennent avant de lancer une application.
Faut-il développer une application iOS et une application Android séparément ?
Pas nécessairement. Une application multiplateforme partage un seul code pour les deux systèmes et convient à la plupart des usages métiers comme des services clients. Deux applications natives se justifient quand une fonction de l'appareil ou une exigence particulière l'impose. Nous recommandons la forme au cadrage, selon vos fonctions, vos utilisateurs et la maintenance prévue.
Une application mobile peut-elle fonctionner sans connexion Internet ?
Oui, pour les fonctions conçues pour cela. Les saisies sont enregistrées sur le téléphone et envoyées au retour du réseau. Il faut alors définir ce qui est stocké sur l'appareil, combien de temps, et comment résoudre un conflit si le même dossier change ailleurs. Les actions qui ont besoin du serveur, comme un paiement ou une vérification en temps réel, restent indisponibles hors ligne.
Peut-elle communiquer avec notre logiciel métier ou notre CRM ?
Oui, lorsque ce logiciel le permet : interface de programmation, export, connecteur. Nous étudions d'abord ce que votre outil autorise, puis nous définissons ce que l'application lit et ce qu'elle renvoie. Si aucun accès n'existe, une plateforme métier intermédiaire peut prendre le relais : elle reçoit les données du terrain et les tient à disposition de vos équipes.
Comment se déroule la publication sur les stores ?
Une application publique passe par l'App Store d'Apple et par Google Play, qui appliquent chacun leurs règles et leur vérification avant la mise en ligne, puis à chaque mise à jour. Nous recommandons que les comptes développeur soient au nom de votre entreprise. Une application réservée à vos équipes peut être distribuée en interne, sans publication publique.
Qui possède le code et les données ?
Les données de votre activité restent les vôtres. Les droits sur le code, son dépôt et sa transmission sont fixés par le contrat, et dépendent aussi des composants tiers utilisés, qui gardent leur propre licence. Nous précisons ces points avant le démarrage, pour que vous sachiez ce que vous recevez et ce que vous pouvez en faire.
Comment sont prévues les mises à jour et la maintenance ?
Apple et Google font évoluer leurs systèmes et leurs règles chaque année : une application doit être maintenue pour rester publiée et compatible. Le contenu de la maintenance est défini dans l'engagement convenu : correctifs, compatibilité avec les nouvelles versions, évolutions et délais d'intervention. Ce qui n'y figure pas fait l'objet d'une proposition séparée.
Votre application, dans les mains de ceux qui l'utilisent.
Avant de parler d'écrans, un premier échange pose le cadre. Ces cinq réponses disent quel type d'application convient, et ce qu'elle doit savoir faire.
- Les utilisateursTechniciens, commerciaux, clients : qui ouvre l'application, et combien sont-ils ?
- Les appareilsTéléphones fournis ou personnels, iPhone, Android, tablettes.
- Les situations d'usageSous-sol, chantier, route, comptoir : le réseau et les conditions d'utilisation.
- Les données et les outils à connecterLogiciel métier, CRM, ERP, documents : ce que l'application lit, et ce qu'elle renvoie.
- Les contraintes de déploiementStores publics ou distribution interne, comptes, mises à jour, sécurité des accès.
Vous repartez avec un périmètre écrit : la forme d'application conseillée, ce qu'elle relie et ce qui reste à décider.