Ciama : suivre chaque synchronisation de sa file d’attente à son résultat

1. Ciama, une plateforme où les données arrivent par plusieurs familles de collectes

Produits, tags, offres, commandes, devis, fournisseurs et stocks ne suivent pas tous le même chemin

Le cockpit rassemble des données de catalogue, de vente, d’achat et de logistique. Certaines synchronisations sont planifiées ; d’autres relisent un historique ; d’autres encore sont lancées pour un canal ou un fournisseur précis.

Le traitement global peut distribuer du travail à plusieurs sources. Une collecte de commandes, par exemple, crée une exécution parente puis des sous-exécutions rattachées aux canaux concernés. Chacune avance et termine indépendamment.

Le besoin n’était donc pas un simple journal de messages. Il fallait conserver une identité métier stable, la période demandée, le canal ou le fournisseur, les volumes collectés, ajoutés ou mis à jour, le nombre d’erreurs, la progression et la durée.

La vue devait également rester cloisonnée au compte. Un vendeur ne doit voir ni les volumes ni les noms de traitements d’un autre compte, et la connaissance d’un identifiant d’exécution ne doit pas contourner cette frontière.

2. Séparer le cycle d’une exécution de la logique propre à chaque connecteur

Une convention commune qui laisse chaque collecte déclarer ses métriques

Le chantier a d’abord défini six états : en attente, en cours, succès, vide, avertissement et échec. « Vide » distingue une collecte correctement terminée sans élément d’un problème technique. « Avertissement » conserve un résultat exploitable tout en signalant des écarts.

Un orchestrateur unique ouvre ensuite la trace, passe l’exécution en cours, borne la progression entre zéro et cent, incrémente les métriques, ajoute les erreurs et marque la fin. Les collectes emploient cette convention sans devoir réinventer le calcul de durée ou la fusion des compteurs.

Pour les traitements distribués, une agrégation relit les enfants. Elle additionne les métriques, calcule la part d’avancement de chacun et détermine l’état parent selon une priorité qui conserve les échecs et avertissements lorsque toutes les sources ont terminé.

Enfin, deux écrans ont été construits : une recherche limitée aux exécutions parentes et une vue détaillée qui affiche la ligne parente puis ses enfants directs dans leur ordre de création. Cette séparation garde la liste générale lisible sans perdre le détail multi-source.

3. Avant le projet : un déclenchement ne suffisait pas à prouver le résultat

Entre la commande planifiée et la donnée finale, plusieurs étapes pouvaient diverger

Un planificateur peut lancer une collecte sans qu’un worker ne la prenne immédiatement. Le connecteur peut ensuite répondre correctement mais ne retourner aucun élément. Il peut aussi collecter cent lignes et n’en enregistrer qu’une partie.

Ces situations n’appellent pas la même lecture. Une tâche en attente, une réussite vide, un traitement partiel et un échec doivent être distingués avant de rechercher la cause dans le catalogue ou la marketplace.

Les traces applicatives restent utiles pour l’investigation technique, mais elles ne donnent pas spontanément un tableau comparable entre produits, commandes, offres, achats et stocks. Le nom d’un message ne remplace pas une fonction métier, un contexte et des volumes.

Le projet a donc créé un objet d’exécution durable. Chaque collecte instrumentée écrit dans le même langage opérationnel, ce qui permet à la liste de rapprocher des traitements différents sans gommer leurs caractéristiques.

4. Instrumenter les collectes qui structurent réellement le cockpit

Un socle partagé par plusieurs univers, sans revendiquer une couverture absolue

Le journal est utilisé par des collectes de produits, tags, offres, commandes et devis. Il suit aussi des fournisseurs, achats fournisseurs, préparations logistiques, stocks, rapports et traitements d’entrepôt.

Les modes planifié et historique sont présents dans plusieurs de ces familles. Certaines exécutions sont globales ; d’autres ciblent un canal, un fournisseur, un entrepôt ou une période.

L’instrumentation reste volontaire. Une tâche qui ne crée pas d’exécution dans ce socle n’apparaît pas par magie dans la page. Le journal décrit donc son périmètre réel, pas l’intégralité des processus de la plateforme.

Cette limite protège la qualité de lecture : chaque ligne visible possède un cycle de vie et des métriques assumés par le traitement qui l’a créée, plutôt qu’une déduction fragile à partir de traces hétérogènes.

5. Donner à chaque exécution une identité et un périmètre

Compte, fonction, mode, univers, commande, message et relations de groupe

