diff --git a/content/en/post/tailscale/index.md b/content/en/post/tailscale/index.md
index b9f3444..ab1abe2 100644
--- a/content/en/post/tailscale/index.md
+++ b/content/en/post/tailscale/index.md
@@ -90,7 +90,7 @@ tailscale status
 ℹ️ For Linux users, ensure that Tailscale works well with your DNS configuration: Follow [this documentation](https://tailscale.com/kb/1188/linux-dns/).
 
 {{% notice tip "Sources" %}}
-All the steps performed in this article come from this [**git repository**](https://github.com/Smana/demo-secured-eks).
+All the steps performed in this article come from this [**git repository**](https://github.com/Smana/demo-cloud-native-ref).
 
 It will allow you to create all the components aiming to set up an EKS Lab cluster, following a previous blog post on [Cilium and Gateway API](https://blog.ogenki.io/fr/post/cilium-gateway-api/).
 
@@ -111,7 +111,7 @@ We can then **reach Cloud subnets through Tailscale's VPN**.
 ### 🚀 Deploying a Subnet Router
 
 Let's dive in and deploy a _Subnet router_ on an AWS network!</br>
-Everything is done using the **Terraform** code present in the directory [terraform/network](https://github.com/Smana/demo-secured-eks/tree/main/terraform/network). We will analyze the Tailscale-specific configuration present in the [tailscale.tf](https://github.com/Smana/demo-secured-eks/blob/main/terraform/network/tailscale.tf) file before deploying.
+Everything is done using the **Terraform** code present in the directory [terraform/network](https://github.com/Smana/demo-cloud-native-ref/tree/main/terraform/network). We will analyze the Tailscale-specific configuration present in the [tailscale.tf](https://github.com/Smana/demo-cloud-native-ref/blob/main/terraform/network/tailscale.tf) file before deploying.
 
 #### The Terraform provider
 
@@ -248,7 +248,7 @@ module "tailscale_subnet_router" {
 
 Now that we've examined the various parameters, it's time to **start our Subnet router** 🚀 !! </br>
 
-First, you need to create a `variable.tfvars` file in the [terraform/network](https://github.com/Smana/demo-secured-eks/tree/main/terraform/network) directory.
+First, you need to create a `variable.tfvars` file in the [terraform/network](https://github.com/Smana/demo-cloud-native-ref/tree/main/terraform/network) directory.
 
 ```hcl
 env                 = "dev"
@@ -262,7 +262,7 @@ tailscale = {
 }
 
 tags = {
-  project = "demo-secured-eks"
+  project = "demo-cloud-native-ref"
   owner   = "Smana"
 }
 ```
@@ -381,7 +381,7 @@ In our setup, we already have a _Subnet router_ that routes the entire VPC netwo
 
 To access the Kubernetes API, it's essential to **authorize the Subnet router**. This is accomplished by setting the following rule for the source _security group_.
 
-[terraform/eks/main.tf](https://github.com/Smana/demo-secured-eks/blob/main/terraform/eks/main.tf#L44)
+[terraform/eks/main.tf](https://github.com/Smana/demo-cloud-native-ref/blob/main/terraform/eks/main.tf#L44)
 
 ```hcl
 module "eks" {
@@ -423,7 +423,7 @@ infrastructure      Active   4m1s
 An exposed Kubernetes `Service` is just another AWS network resource 😉. We simply need to ensure that this service uses a **private IP**.
 In my example, I'm using the `Gateway API` to configure Clouder's load balancing, and I encourage you to read my [**previous article**](https://blog.ogenki.io/fr/post/cilium-gateway-api/) on the subject.
 
-All that's needed is to create an internal NLB, ensuring that the `Service` has the annotation `service.beta.kubernetes.io/aws-load-balancer-scheme` set to `internal`. With Cilium Gateway API, this is achieved via the [Kyverno](https://kyverno.io/) [clusterPolicy](https://github.com/Smana/demo-secured-eks/blob/main/security/mycluster-0/platform-gw-clusterpolicy.yaml).
+All that's needed is to create an internal NLB, ensuring that the `Service` has the annotation `service.beta.kubernetes.io/aws-load-balancer-scheme` set to `internal`. With Cilium Gateway API, this is achieved via the [Kyverno](https://kyverno.io/) [clusterPolicy](https://github.com/Smana/demo-cloud-native-ref/blob/main/security/mycluster-0/platform-gw-clusterpolicy.yaml).
 
 ```yaml
           metadata:
diff --git a/content/fr/post/tailscale/index.md b/content/fr/post/tailscale/index.md
index 4f43a88..64e87bc 100644
--- a/content/fr/post/tailscale/index.md
+++ b/content/fr/post/tailscale/index.md
@@ -91,7 +91,7 @@ tailscale status
 ℹ️ Pour les utilisateurs de Linux, vérifier que Tailscale fonctionne bien avec votre configuration DNS: Suivre [cette documentation](https://tailscale.com/kb/1188/linux-dns/).
 
 {{% notice tip "Les sources" %}}
-Toutes les étapes réalisées dans cet article proviennent de ce [**dépôt git**](https://github.com/Smana/demo-secured-eks)
+Toutes les étapes réalisées dans cet article proviennent de ce [**dépôt git**](https://github.com/Smana/demo-cloud-native-ref)
 
 Il va permettre de créer l'ensemble des composants qui ont pour objectif d'obtenir un cluster EKS de Lab et font suite à un précédent article sur [Cilium et Gateway API](https://blog.ogenki.io/fr/post/cilium-gateway-api/).
 
@@ -113,7 +113,7 @@ Nous pouvons alors **router des sous réseaux du Clouder à travers le VPN de Ta
 ### 🚀 Déployer un Subnet router
 
 Entrons dans le vif du sujet et deployons un _Subnet router_ sur un réseau AWS!</br>
-Tout est fait en utilisant le code **Terraform** présent dans le répertoire [terraform/network](https://github.com/Smana/demo-secured-eks/tree/main/terraform/network). Nous allons analyser la configuration spécifique à Tailscale qui est présente dans le fichier [tailscale.tf](https://github.com/Smana/demo-secured-eks/blob/main/terraform/network/tailscale.tf) avant de procéder au déploiement.
+Tout est fait en utilisant le code **Terraform** présent dans le répertoire [terraform/network](https://github.com/Smana/demo-cloud-native-ref/tree/main/terraform/network). Nous allons analyser la configuration spécifique à Tailscale qui est présente dans le fichier [tailscale.tf](https://github.com/Smana/demo-cloud-native-ref/blob/main/terraform/network/tailscale.tf) avant de procéder au déploiement.
 
 #### Le provider Terraform
 
@@ -247,7 +247,7 @@ module "tailscale_subnet_router" {
 
 Maintenant que nous avons analysé les différents paramètres, il est temps de **démarrer notre Subnet router** 🚀 !! </br>
 
-Il faut au préalable créer un fichier `variable.tfvars` dans le répertoire [terraform/network](https://github.com/Smana/demo-secured-eks/tree/main/terraform/network).
+Il faut au préalable créer un fichier `variable.tfvars` dans le répertoire [terraform/network](https://github.com/Smana/demo-cloud-native-ref/tree/main/terraform/network).
 
 ```hcl
 env                 = "dev"
@@ -261,7 +261,7 @@ tailscale = {
 }
 
 tags = {
-  project = "demo-secured-eks"
+  project = "demo-cloud-native-ref"
   owner   = "Smana"
 }
 ```
@@ -419,7 +419,7 @@ infrastructure      Active   4m1s
 Un `Service` Kubernetes exposé est une resource AWS comme une autre 😉. Il faut juste s'assurer que ce service utilise bien une **IP privée**.
 Dans mon exemple j'utilise `Gateway API` pour configurer la répartition de charge du Clouder et je vous invite à lire mon [**précédent article**](https://blog.ogenki.io/fr/post/cilium-gateway-api/) sur le sujet.
 
-Il suffirait donc  de créer un NLB interne en s'assurant que le `Service` ait bien l'annotation `service.beta.kubernetes.io/aws-load-balancer-scheme` ayant pour valeur `internal`. Dans le cas de Gateway API, cela se fait via la [clusterPolicy](https://github.com/Smana/demo-secured-eks/blob/main/security/mycluster-0/platform-gw-clusterpolicy.yaml) [Kyverno](https://kyverno.io/).
+Il suffirait donc  de créer un NLB interne en s'assurant que le `Service` ait bien l'annotation `service.beta.kubernetes.io/aws-load-balancer-scheme` ayant pour valeur `internal`. Dans le cas de Gateway API, cela se fait via la [clusterPolicy](https://github.com/Smana/demo-cloud-native-ref/blob/main/security/mycluster-0/platform-gw-clusterpolicy.yaml) [Kyverno](https://kyverno.io/).
 
 ```yaml
           metadata: