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

Quelles décisions prendre avant de migrer quoi que ce soit ?

Trois, et aucune n'est technique. Où résident les données et sous quel droit ; ce qui reste sur site et pourquoi ; qui exploite après la bascule. Sans ces réponses écrites, l'organisation hérite d'une architecture hybride subie plutôt que choisie, et d'une facture qui dérive mois après mois.

Ces trois décisions sont rarement prises parce qu'elles engagent la direction plutôt que la technique. Les repousser ne les annule pas : elles se prennent alors 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-il compatible avec la Loi 25 ?

Oui, à condition de traiter la question 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. Ce qui se règle en amont devient coûteux à rattraper après.

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 du fournisseur.

Nous instruisons donc cette question avec la cartographie des données, avant la conception, et non comme une case à cocher en fin de projet.

Comment évite-t-on la dérive des coûts ?

En traitant le coût comme une contrainte de conception plutôt que comme un sujet de facturation. Le dimensionnement, les politiques d'arrêt automatique, la classe de stockage par type de donnée et l'attribution des dépenses par service se décident au moment de l'architecture. 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. Il est rarement estimé à la conception et se révèle à la facture, notamment sur les architectures hybrides où les échanges entre le site et le cloud sont fréquents.

L'attribution des dépenses par service ou par application est le levier le plus efficace, parce qu'elle rend le coût visible par celui qui le génère.

Azure ou AWS : comment trancher ?

Rarement sur les capacités techniques, qui se recouvrent largement pour les usages d'une PME ou d'une organisation de taille moyenne. 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, et souvent des droits déjà acquis.

À l'inverse, une charge applicative particulière ou une compétence interne déjà constituée peut justifier l'autre choix. Le multi-cloud, lui, se décide rarement pour de bonnes raisons dans une organisation de taille moyenne : il double la surface à maîtriser pour un bénéfice théorique.

Nous ne revendons aucune licence et nous ne sommes revendeur d'aucune des deux plateformes, ce qui rend cet arbitrage vérifiable.

Questions fréquentes