Votre application mobile, de l’idée validée aux stores. Pour les équipes de Paris et d’Île-de-France.

Notre équipe est à Strasbourg et nous ne prétendons pas le contraire. Le suivi repose sur trois éléments : un cadrage écrit que vous validez, une version de test installée sur vos téléphones à chaque itération, et des démonstrations en vidéo, enregistrées ou en direct, avec un seul interlocuteur qui connaît le projet. Vous échangez directement avec les personnes seniors qui construisent et publient l’application. Une session en personne, au lancement par exemple, est à organiser si le projet le demande.

Pas forcément. Pour beaucoup de produits, une base de code partagée permet de sortir sur les deux plateformes avec une seule équipe et un seul rythme de versions. Le natif se justifie quand l’application dépend fortement des fonctions de l’appareil ou de performances particulières. Un produit peut aussi démarrer sur une seule plateforme, selon ses utilisateurs. Nous documentons ce choix au cadrage, avec ses conséquences sur la maintenance.

Nous ne publions pas de prix, parce que le budget dépend surtout de ce qui entoure l’application : back-office, comptes, paiements, intégrations, nombre de plateformes et niveau de finition attendu. Notre approche consiste à délimiter une première version qui permet d’apprendre de vrais utilisateurs, à la chiffrer par écrit, puis à prévoir séparément la maintenance et les évolutions. Un échange de 30 minutes permet d’en parler sur votre cas.

Cela dépend du périmètre et des intégrations ; nous ne donnons pas de délai avant le cadrage. Ce que nous fixons, c’est un découpage en itérations courtes, chacune terminée par une version de test, et un calendrier écrit que vous pouvez suivre. Certaines étapes ne dépendent pas de nous : création des comptes développeur, vérifications d’Apple et de Google, revue avant publication.

Cela arrive et personne ne peut garantir l’approbation. Nous réduisons le risque en lisant les règles des stores dès le cadrage : contenus, données personnelles, connexion, achats intégrés, informations de confidentialité. À la soumission, nous préparons les fiches, un compte de démonstration pour les équipes de revue et les explications utiles. En cas de refus, nous analysons le motif, corrigeons ou répondons, puis soumettons à nouveau.

À vous. Nous recommandons que les comptes Apple Developer et Google Play Console soient ouverts au nom de votre entreprise, avec un accès délégué à notre équipe. Le code source, les clés de signature, les noms de domaine et les services tiers sont rattachés à votre organisation et listés dans la documentation de transmission. Vous pouvez ainsi changer de prestataire ou internaliser le développement sans perdre l’application publiée ni ses utilisateurs.

Oui, mais les règles changent selon ce que vous vendez. Les stores encadrent la vente de contenus et de fonctions numériques utilisés dans l’application, avec leurs propres systèmes d’achat intégré et des exceptions qui évoluent. Un bien physique, une réservation ou une prestation réalisée hors de l’application passe en général par un prestataire de paiement classique. Nous vérifions ce point au cadrage, car il touche le modèle économique et peut conditionner la publication.

Une application vit au rythme des stores et des systèmes : nouvelles versions d’iOS et d’Android, exigences de mise à jour, retours des utilisateurs. Nous proposons une maintenance définie par écrit : correctifs, mises à jour techniques, publication des nouvelles versions et évolutions planifiées. Chaque mise à jour passe par une version de test, comme pendant le projet, pour que vous la validiez avant sa sortie.

Oui. Nous commençons par un audit : état du code, dépendances, environnements, back-office, comptes stores et accès. Le premier objectif est souvent de récupérer ce qui doit être à votre nom et de reconstruire la chaîne de publication, pour pouvoir sortir une mise à jour en confiance. Ensuite seulement, nous décidons avec vous ce qui se corrige et ce qui se réécrit.