Ciama : croiser chaque produit avec ses stocks et ses offres par canal

1. Ciama, un référentiel où produit, entrepôt et canal gardent leur rôle

Construire une vue transverse sans aplatir les objets métier

Ciama centralise un catalogue de produits et le relie à des stocks d’entrepôts ainsi qu’à des offres commerciales. Le produit porte son identité, son nom, sa marque et sa catégorie. Le stock décrit une quantité pour un produit dans un entrepôt. L’offre relie un produit à un canal de vente.

Ces relations sont simples prises séparément, mais leur absence devient difficile à repérer lorsque le nombre de colonnes augmente. Une référence peut exister dans le catalogue sans stock pour un entrepôt donné. Elle peut aussi être reliée à certains canaux et absente des autres, volontairement ou non.

Le projet ne cherche pas à décider automatiquement si chaque absence est une erreur. Il construit une surface de contrôle exportable. La personne qui connaît la stratégie d’assortiment peut repérer les cases à examiner, puis revenir aux vues détaillées pour distinguer choix commercial, défaut de synchronisation et simple périmètre hors cible.

2. Partir des relations déjà structurées dans Ciama

Transformer les dimensions du compte en colonnes au moment de la génération

Le premier parcours a été développé le 28 janvier 2026. Une première étape a posé la demande asynchrone et le générateur ; une seconde évolution, le même jour, a consolidé le rapport persistant, son stockage, son téléchargement et une commande de génération utilisable hors de l’interface.

Le traitement charge le compte, ses canaux actifs triés par nom, ses entrepôts actifs triés par nom et tous ses produits triés par identifiant. Ces collections définissent la forme exacte de la matrice au moment où elle est fabriquée.

Pour chaque produit, Ciama écrit ses quatre informations de reconnaissance, recherche son stock dans chacun des entrepôts sélectionnés et cherche une offre dans chacun des canaux sélectionnés. Le fichier est construit ligne après ligne tandis que le rapport conserve sa progression.

3. Avant le projet : une couverture visible seulement référence par référence

Les données existaient, mais leur combinaison demandait trop de navigation

Le produit, le stock et l’offre répondaient chacun à une question précise. Pour contrôler une référence, cette séparation était utile. Pour balayer tout un catalogue, elle imposait de répéter les mêmes vérifications : ouvrir le produit, parcourir les stocks, compter les canaux liés, puis recommencer.

Un export de produits seul n’aurait pas suffi. Il aurait montré les références sans leurs quantités par entrepôt. Un export d’offres seul aurait ignoré les produits sans offre, précisément ceux que la matrice devait pouvoir faire apparaître.

La difficulté était donc de choisir la bonne dimension de départ. En prenant les produits comme lignes, la matrice conserve aussi les références qui ne possèdent aucune offre. En transformant entrepôts et canaux en colonnes, elle rend les trous visibles sans générer plusieurs fichiers à rapprocher.

Cette lisibilité devait rester compatible avec un catalogue variable. Ajouter un canal ou un entrepôt ne devait pas exiger une nouvelle structure codée en dur. Les colonnes devaient refléter le compte actif au moment du rapport.

4. Produire une photographie de couverture, pas un diagnostic automatique

Voir les cases à examiner avant de chercher leur cause

Le premier objectif était l’exhaustivité des lignes : chaque produit connu du compte devait apparaître, qu’il possède ou non des stocks et des offres. La matrice ne devait pas commencer par les seules lignes commerciales existantes.

Le deuxième était la lisibilité en largeur. Pour un produit donné, la personne devait pouvoir parcourir les entrepôts puis les canaux dans un ordre stable, sans joindre manuellement plusieurs extractions.

Le troisième était la traçabilité de génération. Un catalogue volumineux ne devait pas être fabriqué dans une requête web sans état. Ciama devait créer un rapport, le traiter en arrière-plan, montrer sa progression et conserver le fichier terminé.

Le dernier objectif était de ne pas tirer une conclusion excessive de la case. Une quantité répond à une mesure locale ; OK ou Missing répond à une existence d’offre locale. La décision de publier, corriger ou exclure reste fondée sur des informations complémentaires.

5. Construire les colonnes à partir du compte actif

Entrepôts et canaux ne sont pas une liste mondiale figée

Au début de la génération, Ciama récupère uniquement les entrepôts actifs du compte et les trie par nom. Il fait de même avec les canaux actifs. Le fichier reflète donc la configuration exploitable de cette organisation au moment du lancement.

Le premier bloc de l’en-tête contient toujours Identifier, Name, Brand et Category. Viennent ensuite tous les noms d’entrepôts, puis tous les noms de canaux. Cette succession donne au lecteur deux zones : disponibilité physique d’abord, présence commerciale ensuite.

