Dernière mise à jour le

Quand le Web veut dire Internet Explorer 6

Il y a deux phrases qui veulent presque dire la même chose en entreprise :

« C’est une application Web. »

« Ça fonctionne dans Internet Explorer 6. »

Presque. Pour savoir ce qu’on construit, il faut séparer le trajet standard du bout propre au poste Windows.

Quand une personne entre une adresse, IE résout le nom avec DNS, ouvre une connexion HTTP et demande une ressource. Le serveur exécute peut-être ASP ou ASP.NET, lit une base, puis retourne du HTML. IE analyse ce texte pour construire un arbre de document, le DOM. Il télécharge ensuite les feuilles de style, images et scripts référencés, calcule la mise en page et peint les pixels. JavaScript peut modifier le DOM après le chargement sans que le serveur voie chaque clic.

URL → DNS → HTTP → serveur/ASP → HTML
                         ↓
IE → DOM → CSS + JavaScript → mise en page → écran

Ce partage explique déjà quelques pannes. Une validation JavaScript améliore l’expérience, mais une requête HTTP peut contourner le script; le serveur doit revalider les données. Une page mise en cache peut montrer une ancienne version. Une session conservée par cookie peut expirer pendant que le formulaire reste ouvert. Le bouton visible n’est jamais la seule frontière de sécurité.

IE 6 ajoute ses propres interprétations. Une page sans DOCTYPE peut entrer en quirks mode et reproduire d’anciens comportements de mise en page. Le modèle de boîte CSS, les événements et certaines fonctions du DOM diffèrent des autres navigateurs. Si tout le parc est contrôlé, ces différences paraissent sans importance. Elles deviennent du code à reprendre dès qu’un partenaire arrive avec un autre fureteur.

ActiveX va beaucoup plus loin qu’une différence CSS. Une page peut instancier une composante COM installée sur Windows :

<object id="outilDocument"
        classid="CLSID:00000000-0000-0000-0000-000000000000">
</object>

Le contrôle peut ouvrir un document, parler à un périphérique ou accéder à des fonctions locales qu’une page ordinaire ne possède pas. IE vérifie alors sa zone de sécurité, sa signature et les permissions configurées. Le composant doit être installé avec la bonne version et la bonne architecture. Un poste verrouillé peut refuser son exécution; un poste trop permissif peut exécuter du code dangereux avec les droits de la personne.

Une signature Authenticode identifie l’éditeur et permet de détecter une modification du binaire, mais elle ne prouve pas que le code est sans faille. Un contrôle marqué « safe for scripting » expose des méthodes à toute page autorisée à l’instancier. Une mauvaise méthode comme OuvrirFichier(chemin) sans validation peut devenir une porte énorme. Je limiterais l’API, vérifierais l’origine attendue et exécuterais avec le moins de privilèges possible.

Si ActiveX est réellement nécessaire, je l’isolerais derrière une petite fonction JavaScript et une interface serveur claire :

  1. détecter la présence et la version du contrôle;
  2. montrer une instruction d’installation signée si elle manque;
  3. appeler seulement une façade JavaScript, jamais partout dans les pages;
  4. offrir une solution manuelle pour le travail essentiel;
  5. journaliser la version du contrôle lors d’une erreur.

Cette frontière permet de remplacer plus tard le composant sans réécrire tous les écrans. Le HTML, les formulaires, les liens et les réponses HTTP restent standards. Le serveur ne fait jamais confiance à une valeur seulement parce qu’elle vient du contrôle interne.

Je ne bannis pas ce qui est propre à IE en 2003. Livrer un outil interne sur un parc Windows uniforme peut être un très bon compromis. Je veux seulement nommer la dette : version du navigateur, zone de sécurité, installation COM et API exposée. Mon test minimal couvrira un poste neuf, un compte sans droits administratifs, un contrôle absent et une session expirée. « Web » décrira alors le protocole et le serveur; « IE 6 requis » restera une dépendance visible, pas une surprise cachée.

Mise à jour de 2026

Le « presque » a fini par compter. L’application de bureau Internet Explorer 11 n’est plus prise en charge sur les versions visées de Windows 10 depuis le 15 juin 2022. Edge conserve un mode IE, soutenu au moins jusqu’en 2029, pour faire fonctionner les anciennes dépendances ActiveX pendant leur migration. C’est un pont, pas une nouvelle plateforme de développement. La fiche de cycle de vie d’Internet Explorer 11 dirige maintenant les organisations vers Edge et les standards Web modernes.