Brevet FR2949883A1 — publié le 20110311

La présente invention concerne un procédé de codage d'un document structuré composé d'événements à coder présentant des valeurs et un procédé de décodage associé. L'invention concerne également des dispositifs de codage et de décodage correspondants. Une application particulière, non exclusive, de la présente invention est l'encodage d'un fichier XML (acronyme de "eXtensible Markup Language" pour langage de balisage extensible) en un fichier Binaire conforme par exemple à la recommandation EXI ("Efficient XML Interchange"). Le format XML est une syntaxe pour définir des langages informatiques, ce qui permet de créer des langages adaptés à des utilisations 15 différentes pouvant cependant être traités par de mêmes outils. Un document XML est composé d'éléments, chaque élément étant délimité par une balise ouvrante comportant le nom de l'élément (par exemple: ) et une balise fermante comportant elle aussi le nom de l'élément (par exemple: ). Chaque élément peut contenir d'autres éléments de façon 20 hiérarchique ou des données textuelles définissant un contenu. Un élément peut également être précisé par des attributs, chaque attribut étant défini par un nom et ayant une valeur. Les attributs sont alors placés dans la balise ouvrante de l'élément qu'ils précisent (par exemple: ). 25 La syntaxe XML permet aussi de définir des commentaires (par exemple: � �) et des instructions de traitement, qui peuvent préciser à une application informatique quels traitements appliquer au document XML (par exemple : � �). Plusieurs langages différents basés sur le langage XML peuvent 30 contenir des éléments de même nom. Pour pouvoir mélanger plusieurs langages différents, un ajout a été effectué à la syntaxe XML permettant de définir des espaces de nommage ("Namespace" selon la terminologie anglo- saxonne). Deux éléments sont identiques seulement s'ils ont le même nom et se trouvent dans le même espace de nommage. Un espace de nommage est défini par une URI (acronyme de "Uniform Resource Identifier", pour Identifiant uniforme de ressource), par exemple � http://canon.crf.fr/xml/monlangage �. L'utilisation d'un espace de nommage dans un document XML passe par la définition d'un préfixe qui est un raccourci vers l'URI de cet espace de nommage. Ce préfixe est défini à l'aide d'un attribut spécifique (par exemple: � xmins:ml="http://canon.crf.fr/xml/monlangage" � associe le préfixe � ml � à l'URI � http://canon.crf.fr/xml/monlangage �). Ensuite, l'espace de nommage d'un élément ou d'un attribut est précisé en faisant précéder son nom par le préfixe associé à l'espace de nommage suivi de � : � (par exemple: � � indique que l'élément "balise" découle de l'espace de nommage ml et qu'il en est de même pour l'attribut "attribut"). Ces éléments identifiant un élément ou un attribut précis sont appelés "nom qualifié" ("qualified name" selon la terminologie anglo-saxonne, ou "qname" selon la recommandation EXI). Ainsi, un nom qualifié regroupe le nom local de l'événement/attribut (par exemple "balise"), éventuellement une URI (par exemple � xmins:ml="http://canon.crf.fr/xml/monlangage" �) et éventuellement un préfixe (par exemple "mi'). Il s'agit donc d'un nom identifiant de façon unique un type d'événement XML structurel. Dans la terminologie XML, l'ensemble des termes "élément", "attribut", "donnée textuelle", "commentaire", "instruction de traitement" et "section d'échappement" sont regroupés sous le nom générique de "item". A l'intérieur de ces données ou items XML, on distingue généralement deux parties: d'un côté, la structure définissant un type d'item et correspondant par exemple au nom d'un attribut, et de l'autre côté, le contenu de l'item correspondant par exemple à la valeur prise par cet attribut. De façon similaire, pour un élément contenant des données textuelles (par exemple exemple ), les événements XML "début d'élément" ( ) et "fin d'élément" ( ) sont des données de structure, tandis que les données textuelles (ici "exemple") sont des données de contenu. Comme montré dans ce dernier exemple, les items XML peuvent être décrits en termes d'événements, également appelés événements XML. Ainsi, il existe des événements XML relatifs uniquement à la structure du document qui précisent le type d'item, comme par exemple les balises "début d'élément" et "fin d'élément" ou les balises de commentaire ou d'instruction de traitement, et il existe des événements XML comprenant du contenu, par exemple les attributs ou les données textuelles que prennent respectivement les éléments, les commentaires, etc. Pour les besoins d'illustration ci-après, on utilisera les notations suivantes des informations de structure d'événements XML: - SE : événement début de balise; - EE : événement fin de balise; - ATTR : événement attribut; - CH : événement texte. Pour traiter un document XML, ce dernier doit être lu en mémoire. La notion d'événements XML permet notamment la lecture du document suivant l'ordre de ce dernier, par des interfaces de programmation type SAX ("Simple API for XML" signifiant "Interface de programmation simple pour XML") et StAX ("Streaming API for XML" signifiant "Interface de programmation au fur et à mesure pour XML"). En effet, le document XML peut alors être décrit comme une succession d'événements XML. Cette méthode permet notamment de traiter un document XML au fur et à mesure de sa lecture (mode "streaming" en anglais) et requiert donc peu d'espace mémoire. La présente invention telle qu'exposée ci-après s'applique notamment aux traitements en mode streaming (traitement à la volée) de documents XML. Un tel traitement consiste par exemple en une demande d'impression, par laquelle une imprimante reçoit un document à imprimer, par exemple un document SVG ("Scalable Vector Graphics") selon le mode SVG Printing Profile. Ce document contient un certain nombre de pages que l'imprimante va imprimer page après page. Le traitement de visualisation/impression est effectué en mode streaming, en ce qu'il n'est pas besoin de garder en mémoire la première page pour imprimer la deuxième. Malgré de nombreux avantages pour stocker des données dans un fichier ou pour échanger des données, la syntaxe XML présente un principal inconvénient qui est d'être très prolixe. Ainsi la taille d'un document XML peut être plusieurs fois supérieure à la taille intrinsèque des données. Cette taille importante des documents XML induit aussi des temps de traitement importants lors de la génération et surtout de la lecture de documents XML. Bien que l'invention s'applique à tout type de document au format XML, c'est notamment le cas des formats de documents XML tels que SVG, Open Office, Open Document Format ou PDFXML qui proposent généralement une organisation des documents en section ou page et sont généralement très volumineux. Le format SVG est un format basé XML de données conçu pour décrire des ensembles de graphiques vectoriels. Les graphiques sont définis par exemple par des commandes basiques telles que des cercles, des rectangles, des lignes, mais également, au travers d'un outil spécifique, à savoir un chemin SVG, pour des formes plus complexes. L'élément XML correspondant à ces dernières est noté , où l'attribut 'd' décompose le forme complexe en une suite de lettres et de paramètres indiquant une suite de portions élémentaires de la forme. Dans le cadre des documents SVG, cet attribut représente une partie conséquente des données, car les chemins sont généralement complexes et regroupent un grand nombre de lettres (les graphiques élémentaires constitutifs de la forme) et de paramètres associés (des coordonnées, des rayons, des longueurs, etc.) Les formats Open Office et Open Document Format sont des formats basés XML conçus pour stocker des documents de bureautique (document de traitement de texte, document de présentation ou document tableur). Dans ces formats, les données volumineuses sont constituées des données textuelles de l'élément 't'. Le format PDFXML est un format basé XML de description de pages qui permet de préserver la mise en forme du document original. Au regard de la volumétrie des données formant ces documents, il est intéressant de les compresser par codage pour obtenir des documents de taille plus raisonnable. Ainsi, des mécanismes pour coder le contenu du document XML 5 sous une forme compressée ont été mis en place. C'est notamment le cas des formats XML Binaire tels que les formats EXI et Fast Infoset, qui prennent en compte d'un côté les informations structurelles du document XML, et de l'autre côté les informations de valeur/contenu. 10 Par exemple, le format EXI s'appuie sur l'utilisation de grammaires pour décrire la structure des données XML, et sur l'utilisation de tables de valeurs, évolutives au fur et à mesure du codage/décodage, pour décrire leur contenu. Les grammaires décrivent la structure des données XML à partir de 15 la connaissance d'un schéma ou via un apprentissage durant le processus d'encodage ou de décodage. Ces grammaires permettent de traduire les informations de structure en codes (dits codes de priorités), les codes les plus courts servant à encoder les informations de structures considérées comme les plus probables. 20 Les tables de valeurs permettent d'indexer les valeurs des évènements. Ainsi une valeur se présentant plusieurs fois dans un document est encodée sous sa forme littérale (encodage sous la forme d'une suite de caractères) à la première occurrence puis sous sa forme indexée les fois suivantes (encodage sous la forme d'un index dans la table). 25 Le codage classique EXI est réalisé au fur et à mesure du parcours du document XML à coder. Ainsi, traditionnellement, les informations codées de structure et de valeurs sont entrelacées selon leur ordre d'apparition dans le document XML d'origine. Afin d'améliorer encore la compression, deux modes du codage EXI 30 proposant une autre organisation de ces informations codées à l'intérieur du flux EXI généré ont été mis en place: un mode dit de "pré-compression" et un mode dit de "compression", se distinguant l'un de l'autre par la simple mise en oeuvre supplémentaire d'un algorithme final de compression, par exemple de type DEFLATE, pour le mode "compression". Dans ces modes spécifiques, les événements XML sont regroupés en blocs de taille fixe et paramétrable, la taille du bloc définissant le nombre de valeurs d'événements, généralement les valeurs d'attributs (ATTR) et les valeurs de chaînes de caractères (CH), à l'intérieur du bloc. Le codage EXI d'un document est alors opéré bloc par bloc, en séparant à l'intérieur de ceux-ci les informations de structure et les informations de valeurs d'événement. Les valeurs de codage des informations de structure (c'est-à-dire les codes de priorités) avec leur contenu associé à l'exception des valeurs des événements sont regroupées sous la forme d'un canal de structure. Ce canal de structure conserve l'ordre et l'organisation générale de la structure du document XML. Les valeurs des événements d'un bloc sont, quant à elles, regroupées sous forme de plusieurs canaux de valeurs en conservant, à l'intérieur d'un canal de valeurs, l'ordre des valeurs dans le document XML. La valeur d'un événement est notamment placée dans le canal de valeurs identifié par le nom qualifié qname de l'événement en question ou de l'événement parent lorsqu'il s'agit d'une valeur de chaîne de caractères (CH). Les canaux de valeurs sont ensuite ordonnés suivant les informations de structure, c'est-à-dire suivant l'ordre d'apparition, dans le document XML, des noms qualifiés associés. Les valeurs des canaux sont ensuite encodées les unes à la suite des autres, canal par canal (selon l'ordre prévu). Dans le mode "compression", une compression de type DEFLATE est alors opérée sur chacun des canaux de structure et de valeurs ainsi formés, avec la mise en place optionnelle de stratégies de regroupement de canaux (essentiellement de valeurs) en fonction de leur taille (en nombre de valeurs). Le mode "pré-compression" n'effectue, quant à lui, qu'une réorganisation des données en blocs, comme expliqué ci-dessus. On illustre ce mécanisme de "pré-compression" à l'aide du document 10 SVG représenté en figure la. La figure lb représente le canal de structure 12 alors obtenu, conformément à la notation introduite précédemment. La figure lc présente l'ordre des différents canaux de valeurs 14 alors obtenus, à savoir successivement les canaux relatifs aux noms qualifiés width, height, d, style, x, y, xlink:href et rx. L'ordre des valeurs de ces canaux est celui représenté en figure Id, et correspond à l'ordre des valeurs dans le document XML pour chaque canal, ces canaux étant eux-mêmes ordonnés comme dans la figure lc. Comme représenté sur la figure le, le codage EXI du document de la figure la génère un flux EXI 20 comprenant, tout d'abord, le canal de structure selon les codes définis par les grammaires, puis les valeurs du document dans l'ordre défini dans la figure Id. L'encodage exact de chaque valeur est défini par la recommandation EXI: par défaut, les valeurs sont encodées en tant que chaînes de caractères avec indexation. Comme représenté sur la figure le, le canal de valeurs correspondant à l'attribut "d" occupe la plus grande part des données compressées. En effet, comme expliqué précédemment, les attributs 'd' sont les chemins décrivant les formes complexes d'un document SVG, et constituent ainsi les données de plus grande taille. Comme ces chemins ne sont que très rarement répétés, aucun mécanisme d'indexation n'est généralement mis en oeuvre pour les encoder. La mise en oeuvre du mode "compression" est très efficace en terme de compression des données XML, notamment en raison de la diminution d'entropie des données par regroupement, dans une même liste, d'informations similaires. Toutefois, malgré les bonnes performances en taux de compression, ce mode EXI "compression" engendre un surcoût de traitement pour décoder les documents alors codés. Le surcoût a une origine double: d'une part, en raison de l'utilisation de l'algorithme DEFLATE avant le décodage EXI proprement dit des événements XML, et d'autre part, en raison de l'espace mémoire important nécessaire à la mémorisation des événements et canaux afin de les réordonner pour l'encodage et le décodage. Le surcoût lié à la consommation de mémoire est le plus problématique, en particulier pour des dispositifs légers tels que les caméras ou les imprimantes. Ces dispositifs peuvent en effet traiter de gros documents XML (SVG, Open Office, PDFXML) en mode streaming. Or, classiquement, ces dispositifs traitent les documents événement après événement (ou bloc d'événements par bloc d'événements; ou page par page). Dans ce cas, le stockage des événements XML reste facilement contrôlable et modéré. En revanche, lorsque le mode EXI compression est utilisé, le traitement en mode streaming est compromis car le processeur EXI peut être amené à stocker un nombre important d'événements. On peut illustrer ce problème de gestion de la mémoire à l'aide des graphiques de la figure 2. La figure 2a représente, de façon schématique, la consommation mémoire pour le stockage des canaux durant le décodage du document correspondant à la figure la et codé conformément à la recommandation EXI (EXI textuel) sans utiliser les "modes compression" ou "pré-compression". La figure 2b représente également la consommation mémoire dans le cas du document codé à l'aide du mode EXI "compression" prévu par la recommandation EXI. Sur ces figures, les étapes 1, 2, 3, 4 et 5 correspondent à l'utilisation 25 mémoire au moment du décodage des balises des éléments 'svg', 'path', `image', 'path' et 'path' respectivement du document 10. Dans le mode EXI textuel, on débute par décoder la première balise ouvrante qui nécessite peu de mémoire (étape 1 a). Pour chaque décodage d'un élément 'path', on stocke la valeur de l'attribut 'd', lequel est généralement de 30 grande longueur comme expliqué précédemment, d'où les pics des étapes 2a, 4a et 5a. L'élément `image' ne contenant pas de valeurs importantes en taille, le pic de l'étape 3a est nettement plus petit. Dans le mode EXI compression, on décode l'ensemble des informations de structure puis les canaux concernant les attributs width et height, ce qui nécessite un stockage mémoire peu important (étape 1 b). Avant d'émettre les informations concernant le premier élément 'path', on décode en entier le canal de l'attribut 'd' (ici trois valeurs de 'd'). A la fin du décodage du canal correspondant à l'attribut 'd', le décodeur stocke en mémoire l'ensemble des valeurs de 'd', c'est-à-dire la plupart des données SVG (en termes de taille), sans pouvoir les transmettre à l'application informatique, d'où le pic très important que l'on peut observer à l'étape 2b. Une fois le canal de l'attribut 'd' décodé, on commence à décoder le canal de l'attribut 'style'. Le décodage de la première valeur du canal 'style' permet de disposer de l'intégralité des données décodées pour la première balise 'path'. Cette dernière est alors envoyée à l'application. Les valeurs utilisées pour cette balise, notamment la première valeur dans le canal de l'attribut 'd', sont alors effacées de la mémoire si elles ne servent pas de base à une indexation (ce qui est le cas généralement pour les attributs 'd'). La chute brutale (entre 2b et 3b) de la mémoire occupée sur la figure 2b illustre la libération de la mémoire utilisée pour le stockage de la valeur de l'attribut 'd'. Pour décoder la balise suivante `image', on finit le décodage du canal de l'attribut 'style' puis on poursuit par celui des canaux des attributs 'x', 'y' et 'xlink:href (qui ont une taille très réduite par rapport à celle du canal de l'attribut 'd'). Une fois l'ensemble des informations de la balise 'image' décodées, on envoie à l'application l'élément `image' décodé (étape 3b). A ce moment, on dispose de quasiment l'intégralité des canaux décodés. La fourniture des deux balises suivantes 'path' peut ainsi être réalisée immédiatement. La figure 2b montre clairement la libération de l'espace mémoire du fait de la suppression des valeurs de 'd' lors de la transmission à l'application successivement des deux balises 'path' (étape 4b pour la première et étape 5b pour la seconde). Ces figures 2a et 2b montrent clairement les différences de consommation mémoire pour le décodage du document EXI dans les deux cas évoqués ci-dessus. Dans le mode EXI compression, l'utilisation mémoire présente un pic maximal très supérieur à celui observé pour le décodage EXI textuel. Dans le cas présent, cette différence résulte du stockage simultané des trois valeurs de l'attribut 'd', là où le décodage EXI textuel ne stocke au maximum qu'une valeur de l'attribut 'd'. Ces observations montrent que l'utilisation du mode EXI "compression" requiert un espace mémoire important, éventuellement non compatible avec des dispositifs de traitement équipés de peu de ressources mémoire. La présente invention vise à résoudre les inconvénients de l'art antérieur en améliorant les mécanismes de codage/décodage afin de permettre 15 une consommation réduite de la mémoire du décodeur. Dans ce dessein, l'invention concerne notamment un procédé de codage d'un document structuré composé d'événements à coder présentant des valeurs, comprenant les étapes suivantes: - constituer des canaux de valeurs regroupant des valeurs 20 d'événements selon au moins un critère, lesdits canaux étant ordonnés selon un premier ordre correspondant à l'ordre d'apparition de leur première occurrence de valeur dans le document structuré; - ré-ordonner au moins une partie desdits canaux de valeurs selon un deuxième ordre, en fonction d'informations représentatives, chacune, de 25 l'espace mémoire nécessaire au stockage des valeurs de chaque canal de valeurs; et - coder les canaux de valeurs selon ledit deuxième ordre, en un flux codé. Selon l'invention, on modifie l'ordre dans lequel les canaux de 30 valeurs sont codés dans le flux, par exemple de type EXI, selon des informations relatives à l'espace mémoire qu'ils nécessitent du côté du décodeur. En déplaçant les canaux volumineux vers la fin du flux EXI (ré- ordonnancement), on décale, dans le temps, leur décodage. On augmente ainsi les chances que leur utilisation soit instantanée sans à avoir à attendre une valeur manquante, de telle sorte que chaque valeur qui y est décodée est exploitée immédiatement pour fournir une balise ou un événement complet à l'application exploitant le document. Par conséquent, on limite voire évite le stockage des valeurs volumineuses de manière prolongée. En d'autres termes, le procédé selon l'invention minimise le temps (de stockage) entre la phase de décodage d'une valeur et la phase de traitement par l'application (lorsque la balise est complète pour être transmise à l'application). Bien entendu, le décalage dans le temps du décodage des canaux volumineux peut entraîner le stockage temporaire de canaux moins volumineux, et donc une occupation parfois non négligeable de la mémoire. Dans ce contexte, en particulier, le procédé comprend: - le calcul d'une valeur estimée d'occupation mémoire pour une pluralité d'ordres des canaux de valeurs, notamment tous les ordres possibles, ou seulement certains ordres prédéterminés, - la détermination, comme ordre de ré-ordonnancement, de l'ordre des canaux présentant la valeur estimée minimale. De la sorte, on choisit le ré-ordonnancement des canaux de valeurs qui minimise le pic d'occupation mémoire au niveau du décodeur. Ces calculs peuvent être menés par simulation ou approximation au niveau du codeur. On voit ici qu'il convient, non pas de mettre à la fin du flux EXI les canaux les plus volumineux, mais de les positionner de façon optimale. Notamment, ledit calcul d'une valeur estimée d'occupation mémoire pour un ordre comprend l'estimation d'un coût de stockage individuel associé à au moins un canal de valeurs, le coût de stockage individuel d'un premier canal précédant, dans ledit ordre, un canal suivant, correspondant au coût de stockage de l'ensemble des valeurs dudit premier canal postérieures, dans ledit document structuré, à première valeur du canal suivant. On obtient ainsi une estimation raisonnable, à faible coût, de coûts de stockage liés à des canaux. En particulier, ladite valeur estimée pour un ordre comprend la somme de coûts de stockage individuels associés chacun à un canal de valeur. Selon une variante du calcul d'une valeur estimée pour plusieurs ordres des canaux, on peut prévoir que ledit ré-ordonnancement comprend l'interversion itérative d'au moins un canal de valeurs avec un canal de valeurs voisin suivant à partir d'un ordre initial desdits canaux de valeurs. Dans cette configuration, on réduit les coûts de calcul en se limitant, itérativement, à des comparaisons entre deux canaux voisins. On évite ainsi des coûts d'estimation de ré-ordonnancement en évaluant les multiples combinaisons possibles d'ordres des canaux. En particulier, l'interversion itérative comprend, pour chaque canal de valeurs considéré : - l'évaluation de l'opportunité d'intervertir ledit canal de valeurs avec le canal voisin suivant, en comparant un coût de stockage individuel associé audit canal de valeurs considéré avec un coût de stockage individuel associé audit canal de valeurs voisin; - en cas d'évaluation positive, intervertir les deux canaux de valeurs et itérer ladite évaluation avec le nouveau canal de valeurs voisin suivant, en comparant le coût de stockage individuel associé au premier canal considéré alors interverti avec la somme des coûts de stockage individuels associés aux canaux voisins déjà intervertis et au nouveau canal voisin. Au terme des itérations, les canaux ont ainsi été réorganisés selon un nouvel ordre réduisant les coûts de stockage. Dans un mode de réalisation de l'invention, le procédé comprend l'indication, dans le flux codé contenant les canaux codés, d'une information de ré-ordonnancement desdits canaux codés. Par ce mécanisme, on informe, à faible coût, le décodeur quant à l'ordre d'encodage des canaux et donc les adaptations à mener pour décoder le document codé selon des informations de structure, par exemple également encodées dans le flux. En particulier, ladite information de ré-ordonnancement est codée dans l'en-tête du flux codé, et comprend une information de priorité d'une pluralité de canaux définissant relativement un ordre desdits canaux. En indiquant uniquement l'information de priorité de chaque canal ayant une telle priorité, on minimise la quantité d'information à transmettre. L'ordre des canaux, fonction de ces priorités, est ainsi aisément déterminable par le décodeur. Selon une caractéristique de l'invention, les canaux de valeurs regroupent, chacun, les valeurs des événements correspondants à un même type d'information de structure, notamment un même nom qualifié, et le procédé comprenant la constitution d'un canal de structure répertoriant des informations de structure de telle sorte que les premières occurrences de types d'informations de structure dans ce canal de structure sont dans le même ordre que les canaux de valeurs correspondants à ces types d'informations selon ledit deuxième ordre. Dans cette configuration, on peut modifier, pour renseigner le ré-ordonnancement des canaux, uniquement le canal de structure par rapport à l'ordre initial prévu dans la plupart des recommandations ou normes de compression de documents structurés. De ce fait, on conserve la compatibilité avec ces recommandations ou normes, et l'invention peut être mise en oeuvre pour des décodeurs classiques. En particulier, ladite constitution du canal de structure comprend : l'ajout, dans un canal de structure répertoriant, dans ledit premier ordre, les informations de structures du document structuré, d'au moins une information de structure factice, c'est-à-dire qui ne reflète pas une information de structure réellement existante dans le document structuré à coder. Notamment, cette information factice indique, avant la première occurrence d'un type d'information de structure correspondant à un canal déplacé dans ledit ré-ordonnancement, des premières occurrences des types d'informations de structure correspondants à des canaux de valeurs précédant ledit canal déplacé. Dans ce cas, on prévoit également l'ajout, dans les canaux de valeurs précédant le canal déplacé, c'est-à-dire les canaux correspondants aux informations de structure ajoutées, d'une valeur factice. Cet ajout de données factices assure, au niveau du décodeur, le décodage et le chargement en mémoire des canaux précédant le canal déplacé, et donc le décodage tardif de ce dernier afin d'en effectuer une exploitation immédiate en minimisant son stockage. Selon une caractéristique de l'invention : - la formation du canal de structures répertoriant les informations de structures et la constitution des canaux de valeurs selon le premier ordre sont mises en oeuvre par une premier moyen de génération de données à encoder; - lesdits ajouts d'informations et de valeurs factices sont mis en oeuvre sur lesdites données à encoder, par un moyen distinct de prétraitement; et - ledit codage est mis en oeuvre sur les données issues du 15 prétraitement, par un moyen de codage. Cette configuration permet d'utiliser les encodeurs actuels sans les modifier (génération de données à encoder et moyen de codage), en leur adjoignant un moyen de prétraitement intermédiaire qui modifie les données à coder, selon les particularités de l'invention, avant codage. 20 Dans un mode de réalisation de l'invention, le procédé comprend: - la séparation d'un canal de valeurs en au moins deux sous-canaux, et - la modification dudit deuxième ordre pour faire apparaître les deux sous-canaux, le premier sous-canal conservant la position dudit canal de 25 valeurs séparé, et le deuxième sous-canal prenant une position correspondant à la position de sa première valeur dans le document structuré. Dans cette configuration, on scinde les canaux de valeurs en sous-canaux que l'on traite indépendamment. Ainsi, alors que les techniques connues de décodage jusqu'alors nécessitaient le stockage de toutes les 30 valeurs décodées du canal de valeur pour passer au canal suivant, l'invention permet ici de limiter ce stockage à un seul sous-canal. Le décodage des autres sous-canaux est alors déporté à leur première occurrence propre. On optimise ainsi l'utilisation de la mémoire au niveau du décodeur. En particulier, un emplacement de séparation du canal de valeurs correspond à la limite d'un bloc de données prédéterminé dans ledit document structuré. C'est par exemple le cas des éléments 'self-containecf prévus dans la recommandation EXI, ou encore des blocs nommés 'page' ou 'ensemble de pages' de SVG. La séparation des canaux selon ces blocs de données est particulièrement efficace du fait que l'exploitation du document est généralement effectuée au regard de ces blocs de données (par exemple pour impression ou affichage page par page, pour navigation par élément, etc.) et que l'on stocke par conséquent uniquement les valeurs associées à chaque bloc à traiter sans stocker les valeurs des autres blocs non traités à ce moment. Notamment, lesdits sous-canaux comprennent des valeurs contiguës dudit document structuré. Cette configuration permet de limiter le stockage de valeurs de sous- canaux résultant d'une scission d'un canal original. Selon une caractéristique particulière, on encode lesdits sous-canaux obtenus et on insère au moins une indication de séparation d'un canal à la fin d'un sous-canal encodé. Cette disposition permet au décodeur de savoir qu'un canal a été séparé. En effet, dans le cas où le décodeur récupère par exemple des informations de ré-ordonnancement des canaux, cette indication supplémentaire permet de détecter les canaux séparés en sous-canaux. Par ailleurs, on peut prévoir que le procédé comprend l'estimation d'un coût de stockage individuel nécessaire au stockage de valeurs de chaque canal de valeurs, et d'un coût de stockage global desdits canaux de valeurs lors du décodage du document, et le procédé comprend, tant que le coût de stockage global est supérieur à une valeur seuil, les étapes suivantes: - déterminer le canal de valeurs ayant le plus grand coût de stockage individuel; - séparation dudit canal de valeurs déterminé en au moins deux canaux; - mise à jour des coûts de stockage individuels et global. Dans un mode de réalisation, le procédé comprend la fusion d'au moins deux canaux de valeurs en un unique canal dont les valeurs suivent leur ordre dans le document structuré (ledit premier ordre). En particulier, ladite fusion d'au moins deux canaux de valeurs est opérée selon un critère d'entremêlement desdits au moins deux canaux de valeurs. Dans cette configuration, on rend possible l'exploitation directe des valeurs décodées correspondant à ces canaux fusionnés sans stockage de celles-ci, alors qu'en l'absence de fusion, le stockage d'une partie des canaux au moins est nécessaire du fait de l'entremêlement. Dans un mode de réalisation de l'invention, le procédé comprend: - la sélection, parmi lesdits canaux de valeurs, d'un ensemble de canaux dont l'espace mémoire nécessaire au stockage de leurs valeurs est supérieur à une valeur prédéterminée ; - l'association, à chaque canal sélectionné, d'une valeur de priorité représentative dudit espace mémoire nécessaire au stockage de ses valeurs, et ledit ré-ordonnancement étant relatif aux valeurs de priorité. Dans cette configuration, la sélection permet de réduire les calculs de ré-ordonnancement selon l'invention car on se concentre désormais sur les uniques canaux sélectionnés. Notamment, on peut prévoir que lesdits canaux de valeurs sélectionnés, ordonnés relativement auxdites valeurs de priorité, sont disposés à la suite des canaux de valeurs non sélectionnés ordonnés selon l'ordre d'apparition de leur première occurrence dans le document structuré. Selon une caractéristique de l'invention, le procédé comprend les étapes suivantes: - déterminer des groupes disjoints de canaux de valeurs, au sens où les groupes forment des ensembles disjoints de valeurs, c'est-à-dire des ensembles consécutifs de valeurs dans l'ordre dudit document structuré; - ré-ordonner indépendamment chaque groupe en conservant l'ordre desdits groupes selon l'ordre d'apparition de leur première occurrence dans le document structuré. Un intérêt manifeste de cette disposition réside dans le fait que, puisque le document se compose de parties distinctes et indépendantes (car disjointes), les canaux associés à ces parties ne doivent pas être mélangés afin d'éviter le stockage de l'un d'entre eux alors qu'on décode un canal d'une autre partie du document. Par ailleurs, cette disposition permet de paralléliser les traitements sur les différents groupes, et donc d'accélérer le codage selon l'invention. Corrélativement, l'invention concerne un dispositif de codage d'un document structuré composé d'événements à coder présentant des valeurs, comprenant: - un moyen de constitution pour constituer des canaux de valeurs regroupant des valeurs d'événements selon au moins un critère, lesdits canaux étant ordonnés selon un premier ordre correspondant à l'ordre d'apparition de leur première occurrence de valeur dans le document structuré; - un moyen de ré-ordonnancement pour ré-ordonner au moins une partie desdits canaux de valeurs selon un deuxième ordre, en fonction d'informations représentatives, chacune, de l'espace mémoire nécessaire au stockage des valeurs de chaque canal de valeurs; - un moyen de codage pour coder les canaux de valeurs selon le deuxième ordre, en un flux codé. Le dispositif de codage présente des avantages similaires à ceux du procédé de codage exposé ci-dessus, notamment de permettre l'utilisation réduite des ressources mémoire au niveau du décodeur. De façon optionnelle, le dispositif peut comprendre des moyens se rapportant aux caractéristiques du procédé de codage exposé précédemment, tels que des moyens de calculs de priorités ou de coûts de stockage associés à des canaux, des moyens de séparation ou de fusion de canaux, des moyens de détermination de groupes disjoints de canaux de valeurs. Par ailleurs, l'invention concerne également un procédé de décodage d'un flux codé correspondant à un document structuré, comprenant les étapes suivantes: - récupérer des données à décoder correspondant à plusieurs 5 canaux codés de valeurs; - déterminer un ordre initial desdits canaux de valeurs; - récupérer, dans ledit flux codé, une information de ré-ordonnancement desdits canaux de valeurs; - modifier l'ordre des canaux de valeurs conformément à ladite 10 information de ré-ordonnancement; et - décoder les valeurs codées selon l'ordre modifié desdits canaux de valeurs. Grâce à l'information de ré-ordonnancement des canaux, le décodeur peut mener un décodage efficace du flux codé tirant le bénéfice du 15 ré-ordonnancement prévu au codage. Une consommation réduite de la mémoire du décodeur peut ainsi être obtenue. Selon une caractéristique particulière, ledit décodage des valeurs codées d'un canal de valeurs comprend: - la récupération, dans le flux codé, d'une information indiquant que 20 ledit canal est séparé en au moins deux sous-canaux de valeurs; - le décodage des valeurs contiguës correspondant à un sous-canal de valeurs; - la mise à jour d'une liste ordonnant lesdits canaux de valeurs par l'insertion de l'autre sous-canal. 25 La gestion de canaux scindés permet d'améliorer encore l'utilisation réduite de la mémoire du décodeur. Corrélativement, l'invention concerne un dispositif de décodage d'un flux codé correspondant à un document structuré, comprenant: - un premier moyen de récupération pour récupérer des données à 30 décoder correspondant à plusieurs canaux codés de valeurs; - un moyen de détermination pour déterminer un ordre initial desdits canaux de valeurs; - un second moyen de récupération pour récupérer, dans ledit flux codé, une information de ré-ordonnancement desdits canaux de valeurs; - un moyen de modification pour modifier l'ordre des canaux de valeurs conformément à ladite information de ré-ordonnancement; et - un moyen de décodage pour décoder les valeurs codées selon l'ordre modifié desdits canaux de valeurs. Le dispositif de décodage présente des avantages similaires à ceux du procédé de décodage exposé ci-dessus, notamment de permettre l'utilisation réduite des ressources mémoire au niveau du décodeur. De façon optionnelle, le dispositif peut comprendre des moyens se rapportant aux caractéristiques du procédé de codage exposé précédemment. L'invention concerne également un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprenant des instructions pour un programme informatique adapté à mettre en oeuvre le procédé de codage ou de décodage conforme à l'invention lorsque ce programme est chargé et exécuté par le système informatique. L'invention concerne également un programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé de codage ou de décodage conforme à l'invention, lorsqu'il est chargé et exécuté par le microprocesseur. Les moyens de stockage d'information et programme d'ordinateur présentent des caractéristiques et avantages analogues aux procédés qu'ils mettent en oeuvre. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les dessins ci-joints, dans lesquels : - la figure 1 illustre les mécanismes d'encodage d'un document structuré selon les techniques de l'état de l'art et selon l'invention; - la figure 2 illustre, à l'aide de graphiques schématiques, une comparaison de la consommation mémoire d'un décodeur selon les techniques de l'état de l'art et selon l'invention; - la figure 3 représente, sous forme de logigramme, des étapes d'encodage d'un document structuré selon un premier mode de réalisation de l'invention; - la figure 4 représente, sous forme de logigramme, des étapes de détermination de l'ordre des canaux selon l'invention lors d'une étape particulière du procédé de la figure 3; - la figure 5 représente, sous forme de logigramme, des étapes pour le calcul de valeurs de priorité pour des canaux de valeurs, mis en oeuvre lors du procédé de la figure 3; - la figure 5bis illustre la mise en oeuvre d'un ré-odonnancement par groupes disjoints de canaux, selon l'invention ; - la figure 6 illustre, à l'aide d'un logigramme, des étapes d'encodage d'un document structuré selon un deuxième mode de réalisation de l'invention mettant en oeuvre une modification d'informations de structure; - la figure 7 illustre, à l'aide d'un logigramme, des étapes d'encodage d'un document structuré selon un troisième mode de réalisation de l'invention mettant en oeuvre une séparation de canaux de valeurs; - la figure 8 représente, sous forme de logigramme, des étapes de décodage d'un flux codé selon l'invention; - la figure 9 représente, sous forme de logigramme, des étapes d'un mode particulier de décodage d'un flux codé selon l'invention, mettant en oeuvre la séparation de canaux de valeurs de la figure 7; et - la figure 10 montre une configuration matérielle particulière d'un dispositif apte à une mise en oeuvre du ou des procédés selon l'invention. On décrit maintenant un mode de réalisation de l'invention consistant à contrôler l'ordonnancement des canaux de valeurs EXI en fonction de l'espace mémoire que ceux-ci requièrent pour leur stockage au niveau du décodeur. En effet, selon l'invention, on cherche à éviter le stockage des canaux volumineux. On minimise ce stockage en prévoyant d'améliorer leur exploitation simultanée avec leur décodage. Les figures 1f et 1g montrent la mise en oeuvre de l'invention sur le document de la figure la. Le ré-ordonnancement prévu dans ce cas positionne, dans le flux EXI généré 20, le canal 14 associé à l'attribut 'd' (dont les valeurs sont les chemins SVG M..., M... et M...) après les canaux 'style', 'x' et 'y'. Ainsi, comme représenté sur la figure 2c, on observe une 5 consommation instantanée de la mémoire réduite comparativement à celle de la figure 2b, notamment un pic maximal nettement réduit. En effet, pour décoder la première balise ouvrante 'svg', on effectue le décodage du canal de structure 12 puis des canaux des valeurs 14 des attributs 'width' et 'height' (étape 1c). Pour décoder l'élément 'path' suivant, 10 l'ensemble des canaux ("style', 'x' et 'y') précédant le canal de l'attribut 'd' est décodé. On décode alors la première valeur du canal de l'attribut 'd'. A ce stade, on possède toutes les informations de la première balise 'path' (étape 2c), que l'on envoie alors pour traitement à l'application. On supprime 15 instantanément les informations relatives à cette balise 'path' de la mémoire. Les informations nécessaires au traitement de la balise suivante `image' sont également toutes disponibles en mémoire et la balise `image' peut donc être envoyée instantanément à l'application (étape 3c). Les valeurs de cette balise sont alors supprimées de la mémoire. 20 Avant d'envoyer les éléments 'path' suivants, on décode la valeur de l'attribut 'd' correspondant à chaque balise avant de les envoyer à l'application (étape 4c et 5c). Comme toutes les autres informations de ces balises sont déjà disponibles en mémoire, le décodage de chaque valeur du canal de l'attribut 'd' engendre la transmission instantanée de la valeur à l'application, puis la 25 suppression immédiate de cette valeur de la mémoire. Ainsi, à aucun moment, dans cet exemple, on ne stocke deux valeurs de l'attribut 'd'. On réduit alors la capacité mémoire nécessaire au décodage. On peut ensuite envoyer le reste des informations décodées. Comparé au codage/décodage EXI "compression" sans l'invention, la 30 mise en oeuvre de l'invention nécessite le stockage des valeurs des canaux 'style', 'x' et 'y' avant d'accéder au canal volumineux 'd'. Toutefois, le stockage de ces premiers canaux représente un coût modéré car leurs valeurs prennent peu d'espace mémoire. Il ressort de cet exemple que l'invention permet d'éviter, ou à tout le moins de réduire, le stockage des informations prenant beaucoup de place. On diminue ainsi le pic de consommation mémoire instantanée et on réduit également la consommation mémoire globale utilisée durant le décodage. Il est à noter que les valeurs des canaux de petite taille sont généralement des petites valeurs sur lesquelles sont mis en oeuvre les mécanismes d'indexation. Ces valeurs sont, par conséquent, conservées par le décodeur dans les tables d'indexation. En revanche, les valeurs importantes en taille ont peu de chance de se retrouver plusieurs fois dans le même document et de ce fait ne font pas l'objet d'indexation. C'est pourquoi on peut les supprimer de la mémoire dès utilisation pour générer une valeur à l'application. On prévoit ainsi, selon un mode de réalisation de la présente invention, le ré- ordonnancement des canaux associés à ces valeurs de grande taille, vers la fin du flux codé EXI. Outre les gains en consommation mémoire, l'invention permet de démarrer plus tôt les traitements en mode streaming. En effet, comme montré par la comparaison entre les figures le et 1g, pour émettre la balise 'path' à l'application, le décodage sur un document codé selon l'invention requiert le décodage de moins de la moitié du flux EXI 20, alors qu'en l'absence de l'invention, près de trois quart du flux doit être décodé pour obtenir les informations de 'style'. De ce fait, l'application pourra émettre des résultats partiels plus tôt. Cette amélioration est particulièrement intéressante dans le cadre de la visualisation ou de l'impression d'un document. On peut par ailleurs noter que les avantages ainsi conférés par l'invention ne modifient en rien les taux de compression obtenus. En détail, en référence à la figure 3, on décrit maintenant les étapes générales d'un encodage selon l'invention, impliquant un ré-ordonnancement 30 des canaux de valeurs. Le traitement débute, à l'étape E100, par la récupération des données à encoder. Ces données à encoder résultent des traitements classiques selon la recommandation EXI par exemple, et prennent la forme d'un canal de structure 12 répertoriant l'ensemble des informations de structure du document XML de départ, dans l'ordre de ce document, et de plusieurs canaux de valeurs 14 correspondants aux différents noms qualifiés rencontrés, ces canaux de valeurs étant dans l'ordre d'apparition des noms qualifiés dans le document 10 à coder (même ordre que celui conservé dans les informations de structure du canal 12). A l'étape E110, on détermine des priorités à affecter aux canaux de valeurs 14 des données à encoder. On cherche ici à hiérarchiser les canaux selon des priorités représentatives du coût correspondant de stockage en mémoire du décodeur, pour les ordonner de préférence depuis les valeurs de faible priorité jusqu'à celles de haute priorité. Ainsi, le traitement d'une valeur décodée de haute priorité (car volumineuse par exemple) s'effectue en dernier et sans stockage. Différentes approches d'attribution de priorités peuvent être mises en oeuvre. En particulier, une approche statique par laquelle on affecte, de façon prédéfinie, les mêmes priorités pour toutes les données d'un même type. Le type de données peut correspondre au format (SVG par exemple), à un profil de format (le profil d'impression SVG par exemple) ou même à un type de données générées par une application. A titre d'exemple, on définit que l'attribut 'd' de tout document SVG a une forte priorité car les valeurs qu'il prend sont importantes en termes de mémoire. Pareillement, on peut affecter une priorité importante aux attributs d'animation (attribut `values' notamment de SVG) car les valeurs qu'ils prennent peuvent être importantes en termes de mémoire. De façon similaire, les informations d'animation étant plus volumineuses que les informations graphiques SVG, on peut prévoir d'affecter statiquement une priorité plus grande pour les premières. Une autre approche consiste en un calcul dynamique des priorités sur la base de l'ensemble des données à encoder. On adapte ainsi précisément les priorités au contenu des données à encoder. Un mode de réalisation est présenté ci-après en référence à la figure 5, et s'organise autour de trois grandes étapes: - une sélection (étapes E300 à E320) de canaux susceptibles d'être prioritaires selon un critère de taille; - la détermination (étapes E325 à E335) d'un ordre de ces canaux permettant une diminution du stockage des valeurs de ces canaux au moment du décodage; et - l'affinage (étape E340 à E360) optionnel de l'ordonnancement des 10 valeurs des canaux pour atteindre un coût de stockage minimal en prévoyant l'unification de canaux et/ou la séparation de canaux. Une dernière approche, dite mixte, combine ces deux premières approches, en effectuant une classification à partir du type de données (SVG, Open Document Format, etc.) et des données elles-mêmes (SVG avec 15 animation ou pas). En d'autres termes par exemple, l'information de type des données peut servir à déterminer un petit nombre de canaux auxquels on va affecter des priorités de façon dynamique. Par exemple, pour Open Office, on peut décider de calculer les priorités uniquement pour les éléments `t', 'span' et 'p' qui 20 généralement contiennent la plupart des données textuelles d'un document Open Office. De même le type des données peut permettre de déterminer la possibilité de fusionner ou pas des canaux. Ainsi, les éléments `t', `span' et 'p' peuvent être fusionnés car les données de ces éléments sont du même type. A la fin de l'étape E110, on obtient des priorités pour les canaux, 25 définissant un ordre précis des valeurs organisées en canaux ou sous-canaux. Lorsque cet ordre ou les priorités sont déterminées pour tout ou partie des canaux de valeurs 14, on passe à l'encodage d'une information de ré-ordonnancement (étape E120) et des informations de structure composant le canal de structure 12 (étape E130). 30 Différents modes de réalisation sont possibles pour ces étapes. Dans un premier mode, illustré ci-après en référence à la figure 6, l'information de ré-ordonnancement peut être intégrée aux informations de structure en modifiant ces dernières dans le canal de structure 12 pour obtenir l'ordre désiré. En effet, dans le schéma conforme à la recommandation EXI, les canaux de valeurs 14 sont ordonnés dans le même ordre que les informations de structure correspondantes dans le canal de structure 12. Dans ce cas, les étapes E120 et E130 sont réalisées conjointement. Dans un autre mode, l'information de ré-ordonnancement est encodée dans l'en-tête du flux XML binaire de type EXI, au niveau de champs optionnels laissés libres par la recommandation EXI. Dans ce cas, on effectue l'étape E120 puis l'étape E130, et le décodeur devra être adapté pour interpréter ces champs optionnels utilisés. Dans encore un autre mode, on réalise les étapes E120 et E130 en parallèle, l'étape E120 consistant alors à récupérer l'ensemble des canaux de valeurs 14 ayant une priorité (non nulle) et à encoder, dans des données particulières listant l'ensemble des canaux, pour chacun de ces canaux ayant une priorité : - le nom qualifié qname associé au canal; - le type du canal (canal noeud texte ou canal attribut); et - la priorité associée au canal. L'invention s'avère très efficace lorsque les canaux de valeurs volumineuses sont concernés par le ré-ordonnancement des canaux, afin de les déplacer vers la fin des données codées. Or, généralement, le nombre de tels canaux de valeurs volumineux est assez faible dans un document, notamment du fait que peu d'éléments ou d'attributs se retrouvent fréquemment dans un document avec des valeurs associées de taille importante. Aussi, le nombre de canaux de valeurs auxquels on cherche à attribuer une priorité est assez faible en vue de réaliser un déplacement de ceux-ci dans l'ordre des canaux. Ainsi, le coût d'encodage de l'information de ré-ordonnancement reste très faible car très peu d'information est à encoder. Une fois les informations de structure et de priorité encodées aux étapes E120 et E130, on détermine, lors de l'étape E140, l'ordre final d'encodage des canaux de valeurs 14, en utilisant notamment les priorités affectées aux canaux à potentiellement déplacer. Toutefois, comme on le verra par la suite, cette étape peut être réalisée dès l'étape E110, lorsque cette dernière prévoit de calculer directement un nouvel ordre des canaux. Un exemple de réalisation de l'étape E140, dans le cas où des priorités ont été affectées aux canaux, est illustré en référence à la figure 4. La figure 4 présente une réalisation particulière de l'ordonnancement des canaux qui est effectué au moment de l'encodage ou au moment du décodage comme on le verra par la suite. On débute à l'étape E200 par déterminer les informations de structure. Cette étape consiste à décoder les informations de structure pour le processus de décodage et à stocker les informations de structure (du canal 12) fournies par l'application pour le processus d'encodage. On parcourt ensuite, dans l'ordre, ces informations de structure sous la forme d'une liste d'événements du document 10, lors des étapes E210 et E220. Pour chaque nouvel événement, on détermine si un nouveau canal doit être créé en testant le nom qualifié qname associé à l'événement (étape E230). Un nouveau canal doit être créé s'il n'existe pas encore de canal de valeurs 14 associé à ce nom qualifié. Si ce n'est pas le cas (sortie non de l'étape E230), on passe à l'événement suivant (étape E210). Si un nouveau canal doit être créé (sortie oui de l'étape E230), on récupère la priorité liée à ce canal de valeurs 14 lors de l'étape E240. Il s'agit notamment de la priorité calculée lors de l'étape E110 lors de l'encodage, ou celle récupérée lors de l'étape E610 décrite ci-après lors du décodage, par exemple par lecture des priorités dans l'en-tête du flux binaire EXI. Si aucune priorité n'est affectée à ce canal de valeurs (sortie non de l'étape E240), on ajoute, lors de l'étape E250, ce canal à la fin d'une liste principale des canaux de valeurs. On conserve ainsi ces canaux sans priorité dans l'ordre initial du document 10. Sinon (priorité détectée), le canal de valeurs 14 est ajouté à la liste des canaux avec priorité lors de l'étape E260. Cette liste peut maintenir ordonnés les canaux de différentes façons. Dans un premier cas, les canaux de valeurs 14 peuvent être ordonnés selon l'ordre croissant des priorités, les canaux avec les plus grandes priorités se retrouvant à la fin de la liste. De façon optionnelle, si un canal 14 a une priorité égale à celle d'un autre canal, on peut fusionner/unifier ces canaux en un seul canal, en conservant, dans le canal fusionné, les valeurs dans le même ordre qu'elles apparaissent dans le document 10. On encode l'ensemble des valeurs de ce canal fusionné en suivant l'ordre du document, comme si les valeurs de ce canal fusionné correspondaient au même nom qualifié. Ainsi, la fusion des canaux d'un attribut 'a' et d'un attribut 'b' se fait comme suit : - la valeur correspondant à la première occurrence de l'attribut a ou de l'attribut b est encodée en premier - la valeur correspond à la énième occurrence de l'attribut a ou de l'attribut b est encodée en énième position. Ceci peut être intéressant lorsque plusieurs canaux sont de taille importante et que les valeurs des différents canaux sont dispersées dans l'ensemble du document 10. Dans ce cas, les valeurs des deux canaux étant entremêlées (ou entrelacées), on peut remarquer, comparativement au cas où les valeurs ne sont pas entremêlées, des différences de compression dues à une efficacité différente de l'algorithme DEFLATE sur le flux réordonné. Notamment, si les valeurs des canaux se ressemblent, un gain en compression est obtenu lorsque les valeurs sont regroupées. La fusion de deux canaux 14 peut également être conditionnée à un critère supplémentaire, par exemple un critère d'enchevêtrement de valeurs des canaux. On peut décider de fusionner des canaux si le nombre de valeurs de deux canaux de même priorité se chevauchant est supérieur à une valeur prédéterminée. Lorsque les valeurs du canal résultant sont exploitées directement au fur et à mesure du décodage de ce canal, on évite, grâce à la fusion pour cause d'enchevêtrement important, le stockage temporaire d'un grand nombre de valeurs du premier canal accédé. Un autre critère peut être le coût de stockage nécessaire si les deux canaux 14 ne sont pas fusionnés. A noter que cette fusion peut être réalisée lors de l'étape E140 décrite ici, notamment si le calcul des priorités des canaux se base uniquement sur le type de donnée, ou directement lors de l'étape E110 de calcul de priorité des canaux 14, comme décrit plus loin aux étapes E340-E345 de la figure 5. Une fois l'ensemble des événements, et donc des canaux de valeurs 14, traités (sortie non de l'étape E210), on dispose de deux listes de canaux distinctes: les canaux sans priorité, et ceux ordonnés selon leurs priorités. L'approche décrite ici repose sur une approximation selon laquelle les canaux sans priorité (donc de faible taille) ont un impact négligeable sur la mémoire. Il peut ainsi être envisagé de les décoder entièrement avant de s'atteler au traitement des canaux avec priorité. Aussi, on insère la liste des canaux disposant d'une priorité à la fin de la liste principale des canaux sans priorités (étape E270). Le traitement prend alors fin (étape E280). La présente invention n'est toutefois pas limitée à une scission aussi prononcée entre les canaux avec priorité et ceux sans. En effet, comme décrit plus loin, on peut envisager de modifier l'ordre des canaux 14 de manière à minimiser la consommation instantanée de la mémoire du décodeur, ce qui peut conduire à conserver des canaux 14 de faible taille (donc sans priorité) après des canaux 14 volumineux. Par ailleurs, dans le cas où des groupes de canaux ne s'entremêlent pas ou peu, il peut être efficace de traiter séparément ces groupes de telle sorte que des canaux sans priorité du deuxième groupe seront encodés après des canaux avec priorité du premier groupe. C'est par exemple le cas, dans l'exemple des figures 1f et 1g, où le canal 'rx' est maintenu après le canal 'd'. De retour à la figure 3, on peut noter que généralement l'étape E140, se basant sur les résultats de l'étape E110, peut être réalisée au fur et à mesure de l'étape E110, voire juste après celle-ci en parallèle des étapes El 20 et E130. Une fois l'ordre des canaux connu, on peut alors procéder (étape E150) à l'encodage des canaux 14 en utilisant un mode de réalisation conforme au format XML binaire selon la recommandation EXI, c'est-à-dire en suivant l'ordre des canaux obtenu à l'étape E140. On décrit maintenant un exemple de détermination des priorités de l'étape E110 en référence à la figure 5, s'organisant autour de trois grandes étapes. La première grande étape de sélection débute, à l'étape E300, par l'obtention de la liste des canaux à évaluer. Il s'agit de l'ensemble des canaux de valeurs 14 récupérés à l'étape E100. A l'étape E305, on obtient alors l'ensemble des valeurs de chaque canal. On détermine, à l'étape E310, le coût de stockage pour chaque canal. Ce coût est défini par la taille mémoire de l'ensemble des valeurs. On rappelle que ces valeurs sont stockées par le décodeur tant que la balise ou l'événement correspondant à la valeur n'est pas complet (ou qu'une balise/événement précédent n'est pas complet) et ne peut donc être envoyé à l'application. On calcule donc à cette étape un coût maximal estimé de stockage de chaque canal pour déterminer si celui-ci peut être prioritaire ou pas, en additionnant les coûts de stockage de chaque valeur du canal. Selon diverses approches, le coût de stockage d'une valeur correspond au nombre d'octets nécessaires pour stocker cette valeur encodée selon le format EXI; à l'espace nécessaire pour stocker la représentation de la valeur en tant que chaîne XML; ou à l'espace nécessaire pour stocker la représentation en tant que valeur programmatique (valeur typée, objet...). Au sortir de l'étape E310, on dispose ainsi d'un coût maximal de stockage de chaque canal. On poursuit, à l'étape E315, par le calcul du coût global de stockage de l'ensemble des canaux en additionnant ces différents coûts individuels. A l'étape E320, on utilise ces coûts maximaux individuels ou globaux, pour déterminer les canaux nécessitant un stockage important. On propose ici, de façon non limitative, trois approches, à savoir : - la détermination par un test sur le coût de stockage individuel du canal: par exemple, les canaux dont le coût de stockage est supérieur à 1 Mo ou supérieur à 33% de l'espace mémoire maximal disponible au niveau du décodeur sont sélectionnés. Ainsi, si un canal ne peut être stocké en entier par le décodeur, il est sélectionné comme canal candidat au ré-ordonnancement ; - la détermination par un test sur le ratio coût individuel / coût global, à partir des coûts calculés aux étapes E315 et E320. Par exemple, si un canal représente plus d'un certain ratio (25% à titre d'exemple) du coût global, il est sélectionné comme canal candidat au ré-ordonnancement ; - la détermination par un test combinant les deux critères précédents. A l'issue de l'étape E320, on dispose ainsi d'une liste de canaux nécessitant un stockage important. C'est à ces canaux que l'invention, dans le mode de réalisation décrit ici, prévoit d'affecter une priorité. La deuxième grande étape de la détermination des priorités E110 vise à déterminer un ordre de ces canaux prioritaires pour les classer selon l'ordre optimal en termes de consommation mémoire au niveau du décodeur. Pour ce faire, le traitement continue à l'étape E325 par déterminer la répartition des canaux les uns vis-à-vis des autres, notamment quant à savoir si ceux-ci sont entremêlés ou disjoints. Ainsi, à l'étape E325, on détermine, à l'intérieur du document XML de départ 10, pour chaque couple (A, B) de canaux de valeurs 14 parmi la liste des canaux retenus: - la première valeur du canal A située après la première valeur du canal B et la première valeur du canal B située après la première valeur du canal A; - la première valeur du canal A située après la dernière valeur du canal B et la première valeur du canal B située après la dernière valeur du canal A. Si par exemple, il n'y a pas de premières valeurs du canal A situées après les première et dernière valeurs du canal B, cela signifie que ces canaux sont disjoints, A précédant B. En d'autres termes, toutes les valeurs d'un des deux canaux se trouvent avant la première valeur de l'autre canal ou après la dernière valeur de cet autre canal suivant l'ordre du document 10. Par contre, un ensemble de valeurs A est considéré comme entremêlé avec un ensemble de valeurs B lorsqu'une valeur de A se trouve comprise entre deux valeurs de B suivant l'ordre des données. Plus le nombre de valeurs de A comprises entre deux valeurs de B et le nombre de valeurs de B comprises entre deux valeurs de A sont importants, plus les canaux peuvent être considérés comme entremêlées. Si certains canaux ou groupes de canaux sont disjoints, on peut alors séparer ces canaux en groupes disjoints et appliquer les étapes suivantes E330 et E335 de calcul des gains de codage pour chaque ordonnancement des canaux et de calcul des priorités correspondantes, indépendamment pour chaque groupe disjoint de canaux. Par ailleurs, ce critère de disjonction peut être appliqué plus tôt, notamment à l'étape E300, afin de traiter de façon totalement indépendante les canaux de valeurs 14 pour différentes parties successives du document 10. Chaque partie aura ainsi sa propre liste de canaux sans priorité et possiblement une liste de canaux avec priorité. Cette situation est illustrée par l'exemple de la figure 1g, où le canal 'rx', étant disjoint des autres canaux, est encodé isolément après le canal 'd'. On peut alors estimer à l'étape E330 les besoins en stockage pour le décodeur pour chaque ordonnancement, y compris l'ordre initial résultant du codage EXI classique (cet ordre des canaux 14 est celui suivant l'apparition des noms qualifiés correspondants dans le document 10 ou dans les informations de structure 12). Pour chaque ordonnancement, on prend en compte le stockage des valeurs nécessitant d'être stockées. Pour cela, on dispose, pour chaque canal de l'ordonnancement, disons le canal A, de la position de la première valeur nécessitant d'être stockée. Il s'agit de la première valeur VS de A située, dans le document 10, après la première valeur du canal ordonné après, noté canal B, et calculée lors de l'étape E325. 32 Le coût de stockage CA lié au canal A correspond au stockage de l'ensemble des valeurs du canal A qui sont situées après VS dans le document 10, y compris VS. On réalise ce calcul pour chacun des canaux de l'ordonnancement, puis on additionne ces différents coûts individuels Ci pour obtenir un coût global de l'ordonnancement CGordonnancement. On constate ici que ce coût global n'est qu'une approximation du pic de consommation mémoire que le décodeur peut subir. En effet, dans les calculs proposés on ne tient pas compte du temps au cours duquel des valeurs stockées d'un canal précédent sont supprimées de la mémoire avant de stocker un canal ultérieur. A titre d'exemple, dans le cas où l'on souhaite déterminer la meilleure position d'un canal A parmi 4 canaux prioritaires (A, B, C et D), on va calculer le coût de codage pour les 4 configurations d'ordonnancements (ABCD, BACD, BCAD, BCDA). On détermine alors la position de la première valeur VS du canal suivant le canal A (B pour la première configuration; C pour la deuxième configuration; D pour la troisième configuration, et pas de canal et de valeur VS donc pas de stockage pour la quatrième configuration). On calcule alors le coût CA lié au canal A pour chacune de ces configurations. On peut procéder de la même façon pour les canaux B, C et D pour obtenir CB, Cc et CD. Pour chaque ordonnancement, on additionne alors les coûts CA à CD liés à chacun des canaux de l'ordonnancement. A l'issue de l'étape E330, on dispose ainsi d'un coût global CGordonnancement i de stockage estimé pour chacun des ordonnancements 'i' possibles entre les canaux sélectionnés à l'étape E320. On poursuit alors, à l'étape E335, par la détermination des priorités de chaque canal en fonction des coûts estimés à l'étape E330. Pour ce faire, on sélectionne l'ordre minimisant le coût global de stockage des canaux sélectionnés, c'est-à-dire offrant le meilleur gain de stockage au niveau du décodeur: min { CGordonnancementi }. Dans le cas où plusieurs groupes de canaux sont disjoints comme évoqué précédemment, il est entendu qu'on traite chacun de ces groupes indépendamment en conservant néanmoins l'ordre de ces groupes de canaux similaire à leur ordre d'apparition dans le document. Par ailleurs, chaque canal est ordonné, à l'intérieur de son groupe, selon l'ordonnancement minimisant le coût de stockage. On en déduit alors l'ordre de l'ensemble des canaux. Cela est illustré par la figure 5bis. A partir de cet ordre minimisant le coût de stockage, on calcule les priorités à affecter à chaque canal. A titre d'exemple, tant que les canaux de valeurs ainsi traités suivent l'ordre des noms qualifiés correspondants déterminé dans les informations de structure (même si certains noms qualifiés des informations de structure ne sont pas pris en compte, leur canal ayant été déplacé comme décrit ci-après), aucune priorité n'est affectée à ces canaux. On économise ainsi des informations de priorités à coder dans le flux final lors de l'étape El 20. En revanche, dès qu'un canal dans le nouvel ordre se trouve être déplacé par rapport à l'ordre initial du document 10 (en d'autres termes, si la première occurrence de son nom qualifié dans les informations de structure ne se réalise pas à la suite de celles des canaux précédemment parcourus), on affecte une valeur de priorité à ce canal, valeur que l'on incrémente de canal en canal. Ainsi, chaque canal de priorité se retrouve avec une priorité différente. On observera que, selon le nombre de canaux sélectionnés à l'étape E320, les étapes E325, E330 et E335 peuvent représenter un coût de calcul important, notamment en raison du nombre de combinaisons de canaux. Généralement un nombre de canaux sélectionné inférieur ou égal à 4 est considéré comme raisonnable avec un coût de calcul raisonnable. Au-delà, on peut modifier ces étapes afin de réduire ces coûts, au détriment parfois de l'optimum du nouvel ordre des canaux. On peut par exemple procéder de la sorte : - on débute par définir un ordre initial de l'ensemble des canaux de valeurs 14. Typiquement, il peut s'agir de l'ordre naturel défini par les informations de structure 12 (c'est-à-dire par le document 10); - ensuite, on détermine la meilleure position du premier canal, noté A, en testant l'échange de ce canal A avec son voisin suivant, noté B. Ce test consiste à comparer le besoin en stockage si A est avant B ou si B est avant A. Pour ce faire: o on détermine la position VS de la première valeur de A située après la première valeur de B dans le document 10; o on calcule le coût de stockage correspondant au stockage du canal A pour passer au décodage du canal B (si A est avant B): il s'agit du coût de stockage des valeurs du canal A dont la position est égale ou supérieure à VS. Le coût de chaque valeur peut être calculé de façon similaire à ce qui est décrit pour l'étape E310; o on récupère ou calcule le coût de stockage correspondant au stockage du canal B lorsqu'on passe au décodage du canal A (si B est avant A): il s'agit du coût de stockage de toutes les valeurs du canal B si B est initialement après 1. Ce coût a notamment été calculé à l'étape E315; o on compare ces deux coûts: si le coût de stockage lié à A est supérieur au coût de stockage lié à B, on inverse A et B et on continue à tester l'échange de ce canal A avec son voisin suivant, noté C. Dans ce cas, le coût de stockage à comparer avec celui de A est la somme des coûts de stockage de B et C car ces canaux doivent être tous deux stockés avant d'obtenir les valeurs décodées du canal A pour compléter les balises ou événements. On itère, si nécessaire, avec les canaux suivants D, E, etc... en comparant le coût de stockage de A avec la somme des coûts de stockage des autres canaux. On itère le processus sur chaque canal pour obtenir l'ordre final. Il est aussi possible d'utiliser d'autres heuristiques permettant d'obtenir un ordre des canaux et déterminer ainsi les priorités de chaque canal. C'est notamment le cas du regroupement de canaux selon le critère d'enchevêtrement pour procéder à des calculs indépendants sur ces groupes. Dans une variante, on peut grouper les canaux en groupes de canaux dont la taille est sensiblement équivalente: par exemple les 'petits' canaux d'un côté et les 'gros' canaux de l'autre. On peut par exemple diviser l'ensemble des canaux en deux groupes égaux ou utiliser d'autres critères. On place alors le groupe de petits canaux avant celui des gros canaux. Au sein de chaque groupe de canaux, on ordonne les canaux suivant leur ordre d'apparition dans les informations de structure: l'ordre des `petits' canaux les uns par rapport aux autres est défini par les informations de structure 12. Idem pour les 'gros' canaux. Optionnellement, on peut ordonner les groupes suivant leur taille moyenne. Suivant cet ordre résultant, on attribue des priorités aux canaux qui ont finalement été déplacés par rapport à l'ordre initial. A l'issue de l'étape E335, on dispose ainsi d'un nouvel 10 ordonnancement des canaux de valeurs 14 considérés comme prioritaires, dont on connaît un coût global estimé de stockage. On décrit maintenant la troisième grande étape de la détermination des priorités E110, qui est optionnelle et consiste en l'amélioration de l'ordre des valeurs au sein des canaux ainsi ordonnés. On applique cette grande étape 15 par exemple lorsque l'ordre optimal des canaux déterminé précédemment ne permet pas d'avoir un coût global de stockage inférieur à l'espace mémoire disponible au niveau du décodeur. Cette étape se décompose en deux sous-étapes, elles-mêmes optionnelles: l'unification de canaux et la séparation de canaux. 20 Suite à l'étape E335, on teste la possibilité d'unifier des canaux 14 à l'étape E340. Cela consiste à déterminer si le fait de fusionner des canaux entre eux fait diminuer le coût global de stockage. En effet, par exemple si un document présente une alternance de données de deux noms qualifiés, le canal du premier nom qualifié doit être décodé en entier, et donc stocké, pour 25 procéder au décodage du second canal. Or, puisqu'il s'agit d'une alternance de données de ces deux canaux, s'ils sont unifiés en un seul, toutes ces données seront décodées et exploitées directement au fur et à mesure du décodage de ce canal unifié, sans qu'un stockage même partiel de celui-ci soit réalisé. C'est notamment le cas pour des dessins vectoriels où une abscisse 'x' est toujours 30 liée à une ordonnée 'y'. On peut, pour tester cette possibilité, combiner plusieurs critères. D'une part, on estime le degré d'entremêlement des canaux. Pour ce faire, on réutilise les résultats de répartition des canaux de l'étape E325 pour déterminer les candidats : plus les valeurs de canaux sont entremêlées, plus on souhaite unifier les canaux. Une valeur d'entremêlement peut être le nombre de valeurs de A comprises entre au moins deux valeurs de B ajouté au nombre de valeurs de B comprises entre au moins deux valeurs de A. D'autre part, on vérifie que les valeurs des canaux se ressemblent suffisamment pour être regroupées et permettre une compression du flux binaire suffisamment efficace. On tient alors éventuellement compte du type des valeurs (chaîne de caractère, entier, etc.) des canaux 14 considérés pour n'unifier que des canaux ayant le même type de valeurs. Lorsqu'une ou plusieurs décisions d'unification de canaux 14 sont prises (sortie oui de l'étape E340, par exemple deux canaux stockant des chaînes de caractères et ayant au moins la moitié de leurs valeurs qui sont entremêlées), on réalise cette unification en regroupant les valeurs des canaux dans un même canal tout en conservant le même ordre des valeurs que celui de l'apparition de celles-ci dans le document 10. On modifie alors, à l'étape E345, les priorités des canaux d'une même unification en leur affectant la même valeur, par exemple en conservant la plus grande des deux priorités qui étaient affectées aux canaux avant unification. On détermine alors le nouveau coût global de stockage mémoire, en tenant compte du fait que plusieurs unifications peuvent avoir été menées, par exemple en réalisation à nouveau les calculs de coût décrits précédemment. Si celui-ci est trop important (coût global de stockage > maximum autorisé), on peut alors décider de scinder un ou plusieurs canaux 14 en différentes parties (généralement 2), ce que l'on teste à l'étape E350. Comme critère de séparation, on peut par exemple utiliser le coût de stockage maximal. Ainsi, on sélectionne le canal prioritaire 14 dont le coût de stockage (comme calculé à l'étape E310) est le plus élevé. Dans l'affirmative, à l'étape E355, on détermine alors les positions de séparation des canaux, puis on le scinde en deux parties de valeurs contiguës ou plus, par exemple de tailles sensiblement équivalentes. On détermine alors la position du nouveau canal ainsi créé (correspondant à la deuxième partie des valeurs) et on détermine le nouveau coût de stockage global en le recalculant pour chacun des (sous)-canaux ainsi créés. On itère ensuite le processus jusqu'à obtenir un coût global de stockage acceptable, notamment inférieur à l'espace mémoire maximal préfixé. On décrit plus loin, en référence à la figure 7, un mode de réalisation particulier de l'invention mettant en oeuvre de telles opérations de séparation des canaux. L'algorithme se termine alors à l'étape E360. En variante, on peut réaliser les étapes E350 et E355 avant les étapes E340 et E345. On peut aussi évaluer les possibilités de gain par unification de canaux et les possibilités de gain par séparation de canaux, puis les comparer avant de procéder soit à l'unification de canaux, soit à la séparation de canaux, selon laquelle est la plus avantageuse. Par ailleurs, on rappelle que ces opérations de séparation et d'unification de canaux peuvent être menées lors de l'étape E140. Comme évoqué précédemment pour l'étape E120, on peut, pour renseigner le nouvel ordre des canaux, modifier le canal de structure 12 de telle sorte que les premières occurrences de types d'informations de structure dans ce canal sont dans le même ordre que les canaux de valeurs correspondants selon le ré-ordonnancement des canaux. La figure 6 décrit un mode de réalisation de l'algorithme d'encodage mettant en oeuvre une telle modification du canal de structure 12 pour indiquer 25 ce ré-ordonnancement. On notera tout d'abord que, dans cette réalisation, les canaux de même priorité ne sont pas fusionnés en un seul canal, mais sont encodés séparément dans l'ordre des données du document 10. On commence alors à l'étape E400 par récupérer les données à 30 encoder (similaire à l'étape E100), puis, à l'étape E410, on calcule les priorités des canaux de façon similaire à l'étape E110 telle que décrite précédemment en référence à la figure 5. Cette étape permet de récupérer l'ensemble des canaux avec priorité. On traite successivement chacun des canaux depuis ceux à faible priorité jusqu'à celui ayant la plus haute priorité (test à l'étape E420). Pour chaque canal à traiter, on récupère la liste ordonnée des canaux de valeurs 14 suivant les informations de structure à l'étape E430. Il s'agit de l'ordre initial des canaux. A l'étape E440, on récupère ensuite l'ensemble des canaux à faire apparaître, au sein des informations de structure 12, avant le canal de priorité à traiter. Pour ce faire: - on enlève, de la liste ordonnée, les canaux situés avant le canal à traiter; - on détermine ensuite, dans cette liste restante, le premier canal dont les valeurs ne sont pas entremêlées avec les valeurs du canal à traiter. On peut utiliser les informations issues de l'étape E325 de la figure 5; - on enlève alors de cette liste ce premier canal et les canaux suivants sans tenir compte des canaux ayant une priorité plus élevée que celle du canal en cours de traitement (ces canaux de plus haute priorité sont traités lors des itérations suivantes). Une fois la liste des canaux à faire apparaître connue, on ajoute, à l'étape E450, l'ensemble des noms qualifiés des canaux de cette liste aux informations de structure. Pour ce faire, on fait apparaître ces noms qualifiés avant la première occurrence du ou des canaux à déplacer (ceux ayant une priorité). En reprenant l'exemple de la figure 1, on ajoute alors un nouvel élément factice 'VELT' qui possède les attributs `style', 'x', 'y' et 'xlink:href avant l'apparition de l'attribut 'd' correspondant au canal à déplacer (voir la ligne en gras de la figure l h). Lors de l'ajout de ces noms qualifiés (sous l'élément factice 'VELT' dans l'exemple), on modifie également les canaux de ces noms qualifiés en y ajoutant une valeur factice, en première position, de sorte que le décodage de la ligne ajoutée dans les informations de structure vienne consommer ces valeurs factices lors du décodage et non les valeurs des canaux réellement issues du document 10. A noter, dans l'exemple ci-dessus, que l'attribut 'rx' n'est pas à faire apparaître car le canal 'rx' n'est pas entremêlé avec le canal 'd', et est donc traité séparément. Cela correspond notamment au cas évoqué précédemment dans lequel on souhaite mettre en oeuvre des groupes de canaux indépendants. Ainsi, plusieurs éléments factices peuvent être introduits dans les informations de structure pour organiser le ré-ordonnancement de chacun des groupes. On obtient ainsi les canaux représentés sur la figure 1f. Une fois l'ensemble des canaux avec priorité traités, on passe à l'étape E460 consistant à encoder les informations de structure telles que modifiées durant l'étape E450. Cette étape est similaire à l'étape El 30. On encode ensuite, à l'étape E470, les valeurs des canaux 14 suivant l'ordre des canaux désormais défini par les informations de structure 12 (incluant tous les canaux, avec ou sans priorité). Il s'agit donc d'un encodage classique. Le processus d'encodage se termine alors à l'étape E480. Cette réalisation avec modification des informations de structure permet de concentrer l'ensemble des moyens de l'invention au niveau de l'encodeur et de générer un flux standard sans extension et compatible avec les décodeurs type EXI classiques. On veillera cependant à ce que le format des données et l'application de traitement au niveau du décodeur acceptent des ajouts d'éléments, ici l'élément factice 'VELT'. Typiquement, cet élément 'VELT' se trouvera dans un espace de nommage différent de ceux utilisés par les données encodées. On peut aussi implémenter cet algorithme de manière à ne pas modifier l'encodeur. Pour ce faire, on met, entre l'application qui génère les données à encoder et l'encodeur, une entité de prétraitement prévue pour modifier les données XML avant encodage afin d'obtenir l'ordre des canaux souhaité. Cette entité effectue alors les étapes E400 à E440 de manière similaire. L'étape E450 consiste ensuite à modifier les données XML en insérant les informations d'ordonnancement sous la forme d'un élément XML (VELT'). Le travail de l'entité de prétraitement est alors terminé et les étapes E460 et E470 sont effectuées par un encodeur standard. Comme évoqué précédemment, la figure 7 présente un mode de réalisation de l'encodage selon l'invention dans lequel une séparation de canaux de valeurs 14 est menée. Le principe de ce mode de réalisation est de considérer que chaque canal 14 ayant une priorité peut être encodé en plusieurs parties dans différents endroits dans le flux binaire EXI généré par l'invention. La séparation d'un canal en plusieurs sous-parties peut résulter de plusieurs motivations. Tout d'abord, plusieurs canaux ayant une priorité peuvent être déterminés sans possibilité de les fusionner (notamment si le coût de fusion en terme d'efficacité de compression est rédhibitoire). Dans ce cas, on doit stocker partiellement certains de ces canaux 14 dans l'attente du décodage des canaux suivants. Il peut alors s'avérer utile de séparer un ou plusieurs canaux ayant une priorité pour permettre une mise en mémoire des valeurs moins conséquente. D'autre part, on peut envisager l'application de cette méthode lorsque les données d'un document 10 sont à conserver et à traiter par blocs indépendants. Du fait de cette indépendance, il s'avère efficace de faire coïncider ces blocs de données avec les canaux de valeurs pour optimiser l'utilisation mémoire. Par exemple, le profil SVG printing définit un élément `ensemble de pages' et un élément `page'. Chaque élément `page' contient les informations graphiques à imprimer sur une page alors que plusieurs pages mettent en oeuvre de mêmes noms qualifiés. En mettant en oeuvre une séparation des canaux par page, le dispositif d'impression qui reçoit des données suivant ce profil peut alors traiter chaque élément `page' indépendamment, sans avoir à stocker temporairement des informations relatives à des pages ultérieures. Egalement, le format EXI propose l'option de codage `SELF CONTAINED' qui permet d'encoder des éléments sans faire appel à l'historique passé des données (soit le début du document). Ainsi, du fait de l'indépendance des éléments codés `SELF CONTAINED' au regard du reste du document 10, il s'avère efficace encore une fois de séparer les canaux selon les limites de ces éléments. Toutefois, comme il n'est pas toujours intéressant d'effectuer de telles séparations pour chaque canal de valeurs 14, on limite cette séparation aux seuls canaux ayant une priorité. En détails, la séparation d'un canal 14 en sous-canaux se passe comme suit : - décision d'un endroit où séparer un canal en deux parties, généralement aux frontières des blocs indépendants (page, élément 'SELF CONTAINED', etc.); - encodage de la première partie à l'endroit déterminé par les informations de structure; - encodage d'un symbole précisant que ce canal a été scindé; - détermination de la position de la deuxième partie, généralement en fonction des informations de structure, pour permettre un décodage le plus simple possible; et - encodage de la deuxième partie à l'endroit de cette position déterminée. Il est entendu qu'un sous-canal peut itérativement être scindé à nouveau. En référence à la figure 7, l'encodage commence, à l'étape E500, par la récupération des données à encoder. A l'étape E510, on détermine et encode les informations de structure 12 ainsi que les informations de priorité. Les étapes E520 à E590 réalisent ensuite la séparation de certains canaux. Dans le cas où l'on traite l'ensemble des canaux par groupes disjoints indépendants, on applique ces étapes E520 à E590 à chacun des groupes. Ainsi, on récupère, à l'étape E520, la liste des canaux de valeurs à encoder telle qu'ordonnée par l'invention selon les priorités, cette liste incluant l'ensemble des canaux avec et sans priorité, les canaux avec priorité se trouvant à la fin des canaux sans priorité. On encode ensuite successivement chaque canal. Pour ce faire, on teste s'il reste un canal avec des valeurs à encoder (étape E530). Si oui, on détermine, à l'étape E540, si ce canal est prioritaire et si une séparation des valeurs de ce canal est à effectuer. Comme décrit précédemment, cette décision peut être basée sur la présence d'éléments 'SELF CONTAINED' ou d'éléments traités de manière séparée (éléments `page' dans un processus d'impression par exemple), ou selon un critère de stockage mémoire maximum comme explicité aux étapes E350-E355 de la figure 7. Dans l'affirmative du test E540, on segmente le canal prioritaire à encoder selon le critère de séparation, en autant de sous-canaux qu'il est nécessaire. On note en particulier qu'en présence d'un élément 'SELF CONTAINED', il convient de prévoir un sous-canal pour les valeurs apparaissant dans cet élément, et un ou deux sous-canaux (selon que l'on souhaite fusionner ceux-ci) pour les valeurs apparaissant avant et après cet élément. Chaque sous-canal comprend les valeurs du canal d'origine dans l'ordre du document 10. On encode alors les valeurs du premier sous-canal formé et un symbole de fin de sous-canal, à l'étape E570. On met ensuite à jour la liste des canaux à encoder (étape E580), en réinsérant le ou les sous-canaux restants dans la liste, soit à la fin de cette liste ou selon l'ordre défini par les informations de structure. Dans ce dernier cas, il faut donc parcourir les informations de structure pour déterminer la position de la première valeur du ou des sous-canaux restants et déterminer la position du ou des sous-canaux dans la liste à partir de cette position. On notera que cette séparation des canaux peut être menée au moment de la création des canaux. Si le canal n'est pas à séparer ou est non prioritaire (sortie non du test E540), on encode toutes les valeurs du canal d'un coup (étape E550) et on supprime ce canal de la liste des canaux à encoder (étape E560). Une fois la liste des canaux vide, l'algorithme se termine (étape E590). Les différentes réalisations d'encodage décrites ci-dessus permettent d'obtenir un flux compressé, par exemple de type EXI, dans lequel les canaux de valeurs 14 ont été ré-ordonnés par rapport à l'ordre initial du document 10. Ces informations de ré-ordonnancement sont soit disponibles dans l'en-tête du flux EXI 20, soit prennent la forme d'informations factices de structure dans le canal de structure 12. Certains canaux ont pu être fusionnés ou séparés. On décrit maintenant en référence à la figure 8 les étapes générales de décodage en mode streaming d'un tel flux EXI, étant entendu que lorsque l'on modifie, au codage, les informations de structure 12 pour indiquer le ré-ordonnancement (figure 6), ce décodage est classique selon la recommandation EXI. On commence à l'étape E600 par récupérer les données à décoder. Aux étapes E610 et E620, on décode les informations de priorité et de structure. Ces étapes sont le pendant des étapes El 20 et El 30 du codage. Selon que les informations de priorité sont dans l'en-tête du flux codé EXI ou que le ré-ordonnancement est indiqué sous la forme d'informations de structure supplémentaires, ces étapes peuvent être successives ou simultanées. Dans le cas par exemple des informations de priorité récupérées dans l'en-tête du flux EXI, les informations de structure 12 donnent un ordre initial des canaux de valeurs correspondant à l'ordre du document XML 10, mais pas à l'ordre de codage effectif dans le flux EXI du fait du ré-ordonnancement selon l'invention. On poursuit donc à l'étape E630 par la détermination de l'ordre des canaux de valeurs 14 dans ce flux EXI. Cette détermination est similaire à celle décrite pour l'étape E140 en référence à la figure 4. Elle se base notamment sur les informations de priorité récupérées dans l'en-tête. Cette étape n'est pas réalisée dans le cas où le ré-ordonnancement est indiqué au travers des informations de structure 12. Dans ce cas, le décodage du flux est un décodage EXI classique, l'ordonnancement des canaux lors du codage assurant une utilisation efficace de la mémoire du décodeur. Une fois l'ordre des canaux établi, on décode les valeurs de chaque canal. Pour permettre un traitement efficace des données en vue de leur exploitation par une application informatique, on envoie les événements ou des suites d'événement (balises) dès qu'ils sont complétés (c'est-à-dire que toutes les données les composant sont décodées). Ainsi, dans le cas d'une interface par flux (Stax, SAX...), on envoie l'événement suivant dès qu'il est complété. Dans le cadre d'une interface par arbre ou par structure, on peut envoyer, à l'application, des suites d'événements correspondant à une sous-partie complète de l'arbre ou de la structure. Le procédé prévoit ainsi de décoder successivement les valeurs des canaux 14 dans l'ordre déterminé à l'étape E630. Ainsi, tant qu'il reste une valeur à décoder (test de l'étape E640), on la décode à l'étape E660 et on la stocke dans la mémoire du décodeur. Une fois la valeur décodée, on affecte cette valeur à l'événement correspondant lors de cette même étape. On teste alors si un ou plusieurs événements peuvent être envoyés à l'étape E670, par exemple une balise complète. Si tel est le cas, on effectue l'envoi de ces données décodées à l'application qui va les traiter à l'étape E680, et on peut supprimer, de la mémoire du décodeur, les valeurs utilisées pour cet événement envoyé, notamment si elles ne servent pas pour l'indexation de valeurs ultérieures. On itère ainsi jusqu'à décoder toutes les valeurs et arriver à la fin du décodage (étape E650). En envoyant les événements décodés à l'application lors de l'étape E680 alors même que les valeurs suivantes ne sont pas décodées, on permet 30 le traitement en mode streaming du document codé EXI. En référence maintenant à la figure 9, on décrit le décodage dans le cas particulier où les canaux ont été séparés en plusieurs sous-canaux lors de l'encodage (cas de la figure 7 précédemment décrite). Le décodage commence à l'étape E700 par la récupération des 5 données codées EXI dans le flux codé. A l'étape E710, on décode les informations de structure 12 du flux EXI, et éventuellement celles de priorité, de façon similaire aux étapes E610-E620. A l'étape E720, on récupère ensuite la liste ordonnée des canaux de 10 valeurs 14 à décoder, de façon similaire à l'étape E630. On débute ensuite le décodage de chaque canal comme suit. Tant qu'il reste des canaux à décoder (test de l'étape E730), on détermine si le canal est séparé ou pas à l'étape E740. Cette détermination peut se faire en décodant un symbole particulier de séparation durant le 15 décodage des valeurs du canal ou peut provenir d'une source d'information externe (les informations de structure par exemple). On peut en effet établir une règle précisant que chaque canal ayant une priorité et des valeurs séparées par un événement SELF CONTAINED ou n'étant pas enfant d'un même élément (`page' par exemple) doit être séparé. 20 Si ce canal a des valeurs séparées, on décode alors les valeurs contiguës du canal à l'étape E770 en les enregistrant dans la mémoire du décodeur et/ou en les exploitant immédiatement si un événement peut être envoyé à l'application informatique de traitement. On met alors à jour, à l'étape E780, la liste des canaux à décoder de manière similaire à l'étape E580. 25 Si le canal n'est pas séparé, on décode l'ensemble des valeurs du canal à l'étape E750 en les mémorisant dans la mémoire du décodeur et/ou en les exploitant, et on supprime le canal de la liste des canaux à décoder à l'étape E760. Bien entendu, lors du décodage E750 ou E770, on met en relation 30 les valeurs décodées avec les événements correspondants, et on transmet un événement ou une balise à l'application de traitement dès complétude de cet événement/balise. On supprime de la mémoire du décodeur les valeurs utilisées pour ces événements/balises alors envoyées lorsqu'elles ne sont pas utilisées pour l'indexation d'événements ultérieurs. Lorsque la liste est vide, l'algorithme se termine (étape E790). On note que dans le cas de canaux fusionnés, les informations de priorité dans l'en-tête indiquent par exemple que les deux canaux A et B sont fusionnés. Ainsi le décodage du flux EXI reste tel que décrit précédemment en considérant désormais que les noms qualifiés 'a' et 'b' correspondent au même canal. En référence maintenant à la figure 10, il est décrit à titre d'exemple une configuration matérielle particulière d'un dispositif de codage ou décodage d'un document structuré apte à une mise en oeuvre du procédé selon l'invention. Un dispositif de traitement d'information mettant en oeuvre l'invention est par exemple un micro-ordinateur 50, une station de travail, un assistant personnel, ou un téléphone mobile connecté à différents périphériques. Selon encore un autre mode de réalisation de l'invention, le dispositif de traitement d'information se présente sous la forme d'un appareil photographique muni d'une interface de communication pour autoriser une connexion à un réseau. Les périphériques reliés au dispositif de traitement d'information comprennent par exemple une caméra numérique 64, ou un scanner ou tout autre moyen d'acquisition ou de stockage d'images, relié à une carte d'entrée/sortie (non représentée) et fournissant au dispositif de traitement d'information des données multimédia, éventuellement sous forme de documents XML. Le dispositif 50 comporte un bus de communication 51 auquel sont reliés : - une unité centrale de traitement CPU 52 se présentant par exemple sous la forme d'un microprocesseur ; - une mémoire morte 53 dans laquelle peuvent être contenus les 30 programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. Il peut s'agir d'une mémoire flash ou EEPROM; - une mémoire vive 54 qui, après la mise sous tension du dispositif 50, contient le code exécutable des programmes de l'invention nécessaires à la mise en oeuvre de l'invention. Cette mémoire vive 54 est de type RAM (à accès aléatoire), ce qui offre des accès rapide comparés à la mémoire morte 53. Cette mémoire RAM 54 mémorise en particulier les canaux de valeurs et les valeurs décodées des canaux au fur et à mesure des traitements (encodage et décodage) sur les documents XML. Dans le cadre de l'invention, c'est cette mémoire RAM 54 du dispositif décodeur qui constitue une limitation des capacités mémoires, notamment car elle est embarquée dans des dispositifs mobiles de faibles dimensions tels des téléphones portables ou appareils photographiques; - un écran 55 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui peut ainsi interagir avec les programmes de l'invention, à l'aide d'un clavier 56 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 57 ou un crayon optique ; - un disque dur 58 ou une mémoire de stockage, telle qu'une mémoire de type compact flash, pouvant comporter les programmes de l'invention ainsi que des données utilisées ou produites lors de la mise en oeuvre de l'invention; - un lecteur de disquettes 59 optionnel, ou un autre lecteur de support de données amovible, adapté à recevoir une disquette 63 et à y lire / écrire des données traitées ou à traiter conformément à l'invention ; et - une interface de communication 60 reliée au réseau de télécommunications 61, l'interface 60 étant apte à transmettre et à recevoir des données. Le bus de communication 51 autorise une communication et une interopérabilité entre les différents éléments inclus dans le dispositif 50 ou reliés à celui-ci. La représentation du bus 51 n'est pas limitative et, notamment, l'unité centrale 52 est susceptible de communiquer des instructions à tout élément du dispositif 50 directement ou par l'intermédiaire d'un autre élément du dispositif 50. Les disquettes 63 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par un microprocesseur, intégré ou non au dispositif de codage ou décodage d'un document structuré, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention. Le code exécutable permettant au dispositif de codage ou décodage d'un document structuré la mise en oeuvre de l'invention peut être indifféremment stocké en mémoire morte 53, sur le disque dur 58 ou sur un support numérique amovible tel que par exemple une disquette 63 comme décrite précédemment. Selon une variante, le code exécutable des programmes est reçu par l'intermédiaire du réseau de télécommunications 61, via l'interface 60, pour être stocké dans un des moyens de stockage du dispositif 50 (tel que le disque dur 58 par exemple) avant d'être exécuté. L'unité centrale 52 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes de l'invention, les instructions ou portions de code logiciel étant stockées dans l'un des moyens de stockage précités. Lors de la mise sous tension du dispositif 50, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 58 ou la mémoire morte 53, sont transférés dans la mémoire vive 54 qui contient alors le code exécutable du ou des programmes de l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. On notera également que le dispositif mettant en oeuvre l'invention ou incorporant celle-ci est réalisable aussi sous la forme d'un appareil programmé. Par exemple, un tel dispositif peut alors contenir le code du ou des programmes informatiques sous une forme figée dans un circuit intégré à application spécifique (ASIC). Le dispositif décrit ici et, particulièrement, l'unité centrale 52, sont susceptibles de mettre en oeuvre tout ou partie des traitements décrits en lien avec les figures 1 à 9, pour mettre en oeuvre les procédés objets de la présente invention et constituer les dispositifs objets de la présente invention. Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas. REVENDICATIONS1. Procédé de codage d'un document structuré (10) composé d'événements à coder présentant des valeurs, comprenant les étapes suivantes: - constituer des canaux de valeurs (14) regroupant des valeurs d'événements selon au moins un critère (qname), lesdits canaux étant ordonnés selon un premier ordre correspondant à l'ordre d'apparition de leur première occurrence de valeur dans le document structuré (10); - ré-ordonner (E140) au moins une partie desdits canaux de valeurs (14) selon un deuxième ordre, en fonction d'informations représentatives, chacune, de l'espace mémoire nécessaire au stockage des valeurs de chaque canal de valeurs ; et - coder (E150, E470, E550, E570) les canaux de valeurs (14) selon ledit deuxième ordre, en un flux codé (20). 2. Procédé de codage selon la revendication 1, comprenant: - le calcul (E330) d'une valeur estimée d'occupation mémoire pour une pluralité d'ordres des canaux de valeurs, - la détermination, comme ordre de ré-ordonnancement, de l'ordre des canaux présentant la valeur estimée minimale. 3. Procédé de codage selon la revendication 2, dans lequel ledit calcul d'une valeur estimée pour un ordre comprend l'estimation d'un coût de stockage individuel associé à au moins un canal de valeurs (E330), le coût de stockage individuel d'un premier canal précédant (A), dans ledit ordre, un canal suivant (B), correspondant au coût de stockage de l'ensemble des valeurs dudit premier canal postérieures, dans ledit document structuré, à la première valeur du canal suivant. 4. Procédé de codage selon la revendication 1, dans lequel ledit ré-ordonnancement comprend l'interversion itérative d'au moins un canal de valeurs avec un canal de valeurs voisin à partir d'un ordre initial desdits canaux de valeurs. 5. Procédé de codage selon la revendication précédente, dans lequel l'interversion itérative comprend, pour chaque canal de valeurs considéré: - l'évaluation de l'opportunité d'intervertir ledit canal de valeurs avec le canal voisin suivant, en comparant un coût de stockage individuel associé audit canal de valeurs considéré avec un coût de stockage individuel associé audit canal de valeurs voisin; - en cas d'évaluation positive, intervertir les deux canaux de valeurs et itérer ladite évaluation avec le nouveau canal de valeurs voisin suivant, en comparant le coût de stockage individuel associé au premier canal considéré alors interverti avec la somme des coûts de stockage individuel associé aux canaux voisins déjà intervertis et au nouveau canal voisin. 6. Procédé de codage selon l'une des revendications 1 à 5, comprenant l'indication, dans le flux codé contenant les canaux codés, d'une information de ré-ordonnancement desdits canaux codés. 7. Procédé de codage selon la revendication précédente, dans lequel ladite information de ré-ordonnancement est codée dans l'en-tête du flux codé (20), et comprend une information de priorité d'une pluralité de canaux définissant relativement un ordre desdits canaux. 8. Procédé de codage selon l'une des revendications 1 à 5, dans lequel les canaux de valeurs (14) regroupent, chacun, les valeurs des événements correspondants à un même type d'information de structure (qname), et le procédé comprenant la constitution (E450) d'un canal de structure (12) répertoriant des informations de structure de telle sorte que les premières occurrences de types d'informations de structure dans ce canal de structure sont dans le même ordre que les canaux de valeurs correspondants à ces types d'informations selon ledit deuxième ordre. 9. Procédé de codage selon la revendication précédente, dans lequel ladite constitution (E450) du canal de structure (12) comprend: - l'ajout, dans un canal de structure répertoriant, dans ledit premier ordre, les informations de structures du document structuré, d'au moins uneinformation de structure factice (VELT) indiquant, avant la première occurrence d'un type d'information de structure correspondant à un canal déplacé dans ledit ré-ordonnancement, des premières occurrences des types d'informations de structure correspondants à des canaux de valeurs précédant ledit canal déplacé, - l'ajout, dans les canaux de valeurs (14) précédant le canal déplacé, d'une valeur factice. 10. Procédé de codage selon la revendication précédente, dans lequel - la formation du canal de structures (12) répertoriant les informations de structures et la constitution des canaux de valeurs (14) selon le premier ordre sont mises en oeuvre par une premier moyen de génération de données à encoder; - lesdits ajouts d'informations et de valeurs factices sont mis en oeuvre sur lesdites données à encoder, par un moyen distinct de prétraitement; et - ledit codage est mis en oeuvre sur les données issues du prétraitement, par un moyen de codage. 11. Procédé de codage selon l'une des revendications précédentes, 20 comprenant: - la séparation (E355, E570) d'un canal de valeurs (14) en au moins deux sous-canaux, et - la modification (E580) dudit deuxième ordre pour faire apparaître les deux sous-canaux, le premier sous-canal conservant la position dudit 25 canal de valeurs séparé, et le deuxième sous-canal prenant une position correspondant à la position de sa première valeur dans le document structuré. 12. Procédé de codage selon la revendication précédente, dans lequel un emplacement de séparation du canal de valeurs correspond à la limite 30 d'un bloc de données prédéterminé dans ledit document structuré. 13. Procédé de codage selon la revendication 11 ou 12, dans lequel on encode lesdits sous-canaux obtenus et on insère au moins une indication de séparation d'un canal à la fin d'un sous-canal encodé. 14. Procédé de codage selon l'une des revendications précédentes, comprenant la fusion (E345) d'au moins deux canaux de valeurs (14) en un unique canal dont les valeurs suivent leur ordre dans le document structuré. 15. Procédé de codage selon la revendication précédente, dans lequel ladite fusion (E345) d'au moins deux canaux de valeurs est opérée selon un critère d'entremêlement desdits au moins deux canaux de valeurs. 16. Procédé de codage selon l'une des revendications précédentes, comprenant: - la sélection (E320), parmi lesdits canaux de valeurs, d'un ensemble de canaux (14) dont l'espace mémoire nécessaire au stockage de leurs valeurs est supérieur à une valeur prédéterminée; - l'association (E335), à chaque canal sélectionné, d'une valeur de priorité représentative dudit espace mémoire nécessaire au stockage de ses valeurs, et ledit ré-ordonnancement étant relatif aux valeurs de priorité. 17. Procédé de codage selon la revendication 16, dans lequel lesdits canaux de valeurs sélectionnés, ordonnés relativement auxdites valeurs de priorité, sont disposés à la suite des canaux de valeurs non sélectionnés ordonnés selon l'ordre d'apparition de leur première occurrence dans le document structuré. 18. Procédé de décodage d'un flux codé (20) correspondant à un 25 document structuré (10), comprenant les étapes suivantes: - récupérer (E600, E700) des données à décoder correspondant à plusieurs canaux codés de valeurs (14); - déterminer un ordre initial desdits canaux de valeurs; - récupérer, dans ledit flux codé, une information de ré-30 ordonnancement desdits canaux de valeurs; - modifier (E630) l'ordre des canaux de valeurs conformément à ladite information de ré-ordonnancement; et- décoder (E660, E750, E770) les valeurs codées selon l'ordre modifié desdits canaux de valeurs. 19. Procédé de décodage selon la revendication précédente, dans lequel ledit décodage des valeurs codées d'un canal de valeurs comprend: - la récupération, dans le flux codé, d'une information indiquant que ledit canal est séparé en au moins deux sous-canaux de valeurs; - le décodage (E770) des valeurs contiguës correspondant à un sous-canal de valeurs; - la mise à jour (E780) d'une liste ordonnant lesdits canaux de valeurs par l'insertion de l'autre sous-canal. 20. Dispositif de codage d'un document structuré composé d'événements à coder présentant des valeurs, comprenant: - un moyen de constitution pour constituer des canaux de valeurs regroupant des valeurs d'événements selon au moins un critère, lesdits canaux étant ordonnés selon un premier ordre correspondant à l'ordre d'apparition de leur première occurrence de valeur dans le document structuré; - un moyen de ré-ordonnancement pour ré-ordonner au moins une partie desdits canaux de valeurs avant codage selon un deuxième ordre, en fonction d'informations représentatives, chacune, de l'espace mémoire nécessaire au stockage des valeurs de chaque canal de valeurs. - un moyen de codage pour coder les canaux de valeurs selon le deuxième ordre de ceux-ci, en un flux codé. 21. Dispositif de décodage d'un flux codé correspondant à un 25 document structuré, comprenant: - un premier moyen de récupération pour récupérer des données à décoder correspondant à plusieurs canaux codés de valeurs; - un moyen de détermination pour déterminer un ordre initial desdits canaux de valeurs; 30 - un second moyen de récupération pour récupérer, dans ledit flux codé, une information de ré-ordonnancement desdits canaux de valeurs;- un moyen de modification pour modifier l'ordre des canaux de valeurs conformément à ladite information de ré-ordonnancement; et - un moyen de décodage pour décoder les valeurs codées selon l'ordre modifié desdits canaux de valeurs. 22. Moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un système informatique, comprenant des instructions pour un programme informatique adapté à mettre en oeuvre le procédé de décodage ou de codage conforme à l'une quelconque des revendications 1 à 19, lorsque le programme est chargé et exécuté par le système informatique. 23. Produit programme d'ordinateur lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé de décodage ou de codage selon l'une quelconque des revendications 1 à 19, lorsqu'il est chargé et exécuté par le microprocesseur.