Aller au contenu principal
NAKO
France · application mobile

Développement d'application mobile

De l'idée au store, pour des entreprises qui ont besoin d'une application sans monter un service pour la faire.

Ce qu'il faut décider au début

La plupart des projets n'ont pas besoin de deux applications natives. Ce qui décide, c'est l'usage réel : si l'appareil photo, les notifications ou le fonctionnement hors ligne comptent, la voie native s'impose ; sinon une seule base de code couvre les deux systèmes pour un coût différent. Deux points se tranchent au début et non à la fin. Le traitement des données d'abord : information dans l'application et sur la fiche du store, mesure seulement après consentement, données de préférence dans l'Union. Ensuite l'accessibilité : le référentiel français, le RGAA, s'impose au secteur public et à ses délégataires, et la réglementation européenne étend l'exigence à de nombreux services destinés aux particuliers. Ajoutée après coup, l'accessibilité coûte plusieurs fois son prix.

Ce que nous mettons au plan

Natif ou base unique

Appareil photo, notifications ou hors ligne poussent au natif ; sinon une base unique couvre les deux systèmes

Données

Information dans l'application et sur la fiche, mesure après consentement, données de préférence dans l'Union

Accessibilité

RGAA pour le secteur public et ses délégataires ; l'exigence s'étend aux services aux particuliers

Fiche de store

Description et visuels en français — une fiche en anglais coûte des installations

Paiements

Dans l'application via Apple et Google ; en dehors, carte bancaire, virement et PayPal

Livraison

Code source et comptes de store à votre nom, même si nous ne continuons pas ensemble

Ce que cela comprend

Développement

Application iOS et Android, plus le site qui la présente.

Marketing

Visibilité sur le store et campagnes pour les premières installations.

Automatisation

Raccordement au CRM, à la gestion commerciale ou à la réservation.

Analytics

Données d'usage et abandons, mesurés seulement après consentement.

Audit

Revue d'applications existantes : accessibilité, données, performances.

Comment nous travaillons

  • Nous disons quand une application native n'est pas nécessaire, même si c'est la mission la plus grosse
  • Code source et comptes de store à votre nom dès le premier jour
  • Accessibilité prévue dès la conception, pas ajoutée après coup
  • Des étapes avec recette — vous ne payez pas à l'aveugle jusqu'à la fin
  • Maintenance facultative et résiliable au mois

Questions fréquentes

Faut-il vraiment deux applications natives ?

Souvent non. Si l'appareil photo, les notifications ou le fonctionnement hors ligne ne sont pas en jeu, une seule base de code couvre les deux systèmes pour un coût différent. Cela se décide sur l'usage, pas sur la mode.

Notre application doit-elle être accessible ?

Le RGAA s'impose au secteur public et à ses délégataires, et la réglementation européenne étend l'exigence à de nombreux services destinés aux particuliers. Nous vérifions votre cas avant de commencer : ajoutée après coup, l'accessibilité coûte plusieurs fois son prix.

À qui appartient le code source ?

À vous, dès le premier jour : le code est dans votre dépôt et les comptes de store sont au nom de votre entreprise. Changer de prestataire doit être une décision, pas un rapport de force.

Combien de temps faut-il ?

Une première version utilisable prend en général trois à quatre mois selon le périmètre. Nous avançons par étapes avec recette, pour que vous voyiez quelque chose après chaque pas et puissiez changer de direction tant que c'est peu coûteux.

Parler de l'application

Décrivez brièvement ce que l'application doit faire : nous répondons avec une évaluation du périmètre, des délais et des obligations.