Épreuve – Mini rapport d’audit technique et stratégie de migration cloud

Contexte général

Un organisme gère un moteur transactionnel utilisé par une compagnie en charge du remboursement et de la gestion des cotisations d’assurés sociaux, dans un environnement dépendant de la Sécurité sociale.

L’application est critique : elle traite quotidiennement des flux de remboursement, des calculs de droits, des mises à jour de dossiers assurés, ainsi que des échanges avec plusieurs systèmes externes. Une interruption du service ou une altération des données peut avoir des conséquences fortes sur la continuité du service rendu, la conformité réglementaire et la confiance des usagers.

Le volume traité est élevé, avec un ordre de grandeur de 100 millions de transactions COBOL par mois avec en moyenne 10 Ko (8Gb RAM occupée) utiles moyens par transaction pour une durée de traitement de 800ms. Les traitements batch représentent environ 20 % des transactions hebdomadaires, ce qui en fait un composant important du fonctionnement global, mais distinct du transactionnel temps réel. Seules les requêtes critiques (1 requête sur 5) sont sauvegardées.

Le présent périmètre correspond à une première tranche de migration, intégrée dans une trajectoire plus large de transformation du système d’information. Cette application constitue ainsi la tranche 1 sur 20 d’un programme de migration progressif. Le choix proposé devra donc rester cohérent avec une logique de standardisation, de réutilisation des principes d’architecture et de reproductibilité sur d’autres applications du SI.

Le système actuel présente une dette technique importante. L’organisation souhaite définir une stratégie de migration vers un cloud souverain tout en conservant un niveau élevé de sécurité, de traçabilité et de maîtrise des coûts.

Une contrainte technique importante s’ajoute au projet : l’environnement actuel repose sur des serveurs IBM Power sous AIX (architecture PowerPC / POWER), alors que le système cible devra fonctionner sous Linux. Le sujet ne porte donc pas sur un simple changement d’hébergement, mais sur une transformation technique plus structurante.

---

Contexte métier

L’application permet notamment :

• le calcul et le traitement de remboursements,
• la gestion des cotisations,
• la mise à jour des dossiers assurés,
• la consultation d’informations par les gestionnaires,
• l’échange de données avec des systèmes partenaires.

L’application s’appuie en partie sur un patrimoine COBOL, encore fortement intégré au fonctionnement du moteur transactionnel. Cette caractéristique pèse sur la maintenabilité, la modernisation, les possibilités d’automatisation et les choix de migration.

Le service est utilisé par plusieurs catégories d’acteurs :

• des agents de gestion,
• des équipes métier,
• des équipes techniques et d’exploitation,
• des systèmes partenaires exposant ou consommant des flux.

L’activité est sensible car elle manipule des données personnelles et sociales. Les exigences de confidentialité, d’intégrité, de disponibilité, de traçabilité et de conformité réglementaire sont donc très fortes.

À titre de contexte complémentaire, l’application s’inscrit dans un environnement proche d’un grand régime de protection sociale sectoriel : gestion des prestations, des cotisations, des affiliations, des échanges inter-régimes, des flux réglementaires, des opérations de contrôle et de consultation par les gestionnaires. Le sujet ne demande pas de traiter tous ces domaines, mais ce contexte explique le niveau de sensibilité, la volumétrie et la nécessité d’une migration progressive.

---

État actuel du système

L’application repose actuellement sur une infrastructure hébergée en datacenter interne.

Infrastructure existante

L’environnement actuel est composé de 15 serveurs IBM Power sous AIX, correspondant à une infrastructure historique puissante mais coûteuse, spécialisée et devenue difficile à faire évoluer.

