Protéger les Secrets d'un cluster Kubernetes

Un Secret Kubernetes n'est protégé par rien d'autre que ce que vous configurez autour de lui : par défaut, l'API server (le composant qui reçoit toutes les requêtes du cluster) l'écrit en clair dans etcd (la base où le cluster garde son état), et tout compte qui a le droit get sur secrets le lit. Cette leçon, pour une personne qui administre ou déploie sur un cluster, installe les trois protections d'un cluster réel : le chiffrement au repos dans etcd, un RBAC qui limite la lecture, et le montage en volume. Elle s'arrête ensuite sur les outils externes (External Secrets Operator, CSI Secrets Store, Sealed Secrets, SOPS) et sur le critère qui permet de choisir.

Ce que vous allez apprendre

• Prouver qu'un Secret est lisible en clair dans etcd, puis activer le chiffrement au repos et constater le changement
• Limiter la lecture d'un Secret à un ServiceAccount précis et le vérifier avec kubectl auth can-i
• Réduire l'exposition dans le Pod : volume plutôt que variable d'environnement, Pod privilégié interdit
• Synchroniser un Secret depuis un coffre externe avec External Secrets Operator
• Décider quand choisir CSI Secrets Store, Sealed Secrets ou SOPS, et reconnaître ce que chaque protection ne couvre pas
• Répondre aux exigences SOCLE-SEC-STO-1 (secrets chiffrés au repos), SOCLE-SEC-GEN-3 (accès scopés ; le traçage relève de l'audit) et SOCLE-CLD-K8S-10 (coffre externe et montage en fichiers ; la rotation qu'elle exige reste hors de cette leçon)

Prérequis

Cette leçon prolonge Les Secrets, qui explique ce qu'est un Secret, pourquoi le base64 n'est qu'un encodage, les types de Secrets et l'injection par variable ou par volume. Elle ne les redit pas. Vous devez aussi avoir lu RBAC Kubernetes (rôles et liaisons) et savoir ce qu'est etcd.

Pour rejouer les manipulations, il faut Docker, kind 0.33 ou plus, kubectl, helm (voir la formation Helm) et l'utilitaire strings (paquet binutils sous Linux). La lecture d'etcd par kubectl exec et etcdctl est celle de la leçon etcd. Le cluster de test est jetable et se supprime à la fin.

Où un Secret est-il exposé, et qui le protège ?

Un Secret traverse quatre maillons entre sa création et son usage : l'API server, etcd, le kubelet (l'agent de chaque nœud) et le Pod. Chaque protection ne couvre que certains d'entre eux. Le schéma suit ce trajet : l'API server filtre les lecteurs avec le RBAC, écrit la valeur dans etcd (là joue le chiffrement au repos), puis le kubelet la monte dans le Pod en tmpfs, un système de fichiers en mémoire. Le coffre externe, en pointillé, a deux entrées : External Secrets Operator alimente l'API server à la place d'une saisie manuelle, tandis que le CSI Driver monte la valeur directement dans le Pod, sans passer par l'API server ni par etcd.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Le base64 ne protège aucun de ces maillons : il se décode en une commande, comme le montre la leçon de base. Un maillon s'oublie facilement : la sauvegarde d'etcd contient tous les Secrets, et quiconque la lit les obtient sans passer par l'API. Le chiffrement au repos est la parade à ce cas.

Comment chiffrer les Secrets au repos dans etcd ?

Le chiffrement au repos (encryption at rest) demande à l'API server de chiffrer chaque Secret avant de l'écrire dans etcd. Il se déclare dans un fichier EncryptionConfiguration que l'API server lit au démarrage. La liste providers est ordonnée : le premier fournisseur chiffre les nouvelles écritures, tous servent à relire. C'est ce qui permet de passer d'un état à l'autre sans casser les Secrets existants.

Les étapes ci-dessous créent un cluster kind dont l'API server lit un fichier de configuration qui ne chiffre encore rien (identity en premier, c'est-à-dire aucun chiffrement), constatent la fuite, puis basculent sur secretbox, un chiffrement authentifié de la bibliothèque NaCl. La leçon de base montre aescbc : l'ordre des fournisseurs et la réécriture des Secrets sont les mêmes quel que soit le fournisseur choisi.

