Une nouvelle architecture gagne facilement au tableau blanc. Les boîtes sont propres, les services sont gérés et aucune flèche ne traîne encore dix ans d’exceptions. L’ancien système paraît toujours plus lourd parce qu’il contient tout ce qui est arrivé pour vrai.

C’est pourquoi je reste prudent quand une migration vers le cloud est présentée comme une évidence.

En 2019, le nuage est une option d’architecture mature. Il donne accès à de l’infrastructure automatisée, à une capacité variable et à des services gérés qu’il serait difficile de reproduire seul. La question est de savoir quel problème précis il règle et comment on déplace le système sans perdre une transaction.

Mesurer le problème avant le fournisseur

Les bonnes raisons sont concrètes : absorber une pointe, réduire le délai de livraison, améliorer la reprise ou arrêter d’opérer une composante qui ne différencie pas l’entreprise. Je leur donnerais une mesure de départ et une cible :

Besoin	Aujourd’hui	Cible vérifiable
pointe saisonnière	saturation à 300 req/s	600 req/s avec p95 < 500 ms
livraison	14 jours pour un environnement	moins de 2 heures par pipeline
reprise	restauration manuelle, 12 h	RTO 2 h, RPO 15 min testés
coût	matériel et licences fixes	coût par commande suivi mensuellement

Le RTO est le temps maximal visé pour remettre le service en fonction. Le RPO est la quantité de données qu’on accepte de perdre. Écrire ces nombres force le design : réplication, sauvegardes, fréquence des journaux et procédure de bascule. « Le cloud est résilient » ne dit rien sur notre base ni sur nos tests.

Déplacer une tranche plutôt que tout réécrire

Une réécriture complète doit redécouvrir les règles cachées pendant que l’ancien système continue de rouler. Je préfère souvent le strangler pattern : placer une façade devant le système et détourner graduellement certaines fonctions vers de nouveaux composants.

clients → routeur/API
              ├─ /catalogue  → nouveau service cloud
              ├─ /commandes  → ancien système
              └─ /comptes    → ancien système

Le premier candidat devrait avoir une frontière claire, des tests et un retour arrière simple. Le routeur envoie une petite proportion du trafic, compare erreurs et latence, puis augmente graduellement. Si les métriques se dégradent, il renvoie tout vers l’ancien chemin.

La difficulté arrive avec les données. Si le catalogue est lu dans le cloud mais modifié dans l’ancien ERP, il faut une réplication. Un journal de changements ou une table d’événements peut envoyer les mises à jour dans l’ordre. Chaque événement porte un identifiant et une version; le consommateur l’applique de façon idempotente et mesure son retard.

{
  "eventId": "evt-94821",
  "type": "ProductPriceChanged",
  "productId": "P-42",
  "version": 18,
  "price": 249.99,
  "currency": "CAD"
}

La double écriture depuis l’application est plus fragile. Si l’ancien système accepte le prix et le nouveau refuse, lequel gagne? Une source de vérité publie son changement après la transaction; l’autre côté reprend les erreurs et peut rejouer. Tant que la réplication n’est pas à jour, le design doit décider si une lecture tolère l’ancien prix ou revient vers la source.

Payer et opérer la coexistence

Pendant la transition, on paie les deux environnements, le transfert de données, la journalisation et l’équipe qui apprend les nouveaux outils. Le modèle financier devrait inclure la migration, pas seulement l’état final :

coût mensuel de coexistence
  = ancien hébergement
  + nouveaux services cloud
  + trafic et stockage
  + licences/outils de migration
  + temps d’exploitation supplémentaire

Une ressource élastique réduit le coût seulement si elle peut réellement diminuer. Une base dimensionnée pour la pointe et active tout le mois reste une dépense fixe sous une autre forme. Je suivrais le coût par commande, par client actif ou par traitement, ainsi que les ressources sans propriétaire.

Un service géré retire certaines tâches — remplacement de disque, correctifs du moteur ou réplication selon l’offre — mais il ne retire pas la responsabilité des schémas, des accès, des sauvegardes ni des requêtes. Il ajoute une dépendance envers l’API, les quotas, la région, les prix et le chemin d’export du fournisseur.

Tester la sortie avant d’entrer

Je ferais un exercice de reprise avant la bascule :

1. restaurer la base dans un environnement vide;
2. redéployer l’infrastructure à partir du code;
3. remplacer un secret et vérifier les identités de service;
4. couper la région ou le composant simulable;
5. mesurer le RTO, le RPO et les étapes manuelles;
6. exporter un jeu de données exploitable hors du service.

Les pannes de migration les plus dangereuses sont silencieuses : événements en retard, encodage changé, fuseau horaire différent, permissions trop larges ou métrique absente. Une période parallèle doit comparer les comptes, sommes et clés, pas seulement une page qui s’ouvre.

Comme directeur technique, j’aime une solution bien conçue. Je dois aussi savoir quel problème paie la transition et quelle équipe l’opère. Le cloud est assez mature pour être évalué comme les autres options : métrique de départ, tranche migrée, mécanisme de données, coût de coexistence et retour arrière. Si le principal argument reste le nom moderne des services dans le diagramme, je ne déplacerais pas encore le premier client.