Le projet en un coup d’œil
Entre une collecte planifiée et sa conséquence métier, un traitement peut attendre, avancer, terminer vide, échouer ou rester dans une file.
Le journal d’exécution oriente l’enquête, RabbitMQ montre la circulation réelle et le journal système apporte le détail lorsque les deux premiers niveaux ne suffisent pas.
L’équipe peut distinguer attente, consommation en cours, redélivrance, absence de donnée et erreur applicative sans déclencher une relance globale depuis ces écrans.
Une commande absente, un stock qui paraît ancien ou une offre qui ne se met plus à jour ne disent pas où le flux s’est interrompu. Le traitement a peut-être été créé mais pas encore pris en charge. Un worker peut être en train de le consommer. La source peut avoir répondu sans donnée. Le message peut avoir été redélivré après une première tentative. Une exception peut enfin avoir arrêté l’exécution. Ces situations produisent le même symptôme visible, mais elles n’appellent surtout pas la même réponse.
Dawap a construit dans Ciama une chaîne de lecture progressive pour ne plus commencer l’enquête par une relance générale. Le premier niveau traduit les collectes instrumentées en exécutions métier. Le deuxième interroge en direct les files RabbitMQ qui transportent le travail asynchrone. Le troisième ouvre un accès très restreint aux journaux applicatifs, lu par petits segments et capable de suivre une rotation de fichier. Chaque niveau répond à une question plus précise que le précédent.
Ce dispositif, achevé dans sa forme actuelle avec le tableau RabbitMQ du 26 avril 2026, matérialise une approche exigeante du run et de la supervision marketplace : donner assez de contexte pour décider, préserver les frontières de sécurité et ne jamais confondre visibilité avec réparation automatique. La valeur n’est pas de promettre qu’aucun incident n’arrivera ; elle est d’éviter qu’un symptôme imprécis déclenche une action plus risquée que le problème initial.
1. Ciama, un cockpit alimenté par des traitements asynchrones
Catalogue, commandes, offres, achats et stocks avancent à des rythmes différents
Ciama réunit plusieurs univers de commerce : marketplaces, e-commerce, B2B, achats et logistique. Ses données proviennent de connecteurs hétérogènes, parfois interrogés sur une période, parfois parcourus canal par canal ou fournisseur par fournisseur. Une action visible dans le cockpit peut donc dépendre d’une chaîne composée d’un planificateur, d’un message, d’un consommateur, d’une API distante et d’une écriture locale.
Ce fonctionnement asynchrone protège l’usage quotidien contre les traitements longs, mais il déplace une partie de la complexité vers l’exploitation. Le clic ou la planification ne coïncident plus nécessairement avec le résultat. Plusieurs messages peuvent progresser en parallèle, attendre un consommateur ou produire des volumes différents selon leur source. Sans lecture adaptée, un retard normal ressemble vite à une panne et une panne silencieuse à un simple retard.
Le projet ne consiste donc pas à inventer une file d’incidents métier universelle. Il organise les preuves déjà produites par les trois couches qui font réellement vivre ces flux. Le compte connecté garde une vue synthétique de ses exécutions ; l’exploitation peut descendre dans le transport ; un cercle d’accès encore plus réduit peut lire le contexte brut de l’application lorsque cela devient nécessaire.
Cette graduation est importante pour un outil multi-compte. Une information utile au diagnostic peut contenir un nom de canal, une période, des volumes ou une charge de message. Les écrans ne doivent pas donner la même profondeur à tout le monde. La lisibilité opérationnelle et le cloisonnement ne sont pas deux sujets opposés : ils font partie de la même conception.
2. Construire le diagnostic comme une progression, pas comme un écran unique
Commencer par la preuve métier, puis descendre seulement si elle ne suffit pas
La première étape a consisté à donner une convention commune aux collectes : identité, fonction, mode, univers, contexte, progression, métriques, erreurs, début, fin et durée. Cette couche répond aux questions les plus fréquentes sans exposer le transport. Elle montre ce qui a été demandé et ce que le traitement déclare avoir accompli.
La deuxième étape rend l’état de RabbitMQ observable depuis le back-office. Le tableau ne se contente pas d’un total de messages : il sépare ceux qui attendent de ceux qui ont été livrés mais pas encore acquittés, montre les consommateurs et rapproche les débits de publication, de livraison et d’acquittement. Une file peut ainsi être lue comme un mouvement, pas seulement comme un nombre.
La troisième étape réserve les journaux système à quatre identités explicitement autorisées. La lecture est incrémentale, limitée en volume et cantonnée aux fichiers de développement ou de production. La page sait reprendre la fin d’un journal, suivre les ajouts et réinitialiser son curseur si le fichier a tourné. Cette couche fournit le contexte technique sans transformer les logs en contenu largement accessible.
Les trois briques ont été sécurisées par onze fichiers de tests ciblés couvrant le cycle de vie des exécutions, leurs mises à jour, l’agrégation parent-enfants, les contrôleurs de recherche et de détail, la lecture protégée des journaux et la normalisation des données RabbitMQ. Les tests ne prouvent pas qu’un service distant ne tombera jamais ; ils verrouillent les contrats qui permettent d’interpréter correctement ce que l’écran affiche.
3. Partir du symptôme sans lui attribuer trop vite une cause
Le même retard apparent peut correspondre à cinq réalités opérationnelles
Lorsqu’une donnée attendue n’apparaît pas dans le cockpit, la tentation naturelle consiste à relancer le flux. Pourtant, un traitement encore en attente peut simplement manquer de capacité disponible. Un traitement en cours peut parcourir une période volumineuse. Une collecte terminée vide peut refléter une réponse valide de la source. Aucune de ces situations ne justifie automatiquement un second lancement.
À l’inverse, une file dont le nombre de messages prêts augmente alors qu’aucun consommateur n’est présent signale un problème différent. Des messages non acquittés montrent qu’un ou plusieurs consommateurs les ont reçus sans avoir encore confirmé leur traitement. Une redélivrance indique que RabbitMQ a déjà présenté le message auparavant. Ces indices rapprochent l’équipe du bon périmètre sans encore prétendre expliquer la cause finale.
Le projet impose donc une règle de lecture simple : ne pas interpréter un seul signal isolément. Le statut métier donne l’intention et le résultat déclaré ; la file montre le transport ; le journal révèle l’exception ou le contexte technique. C’est la concordance entre ces niveaux qui permet de choisir entre attendre, approfondir, corriger une donnée ou préparer une reprise contrôlée.
Cette discipline protège les opérations marketplace. Relancer un import de commandes, une collecte de stock ou une synchronisation d’offres sans comprendre son état peut créer des doublons, augmenter la charge ou masquer l’incident initial. Le diagnostic ne supprime pas le besoin d’agir : il rend l’action proportionnée et vérifiable.
4. Une échelle de diagnostic en trois niveaux complémentaires
Chaque profondeur répond à une question et possède sa propre frontière d’accès
Le niveau métier répond à « quel traitement a été lancé et comment s’est-il terminé ? ». Il porte une fonction, un mode, un univers, une source éventuelle, une période, six états, une progression et des compteurs. C’est le point d’entrée le plus lisible, car il parle de collecte, de produits, d’offres ou de commandes plutôt que de processus techniques.
Le niveau RabbitMQ répond à « où se trouve le travail asynchrone maintenant ? ». Il observe les files du vhost configuré, les trie par nombre de messages et actualise la photographie toutes les deux secondes. Il permet de repérer une accumulation, l’absence de consommateur, une activité de livraison ou un écart entre publication et acquittement.
Le niveau journal répond à « quel événement applicatif accompagne ce comportement ? ». Il intervient lorsque le statut et la file ne suffisent plus. La page suit uniquement les journaux autorisés, conserve un tampon d’affichage borné et offre pause, reprise, effacement visuel et défilement automatique. Elle donne de la profondeur sans modifier les fichiers.
Cette séparation évite le tableau de bord omnipotent qui mélange toutes les audiences et toutes les actions. Une équipe métier peut s’orienter avec une exécution. L’exploitation peut vérifier le transport. Seules les identités prévues descendent dans le texte brut. Plus le diagnostic devient sensible, plus la frontière se resserre.
5. Premier niveau : retrouver l’exécution dans son contexte métier
Fonction, mode, univers, source, période, progression et compteurs partagent le même langage
Chaque exécution instrumentée appartient à un compte et reçoit un identifiant unique. Sa fonction nomme le travail suivi. Son mode distingue notamment un passage planifié, une reprise historique ou une synchronisation. L’univers précise le périmètre B2B, marketplace ou e-commerce lorsque cette information est disponible.
Le contexte peut ajouter le canal, son nom, ses identifiants de catalogue, son type et les bornes de période demandées. Cela permet de comparer deux exécutions proches sans supposer qu’elles portaient sur la même source ou la même fenêtre temporelle. Une ligne devient un objet opérationnel, pas seulement l’horodatage d’un déclenchement.
Pendant le traitement, la progression reste comprise entre zéro et cent. Les métriques numériques sont additionnées au fil des étapes : éléments collectés, distribués, ajoutés, mis à jour, erreurs ou échecs spécialisés. La liste en expose une sélection stable afin de garder la comparaison lisible entre plusieurs familles de collectes.
La fiche consacrée au journal des synchronisations détaille ce modèle et ses filtres. Dans le présent projet, ce journal joue un rôle précis : il localise le symptôme au niveau métier avant de décider s’il faut réellement inspecter le transport.
6. Six états pour éviter les diagnostics binaires
En attente, en cours, succès, vide, avertissement et échec n’expriment pas la même situation
« En attente » indique que l’exécution existe mais n’a pas encore été déclarée active. « En cours » signifie que le traitement a pris la main et peut faire évoluer sa progression. Ces deux états temporaires permettent de distinguer la file d’attente du travail effectivement commencé.
« Succès » clôt un traitement nominal. « Vide » clôt correctement une collecte qui n’a trouvé aucun élément. Cette nuance évite de transformer une absence de nouveauté en incident. Elle est particulièrement utile sur des passages fréquents où zéro commande ou zéro offre nouvelle peut être un résultat parfaitement normal.
« Avertissement » conserve un résultat exploitable tout en signalant des écarts. « Échec » marque une fin non nominale. Lorsqu’une exécution se termine, sa progression atteint cent et sa durée est calculée entre son début effectif et sa fin. Un état final ne donne cependant pas à lui seul le détail de chaque conséquence distante.
Le diagnostic commence donc par la bonne question : le traitement attend-il, travaille-t-il, n’avait-il rien à faire ou s’est-il réellement arrêté ? Cette distinction réduit les fausses alertes et empêche qu’un résultat vide soit relancé en boucle sous prétexte qu’aucun volume visible n’a été produit.
7. Lire une collecte distribuée sans masquer la branche en difficulté
La synthèse parente agrège les sources, le détail conserve chaque sous-traitement
Une collecte globale peut distribuer plusieurs sous-traitements, par exemple un par canal. L’exécution parente donne la vue d’ensemble et les enfants conservent chacun leur source, leur état, leur progression et leurs métriques. La recherche générale reste centrée sur les parents afin qu’un lancement multi-source ne remplisse pas artificiellement la liste.
L’agrégation additionne huit familles de compteurs et calcule l’avancement à partir des enfants. Une branche terminée contribue entièrement ; une branche active contribue selon sa progression. Quand toutes les branches sont closes, un échec reste prioritaire sur un avertissement, lui-même prioritaire sur un succès puis un résultat vide.
Ce choix est décisif pour l’enquête. Une collecte parente ne devient pas verte simplement parce que neuf sources sur dix ont réussi. Le canal en échec reste visible dans le verdict global, tandis que la vue de détail permet de retrouver la branche concernée dans son ordre de création.
À ce stade, l’équipe sait si le problème est global ou localisé. Si un enfant reste en attente ou en cours anormalement longtemps, le niveau RabbitMQ devient pertinent. S’il est terminé en échec, la période, le canal et les compteurs réduisent déjà le champ de recherche avant l’ouverture du journal.
8. Deuxième niveau : observer RabbitMQ depuis le back-office
Une photographie vivante des files, triée pour faire remonter les accumulations
Le tableau interroge l’API de gestion RabbitMQ sur le vhost indiqué par la connexion de transport. Les files sont normalisées puis classées par nombre total de messages décroissant, avec le nom comme second ordre. Les accumulations apparaissent ainsi en haut sans imposer un seuil arbitraire de criticité.
Quatre cartes donnent immédiatement le nombre de files, le total de messages, les messages prêts et les messages non acquittés. La table ajoute l’état de chaque file, ses consommateurs, ses débits de publication, de livraison et d’acquittement, sa mémoire et sa dernière période d’inactivité connue.
La photographie est renouvelée toutes les deux secondes. Le dernier horaire reçu est affiché et le badge passe explicitement en erreur si l’API ne répond pas ou retourne un résultat invalide. Un tableau figé n’est donc pas présenté comme une observation en direct lorsqu’il ne peut plus être rafraîchi.
La connexion de gestion est dérivée du transport AMQP ou AMQPS déjà configuré, avec le port de management dédié et un délai réseau de quatre secondes. Les erreurs sont retournées comme un état structuré avec des totaux vides, ce qui évite de confondre l’indisponibilité de l’observabilité avec une file réellement vide.
9. Séparer les messages prêts des messages non acquittés
Attendre un consommateur et être en cours de traitement sont deux diagnostics différents
Un message « ready » attend d’être livré à un consommateur. Si ce volume monte alors que le nombre de consommateurs est nul, l’enquête doit d’abord porter sur la capacité de consommation ou le runtime associé. Ajouter un second message identique ne résout pas l’absence de worker et augmente au contraire le retard.
Un message « unacked » a déjà été livré mais n’est pas encore acquitté. Il peut être en cours de traitement, bloqué dans une opération longue ou attaché à un consommateur qui ne répond plus. La présence de messages non acquittés oriente donc l’analyse vers l’exécution active plutôt que vers la publication initiale.
Le total « messages » rassemble ces deux catégories, mais le tableau conserve leur distinction sur chaque ligne. Cette lecture évite l’erreur classique qui consiste à regarder uniquement la profondeur globale de la file. Dix messages prêts et dix messages en cours ne représentent ni le même goulot ni le même risque de duplication.
L’état RabbitMQ ne remplace pas le verdict métier. Une file peut être vide parce que le traitement a réussi, parce qu’il a échoué après consommation ou parce qu’aucun message n’a été publié. C’est précisément pour cette raison que l’enquête part de l’exécution et revient ensuite vers elle après l’observation du transport.
10. Lire les débits et les consommateurs comme un mouvement
Publication, livraison et acquittement révèlent une dynamique que le stock de messages ne montre pas
Le débit de publication mesure l’arrivée des messages. Le débit de livraison montre leur passage vers les consommateurs. Le débit d’acquittement indique la vitesse à laquelle les traitements confirment leur prise en charge. Ces trois valeurs, affichées par seconde, rendent visible la trajectoire d’une file entre deux rafraîchissements.
Une profondeur stable peut cacher un équilibre sain si les publications et les acquittements progressent au même rythme. Elle peut aussi masquer une immobilité complète si tous les débits restent nuls. Inversement, une profondeur temporairement élevée n’est pas forcément un incident lorsqu’elle décroît et que plusieurs consommateurs travaillent.
Le nombre de consommateurs donne le contexte indispensable à ces débits. Une file sans consommateur appelle une vérification différente d’une file dont les consommateurs livrent et acquittent normalement. La mémoire et l’inactivité complètent l’observation sans être transformées en verdict automatique.
Le tableau ne calcule volontairement ni seuil universel ni score d’impact commercial. La criticité dépend du flux, de la période, du volume attendu et de la conséquence métier. L’outil fournit des faits temporels ; l’équipe de run conserve l’arbitrage, enrichi par le contexte de l’exécution concernée.
11. Ouvrir jusqu’à cent messages sans les consommer
Une lecture de diagnostic qui remet chaque message dans sa file
Depuis le nom d’une file, une vue dédiée demande à RabbitMQ jusqu’à cent messages visibles. Le mode d’acquittement utilisé lit puis remet les messages en file. L’action sert à examiner leur charge ; elle ne les supprime pas et ne valide pas leur traitement à la place du consommateur prévu.
Chaque charge est limitée à cinquante mille octets pour protéger la page contre un message anormalement lourd. Lorsqu’un contenu est un JSON valide, il est remis en forme afin de faciliter la lecture. La vue distingue aussi un message prêt d’un message redélivré, c’est-à-dire déjà présenté au moins une fois par le transport.
La réponse normalisée conserve la taille, l’encodage, l’échange, la clé de routage, l’indicateur de redélivrance, le nombre restant, le type de contenu, le mode de livraison et le nombre d’en-têtes. L’écran actuel se concentre sur le statut et le corps JSON, mais le client garde un contrat plus riche pour l’exploitation.
Cette ouverture doit rester un geste de diagnostic mesuré. Lire cent messages peut aider à vérifier si une file contient la bonne famille de commandes, le bon canal ou une charge répétée. Elle ne constitue ni un bouton de rejeu ni une preuve que le traitement applicatif réussira lorsqu’un consommateur reprendra le message.
12. Troisième niveau : suivre le journal applicatif lorsque le transport ne suffit plus
Un accès en direct aux dernières lignes, sans téléchargement global du fichier
Lorsque l’exécution indique un échec et que RabbitMQ montre que le message a bien circulé, la cause se trouve souvent dans le contexte applicatif : réponse distante invalide, donnée impossible à mapper, authentification expirée ou exception interne. Le journal apporte ce dernier niveau de précision.
La page propose uniquement les fichiers de développement et de production réellement présents. Par défaut, elle sélectionne le journal correspondant à l’environnement courant. Elle affiche les nouvelles données dans une zone à défilement automatique, avec la possibilité de mettre en pause, de reprendre ou d’effacer uniquement l’affichage local.
L’effacement ne touche jamais le fichier sur le serveur. De même, la pause arrête le rafraîchissement de la page, pas l’écriture de l’application. Ces distinctions sont importantes : un outil de diagnostic ne doit pas donner à une action de confort visuel un effet sur la preuve source.
Le rafraîchissement intervient toutes les 1,5 seconde et la zone visible conserve au maximum quatre cent mille caractères. Lorsque cette limite est dépassée, les caractères les plus anciens de l’écran sont retirés. Le fichier d’origine reste intact ; seule la fenêtre de lecture du navigateur reste bornée.
13. Réserver les journaux bruts à une liste d’identités explicite
Une page introuvable pour les comptes qui ne doivent pas connaître son existence
Les journaux applicatifs peuvent contenir des détails de traitement qui n’ont pas leur place dans une vue générale. L’accès ne repose donc pas seulement sur le fait d’être connecté. Quatre adresses précises, appartenant aux équipes Dawap et 1UP prévues pour l’exploitation, sont autorisées.
Une personne absente de cette liste reçoit une page introuvable. Cette réponse ne confirme pas l’existence de la ressource et ne révèle pas les noms de fichiers disponibles. La même vérification est appliquée à l’écran et à chaque appel de lecture, de sorte qu’une URL JSON connue ne contourne pas le contrôle.
Le nom du fichier est lui aussi limité à « dev » ou « prod ». Une valeur fournie dans l’URL ne peut pas être transformée en chemin arbitraire. Sur l’écran, un nom inconnu est ramené au journal de l’environnement ; sur l’endpoint de lecture, il produit une erreur explicite de requête invalide.
Le diagnostic devient ainsi plus profond sans ouvrir une porte générique sur le système de fichiers. Cette frontière complète le cloisonnement par compte du journal d’exécution. La bonne information reste disponible au bon niveau, avec une audience qui se réduit à mesure que sa sensibilité augmente.
14. Lire par segments de cinquante mille octets
Un curseur poursuit le fichier au lieu de le recharger intégralement
Lors de la première ouverture, la lecture commence au plus deux cent mille octets avant la fin du fichier. L’équipe voit ainsi le contexte récent sans rapatrier tout l’historique d’un journal potentiellement volumineux. Si le fichier est plus petit, la lecture commence simplement à zéro.
Chaque appel suivant envoie la position déjà lue. Le serveur calcule ce qu’il reste, lit au maximum cinquante mille octets et retourne le prochain curseur. La réponse précise également la taille du fichier, la position demandée, la position réellement utilisée et s’il reste encore du contenu.
Cette lecture incrémentale réduit le volume transféré et conserve l’ordre des événements. Elle évite aussi qu’un rafraîchissement répète sans cesse les mêmes lignes, comportement qui rendrait l’investigation confuse précisément au moment où plusieurs événements rapprochés doivent être comparés.
Le navigateur planifie l’appel suivant même après une erreur, mais son badge quitte l’état « Live » pour afficher l’échec. L’opérateur sait donc que l’absence de nouvelle ligne peut venir de la lecture elle-même. La page ne transforme pas un défaut réseau en silence rassurant.
15. Continuer à suivre un journal après sa rotation
Un curseur devenu trop grand est replacé dans la fin du nouveau fichier
En production, un journal peut être archivé puis remplacé par un fichier plus court. Le curseur du navigateur pointe alors au-delà de la nouvelle taille. Sans traitement spécifique, la page resterait bloquée à une position qui n’existe plus et cesserait silencieusement d’afficher les événements.
Le lecteur détecte cette situation. Il replace la position au plus deux cent mille octets avant la fin du nouveau fichier et retourne un indicateur de rotation. L’interface ajoute une ligne visible signalant que le curseur a été réinitialisé avant de poursuivre le suivi.
Cette décision privilégie la continuité d’exploitation. Elle ne tente pas de fusionner automatiquement l’ancien fichier archivé avec le nouveau, ce qui pourrait mélanger des chronologies ou demander des droits supplémentaires. L’équipe garde l’information essentielle : le flux en direct a changé de fichier.
Le mécanisme illustre l’esprit du projet : traiter explicitement les états intermédiaires qui rendent un diagnostic trompeur. Une rotation n’est ni une absence d’événement ni une erreur du flux métier. C’est un changement de support que l’outil doit annoncer pour préserver la confiance dans la lecture.
16. Scénario : une collecte de commandes semble ne plus avancer
Trois niveaux suffisent à séparer attente, saturation et erreur applicative
L’équipe constate qu’une commande attendue n’apparaît pas. Elle ouvre d’abord les exécutions du compte, filtre la fonction et retrouve le lancement concerné. Si son état est « vide », la collecte déclare n’avoir reçu aucun élément sur la période : la piste porte sur la source ou les bornes demandées, pas sur une file bloquée.
Si l’exécution reste en attente, le tableau RabbitMQ montre la file correspondante. Des messages prêts et aucun consommateur orientent vers le runtime. Des messages non acquittés et un débit d’acquittement actif suggèrent au contraire un travail encore en cours. Une profondeur qui diminue invite à observer plutôt qu’à dupliquer le lancement.
Si l’exécution finit en échec après consommation, une personne autorisée ouvre le journal de production et retrouve l’événement à partir de l’heure, de la fonction et du contexte canal. Elle dispose alors de la matière nécessaire pour distinguer une donnée refusée, une indisponibilité externe ou un défaut interne.
La reprise éventuelle est préparée en dehors de ces écrans, avec un périmètre identifié. L’équipe peut corriger la donnée ou le connecteur concerné puis relancer le flux approprié, au lieu de redémarrer indistinctement toutes les collectes. Le bénéfice vient de la précision de la décision, pas d’une automatisation cachée du remède.
17. Des arbitrages conçus pour préserver la preuve
Lecture seule, volumes bornés et absence de score automatique
Le premier arbitrage est l’absence d’action destructive dans le tableau RabbitMQ. Il n’y a ni purge de file, ni suppression de message, ni acquittement forcé. Même l’ouverture des charges utilise un mode qui les remet en file. L’observation ne change donc pas volontairement le résultat attendu du traitement.
Le deuxième arbitrage concerne les volumes. Cent messages au maximum, cinquante mille octets par charge, cinquante mille octets par segment de journal, deux cent mille octets de contexte initial et quatre cent mille caractères dans le navigateur empêchent l’outil d’exploitation de devenir lui-même une source de charge incontrôlée.
Le troisième arbitrage refuse une priorité business fabriquée à partir de signaux techniques. Le nombre de messages, l’ancienneté, le statut ou le débit ne disent pas seuls combien de commandes, de ventes ou de marge sont exposées. L’écran présente les faits ; la qualification économique reste un travail à relier au contexte vendeur.
Enfin, les erreurs de l’observabilité restent visibles. Une API RabbitMQ indisponible produit un badge d’erreur. Un journal absent renvoie une réponse dédiée. Une rotation est annoncée. À chaque fois, le système distingue « aucun problème détecté » de « impossible d’observer », nuance indispensable pour un run fiable.
18. Onze fichiers de tests pour verrouiller les contrats de diagnostic
Cycle métier, agrégation, accès, lecture incrémentale et normalisation des files
Trois tests unitaires couvrent l’ajout, la modification et l’agrégation d’une exécution ; trois tests d’intégration reprennent ces mêmes services avec leurs écritures réelles. Ils contrôlent notamment les états, la progression, les compteurs cumulés et le calcul du parent à partir de ses enfants.
Deux tests applicatifs vérifient la recherche et la vue de détail des exécutions, dont le cloisonnement par compte. Deux autres couvrent l’écran et la lecture du journal système : personnes autorisées, fichiers permis, positions de lecture et réponses lorsque la ressource n’est pas disponible.
Le onzième fichier contrôle le client RabbitMQ. Il vérifie la requête vers le bon vhost, l’authentification, la normalisation de deux files, leur tri et le calcul des totaux messages, prêts, non acquittés, consommateurs et débits. Cette preuve porte sur le contrat d’affichage, pas sur une disponibilité permanente de RabbitMQ.
Le choix de tests ciblés accompagne la structure en trois niveaux. Si un statut, un total ou une frontière d’accès change, la régression doit être visible avant qu’elle ne transforme un diagnostic correct en fausse conclusion. Sur un outil d’exploitation, une donnée mal interprétée peut être plus dangereuse qu’une donnée absente.
19. Une mise en place en trois temps, consolidée au printemps 2026
Le journal métier a précédé les logs protégés, puis l’observation RabbitMQ a complété la chaîne
Le 6 mars 2026, la recherche des exécutions a fourni le premier repère métier. Les jours suivants ont enrichi la vue, le contexte et la relation entre collectes parentes et sous-traitements. Cette première étape rendait déjà chaque lancement identifiable et comparable dans le compte concerné.
Le 15 mars, l’accès aux journaux système a ajouté une profondeur réservée à l’exploitation. La lecture incrémentale, les limites de taille, le suivi en direct et la gestion de rotation ont été conçus ensemble afin que l’écran reste utilisable lorsque le fichier continue d’évoluer.
Le 26 avril, le tableau RabbitMQ a comblé l’espace entre ces deux couches. L’équipe pouvait désormais voir si le travail attendait, était livré ou progressait entre publications et acquittements, puis ouvrir un échantillon de charges sans les consommer. La chronologie du projet suit ainsi la profondeur de l’enquête.
Cette succession évite de présenter le diagnostic comme une fonction monolithique apparue d’un seul geste. Chaque niveau répond à une limite observée du précédent et conserve son propre contrat. En production, l’ensemble forme un parcours continu tout en restant composé de briques indépendantes et testables.
20. Ce qui change concrètement pour l’exploitation
Moins d’hypothèses au départ, un périmètre plus précis avant toute reprise
Le premier gain observable est la réduction du champ de recherche. L’heure, la fonction, le mode, le canal, la période, le statut et les compteurs identifient l’exécution concernée. L’équipe n’ouvre plus un journal général sans savoir quelle fenêtre ni quelle source chercher.
Le deuxième gain est la distinction entre attente et traitement actif. Ready, unacked, consommateurs et débits montrent si le message n’a pas encore été pris, s’il est en cours ou si la file se résorbe. Cette lecture permet d’éviter une relance prématurée qui ajouterait du travail pendant que le premier passage avance encore.
Le troisième gain est la continuité du diagnostic. Si le niveau métier ne suffit pas, la file puis le journal prolongent l’enquête sans rupture de raisonnement. Chaque couche apporte une preuve différente, et l’indisponibilité de l’une d’elles est elle-même signalée au lieu d’être assimilée à un état sain.
Enfin, la séparation des accès améliore la sérénité opérationnelle. Le compte voit ses traitements sans connaître ceux des autres. L’exploitation observe les files avec des réponses bornées. Les journaux bruts restent réservés. La visibilité augmente donc sans banaliser l’accès aux données les plus sensibles.
21. Ce que le dispositif ne décide pas à la place de l’équipe
Pas de priorité économique, d’alerte ni de rejeu depuis ces écrans
Le dispositif ne transforme pas automatiquement une profondeur de file en gravité commerciale. Il ne connaît pas, dans ce périmètre, le chiffre d’affaires exposé, la marge concernée ou la promesse client associée à chaque message. Ces éléments doivent être rapprochés d’indicateurs métier avant de prioriser une intervention.
Il n’envoie pas non plus de notification lorsqu’une exécution échoue ou qu’une file s’accumule. Le rafraîchissement est visible tant que la page est ouverte. Une politique d’alerte demanderait des seuils par flux, une gestion du bruit et des destinataires responsables ; aucune de ces décisions n’est simulée dans le récit.
Enfin, il ne corrige aucune donnée et ne relance aucun traitement. Une charge RabbitMQ observée est remise en file, mais la page ne rejoue pas une commande applicative. Le journal système se lit sans modification. Cette frontière empêche qu’une investigation exploratoire produise une mutation difficile à retracer.
Ces limites ne diminuent pas la valeur du projet : elles la définissent. Ciama dispose d’une base fiable pour qualifier avant d’agir. Les futures capacités d’alerte ou de reprise pourront s’y appuyer seulement lorsqu’elles auront leur propre contrat de sécurité, de responsabilité et de preuve.
22. Relier le diagnostic aux preuves métier voisines
Exécution globale, connecteur actif et tentative de stock éclairent des échelles différentes
Le journal des synchronisations métier approfondit le premier niveau : six états, progression, compteurs, filtres et relation parent-enfants. Il constitue le point d’entrée naturel lorsque l’incident porte sur une collecte identifiable.
Le centre de contrôle des connecteurs explique en amont comment une capacité est rendue disponible par compte, fournisseur et fonction. Il aide à distinguer un flux non activé d’un flux activé qui ne circule plus correctement.
L’historique des envois de stock descend au niveau d’une offre précise et sépare résultat du push et résultat de la relecture. Il montre comment le diagnostic général rejoint une preuve fonctionnelle spécialisée lorsque l’incident concerne une quantité marketplace.
Ces projets forment un parcours cohérent sans se confondre. Le connecteur détermine ce qui peut fonctionner, l’exécution décrit ce qui a été lancé, RabbitMQ montre comment le travail circule et l’historique métier confirme la conséquence particulière. La supervision du run marketplace consiste précisément à tenir ces niveaux ensemble sans en faire un verdict magique.
23. Conclusion : une bonne reprise commence par un diagnostic proportionné
Comprendre le parcours réel du flux avant de décider où et comment intervenir
Ce projet transforme un symptôme flou en enquête structurée. L’exécution métier donne le contexte et le verdict déclaré. RabbitMQ montre l’attente, la consommation et les débits. Le journal applicatif apporte le détail réservé aux situations qui le demandent. Aucun niveau ne prétend suffire seul, mais chacun réduit l’incertitude du suivant.
La force de la solution tient autant à ses limites qu’à ses écrans. Les messages observés ne sont pas supprimés. Les journaux ne sont pas ouverts à tous. Les volumes sont bornés. Aucune priorité commerciale, alerte ou reprise automatique n’est inventée. La plateforme donne des preuves pour agir, pas l’illusion qu’un bouton générique peut réparer tous les flux.
Pour une équipe qui exploite commandes, offres, catalogue ou stocks sur plusieurs canaux, cette discipline change le quotidien : attendre lorsqu’un traitement avance, intervenir lorsque la file ne consomme plus, approfondir lorsqu’une erreur applicative l’exige et préparer une reprise seulement après avoir circonscrit la cause. C’est ce que Dawap met en œuvre dans son accompagnement de run et supervision marketplace vendeur : une exploitation lucide, traçable et maîtrisée.
