XML (eXtensible Markup Language), créé à partir de SGML par le W3C en février 1998, a le don de faire frémir les mondes de l’informatique, de la documentation, du commerce électronique et de l’Internet réunis. Et pour cause, cette technologie est à la fois riche de promesses (lire à ce sujet l’article incontournable de Jon Bosak et Tim Bray, respectivement président du groupe de coordination XML du Consortium W3C et coéditeur de la norme XML 1.0, paru en français sur le site de Pour la science) et souvent complexe à appréhender. Pour une raison simple : « XML, en soi ne sert à rien, explique Pierre Attar, consultant en ingénierie documentaire et fondateur de Mutu-XML (un projet soutenu par la FING). Les Américains en parlent comme une technologie de type « enabler ». Une technologie qui facilite quelque chose mais qui, en soi, ne fait rien. Comme un ordinateur : peut-on dire qu’un ordinateur sert à quelque chose ? Non. Il faut y intégrer des logiciels pour qu’il soit utile. XML est un standard d’échange universel d’information, une technologie qui facilite l’échange de données. »

Pour que XML serve à quelque chose il lui faut des feuilles de styles, des programmes spécifiques, mais surtout des modèles (DTD ou schéma) qui vont définir comment typer une information selon son contexte. Et là, les choses se compliquent car, du coup, il n’y a pas de modèle universel et il peut exister autant de modèles qu’il y a de domaines d’activités, de métiers, d’entreprises… « Parce que la seule chose qu’apporte XML c’est de dire : si, lors d’un transfert d’informations, on sait de quelle nature est une donnée autant le dire lors de sa création et les programmes qui la liront pourront alors l’utiliser au mieux, poursuit Pierre Attar. La force d’XML est alors de permettre de décrire ce que sont les choses du point de vue pertinent pour le concepteur et surtout pour le récepteur. Et c’est là où cela devient intéressant. Car qui définit la pertinence ? En tout cas, une chose est sûre, c’est que la pertinence n’est pas un concept universel. Dès qu’on commence à mettre en place des modèles, XML n’est plus une technologie universelle mais une technologie qui s’adresse à un ensemble de personnes, partenaires d’un échange. »

Prenons l’exemple du code d’un département : rien ne permet à un ordinateur de savoir si la donnée « 92 » est un prix, un kilométrage ou un département. XML se propose de reconnaître que 92, codé 92 dans un transfert, est bien un département. Pour ce faire, lors de l’échange, une information de structure est ajoutée  : « dept » identifie les caractères comme étant un département. Des programmes savent alors reconnaître cette information et la traiter comme telle.
Cependant, il faut que l’information de structure soit toujours la même, au risque de coder parfois 92, d’autres fois 92, ou encore 92. C’est l’objectif des modèles électroniques d’XML que de figer les règles et les vocabulaires utilisables dans les transferts.

Cependant, il ne faut pas oublier que la notion de département, elle-même, n’est pas universelle. Pour une DDE (direction départementale de l’équipement), le département est un territoire. Pour une université, « département » peut également être le mot désignant le lieu d’une discipline  : le département de sociologie, le département de physique, etc. On s’aperçoit alors que la modélisation des informations nécessaire à une DDE et à une université ne sera pas la même. Le modèle doit être connu et explicité.

Les enjeux des modèles sont donc fondamentaux. Sans eux, XML ne sert à rien. Mais où trouver ces modèles qui serviront de tronc commun pour que chacun puisse construire le sien propre, tout en laissant l’oportunité aux systèmes d’informations d’échanger au mieux ? Un projet est en cours afin de créer un répertoire francophone de modèles pour les applications d’XML. Lancé en janvier 2002 par Mutu-XML, Edifrance et le GFII (Groupement français de l’industrie de l’information), il entre dans une phase de consultation. Pierre Attar (Mutu-XML) nous détaille ce projet.

Avant d’aborder le projet de répertoire en lui-même, pouvez-vous nous expliquer le principe de modélisation ?

