Dette technique d'une application mobile : peut-elle encore être sauvée ?

La dette technique désigne les raccourcis de code pris pour aller vite, qui rendent chaque nouvelle fonctionnalité plus lente et plus risquée à ajouter. Sur les projets mobiles, elle s'accumule surtout quand une fonctionnalité est développée sans être testée et validée avant de passer à la suivante.

Vous avez investi 9 500€ ou 80 000€ dans le développement de votre app. Le dev vous envoie une vidéo finale après 8 semaines : tout est codé, tout est là, on est prêt à publier. Vous installez la build, vous testez le parcours principal, et là : un crash sur l'inscription. Un bouton qui ne fait rien. Un écran qui se charge à l'envers sur Android. Et le développeur qui vous dit : « on va corriger, mais ça va prendre 2 à 3 semaines en plus parce qu'on doit retoucher plusieurs choses qui s'imbriquent ».

Bienvenue dans la dette technique : un scénario qui revient sans arrêt dans les retours de fondateurs sur les projets d'apps mobiles mal cadrés. La cause n'est presque jamais le talent du développeur. La cause, c'est le process : l'absence de validation continue, fonctionnalité par fonctionnalité, pendant le développement. Voici ce que ça veut dire concrètement, comment évaluer si votre application se corrige ou se refait, et comment j'applique cette discipline sur chaque projet Zuhd Studio.

