"
- }]
-}) }}
-
-
-
-[Voir aussi la page du composant sur le site du DSFR](https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/accordeon){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
\ No newline at end of file
diff --git a/content/fr/blog/posts/architecture.md b/content/fr/blog/posts/architecture.md
new file mode 100644
index 0000000..0d16cb5
--- /dev/null
+++ b/content/fr/blog/posts/architecture.md
@@ -0,0 +1,28 @@
+---
+title: Guide de bonnes pratiques d’architecture
+description: ensemble d’exigences non fonctionnelles et de bonnes pratiques d’architecture SI, s’appliquant à l’ensemble des applications et SI du MIOM et Inter Ministériel
+date: git Last Modified
+tags:
+ - cloud
+ - virtualisation
+ - architecture
+ - dev.
+ - ci/cd
+---
+
+{% from "components/component.njk" import component with context %}
+
+{{ component("card", {
+ url: "/guide-architecture/sommaire",
+ title: "Guide de bonnes pratiques d’architecture",
+ description: "ensemble d’exigences non fonctionnelles et de bonnes pratiques d’architecture SI, s’appliquant à l’ensemble des applications et SI du MIOM et Inter Ministériel;",
+ tags: [],
+ date: "2023-06-21" | jsDateObject,
+ badges: [],
+ image: {
+ path: "../../../../public/img/undraw_urban_design_kpu8.png",
+ alt: ""
+ },
+ orientation: "horizontal"
+}) }}
+
\ No newline at end of file
diff --git a/content/fr/blog/posts/blog-post.md b/content/fr/blog/posts/blog-post.md
deleted file mode 100644
index 8b21d75..0000000
--- a/content/fr/blog/posts/blog-post.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Mise en page d'un article
-description: Caractéristiques de la mise en page d'un article de blog.
-date: git Last Modified
-tags:
- - layout
- - contenu
----
-La mise en page [`post.njk`](https://github.com/codegouvfr/eleventy-dsfr/tree/main/_includes/layouts/post.njk) utilisée pour les articles de blog, permet l'ajout d'une bannière en haut, via la variable `image` du cartouche :
-
-```markdown
----
-image:
- src: ./possum.png
- alt: A possum
----
-```
-
-**Note :** La variable `src` correspond au chemin relatif du fichier depuis l'emplacement de la page dans le dépôt.
-
-Le fil d'Ariane peut être affiché automatiquement si la variable `showBreadcrumb` du cartouche est positionnée :
-
-```markdown
----
-showBreadcrumb: true
----
-```
\ No newline at end of file
diff --git a/content/fr/blog/posts/carte.md b/content/fr/blog/posts/carte.md
deleted file mode 100644
index 90a5803..0000000
--- a/content/fr/blog/posts/carte.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-title: Carte
-description: Comment intégrer une carte dans une page du site ?
-date: git Last Modified
-tags:
- - DSFR
- - composant
----
-Chaque composant peut être inclus dans un fichier Nunjucks `.njk` ou Markdown `.md`.
-
-## Exemple d'utilisation
-
-```njk
-{% raw %}
-{% from "components/component.njk" import component with context %}
-{{ component("card", {
- url: "/",
- title: "Intitulé carte",
- description: "La carte donne des aperçus cliquables d’une page de contenu à l’utilisateur. Elle fait généralement partie d'une collection ou liste d’aperçus de contenu similaires. La carte n’est jamais présentée de manière isolée.",
- tags: ["label tag"],
- date: "2023-06-21" | jsDateObject,
- badges: ["label badge"],
- image: {
- path : "../../../../public/img/placeholder.16x9.png",
- alt: ""
- },
- orientation: "horizontal"
-}) }}
-{% endraw %}
-```
-
-Le format complet de l'objet en paramètre est le suivant :
-
-```json
-{
- "url": "string",
- "externalUrl": "string",
- "urlDescription": "string",
- "title": "string",
- "description": "string",
- "tags": "string[]",
- "date": "Date",
- "badges": "string[]",
- "image": {
- "path": "string",
- "alt": "string"
- },
- "orientation": "horizontal | vertical"
-}
-```
-
-Si `card.externalUrl` est utilisé, `card.url` doit être `false`. `card.urlDescription` peut alors être utilisé pour nommer le lien.
-`imagePath` est le chemin de l'image dans le système de fichier (et non pas son url dans le site).
-
-## Rendu
-
-{% from "components/component.njk" import component with context %}
-
-{{ component("card", {
- url: "/",
- title: "Intitulé carte",
- description: "La carte donne des aperçus cliquables d’une page de contenu à l’utilisateur. Elle fait généralement partie d'une collection ou liste d’aperçus de contenu similaires. La carte n’est jamais présentée de manière isolée.",
- tags: ["label tag"],
- date: "2023-06-21" | jsDateObject,
- badges: ["label badge"],
- image: {
- path : "../../../../public/img/placeholder.16x9.png",
- alt: ""
- },
- orientation: "horizontal"
-}) }}
-
-
-
-
-[Voir aussi la page du composant sur le site du DSFR](https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/carte){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
\ No newline at end of file
diff --git a/content/fr/blog/posts/citation.md b/content/fr/blog/posts/citation.md
deleted file mode 100644
index e3c576a..0000000
--- a/content/fr/blog/posts/citation.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: Citation
-description: Comment intégrer une citation dans une page du site ?
-date: git Last Modified
-tags:
- - DSFR
- - composant
----
-Chaque composant peut être inclus dans un fichier Nunjucks `.njk` ou Markdown `.md`.
-
-## Utilisation
-
-### Exemple d'utilisation dans un fichier Markdown `.md`
-
-Seul le texte est disponible.
-
-```md
-:::quote /img/placeholder.1x1.png
-« Lorem [...] elit ut. »
-:::
-```
-
-Le chemin de l'image (optionnelle) est son url dans le site.
-
-### Exemple d'utilisation dans un fichier Nunjucks `.njk`
-
-```njk
-{% raw %}
-{% from "components/component.njk" import component with context %}
-{{ component("quote", {
- sourceUrl: "/",
- text: "Lorem [...] elit ut.",
- author: "Auteur",
- source: "Ouvrage",
- imageSrc: "/img/placeholder.1x1.png"
-}) }}
-{% endraw %}
-```
-
-## Rendu
-
-{% from "components/component.njk" import component with context %}
-{{ component("quote", {
- sourceUrl: "/",
- text: "Lorem [...] elit ut.",
- author: "Auteur",
- source: "Ouvrage",
- imageSrc: "/img/placeholder.1x1.png"
-}) }}
-
-
-
-[Voir aussi la page du composant sur le site du DSFR](https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/citation){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
\ No newline at end of file
diff --git a/content/fr/blog/posts/cloud-pi-native.md b/content/fr/blog/posts/cloud-pi-native.md
new file mode 100644
index 0000000..7d430b0
--- /dev/null
+++ b/content/fr/blog/posts/cloud-pi-native.md
@@ -0,0 +1,30 @@
+---
+title: Cloud Pi Native (intermin)
+description: "Avec l’adoption de la doctrine « Cloud au centre », le Gouvernement Français fait du Cloud un prérequis pour tout nouveau projet numérique au sein de l’État ou refonte substantielle de l’architecture applicative existante."
+date: git Last Modified
+tags:
+ - cloud
+ - cloud native
+ - kubernetes
+ - intermin
+---
+
+
+{% from "components/component.njk" import component with context %}
+
+{{ component("card", {
+ url: false,
+ externalUrl: "https://github.com/cloud-pi-native/documentation",
+ title: "Cloud PI Native",
+ description: "L'objectif est d'accélérer la transformation numérique au bénéfice des usagers et dans le strict respect de la cybersécurité et de la protection des données des citoyens et des entreprises.
+ L'offre interministérielle Cloud π Native, offre les services d'une plateforme DevSecOps complète afin de suivre le cycle de vie complet de son projet.",
+ tags: [],
+ date: "2023-06-21" | jsDateObject,
+ badges: [],
+ image: {
+ path: "../../../../public/img/undraw_Weather_app_re_kcb1.png",
+ alt: ""
+ },
+ orientation: "horizontal"
+}) }}
+
\ No newline at end of file
diff --git a/content/fr/blog/posts/donnees-api.md b/content/fr/blog/posts/donnees-api.md
new file mode 100644
index 0000000..a7c12b2
--- /dev/null
+++ b/content/fr/blog/posts/donnees-api.md
@@ -0,0 +1,26 @@
+---
+title: Données et API
+description: Données et doctrine API
+date: git Last Modified
+tags:
+ - api
+ - data
+ - données
+---
+
+{% from "components/component.njk" import component with context %}
+
+{{ component("card", {
+ url: "/donnees-api/introduction",
+ title: "",
+ description: "Toute application offre des services et manipule des données, des concepts métier, qui jouent souvent un rôle plus large et plus durable que l'application elle-même.",
+ tags: [],
+ date: "2023-06-21" | jsDateObject,
+ badges: [],
+ image: {
+ path: "../../../../public/img/undraw_Location_tracking_re_n3ok.png",
+ alt: ""
+ },
+ orientation: "horizontal"
+}) }}
+
\ No newline at end of file
diff --git a/content/fr/blog/posts/ent.md b/content/fr/blog/posts/ent.md
new file mode 100644
index 0000000..8f9d82f
--- /dev/null
+++ b/content/fr/blog/posts/ent.md
@@ -0,0 +1,26 @@
+---
+title: ENT (intermin)
+description: ensemble de règles et exigences s’appliquant aux applications et SI bureautique du MIOM et à l’interministériel
+date: git Last Modified
+tags:
+ - dsfr
+ - rgaa
+ - intermin
+---
+
+{% from "components/component.njk" import component with context %}
+
+{{ component("card", {
+ url: "/ent/sommaire",
+ title: "Environnement Numérique de Travail",
+ description: "L’Environnement Numérique de Travail (ENT) correspond à l’ensemble des ressources, matériels, outils et services transverses mis à disposition des agents du Ministère de l’Intérieur et des Outre-Mer, leur permettant d’accéder aux informations, de créer ou modifier des fichiers, de communiquer, de collaborer sur des projets, en mobilité ou dans les locaux administratifs, dans un cadre sécurisé",
+ tags: [],
+ date: "2023-06-21" | jsDateObject,
+ badges: [],
+ image: {
+ path: "../../../../public/img/undraw_progressive_app_m9ms.png",
+ alt: ""
+ },
+ orientation: "horizontal"
+}) }}
+
\ No newline at end of file
diff --git a/content/fr/blog/posts/evenement.md b/content/fr/blog/posts/evenement.md
deleted file mode 100644
index f8f369a..0000000
--- a/content/fr/blog/posts/evenement.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Événement exemple
-description: Comment ajouter un événement au calendrier ?
-date: 2023-09-10T09:00:00.0Z
-duration: 50
-location: online
-tags:
-- event
----
-Voici un exemple d'événement qui sera ajouté au calendrier global accessible à l'adresse [/calendar.ics](/calendar.ics), et dont on peut télécharger l'événement de calendrier correspondant à l'adresse [/calendar/evenement-exemple-2023-09-10.ics](/calendar/evenement-exemple-2023-09-10.ics).
-
-## Variables du template
-
-```json
-{
- "title": "string",
- "description": "string",
- "date": "date", // ex. 2001-12-15T02:59:43.1Z
- "duration": "number",
- "location": "string"
-}
-```
-
-## Exemple d'utilisation du composant bouton `add_to_calendar`
-
-```njk
-{% raw %}
-{% include "components/add_to_calendar.njk" %}
-{% endraw %}
-```
-## Rendu du composant bouton `add_to_calendar`
-
-
- {% include "components/add_to_calendar.njk" %}
-
-
-[Voir la section sur la fonctionnalité de calendrier](/fr/blog/fonctionnalités/#calendrier){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
diff --git a/content/fr/blog/posts/fil-d-ariane.md b/content/fr/blog/posts/fil-d-ariane.md
deleted file mode 100644
index 7382a9f..0000000
--- a/content/fr/blog/posts/fil-d-ariane.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: Fil d'Ariane
-description: Comment intégrer un fil d'Ariane dans une page du site ?
-date: git Last Modified
-tags:
- - DSFR
- - composant
----
-Chaque composant peut être inclus dans un fichier Nunjucks `.njk` ou Markdown `.md`.
-
-## Utilisation
-
-### Exemple d'utilisation dans un fichier Nunjucks `.njk`
-
-```njk
-{% raw %}
-{% from "components/component.njk" import component with context %}
-{{ component("breadcrumb", {
- segments: [{
- url: "/blog/",
- title: "Blog"
- }]
-}) }}
-{% endraw %}
-```
-
-### Exemple d'utilisation dans un article de blog ou une page
-
-```yaml
-{% raw %}
----
-segments:
- - url: "/blog/"
- - title: "Blog"
-showBreadcrumb: true
----
-{% endraw %}
-```
-
-[Voir aussi comment utiliser des données dans Eleventy](https://www.11ty.dev/docs/data/){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
-
-## Rendu
-
-{% from "components/component.njk" import component with context %}
-{{ component("breadcrumb", {
- segments: [{
- url: "/blog/",
- title: "Blog"
- }]
-}) }}
-
-[Voir aussi la page du composant sur le site du DSFR](https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/fil-d-ariane){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
\ No newline at end of file
diff --git "a/content/fr/blog/posts/fonctionnalit\303\251s.md" "b/content/fr/blog/posts/fonctionnalit\303\251s.md"
deleted file mode 100644
index 0e1e3ed..0000000
--- "a/content/fr/blog/posts/fonctionnalit\303\251s.md"
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: Fonctionnalités
-description: Comment utiliser certaines des fonctionnalités d'eleventy-dsfr ?
-date: git Last Modified
-tags:
- - contenu
- - i18n
- - navigation
- - pagination
----
-## i18n
-
-[Voir le système d'i18n d'Eleventy](https://www.11ty.dev/docs/i18n/){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
-
-Pour traduire une chaîne de caractères localisée dans une page, utiliser le filtre `i18n` :
-
-```njk
-{% raw %}
-{{ "filter_by_tag" | i18n }}
-{% endraw %}
-```
-
-Pour internationaliser une page : la nommer de la même manière dans toutes les langues, et positionner la variable `slugOverride` du cartouche si besoin.
-
-```yaml
----
-slugOverride: a propos
----
-```
-
-Par exemple, pour la page [À propos](/fr/a-propos), le fichier en français est [`content/fr/about/index.md`](https://github.com/codegouvfr/eleventy-dsfr/tree/main/content/fr/about/index.md), le fichier en anglais est [`content/en/about/index.md`](https://github.com/codegouvfr/eleventy-dsfr/tree/main/content/en/about/index.md).
-L'url en français est [/fr/a-propos](/fr/a-propos), l'url en anglais est [/en/about](/en/about).
-
-## Navigation
-
-[Voir le système de navigation d'Eleventy](https://www.11ty.dev/docs/plugins/navigation/){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
-
-Pour mettre en place une navigation de niveau 2, positionner la variable `parent` avec la valeur de la `key` du parent.
-Par exemple, dans le fichier [`content/fr/about/index.md`](https://github.com/codegouvfr/eleventy-dsfr/tree/main/content/fr/about/index.md) :
-
-```yaml
----
-eleventyNavigation:
- key: Présentation
- parent: À propos
- order: 1
----
-```
-
-Et dans le fichier [`content/fr/about.md`](https://github.com/codegouvfr/eleventy-dsfr/tree/main/content/fr/about.md) :
-
-```yaml
----
-eleventyNavigation:
- key: À propos
- order: 3
-permalink: false
----
-```
-
-**Note :** Cette page n'est pas référencée pour la génération (`permalink: false`) car dans ce cas, elle ne sert que de conteneur de premier niveau pour la navigation.
-
-## Pagination
-
-[Voir le système de pagination d'Eleventy](https://www.11ty.dev/docs/pagination/){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
-
-Pour mettre en place la pagination pour les tags, utiliser le filtre `paginateCollectionTags` dans une fonction de [callback `before`](https://www.11ty.dev/docs/pagination/#the-before-callback) dans un cartouche Javascript.
-Par exemple, dans le fichier [`content/fr/blog/tags.njk`](https://github.com/codegouvfr/eleventy-dsfr/tree/main/content/fr/blog/tags.njk) :
-
-```javascript
----js
- {
- pagination: {
- data: "collections.posts",
- size: 1,
- alias: "tag",
- before: function(paginationData, fullData) {
- return this.paginateCollectionTags(this.filterCollectionLang(paginationData, fullData.lang), 6);
- }
- }
- }
----
-```
-
-## Calendrier
-
-La présence des fichiers de template dans [`content/calendar`](https://github.com/codegouvfr/eleventy-dsfr/tree/main/content/calendar) assure la création d'un fichier de calendrier global [`calendar.ics`](/calendar.ics) à la racine du site, et des fichiers de calendrier `.ics` correspondants aux événements.
-
-Les articles libellés avec `event` sont automatiquement ajoutés au calendrier, et leurs fichiers d'événement de calendrier `.ics` correspondants sont automatiquement créés.
-
-Il existe un composant bouton `add_to_calendar` qui contient un lien vers le téléchargement du fichier d'événement.
-
-[Voir un exemple d'événement](/fr/blog/evenement/){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
\ No newline at end of file
diff --git a/content/fr/blog/posts/legacy.md b/content/fr/blog/posts/legacy.md
new file mode 100644
index 0000000..452866b
--- /dev/null
+++ b/content/fr/blog/posts/legacy.md
@@ -0,0 +1,27 @@
+---
+title: Legacy
+description: ensemble de règles et exigences s’appliquant aux applications et SI du MIOM ne pouvant pas être conçus comme étant cloud native (contraintes techniques et / ou légales)
+date: git Last Modified
+tags:
+ - cloud
+ - openstack
+ - virtualisation
+ - intermin
+---
+
+{% from "components/component.njk" import component with context %}
+
\ No newline at end of file
diff --git a/content/fr/blog/posts/md-cheatsheet.md b/content/fr/blog/posts/md-cheatsheet.md
deleted file mode 100644
index fc57ec1..0000000
--- a/content/fr/blog/posts/md-cheatsheet.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: Syntaxe Markdown
-description: Rappel des éléments de syntaxe Markdown principaux et nouveaux éléments.
-date: git Last Modified
-tags:
- - contenu
- - Markdown
----
-La syntaxe utilisée dans les fichiers Markdown `.md` du site suit la spécification [CommonMark](https://commonmark.org/).
-
-[Voir un rappel des principaux éléments](https://commonmark.org/help/){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
-
-**Deux nouveaux éléments** ont été ajoutés à cette syntaxe et sont disponibles dans eleventy-dsfr.
-
-## La citation
-
-```md
-:::quote
-« Lorem [...] elit ut. »
-:::
-```
-
-[Voir aussi](/fr/blog/citation/#exemple-d-utilisation-dans-un-fichier-markdown-md){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
-
-## La mise en avant
-
-```md
-:::callout Titre mise en avant
-Les parents d’enfants de 11 à 14 ans n’ont aucune démarche à accomplir : les CAF versent automatiquement l’ARS aux familles déjà allocataires qui remplissent les conditions.
-:::
-```
-
-[Voir aussi](/fr/blog/mise-en-avant/#exemple-d-utilisation-dans-un-fichier-markdown-md){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
-
-
-
-La syntaxe utilisée pour le [cartouche](https://www.11ty.dev/docs/data-frontmatter/) en début de fichier est communément le [YAML](https://learnxinyminutes.com/docs/yaml/).
-Il peut contenir des données pré-définies par Eleventy ou personnalisées pour la page en cours.
\ No newline at end of file
diff --git a/content/fr/blog/posts/mise-en-avant.md b/content/fr/blog/posts/mise-en-avant.md
deleted file mode 100644
index 837814c..0000000
--- a/content/fr/blog/posts/mise-en-avant.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: Mise en avant
-description: Comment intégrer une mise en avant dans une page du site ?
-date: git Last Modified
-tags:
- - DSFR
- - composant
----
-Chaque composant peut être inclus dans un fichier Nunjucks `.njk` ou Markdown `.md`.
-
-## Utilisation
-
-### Exemple d'utilisation dans un fichier Markdown `.md`
-
-Seuls le titre et la description sont disponibles.
-
-```md
-:::callout Titre mise en avant
-Contenu **Mardown**
-:::
-```
-
-### Exemple d'utilisation dans un fichier Nunjucks `.njk`
-
-```njk
-{% raw %}
-{% from "components/component.njk" import component with context %}
-{{ component("callout", {
- title: "Titre mise en avant",
- description: "Contenu HTML",
- link: {
- url: "/",
- title: "Label bouton MD"
- }
-}) }}
-{% endraw %}
-```
-
-## Rendu
-
-{% from "components/component.njk" import component with context %}
-{{ component("callout", {
- title: "Titre mise en avant",
- description: "Contenu HTML",
- link: {
- url: "/",
- title: "Label bouton MD"
- }
-}) }}
-
-[Voir aussi la page du composant sur le site du DSFR](https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/mise-en-avant){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
\ No newline at end of file
diff --git a/content/fr/blog/posts/retour-en-haut-de-page.md b/content/fr/blog/posts/retour-en-haut-de-page.md
deleted file mode 100644
index 3b5eef3..0000000
--- a/content/fr/blog/posts/retour-en-haut-de-page.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Retour en haut de page
-description: Comment intégrer un lien de retour en haut dans une page du site ?
-date: git Last Modified
-tags:
- - DSFR
- - composant
----
-Chaque composant peut être inclus dans un fichier Nunjucks `.njk` ou Markdown `.md`.
-
-## Exemple d'utilisation
-
-```njk
-{% raw %}
-{% include "components/back_to_top.njk" %}
-{% endraw %}
-```
-
-## Rendu
-
-
-{% include "components/back_to_top.njk" %}
-
-
-
-
-[Voir aussi la page du composant sur le site du DSFR](https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/retour-en-haut-de-page){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
\ No newline at end of file
diff --git a/content/fr/blog/posts/securite.md b/content/fr/blog/posts/securite.md
new file mode 100644
index 0000000..5f494e9
--- /dev/null
+++ b/content/fr/blog/posts/securite.md
@@ -0,0 +1,26 @@
+---
+title: Guide des bonnes pratiques de sécurité
+description: ensemble d’exigences non fonctionnelles et de bonnes pratiques de sécurité des SI et des applications hébergées chez l’infrastructure du MIOM et des autres ministères
+date: git Last Modified
+tags:
+ - nfr
+ - anssi
+ - ssi
+ - homologation
+---
+
+{% from "components/component.njk" import component with context %}
+
-
-
-
-[Voir aussi la page du composant sur le site du DSFR](https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/tuile){.fr-link .fr-fi-arrow-right-line .fr-link--icon-right}
\ No newline at end of file
diff --git a/content/fr/chapeau.md b/content/fr/chapeau.md
new file mode 100644
index 0000000..e435917
--- /dev/null
+++ b/content/fr/chapeau.md
@@ -0,0 +1,250 @@
+---
+title: Pour commencer
+layout: layouts/page.njk
+showBreadcrumb: true
+eleventyNavigation:
+ key: pour commencer
+ parent: Présentation
+ order: 1
+---
+
+À travers sa doctrine « Cloud au centre », l’État encourage l’ensemble des acteurs publics
+à se saisir de son potentiel afin de développer une nouvelle génération de services
+numériques de qualité, tout en protégeant au mieux les données des entreprises et des
+citoyens français.
+
+Dans le but de disposer un SI adapté et agile, le MIOM a posé un ensemble de normes
+techniques et des recommandations de nature, formalisés dans un document de Cadre
+de Cohérence Technique (CCT), pour le développement de nouvelles applications
+compatibles avec ces normes et hébergées sur son infrastructure, et de services de
+qualité qui répondent aux besoins des métiers et déployables rapidement et à coûts
+réduits.
+
+Ce document représente le document « chapeau » du Cadre de Cohérence Technique
+(CCT) qui vise à faire le lien vers d’autres documents, selon les offres du MIOM et
+interministériel, dont chacun d’eux est couplé d’un guide de bonnes pratiques et d’une
+liste d’annexes et d’exigences.
+
+Le premier chapitre de ce document décrit le contexte et les objectifs du CCT. Il donne
+une visibilité sur son architecture documentaire et son applicabilité selon différents cas d’usages, tout en mentionnant les domaines concernés et les acteurs ciblés ainsi que son utilisation au sein des projets et des processus du MIOM et interministériel.
+
+Le deuxième chapitre défini le cadre d’applicabilité de ce CCT sur les différentes offres de services avec les usages concernés et le dernier chapitre définit son cycle de vie et sa gouvernance.
+
+Pour un accès rapide aux thèmes du CCT correspondant à votre besoin, vous pouvez
+vous référer au tableau ci-dessous.
+
+
+
+
+
+
+## Contexte et Objectifs
+
+Dans le contexte actuel de transformation numérique, le SI du MIOM fait face à des nouveaux défis comme la modernisation du système d’information, l’amélioration de la qualité des services numériques et la création de services innovants et des outils numériques de travail collaboratif.
+
+Dans le but de disposer un SI adapté et agile, le MIOM a posé un ensemble de normes techniques et des recommandations de nature, formalisés dans un document de Cadre de Cohérence Technique (CCT), pour le développement de nouvelles applications compatibles avec ces normes et hébergées sur son infrastructure, et de services de qualité qui répondent aux besoins des métiers et déployables rapidement et à coûts réduits. Ce type d’applications à l’état de l’art et appelées « Cloud Native » est systématiquement privilégié pour les nouveaux projets et évolutions, dans une stratégie « Cloud First ».
+
+
+
+
+
+
+
+Le CCT, au-delà de ses relations directes avec les applications et offres de service, se trouver au centre d’un écosystème d’influences stratégiques et normatives ascendantes et descendantes. Il vise initialement à répondre aux enjeux de dette technique/obsolescence dont le cycle de vie des technologies.
+
+Ce CCT doit être partagé, visible et évolutif.
+Il concourt à fournir à l’utilisateur – qu’il soit citoyen/usager, agent, entreprise ou association - un service numérique de qualité. Cet objectif de qualité doit s'entendre dans toutes ses composantes :
+- En termes de qualité logicielle : un service simple et compréhensible, répondant au besoin, accessible à tous, sécurisé, et préservant les données personnelles
+- En termes de délai et d'évolutivité : le bon service au bon moment
+- En termes de coût : même si en général le service est gratuit, c'est bien l'argent du contribuable qui est mobilisé pour le produire, le maintenir et le faire évoluer
+Le CCT du SI a plusieurs objectifs :
+- Permettre aux applications de partager dans de bonnes conditions l’infrastructure matérielle et l’infrastructure de communication.
+- Permettre aux applications d’interopérer entre elles et avec les partenaires extérieurs.
+- Assurer une bonne pérennité des composants de base par la mise en œuvre de démarches de choix instrumentées, et limiter la variabilité des plates-formes et des configurations.
+- Maîtriser les coûts d’acquisition des progiciels et des composants logiciels ainsi que ceux des services d’intégration et d’administration.
+- Assurer la maîtrise technique des environnements en limitant la multiplication des technologies et des méthodes.
+- Fiabiliser le système d'information en préconisant des briques techniques de sécurité à mettre en œuvre.
+Ce CCT chapeau doit permettre aux Concepteurs/Développeurs, architectes, chefs de projet et DevOps de pouvoir identifier immédiatement les documents et règles auxquelles il doit se conformer en fonction des caractéristiques de son application.
+
+## L'Objet
+
+Ce document représente le document « chapeau » du CCT qui vise à faire le lien vers d’autres documents, selon les offres du MIOM et interministériel, dont chacun d’eux est couplé d’un guide de bonnes pratiques et d’une liste d’annexes et d’exigences.
+Pour plus de flexibilité dans l’évolution et dans l’applicabilité du CCT, celui-ci est scindé en plusieurs documents dont l’architecture est détaillée dans le chapitre 1.3. Ce document « chapeau » vise à faire le lien vers d’autres documents listés ci-dessous dont chacun d’eux est couplé d’une liste d’annexes et d’exigences.
+- Environnements numériques de travail
+- Legacy
+- Cloud Native
+- Guides de bonnes pratiques d’architecture
+- Guides de bonnes pratiques de sécurité
+
+## Architecture documentaire et applicabilité selon les cas
+
+
+Pour des raisons de périmètre et de différences de gouvernance entre les domaines d’exigence, les exigences et recommandations du CCT ont été séparées dans 5 thèmes listés ci-dessous :
+- **Environnement numérique de travail** : ensemble de règles et exigences s’appliquant aux applications et SI bureautique du MIOM et à l’interministériel;
+- **Legacy** : ensemble de règles et exigences s’appliquant aux applications et SI du MIOM ne pouvant pas être conçus comme étant cloud native (contraintes techniques et / ou légales);
+- **Cloud Native** : ensemble des règles et exigences s’appliquant aux applications et SI cloud native à l’interministériel;
+- **Guide de bonnes pratiques d’architecture** : ensemble d’exigences non fonctionnelles et de bonnes pratiques d’architecture SI, s’appliquant à l’ensemble des applications et SI du MIOM et Inter Ministériel;
+- **Guide de bonnes pratiques sécurité** : ensemble d’exigences non fonctionnelles et de bonnes pratiques de sécurité des SI et des applications hébergées chez l’infrastructure du MIOM et des autres ministères.
+
+Les règles et exigences du CCT s’appliquent différemment selon la constitution de
+l’application : a-t-elle une interface « client lourd » ? Une implémentation côté serveur ? Sur Cloud Native ou en Legacy ?
+ - Dans le cas d’une nouvelle application ou application existante avec des évolutions majeures (définir ce qu’est une évolution majeure) à intégrer :
+
+
+
+*Figure: Les documents du CCT à utiliser en fonction des types d'application*.
+
+ - Dans le cas d’une application existante avec des évolutions mineures (définir ce
+qu’est une évolution mineure) à intégrer, quelque soit le type de solution (2.a, 2.b,
+2.c, 2.d ou 2.e) le cadre d’applicabilité sera revu selon les spécificités de chaque
+application et des évolutions.
+
+## Domaines concernés
+Le CCT s'intéresse à 5 domaines principaux, ou piliers :
+- **L’utilisateur**, – qu’il soit citoyen/usager, agent, entreprise, association – Ce
+domaine primordial adresse différents thèmes comme son identification /
+authentification / autorisation, l’environnement numérique de travail de l’agent
+(ETNA)1, les chaînes de soutien, la qualité et l’accessibilité du service rendu
+- **Les données et les API**, patrimoine du SI de l’État et socle sur lequel se fonde le
+service rendu à l'utilisateur
+- La **sécurité du service** et la protection des données personnelles
+- La **fabrique de code** qui traite du "build" au travers des processus d'intégration et de déploiement continu
+- L’**hébergement** qui traite du "run" et des problématiques d'hébergement et
+d'exploitation
+- Les **services transverses** : services de confiance, gestion électronique de courrier, etc.
+
+Dans ces domaines préférentiels :
+- Il édicte des règles et des recommandations;
+- Il référence les règles « parentes » s’appliquant au MIOM (lois, règlements
+européens…);
+- Et il référence les composants et offres services portés par les différents acteurs
+SIC ministériels ou interministériels. Au-delà d'un référentiel de cadrage, le CCT
+se veut un outil de mise en relation entre les producteurs et consommateurs de
+ces composants et services.
+
+
+## Acteurs ciblés
+
+Le CCT a une double portée, ministérielle et interministérielle :
+- Ministérielle pour l’ensemble du périmètre des applications et infrastructures
+appartenant au ministère
+- Interministérielle dans le cas des applications n’appartenant pas au ministère
+mais hébergées en son sein. Ce cas s’adresse principalement aux applications
+Cloud Natives
+Dans ce cadre, les acteurs ciblés par le CCT peuvent être issus du MIOM, d’un autre
+ministère et organisme de l’état ou d’un partenaire externe.
+Les principaux rôles répertoriés sont les suivants :
+- Les propriétaires des applications : référents de l’application qui gèrent son
+homologation, maintiennent son registre RGPD…
+- Les exploitants / hébergeurs : pour leurs exigences d'exploitabilité
+- Les concepteurs / développeurs - qu'ils œuvrent dans les DSI ou dans les directions
+métier, au sein du ministère ou avec des prestataires externes. Le CCT les aident
+à intégrer leur produit dans l'écosystème ministériel et interministériel
+(description des interfaces).
+- Les architectes et intégrateurs. Le CCT les aide à s'orienter vers des architectures
+à la fois maitrisées par le ministère et les plus appropriées au devenir du SI de l'État
+- Les services accompagnant les passations de marché (au travers des clausiers et
+de la notation des offres proposés dans le guide mentionné plus haut)
+
+## Utilisation du CCT au sein des projets et des processus
+
+
+
+*Figure : Focus sur les utilisations du CCT au sein cycle de vie d’une application*
+
+Le CCT contient des exigences de différents niveaux (bloquant, primordial, important).
+A noter que, malgré leur caractère non bloquant, la bonne application des exigences
+primordiales et importantes sera évaluée et notée lors de la comparaison de solutions
+techniques proposées par les prestataires.
+- **Phase de conception** : Pour assurer la bonne prise en compte de ces exigences, il est indispensable de considérer le CCT dès la conception d’une nouvelle application ou au démarrage de la transformation d’une application existante. Et cela avant de démarrer
+les travaux de construction.
+- **Phase de pré-bascule** : Des contrôles de conformité seront effectués lors des phases de test de l’application. Ceux-ci pourront mener à des réserves à la mise en service de l’application.
+- **Phase de bascule et post-bascule** : Si les éventuelles réserves levées lors de la phase de tests ne sont pas levées, la mise en service pourra être bloquée.
+Dans le cadre d’applications développées par des partenaires externes et faisant l’objet
+d’un marché public, le CCT et sa liste d’exigence devront être joints au CCTP.
+
+## Cadre d’applicabilité
+
+### Usages concernés
+Le CCT du MIOM concerne en particulier les modèles de déploiements suivants :
+- **Toute application dont le MIOM** est **propriétaire**
+- **Toute application dont le MIOM** est l’**hébergeur**
+
+Deux approches sont actuellement possibles pour la mise à disposition des applications :
+l’approche « cloud native » et l’approche « legacy » :
+1. La première, le Cloud Native, est à privilégier systématiquement lors de la
+conception de nouvelles applications et lors de la transformation
+d‘applications existantes.
+2. La seconde, le legacy, héberge les applications déployées antérieurement et
+non compatibles avec les nouvelles normes. Elle ne pourra être utilisée pour
+des nouveaux usages que de manière exceptionnelle et dérogatoire.
+
+ |Critères de comparaison|Legacy|Cloud Native|
+ |--------|----------|------|
+ | **Modèle de responsabilité**| Responsabilité entièrement portée par le MIOM à partir de l’intégration de l’application, sur le déploiement et l’exploitation| Responsabilité partagée avec une autonomisation du développeur « you build it,you run it »|
+ |**Processus de déploiement**| Tests, intégration et déploiement manuels ou semi-automatisés|Tests, intégration et déploiements automatisés Déploiements fréquents |
+ |**Exigences et contrôle**|Cadre et exigences sur l’ensemble des couches de l’application Contrôle complet de l’application et infrastructure, homologation de bout en bout| Cadre et exigences focalisés sur les interfaces de l’application et les données exposées Liberté laissée au développeur tant que les interfaces sont respectées|
+ |**Consommation service transverse**|Services transverses à mettre en œuvre et intégrer «manuellement»| Intégration native des services sur étagère et automatiquement|
+ |**Valorisation de la donnée**|Intégration «manuelle» aux services d’exposition de la donnée|Capacités «sur étagère» et automatisée d’exposition des données|
+ |**Observabilité**|Logs non normés, peu ou pas centralisés.|Centralisation systématique du monitoring et des logs de l’infrastructure et des applications permettant une vision 360 sur l’application Normalisation des logs (techniques, métiers, sécurité)|
+ |**Processus de run**|Exploitation des applications dans un modèle **«pet»**, configurations manuelles et réparation des incidents au sein des serveurs|Exploitation dans un modèle **«cattle»**, détection automatisée des problèmes (health check) et reconstruction des containers plutôt que réparation|
+
+
+### Détail sur les contrôles et validation en fonction de l’application
+
+- Pour les grandes applications:
+ - Nouvelles applications : un « Go » devrait être donnée, après étude
+approfondie de la solution par le comité d’architecture
+ - Modifications/évolutions majeures : un « Go » devrait être donnée, après étude approfondie de la modification et l’impact sur la solution globale,
+par le comité d’architecture
+ - Modifications/évolutions mineures : un « Go » devrait être donnée, après étude approfondie de la modification/évolution proposées
+ - Pour les petites applications:
+ - Nouvelles applications : un « Go » devrait être donnée, après étude
+approfondie de la solution par le comité d’architecture (voir lien avec gouvernance ?),
+ - Modifications / évolutions majeures ou mineures : les responsables
+applicatifs effectuent l’étude en autonomie et s’engagent à respecter le CCT
+
+# Cycle de vie du CCT et gouvernance
+
+La gouvernance du CCT s’appuie sur un comité, le comité d'architecture. Celui-ci est
+animé par la DNUM. Le comité est collégial, constitué de référents mandatés par les
+principales sous directions de la DNUM ainsi que des autres acteurs SIC du ministère :
+ST(SI)², PP, agences. Chaque référent titulaire peut être backupé par un suppléant. Les
+décisions sont prises à la majorité des voix des référents présents (titulaire ou
+suppléant).
+
+Au titre de son activité CCT, le comité d’architecture se réunit au moins deux fois par
+an pour valider la publication des mises à jour semestrielles du CCT. En dehors de ces
+deux réunions annuelles, le comité a toute latitude pour organiser les travaux sous
+forme de groupes de travail ad-hoc. Ces groupes de travail peuvent intégrer des
+participants n’appartenant au comité. La liste des représentants des différents acteurs
+SIC du MIOM, ainsi que la liste des contributeurs au CCT mandatés par le comité, sont
+disponibles sur l’espace CCT ministériel.
+
+Contribution du comité d’architecture au CCT : rôle du référent ministériel
+Affecté au BPNM (Bureau des Politiques Numériques du Ministère) de la DTNUM/SDID
+(Sous-Direction à l'Innovation et de la Donnée), il est chargé de :
+
+ - Pilotage du cadre de cohérence technique ministériel, de la gestion et de
+l'animation des groupes de travail et des contributeurs, de la préparation des
+réunions du comité CCT
+ - L’outillage de la méthode, du processus de contrôle de l'application du CCT et
+de la production des livrables
+ - Suivi et de la prise en compte des normes et standards
+ - La veille technologique sur les composants et produits référencés au CCT
+Contribution du comité d’architecture au CCT : les référents des acteurs SIC
+Dans le périmètre de leur entité de rattachement, ils sont chargés de :
+ - L'animation des groupes de travail internes, le cas échéant
+ - Recueil des demandes d'évolution et de la préparation des dossiers présentés en
+comité ministériel
+ - Contrôle de l'application du CCT
+ - L’information au sein de leur entité, et tout particulièrement de la sensibilisation
+des chefs de projets
+
+
+
+:::callout Thèmes
+[Après cette saine lecture découvrons les](../blog)
+:::
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/cloud-au-centre/certification.md b/content/fr/cloud-au-centre/certification.md
new file mode 100644
index 0000000..25eaff4
--- /dev/null
+++ b/content/fr/cloud-au-centre/certification.md
@@ -0,0 +1,115 @@
+---
+title: Cloud PI Native
+layout: layouts/page.njk
+showBreadcrumb: true
+---
+
+# Certification Cloud Pi Native (travail préliminaire)
+
+Inventaire des compétences nécessaires en vue d'obtenir la certification Cloud Pi Native et modalité de validation des compétences.
+
+La certification concerne les domaines suivants de compétence:
+
+- Base et vision numérique de demain
+- Practitioner utilisateurs et Avancés (expert)
+- Contributeur à l’offre : comment contribuer à l'offre.
+- Coaching et transformation d'équipe : comment faire en sorte que l'équipe intègre les concepts, s'améliore en continue.
+- Module animation de communautés internes
+
+Nous sommes à votre écoute pour toute suggestion, critique et apport de contenu.
+
+**Module « base et vision numérique de demain »**
+
+- Comprendre la vision associée à Cloud Pi Native
+- Comprendre la spécificité de Kubernetes, l’architecture d’intégration, l’architecture facilitant l'agilité.
+- Comprendre le landscape cncf, choisir les produits, opérateurs
+- L'éthique et la responsabilité des developpeurs et des architectes.
+- Comprendre la loi de Conway et clean architecture : comprendre et maitriser les impacts du couplage technique et organisationnel, monolithe, monolithe distribué, micro service.
+- Industrialiser la production logicielle, simplifier et réduire la charge de deveoppement.
+- Comprendre la maintenabilité d’un produit numérique, la nécessite de refactoring, la répartition de la capacité d’une équipe
+- Comprendre la topologie des équipes
+- Bibliographie et grands contributeurs internationnaux.
+
+ Validation des acquis par:
+ - QCM
+ - Travaux pratique : designer une architecture logicielle cloud native compatible avec cloud pi native.
+
+**Module « practitioner »**
+- Mettre en place un premier déploiement et le premier build / déploiement. Identifier les ressources nécessaires. Comprendre et utiliser les outils.
+
+ Validation des acquis par :
+ travaux pratiques : faire une démonstration de la maîtrise d’un déploiement sur cloud pi ( sur plateforme simulée )
+
+- Construire un conteneur sécurisé (rootless, filesystem majoritairement readonly ) et permettant au mecanisme blue/green d'argo cd de fonctionner et facile à superviser.
+- Comprendre et Maitriser les ingress controlers, faire le deploiement le plus générique possible, maitriser les certificats et la chaine de service.
+
+- Trucs et astuces, quels sont les pratiques gagnantes et les points spécifiques à connaitre au quotidien.
+
+ Validation des acquis par :
+ - QCM
+ - Capacité d'appel à la communauté d'échange de pratiques
+
+- L’agilité et le devops, mettre en place un flux.
+- Comprendre et maitriser la sécurité by design et les services sasts / dasts
+- Mettre en place un processus qualité logiciel, les tests, la sécurité et le processus de feed-back au développeur "Shift-Left"
+- Comprendre le Sec de DevSecOps avec les services sast et dast ainsi que le scan regulier des images.
+- Contribuer a l’homologation d’un projet en intégrant le socle de sécurité cloud pi native
+- Comprendre l'homologation, les exigences non-fonctionnelles liées à la sécurité
+- Se former, mettre en place une discipline, identifier les ressources de formation disponible et gratuite.
+
+ Validation des acquis par :
+ - Travaux pratiques : vérifier la conformité, augmenter la qualité et la sécurité d’un logiciel, shift-left. ( utilisation de co-pilote )
+ - Travaux pratiques : Automatisation des tests
+ - Travaux pratiques : démarrer une démarche d’homologation
+ - (Avancé) Travaux pratique : déployer la Chaînes primaire,
+ - (Avancé) : déployer la chaîne secondaire la console et déployer une application.
+
+- Maîtriser le repository github, comprendre les exigences du CCT cloud pi native
+
+ Validation des acquis par :
+ - QCM
+
+**Module « contributeur à l’offre »**
+
+- Maîtriser le repository github
+- Contribuer à l’offre, la communauté, la Roadmap.
+
+ Validation des acquis par :
+ - QCM
+ - Travaux pratique : faire un PR, contribution.
+
+**Module « Mettre en place et accompagner des équipes produits numériques intégrées »**
+
+- Maîtriser le repository github, Comprendre les exigences du CCT cloud pi native
+- Transmettre la connaissance minimale.
+- Coacher, mettre en place une organisation en charge de faire du tutoriat.
+- Maitriser l’organisationnel associé à un produit numérique, Conway, clean architecture, etc
+- Comprendre la topologie des équipes (teams topologies)
+- comprendre les interactions d'organisation et l'impact des couplages organisationnels et techniques.
+- Maitriser la soutenabilité de maintenance d’un produit numérique, les bonnes pratiques, les copilotes IA
+- Augmenter la qualité intraséques des logiciels,l'usager au centre
+- Les profils des developpeurs
+- Maitriser la conduite du changement, les neuroscience
+- Établir les plan de formation et accéder aux ressources libres et autres parcours de formation
+- Créer sa propre valise de formation.
+
+ Validation des acquis par :
+ - Évaluation : monter un plan de formation d’une équipe à partir des ressources accessibles.
+ - Évaluation : échange autour d’un cas d’usage réel (ou fictif) de coaching d’une équipe
+
+**Module animation de communautés internes**
+
+- Capacité à mobiliser les énergies au sein de sa communauté
+- Les challenges de faire vivre une communauté
+- Animer un débat autour des tendances
+- Contribuer à la réflexion de l'offre
+
+ Validation des acquis par :
+ - QCM
+ - Evaluation pratique : présentation d'un petit mémoire démontrant la compréhension des les enjeux, quelles sont les tendances IT, les grands sujet de fond pour permettre de produire un produit numérique de qualité, soutenable et qui répond aux besoins.
+
+
+
+
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/cloud-au-centre/sommaire.md b/content/fr/cloud-au-centre/sommaire.md
new file mode 100644
index 0000000..90fcb0a
--- /dev/null
+++ b/content/fr/cloud-au-centre/sommaire.md
@@ -0,0 +1,21 @@
+---
+title: Cloud PI Native
+layout: layouts/page.njk
+showBreadcrumb: true
+eleventyNavigation:
+ key: cloud pi native
+ parent: Cloud au centre
+ order: 1
+---
+
+## Objectif
+
+L'objectif est d'accélérer la transformation numérique au bénéfice des usagers et dans le strict respect de la cybersécurité et de la protection des données des citoyens et des entreprises.
+
+ L'offre interministérielle Cloud π Native, offre les services d'une plateforme DevSecOps complète afin de suivre le cycle de vie complet de son projet.
+
+:::callout Tester vos connaissances
+ Venez vous [certifier](../certification/) 😉🧊
+:::
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/contact/index.md b/content/fr/contact/index.md
index ea085ba..146ab72 100644
--- a/content/fr/contact/index.md
+++ b/content/fr/contact/index.md
@@ -7,5 +7,4 @@ eleventyNavigation:
order: 2
---
# Contact
-
-
+
diff --git a/content/fr/donnees-api/donnees-et-api-analyser-et-valoriser-les-donnees.md b/content/fr/donnees-api/donnees-et-api-analyser-et-valoriser-les-donnees.md
new file mode 100644
index 0000000..e2a1269
--- /dev/null
+++ b/content/fr/donnees-api/donnees-et-api-analyser-et-valoriser-les-donnees.md
@@ -0,0 +1,18 @@
+---
+title: données et api
+layout: layouts/page.njk
+showBreadcrumb: true
+---
+
+# Analyser et valoriser les données
+
+## Principe recherché
+
+La maîtrise de la donnée, de la science de la donnée et de l’intelligence artificielle est identifiée par le Gouvernement comme un enjeu stratégique.
+
+Toute application qui sera amenée à alimenter une plateforme technique de valorisation de données, devra intégrer:
+
+- **des extracteurs de données** - permettant de sortir les données opérationnelles de l'application pour les intégrer au sein de la plateforme technique.
+- des mécanismes d'**anonymisation des données**, avant d'alimenter la plateforme technique de valorisation des données, dans le respect des exigences réglementaires et normatives
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/donnees-api/donnees-et-api-cycle-de-vie.md b/content/fr/donnees-api/donnees-et-api-cycle-de-vie.md
new file mode 100644
index 0000000..f92a496
--- /dev/null
+++ b/content/fr/donnees-api/donnees-et-api-cycle-de-vie.md
@@ -0,0 +1,44 @@
+---
+title: données et api
+layout: layouts/page.njk
+showBreadcrumb: true
+---
+
+# Cycle de vie de la donnée et archivage
+
+## Principe recherché
+
+Modalité d’archivage par nature de donnée
+
+La donnée au sens large (document, donnée structurée ou non) a un cycle de vie, représentée par une température.
+
+- "chaude" lorsqu'elle est utilisée quasi-quotidiennement par son service producteur et ses consommateurs. Durant cette phase, elle doit être pleinement disponible, dans les respects de la sécurité Si et de la protection des données personnelles.
+- "tiède" à la fin de son usage public mais qu'elle reste à disposition du service producteur
+- "froide" lorsque la donnée n'est plus utilisée qu'à des fins historiques scientifiques ou statistiques.
+
+Selon le [code du patrimoine article L 211-1](https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006074236&idArticle=LEGIARTI000006845559&dateTexte=&categorieLien=cid) la définition de l’archivage est le suivant : 'Les archives sont l'ensemble des documents, y compris les données, quels que soient leur date, leur lieu de conservation, leur forme et leur support, produits ou reçus par toute personne physique ou morale et par tout service ou organisme public ou privé dans l'exercice de leur activité'.
+
+Toutes les données sont considérées comme des archives dès leur création.
+
+## Impact sur les applications
+
+L'application doit prendre en compte dans sa conception le cycle de vie de la donnée. C'est à dire les trois phases de l'archivage : courant, intermédiaire et définitif.
+
+1. L'application détient exploite utilise des données chaudes, ou archives **courantes** dans la langue des archivistes.
+2. Les données "tièdes" doivent être versées à un système prenant en charge les archives **intermédiaires**. Le ministère est doté d'un système d'archivage intermédiaire et il convient de s'assurer que le versement pourra être mis en place avec un minimum d'effort (respect des interfaces).
+3. La dernière phase concerne l'archivage **définitif** - ou la destruction, le scénario est sous la responsabilité du responsable des archives ministérielles - Les archives définitives sont externalisées
+
+## Règles et recommandations
+
+{% from "components/component.njk" import component with context %}
+{{ component("table", {
+ title: "Critères retenus pour la sélection des logiciels, outils ou services",
+ headers: ["Ref", "Statut","Intitulé"],
+ data: [
+ ["-","RG", "Toute application doit prévoir dans sa conception le versement des données aux archives intermédiaires du ministère, selon la nature des données. Ce versement doit être conçu dans le respect de l'interface SEDA (https://francearchives.gouv.fr/seda/documentation/SEDA_description_standard_v2_1.pdf)."],
+ ["1129", "RG","Lorsqu'une application comporte des données actives et des données historiques, elles doivent être stockées dans des bases ou des fichiers différents."]
+ ]
+}) }}
+
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/donnees-api/donnees-et-api-donnees-et-services.md b/content/fr/donnees-api/donnees-et-api-donnees-et-services.md
new file mode 100644
index 0000000..2148a4a
--- /dev/null
+++ b/content/fr/donnees-api/donnees-et-api-donnees-et-services.md
@@ -0,0 +1,114 @@
+---
+title: données et api
+layout: layouts/page.njk
+showBreadcrumb: true
+---
+
+# Concevoir une application orientée données et services
+
+## Les données
+
+**Les données** sont un patrimoine de l'État. Leur portée et leur importance peuvent déborder du traitement de l'application qui va les exploiter. Il est donc important, dès la conception d'un nouveau traitement ou d'une nouvelle application, de formaliser une réponse structurée, aux interrogations suivantes :
+
+| Sujet |Quelle question doit on se poser ? |
+|-------|------------------------------------|
+| [Réutilisation](#Réutilisation) (consommation de données déjà existantes) | les données que doit manipuler mon application existent-elles déjà ailleurs et ai je envisagé une réutilisation ? |
+| [Exposition](#Exposition) des données|l'application est elle pensée pour faciliter la réutilisation des données qu'elle crée ou transforme ?|
+| [Exposition de traitements](#Traitements)|Au-delà d'une exposition brute de données, les **traitements** sur les données peuvent être exposés. Sont-ils exposés en vue d'une réutilisation possible ?|
+
+## Les services
+
+Réutiliser des données, exposer des données, exposer des traitements : ces actions sont des **services**. Ceux-ci sont « exposés » aux travers d'interfaces, ou API (Application Programming Interface). L'API est un service WEB qui utilise le protocole http(s) et un style d'architecture REST ou REST full.
+
+Le type d'interface dont il sera question dans la suite de la fiche sera ce type d'API HTTP/REST.
+
+La [Stratégie d’API](../../strategie-api/sommaire.md) du CCT décrit la démarche dans toute sa dimension : architecture, design, sécurité et gouvernance.
+
+### Réutilisation
+
+**Rappel de la question initiale :** les données que doit manipuler mon application existent-elles déjà ailleurs ? Ai-je envisagé leur réutilisation ?
+
+Le traitement de cette question nécessite de croiser les données métier manipulées par l'application avec les données réutilisables, au niveau ministériel comme interministériel.
+
+Il peut s'agir :
+
+- de données de référence, souvent qualifiés de "communs", exposés sur des dispositifs de type MDM (Master Data Management) - Il peut s'agir du GDR (Gestion de Données de Référence) de la DTNUM, ou les données de référence exposées par le SIR du ST(SI)² pour la sécurité intérieure ;
+- de données exposées dans le SI de l'État, dans le cadre État Plateforme et de FranceConnect Plateforme. Exemple : l'API Entreprise ;
+- de données exposées par d'autres applications ;
+- de données ouvertes.
+
+Deux types de vérifications sont à réaliser pour chaque donnée manipulée :
+1. existence de la donnée au sein du ministère de l’Intérieur;
+2. réutilisation de la donnée dans le contexte de l’application
+
+**Existence de la donnée au sein du ministère de l’Intérieur**
+
+Plusieurs sources de données sont disponibles au sein du ministère de l’Intérieur :
+- les données ouvertes de l’État dans [data.gouv.fr](https://www.data.gouv.fr/fr/)
+- le référentiel patrimonial des applications du Ministère de l’intérieur, [CANEL](https://canel-consultation.sso.minint.fr)
+- le catalogue des données du ministère de l'intérieur : [catalogue.data.minint.fr](http://catalogue.data.minint.fr)
+- les catalogues d’API (la majorité des API exposent des données plus que des traitements) : [**api.minint.fr** pour l'accès aux données en interne](http://api.minint.fr/) pour le ministère et [api.gouv.fr](http://api.gouv.fr/) pour l'État.
+
+
+**Réutilisation de la donnée dans le contexte de l’application**
+
+En cas de réutilisation, il est nécessaire de s’assurer que :
+- sa sémantique soit compatible,
+- sa qualité soit satisfaisante,
+- la qualité de service de l'exposition soit compatible avec les exigences de l’application,
+- les performances soient suffisantes,
+- qu'une solution de repli ait été prévue en cas d'interruption de service, le cas échéant qu'un contrat de service ait été établi avec le fournisseur.
+
+### Exposition des données
+
+**Rappel de la question initiale :** l'application contribue t elle à la réutilisation des données qu'elle crée ou transforme ?
+
+Une application peut produire des données métier qui peuvent contribuer à la réutilisation de données, au-delà du contexte de l'application. Conformément à l'approche État Plate-forme avec ses API données, il est obligatoire de prévoir une exposition de ces données pour une ré-utilisation éventuelle.
+
+Modalités d'exposition : une exposition par API, quand elle ne participe pas à un inter-ou intra-applicatif planifié, doit utiliser les services d'une plateforme d'échange et sa brique de gestion d'API (API Management) pour intégrer un certain nombre de services tels que :
+
+- la gestion de la performance (il est possible de limiter les appels par acteurs - throttling, quotas)
+- le contrôle d'accès s'il est nécessaire
+- la contractualisation avec l’offre de service [MonComptePro](https://moncomptepro.beta.gouv.fr/) de la DINUM
+- la traçabilité et l'accounting
+- de la conversion (API SOAP en API REST par exemple)
+
+Une donnée de référence est définie par les propriétés suivantes :
+- utilisation fréquente par un grand nombre d'utilisateurs, internes et externes
+- qualité critique pour un grand nombre de processus
+- sémantique partagée et relativement stable dans le temps
+- durée de vie qui va au-delà des processus opérationnels qui les utilisent
+- facilité d'accès à ces données est critique
+
+Si la donnée entre dans cette catégorie des données de référence, il est nécessaire de la traiter comme telle, et d'utiliser un système d'exposition dédié : GDR ou SIR.
+
+### Exposition de traitements
+
+**Rappel de la question initiale :** Au-delà d'une exposition brute de données, les **traitements** sur les données peuvent être exposés ? Sont-ils exposés en vue d'une réutilisation possible ?
+
+L’exposition public d’un traitement via une API REST-Full est requise pour tout partage inter-applicatif.
+
+Ces API doivent être exposés dans une passerelle d’API (INES, SIR) et décrite au travers d’un catalogue. Le catalogage interne MI se fait sur [](http://api.minint.fr) , le catalogage sur internet se fait sur
+
+## Règles et recommandations
+
+Pour information, il existe des règles pertinentes dans le périmètre des référentiels de données dans le [Cadre Commun d'Architecture des Référentiels de données.](../7-Annexes/Cadre-Commun-d-Architecture-des-Referentiels-de-donnees.pdf)
+
+Le référentiel "stratégie d'API" est lui même un recueil de règles et de recommandations (ou bonnes pratiques) : [Stratégie d'API - Règles et recommandations](../../strategie-api/sommaire)
+
+{% from "components/component.njk" import component with context %}
+{{ component("table", {
+ title: "Règles et recommandations",
+ headers: ["Ref", "Statut","Intitulé"],
+ data: [
+ ["1445","RG","Pour toute donnée, les conditions d'une possible réutilisation doivent être envisagées. Réutilisation en mode différé sous forme de publication de jeu de données ouvertes, et exposition au fil de l'eau sous forme d'API."],
+ ["1446","RG","Toute nouvelle API susceptible d'être réutilisée, doit être cataloguée et documentée sur le catalogue api du ministère (api.minint.fr) si son usage est strictement restreint au ministère, sinon sur celui de l'état (api.gouv.fr)."],
+ ["1447","rc","Toute nouvelle API susceptible d'être réutilisée devrait être exposée via l'une des plateformes d'API Management du ministère."],
+ ["1448","RG","En cas de consommation d'API externe, l'intermédiation d'une plateforme d'échange doit être privilégiée."],
+ ["1360","RG","Il est obligatoire de réutiliser les données existantes"],
+ ["1100","RG","Les composants fonctionnels manifestement communs à plusieurs applications doivent être développés sous forme de services réutilisables."]
+ ]
+}) }}
+
+{% include "components/back_to_top.njk" %}
+
\ No newline at end of file
diff --git a/content/fr/donnees-api/donnees-et-api-donnees-personnelles.md b/content/fr/donnees-api/donnees-et-api-donnees-personnelles.md
new file mode 100644
index 0000000..08706a7
--- /dev/null
+++ b/content/fr/donnees-api/donnees-et-api-donnees-personnelles.md
@@ -0,0 +1,83 @@
+---
+title: données et api
+layout: layouts/page.njk
+showBreadcrumb: true
+---
+# Gestion des données personnelles
+
+
+## Contexte
+
+Les dispositions de l’article 4 du RGPD précisent : «données à caractère personnel», toute information se rapportant à une personne physique identifiée ou identifiable (ci-après dénommée «personne concernée») ; est réputée être une «personne physique identifiable» une personne physique qui peut être identifiée, directement ou indirectement, notamment par référence à un identifiant, tel qu'un nom, un numéro d'identification, des données de localisation, un identifiant en ligne, ou à un ou plusieurs éléments spécifiques propres à son identité physique, physiologique, génétique, psychique, économique, culturelle ou sociale. Au vu de cette définition, la majorité des applications du ministère de l’intérieur traitent des données personnelles.
+La protection des données personnelles relève de plusieurs cadres juridiques :
+- Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016, relatif à la protection des personnes physiques à l'égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général sur la protection des données);
+- Loi n° 78-17 du 6 janvier 1978 relative à l'informatique, aux fichiers et aux libertés;
+- Directive (UE) 2016/680 du Parlement européen et du Conseil du 27 avril 2016 relative à la protection des personnes physiques à l'égard du traitement des données à caractère personnel par les autorités compétentes à des fins de prévention et de détection des infractions pénales, d'enquêtes et de poursuites en la matière ou d'exécution de sanctions pénales, et à la libre circulation de ces données, et abrogeant la décision-cadre 2008/977/JAI du Conseil;
+- La sûreté de l'État et le renseignement.
+
+
+### Le RGPD
+
+Le règlement européen renforce de façon significative les droits de l'usager sur ses données personnelles, notamment :
+- Droit d'accès aux données, de rectification
+- Selon les circonstances : droit à l'effacement, opposition
+- Pour certains traitements (et très rare au MI) : portabilité des données
+
+
+[Politique de conformité des données personnelles du ministère de l'intérieur (PCDP-MI)](http://sg.minint.fr/images/RGPD/PCDP_MI_V1_03062019.pdf)
+
+Les dispositions du RGPD ne parlent pas d’« application informatique » *stricto sensu* mais plutôt de « **traitement** » . Un traitement selon les dispositions de l’article 4 du RGPD constitue « *toute opération ou tout ensemble d'opérations effectuées ou non à l'aide de procédés automatisés et appliquées à des données ou des ensembles de données à caractère personnel, telles que la collecte, l'enregistrement, l'organisation, la structuration, la conservation, l'adaptation ou la modification, l'extraction, la consultation, l'utilisation, la communication par transmission, la diffusion ou toute autre forme de mise à disposition, le rapprochement ou l'interconnexion, la limitation, l'effacement ou la destruction* ». Il s’agit donc d’une définition très large qui désigne toute action sur les données personnelles. Un traitement peut être automatisé (une ou plusieurs applications) ou non (par exemple l'utilisation de la messagerie électronique pour envoyer un mail). Le RGPD s’applique donc à tout traitement, ainsi qu’à tous les fichiers (dont un simple tableau Excel), même papier.
+
+Selon le RGPD, tout traitement doit avoir un **responsable de traitement** : dans la pratique celui qui détermine la finalité et les moyens du traitement, tel qu’un préfet d'un département, ou le directeur d'une administration centrale.
+
+Règle : Chaque responsable de traitement a l'obligation de maintenir un *registre* des traitements dont il a l’initiative (ce qui exclut les traitements nationaux dont il n’est qu’utilisateur). Ce registre pourra être audité par la CNIL, et également, en tant que document administratif, communiqué sur demande citoyenne après occultation des mentions relatives à la sécurité (Cf annexe 2 de la note du DPD).
+
+Lorsqu'un traitement est susceptible "d'engendrer un risque élevé pour les droits et les libertés des personnes physiques" (art 35 du RGPD), **le responsable du traitement doit faire mener une analyse d'impact du traitement sur la protection des données à caractère personnel**.
+
+**Remarque :** l'analyse d'impact est souvent nommée PIA, Privacy Impact Assesment ou encore Étude d'Impacts sur la Vie Privée. (Cf annexe 3 de la note du DPD). Elle doit comporter l’avis du délégué ministériel à la protection des données avant sa validation par le responsable du traitement. L’analyse permet de vérifier la conformité juridique du traitement, d’évaluer les risques, et de mettre en place les mesures de sécurité appropriées. Si une homologation SSI est menée, il est recommandé de la coupler à l’analyse d’impact RGPD : les deux vont recenser les mêmes risques (notamment SSI), et elles différeront sur le périmètre des enjeux : impact sur les droits et libertés pour la PIA, impact sur le ministère pour l’homologation SSI.
+
+### La loi 78-17 Informatique et libertés
+L’entrée en vigueur du RGPD a entraîné l’abrogation de certaines dispositions de cette loi. Toutefois, certaines autres dispositions restent en vigueur afin de préciser les marges de manœuvre nationales du RGPD.
+
+Ainsi, le chapitre II de la loi fixe les conditions de licéité des traitements de données à caractère personnel ; le chapitre III contient les dispositions relatives à la Commission nationale de l'informatique et des libertés (CNIL).
+
+
+## Impacts pour l'application
+
+La protection des données à caractère personnel, que celle-ci relève du RGPD ou de la loi n° 78-17 du 6 janvier 1978 (périmètre sécurité publique et infractions pénales) a un **impact important pour l'application** dans l'ensemble de son cycle de vie (conception, exploitation, décommissionnement). Ainsi que le spécifie le RGPD dans l'article 25, la protection des données doit être prise en compte **dès la conception, et par défaut** (*privacy by design*, *privacy by default*).
+
+Le guide méthodologique de la CNIL « Analyse d'impact relative à la protection des données / La méthode», la démarche de mise en conformité s'appuie sur deux piliers :
+- les **principes et droits fondamentaux**, sont réglementaires, et de facto obligatoires sans condition. On peut citer parmi les droits fondamentaux, l'information des personnes concernées, l'exercice des droits selon les situations (d'accès, de rectification, d'effacement, de limitation du traitement ....)
+- la **gestion des risques sur les droits et libertés des personnes**, qui permet de déterminer les mesures techniques appropriées.
+
+La mise en conformité nécessite la mise en place d'un ensemble de mesures, d'ordre fonctionnel, organisationnel, ou de mise en place de processus et techniques Ces dernières relèvent du présent cadre de cohérence technique.
+
+Les relations avec les sous-traitants qui traitent des données personnelles pour le compte du ministère sont également impactées (nouveaux devoirs du sous-traitant). Le cadre juridique impose de :
+- mettre en conformité avec l’article 28 du RGPD l’ensemble des contrats de sous-traitance;
+- sécuriser les données ; à ce titre, la mise en place d’un dispositif de journalisation participe à cette sécurisation. La CNIL a émis une recommandation en 2021 en ce sens (cf. délibération n° 2021-122 du 14 octobre 2021 portant adoption d'une recommandation relative à la journalisation.
+- pour tous les traitements : mettre en place du concept de limitation du traitement des données (marquage de certaines données pour empêcher leur utilisation, sans toutefois les effacer).
+
+La CNIL a édité un catalogue des mesures de mise en conformité (Analyse d'impact relative à la protection des données / Les bases de connaissance). Le tableau ci-dessous synthétise dans ce catalogue les mesures techniques relevant du CCT.
+
+{% from "components/component.njk" import component with context %}
+{{ component("table", {
+ title: "Mesures de protection des données",
+ headers: ["Extrait du guide CNIL", "Mesures techniqes"],
+ data: [
+
+ ["2 - Anonymisation","Identifier les données pertinentes et supprimer les données inutiles, sur les données. Sur les éléments d’identification directe ou à valeur rare, anonymiser selon la technique adéquate : randomisation ou généralisation."],
+ ["3 - Archivage","La protection des données à caractère personnelle a des impacts sur la politique d’archivage. Cf fiche cycle de vie de la donnée. (offre de service Maarch RM, VITAM, chiffrement des données)"],
+ ["4 - Chiffrement","Le référentiel de composant du CCT préconise des composants de chiffrement, comme les composants PRIM’S"],
+ ["8 - Contrôle des accès logiques","Cf Fiches identification et authentification de l’agent et de l’usager"],
+ ["11 - Exercice des droits de l’usager","Ces nouveaux droits de l’usager induisent principalement des mesures organisationnelles.Du point de vue technique, la mise en œuvre des droits de l’usager nécessite un bon niveau d’authentification de celui-ci. \_Cette fonction pourrait être utilement mutualisée par un téléservice au niveau ministériel (ou au-delà)."],
+ ["19 - Gestion des postes de travail","La protection des données à caractère personnelles implique le poste de travail. Cf fiche ETNA"]
+ ]
+}) }}
+
+
+
+**Remarque** : Le CCT préconise d’utiliser les mesures proposées par la CNIL comme un guide, dans le respect du contexte de l’application et du Ministère de l’Intérieur
+
+Le guide CNIL « [Analyse d'impact relative à la protection des données](https://www.cnil.fr/fr/RGPD-analyse-impact-protection-des-donnees-aipd) » dans son volet base de connaissance est un catalogue des mesures destinées respecter les exigences légales du RGPD et à traiter les risques.
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/donnees-api/gestion-des-echanges.md b/content/fr/donnees-api/gestion-des-echanges.md
new file mode 100644
index 0000000..2fb172a
--- /dev/null
+++ b/content/fr/donnees-api/gestion-des-echanges.md
@@ -0,0 +1,94 @@
+---
+title: données et api
+layout: layouts/page.njk
+showBreadcrumb: true
+---
+
+# Gestion des échanges
+
+
+## Principe recherché
+
+Les applications s'intègrent dans un écosystème ministériel, voire interministériel (SI de l'État), voire au-delà (SI collectivités, partenaires, usagers ..) avec lesquels elles échangent des données. Celles-ci peuvent être des données externes qu'elles consomment, ou des données internes qu'elles exposent (à la consommation des autres applications).
+
+### Interfaces d'échange -- ou API
+
+Dans la stratégie de l'État plateforme, qui s'aligne en cela sur des pratiques généralisée dans l'Internet, les données sont échangées selon le profil recommandé P1 « Fondations État Plateforme » défini dans le [Réglement Général d'Interopérabilité (RGI)](https://references.modernisation.gouv.fr/sites/default/files/Referentiel_General_Interoperabilite_V2.pdf) qui préconise des interfaces API basées sur le protocole https, le style d'architecture REST, le format de données JSON, et le protocole d'authentification OpenID Connect. Un certain nombre de bonnes pratiques ont été définies pour ces échanges, notamment au niveau ministériel avec la stratégie API qui définit le niveau sémantique des API REST.
+
+L’usage d’interface sous forme webservices SOAP est proscrite pour toutes nouvelles ou évolutions majeures de l’application.
+
+Une tolérance, soumise sans condition à validation par le Comité d’architecture, existe pour d'autres modes d'échange :
+
+- échanges par fichier -- Encore très répandus, notamment pour les données ouvertes.
+- CFT, RMI/JRMP, PeSIT
+
+### Les plateformes d'échange
+
+Le ministère structure ses échanges autour de deux plate-formes d'échange :
+- INES, opérée par la DTNUM
+- SIR (Système d'Interface et de Référence), opérée par le ST(SI)²
+
+Les autres DSI (PP, ANTS, ANTAI ...) ne se sont pas dotées de plateforme d'échange référencé par le Ministère de l’intérieur
+
+Par ailleurs, d'autres plateformes d’échange interministériel peuvent être utilisées, si les besoins de l’application ne peuvent être couverte par les plateformes d’échange du Ministère de l’intérieur :
+- La plateforme d’API Gateway/Management de l’AIFE : PISTE (https://piste.gouv.fr/).
+
+**Règle :**
+
+Indépendamment de la plateforme d’échange, qu’elle soit MI ou Interministériel, en cas d’exposition d’une API sur Internet, Il est recommandé d’utiliser la solution de contractualisation de la DINUM :MonComptePro ()
+
+Le composant majeur des plateformes d'échange est l'**API Gateway / API Management**. Celui-ci offre un certain nombre de fonctions essentielles telles que :
+
+- **Passerelle d'API** avec des fonctions d'exposition des services et des ressources, de sécurisation des flux, de régulation du trafic (seuils, quotas), de contrôle des identités et des droits (par jetons)
+- **Magasin d'API** avec des fonctions de publication, des API, de souscription aux API, de tableau de bord pour les développeurs -- Cette fonction est portée au ministère par un autre composant :
+- **Editeur d'API** avec des fonctions de gouvernance (cycles de vie, versioning) , facturation, monitoring, autorisation
+- **ESB (Enterprise Service Bus)**. Ces bus de services sont capables de prendre en charge des transformations ainsi que des agrégations de flux dans des contextes d'échanges inter-applicatifs.
+- **SAS fichier**
+
+### Fonctions d'intermédiation des plateformes d'échange.
+
+La plateforme d'échange et d’intermédiation est porté par la plateforme. Elle offre un service d'intermédiation entre un consommateur et plusieurs fournisseurs.
+
+
+
+L'exemple ci-dessus montre un cas d'intermédiation avec la possibilité pour une application mobile du smartphone Néo qui équipe les forces de l'ordre d'interroger plusieurs fichiers de police en une seule demande sur une API fédérée.
+
+API Entreprise de la DINUM est un autre exemple d'intermédiation et de service à valeur ajoutée en ce qu'elle agrège des informations de l'INSEE (Sirene) et d'Infogreffe.
+
+|INES - DTNUM|SIR - ST(SI)²|
+|------------|-------------|
+|La plateforme INES met en œuvre 3 composants : - API management (tel que décrit ci-dessus) - ESB (Bus de service) qui permet de transformer ou d’agréger des flux. - SAS fichier La plateforme INES est appelée à prendre en charge tous les flux d’API internes au applications hébergées par la DTNUM. La plateforme INES mutualise le raccordement au RIE et à Internet. C’est elle qui permet de « consommer » des API externes, comme par exemple l’API entreprise, la BAN, l’API INSEE …etc. INES est raccordé au SIR et route les flux destinés aux applications de sécurité interieure hébergées au STIG |La plateforme SIR est basée sur un ESB (Bus de service) qui permet notamment d’assurer le routage, la sécurisation, et des agrégations de flux d’API. La plateforme SIR prend en charge les flux d’API sortant du périmètre du centre d’hébergement de la sécurité intérieure (STIG). Le SIR ne prend pas en charge les flux internes au STIG. SIR est raccordé à INES et route les flux destinés aux applications de hébergées dans le centre d’hébergement de la DTNUM. Le SIR route et agrège tous les flux API avec les équipements mobiles des forces de l’ordre, notamment les applications des smartphones Neo (interrogation de fichier ..etc). Cf schéma ci-dessus.|
+
+
+### Urbanisation des flux
+
+
+
+Les deux plateformes d'échanges sont dédiées aux deux principaux hébergements nationaux : INES pour l'hébergement DTNUM et SIR pour l'hébergement STIG de la sécurité intérieure.
+
+Règle : Les flux inter-applicatifs transitant entre les deux hébergements doivent être relayés (contrôlés, sécurisés ...) via INES et SIR.
+
+## Impacts sur les applications
+
+Tout échange entre application doit transiter au travers d’une plateforme d’échange.
+
+## Règles et recommandations
+
+| Ref | Statut | Intitulé |
+|------|--------|----------|
+|1449|rc|La consommation d'API interne devrait passer par une fonction d'API gateway pour avoir une bonne visibilité sur l'ensemble des flux de consommation.|
+|1450|RG|Les flux inter-applicatifs inter-centres d'hébergement transitent par INES et SIR.|
+|1451|RG|La plateforme INES est le point d'entrée pour les API interministérielles (API entreprise, API INSEE, BAN ...etc). Grâce à son API management, elle est garante du respect du contrat de service établi avec les fournisseurs extérieurs.|
+|1363|RG|Le format de présentation et d’échange d’une adresse postale doit respecter la norme AFNOR XPZ 10-011.|
+|1047|rc|Si l'échange entre deux applications nécessite une transformation des données, il est recommandé de s'appuyer sur les plateformes d’échange du ministère.|
+|1048|RG|Tous échanges asynchrones doivent être réalisés au travers d’une plateforme d’échange du ministère, ou interministériel.|
+|1065|RG|Tous les échanges par Web Service ou par API doivent être authentifiés. |
+|1072|RG|Tout fichier XML doit être accompagné de son schéma.|
+|1074|RG|Les formats PNG et JPEG doivent être utilisés pour échanger les informations graphiques et les images fixes.|
+|1075|RG|Les flux audiovisuels, doivent respecter les formats MPEG-2 ou MPEG-4.|
+|1076|RG|En complément du RGI, pour tous les échanges de documents bureautiques internes et externes, seuls les formats OpenDocument et PDF sont autorisés.|
+|1078|RG|Le format d’échange des fichiers géographiques retenu est le format ShapeFile.|
+|1120|RG|Tout échange d’informations avec un SI externe au ministère doit faire l’objet d’un traitement particulier par des serveurs proxy déployés au sein d’une DMZ (conformément aux recommandations de l’ANSSI) afin de vérifier l’innocuité et l’intégrité des flux ou des fichiers. Les infrastructures nationales existantes (ex : SIR, INES) doivent être systématiquement privilégiées.|
+|1165|RG|Les interconnexions avec des partenaires externes doivent être réalisées en priorité à l’aide de VPN IPSEC, selon les recommandations de configuration ANSSI. A défaut, l’usage du protocole TLS, basé sur l’authentification mutuelle par certificat, sera utilisé.|
+
+{% include "components/back_to_top.njk" %}
diff --git a/content/fr/donnees-api/introduction.md b/content/fr/donnees-api/introduction.md
new file mode 100644
index 0000000..5a79bec
--- /dev/null
+++ b/content/fr/donnees-api/introduction.md
@@ -0,0 +1,24 @@
+---
+title: services et données
+layout: layouts/page.njk
+showBreadcrumb: true
+eleventyNavigation:
+ key: services et données
+ parent: Données
+ order: 1
+---
+
+# Introduction
+
+Toute application offre des services et manipule des données, des concepts métier, qui jouent souvent un rôle plus large et plus durable que l'application elle-même. Toute application doit adresser, sans conditions, les 5 questions élémentaires suivantes :
+
+1. [**Concevoir une application orientée service et données**](../donnees-et-api-donnees-et-services) - couvert par plusieurs questions :
+ - **Réutilisation** Les données que doit manipuler mon application existent elles déjà ailleurs et ai je envisagé une réutilisation ?
+ - **Exposition des données** - L'application est elle pensée pour faciliter la réutilisation des données qu'elle crée ou transforme ?
+ - **Exposition des traitements** - Au delà d'une exposition brute de données, mes traitements sur les données eux mêmes peuvent être exposés ? Sont-ils exposés en vue d'une réutilisation possible ?
+1. [**Gestion des échanges**](../gestion-des-echanges) - Les échanges, internes comme externes, sont pris en charge par des dispositifs ministériels ou interministériels dédiés. Ont-ils été pris en compte ?
+2. [**Analyser et valoriser les données**](../donnees-et-api-analyser-et-valoriser-les-donnees) - Les données sont un patrimoine indépendamment des traitements qui leur sont appliqués. Elle doivent pouvoir être notamment croisées, analysées, anonymisées, parfois recyclées en données ouvertes. Toutes les mesures ont elles été prises pour faciliter cette valorisation ultérieure?
+3. [**Données personnelles**](../donnees-et-api-donnees-personnelles) - Le cadre juridique relatif au traitement des données personnelles a-t-il été bien pris en compte (cf. notamment RGPD) ?
+4. **Archivage** - Le cycle de vie complet des données manipulées par l'application a-t-il été pensé ?
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/ent/sommaire.md b/content/fr/ent/sommaire.md
new file mode 100644
index 0000000..cedfe86
--- /dev/null
+++ b/content/fr/ent/sommaire.md
@@ -0,0 +1,209 @@
+---
+title: Environnement Numérique de Travail
+layout: layouts/page.njk
+showBreadcrumb: true
+eleventyNavigation:
+ key: environnement numérique de travail
+ parent: Socle
+ order: 1
+---
+
+# L'environnement numérique de travail (ENT)
+
+## Définition de l’ENT
+L’Environnement Numérique de Travail (ENT) correspond à **l’ensemble des ressources, matériels, outils et services transverses mis à disposition des agents du Ministère de l’Intérieur et des Outre-Mer, leur permettant d’accéder aux informations, de créer ou modifier des fichiers, de communiquer, de collaborer sur des projets, en mobilité ou
+dans les locaux administratifs, dans un cadre sécurisé.**
+
+**L’ENT permet de faciliter les communications, la collaboration et les échanges quotidiens.**
+
+**L’ENT doit répondre aux normes de sécurité imposées par l’ANSSI.**
+
+Le remplacement des applications client-serveur vers des services en ligne engendre de plus fortes implications de sécurité et de confidentialité des données. Avec la doctrine « Cloud au centre », la sécurisation de l’ENT est en enjeu majeur. Le chiffrement des outils nomades de type Noemi, Ubiquity (GN), Hesperis, Call-MI et NEO revêt par
+conséquent un caractère obligatoire.
+
+Il convient également de rappeler et d’imposer à tous les Systèmes d’Information (SI) le respect des normes d’interopérabilité et de sécurité, et ce dès le début de la phase de développement (security by design). A ce titre, la maîtrise d’ouvrage de chaque SI est responsable de la compatibilité aux normes précitées pour les nouveaux SI comme pour les plus anciens qu’il conviendra de faire évoluer, pour garantir la sécurité des SI et
+permettre l’accès à l’ensemble des postes de travail, sans imposer la moindre adhérence à un logiciel, format, version, outil ou à un système d’exploitation.
+
+Les API permettant la communication entre logiciels devront être de type API Rest.
+
+Le développement des applications web devra obligatoirement intégrer le format "Responsive Web Design". L'UX Design devra également être associée aux projets applicatifs dès les premières phases du projet.
+L’accessibilité est un aspect clé de l’ENT car elle garantit que tous les utilisateurs, y compris les personnes en situation de handicap, puissent accéder à l’ensemble des fonctionnalités et services de l’ENT de manière équitable.
+
+Il conviendra de :
+- s’assurer de l’existence de fonctionnalités permettant d’ajuster la lisibilité des contenus à la convenance de l’utilisateur, par exemple en autorisant l’agrandissement des caractères, la présence d’alternatives textuelles aux médias (images, vidéos et podcasts), la bonne sonorisation des contenus par un formatage compatible avec les
+aides techniques employées par les agents (lecteurs d’écran et plages braille) ;
+- s’assurer que les fonctionnalités de publication de contenus permettent de publier des contenus accessibles ;
+- veiller à proposer des interfaces avec un contraste suffisant ;
+- rédiger les contenus dans un langage facile à lire et à comprendre ;
+- respecter le Référentiel Général d’Amélioration de l’Accessibilité (RGAA) pour les interfaces web et se conformer aux normes européennes EN 301 549, ou à défaut aux bonnes pratiques internationales, notamment le Référentiel de l’Accessibilité des Applications Mobiles (RAAM) pour les applications mobiles ;
+- fournir la preuve de l’accessibilité en réalisant ou faisant réaliser un audit d’accessibilité et en publiant le rapport avec l’objectif d’atteindre un score de conformité égal à 100 % des critères du RGAA ou de la norme équivalente pour les fonctionnalités auditées.
+
+
+
+## Périmètre de l'ENT
+
+Le périmètre de l’Environnement Numérique de Travail du Ministère de l’Intérieur et des Outre-Mer englobe les ordinateurs fixes et mobiles, sécurisés ou non, les smartphones et tablettes. Ces matériels, pour faire partie du périmètre de l’ENT, **doivent avoir été configurés ou masterisés à l’aide des images disques ou masters** créés
+et déployés par la DTNUM ou par les services SIC locaux.
+
+### Environnements bureautiques fixes
+Les ordinateurs fixes ou portables, dits de bureau, et destinés à être **connectés uniquement sur le réseau du MIOM et du Réseau Interministériel de l’État (RIE)** seront configurés exclusivement avec les outils de la DTNUM, en respectant les versions préconisées et maintenues des systèmes d’exploitation et des logiciels.
+
+### Environnements bureautiques nomades
+Les ordinateurs portables nomades sécurisés et chiffrés de type **Noemi ou Ubiquity (Gendarmerie Nationale), munis d’un VPN (réseau privé virtuel, tunnel sécurisant l’accès au réseau du MIOM depuis un réseau privé personnel)** seront déployés selon les règles définies par la DTNUM ou le STSI². Le site rassemble toutes les informations nécessaires (les prérequis, les documentations d’installations, les actualités) pour les techniciens support, mais offre également à tous les utilisateurs des réponses aux interrogations, des documentations, une assistance de type FAQ et fixe les restrictions d’usage.
+
+### Environnements d'administration de services
+Les ordinateurs portables sécurisés destinés à l’utilisation du SPAN doivent être configurés selon les règles définies par la DTNUM. **Le SPAN est préconisé pour permettre l’administration à distance de serveurs** par des personnels qualifiés et ne sera déployé que pour cet usage particulier. Le site http://span.dsic.minint.fr/ rassemble les informations nécessaires à son déploiement et au support associé.
+
+### Environnements Passerelles Internet
+Les ordinateurs fixes ou portables communément appelés **« PC ADSL » ou « PC Internet »**, s’ils sont destinés à être **utilisés par le biais de Fournisseurs d’Accès Internet (FAI), ne doivent en aucun cas être exposés alternativement sur internet depuis les FAI et connectés sur le réseau du MIOM**. Ces machines seront configurées indépendamment de toute restriction par les directions qui les utiliseront, à l’exception de l’installation de l’antivirus officiel du MIOM version autonome, disponible sur le [site de téléchargement de la DTNUM](http://telechargement.dnum.minint.fr).
+
+
+### Environnements de developpement et d'administration technique
+Les ordinateurs **dédiés aux développeurs et administrateurs techniques seront configurés sous Linux** et seront préparés et maintenus par la DTNUM ou les services SIC locaux. Un dépôt sera créé à la DTNUM et celui ci sera le seul dépôt autorisé (en complément du dépôt géré par la GN pour leurs besoins propres). La mise en place de ce service sera effective dans le courant de l’année 2023.
+
+### Appareils mobiles
+Les smartphones et tablettes (Hesperis uniquement) déployés et maintenus par la DTNUM ou par les services SIC locaux permettent l’accès au service Hesperis, CallMI et NEO.
+
+Ils permettent de bénéficier :
+- d’une messagerie professionnelle, avec agenda et gestion des contacts
+- de la téléphonie (appels, SMS, MMS),
+- d’un accès internet via Orion,
+- d’un accès intranet,
+- d’un accès aux applications mobiles publiques et métiers validées par le C2MI.
+
+Ils ne permettent pas :
+- l’utilisation des réseaux sociaux comme Facebook, Twitter, instagram…
+- d’utiliser des messageries instantanées (Whatsapp, Télégram).
+- de se servir de son téléphone comme point d’accès mobile.
+
+Rappel : l’utilisation du terminal CallMI est **destinée à un usage Diffusion Restreinte exclusivement (la voix, les sms et la Data sont sécurisés)**. En conséquence ce terminal n’est pas la solution à utiliser pour se tenir informé des dernières nouvelles ou autres activités de même nature.
+
+Important : Toute demande de mise à disposition d’une **nouvelle application sur les smartphones et tablettes** devra nécessairement **passer par le Responsable de la Sécurité des Systèmes d’Information (RSSI)** du demandeur qui, une fois la requête analysée et filtrée, adressera la demande de validation au Service du Haut Fonctionnaire de Défense (SHFD), et plus précisément au **Centre de Cyberdéfense du Ministère de l’intérieur (C2MI)**, qui statuera et autorisera ou non le déploiement.
+
+
+### Systèmes d'exploitation autorisés
+Seuls les systèmes d’exploitation **Windows et Linux (versions supportées et correctement sécurisées)** sont autorisés sur le réseau du MIOM et du RIE. Tout autre système d’exploitation sera nécessairement connecté hors réseau. **Android** est le seul système d’exploitation autorisé (version supportée et correctement sécurisée) **sur les smartphones et tablettes** configurés par la DTNUM ou les services SIC locaux.
+
+### Sécurité des postes de travail et des serveurs
+Tout poste de travail ou serveur (Windows ou Linux) doit être équipé des antivirus qualifiés par le ministère à jour de sa base antivirale.
+Rien ne doit entraver le fonctionnement et la mise à jour de l'anti-virus et/ou de l'anti-espiogiciels et/ou du pare-feu.
+
+### Sécurité des supports de stockage
+Le passage à la station blanche de tous les supports amovibles est indispensable lors des transferts de fichiers. La mise en place d’un système d’authentification des supports amovibles au travers de l’antivirus est fortement recommandé.
+
+### Sécurité reseaux
+Une fiche pratique SSI relative à la sécurisation de l’accès internet par réseau ADSL (ou fibre) est établie par le SHFD. Celle ci est disponible en annexe réglementaire, il conviendra de s’assurer de la conformité de l’installation et de l’utilisation des PC ADSL ou Internet aux dispositions développées, notamment à la mise en place d’un portail d’authentification de type « Alcasar ».
+
+
+**Tous ces outils sont supportés par la DTNUM et peuvent faire l’objet d’une demande d’assistance uniquement s’ils ont été configurés et déployés par les services SIC locaux dépendant de la Direction de la Transformation Numérique.**
+**Il convient de respecter les préconisations établies dans ce document pour l'ensemble de l’ENT dépendant du périmètre du MIOM et des Directions Départementales Interministérielles sous responsabilité numérique du MIOM.**
+
+## Les produits de l'ENT
+
+### Matèriel
+On considère que les produits matériels qui composent l’Environnement Numérique de Travail sont distingués en 4 parties :
+- Les PC sécurisés, fixes ou portables : Solutions Noémi, SPAN, Ubiquity (GN) et Gendbuntu (GN)
+- Les PC dits ADSL ou Internet : Machines exclusivement dédiées et connectées sur Internet
+- Les ordinateurs pour les développeurs et administrateurs techniques : Machines disposant de composants particuliers dédiés aux développeurs et administrateurs techniques
+- Smartphones et tablettes sécurisées : Solutions Hesperis, Call-MI et Neo
+ - Modèles qualifiés Hesperis 2 disponibles sur le site intranet dédié : Ne sont autorisés que les téléphones de marque SAMSUNG, qui comportent une couche de sécurité optimisée avec le module KNOX et sont dotés d’un client adapté à nos usages Samsung Mail, le tout sur une version android supportée.
+ - Modèles qualifiés Call-MI (solution DR) disponibles sur le site intranet dédié : Ne sont autorisés que les téléphones de marque SAMSUNG, qui comportent une couche de sécurité optimisée avec le module KNOX et sont dotés d’un client adapté à nos usages Samsung Mail, le tout sur une version android supportée.
+ - Modèles qualifiés NEO pour les forces de sécurité intérieure
+
+### Logiciels / Services de l'Environnement numérique de Travail
+
+#### Contexte réglementaire :
+
+Le présent document s’appuie sur les textes référencés ci-après définissant la stratégie de l’État au niveau des systèmes d’information.
+Ainsi les critères de sélection des outils/services reprennent ces priorisations pour définir ceux dont l’usage sera autorisé au sein du ministère de l’Intérieur.
+- La loi 2016-1321 du 7 octobre 2016 (article 16) encourageant l’utilisation des logiciels libres et les formats ouverts ;
+- Le Référentiel Général d’Interopérabilité, RGI v1 - ordonnance n° 2005-1516 du 8 décembre 2005, RGI v2 - arrêté en date du 20 avril 2016 ;
+- Le Référentiel Général de l’Amélioration de l’Accessibilité, arrêté du 20 septembre 2019 ;
+- La circulaire Ayrault du 19 septembre 2012 relative aux orientations pour l’usage des logiciels libres dans l’Administration ;
+- La circulaire n° 6282-SG du 5 juillet 2021 relative à la doctrine d’utilisation de l’informatique en nuage par l’État ;
+- Le guide d’hygiène informatique de l’Agence Nationale de Sécurité des Systèmes d’Information,
+- La Politique de Sécurité des Systèmes d’Information du Ministère de l’Intérieur et des Outre-Mer.
+- La note de la Dinum sur la non conformité de Microsoft Office 365 à la doctrine « Cloud au centre ».
+- La fiche pratique SSI du Service du Haut Fonctionnaire de Défense relative à la sécurisation de l’accès internet par réseau ADSL (ou fibre).
+
+{% from "components/component.njk" import component with context %}
+{{ component("table", {
+ title: "Critères retenus pour la sélection des logiciels, outils ou services",
+ headers: ["Critères", "Attentes"],
+ data: [
+ ["Type de logiciel – Libre / Gratuiciel / Payant ", "Ré-utilisabilité, scalabilité, flexibilité, sécurité (transparence du code source), évolutivité (mutualisation possible des améliorations), pérennité, interopérabilité (usage des formats ouverts), limite d’usage si gratuiciel et coût à prévoir si logiciel payant."],
+ ["Existence d’un support correctif O/N", "Garantie d'assistance continue, mises à jour régulières aux fins d'amélioration de fonctionnalités et de corrections de bugs, permettant ainsi une stabilité d’usage sur le long terme. Un logiciel non supporté n’a plus vocation à être utilisé sur les postes du MIOM du fait de la non couverture de ses failles de sécurité."],
+ ["Outil utilisé en Interministériel O/N", "Facilité d’usage entre les systèmes utilisés dans d'autres administrations, possibilité de mutualisation en termes de support et de maintenance, partage des bonnes pratiques."],
+ ["Version LTS ou ESR disponible O/N"," Stabilité, disponibilité et maintien des correctifs sur le long terme, mises à jour de sécurité."],
+ ["Version SSI validée O/N","Logiciels évalués et validés par l’ANSSI. Certification de conformité aux normes de sécurité."],
+ ["Outil multi plateforme Windows/Linux/Android/Mac","Economie, compatibilité matérielle, simplification d’appropriation de l’usage et continuité de travail dans un même outil."],
+ ["Limitation d’usage dans le contexte ministériel", "Définition de l’usage exclusif fixé pour le logiciel sur l’Environnement Numérique de Travail du MIOM."],
+ ["Niveau d'accessibilité actuel (Pris en charge/Partiellement pris en charge/Non pris en charge)","Définition du niveau d'accessibilité du logiciel ou service, afin de valoriser les outils potentiellement adaptés aux agents porteurs de handicaps."],
+ ["Conformité aux normes et standards O/N", "Interopérabilité, meilleure expérience utilisateur (fiabilité des restitutions), non adhérence applicative, conformité réglementaire."],
+ ["Licence open source reconnue par OSI (Open Source Initiative - organisation dévouée à la promotion des logiciels open source)" , "Transparence et confiance, les logiciels reconnus sont évalués pour leur conformité,leur flexibilité de modification et de distribution du code source, leur coopération communautaire et leur stabilité."],
+ ["Type de licence si logiciel propriétaire (libératoire/par poste/par agent/sur volume)", "Vise à limiter l’impact financier et en termes de gestion desdites licences, afin de faciliter la scalabilité de l’usage du logiciel et son coût à la cible."],
+ ["Porteur de logiciel ou service", "Détenteur de la solution (mono-acteur, taille, origine, ….) permettant de s’assurer de la pérennité de la solution dans la durée et couverture possible du risque."],
+ ["Droit soumis à une licence UE O/N", "Conformité réglementaire stricte en matière de protection des données, équité et transparence, garantie de la protection intellectuelle, soumis au droit européen."],
+ ["Taille indicative du paquet","Taille du fichier à mettre en dépôt sur la plateforme de téléchargement. Information donnée à titre indicatif, à prendre toutefois en compte pour un large déploiement sur les systèmes d’information du MIOM."]
+
+ ]
+}) }}
+
+**_A noter :_**
+Certains logiciels pourront être retenus malgré la « non conformité » à un ou plusieurs critères sur raison particulière et justifiée, sans toutefois être en opposition avec la Politique de Sécurité des Systèmes d’Information du MIOM et les principes de base pré-cités. La situation pourra ainsi être réévaluée au regard des nouvelles solutions qui pourraient voir le jour et apporteraient la couverture fonctionnelle attendue tout en répondant aux critères.
+
+Tous les logiciels du poste de travail seront mis à disposition sur le site de téléchargement http://telechargement.dnum.minint.fr, à raison de 3 versions au maximum. Les logiciels installés sur l’ENT ne seront téléchargeables que depuis les plateformes officielles du MIOM (site http://telechargement.dnum.minint.fr ou à terme un outil de gestion centralisé, ou un dépôt Linux DTNUM ou GN)
+
+Tout logiciel ne bénéficiant plus de mise à jour sera remplacé par une autre solution logicielle remplissant le même usage ; le support de la solution doit être assuré par la communauté ou l'éditeur.
+
+
+**Usages :**
+La couverture fonctionnelle de la solution (logiciel ou service) sera par définition totale ou partielle, en fonction des besoins exprimés par les services demandeurs.
+La solution retenue devra néanmoins couvrir le spectre le plus large possible de l’usage qui lui est associé.
+Le choix des logiciels, outils et services sera basé sur les usages et les bonnes pratiques.
+L’objectif est de parvenir à proposer un seul outil/logiciel pour un usage.
+L’usage final non couvert par l’offre, correctement défini par le service demandeur, permettra de proposer de nouvelles solutions au CCT, par le biais d’un [**formulaire d’expression de besoin (FEB)**](../7-Annexes/FEB_Nouvel_Outil_BENT.pdf) dûment renseigné.
+
+**Politique de versions des logiciels, outils ou services :**
+
+Est appliquée l’ensemble des mises à jour de sécurité (au fil de l’eau), sauf en cas d’impact sur le fonctionnel du logiciel. Dans ce cas une analyse d’impact est pratiquée, au regard du risque couvert et une décision est prise concernant l’installation du dit correctif ou son ajournement.
+
+Pour les logiciels majeurs du poste de travail des agents du ministère (navigateur, suite bureautique,..) le cycle de mises à jour prévisionnel est de 6 mois (avril et octobre).
+
+S’appuyant sur la feuille de route du produit à déployer lorsque cette dernière est connue (une variation de quelques semaines peut être nécessaire, le temps de valider la version et selon la présence ou non de correctif suite à la découverte de problèmes dans la version proposée au téléchargement).
+
+Pour les autres logiciels du poste de travail, une montée de version annuelle est prévue (avril ou octobre) sur la base des avancées fonctionnelles notables.
+
+Les logiciels du poste de travail sont testés par un panel de testeurs sur les domaines AC, AT, ATE et PN durant 2 semaines avant mise en production.
+
+**Déploiement des logiciels :**
+
+Le poste de travail de type ordinateur de bureau, chiffré ou non, et destiné à être connecté au réseau du MIOM est fourni à l’agent avec un bouquet logiciel de base.
+
+Les sections support locales chargées du déploiement et de l’installation auprès des agents installeront les outils complémentaires nécessaires à l’agent en fonction de son périmètre d’activité et de ses besoins.
+
+Pour les machines dont le système d’exploitation est de type Microsoft Windows, les services locaux ont à leur disposition sur l’Active Directory, un groupe WPP présent dans chaque OU (Unité d’Organisation) permettant aux machines intégrées à ce groupe WPP (pc_standards) d’obtenir automatiquement et systématiquement la dernière
+version du socle logiciel de base du poste de travail (navigateur, suite bureautique, lecteur PDF, lecteur multimédia, éditeur de texte, retouche d’image, navigateur de visioconférences et client de messagerie). Ce socle sera étendu autant que faire se peut avec des outils qui seront définis comme faisant partie du bouquet logiciel de base fourni à l’agent.
+
+La diffusion automatique des mises à jour du socle logiciel par WPP pourra être remplacée à l’avenir par un outil de gestion et de déploiement centralisé.
+
+A terme, l’agent pourra par lui-même piocher dans un magasin d’application les outils disponibles et les installer sans génération de ticket de support ni besoin de compte administrateur.
+
+Les logiciels ou applications pour les smartphones sont disponibles depuis le magasin accessible depuis chaque terminal ; leurs mises à jour est automatique ou manuel, paramétrable par chaque utilisateur (documentation disponibles sur les sites https://hesperis2.dnum.minint.fr et http://call-mi.dsic.minint.fr)
+
+
+#### Logiciels, outils et services retenus
+
+Se référer au chapitre dédié dans le [référentiel des produits](../../referentiel-des-produits/cct_pro.md)
+
+La [feuille de route sur les produits de l'ENT](../7-Annexes/Feuille_de_route_des_produits_de_l_ENT_2023.pdf) est disponible au travers de ce lien.
+
+Les usages les plus représentatifs de l’ENT sont distingués comme suit :
+
+
+
+## Documents annexés
+
+Les regles présentés dans cette [annexe complètent le document.](../7-Annexes/annexe_ENTA_regles.md)
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/guide-architecture/referentiel-produits.md b/content/fr/guide-architecture/referentiel-produits.md
new file mode 100644
index 0000000..167e238
--- /dev/null
+++ b/content/fr/guide-architecture/referentiel-produits.md
@@ -0,0 +1,9 @@
+---
+title: referentiel des produits
+layout: layouts/page.njk
+showBreadcrumb: true
+---
+
+
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/guide-architecture/sommaire.md b/content/fr/guide-architecture/sommaire.md
new file mode 100644
index 0000000..4a09d84
--- /dev/null
+++ b/content/fr/guide-architecture/sommaire.md
@@ -0,0 +1,13 @@
+---
+title: Guide d'architecture
+layout: layouts/page.njk
+showBreadcrumb: true
+eleventyNavigation:
+ key: guide d'architecture
+ parent: Socle
+ order: 2
+---
+
+
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/guide-securite/sommaire.md b/content/fr/guide-securite/sommaire.md
new file mode 100644
index 0000000..3479d6d
--- /dev/null
+++ b/content/fr/guide-securite/sommaire.md
@@ -0,0 +1,13 @@
+---
+title: Guide de la sécurité
+layout: layouts/page.njk
+showBreadcrumb: true
+eleventyNavigation:
+ key: guide de la sécurité
+ parent: Socle
+ order: 3
+---
+
+
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/index.11tydata.js b/content/fr/index.11tydata.js
index 9c29a00..45d1a99 100644
--- a/content/fr/index.11tydata.js
+++ b/content/fr/index.11tydata.js
@@ -1,5 +1,9 @@
module.exports = {
- pTitle: "Lorem ipsum",
+ pTitle: "Cadre de cohérence technique (CCT)",
pDescription: `
-Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec id mi est. Pellentesque ac eros ipsum. Nunc sed ligula a justo vehicula eleifend. Curabitur ut nibh id sapien ullamcorper ornare at sit amet leo. Ut suscipit, erat eget malesuada feugiat, justo leo maximus ipsum, in consectetur neque turpis non mauris. Pellentesque porttitor ut elit eu posuere. Duis vel posuere lacus, nec pellentesque nunc. Vivamus rutrum eros ac nisl sollicitudin, vitae egestas diam interdum. Vivamus a quam eleifend, maximus massa sed, interdum lectus. In placerat porttitor malesuada. Vestibulum at maximus felis, quis eleifend felis. Nullam id tortor sem. Donec eleifend pharetra justo vel ultricies. Cras lobortis, erat non tempus porta, ligula velit laoreet ligula, ac sagittis metus enim vel nisi.`
+ À travers sa doctrine Cloud au centre , l’État encourage l’ensemble des acteurs publics à se saisir de son potentiel afin de développer une nouvelle génération de services numériques de qualité, tout en protégeant au mieux les données des entreprises et des citoyens français.
+
+
+ Dans le but de disposer un SI adapté et agile, le MIOM a posé un ensemble de normes techniques et des recommandations de nature, formalisés dans un document de Cadre de Cohérence Technique (CCT), pour le développement de nouvelles applications compatibles avec ces normes et hébergées sur son infrastructure, et de services de qualité qui répondent aux besoins des métiers et déployables rapidement et à coûts réduits.
+ `
};
\ No newline at end of file
diff --git a/content/fr/index.njk b/content/fr/index.njk
index a584d7d..512c11b 100644
--- a/content/fr/index.njk
+++ b/content/fr/index.njk
@@ -9,16 +9,14 @@ eleventyNavigation:
-
Un exemple de site institutionnel
+
Un exemple de site pour le cadre de cohérence technique du ministère de l'intérieur
diff --git a/content/fr/menu-cloud.md b/content/fr/menu-cloud.md
new file mode 100644
index 0000000..5e3b16e
--- /dev/null
+++ b/content/fr/menu-cloud.md
@@ -0,0 +1,6 @@
+---
+eleventyNavigation:
+ key: Cloud au centre
+ order: 4
+permalink: false
+---
\ No newline at end of file
diff --git a/content/fr/menu-donnees.md b/content/fr/menu-donnees.md
new file mode 100644
index 0000000..2fba17f
--- /dev/null
+++ b/content/fr/menu-donnees.md
@@ -0,0 +1,6 @@
+---
+eleventyNavigation:
+ key: Données
+ order: 3
+permalink: false
+---
\ No newline at end of file
diff --git a/content/fr/menu-socle.md b/content/fr/menu-socle.md
new file mode 100644
index 0000000..c664629
--- /dev/null
+++ b/content/fr/menu-socle.md
@@ -0,0 +1,6 @@
+---
+eleventyNavigation:
+ key: Socle
+ order: 2
+permalink: false
+---
\ No newline at end of file
diff --git a/content/fr/strategie-api/cover.jpg b/content/fr/strategie-api/cover.jpg
new file mode 100644
index 0000000..ec25e79
Binary files /dev/null and b/content/fr/strategie-api/cover.jpg differ
diff --git a/content/fr/strategie-api/introduction.md b/content/fr/strategie-api/introduction.md
new file mode 100644
index 0000000..5b92fc4
--- /dev/null
+++ b/content/fr/strategie-api/introduction.md
@@ -0,0 +1,35 @@
+---
+title: Doctrine API
+layout: layouts/page.njk
+showBreadcrumb: true
+---
+
+## Introduction
+
+Sous l’impulsion de la Stratégie État Plateforme lancée par la DINUM, de la loi pour une République Numérique et de la [loi 3DS](https://www.economie.gouv.fr/daj/lettre-de-la-daj-application-de-la-loi-3ds-echange-de-donnees-entre-administrations), les systèmes d’information des ministères sont amenés à s’ouvrir. De même, la notion de plateforme incite à la mise en commun de données et de services de l’État dans un objectif de construction d’un écosystème d’acteurs publics ou privés. Ces derniers pourront alors les assembler pour construire ou rénover les services à destination des usagers de l’Administration.
+
+La construction de cet État Plateforme repose sur l’utilisation d’interfaces de programmation applicative appelées API (Application Programming Interface). Cette technologie s’appuie sur des standards largement éprouvés par les géants du Web tels que Google, Amazon ou encore Twitter. Une telle plateforme permet la collaboration au sein de l’écosystème, mais également l’expérimentation de nouveaux services publics numériques dans des délais et des coûts réduits.
+
+Ce document se veut un cadre pour la conception et la réalisation d’API. Celui-ci sera enrichi et adapté au rythme de la construction de l’État Plateforme et des retours des utilisateurs. Cette version pose les bases nécessaires aux premières réalisations. Elle n’a pas la prétention d’être exhaustive ni dans les réponses apportées, ni dans les sujets abordés.
+
+## Les API
+
+Pour remplir cette promesse, les API mises en place dans le cadre de l’État Plateforme doivent pouvoir être assemblées et interopérer. Le respect des standards est un élément essentiel mais pas suffisant pour atteindre cet objectif. En effet, ils focalisent sur les aspects techniques sans explicitement adresser les besoins fonctionnels et métiers. Ce sont pourtant ces derniers qui donnent un sens à l’utilisation ou à la création d’une API.
+
+C’est pour ces raisons qu’il est essentiel, en complément du respect des standards, de définir une stratégie claire des API répondant aux enjeux métiers. Pour cela, on s’attachera, lors de la conception d’une API, aux aspect fonctionnels et métiers des services fournis :
+
+- format de la donnée facilitant son utilisation quelques soient les contextes
+- sollicitation au fil de l’eau (intégration dans les processus des partenaires)
+- adaptation des traitements en fonction des contextes des partenaires (plage d’ouverture, pics saisonniers …)
+- contrôle des données transmises adaptées aux cadres légaux et aux besoins des partenaires
+- …
+
+## Choix technologiques
+
+La stratégie État Plateforme met en avant certains standards qui sont également utilisés dans les différentes API construites par des acteurs publics et disponibles sur [http://api.gouv.fr](http://api.gouv.fr/) :
+
+- l’architecture REST et [API RESTful](https://restfulapi.net/) pour l’appel et l’utilisation des API
+- [la spécification OpenAPI](https://github.com/OAI/OpenAPI-Specification) et [le framework swagger](http://swagger.io/) pour la documentation des API
+- [le format JSON](http://www.json.org/) pour la structuration des données
+
+## [Retour au sommaire](../sommaire)
diff --git a/content/fr/strategie-api/principes.md b/content/fr/strategie-api/principes.md
new file mode 100644
index 0000000..0c644bf
--- /dev/null
+++ b/content/fr/strategie-api/principes.md
@@ -0,0 +1,99 @@
+---
+title: Doctrine API
+layout: layouts/page.njk
+showBreadcrumb: true
+---
+
+Chaque principe exposé ici est décliné en un ensemble de règles [consultables](../regles). Ces principes visent à mettre en place un cadre partagé permettant d’inscrire l’ensemble des projets dans une dynamique API first.
+
+## Principe n°1 : une API doit exposer des services métiers et non des composants techniques
+
+Un service métier repose sur l’utilisation d’une ou plusieurs ressources du système d’information. Ces dernières peuvent être de deux types :
+
+- donnée : le service retourne de l’information à celui qui l’appelle;
+- traitement : le service déclenche l’exécution d’un processus dans le SI. En fonction du contexte, le résultat peut être :
+- l’état du processus : pris en compte, accepté, en cours, finalisé, rejeté …
+- le résultat du traitement qui peut se matérialisé par :
+- un élément physique : permis de conduire, acte d’état civil …
+- un élément numérique
+
+Le délai de retour n’est pas le même entre les ressources de type donnée et celles de type traitement. Les premières retournent l’information quasi instantanément alors que les secondes peuvent nécessiter plusieurs jours voire semaines.
+
+Dans tous les cas, les ressources exposées doivent être documentées en prenant le point de vue fonctionnel du service :
+
+- quel usage puis-je faire de cette API ?
+- comment l’utiliser ?
+- quelles sont les conditions d’utilisation ?
+- inclure des exemples pour accompagner la compréhension.
+
+De même, l’API doit respecter un certain nombre de règles dans sa définition :
+
+- disposer d’une interface bien définie conforme aux règles de nommage
+- fournir des données structurées et adaptées au métier faisant abstraction des ressources techniques sous-jacentes
+- maîtriser les différentes versions disponibles en garantissant, par exemple, une compatibilité ascendante (cf. [**principe 3**](./index.html#pr3))
+
+Afin de s’assurer du respect de ce premier principe, l’approche " [Eat your own dog food](https://en.wikipedia.org/wiki/Eating_your_own_dog_food) " est un bon moyen pour :
+
+- détecter les bugs;
+- les corriger rapidement;
+- améliorer l’utilisabilité de l’API;
+- réaliser les premiers tests de charge;
+- vérifier la bonne application des règles de sécurité. [OWASP](https://owasp.org/www-project-api-security/) décrit ici le top 10 des règles de sécurité d'une API.
+
+Enfin, mettre en place une stratégie « API first ». L’objectif est d’analyse le positionnement du projet dans l’écosystème d’API (du MI, de l’État Plateforme et/ou de partenaires). Cette phase doit permettre d’identifier, dès le lancement, les API disponibles utiles au projet et celles qui pourraient venir compléter l’écosystème.
+
+## Principe n°2 : veiller au découplage des API
+
+Le respect de cette règle se traduit par la conception de services qui ne portent qu’une responsabilité et n’assurent qu’une seule fonction. Il convient de viser l’excellence du service rendu plutôt qu’une large couverture fonctionnelle. Pour cela, le service doit être idempotent et ne pas conserver de contexte des différents appels qu’il reçoit.
+
+L’application de cette règle permet de construire un catalogue d’API modulaires et maintenables en limitant les dépendances et la redondance entre les différentes ressources exposées. Une politique de gestion des versions (cf. [**principe 3**](./index.html#pr3)) assure également cette pérennité et cette maîtrise des évolutions.
+
+Ainsi, une API expose un service qui réalise une fonction métier unique, claire avec des périmètres bien définis. Ce service peut être un traitement ou la fourniture de données et le résultat retourné est indépendant du nombre de fois où l’API est appelée.
+
+## Principe n°3 : les versions d’une API suivent la politique de gestion de versions de la DTNUM
+
+En respect les **principes [1](./index.html#pr1) et [2](./index.html#pr2)**, une API doit maintenir une certaine indépendance avec les systèmes techniques. Pour cette raison, les versions d’une API sont en lien avec des évolutions fonctionnelles ou techniques qui lui sont propres et ne reflètent en rien les évolutions du SI. Le respect de ce principe est facilité par un travail de conception basé sur les besoins métiers et une volonté de réutilisabilité maximale.
+
+Pour des raisons de gestion, le nombre de versions différentes actives en même temps ne peut être infini. Toute nouvelle version doit supporter, autant que faire se peut, les fonctionnalités de la version précédente (on parle de compatibilité ascendante). La mise en place d’une nouvelle version ou la disparition d’une ancienne version doit s’accompagner d’un délai raisonnable permettant aux utilisateurs de prendre en compte ses évolutions.
+
+Une politique de gestion de versions permet de :
+
+- maintenir une adéquation entre besoins métiers et API exposées;
+- garantir la pérennité des API;
+- accompagner les utilisateurs dans les évolutions
+
+## Principe n°4 : sélectionner les API à exposer
+
+Seuls les services répondant à des besoins métiers avérés ont vocation à être exposés, partagés. Le catalogue des API est le reflet des activités du ministère. Il doit donc être construit de manière réfléchie indépendamment des contingences techniques.
+
+L’exposition d’API cohérentes et complémentaires permet :
+
+- un couplage faible entre les API;
+- d’éviter la redondance au niveau des API disponibles;
+- maîtriser les interactions et limiter le risque d’enchaînement en cascade d’appels d’API
+
+## Principe n°5 : mettre en place des éléments de mesure, de supervision et de contrôle
+
+L’exposition d’API implique d’être en capacité de mesurer, contrôler et superviser la fourniture de ces services. Pour cela, un ensemble de métriques techniques et métiers doivent être définis et mis en œuvre par chaque API pour :
+
+- vérifier le respect des engagements (conventions);
+- détection d’usage frauduleux;
+- prendre des mesures de régulation en cas de non respect des engagements;
+- limitation ou coupure de l’accès à l’API;
+- mesurer les performances du service [*Service Level Objectives*](https://fr.wikipedia.org/wiki/SLO);
+- mesurer le niveau du service [*Service Level Agreement*](https://fr.wikipedia.org/wiki/Service-level_agreement);
+- détecter les défaillances;
+- identifier un besoin d’évolution et en mesurer l’efficacité
+
+## Principe n°6 : une API expose de la donnée et des traitements
+
+Bien que dans un premier temps, les API soient principalement utilisées pour l’exposition de données, il ne faut pas les cantonner à ce cas d’usage. En effet, les API peuvent être utilisées pour déclencher des traitements nécessitant des délais de réalisation longs. Dans ces cas de figure, il est nécessaire de mettre en place des mécanismes adaptés à ces temps de traitement longs.
+
+Ces mécanismes doivent permettre à l’émetteur de l’appel à l’API de recevoir le résultat dans un échange différent de son appel. Ils mettent en œuvre les principes de :
+
+- callback : l’utilisateur indique à l’API la localisation du système par lequel le résultat doit lui être transmis. Il s’agit généralement d’une API dédiée à la réception des retours.
+- corrélation : l’utilisateur et le fournisseur de l’API s’entendent sur un identifiant unique permettant de corréler le résultat transmis à un précédent appel.
+
+En complément, des mécanismes de suivi de l’avancement de la réalisation des traitements et de reprise en cas d’incident doivent être mis en place pour informer les utilisateurs de l’API.
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/strategie-api/regles.md b/content/fr/strategie-api/regles.md
new file mode 100644
index 0000000..e5f5ff5
--- /dev/null
+++ b/content/fr/strategie-api/regles.md
@@ -0,0 +1,545 @@
+---
+title: Doctrine API
+layout: layouts/page.njk
+showBreadcrumb: true
+---
+
+Les règles définies dans cette partie se veulent une déclinaison opérationnelle des principes définis précédemment. Ces différentes règles ont été mises à jour en reprenant pour partie le guide API publié par le [Government Digital Service (GDS)](https://www.gov.uk/guidance/gds-api-technical-and-data-standards) anglais, ainsi que certains éléments référencés dans le [guide de design d'API d'Octo](https://blog.octo.com/designer-une-api-rest/).
+
+## Principe n°1 : une API doit exposer des services métiers et non des composants techniques
+
+### Règle 1.1
+
+Une API a pour vocation de mettre à disposition des données aux plus grand nombre de partenaires légitimes à en faire usage. Le contrôle et le filtrage de l’accès à une API doit donc être adapté à cet objectif de diffusion.
+
+L’utilisation d’adresses IP fixes et/ou d’authentification mutuelle par certificats limite fortement la multiplication des utilisateurs. Ces mécanismes sont donc à réserver dans les contextes pour lesquels ils sont indispensables.
+
+### Règle 1.2
+
+Une API expose des données qui ont une pertinence métier en dehors du périmètre de l’application qui les héberge.
+
+Une API ne doit pas être utilisée pour les besoins d’intégration d’applications, mais pour délivrer un service qui est indépendant des cas d’usage dans lesquels il est appelé.
+
+### Règle 1.3
+
+Une API prend en compte dès la conception sa capacité à passer à l’échelle sur l’ensemble des composants contribuant à son fonctionnement. Cela concerne les infrastructures réseau, l’API management, mais également les serveurs de base de données ou applicatifs traitant la demande transmise via API. Cette règle vise à maintenir dans le temps les niveaux de qualité de service et d’engagement lorsque la demande augmente.
+
+## Principe n°2 : développer des API modulaires
+
+### Règle 2.1
+
+L’exposition des données se fait indépendamment des contraintes techniques de l’application (format de données, technologie …) en prenant en compte la pertinence métier.
+
+Une API ne doit pas exposer le modèle de données d’une application sauf à ce que ce dernier soit identique aux objets métiers (ce qui est rarement le cas).
+
+### Règle 2.2
+
+JSON (JavaScript Object Notation) doit être privilégié pour la manipulation de données (envoi ou réception) au travers d'une API.
+
+L’utilisation d’une autre représentation doit être exceptionnelle et limitée à certains cas tels que :
+
+- l’obligation de se connecter à un système hérité, par exemple, un système qui utilise uniquement XML
+- pouvoir bénéficier d’avantages significatifs en respectant des standards largement adoptés dans l’organisation (par exemple, SAML)
+
+En dehors de ces exceptions, nous recommandons de :
+
+- créer des réponses en tant qu’objet JSON et non en tant que tableau (les objets JSON peuvent contenir des tableaux JSON). En effet, les tableaux peuvent limiter la possibilité d’inclure des métadonnées sur les résultats et limiter la capacité de l’API à ajouter des clés de niveau supérieur supplémentaires à l’avenir
+- documenter votre objet JSON pour s’assurer qu’il est bien décrit et pour qu’il ne soit pas traité comme un tableau séquentiel. Chaque information est directement accessible sans avoir à parcourir une structure de données.
+- éviter les clés d’objet non déterministes telles que celles dérivées des données, car cela peut amener des conflits avec les utilisateurs de l’API
+- utiliser une grammaire cohérente pour les clés des objets. Préférer les notations utilisant les types de style *spin-case*, *snake_case*, ou *CamelCase* en vaillant surtout à être cohérent.
+
+#### Règle 2.2.1
+
+Le format [GeoJSON](http://geojson.org/) doit être prévilégié dans le cadre d'échange d'information de localisation géographique.
+Ce format est référencé dans [Référentiel Général Interopérabilité (RGI V2)](http://references.modernisation.gouv.fr/sites/default/files/Referentiel_General_Interoperabilite_V2.pdf).
+
+#### Règle 2.2.2
+
+La norme [Unicode Transformation Format (UTF-8)](https://fr.wikipedia.org/wiki/UTF-8) est à adopter lors du codage de texte ou d'autres représentations textuelles de données.
+Cette norme d'encodage est référencée dans [Référentiel Général Interopérabilité (RGI V2)](http://references.modernisation.gouv.fr/sites/default/files/Referentiel_General_Interoperabilite_V2.pdf).
+
+#### Règle 2.2.3
+
+La représentation du format d'une date ou d'une date et d'une heure doit respecter la norme [ISO 8601 standard](https://fr.wikipedia.org/wiki/ISO_8601) ainsi le traitement en sera internationalement facilité
+
+Ainsi nous pourrions avoir pour une date `2017-08-09` et pour une date et heure `2017-08-09T13:58:07Z`.
+
+### Règle 2.3
+
+Configurez les API pour qu’elles répondent aux « demandes » de données plutôt qu’à « envoyer » ou « pousser » des données. Cela garantit que l’utilisateur de l’API ne reçoit que les informations dont il a besoin.
+
+Lors de la réponse, votre API doit répondre à la demande de manière complète et spécifique. Par exemple, une API doit répondre à la demande « Cet utilisateur est-il marié? » avec un booléen. La réponse ne doit pas renvoyer plus de détails que nécessaire et doit s’appuyer sur l’application cliente pour l’interpréter correctement.
+
+Par exemple :
+
+```json
+{ "married": "true" }
+```
+
+Au lieu de :
+
+```json
+{
+
+"person": {
+"name": "Alice Betterland",
+"dob": "1999-01-01",
+"married": false,
+
+"validFrom":"2011-04-03",
+
+"validTo":""
+}
+
+}
+```
+
+### Règle 2.4
+
+Concevez les champs de données en tenant compte des besoins des utilisateurs. Lors de la conception de vos champs de données, vous devez considérer comment les champs répondront aux besoins des utilisateurs. Avoir un architecte API dans votre équipe peut vous aider à le faire. Vous pouvez également tester régulièrement votre documentation auprès de vos utilisateurs.
+
+Par exemple, si vous avez besoin de recevoir des informations personnelles, avant de décider de la structure de la réponse, vous devrez peut-être déterminer si :
+
+- la conception peut accepter des informations d’identité provenant de région où il n’y a pas de nom ni de prénom
+- l’abréviation DdN a du sens ou s’il est préférable d’utiliser le terme `date de naissance`
+- DdN a du sens lorsqu’il est combiné avec DdDC (date du décès)
+
+Vous devez également vous assurer de fournir toutes les options pertinentes. Par exemple, le champ « civilStatus » contient probablement plus de 2 états que vous souhaitez enregistrer : `marié`, `non marié`, `divorcé`, `veuf`, `séparé`, `annulé`, etc.
+
+Selon ce que vous décidez, vous pouvez choisir la structure de données suivante comme réponse :
+
+```json
+{
+"person": {
+"firstName": "Alice",
+"lastName": "Wonderland",
+"dob": "1999-01-01",
+"civilStatus": "marié",
+
+"validFrom":"2010-03-12",
+
+"validTo":"2011-04-03"
+},
+
+"person": {
+"firstName": "Alice",
+"lastName": "Betterland"
+"dob": "1999-01-01",
+"civilStatus": "divorcé",
+
+"validFrom":"2011-04-03",
+
+"validTo":""
+}
+
+}
+```
+
+### Règle 2.5
+
+Il convient d’être au plus proche des normes et standards utilisés dans l’industrie. Pour cette raison il est fortement recommandé de créer des API RESTful, qui utilisent des requêtes de verbe HTTP pour manipuler les données.
+
+Ainsi,lors du traitement des demandes, vous devez utiliser les verbes HTTP aux fins spécifiées. L’un des avantages de REST est qu’il offre également un cadre pour la communication des états d’erreur.
+
+De manière plus spécifique, une API RESTful doit respecter les directives suivantes :
+
+- stateless : en ce sens il n’associe pas de contexte à un appel
+- utilisation des verbes HTTP :
+ - POST pour la création
+ - GET pour la consultation/lecture
+ - PUT pour la mise à jour
+ - DELETE pour la suppression
+- utilisation des codes retour HTTP suivants :
+
+
+
+| Code | Message | Description |
+| --- | --- | --- |
+| 102 | Processing | Traitement en cours (évite que le client dépasse le temps d’attente limite). |
+| 200 | OK | Code de retour par défaut en cas de succès |
+| 201 | Created | Code retour en cas de succès du traitement et de la création d’une nouvelle ressource |
+| 202 | Accepted | Indique que la requête a bien été prise en compte et sera traitée ultérieurement. Ce mode de fonctionnement est principalement utilisé dans le cas d’échanges asynchrones et nécessite la mise en place d’un mécanisme de Call Back côté client |
+| 204 | No Content | Indique que la requête a bien été traitée mais qu’il n’y a pas de résultat à retourner. C’est par exemple le cas lors d’action de suppression |
+| 206 | Partial Content | Indique qu'une partie de la ressource a été transmise. Utilisé en cas de pagination |
+| 304 | Not Modified | Document non modifié depuis la dernière requête. |
+| 400 | Bad Request | Code d’erreur générique en cas d’informations non valides fournies au service |
+| 401 | Unauthorized | Code utilisé par les services nécessitant une autorisation lorsque l’identification fournie n’est pas autorisée à utiliser le service |
+| 402 | Unprocessable entity | Code de retour générique lorsque la requête ne peut être traitée suite à des paramètres d’entrée non valides |
+| 404 | Not Found | Code d’erreur en cas d’URI d’entrée inexistante ou d'information non trouvée |
+| 405 | Method not Allowed | Code d’erreur en cas d’incompatibilité entre une URI et une méthode |
+| 406 | Not Acceptable | Code de retour lorsque les entêtes ne semblent pas compatibles avec le fonctionnement du service |
+| 409 | Conflict | La requête ne peut être traitée en l’état actuel. Ce code peut être utilisé afin d'indiquer une détection de doublon lors d'une création ou mise à jour par exemple
+| 429 | Too Many Requests | Code de retour lorsque le client émet trop de requêtes dans un délai donné |
+| 500 | Server Error | Code d’erreur par défaut |
+| 503 | Service Unavailable | Code de retour lorsque le service n’est pas disponible |
+
+### Règle 2.6
+
+Vous devez utiliser le protocole HTTPS lors de la création d’API. L’ajout de HTTPS sécurisera les connexions à votre API, préservera la confidentialité des utilisateurs, garantira l’intégrité des données et authentifiera le serveur fournissant l’API.
+
+Sécurisez les API à l’aide de Transport Layer Security (TLS) v1.2. N’utilisez pas Secure Sockets Layer (SSL) ou TLS v1.0. L’obtention de certificats peut être réalisée en utilisant les processus en vigueur dans les différentes organisations.
+
+Assurez-vous que les utilisateurs potentiels de l’API peuvent vérifier vos certificats. Assurez-vous de disposer d’un processus solide pour le renouvellement et la révocation des certificats en temps opportun.
+
+**Point à adresser**
+
+Votre API peut établir des liaisons avec d'autres données. Vous pouvez rendre votre API plus accessible par programme en renvoyant des URI et en utilisant les normes et spécifications existantes. Pour cela, utilisez des identificateurs de ressources uniformes (URI) pour identifier certaines données :
+
+
+```json
+{
+ "name": "Bob Person",
+ "company": "https://your.api/company/bobscompany";
+}
+
+```
+
+### Règle 2.7
+
+Lorsque vous fournissez une API Open Data, vous devez permettre aux utilisateurs de télécharger des ensembles de données entiers à moins qu’ils ne contiennent des informations sensibles. Cela offre aux utilisateurs :
+
+- la possibilité d’analyser le jeu de données localement
+- l’assistance lors de l’exécution d’une tâche nécessitant l’accès à l’ensemble des données (par exemple, tracer un graphique sur les zones de chalandise scolaire en Angleterre)
+
+Les utilisateurs doivent pouvoir indexer leur copie locale des données en utilisant la technologie de base de données de leur choix, puis effectuer une requête pour répondre à leurs besoins. Cela signifie que les futures indisponibilité de l’API ne les affecteront pas, car ils disposent déjà de toutes les données dont ils ont besoin.
+
+L’utilisation d’une requête API permettant la récupération enregistrement par enregistrement pour effectuer la même action ne serait pas optimale, à la fois pour l’utilisateur et pour l’API. Ceci est dû au fait :
+
+- des limites de débit qui ralentiraient l’accès, ou pourraient même empêcher le téléchargement complet de l’ensemble de données
+- si l’ensemble de données est mis à jour en même temps que le téléchargement enregistrement par enregistrement, les utilisateurs peuvent obtenir des enregistrements incohérents
+
+Si vous autorisez un utilisateur à télécharger un ensemble de données complet, vous devez envisager de lui fournir un moyen de le maintenir à jour. Par exemple, vous pouvez diffuser vos données en direct ou les informer que de nouvelles données sont disponibles afin que les consommateurs d’API puissent venir télécharger vos données périodiquement.
+
+### Règle 2.8
+
+N’encouragez pas les utilisateurs à mettre à jour de grands ensembles de données en les retéléchargeant, car cette approche est inutile et peu pratique. Au lieu de cela, laissez les utilisateurs télécharger des listes incrémentielles de modifications apportées à un ensemble de données. Cela leur permet de garder leur propre copie locale à jour et leur évite d’avoir à télécharger à nouveau l’ensemble de données à plusieurs reprises.
+
+Il n’existe pas de norme recommandée pour ce modèle. Les utilisateurs peuvent donc essayer différentes approches telles que:
+
+- l’encodage des données dans les flux [Atom / RSS](https://en.wikipedia.org/wiki/Atom)
+- en utilisant des modèles émergents, tels que les flux d’événements utilisés par des produits tels que [Apache Kafka](https://kafka.apache.org/)
+- utiliser des registres de données ouverts
+
+### Règle 2.9
+
+Lorsque vous publiez des données en masse, rendez ces données disponibles aux formats CSV et JSON. Cela garantit que les utilisateurs peuvent utiliser un large éventail d’outils, y compris des logiciels standard, pour importer et analyser ces données.
+
+Publiez des données en masse sur [data.gouv.fr](https://data.gouv.fr/) et assurez-vous qu’il existe un lien bien en vue vers votre API.
+
+### Règles 2.10
+
+Les noms de domaine des API doivent suivre les recommandations suivantes :
+
+- utiliser des noms plutôt que des verbes
+- être bref, simple et compréhensible
+- être intuitif pour un humain en évitant, si possible, les termes techniques ou spécialisés
+- utiliser des tirets plutôt que des underscores pour séparer les mots lorsque que le nom est composé de plusieurs mots. Par exemple `api-name.interieur.gouv.fr`
+
+### Règle 2.11
+
+Les noms de domaine utilisés dans la construction d’une API doivent se limiter à trois sous-domaines en production. L’objectif est de maintenir intuitive la compréhension de l’URL à utiliser pour respectivement :
+
+- utiliser l’API : `https://api.{nomressource}.interieur.gouv.fr`
+- récupérer un jeton d’authentification : `https://oauth2.{nomressource}.interieur.gouv.fr`
+- consulter la documentation de l’API : `https://developpeurs.{nomressource}.interieur.gouv.fr`
+
+Dans le cas, par exemple, d’interrogation du Système d’Immatriculation des véhicules on aurait :
+
+- `https://api.immatriculation.interieur.gouv.fr`
+- `https://oauth2.immatriculation.interieur.gouv.fr`
+- `https://developpeurs.immatriculation.interieur.gouv.fr`
+
+### Règle 2.12
+
+Eviter les espaces de nommage (namespaces) en privilégiant un nom de domaine par API tout comme pour les services numériques. Cela permet de mélanger les API et facilite la gestion des versions.
+
+### Règle 2.13
+
+Les ressources visées étant des collections ou une instance parmi une collection, il est donc préférables de toujours utiliser le pluriel pour ces collections.
+
+**Cette règle peut se traduire par** :
+
+- *retourne une collection de ressources (toutes les immatriculations)*
+ - **GET** `https://api-name/v1/immatriculations`
+- *retourne une ressource unique (les informations pour l’immatriculation fournie)*
+ - **GET** `https://api-name/v1/immatriculations/AB-123-XZ`
+
+### Règle 2.14
+
+L’objet de cette règle est donc de définir les conventions devant être respectées dans la construction des URI d’une API.
+
+Pour mémoire, le principe de fondateur des API RESTful est de manipuler des ressources identifiées au travers d’une URI (*Uniform Resource Identifier*). Afin de faciliter la réutilisation des API, il est donc important d’accéder de manière homogène aux URI utilisés dans les services.
+
+#### racine du service
+
+La racine de l’URI débute par l’URL (*Uniform Resource Locator*) de base du serveur web exposant l’API tel que défini par la Règle 2.3.
+
+#### version de l’API
+
+L’élément suivant indique le numéro de version de l’API. Celui-ci commence par v et est suivi d’un numéro.
+
+*En fonction de la politique de gestion des versions, le numéro de version pourra contenir des versions mineures en étant codé sur 2 digits.*
+
+#### classement
+
+Si la ressource visée est organisée suivant un classement permettant de différencier des ressources ayant le même nom, ce critère de classement figure après le numéro de version. Ce classement peut être une date, un département ou tout autre élément permettant de regrouper des ressources.
+
+*Si il existe plusieurs niveaux d’imbrication des classements, ceux-ci sont insérés dans l’URI en partant du grain le plus gros.
+Par exemple, une déclaration fiscale est organisée autour d’une année de déclaration, une préfecture autour d’un département.*
+
+Cette règle s’applique également aux ressources nécessitant d’autres ressources pour construire l’URI. C’est le cas notamment lorsqu’il y a une imbrication fonctionnelle entre des objets métiers. Nous pouvons prendre le cas des bibliothèques et des livres à titre d’illustration :
+
+- la liste de toutes les bibliothèques :
+ - **GET** `https://api-name/v1/bibliotheques`
+- la liste de tous les livres :
+ - **GET** `https://api-name/v1/livres`
+- la liste de tous les livres de la BNF :
+ - **GET** `https://api-name/v1/bibliotheques/bnf/livres`
+- la liste des bibliothèques où on peut trouver le livre « Dom Juan » :
+ - **GET** `https://api-name/v1/livres/domjuan/bibliotheques`
+
+#### nom de la ressource
+Enfin, le nom désignant la ressource manipulée au travers de l’API est le dernier élément de la chaîne constituant l’URI.
+
+#### paramètres de la requête
+L'utilisation des paramètres de la requête permettent la pagination, le filtrage, le tri sur les données d'une ressource.
+
+##### Pagination
+Il est nécessaire de prévoir des fonctionnalités de pagination de ressources afin de maitriser la quantité d'informations qui sera présentée à chaque appel.
+
+Pour ce faire, il est utile de préciser :
+
+ - du point de vue du consommateur (ou réutilisateur):
+ - la pagination souhaitée au moment de l'appel à la ressource
+ - du point de vue du producteur de l'API :
+ - le nombre d'éléments maximum renvoyé pour la ressource;
+ - l'interval entre la première page et la dernière page renvoyée;
+ - le nombre d'éléments total de la ressource.
+
+Pour cela, la règle est traduite comme suit en prenant comme exemple une liste d'associations avec une pagination du premier au dixième élément.
+
+> ℹ️ Un exemple inspiré du [guide du design des API rédigé par Octo](https://blog.octo.com/designer-une-api-rest).
+
+```
+ GET https://api-name/v1/associations?range=1-10
+
+ < HTTP/1.1 200 OK
+ < Accept-Range: 50
+ < Content-Range: 1-10/600
+```
+
+##### Tri
+La fonctionnalité de tri comme de *filtrage* ou de *recherche* impacte la fonctionnalité de pagination. Pour répondre à cette fonctionalité 2 paramètres son utilisés `sort` et `desc` :
+
+ - sort : indique les attributs métiers à trier. Si plusieurs attributs sont concernés, ils doivent être séparés par une virgule `sort=theme,titre`
+ - desc: indique le sens du tri descendant pour les attributs métiers souhaités. Par défaut le tri est ascendant.
+
+```
+ GET https://api-name/v1/associations?range=1-70&sort=id_association&desc=id_association
+
+ < HTTP/1.1 200 OK
+ < Accept-Range: 50
+ < Content-Range: 1-50/600
+```
+##### Filtrage
+Le filtrage permet de limiter le nombre d'élément renvoyé pour une ressource donnée, en spécifiant des attributs et leurs valeurs attendus.
+Il est possible de filtrer une collection sur plusieurs attributs simultanément, et de permettre plusieurs valeurs pour un même attribut filtré en utilisant comme séparateur la virgule.
+
+```
+ GET "https://api-name/communes?codeDepartement=13,15&format=json&geometry=centre&fields=nom,code,codeDepartement,departement"
+```
+
+L'exemple cité permet de filtrer non seulement l'ensemble des occurences souhaité en utilisant les attributs et valeurs choisis (ex: *code_departement*), mais également en précisant uniquement les attributs souhaités via le paramètre `fields` (ex: *nom*,*code*,*codeDepartement*,*departement*).
+
+> l'usage du paramètre `fields` permet, à l'issue de l'appel, de ne renvoyer que les informations nécessaires que sont *nom*, *code*, *codeDepartement* et *departement*.
+
+
+##### Recherche globale
+Il s'agit de permettre une recherche approchante sur un ensemble d'attributs, de champs liés à la ressource et qui seront les plus pertinents sur le plan métier. Pour se faire la notation Google est utilisée.
+
+**Cette règle est traduite comme suit** :
+
+```
+ GET `https://api-name/v1/associations/search?q=asso`
+```
+
+Le nombre d'occurrence d'informations pouvant être important, il convient d'en limiter le nombre retourné avec une valeur par défaut (ex: `limit=5`) modifiable jusqu'à une valeur maximale que vous considérez adapter au contexte :
+
+```
+ GET `https://api-name/v1/associations/search?q=asso&limit=5`
+```
+### Règle 2.15
+
+
+Vous devez fournir une documentation permettant de faciliter l'appropriation et l'usage de votre API et permettre à vos consommateurs de démarrer rapidement. Pour cela, vous devez :
+
+- utiliser la [Spécification OpenAPI 3](https://www.openapis.org/) le cas échéant pour générer la documentation (recommandé par l'Open Standards Board)
+- générer une documentation suivant le formalisme [Swagger](https://swagger.io/)
+- fournir un exemple de code pour illustrer comment appeler l'API et pour indiquer aux utilisateurs les réponses auxquelles ils peuvent s'attendre
+
+Vous devez également inclure dans la documentation :
+
+- les informations contextuelles / générales - ce que fait l'API, à qui elle s'adresse et suivant quelles circonstances
+- les règles contractuelle et des données - dans quelles circonstances les données sont-elles disponibles / non disponibles
+- les scénarios d'erreur - pré-conditions et résultats - y compris les codes d'erreur et les messages
+- les détails sur le service de test - comment l'utiliser et comment simuler les différents scénarios de réussite et d'erreur
+- tous les détails des paramètres de requête et de réponse, y compris la signification, le type de données et toute autre contrainte. Donnez des exemples de valeurs valides.
+- les règles relatives au traitement des informations, à la gestion des incidents et à la gestion des risques
+- la méthode d'authentification en place (et son impact sur l'interopérabilité des services, l'authentification unique(SSO) et la limitation du débit (throttling)
+- toutes les règles d'autorisation, par exemple, l'utilisation d'OAuth 2.0 et spécifiquement les scopes requis pour cette API
+- les modifications de conception (récentes et prévues) et les informations de version
+- la disponibilité, la latence, la propriété, la politiques de dépréciation et l'état de la capacité
+- l'approche permettant la compatibilité descendante de l'API
+- des conseils sur la configuration de l'API pour s'assurer que toutes les exigences sont suivies
+- le coût d'utilisation, le cas échéant
+
+Vous devez toujours vous assurer que votre documentation est claires et communiquer lorsque des modifications sont apportées.
+
+## Principe n°3 : les versions d’une API suivent la politique de gestion de versions de la DTNUM
+
+### Règle 3.1
+
+Une API peut supporter au plus deux versions en même temps. Dès la mise en œuvre de la nouvelle version que l’on nommera « Vn+1 », la version « Vn » ne doit pas être disponible au-delà de 18 mois. Ce délai doit permettre une migration de la version « Vn » vers la version « Vn+1 » en toute quiétude.
+
+### Règle 3.2
+
+Une feuille de route est associée à chaque API. Celle-ci doit comporter a minima les informations suivantes :
+
+- la liste des futures versions prévues ainsi que les dates de mise en service associées
+- la liste des nouvelles fonctions ainsi que celles qui ne seront plus supportées
+- les évolutions prévues dans chaque version en précisant les impacts éventuels sur la version précédente
+- le point de contact pour toute question relative à cette feuille de route
+
+Cette information doit faire l'objet d'une diffusion auprès des utilisateurs. Des canaux classiques comme la publication sur la page de présentation de l'API ou de mailing sont à prévoir. Il est également possible d'indiquer les éléments qui ne seront plus supportés en utilisant l'entête `Deprecation` et `Sunset`([RFC
+8594](https://datatracker.ietf.org/doc/html/rfc8594)) des réponses HTTP.
+
+### Règle 3.3
+
+Lors de la publication d'une nouvelle version d'une API, il faut minimiser au maximum les impacts pour les utilisateurs actuels afin de ne pas générer de surcoût pour leur permettre de prendre en compte cette nouvelle version.
+
+Pour cela, il faut privilégier :
+
+- des modifications rétrocompatibles lorsque cela est possible - précisez aux parsers d'ignorer les propriétés qu'ils ne s'attendent pas ou ne comprennent pas pour garantir que les modifications sont rétrocompatibles (cela permet d'ajouter des champs pour mettre à jour les fonctionnalités sans nécessiter de modifications de l'application cliente)
+- la mise à disposition d'un nouvel endpoint pour des changements importants
+- la documentation des endpoints obsolètes
+
+De nouveaux endpoints ne sont pas toujours nécessaires pour la fourniture de nouvelles fonctionnalités si ils permettent de maintenir la compatibilité descendante.
+
+### Règle 3.4
+
+Lorsqu'il n'est pas possible de maintenir une compatibilité avec les versions précédentes, les évolutions de l'API doivent être publiées en prenant en compte :
+
+- l'incrément du numéro de version qui doit apparaître dans l'URL en commençant pas `/v1/`
+- le support les endpoints des anciennes versions conformément à la règle 3.1
+- l'information des utilisateurs pour leur indiquer comment valider les données. En leur indiquant, par exemple, les champ qui ne seront plus présents afin qu'ils puissent s'assurer que leurs règles de validation traiteront ce champ de manière optionnelle
+- la fourniture d'un nouvel objet lorsqu'il est nécessaire de modifier la structure d'un objet complexe. Cela peut être le cas lorsque l'on souhaite combiner les données provenant de plusieurs objets. Dans ce cas le nouvel objet sera exposé au travers d'un nouvel endpoint
+ - combiner les données d'un utilisateur `/v1/users/123` et de son compte `/v1/accounts/123` dans un nouvel objet `/v1/consolidated-account/123`
+
+### Règle 3.5
+
+Afin de permettre aux consommateurs de l'API de tester leur application dans son usage de l'API, celle-ci doit proposer un service de test. En fonction des cas de figure, cette API de test pourra prendre en compte différentes contraintes :
+
+- si l'API est en lecture seule sur des ressources, il n'est pas indispensable de prévoir une API de test
+- si l'API a un comportement complexe ou avec état, envisagez de fournir un service de test qui imite autant que possible le service en direct, mais gardez à l'esprit le coût de cette opération
+- si l'API nécessite une autorisation, l'API de test doit inclure ce mécanisme ou offrir plusieurs niveaux de service de test en fonction des niveaux d'autorisation possibles
+
+Pour que ce service de test soit le plus efficace possible, il est conseillé de réaliser une enquête auprès des consommateurs qui pourront ainsi préciser leurs attentes.
+
+## Principe n°4 : sélectionner les API à exposer
+
+### Règle 4.1
+
+Pour ce qui est des API permettant d’exposer des données sous responsabilité du ministère de l’intérieur, l’identification de ces données de références se fait en collaboration avec l’administrateur ministériel des données (*AMD*).
+
+### Règle 4.2
+
+Pour ce qui concerne les API exposant des traitements, l’identification et la validation des API devant être mises en place se font en collaboration avec les directions métiers visées par le règlement portant ce traitement.
+
+## Principe n°5 : mettre en place des éléments de mesure, de supervision et de contrôle
+
+### Règle 5.1
+
+Si votre API sert des données personnelles ou sensibles, vous devez journaliser la date à laquelle les données sont fournies et à qui. Cela contribura à apporter une réponse aux exigences du règlement général sur la protection des données (RGPD), à répondre aux demandes d'accès des personnes concernées et à détecter les fraudes ou les abus.
+
+### Règle 5.2
+
+Privilégiez un accès sans contrôle si vous souhaitez donner un accès sans entrave à votre API et que vous n'avez pas besoin d'identifier vos utilisateurs. C'est le cas par exemple lorsque vous fournissez des données ouvertes. Cependant,il faut garder à l'esprit le risque [d'attaques par déni de service](https://fr.wikipedia.org/wiki/Attaque_par_d%C3%A9ni_de_service).
+
+Attention, le libre accès ne signifie pas que vous ne pouvez pas limiter l'usage de votre API.
+
+### Règle 5.3
+
+L'authentification des consommateurs est requise lorsque l'on souhaite :
+
+- limiter le débit (ou throttling)
+- auditer l'usage
+- facturer les consommateurs
+- contrôler l'accès en fonction d'autorisations accordées aux consommateurs
+
+En fonction du ou des objectifs, les exigences de sécurité de la solution d'authentification seront différentes.
+
+Par exemple, si vous devez identifier les utilisateurs uniquement à des fins de limitation de débit, vous n'aurez peut-être pas besoin d'actualiser les jetons utilisateur très souvent, car un jeton entre de mauvaises mains ne menacera probablement pas votre service.
+
+Utilisez l'autorisation au niveau de données applicatives si vous souhaitez contrôler quelles applications peuvent accéder à votre API, mais pas quels utilisateurs finaux spécifiques. Cela convient si vous souhaitez utiliser la fonctionnalité de limitation de débit, d'audit ou de facturation. Cependant, elle ne sera sans doute pas adaptée aux API contenant des données personnelles ou sensibles à moins que vous ne fassiez vraiment confiance à vos consommateurs. Si il s'agit, par exemple, d'un autre service gouvernemental.
+
+### Règle 5.4
+
+Il existe deux grandes familles de consommateurs d'une API :
+- anonymes, ne disposant pas d'identifiant et dont l'usage de l'API ne peut être imputé à un acteur. Dans ce cas, seul un contrôle global peut être assuré (cf. Règle 5.4).
+- enregistré, disposant d'un identifiant unique permettant de leur imputer l'usage d'une API. Dans ce cas, un contrat d'usage a été validé lors de l'obtention de l'identifiant. Un contrôle particulier peut alors être mis en place.
+
+Bien qu'il y ait une forte affinité entre consommateurs anonymes et API ouvertes, cette association n'est pas exclusive. Il peut être nécessaire d'obtenir un élément d'identification pour utiliser une API ouverte. Dans ce cas, le contrôle ne portera pas sur l'éligibilité de l'acteur, mais sur l'usage des ressources.
+
+De manière générale, les ressources mises en oeuvre pour un usage anonyme doivent être limité et donc se refléter dans le contrat d'usage avec des niveaux de qualité de service et de volume restreints.
+
+### Règle 5.5
+
+Utilisez l'autorisation au niveau de l'utilisateur si vous souhaitez contrôler les utilisateurs finaux qui peuvent accéder à votre API. Cela convient pour traiter des données personnelles ou sensibles.
+
+[OpenID Connect](http://openid.net/connect/) (OIDC), qui s'appuie sur OAuth2, avec son utilisation de [JSON Web Token (JWT)](https://tools.ietf.org/html/rfc7519), est utilisé par France Connect et peut convenir dans certains cas. Il faudra néanmoins prévoir un dispositif OIDC interne pour permettre à des utilisateurs inconnus des Fournisseurs d'Identité d'utiliser l'API.
+
+### Règle 5.6
+
+L'usage d'une API doit être identifié par un élément unique valide pour une période de temps fixée. Ce dernier doit permettre le suivi de l'usage et la vérification du respect des clauses du contrat. Il peut reposer sur une information spécifique ou être une combinaison d'éléments permettant cette unicité. L'usage des jetons et des autorisations répond à ce besoin et suit les bonnes pratiques suivantes :
+
+- choisissez une fréquence d'actualisation et une période d'expiration appropriées pour vos jetons d'accès utilisateur - le fait de ne pas actualiser régulièrement les jetons d'accès peut entraîner des vulnérabilités
+- autorisez vos utilisateurs à révoquer leur autorité
+- invalidez vous-même un jeton d'accès et forcez une réémission s'il y a une raison de soupçonner qu'un jeton a été compromis
+- assurez-vous que les jetons que vous fournissez disposent des autorisations les plus étroites possibles (la réduction des autorisations signifie qu'il y a un risque beaucoup plus faible pour votre API si les jetons sont perdus par les utilisateurs ou compromis)
+
+### Règle 5.7
+
+Le contrôle de l'usage d'une API peut se faire suivant deux niveaux :
+
+- à un niveau global afin de préserver les ressources mises en oeuvre pour la délivrance de l'API. Ce niveau s'applique globalement à tous les consommateurs et repose généralement sur des éléments techniques pour le comptage de l'usage. Ce contrôle permet de répartir les ressources sur l'ensemble des demandes en limitant l'usage des gros consommateurs.
+- à un niveau contractuel afin de s'assurer du respect des conditions d'utilisation par les consommateurs. Ce niveau repose sur des éléments métiers pointés dans le contrat d'usage. Il permet d'être fin dans la gestion des ressources et ainsi garantir le niveau de qualité de service annoncé.
+
+### Règle 5.8
+
+Surveillez l'usage de votre API pour détecter tout comportement inhabituel, tout comme vous surveilleriez de près tout site Web. Recherchez les changements d'adresses IP ou d'utilisateurs utilisant des API à des moments inhabituels de la journée.
+
+La fourniture d'une API ne doit pas se limiter à la prise en compte des composants permettant son exposition et sa consommation. L'ensemble des composants contribuant aux traitements des demandes soumises par l'API doivent être pris en compte dans cette surveillance.
+
+Cette chaîne de composants entre également dans l'élaboration du contrat d'usage unissant le fournisseur d'API à ses consommateurs.
+
+### Règle 5.9
+
+Un périmètre de données ou de services (scope) doit être défini pour un contrat d'usage.
+
+L'identification d'un contrat d'usage ne doit pas reposer sur des éléments techniques (adresse IP) ou métier (user ID).
+
+### Règle 5.10
+
+Il existe différentes stratégies permettant de garantir le niveau de qualité de service et de disponibilité de votre API ainsi que son passage à l'échelle.
+
+Pour les API d'accès aux données ouvertes pouvant être mises en cache, un réseau de diffusion de contenu (CDN) bien configuré peut fournir une évolutivité suffisante.
+
+Pour les API qui ne présentent pas ces caractéristiques, vous devez définir des quota d'usage pour vos utilisateurs en termes de capacité et de taux disponibles. Commencez petit, en fonction des besoins des utilisateurs, et répondez aux demandes d'augmentation de la capacité en vous assurant que votre API peut respecter les quotas que vous avez définis. Assurez-vous que les utilisateurs peuvent tester votre API complète jusqu'aux quotas que vous avez définis.
+
+Appliquez les quotas que vous avez définis, même lorsque vous avez une capacité excédentaire. Cela garantit que vos utilisateurs bénéficieront d'une expérience cohérente lorsque vos ressources viendront à diminuer, et qu'ils concevront et construiront leurs applications pour gérer votre quota d'API.
+
+Comme pour les services destinés aux utilisateurs, vous devez tester la capacité de vos API dans un environnement représentatif pour vous assurer de pouvoir répondre à la demande.
+
+Lorsque l'API fournit des informations personnelles ou privées, vous, en tant que responsable du traitement, devez fournir des délais d'expiration suffisants pour toutes les informations mises en cache dans votre réseau de distribution (CDN).
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/content/fr/strategie-api/sommaire.md b/content/fr/strategie-api/sommaire.md
new file mode 100644
index 0000000..0811aea
--- /dev/null
+++ b/content/fr/strategie-api/sommaire.md
@@ -0,0 +1,26 @@
+---
+title: doctrine api
+layout: layouts/page.njk
+showBreadcrumb: true
+eleventyNavigation:
+ key: doctrine api
+ parent: Données
+ order: 2
+---
+
+## Doctrine API
+
+- [**Introduction**](../introduction/index.html#intro)
+- [**Les API**](../introduction/index.html#API)
+- [**Choix technologique**](../introduction/index.html#choix)
+
+## Principes & règles
+
+- [Principe n°1 ](../principes/index.html#pr1) et [règles](../regles/index.html#pr1): **une API doit exposer des services métiers** et non des composants
+- [Principe n°2](../principes/index.html#pr2) et [règles](../regles/index.html#pr2): veiller au **découplage des API**
+- [Principe n°3](../principes/index.html#pr3") et [règles](../regles/index.html#pr3"): les versions d’une API suivent la politique de **gestion de versions** de la DTNUM
+- [Principe n°4](../principes/index.html#pr4) et [règles](../regles/index.html#pr4): **sélectionner les API à exposer**
+- [Principe n°5](../principes/index.html#pr5) et [règles](../regles/index.html#pr5): **mettre** en place des **éléments de mesure**, de **supervision** et de contrôle
+- [Principe n°6](../principes/index.html#pr6) : une API expose de la **donnée** et des **traitements**
+
+{% include "components/back_to_top.njk" %}
\ No newline at end of file
diff --git a/package.json b/package.json
index 97de251..21401e6 100644
--- a/package.json
+++ b/package.json
@@ -5,6 +5,7 @@
"scripts": {
"build": "npx @11ty/eleventy",
"postbuild": "npx pagefind --site _site/ --output-subdir \"_pagefind\"",
+ "build-ghpages": "npx @11ty/eleventy --pathprefix=/cct-mi/fr",
"start": "npx @11ty/eleventy --serve --quiet",
"debug": "DEBUG=Eleventy* npx @11ty/eleventy",
"debugstart": "DEBUG=Eleventy* npx @11ty/eleventy --serve --quiet",
@@ -12,7 +13,7 @@
},
"repository": {
"type": "git",
- "url": "git@github.com:codegouvfr/eleventy-dsfr.git"
+ "url": "git@github.com:dnum-mi/cct-mi.git"
},
"author": {
"name": "Mission logiciels libres (DINUM)",
@@ -23,7 +24,7 @@
"engines": {
"node": ">=14"
},
- "homepage": "https://codegouvfr.github.io/eleventy-dsfr/",
+ "homepage": "https://dnum-mi.github.io/cct-mi/fr",
"devDependencies": {
"@11ty/eleventy": "^2.0.1",
"@11ty/eleventy-img": "^3.1.0",
diff --git a/public/icons/undraw_design_team_re_gh2d.svg b/public/icons/undraw_design_team_re_gh2d.svg
new file mode 100644
index 0000000..1d3b17d
--- /dev/null
+++ b/public/icons/undraw_design_team_re_gh2d.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/public/icons/undraw_home_run_acyh.svg b/public/icons/undraw_home_run_acyh.svg
new file mode 100644
index 0000000..2790940
--- /dev/null
+++ b/public/icons/undraw_home_run_acyh.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/public/icons/undraw_online_collaboration_re_bkpm.svg b/public/icons/undraw_online_collaboration_re_bkpm.svg
new file mode 100644
index 0000000..f82a8d2
--- /dev/null
+++ b/public/icons/undraw_online_collaboration_re_bkpm.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/public/icons/undraw_team_collaboration_re_ow29.svg b/public/icons/undraw_team_collaboration_re_ow29.svg
new file mode 100644
index 0000000..4fcf7f3
--- /dev/null
+++ b/public/icons/undraw_team_collaboration_re_ow29.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/public/icons/undraw_team_collaboration_re_ow29_green.svg b/public/icons/undraw_team_collaboration_re_ow29_green.svg
new file mode 100644
index 0000000..ddd42ee
--- /dev/null
+++ b/public/icons/undraw_team_collaboration_re_ow29_green.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/public/img/cct-2.png b/public/img/cct-2.png
new file mode 100644
index 0000000..d277fdb
Binary files /dev/null and b/public/img/cct-2.png differ
diff --git a/public/img/cct-cycle-de-vie-des-applications.png b/public/img/cct-cycle-de-vie-des-applications.png
new file mode 100644
index 0000000..a05fb72
Binary files /dev/null and b/public/img/cct-cycle-de-vie-des-applications.png differ
diff --git a/public/img/cct-themes.png b/public/img/cct-themes.png
new file mode 100644
index 0000000..8fe5ebe
Binary files /dev/null and b/public/img/cct-themes.png differ
diff --git a/public/img/undraw_Engineering_team_a7n2.png b/public/img/undraw_Engineering_team_a7n2.png
new file mode 100644
index 0000000..fb41457
Binary files /dev/null and b/public/img/undraw_Engineering_team_a7n2.png differ
diff --git a/public/img/undraw_Location_tracking_re_n3ok.png b/public/img/undraw_Location_tracking_re_n3ok.png
new file mode 100644
index 0000000..51630d0
Binary files /dev/null and b/public/img/undraw_Location_tracking_re_n3ok.png differ
diff --git a/public/img/undraw_Secure_server_re_8wsq.png b/public/img/undraw_Secure_server_re_8wsq.png
new file mode 100644
index 0000000..4efb0b9
Binary files /dev/null and b/public/img/undraw_Secure_server_re_8wsq.png differ
diff --git a/public/img/undraw_Security_on_re_e491.png b/public/img/undraw_Security_on_re_e491.png
new file mode 100644
index 0000000..743d3cd
Binary files /dev/null and b/public/img/undraw_Security_on_re_e491.png differ
diff --git a/public/img/undraw_Weather_app_re_kcb1.png b/public/img/undraw_Weather_app_re_kcb1.png
new file mode 100644
index 0000000..0d5d6a0
Binary files /dev/null and b/public/img/undraw_Weather_app_re_kcb1.png differ
diff --git a/public/img/undraw_cloud_files_wmo8.png b/public/img/undraw_cloud_files_wmo8.png
new file mode 100644
index 0000000..eac25e5
Binary files /dev/null and b/public/img/undraw_cloud_files_wmo8.png differ
diff --git a/public/img/undraw_progressive_app_m9ms.png b/public/img/undraw_progressive_app_m9ms.png
new file mode 100644
index 0000000..12ea591
Binary files /dev/null and b/public/img/undraw_progressive_app_m9ms.png differ
diff --git a/public/img/undraw_urban_design_kpu8.png b/public/img/undraw_urban_design_kpu8.png
new file mode 100644
index 0000000..a01898c
Binary files /dev/null and b/public/img/undraw_urban_design_kpu8.png differ
+
+
+
+
+
+*Figure : Focus sur les utilisations du CCT au sein cycle de vie d’une application*
+
+Le CCT contient des exigences de différents niveaux (bloquant, primordial, important).
+A noter que, malgré leur caractère non bloquant, la bonne application des exigences
+primordiales et importantes sera évaluée et notée lors de la comparaison de solutions
+techniques proposées par les prestataires.
+- **Phase de conception** : Pour assurer la bonne prise en compte de ces exigences, il est indispensable de considérer le CCT dès la conception d’une nouvelle application ou au démarrage de la transformation d’une application existante. Et cela avant de démarrer
+les travaux de construction.
+- **Phase de pré-bascule** : Des contrôles de conformité seront effectués lors des phases de test de l’application. Ceux-ci pourront mener à des réserves à la mise en service de l’application.
+- **Phase de bascule et post-bascule** : Si les éventuelles réserves levées lors de la phase de tests ne sont pas levées, la mise en service pourra être bloquée.
+Dans le cadre d’applications développées par des partenaires externes et faisant l’objet
+d’un marché public, le CCT et sa liste d’exigence devront être joints au CCTP.
+
+## Cadre d’applicabilité
+
+### Usages concernés
+Le CCT du MIOM concerne en particulier les modèles de déploiements suivants :
+- **Toute application dont le MIOM** est **propriétaire**
+- **Toute application dont le MIOM** est l’**hébergeur**
+
+Deux approches sont actuellement possibles pour la mise à disposition des applications :
+l’approche « cloud native » et l’approche « legacy » :
+1. La première, le Cloud Native, est à privilégier systématiquement lors de la
+conception de nouvelles applications et lors de la transformation
+d‘applications existantes.
+2. La seconde, le legacy, héberge les applications déployées antérieurement et
+non compatibles avec les nouvelles normes. Elle ne pourra être utilisée pour
+des nouveaux usages que de manière exceptionnelle et dérogatoire.
+
+ |Critères de comparaison|Legacy|Cloud Native|
+ |--------|----------|------|
+ | **Modèle de responsabilité**| Responsabilité entièrement portée par le MIOM à partir de l’intégration de l’application, sur le déploiement et l’exploitation| Responsabilité partagée avec une autonomisation du développeur « you build it,you run it »|
+ |**Processus de déploiement**| Tests, intégration et déploiement manuels ou semi-automatisés|Tests, intégration et déploiements automatisés Déploiements fréquents |
+ |**Exigences et contrôle**|Cadre et exigences sur l’ensemble des couches de l’application Contrôle complet de l’application et infrastructure, homologation de bout en bout| Cadre et exigences focalisés sur les interfaces de l’application et les données exposées Liberté laissée au développeur tant que les interfaces sont respectées|
+ |**Consommation service transverse**|Services transverses à mettre en œuvre et intégrer «manuellement»| Intégration native des services sur étagère et automatiquement|
+ |**Valorisation de la donnée**|Intégration «manuelle» aux services d’exposition de la donnée|Capacités «sur étagère» et automatisée d’exposition des données|
+ |**Observabilité**|Logs non normés, peu ou pas centralisés.|Centralisation systématique du monitoring et des logs de l’infrastructure et des applications permettant une vision 360 sur l’application Normalisation des logs (techniques, métiers, sécurité)|
+ |**Processus de run**|Exploitation des applications dans un modèle **«pet»**, configurations manuelles et réparation des incidents au sein des serveurs|Exploitation dans un modèle **«cattle»**, détection automatisée des problèmes (health check) et reconstruction des containers plutôt que réparation|
+
+
+### Détail sur les contrôles et validation en fonction de l’application
+
+- Pour les grandes applications:
+ - Nouvelles applications : un « Go » devrait être donnée, après étude
+approfondie de la solution par le comité d’architecture
+ - Modifications/évolutions majeures : un « Go » devrait être donnée, après étude approfondie de la modification et l’impact sur la solution globale,
+par le comité d’architecture
+ - Modifications/évolutions mineures : un « Go » devrait être donnée, après étude approfondie de la modification/évolution proposées
+ - Pour les petites applications:
+ - Nouvelles applications : un « Go » devrait être donnée, après étude
+approfondie de la solution par le comité d’architecture (voir lien avec gouvernance ?),
+ - Modifications / évolutions majeures ou mineures : les responsables
+applicatifs effectuent l’étude en autonomie et s’engagent à respecter le CCT
+
+# Cycle de vie du CCT et gouvernance
+
+La gouvernance du CCT s’appuie sur un comité, le comité d'architecture. Celui-ci est
+animé par la DNUM. Le comité est collégial, constitué de référents mandatés par les
+principales sous directions de la DNUM ainsi que des autres acteurs SIC du ministère :
+ST(SI)², PP, agences. Chaque référent titulaire peut être backupé par un suppléant. Les
+décisions sont prises à la majorité des voix des référents présents (titulaire ou
+suppléant).
+
+Au titre de son activité CCT, le comité d’architecture se réunit au moins deux fois par
+an pour valider la publication des mises à jour semestrielles du CCT. En dehors de ces
+deux réunions annuelles, le comité a toute latitude pour organiser les travaux sous
+forme de groupes de travail ad-hoc. Ces groupes de travail peuvent intégrer des
+participants n’appartenant au comité. La liste des représentants des différents acteurs
+SIC du MIOM, ainsi que la liste des contributeurs au CCT mandatés par le comité, sont
+disponibles sur l’espace CCT ministériel.
+
+Contribution du comité d’architecture au CCT : rôle du référent ministériel
+Affecté au BPNM (Bureau des Politiques Numériques du Ministère) de la DTNUM/SDID
+(Sous-Direction à l'Innovation et de la Donnée), il est chargé de :
+
+ - Pilotage du cadre de cohérence technique ministériel, de la gestion et de
+l'animation des groupes de travail et des contributeurs, de la préparation des
+réunions du comité CCT
+ - L’outillage de la méthode, du processus de contrôle de l'application du CCT et
+de la production des livrables
+ - Suivi et de la prise en compte des normes et standards
+ - La veille technologique sur les composants et produits référencés au CCT
+Contribution du comité d’architecture au CCT : les référents des acteurs SIC
+Dans le périmètre de leur entité de rattachement, ils sont chargés de :
+ - L'animation des groupes de travail internes, le cas échéant
+ - Recueil des demandes d'évolution et de la préparation des dossiers présentés en
+comité ministériel
+ - Contrôle de l'application du CCT
+ - L’information au sein de leur entité, et tout particulièrement de la sensibilisation
+des chefs de projets
+
+
- 
+