Modernisation du plan de contrôle géré

Vous devez moderniser vos parcs Cloud Service Mesh en remplaçant l'implémentation obsolète du plan de contrôle ISTIOD par l'implémentation TRAFFIC_DIRECTOR avant la date limite de fin de compatibilité. Vous pouvez lancer la modernisation selon votre propre calendrier ou laisser Google la planifier automatiquement une fois que votre organisation est compatible.

Il existe deux approches de modernisation, que vous pouvez également combiner :

  • Modernisation déclenchée par le client (libre-service) : vous lancez et contrôlez vous-même le moment exact de la modernisation du parc à l'aide de la Google Cloud CLI, indépendamment des planifications gérées par Google.
  • Modernisation gérée par Google (par défaut) : Google évalue la compatibilité du parc et planifie automatiquement la modernisation dans votre organisation en fonction des intervalles de maintenance et des notifications préalables. Google attend que tous les parcs de votre organisation soient compatibles. Un seul parc incompatible bloquera donc votre modernisation.

Quelle que soit la méthode choisie, vous devez suivre les étapes principales suivantes pour moderniser votre plan de contrôle :

  1. Vérifier la compatibilité : activez les vérifications de compatibilité et déterminez si vos parcs sont compatibles avec la modernisation.
  2. Planifier et configurer votre modernisation : choisissez votre parcours, configurez l'ordre de déploiement des clusters et des parcs, ou différez des parcs spécifiques.
  3. Corriger les problèmes de compatibilité : assurez-vous que vos parcs répondent à toutes les exigences de compatibilité avant de lancer la modernisation.
  4. Lancer la modernisation : déclenchez la modernisation initiée par le client selon votre calendrier ou attendez la planification par Google.
  5. Modernisation du cluster actif : pendant les intervalles de maintenance configurés, deux plans de contrôle s'exécutent côte à côte, et les déploiements (charges de travail et passerelles) passent automatiquement au nouveau plan de contrôle. Vous devrez redémarrer manuellement les charges de travail StatefulSet et DaemonSet.
  6. Surveiller l'état, observer et finaliser : surveillez la progression des conditions, résolvez les blocages, observez les charges de travail pendant la période d'observation (au moins six jours ouvrés), avec une compatibilité complète avec le rollback avant la finalisation au niveau du parc.

Vérifier la compatibilité du parc et corriger les écarts

Avant qu'un parc puisse être modernisé (que ce soit à l'initiative du client ou de Google), sa compatibilité doit être vérifiée. Vous devez activer les rapports de compatibilité pour inspecter les conditions de blocage potentielles et corriger les lacunes de configuration. Pour en savoir plus, consultez Comprendre la compatibilité de Cloud Service Mesh.

  • Pour la modernisation gérée par Google : Google ne planifiera que les organisations dont tous les parcs non différés sont compatibles.
  • Pour la modernisation déclenchée par le client : vous devez vérifier que votre parc cible indique MODERNIZATION_COMPATIBLE avant de lancer la modernisation.

Les vérifications de compatibilité évaluent les configurations CRD Istio de votre parc, les annotations de pod, les dépendances d'infrastructure (telles que Workload Identity) et les paramètres de scaling.

Gérer les fonctionnalités non compatibles

Dans le cadre de l'abandon du plan de contrôle ISTIOD, Google Cloud met fin à la compatibilité avec les fonctionnalités incompatibles avec la mise en œuvre du plan de contrôle TRAFFIC_DIRECTOR. Consultez les détails de la compatibilité avec les API.

Si vous utilisez des fonctionnalités non compatibles, vous devez effectuer l'une des actions suivantes avant la fin de la compatibilité (voir Fonctionnalités obsolètes) :

  • Refactorisez votre configuration (recommandé) : supprimez les champs non compatibles ou remplacez-les par des alternatives Cloud Service Mesh compatibles afin que votre parc signale MODERNIZATION_COMPATIBLE, puis modernisez l'implémentation du plan de contrôle TRAFFIC_DIRECTOR.
  • Migrer vers Istio Open Source (OSS) : si vos charges de travail nécessitent strictement des fonctionnalités que Cloud Service Mesh géré avec TRAFFIC_DIRECTOR ne prend pas en charge, vous ne pouvez pas moderniser ces clusters vers TRAFFIC_DIRECTOR. Vous devez migrer ces charges de travail vers Istio Open Source autogéré.
  • Désinstaller Cloud Service Mesh : vous pouvez désinstaller Cloud Service Mesh géré.

