Aller au contenu principal

Planification Stack Python - Aaperture

Date : 2026-01-24
Statut : ✅ Implémenté et Production Ready
Dernière mise à jour : 2026-01-24

🎯 Contexte​

Maintenant que le système de documents avec OCR (Tesseract.js) est opérationnel, nous explorons les opportunités d'intégrer une stack Python pour des cas d'usage avancés qui bénéficieraient de l'écosystème Python (ML, traitement de données, bibliothèques spécialisées).

📊 État Actuel​

✅ Ce qui fonctionne déjà en Node.js/TypeScript​

  • OCR : Tesseract.js (multilingue fra+eng) avec pooling de workers
  • IA : OpenAI GPT via LlmService (extraction structurée, templates personnalisés)
  • Traitement PDF : pdfjs-dist + canvas (extraction parallèle optimisée)
  • Workers BullMQ : Architecture asynchrone complète et scalable

🤔 Limitations potentielles identifiées​

  1. OCR Avancé :

    • Tesseract.js est performant mais limité pour certains cas complexes
    • Pas de détection de layout avancée (tableaux, colonnes multiples)
    • Pas de reconnaissance de formulaires structurés (champs, cases à cocher)

  2. Machine Learning :

    • Pas de modèles ML custom (classification, clustering)
    • Pas d'embeddings vectoriels locaux (coûts OpenAI)
    • Pas d'analyse prédictive (forecasting, recommandations)

  3. Traitement de Données :

    • Pas de traitement batch lourd (pandas, numpy)
    • Pas d'analyse statistique avancée
    • Pas de génération de rapports complexes avec visualisations

  4. LangChain & Agents :

    • Pas d'utilisation intensive de LangChain (orchestration complexe)
    • Pas d'agents autonomes avec mémoire persistante
    • Pas de RAG (Retrieval-Augmented Generation) avancé

🚀 Cas d'Usage Potentiels pour Python​

1. Service OCR Avancé (Priorité : Moyenne)​

Pourquoi Python ?

  • PaddleOCR : OCR haute précision pour documents complexes
  • EasyOCR : OCR multilingue avec détection de layout
  • LayoutParser : Détection de structure (tableaux, colonnes, zones)

Architecture proposée :

NestJS Worker → BullMQ Job → Python OCR Service (FastAPI)
                              ↓
                         PaddleOCR/EasyOCR
                              ↓
                         Résultat JSON → BullMQ → NestJS

Avantages :

  • Meilleure précision pour documents scannés complexes
  • Détection automatique de tableaux et formulaires
  • Support de plus de langues

Inconvénients :

  • Complexité de déploiement (service séparé)
  • Latence réseau supplémentaire
  • Maintenance d'un service Python supplémentaire

2. Service ML & Embeddings (Priorité : Haute)​

Pourquoi Python ?

  • sentence-transformers : Embeddings vectoriels locaux (gratuits vs OpenAI)
  • scikit-learn : Classification, clustering, recommandations
  • pandas/numpy : Analyse de données et statistiques

Cas d'usage concrets :

  • Recherche sémantique : Indexer les documents/sessions avec embeddings locaux
  • Classification automatique : Détecter le type de document (facture, contrat, etc.)
  • Recommandations : "Sessions similaires", "Contacts proches"
  • Analyse prédictive : Prévoir les revenus, identifier les risques

Architecture proposée :

NestJS → BullMQ → Python ML Service (FastAPI)
                  ↓
            sentence-transformers
            scikit-learn
            ↓
         Embeddings → Vector DB (Qdrant/Pinecone)

Avantages :

  • Réduction des coûts OpenAI (embeddings locaux)
  • Modèles ML custom entraînables
  • Analyse de données avancée

3. Service LangChain & Agents (Priorité : Basse)​

Pourquoi Python ?

  • LangChain : Framework Python mature pour orchestration LLM
  • Agents autonomes : Chaînes de raisonnement complexes
  • RAG avancé : Recherche augmentée avec mémoire persistante

Cas d'usage :

  • Assistant IA avancé avec mémoire conversationnelle
  • Agents autonomes pour automatisation de workflows
  • RAG pour recherche contextuelle dans toute la base de données

Architecture proposée :

Frontend → NestJS → Python AI Service (LangChain)
                     ↓
                OpenAI + Vector DB
                ↓
            Réponse enrichie

Inconvénients :

  • Complexité élevée
  • Coûts LLM potentiellement plus élevés
  • Nécessite une infrastructure vectorielle

