# Exemple : un workflow de revue documentaire
> **Note: Exemple abouti**
>
> Ceci est un **exemple abouti à étudier**, pas un modèle. Il utilise le [modèle de demande de revue](https://docs.redaction-technique.org/fr/toolkit/documentation-review-request-template/) et la [check-list de revue technique](https://docs.redaction-technique.org/fr/toolkit/technical-review-checklist/) comme outils réels.
## Le scénario
Une nouvelle fonctionnalité sort. Le rédacteur a rédigé un nouvel article tâche pour la documenter, et il doit sortir avec la version.
## Le workflow
```mermaid
%%{init: {"flowchart": {"curve": "basis"}, "themeVariables": {"fontFamily": "IBM Plex Sans Variable, sans-serif"}}}%%
flowchart TD
accTitle: Workflow de revue documentaire en deux passes
accDescr: Progression structurée montrant la séparation entre passe technique et passe éditoriale avant publication.
A["1. Auto-relecture
(Check-list qualité auteur)"] --> B["2. Revue technique
(Ingénieur : Est-ce exact ?)"]
B --> C["3. Traitement des retours
(Résolution des blocages)"]
C --> D["4. Passe éditoriale
(Relecteur : Est-ce clair et cohérent ?)"]
D --> E["5. Contrôle de préparation
(Navigation, build et traduction)"]
E --> F["6. Publication avec la fonctionnalité"]
classDef step fill:#f1f5f9,stroke:#64748b,stroke-width:1.5px,color:#0f172a,font-weight:500
classDef pass fill:#e2e8f0,stroke:#3b82f6,stroke-width:1.5px,color:#1e293b,font-weight:600
class A,C,E step
class B,D,F pass
linkStyle default stroke:#64748b,stroke-width:1.5px
```
1. **Auto-relecture d'abord.** Le rédacteur applique la [check-list de qualité documentaire](https://docs.redaction-technique.org/fr/toolkit/documentation-quality-checklist/) à son propre brouillon avant de demander à quiconque de le regarder — corriger les problèmes évidents ici coûte moins cher qu'un relecteur qui les détecte.
2. **Revue technique.** Le rédacteur envoie une [demande de revue](https://docs.redaction-technique.org/fr/toolkit/documentation-review-request-template/) à l'ingénieur qui a développé la fonctionnalité, cadrée explicitement : *« Confirmez que les étapes correspondent toujours à l'interface livrée — je ne demande pas d'avis sur la formulation. »* L'ingénieur suit la [check-list de revue technique](https://docs.redaction-technique.org/fr/toolkit/technical-review-checklist/) et ne laisse des commentaires bloquants que sur de vraies inexactitudes.
3. **L'auteur traite les retours.** Chaque commentaire bloquant reçoit une correction ou une réponse expliquant pourquoi il ne s'applique pas. Les suggestions non bloquantes sont triées — certaines retenues, d'autres explicitement refusées avec justification.
4. **Passe éditoriale.** Un second relecteur — ou le même rédacteur, après avoir pris du recul sur le brouillon — vérifie la structure, le ton et la cohérence avec le reste du site. Cette passe ne remet explicitement *pas* en cause l'exactitude technique ; c'était le rôle de l'étape 2.
5. **Contrôle de préparation à la mise en production.** Avant que la fonctionnalité ne sorte, la [check-list de préparation à la mise en production](https://docs.redaction-technique.org/fr/toolkit/release-readiness-checklist/) confirme que le nouvel article est relié depuis la navigation, se génère proprement et, le cas échéant, dispose d'un plan de traduction.
6. **Publier en même temps que la fonctionnalité**, pas après — voir [intégrer la documentation aux processus de développement](https://docs.redaction-technique.org/fr/tech-writing-process/integrating-documentation-into-development/).
## Pourquoi la revue est scindée en deux passes
La revue technique et la revue éditoriale posent des questions fondamentalement différentes — « est-ce vrai ? » contre « est-ce clair ? » — et demander à un seul relecteur de porter les deux casquettes à la fois tend à produire une revue qui ne fait ni l'un ni l'autre correctement. Scinder les passes évite aussi que les retours ne se télescopent : une correction technique d'un ingénieur ne se perd pas parmi une douzaine de remarques de formulation, et inversement.
---
Source: https://docs.redaction-technique.org/fr/toolkit/example-review-workflow/