La largeur n’est pas fixe. Un compte avec deux entrepôts et cinq canaux obtient onze colonnes ; un compte sans entrepôt actif conserve seulement le bloc produit puis ses canaux. La même logique s’adapte sans modèle spécifique par client.

Cette souplesse a une contrepartie : deux rapports générés avant et après l’activation d’un canal peuvent avoir des colonnes différentes. Le nom et la date du fichier doivent donc rester associés à sa lecture ; la matrice n’est pas un schéma d’échange immuable.

6. Faire du produit la ligne de référence

Inclure aussi ce qui ne possède encore aucune relation commerciale

Le générateur charge tous les produits rattachés au compte et les trie par identifiant croissant. Il ne limite pas la ligne aux produits actifs, aux produits en stock ou aux produits déjà vendus. Cette absence de filtre est essentielle pour comprendre le périmètre.

Les quatre premières cellules reprennent l’identifiant, le nom, la marque et la catégorie. Marque et catégorie restent vides lorsque le produit ne possède pas ces relations. La matrice n’invente pas une classification pour rendre la ligne plus complète.

Choisir le produit comme axe principal évite un biais fréquent : commencer par les offres ferait disparaître les références sans offre. Ici, un produit entièrement absent des canaux reste visible et produit une suite de cellules Missing.

En revanche, la présence de tous les produits ne signifie pas que chacun devrait être diffusé partout. Une référence inactive, réservée au B2B ou exclue d’un assortiment peut apparaître légitimement. La matrice révèle la structure ; elle ne connaît pas à elle seule la stratégie.

7. Afficher une quantité pour chaque entrepôt actif

Une recherche précise par compte, produit et entrepôt

Pour chaque cellule de la zone stock, Ciama cherche une parcelle qui correspond au compte, à l’entrepôt et au produit de la ligne. Si elle existe, sa quantité courante est écrite dans le CSV.

Si aucune parcelle n’est trouvée, le générateur écrit zéro. Ce choix rend le tableau immédiatement calculable, mais il fusionne deux situations différentes : un stock connu à zéro et une relation de stock absente. La fiche publique conserve cette limite au lieu de présenter chaque zéro comme une rupture mesurée.

Seuls les entrepôts actifs définissent les colonnes. Un entrepôt désactivé ne figure pas dans le rapport même si des données historiques existent encore. La matrice s’aligne sur le périmètre opérationnel courant, pas sur l’historique complet du compte.

Pour approfondir une quantité, le projet stock multi-entrepôts dans Ciama restitue les parcelles et leurs contextes. La matrice sert au balayage ; la vue de stock sert à l’explication.

8. Répondre à une seule question par cellule canal

Une offre locale existe-t-elle pour ce produit et ce canal ?

Pour chaque canal actif, Ciama cherche une offre qui partage le compte, le produit et le canal. Lorsqu’une ligne est trouvée, la cellule contient OK. Lorsqu’aucune ligne ne correspond, elle contient Missing.

OK ne lit ni le champ actif de l’offre, ni son stock, ni son prix, ni sa réponse marketplace. Il ne garantit pas que la fiche soit publiée, visible, acceptée ou éligible à la vente. Il confirme seulement que Ciama possède cette relation locale.

Missing ne fournit pas davantage une cause. Le produit peut être volontairement absent de ce canal, son offre peut ne pas avoir été collectée ou sa relation produit peut manquer. La cellule indique où enquêter ; elle ne qualifie pas automatiquement une erreur.

Tous les canaux actifs du compte sont inclus, sans filtre explicite sur le type marketplace dans le générateur. Si Ciama porte aussi des canaux e-commerce ou B2B actifs, ils deviennent eux aussi des colonnes. Le titre historique « listing marketplace » ne doit donc pas masquer ce périmètre plus large.

9. Générer le CSV en arrière-plan

Séparer le déclenchement de la construction de la matrice

Depuis la page Offer Listing Matrix, une action crée un rapport identifié, rattaché au compte et placé en attente. Un message contenant le compte et le rapport est ensuite envoyé au traitement dédié. L’interface confirme que la génération va commencer puis revient à la liste.

Le générateur vérifie l’existence du compte et du rapport ainsi que leur correspondance. Il passe ensuite le rapport en génération, charge les dimensions et enregistre comme nombre de lignes la quantité totale de produits.

Le fichier CSV est rangé dans un dossier propre au compte et au type Offer Listing Matrix. Son nom contient la date et l’heure de génération. L’en-tête est écrit une fois, puis chaque produit produit immédiatement sa ligne.

Tous les dix produits, ou lorsque le dernier est atteint, Ciama recalcule le pourcentage et persiste la progression. Une fois le fichier fermé, le rapport passe à terminé avec son nom, son chemin, sa date de fin et sa durée en secondes.

10. Conserver les générations au lieu de remplacer le dernier fichier

