Chapitre 6 : Critères de choix décisionnels

Cette section est cruciale car elle fournit la grille d'analyse pour arbitrer entre les différentes solutions. Il n'y a pas de "bonne" réponse universelle, tout dépend du contexte.

Coûts (TCO - Total Cost of Ownership)

Le coût est souvent le premier critère, mais il faut l'analyser correctement sur toute la durée de vie.

CAPEX vs OPEX

CAPEX (Capital Expenditure) - Investissement

• On-premise / Cloud privé : achat de matériel, licences perpétuelles
• Immobilisé au bilan, amortissement sur 3-5 ans
• Gros investissement initial
• Impact sur la trésorerie
• Peut nécessiter validation board/direction
• Avantage fiscal selon les pays (amortissement)

OPEX (Operational Expenditure) - Dépense courante

• Cloud public : facturation mensuelle, pay-as-you-go
• Charge d'exploitation récurrente
• Pas d'immobilisation
• Préserve la trésorerie
• Plus facile à faire valider (pas de gros ticket)
• Déductible fiscalement directement

Implications business

• Startup/PME : préfère OPEX (pas de capital)
• Grande entreprise : peut arbitrer selon stratégie financière
• Contexte économique : taux d'intérêt, fiscalité

Calcul du TCO (Total Cost of Ownership)

Il faut comparer sur un horizon temporel (typiquement 3-5 ans).

On-premise

• Achat matériel (serveurs, stockage, réseau)
• Licences logicielles (OS, hyperviseurs, outils)
• Datacenter (loyer, électricité, climatisation, sécurité physique)
• Personnel (salaires équipe ops, astreintes)
• Maintenance matérielle (contrats support, pièces)
• Renouvellement (obsolescence, évolution technologique)
• Backup et DR (infrastructure redondante)
• Connectivité (liens opérateurs)

Cloud public

• Compute (instances, containers, serverless)
• Stockage (block, object, archivage)
• Réseau (transfert sortant = egress, load balancers)
• Services managés (bases de données, caches, queues)
• Support (plans de support optionnels)
• Outils tiers (monitoring, sécurité, FinOps)
• Formation des équipes
• Migration initiale

Pièges classiques du cloud public

• Egress costs : sortie de données très chère (peut exploser le budget)
• Services managés : pratiques mais coûteux à l'échelle
• Logs et monitoring : volumétrie = coûts cachés
• Over-provisioning : instances trop puissantes ou pas optimisées
• Instances running 24/7 : ne pas éteindre les env de dev/test
• Snapshots oubliés : stockage qui s'accumule
• Multi-AZ sans besoin : redondance pas toujours nécessaire

Outils pour optimiser les coûts cloud

• FinOps : discipline de gestion financière du cloud
• AWS Cost Explorer, Azure Cost Management, GCP Cost Management
• Outils tiers : CloudHealth, Cloudability, Spot.io
• Tagging rigoureux des ressources (par projet, équipe, environnement)
• Reserved Instances / Savings Plans pour workloads stables
• Spot instances pour workloads interruptibles
• Auto-scaling et right-sizing continus
• Shutdown automatique des ressources non-prod

Règle empirique (rough estimate)

• Pour des charges stables : on-premise souvent plus économique à partir de 3-5 ans
• Pour des charges variables : cloud public plus économique
• Le break-even dépend énormément du contexte

Exemple chiffré simplifié

Hypothèse : application nécessitant 10 serveurs moyens (8 cores, 32GB RAM)

On-premise (5 ans)

• Serveurs : 50k€
• Stockage : 20k€
• Réseau : 10k€
• Licences VMware/Windows : 30k€
• Datacenter (5 ans) : 25k€
• Personnel (1 ops, 5 ans) : 300k€
• Maintenance/renouvellement : 30k€
• Total : ~465k€ soit 93k€/an

Cloud public (5 ans)

• 10 instances (m5.2xlarge AWS) : 150k€/an
• Stockage (1TB par serveur) : 15k€/an
• Transfert sortant (estimé) : 10k€/an
• Services managés : 20k€/an
• Total : ~195k€/an x 5 = 975k€

→ Dans cet exemple, on-premise est 2x moins cher... MAIS :