Planifier et configurer votre modernisation

Élaborez un plan pour moderniser votre ou vos parcs. Si vous ne le faites pas, la modernisation basée sur Google est appliquée par défaut. Vous devez prendre des mesures pour vous assurer que vos parcs hors production sont modernisés en premier et que vos parcs critiques sont modernisés en dernier. De plus, la modernisation gérée par Google ne planifiera pas la modernisation de votre organisation tant que 100 % des parcs non différés de l'ensemble de votre organisation ne seront pas compatibles. Votre modernisation pourrait donc être bloquée par des incompatibilités locales.

Avant de lancer la modernisation, examinez vos options et configurez vos paramètres de déploiement sur les parcs et les clusters de votre organisation.

Parcours disponibles

Méthode Description Application idéale Champ d'application Prérequis Avis préalable Capacité de rollback
Modernisation déclenchée par le client Vous lancez la modernisation parc par parc, selon votre propre calendrier. Contrôle précis du calendrier de modernisation du parc (vous décidez quand lancer et quand annuler la modernisation au niveau du parc). Exploiter la surveillance de votre application existante pour vous alerter si un rollback est nécessaire. Parc par parc (FLEET_PROJECT_ID). Le parc cible doit être compatible avec la modernisation. N/A. Rollback immédiat en libre-service à l'aide de la Google Cloud CLI.
Modernisation pilotée par Google (par défaut) Google planifie automatiquement la modernisation dans l'ensemble de votre organisation. Modernisation automatisée une fois que tous les parcs de votre organisation sont compatibles. Toute l'organisation Google Cloud (tous les parcs non différés). Tous les parcs non différés de l'organisation doivent être compatibles avec la modernisation. Notification de parc plus de 14 jours avant le début et notification de cluster plus de 24 heures avant le début. Google effectuera un rollback si la surveillance standardisée indique une erreur. Vous devez contacter Cloud Customer Care si la surveillance de votre application affiche une erreur.

Gérer plusieurs parcs dans une organisation

Si votre Google Cloud organisation gère plusieurs parcs, vous n'avez pas besoin de choisir une seule approche pour tous. Vous pouvez combiner des stratégies, par exemple :

  • Différer les parcs complexes ou critiques : épinglez des parcs spécifiques à l'ancienne implémentation à l'aide de --modernization-strategy deferred afin qu'ils soient exclus de la planification gérée par Google pendant que vous corrigez les dépendances ou planifiez l'exécution déclenchée par le client.
  • Commencez par une modernisation déclenchée par le client sur des parcs sélectionnés : modernisez d'abord les parcs de test, de développement ou d'évaluation pour valider le comportement selon votre propre calendrier.
  • Autoriser Google à moderniser les parcs restants : tous les parcs compatibles et non différés restent activés pour la planification gérée par Google.

Différer la modernisation du parc (désactivation)

Pour désactiver la modernisation gérée par Google pour un parc individuel, définissez sa stratégie sur DEFERRED :

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

Remplacez FLEET_PROJECT_ID par l'ID du projet hôte de parc.

La définition de --modernization-strategy deferred est la méthode recommandée pour :

  • Excluez des parcs spécifiques de la planification gérée par Google, car vous avez l'intention de les moderniser selon votre propre calendrier en utilisant la modernisation déclenchée par le client.
  • Suspendez temporairement la modernisation des parcs complexes ou critiques pendant que vous corrigez les dépendances, ce qui permet aux autres parcs compatibles de votre organisation de procéder à la planification gérée par Google.

Notez que l'ancien libellé de projet mesh-modernization-mode=manual est toujours respecté, mais que --modernization-strategy deferred est recommandé. Les autres parcs non différés de votre organisation restent éligibles à la planification gérée par Google une fois qu'ils sont tous compatibles.

Configurer l'ordre de déploiement

Vous pouvez contrôler l'ordre de déploiement séquentiel sur vos clusters et parcs à l'aide de l'étiquette mesh-modernization-order (early, default ou late).