Date, état, progression, lignes, durée et téléchargement réunis

La page liste les rapports Offer Listing Matrix du compte, du plus récent au plus ancien. Chaque ligne affiche la date de demande, le statut, la progression, le nombre de produits, la durée et le nom du fichier lorsqu’il existe.

Le statut distingue attente, génération, réussite et erreur. Tant que le rapport n’est pas terminé et qu’aucun chemin n’est disponible, la colonne Action reste vide. Le téléchargement apparaît seulement pour un fichier achevé.

Le contrôleur commun de téléchargement vérifie que le rapport appartient au compte connecté, qu’il est terminé, qu’un chemin est enregistré et que le fichier existe réellement. La réponse est envoyée comme pièce jointe avec son nom.

Cette liste forme une mémoire technique des exécutions. Elle ne conserve pas séparément la liste exacte des canaux et entrepôts utilisée dans des métadonnées structurées ; cette information se lit dans l’en-tête du CSV produit.

11. Lire une case comme un signal de vérification

Transformer la largeur du catalogue en questions ciblées

Une ligne avec du stock dans plusieurs entrepôts et Missing sur un canal attire naturellement l’attention. La bonne question n’est pas immédiatement « pourquoi la publication a échoué ? », mais « ce produit devait-il posséder une offre locale sur ce canal ? ».

Si la réponse métier est oui, l’équipe peut contrôler le rapprochement du produit, la collecte du canal puis l’état détaillé de l’offre. Si la réponse est non, la case documente simplement l’assortiment choisi. La matrice aide à sélectionner le bon parcours sans préjuger du résultat.

À l’inverse, une cellule OK avec un stock à zéro ne signifie pas que l’offre est réellement indisponible sur le canal : la quantité de l’offre peut suivre une règle de dispatch, un autre entrepôt ou un état plus récent. La matrice juxtapose deux faits locaux ; elle ne calcule pas leur causalité.

Cette prudence transforme le CSV en outil de contrôle crédible. Les équipes peuvent trier, filtrer ou comparer les colonnes, mais savent quelles vérifications doivent rester dans les écrans vivants de Ciama.

12. Les arbitrages derrière une matrice volontairement simple

Privilégier la couverture globale avant la profondeur de chaque offre

Premier arbitrage : une ligne par produit, pas une ligne par offre. Cette structure rend visibles les absences et permet aux canaux de devenir des colonnes. Elle ne peut pas détailler plusieurs offres du même produit sur un même canal.

Deuxième arbitrage : utiliser OK et Missing plutôt qu’un faux résumé de statuts hétérogènes. Le résultat est binaire et limité, mais son sens peut être défini exactement. Ajouter actif, accepté ou vendable aurait demandé d’autres règles et d’autres preuves.

Troisième arbitrage : écrire zéro lorsqu’aucun stock n’est trouvé. Le tableau reste numérique et facile à exploiter, au prix d’une ambiguïté entre absence de parcelle et quantité nulle. Cette limite doit être connue lors des contrôles de couverture logistique.

Quatrième arbitrage : produire un CSV complet en tâche de fond plutôt qu’une matrice interactive complexe. Le fichier peut être manipulé avec les outils habituels, tandis que Ciama conserve la génération et son accès.

13. Sécuriser le périmètre et l’état du rapport

Une erreur de génération ne doit pas devenir un faux succès

Le compte est utilisé dans chaque recherche de produit, d’entrepôt, de stock, de canal et d’offre. Le rapport lui-même doit appartenir au même compte que le message. Cette cohérence empêche de construire une matrice avec des dimensions provenant de plusieurs organisations.

Le générateur vérifie la création des dossiers et l’ouverture du fichier. Toute exception interceptée est journalisée et fait passer le rapport en erreur lorsqu’il a déjà été retrouvé. La page peut alors distinguer un échec d’un traitement encore en attente.

Le CSV est produit avec le mécanisme standard d’écriture de cellules. Noms de produits, marques ou catégories contenant un séparateur sont encadrés correctement, plutôt que concaténés manuellement dans une ligne fragile.

Le contrôle applicatif disponible vérifie que la page de rapports est accessible avec une configuration autonome. La génération possède aussi une commande dédiée et un worker de reporting. Le périmètre de test public reste honnête : aucun comparatif client chiffré n’est déduit de ces contrôles.

14. Une première version consolidée en deux étapes le même jour

Construire la matrice, puis lui donner un vrai cycle de rapport

Le 28 janvier 2026, un premier changement a introduit la page, la demande, le message et le générateur de la matrice. Le modèle produits–entrepôts–canaux et les valeurs stock, OK et Missing étaient déjà au cœur du traitement.