• Le cloud offre une élasticité (scale down hors heures)
• Pas de gros investissement initial
• Innovation et services managés disponibles
• Pas de risque d'obsolescence

Si on optimise le cloud (reserved instances, auto-scaling, shutdown non-prod)

• Économie de 30-50% possible → ~500-700k€
• On se rapproche du coût on-premise

Conclusion TCO

Le TCO seul ne suffit pas. Il faut pondérer avec les autres critères (agilité, time-to-market, risques).

Compétences de l'équipe

Le facteur humain est souvent sous-estimé, pourtant c'est un critère décisif. Une technologie excellente avec une équipe qui ne la maîtrise pas = échec.

État des lieux des compétences actuelles

Questions à se poser

• Quelle est la taille de l'équipe IT/Ops ?
• Quelles sont les compétences actuelles (technologies maîtrisées) ?
• Quel est le niveau de maturité DevOps/Cloud ?
• Quelle est la capacité d'apprentissage de l'équipe ?
• Quel est le turnover (risque de perte de connaissance) ?
• Y a-t-il une culture d'innovation ou plutôt conservatrice ?

Compétences requises par modèle

On-premise traditionnel

• Administration systèmes (Linux, Windows Server)
• Virtualisation (VMware, Hyper-V, Proxmox)
• Réseau (Cisco, routage, switching, VLANs)
• Stockage (SAN, NAS, LVM, RAID)
• Sécurité infrastructure (firewalls, VPN)
• Hardware (maintenance, diagnostic)
• Datacenter operations
• Monitoring classique (Nagios, Zabbix)

Cloud public

• Nouveaux paradigmes : mindset cloud-native
• Services cloud spécifiques (EC2, S3, Lambda, RDS, etc.)
• Infrastructure as Code (Terraform, CloudFormation)
• Conteneurisation (Docker, Kubernetes)
• CI/CD (Jenkins, GitLab CI, GitHub Actions)
• Serverless et event-driven architecture
• Cloud networking (VPC, subnets, security groups)
• IAM et gestion des accès cloud
• Monitoring cloud (CloudWatch, Stackdriver)
• FinOps (optimisation des coûts)
• Sécurité cloud (responsabilité partagée)

Cloud privé

• Mix des deux mondes
• Compétences infrastructure traditionnelles
• Plus : orchestration cloud (OpenStack, VMware Cloud)
• Automatisation poussée (Ansible, Puppet, Chef)
• APIs et scripting avancé
• Software-Defined Networking (SDN)
• Software-Defined Storage (SDS)

Hybride

• Le plus exigeant : toutes les compétences ci-dessus
• Networking avancé (VPN, Direct Connect, SD-WAN)
• Gestion multi-environnements
• Orchestration cross-platform (Terraform multi-cloud)
• Observabilité distribuée
• Security across boundaries

Gap analysis et plan d'action

Évaluer l'écart

1. Compétences actuelles vs compétences cibles
2. Identifier les gaps critiques
3. Prioriser selon la stratégie choisie

Combler l'écart

Formation

• Certifications cloud (AWS Certified, Azure, GCP)
• Formations internes (workshops, brown bags)
• Formations externes (bootcamps, cours en ligne)
• Conférences et meetups
• Budget : 2-5k€ par personne et par an

Recrutement

• Profils cloud rares et chers (pénurie)
• Guerre des talents (GAFAM, startups)
• Délai de recrutement long (3-6 mois)
• Coût : salaires 20-40% supérieurs pour profils cloud expérimentés
• Risque : turnover élevé dans l'IT

Conseil / Accompagnement

• Faire appel à des experts externes (transition)
• Cabinets spécialisés (Accenture, Capgemini, etc.)
• Freelances/consultants ponctuels
• Coût : TJM 500-1500€ selon expertise
• Attention : transfer de connaissance indispensable

Partenariats / Managed services

• Déléguer une partie de l'ops (managed cloud)
• MSP (Managed Service Provider)
• Réduit le besoin en compétences pointues
• Coût : 20-40% du budget cloud en plus
• Risque : dépendance, perte de contrôle

Montée en compétences progressive

• Commencer par des projets pilotes (POC)
• Pair programming / mob programming
• Documentation et knowledge sharing
• Postmortems et retours d'expérience
• Culture du "fail fast, learn fast"

Culture et mindset

