office_translator/_bmad-output/planning-artifacts/prd.md

stepsCompleted, inputDocuments, workflowType, documentCounts, classification, date

stepsCompleted	inputDocuments	workflowType	documentCounts	classification	date
step-01-init step-02-discovery step-02b-vision step-02c-executive-summary step-03-success step-04-journeys step-05-domain step-06-innovation step-07-project-type step-08-scoping step-09-functional step-10-nonfunctional step-11-polish step-12-complete	product-brief-office_translator-2026-02-18.md	prd	briefs research projectDocs 1 0 0	projectType domain complexity projectContext Application web SaaS + API REST Traduction de documents / Productivité B2B Moyenne-Haute brownfield	2026-02-18

Product Requirements Document - office_translator

Author: Sepehr Date: 2026-02-18

Executive Summary

Office Translator est une plateforme SaaS de traduction de documents Office (Excel, Word, PowerPoint) qui résout un problème critique pour les entreprises : le temps perdu à remettre en page un document mal traduit coûte plus cher que la traduction elle-même.

La vision est simple — l'utilisateur dépose un document, le récupère traduit et visuellement identique à l'original (couleurs, cellules fusionnées, graphiques, mises en page), sans aucune retouche nécessaire.

Cible : Professionnels et entreprises ayant besoin de traduire des documents Office complexes avec une qualité "prête à l'emploi".

What Makes This Special

• Sanitisation et reconstruction de document supérieure : Notre traitement des fichiers Office dépasse les solutions existantes sur la préservation du format.
• Fiabilité sur l'expérimentation : Utilisation de moteurs éprouvés (LLMs stables : Ollama, OpenAI, compatibles) plutôt que des IA génératives instables.
• Administration SaaS robuste : Monitoring, abonnements, rate limiting — pensé pour un déploiement production et une monétisation sereine.

Insight unique : La valeur n'est pas dans la traduction elle-même, mais dans l'élimination du travail post-traduction.

Project Classification

