Développement d'application mobile : 15 questions à poser à une agence avant de signer

Avant de confier le développement d'application mobile à une agence, vérifiez qui construit l'application, à qui appartiennent le code et les comptes des stores, comment l'application est publiée dans les stores, comment les données sont sécurisées et quel suivi est prévu après le lancement. Un portfolio montre ce qu'une équipe a construit. Ces questions montrent comment elle construira la vôtre.

La checklist ci-dessous s'adresse aux fondateurs et aux responsables produit qui comparent des propositions. Elle reprend les questions qui comptent vraiment lors des publications et des transferts de projet, en s'appuyant sur l'étude de cas publique d'ImadDhin et sur les problèmes de publication récurrents traités ailleurs sur ce blog. Ce n'est pas un classement de prestataires.

Pourquoi il est difficile de choisir une agence mobile

La plupart des propositions se ressemblent au niveau où les acheteurs les comparent habituellement : une liste d'écrans, une pile technique, un calendrier et un prix. Les différences qui décident du succès du projet sont moins visibles. Qui détient les comptes développeur Apple et Google ? Le backend est-il assez documenté pour qu'une autre équipe puisse l'exploiter ? Le prestataire a-t-il franchi souvent la validation des stores, ou a-t-il surtout livré des builds que quelqu'un d'autre a dû publier ?

Le mobile ajoute des contraintes que le web n'a pas. Chaque version passe par la validation des stores. Les anciennes versions restent des mois sur les téléphones des utilisateurs, donc le backend doit continuer à les servir. Les notifications push, les achats intégrés, la localisation en arrière-plan et l'accès à la caméra obéissent tous à des règles de plateforme. Un prestataire qui les traite comme des détails les découvrira tard, et sur votre budget.

Les erreurs fréquentes des acheteurs

• Comparer des taux journaliers au lieu du coût total jusqu'à une version réellement publiée, y compris la soumission aux stores, le backend et les corrections après validation.
• Laisser le prestataire créer les comptes développeur, les projets cloud et les noms de domaine au nom de sa propre structure.
• Accepter une démo sur le téléphone du prestataire comme preuve de livraison, au lieu d'un build publié sur votre propre fiche store.
• Ignorer la question de l'après-lancement, quand arrivent les rapports de crash, les mises à jour du système et les refus de validation.
• Choisir une technologie parce qu'elle est à la mode, et non parce qu'elle convient à l'équipe qui maintiendra l'application.

Comment utiliser les 15 questions

Posez-les lors d'un appel ou envoyez-les par écrit. Les bons prestataires y répondent précisément et sans se mettre sur la défensive. Une réponse vague est aussi une information.

Questions 1 à 4 : équipe et propriété

1. Qui va réellement construire l'application ?

Demandez les noms et les rôles des personnes qui feront le travail, pas ceux de l'équipe commerciale. Demandez si une partie est sous-traitée, et à qui. Un studio dirigé par son fondateur, une agence et un freelance de plateforme peuvent tous faire du bon travail, mais vous devez savoir lequel vous engagez.

2. À qui appartient le code, et où se trouve-t-il ?

Le dépôt doit se trouver dans une organisation qui vous appartient, ou vous être transféré selon un calendrier défini. Confirmez que vous recevez le code source complet, la configuration de build et les définitions d'infrastructure, pas seulement des builds compilés.

3. Quels comptes développeur et cloud seront utilisés ?

Apple Developer, Google Play Console, les projets Firebase ou autres projets cloud, les domaines et les comptes de paiement doivent appartenir à votre entreprise, avec le prestataire invité comme membre de l'équipe. Transférer une application d'un compte store à un autre plus tard est possible, mais lent et perturbant.

4. Que se passe-t-il si nous nous séparons en cours de projet ?

Demandez comment se passe le transfert à tout moment : code, identifiants, documentation et une courte présentation. La réponse révèle si le prestataire construit pour vous ou pour vous rendre dépendant.