Élément	Configuration actuelle	Observations
Serveurs applicatifs transactionnels	8 serveurs IBM Power sous AIX, 24 cœurs POWER, 256 Go RAM, 2 x 1,92 To SSD chacun	Hébergement du moteur transactionnel principal ; forte dépendance à la plateforme AIX
Serveurs de services métier	3 serveurs IBM Power sous AIX, 16 cœurs POWER, 128 Go RAM, 1,92 To SSD chacun	Services métier annexes, APIs internes, traitements complémentaires
Serveurs batch	2 serveurs IBM Power sous AIX, 16 cœurs POWER, 128 Go RAM, 1,92 To SSD chacun	Exécution des traitements nocturnes et régulations différées ; cible attendue : remplacement par une solution managée avec un minimum de responsabilités d’exploitation
Serveurs d’intégration / échanges	1 serveur IBM Power sous AIX, 12 cœurs POWER, 64 Go RAM, 960 Go SSD	Échanges avec systèmes partenaires et flux réglementaires
Serveur base de données principal	1 serveur IBM Power haut de gamme sous AIX, 64 cœurs POWER, 2 To RAM, 8 To SSD	Base centrale critique, forte sensibilité aux indisponibilités, composant majeur du SI
Supervision	Outils partiels, journalisation incomplète	Visibilité limitée sur les incidents
Sauvegardes	Sauvegardes quotidiennes locales	Tests de restauration irréguliers
Déploiement	Procédures manuelles	Risque d’erreurs et faible répétabilité

Repère technique sur les serveurs existants

L’infrastructure existante s’appuie sur des serveurs de type IBM Power capables d’exécuter AIX, avec des caractéristiques de haut niveau. À titre indicatif, les gammes IBM Power S1022 prennent en charge jusqu’à 40 cœurs Power10 et 4 To de mémoire, tandis que les serveurs IBM Power E1080 peuvent aller jusqu’à 240 cœurs et 64 To de mémoire. Le parc étudié dans cette épreuve s’inscrit dans cette logique de serveurs AIX puissants, spécialisés et orientés charges critiques.

Constats techniques observés

• dette technique élevée,
• dépendance forte à la plateforme AIX / POWER,
• présence d’un patrimoine COBOL important,
• écart technologique important entre le système source et le système cible Linux,
• architecture vieillissante,
• dépendance forte à quelques composants centraux,
• procédures de déploiement encore largement manuelles,
• supervision partielle,
• reprise d’activité insuffisamment testée,
• capacité de montée en charge coûteuse,
• forte sensibilité de la base de données,
• exposition réglementaire élevée en cas d’incident ou de fuite,
• compétences AIX et COBOL plus rares et plus coûteuses à mobiliser.

---

Contraintes majeures

Le projet doit tenir compte des contraintes suivantes :

• réglementation forte sur les données traitées ;
• sensibilité élevée du service ;
• nécessité d’assurer une continuité d’activité ;
• nécessité de conserver une traçabilité complète ;
• dette technique importante rendant certaines évolutions complexes ;
• présence d’un patrimoine COBOL à prendre en compte dans la migration ;
• impossibilité d’interrompre durablement le service ;
• besoin de maîtriser le niveau de complexité de la future solution ;
• nécessité de migrer d’un environnement AIX / POWER vers un environnement Linux ;
• la partie services métier ne fait pas partie du périmètre de cet appel d’offre ;
• les serveurs batch doivent être remplacés par une solution apportant le minimum de responsabilités d’exploitation ;
• les serveurs applicatifs transactionnels doivent pouvoir absorber une forte montée en charge à moyen terme, notamment en raison d’une fusion à venir avec une autre branche de la protection sociale ;
• le périmètre traité constitue une tranche 1 sur 20 d’un programme global de migration du SI ;
• la solution proposée doit donc rester réplicable, standardisable et compatible avec une gouvernance transverse ;
• recherche d’un cloud souverain fictif offrant hébergement, sécurité et réversibilité.

---

Hypothèse de fournisseur cloud souverain fictif

Le commanditaire envisage un hébergement chez le fournisseur fictif HexaCloud Souverain, opérateur français imaginaire proposant un environnement IaaS / PaaS dédié aux acteurs publics et parapublics.

Exemples de tarifs indicatifs – HexaCloud Souverain

Les tarifs ci-dessous sont fictifs et fournis uniquement pour l’épreuve.

Ressource	Tarif mensuel fictif
VM Linux 2 vCPU / 8 Go RAM	95 €
VM Linux 4 vCPU / 16 Go RAM	180 €
VM Linux 8 vCPU / 32 Go RAM	320 €
VM Linux 16 vCPU / 64 Go RAM	620 €
VM Linux 32 vCPU / 128 Go RAM	1 180 €
Base de données PostgreSQL managée – petite taille	420 €
Base de données PostgreSQL managée – taille moyenne	850 €
Base de données PostgreSQL managée – haute disponibilité	1 450 €
Base de données PostgreSQL managée – haute performance (non HA)	2 200 €
Stockage bloc SSD	0,14 € / Go / mois
Stockage bloc HDD	0,06 € / Go / mois
Stockage objet standard	0,03 € / Go / mois
Stockage objet archivage	0,008 € / Go / mois
Sauvegardes managées	0,05 € / Go / mois
Restauration ponctuelle de sauvegarde	45 € / opération
Snapshot de volume	0,04 € / Go / mois
Load balancer managé	90 €
API Gateway managé	110 €
Journalisation / supervision managée	220 €
Supervision avancée avec rétention étendue	390 €
Pare-feu managé / filtrage réseau	160 €
WAF managé	210 €
VPN / interconnexion sécurisée	180 €
Lien privé dédié inter-sites	490 €
Service IAM / fédération d’identités	120 €
Coffre-fort de secrets	75 €
Bastion d’administration managé	95 €
Registre de conteneurs privé	60 €
Orchestrateur Kubernetes managé – cluster de base	480 €
Ordonnanceur managé de traitements	120 €
File de messages managée	85 €
Bus d’événements managé	140 €
Cache managé	160 €
Fonction serverless type Lambda – requêtes	0,24 € / 1 000 000 requêtes
Fonction serverless type Lambda – calcul	0,000018 € / GB-seconde
Fonction serverless type Lambda – 10 000 000 requêtes	2,40 €
Service de transfert de fichiers managé	130 €
Service DNS privé	35 €
Certificats managés	25 € / certificat / mois

Services disponibles chez HexaCloud Souverain

• machines virtuelles Linux,
• base de données managée,
• stockage bloc, objet et archivage,
• services de sauvegarde et snapshots,
• journalisation centralisée,
• supervision managée,
• segmentation réseau,
• pare-feu et WAF managés,
• interconnexion sécurisée,
• contrôle d’accès renforcé,
• API Gateway managé,
• fonctions serverless de type Lambda,
• ordonnanceur de traitements managé,
• services de file de messages et d’événements,
• registre de conteneurs privé,
• Kubernetes managé,
• cache managé,
• DNS privé,
• coffre-fort de secrets,
• bastion d’administration managé,
• certificats managés,
• service de transfert de fichiers managé.

Repères de coût pour les fonctions serverless

À titre indicatif, le fournisseur fictif propose une tarification proche des modèles serverless du marché :

• 0,24 € par 1 000 000 requêtes ;
• 0,000018 € par GB-seconde de calcul.

Exemple simplifié :

• 1 000 000 requêtes sur une fonction serverless = 0,24 € de coût de requêtes ;
• le coût total dépend ensuite de la durée d’exécution et de la mémoire allouée.

Ces valeurs sont fournies pour permettre un raisonnement budgétaire simple dans l’épreuve.

---

Orientation attendue

L’organisme souhaite étudier une stratégie de migration vers le cloud adaptée à ce contexte.
Le choix devra rester réaliste, justifié et compatible avec :

• la sensibilité du service,
• la dette technique existante,
• la présence de composants COBOL,
• le changement de socle AIX vers Linux,
• les capacités de l’équipe,
• les contraintes réglementaires,
• la nécessité de maintenir l’activité.