Élément	Valeur
Type	Application web SaaS + API REST
Domaine	Traduction de documents / Productivité B2B
Complexité	Moyenne-Haute
Contexte	Brownfield (refonte de l'existant)

Success Criteria

User Success

Rapidité (avec distinction par mode) :

• Mode Classique (Google/DeepL) : < 15 secondes pour un document standard (ex: Word 10 pages) — impression d'instantanéité
• Mode LLM (Ollama/OpenAI) : 1 à 3 minutes acceptables si barre de progression claire
• Critère clé : Feedback visuel (progression) immédiat dans tous les cas

Qualité "prête à l'emploi" :

• Format Fidelity : Le fichier traduit s'ouvre sans erreur dans Office
• Zéro casse visuelle : 0% de tableaux explosés, images déplacées, mises en page brisées
• Taux de retouche < 10% : l'utilisateur corrige une tournure, jamais ne reconstruit le document

Business Success (MVP)

Objectif : Capacité à Facturer (Billability) :

• Le système de tracking (Admin) remonte 100% des usages réels
• Le système de quotas (Rate Limiting) bloque effectivement les abus
• Définition du succès : Si déployé demain, possibilité d'onboarder un client payant sans risque de consommation illimitée gratuite

Technical Success

• Fiabilité : Gestion d'erreurs "graceful" — fichiers corrompus/illisibles → erreur 400 claire (JSON), jamais de crash serveur (500)
• Hygiène : 100% des fichiers temporaires supprimés après TTL (confidentialité + espace disque)
• Performance : 5 conversions simultanées sans ralentissement perceptible de l'interface Admin

Measurable Outcomes

Critère	Cible
Temps de traduction (mode classique)	< 15 sec (doc 10 pages)
Temps de traduction (mode LLM)	1-3 min avec progression
Taux de retouche utilisateur	< 10%
Fichiers ouvrables sans erreur	100%
Caisse visuelle (format)	0%
Couverture tracking usage	100%
Nettoyage fichiers temporaires	100%
Conversions simultanées supportées	5

Product Scope

MVP - Minimum Viable Product

• Refonte backend : code épuré, suppression code mort
• Traduction via LLMs (Ollama, OpenAI, compatibles) + Google/DeepL si API pas chère
• Préservation parfaite du format (Excel, Word, PowerPoint)
• Système de tracking usage (Admin)
• Rate limiting par utilisateur/abonnement
• Gestion d'erreurs robuste
• Nettoyage automatique des fichiers temporaires

Growth Features (Post-MVP)

• Intégration API Google Traduction officielle (si coût acceptable)
• Dashboard analytics avancé
• Historique de traductions pour utilisateurs
• Webhooks / notifications
• Support de formats supplémentaires (PDF ?)

Vision (Future)

• Mode "Team" avec collaboration
• Intégrations (Zapier, Make, etc.)
• API publique documentée pour développeurs tiers
• Marketplace de templates/glossaires

User Journeys

Journey 1 : Marie, Utilisatrice Web Gratuite

Situation : Marie est consultante marketing freelance. Elle reçoit un rapport PowerPoint en anglais d'un client et doit le présenter en français à une réunion dans 2 heures.

Parcours :

1. Marie découvre Office Translator via une recherche ou bouche-à-oreille
2. Elle arrive sur la page d'accueil, comprend immédiatement le propos (traduction de documents, format préservé)
3. Elle glisse-dépose son fichier PPT (15 slides)
4. Elle sélectionne "Anglais → Français" et choisit le mode "Classique" (gratuit, rapide)
5. Une barre de progression s'affiche immédiatement : "Traitement en cours... 3/15 slides"
6. Après 12 secondes, le fichier est prêt → téléchargement automatique
7. Elle ouvre le fichier : le design est intact, les graphiques sont en place
8. Elle corrige 2-3 tournures de phrases, sauvegarde et envoie à la réunion

Résultat : Mission accomplie en moins de 5 minutes. Elle bookmark le site.

Exigences révélées : Landing page claire, upload drag & drop, feedback visuel temps réel, téléchargement fluide, qualité de format.

Journey 2 : Thomas, Utilisateur API Pro

Situation : Thomas est lead dev dans un cabinet d'audit. Son équipe traite 200 rapports financiers Excel par mois pour des clients internationaux. Il automatise avec n8n.

Parcours :

1. Thomas s'abonne au plan Pro (gestion manuelle par Admin pour le MVP)
2. Il accède à son Dashboard → génère une Clé API stable
3. Il lit la documentation API : endpoints, auth, rate limits, codes d'erreur JSON
4. Il configure son workflow n8n avec la clé API
5. Premier test : fichier Excel complexe envoyé → réponse structurée (fichier + métadonnées)
6. Il teste un cas d'erreur : quota dépassé → API renvoie {"error": "quota_exceeded", "message": "Limite mensuelle atteinte"}
7. Il active les fonctionnalités Pro : Glossaires personnalisés + Prompts système pour la terminologie financière
8. Déploiement production → 200 fichiers/mois traités, erreurs gérées automatiquement par ses scripts

Résultat : Gain de 15h/mois. Sa raison de payer : personnalisation terminologique + volume.

Exigences révélées : Génération Clés API dans Dashboard, erreurs JSON structurées, documentation, Glossaires/Prompts système (Pro).

Journey 3 : L'Admin (Dashboard)

Situation : C'est vous, lundi matin. Vous vérifiez le système et gérez les premiers clients.

Parcours :

1. Connexion au Dashboard Admin (auth sécurisée)
2. Vue d'ensemble : santé système, espace disque, mémoire, statut providers
3. Gestion des utilisateurs : vous voyez une nouvelle demande de Thomas
4. Vous passez Thomas de "Free" à "Pro" manuellement (dropdown → "Pro")
5. Sa Clé API est automatiquement générée/activée dans son Dashboard utilisateur
6. Vous vérifiez les stats : 847 traductions ce weekend, 3 erreurs gérées proprement (400)
7. Vérification du rate limiting : utilisateur X bloqué après quota gratuit
8. Purge des fichiers temporaires orphelins → système propre

Résultat : Client Pro onboardé manuellement, système stable, prêt pour la facturation.

Exigences révélées : Dashboard métriques, changement de tier manuel (Free→Pro), génération/révocation clés API, statut providers, logs, purge fichiers.

Journey 4 : Cas d'Erreur - Fichier Non Supporté

Situation : Un utilisateur essaie de traduire un PDF scanné.

Parcours :

1. Upload du fichier PDF
2. Le système détecte le format non supporté
3. API renvoie : {"error": "invalid_format", "message": "Format PDF non supporté. Formats acceptés : .xlsx, .docx, .pptx"}
4. L'utilisateur comprend et convertit son fichier
5. Deuxième tentative : succès

Résultat : Pas de frustration, message explicite, pas de crash serveur.

Exigences révélées : Validation format, erreurs JSON utilisateur-friendly, gestion graceful.

Journey Requirements Summary

Parcours	Capacités Révélées
Utilisateur Web Gratuit	Landing page, upload drag & drop, progression temps réel, téléchargement
Utilisateur API Pro	Génération Clés API, documentation, erreurs JSON structurées, Glossaires/Prompts (Pro)
Admin Dashboard	Métriques système, changement de tier manuel, gestion clés API, statut providers, logs, purge
Gestion d'erreurs	Validation format, erreurs JSON claires, graceful degradation

Domain-Specific Requirements

Confidentialité des données (Data Confidentiality)

• Politique "Zéro Rétention" : Système "Passe-plat" (Pass-through)
• Stockage : Strictement temporaire (/tmp), suppression automatique (Hard Delete) après TTL de 60 minutes ou immédiatement après téléchargement réussi
• Logs : Aucun contenu de document loggué. Seules métadonnées conservées (nom, taille, hash, timestamp)

RGPD / Conformité (GDPR)

• Cible : Clients européens visés
• Stratégie : Conformité par minimisation des données — pas de stockage durable = "Droit à l'oubli" respecté par défaut
• Hébergement : Préférence serveur UE pour le MVP

Propriété Intellectuelle (IP)

• Clause : L'utilisateur reste seul propriétaire des documents
• "No Training Policy" : Garantie que les documents ne sont jamais utilisés pour entraîner les modèles (différenciateur clé B2B)

Sécurité API (API Security)

Vecteur	Mécanisme
Web/Admin	JWT (Access + Refresh Tokens)
API Automation	Clés API statiques générées par Admin
Contrôle	Révocation immédiate via Dashboard (pas de rotation auto MVP)

Audit / Traçabilité

• Logs structurés : Qui, Quand, Quoi, Volume, Status Code
• Usage : Debugging + facturation/quota (pages traduites)
• Scope : Pas d'audit légal complexe pour le MVP

SaaS B2B + API Backend - Exigences Spécifiques

Architecture Multi-Tenant

Aspect	Décision
Isolation	Par utilisateur (quotas, clés API séparées)
Stockage	Local éphémère (/tmp) - pas de S3 pour le MVP
Données persistantes	Utilisateurs, clés API, logs métadonnées uniquement

Modèle de Permissions (RBAC)

Rôle	Accès
Free	Traduction web, mode classique uniquement, quota limité
Pro	Traduction web + API, tous modes (LLM inclus), glossaires/prompts, quota élevé
Admin	Dashboard complet, gestion utilisateurs, révocation clés, métriques système

Tiers d'Abonnement

Tier	Quota	Providers	Fonctionnalités
Free	5 fichiers/jour	Google/DeepL	Traduction web uniquement
Pro	Illimité (fair use)	Tous (LLM inclus)	API, Glossaires, Prompts système, Webhooks

Spécifications API

Versioning :

• Tous les endpoints préfixés par /api/v1/
• Obligatoire pour préserver les intégrations clients

Endpoints principaux :

Endpoint	Méthode	Description
/api/v1/translate	POST	Traduire un document
/api/v1/languages	GET	Langues supportées
/api/v1/health	GET	Santé du service
/api/v1/download/{id}	GET	Télécharger fichier traduit

Authentification :

Contexte	Méthode
Web/Admin	JWT (Access + Refresh Tokens)
API Automation	API Key statique (header X-API-Key)

Gestion d'erreurs :

• Format JSON structuré : {"error": "code", "message": "description"}
• Codes HTTP appropriés (400 client, 500 server - à éviter)

Documentation :

• OpenAPI (Swagger/Redoc) interactif
• Pas de SDK client pour le MVP

Intégrations & Webhooks

Intégration	Statut MVP
Stockage S3	Non (local éphémère)
Email transactionnel	Non (gestion manuelle Admin)
Webhooks	Oui - Fire & Forget (POST URL client après traduction)

Exigences de Conformité

Exigence	Implémentation
RGPD	Minimisation données (zero retention)
Confidentialité	TTL 60 min, hard delete automatique
Hébergement	Préférence UE
"No Training Policy"	Clause contractuelle

Project Scoping & Phased Development

MVP Strategy & Philosophy

Approche MVP : Revenue-Ready Hybride

• Module paiement existant à refactorer (Clean Architecture)
• Gestion manuelle Admin en backup (sécurité support client)
• Objectif : déployer avec capacité de facturer immédiatement

Parcours prioritaire : Thomas (API Pro) — API first, revenus first

Ressources : Solo Developer → Architecture monolithique modulaire

MVP Feature Set (Phase 1)

Parcours utilisateurs supportés :

Parcours	Priorité MVP
Thomas (API Pro)	Critique — Priorité absolue
Admin Dashboard	Critique — Gestion clients + monitoring
Marie (Web Gratuit)	Important — Acquisition utilisateur
Gestion d'erreurs	Critique — Expérience API

Must-Have Capabilities :

Capacité	Priorité	Notes
Traduction Excel/Word/PPT	Critique	Risque technique n°1
Préservation format	Critique	Cœur de valeur
API /v1/ + documentation OpenAPI	Critique	Parcours Thomas
Clés API (génération/révocation)	Critique	Parcours Thomas
Erreurs JSON structurées	Critique	Parcours Thomas
Webhooks (Fire & Forget)	Critique	Automation
Dashboard Admin	Critique	Monitoring + gestion
Changement tier manuel (Free→Pro)	Critique	Backup paiement
Module paiement refactoré	Important	Revenue-ready
Rate limiting	Critique	Protection abus
Nettoyage fichiers (TTL 60min)	Critique	Confidentialité
Auth JWT (Admin)	Critique	Sécurité
Upload Web drag & drop	Important	Parcours Marie
Barre progression	Important	UX

Peut attendre Post-MVP :

• Historique traductions utilisateur
• Dashboard analytics avancé
• Intégrations Zapier/Make
• SDK client

Post-MVP Features

Phase 2 (Growth) :

• Glossaires personnalisés (Pro)
• Prompts système personnalisables
• Historique de traductions
• Dashboard analytics avancé
• Support PDF (si demandé)

Phase 3 (Expansion) :

• Mode Team / collaboration
• Intégrations Zapier, Make
• API publique pour développeurs tiers
• SDK client (Python, JS)
• Marketplace templates/glossaires

Risk Mitigation Strategy

Risque	Type	Mitigation
Préservation format Office	Technique	Tests automatisés sur fichiers complexes, validation visuelle, corpus de test
Intégration multi-providers LLM	Technique	Abstraction provider, fallback entre providers
Bug paiement	Business	Gestion manuelle Admin en backup
Solo developer	Ressource	Monolithe modulaire, scope strict, dette technique zero
Acquisition utilisateurs	Marché	Parcours Marie fonctionnel, bouche-à-oreille

Architecture Decision

Monolithe Modulaire (pas de micro-services) :

• modules/translation/ — cœur métier
• modules/auth/ — JWT + API Keys
• modules/payment/ — paiement refactoré
• modules/admin/ — dashboard
• modules/webhooks/ — notifications

Functional Requirements

Document Translation

• FR1: Users can upload Excel files (.xlsx) for translation
• FR2: Users can upload Word files (.docx) for translation
• FR3: Users can upload PowerPoint files (.pptx) for translation
• FR4: Users can select source and target languages for translation
• FR5: Users can choose translation mode (Classic or LLM) based on their subscription tier
• FR6: System can translate documents using Google/DeepL providers (Classic mode)
• FR7: System can translate documents using LLM providers (Ollama, OpenAI, OpenAI-compatible)
• FR8: System can process multiple translation requests concurrently

Format Preservation

• FR9: System preserves document layout after translation (colors, fonts, spacing)
• FR10: System preserves merged cells in Excel files
• FR11: System preserves tables in Word and PowerPoint files
• FR12: System preserves images and their positions in all document types
• FR13: System preserves charts and their data links in Excel files
• FR14: System preserves formulas in Excel files (translating only text content)
• FR15: System preserves slide layouts and animations in PowerPoint files
• FR16: Users can open translated files in Microsoft Office without errors

User Management & Authentication

• FR17: Users can create an account with email and password
• FR18: Users can log in to the web application via JWT authentication
• FR19: Users can log out of the web application
• FR20: System assigns users to subscription tiers (Free or Pro)
• FR21: Admin can change user tier from Free to Pro manually
• FR22: Admin can change user tier from Pro to Free manually

Subscription & Billing

• FR23: System enforces daily file quotas based on user tier
• FR24: Free users are limited to 5 files per day
• FR25: Pro users have unlimited translations (fair use policy)
• FR26: Pro users can access LLM translation modes
• FR27: System tracks translation usage per user for billing purposes
• FR28: Payment module updates user tier upon successful payment

API & Integration

• FR29: Pro users can generate API keys from their dashboard
• FR30: Pro users can revoke their own API keys
• FR31: Admin can revoke any user's API key
• FR32: System authenticates API requests via X-API-Key header
• FR33: System provides REST API endpoints under /api/v1/ prefix
• FR34: System returns errors in structured JSON format with error code and message
• FR35: System provides interactive API documentation (OpenAPI/Swagger)

Webhooks

• FR36: Users can specify webhook URL per translation request (passed as parameter)
• FR37: System sends POST request to webhook URL when translation completes
• FR38: System includes translation metadata in webhook payload (file ID, status, timestamp)
• FR65: Webhook URL is passed as parameter in the API request body
• FR66: System sends webhook notification only if URL is provided in request

Admin Dashboard

• FR39: Admin can log in to admin dashboard with secure authentication
• FR40: Admin can view system health metrics (disk space, memory usage)
• FR41: Admin can view provider status (Google, DeepL, Ollama, OpenAI connectivity)
• FR42: Admin can view translation statistics (count, errors, usage)
• FR43: Admin can view rate limiting status per user
• FR44: Admin can trigger manual cleanup of orphaned temporary files
• FR45: Admin can view error logs with structured information

Web User Interface

• FR46: Users can upload files via drag-and-drop interface
• FR47: Users see real-time progress indicator during translation
• FR48: Users can download translated files after completion
• FR49: Users receive clear error messages for unsupported file formats

File Management

• FR50: System validates file format before processing (xlsx, docx, pptx only)
• FR51: System stores uploaded files in temporary location
• FR52: System automatically deletes files after TTL (60 minutes)
• FR53: System deletes files immediately after successful download
• FR54: System logs file metadata (name, size, hash, timestamp) without content

Error Handling

• FR55: System returns HTTP 400 errors for client-side issues (invalid format, quota exceeded)
• FR56: System never returns HTTP 500 errors (graceful degradation required)
• FR57: System provides actionable error messages in user's language

Glossaries & Custom Prompts (Pro Feature)

• FR58: Pro users can include a custom glossary in translation requests
• FR59: Pro users can include custom system prompt/instructions in translation requests
• FR60: System applies glossary terms during LLM translation
• FR61: System applies custom prompts to guide LLM translation context

URL Ingestion (Automation)

• FR62: API can accept a file URL as input (in addition to binary upload)
• FR63: System downloads files from public URLs (S3, Drive, etc.) before processing
• FR64: System validates downloaded files against supported formats

Non-Functional Requirements

Performance

ID	Exigence	Critère
NFR1	Temps de réponse mode classique	< 15 secondes pour document 10 pages
NFR2	Temps de réponse mode LLM	1-3 minutes maximum avec progression visible
NFR3	Feedback utilisateur	Progression affichée en temps réel (< 500ms latence)
NFR4	Concurrence	5 conversions simultanées sans dégradation perceptible
NFR5	Interface Admin	Réponse < 2 secondes même pendant conversions

Security

ID	Exigence	Critère
NFR6	Authentification Web	JWT avec Access Token (15min) + Refresh Token (7 jours)
NFR7	Authentification API	Clés API (256-bit minimum) via header X-API-Key
NFR8	Chiffrement transit	HTTPS obligatoire (TLS 1.2+)
NFR9	Chiffrement repos	Non requis (pas de stockage persistant de documents)
NFR10	Secrets	Variables d'environnement, jamais dans le code
NFR11	Données sensibles	Aucun contenu de document dans les logs

Reliability

ID	Exigence	Critère
NFR12	Gestion d'erreurs	0% d'erreurs HTTP 500 - toujours retour 4xx avec message JSON
NFR13	Disponibilité providers	Fallback automatique entre providers si l'un échoue
NFR14	Récupération fichiers	Fichiers temporaires nettoyés même après crash (TTL 60min)

Data Retention & Privacy

ID	Exigence	Critère
NFR15	Rétention fichiers	60 minutes maximum, suppression après téléchargement
NFR16	Logs	Métadonnées uniquement (nom, taille, hash, timestamp)
NFR17	RGPD	Droit à l'oubli respecté par design (zero retention)

API Quality

ID	Exigence	Critère
NFR18	Documentation	OpenAPI 3.0 interactif (Swagger UI ou Redoc)
NFR19	Erreurs API	Format JSON structuré : {error, message, details?}
NFR20	Rate limiting	Par utilisateur, réponse 429 avec Retry-After header
NFR21	Versioning	Préfixe /api/v1/ obligatoire

---

Document Summary

Office Translator PRD — Version MVP

Métrique	Valeur
Exigences Fonctionnelles	66 FRs
Exigences Non-Fonctionnelles	21 NFRs
Parcours Utilisateurs	4
Tiers d'abonnement	2 (Free, Pro)
Formats supportés	3 (xlsx, docx, pptx)

Traceabilité :

• Vision → Success Criteria → User Journeys → Functional Requirements → NFRs
• Toutes les FRs sont traçables vers un besoin utilisateur ou business
• Les NFRs définissent les critères de qualité mesurables

Prochaines étapes BMAD :

1. Architecture Technique (à partir des FRs/NFRs)
2. Epics & User Stories (à partir des FRs)
3. Développement itératif

---

Document généré via workflow BMAD create-prd — 2026-02-18