Questions 5 à 9 : produit et architecture

5. Pourquoi cette technologie pour cette application ?

Le natif, Flutter, React Native et les outils low-code comme FlutterFlow ont tous des usages légitimes. La bonne réponse fait référence à vos besoins : fonctionnalités de la plateforme, fonctionnement hors ligne, compétences de l'équipe, délai de mise sur le marché et identité de ceux qui maintiendront l'application. La mauvaise réponse, c'est que le prestataire utilise toujours cet outil.

6. À quoi ressemble le backend, et qui l'exploite ?

Demandez où sont stockées les données, comment fonctionne l'authentification, comment la logique serveur est déployée et comment le backend est surveillé. Demandez si le même backend servira plus tard une application web, car cela influe sur la conception des comptes et des droits.

7. Comment les données sont-elles sécurisées ?

Demandez comment les règles d'accès sont appliquées sur le serveur ou la base de données, et pas seulement dans l'application. Demandez où sont stockés les secrets, puisque tout ce qui est embarqué dans une application mobile peut être extrait. Demandez comment les données personnelles sont traitées et si les exigences réglementaires de vos marchés ont été prises en compte, par exemple le RGPD pour les utilisateurs européens ou le cadre marocain de protection des données, avec une revue juridique si nécessaire.

8. Comment gérerez-vous les anciennes versions de l'application ?

Tous les utilisateurs ne mettent pas à jour. Demandez comment le backend reste compatible avec les anciennes versions et s'il existe un mécanisme pour imposer une mise à jour lorsqu'un changement incompatible est inévitable.

9. Que se passe-t-il quand le réseau est mauvais ?

Demandez quels écrans fonctionnent hors ligne ou avec une connexion faible, comment les écritures sont retentées et ce que voit l'utilisateur en cas d'échec. Cette seule question sépare les équipes qui ont accompagné de vrais utilisateurs de celles qui n'ont fait des démos que sur le Wi-Fi du bureau.

Questions 10 à 12 : publication et exploitation

10. Qui soumet l'application à l'App Store et à Google Play ?

Demandez qui prépare les fiches, les captures d'écran, les informations de confidentialité et les notes de validation, et qui répond aux refus. Demandez combien de fois l'équipe a fait passer une application en validation, et sur quoi portait le refus le plus récent.

11. Comment les builds sont-ils produits et signés ?

Demandez si les builds sortent d'une chaîne automatisée reproductible ou de l'ordinateur portable d'un seul développeur. Les clés de signature et les identifiants d'API des stores doivent être stockés en sécurité, sous votre contrôle, et documentés.

12. Quel suivi est en place au lancement ?

Le signalement des crashs, des statistiques de base et la journalisation des erreurs du backend doivent faire partie de la première version. Sans eux, le premier signe d'un problème est un avis à une étoile.

Questions 13 à 15 : conditions commerciales

13. Qu'est-ce qui est exactement inclus dans le prix ?

Confirmez si la soumission aux stores, le travail sur le backend, le design, les tests sur appareils réels et les corrections après la première validation sont inclus. Demandez comment les changements sont gérés et facturés.

14. À quoi ressemble le support après le lancement ?

Demandez s'il existe une période de garantie pour les défauts, quels sont les délais de réponse et combien coûte la maintenance courante, comme les mises à jour du système d'exploitation et des dépendances. Une application mobile demande une attention régulière même quand aucune fonctionnalité ne change.

15. Quels sont les coûts récurrents ?

Demandez la liste des coûts récurrents et de leurs facteurs : frais des programmes développeur, hébergement du backend, usage de la base de données, notifications push, e-mails, appels à des modèles d'IA le cas échéant et outils de suivi. C'est vous qui les payez, vous devez donc les voir avant de signer.

Points de mise en œuvre

Demandez les réponses par écrit et intégrez les plus importantes au contrat : propriété des comptes, transfert du code, périmètre inclus et conditions de support. Une réponse aimable au téléphone n'est pas opposable.

