Évitez les expirations d'export grâce à des tâches d'export asynchrones, des indicateurs de progression, la pagination et des téléchargements en streaming pour de grands rapports CSV et PDF.
Un export expire lorsque le serveur n'a pas fini le travail avant une échéance. Cette échéance peut être définie par le navigateur, un reverse proxy, votre serveur d'applications ou la connexion à la base de données. Pour les utilisateurs, cela paraît souvent aléatoire, car l'export fonctionne parfois et échoue d'autres fois.
À l'écran, cela ressemble généralement à l'une de ces situations :
Les gros exports sont stressants car ils sollicitent plusieurs parties du système en même temps. La base de données doit trouver et assembler beaucoup de lignes. Le serveur d'app doit les formater en CSV ou les rendre en PDF. Puis le navigateur doit recevoir une grande réponse sans que la connexion ne tombe.
Les jeux de données énormes sont le déclencheur évident, mais des exports "petits" peuvent aussi être lourds. Des jointures coûteuses, beaucoup de champs calculés, des recherches par ligne et des filtres mal indexés peuvent transformer un rapport normal en timeout. Les PDFs sont particulièrement risqués parce qu'ils impliquent la mise en page, les polices, les images, les sauts de page et souvent des requêtes supplémentaires pour rassembler les données liées.
Les nouvelles tentatives (retries) aggravent souvent le problème. Quand un utilisateur rafraîchit ou clique à nouveau sur Export, votre système peut lancer le même travail deux fois. La base de données exécute des requêtes en double, le serveur construit des fichiers en double et vous avez un pic de charge exactement quand le système est déjà en difficulté.
Si vous voulez prévenir les expirations d'export, traitez un export comme une tâche en arrière-plan, pas comme un chargement de page normal. Même dans un constructeur no-code comme AppMaster, le schéma importe plus que l'outil : un travail long nécessite un flux différent de « cliquer sur le bouton, attendre la réponse ».
La plupart des échecs d'export proviennent du fait que l'app utilise un seul modèle pour toutes les situations, même quand la taille des données et le temps de traitement varient beaucoup.
Un export synchrones simple (l'utilisateur clique, le serveur génère, le téléchargement démarre) convient quand l'export est petit et prévisible. Pensez à quelques centaines de lignes, des colonnes basiques, pas de rendu lourd et pas trop d'utilisateurs simultanés. Si ça se termine toujours en quelques secondes, la simplicité est souvent préférable.
Pour tout ce qui est long ou imprévisible, utilisez des tâches d'export asynchrones. Cela convient aux gros jeux de données, aux calculs complexes, au rendu PDF et aux serveurs partagés où un export lent peut bloquer d'autres requêtes.
Les tâches asynchrones conviennent mieux quand :
Les téléchargements en streaming aident aussi quand l'export est volumineux mais peut être produit dans l'ordre. Le serveur commence à envoyer des octets immédiatement, ce qui semble plus rapide et évite de construire tout le fichier en mémoire. C'est idéal pour de longs CSV, mais moins utile si vous devez tout calculer avant d'écrire la première ligne.
Vous pouvez combiner les approches : lancez une tâche asynchrone pour générer l'export (ou préparer un snapshot), puis streamez le téléchargement quand il est prêt. Dans AppMaster, une approche pratique consiste à créer un enregistrement "Export Requested", générer le fichier dans un processus backend et laisser l'utilisateur télécharger le résultat fini sans garder sa requête navigateur ouverte.
Le changement principal est simple : cessez de générer le fichier dans la même requête que celle où l'utilisateur clique.
Une tâche d'export asynchrone sépare le travail en deux parties : une requête rapide qui crée une tâche, et un travail en arrière-plan qui construit le fichier pendant que l'app reste réactive.
Conservez l'enregistrement de tâche comme source de vérité. Si l'utilisateur rafraîchit, change d'appareil ou ferme l'onglet, vous pouvez toujours afficher le même statut de tâche et le même bouton de téléchargement.
Exemple : un responsable support exporte tous les tickets du trimestre précédent. Au lieu d'attendre dans un onglet qui tourne, il voit une entrée de tâche passer de queued à done, puis le téléchargement apparaît. Dans AppMaster, vous pouvez modéliser la table de tâches dans le Data Designer, construire la logique en arrière-plan dans le Business Process Editor et utiliser un champ de statut pour piloter l'état de l'UI.
Un bon indicateur de progression réduit l'anxiété et empêche les gens de cliquer cinq fois sur Export. Il aide aussi à prévenir indirectement les expirations, car les utilisateurs acceptent d'attendre quand l'app montre un véritable avancement.
Montrez la progression avec des éléments concrets. Le pourcentage seul est souvent trompeur, alors associez-le à quelque chose de tangible :
Évitez la fausse précision. Si vous ne connaissez pas encore le total, n'affichez pas 73%. Utilisez d'abord des jalons, puis passez au pourcentage une fois le dénominateur connu. Un schéma simple est 0% à 10% pour la préparation, 10% à 90% basé sur les lignes traitées, et 90% à 100% pour la finalisation du fichier. Pour les PDFs aux tailles de page variables, suivez des vérités plus petites comme « enregistrements rendus » ou « sections complétées ».
Mettez à jour assez souvent pour que ça fasse vivant, mais pas tellement que vous surchargez la base de données ou la queue. Une approche courante est d'écrire la progression toutes les 1 à 3 secondes, ou tous les N enregistrements (par exemple toutes les 500 ou 1 000 lignes), selon ce qui est le moins fréquent. Enregistrez aussi un timestamp de heartbeat léger pour que l'UI puisse indiquer « Toujours en cours » même quand le pourcentage ne bouge pas.
Donnez le contrôle aux utilisateurs quand ça prend plus de temps que prévu. Permettez d'annuler un export en cours, d'en lancer un nouveau sans perdre le premier, et de consulter l'historique des exports avec statuts (Queued, Running, Failed, Ready) plus un court message d'erreur.
Dans AppMaster, un enregistrement typique ressemble à ExportJob (status, processed_count, total_count, step, updated_at). L'UI interroge cet enregistrement et affiche une progression honnête pendant que la tâche asynchrone génère le fichier en arrière-plan.
La plupart des expirations d'export surviennent parce que l'export tente de tout faire en une seule fois : trop de lignes, trop de colonnes, trop de jointures. La solution la plus rapide est de borner le travail pour que les utilisateurs exportent un morceau de données plus petit et plus clair.
Partez de l'objectif de l'utilisateur. Si quelqu'un a besoin des « factures du mois dernier qui ont échoué », ne mettez pas par défaut « toutes les factures de l'historique ». Faites en sorte que les filtres paraissent naturels, pas comme une corvée. Une simple plage de dates plus un filtre d'état réduit souvent le dataset de 90%.
Un bon formulaire d'export comprend généralement une plage de dates (avec des valeurs par défaut sensées comme 7 ou 30 derniers jours), un ou deux statuts clés, une recherche optionnelle ou une sélection client/équipe, et un aperçu du nombre quand c'est possible (même une estimation).
Côté serveur, lisez les données par tranche en utilisant la pagination. Cela maintient la mémoire stable et vous donne des points de contrôle naturels pour la progression. Utilisez toujours un tri stable lors du paging (par exemple order by created_at, puis id). Sans cela, de nouvelles lignes peuvent glisser dans des pages précédentes et vous risquez de manquer ou dupliquer des enregistrements.
Les données changent pendant les exports longs, alors décidez ce que signifie « cohérent ». Une approche simple consiste à enregistrer un snapshot time au démarrage de la tâche, puis n'exporter que les lignes jusqu'à ce timestamp. Si vous avez besoin d'une cohérence stricte, utilisez une lecture cohérente ou une transaction lorsque votre base le supporte.
Dans un outil no-code comme AppMaster, cela se traduit naturellement par un business process : valider les filtres, définir l'heure de snapshot, puis boucler sur les pages jusqu'à ce qu'il n'y ait plus rien à récupérer.
Le streaming signifie que vous commencez à envoyer le fichier à l'utilisateur pendant que vous le générez encore. Le serveur n'a pas à construire tout le CSV ou le PDF en mémoire en premier. C'est l'une des méthodes les plus fiables pour éviter les expirations quand les fichiers deviennent volumineux.
Le streaming ne rend pas magiquement les requêtes lentes plus rapides. Si le travail en base prend cinq minutes avant que le premier octet soit prêt, la requête peut toujours expirer. La solution habituelle est de combiner le streaming avec le paging : récupérez un chunk, écrivez-le, puis continuez.
Pour garder la mémoire basse, écrivez au fur et à mesure. Générez un chunk (par exemple 1 000 lignes CSV ou une page PDF), écrivez-le dans la réponse, puis flush pour que le client continue de recevoir des données. Évitez de collecter des lignes dans un grand tableau « juste pour trier après ». Si vous avez besoin d'un ordre stable, triez dans la base.
Utilisez des en-têtes clairs pour que les navigateurs et les apps mobiles traitent correctement le téléchargement. Définissez le bon content-type (comme text/csv ou application/pdf) et un nom de fichier sûr. Les noms de fichiers doivent éviter les caractères spéciaux, rester courts et inclure un timestamp si les utilisateurs exportent plusieurs fois le même rapport.
Décidez tôt si vous supportez la reprise. Le streaming de base ne supporte souvent pas la reprise par plages d'octets, surtout pour les PDFs générés. Si vous la supportez, vous devez gérer les requêtes Range et générer une sortie cohérente pour la même tâche.
Avant la mise en production, assurez-vous de :
Si vous construisez des exports dans AppMaster, gardez la logique de génération dans un flux backend et streamez depuis le serveur, pas depuis le navigateur.
Pour les gros CSV, cessez de traiter le fichier comme un seul blob. Construisez-le en boucle : lisez une tranche de données, écrivez des lignes, répétez. Cela maintient la mémoire plate et rend les réessais plus sûrs.
Écrivez le CSV ligne par ligne. Même si vous générez l'export dans une tâche asynchrone, évitez de "collecter toutes les lignes, puis stringify". Gardez un writer ouvert et ajoutez chaque ligne dès qu'elle est prête. Si votre stack le permet, utilisez un curseur de base de données ou pagez les résultats pour ne jamais charger des millions d'enregistrements d'un coup.
La conformité CSV compte autant que la vitesse. Un fichier peut sembler correct jusqu'à ce que quelqu'un l'ouvre dans Excel et que la moitié des colonnes se décalent.
Les performances meurent souvent sur l'accès aux données, pas sur l'écriture. Surveillez les N+1 (comme charger chaque client dans une boucle). Récupérez les données liées en une seule requête ou préchargez ce dont vous avez besoin, puis écrivez les lignes.
Quand les exports sont vraiment gigantesques, fractionnez-les volontairement. Une approche pratique est un fichier par mois, par client ou par type d'entité. Un export « 5 ans de commandes » peut devenir 60 fichiers mensuels, chacun généré indépendamment, ainsi un mois lent n'empêche pas le reste.
Si vous utilisez AppMaster, modélisez le dataset dans le Data Designer et exécutez l'export comme un business process en arrière-plan, écrivant les lignes au fur et à mesure que vous parcourez les enregistrements.
La génération PDF est généralement plus lente que le CSV car elle est gourmande en CPU. Vous ne déplacez pas seulement des données : vous mettez en page, placez des polices, dessinez des tables et redimensionnez souvent des images. Traitez le PDF comme une tâche en arrière-plan avec des limites claires, pas comme une réponse rapide.
Les choix de template déterminent si un export de 2 minutes devient un export de 20 minutes. Les mises en page simples gagnent : moins de colonnes, moins de tableaux imbriqués et des sauts de page prévisibles. Les images ralentissent énormément, surtout si elles sont grandes, haute résolution ou récupérées depuis un stockage distant lors du rendu.
Décisions de template qui améliorent généralement la vitesse et la fiabilité :
Pour les gros exports, rendez par lots. Générez une section ou une petite plage de pages à la fois, écrivez-la dans un fichier temporaire, puis assemblez le PDF final. Cela maintient la mémoire stable et rend les réessais plus sûrs si un worker plante à mi-chemin. Cela se marie bien avec les tâches asynchrones et une progression montrant des étapes significatives (par exemple : "Préparation des données", "Rendu pages 1-50", "Finalisation du fichier").
Remettez aussi en question si le PDF est réellement nécessaire. Si les utilisateurs veulent surtout des lignes et colonnes pour analyse, proposez le CSV en parallèle du « Export PDF ». Vous pouvez toujours générer un PDF résumé plus petit pour le reporting tout en gardant l'intégralité en CSV.
Dans AppMaster, cela s'intègre naturellement : exécutez la génération PDF en tâche de fond, signalez la progression et fournissez le fichier fini en téléchargement une fois la tâche terminée.
Les échecs d'export ne sont généralement pas mystérieux. Quelques choix fonctionnent bien à 200 lignes, puis s'effondrent à 200 000.
Les erreurs les plus courantes :
Un exemple concret : un responsable support exporte tous les tickets des deux dernières années et clique deux fois parce que rien ne semble se passer. Maintenant deux exports identiques concourent pour la même base de données, construisent d'énormes fichiers en mémoire et finissent par expirer.
Si vous construisez ceci dans un outil no-code comme AppMaster, les mêmes règles s'appliquent : sortez les exports du chemin de la requête, suivez la progression par lignes traitées, écrivez la sortie au fur et à mesure, et imposez des limites simples sur le nombre d'exports simultanés qu'un utilisateur peut lancer.
Avant de publier une fonctionnalité d'export en production, faites un passage rapide avec l'état d'esprit « timeout ». Le travail long se passe hors requête, les utilisateurs voient une progression honnête, et le serveur ne tente jamais de tout faire à la fois.
Une checklist pré-vol rapide :
Un bon test de sanité est d'essayer votre pire cas : exportez la plus grande plage de dates autorisée pendant que quelqu'un ajoute des enregistrements. Si vous voyez des duplicatas, des lignes manquantes ou une progression bloquée, votre ordre ou découpage n'est pas stable.
Si vous construisez sur AppMaster, ces vérifications se traduisent clairement : un process background dans le Business Process Editor, un enregistrement d'export dans la base, et un champ de statut que l'UI lit et rafraîchit.
Rendez l'échec sûr. Une tâche échouée doit garder son message d'erreur, permettre un retry et éviter de produire des fichiers partiels qui semblent « terminés » mais sont incomplets.
Un responsable ops a besoin de deux exports chaque mois : un CSV avec les 2 dernières années de commandes pour l'analyse, et un ensemble de PDFs de factures mensuelles pour la comptabilité. Si votre app essaie de construire l'un ou l'autre pendant une requête web normale, vous atteindrez tôt ou tard les limites de temps.
Commencez par borner le travail. L'écran d'export demande une plage de dates (par défaut : 30 derniers jours), des filtres optionnels (statut, région, commercial) et un choix clair de colonnes. Ce simple changement transforme souvent un problème de 2 ans et 2 millions de lignes en quelque chose de gérable.
Quand l'utilisateur clique sur Export, l'app crée un enregistrement Export Job (type, filtres, requested_by, status, progress, error_text) et le met en queue. Dans AppMaster, c'est un modèle Data Designer plus un Business Process qui s'exécute en arrière-plan.
Pendant que la tâche tourne, l'UI affiche un statut digne de confiance : queued, processing (par exemple 3 de 20 chunks), generating file, ready (bouton de téléchargement) ou failed (erreur claire et possibilité de retry).
Le chunking est le détail clé. Le job CSV lit les commandes par pages (par exemple 50 000 à la fois), écrit chaque page en sortie et met à jour la progression après chaque chunk. Le job PDF fait de même par lot de factures (par exemple par mois), ainsi un mois lent ne bloque pas tout.
Si quelque chose casse (filtre erroné, permission manquante, erreur de stockage), la tâche est marquée Failed avec un message court que l'utilisateur peut utiliser : "Impossible de générer les factures de mars. Veuillez réessayer ou contacter le support avec l'ID de tâche 8F21." Un retry réutilise les mêmes filtres pour que l'utilisateur n'ait pas à tout recommencer.
La façon la plus rapide d'éviter les expirations d'export à long terme est de cesser de traiter les exports comme un bouton ponctuel et d'en faire une fonctionnalité standard avec un schéma reproductible.
Choisissez une approche par défaut et utilisez-la partout : une tâche asynchrone génère un fichier en arrière-plan, puis l'utilisateur obtient une option de téléchargement quand c'est prêt. Cette décision unique élimine la plupart des surprises « ça marchait en test », car la requête utilisateur n'attend plus le fichier complet.
Facilitez la recherche des exports déjà générés. Une page d'historique d'exports (par utilisateur, workspace ou compte) réduit les exports répétés, aide le support à répondre « où est mon fichier ? » et vous donne un endroit naturel pour afficher statut, erreurs et expiration.
Si vous construisez ce pattern dans AppMaster, le fait que la plateforme génère du code source réel et supporte la logique backend, la modélisation de la base et l'UI web/mobile en un seul endroit aide. Pour des équipes qui veulent livrer rapidement des tâches d'export asynchrones fiables, appmaster.io est souvent utilisé pour construire la table de tâches, le processus background et l'UI de progression sans tout câbler à la main.
Ensuite, mesurez ce qui fait réellement mal. Suivez les requêtes lentes, la durée de génération CSV et le temps de rendu PDF. Vous n'avez pas besoin d'une observabilité parfaite pour commencer : logger la durée et le nombre de lignes par export montrera vite quel rapport ou quelles combinaisons de filtres posent problème.
Traitez les exports comme toute autre fonctionnalité produit : cohérents, mesurables et faciles à supporter.
Pourquoi les exports expirent-ils même s'ils fonctionnent parfois ?Un export expire quand le travail ne se termine pas avant une limite définie quelque part sur le chemin de la requête. Cette limite peut venir du navigateur, d'un reverse proxy, de votre serveur d'applications ou de la connexion à la base de données, donc ça peut sembler aléatoire même si la cause est une charge constante ou des requêtes lentes.
Quand un export « cliquer et télécharger » est-il acceptable, et quand devrais-je utiliser des tâches asynchrones ?Utilisez un export synchrone simple seulement s'il se termine de façon fiable en quelques secondes avec une taille de données prévisible. Si les exports durent souvent plus de 10–15 secondes, couvrent de larges plages de dates, impliquent des calculs lourds ou des PDFs, passez à une tâche asynchrone pour que la requête du navigateur n'ait pas à rester ouverte.
Quel est le flux asynchrone le plus simple que je peux mettre en place dans AppMaster ?Créez d'abord un enregistrement de tâche, faites ensuite le travail lourd en arrière-plan, et enfin laissez l'utilisateur télécharger le fichier terminé. Dans AppMaster, un montage courant est un modèle ExportJob dans le Data Designer et un Business Process backend qui met à jour status, les champs de progression et une référence au fichier stocké pendant l'exécution.
Comment afficher une progression que les utilisateurs peuvent réellement croire ?Suivez le travail réel, pas le temps écoulé. Une approche pratique consiste à stocker des champs comme step, processed_count, total_count (quand il est connu) et updated_at, puis laisser l'UI interroger ces champs pour afficher des changements d'état clairs afin que les utilisateurs n'aient pas l'impression d'être bloqués et de relancer l'export.
Comment empêcher les utilisateurs de lancer plusieurs fois le même export ?Rendez la requête d'export idempotente et gardez l'enregistrement de tâche comme source de vérité. Si l'utilisateur clique à nouveau, affichez la tâche en cours existante (ou bloquez les duplicatas pour les mêmes filtres) au lieu de lancer le même travail coûteux deux fois.
Quelle est la façon la plus sûre de paginer les données pour de gros exports ?Lisez et écrivez par tranches pour que la mémoire reste stable et que vous disposiez de points de contrôle naturels. Utilisez une pagination stable avec un tri déterministe (par exemple, par created_at puis id) afin de ne pas manquer ou dupliquer des lignes lorsque les données changent pendant un long export.
Comment conserver la cohérence des exports si les données changent pendant l'exécution ?Enregistrez un instantané (snapshot) au démarrage de la tâche et exportez seulement les lignes jusqu'à ce timestamp pour que la sortie ne « bouge » pas pendant l'exécution. Si vous avez besoin de garanties plus fortes, utilisez des lectures cohérentes ou des stratégies transactionnelles supportées par votre base de données, mais commencez par une règle d'instantané simple que la plupart des utilisateurs comprendront.
Le streaming empêche-t-il les expirations à lui seul ?Le streaming aide lorsqu'on peut produire la sortie dans l'ordre et commencer à envoyer des octets tôt, surtout pour les gros CSV. Il ne résoudra pas des requêtes lentes qui prennent plusieurs minutes avant le premier octet, et la connexion peut toujours expirer si rien n'est écrit pendant trop longtemps. Le streaming fonctionne mieux combiné à la pagination qui écrit des morceaux continuellement.
Quelles sont les causes les plus courantes d'exports CSV cassés ou lents ?Écrivez les lignes au fur et à mesure et respectez l'échappement CSV strict pour que le fichier ne casse pas dans Excel ou d'autres outils. Maintenez un encodage cohérent (généralement UTF-8), conservez des en-têtes et un ordre de colonnes stables, et évitez les requêtes par ligne (N+1) qui transforment un export en des milliers de requêtes supplémentaires.
Pourquoi les exports PDF échouent-ils plus souvent que les CSV, et comment les rendre fiables ?La génération de PDF est plus gourmande en CPU car elle implique la mise en page, les polices, les images et les sauts de page. Traitez-la comme une tâche en arrière-plan avec des limites claires. Simplifiez les modèles, évitez les images volumineuses ou distantes lors du rendu, et rapportez la progression en étapes significatives pour que les utilisateurs sachent que ça avance.
21 janv. 2026
8 min
20 janv. 20268 min
20 janv. 20268 minExpérimentez avec AppMaster avec un plan gratuit.
Lorsque vous serez prêt, vous pourrez choisir l'abonnement approprié.
