Guide pour sortir de la dépendance au mode IE

Cet article en une phrase

« Utiliser le mode IE en toute sécurité dans le cadre d’une exploitation officiellement gérée, réduire progressivement la dépendance, et ramener finalement l’usage du mode IE à zéro » — telle est la stratégie réaliste. Avant de vous en débarrasser, commencez par bien le gérer.

Contexte : jusqu’à quand peut-on utiliser le mode IE ?

Le point important à retenir ici est que pouvoir l’utiliser jusqu’en 2029 ne signifie pas qu’on peut le laisser tel quel en toute tranquillité. Cette période n’est qu’un « sursis destiné à organiser une sortie planifiée » ; pour ne pas se retrouver pris de court à l’approche de l’échéance de 2029, il n’y a pas d’autre solution que de commencer à s’y préparer dès maintenant.

Pourquoi est-il si difficile de sortir de la dépendance au mode IE ?

Le mode IE est un mécanisme, à l’intérieur de l’Edge basé sur Chromium, qui fait rendre uniquement les anciens sites par le moteur Trident (MSHTML). Voici ce que ce moteur Trident prend en charge :

• Les anciens modes document (Document Mode)
• Les contrôles ActiveX / BHO (Browser Helper Object)
• Les anciens paramètres de zone de sécurité
• Les paramètres de compatibilité d’Enterprise Mode

Tant que vous dépendez de ces éléments, mettre à jour le navigateur ne suffit pas à résoudre le problème. Identifier la véritable nature de cette dépendance est la première étape.

Problèmes fréquemment rencontrés sur le terrain

1. Mauvaise configuration du mode document → mise en page cassée, erreurs de script
2. Configuration manquante des sites neutres → boucles de réauthentification ou de redirection avec le SSO (authentification unique)
3. Mauvais format de l’Enterprise Mode Site List → le schema v.1 n’est pas pris en charge pour l’intégration au mode IE ; une migration vers le schema v.2 est nécessaire
4. Edge ne traite qu’une seule liste de sites → la politique côté Edge prévaut sur la politique côté IE

Classer la dépendance : d’abord identifier « de quoi on dépend »

Étape 1 : mesures de prolongation de vie — d’abord, exploiter en toute sécurité

1. Gérer correctement la liste de sites (le plus important)

Laisser le « rechargement » à l’initiative des utilisateurs est dangereux. Gérez-le officiellement par la politique.

Ce qu’il faut faire : migrer vers Cloud Site List Management et centraliser la gestion de qui utilise quel site en mode IE, et jusqu’à quand.

2. Solidifier la configuration liée à l’authentification

Lorsque le SSO est impliqué, l’authentification se casse fréquemment lors des transitions entre le mode IE et le mode Edge.

• Configurer correctement les sites neutres (Neutral Site) → spécifier explicitement les serveurs SSO
• Configurer le partage de cookies si nécessaire
• Tant qu’il est vraiment impossible d’identifier le serveur d’authentification, utiliser temporairement la politique qui « conserve la navigation intra-page en mode IE » (mais la désactiver une fois la situation stabilisée)

3. Maîtriser les outils de diagnostic

Décidez à partir de données observées, pas d’impressions.

4. « Isoler » ce qui ne peut vraiment pas être corrigé

Étape 2 : stratégies de sortie — comment réduire la dépendance

Tableau comparatif des approches

★ est le premier choix en pratique.

Où se situe chaque approche

La refactorisation progressive est l’option la plus réaliste.

• Il n’est pas nécessaire de tout reconstruire d’un coup
• Il suffit de moderniser les écrans ou les fonctionnalités un par un
• Pendant la période de coexistence entre ancien et nouveau, la « conception des parcours » (quel écran fonctionne sur quel moteur) est essentielle

Le wrapper WebView2 sert à « redessiner les frontières ».

• Il ne s’agit pas de préserver tel quel la dépendance à ActiveX ou à COM
• Il déporte vers le côté natif les responsabilités côté système d’exploitation — « opérations sur les fichiers », « intégration d’équipements », « authentification Windows » — tout en modernisant le côté interface web
• Attention toutefois : la responsabilité de la distribution du WebView2 Runtime vous incombe alors

Les micro-frontends ne sont efficaces que lorsque les « frontières d’équipe » coïncident avec les « frontières de déploiement ». Il ne faut pas les adopter simplement parce que c’est à la mode.

La réécriture complète est le dernier recours. Elle se limite aux cas où la dépendance à ActiveX ou aux BHO est trop profonde pour permettre une véritable décomposition.

Étape 3 : démarche concrète (feuille de route)

Évaluer -> Prioriser -> PoC -> Tester -> Déployer -> Exploiter

1. Évaluer — inventorier la dépendance

