Documentation d'une application mobile : checklist de passation

Le résultat attendu : une entreprise autonome

Une passation réussie répond à des questions très concrètes. Où se trouve la version exacte du code en production ? Qui paie et administre les services ? Comment restaurer les données ? Que reste-t-il à corriger ? Qui peut publier sur les stores ?

Un lien vers un fichier ne suffit donc pas toujours. Certains livrables sont des droits d'administration, une démonstration, un inventaire ou une décision métier consignée.

Commencer par le produit et le design

La nouvelle équipe doit comprendre ce que fait l'application aujourd'hui, pas ce qui avait été imaginé au premier atelier. Remettez les parcours à jour, les règles métier importantes, les notes de la dernière version et la liste des fonctions réellement actives.

Les sources de design doivent être modifiables. Un dossier de captures ou d'images exportées ne permet pas de maintenir une interface. Il faut le fichier Figma ou équivalent, les composants, les variantes, les styles, les icônes, les polices et les droits d'utilisation des ressources.

Conservez surtout les décisions difficiles à déduire de l'écran. Pourquoi un remboursement partiel suit-il ce calcul ? Quand une réservation devient-elle définitive ? Quelle information reste après la suppression du compte ? Ce contexte évite à l'équipe suivante de casser une règle sensible par manque d'information.

Ajoutez enfin les anomalies connues et le travail reporté. Distinguez un défaut confirmé, une contrainte acceptée et une idée future. Précisez l'impact, la version concernée, la solution provisoire et la priorité.

Faire l'inventaire des comptes et des factures

Pour chaque service, notez son usage, le titulaire, les administrateurs, le contact de facturation, la date de renouvellement et le moyen de récupération. Cet inventaire couvre généralement Apple, Google, le cloud, la base de données, le domaine, les courriels, les SMS, les cartes, les paiements, les statistiques, les erreurs et le service client.

Dans un développement sur mesure, l'entreprise cliente devrait normalement contrôler les comptes essentiels. Le prestataire reçoit des droits adaptés à son travail. Un identifiant personnel partagé par toute l'équipe complique la traçabilité et le départ d'un collaborateur.

La différence entre accès et propriété doit être écrite avant la livraison. Les questions à poser à une agence mobile permettent d'intégrer ce sujet dès la comparaison des offres.

Prouver que le code reconstruit la version publiée

Récupérez les dépôts de l'application, du serveur, de l'interface d'administration et de la configuration technique éventuelle. Une archive supplémentaire est utile, mais elle ne remplace pas l'historique, les branches et les repères de version.

Le guide de démarrage doit indiquer les versions des outils, l'installation des dépendances, le nom des variables nécessaires, les commandes de test et la création d'une version. Les secrets ne doivent pas être collés dans le dépôt. Ils sont conservés dans un espace sécurisé appartenant à l'entreprise.

Demandez à un développeur extérieur au projet de repartir d'un poste vierge. Il suit uniquement les instructions et produit une application de test. La checklist de remise du code de Koder recommande cette vérification de reproductibilité, beaucoup plus révélatrice qu'un simple contrôle de fichiers.

Associez chaque version des stores au bon état du code et du serveur. Sans ce repère, une petite correction peut repartir d'une base incompatible avec la production.

Vérifier les données et le plan de reprise

Un schéma lisible doit montrer l'application, le serveur, la base, le stockage des fichiers, les services externes et l'interface d'administration. Il ne s'agit pas d'un cours d'architecture, mais d'une carte qui aide à comprendre les dépendances.

Documentez les évolutions de la base, l'export, la conservation des données et les sauvegardes. Puis restaurez une sauvegarde récente dans un environnement isolé. Un statut vert dans le tableau du fournisseur ne garantit ni l'intégrité ni la récupération.

La surveillance fait également partie de la reprise. Qui reçoit les alertes de panne, les erreurs de paiement ou les pics d'échec ? Mettez à jour les destinataires et testez un signal avant de supprimer les anciens accès.

Pour un produit ancien, associez cette démarche à un audit de modernisation et à une estimation de la maintenance. La passation révèle souvent des dépendances obsolètes qu'il faut stabiliser avant tout nouveau chantier.

Reprendre les stores sans perdre des éléments

Le guide de publication précise la configuration, la numérotation des versions, la signature, les canaux de test, les identifiants fournis à l'équipe de validation et le retour à une version stable.

Apple propose une procédure pour transférer une app dans App Store Connect. Google explique ce qui accompagne le transfert vers un autre compte. Certains rapports, groupes de test et droits liés à Firebase, Analytics ou d'autres services demandent une action distincte.

Les clés de signature ne doivent pas circuler dans un courriel non protégé. Définissez leur stockage, leurs utilisateurs et leur rotation. Pour Google Play App Signing, différenciez bien la clé de mise en ligne de la clé de signature de l'application.

Organisez une publication sur un canal interne avec les deux équipes. La personne qui reprend observe, puis répète la procédure. Une courte vidéo peut compléter l'écrit, mais l'écrit reste plus simple à actualiser.

Une répétition générale en cinq étapes

La passation peut être validée par cinq résultats visibles :

1. Un nouveau développeur construit l'application sur une machine propre.
2. Le responsable ouvre l'interface d'administration et retrouve le contexte d'un incident.
3. Une sauvegarde est restaurée dans un environnement sûr.
4. Une version est préparée pour un canal de test du store.
5. Un accès de démonstration est retiré et cette action reste traçable.

La checklist ouverte de Futurice considère la passation comme un mini-projet avec responsables et calendrier. La checklist Catalyst insiste elle aussi sur la capacité d'une autre organisation à reprendre les sources, la documentation et les créations.

Accepter, corriger ou refuser la livraison

Demandez une correction avant l'acceptation si l'application ne peut être construite que sur l'ordinateur d'une personne, si les stores appartiennent à un prestataire injoignable, si les secrets sont dans le code ou si aucune sauvegarde n'a jamais été restaurée.

Méfiez-vous également des formulations vagues. "Hébergé dans le cloud" ne donne ni fournisseur, ni projet, ni administrateur, ni facturation, ni récupération. Chaque dépendance essentielle doit être nommée.

Les droits sur le code, les polices et les contenus dépendent du contrat et de la juridiction. Lorsque l'enjeu le justifie, faites vérifier ces points par un juriste. La checklist technique signale les pièces manquantes, mais ne remplace pas un avis légal.

La méthode Appfyl

Pour une nouvelle application, nous établissons tôt une carte de propriété : code, design, stores, données, infrastructure, services externes et support. Les comptes stratégiques peuvent ainsi être créés au bon nom.

À l'approche de la mise en ligne, la version acceptée est reliée à ses dépôts, ses sources graphiques, ses environnements et ses incidents connus. Pour une application héritée, nous vérifions d'abord ce qui peut réellement être ouvert, construit et administré.

Le brief d'estimation Appfyl aide à recenser les rôles et les intégrations. Ces mêmes éléments auront besoin d'un propriétaire et d'une consigne d'exploitation lors de la passation.

Voir comment Appfyl transforme un périmètre en produit lancé. Voir les cas Appfyl.

Questions fréquentes