Votre application Flutter a déjà été diagnostiquée : des crashs, lenteurs, problèmes de mémoire, incidents de production ou angles morts d'observabilité ont été identifiés. Vous devez maintenant corriger ce qui est prioritaire sans lancer une refonte inutile ni intervenir au hasard.

Je vais réaliser un sprint de stabilisation de votre application Flutter à partir d'un diagnostic technique validé.

Cette prestation ne consiste pas à appliquer une liste indéfinie de corrections. Elle transforme un problème identifié en plan d'action, code corrigé, tests et preuves de vérification. Le périmètre est fixé avant le démarrage afin que vous sachiez ce qui sera traité, ce qui restera à faire et comment le résultat sera contrôlé.

## Ce que comprend le sprint de base

### 1. Confirmation du périmètre et du point de départ

Je reprends le diagnostic, les symptômes, les conditions de reproduction et les critères de vérification. Si une donnée manque, elle est signalée avant toute modification afin de ne pas promettre une correction sur une hypothèse non confirmée.

### 2. Observabilité minimale obligatoire

Si l'application ne possède pas d'outil exploitable de remontée d'erreurs, j'installe ou configure la base nécessaire dans l'application : Crashlytics ou Sentry, selon la stack existante et les accès fournis.

Cette étape comprend la vérification de réception d'un événement de test sur un environnement de test lorsque cela est possible. Si un outil est déjà présent, je vérifie ou améliore les informations nécessaires au suivi des incidents concernés.

### 3. Correctifs prioritaires convenus

Je corrige le problème principal ou les problèmes P0/P1 explicitement retenus dans le périmètre : par exemple une fuite de ressources, un démarrage anormalement bloquant, un écran lourd, un crash reproductible, une liste non paginée ou une remontée d'erreur insuffisante.

Les corrections dépendent toujours de la cause réellement confirmée. Une refonte complète, un backend défaillant, un SDK tiers ou un nouveau problème indépendant ne sont pas inclus automatiquement.

### 4. Tests et vérification

Je teste les parcours directement concernés par les modifications. Lorsque le problème et l'environnement le permettent, je compare le comportement avant et après : reproduction du bug, démarrage, rendu d'écran, réception d'événement, consommation observée ou autre critère convenu.

### 5. Livraison et rapport de clôture

Vous recevez :

- le code source des changements, sous forme de commit, branche ou archive selon le mode de collaboration ;
- la liste des composants et fichiers modifiés ;
- les correctifs appliqués et leur justification ;
- les tests réalisés ;
- les mesures ou preuves avant/après lorsque elles sont techniquement réalisables ;
- la preuve de réception d'un événement de test par l'outil d'observabilité lorsque cet outil est inclus ;
- les risques restants, limites connues et actions recommandées après livraison.

## La garantie incluse

Pendant quatorze jours après la livraison, je corrige sans frais les régressions directement causées par les modifications que j'ai livrées, dans le périmètre validé.

Cette garantie ne couvre pas :

- une nouvelle fonctionnalité ou un changement de besoin ;
- un problème indépendant de l'intervention ;
- un backend, un service tiers ou une infrastructure non inclus dans le périmètre ;
- une mise à jour d'Android, iOS, Flutter ou d'une dépendance après livraison ;
- des appareils, comptes ou conditions qui n'étaient pas accessibles durant les tests ;
- une promesse de zéro crash, de sécurité certifiée ou d'absence de tout incident futur.

## Ce service est fait pour vous si

- vous possédez le code source et les accès nécessaires ;
- un diagnostic a déjà identifié les problèmes prioritaires ;
- un décideur peut valider rapidement le périmètre et les accès ;
- vous voulez corriger des incidents de production et installer une base de suivi durable ;
- vous acceptez de traiter d'abord le risque le plus important plutôt que de demander une refonte complète.

## Ce qui n'est pas inclus

- correction illimitée de tous les problèmes de l'application ;
- développement de nouvelles fonctionnalités non liées au diagnostic ;
- refonte globale de l'architecture ;
- audit de sécurité complet, test d'intrusion ou certification ;
- surveillance quotidienne illimitée ;
- publication App Store ou Google Play ;
- correction d'un backend, service tiers ou infrastructure non accessible.