Ce qu'un POC Proxmox doit réellement valider

La première question qu'on pose quand une DSI veut "faire un POC Proxmox" : qu'est-ce que vous souhaitez valider exactement ?

La réponse est souvent vague. "On veut voir si ça fonctionne." Mais ça ne dit pas grand chose. Une VM Proxmox démarre en 90 secondes sur n'importe quel laptop de développeur. Ça "fonctionne" depuis la version 3.0.

Un POC enterprise sérieux répond à une question précise : ce projet de migration peut-il être exécuté sur ce périmètre, avec cette équipe, dans ces contraintes, en maintenant ce niveau de service ?

Définir les critères de validation avant de commencer

C'est la règle la plus importante, et la plus souvent contournée.

Si les critères de succès ne sont pas définis avant le POC, ils seront définis après. And quand ils sont définis après, ils s'adaptent aux résultats observés — ce qui supprime toute valeur décisionnelle au POC.

Les critères à définir en amont :

• RTO cible par catégorie de VM (critique, standard, développement)
• RPO acceptable par profil applicatif
• Performance minimale attendue (IOPS, latence) sur les workloads représentatifs
• Temps maximal de migration par VM (pour estimer la durée des vagues)
• Critères de rollback en cours de POC

Le rollback : le premier test, pas le dernier

La capacité de revenir en arrière est souvent testée en fin de POC, si elle est testée. C'est une erreur.

Le rollback doit être le premier scénario validé. Avant de migrer quoi que ce soit en production, il faut savoir répondre à cette question : "si on constate un problème 48h après une migration, comment on revient à l'état précédent ?"

Test de rollback à inclure :

1. Migration d'une VM test vers Proxmox
2. Simulation d'un problème applicatif (ne pas chercher un vrai problème — en simuler un)
3. Décision de rollback : qui décide, sur quels critères, dans quel délai ?
4. Exécution du rollback : remettre la VM sur VMware et vérifier qu'elle redémarre correctement
5. Durée mesurée de bout en bout

Les workflows opérationnels : ce que la doc ne teste pas

Le POC doit simuler les tâches courantes que l'équipe exploitation réalisera en production.

Pas les tâches de déploiement initial — celles-là, n'importe qui peut les faire avec la documentation. Les tâches récurrentes et les interventions sous pression.

Workflows à couvrir obligatoirement :

• Redémarrage d'urgence d'une VM
• Connexion console en cas de perte réseau VM
• Snapshot manuel avant une opération risquée
• Restauration d'un fichier depuis PBS
• Ajout d'un disque à une VM en production
• Mise à jour d'un nœud Proxmox avec migration Live des VMs

La validation des sauvegardes : plus profond que "le backup s'est terminé sans erreur"

Un backup non vérifié n'est pas un backup. C'est un fichier d'espoir.

Le POC doit inclure des tests de restauration complète — pas juste des vérifications de type "le job de sauvegarde montre une coche verte".

Tests de validation PBS :

1. Sauvegarde d'une VM applicative représentative (idéalement avec une base de données)
2. Restauration complète dans un environnement isolé
3. Démarrage de la VM restaurée et vérification de la cohérence applicative (pas juste "le ping répond")
4. Mesure du temps de restauration end-to-end
5. Test de vérification d'intégrité PBS sur le backup produit

Les tests PRA : pas uniquement sur la partie Proxmox

Un POC Proxmox n'est pas complet s'il n'intègre pas un test PRA complet.

Ce test doit simuler la perte d'un site ou d'un cluster, et mesurer :

• Le temps de détection de l'incident
• Le temps de décision (qui décide le basculement, sur quel critère)
• Le temps d'exécution du basculement technique
• La cohérence applicative après basculement
• Le temps de retour à l'état nominal

Le RTO "technique" (temps d'exécution de la bascule Proxmox) est souvent différent du RTO "réel" (temps avant que les utilisateurs constatent un retour au service). La différence inclut la détection, la décision, et parfois des dépendances applicatives non anticipées.

La cohérence de performance dans le temps

Un benchmark de POC réalisé sur 30 minutes ne représente pas la performance en production sous charge réelle pendant 8 heures.

Ce que le POC doit mesurer :

• Performance sous charge représentative (pas des benchmarks synthétiques seuls)
• Performance pendant une opération de maintenance (live migration d'un autre nœud, rebuild Ceph)
• Performance après une semaine de fonctionnement en charge continue

La maturité de l'équipe : critère non technique mais décisif

Le POC doit aussi répondre à une question qu'on n'ose parfois pas poser explicitement : est-ce que l'équipe est prête à opérer cet environnement ?

Critères d'évaluation :

• Temps nécessaire pour diagnostiquer un problème de réseau Proxmox sans aide externe
• Capacité à interpréter les logs Ceph en cas d'alerte
• Aisance avec l'interface Proxmox pour les opérations courantes
• Compréhension du modèle de bascule HA

Si ces critères ne sont pas satisfaits en fin de POC, deux interprétations possibles : le périmètre n'est pas adapté, ou la formation doit précéder le déploiement production. Les deux sont des réponses honnêtes. Ce qui n'est pas une réponse honnête : ignorer la question et livrer un cluster sans plan de formation.

Ce que le POC doit produire comme livrable

Un POC sans document de sortie n'a pas existé pour les décideurs qui n'y étaient pas.

Livrables minimum :

• Résultats mesurés par critère de validation défini en amont
• Écarts constatés et plans de traitement
• RTO/RPO mesurés vs objectifs
• Points de risque résiduels documentés
• Recommandation go / no-go / conditions du go

Ce document est ce qui permet à la DSI de prendre une décision engagée, documentée, et défendable.