Présentation de la conversion de contenu

  • Article

 

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2016-11-28

La conversion de contenu est le processus consistant à mettre en forme un message correctement pour chaque destinataire. La décision d'exécuter une conversion de contenu sur un message dépend de la destination et du format du message en cours de traitement. Les messages envoyés à des destinataires à l’intérieur de l’organisation Microsoft Exchange Server ne nécessitent pas de conversion de contenu. Seuls les messages envoyés à des destinataires externes peuvent nécessiter une conversion de contenu.

Dans une organisation Exchange Server 2010, la conversion de contenu est effectuée par le catégoriseur sur un serveur sur lequel le rôle serveur de transport Hub est installé. Une catégorisation de chaque message intervient après qu’un nouveau message a été placé dans la file d’attente de soumission. En plus de la résolution des destinataires et de la résolution du routage, une conversion de contenu est appliquée au message avant son placement dans la file d'attente de remise. Si un seul message contient plusieurs destinataires, la conversion de contenu détermine le codage approprié pour chaque destinataire. Sur un serveur de transport Edge, une catégorisation simplifiée a lieu et n'implique aucune conversion de contenu.

Contenu de cette rubrique

Présentation de la structure des messages électroniques

Formats Exchange 2010 et Outlook Message

Éléments de conversion de contenu

Conversion de contenu effectuée par le pilote de banque d'informations

Souhaitez-vous rechercher les tâches de gestion liées à la conversion de contenu ? Voir Gestion des serveurs de transport.

Présentation de la structure des messages électroniques

Pour mieux comprendre la conversion de contenu, vous devez comprendre la structure des messages électroniques. Le protocole SMTP est basé sur du texte brut US-ASCII 7 bits pour la composition et l'envoi de messages électroniques. Un message SMTP standard comprend les éléments suivants :

  • Enveloppe du message   L'enveloppe du message est définie en RFC 2821. Elle contient les informations requises pour transmettre et remettre le message. Les destinataires ne voient jamais l'enveloppe du message, car elle est générée par le processus de transmission du message et ne fait pas partie du contenu du message.

  • Contenu du message   Le contenu du message est défini en RFC 2822. Il comprend les éléments suivants :

    • En-tête du message   L'en-tête du message est un ensemble de champs d'en-tête. Les champs d'en-tête se composent d'un champ name, suivi du caractère deux-points ( : ), suivi d'un champ body, puis d'une combinaison de caractères de retour chariot/retour à la ligne (CR/LF).

      Un champ name doit être composé de caractères de texte US-ASCII imprimables, à l'exception du caractère deux-points ( : ). Plus précisément, les caractères ASCII autorisés doivent avoir des valeurs comprises entre 33 et 57 et entre 59 et 126.

      Un champ body peut contenir tout caractère US-ASCII, à l'exception du caractère de retour chariot (CR) et du caractère de retour à la ligne (LF). Toutefois, un champ body peut contenir la combinaison de caractères CR/LF si elle est utilisée pour le pliaged'en-tête. Le pliage d'en-tête est la séparation d'un champ body d'en-tête en plusieurs lignes conformément à la description de la section 2.2.3 de la norme RFC 2822. D'autres exigences de syntaxe concernant le champ body sont décrites dans les sections 3 et 4 de la norme RFC 2822.

    • Corps du message   Le corps du message est un ensemble de lignes de caractères de texte US-ASCII qui s'affichent après l'en-tête du message. L'en-tête du message et le corps du message sont séparés par une ligne vide qui se termine par la combinaison de caractères CR/LF. Le corps du message est facultatif. Une ligne de texte dans le corps du message doit compter moins de 998 caractères. Les caractères CR et LF ne peuvent apparaître ensemble que pour indiquer la fin d'une ligne.

Si des messages SMTP contiennent des éléments qui ne sont pas du texte brut US-ASCII, il faut coder le message pour préserver ces éléments. La norme MIME définit une méthode de codage du contenu non-texte des messages. MIME autorise du texte dans d'autres jeux de caractères, des pièces jointes sans texte, des corps de message en plusieurs parties et des champs d'en-tête dans d'autres jeux de caractères. MIME est défini dans les normes RFC 2045, RFC 2046, RFC 2047, RFC 2048 et RFC 2077. MIME définit un ensemble de champs d'en-tête qui spécifient des attributs de message supplémentaires. Le tableau suivant décrit certains champs d'en-tête MIME importants.

