Gestion des appareils pour le bureau Linux : la lacune que nous comblons nous-mêmes

Nommez une plateforme, et je nommerai sa gestion d’appareils. Windows ? Microsoft Intune — et avant lui, SCCM, devenu MECM, que personne ne prononce avec assurance. macOS ? Jamf — tellement acquis que les administrateurs Mac ne sauraient agir autrement. iPhone et iPad ? MobileIron, MaaS360, Workspace ONE — tout un zoo de solutions MDM, toutes parlant le même protocole Apple. ChromeOS ? La console Google Admin, élégante jusqu’à l’ennui. Android ? Aucun problème — toute flotte Knox, tout forfait opérateur embarque la gestion.

Et Linux ?

Silence.

Ce silence est la thèse de ce texte : le système d’exploitation qui porte l’infrastructure la plus exigeante du monde — banques, télécoms, hôpitaux, industrie — est celui pour lequel personne n’a sérieusement bâti de gestion d’appareils pour le bureau. Pas commercialement. Pas librement. Nulle part avec le sérieux que Jamf apporte à Apple.

Ce n’est pas gênant. C’est une occasion.

Ce qu’est réellement la gestion d’appareils

Évitons les mots à la mode. La gestion d’appareils est une discipline aux contours nets. Un appareil est enrôlé. Il reçoit des politiques — ce qui est permis, obligatoire, interdit. Il reçoit ses logiciels — automatiquement, silencieusement, sans que l’utilisateur cherche. Il est inventorié — qui détient quel appareil, dans quel état, à quelle révision. Il est mis à jour — piloté centralement, non abandonné à la bonne volonté de l’utilisateur. Il est surveillé — est-il en ligne, sain, conforme ? Et puis un jour il est retiré — proprement, sûrement, avec tout ce que cela comporte.

Le tout enveloppé dans une interface si naturelle qu’un administrateur dirige des flottes de milliers d’appareils sans réfléchir par appareil. Apple a fixé cette barre avec l’application Self Service de Jamf : l’utilisateur voit une appli, tape, elle est là. Cohérent. Amical. Bien rangé.

À cette mesure nous nous mesurons. Non à une plus basse.

Le marché qui existe

Regardons honnêtement. Les produits commerciaux ne sont pas mauvais — ils réussissent parce qu’ils livrent.

Dans le camp Windows règne Intune, cloud-native, MDM par protocole, remplaçant de plus en plus le classique SCCM/MECM, qui arrive sur site et lié à un agent avec son charme pesant. Les deux ensemble — co-management — sont la réalité de nombre de maisons.

Pour Apple, Jamf est le standard, flanqué de jeunes challengers — Kandji, Mosyle, Addigy — tous nés dans le cloud, tous exclusivement Apple. Exploitez des Mac en entreprise et vous échappez à peine à cet écosystème.

Au-dessus trône ce qu’on nomme désormais Unified Endpoint Management : Workspace ONE (autrefois AirWatch, présentement sous Omnissa), MaaS360 d’IBM, Ivanti (qui a uni MobileIron et Pulse Secure), ManageEngine Endpoint Central, Hexnode. Chacun essaie de tout gérer — Windows, Mac, mobile, parfois Linux serveur, rarement Linux bureau. Et ChromeOS règne sur la console Google Admin, sobre et idéale pour les Chromebooks.

Le fil commun : ce monde tourne autour de Windows, Apple et mobile. Le bureau Linux n’y est qu’une note de bas de page — quand on le mentionne.

L’étrange angle mort

Là ça devient intéressant. Rien de comparable n’existe pour le bureau Linux.

Canonical propose Landscape — mais il gère Ubuntu, principalement des serveurs, et finement en profondeur. SUSE Manager repose sur Salt, pensé près de l’infrastructure. Foreman avec Katello provisionne et configure, pourtant son cœur bat dans la salle serveurs, pas au bureau. osquery, couplé à Fleet, livre visibilité et conformité — mais il interroge l’état, il ne le déclare pas. Chef et Puppet portent l’ADN serveur ; ils peuvent atteindre le bureau, mais personne ne leur a enseigné ce que Jamf ressent.