Pierre Attar : Une fois qu’on a dit qu’un modèle était une certaine vision, non objective, de l’information, l’activité de création d’un modèle consiste à définir ce que l’entreprise ou l’administration souhaite retenir de son information et ce qu’elle souhaite partager avec ses partenaires. Typiquement les industriels de l’aéronautique, qui souhaitent un modèle, disent : « mon environnement de travail concerne aussi bien le militaire que le civil. Je dois donc suivre telle et telle réglementation ». A partir de là on peut construire son modèle.
Après, il faut un modèle d’échange. Restons dans l’Après-Vente de l’industrie aéronautique : elle suit un modèle d’information (ATA 2100) qui définit la façon dont doivent être organisés les contenus d’une documentation technique, dans un échange entre un constructeur et une compagnie aérienne. Or, le constructeur a forcément beaucoup plus d’informations dans son propre modèle, puisqu’il fait du civil et du militaire. Il ne souhaitera donc pas partager toutes ses informations. De son côté, la compagnie aérienne a un modèle fondamentalement différent puisqu’elle prend du constructeur des informations pour ses utilisateurs de maintenance. C’est plus de l’opérationnel que du contractuel. L’information change alors de nature, et le modèle également. Pourtant ils ont besoin d’échanger l’info : les modèles publics d’échanges ne servent alors que le temps de l’échange.

L’activité de modélisation est alors fondée sur la compréhension de son organisation et sur des modèles des environnements existants. Si je suis constructeur automobile par exemple, je suis soumis à la réglementation de l’Union européenne. Une norme qui va imposer de classifier l’information en deux parties : celle nécessaire à la réparation du véhicule et celle concernant l’avantage concurrentiel et le savoir-faire industriel. Le volet savoir-faire industriel n’est pas soumis à l’obligation d’être partageable, le nécessaire à la réparation est, lui, obligatoire. Ce qui veut dire que chacun de mes paragraphes de documentation technique concernant une voiture devra être typé pour savoir s’il est lié, ou non, à du savoir-faire industriel, de façon à ne divulguer que le minimum d’information sur mon savoir-faire.
En fait, on a toujours fait des modèles d’information, mais, simplement, on veut désormais faire des modèles électroniques qui permettent de mieux comprendre les informations contenues dans un échange pour mieux en automatiser le traitement. XML dit alors : « Décris-moi et dis-moi ce que sont les choses » .
Autre exemple : les comptes bancaires. Le modèle d’un relevé de compte dit qu’il y a le nom de l’écriture, la date, la somme, le libellé etc. XML permettrait à un particulier qui veut monter sa propre comptabilité familiale, de reprendre tous ses libellés et de faire la classification de l’ensemble de ses informations : rassembler par exemple toutes les opérations liées à un retrait dans un distributeur automatique de billets. S’il veut faire la récupération de façon automatisée, il récupère toutes les informations fournies par sa banque sur Internet dans une fenêtre d’un navigateur. Puis, il réalise un programme fondé sur les contenus textuels de chaque ligne d’opération. Par exemple, il remarque que sur chacun des libellés (classés par date) relevant d’un retrait à un distributeur, il y a indiqué DAB (distributeur automatique de billet). Par une simple reconnaissance de « DAB » il va pouvoir classer ses opérations. Mais tous les distributeurs ne donnent pas le même libellé et il devra aussi prendre en compte « DAB », une autre fois « GAB », une autre « distributeur »… Pourtant, ce sont des ordinateurs, qui ont un modèle de données sous-jacent, qui ont généré l’information et un retrait à un distributeur est toujours un retrait.

Mais justement, pour aller plus loin sur cet exemple, aujourd’hui telle banque va indiquer « distributeur », telle autre « DAB », et si l’usager a deux comptes dans deux banques différentes, alors il ne peut plus traiter son information…

C’est le grand débat en ce moment. Pourquoi travailler toujours sur la représentation, la mise en forme d’une information ? Pourquoi ne pas donner, de manière explicite et dans le même temps, des informations liées au modèle sous-jacent ? Il serait plus simple que tout le monde se mette d’accord, et que, par exemple, le groupement des cartes bancaires rende public un modèle indiquant qu’un retrait dans un distributeur a toujours la même structure et est toujours identifié de la même façon. Du coup, les banques pourront ensuite utiliser ce modèle pour fournir un objet qui s’appelle « DAB » et que l’usager pourra à son tour récupérer en tant que tel quand il consulte son compte.
Ainsi, nous allons vers une démultiplication des modèles verticaux  : un modèle dans l’industrie automobile ne sera pas le même que dans l’industrie aéronautique. Un modèle de documentation de l’Après-Vente ne sera pas le même qu’un modèle de documentation de conception. En revanche il existe quand même des modèles qui sont réutilisables. SVG qui est un modèle basé sur XML est potentiellement réutilisable par tout le monde. Y compris dans les spécifications liées à XML, il y a des embryons de modèle. XInclude par exemple : la balise include qui veut dire « aller chercher un fichier et le mettre à cet endroit-là » est toujours la même.

Et le répertoire de modèles va rendre tous ces types de modèles disponibles ?

