Vous ouvrez la console de votre broker RabbitMQ un lundi matin. 247 files s’affichent. Certaines s’appellent orders, d’autres team3-prod-notifs, d’autres encore test_queue_final_v2. Laquelle est en production ? Laquelle peut-on supprimer sans risque ? Personne ne sait.
Sans convention de nommage, un broker partagé entre plusieurs équipes devient un champ de mines. Cet article propose un template réutilisable, adapté aux contraintes de RabbitMQ, Kafka et AWS SQS, pour que chaque nom de file soit auto-documentant.
Dans cet article, file de messages désigne le concept générique : une queue RabbitMQ, un topic Kafka ou une queue SQS. La convention de nommage s’applique à chacun de ces objets, même si leur mécanique diffère.
Pourquoi normaliser le nommage
Dans un contexte entreprise, le message broker est souvent une entité partagée entre les domaines. Plusieurs applications, voire plusieurs équipes, publient et consomment des messages sur le même cluster.
Sans convention explicite, chaque équipe invente son propre format. Le résultat ?
- Les dashboards Grafana sont illisibles : impossible de filtrer par équipe ou par domaine
- Un incident à 2h du matin sur
queue_notif_3ne permet pas d’identifier le responsable - Les files de test s’accumulent sans jamais être nettoyées
Une convention de nommage structurée, même légère, résout ces problèmes de la même manière que le DNS structure les noms de domaines : par segments lisibles et hiérarchiques.
- Observabilité : un nom structuré s’intègre directement dans les dashboards et les alertes
- Réponse aux incidents : le nom identifie l’équipe, le domaine et l’environnement en un coup d’oeil
- Gouvernance multi-équipes : chaque équipe respecte le même format, sans coordination lourde
- Automatisation : scripts de cleanup, dashboards et alerting peuvent parser les noms de files
Si vous avez déjà vécu un incident sur un broker partagé, vous savez que la première minute est critique. Un SLA de 99,9 % ne laisse que 43 minutes d’indisponibilité par mois : chaque seconde passée à chercher “c’est la file de qui, ça ?” est une seconde perdue.
L’anatomie d’un bon nom
Un nom de file efficace est composé de segments ordonnés, séparés par un délimiteur. Chaque segment porte une information précise.
Environnement
Premier segment, il distingue immédiatement les files de production des files de test.
Valeurs typiques : prod, staging, uat, dev, e2e.
Si votre broker est partagé entre plusieurs environnements (ce qui est courant en développement), l’absence de préfixe d’environnement est la première cause de messages envoyés au mauvais endroit. Ce segment n’est pas optionnel.
Propriétaire
Le nom de l’entité responsable de la file : celle à contacter en cas de problème. Deux approches courantes :
- Par équipe :
team-payments,team-logistics. Avantage : ownership clair pour l’incident response, stable même si les applications évoluent. - Par application :
billing-service,shipping-api. Avantage : traçabilité directe dans les logs et les métriques, plus précis quand plusieurs applications coexistent dans une même équipe.
L’essentiel est de choisir un seul modèle et de s’y tenir. Évitez les noms instables : une personne (file-de-jean-bob), un projet temporaire ou un nom de sprint.
Domaine
Le domaine métier auquel se rattache la file : booking, invoicing, notification, inventory.
Ce segment permet de regrouper visuellement les files par contexte métier dans la console du broker.
Entité
L’entité métier concernée par les messages : order, shipment, payment, user.
Ce segment, souvent oublié, permet de distinguer les files au sein d’un même domaine. Sans lui, prod.team-payments.invoicing.events.v1 ne dit pas quels événements transitent.
Le domaine représente le périmètre fonctionnel (invoicing), l’entité représente l’objet métier précis (invoice, credit-note). Si votre domaine ne contient qu’une seule entité, vous pouvez fusionner les deux segments.
Pattern
Le pattern d’usage de la file :
events: événements métier (publication/abonnement)commands: commandes destinées à un consommateur spécifiqueretry: messages en attente de nouvelle tentativedlq: dead letter queue, le cimetière des messages en erreurbuffer: file tampon pour absorber la charge
Version
La version du contrat de messages : v1, v2.
Les files transportent des messages qui respectent une structure de données précise. C’est une API. Si une évolution cassante survient (champ supprimé, format modifié), la version doit changer.
Si vous utilisez un schema registry (Confluent, AWS Glue), la version dans le nom de la file désigne la version majeure du contrat. Les évolutions compatibles (ajout de champs optionnels) ne nécessitent pas de nouvelle file.
Le template complet
<environnement>.<propriétaire>.<domaine>.<entité>.<pattern>.<version>Exemples concrets :
| Nom de file | Signification |
|---|---|
prod.team-payments.invoicing.invoice.events.v1 | Événements d’invoice en production, équipe payments |
staging.team-logistics.shipping.shipment.commands.v1 | Commandes d’expédition en staging |
prod.team-payments.invoicing.invoice.dlq.v1 | Dead letter queue des événements d’invoice |
prod.team-marketing.notification.email.buffer.v2 | File tampon des notifications email, v2 |
dev.team-platform.monitoring.alert.events.v1 | Événements d’alerting en développement |
Adapter la convention à votre broker
Le template ci-dessus est un modèle générique. Chaque broker impose ses propres contraintes : séparateur, longueur maximale, caractères autorisés. Voici comment l’adapter.
RabbitMQ
RabbitMQ utilise le . comme séparateur naturel dans les routing keys, ce qui rend le template directement compatible. La limite est de 255 octets (en UTF-8) pour le nom d’une queue. En pratique, avec des noms en ASCII pur (lettres, chiffres, ., -), un caractère vaut un octet : la limite équivaut à 255 caractères.
Les routing keys RabbitMQ supportent les wildcards * (un segment) et # (zéro ou plusieurs segments). Votre convention de nommage doit être cohérente avec vos règles de routage : prod.team-payments.invoicing.* doit matcher toutes les files d’invoicing de l’équipe payments en production.
Kafka
Kafka accepte le . et le - comme séparateurs. La limite est de 249 caractères pour un nom de topic. Attention : les consumer groups doivent aussi respecter une convention de nommage.
Suggestion pour les consumer groups : <application>.<topic-name> permet d’identifier immédiatement quelle application consomme quel topic.
Le nom du consumer group apparaît dans les métriques de lag. Un nom structuré (app-billing.prod.team-payments.invoicing.invoice.events.v1) facilite l’alerting sur le retard de consommation.
AWS SQS
SQS utilise le - comme séparateur (le . est autorisé mais peu conventionnel). La limite est de 80 caractères, ce qui impose d’être concis.
Pour les files FIFO, le suffixe .fifo est obligatoire et compte dans la limite de 80 caractères.
Avec SQS, privilégiez des abréviations cohérentes : prd au lieu de prod, pay au lieu de payments. Documentez ces abréviations dans votre ADR ou votre wiki d’équipe.
Tableau comparatif
| Broker | Séparateur | Longueur max | Spécificités |
|---|---|---|---|
| RabbitMQ | . | 255 octets | Wildcards * # sur routing keys |
| Kafka | . ou - | 249 chars | Consumer group à nommer aussi |
| AWS SQS | - | 80 chars | FIFO = .fifo obligatoire |
Les pièges courants
Même avec un template, certaines erreurs reviennent fréquemment.
- Nom instable comme propriétaire : évitez les noms de personnes, de projets temporaires ou de sprints. Que vous choisissiez le nom d’équipe ou d’application, il doit être canonique et durable
- Casse incohérente :
Team-Paymentsici,team_paymentslà. Choisissezkebab-caseet tenez-vous-y - Information transitoire dans le nom :
sprint-42-test-queuen’a aucun sens dans 6 mois - Pas de préfixe d’environnement : la file
order-eventsexiste en prod et en dev ? Bonne chance pour le debug - Nom trop long pour le broker : testez la longueur avant de déployer, surtout sur SQS (80 chars)
Avant de valider un nom de file, posez-vous cette question : est-ce qu’un collègue qui ne connaît pas le projet pourrait comprendre cette file à 2h du matin, en plein incident ? Si la réponse est non, le nom est à revoir.
Et dans le cas de tests automatisés ?
Lorsque vous exécutez des tests d’intégration, il est souvent nécessaire de créer des files à la volée. Chaque exécution doit disposer de ses propres files pour éviter les collisions entre tests parallèles.
La solution : ajouter un UID en suffixe. Préférez un UID court et lisible (contexte d’exécution + identifiant de test + timestamp) plutôt qu’un UUID complet de 36 caractères.
e2e.team-payments.invoicing.invoice.events.v1.runner-1.test-13.20250127T1112Le problème : ces files temporaires s’accumulent. Sans mécanisme de nettoyage, vous pouvez vous retrouver avec des milliers de files orphelines.
Sur un projet réel, nous avons découvert plus de 12 000 files de test orphelines sur un cluster RabbitMQ. Le nettoyage a pris une journée complète. Un mécanisme automatique aurait évité cette dette.
Chaque broker propose des mécanismes de nettoyage :
- RabbitMQ : l’argument
x-expiressupprime automatiquement une queue après une période d’inactivité (par exemple 1 heure) - Kafka : la retention policy (par défaut 7 jours) peut être réduite pour les topics de test
- AWS SQS : pas de TTL natif sur la queue elle-même, mais un script de cleanup basé sur la date dans le nom fonctionne très bien
- Fallback universel : un cron job qui liste les files préfixées
e2e.et supprime celles de plus de 24h
Si vous faites des tests de charge réalistes, le volume de files temporaires peut être encore plus élevé. Automatisez le nettoyage dès le début.
Formaliser et appliquer
Une convention qui n’est pas appliquée est une convention qui n’existe pas. Voici comment la rendre durable.
ADR plutôt que wiki : documentez la convention dans un Architecture Decision Record versionné avec le code. Un wiki se perd ; un ADR dans le dépôt Git reste visible et maintenu.
Validation en CI : une regex dans votre pipeline CI peut rejeter les noms non conformes avant le déploiement.
^(prod|staging|uat|dev|e2e)\.[a-z0-9-]+\.[a-z0-9-]+\.[a-z0-9-]+\.(events|commands|retry|dlq|buffer)\.(v[0-9]+)$
Cette regex valide le format à 6 segments. Adaptez-la à vos besoins : ajoutez des patterns, autorisez des segments optionnels, ou ajustez les valeurs d’environnement.
Catalogue de files : un fichier YAML ou JSON dans votre dépôt qui liste toutes les files déclarées, avec leur propriétaire et leur description. Ce catalogue peut alimenter vos dashboards et vos alertes.
Si vous utilisez une approche de promotion d’artefacts, le catalogue de files peut suivre le même cycle de vie que vos artefacts : déclaré en dev, promu en staging, puis en production.
TL;DR
- Structurez les noms en segments ordonnés :
<env>.<propriétaire>.<domaine>.<entité>.<pattern>.<version> - Adaptez le séparateur et la longueur aux contraintes de votre broker (
.pour RabbitMQ/Kafka,-pour SQS) - Choisissez un propriétaire stable : équipe ou application, peu importe, mais le nom doit être canonique et durable
- Préfixez toujours l’environnement : un broker partagé sans préfixe est un incident qui attend de se produire
- Automatisez le nettoyage des files de test avec
x-expires, retention policies ou cron jobs - Formalisez dans un ADR et validez par regex en CI pour que la convention survive au turnover
Convention de nommage, gouvernance de broker, architecture événementielle : on aide les équipes tech à structurer leurs échanges asynchrones. Parlons-en.
