Le POC commence par une décision à éclairer : quelles charges peut-on migrer, avec quel niveau de service et sous quelles conditions d'exploitation ? Faire démarrer une VM n'apporte qu'une partie de la réponse.
Le périmètre doit représenter les difficultés du projet : application critique, stockage sollicité, dépendance réseau, sauvegarde et équipe d'astreinte. Choisir uniquement les VM les plus faciles rend le résultat peu utile pour préparer la production.
Fixer les critères avant les essais
Écrire les objectifs avec les responsables applicatifs et l'exploitation. Le RTO exprime l'interruption maximale acceptable ; le RPO exprime la perte de données acceptable. Les mesurer au niveau du service, avec un début et une fin observables.
Exemple illustratif : si l'objectif convenu est une reprise en moins de 15 minutes et que le test prend 22 minutes, l'écart doit rester visible dans la décision. Modifier le seuil après l'essai demande un nouvel arbitrage métier.
Pour chaque critère, définir un responsable, une méthode de mesure et une conséquence en cas d'échec. Si un test essentiel n'est pas réalisable pendant le POC, le classer comme non validé et préciser la preuve encore attendue.
Préparer une matrice de recette
Cette matrice est un point de départ à adapter au périmètre. Les essais de panne s'exécutent sur des données de test et dans un environnement isolé, avec un plan de retour à l'état nominal.
| Domaine | Essai | Critère à convenir | Preuve à joindre |
|---|---|---|---|
| Migration | Transfert d'une VM représentative | Durée d'arrêt et contrôle fonctionnel acceptés | Chronologie et validation applicative |
| Maintenance | Déplacement d'une VM sous charge | Interruption et erreurs sous les seuils convenus | Mesures avant, pendant et après |
| HA | Perte d'un hôte de qualification | RTO du service et capacité restante acceptés | Journaux et transaction de contrôle |
| Stockage | Défaut d'un disque ou d'un hôte | Données accessibles et latence admissible | État de protection et reconstruction |
| Sauvegarde | Restauration complète isolée | RPO, RTO et cohérence applicative acceptés | Compte rendu de restauration |
| Retour arrière | Incident simulé après bascule | Procédure et traitement des écritures validés | Exécution du runbook et contrôles |
| Exploitation | Intervention par l'équipe cible | Diagnostic et escalade réalisables | Observations et besoins de formation |
Le résultat doit permettre une décision par famille de charges. Un seul indicateur global « POC réussi » masque les écarts entre applications.
Tester le retour arrière avant la vague de production
Définir le point jusqu'auquel un retour est possible, qui le décide et quelles données seront conservées. Une VM VMware encore présente ne suffit pas si de nouvelles écritures ont eu lieu sur Proxmox.
Le scénario de qualification peut suivre ces étapes :
- Sauvegarder l'état initial et vérifier le moyen de restauration.
- Transférer une VM de test selon la méthode retenue.
- Produire des écritures applicatives identifiables sur la cible.
- Simuler un motif de retour et exécuter la décision.
- Appliquer la stratégie de données prévue, puis vérifier le service.
- Mesurer la durée complète et documenter toute perte acceptée.
Il peut être nécessaire de répliquer les données au niveau applicatif, de restaurer une sauvegarde ou de prévoir un autre mécanisme. Le runbook doit nommer cette méthode. Un snapshot ne remplace pas une sauvegarde indépendante et ne transporte pas automatiquement les écritures vers la plateforme précédente.
Séparer maintenance, HA et PRA
La maintenance d'un hôte encore fonctionnel et la panne brutale sont deux essais différents. Notre article vMotion et Live Migration détaille le premier ; l'épisode VMware HA et Proxmox HA traite le redémarrage après panne.
Pour la HA, vérifier les VM effectivement protégées, le quorum, le fencing, l'accès aux disques et la capacité des nœuds de reprise. Mesurer jusqu'au retour du service applicatif.
Un test local de perte d'hôte ne valide pas la perte d'un site. Si le PRA fait partie de la décision, inclure les dépendances de l'autre site, la disponibilité des sauvegardes, le réseau, l'identité, les clés et le retour au site nominal. Si ce volet reste hors POC, l'indiquer comme condition ouverte avant production.
Restaurer avec la chaîne de sauvegarde retenue
Le POC doit utiliser les versions et composants envisagés pour la production. Si Veeam est retenu, rapprocher la configuration de sa matrice de support Proxmox et de ses limitations.
Avec PBS, inclure une vérification d'intégrité, puis une restauration. La documentation des tâches de maintenance PBS décrit la vérification des sauvegardes. Celle-ci ne remplace pas le contrôle fonctionnel de l'application restaurée.
Dans les deux cas, tester l'accès aux identifiants et aux clés nécessaires depuis l'environnement de reprise. Conserver un contrôle métier : ouverture d'une base, lecture d'un jeu de données et transaction de test. Un système invité qui démarre ne prouve pas cette cohérence.
Mesurer les performances pendant la dégradation
Établir une référence sur la charge représentative, puis refaire les mesures pendant la maintenance et la reconstruction du stockage. Relever la latence applicative, les erreurs, les ressources consommées et le temps de retour à la protection attendue.
Si Ceph est envisagé, notre comparatif Ceph et SAN aide à examiner les choix de stockage. La charge de reconstruction doit figurer dans les essais, avec les sauvegardes et les autres opérations susceptibles de se chevaucher.
La durée du POC dépend des cycles qu'il faut observer : pics, traitements batch, rétention et entretien. Une durée fixe ne garantit pas qu'ils ont été couverts. Inscrire les cycles non observés parmi les limites du résultat.
Faire participer l'équipe qui exploitera la cible
Confier à l'équipe des tâches concrètes : prendre une alerte, ouvrir une console, diagnostiquer un accès au stockage, restaurer et appliquer une procédure de maintenance. Noter les étapes qui exigent une aide extérieure.
Évaluer les permissions, les journaux, les contacts d'escalade et la disponibilité du support aux horaires nécessaires. Le temps de formation et le transfert des procédures font partie du projet.
Remettre un dossier de décision exploitable
Le dossier de sortie doit réunir la configuration testée, les résultats par critère, les preuves, les écarts et les tests non réalisés. Ajouter les risques acceptés, les actions correctives, leurs responsables et les conditions de nouvelle recette.
Un go conditionnel doit nommer ce qui bloque encore la production et qui autorisera la levée de ces conditions. Une charge non validée reste hors de la vague autorisée.
Notre accompagnement POC Proxmox reprend cette logique de validation avant les vagues de migration. Pour préparer votre périmètre, demandez un cadrage POC avec vos critères de reprise et de restauration.
Sources et périmètre
Sources officielles consultées le 15 octobre 2026. La matrice et le scénario de retour arrière sont des propositions de méthode. Ils ne décrivent pas une campagne de tests exécutée ni un résultat client.