Aucun ne livre ce que j’ai posé comme étalon plus haut : une expérience de gestion qui prenne le bureau au sérieux — profils, affectation d’applications, préférences utilisateur, applis par défaut, gestionnaires MIME, dispositions d’écrans — et l’enveloppe dans une interface qui soit un plaisir.

Ce n’est pas une plainte. C’est un diagnostic. La lacune existe parce que Linux n’appartient à personne — donc personne ne bâtit un produit à vendre pour lui. Mais c’est précisément pourquoi nous pouvons la combler nous-mêmes.

Retour à l’open source, à la dure

On pourrait attendre qu’un vendeur remarque la lacune. On pourrait acheter un UEM propriétaire et espérer qu’il prenne Linux au sérieux un jour. L’un comme l’autre est irréaliste. Qui attend ses fournisseurs externalise la définition de son outil — et avec elle la souveraineté sur sa propre flotte.

Alors nous le construisons. Ouvert. Avec Ansible pour fondation, une base relationnelle pour source de vérité, et un plugin qui relie les deux. À la dure — car la dure est la seule voie où l’on comprend vraiment ce que l’on bâtit.

Pourquoi Ansible est la fondation

Je n’ai pas besoin d’expliquer Ansible en longueur ici. Sans agent, SSH, idempotent, déclarant l’état plutôt que la procédure — j’ai plaidé ailleurs. Pour la gestion d’appareils, il reste à nommer : c’est la seule automation répandue qui ne présuppose pas un démon géré tournant sur la cible. Une machine qui parle SSH est gérable. Point.

Mais Ansible est la fondation, non le plafond. Il déclare l’état à merveille — il ne le modèle pas. Et c’est là que commence le vrai problème.

Où YAML atteint ses limites

Une petite flotte tolère le YAML. Dix machines, un inventaire, quelques variables de groupe — terminé. Mais une vraie flotte n’est pas linéaire. C’est un tissu d’appareils, de propriétaires, de rôles, de profils, de sites, de départements, d’exceptions, de lots d’applications et de fragments de configuration, tous reliés. La même appli sur trois types de profil, mais uniquement sur deux sites, sauf l’appareil qui mérite un cas spécial.

Les ancres et alias YAML sont jolies. Elles ne remplacent pas l’intégrité référentielle, les jointures, les contraintes, la normalisation et les transactions. Un inventaire YAML plat ploie sous son propre poids dès que la matrice appareils × profils × exceptions passe en trois dimensions.

Cela exige une vraie base relationnelle. PostgreSQL. Avec un schéma pensé : appareils, propriétaires, classes de profil, applications, fragments de configuration, sites, octrois d’exception, état d’enrôlement. Clés étrangères imposant les relations. Vues répondant à des questions complexes en une requête. Et un plugin de recherche écrit maison qui traduit ces lignes, à l’exécution, en variables comprises d’Ansible — des relations devenant des modèles Jinja2.

La vérité vit en un lieu. Les modèles dérivent des relations, non des copies. C’est la différence entre un inventaire et un modèle.

Pourquoi ne pas simplement étendre NetBox ?

Une objection légitime — et je la connais, puisque ma propre boîte à outils embarque déjà des rôles NetBox. NetBox est, pour l’essentiel, ce que je viens de décrire : PostgreSQL dessous, une interface web dessus, un système de plugins, des champs personnalisés, des étiquettes, des relations, REST et GraphQL. Une source unique de vérité, chérie des réseaux, à juste titre.

Mais NetBox a un cadre — DCIM et IPAM — et son responsable le garde avec une rigueur enviable. Les demandes qui ne cadrent pas avec l’image réseau et centre de données tombent routinièrement au travers. Ce n’est pas un défaut. C’est la raison pour laquelle NetBox reste excellent au lieu de proliférer.