Champ d'en-tête MIME importants

Nom de champ d'en-tête Valeur par défaut Description

Version MIME

1.0

Ce champ d'en-tête et les premier champ d'en-tête MIME apparaissant dans un message au format MIME. Ce champ d'en-tête apparaît après les autres champs d'en-tête RFC 2822 standard mais avant tout autre champ d'en-tête MIME. Les clients de messagerie compatibles MIME utilisent ce champ d'en-tête pour identifier un message codé MIME. Lorsque ce champ d'en-tête est absent, les clients de messagerie compatibles MIME identifient le message comme étant en texte brut.

Content-Type

text/plain

Ce champ d'en-tête identifie le type de média du contenu du message, comme décrit dans la norme RFC 2046. Un type de média consiste en un type, un sous-type et un ou plusieurs paramètres facultatifs, tel qu'un paramètre charset= définissant le codage de caractères MIME. Les types commençant par « x- » ne sont pas standard. Les sous-types commençant par « vnd. » sont spécifiques au fournisseur. L'IANA (Internet Assigned Numbers Authority) conserve une liste des types de médias enregistrés. Pour plus d'informations, consultez la page Web présentant les types de médias MIME.

Le type de média multipart permet de composer un message contenant plusieurs parties en utilisant des sections définies par différents types de médias. text/plain, text/html, multipart/mixed et multipart/alternative sont certaines des valeurs du champ Content-Type.

Content-Transfer-Encoding

7bit

Ce champ d'en-tête peut décrire les informations suivantes sur un message :

  • l'algorithme de codage utilisé pour transformer toute donnée texte ou binaire non-US-ASCII existant dans le corps du message ;

  • un indicateur décrivant la condition actuelle du corps du message.

Le champ d'en-tête Content-Transfer-Encoding d'un message MIME peut prendre plusieurs valeurs. Lorsqu'il apparaît dans l'en-tête du message, il s'applique à l'ensemble du corps du message. Lorsqu'il apparaît dans une des parties d'un message multipart, il ne s'applique qu'à cette partie du message.

Quand un algorithme de codage est appliqué aux données du corps du message, celles-ci sont transformées en texte brut US-ASCII. Cette transformation permet au message de transiter sur des serveurs de messagerie SMTP plus anciens qui ne prennent en charge que les messages en texte US-ASCII. Les valeurs du champ d'en-tête Content-Transfer-Encoding indiquant qu'un algorithme de codage a été utilisé pour le corps du message sont les suivantes :

  • Quoted-printable   Cet algorithme de codage utilise des caractères US-ASCII imprimables pour coder les données du corps du message. Si le texte du message d'origine est essentiellement du texte US-ASCII, le codage Quoted-printable fournit des résultats relativement lisibles et compacts. Tous les caractères de texte US-ASCII imprimables à l'exception du signe égal (=) peuvent être représentés sans codage.

  • Base64   Cet algorithme de codage est principalement basé sur le standard Privacy-Enhanced Mail (PEM) défini dans la norme RFC 1421. Le codage Base64 utilise l'algorithme de codage alphabétique de 64 caractères alphabet et les caractères de remplissage de sortie définis par PEM pour coder les données du corps du message. Un message codé Base64 est généralement 33 pour cent plus volumineux que le message d'origine. Le codage Base64 crée un accroissement prévisible de la taille du message et convient parfaitement pour des données binaires et du texte non-US-ASCII.

Il est rare que plusieurs algorithmes de codage soient utilisés dans le même message.