Ordre de déploiement des clusters (s'applique aux deux parcours)

Si un parc contient plusieurs clusters, vous pouvez contrôler l'ordre dans lequel les clusters sont modernisés en appliquant l'étiquette mesh-modernization-order à chaque cluster. Lorsque vous ou Google déclenchez la modernisation d'un parc, chaque groupe de clusters est modernisé de manière séquentielle. Les étapes de modernisation automatisées doivent se terminer sur le groupe actuel avant de commencer le suivant :

gcloud container clusters update CLUSTER_NAME \
  --location LOCATION \
  --update-labels="mesh-modernization-order=VALUE"

Remplacez CLUSTER_NAME par le nom du cluster, LOCATION par l'emplacement du cluster et VALUE par l'une des valeurs suivantes :

  • early : le cluster est modernisé lors de la première vague de modernisation.
  • default : le cluster est modernisé lors de la deuxième vague de modernisation.
  • late : le cluster est modernisé lors de la troisième et dernière vague de modernisation.

Ordre de déploiement du parc (géré par Google uniquement)

Dans les organisations comportant plusieurs parcs en cours de modernisation par Google, vous pouvez contrôler l'ordre dans lequel Google modernise vos parcs en définissant l'étiquette au niveau du projet sur le projet hôte du parc :

gcloud alpha projects update FLEET_PROJECT_ID \
  --update-labels="mesh-modernization-order=VALUE"

Remplacez FLEET_PROJECT_ID par l'ID du projet hôte de parc et VALUE par l'une des valeurs suivantes :

  • early : le parc est modernisé lors de la première vague de modernisation.
  • default : le parc est modernisé lors de la deuxième vague de modernisation.
  • late : le parc est modernisé lors de la troisième et dernière vague de modernisation.

Google termine la modernisation de chaque niveau de parc avant de commencer le suivant : d'abord le niveau anticipé, puis le niveau par défaut (et sans étiquette), puis le niveau tardif. Les parcs marqués comme différés ne sont pas inclus dans cet ordre.

Par exemple, vous pouvez définir vos parcs hors production sur early, un parc particulièrement critique sur late et laisser les autres parcs sur la valeur par défaut.

Si vous n'utilisez pas d'organisations Google Cloud , vos parcs seront planifiés et modernisés indépendamment, et vous ne pourrez pas contrôler l'ordre.

Modernisation déclenchée par le client (libre-service)

La modernisation déclenchée par le client vous permet de contrôler directement le moment où la modernisation commence pour un parc individuel.

Déclencher la modernisation du parc

Une fois que votre parc cible indique MODERNIZATION_COMPATIBLE, déclenchez la modernisation à l'aide de la commande suivante :

gcloud alpha container fleet mesh update \
  --modernization-strategy automatic \
  --project FLEET_PROJECT_ID

Remplacez FLEET_PROJECT_ID par l'ID du projet hôte de parc.

  • Intervalles de maintenance : Google respecte les intervalles et les exclusions de maintenance configurés pour le cluster. La modernisation du cluster commence lors du prochain intervalle de maintenance ouvert du cluster.
  • Ordre des clusters : si vous avez configuré des libellés mesh-modernization-order sur vos clusters, Google respecte cet ordre.

Suivre la progression

Suivez les instructions de la section Vérifier l'état de la modernisation pour surveiller la progression de la modernisation du parc et du cluster. Surveillez votre application pour déterminer si vous devez effectuer un rollback, en particulier pendant les états MODERNIZATION_PREPARING et MODERNIZATION_MIGRATING_WORKLOADS.

Annuler une modernisation déclenchée par le client

Si vous détectez des problèmes lors de la modernisation d'un cluster actif ou pendant la période de stabilisation du parc (avant la finalisation au niveau du parc), vous pouvez déclencher un rollback immédiat :

gcloud alpha container fleet mesh update \
  --modernization-strategy deferred \
  --project FLEET_PROJECT_ID

Remplacez FLEET_PROJECT_ID par l'ID du projet hôte de parc.

Votre parc restera alors dans l'état "Différé", ce qui signifie qu'il ne sera pas pris en compte pour la modernisation gérée par Google. Lorsque vous êtes prêt à réessayer la modernisation, réexécutez la commande pour déclencher la modernisation du parc.

Modernisation gérée par Google (par défaut, automatisée)

Si vous ne lancez pas la modernisation déclenchée par le client, Google gère automatiquement la modernisation dans l'ensemble de votre organisation.

Planification à l'échelle de l'organisation

Google surveille vos parcs en permanence. Une fois que tous les parcs de votre organisation pour lesquels le maillage est activé (à l'exclusion des parcs différés) sont compatibles avec la modernisation, Google planifie la modernisation de votre organisation.

Notifications et planification avancées

Google fournit deux niveaux de notification préalable avant de commencer la modernisation :

Notification au niveau du parc

Tout d'abord, vous serez averti lorsque vos parcs auront été identifiés comme compatibles avec la modernisation et sélectionnés pour une modernisation gérée par Google à l'avenir.

  • La modernisation de votre cluster peut commencer dès 14 jours après le premier jour ouvré aux États-Unis du mois suivant votre notification. Par exemple, si Google détermine que votre organisation est prête le 10 janvier 2027, nous vous informerons d'ici le 31 janvier 2027 que la date de début de modernisation la plus proche possible est le 15 février 2027.

  • Vous recevrez une notification simultanément pour chacun des parcs de votre organisation (à l'exception de ceux que vous avez différés). Cette notification est disponible dans les conditions d'état de la fonctionnalité au niveau du parc (MODERNIZATION_WILL_BE_SCHEDULED).

Notification au niveau du cluster

Vous serez informé, au niveau du cluster, de la date de début estimée de la modernisation de ce cluster par Google, au moins un jour (24 heures) avant le début de la modernisation du cluster.

Après la notification au niveau du parc, vous obtenez un calendrier beaucoup plus précis de la modernisation des clusters individuels. Cette notification est disponible dans les conditions d'état de la fonctionnalité au niveau du cluster (MODERNIZATION_SCHEDULED).

Demander un rollback pour la modernisation gérée par Google

Si des problèmes surviennent pendant la modernisation active ou la période d'observation d'un parc de modernisation géré par Google, contactez Cloud Customer Care pour demander un rollback.

Que se passe-t-il pendant la modernisation active ?

Cette section décrit ce qui se passe lors de la modernisation active des parcs et des clusters.

Moderniser les parcs

Pour chaque parc en cours de modernisation (qu'il soit géré par Google ou déclenché par le client), nous activons la nouvelle implémentation du plan de contrôle pour tous les clusters en fonction de l'ordre (anticipé → par défaut → tardif).

Une fois le plan de contrôle activé pour tous les clusters, nous transférons le trafic vers la nouvelle implémentation du plan de contrôle pour tous les clusters en fonction de l'ordre (anticipé → par défaut → tardif).

Consultez Vérifier l'état de la modernisation du parc pour vérifier l'état actuel.

Période de stabilisation du parc

Une fois le trafic transféré pour tous les clusters, le parc entre dans une période de stabilisation. Le parc reste en période de stabilisation (MODERNIZATION_MODERNIZED) pendant au moins six jours ouvrés après la modernisation de tous les clusters, avant de passer à l'état MODERNIZATION_FINALIZED. La capacité de rollback complète est préservée tout au long de la période de test. Une fois la modernisation finalisée, le rollback n'est plus possible et les composants ISTIOD peuvent être déprovisionnés.

Moderniser un cluster

Pendant la modernisation active d'un cluster, les deux implémentations du plan de contrôle sont exécutées temporairement côte à côte, et les tâches suivantes sont traitées de manière sécurisée et contrôlée :

  1. Activez la nouvelle implémentation du plan de contrôle. Si vous avez configuré des intervalles de maintenance pour votre cluster, cette étape commencera pendant un intervalle de maintenance et se poursuivra jusqu'à ce qu'elle soit terminée. Tenez compte des remarques suivantes :
  2. Transférez le trafic vers la nouvelle implémentation du plan de contrôle. Si vous avez configuré des intervalles de maintenance pour votre cluster, cette étape commencera pendant un intervalle de maintenance et se poursuivra jusqu'à la fin. Tenez compte des remarques suivantes :
    • Les pods gérés par le déploiement Kubernetes qui disposent de proxys Cloud Service Mesh sont redémarrés afin de se reconnecter au nouveau plan de contrôle.
    • Les pods sont redémarrés par vagues de plus en plus importantes, avec un temps de stabilisation après chaque vague pour la surveillance.

  3. Redémarrages manuels des charges de travail pour les ressources autres que les déploiements (action requise de la part du client).

    • Google redémarre automatiquement les charges de travail gérées par les déploiements Kubernetes. Les charges de travail gérées par d'autres types de ressources Kubernetes, telles que les StatefulSets et les DaemonSets, doivent être redémarrées manuellement.
    • Une fois que les charges de travail Deployment ont été redémarrées, si des charges de travail du cluster ont encore des proxys Cloud Service Mesh connectés à ISTIOD, le cluster signale MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART en plus de MODERNIZATION_MIGRATING_WORKLOADS.
    • Redémarrez manuellement les charges de travail restantes afin que leurs proxys se connectent à l'implémentation du plan de contrôle TRAFFIC_DIRECTOR. Google attend au moins 60 jours que vous redémarriez toutes les charges de travail avant de passer aux clusters suivants (dans un parc multicluster) ou de démarrer la période de stabilisation du parc.
    • Pour vérifier quels proxys sont toujours connectés à ISTIOD, exécutez la commande gcloud beta container fleet mesh debug proxy-status, comme décrit dans Afficher l'état du plan de contrôle. Les proxys avec un ID d'instance Istiod dans la colonne ISTIOD du résultat de la commande se connectent toujours à ISTIOD et nécessitent un redémarrage manuel.
    • Une fois que toutes les charges de travail du maillage du cluster sont connectées à TRAFFIC_DIRECTOR, MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART est automatiquement effacé et l'état du cluster passe à MODERNIZATION_COMPLETED.

  4. Une fois que toutes les charges de travail d'un cluster ont été migrées, le cluster attend la période de stabilisation du parc.

Pour surveiller l'état de modernisation actif de vos clusters, consultez Vérifier l'état de modernisation.

Vérifier l'état de la modernisation et prendre des mesures

Vous pouvez surveiller la progression de la modernisation de vos parcs et clusters à l'aide de la Google Cloud CLI :

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Remplacez FLEET_PROJECT_ID par l'ID du projet hôte de parc.

Le résultat est semblable à :

  membershipStates:
    projects/123456789/locations/global/memberships/cluster-1:
      servicemesh:
        conditions:
        - code: MODERNIZATION_MIGRATING_WORKLOADS
          documentationLink: https://cloud.google.com/service-mesh/docs/...
          severity: INFO
  state:
    servicemesh:
      conditions:
      - code: MODERNIZATION_MODERNIZING
        documentationLink: https://cloud.google.com/service-mesh/docs/...
        severity: INFO

L'état de modernisation est indiqué dans les champs state.servicemesh.conditions (au niveau du parc) et membershipStates.<MEMBERSHIP_NAME>.servicemesh.conditions (au niveau du cluster) :

État d'une modernisation de parc réussie

Si la modernisation du parc réussit, l'état du parc commence par MODERNIZATION_MODERNIZING.

Chaque cluster passe ensuite par les états suivants :

  • MODERNIZATION_SCHEDULED
  • MODERNIZATION_PREPARING
  • MODERNIZATION_PREPARED
  • MODERNIZATION_MIGRATING_WORKLOADS
  • (facultativement) MODERNIZATION_MIGRATING_WORKLOADS par MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART
  • MODERNIZATION_COMPLETED

Une fois que tous les clusters du parc ont terminé leur modernisation, le parc passe par les états suivants :

  • MODERNIZATION_MODERNIZED
  • MODERNIZATION_FINALIZED

Rollbacks

La modernisation basée sur Google surveille l'état de préparation et l'état de votre déploiement tout au long du processus de modernisation. Nous déclencherons automatiquement un rollback si nous détectons des problèmes. Si vous détectez un problème, contactez Cloud Customer Care pour demander un rollback.

Pour la modernisation déclenchée par le client, vous pouvez déclencher un rollback à tout moment.

Lors d'un rollback, le parc affiche l'état MODERNIZATION_ROLLING_BACK_FLEET et le cluster affiche l'état MODERNIZATION_ROLLING_BACK_CLUSTER.

Une fois le rollback d'un cluster terminé, l'état MODERNIZATION_ABORTED s'affiche temporairement.

Gérer les erreurs et les blocages (déclenchés par le client uniquement)

Lors d'une modernisation déclenchée par le client, si un cluster rencontre un problème qui l'empêche de progresser, son état passe à MODERNIZATION_STALLED. Google ne déclenchera pas de rollbacks pour les modernisations déclenchées par le client. Vous devez trier le problème et décider de le corriger ou de déclencher un rollback.

Lorsqu'un cluster signale MODERNIZATION_STALLED, examinez les détails de la condition pour obtenir un lien direct vers la section d'erreur correspondante :

Erreurs exploitables par l'utilisateur

Si nous détectons une configuration de maillage ou de cluster incompatible, nous interrompons la modernisation. Assurez-vous que les rapports de compatibilité sont activés et examinez les conditions au niveau du parc et du cluster pour détecter les lacunes, comme décrit dans Comprendre la compatibilité de Cloud Service Mesh.

  • Nouvelle tentative immédiate : dès que le problème est résolu, nous détectons le changement et reprenons immédiatement la modernisation, sans attendre le prochain intervalle de maintenance.

Erreurs internes

Les problèmes liés aux services Google internes sont examinés par des ingénieurs Google, qui reprendront votre modernisation si possible. Notez que la modernisation peut reprendre en dehors d'un intervalle de maintenance, tout comme pour les erreurs nécessitant une action de l'utilisateur. Pour éviter cela, vous pouvez déclencher un rollback.

Si votre modernisation est bloquée pendant plus de 24 heures et qu'il n'y a pas d'incompatibilité, contactez Cloud Customer Care pour en savoir plus ou déclenchez un rollback si les charges de travail de production sont affectées.

Documentation de référence sur les conditions au niveau du parc

Condition Description
MODERNIZATION_COMPATIBLE Le parc est compatible avec la nouvelle implémentation du plan de contrôle.
MODERNIZATION_WILL_BE_SCHEDULED Modernisation gérée par Google : tous les parcs non différés de l'organisation sont compatibles et ont été mis en file d'attente pour la planification.
MODERNIZATION_MODERNIZING La modernisation est en cours pour un ou plusieurs clusters du parc.
MODERNIZATION_MODERNIZED Tous les clusters ont terminé la modernisation active. Le parc est en période de stabilisation.
MODERNIZATION_FINALIZED La modernisation est terminée et finalisée. Les anciens composants Istiod seront supprimés. Le rollback n'est plus possible.
MODERNIZATION_ROLLING_BACK_FLEET Un rollback au niveau du parc est en cours.

Documentation de référence sur les conditions au niveau du cluster

Condition Description
MODERNIZATION_SCHEDULED La modernisation du cluster est planifiée à la date spécifiée dans la condition ou après cette date. Si des intervalles/exclusions de maintenance sont configurés pour votre cluster, la date indiquera l'intervalle de maintenance cible.
MODERNIZATION_PREPARING Activation de la nouvelle implémentation du plan de contrôle…
MODERNIZATION_PREPARED La nouvelle implémentation du plan de contrôle est activée. La migration de la charge de travail n'a pas encore commencé.
MODERNIZATION_MIGRATING_WORKLOADS Le cluster migre activement les charges de travail vers la nouvelle implémentation du plan de contrôle.
MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART La migration automatisée de la charge de travail est terminée. Redémarrez les charges de travail de maillage non-Deployment, telles que les StatefulSets, les DaemonSets ou les Jobs, afin que leurs proxys se connectent à l'implémentation du plan de contrôle TRAFFIC_DIRECTOR.
MODERNIZATION_COMPLETED La modernisation du cluster est terminée et celui-ci est en période de stabilisation.
MODERNIZATION_STALLED La modernisation est bloquée en raison d'une erreur (déclenchée par le client uniquement). Consultez les détails de la condition pour résoudre le problème.
MODERNIZATION_ROLLING_BACK_CLUSTER Le cluster est en cours de rollback.
MODERNIZATION_ABORTED Le cluster a été restauré vers l'ancien plan de contrôle. Signalé pendant une courte période.