À sa création, une exécution reçoit un identifiant unique et le compte propriétaire. La fonction décrit le travail suivi, par exemple la collecte d’offres ou de commandes ; le mode précise s’il s’agit d’un passage planifié, historique ou d’une synchronisation.

L’univers peut distinguer B2B, marketplace et e-commerce. Le nom de commande et la famille de message peuvent être conservés pour relier le suivi métier à son déclencheur sans les imposer comme libellé principal dans la liste.

Un identifiant de groupe, un parent éventuel et un indicateur parent structurent les collectes distribuées. La source peut aussi être reliée par un identifiant de canal et complétée par des informations utiles dans le contexte.

La période, les paramètres et les repères de source sont conservés dans une charge structurée. La liste en extrait notamment les bornes de date et l’identité visuelle du canal ou du fournisseur lorsqu’elles existent.

6. Distinguer six états au lieu d’un simple succès ou échec

En attente, en cours, succès, vide, avertissement et échec

« En attente » signifie que le travail a été enregistré mais n’est pas encore déclaré en cours. Ce statut permet de voir la file avant que la progression ne commence.

« En cours » accompagne le traitement actif. « Succès » clôt une exécution normale avec un résultat ; « vide » clôt normalement une collecte qui n’a trouvé aucun élément à traiter.

« Avertissement » représente une fin avec des anomalies non assimilées à un échec total. « Échec » indique que l’exécution n’a pas atteint son résultat nominal.

La distinction évite deux erreurs de diagnostic : considérer une absence de nouvelle donnée comme une panne, ou présenter un résultat partiel comme un succès silencieux. Elle ne fournit toutefois pas à elle seule la cause détaillée.

7. Borner la progression et la terminer avec l’exécution

Une valeur comprise entre zéro et cent, mise à jour par le traitement

Le socle accepte une progression fixée ou incrémentée pendant l’exécution. Chaque écriture est ramenée dans l’intervalle zéro à cent afin qu’une mauvaise estimation ne casse pas la lecture de la barre.

Le passage à l’état en cours réinitialise le début effectif, la fin et la durée. Lorsqu’une méthode de fin est appelée, la progression est forcée à cent et l’heure de fin est enregistrée.

La valeur n’est pas extrapolée automatiquement à partir du temps. C’est la collecte instrumentée qui indique ses étapes ou son volume traité. Deux fonctions peuvent donc avoir une granularité de progression différente.

Dans la liste, une barre et un pourcentage donnent le même repère. L’équipe peut distinguer une tâche encore à zéro d’un traitement déjà avancé, sans interpréter cette valeur comme une estimation d’heure de fin.

8. Cumuler les volumes sans écraser les étapes précédentes

Collectés, distribués, ajoutés, mis à jour et échoués

Les métriques sont conservées sous forme structurée. Lorsqu’une collecte ajoute un delta numérique à une clé existante, le socle additionne les valeurs au lieu de remplacer le total précédent.

Les traitements peuvent ainsi compter les éléments collectés, les écritures distribuées, les ajouts, les mises à jour, les échecs d’ajout ou de mise à jour et le nombre d’erreurs. Des métriques imbriquées peuvent également être fusionnées.

La liste publique au compte met en avant quatre compteurs : collectés, ajoutés, mis à jour et erreurs. Une valeur absente est affichée comme indisponible, pas comme zéro inventé.

Ces volumes décrivent l’exécution ; ils ne certifient pas à eux seuls l’état final du système distant. Un ajout compté dans Ciama doit encore être distingué, selon le processus, d’une publication confirmée par une marketplace.

9. Conserver les erreurs en série et exposer leur volume

Une mémoire structurée plus riche que l’interface de synthèse

Le socle peut ajouter plusieurs erreurs à une exécution au fil du traitement. Une erreur unique est normalisée en liste, puis les nouveaux éléments sont ajoutés sans supprimer ceux déjà présents.

Les méthodes de fin avec avertissement ou échec peuvent enregistrer les erreurs restantes et les métriques de clôture dans la même transition. L’exécution conserve ainsi son état final et la matière nécessaire à une investigation.

Dans les écrans livrés, la table montre le compteur d’erreurs issu des métriques. Elle n’affiche pas le contenu détaillé de la collection d’erreurs ni une explication automatique du problème.

La fiche ne promet donc pas une résolution guidée depuis ce journal. Pour expliquer le cas, l’équipe doit encore ouvrir la vue métier concernée ou utiliser le processus de reprise des flux en erreur.