Le cycle de vie du bureau, toutefois, est un autre domaine. Affectation de profils, lots d’applications, préférences utilisateur, MIME par défaut, dispositions d’écrans, état d’enrôlement — cela ne se modèle pas naturellement sur locataires, sites, baies et VLAN. Deux voies demeurent : un schéma autonome, bâti pour le bureau, qui se dote un jour de sa propre interface. Ou un plugin NetBox apportant les modèles bureautiques sans toucher au cœur. L’un et l’autre légitimes. Parier sur l’acceptation dans le cœur en amont serait naïf. Mon instinct dit : d’abord la vérité autonome, bâtie exprès — et si les domaines se réconcilient un jour, migrer comme plugin là où elle appartient.

L’interface web qui vient un jour

Je l’avoue ouvertement : au début, pas de portail brillant. Il y a SQL, la ligne de commande et le plugin. Cela suffit à qui bâtit — et à qui sait ce qu’il fait. Mais la gestion d’appareils devrait un jour être maniée par des gens qui préfèrent ne pas lire le YAML. Alors l’interface web viendra en temps voulu : CRUD sur le schéma, affectation de profils en glisser-déposer, une vue par appareil, une vue par utilisateur, une vue par flotte. jusque-là le schéma est la vérité — et la vérité est assez bien structurée pour que toute interface future se contente de s’y poser.

Tout dans des fichiers — pourquoi Linux est prédisposé

Voici le point architectural plus profond, et c’est le véritable levier.

Linux se configure dans des fichiers. Dotfiles dans le dossier personnel. /etc pour le système. Unités systemd en texte. Gestionnaires MIME en texte. Foot, Kitty, Waybar — texte. Et Sway, le gestionnaire de fenêtres pavées que je déploie via mon propre rôle Ansible : configuration purement textuelle. Quiconque a senti un changement de mode, un plein écran, une tuile se mettre en place au clavier comprend pourquoi ce n’est pas qu’efficient — c’est beau. Presque magique. Soudain une fenêtre glisse, une autre se pave à côté, et tout s’emboîte — sans souris, sans menu.

Je ne m’attarderai pas sur Sway. Le point est plus grand. Dans GNOME, les réglages vivent dans dconf — un magasin à affinité binaire qui ne cède au templating qu’à contrecoeur. KDE utilise des fichiers ini, mais avec ses bizarreries autour de kded et kwriteconfig. Sway, lui, est texte pur — et le texte pur est territoire Jinja2. Un rôle, un modèle, un rendu — fini. Voilà précisément pourquoi la pile Sway/Wayland attire tant Ansible : tout ce qui est défini est un fichier, et chaque fichier est un modèle.

Ce n’est pas un accident. C’est la condition architecturale que Linux apporte à la gestion d’appareils et que les systèmes propriétaires n’offrent qu’en partie.

La boîte à outils Manage-My-Network

Je n’argumente pas depuis la théorie. Sous imp1sh sur GitHub gît ma collection Ansible ansible_managemynetwork — ouverte, orientée Debian et OpenWrt, grossie au fil des ans. Parmi ses rôles : Sway et Waybar, mais aussi agent Zabbix, SNMPD, Restic et Borgmatic pour les sauvegardes, patchday, clés SSH, utilisateurs et groupes, MOTD, Chrony, DNS, pare-feu. La pièce à conviction : le motif fonctionne. Rien de théorique. Tout déployé — souvent sous pression.

Cette collection est la graine. La gestion d’appareils que j’esquisse ici est l’arbre.

Le soin du détail — mieux qu’Apple

Là ça devient présomptueux. Là ça devient honnête.

Nous ne parlons pas de reconstruire la fonctionnalité. Nous parlons de surpasser l’expérience. Cohérent, amical, bien rangé — comme Apple l’a montré, mais sans paternalisme. Des valeurs par défaut qui respectent l’utilisateur. Une flotte si facile à mener qu’un admin gouverne des milliers d’appareils sans penser par appareil. Une intégration de supervision qui grandit avec : chaque appareil déploie automatiquement son exportateur de nœud, son agent Zabbix, son SNMPD — la flotte devient observable sans que personne n’enrôle manuellement.

