Incus 6 LTS — gérer conteneurs système et VMs Linux pour PME ouest-africaine 2026

Mise à jour avril 2026. Le projet Incus, fork communautaire de LXD lancé par Linux Containers en 2023 après la reprise de LXD par Canonical, s’est imposé en deux ans comme la référence pour piloter conteneurs système et machines virtuelles sur un même hôte Linux. La branche Incus 6 LTS, publiée par l’équipe officielle de linuxcontainers.org, apporte aux PME ouest-africaines une alternative robuste, libre, sans coût de licence, capable de remplacer Proxmox VE ou même certains usages VMware sur un parc de serveurs modeste.

Pour un développeur ou un sysadmin à Dakar, Abidjan ou Cotonou, la promesse est simple : héberger plusieurs dizaines d’environnements isolés — sites WordPress, bases de données, runners CI, environnements clients — sur un seul VPS de quelques euros par mois, avec une isolation forte, des sauvegardes nettes et un démarrage en moins de deux secondes par instance. Cet article fait le tour complet : ce qu’est Incus, comment il se compare à ses concurrents, comment il s’installe, ce qu’il sait faire en réseau, stockage et clustering, et comment l’adapter à la réalité de notre marché.

Sommaire

• D’où vient Incus et pourquoi il existe
• Concepts fondamentaux : instances, profils, projets, réseau, stockage
• Incus face à Docker, Proxmox, LXD et Kubernetes
• Installer Incus sur Ubuntu, Debian, Fedora, Arch
• Premiers pas : créer, exécuter, supprimer une instance
• Réseau et stockage : ce qui distingue Incus
• Conteneurs système et machines virtuelles côte à côte
• Clustering : haute disponibilité avec 3 nœuds
• Projets et multi-tenant : architecture SaaS
• Tous les tutoriels Incus de ce site
• Adaptation au contexte ouest-africain
• Erreurs fréquentes à éviter
• FAQ

D’où vient Incus et pourquoi il existe

L’histoire récente est utile à connaître pour comprendre l’écosystème actuel. LXD avait été créé en 2014 par Canonical pour proposer une couche d’orchestration au-dessus de LXC. En juillet 2023, Canonical a déplacé LXD hors de l’organisation Linux Containers, signal d’une trajectoire produit plus alignée avec sa stratégie commerciale. Stéphane Graber, mainteneur historique du projet, a quitté Canonical et lancé Incus comme fork communautaire, hébergé par Linux Containers, qui maintient également LXC, LXCFS et distrobuilder.

Deux ans plus tard, Incus a dépassé son ancêtre sur plusieurs aspects : support natif des images OCI (donc Docker Hub directement), gestion du réseau OVN intégrée pour les architectures distribuées, prise en charge des machines virtuelles via QEMU avec UEFI, Secure Boot et TPM virtuel, et un cycle de release LTS aligné sur les besoins entreprise. Les distributions ont suivi : Debian 13, Ubuntu 24.04 LTS et plus récentes, Fedora et Arch fournissent désormais des paquets officiels. Pour les versions Ubuntu LTS antérieures (22.04) ou Debian 11/12, l’équipe Zabbly publie des dépôts maintenus à jour, recommandés par la documentation officielle.

L’enjeu pour une PME ouest-africaine n’est pas anecdotique. Là où Proxmox VE impose un ISO complet et une logique d’hyperviseur dédié, Incus s’installe sur un hôte Linux existant — typiquement votre VPS Ubuntu — et coexiste avec les services qui tournent déjà. Là où Kubernetes demande trois plans de contrôle, etcd et un investissement minimal de 8 Go de RAM par nœud, Incus tourne confortablement sur un VPS à 2 Go. Là où Docker isole peu et exige un service par conteneur, Incus offre des conteneurs système complets (systemd intégré, plusieurs services par conteneur, ssh, cron, le tout fonctionnel comme une vraie machine).

Concepts fondamentaux : instances, profils, projets, réseau, stockage

Cinq notions reviennent en permanence dans Incus. Les comprendre une fois suffit à manipuler tout le reste sans panique.

Instance

C’est l’objet de base. Une instance peut être un conteneur (partage le noyau de l’hôte, démarre en moins d’une seconde, consomme quelques mégaoctets de RAM au repos) ou une machine virtuelle (noyau dédié, isolation matérielle, capable de lancer Windows ou un kernel custom). Dans les deux cas, on les manipule avec les mêmes commandes : incus launch, incus start, incus stop, incus shell. Le type est précisé à la création avec --vm.

