Oui, une application peut être reprise quand son prestataire ne répond plus, à condition de retrouver les accès, les données et les droits nécessaires à sa maintenance. Commencez par sécuriser ce que votre entreprise contrôle, puis faites auditer l'existant avant de décider ce qu'il faut conserver ou remplacer. Une réécriture complète ne se décide pas sur la seule absence du développeur.
La première semaine, retrouver qui contrôle quoi
Que le freelance soit devenu injoignable, que l'agence ait fermé ou que la maintenance se soit arrêtée, désignez une personne chez vous pour centraliser le dossier. Rassemblez contrat, factures, anciens échanges et alertes reçues. Notez les prochaines échéances avant de demander de nouvelles fonctionnalités.
Pour chaque ligne ci-dessous, consignez le titulaire, l'administrateur, le payeur et la dernière connexion réussie. Une facture à votre nom ne remplace pas un accès testé.
- Domaine et DNS
- Titulaire du domaine, renouvellement, accès au registraire et aux réglages DNS.
- Comptes des stores
- Entité inscrite à Apple Developer et Google Play Console, titulaire du compte et rôles dans App Store Connect.
- Hébergement et facturation
- Comptes cloud, administrateurs, moyen de paiement et alertes de renouvellement.
- Code source
- Dépôt complet avec son historique et une copie sous le contrôle de l'entreprise.
- Backend et base de données
- Services côté serveur, accès aux données, sauvegarde récente et restauration à vérifier.
- API et abonnements
- Services tiers, clés API, licences, quotas et personne qui règle chaque abonnement.
- Mesure d'usage
- Propriété des comptes analytics, accès aux rapports et historique disponible.
- Envoi d'e-mails
- Compte d'envoi, domaines vérifiés et accès aux messages d'erreur et de réinitialisation.
Demandez à la nouvelle équipe de vérifier les sauvegardes dans un environnement isolé avant toute intervention sur les données en production. Organisez ensuite le remplacement des accès partagés et des clés, service par service, en vérifiant les fonctions qui en dépendent.
Ce qu'il faut demander par écrit
Envoyez une demande formelle au contact et à l'adresse prévus au contrat. Énumérez les éléments attendus, proposez un délai de réponse et un mode de transmission sécurisé. Gardez une copie datée de la demande et des réponses.
- Le code complet de la version publiée, les éléments graphiques et les instructions pour préparer et publier une mise à jour.
- L'inventaire des comptes, abonnements, licences et services, avec leurs titulaires et échéances.
- Les accès ou invitations administrateur, les sauvegardes et la procédure de restauration.
- La documentation, les incidents connus, les travaux en cours et les transferts de comptes à organiser.
Demandez des invitations nominatives plutôt qu'un mot de passe personnel. Si l'application appartient au compte du prestataire, suivez la procédure d'Apple App transfer.
Pour Google Play, consultez Transfer apps. Les services associés demandent aussi des vérifications. Sans coopération, contactez l'assistance des plateformes avec les justificatifs disponibles, sans présumer qu'elle pourra transférer l'application.
Le contrat détermine les droits à vérifier
Relisez ce qui est prévu pour la remise du code, son utilisation, sa modification par un tiers et la fin de collaboration. Faites préciser les composants soumis à des licences externes. Posséder une copie du code ne suffit pas à établir l'étendue des droits accordés.
En Suisse, l'IPI distingue la cession des droits de la licence, qui autorise des usages selon un périmètre convenu. Ce repère est une orientation, pas un avis juridique sur votre contrat. Si les clauses sont absentes ou contestées, faites examiner le dossier avant d'engager une modification ou une nouvelle publication.
Les stores continuent d'imposer leurs échéances
Sur iPhone, les Upcoming Requirements d'Apple peuvent empêcher l'envoi d'une mise à jour construite avec un ancien SDK. Par ailleurs, la procédure
App Store Improvements prévoit le retrait d'applications obsolètes ou qui ne fonctionnent plus correctement. Ce sont deux mécanismes distincts.
Sur Android, les règles Target API de Google Play distinguent la publication d'une mise à jour et la disponibilité d'une application existante. Une cible Android trop ancienne peut limiter l'accès des nouveaux utilisateurs sur des appareils plus récents, sans retrait général du catalogue.
Faites donc relire les messages des deux consoles et vérifier les exigences applicables à votre application. Une application encore installée sur votre téléphone ne prouve pas qu'elle reste téléchargeable ou qu'une correction peut être publiée.
Reprendre dans l'ordre des risques
- 1Sécuriser les accès
Identifier les titulaires, préserver les données et assurer les renouvellements urgents.
- 2Auditer
Relier le code à la version utilisée, vérifier les droits et évaluer sécurité, publication et dépendances.
- 3Stabiliser
Rendre une mise à jour possible, tester les parcours essentiels et vérifier la restauration.
- 4Faire évoluer
Décider des améliorations et du remplacement éventuel de certaines parties, sur la base de l'audit.
L'audit doit déboucher sur des décisions chiffrables, avec les inconnues qui restent. Demandez une proposition séparant la continuité immédiate, la stabilisation et les évolutions. Notre guide Comment comparer des devis d'application mobile en Suisse ? aide à comparer ces périmètres.
Si le code manque, commencez par mesurer ce que les données, les comptes et la documentation permettent de récupérer. Si une partie doit être remplacée, prévoyez la migration et la continuité du service. Ne supprimez pas l'existant avant d'avoir vérifié son remplacement.
Préparer la prochaine transmission
Ouvrez les comptes au nom de votre entreprise, avec des responsables internes et des accès nominatifs pour le prestataire. Conservez la documentation des services, des coûts récurrents, des sauvegardes et de la publication là où votre équipe peut la retrouver. Vérifiez qu'une autre personne peut suivre la procédure de mise à jour.
Le prochain contrat doit préciser les droits, les livrables, la remise des accès et l'accompagnement de fin de mission, y compris ses conditions financières. Chez Appik Studio, le co-développement de l'application Le Temps avec son équipe interne illustre le partage du code, des décisions et des connaissances qui prépare la continuité, comme nous le décrivons dans notre approche.
Pour examiner votre situation, consultez notre service de reprise d'application ou notre offre de développement et reprise mobile. Le premier échange sert à préciser ce qui est accessible et ce qui reste à éclaircir avant de définir une intervention.
Sources et références
6 sourcesige.ch · developer.apple.com · support.google.com
- ige.chIPI, cession de droits et licences. Orientation suisse sur la distinction entre droits et usages autorisés, sans analyse du contrat individuel. Page non datée, consultée le 13 novembre 2026.ige.ch
- developer.apple.comApple Developer, Upcoming Requirements. Exigences OS et SDK pour les envois dans App Store Connect, distinctes d'un retrait de la vente. Calendrier évolutif consulté le 13 novembre 2026.developer.apple.com
- developer.apple.comApple Developer, App Store Improvements. Procédure d'examen et de retrait des applications obsolètes ou défaillantes. Page non datée, consultée le 13 novembre 2026.developer.apple.com
- support.google.comGoogle Play, Target API level requirements. Politique 2026 distinguant nouveaux envois, mises à jour et disponibilité des applications existantes selon les appareils, avec exceptions par plateforme. Consultée le 13 novembre 2026.support.google.com
- developer.apple.comApple Developer, Overview of app transfer. Transfert entre comptes et vérifications des services associés. Page non datée, consultée le 13 novembre 2026.developer.apple.com
- support.google.comGoogle Play, Transfer apps to a different developer account. Conditions des comptes et traitement séparé des services et rapports. Page non datée, consultée le 13 novembre 2026.support.google.com