Créer le cluster de test

Travaillez dans un dossier vide et gardez le même terminal jusqu'au bout : la variable KEY et la fonction etcd_get définies plus bas n'existent que dans lui. La clé de 32 octets se génère localement, et le fichier est monté dans le nœud de contrôle. L'option encryption-provider-config-automatic-reload évite de redémarrer l'API server quand le fichier change : sans elle, la modification serait lue au prochain démarrage seulement.

mkdir secrets-lab && cd secrets-lab
KEY=$(head -c 32 /dev/urandom | base64)

cat > enc.yaml <<EOF
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - identity: {}
      - secretbox:
          keys:
            - name: key1
              secret: $KEY
EOF

cat > kind.yaml <<EOF
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
    extraMounts:
      - hostPath: $PWD/enc.yaml
        containerPath: /etc/kubernetes/enc/encryption-config.yaml
    kubeadmConfigPatches:
      - |
        kind: ClusterConfiguration
        apiServer:
          extraArgs:
            - name: encryption-provider-config
              value: /etc/kubernetes/enc/encryption-config.yaml
            - name: encryption-provider-config-automatic-reload
              value: "true"
          extraVolumes:
            - name: enc
              hostPath: /etc/kubernetes/enc
              mountPath: /etc/kubernetes/enc
              readOnly: true
              pathType: DirectoryOrCreate
EOF

kind create cluster --name sec-lab --config kind.yaml \
  --image kindest/node:v1.37.0@sha256:a1ed56cfb0e7b93589bdf97c8cd566405a265939e3620fc4f5de89adff580ae5

La dernière ligne de la sortie de kind doit afficher Have a nice day!. Si la création échoue avec une erreur sur kubeadm.k8s.io/v1beta3, votre kind est trop ancien : kind version doit rendre 0.33 ou plus (le format v1beta4 est géré dès la 0.32, mais c'est la 0.33 qui publie l'image v1.37.0 utilisée ici), et le digest de l'image garantit qu'on rejoue le même nœud.

Constater que la valeur est lisible dans etcd

Créez un Secret, puis lisez-le directement dans etcd avec etcdctl, l'outil client d'etcd, présent dans le Pod etcd-sec-lab-control-plane. La fonction ci-dessous évite de répéter les trois certificats que etcdctl exige.

kubectl create secret generic db-credentials \
  --from-literal=password='S3cr3t-Zeta'

etcd_get() {
  kubectl -n kube-system exec etcd-sec-lab-control-plane -- etcdctl \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/server.crt \
    --key=/etc/kubernetes/pki/etcd/server.key \
    get "$1" --print-value-only
}

etcd_get /registry/secrets/default/db-credentials | strings | grep S3cr3t

Sortie

S3cr3t-Zeta

La valeur apparaît telle quelle. Quiconque lit le disque du nœud de contrôle, ou une sauvegarde d'etcd, obtient le mot de passe sans passer par l'API ni par le RBAC.

Basculer sur secretbox

Réécrivez le fichier en plaçant secretbox en premier : il chiffrera les nouvelles écritures, tandis que identity reste en dernier pour relire les anciennes valeurs encore en clair. Utilisez bien cat > (qui écrit dans le même fichier) et non mv : le nœud a monté ce fichier précis, et un fichier remplacé par un autre n'est pas vu depuis le conteneur.

cat > enc.yaml <<EOF
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - secretbox:
          keys:
            - name: key1
              secret: $KEY
      - identity: {}
EOF

L'API server recharge le fichier seul, mais pas instantanément : il le relit toutes les minutes, donc attendez deux minutes. Créez ensuite un second Secret et regardez son préfixe dans etcd, qui nomme le fournisseur et la clé utilisés.

sleep 120
kubectl create secret generic api-token --from-literal=token='Tok-Omega-42'
etcd_get /registry/secrets/default/api-token | head -c 26; echo

Sortie

k8s:enc:secretbox:v1:key1:

Le préfixe k8s:enc:secretbox:v1:key1: prouve que la valeur est chiffrée. Si vous lisez encore k8s suivi d'octets illisibles et du mot Secret, l'ancien état est toujours actif : patientez et recréez un Secret.

Chiffrer les Secrets déjà présents

Le changement ne touche que les nouvelles écritures. db-credentials, créé avant, est toujours en clair dans etcd. Il faut le réécrire pour qu'il passe par le nouveau fournisseur : relire tous les Secrets puis les remplacer suffit, et c'est la méthode donnée par la documentation Kubernetes.

kubectl get secrets -A -o json | kubectl replace -f -
etcd_get /registry/secrets/default/db-credentials | head -c 26; echo
etcd_get /registry/secrets/default/db-credentials | strings | grep -c S3cr3t

Sortie

k8s:enc:secretbox:v1:key1:
0

Le premier résultat montre le préfixe, le second zéro occurrence de la valeur. Côté API, rien ne change pour les utilisateurs : kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d rend toujours S3cr3t-Zeta, car l'API server déchiffre à la lecture.

Clé locale ou KMS : où vit la clé de chiffrement ?

Avec secretbox, la clé est dans le fichier posé sur le nœud de contrôle, comme dans cet exercice. Elle protège contre la lecture d'etcd ou d'une sauvegarde, pas contre quelqu'un qui est déjà root sur le nœud de contrôle : il lit aussi le fichier de clé. Pour séparer la clé des données, Kubernetes propose le fournisseur KMS (Key Management Service), où l'API server confie le chiffrement à un coffre de clés externe (KMS du cloud, Vault), selon le principe du chiffrement en enveloppe expliqué dans Le chiffrement des secrets. Sur un cluster managé, ce réglage est celui du fournisseur, et c'est à vous de vérifier dans sa documentation qu'il est actif. Un secretbox à clé locale ne vaut donc pas preuve de SOCLE-CLD-K8S-8, qui exige un fournisseur KMS ; cette leçon ne déclare pas cette exigence.

Comment limiter qui lit les Secrets avec RBAC ?

Le chiffrement protège le disque, pas l'API : un compte autorisé à lire reçoit la valeur déchiffrée. C'est le RBAC qui décide qui lit. Le principe est celui du moindre privilège : un Role qui donne le verbe get sur un Secret nommé (--resource-name en ligne de commande, champ resourceNames dans le YAML), lié à un seul ServiceAccount (l'identité d'un Pod), et rien d'autre. Un Role ne vaut que dans son namespace : séparer les environnements par namespace, ici production, empêche un compte de développement de lire les Secrets de production, tant qu'aucun ClusterRoleBinding ne lui donne ce droit partout.

kubectl create namespace production
kubectl -n production create secret generic app-db --from-literal=password=x
kubectl -n production create secret generic other --from-literal=k=v
kubectl -n production create serviceaccount my-app
kubectl -n production create role app-secrets-reader \
  --verb=get --resource=secrets --resource-name=app-db
kubectl -n production create rolebinding app-secrets-reader \
  --role=app-secrets-reader --serviceaccount=production:my-app

kubectl auth can-i demande à l'API server si une identité a un droit, en usurpant cette identité avec --as. Quatre vérifications suffisent à prouver le périmètre : la lecture du Secret autorisé, le refus sur un autre Secret, le refus de list, et l'erreur Forbidden réelle.

S=--as=system:serviceaccount:production:my-app
kubectl auth can-i get secret/app-db -n production $S
kubectl auth can-i get secret/other  -n production $S
kubectl auth can-i list secrets      -n production $S
kubectl -n production get secret other $S

Sortie

yes
no
no
Error from server (Forbidden): secrets "other" is forbidden: User "system:serviceaccount:production:my-app" cannot get resource "secrets" in API group "" in the namespace "production"

Deux pièges expliquent l'essentiel des fuites. Le verbe list (et watch) sur secrets renvoie le contenu de tous les Secrets du namespace, pas seulement leurs noms : ne l'accordez jamais à un compte applicatif. Et le droit de créer un Pod dans un namespace équivaut à lire ses Secrets, puisque le Pod peut en monter un : limitez-le autant que la lecture. Pour savoir qui a lu quoi, activez l'audit, décrit dans Audit logs Kubernetes.

