Ciama : exporter une recherche de commandes sans bloquer le cockpit

1. Ciama, une vue unifiée de commandes qui continuent d’évoluer

Partager une sélection sans détacher le fichier de son contexte

Ciama réunit dans une même recherche les commandes issues des canaux connectés. Chaque ligne porte son canal, son identifiant, son statut, son mode de fulfilment, son pays de livraison, ses dates et les montants calculés dans la devise source ou convertis.

Cette matière sert plusieurs usages. Le support recherche une commande précise ; les opérations isolent les statuts à traiter ; la direction compare revenus, frais et marge ; la finance a besoin d’une sélection à contrôler ou à rapprocher. Le même écran peut donc conduire à des fichiers très différents selon les filtres actifs.

Mais un export reste une photographie. Une commande peut être expédiée, annulée, recalculée ou resynchronisée après la génération. Le projet devait faciliter le partage sans laisser croire que le fichier remplace la donnée courante, ni confondre la progression technique du rapport avec l’avancement métier des commandes.

2. Découpler la demande web de la fabrication du fichier

Créer une trace immédiatement, puis laisser un traitement dédié parcourir les données

La première version complète a été livrée le 21 février 2026. Elle a réuni le formulaire d’export de la recherche, le rapport persistant, le message de génération, le traitement en arrière-plan, la page de progression et le téléchargement contrôlé.

Le découpage répond à une contrainte simple : la durée de génération dépend du nombre de commandes, alors qu’une interaction web doit rester courte. Ciama enregistre donc un rapport « en attente », transmet son identifiant et les filtres au moteur de messages, puis redirige immédiatement vers la recherche.

Le traitement retrouve ensuite le compte et le rapport, vérifie leur relation, recompte le résultat et écrit le fichier par lots. La progression, le nombre de lignes, le nom, le chemin, la durée et la date de fin sont conservés dans le même objet pour suivre tout le cycle.

3. Avant le projet : la bonne liste était enfermée dans la page

Consulter quelques commandes et transmettre tout un périmètre sont deux charges différentes

La recherche de commandes savait déjà présenter un résultat paginé. Elle était adaptée à la consultation : ouvrir une ligne, regarder son statut, comparer ses montants ou changer un filtre. Mais le navigateur ne devait pas porter seul la fabrication d’un fichier comprenant potentiellement bien plus de lignes que la page affichée.

Un export naïf aurait créé deux risques. Le premier était technique : une requête longue pouvait dépasser son délai ou mobiliser inutilement le serveur web. Le second était fonctionnel : reconstruire une requête différente de celle de l’écran pouvait ajouter ou retirer des commandes sans que l’utilisateur le comprenne.

La richesse des données rendait le sujet plus sensible. Les revenus, frais de commission, frais logistiques, coût d’achat et marge ne sont pas des colonnes décoratives. Un fichier incomplet ou décalé peut modifier la lecture d’une sélection et propager une mauvaise décision hors du cockpit.

Le chantier a donc été recentré sur une promesse contrôlable : demander le rapport depuis la recherche active, conserver son propriétaire et son état, traiter le volume ailleurs, puis ne rendre le fichier disponible qu’une fois terminé.

4. Préserver le périmètre, la fluidité et la responsabilité

Trois conditions pour qu’un export devienne réellement opérationnel

Préserver le périmètre signifie transporter les critères utiles de la recherche vers le traitement. La commande exportée doit appartenir au compte connecté et satisfaire les mêmes filtres métier que la liste demandée, indépendamment de la pagination visible.

Préserver la fluidité signifie ne pas attendre la fin du fichier dans la requête du bouton. La page doit pouvoir se recharger avec un état « en attente », pendant qu’un consommateur spécialisé calcule et écrit le rapport.

Préserver la responsabilité signifie lier chaque rapport à son compte. Un identifiant de rapport ne doit pas suffire pour consulter son statut ou récupérer son fichier depuis une autre organisation. Cette règle doit exister dans le traitement comme dans les endpoints de restitution.

Enfin, le rapport devait rester compréhensible. Son format, ses colonnes et ses états devaient être explicites ; un échec devait arrêter le suivi comme erreur plutôt que laisser indéfiniment une barre de progression ambiguë.

5. Créer le rapport au moment du clic

Une identité stable avant même que la première ligne soit écrite

Le formulaire d’export vit dans l’en-tête de la recherche de commandes. Il reprend les paramètres actifs, à l’exception de la page et de la limite de pagination : le fichier porte sur le résultat filtré complet, pas seulement sur les lignes actuellement visibles.

L’utilisateur choisit CSV ou Excel. Une valeur inconnue est ramenée au CSV. Le contrôleur filtre aussi les paramètres entrants à partir d’une liste autorisée ; un champ arbitraire ajouté à la requête ne devient pas automatiquement une contrainte de lecture.

Ciama crée alors un identifiant unique, rattache le rapport au compte, renseigne son type « export de recherche de commandes » et le place dans l’état « en attente ». Cette trace existe avant la mise en file : le navigateur dispose immédiatement d’un objet à suivre.

La redirection revient sur la recherche avec les filtres conservés et l’identifiant du rapport. L’export ne remplace donc pas le contexte de travail. L’équipe peut continuer à lire sa liste tandis que le composant global de suivi prend le relais.

6. Rejouer les filtres utiles sans accepter toute la requête

Dix-neuf critères métier et un tri traités explicitement

Le générateur accepte une recherche textuelle, un statut, un canal, une année et un mois. Il peut aussi reprendre les bornes de création, de mise à jour et d’achat, un identifiant de commande et le mode de fulfilment.

Les critères financiers couvrent les montants minimum et maximum ainsi que les seuils de taux de marge. Le pays de livraison et la devise complètent le périmètre. Les valeurs vides ou structurées comme des tableaux sont ignorées lorsqu’un scalaire est attendu.

Le compte n’est jamais repris depuis un filtre envoyé par le navigateur. Il est ajouté par le traitement à partir de l’identité portée dans le message. Cette règle empêche qu’un paramètre de formulaire élargisse l’export aux commandes d’un autre compte.

Le tri demandé est traité à part, avec une direction limitée aux valeurs ascendante, descendante ou par défaut. En l’absence de choix, les commandes sont ordonnées sur leur date d’achat, de la plus récente à la plus ancienne.

7. Choisir seize colonnes qui expliquent la commande et sa marge

Des identifiants jusqu’aux coûts, sans exporter toute la base

Chaque ligne commence par le canal, l’identifiant de commande, le statut, le mode de fulfilment et le pays de livraison. Les dates d’achat et de dernière mise à jour replacent ensuite l’état commercial dans le temps.

Les montants distinguent le total TTC dans la devise source, le total TTC converti et le revenu hors taxes converti. La TVA convertie reste une colonne propre ; elle n’est pas noyée dans un calcul présenté uniquement sous forme de marge.

Trois familles de coûts sont exposées : commissions du canal, frais de livraison et coût d’achat, tous dans leur valeur hors taxes convertie disponible. Le total de marge et le taux de marge ferment la ligne.

Ce contrat de seize colonnes évite un export « de tout ». Il répond à une lecture précise : reconnaître la commande, comprendre son exécution et décomposer son économie. Les lignes de commande, adresses complètes ou données client détaillées ne sont pas ajoutées à ce rapport.

8. Parcourir les commandes par lots de 500

Mesurer le volume avant de produire le fichier

Au démarrage, le traitement retrouve le compte et le rapport. Il refuse de continuer si l’un manque ou si le rapport appartient à une autre organisation. Une fois ces contrôles passés, le statut devient « en génération » et la progression repart de zéro.

Une première requête compte les résultats qui correspondent aux filtres. Le nombre est enregistré sur le rapport et la progression passe à 5 %. Cette étape donne un dénominateur au suivi avant la lecture effective des commandes.

Les entités sont ensuite chargées par pages de 500 avec les mêmes filtres et le même tri. Chaque page est écrite immédiatement dans le fichier, puis le nombre traité alimente la progression. La mémoire ne doit donc pas contenir tout le résultat simultanément.

La progression intermédiaire est plafonnée à 99 %. Le passage à 100 % intervient seulement après la fermeture du fichier et l’enregistrement de son nom, de son chemin, de sa date de fin et de sa durée totale.

9. Afficher un état utile sans retenir l’utilisateur

Une barre commune suit le rapport depuis toutes les pages concernées

Lorsque l’URL contient l’identifiant de l’export, le layout du back-office affiche une carte dédiée. Elle commence dans l’état « en attente », montre le nom du fichier dès qu’il existe et fait progresser une barre entre zéro et cent.

Le navigateur interroge l’endpoint de statut après un court délai, puis environ toutes les deux secondes tant que le travail continue. Une réponse HTTP temporairement indisponible déclenche une nouvelle tentative plus espacée au lieu de supprimer immédiatement le suivi.

Quand le rapport est terminé, l’animation s’arrête et le bouton de téléchargement apparaît avec l’URL calculée côté serveur. Si le rapport passe en erreur, la barre devient rouge et le polling s’arrête. Le navigateur ne propose donc pas un lien vers un fichier incomplet.

Les quatre états — en attente, en génération, terminé et en erreur — séparent clairement la file, le travail, la réussite et l’échec. Ils appartiennent au rapport, pas aux commandes elles-mêmes.

10. Proposer CSV et compatibilité tableur sans masquer leur différence

Deux sorties simples, conçues pour la manipulation opérationnelle

En CSV, Ciama ouvre le fichier en écriture, ajoute la ligne d’en-tête puis utilise le mécanisme CSV du langage pour chaque commande. Les séparateurs, guillemets et valeurs vides sont donc gérés comme des cellules plutôt que par une concaténation manuelle fragile.

L’option appelée Excel écrit un document HTML encodé en UTF-8, composé d’un tableau avec cellules d’en-tête et cellules de données, puis lui donne une extension .xls. Les valeurs sont échappées avant d’entrer dans le balisage.

Ce format est pratique pour ouvrir rapidement le résultat dans un tableur, mais ce n’est pas un classeur XLSX natif. Il ne porte ni types riches, ni feuilles multiples, ni styles métiers, ni formules. Le présenter honnêtement évite de promettre des capacités que le générateur ne possède pas.

Le nom inclut le format demandé et l’heure de génération. Il aide à distinguer deux extractions successives, sans pour autant constituer une gestion de versions ou une politique d’archivage documentaire.

11. Isoler le rapport et son fichier par compte

Contrôler la propriété pendant la génération, le statut et le téléchargement

Le rapport est rattaché au compte dès sa création. Le traitement vérifie à nouveau que le compte du message correspond à celui du rapport avant d’interroger les commandes. Cette double information ne sert pas à élargir l’accès : elle sert à détecter une incohérence.

Le dossier de sortie est lui aussi segmenté par identifiant de compte, puis par type de rapport. Ce rangement réduit les collisions de noms et garde les fichiers de recherche de commandes séparés des autres rapports générés par Ciama.

L’endpoint de statut utilise un résolveur qui compare le compte de l’utilisateur connecté à celui du rapport. Une demande étrangère reçoit une absence. Le lien de téléchargement n’est fourni que pour un rapport terminé.

Au téléchargement, Ciama refait le contrôle de propriété, exige l’état terminé, vérifie qu’un chemin existe puis contrôle la présence effective du fichier. La réponse force une pièce jointe avec le nom enregistré ; connaître un identifiant ne suffit pas à récupérer le contenu.

12. Les arbitrages qui protègent le run

Faire moins dans la requête web pour mieux maîtriser le volume

Premier arbitrage : exporter le résultat complet des filtres, mais exclure page et limite. La liste visible reste une interface de navigation ; le rapport représente le périmètre demandé, pas un écran de vingt ou cinquante lignes.

Deuxième arbitrage : imposer une liste de filtres admis. Cette discipline limite les divergences entre le contrôleur et le générateur et empêche qu’un nouveau paramètre d’URL influence le rapport avant d’avoir été explicitement pris en charge.

Troisième arbitrage : compter avant de parcourir. Cette requête supplémentaire a un coût, mais elle rend le nombre de lignes et la progression calculables. Sans elle, la barre serait une animation sans rapport vérifiable avec le volume.

Quatrième arbitrage : conserver CSV et un .xls simple au lieu de construire immédiatement un moteur de classeurs complexes. Le projet privilégie une donnée tabulaire stable et une génération progressive ; les enrichissements de présentation restent hors de son cœur.

13. Prévoir les échecs à chaque frontière

Base, filesystem et worker peuvent chacun interrompre la génération

Le traitement encadre toute la génération. Un compte absent, un rapport introuvable, une propriété incohérente, un dossier impossible à créer ou un fichier impossible à ouvrir conduit au même résultat explicite : le rapport passe en erreur et l’exception est inscrite dans les journaux.

Les dossiers nécessaires sont créés avant l’écriture et leur existence est revérifiée. Le fichier n’est déclaré terminé qu’après la dernière ligne et sa fermeture. Le chemin et le nom ne suffisent donc pas à faire apparaître trop tôt le bouton de téléchargement.

Les montants absents restent des cellules vides plutôt que des zéros inventés. Le mode de fulfilment devient oui ou non, le pays disparaît proprement lorsqu’il est inconnu et les dates sont formatées de manière stable. Le fichier conserve ainsi la distinction entre absence et valeur nulle connue.

Les contrôles applicatifs couvrent la route de demande d’export avec un utilisateur et des données autonomes. Les composants de rapport sont aussi utilisés par les rapports de marge et de matrice d’offres, ce qui exerce le cycle partagé de progression et de téléchargement dans plusieurs parcours.

14. Une livraison reliée à une file dédiée de reporting

Du premier parcours en février à un statut unifié en avril 2026

Le 21 février 2026, Dawap a livré le rapport de recherche de commandes avec son message, son traitement, ses routes, son formulaire et sa restitution. Cette date marque le premier parcours fonctionnel complet, de la sélection au fichier.

