Cas corrigé : migrer une application de Sorbier vers le cloud

Les trois services sont du PaaS : App Service héberge le code sans que Sorbier gère de serveur ; Azure Database for MySQL est une base managée ; Blob Storage est un service de stockage managé.

Tâches qui disparaissent, par exemple : appliquer les mises à jour du système et de PHP ou Node.js ; gérer le certificat HTTPS ; sauvegarder la base (les sauvegardes sont automatiques) ; remplacer le matériel en panne ou en fin de garantie ; surveiller l'espace disque.

Non. Le plan B1 (niveau Basic) ne permet pas la mise à l'échelle automatique : l'application ne passera pas seule à plusieurs instances en décembre. On perd la caractéristique d'élasticité, justement celle qui justifiait le cloud.

Il faut donc un plan Standard ou Premium. Le plan P0v3 coûte 0,0781 € de l'heure, moins que le S1 (0,0808 €), tout en étant plus récent : on choisit P0v3, avec une règle de mise à l'échelle automatique (par exemple, une instance de plus quand le processeur dépasse 70 %, jusqu'à 3 instances).

Pour : une VM donne le contrôle complet du système, et permet de reprendre l'application telle quelle, sans l'adapter (lift and shift).

Contre : Sorbier garderait toute l'administration du système (mises à jour, sécurisation, sauvegarde de la VM), qu'elle cherche justement à alléger ; et une VM seule n'est pas élastique, il faudrait plusieurs VM, un équilibreur de charge et une règle de mise à l'échelle pour absorber le pic de décembre.

Oui : nom, adresse, téléphone et signature identifient des personnes physiques, les destinataires des colis. Ce ne sont pas des données sensibles au sens de l'article 9.

Sorbier est responsable de traitement : elle décide des finalités et des moyens. Microsoft est sous-traitant : il traite les données pour le compte de Sorbier.

Leur relation doit être encadrée par un contrat de sous-traitance conforme à l'article 28 du RGPD (chez Microsoft, l'avenant sur la protection des données accepté avec les conditions du service). En fin de contrat, il doit prévoir la suppression ou la restitution de toutes les données, au choix du responsable de traitement.

Le CLOUD Act (2018) permet aux autorités américaines d'exiger d'un fournisseur soumis au droit américain les données qu'il contrôle, où qu'elles soient stockées. La région France Central fixe l'emplacement des données, pas le droit applicable à Microsoft.

SecNumCloud n'est pas exigé ici : Sorbier est une entreprise privée, et les données sont des données personnelles courantes, ni sensibles, ni de santé, ni des données de l'État. Le risque lié au Cloud Act est faible pour ces données ; il est noté dans l'analyse de risques et le registre des traitements. Si Sorbier traitait des données stratégiques, elle choisirait une offre qualifiée SecNumCloud ou chiffrerait les données avec des clés qu'elle seule détient.

• Application, une instance : 730 × 0,0781 = 57,013 €.
• Base : 730 × 0,0171 = 12,483 €, plus 32 × 0,1194 = 3,8208 € de stockage.
• Bons de livraison : 200 × 0,0094 = 1,88 €.

Mois normal : 57,013 + 12,483 + 3,8208 + 1,88 = 75,1968 €, soit 75,20 €.

Décembre, trois instances : 3 × 57,013 = 171,039 € pour l'application, donc 171,039 + 12,483 + 3,8208 + 1,88 = 189,2228 €, soit 189,22 €.

Coût annuel d'infrastructure : 11 × 75,1968 + 189,2228 = 827,1648 + 189,2228 = 1 016,39 €.

Administration : 0,5 × 45 × 12 = 270 € par an.

TCO cloud sur cinq ans : 5 × (1 016,3876 + 270) + 1 500 = 6 431,94 + 1 500 = 7 931,94 €.

TCO du serveur renouvelé : 4 800 + 5 × 2 075,60 = 15 178 €, comme au chapitre 5.

Le passage à Azure coûte 7 246,06 € de moins sur cinq ans.

Limites, par exemple : le volume des bons de livraison augmente de 40 Go par an, ce qui fait monter le coût du stockage (faiblement : 40 × 0,0094 = 0,376 € de plus par mois chaque année) ; les prix d'Azure peuvent évoluer ; le calcul ne compte ni les données sortantes ni les sauvegardes hors d'Azure ; le scénario sur site n'a pas le même niveau de service (pas d'élasticité, pas de sauvegarde automatique).

1. Les services nécessaires à une fonction sont en série : on multiplie leurs disponibilités.
   • Suivi des colis : 0,9995 × 0,999 = 0,9985005, soit 99,85 %. Arrêt toléré : (1 − 0,9985005) × 730 h ≈ 1,09 h, soit 1 h 6 min par mois.
   • Consultation des bons : 0,9985005 × 0,99 = 0,988515495, soit 98,85 %. Arrêt toléré : (1 − 0,988515495) × 730 h ≈ 8,38 h, soit 8 h 23 min par mois.
2. 4 heures sur 730 correspondent à une disponibilité de 1 − 4 ÷ 730 ≈ 99,45 %. Le suivi des colis (99,85 %) la respecte ; la consultation des bons (98,85 %) ne la respecte pas : le niveau froid fait chuter la disponibilité garantie. Deux solutions : garder au niveau chaud les bons récents, ceux que le service client consulte (0,9985005 × 0,999 ≈ 99,75 %, soit 1 h 49 min par mois), et ne passer en froid puis en archive que les bons anciens, par une règle de cycle de vie ; ou faire valider par la direction que l'exigence porte sur le suivi des colis, et pas sur les archives. Dans tous les cas, le SLA est un engagement, pas une garantie : la disponibilité réelle se mesure par la supervision.

En Burstable, sans haute disponibilité, la base est indisponible tant que la zone ne revient pas, et l'application avec elle. Passe la base en niveau General Purpose avec la haute disponibilité redondante entre zones : un serveur de secours dans une autre zone prend le relais automatiquement. Ce changement impose de créer un nouveau serveur (la haute disponibilité redondante entre zones se choisit à la création) et d'y restaurer les données, et il augmente le coût de la base.

(a) Microsoft : en PaaS, le système est géré par le fournisseur. (b) Sorbier : les comptes et identités restent toujours au client. (c) Microsoft. (d) Sorbier : le code de l'application est au client. (e) Sorbier : la gestion des accès aux données reste au client.

1. Le compte invité du prestataire est propriétaire (Owner) de tout l'abonnement. Il peut tout faire, y compris donner des droits. Correction : le rôle Contributor sur le seul groupe de ressources de l'application, pour la durée du projet, puis retrait ; MFA exigée pour les invités.
2. Le pare-feu de MySQL est ouvert à tout Internet (0.0.0.0 à 255.255.255.255). Correction : n'autoriser que les adresses sortantes de l'application et l'adresse d'administration du siège, ou mieux, passer la base en accès privé dans un réseau virtuel.
3. Le conteneur des bons de livraison est en lecture anonyme : n'importe qui peut lister et télécharger des documents qui contiennent des données personnelles. Correction : désactiver l'accès public du compte, donner à l'application une identité managée avec le rôle Storage Blob Data Reader, et générer des liens de partage temporaires (SAS) si un client doit recevoir son bon. Vérifier les journaux d'accès : si des lectures anonymes ont eu lieu, c'est une violation de données à traiter.
4. L'application se connecte avec le compte administrateur de MySQL. Une faille dans l'application donnerait tous les droits sur le serveur. Correction : un compte applicatif dédié, avec les seuls droits nécessaires sur la base de l'application (SELECT, INSERT, UPDATE sur les tables utiles), et son mot de passe dans Azure Key Vault, lu par l'identité managée.

On peut aussi relever que deux propriétaires, dont un externe, sans gestion des privilèges juste-à-temps, c'est beaucoup pour une PME.

• Base : les sauvegardes automatiques d'Azure, avec une rétention de 14 jours et la restauration à un instant précis (perte de quelques minutes au plus) ; plus un export mysqldump quotidien, chiffré, copié sur le NAS du siège. L'exigence de 24 heures est tenue même si l'on ne peut compter que sur l'export.
• Bons de livraison : suppression réversible et versionnage activés, compte en GRS pour une copie dans la région France South, et une copie hors d'Azure vers le stockage objet déjà utilisé par le NAS, avec un verrouillage contre la suppression.

On a bien trois copies (production, sauvegardes Azure, copie au siège ou chez l'autre fournisseur), sur deux supports différents, dont une hors site et hors du fournisseur. Un test de restauration complet est planifié chaque année.

Choix techniques, par exemple :

1. une base MySQL standard, exportable avec mysqldump et relisible par n'importe quel serveur MySQL ;
2. l'application livrée aussi sous forme d'image Docker, qui tournerait sur un autre cloud ou sur le cluster Proxmox du siège ;
3. un module d'accès au stockage isolé dans le code, seul à utiliser l'API de Blob Storage, et des exports réguliers des bons de livraison hors d'Azure.

Clauses, par exemple : les formats et délais de restitution des données, et la suppression de toutes les copies avec attestation en fin de contrat. Depuis le Data Act, Sorbier peut aussi compter sur un préavis de deux mois au plus, une période de transition de trente jours au plus, et l'absence de frais de changement de fournisseur à partir du 12 janvier 2027.