Application mobile à Mulhouse : créer, ou reprendre l'existant

Nous publions nos propres applications sur Google Play. Nous connaissons la revue, ses refus, les versions cibles imposées chaque année et les pages obligatoires, parce que nous les subissons sur nos applications, pas parce qu'on nous l'a raconté.

Entreprises, industriels et associations de Mulhouse et du Haut-Rhin.

Le cas le plus fréquent n'est pas la création

Une bonne partie des demandes ne concerne pas une application à créer, mais une application qui existe déjà et qui a cessé d'avancer. Le prestataire a changé de métier, l'interne qui s'en occupait est parti, ou la facture de maintenance a été coupée un jour où tout fonctionnait encore.

Trois symptômes reviennent, et ils n'ont pas la même gravité. L'application marche mais n'évolue plus : situation confortable et trompeuse, elle a une date de péremption. Elle a disparu du magasin : elle ne respecte plus la version cible imposée, ou une déclaration obligatoire n'a pas été mise à jour. Elle plante depuis une mise à jour du téléphone : le plus urgent, parce que vos utilisateurs le voient.

Les trois choses à vérifier avant même de demander un devis

Ces trois points décident du prix bien plus que le nombre d'écrans, et vous pouvez les vérifier vous-même en une heure. Sans eux, aucun devis de reprise n'est sérieux.

1. À qui appartient le compte développeur. Si l'application est publiée sous le compte de votre ancien prestataire, elle n'est pas juridiquement sous votre contrôle. Un transfert entre comptes existe, il se demande, et il prend du temps. C'est le premier appel à passer, avant tout chiffrage.

2. Qui détient les clés de signature. Une application Android publiée est signée. Sans la clé d'origine ou sans la signature déléguée à Google, vous ne pouvez pas publier de mise à jour de votre propre application : il faut en republier une nouvelle, et vos utilisateurs installés ne suivent pas. C'est le point qui transforme une reprise en recréation, et presque personne ne le vérifie à temps.

3. Où vivent les comptes utilisateurs. Si l'application a des utilisateurs inscrits, leurs données sont sur un serveur qui appartient à quelqu'un. Savoir lequel, et avec quels accès, décide de ce qu'on peut reprendre sans rien casser.

Ce qui se récupère, et ce qui se refait

Se récupère presque toujours : les écrans et le parcours, qui représentent le travail de conception le plus long, ainsi que les contenus et les données. Un code même ancien documente les règles métier réelles, y compris celles que personne ne sait plus énoncer.

Se refait souvent : la couche technique, quand elle repose sur un cadre applicatif abandonné ou sur des bibliothèques que les magasins n'acceptent plus. Il faut le dire franchement quand c'est le cas, plutôt que rafistoler une base qui coûtera plus cher en deux ans qu'une reprise propre.

La bonne question n'est donc pas « peut-on récupérer le code ? » mais « peut-on garder les utilisateurs, l'historique et le référencement du magasin ? ». On peut très bien tout réécrire en dessous et conserver les trois, à condition d'avoir réglé les points 1 et 2 ci-dessus.

Comment nous procédons

Un état des lieux d'abord, court et payant au juste prix, qui répond à trois questions : qu'est-ce qui vous appartient réellement, qu'est-ce qui bloque la publication aujourd'hui, et qu'est-ce que coûterait la remise en état par rapport à une reprise complète. Vous repartez avec ce document même si vous ne travaillez pas avec nous. Ensuite seulement on parle de développement, avec un devis fondé sur des faits plutôt que sur des hypothèses.