Et pourquoi pas un Panoramix pour gérer sécurix avec git ?

Sécurix, basé sur NixOS, est le projet de poste de travail de la DINUM.
NixOS a la particularité d’être une distribution Linux déclarative, reposant sur le gestionnaire de paquets Nix et son propre langage de configuration, le langage Nix.

Sécurix : L'OS qui remplacera Windows et que le monde entier nous enviera

Pour répondre aux problématiques de gestion de parc, Nix introduit un mécanisme central : les flakes.
Un flake est un ensemble structuré de fichiers permettant de décrire un système complet, avec ses dépendances, de manière versionnée et reproductible. Concrètement, un poste de travail devient une configuration définie dans un dépôt, avec un point d’entrée (flake.nix) qui décrit précisément comment construire le système.

Cela implique qu’il devient possible de gérer des postes de travail via Git.
Oui, Git.
Vous ne rêvez pas.

Chaque machine peut être décrite comme un projet, versionné, historisé, et reproductible à l’identique. Une modification de configuration devient un commit. Un retour arrière devient un simple rollback.
À partir de ces éléments, je vous propose une réflexion autour d’un logiciel fictif : Panoramix.

Objectif

permettre de gérer un parc de postes NixOS via une interface graphique, tout en conservant la puissance du modèle déclaratif.
Le choix technique se veut volontairement pragmatique.

La stack retenue :
* Python, pour sa simplicité et sa large adoption,
* un framework web léger comme Flask,
* une API pour piloter les actions,
* et un serveur Git intégré pour gérer les configurations des machines.

L’idée n’est pas de complexifier, mais au contraire de rendre accessible un modèle puissant, en s’appuyant sur des briques simples et maîtrisées.

Le principe

Le logiciel reposerai sur un principe simple.
Il permet de modifier des fichiers Nix présents dans des dépôts qu’il héberge lui-même, via une interface graphique.

On peut voir cela comme une approche proche d’Intune :
* modification de policies,
* gestion de la configuration,
* ajout ou suppression de logiciels.

Mais avec une différence fondamentale.
Chaque machine possède son propre dépôt Git.

Autrement dit, un poste de travail devient un projet à part entière :
* avec sa configuration,
* son historique,
* et son cycle de vie.

Ici, il n’y a pas d’agent, pas de client spécifique installé sur les postes.
Tout repose sur Git.

Chaque modification effectuée dans l’interface :
• met à jour les fichiers Nix,
• génère un commit,
• puis est poussée dans le dépôt de la machine concernée.

Le poste, de son côté, ne fait qu’une chose :
• récupérer les changements,
• appliquer la configuration.

On ne pilote plus les machines directement.
On pilote leur état via leur configuration.
C’est un changement de paradigme important.
On passe d’un modèle impératif, basé sur des actions,
à un modèle déclaratif, basé sur un état attendu.

Exemple

Imaginons un exemple simple avec le déploiement de Firefox sur une machine.

1. L’administrateur, via l’interface simplifiée, ajoute Firefox ESR depuis un catalogue d’applications disponibles.

L’utilisateur ne manipule pas directement du Nix.
Il sélectionne simplement une application dans une liste.

2. Le backend de l’application modifie le fichier programs.nix dans le dépôt du poste.

Concrètement, le logiciel :
• récupère le dépôt de la machine,
• ajoute l’entrée correspondante (ex : pkgs.firefox-esr),
• génère un commit.

Exemple simplifié d’un dépôt de poste :

machine-01/
 ├── flake.nix
 ├── flake.lock
 └── hosts/
     └── this/
         ├── configuration.nix
         ├── programs.nix
         └── hardware-configuration.nix

Le fichier programs.nix pourrait ressembler à ça :

{ pkgs }:
[
  pkgs.firefox-esr
  pkgs.git
]

À ce stade, rien n’est encore appliqué sur la machine.
Seule la configuration a changé.

3 . Le déploiement est ensuite déclenché.

Deux approches sont possibles :
• soit directement via nixos-rebuild switch,
• soit via un outil comme Colmena, qui permet de gérer plusieurs machines en parallèle.

Dans les deux cas, le principe reste identique :
• la machine récupère la dernière version de son dépôt (git pull),
• Nix reconstruit le système à partir du flake,
• la nouvelle configuration est appliquée.

4. La machine converge vers l’état attendu.

Firefox est installé automatiquement, sans intervention manuelle supplémentaire.
Si un problème survient :
* il suffit de revenir au commit précédent,
* et de redéployer.
Ce mécanisme illustre bien la philosophie globale.
On ne déploie pas un logiciel au sens classique.
On modifie une déclaration, et le système se met en conformité avec cette déclaration.

Une gestion par groupe

Par ailleurs, on peut totalement imaginer une gestion des postes de travail basée sur des groupes, à l’image d’Active Directory ou d’autres systèmes de gestion existants.
Voici comment cela pourrait fonctionner.

Chaque machine serait rattachée à un ou plusieurs groupes :

• bureautique
• développeurs
• sécurité renforcée
• etc.

Ces groupes ne sont pas juste organisationnels.
Ils portent directement de la configuration.
Concrètement, un groupe définit :

• une liste de logiciels,
• des paramètres système,
• des policies.

Dans Panoramix, cela se traduirait par une séparation claire dans les fichiers Nix.
ce sont des configurations déclaratives, versionnées, et traçables.

La serpervision

Et pour le suivi, on peut imaginer un mécanisme simple basé sur une tâche planifiée.
Chaque poste exécute régulièrement un cron (ou un timer systemd) qui :

• collecte les logs Nix (build, switch, erreurs),
• les commit dans un dépôt dédié ou les pousse vers le serveur central.

Exemple :
- récupération des logs nixos-rebuild
- git add logs/
- git commit
- git push

Cela permet :
• d’avoir une traçabilité centralisée,
• de suivre l’état réel des machines,
• et de détecter rapidement les anomalies.

Le poste ne remonte pas un état via une API.
Il publie simplement son état… via Git.

Pour conclure.

NixOS peut être géré avec Git.
J’ai encore du mal à le dire… alors que je viens de l’écrire.
Et pourtant.

Une machine devient un dépôt.
Une configuration devient un commit.
Un déploiement devient un simple pull.

C’est assez déroutant en y pensant.
Et puis, assez logique une fois qu’on a assimilé.
Maintenant que l’on sait cela, une porte s’ouvre.
Il devient possible de concevoir des outils de gestion de parc :
* sécurisés,
* maîtrisés,
* et avec une interface graphique accessible.

Panoramix s’inscrit dans cette idée.
Pas comme un produit fini, mais comme une direction.
Une façon différente de penser la gestion des postes.

Reste "THE QUESTION"
Est-ce qu’il y a un besoin pour ce type d’outil ?

Est-ce que les entreprises sont prêtes à passer à ce modèle ?

Qu’en pensez-vous ?