Comment réduire l'exposition dans le Pod et sur le nœud ?

Une fois le Secret sorti de l'API, la dernière exposition est le Pod. Une variable d'environnement se retrouve dans /proc/<pid>/environ, dans les sorties de débogage et dans les traces d'erreur de beaucoup de frameworks. Un volume monte la valeur en fichier tmpfs, avec des droits fixés par defaultMode, et la met à jour sans redémarrer le Pod (une variable d'environnement, elle, ne change qu'au redémarrage). Préférez donc le volume, comme l'explique la leçon de base.

Le volume protège le disque du nœud, pas le processus : un conteneur compromis lit ses propres fichiers. Un conteneur privileged: true peut s'évader vers le nœud, et atteindre alors les Secrets montés sur ce nœud ainsi que les identifiants du kubelet. Interdisez-le avec les Pod Security Standards et appliquez le Security Context au Pod.

Comment synchroniser un coffre externe avec External Secrets Operator ?

External Secrets Operator (ESO) est un contrôleur qui lit une valeur dans un coffre externe et crée le Secret Kubernetes correspondant. Dans ce rôle, il copie ce qui existe dans le coffre : il n'y crée aucune valeur et ne la fait pas tourner. Deux ressources le pilotent. Le SecretStore dit où et comment se connecter au coffre (il ne vaut que pour son namespace, et sa variante ClusterSecretStore sert tout le cluster) ; l'ExternalSecret dit quelle clé lire et quel Secret créer. Avec un vrai coffre, votre dépôt Git ne contient que ces descriptions, jamais la valeur.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

L'exercice utilise le fournisseur fake d'ESO, un coffre factice défini dans le SecretStore lui-même : il permet de rejouer la chaîne complète sans compte cloud ni serveur Vault. Il sert à la démonstration uniquement. Pour un coffre réel, remplacez le bloc fake par vault, aws ou un autre fournisseur, dont l'authentification est détaillée dans le guide HashiCorp Vault.

1. Installer ESO en version 2.13.0

   Le chart déploie le contrôleur, un webhook de validation et les définitions de ressources personnalisées (CRD) qui ajoutent SecretStore et ExternalSecret à l'API.

   helm repo add external-secrets https://charts.external-secrets.io
   helm install external-secrets external-secrets/external-secrets \
     --version 2.13.0 -n external-secrets --create-namespace --wait
   kubectl -n external-secrets get pods

   Les trois Pods (external-secrets, cert-controller, webhook) doivent être 1/1 Running.

2. Déclarer le coffre et la synchronisation

   Enregistrez ce manifeste sous eso.yaml. refreshInterval fixe la fréquence à laquelle ESO relit le coffre.

   eso.yaml

   apiVersion: external-secrets.io/v1
   kind: SecretStore
   metadata:
     name: coffre-factice
     namespace: production
   spec:
     provider:
       fake:
         data:
           - key: /production/db
             value: "Zeta-Mot-De-Passe-1"
   ---
   apiVersion: external-secrets.io/v1
   kind: ExternalSecret
   metadata:
     name: db-credentials
     namespace: production
   spec:
     refreshInterval: 1m
     secretStoreRef:
       name: coffre-factice
       kind: SecretStore
     target:
       name: db-credentials
       creationPolicy: Owner
     data:
       - secretKey: password
         remoteRef:
           key: /production/db

   kubectl apply -f eso.yaml

   ESO affiche un avertissement : le fournisseur fake n'est plus maintenu, ce qui est attendu pour une démonstration. Le même avertissement revient à chaque commande qui modifie le SecretStore.

3. Vérifier la synchronisation

   kubectl -n production get externalsecret
   kubectl -n production get secret db-credentials \
     -o jsonpath='{.data.password}' | base64 -d; echo

   Sortie

   NAME             STORETYPE     STORE            REFRESH INTERVAL   STATUS         READY   LAST SYNC
   db-credentials   SecretStore   coffre-factice   1m                 SecretSynced   True    8s
   Zeta-Mot-De-Passe-1

