Modèle : article tâche

Un modèle Markdown prêt à copier pour rédiger un article tâche/didacticiel, selon la structure Objectif / Prérequis / Étapes / Résultat attendu / Dépannage.

Mis à jour en septembre 2026, 1 min de lecture

Voir en Markdown

Utilisez cette structure quand l’intention première du lecteur est de faire quelque chose avec un résultat concret et vérifiable. Ses étapes et son tableau de dépannage appliquent deux des principes cités sous le minimalisme mis à l’épreuve et formulé en principes dans l’historique du site : une approche orientée vers l’action, et l’aide à reconnaître les erreurs et à s’en remettre.

Gardez le Typage de l'informationLa discipline consistant à classer le contenu selon son objectif communicatif (concept, tâche, référence) plutôt que de rédiger une prose indifférenciée.Voir dans le glossaire → principal clair : un article tâche peut intégrer une ou deux phrases de rappel conceptuel dans son objectif ou ses prérequis pour expliciter l’intérêt d’une étape, mais les développements architecturaux substantiels doivent être placés dans un article concept, et les listes exhaustives de paramètres dans un article référence.

La structure ci-dessous est un modèle de rédaction pratique conçu pour un flux 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 → / Astro léger, appliquant le principe de typologie de l’information sans schémas 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 → ni contraintes DTD (Document Type Definition)Le plus ancien langage de schéma XML : il déclare les éléments et les attributs qu'un document peut contenir, et dans quel ordre. DITA XML est distribué avec des DTD aussi bien qu'avec des schémas XSD.Voir dans le glossaire → :

---
title: "<Titre à l'infinitif ou à l'impératif, ex. 'Configurer X' ou 'Migrer Y vers Z'>"
description: "<Une phrase : ce que le lecteur accomplit>"
contentType: task
---

## Objectif

<Une phrase : ce que le lecteur aura en place/accompli à la fin.>

## Prérequis

- <Accès, outil ou connaissance préalable requis>
- <Accès, outil ou connaissance préalable requis>

<Omettez entièrement cette section s'il n'y en a vraiment aucun —
ne la remplissez pas avec « un ordinateur » ou d'autres
non-prérequis.>

## Temps estimé

<À inclure uniquement si vous pouvez l'appuyer sur un chiffre réel —
un nombre de mots divisé par une vitesse de lecture, ou un
chronométrage réel. Ne devinez jamais.>

## Étapes

1. <Action. Limitez chaque étape à une seule action que le lecteur
   peut accomplir avant de passer à la suivante.>
2. <Action.>
3. <Action.>

## Résultat attendu

<Ce que le lecteur doit voir si les étapes ont fonctionné. Concret
et vérifiable — une capture d'écran, une sortie de commande, une URL
qui répond désormais.>

## Dépannage

| Symptôme | Cause probable | Solution |
| --- | --- | --- |
| <Ce qui ne va pas> | <Pourquoi> | <Que faire> |

<Omettez si vous n'avez pas de vrais cas d'échec à documenter — un
tableau de dépannage inventé est pire que son absence.>

## Ressources connexes

- [<Article connexe 1>](<lien>)
- [<Article connexe 2>](<lien>)

Quand omettre une section

Temps estimé : uniquement si vous avez une vraie base pour ce chiffre (voir ci-dessus).
Dépannage : documentez uniquement les cas d’échec réellement observés ou raisonnés concrètement - ce tableau se dégrade vite s’il est rempli de suppositions.
Ne jamais omettre Objectif, Étapes ou Résultat attendu - un article tâche sans résultat vérifiable n’en est pas un.