Si aucun algorithme de codage n'est utilisé dans le corps du message, le champ d'en-tête Content-Transfer-Encoding identifie simplement la condition actuelle des données du corps du message. Les valeurs du champ d'en-tête Content-Transfer-Encoding indiquant qu'aucun algorithme de codage n\a été utilisé pour le corps du message sont les suivantes :

  • 7bit    Cette valeur indique que les données du corps du message sont déjà au format RFC 2822. Plus précisément, cela signifie que les conditions suivantes doivent être remplies :

    • Les lignes de texte doivent compter moins de 998 caractères.

    • Tous les caractères doivent être des caractères de texte US-ASCII de la plage de valeurs 1 à 127.

    • Les caractères CR et LF ne peuvent apparaître ensemble que pour indiquer la fin d'une ligne de texte.

    Le corps du message tout entier peut être 7bit ou, s'il s'agit d'un message de type multipart, seule une partie du message peut être 7bit. Si le message multipart contient d'autres parties comprenant des données binaires ou du texte non-US-ASCII, cette partie du message doit être codée à l'aide des algorithmes de codage Quoted-printable ou Base64.

    Des messages ayant un corps 7bit peuvent voyager entre des serveurs de messagerie SMTP grâce à la commande DATA standard.

  • 8bit    Cette valeur indique que les données du corps du message contiennent des caractères non-US-ASCII. Plus précisément, cela signifie que les conditions suivantes doivent être remplies :

    • Les lignes de texte doivent compter moins de 998 caractères.

    • Un ou plusieurs caractères du corps du message ont des valeurs supérieures aux valeurs US-ASCII 127.

    • Les caractères CR et LF ne peuvent apparaître ensemble que pour indiquer la fin d'une ligne de texte.

    Le corps du message tout entier peut être 8bit ou, s'il s'agit d'un message de type multipart, seule une partie du message peut être 8bit. Si le message multipart contient d'autres parties comprenant des données binaires, cette partie du message doit être codée à l'aide des algorithmes de codage Quoted-printable ou Base64.

    Les messages dont le corps est en 8bit ne peuvent voyager qu'entre des serveurs de messagerie SMTP qui prennent en charge l'extension SMTP 8BITMIME définie dans la norme RFC 1652, tels que des serveurs exécutant Exchange 2010, Exchange Server 2007, Exchange Server 2003 ou Exchange 2000 Server. Plus précisément, cela signifie que les conditions suivantes doivent être remplies :

    • Le mot clé 8BITMIME doit être annoncé dans la réponse EHLO du serveur.

    • Les messages sont malgré tout transférés à l'aide de la commande DATA standard du protocole SMTP. Toutefois, le paramètre BODY=8BITMIME doit être ajouté à la fin de la commande MAIL FROM.

  • Binary    Cette valeur indique que les données du corps du message contiennent du texte non-US-ASCII ou des données binaires. Plus précisément, cela signifie que les conditions suivantes sont remplies :

    • Toute séquence de caractères est autorisée.

    • Il n'existe aucune limitation à la longueur de ligne.

    • Les éléments de message binaires ne nécessitent pas de codage.

    Les messages dont le corps est en Binaire ne peuvent voyager qu'entre des serveurs de messagerie SMTP qui prennent en charge l'extension SMTP BINARYMIME définie dans la norme RFC 3030, tels que des serveurs exécutant Exchange 2010, Exchange 2007, Exchange 2003 ou Exchange 2000. Plus précisément, cela signifie que les conditions suivantes doivent être remplies :

    • Le mot clé BINARYMIME doit être annoncé dans la réponse EHLO du serveur.

    • L'extension SMTP BINARYMIME ne peut être utilisée qu'avec l'extension SMTP CHUNKING. Chunking permet d'envoyer des corps de message volumineux en plusieurs blocs de plus petite taille. L'extension Chunking est également définie dans la norme RFC 3030. Le mot clé CHUNKING doit également être annoncé dans la réponse EHLO du serveur.

    • Les messages sont transférés à l'aide de la commande BDAT au lieu de la commande DATA standard.

    • Le paramètre BODY=BINARYMIME doit être ajouté à la fin de la commande MAIL FROM si le message contient un corps de message.

Les valeurs 7bit, 8bit et Binary ne coexistent jamais dans un message multipart. Ces valeurs s'excluent mutuellement. Les valeurs Quoted-printable ou Base64 peuvent apparaître dans un corps de message multipart 7bit ou 8bit, mais jamais dans un corps de message Binary. Si un corps de message multipart contient plusieurs parties composées de contenu 7bit et 8bit, le message entier est classifié 8bit. Si un corps de message multipart contient plusieurs parties composées de contenu 7bit, 8bit et Binary, le message entier est classifié Binary.

Content-Disposition

Pièce jointe

