diff --git a/docs/.vitepress/sidebar.json b/docs/.vitepress/sidebar.json
index 7ef3ffb..19a6b14 100644
--- a/docs/.vitepress/sidebar.json
+++ b/docs/.vitepress/sidebar.json
@@ -98,17 +98,29 @@
"link": "/guide/get-started"
},
{
- "text": "Gestion des environnements",
- "link": "/guide/environments-management"
+ "text": "Gestion des projets",
+ "link": "/guide/projects-management"
},
{
- "text": "Gestion des equipes",
+ "text": "Gestion des équipes",
"link": "/guide/team"
},
+ {
+ "text": "Gestion des dépôts",
+ "link": "/guide/repositories-management"
+ },
+ {
+ "text": "Gestion des environnements",
+ "link": "/guide/environments-management"
+ },
{
"text": "Gestion des secrets",
"link": "/guide/secrets-management"
},
+ {
+ "text": "Déploiement de votre application",
+ "link": "/guide/deployment-with-argo"
+ },
{
"text": "Bonnes pratiques",
"link": "/guide/best-practices"
diff --git a/docs/guide/deployment-with-argo.md b/docs/guide/deployment-with-argo.md
new file mode 100644
index 0000000..e31ee5b
--- /dev/null
+++ b/docs/guide/deployment-with-argo.md
@@ -0,0 +1,30 @@
+# Déploiement de votre application
+
+Une fois qu'un dépôt d'infrastructure est synchronisé, il convient de se rendre sur le service ArgoCD depuis la liste des services :
+
+
+Cliquez sur le projet nouvellement créé afin de finaliser son configuration: modification du dépôt d'infrastructure par défaut, ou le cluster de déploiement applicative.
+
+Allez dans le menu en haut et cliquez sur App detail :
+
+
+Sur l'écran qui s'affiche, cliquez sur le bouton *EDIT* et adaptez les valeurs renseignées par defaut par la console et selectionner le cluster de déployement.
+
+
+Notamment:
+
+- **CLUSTER**: correspond au cluster sur lequel l'application doit être déployée, cela dépends des informations saisie lors de l'étape de [gérer les environnements](/guide/environments-management).
+- **TARGET REVISION**: correspond à la branche du repo d'infra à déployer, par defaut il point sur HEAD (master). A adapter si le repo utilise une branche
+- **PATH** qui est positionné à base par defaut et qui correspond à un déploiement de type fichiers de manifests ou kustmize. Dans le cas d'un déploiement de type HELM, modifier le PATH point pointer vers la racine en mettant un point dans le champs : . ou préciser le répertoire correspondant à la racine du chart
+- Dans l'onglet **PARAMETERS**, il est possible de surcharger certaines valeurs du fichier values (mais il est préférable de modifier le fichier values directement)
+
+Finir la saisie en cliquant sur le bouton *SAVE*
+
+Le déploiement se fait automatiquement par ArgoCD, mais il est possible de forcer la synchronisation avec le repo sur gitlab Cloud π Native en cliquant sur les boutons:
+
+- *REFRESH* pour forcer la synchronisation depuis le repo gitlab de la plateforme Cloud π Native
+- *SYNC* pour forcer le rafraichissement entre l'état défini par git et l'état réel des objets créés par ArgoCD.
+
+Une fois le déploiement est correctement effectué le status de l'application ArgoCD doit correspondre à :
+
+
diff --git a/docs/guide/get-started.md b/docs/guide/get-started.md
index 42e7cb3..b2fde35 100644
--- a/docs/guide/get-started.md
+++ b/docs/guide/get-started.md
@@ -7,275 +7,44 @@ La prise en main de la plateforme Cloud π Native se fait par la console.
Une fois sur la console, il faut se connecter en cliquant en haut à droite sur le bouton se connecter :
-> **La** création des comptes utilisateurs est opérée par les administrateurs de la plateforme via l'interface administrateur de Keycloak.
+> La création des comptes utilisateurs est opérée par les administrateurs de la plateforme.
-## Etape 2 - Mes projets
+## Etape 2 - Créer un projet
-Une fois connecté sur la console, le menu gauche s'enrichi avec une entrée "Mes Projets" contenant la liste de ses projets.
-
+Créer un projet sur la console (un détail des opérations à mener est trouvable [ici](/guide/projects-management))
-Un projet est un espace virtuelle (Namespace pour kubernetes) pour une seule application et c'est rattaché à un ou plusieurs dépôts de code.
+**Attention, un projet ne peut changer de nom après sa création.**
-Cliquez sur le bouton **+ Créer un projet** afin d'ajouter un nouveau projet :
-
+## Etape 3 - Ajouter des collaborateurs
-Sur cet écran il est nécessaire de renseigner :
- - Nom de l'organisation : correspondant à l'entité administratif de rattachement.
- - Nom du projet : Ce nom servira à créer un groupe dans gitlab de la plateforme Cloud π Native et sera une composante du namesapce Kubernetes créé.
+Ajouter vos collaborateurs sur le projet, un guide est disponible [ici](/guide/team)
-Valider la saisie en cliquant sur **Commander mon espace projet**
+Les collaborateurs devant accéder à Argo CD devront être ajoutés à chaque environnement concernés, voir le guide [ici](/guide/team#attribution-de-droits-a-un-membre)
-La création d'un projet va lancer le provisionnement des différents [services](https://cloud-pi-native.fr/platform/introduction.html#services-core-proposes-par-la-plateforme), ce qui signifie principalement la configuration de ces outils avec un éspace dédié pour le projet, son cloisonnement avec les autres projets et l'authentification des utilisateurs projet dans ces outils. Cette opération pourra prendre quelques minutes et le nouveau projet est présenté en cours de construction :
+## Etape 4 - Ajouter un dépôt synchronisé
-
+Ajouter vos dépôts (qui devront par la suite être synchronisé - manuellement ou via un automatisation), un guide est disponible [ici](/guide/repositories-management).
-A la fin du processus de création, l'icone du projet est modifiée comme suit et devient un lien cliquable :
+Il existe deux types de dépôts:
-
+- dépôt avec du code applicatif: génère une image docker utilisée plus tard dans vos déploiements (doit contenir un Dockerfile et un fichier gitlab-ci nommé `.gitlab-ci-dso.yaml`)
+- dépôt avec du code d'infrastructure: manifest / template kuztomize / chart helm générant votre infrastructure via ArgoCD
-Au clic sur le projet, on arrive sur la liste des services associés :
-
+> Note: il est possible d'avoir un seul dépôt avec les 2 fonctionnalités
-Chaque icone permet d'accéder directement aux services de la plateforme directement sur le contexte du projet.
+## Etape 5 - Ajouter un environnement
-Une entrée dans le menu gauche permet également de voir l'état des services :
+Un environnement est un namespace cloisonné au sens kubernetes permettant de déployer le code d'infrastructure du dépôt idoine.
-
+Pour déployer un environnement un guide est disponible [ici](/guide/environments-management).
-### Gérer les membres
+> Note: les collaborateurs du projet devant intervenir sur ArgoCD concernant l'infrastructure doivent être rajouté sur chaque environnement, un guide disponible [ici](/guide/team#attribution-de-droits-a-un-membre).
-:construction: *Disponible prochainement* :construction:
+## Divers
-## Etape 3 - Ajouter un dépôt synchronisé
+Afin d'accéder à vos images construites via Cloud Pi Native et stockées sur Harbor, un secret, nommé `registry-pull-secret`, est créé automatiquement par la plateforme.
-Une fois que le projet est créé sur la console, il convient d'ajouter des dépôts synchronisés.
+Un tutoriel est disponible [ici](/guide/tutorials/#acces-aux-images-harbor)
-En effet, en phase de développement, les équipes projets sont autonomes et travaillent avec leurs outils sans contraintes apportées par la plateforme Cloud π Native. La synchronisation des dépôts est le processus qui permet de *copier* les dépôts externes stockés sur github, gitab.com, bitbucket, etc. vers le repo de code de la plateforme Cloud π Native. la seule contrainte est que le repo externe soit accessible depuis Internet. Ce repo peut être public ou privé. Pour plus d'information, voir la page dédiée au [repo de code](/services/gitlab)
+Un tutoriel est disponible [ici](/guide/tutorials) pour automatiser la synchronisation entre votre dépôt primaire et le dépôt sur la plateforme Cloud Pi Native
-Cliquez sur le menu gauche **Dépôts synchronisés**
-
-Puis sur le bouton **+ Ajouter un nouveau dépôt**
-
-
-
-
-Remplir le formulaire de synchronisation des dépôts:
- - Choisir un nom
- - Saisir l'URL du repo git distant. Dans le cas d'un repo privé cocher la case et préciser les credentials d'accès
- - Deux types de repo peuvent être ajouté :
- - Un repo applicatif : contenant du code applicatif et qui sera construit afin de créer des images Docker à déployer sur l'infrastructure cible.
- - Un repo d'infra : contenant les manifests de déploiement ou chart HELM contenant *l'infrastructure as code* du projet à déployer
-
-
-
-
-Dans le cas d'un dépôt de code applicatif, générer les fichiers de *gitlab-ci* en cliquant sur le bouton *Fichiers de GitLab CI*. Le fichier `.gitlab-ci-dso.yml` est à placer à la racine de votre dépôt externe et les `includes` (les autres fichiers `.yml`) sont à placer dans un dossier `includes/` à la racine de votre dépôt externe. Ces fichiers seront utilisés par le GitLab de Cloud π Native pour effectuer les divers tests, scans et déploiements du projet.
-
-
-
-Cliquer enfin sur le bouton `Ajouter le dépôt`.
-
-Lorsqu'un dépôt est créé dans la console en tant que `dépôt d'infrastructure`, la plateforme créé automatiquement l'application [ArgoCD](https://argo-cd.readthedocs.io/en/stable/) associée qui permettra le déploiement.
-
-
-Une fois que le dépôt est correctement ajouté, il apparait avec une icône indiquant son statut :
-
-
-
-> Cette opération demande d'attendre jusqu'à quelques minutes.
-
-> Des exemples de dépôts sont disponibles dans la sections [tutoriels](tutorials).
-
-
-### Gérer les environnements
-
-Une fois les dépôts d'infrastructure sont ajoutés, il sera possible d'ajouter un environnement en cliquant sur `Environments du projet` puis `Ajouter un nouvel environnement`
-
-
-
-Il faudra d'abord sélectionner le *stage* de déploiement de l'application permettant ensuite de choisir le cluster de déploiement (Prod/HorsProd/Dédié) ains que différents *quotas*.
-
-Selectionner ensuite l'environnement, les quotas, et le cluster ou vous souhaitez le déployer puis sur `Ajouter l'environnement`
-
-:warning: La création de dépôt d'infrastructure et la déclaration d'un environnement déclenche la création d'une application dans ArgoCD et d'un namespace dédié afin de déployer l'application.
-
-Des informations seront précréer dans ce namespace notamment l'imagePullSecrets qui sera a utilisé pour votre projet.
-
-**L'IMAGEPULLSECRETS SERA A RENSEIGNRER DANS LES TEMPLATES DE DEPLOYEMENT DE VOS IMAGES** :warning:
-
-Exemple:
-
-```yaml
----
-apiVersion: apps/v1
-kind: Deployment
-metadata:
- name: monimage-backend
- labels:
- app: monimage-backend
-spec:
- replicas: 1
- selector:
- matchLabels:
- app: monimage-backend
- template:
- metadata:
- labels:
- app: monimage-backend
- Tier: backend
- Criticality: Low
- Component: java
- spec:
- imagePullSecrets:
- - name: registry-pull-secret
- containers:
- - name: monimage-backend
- image: harbor.apps.c6.numerique-interieur.com/mi-monprojet/monimage-backend:v2
- imagePullPolicy: Always
- resources:
- requests:
- memory: "256Mi"
- cpu: "100m"
- limits:
- memory: "256Mi"
- cpu: "100m"
- ports:
- - containerPort: 8080
-```
-
-Une fois qu'un dépôt d'infrastructure est synchronisé, il convient de se rendre sur le service ArgoCD depuis la liste des services :
-
-
-
-Cliquez sur le projet nouvellement créé afin de finaliser son configuration: modification du dépôt d'infrastructure par défaut, ou le cluster de déploiement applicative.
-
-Allez dans le menu en haut et cliquez sur App detail :
-
-
-
-Sur l'écran qui s'affiche, cliquez sur le bouton *EDIT* et adaptez les valeurs renseignées par defaut par la console et selectionner le cluster de déployement.
-
-
-
-Notamment :
- - CLUSTER : correspond au cluster sur lequel l'application doit être déployée, cela dépends des informations saisie lors de l'étape de [gérer les environnements](#gérer-les-environnements).
- - TARGET REVISION : correspond à la branche du repo d'infra à déployer, par defaut il point sur HEAD (master). A adapter si le repo utilise une branche
- - PATH qui est positionné à base par defaut et qui correspond à un déploiement de type fichiers de manifests ou kustmize. Dans le cas d'un déploiement de type HELM, modifier le PATH point pointer vers la racine en mettant un point dans le champs : . ou préciser le répertoire correspondant à la racine du chart
- - Dans l'onglet *PARAMETERS*, il est possible de surcharger certaines valeurs du fichier values (mais il est préférable de modifier le fichier values directement)
-
-Finir la saisie en cliquant sur le bouton *SAVE*
-
-Le déploiement se fait automatiquement par ArgoCD, mais il est possible de forcer la synchronisation avec le repo sur gitlab Cloud π Native en cliquant sur les boutons :
- - *REFRESH* pour forcer la synchronisation depuis le repo gitlab de la plateforme Cloud π Native
- - *SYNC* pour forcer le rafraichissement entre l'état défini par git et l'état réel des objets créés par ArgoCD.
-
-Une fois le déploiement est correctement effectué le status de l'application ArgoCD doit correspondre à :
-
-
-
-
-## Etape 4 : Paramétrer la synchronisation
-
-Une fois le dépôt interne à la plateforme créé et lié à un dépôt externe, il sera important de paramétrer la synchronisation entre le dépôt source et son clône. La création déclenche une première synchronisation. Il convient maintenant de configurer comment ce dépôt sera synchronisé dans le temps.
-
-Pour paramétrer la synchronisation d'un dépôt :
-
-
-
-- Un dépôt nommé `/mirror` a été créé dans le groupe GitLab du projet. Dans ce dernier se trouve un script `mirror.sh` à copier dans votre dépôt externe.
- > Ce script a pour but de demander à la plateforme de synchroniser le dépôt en effectuant un appel api (avec authentification un trigger_token).
- > Il faut donc lancer ce script dans la CI/CD du dépôt source selon les évènements sur lesquels on souhaite déclencher une synchronisation (ex: lors d'un push sur la branche main).
-
-- Dans le GitLab de la plateforme, récupérer dans le dépôt `/mirror` le token `GITLAB_TRIGGER_TOKEN` (`Settings > CI/CD > Pipeline triggers`, au besoin en créer un).
-
-- Ajouter les variables d'environnements suivantes dans les __*secrets*__ de la CI/CD externe avec les valeurs fournies par l'équipe DSO ou précédemment récupérées (ces secrets seront utilisés par le script `mirror.sh`)
-
- | Nom de variable | Description |
- | ------------------------ | ---------------------------------------------------------------------------- |
- | API_URL | Url de GitLab |
- | BRANCH_TO_SYNC | Branche ou tag a synchroniser |
- | GITLAB_MIRROR_PROJECT_ID | ID du projet mirror dans GitLab |
- | REPOSITORY_NAME | Nom du repo a synchronisé dans le GitLab DSO |
- | GITLAB_TRIGGER_TOKEN | Token de déclenchement du pipeline de synchronisation dans le GitLab interne |
-
-- Ajouter dans la CI/CD l'exécution de ce script pour déclencher la synchronisation automatiquement.
-
- *Exemple avec Github (synchro lors d'un push sur la branche main du dépôt source) :*
-
- ```yaml
- # Dans un fichier .github/workflows/script-mirror.yaml
- name: Repo sync with Cloud π Native
-
- on:
- push:
- branches:
- - "main"
- workflow_dispatch:
-
- jobs:
- mirror:
- name: Sync repo with Cloud π Native
- runs-on: ubuntu-latest
- steps:
- - name: Checks-out repository
- uses: actions/checkout@v3
- - name: Send a sync request to DSO api
- run: |
- sh ./path/to/mirror.sh \
- -a ${{ secrets.API_URL }} \
- -g ${{ secrets.GITLAB_TRIGGER_TOKEN }} \
- -b ${{ secrets.BRANCH_TO_SYNC }} \
- -r ${{ secrets.REPOSITORY_NAME }} \
- -i ${{ secrets.GITLAB_MIRROR_PROJECT_ID }}
- ```
-
-- Répéter cette opération pour tous les dépôts en changeant le **REPOSITORY_NAME** y compris pour le ou les dépôts d'infrasctructure as code.
-
-La synchronisation est maintenant en place et chaque appel API effectué avec le script `mirror.sh` entrainera le déclenchement de la chaine DevSecOps.
diff --git a/docs/guide/projects-management.md b/docs/guide/projects-management.md
new file mode 100644
index 0000000..7001117
--- /dev/null
+++ b/docs/guide/projects-management.md
@@ -0,0 +1,45 @@
+# Gestion des projets
+
+Un projet est un espace virtuel (namespace au sens kubernetes) cloisonné pour une seule application.
+
+Chaque projet contient une liste de collaborateurs (voir [Gestion des équipes](/guide/team)) ainsi qu'un ou plusieurs dépôts de code (voir [Gestion des dépôts](/guide/repositories-management.md))
+
+## Création d'un projet
+
+Une fois connecté sur la console, le menu gauche présente une entrée "Mes Projets" contenant la liste de ses projets.
+
+
+Cliquez sur le bouton **+ Créer un projet** afin d'ajouter un nouveau projet:
+
+
+Sur cet écran il est nécessaire de renseigner :
+
+- **Nom de l'organisation**: correspondant à l'entité administratif de rattachement.
+- **Nom du projet**: ce nom servira à créer un groupe dans gitlab de la plateforme Cloud π Native et sera une composante du namespace Kubernetes créé.
+
+Valider la saisie en cliquant sur **Commander mon espace projet**
+
+La création d'un projet va lancer le provisionnement des différents [services](/platform/introduction.html#services-core-proposes-par-la-plateforme), ce qui signifie principalement la configuration de ces outils avec un espace dédié pour le projet, son cloisonnement avec les autres projets et l'authentification des utilisateurs projet dans ces outils. Cette opération pourra prendre quelques minutes et le nouveau projet est présenté en cours de construction:
+
+A la fin du processus de création, liste de tous vos projets est affiché avec le nouveau projet disponible
+
+
+
+Au clic sur le projet, une page de tableau de bord est affichée
+
+
+Deux informations affichées:
+
+- si le projet est verrouillé, demander à la ServiceTeam les raisons et le déverrouillage du projet
+- si les dernières opérations concernant le projet ont réussi
+
+Un certain nombre d'actions sont disponibles:
+
+- **Reprovisionner le projet**: la console DSO étant en cours de développement actif, des changements ont lieu et peuvent perturber le bon fonctionnement des projets. Ce bouton permet de mettre à jour son projet par rapport aux derniers développement de la console.
+- **Afficher les secrets des services**: affiche des configurations utiles mais sensible des projets (seul le propriétaire du projet peut voir les secrets)
+
+La partie GitLab permet d'avoir le token ainsi que l'id du dépôt mirror (permettant de cloner son dépôt primaire sur Cloud Pi Native). Cela permet d'automatiser cette action via des pipelines sur votre dépôt primaire.
+Concernant Harbor, la registry stockant les images construites sur la plateforme CPiN
+Pour la section Kubernetes, le nom du secret permettant de s'authentifier auprès d'Harbor.
+- **Supprimer le projet monprojet**: après confirmation, supprime définitivement le projet. Aucune restauration n'est possible.
+
diff --git a/docs/guide/repositories-management.md b/docs/guide/repositories-management.md
new file mode 100644
index 0000000..400aeb1
--- /dev/null
+++ b/docs/guide/repositories-management.md
@@ -0,0 +1,35 @@
+# Gestion des dépôts
+
+En phase de développement, les équipes projets sont autonomes et travaillent avec leurs outils sans contraintes apportées par la plateforme Cloud π Native. La synchronisation des dépôts est le processus qui permet de *copier* les dépôts externes stockés sur github, gitab.com, bitbucket, etc. vers le repo de code de la plateforme Cloud π Native. la seule contrainte est que le repo externe soit accessible depuis Internet. Ce repo peut être public ou privé. Pour plus d'information, voir la page dédiée au [repo de code](/services/gitlab)
+
+Cliquez sur le menu gauche **Dépôts synchronisés**
+
+
+Puis sur le bouton **+ Ajouter un nouveau dépôt**
+
+Remplir le formulaire de synchronisation des dépôts:
+
+- Choisir un nom
+- Saisir l'URL du repo git distant. Dans le cas d'un repo privé cocher la case et préciser les credentials d'accès
+- Deux types de repo peuvent être ajoutés:
+ - Un repo applicatif: contenant du code applicatif et qui sera construit afin de créer des images Docker à déployer sur l'infrastructure cible.
+ - Un repo d'infra: contenant les manifests de déploiement ou chart HELM contenant *l'infrastructure as code* du projet à déployer
+
+
+
+Dans le cas d'un dépôt de code applicatif, générer les fichiers de *gitlab-ci* en cliquant sur le bouton *Fichiers de GitLab CI*. Le fichier `.gitlab-ci-dso.yml` est à placer à la racine de votre dépôt externe. Ces fichiers seront utilisés par le GitLab de Cloud π Native pour effectuer les divers tests, scans et déploiements du projet.
+
+
+
+Cliquer enfin sur le bouton `Ajouter le dépôt`.
+
+Lorsqu'un dépôt est créé dans la console en tant que `dépôt d'infrastructure`, la plateforme créée automatiquement l'application [ArgoCD](https://argo-cd.readthedocs.io/en/stable/) associée qui permettra le déploiement.
+
+
+Une fois que le dépôt est correctement ajouté, il apparait avec une icône indiquant son statut :
+
+
+
+> Cette opération demande d'attendre jusqu'à quelques minutes.
+>
+> Des exemples de dépôts sont disponibles dans la sections [tutoriels](tutorials).
diff --git a/docs/guide/tutorials.md b/docs/guide/tutorials.md
index c4de947..e9f2301 100644
--- a/docs/guide/tutorials.md
+++ b/docs/guide/tutorials.md
@@ -2,10 +2,6 @@
Choisir entre un déploiement via le dépôt d'Infrastructure As Code `Manifestes` ou `Helm` lors de l'ajout du dépôt d'infrastructure dans la console.
-__Monorepo__
-> [!TIP]
-> Il est aussi possible d'utiliser un monorepo comprenant le code applicatif ainsi que le code d'infrastructure, dans ce cas ajouter ce seul dépôt de code et cocher la case `Dépôt contenant du code d'infrastructure`.
-
## Déployer une application stateless
Tutoriel de déploiement d'un serveur web servant une page html statique.
@@ -13,6 +9,7 @@ Tutoriel de déploiement d'un serveur web servant une page html statique.
### Nginx
Technologies:
+
- Server web Nginx
#### Dépôts
@@ -34,6 +31,7 @@ __Monorepo__
### Nginx / Nodejs
Technologies:
+
- Server web Nginx
- Api Nodejs
@@ -52,6 +50,7 @@ Tutoriel de déploiement d'une application dialoguant avec une base de données.
### Java / Postgresql
Technologies:
+
- Application Java
- Base de données Postgresql
@@ -64,3 +63,48 @@ __Multirepo__
| Applicatif | |
| IAC *(Manifestes)* | |
| IAC *(Helm)* | |
+
+## Mocks
+
+### Data-tooling
+
+Un mock data-tooling permettant d'exposer un base de données PostgreSQL en tant qu'api rest est disponible [ici](https://github.com/cloud-pi-native/mock-data-tooling).
+
+Ce mock contenant les outils suivants:
+
+- haproxy: agit en tant qu'API Gateway
+- postgrest: expose la base de données postgres au protocol REST
+- cloudpgnative: opérateur k8s pour gérer un cluster de postgresql
+- pgadmin: administration de la base de données
+- vector: gestion des logs
+- sops: gestion des secrets
+
+> Ce chart helm est capable de gérer la réplication de base de données sur de multiples environnements cloisonnés via une synchronisation des wals depuis un S3
+
+Pour l'utiliser, forker le dépôt et modifier le chart helm.
+
+Il est accompagné d'un autre chart helm disponible [ici](https://github.com/cloud-pi-native/mock-data-tooling-minio) permettant d'installer un S3 (minio) avec un certain nombre de buckets créés par défaut.
+
+### INES et Passage 2
+
+Une fois que vous avez validé votre déploiement sur la console DSO d'OVH, la suite logique est de répéter ce procédé au sein du réseau ministériel. Et dépendamment des besoins de votre application, vous aurez besoin ou non de communiquer avec les équipes de Passage2 et d'INES.
+
+Pour vous aider, un mock a été mis en place [ici](https://github.com/cloud-pi-native/helm-projects-mocks/)
+
+## Divers
+
+### Monorepo
+
+Il est aussi possible d'utiliser un monorepo comprenant le code applicatif ainsi que le code d'infrastructure, dans ce cas ajouter ce seul dépôt de code et cocher la case `Dépôt contenant du code d'infrastructure`.
+
+### Accès aux images Harbor
+
+Un secret nommé `registry-pull-secret` est automatiquement créé par la plateforme Cloud Pi Native lors de la création d'un environnement.
+
+Vous pouvez retrouver un exemple d'utilisation de ce secret [ici](https://github.com/cloud-pi-native/exemples_ServiceTeam/blob/main/misc/pull_images_from_harbor/README.md)
+
+### Exemples
+
+Divers code d'exemple écrits par l'équipe Cloud Pi Native sont trouvables [ici](https://github.com/cloud-pi-native/exemples_ServiceTeam/).
+
+Ces exemples se concentrent sur des points précis, comme le monitoring, l'utilisation de sops ou encore l'archivage des logs et sont fréquemment enrichis.
diff --git a/docs/public/img/guide/project/create_project.png b/docs/public/img/guide/project/create_project.png
new file mode 100644
index 0000000..ef20265
Binary files /dev/null and b/docs/public/img/guide/project/create_project.png differ
diff --git a/docs/public/img/guide/project/monprojet_secrets.png b/docs/public/img/guide/project/monprojet_secrets.png
new file mode 100644
index 0000000..c49b541
Binary files /dev/null and b/docs/public/img/guide/project/monprojet_secrets.png differ
diff --git a/docs/public/img/guide/project/monprojet_tableaudebord.png b/docs/public/img/guide/project/monprojet_tableaudebord.png
new file mode 100644
index 0000000..71fd76a
Binary files /dev/null and b/docs/public/img/guide/project/monprojet_tableaudebord.png differ
diff --git a/docs/public/img/guide/project/monprojettuile.png b/docs/public/img/guide/project/monprojettuile.png
new file mode 100644
index 0000000..15f5f13
Binary files /dev/null and b/docs/public/img/guide/project/monprojettuile.png differ
diff --git a/docs/public/img/tuto/1tuto-connexion.png b/docs/public/img/tuto/1tuto-connexion.png
index 3fa7ee0..a57fb5b 100644
Binary files a/docs/public/img/tuto/1tuto-connexion.png and b/docs/public/img/tuto/1tuto-connexion.png differ
diff --git a/docs/public/img/tuto/3tuto-depots.png b/docs/public/img/tuto/3tuto-depots.png
index 4f4b539..50a6405 100644
Binary files a/docs/public/img/tuto/3tuto-depots.png and b/docs/public/img/tuto/3tuto-depots.png differ