File d'attente : le mécanisme qui empêche vos flux de disparaître quand ça casse

Un ERP⁸ envoie une commande. Le CRM⁹ est en maintenance. Sans file d'attente¹, la commande rebondit, l'erreur s'affiche, et selon l'implémentation la donnée est perdue ou relancée à l'aveugle. Avec une file, le message attend. Le CRM⁹ revient. Le traitement reprend. Ce n'est pas de la magie : c'est un contrat.

Une file d'attente¹ (message queue en anglais) est un intermédiaire qui reçoit des messages, les stocke de façon durable, et les remet à un consommateur quand celui-ci est prêt. L'émetteur n'attend pas que le destinataire soit disponible ; il dépose et continue.

Le problème qu'elle résout

• Découplage temporel : l'émetteur et le consommateur n'ont pas besoin d'être disponibles en même temps.
• Absorption des pics : un rush de commandes ne noie pas immédiatement le système aval.
• Résilience : une panne du consommateur ne fait pas disparaître les messages déjà acceptés.
• Retraitement : un message échoué peut être relu et rejoué, sous conditions.

Avant que les files deviennent un standard accessible, on collait souvent toute cette logique dans un ESB⁷. Aujourd'hui, pour synchroniser un CRM⁹, un ERP⁸ et deux outils métier via des API⁵, une file bien placée remplace une large part du bus : plus simple à auditer, plus facile à expliquer en comité.

Comment ça marche, en une phrase par rôle

• Producteur : envoie un message (« nouvelle commande #4521 »).
• File : persiste le message jusqu'à accusé de traitement.
• Consommateur : lit le message, exécute la logique (transformer, appeler une API⁵), acquitte ou signale l'échec.
• Supervision : compteurs, alertes, profondeur de file, pour savoir si ça s'emballe.

Le détail qui change tout : l'acquittement. Tant que le consommateur n'a pas fini correctement, le message peut réapparaître. C'est la base du rejeu², et aussi du risque de doublons si la logique n'est pas idempotente⁴.

File d'attente vs appel direct

Un appel HTTP⁶ synchrone entre deux systèmes, c'est simple tant que les deux sont debout. Dès que l'un tombe, ou que le traitement dépasse le timeout, vous êtes dans le gris : retry automatique ? doublon ? perte ?

• Appel direct : faible latence, peu de moving parts, fragile aux pannes.
• File d'attente¹ : latence légèrement plus haute, bien plus prévisible en exploitation.

Pour du temps réel strict (affichage utilisateur), l'appel direct a sa place. Pour de l'intégration de données entre systèmes critiques, la file est le défaut raisonnable.

Rejeu, DLQ et limites

Une file ne résout pas tout. Trois pièges reviennent en production :

• Rejeu infini : le même message cassé tourne en boucle et pollue les logs. Il faut un plafond de tentatives puis une dead letter queue³.
• Doublons : un acquittement tardif peut faire traiter deux fois le même événement. La logique doit être idempotente⁴ ou dédupliquée.
• Ordre : toutes les files ne garantissent pas l'ordre strict ; le design des flux doit l'assumer.

Le rejeu² mérite sa propre lecture : rejeu des flux d'intégration. Les patterns DLQ³ : dead letter queue. Une file sans politique de rejeu, c'est une poubelle retardée.

Ce qu'une file n'est pas

• Pas un entrepôt de données : ne remplace pas un data warehouse¹² pour l'analytique.
• Pas un BPM¹¹ : elle transporte des messages, elle ne valide pas des workflows humains multi-étapes.
• Pas un iPaaS¹⁰ : c'est une brique d'infrastructure, pas une plateforme complète avec studio et catalogue.
• Pas une excuse pour ne pas tester : le code consommateur reste du code à revoir et à déployer.

Où se place Portlane

Portlane s'appuie sur des files d'attente¹ fiables pour découpler les systèmes et permettre le rejeu² contrôlé. La logique reste en Python full-code¹³, versionnée chez vous. La file est l'échafaudage, pas la prison.

Portlane est encore en développement actif. Le principe architectural est posé ; cette page ne remplace pas une doc d'exploitation. Contexte plus large : qu'est-ce qu'un iPaaS et pourquoi nous construisons Portlane.

Quand en mettre une (checklist)

• Un flux ne doit pas perdre de données si le destinataire est down.
• Les volumes varient (pics commandes, fins de mois).
• Vous voulez rejouer après correction sans réinjecter manuellement.
• Deux équipes déploient à des rythmes différents : la file absorbe le décalage.

Si aucune de ces cases n'est cochée et que le flux est trivial, un appel direct peut suffire. Dès qu'un flux est critique, la question n'est plus « file ou pas » mais « quelle politique de rejeu ».

Pour aller plus loin

• Rejeu contrôlé : rejeu des flux d'intégration
• Messages en échec : dead letter queue
• Le bus historique : l'ESB est trop vieux
• Le full-code : full-code vs low-code

Questions fréquentes

File d'attente et base de données, c'est la même chose ?

Non. Une base stocke l'état métier (clients, commandes). Une file d'attente¹ stocke des messages en transit : « traite ceci quand tu peux ». On peut persister les deux, mais le contrat n'est pas le même. Mélanger les rôles crée des tables bâtardes que personne n'ose vider.

Faut-il une file d'attente pour chaque flux ?

Pas forcément une par flux, mais au moins une frontière claire entre émetteur et consommateur dès qu'une panne ne doit pas faire disparaître des données. Plusieurs flux peuvent partager une infrastructure de files avec des files logiques séparées.

Une file d'attente remplace-t-elle un ESB ?

Non. Elle remplace une partie de ce que l'ESB⁷ faisait pour le découplage et la résilience. Pas la médiation multi-protocoles, pas le BPM¹¹, pas le MDM. Pour beaucoup d'ETI, c'est suffisant. Voir l'ESB est trop vieux.

Portlane utilise-t-il des files d'attente ?

Oui. C'est un pilier du modèle : découpler les systèmes, survivre aux pannes, permettre le rejeu². Portlane est encore en développement actif ; le principe est fixé, pas chaque détail d'implémentation.

Que faire quand un message échoue en boucle ?

Ne pas le relancer indéfiniment. Isoler dans une dead letter queue (DLQ³), alerter, analyser, corriger, puis rejouer manuellement ou automatiquement. Patterns détaillés : dead letter queue en intégration.

Glossaire

• ¹ File d'attente (message queue) : système qui stocke des messages en attente de traitement par un consommateur.
• ² Rejeu : relance d'un message ou d'un flux après échec ou correction.
• ³ DLQ (dead letter queue) : file où sont isolés les messages en échec définitif après épuisement des tentatives.
• ⁴ Idempotence : traiter deux fois le même message produit le même résultat qu'une fois, évite les doublons.
• ⁵ API : interface standardisée d'échange entre logiciels.
• ⁶ HTTP : protocole courant des API REST.
• ⁷ ESB : bus de services d'entreprise, médiation centralisée entre applications.
• ⁸ ERP : progiciel de gestion intégré.
• ⁹ CRM : logiciel de gestion de la relation client.
• ¹⁰ iPaaS : plateforme cloud d'intégration en service.
• ¹¹ BPM : orchestration de processus métier.
• ¹² Data warehouse : entrepôt de données pour l'analytique.
• ¹³ Full-code : logique d'intégration écrite en code versionné.