À la une

L’IA sait écrire de la documentation. Que doit faire le rédacteur technique maintenant ?

En trois ans, l’IA générative a transformé le premier brouillon en opération bon marché. La question essentielle est désormais de savoir qui assume les faits, la structure, la revue, les mises à jour et la qualité.

Lire l’article →4 min de lecture

L’IA sait écrire de la documentation. Que doit faire le rédacteur technique maintenant ?

Docs-as-Code sans fanatisme

Docs-as-Code ne signifie pas imposer un IDE à tous les rédacteurs. Le bon modèle combine sources versionnées, édition dans le navigateur, previews, contrôles automatisés utiles, revue humaine et publication prévisible.

Bien documenter une API REST

Une bonne documentation d’API associe contrat lisible par machine, explications humaines, exemples exécutables et comportement d’erreur explicite. La documentation REST s’adresse aux machines et aux humains.

Que reste-t-il du rédacteur technique de 2006 ?

Les outils ont radicalement changé, mais le cœur du métier reste reconnaissable : public, preuves, structure, terminologie et responsabilité. En 2006, desktop publishing, formats bureautiques et systèmes d’aide maintenus manuellement étaient beaucoup plus courants.

Outils

Tous les articles →

Choisir un générateur de documentation sans choisir une religion

Sphinx, MkDocs, Astro et les autres générateurs optimisent des modèles de contenu et des équipes différents. Choisissez selon le workflow, l’extensibilité, la localisation et le coût de maintenance, pas selon une jolie démo. Une démonstration superbe peut être mauvaise pour votre documentation.

Choisir la recherche documentaire : commencer par les échecs

Une approche pratique et vérifiable de « Choisir la recherche documentaire : commencer par les échecs », conçue pour une documentation claire et maintenable. Comment traiter « Choisir la recherche documentaire : commencer par les échecs » avec une approche pratique, vérifiable et maintenable de la documentation technique.

Diagrammes as code : quand ils aident et quand ils n’aident pas

Une approche pratique et vérifiable de « Diagrammes as code : quand ils aident et quand ils n’aident pas », conçue pour une documentation claire et maintenable. Comment traiter « Diagrammes as code : quand ils aident et quand ils n’aident pas » avec une approche pratique, vérifiable et maintenable de la documentation technique.

Documentation dans la CI/CD

Traitez la documentation comme un artefact de build : validez structure, liens, exemples et règles avant publication. La CI ne peut pas juger l’utilité d’une explication, mais elle peut bloquer des défauts prévisibles avant de consommer du temps humain.