MasomoAI
Une plateforme d’apprentissage IA qui transforme documents, images, vidéos et textes en supports d’étude structurés. J’ai piloté l’architecture backend pour l’ingestion, les traitements IA asynchrones, les domaines pédagogiques et l’exploitation.
Le code source est privé. L’étude de cas se concentre sur la structure du pipeline, le contrôle asynchrone, la gestion des échecs et le comportement en production plutôt que sur les contenus sensibles.
- Modèle produit
- SaaS d’apprentissage IA
- Public
- Étudiants & partenaires éducatifs
- Période
- 2025
- Mon rôle
- Lead backend engineer
- Contexte
- Produit commercial privé
- Périmètre
- API · pipeline IA · workers · opérations
01
Surfaces produit
Surfaces produit
Des surfaces distinctes rendaient visibles les responsabilités école, association et campus avant même de regarder l’architecture.
Import et traitement de cours
Ingestion des sources, statut de traitement et préparation des supports avant génération IA.
Supports d’étude générés
Résumés, quiz, flashcards et examens générés à partir des contenus importés.
Interface tutorat et chat
Interactions côté apprenant qui restent réactives pendant que les générations lourdes tournent en arrière-plan.
02
Problème et contraintes
Problème et contraintes
Les supports pédagogiques arrivent dans des formats aux coûts d’extraction et modes d’échec différents. Le produit doit isoler OCR et appels modèles des requêtes interactives tout en rattachant chaque contenu généré au bon profil, cours et état de traitement.
Qualité source imprévisible
PDF natifs, scans, images et vidéos ne peuvent pas partager un seul parcours d’extraction ni un même profil de coût.
Traitements IA longs
OCR, génération et correction dépassent le budget de latence des requêtes API classiques.
Flux interactifs versus charges batch
Le chat et la consultation côté apprenant ne doivent pas attendre derrière l’extraction de masse ou les statistiques planifiées.
Reprise opérationnelle après échec asynchrone
Le système doit rendre visibles jobs bloqués, tâches échouées et erreurs fournisseur au lieu de les cacher derrière de faux succès.
03
Mon périmètre exact
Mon périmètre exact
J’ai conçu
- Le cycle d’ingestion séparant fichiers source, texte extrait et contenus pédagogiques générés.
- Le routage des queues et l’isolation des charges entre chat, extraction, OCR, génération et tâches planifiées.
- Les états de traitement rendant les travaux IA asynchrones lisibles pour les utilisateurs et les opérateurs.
J’ai implémenté
- Les flux de génération asynchrones pour résumés, quiz, flashcards, examens et support tutorat.
- Les contrôles Celery avec retries, acquittements tardifs, rejet en cas de perte worker et exécution bornée.
- L’authentification, le throttling par scope, les logs expurgés et l’observabilité production autour des traitements longs.
J’ai collaboré sur
- Le comportement produit autour des états asynchrones visibles et des supports d’étude générés.
- Les choix fournisseurs et le traitement opérationnel autour de l’extraction documentaire et des workflows IA.
03
Objectifs
Objectifs
Ingestion
Accepter des supports hétérogènes et conserver une couche de texte extrait réutilisable.
Réactivité
Sortir les traitements coûteux du chemin HTTP et prioriser les opérations interactives.
Séparation métier
Garder cours, examens, correction, chat, quiz et flashcards maintenables indépendamment.
Exploitation
Exposer santé des queues, retries, échecs et corrélation des requêtes pour l’analyse d’incidents.
04
Architecture système
Architecture système
PDF · image · vidéo · texte
PyMuPDF · pypdf · Document AI · OCR
Django · Celery · Redis · services LLM
Résumé · quiz · cartes · examen · chat
La plateforme sépare ingestion, extraction, orchestration et sorties pédagogiques afin que les traitements IA lourds puissent évoluer sans contaminer le chemin de requête.
Stack technique
Application
Django 5 · Django REST Framework · PostgreSQL · OpenAPI
Runtime asynchrone
Celery · Redis · Celery Beat · Priority queues
IA & extraction
Document AI · PyMuPDF · pypdf · Tesseract · DeepSeek · OpenAI · Mistral
Services production
Cloudflare R2 · PgBouncer · Better Stack · Gunicorn
05
Modèle d’états
Modèle d’états
Le traitement d’un cours est une machine à états asynchrone explicite. La requête peut répondre avant la fin de l’extraction, de la modération et de la génération.
En attente
Le fichier et le cours existent ; le traitement de fond est en file.
En traitement
Extraction, contrôles de contenu et génération IA s’exécutent hors de la requête HTTP.
Prêt
Le texte extrait et les contenus pédagogiques générés peuvent être servis.
Transitions alternatives
Rejeté
La modération enregistre un motif ; les fichiers utilisateur rejetés peuvent être purgés.
Échec
Une erreur de traitement est enregistrée pour retry ou investigation opérationnelle.
Le cycle de traitement visible fait partie du contrat produit : utilisateurs et opérateurs distinguent clairement attente, traitement, rejet et échec.
07
Défis d’ingénierie
Défis d’ingénierie
Un modèle de contenu, plusieurs extractions
La qualité va du PDF textuel au scan nécessitant un OCR.
Tenter l’extraction native, escalader les fichiers difficiles vers l’OCR, mettre le texte en cache et modérer avant génération.
Le pipeline comporte plus d’états et de nettoyage, mais évite le coût OCR pour chaque document.
Si tous les fichiers sont traités de la même manière, coût, latence et reprise sur erreur deviennent plus difficiles à maîtriser.
Interactions face aux traitements IA de masse
Une queue FIFO unique laisse les longs OCR retarder chat et notifications.
Utiliser cinq queues routées par priorité, des limites par tâche, acquittements tardifs et rejet en cas de perte worker.
L’exploitation devient plus complexe, mais les charges interactives et batch disposent de règles de capacité explicites.
Si charges interactives et batch partagent aveuglément la même queue, le produit paraît cassé même si les workers tournent encore.
Des fallbacks qui ne masquent pas l’échec
Exécuter silencieusement les jobs dans des threads web peut perdre le travail lors des redémarrages.
Désactiver le fallback thread en production, faire échouer explicitement l’enqueue et persister les événements retry/échec.
L’utilisateur voit une erreur récupérable si le broker est indisponible plutôt qu’une fausse confirmation.
Si le système fait semblant de démarrer des travaux de fond qui n’ont pas démarré, support et utilisateurs se retrouvent avec des contenus bloqués dans des états trompeurs.
08
Modes d’échec & mitigation
Modes d’échec & mitigation
Échec OCR sur support de mauvaise qualité
Le pipeline enregistre des états d’échec ou de rejet explicites au lieu de boucler silencieusement sur des documents illisibles.
Crash worker pendant la génération
Les acquittements tardifs, le rejet en cas de perte worker et les retries rendent les jobs interrompus visibles et récupérables.
Indisponibilité du broker ou des queues
Les échecs d’enqueue remontent explicitement au lieu de basculer vers un comportement in-process risqué en production.
Tâche bloquée qui ne termine jamais
La reprise des jobs bloqués et la visibilité sur la santé des queues donnent à l’exploitation un moyen d’inspecter et récupérer le travail incomplet.
09
Décisions techniques
Décisions techniques
Extraire avant de générer
L’extraction PDF native est tentée d’abord, avec réparation et OCR réservés aux documents difficiles.
Des jobs, pas de longues requêtes
La génération passe par Celery pour conserver des réponses HTTP prévisibles et permettre retry et observation indépendants.
Services IA par domaine
Les parcours apprentissage, examen et correction disposent de services séparés plutôt que d’une couche de prompts monolithique.
10
Sécurité & exploitation
Sécurité & exploitation
Responsabilités Redis isolées
Cache, sessions et Celery utilisent des bases logiques séparées pour éviter les évictions croisées.
Livraison média privée
Les objets R2 restent privés et sont servis par URLs signées à durée limitée.
Sécurité derrière proxy
HTTPS, origines de confiance, headers proxy et allowlists de callbacks sont validés en production.
Observabilité expurgée
Request IDs et classes de latence sont journalisés tandis que tokens, mots de passe, cookies et fichiers sont expurgés.
- Limites worker, stratégies de retry et monitoring des queues.
- Logs structurés et monitoring erreurs/performance.
- Frontières fournisseur pour garder l’orchestration modèle remplaçable.
11
Résultat livré
Résultat livré
Résultats d’implémentation — aucune métrique commerciale non vérifiée.
Cycle de contenu déterministe
Chaque cours importé expose un état de traitement et un chemin d’échec terminal.
Isolation des charges
Chat, génération, OCR et tâches planifiées ne se concurrencent plus dans une queue unique.
Opérations récupérables
Retries, jobs bloqués et échecs produisent des signaux de diagnostic explicites.
Fournisseurs remplaçables
Fournisseurs d’extraction et modèles restent derrière des services métier plutôt que dans les endpoints produit.
Ce que j’en retiens
“La qualité d’un produit IA dépend autant du conditionnement documentaire, des queues et des erreurs que du modèle lui-même.”