Profil

Un profil est un patron de configuration appliqué à une ou plusieurs instances. Il contient les limites CPU/RAM, les périphériques (disque racine, carte réseau, GPU, USB), les variables d’environnement, les options cloud-init. Une instance hérite par défaut du profil default, et on peut en empiler plusieurs : un profil web-server qui ouvre les ports HTTP/HTTPS, un profil backup-target qui monte un volume sauvegarde. Ce mécanisme évite de répéter la configuration sur chaque instance et facilite la cohérence sur un parc.

Projet

Un projet est une cloison logique qui isole un ensemble d’instances, profils, images, réseaux, stockages. Pour un freelance qui héberge cinq clients sur le même VPS, créer un projet par client garantit qu’aucune confusion ne peut survenir : les listes incus list ne montrent que les instances du projet courant, et les quotas se définissent au niveau du projet (par exemple : maximum 10 instances et 50 Go de stockage pour le client X).

Réseau

Incus crée par défaut un réseau bridge nommé incusbr0 avec NAT et DHCP intégré. Au-delà, il sait gérer des bridges custom, des VLANs, du macvlan (instances avec IP publique directe), et surtout OVN (Open Virtual Network) pour les architectures distribuées avec micro-segmentation, ACL applicatives et load balancing natif. Pour la majorité des PME, incusbr0 et un reverse-proxy Caddy ou Nginx sur l’hôte suffisent.

Stockage

Le stockage est organisé en pools. Chaque pool s’appuie sur un driver : dir (le plus simple, dossier sur l’hôte), btrfs, zfs, lvm-thin, ceph, cephfs, ou powerflex/pure-storage en entreprise. Le choix du driver impacte directement la rapidité des snapshots et la facilité des sauvegardes. Pour un VPS unique, ZFS est le compromis qu’on recommande systématiquement : snapshots instantanés, compression transparente, déduplication possible. Pour une PME avec deux ou trois VPS, Ceph apporte la réplication entre nœuds.

Incus face à Docker, Proxmox, LXD et Kubernetes

La question revient toutes les semaines : « Pourquoi pas Docker ? Pourquoi pas Proxmox ? » La réponse dépend du cas d’usage.

Face à Docker, Incus joue dans une autre catégorie. Docker isole un processus dans un conteneur applicatif, idéal pour empaqueter un microservice. Incus, lui, fait tourner une distribution Linux complète avec son init, ses cron, son ssh — exactement comme une VM mais sans le coût de la virtualisation matérielle. Pour un site WordPress de PME, un conteneur Incus avec Apache, MariaDB et tous ses cron WP est plus simple à exploiter qu’un compose Docker à cinq services. À noter : Incus 6 sait aussi lancer directement des images OCI (donc Docker Hub) — vous avez les deux modèles dans le même outil.

Face à Proxmox VE, Incus est plus léger et plus scriptable. Proxmox embarque sa propre distribution Debian modifiée et impose ses choix (LVM, sa propre interface). Incus s’installe par-dessus n’importe quel hôte Linux et expose une API REST propre pour l’automatisation. Pour les administrateurs réseau qui aiment cliquer, Proxmox reste plus visuel, mais une interface web Incus officielle existe maintenant et progresse à chaque release.

Face à LXD, le choix est tranché par la communauté technique. LXD reste maintenu par Canonical mais avec une trajectoire désormais alignée sur Ubuntu Pro. Incus garde la philosophie originelle de LXD : libre, multi-distribution, cycle LTS prévisible, nouvelles fonctionnalités tirées par la communauté. La migration LXD → Incus est documentée et automatisée (un tutoriel dédié couvre la procédure complète).

Face à Kubernetes, Incus n’est pas un concurrent direct mais un complément. Kubernetes orchestre des conteneurs applicatifs courts vivants ; Incus gère des machines longues vivants avec état. On voit fréquemment des architectures où Incus fournit les nœuds (VMs ou conteneurs système) qui font tourner un cluster Kubernetes pour la couche applicative. Pour une PME en phase de démarrage, Incus seul suffit ; Kubernetes vient quand la charge dépasse trois ou quatre VPS.

Installer Incus sur Ubuntu, Debian, Fedora, Arch

L’installation est radicalement plus simple qu’avec Proxmox parce qu’il n’y a pas d’ISO, pas de bare-metal obligatoire, pas de redémarrage. Tout se fait à partir d’un Linux fonctionnel.