Ce champ d'en-tête indique à un client de messagerie compatible MIME la manière d'afficher un fichier joint ; il est décrit dans la norme RFC 2183. Les valeurs de ce champ peuvent être Inline ou Attachment. Si la valeur de ce champ est Inline, la pièce jointe s'affiche dans le corps du message. Si la valeur de ce champ est Attachment, le fichier joint s'affiche comme pièce jointe ordinaire séparée du corps du message. D'autres paramètres sont disponibles si la valeur est Attachment, tels que Filename, Creation-date et Size.

Formats Exchange 2010 et Outlook Message

La liste suivante répertorie les formats de message de base disponibles dans Exchange 2010 et Microsoft Outlook :

  • Texte brut   Un message en texte brut contient uniquement du texte US-ASCII, comme décrit dans la norme RFC 2822. Le message ne peut pas contenir des polices différentes ni de mise en forme du texte. Les deux formats suivants peuvent être utilisés pour un message en texte brut :

    • Les en-têtes et le corps du message sont composés de texte US-ASCII. Les pièces jointes doivent être codées à l'aide de l'algorithme Uuencode. Uuencode est une abréviation de Unix-to-Unix encoding qui définit un algorithme de codage pour le stockage de pièces jointes binaires dans le corps d'un message électronique à l'aide de caractères de texte US-ASCII.

    • Le message est codé MIME avec une valeur Content-Type de text/plain et une valeur Content-Transfer-Encoding de 7bit pour les parties texte d'un message multipart. Toute pièce jointe d'un message est codée à l'aide d'un codage Quoted-printable ou Base64. Par défaut, lorsque vous composez et envoyez un message en texte brut dans Outlook, le message est codé MIME à l'aide d'une valeur Content-Type de text/plain.

  • HTML   Un message HTML prend en charge la mise en forme de texte, les images d'arrière-plan, les tableaux, les listes à puces et d'autres éléments graphiques. Par définition, un message au format HTML doit être codé MIME pour conserver ces éléments de mise en forme.

  • Rich text format (RTF)   RTF prend en charge la mise en forme de texte et d'autres éléments graphiques. RTF est synonyme de TNEF (Transport Neutral Encapsulation Format). Les formats TNEF et RTF peuvent être utilisés de façon interchangeable.

    Seul Outlook et quelques autres clients de messagerie MAPI comprennent les messages RTF. MAPI est une architecture de messagerie développée par Microsoft qui permet l’interaction de plusieurs applications avec différents systèmes de messagerie et ce, sur un large éventail de plateformes matérielles. MAPI est basé sur l’architecture COM (Component Object Model). Outlook l’utilise pour communiquer avec des boîtes aux lettres sur un ordinateur exécutant Exchange 2010, sur lequel le rôle serveur de boîtes aux lettres est installé.

    Le format de texte enrichi est totalement différent du format RTF disponible dans Microsoft Word.

  • TNEF   TNEF est un format spécifique à Microsoft pour l'encapsulation de propriétés de message MAPI. Un message TNEF contient une version du message en texte brut et une pièce jointe qui contient la version mise en forme d’origine du message. Généralement, cette pièce jointe est nommée Winmail.dat. La pièce jointe Winmail.dat inclut les informations suivantes :

    • version mise en forme d'origine du message incluant, par exemple, les polices, les tailles et les couleurs de texte ;

    • objets OLE incluant, par exemple, des images ou des documents Microsoft Office imbriqués ;

    • fonctionnalités Outlook spéciales incluant, par exemple, des écrans personnalisés, des boutons de vote ou des demandes de réunion ;

    • pièces jointes au message d'origine.

    Le message en texte brut obtenu peut être représenté dans les formats suivants :

    • message conforme à la norme RFC 2822 composé uniquement de texte US-ASCII avec une pièce jointe Winmail.dat codée en Uuencode ;

    • message multipart codé MIME contenant une pièce jointe Winmail.dat.

    Un client de messagerie compatible MAPI qui comprend totalement le format TNEF, tel que Outlook, traite la pièce jointe Winmail.dat et affiche le contenu du message d'origine sans jamais afficher la pièce jointe Winmail.dat. Un client de messagerie ne comprenant pas le format TNEF peut présenter un message TNEF de l'une des manières suivantes :

    • La version en texte brut du message s'affiche et le message contient une pièce jointe nommée Winmail.dat, Win.dat ou à l'aide d'un autre nom générique tel que Attnnnnn.dat ou Attnnnnn.eml où l'espace réservé nnnnn représente un numéro aléatoire.

    • La version en texte brut du message s'affiche. La pièce jointe TNEF est ignorée ou supprimée. Le résultat est un message en texte brut.

    • Les serveurs de messagerie qui comprennent le format TNEF peuvent être configurés pour supprimer les pièces jointes TNEF des messages entrants. Le résultat est un message en texte brut. En outre, certains clients de messagerie tels que Microsoft Outlook Express peuvent ne pas comprendre le format TNEF mais reconnaître et ignorer les pièces jointes TNEF. Le résultat est un message en texte brut.

    Certains utilitaires tiers peuvent aider à convertir des pièces jointes Winmail.dat.

    Le format TNEF est compris par Exchange 2010, Exchange 2007, Exchange 2003, Exchange 2000 et Exchange Server version 5.5. Les messages TNEF sont transférés entre des serveurs de messagerie SMTP à l’aide du verbe de commande DATA standard. Le format TNEF est automatiquement utilisé par Exchange dans les situations suivantes :

    • Exchange 2003   Si l'organisation Exchange est en mode mixte, le format TNEF est utilisé pour les messages transférés entre des serveurs Exchange qui se trouvent dans des groupes de routage différents.

    • Exchange 2000   Le format TNEF est utilisé pour les messages transférés entre des serveurs Exchange qui se trouvent dans des groupes de routage différents.

  • STNEF (Summary Transport Neutral Encapsulation Format)   STNEF équivaut à TNEF. Toutefois, les messages STNEF sont codés différemment des messages TNEF. Plus précisément, les messages STNEF sont toujours codés MIME et ont toujours une valeur Content-Transfer-Encoding de Binary. C'est pourquoi il n'y a pas de représentation en texte brut du message ni de pièce jointe Winmail.dat distincte contenue dans le corps du message. Le message entier est représenté uniquement à l'aide de données binaires. Les messages qui ont une valeur Content-Transfer-Encoding de Binary ne peuvent être transférés qu'entre des serveurs de messagerie SMTP qui prennent en charge et annoncent les extensions BINARYMIME et CHUNKING SMTP définies dans la norme RFC 3030. Les messages sont toujours transférés entre messageries SMTP à l'aide de la commande BDAT au lieu de la commande DATA standard.

    Le format STNEF est compris par Exchange 2010, Exchange 2007, Exchange 2003 et Exchange 2000. Le format STNEF est automatiquement utilisé par Exchange si les conditions suivantes sont remplies :

    • Exchange 2010   Le format STNEF est utilisé pour tous les messages transférés entre des serveurs Exchange au sein de l'organisation.

    • Exchange 2007   Le format STNEF est utilisé pour tous les messages transférés entre des serveurs Exchange au sein de l'organisation.

    • Exchange 2003   Si l'organisation Exchange est en mode natif, le format STNEF est utilisé pour tous les messages transférés entre des serveurs Exchange au sein de l'organisation.

    • Exchange 2000   Le format TNEF est utilisé pour les messages transférés entre des serveurs Exchange qui se trouvent dans le même groupe de routage. Un correctif non pris en charge permet également à Exchange 2000 d'utiliser le format STNEF pour des messages transférés entre des serveurs Exchange dans différents groupes de routage.

    Exchange n'envoie jamais de message au format STNEF à des destinataires externes. Seuls des messages TNEF peuvent être envoyés à des destinataires en dehors de l'organisation Exchange.