4. Changer la valeur côté coffre et forcer la relecture

   La source change, le Secret suit. Sans l'annotation, ESO attend le prochain refreshInterval.

   kubectl -n production patch secretstore coffre-factice --type=json \
     -p '[{"op":"replace","path":"/spec/provider/fake/data/0/value","value":"Zeta-Mot-De-Passe-2"}]'
   kubectl -n production annotate externalsecret db-credentials \
     force-sync=$(date +%s) --overwrite
   sleep 6
   kubectl -n production get secret db-credentials \
     -o jsonpath='{.data.password}' | base64 -d; echo

   Sortie

   Zeta-Mot-De-Passe-2

Gardez à l'esprit ce que cette mécanique ne fait pas. ESO synchronise, il ne fait pas de rotation : générer un nouveau mot de passe et révoquer l'ancien reste le travail du coffre. Et le Secret créé est un Secret natif, stocké dans etcd : le chiffrement au repos et le RBAC des sections précédentes s'y appliquent toujours.

Quand choisir CSI Secrets Store, Sealed Secrets ou SOPS ?

Ces trois outils couvrent ce qu'ESO ne fait pas, ou le font autrement : le CSI Driver est une alternative à ESO quand la valeur ne doit pas passer par etcd, Sealed Secrets et SOPS règlent un autre problème. Chacun se reconnaît à la question qu'il règle : où la valeur est-elle lue, et dans quel état voyage-t-elle jusqu'au cluster ?

Le Secrets Store CSI Driver (version 1.6.1 au 18 octobre 2026) monte la valeur directement depuis le coffre dans le Pod, sous forme de fichiers tmpfs, sans passer par un objet Secret. Il s'appuie sur un DaemonSet (un Pod par nœud) et sur un provider par coffre. Son intérêt est que la valeur n'est pas stockée dans etcd, donc pas exposée à kubectl get secret (tant que vous n'activez pas la synchronisation facultative en Secret, qui recrée un objet dans etcd) ; son prix est que l'application doit relire le fichier quand la valeur change, et qu'il ne redémarre aucun Pod.

La rotation du contenu monté est désactivée par défaut : elle s'active avec --enable-secret-rotation=true (enableSecretRotation=true dans le chart Helm), avec un intervalle par défaut de 2 minutes.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

Sealed Secrets et SOPS règlent un autre problème : versionner un Secret dans Git sans exposer la valeur, en pratique GitOps (le dépôt Git décrit l'état du cluster, un outil l'applique). Avec Sealed Secrets, un contrôleur du cluster détient la clé privée et seul lui sait déchiffrer le SealedSecret que vous commitez ; le guide Sealed Secrets avec Kubeseal détaille l'installation et l'usage. Avec SOPS, vous chiffrez les fichiers eux-mêmes ; le guide SOPS couvre l'outil et celui de Flux CD avec SOPS montre un déchiffrement fait par le cluster. Dans les deux cas, le Secret obtenu dans le cluster reste un Secret natif : chiffrement etcd et RBAC restent nécessaires.

Quel outil pour quel besoin ?

Le critère de choix principal n'est pas le niveau de sécurité de l'outil, mais ce que votre application sait faire de la valeur et où vit la source de vérité. Une même organisation combine souvent plusieurs lignes : le socle (chiffrement etcd, RBAC strict, audit) s'applique toujours.

Situation	Choix
Un seul cluster, peu de Secrets, pas de coffre	Secrets natifs, chiffrement etcd, RBAC strict, audit
Un coffre existant (Vault, cloud) et une application qui ne sait lire qu'une variable d'environnement	External Secrets Operator
La valeur ne doit pas être dans etcd et l'application relit un fichier	CSI Secrets Store, sans synchronisation vers un Secret
Des manifestes de Secrets à versionner dans Git, pas de coffre	Sealed Secrets ou SOPS
Plusieurs namespaces alimentés par le même coffre	External Secrets Operator avec un ClusterSecretStore, déclaré une seule fois
Plusieurs clusters alimentés par le même coffre	Un External Secrets Operator dans chaque cluster, tous pointés sur ce coffre
Des identifiants éphémères, générés à la demande	Un coffre qui génère (Vault), exposé par ESO ou le CSI Driver
Vault déjà en place et une injection par Pod, sans objet Secret	Vault Agent Injector (sidecar décrit dans le guide HashiCorp Vault), à comparer au CSI Driver

Glissez pour voir

Une application qui lit sa configuration une seule fois au démarrage ne profite pas d'un montage rechargé à chaud : il faut alors redéployer le Pod quand la valeur change. L'identité qui permet au cluster de s'authentifier auprès du coffre sans mot de passe stocké relève de l'identité machine et du workload identity.

Dépannage : que faire quand la protection ne se voit pas ?

Les échecs de cette leçon sont silencieux : rien ne casse, la protection est simplement absente. Le tableau relie chaque symptôme à sa cause probable et à la commande qui la lève.

Symptôme	Cause probable	Solution
Un Secret créé après le changement est encore en clair dans etcd	L'API server n'a pas rechargé le fichier	Attendre une minute de plus, puis vérifier que l'option figure dans le manifeste de l'API server : docker exec sec-lab-control-plane grep encryption-provider /etc/kubernetes/manifests/kube-apiserver.yaml
Les anciens Secrets sont en clair malgré secretbox en tête	Seules les nouvelles écritures sont chiffrées	kubectl get secrets -A -o json | kubectl replace -f -
Le fichier modifié n'est pas pris en compte	Il a été remplacé (mv, éditeur) au lieu d'être réécrit	Recréer le cluster : le nœud garde le montage de l'ancien fichier (l'ancien inode), et réécrire le nouveau avec cat > n'y change rien
kubectl auth can-i répond yes à list secrets	Un autre Role ou ClusterRole accorde ce droit	kubectl auth can-i --list --as=system:serviceaccount:production:my-app -n production liste ses droits ; kubectl get rolebindings,clusterrolebindings -A retrouve la liaison
L'ExternalSecret reste SecretSyncedError	Le SecretStore est invalide ou la clé distante absente	kubectl -n production describe externalsecret db-credentials

