Déployer des clusters Kubernetes avec Talos Linux

Talos Linux est un système d'exploitation Linux moderne conçu spécifiquement pour exécuter Kubernetes. Il élimine la complexité des distributions traditionnelles en fournissant un OS minimal, immuable et entièrement géré via une API déclarative. Contrairement aux approches classiques nécessitant SSH et des configurations manuelles, Talos offre une expérience unifiée où chaque aspect du système est contrôlé par des manifestes YAML.

Ne restez pas sur Talos 1.11 ou antérieur

La CVE-2026-31431 (CVSS 7.5) touche toutes les versions antérieures à 1.12.7 et 1.13.0. Un conteneur sans aucun privilège Kubernetes, simplement capable d'être planifié sur un nœud, peut corrompre le cache mémoire d'un binaire partagé du système, obtenir l'exécution de code dans un pod privilégié, puis s'échapper vers l'hôte et accéder aux secrets du nœud. C'est une compromission complète du nœud.

Le correctif est arrivé avec Talos 1.12.7 et 1.13.0. La branche 1.11 n'a plus reçu de mise à jour depuis décembre 2025 et ne recevra pas ce correctif.

Ce guide documente Talos 1.13.6, la version stable actuelle. Si vous opérez un cluster sur une branche antérieure, la montée de version n'est pas une amélioration de confort, c'est un correctif de sécurité.

Ce que vous allez apprendre

Créer un cluster Talos local en moins d'une minute, sans machine virtuelle
Administrer un nœud qui n'a ni SSH, ni shell, ni gestionnaire de paquets
Lire l'état d'un nœud par talosctl, seule voie d'accès
Situer Talos face à kubeadm et aux distributions classiques

Concepts clés de Talos Linux

Pour bien comprendre Talos, il est essentiel de saisir les concepts fondamentaux qui le différencient des approches traditionnelles :

OS immuable : Le système de fichiers racine de Talos est monté en lecture seule. Aucune modification manuelle ne peut altérer l'état du système. Les mises à jour s'effectuent par remplacement complet de l'image système, garantissant qu'un nœud est toujours dans un état connu et reproductible. Cette immuabilité élimine la dérive de configuration qui affecte les systèmes traditionnels où des modifications accumulées au fil du temps créent des différences entre serveurs.
Administration API-driven : Talos ne fournit aucun accès shell (pas de SSH, pas de console). Toute interaction avec le système s'effectue exclusivement via l'API Talos, une API gRPC sécurisée accessible par le client talosctl. Ce modèle garantit que toutes les opérations sont traçables, reproductibles et peuvent être automatisées. Chaque action administrative passe par la même interface, qu'il s'agisse de récupérer des logs, redémarrer un service ou mettre à jour le système.
Machine Config : La configuration complète d'un nœud Talos est définie dans un fichier YAML appelé Machine Config. Ce manifeste déclaratif décrit tous les aspects du nœud : réseau, stockage, kubelet, certificats, utilisateurs API Talos, etc. En appliquant la même Machine Config à plusieurs nœuds, vous obtenez des machines strictement identiques. Cette approche déclarative s'intègre naturellement dans les workflows GitOps.
Bootstrap etcd : Dans un cluster Kubernetes, etcd stocke tout l'état du cluster. Avec Talos, l'initialisation du quorum etcd est simplifiée : vous exécutez une seule commande bootstrap sur le premier control-plane, et les autres nœuds rejoignent automatiquement le cluster. Talos gère la formation du quorum, la distribution des certificats et la configuration réseau nécessaire.
Endpoints et Nodes dans talosctl : La configuration talosctl utilise deux concepts distincts mais complémentaires. Les endpoints définissent les points d'accès à l'API Talos (typiquement des load balancers ou VIPs pour les clusters HA). Les nodes spécifient les machines cibles sur lesquelles exécuter les commandes. Dans un setup local, l'endpoint et le node peuvent être identiques (l'IP du nœud), mais en production, l'endpoint pointe vers un load balancer qui distribue les requêtes API, tandis que les nodes sont les adresses IP réelles des machines. Cette séparation permet d'interroger l'API via un point d'entrée unique (endpoint) tout en ciblant précisément des nœuds spécifiques pour les opérations de maintenance. Vous configurez les endpoints avec talosctl config endpoint <IP> et les nodes avec talosctl config nodes <IP1> <IP2>, ou via les options --endpoints et --nodes en ligne de commande.