Une seconde livraison le même jour a ajouté et renforcé le rapport persistant, le téléchargement, la commande de génération et l’exécution par worker. La fonctionnalité a ainsi dépassé le simple script : elle pouvait être demandée, suivie, historisée et récupérée depuis Ciama.

En mars, la migration du socle applicatif a conservé ce parcours et son transport de reporting. Les contrôleurs, entités et handlers ont été adaptés sans changer la signification fondamentale des cellules.

Cette stabilité est un choix utile. Plutôt que d’ajouter des statuts que le générateur ne calcule pas, le projet garde une matrice lisible et laisse les analyses détaillées aux modules qui possèdent réellement les données nécessaires.

15. Ce que la matrice change pour le contrôle de couverture

Passer de vérifications répétées à une photographie transversale

L’équipe obtient tous les produits dans un seul fichier, y compris ceux sans offre. Elle n’a plus besoin de partir d’un export commercial incomplet par construction pour chercher ce qui manque au catalogue.

Les stocks sont alignés par entrepôt et les offres par canal dans la même ligne. Un tri ou un filtre suffit pour faire ressortir une combinaison à examiner : stock positif et offre absente, produit sans aucun stock, ou couverture différente entre canaux.

Le rapport conserve son état, sa progression, son nombre de lignes et sa durée. Une génération importante peut continuer hors de la page, et les rapports précédents restent visibles dans le compte avec leur fichier lorsqu’il existe encore.

Le gain n’est pas présenté comme une hausse automatique de diffusion. La matrice réduit le coût de repérage et rend les questions de couverture plus précises ; l’équipe doit toujours qualifier chaque absence et vérifier les états vivants avant d’agir.

16. Le scénario qui distingue absence locale et échec marketplace

Un produit stocké apparaît Missing sur un canal stratégique

Une référence possède vingt unités dans l’entrepôt principal et cinq dans un second entrepôt. Les colonnes Amazon et Cdiscount affichent OK, tandis que la colonne d’un troisième canal affiche Missing. La largeur de la matrice rend cette différence immédiatement repérable.

La personne responsable vérifie d’abord si le produit appartient bien à l’assortiment prévu pour ce canal. Si ce n’est pas le cas, aucune correction n’est nécessaire. Si la diffusion était attendue, elle recherche ensuite l’offre et le produit dans les vues de Ciama.

Missing indique qu’aucune offre locale n’a été trouvée pour ce couple. Il ne dit pas que la marketplace a refusé le produit. L’enquête peut révéler une collecte non faite, un mauvais rattachement ou une offre qui n’a jamais été créée.

Si une offre est finalement rattachée, une nouvelle matrice générée plus tard affichera OK. Pour contrôler ensuite son stock, son prix ou son statut source, l’équipe utilise la vue des offres normalisées par canal plutôt que de demander au CSV ce qu’il ne mesure pas.

17. Les limites qui empêchent les faux diagnostics

Couverture locale, quantité courante et performance technique bornée

La matrice travaille sur les offres et les relations de stock disponibles. Les statuts de publication, rejets de contenu, règles d’éligibilité et prix acceptés demandent des sources complémentaires avant d’entrer dans ce diagnostic.

OK ne signifie pas offre active ou vendable. Missing ne signifie pas erreur. Zéro ne distingue pas stock absent et stock connu à zéro. Ces trois limites sont centrales : ignorer l’une d’elles transformerait un outil de repérage en source de conclusions fausses.

Le générateur charge tous les produits en mémoire puis effectue une recherche de stock pour chaque couple produit–entrepôt et une recherche d’offre pour chaque couple produit–canal. Cette stratégie est explicite et simple, mais son coût augmente avec les trois dimensions ; aucun seuil de volumétrie garanti n’est publié.

Le fichier reflète les dimensions actives et les valeurs lues pendant sa génération. Il ne constitue pas un instantané transactionnel ni un historique automatique de chaque relation. Pour le reporting marketplace vendeur, il faut donc lire sa date et confirmer les cas sensibles dans Ciama.

18. Relier la matrice aux vues qui savent expliquer chaque case

Un point de départ transverse, plusieurs chemins de diagnostic

Le stock multi-entrepôts permet d’examiner les parcelles derrière une quantité. Il distingue les entrepôts et rattache le stock au produit, là où la matrice ne garde qu’une cellule numérique.

La normalisation des offres marketplace restitue les informations commerciales communes aux canaux. Elle devient le bon prolongement lorsqu’une cellule OK doit être vérifiée au-delà de la simple existence.

Le Product Explorer apporte enfin le contexte de la fiche externe et de ses identifiants. Il aide à comprendre le produit marketplace auquel une offre peut être reliée.

Dans Ciama Marketplace, cette articulation évite de concentrer tous les sens dans un seul tableau. La matrice repère ; les vues de stock, de produit et d’offre expliquent ; l’équipe décide.