Réponse courte. La reprise se fait en quatre étapes et six semaines : l'inventaire de ce que vous avez et de ce qui est à votre nom ; la récupération, actif par actif, des comptes stores, du domaine, de l'hébergement, du code, des données et des clés, avec une mise en demeure si le contrat le permet ; l'audit du code et des données, qui décide ce qui se garde, se répare ou se réécrit ; la remise en route, accès verrouillés, dépendances à jour, stores repris, documentation d'une page. La décision de réécrire se prend en semaine quatre, sur l'audit, pas en semaine zéro sur la colère. Et 2027 rend la reprise urgente : les stores retirent les applications non mises à jour, et la vérification mondiale des développeurs Android ferme la porte à l'APK distribué à la main.
Ce guide répond à des messages que nous recevons chaque mois, d'entreprises algériennes et de fondateurs de la diaspora, et il complète peut-on connaître le prix total avant de commencer et freelance, agence ou atelier d'ingénierie, écrits avant le projet. Ici, le projet a déjà mal tourné.
Pourquoi 2027 rend la reprise urgente
Une application abandonnée pouvait, jusqu'ici, tourner des années sans que personne n'y touche. Trois choses changent en 2027.
- Les stores retirent les applications non mises à jour. Google Play et l'App Store exigent chaque année que les applications ciblent une version récente du système ; une application figée cesse d'être proposée aux nouveaux utilisateurs, puis disparaît des résultats. Si le compte est au nom du prestataire disparu, personne ne peut la mettre à jour.
- La vérification mondiale des développeurs Android. Google a annoncé qu'à partir de 2027, les applications installées sur les appareils Android certifiés devront provenir d'un développeur identifié, y compris hors Play Store. La solution de secours « on envoie l'APK sur WhatsApp » a une date de fin.
- Le paiement et les données. Avec le projet de loi de finances 2027 qui pousse vers l'encaissement électronique et la loi 18-07 sur les données personnelles, une application dont vous ne contrôlez ni le paiement ni la base de données est un risque juridique, pas seulement technique.
Nous avons détaillé ces échéances dans les sept décisions d'une application mobile en 2027. Pour une application déjà construite, elles se résument en une phrase : ce qui n'est pas à votre nom ne vous appartient pas, et ce qui n'est pas mis à jour disparaît.
Les quatre étapes d'une reprise
L'ordre compte. Les entreprises qui appellent un nouveau développeur en lui demandant de « tout refaire » sautent les deux premières étapes et paient un projet entier pour un code qui aurait peut-être tenu.
L'inventaire tient sur une page : les comptes Google Play et App Store, le nom de domaine, l'hébergeur et les serveurs, le dépôt de code, la base de données, les services tiers, SMS, paiement, cartes, notifications, et pour chacun, qui détient l'accès et à quel nom il est enregistré. Relisez le contrat et les factures : ce qui est écrit sur la propriété du code et sur la remise des accès décide de la suite. La récupération se fait actif par actif, par les procédures des plateformes elles-mêmes, et par une mise en demeure écrite au prestataire lorsque le contrat le permet ; le détail est dans la figure suivante. L'audit regarde le code récupéré avec trois questions : est-il lisible par un autre développeur, ses dépendances sont-elles à jour et sans faille connue, les données sont-elles exportables et saines ? La remise en route verrouille tout à votre nom, met à jour, reprend les publications sur les stores, teste une restauration de sauvegarde et écrit la documentation d'une page.
«La décision de réécrire se prend en semaine quatre, sur l'audit, pas en semaine zéro sur la colère.»
Ce qui se récupère, et comment
La question « est-ce que je peux récupérer mon application » a six réponses, une par actif. La colonne de gauche prend une journée ; la colonne de droite, des semaines.
Les comptes stores. S'ils sont à votre nom, changez les mots de passe et activez la double authentification sur votre propre téléphone. S'ils sont au nom du prestataire, Google Play et l'App Store ont une procédure de transfert d'application vers un autre compte, qui exige la coopération du titulaire ; sans elle, l'application se republie sous votre compte, avec un nouvel identifiant, et vos utilisateurs doivent la réinstaller. Le domaine se vérifie chez le registrar : le titulaire doit être vous ; sinon, exigez le transfert par écrit, et préparez un nouveau domaine avec redirection si le prestataire ne répond pas. L'hébergement : si vous avez les accès, exportez immédiatement une sauvegarde complète ; sinon, l'hébergeur peut parfois fournir un export de la base au titulaire du contrat. Le code : vérifiez que le dépôt contient la dernière version déployée, pas une version d'il y a six mois ; s'il n'y a pas de dépôt, le build en production se récupère et s'analyse, mais il ne remplace pas le code source. Les données de vos clients vous appartiennent, et la loi 18-07 vous rend responsable de leur protection ; l'export est exigible. Les clés des services tiers, SMS, paiement CIB/Edahabia, cartes, se révoquent et se recréent toutes, à votre nom, sans exception : une clé laissée au prestataire est une porte ouverte.
L'audit : garder, réparer ou réécrire
C'est l'étape que la colère fait sauter. Trois cas, décidés sur le code récupéré, avec un prix total écrit pour chacun.
- Garder. Le code est lisible, les dépendances se mettent à jour sans casser, les données sont saines. On reprend la maintenance, on verrouille, on publie une mise à jour. C'est plus fréquent qu'on ne le croit quand le prestataire était compétent mais indisponible.
- Réparer. Le code tient mais une partie est fragile : paiement bricolé, hors-ligne absent, base sans sauvegarde. On remplace cette partie, on garde le reste. Le prix se compare à la partie, pas au projet.
- Réécrire. Le code est illisible, ou construit sur une technologie que plus personne ne maintient, ou les données sont irrécupérables. On repart du cadrage, en reprenant les données et les utilisateurs. C'est la seule situation où le projet entier est justifié, et elle se constate, elle ne se décrète pas.
Un audit se livre par écrit : ce qui a été regardé, ce qui a été trouvé, les trois options avec leur prix total, et une recommandation. Un prestataire qui recommande la réécriture sans avoir lu le code vous vend un projet, pas une reprise.
Le kit de propriété, pour que ça n'arrive plus
Que vous gardiez ou réécriviez, la remise en route installe cinq couches qui font qu'aucun prestataire, y compris nous, ne peut plus bloquer votre application.
Les comptes stores, domaine et hébergeur sont à votre nom, avec la double authentification sur votre téléphone ; le prestataire est invité avec un rôle, jamais propriétaire. Le code vit dans un dépôt à votre nom, où le prestataire est invité et d'où il se révoque en un clic ; il est livré à chaque étape, pas à la fin. L'infrastructure : les accès administrateur des serveurs et de la base sont chez vous, les clés des services tiers dans un coffre à votre nom, et les sauvegardes ont été restaurées au moins une fois, parce qu'une sauvegarde jamais testée n'existe pas. Le contrat écrit la propriété du code, cédée à chaque paiement, et une clause de réversibilité : accès et documentation remis sous quinze jours à la demande. La documentation tient sur une page, où est quoi et comment déployer, lisible par un autre développeur en une heure. C'est ce que nous livrons sur chaque projet, et c'est ce qu'il faut exiger de quiconque ; nous l'avons expliqué dans comment choisir un développeur en Algérie.
«Rien d'essentiel ne doit exister uniquement sur l'ordinateur ou dans le téléphone du prestataire.»
Les six semaines de la reprise
Six semaines, dont quatre avant la décision la plus chère.
Semaine 1, l'inventaire, avec vous : la liste, le contrat, les factures, les captures d'écran de ce qui existe. Semaines 2 et 3, la récupération, en parallèle sur tous les actifs, avec la mise en demeure envoyée le premier jour si le prestataire ne répond pas ; chaque jour sans accès au compte store est un jour de risque de retrait. Semaines 3 et 4, l'audit du code et des données récupérés, par écrit. Semaine 4, la décision, sur l'audit, avec trois prix totaux. Semaines 5 et 6, la remise en route : tout à votre nom, dépendances à jour, publication sur les stores reprise, restauration testée, documentation. Si la décision est de réécrire, les semaines 5 et 6 deviennent le cadrage du nouveau projet, avec les données et les utilisateurs repris.
Une reprise, inventaire, récupération, audit, remise en route, se situe en catégorie 1 de notre grille de prix ; la réparation ou la réécriture, si l'audit les justifie, se chiffrent séparément, par écrit.
Les erreurs que nous voyons dans les reprises
- Demander « tout refaire » au premier appel. Un projet entier payé pour un code qui aurait tenu. Inventaire, récupération, audit, puis décision.
- Attendre que le prestataire réponde. Les stores n'attendent pas. La mise en demeure part le premier jour, la récupération par les plateformes en parallèle.
- Laisser une seule clé à l'ancien prestataire. SMS, paiement, serveur : une clé oubliée est une porte ouverte. Toutes révoquées, toutes recréées.
- Republier sous un nouveau compte sans prévenir les utilisateurs. Ils gardent l'ancienne application, qui meurt. Message dans l'ancienne version, migration des données, redirection.
- Reprendre sans sauvegarde testée. Le premier incident après la reprise efface tout. Une restauration réelle avant de toucher à quoi que ce soit.
- Refaire la même erreur avec le nouveau prestataire. Comptes à son nom, code livré à la fin. Le kit de propriété s'installe le premier jour de la reprise.
Questions fréquentes
- Mon développeur a disparu avec le code, que faire en premier ?
- L'inventaire : listez les comptes stores, le domaine, l'hébergeur, le dépôt de code, la base et les services tiers, et notez pour chacun à quel nom il est enregistré. Relisez le contrat. Puis la récupération actif par actif, avec une mise en demeure écrite le premier jour si le contrat le permet.
- Peut-on récupérer une application publiée sous le compte Google Play du prestataire ?
- Google Play et l'App Store ont une procédure de transfert vers un autre compte, qui exige la coopération du titulaire. Sans elle, l'application se republie sous votre compte avec un nouvel identifiant, et vos utilisateurs doivent la réinstaller, avec un message dans l'ancienne version et une migration des données.
- Les données de mes clients m'appartiennent-elles ?
- Oui. Les données de vos clients vous appartiennent et la loi 18-07 vous rend responsable de leur protection. L'export est exigible du prestataire ou de l'hébergeur, et il est la première chose à sauvegarder une fois l'accès récupéré.
- Faut-il tout réécrire ?
- Seulement si l'audit le constate : code illisible, technologie plus maintenue ou données irrécupérables. Dans les autres cas, on garde ou on répare la partie fragile. La décision se prend en semaine quatre, sur l'audit écrit, avec trois prix totaux, pas au premier appel.
- Pourquoi est-ce plus urgent en 2027 ?
- Parce que les stores retirent les applications qui ne ciblent pas une version récente du système, que la vérification mondiale des développeurs Android annoncée pour 2027 ferme la porte à l'APK distribué à la main, et que le paiement et les données personnelles sont désormais encadrés. Une application que personne ne peut mettre à jour a une date de fin.
- Comment éviter que ça se reproduise ?
- Par le kit de propriété : comptes stores, domaine et hébergeur à votre nom avec double authentification, dépôt de code à votre nom où le prestataire est invité, accès et clés chez vous, contrat avec cession du code à chaque paiement et clause de réversibilité, documentation d'une page. Installé le premier jour de la reprise.