The Documentation System

Une des clés à connaître pour la rédaction d’une bonne documentation logicielle est qu’il n’y a pas un seul type de documentation, il y en a quatre.

Il s’agit des didacticiels, des guides pratiques, des références techniques et des explications. Ils représentent quatre objectifs ou fonctions différentes et nécessitent donc quatre approches différentes pour leur écriture. Comprendre ce que cela implique permet d’améliorer la manière de rédiger vos documentations.

Le système décrit ici est basé sur des règles simples et généralisables qui ont fait leurs preuves dans la pratique dans une grande variété de domaines et d’applications.

Il existe des principes très simples qui régissent la documentation et qui sont très rarement, voire jamais, explicités.

Introduction

Problème et solution

Le problème à résoudre

Peu importe la qualité de votre produit si sa documentation n’est pas suffisamment bonne les gens ne l’utiliseront pas. Et s’ils doivent l’utiliser parce qu’ils n’ont pas le choix, ils ne le feront pas correctement ou n’y prendront pas plaisir.

C’est un état de fait : tout le monde sait qu’il faut une bonne documentation et la plupart des gens essaient d’en créer une de bonne qualité. Mais souvent échouent. Et en général ce n’est pas une question d’efforts, mais plutôt de méthode et d’approche.

Cet article se veut être un moyen pour vous aider à améliorer votre documentation. Non pas en y mettant plus d’efforts mais en le faisant de la bonne manière. La bonne manière est la plus simple : plus facile à rédiger et plus facile à maintenir.

Le « secret »

La documentation doit être structurée autour de quatre fonctions différentes : didacticiels, guides pratiques, références techniques et explications. Chacune d’entre elles nécessite un mode d’écriture distinct. Les personnes qui travaillent avec des logiciels ont besoin de ces quatre types de documentation à des moments différents et dans des circonstances différentes. Les logiciels en ont donc généralement besoin de toutes, et elles doivent toutes être intégrées à votre documentation.

La documentation doit être explicitement structurée autour d’eux, et ils doivent tous être conservés séparés et distincts les uns des autres.

Cette division permet à l’auteur et au lecteur de savoir clairement quel type de document se situe à quel endroit. Elle indique à l’auteur comment écrire, quoi écrire et où l’écrire. Elle évite à l’auteur de perdre beaucoup de temps à essayer de mettre en forme les informations qu’il souhaite transmettre, car chacun de ces types de documentation n’a qu’une seule fonction.

En fait, il est extrêmement difficile de maintenir une bonne documentation qui ne reconnaisse pas implicitement ou explicitement les quadrants de ce schéma. Les exigences de chaque type sont différentes de celles des autres, donc toute tentative de documentation qui ne parvient pas à maintenir cette structure en souffre, car elle est tirée dans plusieurs directions différentes à la fois.

Une fois que vous avez compris la structure, cela devient un outil très utile pour analyser la documentation existante et comprendre ce qui doit être fait pour l’améliorer.

Dans les sections suivantes, chacune de ces quatre parties est traitée en détail.

Faire une documentation qui marche

Pour les auteurs

L’un des plus gros problèmes auxquels les personnes chargées de rédiger la documentation doivent faire face est de ne pas avoir une idée claire de ce qu’ils doivent faire. Ils écrivent et réécrivent, mais ont du mal à faire en sorte que tout s’assemble de manière cohérente.

Cette méthode tente de résoudre ce problème en établissant des distinctions et des séparations claires. Elle permet de créer une documentation plus facile à rédiger et à maintenir, plus facile à utiliser et à consulter.

La documentation ne s’écrit pas toute seule, mais il est ainsi possible de la rédiger sans avoir à se soucier d’un manque d’adéquation, d’un champ d’application flou ou d’un doute sur ce qui doit être inclus ou sur le style à adopter. Il devient beaucoup plus facile de comprendre ce qu’il faut écrire, comment l’écrire et où le placer.

Pour les lecteurs

Il sert mieux les utilisateurs car pour toutes les différentes phases du cycle de leur interaction avec le logiciel ils trouveront le bon type de documentation qui répond aux besoins du moment.

La rédaction d’une documentation qui aborde explicitement et distinctement chacun des quatre quadrants aide le logiciel à attirer et à fidéliser davantage d’utilisateurs, qui l’utiliseront plus efficacement. Et c’est l’une des choses que les créateurs de logiciels souhaitent le plus.

