Former son équipe à Proxmox : ce qui marche, ce qui ne marche pas

« Forme l’équipe à Proxmox, et nous serons tranquilles. » Cette phrase, je l’entends souvent, en général après une migration VMware ou juste avant. Et neuf fois sur dix, elle cache un autre besoin que celui qui est formulé.

Parce que « savoir utiliser Proxmox » et « exploiter sereinement un cluster de production », ce ne sont pas les mêmes compétences, ni le même chantier. Voici ce que j’ai retenu des sessions que j’anime chez mes clients, et le programme que je considère comme le minimum vital.

Le vrai besoin n’est presque jamais celui qui est exprimé

Quand une DSI demande une formation Proxmox, le déclencheur est rarement la curiosité technique. C’est presque toujours l’un de ces trois motifs :

Le premier, c’est la migration. L’équipe maîtrise vSphere depuis dix ans, la direction annonce le passage à Proxmox VE, et elle doit se sentir légitime sur le nouvel outil avant la bascule. Le besoin réel : retrouver ses repères, pas apprendre l’hyperviseur de zéro.

Le deuxième, c’est la dépendance à une seule personne. Elle seule maîtrise vraiment la plateforme, et elle part en congé, ou quitte l’entreprise. Le besoin réel : répartir la connaissance sur deux ou trois personnes.

Le troisième, c’est la reprise en main. L’infrastructure a été montée par un prestataire, personne en interne ne sait ce qu’il y a dedans. Le besoin réel : documenter et comprendre l’existant, ce qui n’est pas une formation mais un transfert de compétences.

Ces trois cas appellent des contenus différents. Vendre le même catalogue aux trois, c’est la garantie d’une formation poliment appréciée et jamais appliquée.

Ce qui ne marche pas

La formation catalogue sur l’infrastructure du formateur. Trois jours dans une salle, sur des VMs jetables montées pour l’occasion, avec un stockage local et un réseau à plat. Les participants repartent satisfaits, puis découvrent que leur cluster a du Ceph, du VLAN tagué, un pare-feu et des règles de sauvegarde qui ne ressemblent en rien au lab. Le transfert ne se fait pas. J’ai vu des équipes sortir d’une formation certifiante et rester bloquées sur leur première migration à chaud.

Le format long et dense. Au-delà de deux jours consécutifs, la rétention s’effondre. Le troisième jour efface une bonne partie du premier. Mieux vaut deux jours maintenant et une demi-journée de rattrapage six semaines plus tard, quand les vraies questions sont remontées.

Le « on apprendra en production ». C’est le plus cher de tous. Les deux jours de formation économisés se paient en jours d’incident. La ligne de commande Proxmox est accueillante, ce qui donne une fausse impression de simplicité : qm et pct sont faciles, la gestion du quorum, du fencing et des politiques de rétention ne l’est pas.

Ne former qu’une seule personne. C’est reproduire exactement le problème qu’on cherchait à résoudre. Si le budget ne permet qu’un participant, ce n’est pas de formation qu’il faut parler, mais d’infogérance.

Ce qui marche

Deux à quatre participants, pas huit. À huit, la session devient une conférence. À trois, chacun pratique et pose les questions qui comptent, celles qui commencent par « oui, mais chez nous… ».

Séquencer sur les gestes, pas sur les fonctionnalités. Un plan de formation organisé par menu de l’interface web ne prépare à rien. Un plan organisé par situation opérationnelle (je dois patcher un nœud, je dois restaurer une VM, je dois ajouter du stockage) produit des réflexes.

Repartir avec de l’écrit. À la fin de la session, l’équipe doit avoir produit ses propres procédures, pas reçu les miennes. Une procédure de patching écrite par celui qui va l’exécuter a dix fois plus de chances d’être suivie.

Le programme minimal qui rend une équipe autonome

Si je devais réduire une formation Proxmox VE à l’essentiel, voici les six gestes que je veux voir maîtrisés avant de considérer une équipe autonome sur son exploitation quotidienne :

1. Patcher un nœud sans interrompre le service. Migrer les VMs, mettre à jour, redémarrer, remettre en charge, vérifier : l’administration récurrente d’une infrastructure de virtualisation.
2. Comprendre le quorum et savoir réagir quand il est perdu. Ce que fait le cluster quand un nœud disparaît, pourquoi il se fige, et ce qu’il ne faut surtout pas faire dans l’urgence.
3. Restaurer une VM, chronomètre en main. Non seulement valider qu’une sauvegarde s’est bien terminée mais également remonter le service et mesurer combien de temps cela prend.
4. Ajouter et retirer du stockage proprement. Y compris savoir dire non à une demande qui casserait la politique de rétention.
5. Lire l’état de santé du cluster. Journaux, réplication, réseau corosync, alertes de supervision. Savoir distinguer un bruit d’une vraie alerte.
6. Savoir où sont les limites, et qui appeler. Une équipe autonome n’est pas une équipe qui sait tout faire, c’est également une équipe qui sait déléguer lorsque c’est nécessaire.

Deux jours suffisent à couvrir ces six gestes sur un environnement de formation qui reprend votre architecture. L’idée étant de vous fournir les bagages nécessaires pour le voyage qui vous mènera jusqu’à l’autonomie.

Formation et infogérance, un modèle partagé

Dans la plupart des PME que j’accompagne, la bonne réponse n’est ni « on forme tout le monde » ni « on externalise tout », mais un modèle partagé : l’équipe interne monte en compétence sur les gestes du quotidien, un partenaire prend l’astreinte, les opérations à risque et les pics. La formation et l’infogérance Proxmox VE ne s’opposent pas, elles se complètent.

Côté plateforme, Proxmox VE est open source, et une souscription par socket est recommandée en production pour l’accès au dépôt entreprise et au support éditeur. Votre équipe formée l’exploite au quotidien, l’éditeur et votre partenaire la sécurisent.

Par où commencer

Si vous vous reconnaissez dans l’un des trois déclencheurs du début, la première question à trancher n’est pas tout de suite le contenu du programme mais plutôt : de quoi avez-vous besoin dans six mois, d’une équipe qui sait faire, ou d’une équipe qui n’a plus à faire ?

La réponse est souvent un savant mélange des deux, dont vous seuls avez la réponse. C’est précisément ce que nous examinons ensemble avant de construire un programme. Les formations Proxmox, Docker, Ansible et GitLab que j’anime sont toutes calibrées sur l’architecture du client, en intra ou à distance, de un à huit participants. Si vous hésitez sur le format, écrivez-moi : nous définirons ensemble le bon format lors d’un premier échange.