DITA… vous n’en voulez pas ?

 

DITA, pourquoi s’embêter ?

C’est la question que se sont posés les collègues sur un groupe de discussion LinkedIn (DITAToo community).

L'emblème DITA

Grosso modo : faut-il adopter ce standard ?

En dehors des discussions sur la difficulté d’adopter ce standard (on a tout entendu : « non, c’est trop compliqué, mes rédacteurs ne comprendront pas » ou « non, on n’a adopté qu’une partie du standard, parce que les rédacteurs ne comprendront pas la catégorie « CONCEPT »… Euh… ils sont dérangés mentalement vos rédacteurs ? Ils n’arrivent pas à comprendre la différence entre une TACHE, un CONCEPT et une REFERENCE ?…), il faut s’arrêter sur la réponse de JoAnn Hackos :

L’avis de l’experte

Don’t forget that there is another reason for adopting standards, one that I try to impress of organizations that are thinking of a move to DITA. Engineering organizations understand standards; they already adopt standards for their engineering work. IT organizations may feel the same way, because they understand the cost of proprietary solutions that make it difficult to migrate to new systems or products. Corporate management generally understand the value of adopting products that are standards-based.

Dernière publication JoAnn Hackos

I recently spoke about the DITA standard at a meeting of Chinese standards representatives. It seems clear that they value standards in their emerging economy. Read some of the articles we have published in the CIDM e-news by Laurent Liscia, executive director of OASIS, on the standards process. Very enlightening.

Using a standard, based on the work of volunteer committee members, means that organizations do not have to pay the cost of updating their own proprietary systems. Many organizations that originally developed their own proprietary information architecture in XML are considering a shift to DITA because it will ultimately be less costly to maintain.

 

Expériences…

On a vu, en effet, des projets dans lesquels vous passiez vos journées à changer un nom de produit, un par un, en allant chercher le morceau de texte sur le serveur (longues minutes d’attente pour le telechargement), en y rentrant les modifications de balises (date de mise à jour, auteur de la modification,…) puis en changeant enfin le nom du produit (sans outil de recherche automatique), en sauvegardant et ensuite déposant le fichier modifié sur le serveur. Quatorze étapes pour une seule modification ! Qui dit mieux ?

Tout délocaliser ?

Cela veut dire que toutes ces modifications et vilains bidouillages ont un COUT ! A un certain moment, l’entreprise commence à trouver le budget documentation un peu trop lourd.

Que se passe-t-il ?

Et bien, on délocalise ! Parce que tant qu’à faire de passer son temps à faire et refaire, on peut demander à des prestataires indiens ou chinois (beaucoup moins chers) de faire le travail, n’est-il pas ?

Et c’est ainsi que de nombreuses équipes de documentation se sont réduites, en Europe, à une peau de chagrin : une ou deux personnes tout au plus pour gérer les projets !

 

Laisser un commentaire