Le projet réel n’est pas d’inventer une distribution. C’est d’affiner continuellement une publication existante. Polissage. Encore et encore. Si constamment que finalement personne ne souhaite sincèrement retrouver macOS ou Windows. Sourire — mais sérieusement.

Le choix de la distribution

Quelle publication ? Là ça devient concret, et je n’esquive pas.

Debian est l’ancre naturelle — ma collection le cible, il est solide comme le roc, et cette constance est un cadeau pour une flotte qui mérite stabilité. Le prix : stable peut être trop sage pour un bureau brillant. Le remède est pragmatique — backports, Flatpaks pour les applications actuelles, sélectivement testing. Pas du dogme, un mélange.

Fedora est la tentation : Wayland plus frais, Sway courant, PipeWire à jour, proche de l’amont. Ceux qui veulent un bureau vif trouvent peu à redire. Le prix est une cadence plus haute — du remueménage qui peut fatiguer une flotte si l’on n’y prend garde.

openSUSE et dérivés Arch tiennent également dans la salle ; NixOS est intellectuellement tentant mais, côté maintenance, une langue à part. Bilan honnête : pour un polissage continu sans incendies, Debian est le terrain où l’on bâtit le plus tranquillement. Fedora reste l’essai pour ceux qui préfèrent la fraîcheur au calme. Je penche Debian — et je le dis ouvertement, parce que la collection l’a déjà choisi.

L’intégration qui grandit avec

Une flotte qui s’enrôle elle-même n’est qu’à moitié faite. L’autre moitié est l’observabilité. Dès qu’un appareil est embarqué, il reçoit son exportateur, son agent, sa configuration de sauvegarde — tout issu du schéma, tout modélisé. Prometheus gratte, Zabbix enregistre, Uptime Kuma ping. Les sauvegardes tournent avec Restic ou Borgmatic — chiffrées, dédupliquées, sans qu’on y pense. Le retrait se fait proprement : clés parties, inventaire archivé, supervision tue. Tout le cycle de vie, câblé.

Comment l’enrôlement fonctionne réellement — honnêtement

Que ce ne soit pas illusion : Ansible pousse par défaut — du contrôleur vers l’hôte en SSH. Les portables itinérants sont rarement joignables quand on les veut. D’où le mode pull. ansible-pull, piloté par un timer systemd ou cron, tire périodiquement l’état déclaré depuis le dépôt. Un contrôleur léger — AWX ou un petit runner — coordonne ce qui est en attente. L’enrôlement se résume alors à : un appareil, un jeton, un premier pull. Pas de sorcellerie. De la conséquence.

C’est plus honnête que la promesse des check-ins MDM classiques — et pour une flotte open source, suffisamment robuste.

Pourquoi cela a du sens

Quelqu’un peut se demander : reconstruisez-vous Jamf pour Linux ? Oui et non. Oui, car l’ambition est la même — gestion de flotte qui prend le bureau au sérieux. Non, car le chemin diffère : non un produit qu’on achète, mais un modèle qu’on possède. Open source, relationnel, piloté par le texte, avec soin du détail.

La lacune existe parce que Linux n’appartient à personne. C’est précisément pourquoi nous pouvons la combler — sans permission, sans feuille de route d’autrui, sans crainte qu’un vendeur coupe le courant. Ce n’est pas un défaut. C’est la condition de possibilité.

Si vous exploitez une flotte de bureaux Linux — ou en projetez une — et vous êtes demandé comment cela peut marcher sans s’appuyer sur un UEM propriétaire : parlons-en. Sans pression commerciale, l’œil sur le long terme. Écrivez à contact@libcom.de. Nous ferons l’inventaire — honnêtement, traçablement — et réfléchirons ensemble à si et comment cette approche convient à votre flotte.