Difficultés et retours d'expérience

🔧 Difficultés et retours d’expérience

Difficultés techniques

1. Migration FastAPI → Laravel

Impact : Élevé

Contexte : Notre prototype initial était développé en FastAPI (Python). Nous avons décidé de migrer vers Laravel pour bénéficier d’un écosystème plus complet.

Problèmes rencontrés :

Réécriture complète du code backend
Perte de temps significative (3 semaines)
Courbe d’apprentissage de Laravel
Adaptation des patterns Python → PHP

Leçons apprises :

“Mieux vaut prendre le temps de choisir les bonnes technologies au départ que de devoir migrer en cours de projet.”

Résolution :

Documentation systématique des endpoints existants
Tests automatisés pour valider la migration
Migration progressive par modules

2. Performance du service IA

Impact : Critique

Contexte : La génération de cartes par l’IA prenait parfois plus de 30 secondes, causant des timeouts et une mauvaise expérience utilisateur.

Problèmes rencontrés :

Timeouts HTTP côté mobile
Coûts API OpenAI élevés
Latence variable selon la charge

Analyse :

flowchart LR
    subgraph Avant["❌ Avant optimisation ~30s"]
        direction TB
        A1["Extraction contenu"] -->|2s| A2["Appel LLM x10"]
        A2 -->|25s| A3["Validation"]
        A3 -->|3s| A4((30s))
    end
    
    subgraph Apres["✅ Après optimisation ~10s"]
        direction TB
        B1["Extraction contenu"] -->|1s| B2["Appel LLM batch"]
        B2 -->|8s| B3["Validation parallèle"]
        B3 -->|1s| B4((10s))
    end
    
    Avant -.->|"🚀 3x plus rapide"| Apres
    
    style Avant fill:#c62828,stroke:#ef5350
    style Apres fill:#2e7d32,stroke:#66bb6a
    style A4 fill:#b71c1c,stroke:#ef5350
    style B4 fill:#1b5e20,stroke:#66bb6a

Solutions implémentées :

Traitement asynchrone - Jobs Laravel Horizon
Batch processing - Générer plusieurs questions en un appel
Cache d’embeddings - Éviter les calculs redondants
WebSockets - Notification temps réel de fin de génération

3. Échec du lancement beta

Impact : Critique

Contexte : En décembre 2025, nous avons lancé une version beta qui s’est révélée être un échec technique majeur.

Bugs critiques découverts :

Bug	Impact	Cause
Crash au démarrage sur iOS 16	Bloquant	Dépendance incompatible
Perte de données synchronisation	Critique	Race condition
Lenteur extrême en offline	Majeur	Pas de cache local
Auth token expiré silencieusement	Majeur	Pas de refresh automatique

Retours utilisateurs :

“L’app crash à chaque ouverture” - 3 utilisateurs

“J’ai perdu toutes mes cartes” - 2 utilisateurs

“C’est inutilisable sans internet” - 5 utilisateurs

Leçons apprises :

Tests insuffisants : Notre couverture était de ~40%
Pas de beta testing : Nous avons publié directement
Feature creep : Trop de fonctionnalités ajoutées par peur

Plan d’action post-mortem :

Gel des nouvelles fonctionnalités
Focus 100% sur la stabilité
Suite de tests complète (400+ tests)
Programme de beta-testeurs privés
Monitoring et alertes en production

4. Gestion de l’état mobile

Impact : Modéré

Contexte : La synchronisation de l’état entre l’application et le serveur causait des incohérences.

Problèmes rencontrés :

État local désynchronisé après perte de connexion
Conflits lors de modifications simultanées
Cache local obsolète

Solution : Architecture avec Zustand + Query

// Avant : État global fragile
const [cards, setCards] = useState([]);

useEffect(() => {
  fetchCards().then(setCards);
}, []);

// Après : Cache intelligent avec invalidation
const { data: cards, isLoading } = useQuery({
  queryKey: ['cards', collectionId],
  queryFn: () => cardsService.getByCollection(collectionId),
  staleTime: 5 * 60 * 1000, // 5 minutes
});

5. Intégration des services cloud

Impact : Modéré

Contexte : Configuration de l’infrastructure Kubernetes sur OVHcloud.

Difficultés :

