> For the complete documentation index, see [llms.txt](https://doc.dastra.eu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.dastra.eu/features/compliance/projects/design.md).
# Conception du projet
La phase de conception constitue le point de départ de votre projet de conformité.
Elle permet de définir le **cadre organisationnel**, de sélectionner les **référentiels applicables** et d’initialiser automatiquement les contrôles, tests et risques associés.
Cette étape pose les fondations du projet et conditionne la qualité du suivi dans les phases suivantes.
***
### 1. Création du projet et définition du périmètre
Lors de la création du projet, un **périmètre organisationnel** doit être sélectionné.\
Le périmètre (scope) regroupe une ou plusieurs unités organisationnelles et détermine **le champ d’application du projet de conformité**.
{% columns %}
{% column %}
Une fois le projet créé, le périmètre est affiché dans l’en-tête du projet et utilisé tout au long du cycle de conformité.
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
***
### 2. Affectation des utilisateurs au projet
{% columns %}
{% column %}
{% endcolumn %}
{% column %}
La phase de conception permet également de **désigner les utilisateurs autorisés à gérer le projet**.
* Chaque utilisateur peut se voir attribuer un rôle (ex. : responsable).
* Ces utilisateurs seront habilités à piloter les contrôles, les tests et les audits du projet.
{% endcolumn %}
{% endcolumns %}
***
### 3. Ajout des frameworks de conformité
Un projet de conformité repose sur un ou plusieurs **frameworks** (standards, référentiels internes ou personnalisés).
L’ajout d’un framework permet d’importer :
* les **exigences**,
* les **contrôles**,
* les **tests**,
* et les **risques** associés.
Seules les versions publiées d'un framework sont proposées. Lorsque plusieurs versions publiées existent, choisissez la version dans la liste **Version à installer** affichée à côté du nom du framework ; la version actuelle est présélectionnée.
Le projet reste rattaché à la version installée. Lorsqu'elle n'est plus la version actuelle, la carte du framework dans la vue d'ensemble du projet affiche le badge **Mise à jour disponible**. Le passage à une autre version se fait manuellement avec l'action **Mettre à jour la version du framework**, impossible tant qu'un audit est en cours dans le projet (voir [Versions de framework](/features/compliance/library/frameworks/versions-de-framework.md)).
Il est possible d’ajouter plusieurs frameworks successivement au même projet.
***
### 4. Mutualisation des contrôles entre frameworks
Lorsque plusieurs frameworks sont ajoutés au projet, Dastra détecte automatiquement les **contrôles communs**.
* Un contrôle partagé entre plusieurs frameworks **n’est importé qu’une seule fois**.
* Sa mise en œuvre couvre simultanément l’ensemble des exigences associées.
* Cela permet d’augmenter la couverture de conformité sans multiplier les actions.
***
### 5. Sélection des contrôles à importer
Lors de l’ajout d’un framework, plusieurs options sont proposées :
* importer **l’ensemble des contrôles** du framework,
* importer **uniquement certains contrôles**,
* ou **ne pas importer de contrôles** afin de les implémenter manuellement.
Cette flexibilité permet d’adapter le projet à la maturité de l’organisation.
***
### 6. Initialisation des contrôles et des tests
{% columns %}
{% column %}
Une fois les frameworks importés :
* Les **contrôles sélectionnés** sont automatiquement ajoutés au projet.
* Ils sont considérés comme **implémentés par défaut**.
* Les **tests associés** sont également rattachés aux contrôles.
À ce stade :
* les tests sont positionnés dans l’état **« preuve manquante »**,
* aucune preuve n’est encore collectée.
{% endcolumn %}
{% column %}
{% endcolumn %}
{% endcolumns %}
***
### 7. Préparation de l’analyse des risques
Les **risques issus des frameworks** peuvent être sélectionnés lors de l’import.
Ils constituent :
* la base de l’**évaluation du risque initial**,
* le point de référence pour le calcul du **risque résiduel** après application des contrôles.
***
### Résultat de la phase Conception
À l’issue de la phase de conception, le projet dispose :
* d’un périmètre clairement défini,
* de responsables identifiés,
* de frameworks applicables importés,
* de contrôles mutualisés et prêts à être suivis,
* de tests initialisés,
* et d’une base de risques structurée.
Le projet est alors prêt à entrer dans la phase suivante : **Implémentation**.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://doc.dastra.eu/features/compliance/projects/design.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
