Comment choisir une agence de développement d'application mobile

Comparez d'abord ce que chaque agence prévoit de livrer

Trois propositions soignées peuvent décrire trois applications différentes. L'une comprend le serveur et l'interface d'administration. Une autre suppose que ces éléments existent déjà. La troisième annonce une date sans préciser les décisions que votre entreprise doit prendre pour la respecter. Tant que ces écarts restent invisibles, comparer les montants ne suffit pas.

Nous préférons une première version limitée, avec une réception clairement définie, à la promesse de tout réaliser. La prudence n'est pourtant pas une qualité en soi. Ce qui compte, c'est la capacité à expliquer les incertitudes et à proposer une façon concrète de les lever. Une équipe utile ne se contente pas d'approuver toutes vos idées.

Présentez le même besoin à toutes les équipes

Décrivez une personne et ce qu'elle doit pouvoir accomplir. Pour une école en ligne, il peut s'agir d'un élève qui ouvre sa leçon, rend un exercice et reçoit un commentaire du professeur. « Une plateforme éducative avec IA et communauté » laisse beaucoup plus de place aux suppositions.

Transmettez le même document court aux agences retenues : parcours principal, outils existants, pays de lancement, appareils visés, état du design et fonctions reportables. Notre guide sur la préparation d'une estimation aide à rassembler ces éléments. Un cahier des charges complet n'est pas nécessaire pour un premier échange sérieux.

Demandez ensuite à chaque équipe de reformuler le projet. Pense-t-elle à des cours enregistrés, des séances en direct ou une bibliothèque sur abonnement ? Ce ne sont pas les mêmes produits. Mieux vaut découvrir ces différences maintenant qu'après la validation des premiers écrans.

Cherchez ce que les références prouvent réellement

Ouvrez une application pertinente, si elle est accessible dans votre marché, et essayez son parcours principal. Demandez ensuite quelle partie l'agence a réalisée, à quelle période elle est intervenue et si elle assure encore la maintenance. La version actuelle peut intégrer le travail de plusieurs prestataires.

Une expérience opérationnelle proche vaut parfois davantage qu'une étiquette sectorielle identique. Savoir traiter les réservations concurrentes, remboursements et droits du personnel peut être précieux pour un service de prise de rendez-vous. À l'inverse, de beaux écrans ne démontrent pas la maîtrise d'une administration complexe.

Vous pouvez demander une référence client avec son accord, ou des documents anonymisés : plan de test, relevé de décisions, exemple de transmission. Ils permettent de comprendre le travail sans divulguer des informations confidentielles. Refuser de montrer le code privé d'un client est normal. Ne pouvoir expliquer aucun processus concret est une autre question.

Notez les réponses plutôt que vos seules impressions

Après plusieurs rendez-vous, on se souvient facilement d'un bon contact et moins facilement de la personne chargée du serveur. Pour chaque point important, notez : clair, à préciser ou inacceptable. Une notation peut aider, mais une bonne moyenne ne doit pas masquer un problème bloquant de propriété.

Faites ensuite préciser une réponse par un exemple. Comment vérifie-t-on une réservation ? Quand votre entreprise accède-t-elle au code ? De quoi un autre développeur aurait-il besoin pour compiler l'application ? Une explication de ce type vaut davantage qu'un engagement général.

Dix questions pour aller au fond du sujet

Il n'est pas nécessaire de transformer l'entretien en interrogatoire. Gardez ces questions comme fil conducteur et approfondissez les réponses encore vagues.

1. Que pourra terminer un utilisateur dans la première version ?
2. Quelle fonction de notre idée reporteriez-vous, et pourquoi ?
3. Quels éléments supposez-vous déjà disponibles chez nous ?
4. Qui traitera les remboursements et autres exceptions ?
5. Que verrons-nous avant le développement principal ?
6. Comment démontrerez-vous le fonctionnement sur les appareils visés ?
7. Qui valide une modification et où ses conséquences sont-elles consignées ?
8. Qui contrôle le code et les comptes de production ?
9. Que se passe-t-il si une personne clé devient indisponible ?
10. Quel travail est prévu après la première publication ?

« Nous devons vérifier la fiabilité des disponibilités renvoyées par votre logiciel de réservation » peut être une excellente réponse. Il faut alors une vérification délimitée et une date de décision. « Les intégrations sont simples » apporte beaucoup moins d'informations pour choisir.