• Lister les URL cibles avec Enterprise Site Discovery
• Visualiser les transitions réseau avec edge://net-export
• Classer la dépendance en « mode document », « ActiveX/BHO », « authentification », « certificats client », « fichiers/impression » et « équipements/COM »

2. Prioriser — par où commencer

Triez selon les critères suivants.

• Importance (dans l’ordre de gravité si l’arrêt survenait)
• Nombre d’utilisateurs
• Exposition à la sécurité
• Impact sur les autres systèmes
• Facilité de découpage (frontières claires ou non)

En particulier, distinguer « les fonctionnalités qui avancent dès que la frontière est coupée » des « fonctionnalités qui exigent de déplacer la frontière tout entière » facilite grandement la planification qui suit.

3. PoC (preuve de concept) — tester à petite échelle

Commencez par un seul workflow, présentant « une forte valeur métier et une dépendance modérée ».

Les conditions de réussite sont les quatre suivantes.

1. Le mode IE devient inutile
2. Le SSO est préservé
3. Les performances de réponse restent à un niveau comparable
4. Le retour en arrière (rollback) reste possible

4. Tester — gérer la coexistence ancien/nouveau

• Parcours moderne → tests automatisés d’Edge avec Playwright
• Parcours en mode IE → page de diagnostic + vérification manuelle
• Pendant la période de coexistence, explicitez clairement quel parcours fonctionne sur quel moteur (sans cela, la reproduction des anomalies devient très difficile)

5. Déployer — étendre progressivement

• Distribution en canari (déploiement anticipé auprès d’un sous-ensemble d’utilisateurs)
• Réserver une fenêtre de validation avec Extended Stable (cycle de 8 semaines)
• Intégrer l’intervalle de mise à jour de la liste de sites et les exigences de redémarrage du navigateur dans le flux opérationnel
• N’oubliez pas que l’utilisation de la liste de sites cloud suppose que l’utilisateur soit connecté à Edge

6. Exploiter — continuer à réduire

• Utiliser la fonction de retour d’information de Cloud Site List Management pour récupérer les sites ajoutés par les utilisateurs ou les erreurs de configuration
• Faire tourner un cycle opérationnel qui réduit chaque mois la liste des cibles en mode IE
• Toujours associer les « mesures de prolongation de vie » à une « exploitation qui réduit la dépendance »

Vue d’ensemble du flux (organigramme)

