# Modèle : article référence

**Type d'information :** [Référence](https://docs.redaction-technique.org/fr/toolkit/information-types/)

> **Astuce: Modèle**
>
> Ceci est un **point de départ à copier et adapter**, pas un exemple abouti. Pour une version remplie, voir le [modèle de documentation d'API](https://docs.redaction-technique.org/fr/toolkit/api-documentation-template/), un cas particulier de ce patron. Pour comprendre comment le contenu de référence s'intègre dans l'architecture documentaire, lisez [Typologie de l'information](https://docs.redaction-technique.org/fr/toolkit/information-types/).

Utilisez cette structure quand l'intention première du lecteur est la **consultation** — il sait déjà ce qu'il cherche à accomplir et a besoin de la syntaxe exacte, des paramètres, des commandes ou des spécifications. Contrairement à un article concept ou tâche, personne ne lit un article référence de bout en bout ; on le parcourt pour trouver un seul détail.

Gardez le type d'information principal clair : un article référence intègre couramment des exemples de syntaxe concrets pour illustrer des options, mais les tutoriels pas-à-pas relèvent d'un [article tâche](https://docs.redaction-technique.org/fr/toolkit/task-article-template/) et les explications d'architecture d'un [article concept](https://docs.redaction-technique.org/fr/toolkit/concept-article-template/).

La structure ci-dessous est un **modèle de rédaction pratique** conçu pour un flux Markdown / Astro léger, appliquant le principe de typologie de l'information sans schémas DITA XML ni contraintes DTD :

```markdown
## Aperçu

<Une ou deux phrases de contexte — de quoi permettre à quelqu'un qui
arrive ici depuis une recherche de savoir qu'il est au bon endroit.>

## Syntaxe

<La syntaxe exacte et littérale. Un bloc de code, pas de la prose.>

## Paramètres

| Paramètre | Type | Obligatoire | Description |
| --- | --- | --- | --- |
| `<nom>` | `<type>` | Oui/Non | <ce qu'il fait> |

## Exemples

<Au moins un exemple complet et exécutable — pas un fragment.>

## Limitations

<Contraintes connues, combinaisons non prises en charge ou cas
limites. Omettez si aucune n'existe ; n'inventez pas de mises en
garde pour remplir la section.>

## Références connexes

- [<Référence connexe 1>](<lien>)
- [<Référence connexe 2>](<lien>)
```

## Quand omettre une section

- **Limitations** : uniquement si de vraies limitations existent.
- **Paramètres** : si l'élément documenté ne prend aucun paramètre, remplacez le tableau par une note d'une ligne le précisant — ne supprimez pas le titre en silence, son absence doit être explicite, pas implicite.
- Ne jamais omettre **Syntaxe** ni **Exemples** — un article référence sans forme littérale et copiable ne remplit pas son rôle.

---

Source: https://docs.redaction-technique.org/fr/toolkit/reference-article-template/
