Changer l’équipe qui maintient une application mobile ne consiste pas à transmettre un dépôt Git. Une application déjà installée chez des utilisateurs dépend aussi de comptes stores, de certificats, d’une API, de services de notification et d’une chaîne de publication. Un seul accès manquant peut empêcher la prochaine mise à jour.
Cette checklist aide à reprendre une application iOS et Android sans perdre sa fiche, ses utilisateurs ou la capacité à publier.
Conserver les applications existantes sur les stores
Le nouvel intervenant ne doit pas créer une autre application pour remplacer l’ancienne. Une mise à jour doit conserver les identifiants techniques et être publiée depuis les comptes qui détiennent déjà les fiches App Store et Google Play.
Vérifiez d’abord :
- l’accès administrateur à App Store Connect et Google Play Console ;
- le propriétaire légal de chaque compte ;
- les identifiants d’application et noms de package ;
- les contrats, informations fiscales et moyens de paiement ;
- les rôles attribués aux anciens et nouveaux intervenants ;
- les versions disponibles en production et en test.
Les comptes doivent appartenir à l’entreprise cliente. Si l’application est publiée sur le compte personnel d’un développeur ou celui d’une agence, il faut préparer son transfert selon les règles de la plateforme.
Récupérer les certificats et moyens de signature
Apple et Android utilisent des mécanismes différents, mais le principe reste le même : les utilisateurs doivent recevoir une mise à jour reconnue comme provenant de l’application déjà installée.
L’équipe doit localiser les certificats, profils, clés et mots de passe nécessaires, ainsi que leurs dates d’expiration. Elle vérifie aussi les mécanismes de signature gérés directement par les plateformes. Ces éléments ne doivent pas être envoyés sans protection dans une messagerie ou ajoutés au dépôt.
Faire l’inventaire des services mobiles
Le code mobile dialogue rarement uniquement avec l’API principale. Recherchez les services de :
- notifications push ;
- authentification sociale ;
- analytics et suivi des erreurs ;
- paiement et abonnements ;
- liens profonds ;
- stockage de fichiers ;
- cartographie, caméra ou objets connectés ;
- configuration à distance.
Pour chacun, documentez le propriétaire du compte, les environnements, les quotas et les clés utilisées. Une configuration oubliée peut fonctionner dans l’ancienne version tout en échouant lors du prochain build.
Reproduire les builds iOS et Android
La nouvelle équipe doit pouvoir générer les applications à partir d’un poste ou, idéalement, d’une CI. Il faut connaître les versions des SDK, les dépendances natives, les variables d’environnement et les commandes de build.
Une application hybride ou multiplateforme ajoute parfois plusieurs couches : Flutter, React Native, Ionic ou Capacitor, puis les projets natifs iOS et Android. Les plugins doivent être compatibles avec les versions récentes des systèmes et des outils de publication.
Le premier objectif est de reproduire la version actuelle sans modification fonctionnelle. Cela isole les problèmes de reprise avant d’introduire de nouveaux changements.
Vérifier l’API et la compatibilité des versions
Tous les utilisateurs ne mettent pas leur application à jour le même jour. L’API doit donc accepter pendant un temps plusieurs versions mobiles. Avant de modifier un contrat d’échange, identifiez les versions encore actives et prévoyez une période de compatibilité.
Les migrations doivent tenir compte des sessions, des données enregistrées localement et des utilisateurs qui passent directement d’une version ancienne à la plus récente. Un test uniquement réalisé après une installation neuve ne couvre pas ce parcours.
Préparer une première mise à jour à faible risque
La première publication de la nouvelle équipe doit rester limitée : correction visible mais simple, mise à niveau technique maîtrisée ou amélioration de la supervision. Elle valide la signature, les tests, la soumission, la revue des stores et la communication avec les utilisateurs.
Utilisez les canaux de test internes, puis un déploiement progressif lorsque la plateforme le permet. Surveillez les erreurs, les performances de l’API et les retours du support avant de généraliser.
Ne pas oublier le produit et le support
La reprise doit inclure les textes et visuels des fiches, la politique de confidentialité, les coordonnées de support et les réponses aux avis. Vérifiez également les obligations déclarées dans les stores concernant les données et les permissions.
Une Tierce Maintenance Applicative peut ensuite couvrir les mises à jour des systèmes, les incidents et les évolutions régulières.
Le cas MyTwiga
La reprise de MyTwiga associait plusieurs applications mobiles, une nouvelle API et l’infrastructure de déploiement. Farrago a travaillé sur ces éléments comme un système unique, tout en maintenant le service et en terminant les refontes engagées. Découvrez la réalisation MyTwiga.
Pour une méthode plus large incluant accès, audit et organisation, consultez notre guide pour faire reprendre une application existante.