10. Enrichir la trace avec le canal ou le fournisseur concerné

Une source reconnaissable dans la liste, pas seulement un identifiant

Lorsqu’un canal est fourni, le journal conserve son identifiant dans le contexte. S’il retrouve ce canal dans Ciama, il ajoute également son nom, ses identifiants de catalogue et son type.

La vue utilise ces valeurs pour choisir un libellé et un logo de contexte. Pour certains traitements, un identifiant fournisseur présent dans la charge permet la même lecture visuelle.

Les bornes « du » et « au » sont affichées lorsqu’elles ont été enregistrées. Elles donnent le périmètre temporel d’une collecte historique sans être confondues avec l’heure de création de l’exécution.

Si le contexte n’est pas fourni ou si le logo manque, la cellule reste neutre ou emploie une image de repli. La supervision ne déduit pas une source à partir du seul nom de fonction.

11. Séparer l’exécution globale des sous-traitements par source

Une ligne parente pour le run, une ligne enfant pour chaque branche distribuée

Une collecte multi-source commence par une exécution parente. Chaque branche reçoit ensuite son propre identifiant et référence le parent, tout en conservant son canal, sa progression, son statut et ses métriques.

La recherche générale affiche uniquement les parents. Sans cette règle, un run sur dix canaux occuperait onze lignes et rendrait le nombre de collectes globales difficile à lire.

La vue détaillée montre d’abord le parent puis ses enfants directs, classés par date de création croissante. L’équipe suit ainsi l’exécution d’ensemble et compare les sources dans l’ordre où elles ont été distribuées.

Un enfant n’est pas un simple message textuel. Il possède le même modèle de statut, de progression, de période, de contexte, de volumes et de durée que le parent.

12. Calculer l’avancement parent à partir de toutes les branches

Les enfants terminés valent une unité, les enfants actifs leur fraction de progression

L’agrégation compte d’abord les enfants dans un état final. Chacun contribue pour une unité complète. Un enfant encore actif contribue selon sa progression ramenée entre zéro et un ; un enfant en attente à zéro ne contribue pas encore.

La somme est divisée par le nombre total d’enfants puis convertie en pourcentage. Deux branches, dont une à cinquante pour cent et une encore en attente, placent donc le parent à vingt-cinq pour cent.

Les métriques sont additionnées sur toutes les branches : collectés, distribués, ajoutés, mis à jour, échecs et erreurs. Le parent devient une synthèse calculée, pas une seconde collecte indépendante.

La mise à jour intervient lorsque les enfants progressent ou terminent dans les parcours instrumentés. Elle n’invente pas la progression d’une branche qui ne la renseigne pas.

13. Faire remonter l’état le plus significatif une fois toutes les branches finies

Échec avant avertissement, puis succès et enfin résultat vide

Tant qu’un enfant travaille ou possède une progression non nulle sans être terminé, le parent reste en cours. Si les branches restantes sont seulement en attente, le parent est lui aussi en attente.

Lorsque tous les enfants ont fini, la présence d’un échec donne l’état échec au parent. Sans échec, un avertissement donne l’état avertissement. Sans les deux, au moins un succès donne succès ; un ensemble uniquement vide donne vide.

Cette priorité évite qu’un canal réussi masque une autre branche en échec. Elle évite aussi de déclarer vide une collecte globale lorsque l’une de ses sources a effectivement produit un résultat.

La fin du dernier enfant fixe la progression parente à cent, l’heure de fin et la durée. Le statut de synthèse et les compteurs décrivent alors le run complet.

14. Rechercher une exécution par son identité technique ou métier

Fonction, mode, statut, univers, commande, message et canal

Le champ libre cherche une correspondance partielle dans la fonction, le mode, le statut, l’univers, le nom de commande, la famille de message et l’identifiant de canal.

Cette recherche aide autant l’exploitation que l’escalade. Une équipe peut partir du nom fonctionnel qu’elle connaît ; une personne chargée du diagnostic peut retrouver la même exécution par le déclencheur ou le message.

Le contenu des erreurs, les métriques et les valeurs arbitraires de contexte ne font pas partie de cette recherche. Connaître un texte d’erreur ne suffit donc pas à retrouver toutes les traces concernées depuis ce champ.

Chaque critère libre s’applique en plus des filtres structurés. Le total et la pagination sont calculés après combinaison, ce qui évite d’afficher un nombre global à côté d’une liste réduite.

15. Filtrer par mode, univers, statut et fonction

Des valeurs fermées pour les dimensions stables, une liste dynamique pour les fonctions

