Progress: 0%
Scroll for premium experience
retour
DEBUG|4 Décembre 2025|5 min

Debug mobile : quand les embeddings ne répondent plus

temps humain:1h 30
|
temps IA:20 min

NEO fonctionnait parfaitement sur desktop. Sur mobile, les requêtes timeout après 30 secondes. Même code, même API. Le problème était ailleurs. Voici comment on a diagnostiqué et résolu un bug qui n'apparaissait que sur mobile.

Le symptôme

Desktop (Chrome DevTools) : Réponse en ~0.8s

Mobile (Safari iOS) : Timeout après 30s, puis erreur réseau

Même endpoint API. Même requête. Résultats différents.

Premier réflexe : vérifier les logs serveur. Les requêtes mobile n'arrivaient même pas au backend.

Diagnostic pas à pas

Étape 1 : Network tab mobile

On a activé le debug Safari distant sur iPhone. Les requêtes partaient, mais restaient en "pending" indéfiniment.

Étape 2 : Reproduire en local

Même comportement sur localhost via l'IP locale (192.168.x.x). Le problème n'était pas lié à la production.

Étape 3 : Simplifier la requête

On a testé avec un payload minimal. Ça fonctionnait. Donc le problème était lié à la taille des données.

Étape 4 : Identifier le coupable

Notre requête envoyait un contexte de 50KB (historique de conversation). Mobile Safari coupait les requêtes volumineuses sur connexion instable.

La solution

Le problème : On envoyait l'historique complet à chaque requête (50KB+).

La solution : Pagination du contexte.

Implémentation :

  • 1. Stocker l'historique côté serveur (session ID)
  • 2. Envoyer uniquement le dernier message + session ID
  • 3. Le serveur reconstruit le contexte depuis son cache
  • Résultat :

  • - Payload : 50KB → 500 bytes
  • - Temps de réponse mobile : 30s timeout → 1.2s
  • - Bonus : moins de tokens consommés (contexte géré côté serveur)
  • Ce que Claude Code a fait

    Prompt :

    "Les requêtes RAG timeout sur mobile. Desktop OK. Même code. Diagnostic et fix."

    Ce que l'IA a proposé (20 min) :

  • 1. Ajout de logs détaillés pour tracer le flow
  • 2. Test de connectivity basique (ping endpoint)
  • 3. Identification du problème de payload size
  • 4. Refactoring vers session-based context
  • Ce que j'ai fait (1h 30) :

  • 1. Tests manuels sur différents devices
  • 2. Debug Safari distant (configuration fastidieuse)
  • 3. Validation que la solution ne cassait pas les features existantes
  • 4. Tests de régression
  • Ce qu'il faut retenir

    • -Un bug "ça marche sur mon PC" est souvent lié au réseau ou à la taille des données.
    • -Safari iOS a des limites plus strictes que Chrome sur les requêtes volumineuses.
    • -Session-based context > Envoyer tout l'historique à chaque fois.
    • -Le debug mobile prend plus de temps que le fix lui-même.

    Stack

    Safari Remote DebugFastAPISession ManagementClaude Code
    debug mobile | RAG mobile optimization | Safari iOS timeout | payload size limit | vibe coding debug | formation vibe coding suisse

    D'autres articles dans le journal

    On documente tout ce qu'on fait.

    Vibe Coding | Formation Vibe Coding Suisse | Journal IA & Développement | OSOM