Jusqu'à quand peut-on utiliser MSMQ ? — La décision de migration d'une file d'attente héritée « qui n'est même pas dépréciée »

« J’ai entendu dire que MSMQ a été abandonné. Le système que nous faisons tourner aujourd’hui doit-il être migré tout de suite ? » — quand on maintient un système existant, c’est la première chose à démêler.

La survie de MSMQ (Microsoft Message Queuing) en tant que fonctionnalité de l’OS et l’existence d’une API pour l’utiliser depuis .NET sont deux questions distinctes. En juillet 2026, date de référence de cet article, MSMQ ne figure sur aucune liste officielle de fonctionnalités dépréciées et reste une fonctionnalité optionnelle de Windows. La bibliothèque standard System.Messaging, en revanche, est réservée à .NET Framework et n’a jamais été portée vers .NET (Core et versions ultérieures).¹²³

Le problème n’est donc pas que MSMQ s’arrêtera demain. C’est que l’implémentation de la file d’attente devient l’obstacle lorsqu’on porte l’application vers .NET.

Cet article s’adresse aux développeurs qui maintiennent et migrent des systèmes utilisant MSMQ, ainsi qu’aux services des systèmes d’information qui fixent la politique. Il commence par établir les faits et les conditions d’une utilisation continue, puis enchaîne sur l’inventaire, le choix de la cible de migration, l’implémentation d’une file d’attente sur table et la procédure de bascule.

Pour la migration depuis VB6 ou depuis .NET Framework dans son ensemble, voir « Jusqu’à quand les applications VB6 continueront-elles de fonctionner ? — état du support du runtime et démarche concrète vers une migration .NET » et « Liste de vérification avant de migrer de .NET Framework vers .NET ». Cet article se concentre sur la file d’attente.

1. D’abord la conclusion : séparer la survie de l’OS de la migration de l’application

Si vous portez l’application vers .NET, le principe est de migrer la file d’attente en même temps. Si vous restez pour l’instant sur .NET Framework, vous pouvez choisir de continuer à utiliser MSMQ une fois la période de support de l’OS et les conditions d’exploitation vérifiées. Adopter MSMQ dans un nouveau projet n’est pas recommandé.⁴

Lire à partir de ce que vous devez décider maintenant

Si vous lisez l’article d’un bout à l’autre, l’ordre est confirmer ce qui survit → conditions d’utilisation continue → inventaire → cible de migration → implémentation → bascule. Quand vous reviendrez sur la décision plus tard, voir le résumé du chapitre 7.

1.1. Confirmer de quelle couche parle la question

La réponse à « peut-on encore utiliser MSMQ » diffère selon la couche, comme suit. La date de référence de ces états est juillet 2026, la même qu’en tête d’article.

1.2. Ce qui n’a pas été déprécié, c’est la fonctionnalité OS

La liste « Deprecated features » du client Windows porte des entrées telles que NTLM, VBScript et WordPad, mais il n’y a pas d’entrée pour MSMQ. Il en va de même pour « Features Removed or No Longer Developed » de Windows Server, y compris l’onglet Windows Server 2025.¹²

Deprecated est un stade officiel indiquant que le développement actif a cessé et que la fonctionnalité pourra être retirée dans une mise à jour future. C’est distinct de removed. Pour MSMQ, ce que cet article a confirmé, c’est que même cette dépréciation n’a pas été déclarée.

1.3. Ce qui bloque la migration vers .NET, c’est l’API managée

La référence de System.Messaging.MessageQueue couvre .NET Framework 1.1 à 4.8.1 ; il n’existe pas d’édition pour .NET (Core et versions ultérieures). Le pack de compatibilité Windows (Microsoft.Windows.Compatibility) fournit environ 20 000 API, couvrant des domaines tels que le Registre, WMI, les services Windows et EventLog, mais il n’inclut pas System.Messaging.³⁶