Comparez deux offres sur un cas concret

Prenons une application fictive de réservation de cours. L'offre A comprend le choix d'une séance et le paiement. L'offre B prévoit aussi le blocage temporaire d'une place, les annulations, les corrections du personnel et le suivi des paiements échoués. Le titre des deux documents est identique, pas leur contenu.

Demandez à A si ces comportements sont inclus, exclus ou encore indécis. Demandez à B lesquels doivent absolument être automatisés au lancement. Certaines exceptions rares peuvent être gérées manuellement, à condition qu'une personne en soit responsable et que l'utilisateur reçoive une réponse fiable.

Cela évite une erreur classique : retenir une proposition plus légère en imaginant que toute l'exploitation nécessaire est implicitement comprise. Vous n'avez pas à imposer la même architecture aux équipes. En revanche, le résultat attendu et la répartition des responsabilités doivent être comparables.

Décidez à l'avance ce que signifie « terminé »

Une maquette interactive prouve une idée de navigation, pas le fonctionnement d'un service réel. Un écran de paiement qui marche sur un téléphone ne prouve pas la récupération après une coupure réseau. Distinguez validation du design, recette fonctionnelle, préparation de la soumission et publication effective.

Pour une réservation, un critère peut être le suivant : deux personnes tentent d'acheter la dernière place, une seule obtient confirmation et l'autre ne reste pas avec un débit inexpliqué. Précisez qui fournit les comptes de test et qui accepte le résultat. Le modèle de cahier des charges montre comment décrire ces conditions.

Le guide GOV.UK sur les récits utilisateurs relie un besoin à un résultat vérifiable. Vous pouvez utiliser ce principe sans adopter une méthode de gestion particulière. La liste de vérification qualité complète la discussion sur les preuves attendues.

Gardez la maîtrise des comptes et de la transmission

Dans la mesure du possible, placez les comptes critiques sous le contrôle de votre entreprise et attribuez les rôles nécessaires à l'agence. Identifiez les responsables du code, des boutiques, de l'hébergement, de la base, du domaine, des outils d'analyse, des fichiers de design et des paiements. Une adresse personnelle ne doit pas devenir l'unique porte d'entrée du produit.

Une copie du code ne suffit pas pour exploiter l'application. Une transmission utilisable comprend les instructions de compilation, la configuration des environnements, les dépendances et la publication des mises à jour. Les secrets doivent passer par un dispositif sécurisé, pas par un document public.

Apple décrit sa procédure de transfert, tandis que Google prévoit ses propres conditions. Un transfert ultérieur ne remplace pas un accord initial sur les comptes. Faites vérifier les clauses juridiques si nécessaire : accès technique et droits sur le résultat ne se confondent pas.

Cinq erreurs qui fragilisent la collaboration

La première consiste à envoyer des demandes différentes puis à comparer les réponses comme des offres équivalentes. La deuxième est de valider les écrans avant les règles du service. Ces deux situations peuvent provoquer un désaccord sans qu'aucune partie ait cherché à tromper l'autre.

La troisième est de laisser des décisions sans responsable. Si votre entreprise n'a pas choisi son prestataire de paiement ou ses conditions d'annulation, l'agence ne peut pas prendre discrètement cette décision commerciale. Désignez une personne habilitée à arbitrer et un remplaçant.

La quatrième est d'accepter des promesses illimitées sur l'IA, le low-code ou les corrections. Ces outils peuvent aider, mais demandez comment le résultat est contrôlé et maintenu. Enfin, n'attendez pas une panne pour parler assistance. Précisez le canal de signalement, les degrés d'urgence et la différence entre correction et nouvelle fonctionnalité.

Prenez la décision avec un dossier que vous pourrez relire

Avant de signer, réunissez première version, exclusions, questions ouvertes, exemples de recette, titulaires des comptes et conditions de maintenance. Une question non résolue ne justifie pas forcément d'écarter l'équipe. Elle doit toutefois avoir un responsable et une prochaine étape.

Les réalisations publiques d'Appfyl constituent elles aussi un point de départ pour poser des questions, pas une dispense de vérification. Interrogez-nous comme les autres prestataires. Si le projet reste à définir, le court questionnaire de cadrage organise une demande à examiner ; il ne fournit pas de devis ferme instantané.

Questions fréquentes