Équiper une salle informatique pédagogique pose une question rarement traitée de front : sur quoi repose l'authentification, le stockage des travaux et le déploiement des postes ? La réponse est souvent héritée plutôt que choisie. EduLibre part de la question inverse — que faudrait-il construire si on décidait aujourd'hui, avec des briques libres ?
Ce qui pousse à se poser la question
La dépendance, avant le coût
Un parc adossé à un écosystème propriétaire crée un enchaînement : l'annuaire impose le système client, qui impose la suite bureautique, qui impose le format des documents, qui impose le renouvellement des licences. Chaque brique semble un choix technique ; l'ensemble constitue une dépendance de fait, dont on ne mesure le coût qu'au moment d'essayer d'en sortir.
La question à se poser n'est pas « ce produit est-il bon ? » — souvent il l'est — mais « combien coûterait le changement ? ». Si la réponse est « on ne peut plus », le choix a déjà été fait à notre place.
Le coût, tout de même
Licences serveur, licences d'accès client, suites bureautiques, renouvellements. Sur un parc pédagogique de quelques dizaines de postes, l'addition annuelle représente un budget qui n'achète aucun matériel et ne forme personne. À l'inverse, un socle libre déplace la dépense vers du temps de compétence interne — ce qui n'est gratuit ni immédiat, mais reste dans l'établissement.
Les données des élèves
Travaux, profils, comptes, journaux de connexion : ce sont des données personnelles de mineurs. Les héberger sur une infrastructure maîtrisée, dans un domaine interne, sans dépendance à un service externe, simplifie considérablement la conformité — et surtout la capacité à répondre précisément à la question « où sont ces données, et qui y accède ? ».
La dimension pédagogique
Argument spécifique à l'éducation, et pas le moindre : une infrastructure libre est ouvrable. Un élève ou un enseignant peut regarder comment fonctionne l'annuaire, le DNS, le déploiement. Sur un socle propriétaire, l'infrastructure est une boîte noire — ce qui est un choix pédagogique, même quand il n'est pas assumé comme tel.
Le socle visé : services réseau, annuaire, stockage et orchestration — chacun sur une brique libre et documentée.
Ce que remplace concrètement chaque brique
- l'annuaire — OpenLDAP tient le rôle de référentiel d'identités : comptes, groupes, appartenances ;
- les profils et partages — NFS avec des quotas, adossé aux identifiants de l'annuaire ;
- les stratégies de poste — Ansible, qui applique et réapplique une configuration décrite dans du texte versionné ;
- le déploiement — PXE, pour installer un poste sans clé USB ni intervention ;
- les services réseau — DNS, DHCP et routage sur une passerelle dédiée.
Aucune de ces briques n'est exotique : ce sont les mêmes qui font tourner des infrastructures de production ailleurs. La difficulté n'est pas leur maturité, c'est leur assemblage.
Les objections à traiter honnêtement
« Il faut des compétences. » Oui. C'est le vrai coût, et il est réel : administrer un annuaire, un serveur de fichiers et un outil d'orchestration demande d'apprendre. La contrepartie est que ces compétences sont transférables — elles servent partout — alors qu'une expertise sur une console propriétaire ne vaut que tant qu'on la paie.
« Et si la personne qui sait s'en va ? » C'est l'objection décisive, et elle vaut pour les deux modèles. La seule réponse est la documentation et la reproductibilité : un socle décrit pas à pas, avec des configurations en texte et des scripts rejouables, se reprend. Une infrastructure cliquée dans des interfaces graphiques, non — quel que soit l'éditeur.
« Les logiciels métier ne tourneront pas. » Parfois vrai, et il faut le regarder application par application avant de décider. C'est d'ailleurs pourquoi une telle bascule commence par un laboratoire, pas par la salle de classe.
La méthode : infra-first, et un lab d'abord
Le principe directeur du projet est écrit noir sur blanc dans sa documentation : infra-first. Si le socle est propre — DNS, annuaire, identifiants, certificats — tout ce qui suit devient simple ; s'il est bricolé, tout devient chaotique.
Concrètement, cela impose un ordre : le réseau, puis l'identité, puis le stockage, puis l'orchestration — et seulement ensuite les postes. Chaque brique est validée avant d'introduire la suivante, et l'ensemble est monté en machines virtuelles avant de toucher au moindre poste réel.
Cette méthode a un avantage décisif dans un contexte éducatif : elle permet de démontrer avant de décider. Une salle pilote sur socle libre, comparée à l'existant, remplace utilement un débat d'opinions.
Ce qu'on obtient au bout
Un parc où un élève se connecte avec son compte d'annuaire sur n'importe quel poste et retrouve son profil ; où un poste réinstallé revient au même état sans intervention ; où la configuration de l'ensemble tient dans des fichiers versionnés ; et où l'on peut expliquer, à qui le demande, exactement ce qui tourne et pourquoi.
Les articles suivants décrivent cette construction, de l'architecture globale à l'industrialisation du parc.
La série EduLibre
De la décision à l'industrialisation du parc :
- 1. Pourquoi un socle libre pour un parc informatique — vous y êtes
- 2. L'architecture globale, brique par brique
- 3. La passerelle : routage, NAT, DNS et DHCP
- 4. L'annuaire LDAP, brique de voûte
- 5. NFS : profils, classes et quotas
- 6. PXE et Ansible : le parc en zero-touch