Fonctionnalités de Talos Linux

Au-delà des concepts, Talos offre des fonctionnalités techniques concrètes :

Sécurité renforcée : Désactivation totale de SSH, authentification mutuelle TLS pour toutes les communications API, support natif du chiffrement de disque avec TPM2 et KMS
Gestion automatique des certificats : Génération, distribution et rotation automatiques des certificats Kubernetes et Talos sans intervention manuelle
Support multi-plateforme : Déploiement sur bare-metal, cloud public (AWS, Azure, GCP, Outscale), plateformes de virtualisation (Proxmox, VMware, QEMU, Hyper-V) et architectures ARM64
Mises à jour atomiques : Upgrades système et Kubernetes par remplacement complet d'image avec validation de santé automatique et rollback possible
Diagnostics intégrés : Accès aux logs système, métriques, processus et état des services directement via talosctl sans shell
Extensions système : Mécanisme d'extensions pour ajouter des drivers réseau personnalisés, modules de stockage ou agents de monitoring
Mode maintenance : Possibilité de booter un nœud en mode maintenance pour récupération ou débogage avancé
API versionnée : API Talos stable avec versioning sémantique garantissant la compatibilité

Différences avec Kubeadm et autres outils

Pour bien comprendre la valeur ajoutée de Talos, il est utile de le comparer avec kubeadm, l'outil standard de déploiement Kubernetes.

Avec kubeadm, vous installez d'abord une distribution Linux complète (Ubuntu, Debian, Rocky Linux), puis vous ajoutez le runtime de conteneurs (containerd ou CRI-O), et enfin vous exécutez les commandes kubeadm pour initialiser le cluster. Cette approche nécessite :

La gestion des accès SSH pour administrer les machines
L'installation et la maintenance de paquets système
La configuration manuelle de systemd, réseau, firewall
La rotation manuelle des certificats et la gestion des secrets
Des procédures de mise à jour complexes touchant multiple couches

Avec Talos Linux, toute cette complexité disparaît. Le système d'exploitation, le runtime et Kubernetes sont livrés comme une image unique. Il n'y a qu'une seule Machine Config à appliquer pour définir complètement un nœud. Les mises à jour se font atomiquement en remplaçant l'image système complète. Les certificats sont automatiquement gérés et renouvelés.

Cette approche présente plusieurs avantages majeurs :

Reproductibilité parfaite : Deux nœuds avec la même Machine Config sont strictement identiques
Sécurité accrue : Surface d'attaque minimale, pas d'accès shell, audit trail complet via l'API
Simplicité opérationnelle : Une seule interface (talosctl) pour toutes les opérations
Conformité facilitée : Configuration versionnée et revue, état immuable vérifiable
Automatisation native : API gRPC permettant l'intégration avec n'importe quel outil d'orchestration

Prérequis pour le déploiement local

Pour ce guide d'introduction, nous allons déployer un cluster Talos Linux localement avec Docker. Vous aurez besoin de :