Didacticiels

Les didacticiels sont des leçons qui guident le lecteur à travers une série d’étapes pour mener à bien un projet quelconque. Ils sont requis par votre produit pour montrer à un débutant ce qu’il peut réaliser avec.

Ils sont entièrement axés sur l’apprentissage et plus précisément vers le comment plutôt que le quoi.

Vous êtes l’enseignant et vous êtes responsable de ce que l’élève va faire. Sous vos instructions, l’élève va exécuter une série d’actions pour atteindre un objectif. Le but doit être significatif, mais aussi réalisable par un réel débutant. L’important est qu’après avoir suivi le didacticiel, l’élève soit en mesure de comprendre le reste de la documentation et le logiciel par lui-même.

La plupart des logiciels ont des didacticiels de mauvaise qualité, voire inexistants. Or, ce sont les didacticiels qui transformeront vos élèves en utilisateurs. Un didacticiel de mauvaise qualité ou manquant empêchera votre produit d’acquérir de nouveaux utilisateurs.

Parmi les sections décrivant les quatre types de documentation, celle-ci est de loin la plus longue, car les didacticiels sont les plus mal compris et les plus difficiles à réaliser. La meilleure façon d’enseigner reste d’avoir un enseignant présent qui interagit avec l’élève. Lorsque ça n’est pas possible, les didacticiels écrits seront au mieux un substitut loin d’être parfait. C’est une raison de plus pour leur accorder une attention particulière.

Les didacticiels doivent être utiles aux débutants, faciles à suivre, pertinents, extrêmement robustes et tenus à jour. Vous constaterez peut-être que la rédaction et la maintenance de vos didacticiels peuvent occuper autant de temps et d’énergie que les trois autres parties réunies.

Analogie avec la cuisine

Prenons l’analogie de l’apprentissage de la cuisine à un enfant.

Ce que vous apprenez à cuisiner à votre enfant n’est pas vraiment important. Ce qui compte, c’est que l’enfant trouve cela agréable, qu’il prenne confiance en lui et qu’il ait envie de le refaire.

Au travers des activités auxquelles l’enfant participe, il apprendra des aspects importants de la cuisine. Il acquerra de l’expérience en cuisine, dans l’utilisation des ustensiles et dans la manipulation des aliments.

Car utiliser un logiciel, comme cuisiner, est une forme d’artisanat. C’est un savoir, mais c’est un savoir pratique, pas un savoir théorique. Or lorsque nous apprenons un nouveau métier ou une nouvelle compétence, nous commençons toujours par la pratique.

Comment écrire de bons didacticiels

1. Permettez à l’utilisateur d’apprendre en faisant

Au début, nous n’apprenons qu’en faisant : c’est ainsi que nous apprenons à parler ou à marcher.

Dans votre didacticiel logiciel, votre élève doit effectuer des tâches. Les différentes tâches qu’il doit effectuer au fil de votre didacticiel doivent couvrir un large éventail d’outils et d’opérations, des plus simples jusqu’aux aux plus complexes.

2. Bien démarrer

Il est normal que les premiers pas de votre élève soient vraiment simples. Il est également normal que ce que vous demandez au débutant de faire ne soit pas comme le ferait une personne expérimentée, ou même que ce ne soit pas la « bonne » manière. Un didacticiel pour débutants n’est pas la même chose qu’un manuel de bonnes pratiques. L’objectif d’un didacticiel est de permettre à votre élève de démarrer son parcours d’utilisateur, et non de l’amener à une destination finale.

3. Assurez-vous que votre didacticiel fonctionne

L’une de vos tâches en tant que tuteur est d’inspirer la confiance du débutant : dans le logiciel, dans le didacticiel, dans l’enseignant et, bien sûr, dans sa propre capacité à réaliser ce qui lui est demandé.

Plusieurs facteurs contribuent à cela. Un ton amical, un langage cohérent et une progression logique dans le cours sont des éléments importants. Mais le plus important est que ce que vous demandez au débutant de faire fonctionne. L’élève doit voir que les actions que vous lui demandez d’effecter ont l’effet que vous lui avez promis.

Si les actions de l’élève provoquent une erreur ou un résultat inattendu votre didacticiel a échoué même si ce n’est pas de votre faute. Lorsque vos élèves sont là avec vous vous pouvez les sauver. S’ils lisent votre documentation par eux-mêmes, vous ne le pouvez pas. Vous devez donc empêcher que cela se produise à l’avance.

