Les situations les plus fréquentes
- Le développeur ou l’agence ne répond plus, et une mise à jour est urgente.
- Apple ou Google a rejeté une version, ou menace de retirer l’application.
- Des bugs bloquent l’inscription ou le paiement juste avant une échéance : un lancement, un salon, une levée de fonds.
- Un prototype fait sans code, sur FlutterFlow par exemple, ne tient plus face à un usage réel.
Les accès à récupérer, avant tout
Avant toute intervention sur le code, il faut vous assurer de la maîtrise de votre application. Voici les accès que je demande à chaque reprise. Récupérez-les, même si votre prestataire est encore joignable.
- Le code source, dans un dépôt GitHub ou GitLab à votre nom, ou au moins une copie complète.
- Le compte Apple Developer, avec un accès administrateur pour vous.
- La console Google Play, avec un accès propriétaire ou administrateur.
- Les services du serveur : Firebase, Supabase ou l’hébergeur, et la base de données.
- Le nom de domaine et sa configuration.
- Les services branchés à l’application : paiement, envoi d’e-mails, notifications, cartes.
- Pour Android, la clé de signature de l’application. Si Google la conserve pour vous (Play App Signing), une clé perdue se remplace. Sinon, l’application ne peut plus être mise à jour.
Relisez votre contrat. En France, les droits sur un logiciel écrit par un prestataire indépendant lui restent tant qu’une cession n’a pas été signée par écrit. Si le contrat n’en parle pas, demandez la cession en même temps que les accès.
Le diagnostic
Je commence toujours par un diagnostic, à prix fixé d’avance. Je compile l’application, je l’exécute, j’analyse le code et les comptes. Je vous remets ensuite la liste de ce qui bloque, l’ordre de correction que je recommande et le coût de chaque étape.
Je traite en priorité ce qui empêche vos utilisateurs de s’inscrire, de se connecter ou de payer. Sur Mamie Jacotte, il s’agissait de familles créées en double et d’une connexion avec Google défaillante.
Reprendre ou réécrire
Dans la plupart des cas, la reprise est préférable. Réécrire coûte cher, fait perdre des mois et réintroduit des bugs déjà corrigés. Je ne propose de réécrire que si l’application repose sur un outil abandonné, si chaque correction en casse deux autres, ou si elle doit changer de nature.
Sur DEJA-VU, le prototype ne fonctionnait pas et la levée de fonds approchait. J’ai repris l’architecture existante plutôt que de repartir de zéro, et la fondatrice a pu montrer un parcours complet aux investisseurs.
Quand Apple ou Google rejette une version
Un rejet n’est presque jamais définitif. Apple cite la règle de ses consignes qui pose problème, et il est possible de répondre dans la console, ou de corriger puis de renvoyer la version. Les causes les plus fréquentes : une déclaration de confidentialité incomplète, une connexion qui ne fonctionne pas pour le testeur, une fonction payante qui contourne le paiement intégré, ou une version Android trop ancienne pour les exigences de Google.
Sur Milky Date, les règles d’Apple et de Google menaçaient la place de l’application sur les stores. Je l’ai stabilisée, remise en conformité, et j’ai automatisé la préparation des versions pour que les mises à jour suivantes soient simples.
Après la reprise
Je documente ce que j’ai trouvé et ce que j’ai changé, et je laisse les accès en ordre. L’objectif est que vous ne dépendiez plus d’une seule personne, moi compris. Je peux ensuite assurer la maintenance, ou passer la main à votre équipe.