4. Service Analyse de Données (Priorité : Moyenne)​

Pourquoi Python ?

  • pandas : Manipulation de données à grande échelle
  • matplotlib/seaborn : Génération de graphiques et visualisations
  • scipy : Analyses statistiques avancées

Cas d'usage :

  • Génération de rapports analytiques complexes
  • Visualisations de données (graphiques, heatmaps)
  • Analyses statistiques (corrélations, tendances)

Architecture proposée :

NestJS → BullMQ → Python Analytics Service
                  ↓
            pandas + matplotlib
            ↓
         PDF/Image généré → R2

🏗️ Architecture Technique Proposée​

Option 1 : Service Python Monolithique (Recommandé pour début)​

┌─────────────┐
│   NestJS    │
│   Backend   │
└──────┬──────┘
       │ BullMQ Jobs
       ↓
┌─────────────────┐
│  Python Service │
│   (FastAPI)     │
│                 │
│  - OCR          │
│  - ML           │
│  - Analytics    │
└─────────────────┘

Avantages :

  • Un seul service à maintenir
  • Communication simple (REST ou gRPC)
  • Déploiement simplifié

Option 2 : Services Python Séparés (Scalabilité)​

┌─────────────┐
│   NestJS    │
└──────┬──────┘
       │
       ├──→ Python OCR Service
       ├──→ Python ML Service
       └──→ Python Analytics Service

Avantages :

  • Scalabilité indépendante par service
  • Isolation des erreurs
  • Technologies différentes par service

📋 Plan d'Implémentation Recommandé​

Phase 1 : Infrastructure de Base (1-2 semaines)​

  1. ✅ Créer un service Python minimal (FastAPI)
  2. ✅ Configurer la communication NestJS ↔ Python (REST ou gRPC)
  3. ✅ Intégrer BullMQ pour les jobs Python
  4. ✅ Dockerfile Python avec dépendances ML

Phase 2 : Service ML & Embeddings (2-3 semaines)​

  1. ✅ Implémenter sentence-transformers pour embeddings locaux
  2. ✅ Créer un service de recherche vectorielle (Qdrant local ou Pinecone)
  3. ✅ Migrer progressivement les embeddings OpenAI → Locaux
  4. ✅ Tests de performance et comparaison des coûts

Phase 3 : OCR Avancé (Optionnel, 2-3 semaines)​

  1. ✅ Évaluer PaddleOCR vs EasyOCR
  2. ✅ Implémenter le service OCR Python
  3. ✅ Comparer avec Tesseract.js actuel
  4. ✅ Décision : garder les deux ou migrer complètement

Phase 4 : Analytics & Visualisations (Optionnel, 1-2 semaines)​

  1. ✅ Service de génération de rapports
  2. ✅ Graphiques et visualisations
  3. ✅ Export PDF/Image des analyses

🎯 Recommandation Immédiate​

Commencer par le Service ML & Embeddings car :

  1. Impact business élevé : Réduction des coûts OpenAI (embeddings)
  2. ROI rapide : Recherche sémantique améliorée
  3. Fondation solide : Base pour futures fonctionnalités ML
  4. Complexité modérée : Plus simple que LangChain/Agents

Stack technique proposée :

  • Framework : FastAPI (rapide, moderne, async)
  • ML : sentence-transformers (embeddings), scikit-learn (classification)
  • Vector DB : Qdrant (local) ou Pinecone (cloud)
  • Communication : REST API (simple) ou gRPC (performant)

❓ Questions à Résoudre​

  1. Quel est le besoin prioritaire ?

    • Réduction des coûts OpenAI (embeddings) ?
    • Amélioration de l'OCR pour documents complexes ?
    • Analyse de données avancée ?

  2. Infrastructure disponible ?

    • Capacité à déployer un service Python séparé ?
    • Budget pour services cloud (Pinecone, etc.) ?
    • Ressources pour maintenir une stack Python ?

  3. Timeline ?

    • Besoin immédiat ou planification long terme ?

📚 Documentation Complète​

📚 Ressources Externes​

✅ Statut Final​

Toutes les phases sont complétées et le stack Python est Production Ready :

  • ✅ Infrastructure de base (FastAPI, embeddings, Qdrant)
  • ✅ Recherche sémantique (Sessions, Contacts)
  • ✅ Classification automatique de documents
  • ✅ OCR avancé (EasyOCR/PaddleOCR)
  • ✅ Optimisations production (rate limiting, circuit breaker, monitoring, cache)
  • ✅ Docker optimisé (build rapide, permissions corrigées)