4. Assurez-vous que l’utilisateur voit les résultats immédiatement

Tout ce que fait l’élève doit générer quelque chose de compréhensible, même minime. Si votre élève doit faire des choses étranges et incompréhensibles pendant deux pages avant même de voir un résultat, c’est beaucoup trop long. L’effet de chaque action doit être visible et évident dès que possible, et le lien avec l’action doit être clair. La conclusion de chaque section d’un didacticiel, ou du didacticiel dans son ensemble, doit être une réalisation significative.

5. Rendez votre didacticiel répétable

Votre didacticiel doit pouvoir être répété de manière fiable. Ce n’est pas chose facile : les utilisateurs le suivront depuis des systèmes d’exploitation, des niveaux d’expérience et des outils différents. De plus, les logiciels ou les ressources qu’ils utilisent sont susceptibles d’évoluer entre-temps. Le didacticiel doit fonctionner pour tous, à chaque fois. Les didacticiels nécessitent malheureusement des tests réguliers et détaillés pour garantir qu’ils fonctionnent toujours.

6. Concentrez-vous sur des étapes concrètes et non sur des concepts

Les didacticiels doivent être concrets, construits autour d’actions et de résultats spécifiques et particuliers.

La tentation d’introduire des abstractions est grande ; après tout, c’est de là que vient la puissance des logiciels. Mais tout apprentissage procède du particulier et du concret vers le général et l’abstrait, et demander à l’élève d’apprécier les niveaux d’abstraction avant même qu’il ait eu la chance de saisir le concret est une mauvaise méthode d’enseignement.

7. Ne fournissez que l’explication minimale nécessaire

N’expliquez rien que l’élève n’ait pas besoin de savoir pour terminer le didacticiel. Une discussion approfondie est importante, mais pas dans un didacticiel : c’est une gêne et une distraction. Seul le strict minimum est approprié. À la place, utilisez des liens vers des explications ailleurs dans la documentation.

8. Concentrez-vous uniquement sur les étapes que l’utilisateur doit suivre

Votre didacticiel doit être axé sur la tâche à accomplir. Peut-être que la fonctionnalité que vous introduisez possède de nombreuses autres options, ou peut-être qu’il existe différentes manières d’effectuer une certaine action. Cela n’a pas d’importance : pour l’instant, votre élève n’a pas besoin de connaître ces éléments pour progresser.

Guides pratiques

Les guides pratiques guident le lecteur à travers les étapes nécessaires pour résoudre un problème du monde réel.

Ce sont des recettes, des instructions pour atteindre un objectif spécifique - par exemple : comment créer un formulaire Web ; comment tracer un ensemble de données en trois dimensions ; comment activer l’authentification LDAP.

Ils sont entièrement axés sur un objectif.

Les guides pratiques sont différents des didacticiels et ne doivent pas être confondus avec eux :

• Un didacticiel est ce que vous décidez qu’un débutant doit savoir.
• Un guide pratique est une réponse à une question que seul un utilisateur ayant une certaine expérience pourrait formuler.

Dans un guide pratique, vous pouvez supposer que l’utilisateur possède certaines connaissances et une certaine compréhension du logiciel. Vous pouvez supposer que l’utilisateur sait déjà comment faire des choses de base et utiliser des outils. Contrairement aux didacticiels, les guides pratiques dans la documentation logicielle sont généralement assez bien rédigés et sont également assez faciles à écrire.

Analogie avec la cuisine

Pensez à une recette pour préparer quelque chose à manger.

Une recette a un but clair et défini. Elle répond à une question précise. Elle montre à quelqu’un - dont on peut supposer qu’il possède déjà des connaissances de base - comment réaliser quelque chose.

On ne peut pas s’attendre à ce que quelqu’un qui n’a jamais cuisiné suive une recette avec succès, donc une recette ne remplace pas un cours de cuisine. En même temps, quelqu’un qui lit une recette serait irrité de découvrir qu’elle essaie d’enseigner des bases qu’il connaît déjà, ou contient des explications non pertinentes sur les ingrédients.

Comment rédiger de bons guides

1. Suivez une série d’étapes

