Remplacer un système legacy d’un seul coup (réécrire, tester, basculer en une fois) concentre tout le risque d’une migration dans un seul événement, souvent après des mois de développement sans validation en conditions réelles. Le pattern strangler fig prend le problème à l’envers : une façade de routage s’intercale devant le legacy dès le premier jour, et chaque fonctionnalité bascule individuellement vers le nouveau système, jusqu’à ce que l’ancien ne serve plus à rien.

La façade, le seul composant nouveau au départ

La première étape n’écrit aucune nouvelle fonctionnalité métier : elle installe un point d’entrée (un reverse proxy, un Ingress, une Gateway API) qui route 100 % du trafic vers le legacy, exactement comme avant, mais désormais via un composant qu’on contrôle.

# Au départ, la façade route tout vers le legacy,
# aucun comportement visible ne change encore
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: strangler-facade
spec:
  rules:
    - backendRefs:
        - name: legacy-monolith
          port: 8080

Cette étape, apparemment inutile puisqu’elle ne change rien pour l’utilisateur, est celle qui rend toute la suite possible : elle établit le point de contrôle unique par lequel chaque bascule future passera.

Basculer une route à la fois, jamais le système entier

Une fois la façade en place, chaque fonctionnalité migrée (un module, un endpoint, une route spécifique) se réécrit indépendamment dans le nouveau système, puis la façade bascule uniquement le trafic correspondant à cette fonctionnalité précise, sans toucher au reste.

# Une route précise bascule vers le nouveau système,
# tout le reste continue de passer par le legacy
rules:
  - matches:
      - path: {value: /api/invoicing}
    backendRefs:
      - name: new-invoicing-service
        port: 8080
  - backendRefs:
      - name: legacy-monolith
        port: 8080

Le legacy et le nouveau système coexistent alors pendant toute la durée de la migration, chacun gérant sa part du trafic, sans jamais nécessiter que l’un ou l’autre gère l’intégralité pendant la transition.

Ce que ça élimine : le risque du tout-ou-rien

Une bascule ratée sur une seule fonctionnalité migrée reste circonscrite à cette fonctionnalité : revenir en arrière (repointer la route vers le legacy) est une opération locale, sans jamais remettre en cause tout le travail déjà migré ailleurs. Un remplacement en un seul événement n’offre pas cette granularité : un problème découvert après bascule force soit à tout accepter en dégradé, soit à tout annuler, sans position intermédiaire.

Le vrai coût : la durée, pas la complexité technique

Le pattern strangler fig s’étale généralement sur plusieurs mois, parfois plus d’un an pour un système suffisamment large, une durée qui a un coût organisationnel réel : maintenir deux systèmes en parallèle (le legacy encore actif, le nouveau en construction), avec l’équipe qui doit comprendre les deux, un investissement continu que le remplacement en un coup n’impose pas de la même façon, au prix bien plus élevé du risque qu’il concentre en échange.

À retenir

Le strangler fig installe une façade de routage devant un système legacy dès le premier jour, puis bascule fonctionnalité par fonctionnalité vers le nouveau système, jamais l’ensemble d’un coup : chaque bascule reste réversible localement, sans jamais mettre en jeu tout le travail de migration accompli ailleurs. Le vrai coût de cette approche n’est pas technique mais organisationnel : maintenir deux systèmes en parallèle pendant une durée qui s’étend souvent sur plusieurs mois. C’est ce compromis, durée contre risque concentré, qui structure la méthode d’une migration Kubernetes qui refuse de couper la prod pour tout remplacer d’un coup.