# Modèle : article concept

**Type d'information :** [Concept](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 illustration complète et commentée de ce modèle, consultez [Exemple : une page Markdown bien structurée](https://docs.redaction-technique.org/fr/toolkit/example-markdown-page/). Pour comprendre comment le concept s'intègre dans l'architecture documentaire, lisez [Typologie de l'information](https://docs.redaction-technique.org/fr/toolkit/information-types/).

## Qu'est-ce qu'un Concept ?

Un concept est un **type d'information**, et non un simple style rédactionnel ou une introduction décorative. Son rôle est de répondre à une question centrale : **« Qu'est-ce que c'est ? »**

Un article de type concept :

- **Construit la compréhension :** il fournit les définitions, le contexte et les modèles mentaux nécessaires au lecteur avant qu'il ne puisse manipuler efficacement un système.
- **Explicite les relations :** il explique comment les composants, idées ou couches architecturales s'articulent entre eux.
- **Ne donne pas de directives :** il ne comporte généralement pas d'instructions séquentielles pas-à-pas (qui relèvent d'un [article tâche](https://docs.redaction-technique.org/fr/toolkit/task-article-template/)).
- **Prépare à l'action :** les lecteurs se tournent vers les concepts lors de l'intégration (*onboarding*), de l'évaluation d'une approche ou du diagnostic d'un système avant de passer aux tâches pratiques.

## Maîtriser les frontières de contenu

Gardez le type d'information principal clair. Un article conceptuel peut intégrer un court extrait de code, une bribe de configuration ou un diagramme pour ancrer un principe abstrait. En revanche, les éléments d'appui ne doivent pas submerger l'intention première :

- **Une illustration concise est bienvenue :** un extrait bref montrant le concept en action renforce la compréhension.
- **Les procédures substantielles relèvent d'une Tâche :** si vous développez des instructions séquentielles pas-à-pas (*« Comment configurer X ? »*), déplacez-les dans un [article tâche](https://docs.redaction-technique.org/fr/toolkit/task-article-template/) et créez un lien.
- **Les paramètres exhaustifs relèvent d'une Référence :** si vous énumérez un catalogue complet d'options ou de variables (*« Quels sont les paramètres de X ? »*), déplacez-les dans un [article référence](https://docs.redaction-technique.org/fr/toolkit/reference-article-template/) et créez un lien.

Maintenir l'attention sur l'intention première du lecteur garantit que celui venu assimiler une règle architecturale n'est pas distrait par des tables interminables, tandis que l'utilisateur cherchant à réaliser une procédure urgente n'a pas à lire de longs paragraphes de théorie.

---

## Structure recommandée

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 validation DTD. Elle ordonne logiquement le contenu, de la définition immédiate à l'illustration concrète :

1. **Définition :** définition en langage clair répondant à « Qu'est-ce que c'est ? » en une ou deux phrases.
2. **Contexte (Pourquoi c'est important) :** les conséquences pratiques — ce qui dysfonctionne, coûte plus cher ou échoue sans la maîtrise de ce concept.
3. **Fonctionnement (Principes clés) :** les idées directrices ou mécanismes constitutifs du concept.
4. **Caractéristiques clés (Compromis) :** limites, contraintes ou arbitrages délibérés lorsqu'un choix réel existe.
5. **Exemples :** au moins un exemple concret ancré dans la pratique.
6. **Concepts connexes :** liens contextuels vers les concepts parents, voisins ou les tâches associées.

```markdown
---
title: "<Nom du concept>"
description: "<Une phrase : ce que le lecteur comprendra après lecture>"
contentType: concept
---

## Définition

<Une ou deux phrases définissant le concept en langage simple. Un
lecteur qui ne lit que ce paragraphe doit repartir avec une
compréhension correcte, même si incomplète.>

## Pourquoi c'est important

<La conséquence de comprendre — ou de ne pas comprendre — ce concept.
Qu'est-ce qui casse, coûte plus cher ou devient confus sans lui ?>

## Principes clés

<Les deux à quatre idées qui composent le concept. Une liste à puces
ou un tableau court fonctionnent bien ici.>

## Exemples

<Au moins un exemple concret. Les concepts abstraits sans exemple
sont la cause la plus fréquente de confusion du lecteur.>

## Compromis

<Facultatif. À inclure uniquement si le concept implique un vrai
choix — quand choisirait-on délibérément de ne PAS appliquer ce
concept ?>

## Concepts connexes

- [<Concept connexe 1>](<lien>)
- [<Concept connexe 2>](<lien>)
- [<Tâche associée>](<lien>)
```

---

## Quand omettre une section

- **Compromis :** supprimez cette section s'il n'existe aucun véritable dilemme, plutôt que d'inventer un compromis artificiel.
- **Pourquoi c'est important :** si le concept est simple et que sa valeur découle immédiatement de la définition, fusionnez les deux.
- **Ne jamais omettre Définition ni Exemples :** un article concept sans définition claire laisse le lecteur dans le flou ; un article concept sans exemple concret reste abstrait et désincarné.

---

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