Le premier parcours, avant les fonctionnalités
Une application réussit rarement parce qu’elle fait beaucoup de choses. Elle réussit parce qu’un parcours précis fonctionne dès la première version : réserver, trouver une sortie, comparer un prix, consulter les informations de sa commune. Que le projet soit une startup, une place de marché ou un outil de réservation, Devlab pose ce parcours et sa façon de le valider avant d’écrire la première ligne de code.
Concrètement, cela commence par repérer qui utilisera l’application, esquisser les écrans et éprouver les parcours qui comptent vraiment, avant de construire tout le reste. Ce sont les temps « Écouter » puis « Quantifier » de la méthode Devlab : observer vos usages et définir le problème à résoudre, puis fixer les priorités, le budget et les critères de réussite.
Qui utilisera l’application, et dans quelle situation : au bureau, en déplacement, sur un site sans réseau.
Le premier service qu’elle doit rendre à ces utilisateurs, décrit en une phrase.
Les critères qui diront que la première version fonctionne.
Ce qui peut attendre la version suivante.
Téléphones, réseau et îles : les contraintes du fenua
En Polynésie française, le matériel dont disposent vos utilisateurs, la qualité de leur connexion, la langue et le volume de données à transférer pèsent directement sur la conception. Une application pensée pour un réseau parfait déçoit dès qu’on quitte Papeete : sur un chantier, dans une île, dans une cale de bateau, les équipes travaillent souvent sans réseau.
La réponse technique s’appelle offline-first : saisie sur le terrain, stockage local sur le téléphone et synchronisation au retour du réseau. Devlab l’applique dans Kohi, son logiciel d’inventaire hôtelier : les équipes y saisissent constats, quantités et photos sur mobile, même sans réseau.
L’audio guide Taputapuātea, développé pour la Direction de la Culture et du Patrimoine, illustre cette expérience : parcours audio et images accessibles hors connexion, carte interactive et lexique, parcours en français, en tahitien et en anglais, pour suivre la visite du site de Taputapuātea, à Raiatea, même sans réseau mobile.
Toutes les fonctions n’ont pas besoin de marcher sans connexion. Pour chaque projet, on trie ce qui reste stocké dans le téléphone et ce qui doit repasser par le réseau pour se mettre à jour.
Backend, comptes et connexions
Une application mobile n’est que la partie visible. Derrière, un backend relie les comptes, les contenus et les données, avec des outils d’administration pour votre équipe. Vos outils actuels peuvent s’y brancher, mais seulement si leur interface le permet : mieux vaut le vérifier tôt, car cela change le périmètre du projet.
Selon le projet, l’application embarque ce qui sert réellement à vos utilisateurs : une carte, des notifications, l’appareil photo, ou un accès sans réseau. L’application Air Tahiti, par exemple, couvre la réservation de billets et la gestion des dossiers de voyage, l’enregistrement et l’accès à la carte d’embarquement, la consultation des horaires et le suivi du statut des vols. Plus une application dépend de données vivantes, plus le backend et les connexions pèsent dans le projet.
Comptes utilisateurs et rôles : qui se connecte, avec quels droits.
Contenus et données : qui les met à jour, depuis quel outil d’administration.
Services existants (réservation, paiement, gestion commerciale) : à connecter quand leurs API le permettent.
Carte, notifications, appareil photo : à prévoir selon le projet, pas par défaut.
Publication sur l’App Store et Google Play, puis la suite
Publier une application ne se résume pas à appuyer sur un bouton. Devlab teste, soumet aux plateformes, puis s’accorde avec vous sur qui surveille les incidents, comment sortent les mises à jour et quelles évolutions figurent au contrat.
Le compte de publication compte autant que le code. Beedr est publiée sur iOS et Android sous le compte Devlab ; l’application de la Ville de Punaauia est référencée sous Ville de Punaauia sur l’App Store et Mairie de Punaauia sur Google Play, les deux stores citant Devlab comme développeur. Ces choix se posent au départ : à qui appartient le code, qui garde la main sur les comptes de publication, où l’application est hébergée, et qui s’occupe de l’entretenir.
Beedr et Panier Futé figurent à la fois sur l’App Store et sur Google Play ; l’audio guide Taputapuātea et Air Tahiti sont publiés sur Google Play. Toutes les applications n’ont pas besoin des deux plateformes dès le départ : la question se tranche avec les téléphones réellement utilisés par vos utilisateurs.
Ce que ça coûte et comment Devlab chiffre
Le prix d’une application suit ses parcours, ses plateformes, son backend, ses connexions et le suivi voulu après la mise en ligne. Devlab chiffre une fois le cadrage fait, et le devis sépare trois postes : la construction de l’application, ce qui dépend de fournisseurs tiers et la maintenance.
Chez Devlab, 90 % des clients choisissent l’abonnement mensuel : pas de mise de fonds au départ, et la conception, l’hébergement, le suivi et les évolutions sont compris, à partir de 20 000 XPF par mois. Ce montant d’entrée est le même pour tous nos accompagnements ; le prix exact dépend ensuite de l’ampleur du projet, des volumes et de l’objectif visé. L’achat reste possible pour qui veut être propriétaire de sa solution : la mise de départ est nettement plus élevée, et l’entretien est à prévoir ensuite.
Le premier rendez-vous dure 30 minutes et ne coûte rien. Le devis est gratuit lui aussi, il ne vous engage pas, et Devlab répond sous 24 h. Décrivez les utilisateurs de l’application et le premier service qu’elle doit leur rendre : c’est tout ce qu’il faut pour lancer ce cadrage.
Sept applications, sept contextes
Sport, voyages, achats du quotidien, information municipale et agriculture : les sept réalisations mobiles de Devlab en Polynésie française couvrent des usages très différents. Chaque page dédiée détaille notre rôle exact et cite ses sources.
ito ito : activité physique, challenges et récompenses en Polynésie française. Créée et développée par Devlab, qui en a ensuite assuré la maintenance ; la solution a depuis été vendue à SAS Itoito.
Beedr : découvrir des événements et suivre leurs organisateurs à Tahiti, avec deux parcours, participant et organisateur. Publiée sur iOS et Android sous le compte Devlab.
Panier Futé : développée pour la Direction générale des affaires économiques (DGAE) pour comparer les prix relevés dans les magasins de Tahiti, Moorea et Raiatea.
Air Tahiti : réservation, enregistrement, carte d’embarquement, horaires et statut des vols pour les voyageurs entre les îles de Polynésie française, sur Android.
Audio guide Taputapuātea : visite du site de Taputapuātea à Raiatea, hors connexion, en français, tahitien et anglais, pour la Direction de la Culture et du Patrimoine.
Ville de Punaauia : informations de la commune, carte et notifications, sur iOS et Android.
CAPL : application de prévisions de récoltes sur tablette, co-développée avec la cellule technique de la Chambre de l’agriculture et de la pêche lagonaire, présentée dans son bulletin de décembre 2020.