POC structuré avant migration d'un datacenter public

Pourquoi un POC structuré

Dans le secteur public, une décision de migration infrastructure ne peut pas reposer sur un benchmark commercial ou une démo éditeur. Elle doit s'appuyer sur une validation technique formelle, documentée, reproductible.

Cet organisme public avait la volonté de migrer depuis VMware. Broadcom avait rendu le renouvellement significativement plus coûteux. Mais la direction technique refusait à juste titre un "go" basé sur des retours d'expérience de tiers. Elle voulait ses propres preuves, sur ses propres workloads représentatifs, avec des critères de validation définis en amont.

:::Contexte de mission Environnement réglementé, continuité de service contractuelle, équipe IT réduite. Le risque n'était pas seulement technique — un échec de migration aurait eu des conséquences réglementaires directes. :::

Ce qu'un bon POC doit démontrer

Avant de commencer, trois heures de cadrage ont servi à définir ce que le POC ne devait pas faire : prouver que Proxmox fonctionne en laboratoire. Ce qu'il devait faire : prouver que Proxmox fonctionne sur leurs workloads, avec leur réseau, leur stockage, leurs contraintes opérationnelles.

Critères de validation définis en amont :

• Bascule HA automatique en moins de 8 minutes sur les charges représentatives
• Restauration d'une VM critique depuis Proxmox Backup Server en moins de 10 minutes
• Isolation réseau entre segments réglementaires respectée à l'identique
• Montée en charge simultanée de N+2 VMs sans dégradation mesurable
• Exécution complète d'une procédure de rollback par l'équipe IT interne

:::Point critique Un critère non défini en amont devient un critère subjectif en aval. Si les objectifs de RTO ne sont pas écrits avant le test, chaque acteur interprète le résultat selon sa position. :::

Structure des 7 phases

Chaque phase a produit un rapport technique intermédiaire validé avant de passer à la suivante.

1. Architecture de base — déploiement cluster Proxmox, configuration réseau initiale, intégration dans l'environnement existant
2. Réseau — VLAN, routage inter-segments, inspection des flux réglementaires
3. Stockage — benchmark ZFS vs Ceph selon les profils d'usage identifiés, calibration des paramètres
4. Haute disponibilité — tests de bascule sur panne simulée (nœud, réseau, alimentation), mesure RTO réel
5. PRA — exécution complète d'un scénario de reprise depuis backup, mesure RPO/RTO
6. Montée en charge — simulation de charge simultanée représentative du pic d'activité
7. Exploitation — exécution des procédures de maintenance courantes par l'équipe IT interne, sans assistance externe

:::Observation terrain La phase 7 était la plus révélatrice. Une technologie qu'une équipe de 2 personnes ne peut pas opérer seule n'est pas une solution viable, quelle que soient ses performances techniques. :::

Ce que le POC a eu du mal à valider

Honnêteté : deux points ont nécessité des ajustements en cours de POC.

L'intégration avec l'annuaire interne (contrainte réglementaire) a demandé un détour technique non anticipé. La configuration réseau d'un des segments réglementaires avait une particularité documentée uniquement dans un fichier de configuration local que nous n'avions pas initialement identifié.

Ces deux points ont été documentés dans le rapport final avec les solutions retenues et les contraintes résiduelles.

:::Ce qu'on découvre trop tard Les configurations réseau héritées sont souvent dans les esprits des exploitants historiques, pas dans la documentation formelle. Un POC sérieux les révèle. Un POC superficiel les masque jusqu'en production. :::

Résultat

Rapport de validation complet remis à la DSI, couvrant les 7 phases avec métriques mesurées. Architecture cible définie, contraintes résiduelles documentées avec leur plan de traitement. L'organisme a engagé la migration sur cette base — avec un dossier technique opposable en cas de question réglementaire.