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 plate-forme repose sur des 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 en flux asynchrone des fichiers binaires (FileResponse) et nettoyage en arrière-plan via BackgroundTasks.
  • Courtier de messages et cache : Redis 7 (gestion des tâches Celery, verrouillages anti-concurrence, protection contre les attaques par force brute, mise en cache des sessions).
  • Exécuteur en arrière-plan (Task Queue) : Celery 5.4 avec un pool dédié de workers 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 relance automatique des transactions défectueuses (@db_retry).
  • Circuit réseau : Tunneling via Cloudflare Zero Trust avec blocage de l'accès direct par IP 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 de bloquer le traitement des messages entrants dans Telegram lors d'opérations lourdes, une isolation stricte a été mise en place :

  • Délégation des tâches dans Redis : Lors de la sélection 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 de worker isolé : L'exécution des utilitaires de conversion a lieu 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 enveloppés dans un contexte asynchrone avec un contrôle strict du temps (conversion_timeout_sec = 180). Si la limite est dépassée, 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 perturbation pour l'utilisateur.

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

Des utilitaires et bibliothèques natifs hautement spécialisés sont utilisés pour chaque type de données :

  • Documents et tableurs (LibreOffice) : Suite bureautique sans interface graphique (soffice --headless) pour le 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 surcharge 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.
  • Graphismes matriciels 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), analyseur 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 éviter les pannes du serveur dues à un manque de mémoire (OOM Killer), un service de diagnostic préventif System Guard a été mis en place. 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).

Lorsque les limites sont dépassées, 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 de 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 (garbage collector) automatique efface les fichiers originaux et convertis dès la confirmation de l'envoi réussi dans le chat ou à l'expiration du délai de session.
  • La base de données PostgreSQL ne stocke pas les fichiers binaires ni les textes personnels des documents — seules les métadonnées techniques anonymisées sont enregistrées dans les tables (formats, tailles en octets, temps de traitement, statuts).

6. REST API universelle pour les services web externes

Le service a été conçu dès l'origine 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 Google Sheets.
  • POST /api/v1/convert — point de terminaison universel acceptant multipart/form-data (fichier, format cible, ID client externe) et renvoyant un flux d'octets prêt à l'emploi 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 à 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.