# Modèle de document de conception technique

Six documents liés qui mènent un système des exigences au déploiement : le contexte, l’architecture, les données et les interfaces, comment il tourne et comment il tombe, et les options écartées. Téléchargez-les en fichiers Markdown : ils s’ouvrent dans n’importe quel éditeur, vivent à côté du code dans un dépôt, dessinent leurs diagrammes sur GitHub et dans Obsidian, et s’importent dans Nodary sous forme de carte.

Gratuit, sans compte, sans e-mail. Utilisez-le, modifiez-le, partagez-le.

[Télécharger le modèle (.zip)](https://nodary.ai/downloads/modele-document-de-conception-technique.zip)

## Lisez chaque page avant de télécharger

La vue d’ensemble tient sur un écran et renvoie à cinq parties : un relecteur lit le résumé, puis va droit à la partie qui le concerne. Les lignes en italique disent quoi écrire ; les exemples suivent une même fonctionnalité d’exemple, des liens de partage qui expirent.

- Document de conception technique: La page que tout le monde lit d’abord : le résumé, les objectifs et non-objectifs, et un lien vers chaque partie.
- Contexte et exigences: L’existant, les exigences auxquelles la conception doit répondre, et les contraintes autour.
- Architecture: Les composants, comment ils se parlent, le parcours d’une requête, et les décisions clés.
- Données et interfaces: Le modèle de données, les API et les événements, et comment les données existantes passent à la nouvelle forme.
- Exploitation: Comment c’est déployé et surveillé, comment cela reste sûr, et ce qui se passe quand quelque chose tombe.
- Alternatives et risques: Les options écartées et pourquoi, les risques, le plan de déploiement et les questions ouvertes.

### Document de conception technique

_Mode d’emploi : les lignes en italique sont des consignes. Remplacez-les par vos propres mots, puis supprimez-les. Les valeurs entre crochets sont à remplir. Gardez cette page sur un écran : un relecteur doit y comprendre ce qu’il approuve._

#### En bref

| Champ | Cette conception |
| --- | --- |
| Système ou fonctionnalité | [Nom] |
| Auteur | [nom] |
| Relecteurs | [noms] |
| Statut | [brouillon, en relecture, approuvé, réalisé] |
| Exigences | [lien vers le PRD] |
| Version visée | [date ou version] |

#### Résumé

_Trois phrases : ce que vous allez construire, pourquoi, et la décision qu’un relecteur doit regarder en premier._

_Exemple (une fonctionnalité d’exemple) : Les liens de partage reçoivent une date de fin facultative. Chaque requête vérifie la date : un lien cesse de marcher à l’instant où il prend fin. Une tâche planifiée révoque les liens expirés chaque minute ; elle ne fait que nettoyer, et un retard ne change rien pour qui ouvre le lien._

[Votre résumé]

#### Objectifs et non-objectifs

- Objectif : [...]
- Objectif : [...]
- Non-objectif : [...]
- Non-objectif : [...]

#### Le reste de la conception

_Chaque partie est un document à part. Liez-la plutôt que de la recopier : chaque fait vit à un seul endroit._

- [Contexte et exigences](https://nodary.ai/fr/templates/technical-design-document#doc-context) : l’existant, les exigences et les contraintes
- [Architecture](https://nodary.ai/fr/templates/technical-design-document#doc-architecture) : les composants, le parcours d’une requête et les décisions clés
- [Données et interfaces](https://nodary.ai/fr/templates/technical-design-document#doc-data) : le modèle de données, les API, les événements et la migration
- [Exploitation](https://nodary.ai/fr/templates/technical-design-document#doc-operations) : déploiement, surveillance, sécurité et modes de panne
- [Alternatives et risques](https://nodary.ai/fr/templates/technical-design-document#doc-alternatives) : les options écartées, les risques, le déploiement et les questions ouvertes

_Ce modèle est libre d’utilisation, de modification et de partage. Il vient de_ [Nodary](https://nodary.ai/fr)_, où ces fichiers s’importent sous forme de carte de documents liés._

### Contexte et exigences

**Responsable :** [nom] · **Statut :** brouillon · **Dernière relecture :** [date]

#### L’existant

_Ce qui existe aujourd’hui et ce qui ne va pas, en quelques phrases. Liez le code, les tableaux de bord et les conceptions précédentes._

[L’existant]

#### Exigences

_Les exigences qui façonnent la conception, chacune reliée à sa source. Laissez de côté celles que la conception ne touche pas._

| ID | Exigence | Source |
| --- | --- | --- |
| [E1] | [...] | [PRD, incident, réglementation] |
| [E2] | [...] | [...] |

_Exemple (une fonctionnalité d’exemple) : E1 : un lien cesse de s’ouvrir dans la minute qui suit sa date de fin. Source : les critères d’acceptation du PRD._

#### Contraintes

- Performance : [...]
- Sécurité et confidentialité : [...]
- Compatibilité : [...]
- Équipe et délais : [...]

#### Hypothèses

- [Hypothèse], vérifiée par [nom]
- [...]

Voir aussi : [Document de conception technique](https://nodary.ai/fr/templates/technical-design-document#doc-overview) · [Architecture](https://nodary.ai/fr/templates/technical-design-document#doc-architecture)

### Architecture

**Responsable :** [nom] · **Statut :** brouillon · **Dernière relecture :** [date]

#### Composants

_Remplacez ces boîtes par les vôtres. Indiquez ce qui est nouveau, ce qui change et ce qui reste tel quel._

```mermaid
flowchart TD
  n0["Client"]
  n1["API"]
  n2["Service"]
  n3["Base de données"]
  n4["File de tâches"]
  n5["Stockage de fichiers"]
  n0 --> n1
  n1 --> n2
  n2 --> n3
  n2 --> n4
  n4 --> n3
  n2 --> n5
```
_Les composants principaux et les appels entre eux_

| Composant | Rôle | Équipe | Nouveau ou modifié |
| --- | --- | --- | --- |
| [API] | [...] | [équipe] | [nouveau, modifié, inchangé] |
| [...] | [...] | [...] | [...] |

#### Parcours d’une requête

_Suivez une requête de l’action de l’utilisateur à la réponse. Numérotez les étapes : les relecteurs les commentent par numéro._

1. [L’utilisateur fait ...]
2. [L’API vérifie ...]
3. [Le service écrit ...]
4. [La réponse dit ...]

#### Décisions clés

_Les choix avec lesquels un relecteur doit être d’accord. Donnez à chaque choix important une fiche dans le journal des décisions de l’équipe, et liez-la ici._

| Décision | Pourquoi | Fiche |
| --- | --- | --- |
| [...] | [...] | [lien] |

Voir aussi : [Contexte et exigences](https://nodary.ai/fr/templates/technical-design-document#doc-context) · [Données et interfaces](https://nodary.ai/fr/templates/technical-design-document#doc-data) · [Exploitation](https://nodary.ai/fr/templates/technical-design-document#doc-operations)

### Données et interfaces

**Responsable :** [nom] · **Statut :** brouillon · **Dernière relecture :** [date]

#### Modèle de données

| Entité | Champ | Type | Notes |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [facultatif, indexé, donnée personnelle] |
| [...] | [...] | [...] | [...] |

_Exemple (une fonctionnalité d’exemple) : share__link.expires__at : un horodatage avec fuseau, vide quand le lien n’a pas de fin, indexé pour la tâche qui révoque les liens expirés._

#### API

| Méthode | Chemin | Rôle | Qui peut l’appeler |
| --- | --- | --- | --- |
| [POST] | [/...] | [...] | [...] |
| [...] | [...] | [...] | [...] |

#### Événements

| Événement | Émis quand | Lu par |
| --- | --- | --- |
| [...] | [...] | [...] |

#### Migration

_Comment les données existantes passent à la nouvelle forme sans interruption, et comment revenir en arrière._

1. [Ajouter les nouveaux champs, vides]
2. [Écrire dans l’ancien et le nouveau]
3. [Remplir l’historique]
4. [Lire dans le nouveau]
5. [Retirer l’ancien]

Voir aussi : [Architecture](https://nodary.ai/fr/templates/technical-design-document#doc-architecture) · [Exploitation](https://nodary.ai/fr/templates/technical-design-document#doc-operations)

### Exploitation

**Responsable :** [nom] · **Statut :** brouillon · **Dernière relecture :** [date]

#### Déploiement

- Où cela tourne : [...]
- Comment c’est livré : [chaîne de livraison, drapeaux]
- Configuration et secrets : [...]

#### Surveillance et alertes

| Signal | Normal | Alerte quand | L’alerte va à |
| --- | --- | --- | --- |
| [taux d’erreur] | [...] | [...] | [équipe] |
| [...] | [...] | [...] | [...] |

#### Sécurité et confidentialité

- [ ] Chaque requête vérifie qui demande et ce qu’il a le droit de faire
- [ ] Données personnelles listées, avec où elles sont gardées et combien de temps
- [ ] Secrets hors du code et des journaux
- [ ] Entrées vérifiées là où elles entrent dans le système
- [ ] Abus et limites de débit envisagés

#### Modes de panne

| Panne | Ce que voient les utilisateurs | Comment on le voit | Comment on reprend |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |
| [...] | [...] | [...] | [...] |

_Exemple (une fonctionnalité d’exemple) : La tâche de révocation s’arrête : les liens expirés restent refusés, puisque chaque requête vérifie la date ; seul le nettoyage prend du retard. Une alerte part quand la tâche n’a pas tourné depuis cinq minutes._

Voir aussi : [Architecture](https://nodary.ai/fr/templates/technical-design-document#doc-architecture) · [Alternatives et risques](https://nodary.ai/fr/templates/technical-design-document#doc-alternatives)

### Alternatives et risques

**Responsable :** [nom] · **Statut :** brouillon · **Dernière relecture :** [date]

#### Alternatives envisagées

| Option | Pour | Contre | Pourquoi non |
| --- | --- | --- | --- |
| [...] | [...] | [...] | [...] |
| [...] | [...] | [...] | [...] |

#### Risques

| Risque | Impact | Ce qu’on y fait | Responsable |
| --- | --- | --- | --- |
| [...] | [faible, moyen, fort] | [...] | [nom] |

#### Déploiement progressif

1. Derrière un drapeau, pour [l’équipe]
2. [Une petite part] des [utilisateurs]
3. Tout le monde
4. Drapeau retiré

#### Questions ouvertes

- [ ] [Question], [qui y répond], [pour quand]

Voir aussi : [Document de conception technique](https://nodary.ai/fr/templates/technical-design-document#doc-overview) · [Contexte et exigences](https://nodary.ai/fr/templates/technical-design-document#doc-context) · [Exploitation](https://nodary.ai/fr/templates/technical-design-document#doc-operations)

## Comment s’en servir

### Partez des exigences

Liez les exigences produit dans la page de contexte et listez celles qui façonnent la conception. Une conception qui ne répond à aucune exigence est un refactoring déguisé.

### Dessinez, puis écrivez

Dessinez les composants et les appels entre eux avant la prose. Un relecteur repère une boîte manquante plus vite qu’un paragraphe manquant.

### Écrivez ce que vous avez écarté

Remplissez les alternatives avec les options sérieusement envisagées. La relecture ne les rouvrira pas une par une.

### Mettez-le à jour après la réalisation

Quand le code est livré, notez ce qui a changé par rapport au plan. Le suivant lit la conception pour savoir comment le système marche, pas comment on l’avait imaginé.

## Importez-le dans Nodary en carte

Nodary est un espace de travail IA où les documents d’une équipe se relient au lieu de s’empiler. Importez le .zip : la conception arrive avec ses cinq parties rangées sous elle, ses liens conservés et son diagramme dessiné en diagramme Mermaid modifiable. Les relecteurs commentent un passage ou un élément de diagramme, l’auteur demande une approbation, et des agents de code comme Cursor, Claude Code ou VS Code, connectés par MCP, lisent la conception avant d’écrire le code.

1. Ouvrez la carte d’un projet et choisissez Importer.
2. Choisissez l’onglet Dossier ou ZIP, puis Choisir un ZIP.
3. Sélectionnez le fichier téléchargé, vérifiez l’arborescence et importez.

L’offre gratuite compte dix documents par espace de travail, page du projet comprise : les six du modèle laissent la place pour trois autres. Nodary a aussi un modèle de conception technique d’une page intégré.

## Écrire une conception que les relecteurs peuvent approuver

Un document de conception technique échoue quand les relecteurs ne savent pas ce qu’ils approuvent, ou quand le système décrit n’est pas celui qui a été livré. Ces habitudes évitent les deux.

### Commencez par la décision

Dites dans le résumé ce que vous allez construire et le choix qu’un relecteur doit regarder en premier. Personne ne devrait le trouver en page trois.

### Dessinez avant d’écrire

Un diagramme de six boîtes et de leurs appels vaut six pages de prose, et montre tout de suite la pièce qui manque.

### Dites ce que vous ne ferez pas

Les non-objectifs gardent la relecture sur la conception présentée, pas sur celle que quelqu’un aurait voulu lire.

### Montrez les options écartées

Pour chaque choix important, dites ce que vous avez envisagé d’autre et pourquoi non. Les relecteurs discutent alors vos raisons, pas votre conclusion.

### Prévoyez la panne

Dites ce qui se passe quand chaque partie tombe, comment vous le verrez et comment vous reprenez. L’exploitation fait partie de la conception, ce n’est pas une annexe.

### Gardez-la vraie après la réalisation

Notez ce qui a changé pendant la réalisation et liez les décisions qui l’expliquent. Une conception fidèle au code est une documentation ; une conception qui ne l’est pas est un piège.

## Questions sur le document de conception technique

### Qu’est-ce qu’un document de conception technique ?

Un document de conception technique (en anglais technical design document, TDD) décrit comment un système ou une fonctionnalité sera construit avant l’écriture du code : son contexte et ses exigences, son architecture, ses données et interfaces, son déploiement et sa surveillance, les risques et les alternatives envisagées. Les développeurs l’écrivent pour que d’autres relisent l’approche tant qu’elle coûte peu à changer.

### Que doit contenir un document de conception technique ?

Un résumé avec objectifs et non-objectifs, l’existant et les exigences, les composants et leurs échanges, le modèle de données et les API, le déploiement, la surveillance, la sécurité et les modes de panne, les alternatives envisagées, les risques, le plan de déploiement et les questions ouvertes. Ce modèle a un document pour chaque groupe.

### Quelle différence avec un PRD ?

Le document d’exigences produit dit ce que la fonctionnalité doit faire et pourquoi. Le document de conception technique dit comment le système le fera. Écrivez d’abord le PRD, puis liez-le depuis la conception pour que chaque exigence se retrouve.

### Quand un changement demande-t-il un document de conception ?

Quand il touche plusieurs composants ou équipes, change des données existantes, est difficile à défaire, ou porte un risque qui mérite un second regard. Un petit changement dans un seul composant demande en général une bonne pull request, pas un document de conception.

### Qui doit relire un document de conception technique ?

Les développeurs qui vont le construire et l’exploiter, un développeur de chaque système concerné, et une personne responsable de la sécurité quand il touche à des données personnelles ou à des accès. Demandez la relecture tôt, avant que l’essentiel du code existe.

### Les équipes de jeu écrivent-elles aussi des documents de conception technique ?

Oui. Le modèle de document de game design a une partie conception technique pour le moteur, les cibles et la chaîne de production ; un gros système, comme le réseau, les sauvegardes ou les outils, mérite son propre document de conception technique, relié depuis le GDD.

La page : https://nodary.ai/fr/templates/technical-design-document