Je vais supposer que vous connaissez les mécanismes de base du XML et savez identifier les éléments, attributs et balises qui les définissent. Je suppose donc que vous reconnaissez que l’échantillon ci-dessous, un extrait de document XHTML, contient un élément <p> et deux éléments <i> <> , et que ces éléments sont définis à l’aide des balises , c’est-à-dire les informations entre les symboles <> :

<p><i>Guerre et Paix</i> est un <i>très</i> gros livre.</p>

Ces balises sont des métadonnées. Quand on évoque les métadonnées, on pense souvent qu’il ne s’agit que d’une simple étiquette attachée à un contenu, généralement à l’aide d’un système de gestion de contenus, permettant de suivre le document et de le trouver plus facilement. C’est effectivement une des principales utilisations des métadonnées, mais les métadonnées offrent beaucoup plus que cela. Les métadonnées sont des données qui décrivent d’autres données. Il existe de nombreuses formes utiles de métadonnées, notamment les balises XML. (Pour plus d’informations à ce sujet, consultez la rubrique The Meaning of Metadata.)

La raison pour laquelle le langage XML est si utile, c’est qu’il nous permet d’assigner des métadonnées au contenu à n’importe quel niveau de granularité, et pas seulement à un document dans son ensemble, mais à une phrase ou à un mot unique. Dans l’exemple ci-dessus, la balise <i> nous indique que la chaîne « Guerre et Paix » devrait apparaître en italique. (Telle est la signification de <i> en langage XHTML. Une balise <i> pourrait signifier quelque chose de complètement différent dans un autre langage de balisage.)

Bien sûr, « afficher ceci en italique » n’est pas la forme de métadonnées la plus complexe qui soit. En outre, cela va à l’encontre de la règle souvent citée selon laquelle XML sépare le contenu de la mise en forme. En fait, cette règle est inexacte. Certains langages de balisage XML comme XHTML et XSL-FO  sont conçus spécifiquement pour appliquer une mise en forme à un contenu. Certains langages XML sont conçus pour séparer le contenu de la mise en forme. D’autres ne s’occupent absolument pas du contenu. Il serait préférable de préciser que le langage XML vous permet d’appliquer des métadonnées au contenu, et que les métadonnées que vous appliquez peuvent exprimer tout ce que vous voulez.

Ainsi, XHMTL n’applique aucune mise en forme au contenu et une application de traitement de XHTML (disons, un navigateur Web) afficherait ainsi le contenu de notre échantillon :

Guerre et Paix est un très gros livre.

Le résultat est satisfaisant, mais le format XML nous permet d’en faire beaucoup plus.

Séparation du texte de la mise en forme

Si nous voulons séparer le contenu de la mise en forme, nous devons ajouter des métadonnées pour créer cette séparation. XHTML nous permet de franchir une première étape vers cet objectif en utilisant la balise <em> (mise en valeur) plutôt que la balise <i> :

<p><em>Guerre et Paix</em> est un <em>très</em> gros livre.</p>

Plutôt que de préciser que « Guerre et Paix » et « très » s’affichent en italique, ce balisage indique simplement que ces éléments seront mis en valeur. L’application de traitement décide seule comment les mettre en valeur. Par exemple, cela peut prendre la forme :

Guerre et Paix est un très gros livre.

Toutefois, un problème se pose alors. L’application de traitement peut parfaitement afficher le contenu mis en valeur en texte rouge gras car le format gras et la couleur rouge correspondent effectivement à une mise en valeur. Mais il existe des conventions précisant comment présenter le titre d’un livre, et l’une d’entre elles stipule que le texte doit apparaître en italique.

Si nous allons séparer le contenu de la mise en forme, mieux vaut donc le faire correctement. Si nous utilisons uniquement <em> comme synonyme de <i>, alors nous ne séparons pas réellement le contenu de la mise en forme. Il vaut donc mieux conserver <i> car cette balise est en fait une meilleure façon d’exprimer ce que nous souhaitons.

Si nous voulons vraiment séparer le contenu de la mise en forme, mieux vaut trouver un moyen plus judicieux que simplement remplacer partout <i> par <em>. Si nous n’allons pas mettre en forme le texte directement, alors nous devons fournir à l’application de traitement suffisamment de métadonnées pour qu’elle puisse distinguer les éléments à mettre en forme différemment.

Pour fournir à cette application de traitement suffisamment d’informations pour mettre correctement en forme « Guerre et Paix », nous devons fournir des métadonnées indiquant que la chaîne « Guerre et Paix » est un titre :

<p><title>Guerre et Paix</title> est un <em>très</em> gros livre.</p>

Maintenant, nous avons fourni suffisamment d’informations pour qu’un processeur XML affiche la phrase appropriée :

Guerre et Paix est un très gros livre.

Cependant, en ajoutant la balise <title> à notre langage de balisage, nous nous sommes écartés de XHTML. Le langage XHTML ne prend pas en charge la balise <title> mais il l’utilise à l’intérieur de l’élément <head> pour capturer le titre du document actuel. Il ne prend pas en charge l’utilisation de la balise <title> à l’intérieur de l’élément <p> pour marquer les titres des livres. Alors, si nous n’utilisons plus XHTML, qu’utilisons-nous ? Nous utilisons maintenant un langage de balisage de notre propre invention. Il s’agit de YAMLX (Yet Another Markup Language eXample). Nous commençons à capturer les métadonnées spécifiques à notre entreprise. Cela signifie que nous devons commencer à assumer la conception de notre propre système de balises, et trouver un langage de balisage existant capable de fournir les métadonnées dont nous avons besoin ou en créer un nous-mêmes. Dans le cadre de cet article, peu importe si YAMLX est un langage accessible au public ou s’il s’agit d’un langage que vous créez vous-même. L’important, c’est que YAMLX capture les métadonnées nécessaires pour exécuter efficacement votre processus de contenu.

Bien entendu, YAMLX n’est pas XHTML, et les navigateurs Web ne pourront pas l’interpréter directement. Pour publier votre contenu, vous devrez le traiter d’une certaine manière afin que les navigateurs sachent comment l’afficher. Il existe deux façons de procéder. L’une consiste à créer une feuille de style CSS pour indiquer au navigateur comment afficher les éléments YAMLX, et l’autre à créer un script XSLT pour convertir YAMLX en HTML. Certains des éléments que nous allons ajouter ultérieurement à YAMLX nous rapprocheront de l’utilisation de XSLT, et c’est ce que nous allons examiner ici.

Heureusement, YAMLX ne diffère de XHTML qu’au niveau d’une balise (jusqu’à présent), et nous pouvons donc écrire un modèle XSLT pour convertir un élément <title> d’un élément <p> en une balise XHTML valide. Il suffit ensuite de copier le reste. Voici le modèle qui convertit l’élément <title> en un élément <i> :

<xsl:template match=”p/title”>
<i>
<xsl:apply-templates/>
</i>
</xsl:template>

Ne vous laissez pas impressionner par ce balisage. Il est très simple. Il indique au moteur de rendu de contenu : si vous détectez un élément <title> à l’intérieur d’un élément <p>, remplacez-le par un élément <i>. Peu importe si vous comprenez exactement le fonctionnement, mais vous pouvez constater que ce n’est pas sorcier.

Balisage sémantique

Bien, nous avons séparé le texte de la mise en forme et fait une distinction entre les titres et la mise en valeur afin d’appliquer une mise en forme différente, mais la seule chose que nous pouvons vraiment faire avec ce balisage, c’est de lui appliquer la mise en forme. La séparation du contenu de la mise en forme n’est pas exactement une révolution en matière de productivité. Surtout si vous vous contentez de regrouper à nouveau ces éléments. Pour obtenir tous les avantages réels de la séparation, nous devons en faire plus. Nous allons donc mettre à jour le langage YAMLX pour capturer certaines métadonnées plus utiles :

<p><title isbn=”1400079985″>Guerre et Paix</title> est un <em>très</em> gros livre.</p>

Ici, nous avons ajouté d’autres métadonnées à la balise <title> sous la forme d’un attribut isbn. Avec ces métadonnées supplémentaires, le balisage ne se contente pas d’identifier « Guerre et Paix » comme un titre. Il l’identifie comme le titre d’une œuvre spécifique .

Que pouvons-nous faire avec ces métadonnées supplémentaires ?  Un numéro ISBN  permet d’accéder à une grande quantité d’informations sur un livre publié. En disposant d’un numéro ISBN, nous pouvons rechercher toutes sortes d’autres informations. Par exemple, nous pouvons utiliser le numéro ISBN pour rechercher des détails de publication en utilisant un service Web comme ISBNdb.

La plupart des services Web renvoient des informations au format XML, ce qui est parfait pour nous, puisque notre contenu est en XML. Par exemple, un service Web ISBN peut renvoyer un document XML similaire à celui-ci (il ne s’agit pas d’un résultat obtenu avec ISBNdb, mais juste d’un exemple simplifié) :

<book>
<isbn>1400079985</isbn>
<title>Guerre et Paix</title>
<author>Léon Tolstoï</author>
<publisher>Classique</publisher>
<publication-year>2008</publication-year>
<page-count>1296</page-count>
…
</book>

Nous pourrions alors extraire des éléments de ce document XML et les ajouter à notre propre contenu pour obtenir le résultat suivant :

Guerre et Paix (Léon Tolstoï, Classique, 2008, 1296 pages) est un très gros livre.

Bien entendu, cette opération n’est pas manuelle. Nous utilisons un script. Pour vous prouver que cette opération n’a rien de compliqué, voici un extrait de code XSLT permettant d’obtenir ce résultat :

<xsl:template match=”p/title”>
<!– capturer le numéro isbn à rechercher –>
<xsl:variable name=”isbn” select=”@isbn”/>

