Après la démo du prestataire, tout semble fluide, mais dès la réception on découvre des échecs de connexion intermittents, des callbacks de paiement non aboutis, des données back-office incohérentes — ce type de reprise est particulièrement éprouvant. La réception d'un projet de développement d'App en sous-traitance ne consiste pas à « jeter un œil pour voir si ça tourne », mais à aligner point par point les besoins, la qualité et les livrables. Voici la démarche, dans un ordre opérationnel.
1. Valider d'abord la liste des besoins, pas « au ressenti »
Le premier document de réception n'est pas le package d'installation, mais le cahier des charges et la liste fonctionnelle. Beaucoup de reprises viennent d'un manque de clarté initial : qui utilise, dans quel contexte, comment signaler les cas d'erreur.
Recommandations :
- Découper les besoins en éléments cochables, chacun décrit par « entrée — action — résultat attendu », par exemple « connexion par numéro de téléphone : saisir un numéro non enregistré, afficher un message indiquant que le compte n'existe pas et proposer l'inscription ».
- Indiquer les priorités : les parcours critiques (inscription/connexion, commande/paiement, opérations métier essentielles) doivent être validés à 100 %, les fonctions secondaires peuvent être listées comme points à corriger.
- Lors de la réception, cocher chaque élément un par un, consigner captures d'écran ou enregistrements vidéo sur place, pour éviter les « ça ne va pas » sans preuve.
À éviter : ne pas prendre « ce n'est pas ce que j'imaginais » comme critère de réception. Les détails d'interface peuvent être ajustés, mais les fonctions manquantes et les erreurs de données doivent figurer dans la fiche de correction, avec responsabilités et délais clairement définis.
2. Les tests sur appareils réels doivent couvrir les modèles et les cas d'erreur
Un fonctionnement sur émulateur ne garantit pas l'absence de problèmes sur appareil réel. Dans le développement d'App, les reprises les plus fréquentes sont : plantage sur une marque de téléphone, écran blanc en réseau faible, blocage du parcours après refus d'une permission.
Méthode concrète :
- Couvrir au minimum 2 à 3 appareils réels iOS et Android parmi les modèles courants, dont un modèle d'entrée de gamme.
- Tester en priorité les cas d'erreur : coupure réseau, passage en arrière-plan puis retour, interruption par un appel, refus de permission, clics répétés sur un bouton de soumission.
- Les modules dépendant des capacités système (paiement, notifications push, géolocalisation, appareil photo) doivent être vérifiés un par un sur appareil réel.
- Consigner les journaux de plantage et les étapes de reproduction, comme base des corrections.
À éviter : ne tester que le « chemin nominal » est le plus grand piège de la réception. Les chemins d'erreur sont ce que l'utilisateur rencontrera réellement, et ce qui coûtera le plus cher en maintenance.
3. Valider ensemble API, back-office et données
L'App n'est que la partie front-end ; d'où viennent les données et où sont-elles stockées déterminent la pérennité du système. Beaucoup de projets ont une belle interface, mais le back-office ne retrouve pas les données, les exports sont illisibles, les permissions sont chaotiques.
Points à vérifier lors de la réception :
- La stabilité des API : en cas de requêtes répétées, de timeout ou de réponse anormale, l'App affiche-t-elle un message de repli ?
- Le back-office : création/modification/suppression/recherche, gestion des niveaux de permission, export de données sont-ils opérationnels ?
- Les données clés sont-elles traçables, par exemple l'historique des changements de statut de commande ?
- Si un développement de mini-programme ou un développement de site web partage le même back-office, vérifier la cohérence des données entre les plateformes.
À éviter : ne pas se contenter de l'interface de l'App. Le back-office est l'outil quotidien de l'exploitation ; lors de la réception, faire manipuler l'outil par les utilisateurs réels est plus convaincant qu'une démonstration technique.
4. Livrer intégralement le code, la documentation et les comptes
Les reprises surviennent souvent au moment du « changement d'équipe ». Si le code n'est pas chez vous, si les comptes serveur sont chez le prestataire, sans documentation de déploiement, chaque modification ultérieure devra être renégociée financièrement.
Liste de livrables à inscrire au contrat :
- Le code source complet et les instructions de build, permettant de le faire tourner dans un environnement propre.
- La documentation des API, la description de la structure de la base de données, la configuration des services tiers.
- Les droits d'administration sur les comptes serveur, nom de domaine, stores d'applications, paiement, notifications push, etc.
- L'historique des versions et la liste des problèmes connus.
À éviter : faire de la « liste des livrables » une condition des jalons de paiement avant la réception. Un code hébergé sur votre propre compte, avec des droits transférables, est plus fiable qu'une promesse verbale.
5. Convenir à l'avance de la mise en ligne et de la maintenance
La mise en ligne n'est pas la fin. La revue des stores, l'expiration des certificats, les problèmes de compatibilité liés aux mises à jour système surviendront après la livraison.
À préciser :
- Qui soumet l'application, qui corrige en cas de rejet par la revue.
- Quelle est la durée de la maintenance gratuite après livraison, et quel est son périmètre (correction de plantages, problèmes de compatibilité).
- Comment sont facturés les nouveaux besoins, pour éviter que les « petites modifications » ne deviennent un puits sans fond.
Un cas concret : une entreprise fait développer une App de réservation ; à la réception toutes les fonctions passent, mais après la mise en ligne, sur une ancienne version d'Android, le sélecteur de date est décalé et l'utilisateur ne peut pas choisir l'heure. Si un test sur appareil d'entrée de gamme avait été fait lors de la réception, ce problème aurait pu être détecté à temps.
Quand faire appel à MIC Studio
Si vous êtes à ces étapes, vous pouvez envisager de faire intervenir MIC Studio : le besoin n'est pas encore stabilisé et il faut de l'aide pour découper la liste ; une App existante ou un site web d'entreprise doit être refondu ou connecté à un back-office ; vous souhaitez faire une campagne de tests de sécurité ou de tests inversés avant la mise en ligne pour vérifier l'absence de failles évidentes dans les API et les données ; ou votre équipe manque de ressources et a besoin d'un appui en développement de scripts, développement de site web, développement de mini-programme, etc. Nous avons l'habitude de clarifier d'abord les critères de réception et les livrables, puis de commencer, afin de réduire les reprises ultérieures.
Trois conseils opérationnels pour finir
1. Obtenir la liste fonctionnelle et la liste des livrables avant la réception, cocher point par point, consigner les problèmes dans une fiche de correction avec des délais convenus.
2. Les tests sur appareils réels couvrent les modèles d'entrée de gamme et les cas d'erreur ; paiement, notifications push et permissions doivent être vérifiés un par un.
3. Inscrire au contrat le code source, la documentation, les droits sur les comptes et le périmètre de maintenance gratuite, comme conditions des jalons de paiement.