Documentation OVHcloud parfois incomplète
Configuration des secrets Kubernetes
Certificats SSL avec Let’s Encrypt
Debugging des pods en production

Résolutions :

Utilisation de Helm pour standardiser les déploiements
Mise en place de logs centralisés
Scripts d’automatisation du provisioning

Difficultés organisationnelles

1. Équipe de 2 personnes

Défis :

Charge de travail importante
Polyvalence obligatoire
Risque de burnout

Solutions adoptées :

Répartition claire des responsabilités
Rituels de synchronisation quotidiens
Priorisation impitoyable des tâches

2. Statut étudiant-entrepreneur

Défis :

Jongler entre cours et projet
Ressources financières limitées
Manque d’expérience business

Opportunités :

Accompagnement PEPITE
Concours et visibilité
Réseau d’entrepreneurs

3. Questions légales et éthiques

En cours

Questionnements :

Propriété intellectuelle du code
Utilisation des données utilisateurs
Éthique de l’IA dans l’éducation
Publication sur les stores

Actions entreprises :

Consultation d’un avocat spécialisé
Rédaction de CGU et politique de confidentialité
Charte éthique IA interne

Importance de la phase de conception

Architecture

Prendre le temps de concevoir l’architecture évite les migrations coûteuses

Tests

Écrire les tests AVANT le code (TDD) améliore la qualité

Documentation

Documenter les décisions techniques aide à la maintenance

Revue de code

Le regard d’un pair détecte les problèmes tôt

Méthodologie améliorée

Avant (Phase prototype) :

flowchart LR
    A["💡 Idée"] --> B["💻 Code"]
    B --> C["🖱️ Test manuel"]
    C --> D["🚀 Production"]
    B -.-> E["😱 Bugs en prod"]
    
    style A fill:#1565c0,stroke:#1976d2
    style B fill:#e65100,stroke:#f57c00
    style C fill:#f9a825,stroke:#fbc02d
    style D fill:#c62828,stroke:#ef5350
    style E fill:#b71c1c,stroke:#c62828

Après (Phase actuelle) :

flowchart LR
    A["💡 Idée"] --> B["📋 Conception"]
    B --> C["🧪 Tests"]
    C --> D["💻 Code"]
    D --> E["👀 Review"]
    E --> F["🧪 Tests"]
    F --> G["🎭 Staging"]
    G --> H["🚀 Production"]
    H -.-> I["😊 Stabilité"]
    
    style A fill:#1565c0,stroke:#1976d2
    style B fill:#2e7d32,stroke:#388e3c
    style C fill:#e65100,stroke:#f57c00
    style D fill:#e65100,stroke:#f57c00
    style E fill:#7b1fa2,stroke:#9c27b0
    style F fill:#e65100,stroke:#f57c00
    style G fill:#00838f,stroke:#0097a7
    style H fill:#388e3c,stroke:#4caf50
    style I fill:#1b5e20,stroke:#2e7d32

Regard critique sur le projet

Ce qui a bien fonctionné ✅

Aspect	Pourquoi
Stack technique	Choix pragmatiques adaptés à notre équipe
Communication équipe	Rituels réguliers et transparence
Pivot B2B	Réactivité face aux retours du marché
Concours PEPITE	Validation externe et visibilité

Ce qui aurait pu être mieux ❌

Aspect	Amélioration possible
Tests	Commencer par TDD dès le début
Lancement beta	Faire une vraie phase de beta fermée
Migration Laravel	Mieux évaluer les frameworks au départ
Scope	Éviter le feature creep

Recommandations pour des projets similaires

Investir dans les tests dès le premier jour
Choisir les technologies avec lesquelles l’équipe est à l’aise
Valider le marché avant de construire
Itérer rapidement avec un MVP minimal
Documenter les décisions et les erreurs
Demander du feedback régulièrement
Prendre soin de l’équipe pour éviter le burnout

Conclusion

L’aventure Mindlet nous a enseigné que :

La qualité prime sur la quantité de fonctionnalités
La préparation est plus importante que la vitesse
Les retours utilisateurs sont une mine d’or
L’humilité face à l’échec permet de progresser

“L’échec n’est pas l’opposé du succès, c’est une partie du succès.” - Arianna Huffington