Missing — Reprendre une app en production et la remettre d’aplomb

Le problème

L’app est en production mais chaque nouvelle fonctionnalité introduit des régressions. Les utilisateurs rencontrent des crashes, des comportements incohérents, des données qui ne s’affichent pas correctement.

En auditant le code, je découvre l’ampleur du problème : plus de 700 cas de fuites mémoire et de data races non protégées. Des secrets d’API écrits en dur dans le code source. Des endpoints qui renvoient plus de données que nécessaire — le filtrage est fait côté app au lieu d’être fait côté serveur, ce qui signifie que quelqu’un interceptant les échanges réseau pourrait accéder à des données qui ne le concernent pas. Règle de base en développement : le serveur ne doit jamais faire confiance au client.

Les pages statiques buggaient à cause d’appels API qui bouclaient. Les champs de recherche ne fonctionnaient pas correctement et les filtres étaient quasi tous cassés.

Le backend en CakePHP — un framework que je n’avais jamais utilisé — a les mêmes problèmes : pas de validation stricte, pas de contrôle d’accès rigoureux sur les endpoints critiques.

En résumé : une communauté qui grandit, un produit qui ne suit pas.

L’intervention

Avant de toucher au code, j’audite. Je trace les flux de données, j’identifie les points critiques, je classe les problèmes par sévérité. L’objectif n’est pas de tout réécrire — c’est de stabiliser ce qui existe et de corriger ce qui est dangereux.

Sécurité et stabilité — le socle

Je reprends les 700+ cas de fuites mémoire et de data races un par un. Je supprime les secrets d’API hardcodés dans le code source. Je restructure les endpoints backend pour que le serveur ne renvoie que les données auxquelles l’utilisateur a droit — le filtrage passe côté serveur, là où il aurait toujours dû être. Je corrige les appels API qui bouclaient et faisaient planter les pages statiques. Je reprends les endpoints de recherche et les filtres pour qu’ils fonctionnent enfin sur l’ensemble de l’app. Ce travail n’est pas visible pour l’utilisateur, mais c’est ce qui fait la différence entre une app qui crashe et une app qui tient.

Les features reprises de zéro

Plusieurs fonctionnalités existaient mais ne fonctionnaient pas correctement.

Le système SOS — qui permet de faire sonner le téléphone de ses proches, partager sa localisation en direct et lancer une vidéo live — fonctionnait partiellement. Les alertes critiques iOS n’étaient pas implémentées correctement, et le flow d’abonnement censé protéger cette feature était contournable à cause d’un bug. J’ai repris le système complet : alertes critiques Apple fonctionnelles, abonnement sécurisé, flux de bout en bout.

Le chat de l’app était basique — pas de modification ni suppression des messages, pas de groupement visuel des bulles par utilisateur, notifications approximatives. Je l’ai repris pour en faire un chat moderne avec ces fonctionnalités.

Avant

Après

L’internationalisation était bancale sur l’ensemble de l’app — textes manquants, langues mélangées. Repris et corrigé intégralement.

Ce que j’ai apporté au produit

Au-delà de la stabilisation, j’ai développé de nouvelles fonctionnalités et amélioré celles qui existaient.

Une carte interactive des bénévoles, qui géolocalise les bénévoles inscrits sur une carte du monde. J’ai poussé le concept plus loin : quand un utilisateur booste son mandat, il peut consulter les bénévoles présents dans le rayon du boost et en ajouter directement à sa recherche. L’idée de ce flow vient en grande partie de moi.

Avant

Après

La section “objets trouvés” affichait toutes les informations en clair — description détaillée, localisation exacte — avant même que l’utilisateur n’ait payé pour contacter l’auteur de l’annonce. Plus aucune raison de payer. J’ai flouté ces informations avec défloutage et mise en contact au moment du paiement.

Pour la section “perdus de vue”, les utilisateurs avaient un mois gratuit puis devaient payer, mais n’étaient jamais prévenus et ne comprenaient pas comment remettre leur annonce en ligne. J’ai conçu et implémenté un système d’abonnement annuel via l’App Store avec un mois de free trial intégré — gestion complète côté backend : annulation, paiement refusé, renouvellement, tout est automatique et transparent.

Les utilisateurs supprimaient leurs mandats au lieu de les marquer comme retrouvés. Le flow ne proposait pas d’alternative claire. J’ai ajouté une question intermédiaire : “Avez-vous retrouvé cet objet ?” — si oui, redirection vers l’écran “marquer comme retrouvé” ; si non, confirmation de suppression.

Le résultat

En 4 mois, seul sur l’iOS et développeur principal sur le backend :

Pendant cette période, l’app est passée de 45 nouveaux inscrits par mois à plus de 1 000. La communauté — portée par le travail d’AMEVA sur les réseaux sociaux — a trouvé un produit qui fonctionne enfin à la hauteur de son ambition. Et ce qui est décrit ici n’est pas exhaustif — en 4 mois seul sur l’iOS et principal sur le backend, le volume de travail dépasse ce qu’une étude de cas peut couvrir.

Ce que ce projet montre

Reprendre un projet existant, c’est souvent plus difficile que de partir de zéro. Il faut comprendre les décisions des développeurs précédents — même quand elles n’ont aucune logique — avant de pouvoir les corriger sans tout casser.

Sur Missing, la priorité était double : rendre l’existant fiable ET continuer à faire avancer le produit. Sécuriser les données, stabiliser le code, corriger les flows — tout en livrant de nouvelles fonctionnalités.

C’est aussi sur ce projet que j’ai repris des pans entiers du backend en CakePHP — un framework que je ne connaissais pas. Quand le projet l’exige, je ne m’arrête pas aux frontières de ma stack habituelle.