Les guides pratiques doivent contenir une liste d’étapes à suivre dans l’ordre (tout comme les didacticiels). Vous n’êtes pas obligé de commencer au tout début, mais simplement à un point de départ raisonnable. Les guides pratiques doivent être fiables, mais ils n’ont pas besoin d’avoir la répétabilité absolue d’un didacticiel.

2. Concentrez-vous sur les résultats

Les guides pratiques doivent se concentrer sur la réalisation d’un objectif pratique. Tout le reste n’est que distractions. Comme dans les didacticiels, les explications détaillées n’ont pas leur place ici.

3. Résolvez un problème

Un guide pratique doit répondre à une question ou à un problème spécifique : Comment puis-je… ? C’est l’une des raisons pour lesquelles les guides pratiques se distinguent des didacticiels : dans un guide pratique, on peut supposer que le lecteur sait ce qu’il doit réaliser, mais ne sait pas encore comment - alors que dans un didacticiel, c’est vous qui décidez des choses que le lecteur doit savoir.

4. N’expliquez pas les concepts

Un guide pratique ne doit pas donner d’explications. Ce n’est pas le lieu pour des discussions de ce genre ; elles ne feraient que gêner le déroulé. Si les explications sont importantes, créez un lien vers une autre article.

5. Permettre une certaine flexibilité

Un guide pratique doit permettre des façons légèrement différentes de faire la même chose. Il doit être suffisamment flexible pour que l’utilisateur puisse imaginer comment il s’appliquera à des exemples légèrement différents de celui que vous décrivez, ou comprendre comment l’adapter à un système ou une configuration légèrement différente de celle supposée. Ne soyez pas trop précis afin que le guide puisse être utilisé pour autre chose que l’objectif exact que vous avez en tête.

6. Laissez des choses de côté

La facilité d’utilisation est plus importante que l’exhaustivité. Les didacticiels doivent être des guides complets et de bout en bout, ce qui n’est pas le cas des guides pratiques. Ils peuvent commencer et se terminer là où cela vous semble approprié. Ils n’ont pas non plus besoin de mentionner tout ce qu’il y a à mentionner simplement parce que c’est lié au sujet. Un guide pratique trop chargé n’aide pas l’utilisateur à trouver rapidement la solution.

7. Le nom donne le sens

Le titre d’un document pratique doit indiquer à l’utilisateur exactement ce qu’il fait. « Comment créer une vue basée sur les classes » est un bon titre. « Créer une vue basée sur les classes » ou pire, « Des vues basées sur les classes » ne le sont pas.

Guides de référence

Les guides de référence sont des descriptions techniques des logiciels et de leur fonctionnement.

Les guides de référence n’ont qu’une seule fonction : décrire. Ils sont déterminés par le code et la fonction car en fin de compte c’est ce qu’ils décrivent : les éléments clés, les fonctions, les API, et ils doivent donc répertorier des éléments tels que les fonctions, les champs, les attributs et les méthodes, et expliquer comment les utiliser et ce à quoi ils servent, Le matériel de référence est axé sur l’information.

Les références techniques peuvent bien sûr contenir des exemples pour illustrer leur utilisation, mais elles ne doivent pas tenter d’expliquer les concepts de base ou comment réaliser des tâches courantes. Le matériel de référence doit être simple et précis.

Notez que la description comprend une explication de base sur la manière d’utiliser l’outil - comment instancier une classe particulière ou invoquer une certaine méthode, par exemple, ou les précautions à prendre lors du passage de quelque chose à une fonction. Cependant, cela fait simplement partie de sa fonction de référence technique et ne doit absolument pas être confondu avec un guide pratique - décrire l’utilisation correcte d’un logiciel (référence technique) n’est pas la même chose que montrer comment l’utiliser pour atteindre un certain objectif (documentation pratique).

Pour certains développeurs, les guides de référence sont le seul type de documentation qu’ils peuvent imaginer. Ils connaissent déjà leur logiciel, ils savent comment l’utiliser. Tout ce qu’ils peuvent imaginer, c’est que d’autres personnes pourraient avoir besoin d’informations techniques à son sujet.

Les documents de référence sont généralement bien rédigés. Ils peuvent même, dans une certaine mesure, être générés automatiquement, mais cela ne suffit jamais.

Analogie avec la cuisine

Considérez un article d’encyclopédie sur un ingrédient, par exemple le gingembre.

Lorsque vous recherchez du gingembre dans un ouvrage de référence, ce que vous voulez, ce sont des informations sur l’ingrédient - des informations décrivant sa provenance, son comportement, ses constituants chimiques, comment il peut être cuisiné.

Vous vous attendez à ce que, quel que soit l’ingrédient que vous recherchez, les informations soient présentées de manière similaire. Et vous vous attendez à être informé de faits de base, comme le fait que le gingembre fait partie de la famille qui comprend le curcuma et la cardamome.

C’est également ici que vous vous attendez à être alerté des problèmes potentiels, tels que : le gingembre est connu pour provoquer des brûlures d’estomac chez certaines personnes ou : le gingembre peut interférer avec les effets des anticoagulants, tels que la warfarine ou l’aspirine.

Comment rédiger de bons guides

1. Structurez la documentation autour du code

Donnez à la documentation de référence la même structure que la base de code, afin que l’utilisateur puisse parcourir à la fois le code et la documentation associée. Cela aidera également les responsables à voir où la documentation de référence est manquante ou doit être mise à jour.

2. Soyez cohérent

Dans les guides de référence, la structure, le ton et le format doivent tous être cohérents – aussi cohérents que ceux d’une encyclopédie ou d’un dictionnaire.

3. Ne faites rien d’autre que décrire

La seule fonction d’une référence technique est de décrire le document de la manière la plus claire et la plus complète possible. Tout autre élément (explication, discussion, instruction, spéculation, opinion) est non seulement une distraction, mais rendra également l’utilisation et la maintenance plus difficiles. Donnez des exemples pour illustrer la description lorsque cela est approprié.

Évitez la tentation d’utiliser des documents de référence pour expliquer comment réaliser des choses qui vont au-delà de la portée de base de l’utilisation du logiciel, et ne laissez pas les explications de concepts ou les discussions sur des sujets se développer. Au lieu de cela, créez des liens vers des guides pratiques, des explications et des didacticiels d’introduction, selon le cas.

4. Soyez précis

Ces descriptions doivent être précises et mises à jour. Toute divergence entre la machine et la description que vous en faites peut inévitablement induire l’utilisateur en erreur.

Explication

Les explications ou discussions clarifient et éclairent un sujet particulier. Elles élargissent la couverture documentaire d’un sujet. Elles sont orientées vers la compréhension.

Les explications peuvent tout aussi bien être décrites comme des discussions ; elles sont de nature discursive. Elles permettent à la documentation de se détendre et de prendre du recul par rapport au logiciel, d’avoir une vue plus large, de l’éclairer d’un niveau supérieur ou même de perspectives différentes. On pourrait imaginer un document de discussion lu à loisir, plutôt que sur le code.

Cette section de la documentation est rarement créée explicitement et, à la place, des extraits d’explications sont dispersés parmi d’autres sections. Parfois, la section existe, mais porte un nom tel que Contexte ou Autres notes ou Rubriques clés - ces noms ne sont pas toujours utiles.

Les discussions sont moins faciles à créer qu’il n’y paraît : les choses sont simples à expliquer lorsque vous avez un point de départ d’une question de quelqu’un, et le sont moins lorsque vous avez une page blanche et que vous devez écrire quelque chose à ce sujet.

Un sujet n’est pas défini par une tâche spécifique que vous souhaitez réaliser comme dans un guide pratique, ou par ce que vous souhaitez que l’utilisateur apprenne comme dans un didacticiel. Il n’est pas défini par un élément du logiciel, comme un matériel de référence. Il est défini par ce que vous pensez être un domaine raisonnable à essayer de couvrir en une seule fois, de sorte que la division des sujets de discussion peut parfois être un peu arbitraire.

Analogie avec la cuisine

Pensez à une œuvre qui traite de l’alimentation et de la cuisine dans le contexte de l’histoire, de la science et de la technologie. Il s’agit de cuisine et de la cuisine.

Il n’enseigne pas, ce n’est pas un recueil de recettes et il ne se contente pas de décrire.

Au contraire, il analyse les choses, les considère sous différents angles. Il peut expliquer pourquoi nous faisons les choses comme nous le faisons, ou même décrire de mauvaises façons de faire les choses, ou encore obscurcir des alternatives.