Éléments de conversion de contenu

La conversion de contenu est l'acte consistant à mettre en forme un message correctement pour chaque destinataire externe. Cette conversion est effectuée par le catégoriseur sur un serveur de transport Hub.

Les options de conversion de contenu configurables dans une organisation Exchange sont décrites dans les catégories suivantes :

  • Options de conversion TNEF   Ces options de conversion indiquent si le format TNEF (Transport Neutral Encapsulation Format) doit être préservé ou supprimé des messages sortants de l’organisation Exchange.

  • Options de codage des messages   Ces options spécifient les options de codage des messages, telles que les jeux de caractères MIME et non-MIME, le codage des messages et les formats des pièces jointes.

Ces options de conversion et de codage sont indépendantes l'une de l'autre. Par exemple, le fait que des messages TNEF puissent quitter l'organisation Exchange n'est pas lié aux paramètres de codage MIME ou de texte brut de ces messages.

Vous pouvez spécifier la conversion de contenu à divers niveaux de l'organisation Exchange, tels que décrits dans la liste suivante :

  • Paramètres de domaine distant   Les domaines distants permettent de définir des paramètres de transfert des messages sortants entre l’organisation Exchange 2010 et des domaines situés hors de la forêt Active Directory. Même si vous ne créez pas d'entrée de domaine distant pour des domaines spécifiques, il existe un domaine distant prédéfini, nommé Default, qui s'applique à tous les espaces d'adressage distants ( * ).

  • Paramètres d'utilisateur et de contact de messagerie   Les utilisateurs de messagerie ressemblent à des contacts de messagerie ; ils ont des adresses de messagerie externes et contiennent des informations sur des personnes externes à l'organisation Exchange. La principale différence est que les utilisateurs de messagerie ont des contextes de sécurité utilisables pour se connecter au domaine Active Directory et accéder à des ressources auxquelles ils sont autorisés à accéder.

  • Paramètres Outlook   Outlook vous permet de définir les options de mise en forme et de codage des message décrites dans la liste suivante :

    • Format des messages   Permet de définir le format de message par défaut pour tous les messages. Vous pouvez également remplacer le format de message par défaut à mesure que vous composez un message spécifique.

    • Format des messages Internet   Permet de contrôler si des messages de format TNEF sont envoyés à des destinataires distants ou s'ils sont d'abord convertis en un format plus compatible. Vous pouvez également spécifier diverses options de codage pour les messages envoyés à des destinataires distants. Ces paramètres ne s'appliquent pas aux messages envoyés à des destinataires au sein de l'organisation Exchange.

    • Format de message de destinataire Internet   Permet de contrôler si des messages de format TNEF sont envoyés à des destinataires spécifiques ou s'ils sont d'abord convertis en un format plus compatible. Vous pouvez définir les options de conversion pour des contacts spécifiques dans le dossier Contacts ainsi que remplacer des options de conversion pour un destinataire spécifique dans les champs À :, Cc et Cci : Ces options de conversion ne sont pas disponibles pour des destinataires de l'organisation Exchange.

    • Options de codage de message de destinataire Internet   Permet de contrôler les options de codage MIME ou de texte brut pour des contacts spécifiques dans votre dossier Contacts ; vous pouvez également remplacer les options de conversion pour un destinataire spécifique dans les champs À :, Cc et Cci lorsque vous composez un message. Ces options de conversion ne sont pas disponibles pour des destinataires de l'organisation Exchange.

    • Options internationales   Vous pouvez contrôler les jeux de caractères utilisés dans les messages.