Si vous le faites vivre avec P/Invoke, vous assumez la maintenance du wrapper

L’API native n’a pas disparu non plus. Appeler depuis .NET, via P/Invoke, des API Win32 telles que MQSendMessage et MQReceiveMessage est possible en soi. Mais vous écrirez et maintiendrez votre propre wrapper pour les formateurs et l’intégration transactionnelle que System.Messaging fournissait. Ce n’est pas la voie principale d’une migration ; c’est un moyen de prolonger la vie de MSMQ lorsque vous devez absolument le garder.⁵

1.4. Juger CoreWCF comme une voie pour le côté récepteur WCF

WCF dans .NET Framework avait une liaison qui utilise MSMQ. Comme voie pour l’héberger sur .NET, il existe le transport MSMQ de CoreWCF (CoreWCF.MSMQ).⁷

Son objet, toutefois, est le côté récepteur d’un service WCF invoqué via une file. Ce n’est ni une API de file générique qui remplace System.Messaging, ni un substitut du client émetteur.

CoreWCF lui-même a une politique de support Microsoft. L’implémentation du transport MSMQ, en revanche, dépend d’un portage communautaire de la version .NET Framework de System.Messaging, et cette dépendance ne peut pas être traitée comme portant la même garantie. Ne l’adoptez qu’après avoir vérifié si la version que vous utilisez est couverte par le support, et qui maintiendra la pièce dépendante.⁷