Transition culturelle nécessaire

On-premise → Cloud

• De "pets" (serveurs nommés, choyés) à "cattle" (troupeau jetable)
• De changements rares et contrôlés à déploiements fréquents
• De tickets manuels à automation/self-service
• De silos (dev/ops/sécu) à DevSecOps
• De planification long terme à itératif/agile

Résistance au changement

• Peur de l'obsolescence ("mon job va disparaître")
• Confort de la maîtrise actuelle
• Scepticisme sur le cloud ("c'est juste l'ordinateur de quelqu'un d'autre")
• Attachement à l'infrastructure physique

Gérer la résistance

• Communication transparente sur la vision
• Impliquer l'équipe dans les décisions
• Valoriser l'apprentissage
• Montrer les opportunités (nouvelles compétences, carrière)
• Quick wins pour prouver la valeur
• Accompagnement psychologique si nécessaire

Taille d'équipe par modèle (ordre de grandeur)

Pour une infrastructure moyenne (50-100 serveurs/VMs) :

On-premise

• 3-5 ops/sysadmins
• 1-2 réseau
• 1 sécurité
• 1 DBA (selon l'usage)
• Total : 5-10 personnes

Cloud public (bien optimisé)

• 2-3 cloud engineers/SRE
• 1 FinOps (peut être partagé)
• Sécurité mutualisée avec le dev (shift-left)
• Total : 2-4 personnes (moins d'ops, plus de dev)

Cloud privé

• 3-4 ops (gestion de la plateforme)
• 1-2 réseau
• 1 sécurité
• Total : 5-7 personnes

Hybride

• Le plus exigeant : 6-12 personnes selon la complexité

→ Le cloud public bien fait réduit le besoin en ops, mais requiert des profils plus qualifiés (et donc plus chers).

Recommandations

• Ne pas sous-estimer le facteur humain
• Anticiper la formation (6-12 mois avant migration)
• Prévoir un budget formation conséquent (5-10% masse salariale IT)
• Si l'équipe est petite (<5 personnes) : privilégier cloud public ou managed services
• Si l'équipe résiste fortement : peut-être rester on-premise n'est pas si mal

Roadmap technique

La stratégie d'hébergement doit s'aligner avec la vision technique à moyen/long terme.

Vision technique et stratégie entreprise

Questions stratégiques

• Quelle est la stratégie business de l'entreprise (croissance, stabilité, pivot) ?
• Quelle est la vision produit (fonctionnalités prévues) ?
• Quels sont les objectifs IT (innovation, optimisation, réduction coûts) ?
• Quel est l'horizon de la refonte (1 an, 3 ans, 5 ans) ?
• Y a-t-il des contraintes temporelles (dead-lines réglementaires, contrats) ?

Alignement hébergement / roadmap

Scénario : Croissance rapide prévue

• Besoin de scalabilité importante
• Incertitude sur les volumes → Cloud public : élasticité, pay-as-you-grow

Scénario : Stabilisation et optimisation

• Volumes prévisibles et stables
• Focus sur la réduction des coûts → On-premise ou cloud privé : TCO optimisé

Scénario : Innovation produit intensive

• Besoin d'expérimenter (IA/ML, IoT, big data)
• Time-to-market critique → Cloud public : accès à services innovants

Scénario : Transformation digitale progressive

• Migration du legacy sur plusieurs années
• Coexistence ancien/nouveau monde → Hybride : progressivité

Stack technique et architecture

Applications monolithiques legacy

• Difficiles à migrer dans le cloud
• Nécessitent souvent refactoring
• Peuvent rester on-premise temporairement ou définitivement
• Stratégie : strangler pattern (étrangler progressivement)

Architecture microservices / cloud-native

• Conçue pour le cloud (stateless, 12-factor)
• Conteneurisée (Docker/Kubernetes)
• Event-driven, resilient → Cloud public ou privé : tirent pleinement parti des capacités

Applications avec état (stateful)

• Bases de données complexes
• Systèmes de fichiers partagés
• Applications legacy avec état local → Plus complexes dans le cloud, considérer hybride

Dépendances et intégrations

Systèmes interconnectés

• ERP on-premise
• Applications métier legacy
• APIs et flux de données entre systèmes
• Latence critique entre composants

→ Si forte interdépendance on-premise, garder proximité ou prévoir liens dédiés

Partenaires et fournisseurs

• Intégrations B2B
• EDI (Échange de Données Informatisées)
• APIs exposées à des tiers → Cloud public facilite l'exposition sécurisée

Évolutions technologiques anticipées

Court terme (0-2 ans)

• Quelles technologies seront adoptées ?
• Quels projets sont déjà planifiés ?
• Quels besoins métier émergent ?

Moyen terme (2-5 ans)

• Quel niveau de maturité DevOps visé ?
• Adoption de conteneurs ? Kubernetes ?
• Serverless envisagé ?
• IA/ML dans la roadmap ?

Long terme (>5 ans)

• Vision aspirationnelle
• Transformation complète ?
• All-in cloud ou hybride durable ?

Stratégies de migration

Big bang

• Tout migrer d'un coup
• Risqué, complexe, rarement recommandé
• Peut être envisagé pour petites infrastructures simples

Progressif / par vagues

• Migrer application par application
• Réduire les risques
• Apprendre et ajuster en continu
• Recommandé pour la plupart des cas

Strangler pattern

• Nouveau système "étrangle" progressivement l'ancien
• Fonctionnalités migrées une par une
• Coexistence longue période
• Idéal pour refonte de monolithes

Lift-and-shift puis optimize

• Phase 1 : migrer tel quel (rehosting)
• Phase 2 : optimiser et refactorer
• Rapide à démarrer, amélioration continue
• Bon compromis rapidité/risque

Priorisation des workloads à migrer

Critères de priorisation

1. Quick wins : applications simples, peu risquées, haute visibilité
2. Obsolescence : systèmes arrivant en fin de vie
3. Coût : applications coûteuses à héberger on-premise
4. Business value : impact métier fort
5. Dépendances : minimiser d'abord, complexes ensuite

Matrice de priorisation

• Axe X : Complexité technique (faible → élevée)
• Axe Y : Valeur métier (faible → élevée)
• Prioriser : haute valeur, faible complexité (quick wins)
• Planifier soigneusement : haute valeur, haute complexité
• Différer : faible valeur, haute complexité

Gestion du legacy

Stratégies avec les systèmes legacy

Retire (retirer)

• Application plus utilisée ou redondante
• Décommissionner
• Archiver les données si nécessaire

Retain (conserver)

• Système stable, fonctionne, pas de ROI à migrer
• Garder on-premise
• Réévaluer périodiquement

Rehost (lift-and-shift)

• Migrer tel quel (VM → VM cloud)
• Rapide, peu risqué
• Ne tire pas parti du cloud

Replatform (lift-and-reshape)

• Adaptations mineures (DB managée au lieu de VM+DB)
• Compromis effort/bénéfice
• Bon pour beaucoup d'apps

Refactor/Re-architect

• Réécriture significative
• Architecture cloud-native
• Coûteux mais maximise les bénéfices cloud

Replace

• Remplacer par SaaS ou COTS
• Exemple : Exchange → Office 365
• Réduit la maintenance

Rebuild

• Réécrire from scratch
• Rarement justifié (très coûteux)
• Si technologie obsolète et critique

Roadmap de compétences

La roadmap technique doit s'accompagner d'une roadmap de montée en compétences (voir section Compétences de l'équipe).

Checkpoints et réversibilité

• Prévoir des points de validation (go/no-go)
• Possibilité de rollback en début de migration
• Plan B si les hypothèses s'avèrent fausses

Exemple de roadmap 3 ans

Année 1 : Fondations et quick wins

• Q1 : Formation équipe, POC cloud
• Q2 : Migration environnements dev/test
• Q3-Q4 : Migration apps non-critiques (quick wins)
• Parallèle : Setup réseau (Direct Connect), IAM, monitoring

Année 2 : Apps métier et optimisation

• Q1-Q2 : Migration apps métier prioritaires
• Q3 : Refactoring première vague (cloud-native)
• Q4 : Optimisation coûts (reserved instances, right-sizing)

Année 3 : Workloads complexes et hybride stabilisé

• Q1-Q2 : Migration workloads complexes/legacy
• Q3 : Consolidation, optimisation finale
• Q4 : Décommissionnement infrastructure on-premise (ou conservation si hybride durable)