Des applications mobiles au service de votre activité. Conçues et suivies depuis Strasbourg.

Oui. Dans la plupart des applications métier, une base de code partagée couvre les deux plateformes et réduit le travail de maintenance. Lorsqu’une fonction exige un accès fin à l’appareil, une performance particulière ou une intégration propre à iOS ou à Android, nous développons tout ou partie en natif. Le choix se fait au cadrage, à partir de vos fonctions et de vos appareils, et il est écrit dans la proposition avec ses conséquences sur la maintenance.

Le budget dépend du nombre de parcours, des plateformes visées, du besoin hors connexion, des intégrations avec vos outils et de l’étendue du back-office. Plutôt qu’un prix au forfait annoncé à l’aveugle, nous proposons un premier échange, puis un cadrage qui aboutit à un périmètre chiffré, découpé en versions. Une première version volontairement resserrée permet souvent de vérifier l’usage avant d’engager la suite.

Cela dépend du périmètre, de la disponibilité des personnes qui valident et de l’état des systèmes à connecter. Nous préférons fixer un calendrier après le cadrage plutôt que de l’annoncer avant. Il faut aussi compter les délais de revue de l’App Store et de Google Play, qui ne dépendent pas de nous. Le découpage en versions vous permet de mettre une première version entre les mains d’utilisateurs sans attendre que tout soit construit.

Oui. Nous préparons les fiches, les captures, les déclarations de confidentialité et les comptes de test demandés par les équipes de revue, puis nous soumettons et suivons chaque version. Si Apple ou Google refusent une soumission, nous analysons le motif, corrigeons l’application ou sa fiche et resoumettons. Nous publions nos propres applications et celles de nos clients sur les deux stores, comme LandLording, mais personne ne peut garantir une acceptation : la décision reste chez Apple et Google.

Chaque année, Apple et Google publient de nouvelles versions de leurs systèmes et relèvent leurs exigences pour les mises à jour d’applications. Une application qui n’est plus entretenue finit par ne plus pouvoir être mise à jour, voire par mal fonctionner. Nous proposons un accord de maintenance : suivi des versions d’OS, mise à jour des dépendances, corrections et nouvelles soumissions. Son contenu est écrit à l’avance, pour que chacun sache qui fait quoi.

Oui, à condition de le décider dès la conception. Pour une application terrain, nous définissons quelles données sont disponibles sur le téléphone, ce qui peut être saisi sans connexion et comment les modifications sont synchronisées au retour du réseau, y compris lorsque deux personnes ont modifié le même élément. C’est un choix d’architecture qui touche aussi le back-office, et il est bien plus simple à prévoir au départ qu’à ajouter ensuite.

À votre organisation. Nous recommandons que les comptes Apple Developer et Google Play Console soient ouverts à son nom, et que nous y soyons invités avec les droits nécessaires. Le code source, les accès au back-office, à l’hébergement et la documentation vous sont remis selon le contrat. Si un jour vous changez de prestataire, l’application, ses fiches et ses utilisateurs restent chez vous.

Oui, et c’est souvent là que se trouve l’essentiel du travail. Une application métier a besoin d’une API, d’une base de données, d’une gestion des comptes et des droits, d’un outil web pour administrer contenus et utilisateurs, et parfois de connexions à votre ERP, votre CRM ou votre outil de planification. Nous concevons l’ensemble, avec un hébergement dans l’Union européenne lorsque vos données l’exigent.