Sur Ubuntu 24.04 LTS et plus récent, le paquet est natif :

sudo apt update
sudo apt install incus
sudo incus admin init   # interactif : pool, réseau, cluster ou non

Sur Ubuntu 22.04 LTS ou Debian 11/12, le dépôt Zabbly fournit des paquets stables maintenus par l’équipe Incus :

curl -fsSL https://pkgs.zabbly.com/key.asc | sudo tee /etc/apt/keyrings/zabbly.asc
sudo curl -o /etc/apt/sources.list.d/zabbly-incus-stable.sources   https://pkgs.zabbly.com/incus/stable/zabbly-incus-stable.sources
sudo apt update
sudo apt install incus

Sur Debian 13 (trixie), le paquet est natif comme sur Ubuntu 24.04. Sur Fedora, sudo dnf install incus. Sur Arch Linux, sudo pacman -S incus. Sur NixOS, ajouter virtualisation.incus.enable = true; dans la configuration.

Quelle que soit la distribution, terminez par sudo incus admin init. La phase interactive demande le pool de stockage (ZFS recommandé si possible), le réseau bridge (acceptez le défaut incusbr0), si vous voulez exposer l’API en TCP, et si vous démarrez un cluster ou un nœud isolé. Pour un premier serveur, répondez « non » au cluster — vous pourrez en former un plus tard sans perdre vos instances.

Côté ressources, Incus tourne confortablement à partir de 2 Go de RAM. Le binaire seul consomme une trentaine de mégaoctets ; les conteneurs ajoutent ce qu’ils utilisent vraiment, soit quelques dizaines de mégaoctets pour un Linux léger au repos. Pour pratiquer, Hostinger Cloud VPS propose des plans à partir de 4 GB RAM / 1 vCPU pour quelques euros par mois, avec un panneau d’administration en français et un support réactif — un terrain idéal pour monter votre premier hôte Incus avec marge pour cinq à dix conteneurs en parallèle.

Premiers pas : créer, exécuter, supprimer une instance

Une fois Incus initialisé, lancer un premier conteneur tient en une commande :

incus launch images:debian/12 mon-conteneur

Cette commande télécharge l’image officielle Debian 12 depuis le serveur d’images de Linux Containers, crée une instance nommée mon-conteneur et la démarre. Au premier appel, le téléchargement prend quelques minutes ; les fois suivantes, les instances de la même base démarrent en moins de deux secondes (l’image est mise en cache).

Quelques commandes utiles pour la suite :

incus list                    # voir toutes les instances
incus shell mon-conteneur     # ouvrir un shell root dedans
incus exec mon-conteneur -- apt update    # exécuter une commande
incus stop mon-conteneur      # arrêter
incus delete mon-conteneur    # supprimer (instance arrêtée)
incus snapshot create mon-conteneur snap1   # snapshot
incus snapshot restore mon-conteneur snap1  # rollback

L’image images:debian/12 est l’une de centaines disponibles : images:ubuntu/24.04, images:alpine/3.19, images:rockylinux/9, images:archlinux, et même des images Windows pour les machines virtuelles. La liste complète vit sur le serveur d’images officiel ; incus image list images: permet de filtrer en local.

Réseau et stockage : ce qui distingue Incus

Le réseau par défaut incusbr0 est un bridge avec NAT et DHCP. Vos instances reçoivent une IP privée (typiquement 10.x.x.x) et accèdent à internet via l’hôte. Pour un site web hébergé dans un conteneur, on ajoute un reverse-proxy sur l’hôte (Caddy ou Nginx) qui transmet le trafic HTTPS au conteneur — schéma classique et bien documenté.

Pour des cas plus avancés, Incus sait : créer plusieurs bridges isolés (un par projet client), assigner une IP statique à une instance (incus config device override mon-conteneur eth0 ipv4.address=10.0.0.50), exposer un port de l’hôte vers une instance (incus config device add mon-conteneur web8080 proxy listen=tcp:0.0.0.0:8080 connect=tcp:127.0.0.1:80), brancher une instance directement sur le réseau physique en macvlan (utile quand on veut une IP publique sur l’instance), ou monter une infrastructure OVN distribuée pour micro-segmentation et load balancing applicatif.

