À propos d’Olivier Carrère

Rédacteur technique senior spécialisé en documentation développeur, docs-as-code et rédaction structurée DITA : parcours, démarche et fabrication de ce site.

Mis à jour en septembre 2026, 4 min de lecture

Voir en Markdown

Je rédige la documentation de produits logiciels et des équipes d’ingénierie qui les construisent. Ce site est ma pratique de la rédaction technique : un guide pratique pour concevoir, rédiger, maintenir et publier de la documentation technique, fondé sur mes méthodes, mes projets et mon expérience. Je le maintiens comme un projet Docs-as-codeTraiter la documentation comme du code source : formats texte, gestion de versions, revue de code et CI/CD, plutôt qu'un processus de publication séparé.Voir dans le glossaire →. Mon profil professionnel ↗ (en anglais) résume mon expertise et mes travaux choisis, et publie mes articles.

À propos de moi

Profil

Documentation de produits logiciels. J’ai rédigé la documentation de NuFirewall en DITA XMLUne architecture de rédaction structurée et modulaire, construite autour de la typologie concept/tâche/référence et de la réutilisation de contenu via conrefs et ditamaps.Voir dans le glossaire → ; la presse l’a citée comme un point fort du produit.
Rédaction structuréeRédiger un contenu dont le balisage encode le sens (ceci est un avertissement, ceci est une étape) plutôt que la seule apparence visuelle — permettant un traitement automatisé, une réutilisation et des contrôles de cohérence que les formats non structurés ne permettent pas.Voir dans le glossaire →. J’ai utilisé DITA XML au quotidien sur des projets multilingues : typage des TopicLa plus petite unité d'information autonome et titrée en DITA XML, typée comme concept, tâche ou référence et assemblée en documents via des ditamaps.Voir dans le glossaire →, Réutilisation du contenu (réutilisation de contenu)Rédiger une information une seule fois et l'employer à plusieurs endroits ou dans plusieurs livrables plutôt que de la recopier : une correction faite une fois s'applique partout. Les conrefs, le texte conditionnel et le single-sourcing sont autant de moyens d'y parvenir.Voir dans le glossaire → par ConrefUn mécanisme DITA XML de réutilisation d'un bloc de contenu par référence : le contenu d'un nœud cible est remplacé par le contenu d'un nœud source à la compilation.Voir dans le glossaire →, Texte conditionnelContenu marqué comme ne s'appliquant qu'à un public, une version de produit ou un livrable donnés, afin qu'une même source puisse être filtrée à la compilation pour produire des documents différents. DITA XML le met en œuvre avec les fichiers ditaval ; des moteurs de modèles comme Jinja font de même pour les formats texte.Voir dans le glossaire → et sources prêtes pour la traduction.
Docs-as-code. Ce site est rédigé, versionné et publié à partir de Git depuis 2014, à travers plusieurs formats sources et chaînes de publication.
Traduction. Diplômé d’une école de traduction, j’ai plusieurs années d’expérience en traduction technique, ce qui oriente la façon dont je structure le contenu pour la localisation.

Ma démarche documentaire au sein des équipes d’ingénierie

La documentation sort avec le produit, suit le même cycle de vie et passe par le même contrôle qualité : voir intégrer la documentation aux processus de développement.
Je teste le produit en conditions réelles d’utilisation avant de le documenter, plutôt que de compiler ce que l’on me dit : voir tester les produits pour les documenter.
Je collecte l’information auprès des ingénieurs et des autres experts métier, et je sollicite des revues techniques ciblées : voir collecte de l’information et la check-list de revue technique.
Les modifications de la documentation passent par des branches et une revue par Pull requestDemande d'intégration des modifications d'une branche dans la ligne principale, présentée sous forme de différences à relire : les relecteurs commentent, les contrôles automatisés s'exécutent et l'approbation est tracée avant la publication. GitLab parle de merge request.Voir dans le glossaire →, en séparant revue technique et revue éditoriale : voir le workflow de revue documentaire.

Libérez vos informations de leurs silos

Des solutions souples et fiables libèrent vos informations des silos d’information cloisonnés où elles sont emprisonnées et sous-exploitées. Oubliez MS Word ou FrameMaker pour passer de la maintenance de la documentation à la gestion du cycle de vie des projets documentaires modulaires !

Intégrer la documentation aux processus de développement détaille ce que cela suppose : une documentation qui sort en même temps que le produit, suit les mêmes cycles de vie et le même contrôle qualité, sans vendor lock-in, avec des chaînes de publication libres et gratuites et une mise en page totalement automatisée.

Domaines d’expertise

La page Expertise relie chaque domaine aux articles qui en témoignent :

Disponibilité

Mon contrat actuel de rédacteur technique senior chez Unity se termine le 1er octobre 2026. Je suis ouvert à de nouvelles opportunités à partir d’octobre 2026.

Me contacter