C'est quoi la dette technique d'une app mobile (et pourquoi c'est invisible au début)

La dette technique, dans un projet mobile, ce sont toutes les décisions de code prises dans l'urgence, sans validation, sans test, qui s'accumulent les unes sur les autres jusqu'au moment où plus rien ne tient. Imaginez une pile de cartons mal empilés : les trois premiers tiennent. À partir du dixième, un seul mouvement et tout s'effondre.

Ce qui rend la dette technique particulièrement dangereuse sur une app mobile :

• Elle est invisible au fondateur non technique pendant 80% du dev. Le code progresse, les écrans se dessinent, tout semble bien aller.
• Elle se révèle au pire moment : juste avant le lancement, quand tout le monde teste sérieusement et qu'on découvre que les fonctionnalités s'auto-cassent.
• Elle a un effet d'intérêt composé : chaque correction tardive en révèle deux autres, qui en révèlent quatre, etc.
• Elle fait reculer la date de publication de plusieurs semaines, parfois plusieurs mois, et coûte deux à trois fois plus cher à corriger qu'à éviter.

La dette technique sur mobile, ce n'est pas une vue de l'esprit. Selon une étude Stripe / Harris Poll, les développeurs passent en moyenne 17,3 heures par semaine à gérer de la dette ou de la maintenance : 33% du temps de dev. Sur un projet mobile mal cadré, ce ratio explose après quelques semaines.

Le scénario qui tue la plupart des projets : tout coder en bloc, tester à la fin

Voici le scénario le plus courant derrière une application livrée pleine de bugs. Si vous reconnaissez votre projet là-dedans, ce n'est pas une coïncidence : c'est la norme du marché quand un projet est développé sans validation continue.

Semaine 1 à 4 : tout va bien (en apparence)

Le développeur code dans son coin. Vous recevez une réunion de suivi par semaine, parfois moins. Quelques captures d'écran sont partagées. Le dev dit « j'avance bien », vous dites « super ». Personne n'a installé l'app sur un vrai téléphone. Personne n'a testé un parcours réel. La conversation porte sur le calendrier, pas sur la qualité.

Semaine 5 à 7 : les premiers signaux faibles

Le développeur commence à dire : « on verra ça à la fin », « j'ai pris une option qu'on pourra changer plus tard », « il faut qu'on revienne sur l'écran X mais pas tout de suite ». Ce vocabulaire est le signal d'alarme. Chaque « on verra » est une dette qu'on s'engage à payer plus tard, à un taux d'intérêt qu'on ignore.

Semaine 8 : la livraison qui ne ressemble à rien

Vous recevez la build. Vous testez. La moitié des fonctionnalités a un comportement inattendu. Le design ressemble à 70% à la maquette, pas à 100%. Sur Android, certains écrans débordent. La création de compte met 8 secondes. Vous remontez 30 points au dev. Il vous répond que sur les 30 points, 18 nécessitent de retoucher l'architecture qu'il a choisie en semaine 2 sans vous demander.

À ce moment-là, vous êtes piégé. Soit vous acceptez de livrer une app dégradée, soit vous engagez 4 à 6 semaines de plus et un budget que vous n'aviez pas prévu. C'est exactement ce que le cadrage initial doit éviter, mais sans process de validation continue, même un bon cadrage ne suffit pas.

Comment j'évalue la dette d'une application qu'on me confie

L'ordre compte, et il est toujours le même : d'abord l'usage, ensuite le code. Avant tout devis, l'application est testée comme le ferait un utilisateur (inscription, connexion, action principale, paiement si applicable, sur au moins deux appareils) pour lister précisément ce qui casse. C'est ce test qui sert de base au devis, pas la lecture du code.

Une fois le devis signé et le code transmis, six signaux permettent de juger si la dette est gérable ou si mieux vaut repartir sur une base saine : présence de tests, documentation minimale, cohérence de l'architecture, absence de secrets codés en dur, historique Git exploitable, dépendances à jour. Cette étape ne change ni le prix ni le délai déjà signés : elle détermine seulement si l'application se corrige ou se refait en Flutter.

Ces six signaux sont aussi ceux que couvre le guide gratuit, pour les vérifier vous-même avant de payer un audit.

La méthode Zuhd : une fonctionnalité, une livraison, une validation

Ce qui suit est la méthode appliquée à partir du moment où la reprise démarre, que l'application soit corrigée fonctionnalité par fonctionnalité ou refaite entièrement, la discipline est la même : plus jamais de « test à la fin ».

Sur chaque projet ZUHD, la règle est simple et elle est non négociable : aucune fonctionnalité n'est marquée « terminée » tant qu'elle n'a pas été testée par moi puis validée par le client. Et tant qu'elle n'est pas validée, on ne passe pas à la suivante.

Concrètement, voici comment se déroule une semaine type sur un MVP de 60 jours :

Étape 1 : je code la fonctionnalité en isolation

Je prends une fonctionnalité du backlog (ex : « inscription par email avec vérification »). Je la code de bout en bout : UI, logique, backend, gestion d'erreur, cas limites. Je la teste sur deux devices physiques (un iPhone récent, un Android d'il y a 3 ans pour valider les performances).

Étape 2 : je tourne une vidéo de démo (ou une build TestFlight)

Selon la fonctionnalité, je vous envoie l'un de ces trois formats :

• Vidéo Loom 2-5 minutes où je joue le parcours complet en commentant chaque écran. Idéal pour les fonctionnalités où vous n'avez pas besoin de manipuler vous-même (ex : algorithme de matching, traitement en arrière-plan).
• Build TestFlight (iOS) ou APK signé (Android) avec un compte de démo. Vous installez sur votre propre téléphone, vous testez à votre rythme, dans votre vie réelle. Format obligatoire pour tout ce qui touche à l'UX (onboarding, navigation, formulaires).
• Call de 30 minutes en partage d'écran. On teste ensemble en live, je peux répondre à vos questions immédiatement. Format réservé aux fonctionnalités complexes ou aux moments décisifs (validation du flow d'achat in-app, par exemple).

Étape 3 : vous me revenez sous 24h

Je vous demande explicitement un retour dans les 24h ouvrées. Trois réponses possibles :

• « C'est validé » → je passe à la fonctionnalité suivante.
• « C'est validé sauf X » → je corrige X dans la journée, on reboucle.
• « Ce n'est pas ce que j'avais en tête » → on prend 30 minutes au téléphone pour aligner avant de continuer. Mieux vaut perdre 30 minutes là que 3 jours plus tard.