Côté stockage, ZFS est le compromis recommandé pour un usage individuel ou PME. Snapshots instantanés (vraiment instantanés, indépendants du volume), compression LZ4 transparente (réduit l’occupation disque de 30 à 50 % sur du contenu textuel), et duplication possible. Sur un VPS Hostinger 4 GB / 80 GB SSD, un pool ZFS de 60 Go laisse confortablement la place à dix à quinze conteneurs Debian/Alpine légers.

Conteneurs système et machines virtuelles côte à côte

Un trait distinctif d’Incus est de gérer les deux types d’instances avec le même outil. Lancer une VM se fait avec une seule option :

incus launch images:ubuntu/24.04 ma-vm --vm
incus console ma-vm   # accès série
incus console ma-vm --type vga   # accès SPICE/VNC

L’intérêt ? Un service qui exige un noyau spécifique (driver propriétaire, hyperviseur imbriqué, Windows Server) tourne en VM ; à côté, vingt conteneurs système assurent les sites web, les bases de données et les runners CI sans coûter la mémoire d’une VM. La même machine physique fait les deux. Les VMs supportent UEFI, Secure Boot, TPM 2.0 virtuel (utile pour Windows 11), GPU passthrough et USB passthrough.

Clustering : haute disponibilité avec 3 nœuds

Incus sait fédérer plusieurs hôtes en un cluster qui se présente comme un seul système. Les instances peuvent être créées sur n’importe quel nœud, les images sont partagées, et en cas de panne d’un nœud, les VMs déclarées critiques peuvent être redémarrées automatiquement ailleurs (live migration disponible pour les VMs).

Trois nœuds est le minimum pour avoir un quorum résilient (un nœud peut tomber sans bloquer le cluster). En dessous, le cluster fonctionne mais perd le bénéfice du quorum en cas de partition réseau. Pour une PME, le scénario typique est un cluster à trois petits VPS chez le même hébergeur, dans la même région, avec un réseau privé entre eux.

La formation du cluster se fait en deux temps : incus admin init sur le premier nœud avec cluster: yes, puis le même init sur les nœuds suivants avec le token de jonction généré. Une fois le cluster en place, on définit des groupes (par exemple : frontend, database, backup) et l’algorithme de placement choisit automatiquement le bon nœud à la création.

Projets et multi-tenant : architecture SaaS

Pour un freelance ou une agence qui héberge plusieurs clients, le système de projets est un atout différenciant. Chaque projet a ses instances, ses profils, ses images, ses réseaux. On bascule de l’un à l’autre par incus project switch <nom>. Les quotas (features.images=true, limits.containers=10, limits.memory=8GB) garantissent qu’aucun projet ne mange les ressources des autres.

L’authentification peut être déléguée à un fournisseur OIDC (Keycloak, Authentik) avec des groupes mappés sur des permissions Incus : un membre de l’équipe X ne voit que le projet X. C’est le socle d’une plateforme SaaS interne sans avoir à coder un panneau de contrôle complet.

Tous les tutoriels Incus de ce site

Cet article de référence est complété par une centaine de tutoriels pas-à-pas, organisés par thème. Chaque tutoriel est court (15 à 25 minutes de lecture), s’appuie sur la documentation officielle pour les commandes, et précise systématiquement les particularités d’un déploiement chez un hébergeur accessible aux Africains francophones.

Installation et démarrage

• Installer Incus sur Ubuntu 24.04 avec le dépôt Zabbly
• Installer Incus sur Debian 12/13 — procédure pas-à-pas
• Installer Incus sur Fedora, Arch et NixOS
• Migrer LXD vers Incus — procédure officielle
• Premier conteneur Incus : launch, exec, shell
• Configurer un pool de stockage ZFS par défaut
• Configurer un pool de stockage Btrfs par défaut
• Configurer un pool de stockage LVM-thin par défaut

Gestion des instances

• Cycle de vie d’une instance : start, stop, restart, pause
• Snapshots et restauration d’instance
• Cloner une instance avec copy et move
• Publier une instance comme image réutilisable
• Exporter et importer une instance pour backup ou migration
• Instances éphémères pour tests rapides
• Limites CPU et mémoire d’une instance
• Arrêter automatiquement une instance inactive
• Accéder aux fichiers d’une instance avec file pull et file push
• Supprimer une instance avec protection contre l’effacement accidentel

Profils et configuration

