Pourquoi les dépendances techniques bloquent le choix du modèle 6R
Choisir entre rehost, replatform, refactor ou rearchitect n'est jamais une décision isolée. Chaque application vit au cœur d'un écosystème de dépendances techniques qui pèsent lourd sur la faisabilité et le coût final de la migration. Une application qui semble idéale pour un rehost simple peut s'avérer impossible à déplacer parce qu'elle dépend fortement d'une base de données on-premise critique, d'une API propriétaire verrouillée, ou d'une intégration legacy impossible à dénouer rapidement. Ces dépendances ne sont pas des détails à affiner tard dans le projet : elles sont des facteurs de décision majeurs qui doivent être identifiées dès l'assessment initial. Sans cette analyse, on risque de choisir un modèle 6R qui parait optimal sur le papier, mais qui deviendra un gouffre de coûts et de délais une fois la réalité opérationnelle rencontrée. C'est pourquoi toute sélection de modèle 6R doit reposer sur un audit préalable des dépendances.
Les quatre catégories de dépendances qui pèsent sur la migration
Les obstacles techniques à la migration ne surgissent pas au hasard : ils se regroupent en quatre grandes familles, chacune posant des risques différents selon le modèle 6R choisi. D'abord, les dépendances de données : une application qui dépend d'une base de données on-premise partagée avec d'autres systèmes ne peut pas migrer seule en rehost simple. Il faut soit migrer la base aussi (complexité accrue), soit mettre en place une couche d'accès à distance (latence, coûts réseau). Ensuite, les dépendances d'intégration : si votre application échange des fichiers plats avec un système legacy tous les jours, ou appelle des APIs côté on-premise, vous devez valider que cette connexion fonctionnera aussi bien depuis AWS. Les dépendances de compliance viennent ensuite : certains secteurs (finance, santé, défense) imposent des données sensibles à rester physiquement on-premise ou au sein d'une région AWS précise. Migrer l'application but pas les données pose un problème insoluble. Enfin, les dépendances architecturales : une application monolithique 15 ans qui a grandi en fonction des besoins du métier, sans refonte, accumule parfois des couplages internes si serrés qu'un rehost simple serait instable. La refonte (refactor ou rearchitect) devient alors quasi-obligatoire. Identifier dans quelle catégorie tombe chaque blogage oriente directement vers le modèle 6R adapté.
Auditer les dépendances de données avant de choisir rehost ou replatform
Les dépendances de données sont souvent les plus visibles, mais aussi les plus sous-estimées dans leur impact sur le coût total. Commencez par cartographier : qui accède à quelles données, d'où, et avec quelle fréquence ? Si votre application écrit dans une base de données partagée avec trois autres systèmes on-premise, migrer en rehost simple signifie laisser cette base on-premise et faire transiter les requêtes à travers un VPN ou une Direct Connect. C'est techniquement possible, mais cela ajoute de la latence (impactant les perfs utilisateur), augmente les coûts réseau (AWS facture l'egress), et cré une dépendance persistante à l'infrastructure on-premise, contredisant le bénéfice attendu de la migration. Replatform devient alors intéressant : isoler une copie de la base dans AWS (ou intégrer une base managée RDS), puis synchroniser les données entre on-premise et cloud en temps quasi-réel via un ETL ou une réplication native. C'est plus lourd que le rehost, mais cela élimine la dépendance à long terme. Dans d'autres cas, la base de données elle-même doit migrer en priorité : certaines bases relationnelles on-premise peuvent être converties directement en RDS (même moteur), d'autres nécessitent un refactor vers une base cloud-native (Aurora Serverless, DynamoDB). Avant de valider le modèle 6R, testez la synchronisation de données entre on-premise et cloud sur un sous-ensemble réel : mesurer la latence ajoutée, les délais de cohérence, et les coûts AWS. Cet audit prend quelques jours, mais il évite une mauvaise décision qui coûterait des mois en corrections.
Évaluer les dépendances d'intégration et de compliance qui figent le modèle
Une application peut être techniquement autonome en matière de données, mais profondément attachée à son contexte opérationnel par les intégrations. Auditez systématiquement : quels systèmes externes appellent cette application, et quels systèmes externes elle appelle ? Si elle consomme une API legacy, vérifiez si cette API peut fonctionner depuis AWS (certaines exigent une IP on-premise fixe pour des raisons de sécurité obsolètes). Si elle expose elle-même une API que d'autres systèmes consomment, envisagez un replatform léger au minimum pour replacer un API Gateway cloud devant elle, sinon les appelants devront tous être recâblés. Les dépendances d'intégration via fichiers (uploads/downloads réguliers, EDI, transferts batch) sont aussi des points d'accrochage : migrer sans revoir ces circuits signifie garder des ponts on-premise/cloud qui ralentissent et coutent cher. La compliance encadre souvent ce qui est faisable. En secteur financier, certaines données de client ne peuvent pas quitter un data center de la région. En santé, les données de santé doivent rester dans la même zone géographique et respecter des certifications spécifiques (HDS en France, HIPAA aux US). Un rehost innocent devient impossible si les données doivent rester on-premise : il faut alors envisager un hybrid (application dans AWS, données on-premise synchronisées), ou accepter de rester entièrement on-premise (retain). La compliance s'évalue tôt en partenariat avec le responsable conformité ou juridique de votre organisation, pas en fin de projet quand tout est déjà décidé. Checklist: vérifier les clauses de localité des données, les certifications requises, les audits annuels attendus, et les délais de réaction en cas d'incident.
Les dépendances architecturales qui rendent refactor ou rearchitect obligatoires
Au-delà des données, des intégrations et de la compliance, la structure interne de l'application elle-même peut être un blogage. Une monolithe de 500 K lignes de code où chaque couche dépend fortement des autres, sans API nette entre les modules, ne migre pas bien en rehost pur. Le comportement peut changer subtilement au-dessus d'AWS (latence réseau différente, timing des threads, accès aux fichiers système), et sans structure modulaire, localiser le bug devient infernal. Pour ces architectures fragiles, replatform offre une amélioration légère (environnement cloud plus stable que l'on-premise vieillissant), mais refactor devient quasi-obligatoire si vous voulez vraiment en tirer parti. Refactor signifie conserver la logique métier, mais réorganiser l'application : isoler les modules en services séparés (micro-services), ajouter des APIs claires entre eux, extraire la logique métier dans des couches découplées. C'est plus lourd qu'un simple rehost, mais cela rend l'application stable en cloud et surtout maintenable long terme. Rearchitect (une réécriture totale) s'envisage quand l'architecture actuelle accumule tellement de dette que refactoriser coûterait autant que réécrire. Évaluez ces dépendances architecturales en mesurant : le couplage entre modules (partagent-ils état global, données communes ?), la couverture de tests (existe-t-il une suite suffisante pour valider la refonte ?), et l'âge/connaissance du code (l'équipe actuelle comprend-elle assez le code pour le refactoriser sans l'casser ?). Si le couplage est fort, les tests faibles et le code très vieux, refactor risque d'être plus cher que rearchitect.
Checklist concrète pour auditer les dépendances avant la décision 6R
Attendre la phase de planning détaillé pour auditer les dépendances est trop tard. L'assessment initial (deux à quatre semaines) doit inclure cet audit. Voici une checklist concrète, appliquée à chaque application candidate à la migration. D'abord, les données : listez toutes les bases auxquelles l'application accède (bases propres, bases partagées, data warehouses), notez pour chacune si elle est en lecture seule ou lecture-écriture, mesurez la fréquence des appels (batch quotidien, requêtes temps réel), et identifiez les autres consommateurs de ces bases. Pour les bases partagées, estimer le coût et délai de migrer la base aussi. Ensuite, les intégrations : énumérez chaque système externe avec lequel votre application communique, notez le protocole (API REST, SOAP, fichiers batch, queues de messages), vérifiez si la cible (on-premise ou autre cloud) peut communiquer avec AWS sans blocage réseau, et testez une connexion de proof-of-concept. Puis, la compliance : consultez les règles métier et réglementaires (GDPR, HIPAA, directives sectorielles) et enregistrez les contraintes de localité, certifications requises, audit trails, et délais de conformité. Enfin, l'architecture : relevez le langage de programmation et l'âge du code, mesurez l'indice de couplage (combien de modules partagent état global), vérifiez la couverture de tests (idéalement > 60%), et évaluez la capacité de l'équipe actuelle à refactoriser ou si une expertise externe est nécessaire. Une fois cette checklist complétée pour chaque application, cartographiez les résultats sur une matrice simples (axe X : complexité des dépendances, axe Y : enjeu métier), puis classez les applications à migrer en priorité et en modèle 6R recommandé. Cet audit prend une à deux semaines par groupe d'applications, mais il solidifie votre stratégie de migration en éliminant les mauvaises surprises.
Comment les dépendances influencent la matrice de sélection 6R
Une fois l'audit des dépendances bouclé, ces informations alimentent directement la matrice de sélection 6R. La matrice classique considère trois axes : impact métier, complexité technique, et urgence. L'audit des dépendances ajoute un quatrième facteur décisif : le coût et le délai d'atténuation des blocages identifiés. Une application à fort impact métier, techniquement simple, mais criblée de dépendances (base partagée, API legacy, compliance sévère) ne sera jamais un rehost pur, même si elle le semblerait sans cet audit. Elle devient replatform au minimum, ou même refactor si les dépendances architecture sont lourdes. À l'inverse, une application moins visibles mais aux dépendances minimales (données propres, intégrations simples, architecture modulaire) peut être rehost dès le premier trimestre, libérant des ressources pour les cas plus complexes. Cette priorisation basée sur l'audit évite l'effet Tetris classique des migrations : choisir les cas faciles en premier parce qu'on peut, puis buter sur un grosse dépendance en milieu de projet et ralentir tout le reste. La matrice intègre l'audit des dépendances en décision pondérée : chaque modèle 6R reçoit un score de faisabilité (rehost = 5 si aucune dépendance critiques, 1 si dépendances multiples), et le modèle retenu est celui qui maximise l'impact métier tout en minimisant les dépendances résiduelles. Ceux qui prennent le temps de bien auditer les dépendances dès l'assessment accélèrent réellement la migration totale, en déplaçant les cas complexes plus tard quand l'équipe a l'expérience et l'outillage.