LinkedIn : linkedin.com/in/carrereolivier. Le meilleur moyen de me contacter au sujet d’un poste ou d’un projet de rédaction technique.
Code source de ce site : github.com/olivier-carrere/redaction-technique.org
Profil professionnel, travaux choisis et articles : redaction-technique.org (en anglais)

Comment ce site est construit

Cette partie est le colophon du site. L’historique du site retrace le passage de ce corpus documentaire de WordPress à Sphinx puis à Astro, et le devenir de chaque page en chemin.

Ce site traite des processus et des formats de rédaction technique : son historique et ses branches Git sont donc aussi pertinents que son contenu.

Il traite des formats, des outils et des tâches suivants : reStructuredTextLangage de balisage en texte brut issu de l'écosystème Python, plus riche que Markdown (directives, rôles, renvois) et format source natif du générateur de documentation Sphinx.Voir dans le glossaire →, DITA XML, scripts Bash, awk, sed, expressions rationnelles, Python, Gestion de versionsEnregistrement de chaque modification d'un ensemble de fichiers, qui permet de restaurer n'importe quel état antérieur, de comparer les changements et de travailler à plusieurs en parallèle. Git est le logiciel de gestion de versions le plus répandu ; en docs-as-code, la documentation est placée sous gestion de versions à côté du code du produit.Voir dans le glossaire →, Git, compilation, Makefile, Ant, XSLT (XSL Transformations)Langage de transformation de documents XML en d'autres documents XML, HTML ou texte. Les chaînes de publication XML comme le DITA Open Toolkit utilisent des feuilles de style XSLT pour produire du HTML, ou du XSL-FO pour la sortie PDF.Voir dans le glossaire →, mise en page, HTML, CSS, PDF, LaTeX, XSL-FOUn langage de feuilles de style pour transformer et mettre en page du contenu XML pour une sortie impression/PDF, couramment associé aux pipelines de publication DITA XML.Voir dans le glossaire →.

Aujourd’hui, le site est rédigé en MDX et compilé avec Astro et Starlight. GitHub Actions le compile à chaque push et pull request, une suite de tests vérifie son contenu et son API, et il est publié en français et en anglais. Les mêmes sources alimentent aussi une API lisible par les machines et un assistant documentaire fondé sur ce contenu.

La pile technique sur laquelle ce site est construit aujourd’hui

Les sources de ce site sont gérées sous Git

Ce site a été initialement développé sous WordPress. L’impossibilité d’effectuer sous ce CMS des modifications transverses ou d’avoir un suivi précis du cycle de vie du contenu a entraîné une migration vers le format de balisage léger reStructuredText.

Plateformes de gestion du cycle de vie de la documentation

Toutes les versions de ce site sont gérées sous le logiciel de gestion de versions décentralisé Git. Les modifications de contenu, de structure ou de mise en page peuvent désormais être :

regroupées par lots cohérents,
liées à un ticket de logiciel de suivi de problèmes tel que Bugzilla ou Jira,
validées par des pairs,
partagées entre différentes versions du projet de documentation,
annulées en une seule opération, etc.

Formats sources

La version 1.1 de ce site était disponible en trois formats sources, de niveaux de fonctionnalités et de complexité différents.

Niveau de fonctionnalités et de complexité des formats texte

reStructuredText: reStructuredText est un langage de balisage léger de type Wiki ou MarkdownLangage de balisage léger en texte brut, où la mise en forme s'exprime par une ponctuation simple, par exemple un # en début de ligne pour un titre. Facile à rédiger et à relire sous gestion de versions, il n'impose aucun schéma : les équipes docs-as-code compensent par des modèles et des contrôles automatisés. Ce manuel est rédigé en MDX, une variante de Markdown.Voir dans le glossaire → qui, combiné au générateur de documentation Sphinx, offre un bon niveau de fonctionnalités.

DITA XML: DITA XML est une architecture documentaire XML sémantique et modulaire complexe qui offre des gains de productivité importants grâce à une forte réutilisation du contenu.

DocBook: DocBookLangage de balisage XML sémantique destiné à la documentation technique, organisé en livres, chapitres et sections plutôt qu'en topics typés. Antérieur à DITA XML, il sert de point de comparaison habituel lors du choix d'un format structuré.Voir dans le glossaire → est un langage de balisage XML sémantique qui offre un rapport fonctionnalités/complexité aujourd’hui peu intéressant.

Formats cibles

La version Sphinx était compilée aux formats :

PDF,
EPUB,
HTML.

Ces différentes versions étaient générées à partir des mêmes sources exactement. Elles présentaient cependant de légères variations, mises en œuvre par un mécanisme de texte conditionnel. Par exemple, le terme suivant varie selon le Format cibleLe format réellement consommé par le lecteur — PDF, HTML, aide compilée — généré à partir du format source.Voir dans le glossaire → :

Format cible	Terme
PDF	document
EPUB	livre électronique
HTML	site