• Profils Incus : créer, modifier, appliquer
• Profil default versus profils personnalisés
• Héritage de plusieurs profils sur une même instance
• Configurer cloud-init pour bootstrap automatique
• Variables d’environnement d’une instance
• Options bas niveau raw.lxc et raw.qemu
• Limiter accès disque et IOPS d’une instance
• Dupliquer profils entre serveurs Incus

Réseau

• Comprendre le bridge par défaut incusbr0
• Créer un bridge personnalisé pour isoler des projets
• Assigner une IP statique à une instance
• Configurer un VLAN trunk sur une instance
• OVN dans Incus : introduction au réseau overlay
• ACL Incus pour pare-feu applicatif
• Network forwards pour publier un port d’instance
• Load balancer Incus natif pour distribuer le trafic
• Routes statiques personnalisées
• Macvlan : donner une IP publique à une instance
• Comprendre nftables et iptables sur l’hôte Incus
• Dual-stack IPv4 et IPv6

Stockage avancé

• Comparatif ZFS, Btrfs, LVM, Ceph pour Incus
• Ceph RBD pour stockage distribué
• CephFS pour volume partagé multi-nœuds
• Snapshots de pool et instances ZFS
• Quotas de volume pour limiter une instance
• Transférer un volume entre pools
• Backup de volumes vers stockage S3 distant
• Dataset ZFS natif attaché à une instance
• Chiffrement de volume avec ZFS et LUKS

Machines virtuelles

• Lancer une VM Incus avec QEMU (Linux et Windows)
• Installer Windows 11 en VM avec drivers VirtIO
• Configurer UEFI et Secure Boot pour une VM
• TPM virtuel pour Windows en VM
• GPU passthrough pour jeu ou ML
• USB passthrough pour clé matérielle
• Console VNC et SPICE
• Live migration entre nœuds
• Redimensionner le disque d’une VM
• Virtualisation imbriquée (KVM dans VM Incus)

Conteneurs OCI (compatibles Docker)

• Lancer un conteneur OCI Docker dans Incus
• Importer une image depuis Docker Hub
• Comparaison Incus OCI versus Docker Engine
• Migrer un fichier compose.yml vers plusieurs instances Incus
• Registry OCI privé pour images internes

Clustering et haute disponibilité

• Former un cluster Incus à 3 nœuds — bootstrap complet
• Ajouter un nœud à un cluster existant
• Retirer un nœud (évacuation propre)
• Quorum et failover : ce qu’il faut comprendre
• Distribution d’instances et scheduler
• Évacuation de nœud pour maintenance
• Cluster groups et zones de disponibilité
• Mise à jour rolling d’un cluster
• TLS et mTLS dans un cluster Incus
• Backup complet d’un cluster

Sécurité et isolation

• Conteneurs non privilégiés et id-mapping
• AppArmor : profils par instance
• Seccomp : filtrage de syscalls
• Capacités Linux dans un conteneur
• Nesting Incus : conteneurs dans conteneurs
• TLS trust et pin de certificats clients
• OIDC SSO avec Keycloak ou Authentik
• RBAC, projets et permissions utilisateur
• Logs d’audit et traçabilité
• Fail2ban contre le brute-force sur l’API

Projets et multi-tenant

• Projets Incus : introduction à l’isolation
• Quotas projet pour limiter les ressources
• Partager des images entre projets
• SaaS multi-clients : architecture par projets
• Migrer une instance entre projets

Production et exploitation

• Monitorer Incus avec Prometheus et Grafana
• Exporter les métriques via textfile collector
• Logs centralisés avec Loki et Promtail
• Backup et restauration d’instance — procédure
• Backup distant S3 avec script automatisé
• Mettre à jour Incus via Zabbly en sécurité
• Récupérer un cluster corrompu (base de données)
• Ansible Incus collection : automatiser
• Provider Terraform Incus pour IaC
• Comparatif Proxmox VE versus Incus 2026
• Déployer l’interface web officielle d’Incus
• Service systemd : debugger Incus en production

Cas d’usage Afrique de l’Ouest

• Héberger 100 conteneurs sur un VPS Hostinger
• Cluster Incus à 2 VPS Hostinger pour PME
• CI/CD GitLab avec runners Incus éphémères
• WordPress multisite : un conteneur par client
• Environnements de développement par snapshots

Adaptation au contexte ouest-africain

Trois contraintes locales pèsent sur le choix d’Incus comme socle d’infrastructure : la bande passante, le coût d’hébergement et l’électricité.