Le mode propose planifié, historique et synchronisation. L’univers propose B2B, marketplace et e-commerce. Le statut reprend les six états du cycle de vie.

La liste des fonctions est construite à partir des exécutions parentes du compte, triées alphabétiquement et dédupliquées. Elle s’adapte donc aux traitements réellement présents au lieu d’afficher un catalogue théorique.

Les filtres actifs apparaissent comme des facettes amovibles. L’utilisateur voit immédiatement pourquoi une liste est réduite et peut retirer un critère sans reconstruire tout le formulaire.

Le contrôleur accepte une valeur textuelle exacte pour chaque filtre. L’interface guide vers les valeurs connues, mais aucune sévérité métier ni notion de traitement « en retard » n’est calculée.

16. Lire les cinquante dernières exécutions parentes dans une table commune

Une pagination bornée de une à deux cents lignes

La liste est triée par date de création décroissante. Elle affiche cinquante exécutions par défaut et accepte une taille comprise entre une et deux cents lignes.

Chaque ligne rassemble l’identifiant court, la date, la fonction, l’univers, la période, le contexte, le mode, le statut, la progression, quatre compteurs et la durée.

Les statuts et les modes utilisent des repères visuels distincts. La progression reste visible même lorsqu’aucun compteur n’a encore été fourni, et la durée reste absente tant que l’exécution n’est pas terminée.

Un bouton ouvre le détail. Il ne relance pas la collecte, n’acquitte pas un incident et ne change aucun statut : la page de recherche reste une vue d’observation.

17. Comparer le parent et ses enfants dans le même format

Une vue de décomposition, pas une console de reprise

Le détail reprend exactement les colonnes de la synthèse et ajoute un type de ligne. Le parent est mis en avant ; chaque sous-exécution apparaît dessous avec son propre identifiant et son heure de création.

Cette présentation permet de repérer une branche à zéro, un canal en avertissement ou un écart de volume entre plusieurs sources sans ouvrir plusieurs écrans.

La vue ne déroule pas la charge complète, le nom de commande, la famille de message ni le contenu des erreurs stockées. Elle expose les éléments de comparaison utiles à la première qualification.

Elle n’ajoute aucun bouton de relance ou de correction. Une exécution en échec devient un point de départ vers le flux concerné, pas une autorisation automatique de le rejouer.

18. Isoler la liste et le détail par compte

Une vérification avant la recherche et une seconde sur chaque identifiant ouvert

La recherche part du compte de l’utilisateur connecté et impose ce compte avant d’appliquer les autres critères. Les fonctions proposées dans le filtre suivent la même frontière.

Le détail recharge l’exécution demandée puis compare son compte à celui de l’utilisateur. Une exécution inconnue ou appartenant à un autre compte produit la même réponse introuvable.

Les enfants sont recherchés seulement après cette validation du parent. La page ne peut donc pas être utilisée comme porte d’entrée pour explorer les identifiants d’un autre vendeur.

Ce cloisonnement couvre des informations sensibles même lorsqu’elles semblent agrégées : volumes de commandes, rythme des synchronisations, fournisseurs connectés et fréquence des erreurs.

19. Sécuriser les compteurs lorsque plusieurs messages terminent ensemble

Une mise à jour verrouillée pour ne pas perdre un delta

Les workers peuvent mettre à jour la même exécution à peu d’intervalle, notamment lorsqu’ils ajoutent des métriques ou lorsqu’un parent agrège plusieurs branches.

Chaque modification prend un verrou sur la ligne concernée avant de relire l’état, fusionner les compteurs, ajouter les erreurs et enregistrer la nouvelle progression. La transaction est validée uniquement après l’écriture complète.

L’agrégation du parent suit la même discipline. Elle recalcule l’état et les métriques à partir des enfants, puis verrouille le parent pendant la synchronisation de la synthèse.

Cette protection ne rend pas les connecteurs infaillibles ; elle empêche surtout deux mises à jour concurrentes du journal de s’écraser silencieusement.

20. Assumer une mémoire opérationnelle avec des outils de purge

Le journal n’est pas présenté comme une archive réglementaire immuable

Trois commandes de maintenance peuvent supprimer les exécutions selon leur ancienneté. Leurs valeurs par défaut ciblent les résultats vides de plus de dix minutes, les attentes de plus de vingt-quatre heures et l’ensemble des traces de plus d’un mois.

Ces seuils sont réglables au lancement des commandes. Leur existence montre que le journal est conçu pour la supervision courante, pas pour une conservation illimitée.