Si vous ne pouvez pas juger vous-même les réponses techniques, posez les mêmes questions à chaque prestataire et comparez leur degré de précision. La précision est un bon indicateur d'expérience. Vous pouvez aussi demander une courte phase de cadrage rémunérée avant de vous engager sur le développement complet.

Anticipez les comptes des stores. L'inscription d'une organisation chez Apple et Google exige une vérification de l'entreprise qui peut prendre du temps, et il est bien plus simple de démarrer avec les bons comptes que de migrer ensuite.

Les compromis

Une grande agence offre plus de capacité et de continuité si des personnes partent, au prix de plus d'intermédiaires entre vous et ceux qui écrivent le code. Un studio plus petit ou dirigé par son fondateur signifie généralement un accès direct à l'ingénieur qui prend les décisions, avec moins de capacité disponible. Un freelance peut être excellent pour un travail bien défini, mais comporte un risque plus fort de dépendance à une seule personne.

Les frameworks multiplateformes réduisent le coût de maintien des deux plateformes, tandis que le développement natif peut être le meilleur choix pour les applications très dépendantes de fonctionnalités propres à une plateforme. Les outils low-code peuvent raccourcir le chemin vers une première version, à condition que l'équipe sache quand ajouter du code personnalisé ou exporter le projet.

Ce que montre le travail d'ImadDhin

L'étude de cas FoCoCo, publique, couvre une application téléphone Flutter, une application web Next.js, un backend Firebase, de la voix en temps réel et des abonnements. En observation d'implémentation, les questions qui ont le plus compté ne portaient pas sur les écrans. Elles portaient sur une identité unique entre l'application téléphone et l'application web, pour qu'un compte et un abonnement créés sur une plateforme fonctionnent sur l'autre, ainsi que sur la publication dans les stores et les règles du backend, qui devaient être justes avant que le produit paraisse terminé.

L'article sur FlutterFlow et l'App Store de ce blog documente un schéma que les questions 3, 10 et 11 sont conçues pour détecter : une application visuellement terminée mais incapable d'atteindre TestFlight à cause d'identifiants de bundle, de droits de clé d'API des stores ou de textes de confidentialité manquants. Ces problèmes relèvent de l'ingénierie de publication et doivent être abordés avec le prestataire avant de signer.

Les erreurs à tester

• Demandez à voir une fiche store publiée par le prestataire, et vérifiez sous quel compte elle se trouve.
• Demandez au prestataire d'expliquer un refus de validation passé et comment il a été résolu.
• Vérifiez si la proposition distingue les coûts récurrents du prix de développement.
• Faites confirmer par écrit que les comptes développeur et les projets cloud seront créés au nom de votre organisation.
• Demandez un exemple de documentation de transfert d'un projet précédent, sans les informations du client.

Quand une option plus simple suffit

Si vous testez encore l'intérêt des utilisateurs pour votre produit, vous n'avez peut-être pas encore besoin d'une application mobile. Une application web responsive ou un prototype cliquable peut valider la demande pour une fraction de l'effort, et la validation des stores ne vous freine pas lorsque vous voulez modifier quelque chose chaque jour.

Si vous avez besoin d'un petit outil interne pour un groupe d'utilisateurs connu, une approche low-code ou web peut suffire. Faites appel à une agence de développement d'application mobile lorsque vous avez besoin d'une présence sur les stores, de fonctionnalités de l'appareil ou d'une expérience qui gagne réellement à être native.

Parlez aux personnes qui la construiraient

Posez ces questions à chaque prestataire, y compris à nous. Si votre projet repose sur FlutterFlow, découvrez comment ImadDhin aborde les développements et les reprises FlutterFlow ; pour un périmètre plus large, consultez les formats de mission ou envoyez un brief de projet. Le moyen le plus rapide d'avancer est un appel de 30 minutes pendant lequel vous pourrez poser les 15 questions directement.