Sur la bande passante, le téléchargement initial des images peut être lent depuis Dakar ou Abidjan vers images.linuxcontainers.org (latence 200 ms+). Une bonne pratique est de configurer un image cache sur un nœud central et de le désigner comme miroir pour les autres : les images sont téléchargées une fois, partagées localement. Pour les conteneurs Debian/Alpine légers, on parle de 50 à 80 Mo par image — gérable même en 4G partagée.

Sur le coût, c’est précisément l’argument fort d’Incus pour notre marché. Hostinger Cloud VPS propose des plans à partir d’environ 5 USD/mois pour 4 Go de RAM et 80 Go SSD, avec interface en français et paiement carte sans surcharge importante. Sur ce VPS, un Incus avec ZFS et compression accueille confortablement une dizaine de petits conteneurs (sites WordPress, environnements de test, bases SQL) — soit un coût de moins de 50 centimes par environnement et par mois. Aucun produit Proxmox ou VMware n’approche ce ratio à cette échelle.

Sur l’électricité, la coupure récurrente n’est plus un problème dès lors que vous travaillez sur VPS : la machine vous appartient virtuellement, l’hébergeur garantit le 99,9 % d’uptime, et vos snapshots Incus tournent toutes les heures vers un stockage S3-compatible (Bunny Storage, Wasabi ou MinIO auto-hébergé). En cas de panne sur votre poste de travail, vous reprenez la session du serveur où vous l’aviez laissée. C’est exactement le modèle qu’on conseille systématiquement pour les freelances dakarois et abidjanais.

Erreurs fréquentes à éviter

FAQ

Incus est-il adapté à un débutant complet en Linux ?
Pas immédiatement. Une base Linux solide (système de fichiers, services systemd, réseau bridge) facilite énormément l’apprentissage. Comptez deux à trois jours de pratique avant de vous sentir à l’aise sur les commandes courantes ; Incus n’est pas plus difficile que Docker mais demande de comprendre l’écosystème système Linux complet, pas juste des images applicatives.

Peut-on faire tourner Windows dans Incus ?
Oui, en mode VM avec --vm. UEFI, Secure Boot et TPM 2.0 virtuel sont supportés, ce qui satisfait les exigences d’installation de Windows 11. Les drivers VirtIO sont à charger pendant l’installation pour de meilleures performances.

Incus consomme-t-il beaucoup de RAM par conteneur ?
Non. Un conteneur Debian minimal au repos consomme 30 à 80 Mo de RAM. Un conteneur Ubuntu avec systemd, ssh et cron : 100 à 150 Mo. Une instance WordPress complète avec Apache et MariaDB : 300 à 500 Mo selon la charge. Sur un VPS 4 Go, prévoir une dizaine d’instances en parallèle est réaliste.

Quelle différence avec systemd-nspawn ?
systemd-nspawn fait tourner un conteneur, mais sans gestion réseau, sans pool de stockage, sans cycle de vie complet, sans cluster. Incus ajoute toute la couche de management qui rend l’usage industriel possible.

Incus chiffre-t-il les conteneurs au repos ?
Pas par défaut. Le chiffrement se gère au niveau du pool de stockage : ZFS native encryption ou LUKS sous le pool LVM. Pour une PME qui héberge des données clients, c’est une bonne pratique à activer dès la création du pool.

Comment migrer depuis LXD ?
L’équipe Incus fournit un outil lxd-to-incus qui automatise la conversion : il arrête LXD, copie la base de données, ajuste la configuration et redémarre sous Incus. Un tutoriel dédié couvre la procédure pas à pas, y compris les cas où les versions divergent.

Pour aller plus loin

• Documentation officielle d’Incus (linuxcontainers.org)
• Dépôt GitHub officiel d’Incus
• Dépôt Zabbly pour paquets Ubuntu/Debian récents
• Pour pratiquer sur un VPS dédié : Hostinger Cloud VPS — plans à partir de 4 Go RAM en français.
• Si vous arrivez de Docker, commencez par le tutoriel « Lancer un conteneur OCI dans Incus » qui montre la cohabitation OCI + conteneurs système.
• Si vous arrivez de Proxmox, le comparatif « Proxmox VE versus Incus 2026 » détaille les différences pratiques au quotidien.

Bonne route avec Incus. Le projet est jeune mais déjà solide, le rythme de release est régulier, et la communauté francophone sur le forum Linux Containers est accueillante. Posez vos questions sans hésiter dès qu’un comportement vous surprend — la doc officielle est rarement loin de la réponse.