Options de conversion TNEF

Vous pouvez spécifier les options de conversion TNEF aux niveaux suivants :

  • paramètres de domaine distant ;

  • paramètres d’utilisateur et de contact de messagerie ;

  • paramètres d'Outlook, y compris :

    • format des messages ;

    • format de message Internet ;

    • format de message de destinataire Internet ;

Pour plus d'informations, consultez Options de conversion TNEF.

Options de codage de message

Vous pouvez spécifier les options de message aux niveaux suivants :

  • Paramètres de domaine distant

  • paramètres d’utilisateur et de contact de messagerie ;

  • paramètres d’Outlook, y compris :

    • format des messages ;

    • message Internet ;

    • format de message de destinataire Internet ;

    • options de codage de jeu de caractères de message.

Pour plus d'informations, consultez Options de codage des messages.

Conversion de contenu effectuée par le pilote de banque d'informations

Le pilote de banque d'informations effectue également la conversion de contenu. Le pilote de banque d'informations sur les serveurs de transport Hub est utilisé pour le transport de messages entres des serveurs de boîtes aux lettres et la file d'attente de soumission. Plus précisément, il transporte des messages de la boîte d'envoi de l'expéditeur vers la file d'attente de soumission sur le serveur de transport Hub, et il transporte les messages de la file d'attente de soumission sur le serveur de transport Hub vers la boîte de réception du destinataire. Le pilote de banque d'informations convertit tous les messages sortants de MAPI ainsi que tous les messages entrants dans MAPI. Le suivi de conversion de contenu capture ces erreurs de conversion du pilote de banque d'informations.

Pour plus d'informations, consultez la rubrique Suivi de la conversion de contenu.

 © 2010 Microsoft Corporation. Tous droits réservés.