Documentation technique.

Une machine, un logiciel, une opération à expliquer : c’est assez pour commencer. Nous cherchons les informations auprès des sources disponibles et des personnes qui connaissent le produit. Le document se construit ensuite autour de ce que son lecteur doit comprendre et faire.

Nous reprenons aussi des fonds documentaires qui ont déjà une histoire : fichiers Word, projets FrameMaker ou MadCap Flare, XML, HTML, images et traductions. Avant de convertir quoi que ce soit, il faut retrouver la version qui fait référence. Sans cela, on risque surtout de remettre en forme une erreur ancienne.

Quand conserver Word ? Pour des documents relativement autonomes, avec peu de variantes, et des contributeurs qui doivent pouvoir les modifier facilement, Word peut convenir. Des modèles, des styles, des renvois et des règles de mise à jour peuvent déjà améliorer le travail.

Quand la même instruction circule dans plusieurs manuels, chaque correction devient une série de reports. Les variantes et les traductions multiplient ce travail ; la publication web ajoute encore une sortie à tenir. C’est cette organisation qu’il faut examiner. La longueur du manuel ne dit pas, à elle seule, combien de corrections doivent être reportées.

Un échantillon sert à vérifier les tableaux, les illustrations, les liens et la mise en page avant une migration. Conserver un outil bien réglé peut être préférable à une conversion qui ajoute du travail.

Dans un fonds constitué au fil des années, un composant finit parfois par porter trois noms. Nous comparons les documents, relevons les contradictions et convenons d’un vocabulaire commun avec les personnes qui connaissent le produit. Le plan, les unités et la façon de décrire une opération suivent la même logique.

La réécriture vient ensuite. Nous raccourcissons ce qui gêne la lecture, levons les ambiguïtés et signalons les informations qui manquent. Un passage périmé est retiré après validation. Le lecteur doit pouvoir reconnaître le même composant dans le manuel, sur l’écran de la machine et pendant une formation.

Les modifications de fond restent distinguées des corrections de présentation. Un texte plus fluide doit conserver les faits, les valeurs et les conditions d’utilisation du produit.

Une procédure décrit une opération ; une référence permet de retrouver une valeur ; un avertissement signale un risque. Nous donnons à ces contenus une structure que les outils peuvent reconnaître, indépendamment de leur présentation. Mettre une phrase en gras ne suffit pas à en faire une consigne de sécurité.

Prenons une opération d’entretien commune à plusieurs modèles. Elle peut être écrite et entretenue à un seul endroit, puis reprise dans les manuels concernés. Les réglages propres à chaque modèle restent séparés. Lorsqu’on corrige l’opération, on sait ainsi quelles publications doivent être régénérées.

Cette méthode peut commencer modestement, avec des styles cohérents et un découpage clair. Elle n’impose pas d’emblée une migration complète vers XML.

FrameMaker et Flare sont des outils. DITA et DocBook sont des structures XML. HTML et PDF répondent à des usages de publication. Ces choix se croisent, mais ils ne sont pas interchangeables. Nous les examinons avec vos langues, vos variantes, vos licences et la nécessité de reprendre les sources plus tard.

Les langues, les variantes, les validations, les compétences disponibles et les sorties attendues guident le choix. Une chaîne existante sous FrameMaker ou Flare peut être conservée et améliorée ; changer d’outil n’est pas un objectif en soi.

Une version source est identifiée, avec un vocabulaire de référence et les noms qui doivent rester inchangés. Les contenus communs, les variantes et les passages modifiés sont repérés pour préparer le travail linguistique.

Les traductions déjà faites représentent du travail qu’il serait absurde de recommencer sans raison. Nous cherchons ce qui correspond encore à la source, puis les passages qui ont changé. Les outils de traduction et l’IA peuvent intervenir dans cette chaîne ; les termes, les valeurs et les consignes restent à relire sur le produit concerné.

Les langues, les personnes chargées de la validation et le niveau de revue attendu sont définis avant de commencer. Les versions livrées restent rattachées à leur source.

La publication peut être organisée pour fournir un manuel complet, une notice ciblée, une aide en ligne ou des instructions de maintenance. Les contenus communs sont séparés des éléments propres à un produit, une option ou un public.

Trois variantes d’un équipement peuvent partager l’entretien sans partager les réglages. La difficulté consiste à garder cette distinction jusqu’à la sortie : la bonne procédure commune, avec les bonnes valeurs pour le bon modèle. Chaque manuel est relu comme le document que recevra son utilisateur.

Les gabarits, les liens, les images, les tableaux et les sauts de page sont contrôlés dans les formats livrés. Une source commune facilite la cohérence ; elle ne dispense pas de relire le résultat publié.

Voir un manuel réalisé pour le web et l’impression

L’automatisation documentaire porte sur une chaîne de travail : récupérer une information, mettre à jour son contenu de référence, assembler les variantes et produire les sorties. La génération de texte n’en est qu’une possibilité. Les interfaces disponibles et l’état des sources déterminent ce qu’on peut réellement relier.

• Préparer les sources : repérer des styles incohérents, des champs manquants, des liens cassés ou des références à vérifier.
• Assembler les variantes : sélectionner les procédures, les options et les valeurs propres à un modèle, depuis une base commune.
• Préparer les traductions : repérer les passages modifiés et organiser les lots à traduire, sans retraiter systématiquement tout le manuel.
• Produire les sorties : lancer les générations web et PDF, appliquer les gabarits et déposer les fichiers aux emplacements convenus.
• Tracer les contrôles : produire un rapport des écarts et des validations encore nécessaires avant publication.

Si une opération d’entretien change pour une gamme, nous pouvons mettre à jour son contenu commun, repérer les variantes et les traductions concernées, puis régénérer les publications. La relecture se concentre alors sur les changements, les valeurs et les consignes, avec un contrôle du rendu avant diffusion.

Nous avons développé HTML Editor pour pouvoir piloter cette chaîne, y compris par IA. Une installation existante peut aussi être automatisée : Flare dispose, par exemple, d’une génération en ligne de commande. Nous commençons sur un lot représentatif pour savoir quelles opérations l’outil peut prendre en charge et ce que la mise en place coûtera.

La proposition précise les contenus concernés, les langues, les formats de livraison, les sources remises et les validations attendues. Elle distingue la remise en ordre initiale de la production des prochaines versions.

Un fonds volumineux bien organisé peut demander moins de reprise qu’un petit ensemble dont les sources, les images et les versions se contredisent. Nous chiffrons le travail sur l’état réel du fonds, les variantes et les langues à livrer. Un premier lot permet d’en discuter sur pièces.

Pour commencer, un ou deux documents représentatifs et la liste des publications souhaitées suffisent à engager l’analyse. Les fichiers d’origine et les images disponibles aideront à éviter une reconstruction inutile.