La présence des commandes ne prouve pas leur fréquence d’exécution dans chaque environnement. La fiche ne transforme donc pas ces valeurs par défaut en politique de rétention garantie en production.

Si une conservation longue, un export d’audit ou une obligation réglementaire devient nécessaire, elle doit être cadrée comme un besoin distinct avec sa propre preuve de stockage.

21. Rendre visibles les limites de la version livrée

Observer un traitement ne signifie pas encore piloter sa reprise

Le journal ne détecte pas automatiquement qu’une exécution est en retard. Il n’existe pas de fréquence attendue par fonction, de seuil d’ancienneté, de criticité métier ou de calcul d’impact sur les ventes.

Aucun e-mail, SMS, webhook ou outil d’astreinte n’est déclenché depuis cette brique. Les états deviennent visibles dans Ciama, mais la notification reste un chantier séparé.

PagerDuty ne faisait pas partie du périmètre livré pour Ciama. La page intégrateur PagerDuty API décrit le chantier d’alerte, d’escalade et d’acquittement qui pourrait exploiter le contexte du journal métier avant tout routage d’astreinte.

La liste et le détail ne proposent ni relance, ni annulation, ni acquittement, ni affectation à un responsable. Le compteur d’erreurs ne montre pas encore leur contenu détaillé dans l’interface.

Enfin, l’état succès confirme la fin nominale du traitement instrumenté ; il ne garantit pas toutes les conséquences distantes possibles. Une publication ou une écriture externe peut demander une confirmation spécifique au connecteur.

22. Ce qui change après la livraison

Le run dispose d’une preuve commune avant l’investigation

L’équipe peut d’abord distinguer une collecte encore en attente d’un résultat vide. Cette différence évite de chercher une panne lorsqu’aucune nouvelle donnée n’était disponible, ou de considérer une tâche non démarrée comme terminée.

Les volumes collectés, ajoutés, mis à jour et en erreur donnent un premier contrôle de cohérence. Un écart entre cent éléments collectés et quelques mises à jour devient visible sans ouvrir les traitements un à un.

La hiérarchie parent-enfants localise les divergences par source. Le statut global conserve l’échec le plus significatif et les métriques agrégées évitent de recalculer manuellement les totaux.

La recherche et les filtres réduisent le temps nécessaire pour retrouver une famille, un canal, une période ou un mode. L’identifiant court fournit ensuite un repère commun pour transmettre le cas.

Cette base renforce la supervision du run marketplace avec une règle simple : qualifier l’exécution observée avant de décider si elle doit être surveillée, investiguée ou reprise.

23. Le scénario terrain qui résume le projet

Une collecte globale réussit sur deux canaux et échoue sur un troisième

Une collecte historique d’offres est lancée sur trois canaux. L’exécution parente apparaît en attente avec ses bornes de dates, puis passe en cours lorsque les workers commencent à traiter les branches.

Le premier canal termine avec succès et des ajouts. Le deuxième ne trouve aucune donnée et finit vide. Le troisième progresse, enregistre plusieurs erreurs puis termine en échec.

Pendant le run, la progression parente combine les branches terminées et la fraction de la branche active. À la fin, les trois enfants valent cent pour cent mais le parent reçoit l’état échec, car cette priorité empêche les deux résultats normaux de masquer le troisième.

La liste montre le total collecté, les ajouts, les mises à jour, les erreurs et la durée globale. Le détail révèle immédiatement la source en échec et conserve les volumes de chaque branche.

L’équipe possède alors l’identifiant et le contexte nécessaires pour poursuivre dans la reprise guidée des flux. Le journal a qualifié le run ; il n’a ni inventé la cause ni relancé le canal sans contrôle.

24. Relier journal global, preuve stock et configuration des connecteurs

Chaque vue répond à un niveau différent du diagnostic

Le Hub connecteurs marketplace décrit les sources et capacités activées. Le journal montre ensuite les exécutions que les parcours instrumentés produisent pour ces sources.

L’historique des actions de stock descend au niveau de l’offre et de la décision envoyée. Il complète la vue d’exécution globale lorsque l’enquête porte sur une référence précise.

La reprise guidée des flux en erreur porte le passage du constat à l’action. Cette séparation empêche un écran de supervision de devenir une console de relance sans contexte métier.

Dans Ciama Marketplace, ces briques composent un parcours : savoir ce qui était configuré, vérifier ce qui s’est exécuté, localiser le canal ou l’objet concerné, puis reprendre au bon niveau.