Pendant la migration technique de mars, les composants ont été portés dans le nouveau socle Symfony et le transport de messages a été configuré pour le reporting. Le générateur de commandes possède sa file dédiée afin que ces travaux de volume ne dépendent pas du traitement web.

Le 11 mars, l’interface de recherche et le générateur ont été consolidés dans ce socle, avec la liste actuelle des filtres et le suivi global. Le 26 avril, les routes de progression et de statut ont été séparées pour distinguer restitution HTML et réponse JSON interrogée par la page.

Cette évolution montre une livraison qui vit après son premier lot. Le mécanisme commun est partagé avec d’autres rapports asynchrones, tandis que le contrat de colonnes et les filtres de commandes restent propres à ce projet.

15. Ce qui change pour les équipes qui exploitent les commandes

Un partage plus fluide, un périmètre plus lisible et un fichier économique exploitable

L’utilisateur n’attend plus devant une réponse longue. Il déclenche le rapport, reste sur la recherche et voit son état progresser. Le travail de lecture des commandes peut continuer pendant que les pages de données sont traitées ailleurs.

Le périmètre est moins ambigu. Les filtres actifs accompagnent la demande, la pagination de l’écran n’ampute pas le résultat et le nombre total est conservé sur le rapport. Une extraction terminée peut être reliée à son instant de création et à son format.

Les seize colonnes réunissent exploitation et économie. Support, opérations ou finance peuvent reconnaître le canal et le statut, puis lire revenu, TVA, commissions, livraison, achat et marge sans assembler plusieurs fichiers au préalable.

Le gain reste qualitatif faute de mesure chronométrée disponible : moins de risque de timeout web, moins de reconstruction manuelle du périmètre et une frontière d’accès appliquée au rapport. Aucun pourcentage de temps gagné ni effet sur le chiffre d’affaires n’est inventé.

16. Le scénario qui justifie le traitement en arrière-plan

Transmettre les commandes à faible marge d’un canal sans exporter le reste

Une responsable sélectionne une marketplace, une période d’achat et un taux de marge maximum. La recherche lui permet de vérifier quelques lignes, mais elle doit transmettre l’ensemble à la personne chargée de contrôler frais et coûts d’achat.

Elle choisit CSV et déclenche l’export. Ciama ignore la page courante, conserve les filtres admis, crée le rapport pour son compte et revient sur la liste. La carte de progression apparaît pendant que le worker compte puis traite les commandes par blocs de 500.

Chaque ligne rassemble l’identifiant, le statut, le pays, les dates, les montants source et convertis, les trois familles de frais, la marge et son taux. Une fois le fichier fermé, le rapport passe à 100 % et le lien de téléchargement devient visible.

Le fichier peut alimenter une revue ponctuelle. Si une ligne soulève un doute, la responsable revient vers la commande centralisée dans Ciama pour consulter son état actuel. Le rapport aide la discussion ; le cockpit reste la référence vivante.

17. Les limites qui maintiennent la preuve au bon niveau

Un export filtré ne remplace ni un historique figé ni un entrepôt analytique

Le générateur lit les commandes par pages successives. Il ne crée pas d’instantané transactionnel de toute la sélection avant de commencer. Si les données évoluent pendant un export très long, le fichier représente le parcours effectué, pas une photographie certifiée à la milliseconde.

La segmentation par compte organise l’accès aux fichiers. Une politique de conservation et de purge peut compléter ce dispositif lorsque la rétention devient un enjeu contractuel.

Le format .xls n’est pas un classeur natif ; le CSV n’embarque ni mise en forme, ni graphique, ni formule. Le rapport privilégie le transport des valeurs. Une présentation financière officielle demanderait un livrable et des contrôles supplémentaires.

Le périmètre livré couvre un parcours d’export de commandes précis. Le reporting des ventes multicanal et les modules spécialisés prennent en charge les analyses de stocks, produits, reprises et alertes selon leurs propres règles.

18. Relier recherche, marge et action sans multiplier les vérités

Une sortie de travail qui garde un chemin clair vers sa donnée vivante

La centralisation des commandes marketplace fournit les identités, statuts et montants que l’export restitue. Sans cette normalisation amont, seize colonnes homogènes ne seraient qu’une façade sur des canaux incompatibles.

Le projet calcul de marge par commande explique comment revenus et coûts deviennent une lecture économique. L’export donne ensuite à cette lecture une forme tabulaire partageable sur un périmètre choisi.

Le reporting marketplace vendeur répond aux tendances et comparaisons agrégées. L’export de recherche répond à une autre question : quelles commandes composent précisément le segment que nous devons examiner maintenant ?

Dans Ciama Marketplace, les deux usages se complètent : comprendre une trajectoire, isoler les lignes concernées, les partager, puis revenir à la commande lorsque son état doit être contrôlé ou traité.