Ainsi, « MSMQ a déjà été abandonné » et « on ne peut pas le porter tel quel vers .NET » ne veulent pas dire la même chose. Choisir P/Invoke ou CoreWCF reporte le remplacement de la file au prix d’assumer la charge de maintenance de cette voie.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (28 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Continuer à l’utiliser ou non : décider d’après le plan de migration vers .NET et votre dispositif d’exploitation

2.1. Pourquoi « ça marche » ne suffit pas à décider

.NET Framework 4.8 est pris en charge comme composant de Windows, selon le cycle de vie de l’OS sur lequel il est installé. Vous pouvez donc planifier de le faire tourner dans cette période de support.⁴

Ce que vous voulez établir, ce n’est pas seulement s’il fonctionne. Si une dépendance à MSMQ retient toute l’application sur .NET Framework, les charges de maintenance et de migration suivantes restent également.

Le problème de perdre le mainteneur est aussi traité dans « Quand vous héritez d’un système sans code source ni documentation — Procédure pratique pour l’exploiter et le maintenir sans interruption ». Les consultations MSMQ tendent à commencer par une estimation de migration plutôt que par une panne, précisément parce que ce qui pose problème, c’est ce genre de dépendance et de passation, plutôt que le comportement lui-même.

« Ça tourne aussi longtemps que l’OS le prend en charge » et « plus on attend, plus la migration devient facile » sont deux affirmations différentes. Même lorsque vous ne migrez pas pour l’instant, faites d’abord l’inventaire des parties difficiles.

2.2. Si vous ne migrez pas pour l’instant, remplissez quatre conditions minimales

N’avoir aucun plan de porter l’application vers .NET et la laisser inchangée pour l’instant pour des raisons de coût-bénéfice — ce qu’on appelle souvent conservation figée — est raisonnable sous conditions. La prémisse, toutefois, est que les quatre points suivants soient tous remplis.

La revue annuelle en particulier est la procédure qui empêche un avis de dépréciation ou l’effet d’une mise à jour de l’OS de vous échapper. Au cas où la personne responsable partirait, laissez derrière vous non seulement la configuration mais aussi la procédure de reprise. Maintenir le statu quo sans remplir ces conditions porte le risque que plus personne ne sache ni qu’il s’est arrêté, ni pourquoi.

3. Inventaire : consigner ce que vous avez délégué à MSMQ

3.1. Mettre au clair les fonctionnalités et la terminologie

Avec MSMQ, l’émetteur écrit un message dans une file, et une application sur la même machine ou sur une autre le retire au moment qui lui convient. Il y a principalement trois propriétés qui doivent passer à la cible de migration.

Il s’accumule même lorsque la destination est arrêtée : store-and-forward

Même lorsque la destination est arrêtée, les messages s’accumulent localement et sont livrés une fois qu’elle se rétablit. Cela aide sur des liaisons instables entre sites, mais cela ne garantit pas inconditionnellement la durabilité au-delà d’un redémarrage.

Il valide ensemble la file et la mise à jour de la base : transactions

Les opérations sur la file peuvent être rendues transactionnelles, et avec MS DTC (le coordinateur de transactions distribuées) le retrait de la file et la mise à jour de la base peuvent être validés dans une seule transaction distribuée.

Il était utilisable sans installer de middleware supplémentaire : livré avec l’OS

Parce qu’aucun middleware supplémentaire n’avait à être installé, il a été largement utilisé dans les années 2000 pour l’intégration des commandes, la génération asynchrone de rapports et l’intégration entre étapes de fabrication à l’atelier. La combinaison de ces trois propriétés est la raison pour laquelle il est encore là.

Distinguer par leur nom l’accumulation, la durabilité et les transactions

Les termes utilisés dans les tableaux de décision sont aussi fixés ici.⁹

« Ça peut s’accumuler pendant que le récepteur est arrêté » et « ça survit à un redémarrage de MSMQ ou de la machine » sont des propriétés différentes. Enquêtez séparément pour savoir si vous vous appuyez sur la première seulement, ou si vous avez aussi besoin de la seconde via des messages recoverable ou transactionnels.

3.2. Extraire les dépendances du code, de la configuration et de l’exploitation

Ne pas laisser l’inventaire s’arrêter aux références de bibliothèques

Commencez par chercher les références à System.Messaging et les endroits où MessageQueue est construit. L’absence d’une telle référence, toutefois, n’est pas à elle seule un motif de conclure que MSMQ n’est pas utilisé. Vérifiez les voies d’appel séparément.

Consigner, par file, le fondement de la décision de migration

Utilisez le tableau suivant pour consigner ce que vous trouvez, une ligne par file. L’essentiel n’est pas de cocher et d’en rester là, mais de laisser les résultats comme fondement de la politique de migration et des documents d’approbation interne.

4. Cibles de migration : choisir par les propriétés dont vous avez besoin, non par le nom d’un produit successeur

4.1. Trier les exigences avec quatre questions

D’après les résultats de l’inventaire, établissez les quatre points suivants.

1. Le côté récepteur est-il un traitement qui met à jour votre propre base de données métier ?
2. La file transactionnelle et la mise à jour de la base sont-elles validées ensemble via DTC ?
3. L’émetteur et le récepteur sont-ils sur des machines ou des sites différents ? Le store-and-forward est-il réellement en usage ?
4. Quel est le volume de messages ? À l’échelle de quelques milliers à quelques dizaines de milliers par jour, typique de nombreux systèmes métier, le seul débit des candidats a peu de chances de trancher le choix.

4.2. Le premier choix pour chaque propriété

Pour un travail asynchrone qui met à jour la base métier du même système, regardez d’abord une file d’attente sur table. Choisissez un courtier lorsqu’il existe une exigence qu’une file d’attente sur table ne peut pas satisfaire, telle que la livraison vers plusieurs systèmes ou le routage.

Pourquoi une file d’attente sur table vient en premier

« Regarder d’abord une file d’attente sur table » n’est pas ici le souhait de recommander une base de données pour chaque usage. C’est que pour le traitement asynchrone qui met à jour la même base, courant dans les systèmes métier de l’époque MSMQ, la cohérence reste simple et les sauvegardes, la surveillance et l’exploitation existantes peuvent être mises à profit.

Exigences qui conviennent à un courtier, et ce qu’il faut concevoir en plus

RabbitMQ et Azure Service Bus conviennent à une livraison faiblement couplée entre plusieurs systèmes et plusieurs langages, à la diffusion en éventail et au routage. Ils méritent aussi d’être envisagés lorsque un débit élevé est requis. Parce que la file et la base métier deviennent des ressources séparées, toutefois, ne transportez pas telles quelles l’atomicité de MSMQ plus DTC : concevez l’idempotence et le renvoi dans l’application. Incluez dans l’estimation la surveillance, la redondance, les correctifs et la formation du personnel pour le nouveau middleware.

Migrer ne signifie pas toujours que l’accumulation pendant l’arrêt peut être abandonnée

Vérifiez si la tolérance hors ligne et l’accumulation pendant que le récepteur est arrêté sont des exigences que vous avez le droit d’abandonner. Choisir une file dans le cloud n’apporte pas automatiquement une accumulation locale côté émetteur, et passer à des tubes nommés ne préserve pas l’attente pendant que le pair est arrêté sous la même forme. Si vous en avez besoin, donnez à l’application le renvoi et le tamponnage, ou gardez une file.

5. La file d’attente sur table : valider l’opération de file et la mise à jour métier dans la même base

Ce chapitre commence par ce que signifie rassembler les deux dans une seule base. De là, il examine tour à tour les prémisses du SQL de retrait, jusqu’où l’ordre est garanti, la transaction du worker et les traitements à ajouter pour la production.

5.1. Pourquoi DTC devient inutile

Avec MSMQ, la file et la base sont des ressources séparées. Valider ensemble « retiré de la file » et « mis à jour les données métier » exigeait une transaction distribuée via DTC.

Faites de la file une table de la même base que les données métier et les deux deviennent des mises à jour de cette seule base. Le retrait, la mise à jour métier et l’enregistrement d’achèvement peuvent être validés dans une seule transaction locale. Remplacer une transaction distribuée par une transaction locale est le cœur de cette migration.

Pas seulement le côté récepteur : le côté émetteur peut aussi valider en même temps

Côté émetteur également, la mise à jour des données métier et l’INSERT de la ligne de message peuvent aller dans la même transaction. C’est le modèle outbox, et il empêche l’incohérence où les données métier ont été mises à jour mais aucun message n’est parti.

Ce qui suit est la forme minimale sur SQL Server. La partie C# est un pseudocode qui montre la frontière de transaction ; ce n’est pas une implémentation finie à déployer telle quelle.

5.2. La table qui stocke les travaux

CREATE TABLE dbo.JobQueue (
    Id          BIGINT IDENTITY(1,1) PRIMARY KEY,
    Payload     NVARCHAR(MAX) NOT NULL,                    -- The body. Held as JSON
    Status      TINYINT       NOT NULL DEFAULT 0,          -- 0: pending, 1: in progress, 2: done
    EnqueuedAt  DATETIME2     NOT NULL DEFAULT SYSUTCDATETIME(),
    StartedAt   DATETIME2     NULL,                        -- Used to reclaim rows left in progress by a crash
    RetryCount  INT           NOT NULL DEFAULT 0
);
CREATE INDEX IX_JobQueue_Status ON dbo.JobQueue (Status, Id);

Payload tient le corps en JSON, et Status distingue en attente, en cours et terminé. StartedAt et RetryCount servent aux opérations de récupération et de nouvelle tentative.

5.3. Retirer une ligne, et vérifier les paramètres de la base

Mettre à jour la ligne que vous prenez et récupérer son corps dans une seule instruction SQL

Pour retirer, mettez à jour une ligne en « en cours » tout en recevant le corps via OUTPUT. READPAST saute les candidats qu’un autre worker tient sous verrou de ligne au lieu d’attendre, ce qui permet à plusieurs processus de se partager le travail.¹⁰

WITH next_job AS (
    SELECT TOP (1) *
    -- READCOMMITTEDLOCK is required on a database where READ_COMMITTED_SNAPSHOT is ON (see below).
    -- On a database where it is OFF it matches the default behavior, so leaving it in works for both
    FROM   dbo.JobQueue WITH (READPAST, UPDLOCK, READCOMMITTEDLOCK)
    WHERE  Status = 0
    ORDER  BY Id          -- Dequeue in insertion order. This is what makes it a queue
)
UPDATE next_job
SET    Status = 1, StartedAt = SYSUTCDATETIME()
OUTPUT inserted.Id, inserted.Payload;

Vérifier d’abord le paramètre snapshot et le niveau d’isolement

Quand vous lisez ce SQL, vérifiez READ_COMMITTED_SNAPSHOT et le niveau d’isolement de la session.

La documentation officielle indique que lorsque le READ_COMMITTED_SNAPSHOT de la base est ON et que soit la session est à READ COMMITTED, soit la requête utilise aussi l’indice READCOMMITTED, READPAST ne peut pas être spécifié tel quel. Le remède est de retirer l’indice READCOMMITTED s’il est présent, et d’inclure READCOMMITTEDLOCK.¹⁰

Le niveau d’isolement par défaut est READ COMMITTED, donc porter ceci dans une base avec snapshot activé sans précautions ne se contente pas de bloquer — l’instruction SQL échoue avec une erreur. Azure SQL Database l’a ON par défaut. Sur site, il peut aussi avoir été activé pour soulager le blocage en lecture, donc vérifiez avant de commencer.

SELECT is_read_committed_snapshot_on FROM sys.databases WHERE name = DB_NAME();

Le SQL de retrait ci-dessus inclut READCOMMITTEDLOCK et lit donc avec des verrous indépendamment du paramètre snapshot. Sur une base où le paramètre est OFF, cela correspond au comportement par défaut.¹⁰

Pourquoi ROWLOCK n’est pas listé à côté, et les limites de READPAST

Contrairement au WITH (READPAST, UPDLOCK, ROWLOCK) souvent vu, ROWLOCK n’est pas listé à côté ici. C’est parce que ROWLOCK et READCOMMITTEDLOCK appartiennent au même groupe d’indices de granularité, et les deux ne peuvent pas être spécifiés pour la même table.¹⁰

READPAST ne peut sauter que les verrous de ligne ; il ne peut pas sauter les verrous de page. Dans le cadre de cet exemple, qui prend une seule ligne via un seek d’index TOP (1), l’escalade n’est pas un souci pratique, mais si vous voulez ROWLOCK écrit explicitement, confirmez que READ_COMMITTED_SNAPSHOT est OFF puis retirez READCOMMITTEDLOCK à la place.

5.4. L’ordre de retrait et l’ordre des mises à jour des données métier sont des choses différentes

Spécifier un ordre pour les lignes candidates

Si vous ôtez le ORDER BY et écrivez UPDATE TOP (1), quelle ligne est choisie est indéfini. Le TOP d’un UPDATE n’ordonne pas les lignes qu’il touche, et le seul fait d’avoir un index sur (Status, Id) n’est pas non plus une garantie d’ordre. Pour empêcher les anciens travaux d’être reculés indéfiniment, l’exemple spécifie ORDER BY Id.¹¹

En traitement parallèle, premier sorti ne veut pas dire premier appliqué

Cela dit, l’ordre d’achèvement en traitement parallèle n’est pas aligné. Pendant que le worker A traite le travail 1, le worker B saute cette ligne via READPAST et peut valider le travail 2 en premier.

Lorsque l’ordre d’application a un sens — des mises à jour contre le même numéro de commande, par exemple — choisissez l’une des options suivantes.

Si vous ne choisissez ni l’un ni l’autre, indiquez explicitement dans la conception que le FIFO global n’est pas garanti en traitement parallèle. Le même problème apparaît avec MSMQ dès que vous recevez en parallèle. Ce qui compte, ce n’est pas de migrer en croyant encore que « c’est une file, donc ça sort dans l’ordre ».

5.5. La frontière de transaction du worker

Ce que vous alignez côté récepteur, c’est la transaction qui couvre le retrait, la mise à jour des données métier et l’enregistrement d’achèvement. Dans le pseudocode ci-dessous, les trois opérations reçoivent la même connexion et la même transaction, et sont validées ensemble à la fin.

while (!stoppingToken.IsCancellationRequested)
{
    using var tx = connection.BeginTransaction();

    var job = DequeueOne(connection, tx);          // The UPDATE ... OUTPUT above
    if (job is null)
    {
        tx.Commit();
        await Task.Delay(TimeSpan.FromSeconds(1), stoppingToken);  // Nothing there: wait one polling interval
        continue;
    }

    ApplyBusinessData(connection, tx, job);        // <- Update the business data (the work you actually wanted)
    MarkDone(connection, tx, job.Id);              // Status = 2

    tx.Commit();   // "Dequeue" and "business update" are committed together by this one line
}

Le point clé est que DequeueOne, ApplyBusinessData et MarkDone utilisent la même connexion et la même transaction, et que le Commit final valide ensemble le retrait et la mise à jour métier. Si vous remplacez ceci par un courtier, cette propriété de même base est perdue, et une autre conception de cohérence devient nécessaire.

5.6. Récupération, nouvelles tentatives et nettoyage à ajouter pour la production

Par-dessus l’exemple minimal, concevez les opérations suivantes.

Dans les systèmes métier de petite et moyenne taille, une table plus un polling, ou une variante pilotée par notification, suffit souvent. Avant d’ajouter un autre produit de file, vérifiez si cette implémentation satisfait déjà les propriétés et l’exploitation dont vous avez besoin.

6. Bascule : aligner d’abord le format, le comportement et le côté récepteur

Pour la bascule, alignez d’abord le format des messages et les tests sur les entrées et les résultats. Ensuite, choisissez entre faire le pont entre l’ancien et le nouveau et vider l’ancienne file avant de basculer.

6.1. Décider un format de message dans lequel l’ancien et le nouveau peuvent coexister

Faites de JSON le défaut après la migration. Ce que vous ne transportez pas, c’est la sérialisation basée sur BinaryFormatter telle que BinaryMessageFormatter. L’implémentation de BinaryFormatter a été retirée du runtime dans .NET 9, et elle n’est pas non plus recommandée pour des raisons de sécurité.⁸

Cela ne veut pas dire que tout format binaire est exclu, toutefois. Les formats dont la spécification est maintenue indépendamment, tels que Protocol Buffers et MessagePack, peuvent être transportés vers le nouveau système tels quels sans problème. Établissez d’abord le formateur et le type du corps, dans l’inventaire de la section 3.2.

6.2. Avant de réécrire, figer les entrées et les résultats avec des tests

Le traitement de files est un domaine où les défauts dépendants du timing s’introduisent facilement. Préparez d’avance des tests de caractérisation qui disent « ce message d’entrée produit ce résultat », afin de pouvoir vérifier mécaniquement que le remplacement produit le même résultat. Voir aussi « Modifier en toute sécurité une application métier legacy sans tests — Tests de caractérisation et refactorisation en pratique ».

6.3. Traiter d’abord le côté récepteur, et concevoir le pont autour de la perte et de la duplication

Porter d’abord le côté récepteur

D’abord provisionnez la nouvelle file, faites fonctionner le côté récepteur contre elle, et seulement ensuite basculez le côté émetteur.

Insérer un petit pont qui déplace les messages de l’ancien MSMQ vers la nouvelle file vous évite de basculer tous les émetteurs d’un coup. Le pont lui-même peut rester sur .NET Framework.

Séparer la procédure de passation selon que les transactions sont utilisées

Mais s’il s’arrête entre le retrait de MSMQ et l’écriture dans la nouvelle file, vous obtenez soit une perte, soit une double livraison. Concevez comme suit, selon le type de file source.

L’attribut transactionnel d’une file est fixé à sa création et ne peut plus être changé ensuite. Notez que la procédure de réception transactionnelle ne peut pas simplement être appliquée à une file non transactionnelle.

6.4. Si le pont n’en vaut pas la peine, vider la file et basculer

Si les mesures contre la perte et la duplication dans le pont sont hors de proportion avec la taille du système, ne forcez pas l’ancien et le nouveau à coexister ; penchez vers vider l’ancienne file pendant une interruption planifiée puis basculer.

Basculer avec des messages encore assis dans la file provoque un double traitement et une perte. Vider la file avant de basculer est, au bout du compte, souvent à la fois la voie la plus sûre et la plus rapide — c’est le jugement pratique de cet article.

7. Résumé

En juillet 2026, date de référence de cet article, MSMQ n’a pas été officiellement déprécié. Survivre en tant que fonctionnalité de l’OS et être facile à migrer vers .NET sont deux choses différentes. System.Messaging est confiné à .NET Framework, donc le principe est que si vous portez l’application vers .NET, vous revoyez la file en même temps.¹²³

Si vous continuez à l’utiliser pour l’instant, vérifiez la période de support de l’OS et mettez en place les procédures de construction et de reprise, la surveillance des files, un enregistrement de la configuration, et une revue annuelle de la décision. Le grand risque de la conservation figée n’est pas seulement technique : c’est qu’il ne reste plus personne capable d’y toucher.

Si vous migrez, faites d’abord l’inventaire des dépendances et des formats de messages. Pour un traitement asynchrone qui met à jour la même base métier, une file d’attente sur table est le premier choix. La cohérence que MSMQ plus DTC assuraient peut être remplacée par une transaction locale dans cette seule base. Envisagez RabbitMQ ou Azure Service Bus lorsqu’il existe une exigence qu’elle ne peut pas satisfaire, telle que la livraison vers plusieurs systèmes ou le routage.

Par-dessus cela, vérifiez le niveau d’isolement SQL et les indices, l’ordre d’application des mises à jour sous parallélisme, et les mesures contre la perte et la duplication dans le pont. Ce qui compte, c’est de ne pas se précipiter parce que « apparemment c’est abandonné », mais de comprendre de quoi dépend votre propre système et de décider sur cette base entre le garder et migrer.

Articles connexes

• Jusqu’à quand les applications VB6 continueront-elles de fonctionner ? — état du support du runtime et démarche concrète vers une migration .NET
• Liste de vérification avant de migrer de .NET Framework vers .NET
• Modifier en toute sécurité une application métier legacy sans tests — Tests de caractérisation et refactorisation en pratique
• Comment choisir la communication inter-processus sous Windows ── Tableau de décision : tubes nommés / TCP / gRPC / mémoire partagée / COM
• Le malentendu selon lequel TCP renvoie les données dans les mêmes unités que Send — concevoir la réception comme un flux d’octets
• Quand vous héritez d’un système sans code source ni documentation — Procédure pratique pour l’exploiter et le maintenir sans interruption
• Versionner le schéma de base de données d’une application métier — pratiques de migration pour éviter que « chaque client ait une base différente »

Domaines de conseil associés

Komura Software LLC prend en charge l’inventaire et les plans de migration des configurations héritées incluant MSMQ, la migration de .NET Framework vers .NET, et la modification de systèmes métier impliquant un traitement de files d’attente.

• Valorisation des actifs existants et accompagnement de migration
• Refonte et maintenance de logiciels Windows existants
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

MSMQ a-t-il été abandonné ?

Non. En juillet 2026, MSMQ ne figure ni sur la liste des fonctionnalités dépréciées du client Windows, ni sur la liste des « fonctionnalités supprimées ou dont le développement a cessé » de Windows Server. Il est toujours inclus dans les systèmes d'exploitation actuels en tant que fonctionnalité optionnelle de Windows. L'expression « abandonné » s'est répandue parce qu'elle est confondue avec la situation côté .NET. La bibliothèque de classes standard qui gère MSMQ, System.Messaging, n'existe que dans .NET Framework et n'a jamais été portée vers .NET (Core et versions ultérieures). Autrement dit, plus précisément : « la fonctionnalité perdure en tant que composant du système d'exploitation, mais il n'existe aucun moyen officiel de l'utiliser depuis un .NET moderne ».

Existe-t-il un moyen d'utiliser MSMQ depuis .NET 8 ou .NET 10 ?

Il n'existe aucune API managée officielle. System.Messaging est une API qui s'arrête à .NET Framework 4.8.1 et n'est pas non plus incluse dans le pack de compatibilité Windows (Microsoft.Windows.Compatibility). Il est techniquement possible d'appeler l'API Win32 native de MSMQ (MQSendMessage, etc.) via P/Invoke, mais cela revient à devoir écrire et maintenir soi-même un wrapper incluant les formateurs et l'intégration transactionnelle. Du côté communautaire, le projet CoreWCF publie un paquet pour le transport MSMQ (CoreWCF.MSMQ), mais celui-ci sert à héberger sur un .NET moderne des services WCF appelés via une file d'attente (le portage du côté serveur de WCF) ; ce n'est ni une API de file d'attente générique se substituant à System.Messaging, ni un remplacement pour le client émetteur. Son implémentation dépend elle-même d'un portage communautaire de System.Messaging pour .NET Framework. Cela peut constituer une option de validation ou de sursis provisoire. CoreWCF lui-même dispose d'une politique de support officielle de Microsoft, mais cette garantie ne s'étend pas nécessairement au portage communautaire de System.Messaging dont dépend cette implémentation MSMQ ; si vous envisagez de fonder un système métier sur cette base, vérifiez d'abord si la version que vous utilisez est couverte par la politique de support, ainsi que le traitement réservé à cette dépendance, avant de trancher. En pratique, la bonne approche consiste à migrer la file d'attente en même temps que l'application vers .NET.

Faut-il choisir RabbitMQ ou Azure Service Bus comme cible de migration ?

Avant ce choix binaire, envisagez d'abord de transformer une table de base de données en file d'attente. La plupart des systèmes métier de petite ou moyenne taille utilisant MSMQ ont, comme interlocuteur de la file d'attente, un traitement qui met à jour leur propre base de données. Dans ce cas, une file d'attente basée sur une table permet de valider « le retrait du message » et « la mise à jour des données métier » dans la même transaction locale que les données métier, remplaçant par un mécanisme plus simple la cohérence qu'assuraient MSMQ et les transactions distribuées (DTC). Si la file d'attente sur table ne suffit pas à des besoins comme une diffusion faiblement couplée entre plusieurs systèmes ou un débit élevé, envisagez alors RabbitMQ si les contraintes sur site sont fortes, ou Azure Service Bus si le cloud est possible — cet ordre limite le risque d'échec.

Est-il acceptable de rester pour l'instant sur .NET Framework, en « conservation figée » ?

C'est acceptable, sous conditions. .NET Framework 4.8 est pris en charge comme composant de Windows, suivant le cycle de vie du système d'exploitation, et MSMQ lui-même n'est pas déprécié, si bien qu'on peut raisonnablement prévoir qu'il « continuera de fonctionner ». Cependant, si vous choisissez la conservation figée, faites au minimum ces quatre choses : indiquer explicitement l'activation de la fonctionnalité MSMQ dans la procédure de préparation des postes, mettre en place une surveillance de la longueur des files et des journaux, documenter le format des messages et la configuration des connexions, et conserver une procédure de reprise en cas de changement de personnel responsable. Le vrai risque de la conservation figée n'est pas technique : c'est qu'il ne reste plus personne capable d'y toucher.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.