Le répertoire propose de rendre publics les modèles. Si le groupement des cartes bancaires a fait ce modèle, qui dit que « DAB » décrit un retrait dans un distributeur, ce dernier va forcément intéresser beaucoup de gens dans le monde, donc pourquoi ne pas le rendre public ?
Si je suis un chef de projet en train de faire mon modèle d’information, j’ai besoin de connaître les modèles existants de mon environnement. Je vais sur le répertoire et je trouve donc rapidement les modèles auxquels mon environnement est soumis. Cela me sert de référence  ; cela me sert aussi à comprendre les méthodes et habitudes d’échange d’un domaine d’application particulier.

Comment fonctionnera ce répertoire ?

Certains modèles seront disponibles directement à partir du site, parce qu’ils sont publics. Pour d’autres nous indiquerons où il faut aller pour les chercher, par exemple pour les commander. Nous avons l’objectif très clair de respecter toutes les diversités de confidentialités des propriétaires de modèles car nous voulons répertorier des choses qui ne sont pas obligatoirement publiques, par exemple des modèles sur lesquels les gens veulent avoir une maîtrise de la diffusion. C’est la raison pour laquelle nous pensons être davantage un vaste répertoire organisé qu’un organisme lui-même distributeur de modèles. Ces derniers seront disponibles ailleurs sur Internet, selon l’interface que chacun voudra leur donner.
Mais nous serons un répertoire à forte valeur ajoutée, qui identifie et décrit les modèles. Il ne suffit pas d’avoir un modèle pour que ça marche, il faut qu’il soit documenté. Aujourd’hui, des quantités de modèles qui circulent : La J2008 (norme concernant l’industrie automobile) par exemple, est disponible sur Internet. Mais si on ne lit pas la documentation qui va avec et qui fait 500 pages, on ne comprendra rien au modèle ! On rejoint finalement les objectifs de Mutu-XML : rendre publique de l’information à forte valeur ajoutée sur XML. On rejoint aussi ses objectifs car notre volonté est de fournir de l’information sur les outils et les savoir-faire liés à un modèle particulier. C’est la raison pour laquelle nous voulons proposer également des outils et des environnements paramétrés, des feuilles de styles, quand cette information est disponible. Nos critères qualitatifs ne vont alors pas se fonder sur la bonne qualité du modèle, mais sur sa bonne qualité éditoriale. Nous n’allons pas nous prononcer sur le modèle en lui-même mais sur le fait qu’il soit bien répertorié, bien expliqué.

Pourquoi un répertoire spécifiquement francophone ?

La communauté francophone n’a pas besoin que de schémas et de modèles francophones. Elle a aussi besoin de l’ensemble des informations liées à son environnement et qui sont, souvent, en langue anglaise. Nous nous donnons comme objectif soit de publier des choses purement francophones soit d’essayer de faire des efforts pour ramener en langue française des choses qui sont en anglais. On pourra ainsi avoir des descriptions en langue française de modèles qui sont eux-mêmes définis en langue anglaise. Ce répertoire s’adressera aussi bien aux chefs de projets qui construisent des systèmes d’informations et qui veulent connaître leur environnement, qu’aux techniciens qui veulent savoir comment les autres ont fait.

Si on commence à recenser des choses qui sont par ailleurs recensées dans d’autres langues, toute la question ensuite est de savoir : Est-ce qu’il doit exister un seul répertoire de modèles ou bien autant qu’on veut ? Nous nous positionnons pour la deuxième éventualité.

Cela risque de compliquer encore les choses…

L’idée principale de ce projet est double : d’une part, mettre en place un répertoire de modèles ET, d’autre part, mettre en place un modèle d’échange d’information sur les modèles ! Le répertoire va permettre à tout le monde de prendre toute cette information et d’en faire ce qu’il veut. Mais quand l’administration française va récupérer un modèle c’est une base qu’elle va certainement enrichir et personnaliser pour ses propres besoins, parce que, par exemple, elle a besoin de plus de précisions adminsiratives. Si notre répertoire reste généraliste, chacun va pouvoir aussi prendre l’information brute et rajouter des choses, pour en faire faire sa propre application, avec sa propre valeur ajoutée. Ce qu’on aura gagné avec la mise en place d’un modèle XML d’échange d’informations sur les modèles c’est que tous ces modèles, de manière indépendante des applications, seront utilisables par chacun. On participe alors à la montée en compétences des organisations sur XML ; on favorise aussi la démultiplication des applications fondées sur XML, par une publicisation de savoir-faire sous-tendue dans les modèles rendus publics.

Le répertoire francophone de modèles pour les applications d’XML : http://www.repertoire-modeles.org
L’annonce du projet : http://www.repertoire-modeles.org/defProj/decl/defProj.html