Glissez pour voir

Nettoyer le cluster de test

Supprimez le cluster kind et le dossier de travail, qui contient la clé de chiffrement de l'exercice : cette clé ne protège plus rien, mais ne la réutilisez jamais ailleurs.

kind delete cluster --name sec-lab
cd .. && rm -rf secrets-lab

À retenir

1. Un Secret est en clair dans etcd par défaut : une lecture directe du disque ou d'une sauvegarde le révèle
2. Le chiffrement au repos se déclare par EncryptionConfiguration : le premier fournisseur chiffre les nouvelles écritures, tous servent à relire, et kubectl get secrets -A -o json | kubectl replace -f - chiffre l'existant
3. La clé locale ne protège pas d'un accès root au nœud de contrôle : le KMS sépare la clé des données
4. RBAC décide qui lit : get sur un Secret nommé, jamais list pour une application, et le droit de créer un Pod vaut lecture
5. Le volume expose moins qu'une variable d'environnement, mais ne protège pas d'un conteneur compromis
6. ESO synchronise, il ne fait pas de rotation, et le Secret créé reste dans etcd ; le CSI Secrets Store évite etcd mais exige une application qui relit son fichier
7. Sealed Secrets et SOPS protègent le Secret dans Git, pas dans le cluster
8. Preuve attendue (SOCLE-SEC-STO-1 ; en partie seulement SOCLE-CLD-K8S-10 et SOCLE-SEC-GEN-3) : le préfixe k8s:enc: lu dans etcd, un kubectl auth can-i négatif et des Secrets fournis par ESO ou le CSI Driver. Trois réserves, à connaître avant de déclarer une exigence tenue : SOCLE-CLD-K8S-10 demande aussi des secrets tournés, ce que cette leçon ne couvre pas (ESO synchronise sans tourner, la rotation du CSI est désactivée par défaut) et sa démonstration s'appuie sur un coffre factice ; le traçage des lectures relève de l'audit ; et secretbox ne prouve pas SOCLE-CLD-K8S-8, qui exige un KMS

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →