Basculer vers le cloud sans en faire un pari

Pourquoi une migration dérape

Presque toujours au même endroit : on découvre en cours de route ce que l'application fait vraiment. Un batch de nuit que personne n'avait documenté, une adresse IP écrite en dur, un partage réseau monté depuis un poste de bureau, un certificat renouvelé à la main par quelqu'un qui est parti. Rien de cela n'apparaît dans le schéma d'architecture.

L'inventaire n'est donc pas une formalité de début de projet, c'est là que se joue le calendrier. Tant qu'on ne sait pas ce qui parle à quoi, toute date annoncée est une opinion.

Comment la bascule se prépare

On part de l'existant : ce qui tourne, ce qui communique avec quoi, ce qui doit rester joignable depuis l'extérieur, qui détient les accès. Ensuite chaque composant reçoit une décision explicite. On déplace tel quel, on remplace par un service géré, on réécrit, ou on arrête. Une application qu'on arrête est la migration la moins chère qui existe, et il y en a toujours une ou deux.

La bascule se fait par lots, jamais en une nuit pour tout le système. Chaque lot arrive avec son plan de retour arrière, écrit avant et pas pendant : ce qui déclenche le retour, qui le décide, et combien de temps on a pour le faire. Un retour arrière qui n'a pas été testé n'existe pas.

Les données décident souvent du reste. Une base qui se copie en une nuit et une base qui met trois jours ne se migrent pas de la même manière. La première tolère une fenêtre d'arrêt, la seconde impose une réplication et une vérification d'intégrité après coup.

Là où nous sommes la mauvaise réponse

Si l'application ne peut pas être modifiée, le cloud vous coûtera plus cher, pas moins. Une machine allumée en permanence chez un fournisseur se paie plus cher qu'un serveur déjà amorti dans votre salle. Les économies viennent de la capacité à éteindre, à redimensionner, à remplacer un composant par un service géré. Sans le droit de toucher au code, il reste la facture et pas les gains.

Le lift-and-shift déplace souvent juste la facture. Reprendre vos machines virtuelles à l'identique règle un problème d'hébergement et aucun problème d'architecture. C'est parfois le bon choix quand la date est imposée, mais il faut l'assumer comme une étape, pas le vendre comme une modernisation.

Et une migration sans plan de retour arrière est un pari. Si votre calendrier ne laisse pas la place pour préparer et tester ce retour, nous le dirons avant de commencer et pas le soir de la bascule. Si vous cherchez un prestataire qui signe la date telle qu'elle est, ce ne sera pas nous.

Où vont les données, et qui y touche

Nos ingénieurs peuvent travailler à l'intérieur de votre environnement, sur votre infrastructure, avec vos comptes et vos contrôles d'accès. Dans ce cas la donnée ne bouge pas, ce qui règle une partie des questions de transfert avant même qu'elles se posent.

Sur la sécurité, la réponse exacte : nos pratiques suivent les principes ISO/IEC 27001 et sont alignées sur CyberFundamentals du Centre pour la Cybersécurité Belgique, avec l'audit de stade 2 prévu auprès d'un organisme accrédité BELAC en 2027. Nous ne sommes pas certifiés aujourd'hui, et vous devez l'entendre de nous plutôt que le découvrir dans un questionnaire d'achat.

Le contrat passe par JADEV GROUP SARL en Belgique, en euros et sous droit belge. L'équipe d'ingénierie est à Rabat et Casablanca, en UTC+1, donc sur la même journée de travail que Bruxelles, Paris et Amsterdam. Le jour de la bascule, cela compte.