Le service All File Converter est conçu comme un système SaaS distribué et évolutif basé sur une pile asynchrone moderne Python 3.12. L'architecture est divisée en couches indépendantes : réception des événements réseau, orchestration des tâches, exécution isolée des processus binaires lourds et circuit analytique.

1. Pile technologique générale et architecture système

La plateforme repose sur les principes de haute performance (high-throughput), de consommation minimale de mémoire et de protection contre les pannes :

  • Telegram Bot Framework: Aiogram 3.13, fonctionnant en mode Webhook avec validation des jetons secrets et filtres personnalisés du cycle de vie des messages.
  • Passerelle Web et REST API: FastAPI basé sur le serveur ASGI Uvicorn avec diffusion asynchrone en continu de fichiers binaires (FileResponse) et nettoyage en arrière-plan via BackgroundTasks.
  • Courtier de messages et cache: Redis 7 (gestion des tâches Celery, verrous anti-interblocage, protection contre le brut-force, mise en cache des sessions).
  • Exécuteur en arrière-plan (Task Queue): Celery 5.4 avec un pool de workers dédié dans un conteneur isolé converter_worker.
  • Base de données: PostgreSQL 16 avec la couche ORM SQLAlchemy 2.0 (asyncpg), un pool de connexions permanentes (20+10 overflow) et une reprise automatique des transactions échouées (@db_retry).
  • Circuit réseau: Tunneling via Cloudflare Zero Trust avec blocage de l'accès IP direct au serveur via Middleware.

2. Files d'attente asynchrones et isolation des calculs lourds (Celery + Redis)

La conversion de fichiers multimédias et de suites bureautiques génère des pics de charge sur le CPU et la RAM. Pour éviter que le traitement des messages entrants dans Telegram ne soit bloqué lors d'opérations lourdes, une isolation stricte a été mise en place :

  • Délégation des tâches dans Redis: Lors du choix du format, le gestionnaire Telegram enregistre la tâche dans la base de données avec le statut PROCESSING et place la tâche dans la file d'attente tasks.execute_conversion via Celery.
  • Conteneur worker isolé: L'exécution des utilitaires de conversion s'effectue dans un conteneur Linux séparé doté de ses propres limites de temps processeur et de mémoire.
  • Contrôle des blocages et délais d'attente: Les appels aux utilitaires externes sont encapsulés dans un contexte asynchrone avec un contrôle strict du temps (conversion_timeout_sec = 180). En cas de dépassement de la limite, le processus est arrêté de force via proc.kill(), libérant ainsi les ressources.
  • Fallback tolérant aux pannes: En cas d'indisponibilité temporaire du courtier Redis, la tâche est automatiquement interceptée par le répartiteur asynchrone local et exécutée directement sans perturber l'utilisateur.

3. Pipeline de moteurs de conversion spécialisés

Pour chaque type de données, des utilitaires natifs et des bibliothèques hautement spécialisés sont utilisés :

  • Documents et tableaux (LibreOffice): Suite bureautique sans tête (soffice --headless) pour un rendu précis de DOCX, XLSX, PPTX, RTF, ODT au format PDF ou en fichiers texte.
  • Audio et vidéo en streaming (FFmpeg): Transcodage multithread de codecs vidéo (H.264), de codecs audio (MP3, OGG Opus), extraction de pistes audio, génération de GIF (filtre Lanczos) et recadrage carré (1:1) des messages vidéo Telegram.
  • Traitement PDF haute vitesse (Poppler Utils): Utilitaires pdftotext (extraction instantanée de texte formaté en UTF-8) et pdftoppm (rendu de PDF page par page en images raster sans les surcoûts de LibreOffice).
  • Reconnaissance optique de caractères (Tesseract OCR): Extraction par réseau de neurones de texte imprimé à partir de scans et de photos dans plus de 40 langues.
  • Graphiques raster et vectoriels: Bibliothèques Pillow (incluant la prise en charge des formats HEIC et AVIF), CairoSVG pour les images vectorielles et lottie pour les stickers animés Telegram (.TGS).
  • Livres, sous-titres et polices: Moteur Calibre (ebook-convert), parseur de sous-titres pysubs2 (SRT, VTT, ASS, SSA) et compilateur de polices fonttools (compression Brotli en WOFF2).

4. Protection préventive des ressources (System Guard)

Pour protéger le serveur contre les pannes dues au manque de mémoire (OOM Killer), le service de diagnostic préventif System Guard a été introduit. Avant d'accepter un fichier pour traitement, le système vérifie les métriques clés de l'hôte :

  • Mémoire vive disponible (RAM): Minimum 500 Mo d'espace libre (guard_min_free_ram_mb).
  • Espace disque: Minimum 2 Go d'espace libre dans le répertoire /tmp (guard_min_free_disk_mb).
  • File d'attente des tâches: Limitation de la longueur de la file d'attente Celery (pas plus de 20 tâches en attente).

En cas de dépassement des limites, le service active temporairement la protection (HTTP 503 / message dans le chat), empêchant la surcharge du serveur et envoyant une alerte instantanée aux administrateurs sur Telegram.

5. Cycle de vie des fichiers et sécurité (GDPR)

L'architecture est conçue selon le modèle Zero-Data-Footprint :

  • Les fichiers des utilisateurs sont téléchargés dans un volume sécurisé tmp/conversions/ avec des préfixes uniques basés sur les identifiants des tâches.
  • Les fichiers restent accessibles strictement dans le cadre de la session de travail — pas plus de 15 minutes (900 secondes).
  • Le ramasse-miettes automatique supprime les fichiers d'origine et prêts dès la confirmation de l'envoi réussi dans le chat ou après l'expiration du délai de session.
  • La base de données PostgreSQL ne stocke pas de fichiers binaires ou de textes de documents personnels — seules des métadonnées techniques anonymisées sont enregistrées dans les tables (formats, tailles en octets, temps de traitement, statuts).

6. REST API universel pour les services web externes

Le service a été initialement conçu comme un backend multiplateforme. En plus du bot, une interface de programmation sécurisée à part entière fonctionne pour les sites web (par exemple sur Django) et les bots tiers :

  • GET /api/v1/formats — matrice JSON dynamique des directions de conversion disponibles, synchronisée avec les paramètres de Google Sheets.
  • POST /api/v1/convert — point de terminaison universel acceptant multipart/form-data (fichier, format cible, ID client externe) et renvoyant le flux d'octets prêt sous forme de téléchargement direct.
  • Autorisation par jetons Bearer (WEBHOOK_REFRESH_TOKEN) avec protection contre les attaques temporelles via secrets.compare_digest.

7. Tableau de bord et Observability (NiceGUI + AG Grid)

La surveillance des indicateurs commerciaux et de l'état du système a été intégrée dans un panneau de contrôle natif Single-Page basé sur NiceGUI 2.x :

  • Tableaux interactifs AG Grid (v32+) avec filtres de cases à cocher personnalisés de style Excel (aggrid_filters.js).
  • Surveillance en temps réel des files d'attente, des latences des fournisseurs d'API et du ping PostgreSQL / Redis.
  • Filtrage transversal par dates avec intégration transparente du tableau de bord BI Metabase via des jetons JWT signés.