Étape 4 : la fonctionnalité validée passe en zone gelée

Une fois validée, la fonctionnalité est protégée. On ne la touche plus, sauf si un changement majeur l'exige. Cette discipline est ce qui permet d'avancer en confiance : à chaque nouvelle fonctionnalité, vous savez que tout ce qui a été validé avant continue de marcher.

Comment se passe concrètement une validation : design, fonctionnalités, déploiement

La validation continue ne s'applique pas qu'au code. Elle s'applique aux trois phases du projet, parce que chacune produit sa propre dette si on la traite à la légère.

Phase 1 : la validation design, écran par écran

Avant la première ligne de code, on valide ensemble chaque écran : layout, composants, hiérarchie visuelle, états (vide, chargement, erreur). Pas une validation globale « le style me plaît », mais une validation détaillée écran par écran. Pourquoi ? Parce qu'un retour design en plein dev casse tout : l'architecture des composants a souvent été pensée pour les maquettes initiales, et changer un layout à mi-projet déclenche une cascade de retouches.

Cette discipline rejoint tout ce qui doit être réglé avant d'écrire la première ligne de code. Une heure de validation design en amont économise une journée de retouche en aval. Et surtout, elle vous évite de découvrir au lancement que l'app ne ressemble pas à ce que vous aviez en tête.

Phase 2 : la validation des fonctionnalités, une par une

C'est le cœur du process décrit plus haut. Chaque fonctionnalité est livrée, testée, validée, gelée. On avance par briques solides, pas par couches superposées qui peuvent toutes s'effondrer en même temps.

Phase 3 : la validation du déploiement et de la fiche store

Le déploiement n'est pas un événement de dernière minute. C'est une phase à part entière, qui se prépare. Sur chaque projet ZUHD, voici ce qu'on valide ensemble avant la soumission :

• Le copywriting de la fiche App Store et Play Store : titre, sous-titre, description, mots-clés. Optimisés pour le référencement (ASO), pas écrits à la va-vite. Ce travail conditionne 60% de vos téléchargements organiques.
• Les screenshots : 6 à 8 captures cohérentes, avec textes overlay qui vendent les bénéfices, pas les fonctionnalités. Format adapté à chaque taille d'écran (6.7", 6.5", 5.5", iPad).
• Les comptes développeur : Apple Developer (99€/an) et Google Play (25€à vie) doivent être créés au bon moment et à votre nom, pas au mien. C'est votre app, vos comptes, votre propriété. On en parle aussi dans l'article sur la propriété du code source.
• La privacy policy, les CGU, la fiche App Privacy d'Apple, la Data Safety de Google : tout est rempli proprement avant la soumission, jamais dans la panique. Pour creuser les pièges, voir les 7 raisons de refus d'Apple.

Le retour sous 24h : ce que ça change vraiment

L'engagement « retour sous 24h » n'est pas une formule commerciale. C'est une mécanique de qualité. Voici pourquoi.

Le contexte est encore frais

Quand vous me dites « j'ai testé, le bouton X ne réagit pas » dans les 24h après avoir reçu la build, j'ai encore tout le contexte technique en tête. Je sais exactement quel fichier toucher, quelle dépendance regarder, quelle hypothèse j'avais prise. Le même bug remonté 10 jours plus tard, je dois recharger tout le contexte. Le coût en temps est multiplié par trois.

Pas de fonctionnalités empilées avant validation

Sans engagement de retour, certains clients laissent passer 2-3 fonctionnalités avant de tester. Quand le bug remonte enfin, il a affecté potentiellement les 3 fonctionnalités qui suivent. La correction coûte alors 4x plus cher : on ne corrige pas une fonctionnalité, on en corrige quatre.

Engagement bilatéral

Je m'engage à vous livrer une fonctionnalité testée à chaque cycle. Vous vous engagez à la valider sous 24h. Cette symétrie évite la situation où l'un attend l'autre. Sur un MVP de 60 jours, on ne peut pas se permettre 4 jours d'attente par fonctionnalité : on aurait des semaines mortes.

Côté maintenance post-lancement, le même principe s'applique : tout incident remonté est pris en charge sous 24h ouvrées. C'est ce qui rend l'offre MVP Care à 199€/mois tenable pour vous, et pour moi (avec un nombre de places limité, sinon le SLA s'écroule). Sur le sujet maintenance, cet article détaille ce qui se passe vraiment après le lancement.

Pourquoi cette discipline produit zéro dette au lancement

Quand on livre par briques validées et gelées, le résultat à J+60 n'est pas « une app à finir de tester ». C'est une app dont chaque fonctionnalité a déjà passé un cycle test → validation → correction → re-validation. Le travail de qualité n'est pas concentré dans la dernière semaine. Il est distribué sur les 8 semaines.

Ce que ça produit concrètement, comparé à la livraison classique en bloc :

• Zéro surprise au lancement. Vous avez déjà vu, manipulé et validé chaque écran avant la phase de soumission. La build finale est un assemblage de fonctionnalités déjà connues, pas une découverte.
• Une soumission sans refus. Sur les 3 apps livrées avec ce process, aucune n'a été refusée à la première soumission App Store ou Play Store. Ce n'est pas un coup de chance : la qualité validée à chaque étape se voit dans le build final que le reviewer Apple teste.
• Une rétention plus élevée à J+1. Une app sans bugs visibles, sans crash, sans temps de chargement aberrant retient mécaniquement plus d'utilisateurs. Pour creuser ce sujet, voir les 5 métriques de rétention à suivre dès J+1.
• Une maintenance qui coûte vraiment 199€/mois et pas 1 200€. Une app sans dette technique = une app stable. Les deux mois de MVP Care offerts couvrent largement les ajustements OS (mise à jour iOS, Android), pas des corrections de fond. Une app pleine de dette demanderait un développeur à plein temps pour la stabiliser.

Ce process n'est pas magique. C'est juste de la discipline appliquée à un cycle court. Mais c'est cette discipline qui fait la différence entre une app qui se lance dans les délais et dans le budget, et une app qui prend 4 mois de plus, qui coûte 30% en plus, et qui sort dégradée par rapport à la promesse initiale.

Ce que vous devez exiger de votre prestataire (même si ce n'est pas moi)

Si vous travaillez déjà avec un freelance, une agence ou un autre studio, voici les 5 questions à poser dès demain pour évaluer si votre projet est sur la bonne trajectoire :

• « À quelle fréquence puis-je tester une build sur mon téléphone pendant le dev ? » La bonne réponse : toutes les semaines au minimum. Si la réponse est « à la fin », vous payez de la dette technique.
• « Comment se déroule la validation de chaque fonctionnalité ? » Cherchez un process écrit. Pas juste « on en discute ».
• « Quel est votre engagement de réponse sur les bugs que je remonte ? » Sans engagement chiffré (24h, 48h ouvrées), il n'y a pas de SLA. Donc pas de réflexe qualité.
• « Comment gérez-vous les changements de scope en cours de dev ? » Une bonne réponse explicite ce qui peut changer (priorisation, ajustements UX) et ce qui ne peut pas (architecture, base de données) sans rallonger le projet.
• « Que se passe-t-il les 60 jours après la publication ? » Si la réponse est « on verra », vous allez payer une maintenance imprévue. Si c'est « deux mois inclus », le prestataire prend la qualité au sérieux.

Pour aller plus loin sur le choix du prestataire, j'ai écrit un comparatif honnête entre freelance, agence et studio qui explique les vrais écarts de qualité et de risque entre les trois modèles.

La dette technique n'est pas une fatalité. C'est juste l'absence de process. Avec le bon process, votre app peut sortir à l'heure, dans le budget, avec un code propre, sans crash, et avec un fondateur qui dort la nuit. C'est tout l'intérêt d'avoir un cadre clair dès le départ, et de s'y tenir.