<!– contacter le service Web pour obtenir des infos sur le livre à l’aide du numéro isbn –>
<xsl:variable name=”book-info” select=”document(concat(‘http://example.com/isbn/lookup?’, $isbn))”/>

<!– afficher le titre du livre –>
<i>
<xsl:apply-templates/>
</i>

<!– afficher des informations supplémentaires sur le livre –>
<xsl:text> (<xsl:text>
<xsl:value-of select=”$book-info/book/author”/>
<xsl:text>, <xsl:text>
<xsl:value-of select=”$book-info/book/publisher”/>
<xsl:text>, <xsl:text>
<xsl:value-of select=”$book-info/book/publication-year”/>
<xsl:text>, <xsl:text>
<xsl:value-of select=”$book-info/book/page-count”/>
<xsl:text>) <xsl:text>
</xsl:template>

Encore une fois, ce n’est pas sorcier, mais cette technique élémentaire nous ouvre toutes sortes de portes. Les informations de publication n’étaient pas au format XML original. Elles proviennent d’une autre source en utilisant des métadonnées capturées dans le fichier XML. La puissance du balisage sémantique pour fusionner des informations provenant de différentes sources est considérable. Voici quelques-unes des astuces dont nous pouvons profiter en utilisant les informations extraites à l’aide du numéro ISBN :

• Extraire une photo de la couverture du livre.
• Créer un lien vers un article consacré à Guerre et Paix sur votre site Web.
• Créer un lien vers une librairie en ligne, où le lecteur pourra acheter le livre. Si vous apparteniez à un programme d’affiliation d’une librairie en ligne, vous pourriez gagner un peu d’argent chaque fois qu’un lecteur cliquerait sur votre lien et achèterait un livre. Désormais, les métadonnées des numéros ISBN transforment une référence occasionnelle en une source potentielle de revenus.

Des auteurs plus efficaces

Il est possible d’améliorer considérablement le processus en extrayant ce type de métadonnées de votre contenu XML. Si vous pouvez utiliser les métadonnées clés pour extraire des informations provenant de sources externes, les auteurs n’ont pas à rechercher eux-mêmes toutes ces informations lorsqu’ils écrivent. Ils n’ont pas à choisir les détails du livre qui apparaîtront dans le résultat final. Cette décision est prise en éditant la feuille de style XSLT, et vous pouvez modifier l’ensemble de votre contenu existant simplement en modifiant cette feuille de style.

Comme vous pouvez le voir, l’insertion d’un simple bloc de métadonnées dans notre XML permet d’économiser beaucoup de temps lors de la création et nous laisse toute latitude quant aux détails qui seront publiés. Cette efficacité et cette flexibilité peuvent se traduire par des économies de coûts substantielles et par une augmentation des revenus dans le cas d’un ensemble de contenus volumineux.

Amélioration des métadonnées

Bien que l’ajout d’un numéro ISBN dans YAMLX nous offre de nombreuses options, ce balisage présente quelques problèmes.

Le premier concerne l’exactitude des métadonnées. Un numéro ISBN n’identifie pas directement une œuvre littéraire. Il identifie une édition particulière d’un livre d’un éditeur particulier dans une reliure particulière et pour une année donnée. Cette distinction peut être importante. Il existe de nombreuses autres éditions de Guerre et Paix, traduites dans de nombreuses langues. Guerre et Paix est un très gros livre dans toutes ces éditions et toutes ces langues. Le paragraphe ne se réfère pas spécifiquement à l’édition Classique de 2008. Il considère Guerre et Paix comme un roman en général. Avec l’utilisation du numéro ISBN, les métadonnées sont plus précises que le texte qu’elles balisent. Cela pourrait poser des problèmes pour quelques-unes des méthodes d’interrogation de ce contenu.

Supposons que nous voulions dresser une liste de toutes les références à Guerre et Paix dans notre contenu. Cette opération peut être facilement réalisée à l’aide d’une expression XPath  semblable à ceci :

p[title="Guerre et Paix"].

Celle-ci permet d’afficher tous les éléments <p> avec un élément <title> contenant “Guerre et Paix”. Encore une fois, ne vous préoccupez pas de la syntaxe. L’unique raison pour laquelle je souhaite afficher ces informations, c’est pour montrer que tout cela n’est pas très compliqué.

Cette expression XPath présente cependant un problème. Elle affiche tous les paragraphes contenant le titre « Guerre et Paix ». Mais cela pourrait inclure des références au titre du film qui porte le même nom, à l’opéra de Prokofiev ou à un autre ouvrage intitulé « Guerre et Paix », et ce n’est pas le but recherché. Nous voulons seulement des informations sur le roman.

Pour affiner les résultats, nous devons rechercher d’autres métadonnées. Utilisons par exemple les métadonnées ISBN :

p[title/@isbn="1400079985"].

Cela permet d’afficher tous les éléments <p> avec un élément <title> contenant un attribut isbn dont la valeur est “1400079985″. Cette méthode va certainement éliminer tous les films, opéras et œuvres non romanesques, mais elle risque également d’exclure quelques références au roman. Le problème est qu’il existe plusieurs numéros ISBN pouvant faire référence au roman Guerre et Paix car de nombreuses éditions différentes ont été publiées. Il est évident qu’un auteur qui balise une référence à Guerre et Paix cherchera le même numéro ISBN. C’est pourquoi le fait que nos métadonnées soient plus spécifiques que le contenu qu’elles décrivent pose problème : nous risquons de rater quelques instances du contenu.

Le second problème est lié à la productivité de l’auteur. L’auteur qui a écrit le paragraphe ne connaît sûrement pas par cœur les numéros ISBN de toutes les éditions de Guerre et Paix. Si le balisage faisait référence à un numéro ISBN, l’auteur devra s’interrompre pour rechercher cette information. Éviter aux auteurs d’avoir à s’arrêter pour rechercher des données peut apporter d’importants gains de productivité. Cela peut aussi potentiellement élargir votre pool d’auteurs disponibles.

Ainsi, l’utilisation du numéro ISBN comme métadonnée est trop précise et complique la tâche des auteurs. Nous devons trouver un balisage offrant le niveau de précision approprié et que les auteurs peuvent facilement créer. Nous pouvons, par exemple, utiliser la formulation suivante :

<p><novel author=”Léon Tolstoï”>Guerre et Paix</novel> est un <em>très</em> gros livre.</p>

Ici, nous avons remplacé la balise <title> par la balise <novel> plus spécifique, et remplacé l’attribut isbn trop spécifique par l’attribut plus simple author (au cas où un autre auteur a également écrit un roman intitulé Guerre et Paix).

Ce balisage est évidemment plus facile à créer pour les auteurs. Il ne leur demande que des éléments qu’ils connaissent déjà, de sorte qu’ils n’auront pas à s’arrêter pendant la création pour rechercher ces informations.

Et si nous sélectionnions chaque paragraphe faisant référence au roman de Tolstoï ?  Nous pouvons également le faire avec plus de précision en utilisant une expression XPath de type :

p[novel[@author="Léon Tolstoï"] = “Guerre et Paix“]

Cela permet d’afficher tous les éléments <p> avec un élément <novel> contenant un attribut author avec la valeur « Léon Tolstoï » et dont le contenu est « Guerre et Paix ». C’est ce que nous cherchions et nos métadonnées semblent donc correctes.

Les métadonnées ISBN nous permettent de récupérer des informations de publication en utilisant le numéro ISBN pour interroger la base de données ISBN. Sans numéro ISBN, comment obtenir ces données ? Nous pouvons toujours extraire ces informations, mais en utilisant une requête différente. Voici le code d’origine de notre recherche :

<xsl:variable name=”book-info” select=”document(concat(‘http://example.com/isbn/lookup?’, $isbn))”/>

Nous devons le modifier afin de lancer la recherche sur les métadonnées dont nous disposons : catégorie (roman), titre et auteur :

<xsl:template match=”p/novel”>
<!– capturer les métadonnées à rechercher –>
<xsl:variable name=”title” select=”.”/>
<xsl:variable name=”author” select=”@author”/>

<!– contacter le service Web pour obtenir des informations sur le livre –>

<xsl:variable name=”book-info” select=”document(concat(‘http://example.com/isbn/lookup?category=novel&title=’, $title, ‘&author=’, $author))”/>

La seule différence dans les résultats que nous obtiendrons à partir de cette requête est le fait qu’il peut y avoir plusieurs livres avec ce numéro ISBN (ce sera sûrement le cas car il existe de nombreuses éditions de Guerre et Paix). Par conséquent, le code qui ajoute les informations sur le livre au contenu devra choisir l’une des alternatives à partir des éléments pertinents des données de publication (date de publication la plus récente, par exemple). Autre avantage : les informations de publication que nous affichons seront compatibles partout où nous ferons référence à Guerre et Paix dans notre contenu.

Devrions-nous toujours marquer « Guerre et Paix » en utilisant la balise <novel> et un attribut d’auteur ?  Pas nécessairement. Ce que nous constatons ici, c’est que lorsque nous évoquons « Guerre et Paix » dans notre contenu, nous pourrions effectivement faire référence à des choses différentes. Nous pourrions, comme dans le cas qui nous concerne, parler du roman en général. Mais dans une autre circonstance, nous pourrions nous référer à une édition publiée spécifique. Même si la chaîne reste « Guerre et Paix » dans les deux cas, ce texte désigne des éléments différents. Un des rôles les plus importants des métadonnées XML consiste à effectuer clairement ce genre de distinction afin que nous puissions traiter chaque cas de façon appropriée.

Ce dont nous avons réellement besoin dans YAMLX, ce sont deux balises différentes de telle sorte que nous puissions appliquer les bonnes métadonnées aux termes « Guerre et Paix » en fonction de ce qu’ils signifient dans chaque cas.  Pour faire référence au roman, nous pourrions écrire :

<p><novel author=”Léon Tolstoï”>Guerre et Paix</novel> est un <em>très</em> gros roman.</p>

Pour faire référence à une édition particulière du roman, nous pourrions étendre l’expression YAMLX afin d’inclure un élément édition comprenant un attribut isbn :

<p><edition isbn=”1400079985″>Guerre et Paix</title> est <em>toujours</em> en rupture de stock.</p>

Maintenant, notre application de traitement peut reconnaître que les mots signifient quelque chose de différent dans chaque cas et les traiter en conséquence.

Maîtriser le format des données pour maîtriser la fonctionnalité

Quelle est donc la balise à utiliser pour marquer la chaîne « Guerre et Paix » — <i>, <em>, <title>, <novel> ou <book> ? Impossible de donner une bonne réponse absolue. Tout dépend de ce que vous voulez faire avec vos données. Contenu signifie données. Le contenu se transforme en données dès que vous l’entrez dans un système informatique. Qu’il s’agisse d’un document Microsoft Word, d’un fichier Adobe FrameMaker ou d’un document XML, contenu signifie données. La différence réside dans le fait qu’avec le format XML, vous maîtrisez la structure avec vos propres données de contenu.

Maîtriser la structure des données de votre contenu est important car cela vous permet de contrôler la création et la publication de vos contenus. En utilisant un format binaire, comme Word ou FrameMaker, vous bénéficiez des fonctionnalités de Word ou de FrameMaker. À l’aide de quelques scripts, vous pourrez peut-être ajouter des fonctionnalités supplémentaires, à condition que le modèle de données Word ou FrameMaker les prenne en charge. Avec XML, vous choisissez le format de fichier et la fonctionnalité à mettre en œuvre pour traiter vos données. Vous pouvez définir le format de données qui répond le mieux aux besoins particuliers de votre entreprise.

Mais cela n’a pas beaucoup d’importance, sauf si vous faites quelque chose avec vos données que vous ne pourriez pas faire avec Word ou FrameMaker, par exemple l’extraction automatique de contenus supplémentaires à partir d’une base de données pour améliorer vos contenus et enregistrer le travail de vos auteurs.

Ici, le véritable atout de XML est sa capacité à intégrer vos contenus dans une base de données. Car XML vous permet d’appliquer des métadonnées à votre contenu, d’interroger et de gérer votre contenu, à n’importe quel niveau de granularité. Parallèlement, il vous permet d’intégrer des métadonnées à votre contenu afin de créer une requête de base de données qui extrait d’autres données (comme nous l’avons vu avec l’exemple ISBN).

Telle est la fonction de chaque langage de balisage XML : transformer du contenu en une base de données. Les différences entre les divers langages XML résident dans le degré de détail et la spécificité de la structure de cette base de données, ainsi que sa capacité à répondre à un ensemble particulier de besoins de l’entreprise. Cela a une conséquence très importante si vous faites l’acquisition d’un système de création ou si vous construisez votre propre système : le format des données est plus important que la fonctionnalité de l’application.

Lorsque vous achetez un outil standard comme Word ou FrameMaker, votre décision d’achat repose essentiellement sur la fonctionnalité de l’application. Vous vous préoccupez plus des capacités actuelles de l’outil que de ses possibilités futures. En règle générale, vous n’avez pas à vous soucier de la façon dont le format de fichier que l’application utilise prend en charge sa fonctionnalité. Vous achetez une fonctionnalité, pas une structure de données.

Mais avec le langage XML, ce n’est pas la fonctionnalité de base dont vous disposez qui devrait être une priorité, mais la fonctionnalité que la structure de données XML prend en charge. Même si vous utilisez un ou plusieurs outils avec des fonctionnalités existantes, vous n’êtes pas limité à cette fonctionnalité, et cela ne devrait pas être l’argument principal sur lequel reposera votre décision. Vous pouvez toujours ajouter une fonctionnalité dont vous avez besoin, si votre structure de données la prend en charge. Mais vous ne pouvez pas construire ni acheter des fonctionnalités que les données ne prennent pas en charge.

Tels sont les éléments à prendre en compte lorsque vous envisagez une solution XML :

• XML transforme votre contenu en une base de données. Vous pouvez interroger cette base de données pour organiser et structurer votre contenu et combiner des contenus provenant de différentes sources.
• La conception de cette base de données détermine ce que vous pouvez faire avec les données. Vous devez porter une attention particulière à la conception de votre balisage pour vous assurer qu’il vous permet de mettre en œuvre la fonctionnalité dont vous avez besoin pour rationaliser vos processus de développement de contenus.
• Vous pouvez améliorer la productivité de l’auteur, et intégrer d’autres auteurs, en concevant un balisage qui demande des informations qu’ils connaissent déjà, puis utiliser ces informations pour importer des données connexes.
• La principale décision que vous devez prendre n’est pas de savoir quelle fonctionnalité un outil particulier prend en charge par défaut, mais quelle fonctionnalité le format de votre contenu prendra en charge.

À propos de l’auteur

Mark Baker, Président d’Analecta Communications Inc., a plus de 20 ans d’expérience dans le domaine des communications techniques et plus de 15 ans dans la conception, la mise en œuvre et l’utilisation de systèmes de publication structurés. Vous pouvez consulter son blog sur le site everypageispageone.com.

Commençons par les difficultés rencontrées.

Présentation de la publication par base de données

Pour assembler des catalogues de produits et des listes de prix destinés à ses concessionnaires, un petit groupe au sein d’une organisation suivait un processus lent, coûteux et laborieux. Les descriptions de produits et les listes d’avantages étaient combinées à des photographies de chaque produit, et des tableaux de données étaient manuellement copiés à partir de données tarifaires dans une base de données financières d’entreprise. Une fois la copie assemblée et approuvée, il fallait six mois à un graphiste pour le mettre en page de façon précise dans Adobe InDesign. Au moment où le catalogue était achevé, les données de prix étaient déjà obsolètes. Chaque catalogue était un mélange chaotique de mises en page truffées d’étoiles, de graphiques à barres, d’icônes au look tapageur et autres éléments « décoratifs » éparpillés à travers des centaines de pages uniques. Cette conception chaotique compliquait la mise à jour du contenu avec des modifications de dernière minute. Et les clients éprouvaient des difficultés pour trouver les produits et les prix dont ils avaient besoin.

Figure 1 : Processus de développement de catalogue existant

Processus de développement dynamique

Comment surmonter les difficultés que présentent ces anciens modèles de catalogues de produits ? Tout d’abord, vous devez identifier les éléments communs du catalogue et aider l’équipe en charge de celui-ci à définir une norme. Sortir de cette mise en page chaotique permet de mettre en valeur le potentiel de réduction des coûts. La promesse de délais de livraison plus courts et l’allègement des coûts de développement persuaderont même les membres les plus récalcitrants de l’équipe commerciale des avantages du contenu standardisé.

Vient ensuite la mise en place d’un environnement de création simplifié. La copie standard se compose d’un nom de produit, d’une brève description et d’une liste des avantages. Chaque produit est illustré par une ou plusieurs photographies. Vous obtenez ainsi un environnement de conception simple pouvant être facilement développé par un même auteur.

La base pour la création devient un outil d’édition XML/DITA qui simplifie la saisie du contenu. Chaque description du produit suit exactement la même structure, une caractéristique qui améliore l’accès aux informations et la lisibilité pour les clients.

[Note du rédacteur : DITA signifie Darwin Information Typing Architecture, une architecture basée sur XML destinée à la création, à la production et à la diffusion d'informations techniques. XML signifie Extensible Markup Language, un ensemble de règles de codage de documents dans un format lisible à la fois par l'homme et par la machine.]

La partie la plus complexe du nouveau processus est la conception d’un processus permettant de produire des tableaux de prix en extrayant directement les informations de la base de données financières. Une fois les transformations requises en place, chaque tableau est automatiquement construit puis ajouté au contenu de la rubrique DITA.

Pour ce projet, nous avons créé des transformations afin de développer des index personnalisés permettant aux concessionnaires de trouver facilement les informations. Dès que la feuille de style XSL-FO a été mise en place, un processus de conception et de publication qui nécessitait autrefois plusieurs mois a été achevé en quelques minutes, réduisant ainsi les coûts de conception graphique. Une fois la copie examinée et approuvée, l’impression prend environ deux semaines. Toutefois, cette société s’oriente à présent vers une impression à la demande déclenchée par une requête spécifique d’un concessionnaire.

Figure 2 : Nouveau processus de publication de catalogue

Les responsables du marketing et des ventes, qui s’étaient montrés sceptiques au début, ont réalisé le potentiel que représentent des catalogues supplémentaires. Le second projet est un catalogue non-américain proposant différents prix, des remises pour concessionnaires et une gamme de produits plus limitée. Les métadonnées permettent de sélectionner facilement des produits pour des marchés plus ciblés, remplaçant ainsi l’approche globale qui caractérisait le processus de conception précédent. Le processus de publication automatisé permet également à l’entreprise de produire des catalogues beaucoup plus fréquemment que par le passé.

La société prévoit de relier les rubriques DITA, le processus de publication de leur site de commerce en ligne et le traitement automatisé des achats en ligne.

Faire passer la publication automatisée au niveau supérieur

Mais l’automatisation du processus de publication et l’intégration de texte XML structuré avec les données provenant d’une base de données relationnelle ne représentent que la première étape de la publication du catalogue. Dans une autre organisation, nous avons identifié le potentiel pour des catalogues personnalisés créés à la demande pour un représentant commercial.

Ici encore, les informations de base sur un produit sont créées dans des rubriques DITA puis stockées dans un système de gestion de contenus par composants, avec les dessins et photographies nécessaires au catalogue.

L’analyse du catalogue de ce projet comprenait non seulement des informations descriptives, mais également des tableaux et des graphiques de données. La présentation originale des informations était aussi chaotique que dans le premier projet. Chaque section de produits dans le catalogue papier était unique, et chaque page était conçue individuellement. Il arrivait même que les listes d’avantages des produits et les données d’ingénierie critiques soient tronquées pour s’adapter à la mise en page.

Dans ce cas aussi, la première étape a été la standardisation. En concertation avec l’équipe de gestion des communications marketing, nous avons identifié un ensemble standard de contenus pour chaque produit et conçu une mise en page cohérente à l’aide de DITA Open Toolkit et d’une feuille de style XSL-FO.

Mais la question clé était de savoir comment amener les représentants commerciaux à utiliser la source d’informations pour produire leurs catalogues personnalisés. Nous savions que ces représentants préféraient créer des catalogues uniques pour des clients individuels, plutôt que d’emporter l’énorme catalogue détaillant toute la gamme de produits. Ils voulaient surtout ne pas s’occuper des rubriques DITA et du langage XML.

En réponse à ces besoins, nous avons créé une interface SharePoint permettant à un commercial de choisir parmi un éventail d’options, y compris le nom du produit, le type d’industrie et d’autres caractéristiques clés des informations. En cochant simplement quelques cases, chaque commercial crée un catalogue unique entièrement mis en forme et immédiatement disponible pour téléchargement et impression.

Dans un projet similaire réalisé quelques années plus tôt, nous avions permis à un représentant commercial d’utiliser une interface simple à base de clics sur un site Web afin de sélectionner une fonctionnalité spécifique pour un ensemble de produits et de choisir une page de couverture avec le nom de l’entreprise du client. La force de vente étant largement disséminée, nous avions même donné à chaque commercial la possibilité de sélectionner une imprimerie à proximité. Il lui suffisait donc de se rendre à l’imprimerie pour y récupérer les catalogues finalisés en vue de sa prochaine visite commerciale.

Recherche d’opportunités

Dans la plupart des organisations, le développement de catalogues de produits et de listes de prix se révèle coûteux, fastidieux et pénible. Il incarne le stade ultime de la publication statique. Mais les arguments en faveur de la publication dynamique du contenu de catalogues convaincront rapidement ceux qui veulent aller à l’essentiel :

Réduire considérablement le délai de réalisation d’un catalogue de plusieurs mois à quelques jours

Réduire de manière significative le coût de développement de la mise en page du catalogue final à l’élaboration initiale des feuilles de style XSL-FO

Permettre le développement de catalogues personnalisés à partir d’un même contenu source

Permettre l’impression à la demande de catalogues personnalisés

S’assurer que les données tarifaires sont exactes, actualisées et proviennent directement des bases de données d’achat

Permettre le développement à la demande de catalogues personnalisés par chaque représentant commercial

Lier le contenu du catalogue à des sites Web de commerce en ligne

Bien entendu, il existe au sein de votre organisation de nombreuses autres possibilités d’application de la publication dynamique. Votre point de départ consiste à développer une source unique de tous les contenus (textes, images et données de prix), sans mise en forme (XML/DITA), présentés au personnel et aux clients via une interface utilisateur intuitive et facile d’accès.

Mark Gross, Data Conversion Laboratory

Data Conversion Laboratory, l’entreprise que j’ai fondée, s’occupe de la conversion de documents depuis trente ans. Il arrive souvent qu’une personne que je n’ai pas vue depuis longtemps me demande : « tu en es toujours là ? » ou « il n’existe aucun logiciel capable de faire tout ça ? ».

La vérité est la suivante : si c’était aussi facile, tout serait en effet entièrement automatisé, ce qui est déjà le cas pour les flux d’informations, les transactions financières et autres flux de données standardisés. Mais quand il s’agit de documents et de livres, la créativité ne peut être limitée par des règles et des feuilles de style, en particulier au moment crucial où l’on veut soigner la mise en forme (et que Microsoft Word ne suffit plus). La vérité est qu’un document peut contenir tout type d’information, et que les logiciels informatiques s’accommodent mal de paramètres aussi « aléatoires ».

Même ce qui semble n’être à première vue qu’un simple livre – un livre avec un texte simple, sans tableau ni lien – présente toujours des complications venant contrarier les logiciels qui n’ont pas été conçus à cet effet. Dans un récent test impliquant trois suites de logiciels libres, aucun livre n’a pu être créé de façon parfaite. Chaque livre créé présentait des défauts. Pour compliquer les choses, chaque produit présentait différents problèmes (le webinaire enregistré inclut quelques exemples).

La flexibilité avant tout

Afin de fournir les informations personnalisées de haute qualité que les consommateurs attendent (et exigent dans certains cas), nous devrons commencer à penser sérieusement à créer des flux automatisés de contenus standardisés – une tâche actuellement hors de portée pour la plupart des organisations.

Pour que celles disposant de grandes librairies d’informations puissent distribuer et monétiser leurs contenus, la solution la plus évidente consiste à adopter un modèle flexible de contenus standardisés et à gérer ces contenus dans un système de gestion de contenus approprié. Dans notre monde mobile et toujours connecté, cela implique la création et la diffusion de contenus sur l’appareil que les clients auront choisi. Cela implique également d’anticiper l’évolution de ces contenus afin de pouvoir les préparer et les diffuser rapidement et efficacement sur les nombreux appareils qui n’ont pas encore été lancés sur le marché.

De nombreuses normes de contenus sont disponibles : HTML, EPUB, XML, PDF et DITA. Mais quelle est celle qui répond le mieux à vos besoins ? À ceux de votre public ?  À ceux des publics de l’avenir ? Aurez-vous besoin de plusieurs normes ?

Pour l’instant, supposons que vos informations puissent être stockées à l’aide d’une forme robuste de XML ; définir la forme spécifique la mieux adaptée à vos contenus nécessite une analyse plus approfondie. Cependant, il semble que, pour la plupart des grandes librairies, passer à des formats plus simples comme HTML ou EPUB peut être un investissement à risque en raison du manque de flexibilité qu’ils offrent.

Le format EPUB, par exemple, désormais en version 3.0, répond tout particulièrement aux besoins des livres électroniques (livrels) tels qu’ils existent actuellement. Il est fort possible que toutes les fonctionnalités de vos contenus ne soient pas facilement définissables selon la norme EPUB, et qu’elles ne s’affichent pas sur les appareils actuels. Si vous vous cantonnez à la conversion vers la version EPUB actuelle, vous risquez de limiter vos contenus à mesure que de nouvelles capacités, non encore envisagées, seront mises en œuvre. La même chose s’applique au langage HTML, conçu pour l’affichage des informations.

Afin de préserver votre investissement dans la conversion vers un format standardisé, l’approche la plus sûre consiste à convertir et à stocker les contenus dans une version XML plus robuste comme DITA, DocBook, NLM, TEI, S1000D et diverses autres normes XML créées à des fins spécifiques. Correctement conçues, ces normes vous aideront à convertir automatiquement vos contenus EPUB, HTML, PDF et autres formats finaux dans le futur.

Pourquoi la conversion est-elle si difficile ?

Si tout le monde écrivait ses documents avec l’intention de les standardiser et de les convertir, la vie serait facile (et nous n’aurions pas grand-chose à faire). Mais dans la réalité, la plupart des contenus ne sont pas facilement extractibles et sont dépourvus des informations nécessaires à une conversion complète. Il faut réaliser beaucoup de corrections et des déductions doivent être faites en fonction du contenu.

À titre d’exemple, examinons les difficultés pour extraire le contenu de fichiers PDF. PDF étant un format d’impression, les documents PDF représentent généralement des versions moins structurées que les originaux créés à l’aide d’un traitement de texte. Bien que le contenu PDF soit mis en forme de manière optimale, il comprend très peu de structure, c’est-à-dire qu’il fournit peu d’indices quant à la fonction des éléments de texte (par exemple, les paragraphes, les espaces, les sauts de ligne) ou la façon dont ils doivent être affichés dans un autre contexte (par exemple, un livrel). Même si la conversion de contenus très structurés en XML est simple, le format PDF ne présente aucune structuration explicite. Mais un problème encore plus fondamental concerne l’extraction initiale du contenu du fichier PDF.

Voici d’autres exemples de problèmes que vous êtes susceptible de rencontrer avec des logiciels ou suites commerciaux :

Espaces incorrects entre les mots

L’espacement est généralement correctement extrait car les documents PDF créent des espaces de façon visuelle (ils ne sont pas véritablement désignés comme « un espace standard » ou « deux espaces standard »). Toutefois, il arrive parfois que l’espacement entre les mots soit mal interprété par le logiciel de conversion, ce qui provoque l’ajout ou la suppression d’espaces de façon incorrecte lors de l’extraction de PDF vers Word. C’est pourquoi certains mots risquent d’être collés ou mal espacés dans les livrels qui n’ont pas été totalement vérifiés.

Délimitation des paragraphes

Dans la plupart des cas, les documents PDF ne contiennent aucune information explicite pour indiquer où un paragraphe commence ou se termine. Le logiciel de conversion doit donc procéder à une estimation basée sur une interprétation « visuelle » des blocs de texte. Même si le logiciel de conversion parvient souvent à réaliser une estimation fiable, la délimitation des paragraphes peut être une source d’erreurs d’extraction, en particulier lorsque les paragraphes sont très courts ou s’étalent sur plusieurs pages, ainsi qu’en présence d’images et de tableaux.

Traits d’union

Les traits d’union posent un problème car ils sont utilisés sous différentes formes qu’un système automatisé est incapable de distinguer. Bien que le trait d’union d’un terme comme « vingt-huit » devrait apparaître quelle que soit la place des mots dans un document, un trait d’union affiché au milieu d’un mot en raison d’un saut de ligne entraîne une erreur d’affichage particulièrement visible si le mot est déplacé vers le milieu d’une ligne. C’est un problème récurrent dans les livrels que vous téléchargez.

Mise en valeur

Selon la façon dont un document s’affiche au format PDF, l’extraction d’un texte mis en valeur dans un document PDF peut parfois poser des problèmes au logiciel de conversion. Encore une fois, cela vient du fait que la structure PDF n’est autre qu’une représentation visuelle. Le texte est mis en valeur, mais le format PDF ne le précise pas : le logiciel de conversion doit donc uniquement s’appuyer sur l’apparence du texte.

Exposant et indice

Comme le traitement des exposants et des indices dans les documents PDF se limite à la façon dont ils apparaissent dans la mise en page du fichier PDF (plutôt qu’au moyen de balises de type « superscript » ou « subscript »), le logiciel d’extraction a du mal à définir l’alignement vertical du texte. En conséquence, les exposants et les indices sont souvent mal interprétés par le logiciel d’extraction.

Caractères spéciaux

Dans les documents PDF, les caractères spéciaux tels que les symboles étrangers ou mathématiques sont souvent représentés dans des polices inhabituelles ou propriétaires. Afin de les extraire vers un traitement de texte, ces caractères doivent d’abord être convertis en une représentation de caractères plus standard (par exemple, ISO ou Unicode). Bien que de nombreuses suites de logiciels de conversion construisent des tables de conversion pour gérer ces caractères, il est impossible de gérer la grande variété de polices atypiques et propriétaires utilisées. De nombreux caractères spéciaux ne peuvent donc pas à être extraits correctement.

Sous-polices

La façon dont le format PDF incorpore les polices constitue un autre obstacle à une bonne extraction. Parfois, lorsque des fichiers PDF sont créés, le document PDF ne stocke pas les informations de toute la police mais uniquement les parties utilisées dans un document donné. L’accès aux caractères à l’intérieur de cette « sous-police » s’effectue via un tableau indirect dans le document PDF lui-même, ce qui complique l’interprétation et l’extraction des caractères de la sous-police. De nombreux outils de conversion, totalement incapables d’extraire ces caractères, génèrent du texte « incohérent » au lieu d’afficher un contenu extrait avec précision.

Tableaux

Les tableaux sont parmi les éléments les plus délicats à extraire d’un document. Cela s’explique par le fait que l’apparence même d’un simple tableau est déterminée par de nombreux attributs, y compris, entre autres, par la délimitation des colonnes et des lignes, la délimitation de l’en-tête et du corps du texte, l’expansion verticale et horizontale des cellules, les séparateurs de cellules et l’alignement vertical et horizontal des cellules. Aucune de ces informations ne figurant dans le fichier PDF source, il est presque impossible pour un outil automatisé de reproduire un tableau exactement tel qu’il apparaît dans le document original.

Alors que certains documents courts ou simples peuvent être convertis de PDF en Word (et par conséquent de PDF en EPUB) sans trop de difficultés, les ensembles de documents longs ou complexes vous exposent à plusieurs de ces obstacles. Les obstacles inhérents à toute extraction de texte PDF mettent en évidence, premièrement, l’utilité de conserver les versions originales des documents source au format traitement de texte si possible, et deuxièmement, l’importance cruciale de mettre en œuvre une stratégie d’assurance qualité dans tout processus de conversion.

Alors, que faire maintenant ?

Comme beaucoup d’autres entreprises, nous convertissons des millions de pages. Il existe des solutions adaptées à tous les cas précités et à d’autres situations, comme nous le verrons dans de prochains billets.

Des questions sur la conversion ?

Si vous avez des questions spécifiques au sujet de la conversion, utilisez la fonctionnalité de commentaire du site Web pour nous les soumettre. Je tâcherai de vous fournir la meilleure réponse possible.

Il s’avère qu’il existe de subtiles variations dans les définitions que les leaders du secteur et les consultants chevronnés utilisent pour expliquer ce qu’ils veulent dire lorsqu’ils évoquent la publication dynamique. En fait, certains des experts les plus éminents ne proposent aucune définition claire du terme et préfèrent employer des expressions connexes comme « contenu dynamique » ou « diffusion dynamique ».

Selon Ann Rockley, auteur du livre « Managing Enterprise Content: A Unified Content Strategy » (seconde édition) [New Riders, 2012], ce qui différencie le conte

nu dynamique de son cousin statique est le fait que « le contenu dynamique n’existe pas dans un document ou sous forme de document ; les informations sont uniquement assemblées à la demande. Il existe une série d’objets d’information assemblés en réponse aux demandes de l’utilisateur ou [d'autres] exigences ».

« Le contenu dynamique », explique Ann Rockley, « est un contenu assemblé automatiquement pour répondre aux besoins spécifiques des utilisateurs, leur offrant exactement ce qu’ils recherchent, quand ils le souhaitent et au format qui leur convient. »

L’explication d’Ann Rockley concernant le contenu dynamique est simple, mais insuffisante pour répondre à la question : qu’est-ce que la publication dynamique ?

JoAnn Hackos, dans son étude effectuée en 2002, « Content Management Strategies for Dynamic Web Delivery » (Wiley) aborde certains des avantages de la « présentation dynamique de contenus », notamment le « fort potentiel permettant d’offrir aux utilisateurs des ressources en ligne riches en contenus. »

« Les utilisateurs semblent impatients de travailler avec des ressources adaptées à leurs besoins et capables de répondre à leurs requêtes de manière efficace », indique JoAnn Hackos. Ils semblent également « privilégier la personnalisation des informations qu’ils utilisent fréquemment ».

Mme Hackos met en évidence quelques-uns des avantages de proposer du contenu dynamique, en particulier sur le Web, tout en introduisant un terme supplémentaire dans la définition : la personnalisation.

Chez Quark Software, sponsor fondateur de TheDynamicPublisher.com, on est convaincu que la publication dynamique « repose sur deux principes fondamentaux : l’utilisation de contenus XML structurés réutilisables et l’automatisation de la diffusion de ces contenus sur tous les types de média ».

Quark met l’accent sur l’automatisation de tous les processus impliqués dans une solution de publication dynamique de bout en bout, notamment l’automatisation des points suivants :

• Réutilisation des contenus
• Mise en page
• Flux de travail
• Mise en forme et publication multicanaux
• Contenus sur mesure et personnalisés

Et bien que toutes ces informations soient intéressantes et suscitent une vraie réflexion, je n’ai toujours pas de définition claire et sans ambiguïté de la publication dynamique. Ne devrait-il pas y avoir déjà une page Wikipedia consacrée à ce sujet ? En fait, elle existe. Mais, malheureusement, même si la célèbre encyclopédie en ligne créée par les utilisateurs est souvent utile pour répondre à des questions sémantiques, elle n’est pas ici d’un grand secours.

Que faire dans ces conditions ?

Après plusieurs jours passés à tenter de répondre à cette question, j’ai réalisé que la meilleure façon de trouver une définition solide était peut-être de solliciter l’aide de la communauté. Et c’est là que vous intervenez.

Quelle est votre propre définition de la publication dynamique ? Veuillez utiliser la fonction de commentaire de ce blog pour partager vos opinions sur le sujet. La semaine prochaine, je vous proposerai un résumé de nos propositions pour tenter d’élaborer une définition reprenant l’essentiel de nos réflexions.

Scott Abel, Editor, TheDynamicPublisher.com

Il est de plus en plus difficile de fournir les bonnes informations aux bonnes personnes, au bon moment, dans le bon format et la bonne langue,
sur un marché où les appareils mobiles semblent pousser comme des champignons — surtout si vous vous appuyez sur des techniques de publication traditionnelles. Si votre entreprise est dans la même situation que vos concurrents, alors quels que soient vos efforts ou l’argent que vous dépensez pour tenter de résoudre le problème, vous subirez les conséquences de votre dépendance à l’égard des processus centrés sur l’impression papier et les flux de travail obsolètes et laborieux. Mais vous n’êtes pas seul. Il existe des personnes qui comprennent votre problème et sont disposées à partager avec vous ce qu’elles ont appris pour vous aider à sortir du carcan de la publication traditionnelle.

Découvrez TheDynamicPublisher.com. Site Web dédié à l’origine aux informations sur la publication dynamique du point de vue de Quark Software, TheDynamicPublisher.com a évolué pour devenir aujourd’hui une source d’informations centralisée indépendante sur la publication dynamique et d’autres sujets connexes. Je m’appelle Scott Abel, The Content Wrangler, et je suis votre hôte. Mon travail consiste à passer au crible tous les contenus pertinents, informatifs et utiles relatifs à la publication dynamique, issus des experts les plus brillants au monde, et à vous les présenter.

La publication dynamique permet la diffusion efficace des contenus sur les appareils mobiles, à la demande.

Mais ce n’est pas tout. Je suis également chargé de partager ce site avec une communauté dynamique de professionnels désireux de promouvoir les méthodes, normes et outils logiciels nécessaires pour créer, assembler et diffuser des contenus pertinents à ceux qui en ont besoin, de façon dynamique et à la demande.

Pour atteindre mon objectif, je vais demander au public de m’aider à bâtir un corpus de connaissances et une communauté qui serviront de ressources pour ceux qui veulent s’écarter des méthodes inefficaces et obsolètes de création, de gestion et de diffusion des contenus. Cela vous intéresse ? Alors, rejoignez-moi !

Comment participer ?

Si vous avez des questions sur le contenu dynamique et les sujets connexes, envoyez-les-moi par e-mail. Je demanderai à un ou deux experts de vous répondre.

Si vous êtes expert en la matière et souhaitez proposer un article, indiquez-moi ce que vous voulez écrire en précisant le lien de votre article avec la publication dynamique.

Si vous travaillez pour une entreprise qui développe des logiciels ou propose des services connexes destinés à aider les organisations à produire du contenu dynamique et que vous souhaitez devenir un sponsor, indiquez-moi par e-mail comment vous souhaitez participer.

Et si vous êtes intéressé par les thèmes présentés sur ces pages numériques, n’hésitez à pas à les lire et à nous faire part de vos commentaires et questions. Rejoignez la communauté !

TheDynamicPublisher.com est un travail en constante évolution. Nous nous efforcerons de le mettre à jour et de l’améliorer. Si vous avez des idées sur la façon dont nous pouvons améliorer le site, contactez-moi.

Il est d’usage, dans nos sociétés, de « surfer » sur des concepts novateurs, des « buzz », des tendances. Certains deviennent des lames de fond, d’autres s’échouent sur la grève. Et si on revenait aux fondamentaux ?

Dans le monde de l’impression, qui nous intéresse plus particulièrement, l’expression à la mode est « publication numérique ».

Ce terme est généralement utilisé pour désigner la publication sur les nouveaux appareils comme l’iPad, les tablettes Android et autres terminaux mobiles. Mais derrière cette expression, se cache tout un ensemble d’éléments qui demeurent mal appréhendés. J’ai ainsi pu remarquer que de nombreux graphistes ne savent pas trop comment publier sur ces nouvelles plates-formes ni comment créer leur « app », ce qui est a priori leur objectif.

Un parallèle avec l’Internet

Vous vous souvenez d’Internet dans les années 90 ? On peut dresser de nombreux parallèles entre les deux. Les tablettes numériques seront-elles l’Internet de ce début de 21^e siècle ? Bien malin qui pourrait l’affirmer mais il faut bien admettre qu’Apple, avec son iPad, a – une fois de plus – su apporter un souffle novateur sur la publication. Et ce souffle n’est pas près de s’éteindre au regard des prévisions de vente d’une part, du nombre de tablettes concurrentes qui pointent leur nez dans les étals des magasins d’informatique… et des réunions stratégiques qui se multiplient au sein des sociétés pour « voir comment on pourrait profiter de ce formidable support de communication », dixit beaucoup de responsables éditoriaux, tant en agences que dans les groupes de presse.

Surfer, oui mais… en évitant les écueils

Surfer sur la vague (pour reprendre notre analogie nautique) est une bonne chose, synonyme d’une volonté d’avancer. Maintenant, et comme pour toute nouveauté, les écueils sont nombreux. Quelles sont les principales caractéristiques des tendances émergeantes et des nouveaux marchés ? Habituellement, les gens se ruent sur les premières solutions disponibles, puis travaillent à leur amélioration en tenant compte des commentaires des marchés, des préférences des utilisateurs et des modèles économiques. Concernant la publication numérique, j’ai remarqué que les éditeurs de toute sorte (éditeurs d’entreprise, éditeurs de catalogues, ainsi que magazines, journaux et autres « producteurs de contenu » comme les photographes, les artistes et les créateurs) ont vite adopté les tablettes.

Pour s’afficher sur tablette, le contenu est généralement publié via une « app », une application distincte que les lecteurs doivent télécharger et installer.

La plupart des créateurs et des éditeurs ont produit des apps de première génération qui ressemblaient presque à des PDF interactifs, imitant les supports imprimés avec table des matières et pages à feuilleter, linéaires ou empilées, etc. Même s’il s’agit d’une app et que les pages contiennent des objets multimédias (son, vidéo, animations, etc.), le résultat s’apparente à un PDF à peine amélioré. Une critique souvent entendue de la part des professionnels de la publication « classique », et souvent fruit de désillusions. « Tout ça pour ça », entend-on dans les couloirs à la sortie de ces fameuses réunions stratégiques…

« Tout ça pour ça… »

Cette solution a fonctionné un certain temps. Entichés de ce nouveau support, les lecteurs étaient prêts à payer pour obtenir du contenu. Mais assez vite, on a pu constater une perte d’intérêt du fait que l’app magazine ne présentait que peu de valeur ajoutée (outre le format numérique disponible n’importe où).

Je pense que les lecteurs sont passés à autre chose parce que le contenu et la conception n’étant pas adaptés au terminal, ils ne semblaient pas naturels. Le résultat ressemblait trop aux supports imprimés. Ce n’est pas une critique des PDF ni des supports imprimés. C’est juste que les lecteurs sur tablette s’attendent à autre chose. Dit de façon plus prosaïque : « ils en veulent pour leur argent ».

Actuellement, je qualifierais de deuxième génération la plupart des apps de contenu. Par leur aspect et leur fonctionnement, elles ressemblent plus à des pages Web qu’à des PDF. C’est une amélioration, puisque le numérique s’apparente plus aux pages Web qu’au papier.

App de 3^e génération

Mais alors pourquoi ne pas utiliser un navigateur Web pour consulter des pages HTML ? Il semble que pour de nombreux lecteurs utilisant un terminal mobile, lire dans un navigateur est complètement daté (des années 2000, s’entend). Selon une étude récente (http://goo.gl/cgKxb ), les lecteurs passent plus de temps à utiliser des apps qu’un navigateur. Cela signifie probablement que votre contenu attire plus sûrement l’attention et un plus grand nombre de lecteurs (clients, consommateurs) s’il est consultable par le biais d’une app.

Ne nous méprenons pas ! Je trouve formidables certaines apps de première et deuxième génération et il existe des exemples concluants. Toutefois, si vous êtes un créateur qui souhaite diffuser son contenu dans un format enrichi, vous devez constamment vous poser la question suivante : « quelle est la meilleure méthode pour attirer les lecteurs ? ». Le contenu en est une. La conception et la convivialité en sont une autre. Alors, procédez autrement : concevez la nouvelle génération.

Concevez pour le numérique, peu importe le terminal.

Commencez par vous détacher de l’approche des pages à feuilleter. Ensuite, concevez une page que le lecteur peut balayer du doigt et assurez-vous que la mise en page s’adapte au contenu. Envisagez une nouvelle méthode de fournir du contenu : conservez la même trame sans que le contenu semble statique. Enfin, mais seulement si cela renforce votre message, tirez parti des prises de vue à 360°, 3D ou panoramiques de vos produits, intégrez du contenu enrichi dans les diaporamas avec effet de zoom, etc.

En un mot, tirez le maximum de toutes les possibilités offertes par les tablettes.

Contenu + Conception + Créativité

Globalement, le marché n’étant pas encore arrivé à maturité, tout acteur s’y lançant maintenant a toutes ses chances. Il est encore possible de créer des expériences utilisateur parfaitement adaptées aux tablettes, simplifiant la navigation et l’utilisation du contenu. On suivra avec intérêt la façon dont le marché adoptera les apps Web.

Capture d’écran montrant une page au sein d’une app iPad s’adaptant au contenu

Cliquez sur l’image pour voir un exemple de page s’adaptant au contenu avec balayage

(défilement) vertical, capturée dans App Studio de QuarkXPress bientôt disponible.

Parmi les questions à se poser à propos de la publication dynamique, la première d’entre elles devrait être: « Quels sont les types de documents adaptés à la publication dynamique ? » et sa corollaire : « Quels sont ceux qui n’y sont pas du tout adaptés ? ».

Pour répondre à la première question, on peut dire que les documents adaptés à la publication dynamique sont généralement :

• Produits dans le cadre d’un processus formel — il y a des personnes au sein de l’organisation qui sont explicitement chargées de créer, réviser, approuver et diffuser les informations. Les supports marketing et la documentation produit constituent de bons exemples à cet égard.
• Produits souvent — il est nécessaire de les publier fréquemment ou à intervalles réguliers. Ce sont, par exemple, des bulletins d’informations à l’intention des employés ou des partenaires, des propositions de ventes ou de projets et pratiquement tous les journaux, magazines et autres contenus informatifs publiés sur un rythme quotidien, hebdomadaire ou mensuel.
• Personnalisés — par exemple, des états financiers, des publipostages ou autres communications auprès de la clientèle, dont le contenu doit impérativement correspondre aux besoins spécifiques du ou des destinataire(s).
• Mis à jour souvent — par exemple, les fiches techniques, notices techniques ou autres informations qui doivent être mises à jour pour tenir compte de la sortie de nouveaux produits ou de nouvelles fonctionnalités, prestations ou autres capacités évolutives.
• Coûteux à traduire, mettre à jour et redistribuer — ceci peut être vrai de tous les types de documents mentionnés ci-dessus pour les entreprises qui opèrent dans plusieurs zones géographiques.
• Ceux qui doivent être diffusés via de multiples canaux — notamment le papier, le Web et les terminaux mobiles.

Ces types de documents revêtent une grande valeur pour l’entreprise ; les informations qu’ils contiennent sont vitales pour le marketing, la vente, l’installation, l’exploitation, la maintenance, la réparation, la conformité légale ou réglementaire ainsi que d’autres fonctions critiques de l’entreprise.

D’un autre côté, il est probablement injustifiable d’appliquer la publication dynamique :

• Aux documents qui NE SONT PAS produits dans le cadre d’un processus formel (par exemple, les e-mails) ;
• Aux documents à caractère exceptionnel ou rarement produits (par exemple, les rapports annuels).

Le diagramme ci-dessous montre où se situe le juste milieu en termes de caractéristiques des documents faisant que ceux-ci sont adaptés ou non à la publication dynamique. Toutes les caractéristiques de vos documents ne se situent pas nécessairement à la bonne extrémité du spectre, donc servez-vous en simplement comme indicateurs ; votre décision doit reposer principalement sur les gains de temps et d’argent à réaliser, ainsi que sur l’impact que peut avoir l’amélioration de la précision, de la commodité et de la pertinence de vos informations.

En réfléchissant pour déterminer si les documents que vous publiez sont bien adaptés à la publication dynamique, vous constaterez que vous allez cesser de vous concentrer sur les publications proprement dites pour consacrer vos efforts à la création de composants d’information. Votre système de publication dynamique pourra assembler automatiquement ces derniers en différents types de publications et les publier automatiquement sur plusieurs types de médias.

Le monde du développement de l’information a adopté avec enthousiasme la PAO au milieu des années 1980. Les logiciels de PAO et les imprimantes laser nous ont donné la possibilité de produire des documents plus lisibles et au sein desquels il était plus simple de naviguer. Nous avons été en mesure d’éliminer les coûts liés à la composition tout en conservant une partie de la qualité de présentation que celle-ci permet.

Bien que le SGML (Standard General Markup Language) ait été déjà disponible et largement utilisé par de grandes entreprises comme IBM, Hewlett-Packard et de nombreux organismes publics, la combinaison de Microsoft Word et de divers systèmes de PAO en était venue à dominer le marché.  Tous ces produits étaient propriétaires, c’est-à-dire possédés, développés et contrôlés par une organisation à but lucratif. Dès que vous aviez créé un contenu à l’aide d’un certain produit, vous étiez virtuellement lié à ce produit. Il était devenu – et il demeure – très difficile et onéreux de migrer d’un produit vers un autre.

À partir du milieu des années 80, tout au long des années 90 et maintenant au 21ème siècle, avec l’introduction du XML (eXtensible Markup Language) afin de favoriser le développement d’Internet en tant qu’outil de communication, de nombreuses entreprises, les grandes particulièrement, ont décidé de développer des applications maison en travaillant en SGML, en personnalisant la norme DocBook XML d’OASIS ou en développant un environnement de création et de publication maison exclusif et propriétaire.

Au fil des ans, l’équipe de Comtech a travaillé avec un grand nombre de clients – notamment IBM, Hewlett-Packard, Bell Laboratories et diverses entreprises de télécommunications telles que Lucent, Alcatel, Nortel et bien d’autres – qui avaient développé des systèmes SGML et XML propriétaires en interne.  J’ai personnellement travaillé en étroite collaboration avec la cellule de développement de l’information de SAP pour aider au développement de leur environnement de création interne.

Le succès de ces systèmes SGML et XML maison reposait sur leurs fortes capacités de personnalisation permettant de traiter très exactement les types de contenus fournis aux clients internes et externes. Dans certains cas, les systèmes maison sont extrêmement fonctionnels, soutenus par des environnements de création conviviaux. Dans d’autres, leurs fonctionnalités laissent à désirer par rapport à ce que l’on trouve dans les produits du commerce et leur interface utilisateur est quelque peu passée de mode. Le problème se situe au niveau des ressources. En effet, le coût de la maintenance d’un système maison, entièrement à la charge de l’entreprise, est élevé.

L’un des grands noms du secteur des télécommunications dans les années 90 avait besoin d’une équipe de 15 personnes pour assurer la maintenance de son système maison. Cette équipe fit un excellent travail. Elle créa un système à la pointe du progrès au début des années 90, qui continua à être financé afin de pouvoir l’actualiser et d’assurer sa maintenance – et ce jusqu’à l’effondrement de l’industrie des télécommunications vers l’an 2000. Suite à cet effondrement, la direction réévalua les avantages du système maison par rapport à son coût et finit par migrer vers des produits du commerce, compatibles avec les normes internationales. Le coût des produits développés commercialement peut être amorti sur un grand nombre d’implémentations en clientèle. Qui plus est, les normes sur lesquelles ces produits sont basés sont développées et actualisées par une communauté de bénévoles qui contribuent leur expertise technologique et sectorielle.

La motivation des entreprises pour le changement

Lors de la conférence DITA Europe 2010, patronnée par le CIDM (Center for Information-Development Management), Thilo Buchholtz et Teresa Pask de SAP ont expliqué avec éloquence pourquoi leur organisation d’apprentissage et de formation avait décidé d’abandonner son système de création et de gestion de contenus XML maison et d’adopter à sa place la norme DITA d’OASIS.

Ils ont expliqué, comme tout développeur d’information en conviendra, que l’information doit être développée rapidement et fournie aux clients en temps opportun. Et que les informations provenant de plusieurs sources doivent être intégrées, y compris celles provenant des partenaires.

Buchholtz et Pask ont déclaré que « l’adhésion au modèle de données et au jeu d’outils d’une norme industrielle permet une intégration rapide des nouvelles technologies et modalités, ainsi que l’apport des contenus d’autres contributeurs et de ceux de partenaires ». Pour l’organisation d’apprentissage et de formation de SAP,

- DITA est conforme à l’orientation souhaitée par l’entreprise pour les contenus critiques pour les clients.

- DITA fournit une architecture modulaire qui prend en charge les produits finis à contenus multiples issus d’une source unique.

- Davantage de technologies sont disponibles pour prendre en charge la norme DITA.

- La communauté open source soutient les mutations technologiques.

Je découvre régulièrement, lors de discussions avec des cadres dirigeants, que leurs entreprises ont déjà décidé de renoncer, comme SAP, à leur environnement XML maison sain mais onéreux pour adopter la norme DITA. Mais le seul coût de la maintenance d’un système maison ne suffit pas à expliquer de telles migrations. Il faut ajouter que la norme DITA est synonyme d’interopérabilité, une considération essentielle en cette période qui voit de plus en plus d’entreprises se regrouper.

Fusions et acquisitions

Que se passe-t-il lorsqu’une société utilisant un système maison propriétaire rachète une autre société qui possède son propre système maison propriétaire ? Un groupe doit généralement migrer vers le système propriétaire de l’autre, la plupart du temps à grands frais. Et que se passe-t-il lorsqu’une société utilisant la norme DITA rachète ou fusionne avec une autre société utilisant elle aussi la même norme DITA ? Elles fusionnent généralement leurs contenus, même si elles ont toutes deux des spécialisations DITA en place. Si elles utilisent une solution DITA clé en main, la fusion n’impose qu’une intégration des deux modèles d’information. Cette intégration, bien que nécessitant de s’entendre sur les détails de l’architecture, est infiniment plus simple et moins onéreuse que celle de deux systèmes propriétaires.

Intégration de contributeurs de contenus et de systèmes de gestion de contenus

Si chaque organisation utilise des outils de création ou des systèmes de gestion de contenus différents, pour autant que ces systèmes sont basés sur la norme DITA, l’intégration peut être plutôt simple. En fait, nous avons contribué à une migration de ce type vers un nouveau système de gestion de contenus. Nous exportons toutes les données d’un système, y compris tous les contenus traduits, vers l’autre système à l’aide de scripts automatisés. Les deux systèmes prennent en charge la norme DITA, avec peu de fonctions propriétaires qui ne peuvent être « traduites » dans l’autre système.

Le rôle des organismes de normalisation dans l’abandon des modèles maison et propriétaires

Laurent Liscia, directeur général d’OASIS, a rédigé une série d’articles sur les normes et l’innovation pour CIDM Information Management News, notre e-newsletter mensuelle.

Dans CIDM Information Management News de février 2010, il dévoile une partie de l’historique du développement des normes. Il explique que des organismes approuvés par le gouvernement avaient développé de nombreuses normes dans le passé. Nous savons, par exemple, que certaines agences du gouvernement américain diffusent des normes concernant la sécurité au travail ou la manutention des aliments dans de bonnes conditions sanitaires. De telles normes de jure ou légalement requises sont adossées à des textes de lois.

Plus récemment, des normes ont été développées non pas par les gouvernements mais par des organismes de normalisation tels qu’OASIS, qui bénéficient du soutien des industries intéressées. Il explique que « en 1988… l’Europe a eu la brillante idée de créer un organisme de normalisation qui impliquait non pas les seules administrations des Postes et Télécommunications, mais également des entreprises privées d’Europe et d’ailleurs ».

Des innovations qui avaient été développées en interne par des sociétés – comme ce fut le cas de DITA, développée par IBM – se sont transformées en un ensemble de technologies partagées et ouvertement accessibles. Les normes sont devenues un excellent moyen pour tous de partager les responsabilités et le coût du développement de produits.

Il est clair que la migration vers les normes a été motivée par des considérations d’ordre financier. En travaillant ensemble, les représentants de l’industrie avaient en effet la possibilité de partager le travail de définition et de développement d’une technologie innovante. C’est exactement le résultat que nous avons pu voir avec le développement de la norme DITA. Même si le processus de normalisation a été mis en route par IBM pour faire face à ses propres exigences internes, en faisant don de la norme DITA 1.0 originale à la communauté normative OASIS, IBM a permis à de nombreuses autres sociétés de s’y impliquer. Le développement de la norme est maintenant soutenu par les travaux de nombreux contributeurs.

Toutefois, la répartition des coûts de développement à travers tout un secteur industriel n’est que l’un des avantages des normes. L’aptitude à transférer les ressources d’information d’une société vers une autre, pour cause de fusions et d’acquisitions ou par le biais de partenariats commerciaux, est devenue essentielle. De nos jours, le contenu de la norme DITA peut être :

- Utilisé par plusieurs départements et dans la totalité de l’entreprise à l’échelle mondiale.

- Partagé entre diverses industries connexes.

- Géré par des réorganisations d’entreprise.

Laurent Liscia fait remarquer que « les sociétés proliférant dans ce domaine, l’idée d’une interopérabilité entre les nombreux produits logiciels disponibles faisait de plus en plus son chemin ».

La décision de communiquer via Internet, la migration vers les logiciels Open Source et l’utilisation du XML comme fondation ont été autant d’éléments contribuant à la migration vers les normes. Toutes ces influences ont aidé à promouvoir l’innovation via DITA, en introduisant de nouveaux modes de développement et de gestion de l’information.

Il nous dit également que « la plupart du temps… une norme logicielle EST l’innovation, plutôt que le résultat d’innovations devant être normalisées. Par exemple, [OASIS possède] un ensemble de comités techniques qui font porter leurs efforts sur l’amélioration des réseaux d’énergie électrique – ce que l’on appelle l’effort Smart Grid. Les participants ont une bonne idée de ce qu’ils veulent faire, mais ce qu’ils veulent faire n’existe pas encore et changera au fur et à mesure qu’ils réaliseront leur vision collective, par le biais de commentaires publics, de contributions ouvertes et de scrutins ».

Depuis son introduction en 2006, nous avons été témoins de l’adoption de la norme DITA par un grand nombre d’entreprises. Cette adoption réduit considérablement le coût de l’implémentation de la création structurée sur base XML. Les entreprises en question peuvent s’appuyer sur :

- Les développeurs de produits qui adoptent la norme.

- Des opportunités de formation efficaces et bien organisées.

- Des articles, des livres blancs, des blogs, des présentations dans le cadre de conférences et des livres.

- Une communauté talentueuse de consultants et de collègues.

Les entreprises qui encouragent leur direction à soutenir une migration vers DITA sont à même de faire valoir que l’adoption d’une norme internationale développée par une communauté de représentants de l’industrie est une démarche qui leur est bénéfique. Les dirigeants, souvent issus de l’ingénierie et du développement logiciel, comprennent l’importance des normes. Leur propre travail repose sur des normes, dont beaucoup ont aussi été développées par la communauté OASIS.

Si vous vous préparez à recommander l’adoption de la norme DITA d’OASIS, vous serez en bonne compagnie, non seulement avec d’autres développeurs d’information mais aussi avec toute la communauté normative.

La publication dynamique, c’est simple. Vous prenez des gabarits qui garantissent la qualité de la mise en page, vous les introduisez dans un système qui coordonne la collaboration à l’échelle internationale et abat les frontières entre maquettistes et services techniques et, une fois que vous êtes prêt, vous n’avez plus qu’à appuyer sur le bouton “Sortie” : à partir de là, le message marketing est publié automatiquement sur tous les canaux, depuis le papier jusqu’à Facebook en passant par le Web, l’iPhone et l’iPad. Et c’est tout. La publication dynamique, c’est réellement aussi simple et aussi révolutionnaire que cela. Dans cette série d’articles pour Cleverprinting, nous avons procédé à un examen approfondi des éléments déterminants pour la publication dans le futur :

-       Les gabarits, qui mettent en œuvre une mécanique de mise en page complexe pour donner vie aux informations issues des manuels d’identité visuelle et permettent de réaliser des maquettes parfaitement conformes. Ces gabarits contiennent l’intégralité du savoir-faire des graphistes. Ce sont ces derniers, à travers la production de gabarits, travail exigeant et particulièrement important, qui rendent possible la publication dynamique.

-       Les systèmes de gestion de contenus, qui régissent la coopération au sein des équipes et canalisent les projets via des flux de travail. Ces systèmes mettent à bas les murs qui séparent les concepteurs graphiques, avec leurs logiciels de mise en page, des services techniques utilisant la suite Microsoft Office. Tous les intervenants travaillent au sein d’un même système et peuvent influer à tout moment sur l’avancement du projet via des interfaces web.

-       Les processus automatisés captent les tâches en fonction de leur statut dans les systèmes de gestion de contenus et ont un effet multidirectionnel : ils permettent non seulement de produire automatiquement des maquettes d’emballages ou des fiches techniques de produits, mais alimentent aussi les sites web et les réseaux sociaux en contenus. Ou bien ils permettent de publier de nouveaux messages sur l’iPhone ou dans les magazines iPad. Cette publication cross-média s’effectue automatiquement sur la base de gabarits conçus spécifiquement pour chaque support.

Les gabarits, les systèmes de gestion de contenus et les systèmes automatisés sont les conditions fondamentales d’un marketing efficace dans le monde globalisé d’aujourd’hui et face à une exploitation sans cesse plus fragmentaire des médias. Du fait de l’émergence constante de nouveaux canaux marketing, il n’est pratiquement plus faisable, financièrement parlant, d’assurer un approvisionnement distinct en contenus pour chacun d’eux. Ceci vaut également pour la coordination de projets au sein d’équipes toujours plus étoffées dont les membres se situent aux quatre coins du monde. Dans un tel cas, la publication dynamique libère tout son potentiel et assure dans le même temps l’avenir du marketing.

Dans ce dernier article de notre série, nous allons voir comment les trois éléments déterminants de la publication dynamique vont venir s’imbriquer pour former un projet parfaitement tangible : celui d’une application de messagerie iPhone pour l’entreprise de chemins de fer Arosa Bergbahnen dans le canton des Grisons, en Suisse. L’application offre l’essentiel de ce qui est important tant pour les simples visiteurs que pour les inconditionnels de cette région dédiée au ski : la météo, des webcams, une carte des pistes et, d’abord et avant tout, les dernières nouvelles. Ces actualités forment le cœur de l’application et proposent, souvent sur une base quotidienne, des informations sur les manifestations sportives et autres événements, la campagne de ski ou la vie nocturne.

[Fig. : Différentes parties de l'application Arosa]

Lors de la conception de l’application, il a été décidé que les “flux de nouvelles” en formeraient l’élément central : il ne devait pas s’agir de solutions isolées et le traitement marketing pour maintenance du contenu devait nécessiter le moins de temps possible. C’est pourquoi l’application iPhone a été intégrée à un concept architectural durable ; elle est devenue, à l’instar d’autres mesures de marketing, partie intégrante d’un système de publication dynamique.

Et voici comment tout cela fonctionne :

1.    Des supports publicitaires sont produits pour un événement devant se passer à Arosa. Pour faire connaître celui-ci, des affiches sont placardées et des prospectus distribués sur le plan local. On utilise pour les produire un logiciel de mise en page papier. Lors de leur création, on se sert évidemment de gabarits extrêmement élaborés qui intègrent déjà les éléments d’identité visuelle et sont automatisés dans une large mesure. La réalisation de ces gabarits est la principale discipline relevant des créatifs et des graphistes. La publication dynamique ne peut devenir réalité que grâce à des gabarits parfaitement élaborés.

[Fig. : Les projets de maquette sont réalisés à partir de gabarits flexibles conformes à l'identité visuelle et transférés à un processus de coordination.]

2.    Dans un processus conventionnel, la coordination du contenu et du graphisme fait alors appel à des allers-retours de fichiers PDF. Le client indique les modifications qu’il souhaite dans le fichier PDF, renvoie celui-ci, attend le retour du PDF corrigé, vérifie si ses modifications ont bien été implémentées, signale les nouvelles modifications à faire, etc…
Par contre, dans un environnement de publication dynamique, le client est directement impliqué dans le processus et peut effectuer directement toutes les modifications qu’il veut grâce à une interface accessible via un navigateur web. Dès qu’il les a faites, il renvoie le tout à l’agence par l’intermédiaire du système. Ainsi, le projet demeure canalisé étape par étape dans le flux de travail jusqu’à la commande d’impression. Dans ce processus, il n’y a pas de fichiers PDF à visualiser ni de revérifications fastidieuses à effectuer. Tous les intervenants travaillent dans le cadre d’un seul et même système. L’architecture modulaire permet à plusieurs personnes de travailler simultanément sur les mêmes projets. Le client peut intervenir sur les textes via le Web tandis que le maquettiste affine son design dans le logiciel de mise en page. La synchronisation des deux opérations a bien lieu en temps réel. Cela ouvre également de fantastiques opportunités d’amélioration de la gestion des projets : ainsi peut-on répondre directement à des questions telles que « Où exactement sommes-nous coincés dans le texte ? » ou « Qu’en est-il de l’état d’avancement de notre annonce publicitaire ? » via le système, sans semer le chaos dans le projet. La collaboration par l’intermédiaire d’un système de gestion de contenus constitue une nouvelle expérience de travail qui, une fois que l’on y a goûté, se révèle indispensable.

[Fig. : Le client peut accéder directement au projet via un point d'accès en ligne intégré et, par exemple, apporter des modifications aux textes. L'environnement agence "normal" est toujours présent à l'arrière-plan et est actualisé en temps réel.]

3.    Si le produit papier a atteint le stade de la commande d’impression, un fichier PDF pour impression est produit automatiquement sur la base du statut de “Sortie”. Mais ce n’est pas tout. Une case à cocher spéciale “Envoyer vers mobile” dans le système de gestion de contenus entraîne également la publication automatique des informations sur l’iPhone. Toutefois, l’opération ne s’effectue pas par un simple transfert 1:1 du PDF dans l’application par Arosa. Au lieu de cela, les contenus sont extraits de la mise en page papier et recompilés sous une forme optimisée en vue de l’affichage sur l’iPhone. Pour ce faire, on passe par un procédé dit de “transformation XML”, qui sépare les contenus de la mise en page et en permet l’affichage spécifique pour chaque canal de diffusion. La partie Actualités de l’application iPhone devient ainsi virtuellement une réapplication générée automatiquement du produit papier. Néanmoins, le point le plus important est que le canal iPhone peut être actualisé de cette façon sans la moindre dépense supplémentaire.
On notera incidemment qu’il est possible de s’échapper à tout moment de ce processus centré sur le papier. Ainsi, certains contenus réservés exclusivement à l’iPhone peuvent n’être publiés que sur ce canal. Mais, bien entendu, on pourra aussi les réutiliser ultérieurement sur d’autres canaux.

[Fig. : La publication cross-média authentique sépare le contenu de la mise en page. Du fait de la présence d'un "déclencheur" dans le système de gestion de contenus, un processus est lancé qui décompose le produit papier mis en page en éléments individuels qui sont réassemblés pour publication sur l'iPhone. Ceci se fait naturellement dans le respect des normes d'identité visuelle de l'entreprise.]

Tout cela débouche sur une intéressante perspective stratégique : de la même façon que pour le canal iPhone, d’autres canaux marketing pourront ainsi être exploités à l’avenir. La présence sur le Web, par exemple, ou bien d’autres plates-formes logicielles pour smartphones. L’investissement à engager pour produire une application Android, par exemple, n’est plus aussi élevé parce que les flux de nouvelles existent déjà. Cela signifie qu’il est possible d’assurer la modification du contenu et la publication dans le cadre d’un seul et même processus : une fois généré, le contenu peut être réutilisé à volonté. On bénéficie d’un effet de synergie, en particulier parce que les laborieuses opérations manuelles de copier-coller, si propices aux erreurs, et la synchronisation entre les différents médias sont désormais superflues.

Le projet Arosa n’est pas une vision, c’est la réalité. La publication à partir de gabarits, les nouvelles formes de collaboration et la publication cross-média ne sont plus des fantasmes. Les philosophies qui sous-tendent la publication dynamique marquent un tournant dans le domaine de la production de médias. À l’avenir, les projets se dérouleront moins dans le cadre habituel de la PAO conventionnelle, mais plus dans les nouveaux paradigmes de la publication dynamique.  Ceci représente une opportunité exceptionnelle pour toute la communauté de la création graphique. Le travail du graphiste va prendre plus d’importance et, notamment pour ce qui concerne la création de gabarits, il va devenir plus exigeant et moins interchangeable. L’agilité marketing nouvellement acquise va permettre aussi bien aux clients qu’aux agences d’économiser du temps et de l’argent sur le long terme, et ainsi de distancer leurs concurrents sur le marché. Tout ce dont vous avez besoin pour la publication du futur est d’ores et déjà à votre disposition : saisissez-le dès maintenant !

Georg Obermayr

Première partie : Introduction

Deuxième partie : Web-to-print (liens, aperçu du marché)

Troisième partie : Systèmes éditoriaux (liens, aperçu du marché)

Quatrième partie : Systèmes de publication intégrés (liens, aperçu du marché)

Cinquième partie : Conclusion

Chez Quark, nous sommes toujours très occupés à développer des logiciels de publication dynamique pour les médias numériques. Dans le cadre de ce travail, nous nous entretenons avec des analystes, les médias et les clients, qui tous nous confirment que les entreprises sont à la recherche du meilleur moyen d’atteindre les consommateurs sur les tout derniers gadgets numériques (dont le plus attractif est, bien entendu, l’iPad). Qui les en blâmerait ? Après tout, l’institut Forrester prédit que « les ventes de tablettes aux USA vont plus que doubler en 2011 pour atteindre les 24,1 millions d’unités ».¹

En repensant à ce besoin immédiat de passer au numérique, je me suis rendue compte récemment que cet engouement pour le numérique était vraiment la goutte qui avait fait déborder le vase. Il est une priorité que l’on ne peut plus ignorer ni même différer : le besoin de remettre au goût du jour des processus de publication désormais dépassés.  Pour publier à la fois sur papier et sur le Web, de nombreuses organisations – qu’il s’agisse d’entreprises ou de groupes de médias – se sont contentées au départ d’ajouter simplement des ressources supplémentaires, voire dans quelques cas une équipe entièrement distincte. Mais avec l’apparition des liseuses électroniques, des smartphones et des tablettes, la plupart de ces organisations n’ont plus les moyens d’investir de l’argent et des ressources supplémentaires pour exploiter ce nouveau canal.

Pourquoi cela ? Parce qu’il ne s’agit pas d’effectuer un simple replâtrage.  Il ne s’agit pas que de diffuser des contenus sur un nouveau support ; il s’agit de faire vivre au client une toute nouvelle expérience.  Mais alors, que veulent les clients ?

- Ils veulent pouvoir accéder à leurs informations dans tous les formats à leur disposition : Web, papier et numériques.

- Ils veulent avoir ces informations à portée de main, tout comme les appareils qu’ils emmènent avec eux toujours et en tout lieu.

- Ils veulent pouvoir interagir avec ces informations, et pas seulement les lire.

La publication dynamique :  une solution astucieuse

Il y a de cela quelques années, nous définissions la publication dynamique comme « la rencontre entre la composition graphique professionnelle et la publication multicanal automatisée ».  Voyons un peu en détail en quoi elle permet à une entreprise d’étancher la soif d’informations de ses clients :

- Pour mettre en œuvre une publication cross-média économiquement rentable, les entreprises doivent rechercher des moyens de rationaliser et d’automatiser leurs processus. Ceci nécessite une plate-forme de publication prenant en charge un processus collaboratif pour créer des contenus qui conviennent à chaque type de média, plus un processus automatisé afin de diffuser lesdits contenus. Cette plate-forme doit impérativement être flexible de façon à pouvoir s’adapter à l’évolution rapide de la technologie qu’alimente encore un peu plus l’explosion des tablettes.

- Pour diffuser les informations de manière cohérente, avec précision et immédiatement à tous les médias, les entreprises doivent réutiliser et réorienter les contenus autant qu’elles le peuvent. La première étape dans la création d’un système de publication dynamique de bout en bout consiste à démarrer avec des composants de contenu qui pourront être assemblés automatiquement. Cela ne nécessite pas seulement de passer par le format XML, mais aussi de fournir à l’utilisateur normal de Microsoft Word un moyen simple et familier de créer et modifier du contenu XML.

- Pour tirer parti de la technologie qu’offrent les terminaux mobiles, les entreprises doivent être capables de créer et de faire vivre des expériences convaincantes, de manière à ce que les clients puissent interagir avec les informations.  Tous les signaux tendent à indiquer que la communication va continuer à se faire de plus en plus interactive, combinant le design visuel avec l’audio, la vidéo et d’autres fonctionnalités afin de faire évoluer l’expérience des marques.

Le raz de marée des tablettes est arrivé de nulle part et Quark ne s’y attendait pas plus que les autres ; mais parce que nous avons choisi d’axer notre stratégie sur la publication numérique, nous sommes prêts à y faire face. Et nous sommes très contents, parce que cela valide notre approche et confirme qu’il s’agissait bien de celle à adopter. Aussi, lorsque votre vase va se mettre à déborder, peut-être serait-il bon de penser à Quark pour trouver la solution à votre problème.

[1] Sarah Rotman Epps. (4 janvier 2011). US Tablet Sales Will More Than Double This Year (les ventes de tablettes aux USA vont plus que doubler cette année) [billet sur son blog]. À consulter à cette adresse : http://blogs.forrester.com/sarah_rotman_epps/11-01-04-us_tablet_sales_will_more_than_double_this_year.