Cela approfondit nos connaissances et les enrichit, même si ce ne sont pas des connaissances que nous pouvons réellement appliquer dans un sens pratique - mais elles n’ont pas besoin de l’être pour être précieuses.

C’est quelque chose que nous pourrions lire à notre guise, loin de la cuisine elle-même, lorsque nous voulons réfléchir à la cuisine à un niveau plus élevé et mieux comprendre le sujet.

Comment rédiger une bonne explication

1. Fournissez un contexte

Les explications sont l’endroit où se trouvent l’arrière-plan et le contexte - par exemple, les formulaires Web et la manière dont ils sont gérés dans Django ou la recherche dans le CMS Django.

Ils peuvent également expliquer pourquoi les choses sont ainsi : décisions de conception, raisons historiques, contraintes techniques.

2. Discutez des alternatives et des opinions

L’explication peut prendre en compte des alternatives ou plusieurs approches différentes pour la même question. Par exemple, dans un article sur le déploiement de Django, il serait approprié d’envisager et d’évaluer différentes options de serveur Web.

Les discussions peuvent même prendre en compte et évaluer les opinions contraires - par exemple, si les modules de test doivent être dans un répertoire de packages ou non.

3. Ne donnez pas d’instructions ni de références

L’explication doit faire des choses que les autres parties de la documentation ne font pas. Elle n’a pas pour fonction d’indiquer à l’utilisateur comment faire quelque chose. Elle ne doit pas non plus fournir de description technique. Ces fonctions de la documentation sont déjà prises en charge dans d’autres sections.

À propos de la structure

Pourquoi ce n’est pas évident

Cette structure est claire et fonctionne, mais il y a une raison pour laquelle elle n’est pas si évidente : c’est la façon dont les caractéristiques de chaque quadrant de la documentation se chevauchent avec celles de ses voisins dans le schéma.

Chacun des quadrants est semblable à ses deux voisins :

• Les didacticiels et les guides pratiques visent tous deux à décrire les étapes pratiques
• Les guides pratiques et les références techniques sont tous deux ce dont nous avons besoin lorsque nous sommes au travail, en train de coder
• Les guides de référence et les explications concernent tous deux des connaissances théoriques
• Les didacticiels et les explications sont tous deux plus utiles lorsque nous étudions, plutôt que de travailler réellement

La tendance à l’effondrement

Compte tenu de ces chevauchements, il n’est pas surprenant que les différents types de documentation se mélangent eles uns aux autres. En fait il existe une attraction naturelle entre ces différents types de documentation à laquelle il est difficile de résister. Son effet est de faire s’effondrer la structure, et c’est pourquoi tant de documentations ressemblent à ceci :

Adoption du système

Bien qu’il soit rare de trouver des exemples clairs de son utilisation complète, une grande quantité de documentation reconnaît, de différentes manières, chacune de ces quatre fonctions.

Voici de bons exemples de ce système dans le cadre de projets de grande envergure (en anglais) :

• Le manuel du développeur Divio
• Documentation de Django
• Documentation du CMS Django

Parfois, la documentation est si minimale que tous les quadrants ne sont pas prêts à être représentés, comme dans le cas de Premiers pas avec Java et Spring-boot, qui comprend uniquement un didacticiel, des procédures et du matériel de référence.

Dans chaque cas cependant, aussi minime ou même incomplet soit-il, le système est respecté et la distinction claire entre les sections et leurs objectifs profitera immédiatement à l’auteur et à l’utilisateur, et aidera à guider l’expansion de la documentation à mesure qu’elle se développera dans le futur.

À propos de l’analyse et de son application

L’analyse de la documentation dans cet article est basée sur plusieurs années d’expérience dans la rédaction et la maintenance de la documentation et sur beaucoup de temps passé à réfléchir à la manière de l’améliorer.

Elle repose également sur des principes solides issus de diverses disciplines. Par exemple, sa conception des didacticiels repose sur une base pédagogique ; elle pose comme principe un tuteur et un élève, et considère l’utilisation de logiciels comme un métier dans lequel la compréhension abstraite de principes généraux découle d’étapes concrètes traitant de détails.

Le système est présenté régulièrement lors de conférences et d’ateliers interactifs. L’analyse a été appliquée à de nombreux projets, y compris à de grands ensembles de documentation interne, et a procuré à plusieurs reprises des avantages en termes de facilité d’utilisation et de maintenabilité, dans un très large éventail de domaines techniques.