Machine hôte Linux
Ressources minimales :
- CPU : 4 cœurs
- RAM : 8 Gio (chaque nœud consomme environ 2 Gio)
- Stockage : 20 Gio d'espace disque libre
Logiciels requis :
- Docker (le provisioner utilisé ici, QEMU n'est pas nécessaire)
- talosctl (client CLI Talos)
- kubectl (client Kubernetes)

Notre cluster de test comprendra :

1 nœud control-plane : 2 vCPU, 2 Gio RAM
1 nœud worker : 2 vCPU, 2 Gio RAM

Installation des outils

Talos fournit une commande intégrée pour créer rapidement un cluster local. Deux provisioners sont disponibles :

docker : Utilise des conteneurs Docker (par défaut, simple et rapide)
qemu : Utilise KVM/QEMU avec des VMs complètes (plus proche de la production mais complexe sous WSL)

Choix du provisioner

Utilisez Docker si :

Vous êtes sous Windows avec WSL2 (setup QEMU très complexe)
Vous voulez démarrer rapidement sans configuration système
Vous avez des ressources limitées

Utilisez QEMU si :

Vous tournez sur Linux natif (Ubuntu, Fedora, Debian, etc.)
Vous voulez une expérience identique à un déploiement production
Vous avez besoin de tester des fonctionnalités bas niveau (réseau, stockage)

Le provisionneur QEMU crée de vraies machines virtuelles avec KVM, ce qui se rapproche des environnements cloud réels. Sous WSL, en revanche, configurer KVM demande des manipulations avancées, virtualisation imbriquée, pilotes et réseau, qui dépassent le cadre de ce guide.

Installation de KVM/QEMU

Pour installer KVM/QEMU sur votre distribution Linux, consultez le guide complet : Maîtriser KVM pour la virtualisation Linux.

Ce guide couvre :

Installation sur Ubuntu/Debian, Fedora/RHEL, Arch Linux
Configuration de libvirt et permissions
Validation du support de virtualisation
Gestion des réseaux virtuels

Installation de Docker

Pour utiliser le provisioner docker (recommandé pour ce guide), vous devez avoir Docker installé sur votre système.

Pour une installation complète selon votre distribution Linux, consultez notre guide détaillé : Maîtriser Docker.

Ce guide couvre :

Installation sur Ubuntu/Debian, Fedora/RHEL, Arch Linux
Configuration sans sudo (groupe docker)
Bonnes pratiques de sécurité
Gestion des réseaux et volumes
Commandes essentielles

Installation de talosctl

talosctl est le client CLI pour interagir avec l'API Talos :

# Installer talosctl depuis un binaire officiel vérifié par SHA256
TALOSCTL_VERSION=v1.13.6
cd /tmp
base="https://github.com/siderolabs/talos/releases/download/${TALOSCTL_VERSION}"
curl -sSfLO "${base}/talosctl-linux-amd64"
curl -sSfLO "${base}/sha256sum.txt"
grep 'talosctl-linux-amd64$' sha256sum.txt | sha256sum -c -
sudo install -m 0755 talosctl-linux-amd64 /usr/local/bin/talosctl

# Vérifier l'installation
talosctl version --client

Activer l'autocomplétion

L'autocomplétion améliore considérablement l'expérience d'utilisation de talosctl en permettant la complétion automatique des commandes, options et ressources.

Pour Bash :

# Générer et installer l'autocomplétion
talosctl completion bash | sudo tee /etc/bash_completion.d/talosctl > /dev/null

# Recharger le shell ou sourcer le fichier
source /etc/bash_completion.d/talosctl

Pour Zsh :

# Créer le dossier de complétion s'il n'existe pas
mkdir -p ~/.zsh/completion

# Générer le fichier de complétion
talosctl completion zsh > ~/.zsh/completion/_talosctl

# Ajouter à votre ~/.zshrc si ce n'est pas déjà fait
echo 'fpath=(~/.zsh/completion $fpath)' >> ~/.zshrc
echo 'autoload -Uz compinit && compinit' >> ~/.zshrc

# Recharger la configuration
source ~/.zshrc

Pour Fish :

# Générer et installer l'autocomplétion
talosctl completion fish > ~/.config/fish/completions/talosctl.fish

# Recharger Fish
source ~/.config/fish/config.fish

Installation de kubectl

kubectl est le client CLI pour interagir avec Kubernetes.

Pour une installation complète et des guides d'utilisation détaillés, consultez notre série de guides : Maîtriser kubectl de A à Z.

Ces guides couvrent :

Installation sur toutes les distributions Linux
Configuration et gestion des contextes
Commandes essentielles et avancées
Plugins et outils complémentaires
Cheat sheet complet

Création du cluster local avec talosctl

C'est ici que Talos surprend le plus agréablement : un cluster complet démarre en moins d'une minute, sans machine virtuelle ni image à préparer. Le provisioner Docker fabrique les nœuds comme des conteneurs, ce qui suffit largement à découvrir le paradigme. Il a une limite qu'il vaut mieux connaître d'avance, détaillée plus bas : il ne crée qu'un seul control-plane.

Création du cluster avec Docker

# Créer un dossier pour le projet
mkdir -p ~/talos-lab
cd ~/talos-lab

# Créer le cluster Talos : 1 control-plane et 1 worker
talosctl cluster create docker \
  --name talos-lab \
  --workers 1

# La commande télécharge l'image Talos et crée les conteneurs
# Comptez environ une minute

Le mot-clé docker après cluster create n'est pas décoratif : il désigne le provisioner. Sans lui, talosctl cluster create bascule sur QEMU, exige les droits root et échoue avec un message déroutant. L'ancien flag --provisioner docker n'existe plus.

Cette commande effectue automatiquement :

Téléchargement de l'image Talos pour Docker
Création d'un réseau Docker bridge pour le cluster
Création de 2 conteneurs (1 control-plane + 1 worker)
Génération des Machine Configs
Application des configs aux nœuds
Bootstrap du cluster etcd
Installation du CNI (Flannel par défaut)

Vous devez voir la progression dans la sortie console. Une fois terminée, le commande affiche un résumé avec les adresses IP des nœuds.

validating CIDR and reserving IPs
generating PKI and tokens
creating state directory in "/home/user/.talos/clusters/talos-lab"
downloading ghcr.io/siderolabs/talos:v1.13.6
creating network talos-lab
creating controlplane nodes
creating worker nodes
waiting for API
bootstrapping cluster
waiting for etcd to be healthy: OK
waiting for etcd members to be consistent across nodes: OK
waiting for etcd members to be control plane nodes: OK
waiting for apid to be ready: OK
waiting for all nodes memory sizes: OK
waiting for all nodes disk sizes: OK
waiting for no diagnostics: OK
waiting for kubelet to be healthy: OK
waiting for all nodes to finish boot sequence: OK
waiting for all k8s nodes to report: OK
waiting for all control plane static pods to be running: OK
waiting for all control plane components to be ready: OK
waiting for all k8s nodes to report ready: OK
waiting for kube-proxy to report ready: OK
waiting for coredns to report ready: OK
waiting for all k8s nodes to report schedulable: OK

merging kubeconfig into "/home/outscale/.kube/config"
renamed cluster "talos-lab" -> "talos-lab-1"
renamed auth info "admin@talos-lab" -> "admin@talos-lab-1"
renamed context "admin@talos-lab" -> "admin@talos-lab-1"
PROVISIONER           docker
NAME                  talos-lab
NETWORK NAME          talos-lab
NETWORK CIDR          10.5.0.0/24
NETWORK GATEWAY       10.5.0.1
NETWORK MTU           1500
KUBERNETES ENDPOINT   https://127.0.0.1:34977

NODES:

NAME                        TYPE           IP         CPU    RAM      DISK
/talos-lab-controlplane-1   controlplane   10.5.0.2   2.00   2.1 GB   -
/talos-lab-worker-1         worker         10.5.0.3   2.00   2.1 GB   -

Création du cluster avec QEMU

Si vous utilisez Linux en natif (pas WSL), vous pouvez utiliser le provisioner QEMU pour une expérience plus proche de la production :

sudo -E talosctl cluster create qemu \
  --name talos-lab \
  --controlplanes 3 \
  --workers 2 \
  --cpus 2 \
  --memory 4096 \
  --disk 20480

Le provisioner QEMU exige les droits root (création des interfaces réseau CNI) et conserve le flag --controlplanes, ce qui en fait la seule voie locale pour obtenir un quorum etcd à trois membres.

Les machines QEMU reproduisent un environnement réel : démarrage UEFI, réseau virtuel et stockage persistant. C'est le montage recommandé pour valider une configuration avant la production.

Vérification du cluster

Une fois la création terminée, vérifiez l'état du cluster :

# La commande talosctl cluster show affiche le résumé du cluster
talosctl cluster show --name talos-lab

# Le fichier talosconfig a été créé automatiquement
export TALOSCONFIG=~/.talos/config

# Configurer les nœuds pour talosctl (requis)
talosctl config nodes 10.5.0.2

# Lister les nœuds via l'API Talos (interroge un seul nœud pour éviter les doublons)
talosctl get members

# Récupérer le kubeconfig
talosctl kubeconfig

# Vérifier les nœuds Kubernetes
kubectl get nodes

Résultat attendu :

NAME                       STATUS   ROLES           AGE   VERSION   OS-IMAGE          CONTAINER-RUNTIME
talos-lab-controlplane-1   Ready    control-plane   48s   v1.36.2   Talos (v1.13.6)   containerd://2.2.5
talos-lab-worker-1         Ready    <none>          48s   v1.36.2   Talos (v1.13.6)   containerd://2.2.5

La colonne OS-IMAGE affiche Talos (v1.13.6) : c'est la signature d'un système où aucun paquet n'a été installé. La version de Kubernetes (v1.36.2) est celle embarquée par défaut dans Talos 1.13.6, vous n'avez rien eu à choisir.

Services Talos disponibles

Talos expose plusieurs services système essentiels via son API. Vous pouvez lister l'état de tous les services sur un nœud :

# Liste complète des services et leur état
talosctl --nodes 10.5.0.2 services

NODE       SERVICE      STATE     HEALTH   LAST CHANGE   LAST EVENT
10.5.0.2   apid         Running   OK       18m55s ago    Health check successful
10.5.0.2   containerd   Running   OK       18m56s ago    Health check successful
10.5.0.2   cri          Running   OK       18m55s ago    Health check successful
10.5.0.2   etcd         Running   OK       18m21s ago    Health check successful
10.5.0.2   kubelet      Running   OK       18m24s ago    Health check successful
10.5.0.2   machined     Running   OK       18m56s ago    Health check successful
10.5.0.2   trustd       Running   OK       18m55s ago    Health check successful

Les services principaux que vous verrez :

apid : API Talos (endpoint gRPC pour toutes les commandes talosctl)
containerd : Moteur de conteneurs (runtime pour Kubernetes et services système)
cri : Interface Container Runtime (implémentation CRI pour kubelet)
etcd : Base de données distribuée du control plane Kubernetes
kubelet : Agent Kubernetes sur chaque nœud
machined : Daemon principal Talos (gestion configuration et séquence boot)
trustd : Service de gestion des certificats et PKI Talos

En cas de dysfonctionnement, vous pouvez interroger l'état de chaque service pour diagnostiquer les problèmes.

Plus loin

Ce type de provisionnement automatisé est idéal pour des environnements de test et de développement. Pour des déploiements en production, nous verrons dans une autre guide comment déployer Talos sur des serveurs bare-metal ou dans le cloud avec des outils comme Terraform et Ansible.

Opérations sur le cluster local

Maintenant que le cluster est opérationnel, explorons les opérations courantes avec Talos. Contrairement aux distributions Linux traditionnelles où vous utiliseriez SSH pour accéder aux machines, Talos fonctionne exclusivement via son API gRPC. Toutes les commandes talosctl communiquent avec l'API Talos sur chaque nœud, garantissant traçabilité et reproductibilité.

Accès aux logs et diagnostics

L'API Talos expose les logs système et les informations de diagnostic sans nécessiter d'accès shell. Le client talosctl se connecte au nœud spécifié via --nodes et interroge l'API pour récupérer les données demandées.

# Messages du noyau
talosctl --nodes 10.5.0.2 dmesg

# État du service etcd
talosctl --nodes 10.5.0.2 service etcd status

# Logs du kubelet sur un des services du control-plane
talosctl --nodes 10.5.0.2 logs kubelet # ou etcd

# Lister les processus en cours
talosctl --nodes 10.5.0.2 ps

Ces commandes sont l'équivalent de journalctl, ps, dmesg et systemctl status d'un Linux classique, à une différence près : elles passent uniquement par l'API sécurisée. Aucun shell n'est exécuté sur le nœud cible.

Tester le déploiement d'une application

Une fois le cluster opérationnel avec son CNI installé, déployons une application pour valider la connectivité réseau entre pods et services.

# Créer un Deployment nginx
kubectl create deployment nginx --image=nginx:alpine --replicas=3

# Exposer via un Service
kubectl expose deployment nginx --port=80 --type=NodePort

# Vérifier les pods
kubectl get pods -o wide

# Accéder au service (récupérer le NodePort)
kubectl get svc nginx
PORT=$(kubectl get svc nginx -o jsonpath='{.spec.ports[0].nodePort}')

# Tester l'accès (depuis l'hôte KVM)
curl http://10.5.0.4:$PORT

Le Service de type NodePort expose l'application sur un port aléatoire (30000-32767) de chaque nœud. Les 3 réplicas nginx sont répartis sur les workers par le scheduler Kubernetes. Le CNI (Flannel ou Cilium) gère le routage réseau entre pods et l'accès externe via NodePort. Nous verrons dans un autre guide comment configurer un Ingress avec un load balancer pour un accès plus avancé.

Nettoyage

Un cluster Talos local ne laisse rien derrière lui, à deux réserves près. La commande de destruction supprime les conteneurs et le réseau, mais votre kubeconfig conserve le contexte et le cluster ajoutés à la création : si vous enchaînez les labs, ces entrées s'accumulent et talosctl renomme les suivantes en -1, -2, ce qui devient vite illisible.

Pour supprimer complètement le cluster :

# Détruire le cluster et nettoyer les ressources
talosctl cluster destroy --name talos-lab

# Les conteneurs Docker sont automatiquement supprimés
# Vérifier qu'il ne reste rien
docker ps -a | grep talos-lab
docker prune -f

Passer en production : cluster multi-AZ

Ce guide vous a permis de découvrir Talos Linux dans un environnement local contrôlé. Pour un déploiement en production sur une infrastructure cloud avec :

Architecture multi-zone hautement disponible
Réseau isolé avec peering
Load balancer HAProxy
Provisionnement Infrastructure as Code avec Terraform
Configurations avancées (chiffrement disque, RBAC, monitoring)

C'est par là : Talos Linux : cluster Kubernetes multi-AZ

À retenir

Un nœud Talos n'a ni SSH, ni shell, ni gestionnaire de paquets. Vérifié en lab : docker exec <nœud> sh échoue sur executable file not found, et bash, /bin/sh, /bin/bash échouent de la même façon.
talosctl est la seule voie d'administration, y compris pour lire un répertoire ou l'état d'un service. Ce n'est pas une restriction de confort, c'est le modèle de sécurité.
Le mot-clé docker après cluster create désigne le provisioner. L'omettre bascule sur QEMU, qui exige les droits root et échoue avec un message qui ne mentionne jamais Docker.
Le provisioner Docker ne crée qu'un seul control-plane, le flag --controlplanes n'existant pas sur cette sous-commande. Un quorum à trois membres demande le provisioner QEMU.
Le réseau local occupe 10.5.0.0/24. Une interface résiduelle sur cette plage bloque le démarrage sans message explicite.
La configuration d'un nœud est un YAML, ce qui rend Talos naturellement compatible avec une gestion en dépôt Git.
Restez au-dessus de 1.12.7 ou 1.13.0 : les versions antérieures portent une faille d'évasion de conteneur à la portée d'un Pod sans aucun privilège.

Ressources officielles

Trois sources valent la peine d'être suivies au-delà de ce guide. La documentation officielle fait référence pour les options de configuration, qui évoluent vite. Sidero Labs, l'éditeur, publie les notes de version où sont annoncés les changements de comportement du CLI. Et les articles de Quentin Joly couvrent des cas d'usage réels que la documentation n'aborde pas.

Contrôle de connaissances

Sept questions sur ce qui rend Talos différent, et sur les deux pièges qui bloquent une première installation : le provisionneur et la plage réseau.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

7 questions

5 min.

80% 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

Pour aller plus loin

Installer avec k0s : Une autre distribution minimaliste, à comparer avec l'approche immuable de Talos.
Backup et Restore : La sauvegarde d'etcd sur un cluster où aucun shell n'est disponible.
Troubleshooting cluster : Le diagnostic d'un cluster quand l'accès se limite à kubectl et talosctl.

Déployer des clusters Kubernetes avec Talos Linux

Ne restez pas sur Talos 1.11 ou antérieur

Ce que vous allez apprendre

Concepts clés de Talos Linux

Fonctionnalités de Talos Linux

Différences avec Kubeadm et autres outils

Prérequis pour le déploiement local

Installation des outils

Choix du provisioner

Installation de KVM/QEMU

Installation de Docker

Installation de talosctl

Activer l'autocomplétion

Installation de kubectl

Création du cluster local avec talosctl

Création du cluster avec Docker

Création du cluster avec QEMU

Vérification du cluster

Services Talos disponibles

Plus loin

Opérations sur le cluster local

Accès aux logs et diagnostics

Tester le déploiement d'une application

Nettoyage

Passer en production : cluster multi-AZ

À retenir

Ressources officielles

Contrôle de connaissances

Contrôle de connaissances

Informations

Vérification

Profil de compétences

Quoi faire maintenant

Pour aller plus loin