Migrer vers le cloud sans perdre le contrôle de vos données

L’architecture hybride que vous avez n’a été décidée par personne

Une application est partie chez un éditeur, une autre chez un hébergeur, la messagerie ailleurs, et le reste est demeuré sur site parce que personne n’a tranché. Chacune de ces décisions était raisonnable isolément ; leur somme ne l’est pas.

Trois questions évitent cette dérive, et aucune n’est technique. Repoussées, elles ne disparaissent pas : elles se prennent par défaut, au fil des migrations, sans que personne les ait arbitrées.

• La résidence des données. Elle détermine le droit applicable, les obligations de notification et ce que vous devrez démontrer à un client ou à un régulateur. Elle se décide par catégorie de donnée, pas globalement.
• Ce qui reste sur site. Certaines charges n’ont aucun intérêt à migrer : dépendances matérielles, latence critique, licences liées au matériel. L’arbitrage se fait charge par charge, avec le motif écrit.
• Qui exploite après. La migration déplace la charge d’exploitation, elle ne la supprime pas. Une équipe qui gérait des serveurs devra gérer des abonnements, des identités et des coûts : ce n’est pas le même métier.

Le cloud est compatible avec la Loi 25, à une condition

Il faut la traiter comme une décision d’architecture. La loi n’interdit pas l’hébergement hors Québec : elle impose d’évaluer les facteurs relatifs à la vie privée avant toute communication à l’extérieur, et d’encadrer contractuellement le prestataire.

En pratique, la difficulté n’est pas juridique mais documentaire : la plupart des organisations ne savent pas quelles données partent où, parce que la question n’a jamais été posée service par service.

Un second point revient souvent, la sous-traitance en cascade. Un fournisseur situé au Canada peut lui-même s’appuyer sur des infrastructures ailleurs ; l’évaluation porte sur la chaîne réelle, pas sur l’adresse du siège social. Nous instruisons donc cette question avec la cartographie des données, avant la conception.

La dérive des coûts se traite à la conception

Le coût est une contrainte de conception, pas un sujet de facturation. Dimensionnement, politiques d’arrêt automatique, classe de stockage par type de donnée, attribution des dépenses par service : rétabli après coup, chacun de ces points demande de revenir sur des choix déjà déployés.

La dérive la plus courante ne vient pas d’un surdimensionnement mais de l’absence de propriétaire. Quand personne n’est responsable d’une ressource, personne ne l’arrête : les environnements de test tournent la nuit, les sauvegardes s’empilent, les volumes restent attachés à des machines supprimées.

Le second facteur est le transfert de données, rarement estimé à la conception et révélé à la facture, surtout sur les architectures hybrides où les échanges entre le site et le cloud sont fréquents. L’attribution des dépenses par service reste le levier le plus efficace : elle rend le coût visible par celui qui le génère.

Azure ou AWS se tranche sur l’existant, pas sur la technique

Les capacités techniques se recouvrent largement pour les usages d’une PME. La décision se prend sur l’existant, annuaire, licences, compétences internes, et sur la capacité de vos équipes à exploiter la plateforme au quotidien.

Une organisation dont l’annuaire et la bureautique sont déjà chez un éditeur réduit sa complexité en restant dans le même écosystème : moins d’intégrations à maintenir, une gestion des identités unique, des droits souvent déjà acquis. À l’inverse, une charge applicative particulière ou une compétence interne constituée peut justifier l’autre choix.

Le multi-cloud, lui, se décide rarement pour de bonnes raisons à cette échelle : il double la surface à maîtriser pour un bénéfice théorique. Nous ne sommes revendeur d’aucune des deux plateformes, ce qui rend cet arbitrage vérifiable.