flowchart TD
    A[Inventaire des actifs cibles] --> B[Classification de la dépendance]
    B --> C{Quel type de dépendance ?}
    C -->|Mode document / SSO principalement| D[Exploitation officielle en mode IE]
    C -->|Intégration système / COM principalement| E[Mise en wrapper]
    C -->|Découpable écran par écran| F[Refactorisation progressive]
    C -->|Développement parallèle multi-équipes| G[Micro-frontends]
    C -->|Dépendance trop profonde| H[Réécriture complète]

    D --> I[Ajustement des sites neutres et des cookies]
    E --> J[Frontière WebView2/natif]
    F --> K[Coexistence ancien/nouveau et remplacement progressif]
    G --> K
    H --> L[Reconception vers une nouvelle architecture]

    I --> M[PoC]
    J --> M
    K --> M
    L --> M

    M --> N[Tests automatisés et tests opérationnels]
    N --> O[Déploiement progressif]
    O --> P[Collecte des données d'usage et des retours]
    P --> Q[Réduction de la liste cible du mode IE]
    Q --> R[Décision de retrait]

Étape 4 : gouvernance — le cadre administratif

Codifier le mode IE comme un « régime d’exception »

• Pour chaque nouvelle URL ajoutée en cible du mode IE, définissez systématiquement les éléments suivants :
  • Propriétaire métier (qui est responsable)
  • Propriétaire technique (qui en assure la gestion technique)
  • Date d’expiration (d’ici quand sortir)
  • Plan de remplacement (comment sortir)
• Si votre liste de sites XML existante est au schema v.1, migrez vers le schema v.2, utilisable pour l’intégration au mode IE
• Suivez l’historique des modifications avec Cloud Site List Management ou un outil de gestion de configuration

Points de vigilance en matière de sécurité

• Figer une ancienne version d’Edge en exploitation est dangereux → utilisez la dernière série Stable/Beta
• Si une période de validation est nécessaire, utilisez Extended Stable (cycle de 8 semaines)
• Utilisez le Security Compliance Toolkit et Policy Analyzer pour vérifier la qualité des GPO
• « Une exploitation négligée du navigateur en périphérie » entraîne des incidents bien plus souvent que « des vulnérabilités du mode IE lui-même »

Planifier à rebours à partir de l’échéance

• Fin de la prise en charge du mode IE : 2029
• Fin des mises à jour Edge/WebView2 sous Win10 22H2 : octobre 2028

Ce sont là le « cadre extérieur de l’échéance de retrait ». Il faut d’abord construire un calendrier planifié à rebours qui ramène la dépendance à zéro avant la fin de la prise en charge.

Stratégie recommandée selon l’échelle

Erreurs courantes et mesures correctives

Conclusion

Stratégie standard = exploitation officielle du mode IE (prévention des incidents)
           + visibilité sur la dépendance (inventaire)
           + réduction progressive (sortir une pièce à la fois)

• Pour une petite échelle, optez pour la refactorisation progressive
• Pour une grande échelle, misez sur le contrôle de la liste de sites + la gestion de portefeuille
• Si le budget est serré, contenez la situation par la virtualisation tout en stoppant toute nouvelle dépendance
• La réécriture complète est l’ultime recours
• Les conteneurs sont normalement hors sujet, le VDI est un abri, et le mode IE est une piste d’envol (fait pour décoller)

Liens de référence

• FAQ sur le cycle de vie d’IE et Edge — la politique 2029 pour le mode IE
• Présentation du mode IE — la ressource de base sur le périmètre de prise en charge
• Configurer les politiques du mode IE — les trois niveaux de configuration intégrée
• Stratégie de configuration des sites d’entreprise — sites neutres, partage de cookies, schema v.2
• Dépannage et FAQ du mode IE — page de diagnostic, utilisation de net-export
• Cloud Site List Management — gestion centralisée depuis le centre d’administration
• Enterprise Site Discovery — le point de départ de l’inventaire
• Documentation WebView2 — pour évaluer l’approche par wrapper
• Azure Virtual Desktop / RemoteApp — comme mesure d’isolation
• Guide de migration Windows Containers — inadapté comme destination de prolongation de vie pour une interface graphique
• App Assure — le périmètre de l’assistance à la configuration du mode IE
• Playwright — tests automatisés d’Edge
• single-spa — les fondamentaux des micro-frontends
• webpack Module Federation — intégration de builds indépendants

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Jusqu'à quand le mode IE d'Edge sera-t-il utilisable ?

Le mode IE d'Edge est pris en charge au moins jusqu'en 2029, avec un préavis d'un an avant son retrait. Par ailleurs, les mises à jour d'Edge / du WebView2 Runtime sous Windows 10 22H2 sont assurées au moins jusqu'en octobre 2028. Ce délai n'est toutefois qu'un sursis destiné à organiser une sortie planifiée : 2029 doit être considérée non pas comme la date à laquelle commencer à se préparer, mais comme l'échéance à laquelle la sortie doit être achevée, en planifiant à rebours à partir de cette date. L'application de bureau IE11 elle-même est déjà retirée.

Pourquoi est-il si difficile de sortir de la dépendance au mode IE ?

Parce que le mode IE est un mécanisme, à l'intérieur de l'Edge basé sur Chromium, qui fait rendre les anciens sites uniquement par le moteur Trident (MSHTML) — et que ce moteur Trident prend en charge les anciens modes document, les contrôles ActiveX et BHO, les anciens paramètres de zone de sécurité, ainsi que les paramètres de compatibilité d'Enterprise Mode. Tant que vous dépendez de ces éléments, mettre à jour le navigateur ne résout rien à lui seul. La première étape consiste à classer précisément la dépendance en mode document, ActiveX/BHO, authentification/SSO, intégration côté client et hypothèses opérationnelles obsolètes, afin d'en identifier la véritable nature.

Quelles sont les méthodes possibles pour sortir du mode IE ?

Les principales options sont au nombre de six : poursuite de l'exploitation en mode IE, wrapper WebView2, refactorisation progressive, micro-frontends, réécriture complète, et isolation VDI / RemoteApp. En pratique, le premier choix est la refactorisation progressive, qui permet de moderniser les écrans et les fonctionnalités un par un. Le wrapper WebView2 ne sert pas à préserver ActiveX tel quel, mais à redessiner les frontières en déportant vers le natif les responsabilités côté système d'exploitation, comme les opérations sur les fichiers ou l'intégration d'équipements. La réécriture complète est le dernier recours, réservée aux cas où la dépendance est trop profonde pour être décomposée.

Si l'on doit continuer à utiliser le mode IE pour le moment, que faut-il faire ?

Il faut avant tout gérer officiellement la liste de sites par la politique, plutôt que de laisser les utilisateurs recharger la page en mode IE de leur propre initiative. En migrant vers Cloud Site List Management, il devient possible de distribuer plusieurs listes, de suivre l'historique des modifications et d'affecter des listes par groupe. Lorsque le SSO est en jeu, il faut configurer correctement les sites neutres et, si nécessaire, activer le partage de cookies. En parallèle, pour toute nouvelle URL ajoutée au mode IE, il faut impérativement définir un propriétaire métier, un propriétaire technique, une date d'expiration et un plan de remplacement, et associer cela à un cycle opérationnel qui réduit la liste cible chaque mois.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.