Le candidat devra également tenir compte des orientations suivantes :

• la partie services métier n’est pas traitée dans cet appel d’offre ;
• les serveurs batch doivent être remplacés par une solution apportant le minimum de responsabilités d’exploitation ;
• les serveurs applicatifs transactionnels doivent être conçus pour une forte évolutivité de charge.

Le candidat devra tenir compte du fait qu’une migration directe de type relocate est peu adaptée dans ce contexte, car le système de destination doit être exploité sous Linux. Il pourra s’appuyer, s’il le juge pertinent, sur les stratégies de migration étudiées en cours : retain, relocate, rehost, replatform, refactor, rearchitect, repurchase, retire.

---

Travail demandé

À partir du cas proposé, réalisez un mini rapport d’audit de l’application.

Votre travail doit faire apparaître :

1. les principaux constats ;
2. le type d’architecture initiale ;
3. les pistes de rationalisation ;
4. un budget prévisionnel simplifié ;
5. les mesures de sécurité prioritaires ;
6. une conclusion argumentée.

L’objectif est de formuler une recommandation cohérente, réaliste et justifiée.

---

Consignes de l’exercice

1. Analyse du contexte

• rappeler le contexte métier ;
• identifier le rôle de l’application ;
• préciser les principaux acteurs ou utilisateurs concernés ;
• reformuler les principaux constats observés ;
• qualifier le type d’architecture initiale.

2. Analyse des besoins

• distinguer les besoins actuels ;
• identifier les besoins futurs ;
• relier les constats aux besoins formulés ;
• faire apparaître les principales contraintes ;
• préciser les impacts du patrimoine COBOL, du passage AIX vers Linux, de l’exclusion du périmètre services métier et du besoin de forte montée en charge des serveurs transactionnels.

3. Choix technique et cohérence d’architecture

• préciser le type d’architecture cible retenu pour les serveurs applicatifs transactionnels ;
• préciser la nature de la migration mise en œuvre pour ce chantier ;
• expliquer en quoi ce choix répond au besoin ;
• montrer en quoi le passage de AIX vers Linux et la présence de COBOL influencent la stratégie choisie ;
• préciser comment seront traités les serveurs transactionnels à forte montée en charge ;
• proposer une cible pertinente pour remplacer les serveurs batch avec un minimum de responsabilités d’exploitation ;
• préciser également le type d’architecture cible retenu pour le chantier batch ;
• préciser la nature de la migration mise en œuvre pour ce second chantier ;
• montrer qu’elle reste cohérente avec les capacités de l’équipe et le niveau de complexité acceptable ;
• proposer une stratégie de migration vers le cloud adaptée au contexte.

4. Rationalisation et coûts

• identifier les principaux postes de coût ;
• proposer des pistes simples de rationalisation ;
• justifier les arbitrages entre performance, disponibilité et coût.

5. Budget prévisionnel

• présenter un budget simplifié ;
• faire apparaître les principaux postes de dépense ;
• formuler les principales hypothèses de calcul ;
• vérifier la cohérence avec les moyens du projet.

6. Sécurité cloud

• identifier les mesures de sécurité prioritaires ;
• préciser les principaux risques à réduire ;
• montrer que la solution retenue protège les accès, les données et la continuité de service.

7. Conclusion d’audit

• formuler une recommandation globale ;
• rappeler les bénéfices attendus ;
• mentionner les principaux points de vigilance ;
• justifier la solution retenue de manière synthétique.

---

Attendus de qualité

La réponse doit être :

• courte,
• structurée,
• argumentée,
• cohérente avec le contexte,
• réaliste,
• compatible avec une logique de généralisation à d’autres applications du SI.

Il ne s’agit pas de rédiger un rapport long, mais une analyse synthétique montrant la capacité à passer :

• du constat,
• au besoin,
• puis à une recommandation argumentée,

permettant ainsi de justifier une décision.