Pourquoi continuer de supporter IE 6

Flattr this!

Certains m'ont dit s’être bien marrés à la lecture de mon précédent article concernant IE 6. Certains pour le style (je les en remercie), d'autres parce que ne comprenant pas pourquoi je me retrouve encore à déboguer une appli web pour IE 6. Je vais donc essayer de vous exposer ici le pourquoi de cette situation de façon plus concrète. Je précise cependant que c'est mon point de vue, basé sur ma courte expérience, et en aucun cas une vérité générale.

La quantité de clients

Tout d'abord, même sur ce blog, j'ai encore 1% de visiteurs à l'année qui viennent avec IE 6. Je leur souhaite de migrer aussi vite que possible ne serait-ce que pour une version supérieure. Mais ils existent, et je ne peux pas les ignorer. Techniquement, ça représente un investissement. Mais je ne suis pas un pseudo-gourou de la technologie qui peut se permettre de décréter qu'une technologie est aussi arriérée que des disquettes et donc que je n'ai plus à la supporter (bisous Steve). Même si je le pense, je ne peux simplement pas dire à mes lecteurs que je ne veux pas d'eux parce qu'ils sont sur IE 6.

Et là je vous parle seulement des lecteurs de ce blog, pas des clients de la boite pour laquelle je travaille ou de celles pour qui j'ai pu travailler. Je vous expliquerai après pourquoi ce n'est pas une question "de choix" pour la plupart.

L'importance de ces quelques clients

Bon alors là, on parle vraiment des clients et plus de mes lecteurs. Pour vous donner une idée de l'environnement, la boite pour laquelle je travaille a un ratio, en France (je ne compte pas les autres pays), de 3% de IE 6 dans ses utilisateurs extérieurs (site front, collecte d'informations de façon non-invasive, extranet). En interne, nous ne supportons que la dernière version de Firefox et de Chrome. Ce qui nous pose parfois des soucis (je reviendrai plus tard là dessus). Ce n'est pas énorme me direz-vous. Et sacrifier 3% de la masse de clientèle ne ressemble pas forcément à un gros sacrifice si on pense à cette seule mesure face à l'investissement que nécessite la rétro-compatibilité.

Sauf que ce seul critère n'est pas viable. Il faut avant tout regarder le poids de ce "maigre" échantillon de clients. Dedans, on trouve essentiellement des assurances, des banques, des mutuelles ou simplement de très grosses entreprises. Ces clients représentent à eux seuls 30% du chiffre d'affaires de "ma" société. Et ces sociétés ne supportent que IE 6.

Ignorer 3% des clients est potentiellement envisageable, ignorer 30% des revenus non.

Pourquoi ces entreprises ne migrent pas

Il y a deux raisons à ma connaissance, toutes deux très simples.

La première est la taille de l'entreprise. Aussi bien la taille humaine que le poids de l'architecture informatique et notamment logiciels. Le fait de migrer de version leur imposerait un processus très lourd et très coûteux consistant essentiellement à revalider le comportement de toutes les applications liées au navigateur et développées depuis la création de l'entreprise. Dans certaines sociétés, ce coût de test peut représenter plusieurs mois de budget normalement dédié à la R&D.

La deuxième raison est aussi l'auto-mise à jour des navigateurs introduite dans la plupart des navigateurs récents (à minima les Chrom*, Firefox 4+ et IE 9+, je ne sais pas pour les autres). Avoir cette auto-MAJ, imposerait de revérifier la compatibilité à chaque mise à jour. Effectuer ces vérifications à chaque fois représente un coût plus qu'important et donc non négligeable.

Pour cette deuxième raison, je ne vous ai parlé que de la vérification, pas encore de la maintenance. Quitter IE 6 pour IE 9 ou 10 (par exemple) est envisageable parce que les produits sont sortis et déjà "finis". C'est à dire qu'au moment où vous effectuer la migration, vous êtes déjà capable de vérifier avant mise en production de l'appli sur IE 10 (par exemple) que ça tourne.

Dans le cas de l'auto-mise à jour, vous devez être synchrones avec l'équipe de dev du navigateur cible pour porter votre maintenance applicative en même temps qu'eux changent de version le navigateur. Et ceci pour chaque navigateur supporté. Encore un surcoût qui ne serait pas affecté à l'innovation applicative.

Autre chose que je n'ai pas abordé. Je vous ai parlé de faire des vérifications. Cela impose d'avoir développé masses de tests en tout genres. Honnêtement ? Cette pratique n'est pas au point et de très loin même dans de très grosses entreprises. Mettre en place cette vérification systématique a un coût de fonctionnement, de maintien mais aussi souvent de création. Ce coût peut être rédhibitoire pour beaucoup. J'ai travaillé pour de très très grosses entreprises du logiciel avec un certain nombre d'années d'existence pouvant dépasser les vingt ans. On s'attend à ce que la machinerie sur ce point soit bien huilé, vous seriez surpris d'y trouver le même genre de problèmes que dans de plus petites ou plus jeunes entreprises.

Certains vous avancerons l'argument des versions de dev des navigateurs telles que les nightly build. Effectivement, ça aide pas mal à suivre le rythme mais ça n'est pas encore idéal. Parce que celles ci ne sont pas forcément stables et demanderont donc un re-développement de temps en temps et surtout totalement imprévisible dans le temps. C'est un coût mais aussi un risque si on utilise les termes de la gestion de projets. L’aléatoire, ça peut faire très peur. Et ça se comprend.

Vient alors l'argument de la possibilité de désactiver cette auto-MAJ

Cet argument n'est tout simplement pas valable. Vous pouvez bloquer la possibilité à vos employés d'installer un navigateur en leur donnant des droits restreints. Pas la possibilité de les empêcher de cliquer sur une case à cocher dans les préférences de leur navigateur. Je ne connais pas (peut-être que je me trompe) de système d'exploitation qui ait ce niveau de granularité dans leur gestion des droits utilisateur.

La politique de l'autruche face à l'expérience acquise

Bon je vous ai avancé des arguments que je pense jusque là "défendables" voire carrément valables. Mais nous ne vivons pas chez les bisounours, le pragmatisme et la logique que nous, développeurs, avançons comme les seuls viables ne sont pas celle du "camp d'en face". C'est à dire du coté des gestionnaires, de la direction.

Quand vous avez commencé à faire du support pour IE 6, vous aviez un coût important d'apprentissage. Développement de polyfills, compréhension de bogues etc. Ce coût est évidemment normal et propre à tout nouvel environnement supporté. Qu'il soit vieux ou récent. N'oublions pas au passage qu'ajouter un système impose de risquer de nouvelles régressions supplémentaires sur les environnements déjà supportés.

Au bout de quelques mois d'expériences, vous avez développé des tests unitaires, vos polyfills sont rodés et mettent à plat ce que vos connaissances ne savent pas encore gérer ou contrer. Le développement spécifique à la plateforme concernée ne contient alors plus de coût de recherche de compréhension de celle-ci.

Sera alors avancé l'argument d'amortissement de ce coût. Finalement, maintenant que vous savez bien faire, le coût pour maintenir est négligeable.

Les bonnes tentatives qui foirent

Un de mes followers Twitter m'a dit toujours tenter la blague de l'inter-opérabilité avec des supports récents dont on ne peut plus ignorer l'existence désormais. C'est à dire les unités mobiles. Que ce soit les smartphones ou les tablettes.

L'idée est bonne mais archivée d'avance avec ces gros clients. On ne devient pas gros en affaire en étant complètement idiot ou ignorant. A part peut-être de rares exceptions (je n'ai aucun exemple à ma connaissance), toutes ces grosses boites ont un minimum de personnes techniquement compétentes. Quand l'allégation de la non possibilité de faire à la fois du IE 6 et du mobile sera avancé, vous vous écraserez lamentablement.

Parce qu'en face, ils auront surement entendu parler des polyfills, de jQuery, de Mootools, de jQuery Mobile, de Sencha Touch, de Bootstrap etc. Peut-etre sans connaitre aucun des noms. Ou plus généralement, d'un concurrent ou même pas d'un concurrent dont il leur est arrivé à titre professionnel d'aller sur leur site au boulot avec leur IE 6 et d'avoir voulu par exemple vérifier une info pendant un trajet sur leur smartphone.

Finalement ?

Je n'encourage pas l'utilisation d'IE 6 ni même le maintien de la politique de l'autruche. Je comprends juste mes clients qui m'avancent le coût imposant des mises à jour. Notamment parce que j'ai eu l'occasion de bosser en interne pour eux comme employé. Il est vrai que ça n'est pas la partie la plus funkie de notre métier, et si je peux éviter, j'évite moi aussi volontiers. Mais malheureusement, nous n'avons pas toujours le choix d'imposer nos idées à nos clients.

Flattr this!

A propos de Mathieu

Ingénieur développeur web dans la vente par correspondance B2B, adepte de nouvelles technologies et d'innovation. Vous pouvez aussi me retrouver sur Twitter @mathrobin
Cette entrée a été publiée dans Internet Explorer, avec comme mot(s)-clef(s) , , , , , , , , , . Vous pouvez la mettre en favoris avec ce permalien.
  • http://www.nicolas-hoffmann.net/ Nico

    Simple pragmatisme pour moi aussi sur certains sites : typiquement le site qui a 30% de visites venant de Chine, on peut faire passer la pilule dégradation progressive, mais le « on s’en fout d’IE6 », ça n’est pas envisageable.

    Heureusement, ça disparait petit à petit. :)

    • http://www.mathieurobin.com/ Mathieu

      Et encore, la Chine est souvent prise comme exemple, mais elle est loin d’être seule.

  • Nathan

    Je voudrais réagir à ce point et en profiter pour apporter un argument qui t’a échappé :
    « Cet argument n’est tout simplement pas valable. Vous pouvez bloquer la possibilité à vos employés d’installer un navigateur en leur donnant des droits restreints. Pas la possibilité de les empêcher de cliquer sur une case à cocher dans les préférences de leur navigateur. Je ne connais pas (peut-être que je me trompe) de système d’exploitation qui ait ce niveau de granularité dans leur gestion des droits utilisateur. »

    Si vous vous demandez pourquoi choisir IE en entreprise, sans forcément parler de la v6, pensez que ce fut pendant très longtemps le SEUL navigateur à avoir implémenté la notion de GPO sous Windows. Ce qui signifie que le logiciel PEUT se conformer à la politique de sécurité de l’entreprise. Je ne sais pas si dans les GPO il y en a une qui interdit la MàJ mais franchement ça ne m’étonnerait pas le moins du monde !

    Bonne continuation :)

    • http://www.mathieurobin.com/ Mathieu

      Effectivement, j’avais oublié ce point. Je crois que c’est une des raisons qui fait que Thalès et Dassault Systèmes (entre autres), ne supportent que IE 6 sur certaines applis hyper critiques.

    • http://www.mathieurobin.com/ Mathieu

      Faudrait que je fasse un article sur les GPO à l’occasion. C’est vrai que c’est un point clé. Je sais qu’il est possible d’en faire de même avec Chrome, je suppose que Firefox aussi.

  • http://www.pure-tentation.fr syndrael

    Je plussoie.. même situation pour moi.
    Les grosses entreprises ne sont pas nécessairement lesp lus innovantes.. bien au contraire.
    Le changement coûte cher en terme de déploiement, support, tests etc.. Trop cher pour un ROI pas toujours satisfaisant.

    • http://www.mathieurobin.com/ Mathieu

      Pas toujours satisfaisant voire carrément pas du tout intéressant.

  • Pascal Chevrel

    Salut,

    Je ne suis pas l’actu en détails des versions de Chrome et IE en entreprise, mais je voudrais signaler que ce que tu dis sur la nécessité absolue de suivre le rythme de développement des devs de Firefox est partiellement faux (et je pense que pour Chrome c’est pareil).

    Firefox, comme Chrome, sort une nouvelle version toutes les 6 semaines, version comportant des changements fonctionnels, c’est vrai. Mais il y a aussi une version de Firefox, Firefox ESR (pour Exended Support Release) qui a une durée de 1 an et qui est destiné aux déploiements dans les entreprises, celle ci ne reçoit que des mises à jour de sécurité/stabilité et éventuellement des patchs impactant très fortement les entreprises. Il n’est donc pas forcément nécessaire de suivre le rythme de développement des développeurs pour valider ses applications.

    À la fin du cycle de un an, il y a quelques semaines pendant lesquelles l’anciennes et la nouvelles version ESR sont proposées (en ce moment c’est ESR10 et ESR17) afin que les responsables de parcs aient le temps de migrer. La version à tester en amont est donc pour ceux qui étaient en ESR10 la version Aurora/Beta de ce qui est aujourd’hui la version 17. Cela donne à peu près 3 mois pour retester ses applications.

    https://www.mozilla.org/fr/firefox/organizations/
    https://www.mozilla.org/en-US/firefox/organizations/faq/
    https://www.mozilla.org/en-US/firefox/organizations/all.html

    Je rajouterais aussi que si une entreprise est encore sous IE6 qui n’est même plus supporté par Microsoft, ça ne peut être que pour des raisons de compatibilité avec des applications qui ne sont pas des vraies applications Web (=applets java et activeX, plugins maisons) car la rétrocompatibilité avec les vrais standards du Web est tout de même excellente dans les navigateurs, même dans IE.

    Salutations

    • http://www.mathieurobin.com/ Mathieu

      Effectivement, je n’ai pas parlé de ces versions ESR qui sont un beau geste de Firefox d’ailleurs. A ma connaissance, il n’y a pas d’équivalent Chrom* (ium/e). Mais dans le cas d’un upgrade de navigateur, j’ai rencontré un cas plus rare où on ne supportait que Firefox 3. Et aucune autre version ni autre navigateur. Parce que l’application était développé en XUL et utilisée notamment le XUL distant (désactivé mais paramétrable à partir de la 4).

      Après je n’ai pas dit que toutes les raisons avancées sont bonnes, réalistes et objectives. Certaines le sont, d’autres non. Etre sur une aussi vieille version impose qu’il y a aussi certainement un léger manque d’investissement dans la technique… Et ça c’est pas génial.

  • montesq

    Concernant le problème des màj automatiques des navigateurs, il s’agit d’après moi d’une inquiétude induite par le fait que depuis les prémices du développement web, les applications n’ont pas été développées par rapport à un standard, mais par rapport à des navigateurs (qui ont +/- librement interprétés le standard).
    Du coup, dans l’imaginaire des décisionnaires, il est nécessaire de valider une application pour chaque nouvelle version du navigateur!? Alors que si une application est respectueuse des standards, elle fonctionnera sur n’importe quel navigateur supportant correctement ces standards. Les éditeurs ont de leur côté la responsabilité des tests de régression et il me semble que les tests ACID ont apportés beaucoup de visibilité au respect des standards.

    • http://www.mathieurobin.com/ Mathieu

      C’est exactement ça. Ajouter au problème que n’importe quel décideur te dira, en prime (et je ne jugerai pas de la qualité de ce raisonnement qui me semble un peu limite, mince, je l’ai dit), que les éditeurs ont certes la responsabilité de le faire, mais est-ce qu’ils le font vraiment et le font-ils correctement ?
      La confiance n’est pas souvent de mise dans le monde des affaires, c’est dommage mais ça peut aussi se défendre. Parfois :s

  • http://www.mickael-andrieu.fr mickael andrieu

    Que l’on fasse du support IE6 pour le fric, oui.
    Par contre soutenir que l’idée est bonne sûrement pas.
    Les grosses entreprises paient leur choix de s’être basée sur une solution fermée et proprio qui n’est même plus maintenue: j’ai envie de dire qu’ils avaient qu’à embaucher une bonne DSI capable de faire évoluer l’infrastructure au fur et à mesure.

    Se reposer sur IE6 pendant 15 ans, ça a permis de l’économie sur ces 15 années là, mais il faudra bien passer à la caisse un jour et ça fera mal. (Et les standarts étaient existants à cette époque là, pas d’excuses).

    Par contre c’est chouette de libérer quelques tips pour IE6, même si je refuserai toujours ce type de support :)

  • http://blog.mageekbox.net mageekguy

    Je comprend la problématique, mais je refuse purement et simplement de l’accepter.
    Avec ce genre de raisonnement, dans 10 ans, on maintiendra encore, voir on développera encore, des sites pour IE6.
    Ça laisse songeur, non, dit comme cela ?
    Personne n’avance en restant ancré dans le passé, même avec les « meilleures » raisons du monde, et encore moins quand on se traîne un boulet de la taille de IE6.
    Certes, la migration coûtera cher, mais à un moment, il faut bien payer pour ses erreurs, et c’est de plus omettre le retour sur investissement que peut représenter même à court terme le gain de productivité et d’efficacité que peut représenter l’utilisation d’un navigateur moderne.
    L’utilisateur y gagnera en confort et en productivité grâce à leur performance en nette hausse et les nouvelles possibilités qu’ils offrent en terme d’ergonomie, que ce soit au niveau de leur propre interface (barre d’adresse unifiée, omnibar, etc) ou bien grâce aux nouveautés qu’ils supportent au niveau de HTML, JavaScritpt et CSS.
    Le développeur y gagnera tout autant en confort et en productivité, pour les mêmes raisons et avec en plus le gain apporté par les standards que les éditeurs sont de toute façon quasi obligés de suivre sinon le marché les sanctionnera immédiatement, vu que ce dernier sait ce que cela lui coûtera s’il renouvelle l’erreur « IE6 ».
    Enfin, l’entreprise concernée y gagnera des développements pérennes ou qui seront tout au moins plus facilement transposable d’une technologie à l’autre (ou d’une plate-forme à l’autre) grâce au respect des standards, qui au passage annule le problème des mises à jour automatique.
    D’ailleurs, comme pour beaucoup d’autres choses censés améliorer les choses, je me demande quelle est réellement la valeur ajoutée des certifications effectuées en interne pour valider l’utilisation d’un logiciel en général et du navigateur en particulier, surtout en regard du retard technologique que cela implique et donc du coup des bidouilles et autres astuces nécessaires de trouver et à mettre en œuvre pour faire quelque chose qui se fait en deux coups de cuillères à pot avec une version plus récente du logiciel en question.
    Certes, il faut du courage pour faire la démarche, mais reculer ne permet pas toujours de mieux sauter et ne réduira de toute façon pas le coût de la migration, d’autant que les développeurs qui auront développé les versions IE6 vont ou ont quitté l’entreprise, se feront donc de plus en plus rare, et du coup ne pourront pas apporter leur expérience autant technique que métier lors du portage des sites concernés.
    Du coup, personnellement, en tant qu’extrémiste assumant ses idées, j’ai fais le choix de ne plus développer pour IE6 depuis 2005, et professionnellement, je ne le fais qu’avec le couteau sous la gorge et un 357 magnum sur la tempe.
    Et je ne m’en porte pas plus mal.

    • http://www.mathieurobin.com/ Mathieu

      Je le fais le moins souvent possible (la première fois en 2 ans du coup là). Je fais ce que je peux pour convaincre mes clients pour leur faire comprendre que ce n’est pas la bonne direction, mais si ce n’est pas un point négociable je fais. Mais on est d’accord, je n’ai pas du tout envie de me retrouver dans dix ans, ni même l’année prochaine à encore développer des sites compatibles IE 6.

      D’une certaine façon, tu n’as pas tort d’être de ces extrémistes, et même si j’accepte de faire, pour l’interne, je ne valide que la dernière Chrome et la dernière Firefox (et je suppose que ça valide aussi Safari du coup) comme je le disais dans mon article. Ça fait toujours un DSI de moins à convaincre. On aura leur peau.

  • http://doublevroar.wordpress.com Doukyo

    Très bon article !

    J’ajouterai à ça la notion de sécurité, quand une équipe de sécurité informatique a réussi à identifier et à pallier à la majorité des problèmes de sécurité d’un de leurs logiciels, ils sont plutôt frileux à l’idée de recommencer tout le process de validation du logiciel avant son déploiement sur tout la boite…

    Et il y a aussi la notion de la pluralité des supports informatiques : quand un logiciel est implanté depuis longtemps, ils savent que toutes leurs machines le supportent. Une mise à jour risquerai d’avoir des incompatibilité et de nécessiter un changement de matériel.

  • http://danielhagnoul.developpez.com/ Daniel Hagnoul

    Les entreprises sont coupables d’avoir utilisé les particularités d’un navigateur, mais la société Microsoft n’est pas innocente, elle a toujours mis en avant des spécifications particulières, elle n’est jamais en harmonie avec ses concurrents pour l’adoption des normes. Elle n’a toujours pas retenu la leçon, IE9 et IE10 souffrent toujours des mêmes maux.

    Je dois avouer que je connais mal IE10, mais ce n’est pas de ma faute, il n’existe toujours pas une version définitive pour W7.

    • montesq

      Je crois malheureusement qu’il est impossible de trop blâmer les entreprises pour lesquelles IE6 était déjà intégré dans l’OS et à l’époque il existait très peu de concurrents « crédibles ». On ne pas non plus blâmer Microsoft d’implémenter des fonctionnalités « propriétaires » qui répondent à des véritables besoins des utilisateurs / développeurs -> c’est aux développeurs dans ce cas à faire la part des choses et les éditeurs doivent être force de proposition dans les évolutions des normes.
      Je pense que le VRAI problème vient du fait que Microsoft était dans un position archi dominante au début d’IE 6. En décidant de ne pas implémenter correctement les standards, cela obligeait les développeurs à développer spécifiquement pour IE 6, voire uniquement pour ce navigateur et ainsi les autres navigateurs ne pouvaient pas avoir de rendu satisfaisant pour ces sites, ce qui visait à limiter l’adoption des produits concurrents et donc à conforter la domination d’Internet Explorer… Et étrangement, quand Mozilla Firefox, puis Chrome/Safari ont commencé à prendre des parts de marché non négligeables, IE a travaillé (sérieusement) sur la compatibilité avec les standards!

      • http://www.mathieurobin.com/ Mathieu

        Oui, ils ont d’ailleurs tellement travaillé qu’ils ont fait des progrès de fous furieux et accessoirement ont meme pris de l’avance sur certains points. D’ailleurs, ils se sont même pas mal impliqué dans des devs assez sympa comme jQuery.

    • http://www.mathieurobin.com/ Mathieu

      Exactement, c’est une stratégie qui ne s’est pas révélée payante pour IE 6, mais potentiellement, pour IE 10, cela se pourrait. Quand on voit l’avance qu’ils prennent grâce aux questions des accélérations matérielles, potentiellement…

  • https://twitter.com/robin_parisi Robin

    Ce que je trouve extrêmement frustrant, c’est le temps passé à comprendre le fonctionnement d’iE6 pour corriger les bugs. Lorsque l’on apprend une nouvelle technologie, il y a de grandes chances pour que cet apprentissage nous soit bénéfique dans le futur. Certes, les technologies évoluent et disparaissent, mais le fait qu’elles suivent certains standards nous apporte quand même une méthodologie et un savoir qui nous resservira dans plusieurs années. Dans le cas d’IE6, l’on se retrouve face à un mauvais produit (peut être était il bon à ses débuts, je ne saurais le dire), qui oblige les développeurs non pas à comprendre et apprendre des standards, mais des façons plus ou moins élégantes de bricoler une application afin de la rendre compatible avec le vilain petit canard de la famille IE. Ainsi, que ce soit l’investissement en termes de temps ou les méthodologies acquises, tout cela sera perdu dès lors qu’IE6 disparaitra. Étant encore étudiant, je n’ai jamais eu au cours de mes stages à assurer la compatibilité vers IE6, mais j’ai pu lire énormément à ce sujet sur le net, et cela me donne l’impression d’être devenu une discipline à part entière, limite une compétence à mettre sur son CV tant l’exercice semble ardu et prise de tête.

    Après, je comprends tout à fait la problématique remise dans le contexte de l’entreprise. Dès lors que l’argent entre en jeu, il n’est pas possible de se priver d’une partie de sa clientèle. Par contre, je me demande quelle est l’utilité réelle de repousser l’échéance ? Si je ne me trompe pas, IE6 ne sera plus supporté début 2014, ainsi, le processus de migration que tu décris devra bien être mis en oeuvre d’ici cette date non ?

    En ce qui concerne les autres cas, c’est à dire là ou de l’argent ne rentre pas en jeu (blogs, site perso, etc…), je ne comprends pas l’intérêt de rendre un site compatible IE6. Cela ne fait que tirer le web vers le bas et c’est bien dommage. On nous répète en permanence qu’il faut choyer l’utilisateur, mais l’utilisateur n’est pas non plus un idiot et est capable de mettre à jour son navigateur. Si la plupart des sites qu’il visite ont un rendu dégueulasse, voir ne sont tout simplement pas consultables, il va commencer à se poser des questions. Si maintenant, on lui explique à l’aide d’un bandeau pourquoi et COMMENT migrer, et quels sont les avantages pour lui, il le fera avec plaisir. Pour illustrer mes propos, je donne des cours sur mon temps libre à des débutants en informatique et propose aussi du service à domicile : la plupart du temps, IE6 est encore là car les gens n’ont tout simplement aucune idée de ce qu’est un navigateur. Ils connaissent Internet Explorer et c’est pour eux le seul outil qu’il existe pour naviguer, et ils n’ont aucune idée de comment le mettre à jour (la faute à Microsoft), ou même passer à un autre. Ainsi, ils sont généralement ravis de découvrir les fonctionnalités et la vitesse offertes par un navigateur différent.

    En tout cas, merci pour cet article très intéressant qui à le mérite d’ouvrir le débat :)

    • http://www.mathieurobin.com/ Mathieu

      On est d’accord, je ne vois, à ma connaissance, aucun blog qui pourrait avoir l’utilité d’être compatible IE 6. J’ai tendance à croire que le mien l’est, mais je n’irai pas le vérifier.

      J’aime beaucoup l’idée de la compétence sur le CV. Je n’irai pas le faire parce que je ne veux pas que ça continue dans cette voie, mais j’ai quand même ri à l’ironie de cette situation si réaliste.

  • Benjamin

    Article intéressant. Toutefois, comme @mageekguy je me refuse à faire du IE6 (voir même IE7). Il est envisageable de mettre en place un suivi des versions de navigateur. Si les applications étaient testées de manière automatisées cela n’en serait que plus facile. L’intégration continue ne sert pas qu’à tester les nouveaux développements. Et la mise en place de tests fonctionnels pourraient fortement aider (merci PhantomJS).
    Evidemment que c’est couteux. Maintenant s’ils se penchaient sur le cout réel de la maintenance applicative liée à IE6 depuis la sortie de IE7 et IE8, ils se rendraient compte qu’ils ont dépensés bien plus que ce que leur coutera la migration.
    A vouloir trop reculer pour mieux sauter, on ne saute plus. Donc plus d’évolution, plus d’innovation. Ha, mais c’est vrai, pour les grosses boites on y est déjà 😉

    • http://www.mathieurobin.com/ Mathieu

      On est d’accord qu’avec des tests, ça ne pose pas de soucis. Mais c’est ce que je disais, les tests ne sont pas si fréquents non seulement qu’on le croit mais qu’on l’espère.

      Ceci dit, je ne suis pas totalement d’accord avec toi sur le cout important de rester sur IE 6. Pas de nouvelles licences, pas de temps d’installation/migration, une technique à force maîtrisée, et donc rentabilisée, pour le savoir-faire (perso j’ai ma petite lib un peu chaotique mais éprouvée de polyfills). Je ne suis pas sur que ce soit le meilleur des arguments.

  • Marouane

    Si comme moi votre boite a pour client les services publics, et bien vous n’avez qu’à fermer votre gueule et coder pour IE6 …

    • http://www.mathieurobin.com/ Mathieu

      Oui alors là c’est pire que tout. Chez Thalès, quand j’y étais, par exemple, IE 6 était inclus dans un max de spec « standardes » parce que le client était souvent l’armée et là bas, c’est forcément IE 6. Mais je ne suis pas convaincu que l’armée est le même genre de base de réflexion qu’une entreprise classique.

      • Jimmy

        Je ne suis pas d’accord avec toi. Le navigateur standard au sein de l’Armée de l’Air par exemple est Firefox. Etant ancien développeur pour eux, je suis bien placé pour le savoir.
        Et pourquoi ne pas faire cohabiter plusieurs navigateurs sur les machines. C’est ce que ma nouvelle société a décidé de faire et ça fonctionne très bien.
        IE pour les anciennes applis web critiques développé pour et Chrome ou Firefox pour les nouvelles avec un petit contrôle applicatif du navigateur utilisé.

        • http://www.mathieurobin.com/ Mathieu

          Bah écoute, peut-être que du coté des avions, ils ont progressé, mais au sol, on exigeait systématiquement de nous (j’ai fait des projets pour l’armée de terre, pour être précis), que ça soit compatible IE 6. De toute façon, même sur nos bécanes de développeur, on était verrouillés et on ne pouvait pas installer autre chose. Ceci dit, c’était il y a entre 3 et 4 ans, peut-être que ça a changé. Et je le souhaite sincèrement.
          Je suis d’accord avec toi pour le double usage, sauf que la politique de l’autruche appliquée dans certaines très grosses sociétés te répondra bêtement « pourquoi investir dans deux navigateurs en simultané quand on a tout qui marche sur un seul et qu’on a l’expérience et le savoir faire pour celui-ci ? ».
          Encore une fois, je ne défends pas les entreprises qui tournent encore avec IE 6, ce que je désapprouve en tant que technicien, j’essaie juste d’expliquer d’un point de vue non-technicien pourquoi un développeur web peut se retrouver au jour d’aujourd’hui à encore devoir assurer la compatibilité.

  • Juju

    Vivement que Google utilise un 0day pour installer chrome frame en mode Silent 😉

  • Pluriels

    J’ai travaillé quelques années pour une société équipée de centrales nucléaires…
    Jusqu’à très récemment, IE6 était de rigueur, c’est maintenant IE7 et FF3 :D.

    En tant que développeur, la contrainte IE6 m’a permis de comprendre la nécessité de la normalisation W3C, de pousser jusqu’au bout la portabilité de mon code et de ne hacker / polyfiller qu’au dernier ressort. Prototype / jQuery m’ont enlevé une belle épine du pied pour faire du javascript. Il faut aussi admettre que la norme était de travailler sur IE6 et ensuite rendre compatible pour FF. les « jeunes » vivent malheureusement l’inverse !

    Commercialement, les sociétés qui utilisent encore IE6 ont en moyenne un budget IT plus important que le CA d’une agence web de bonne taille. L’informatique de gestion représente une part non négligeable du gâteau informatique. Je ne mange plus de ce pain là, mais on connaît tous quelques moineaux qui aiment bien picorer.

    Les DSI grands comptes sont à des années lumières de notre mode de fonctionnement. Gérer un parc de 200000 postes, quelques milliers de serveurs, plusieurs milliers d’applications demande une logique et une organisation un peu différente. (Le tout dans une approche « externalisation » contractualisée et des tierce maintenance applicative et des « prestas » à tous les niveaux)
    – la DSI s’est construites à une époque où il qualifiait proprement les solutions informatiques, matériel compris.
    Exiger la compatibilité avec une version spécifique d’un logiciel est une pratique courante.
    – la DSI empêche l’utilisateur d’installer des logiciels sur son posre, il y a d’ailleurs une équipe « poste de travail » qui pilote toutes les installations, rien que la gestion des JVM est compliquée.
    – la DSI va rarement chercher le dernier build sur github avant de déployer, chaque logiciel est qualifié en amont et ensuite proposé. (on n’installe pas n’importe quoi non plus sur un serveur, encore moins PHP 5.4…)
    – la vague « appli web » est récente, la vague « client lourd » résiste encore => changer d’OS pose problème or IE6 est le dernier IE compatible windows 2000 (ne pas rigoler !)
    – l’écriture du code a changé, procédural / objet, architecture logicielle, qualimétrie
    – les méthodologies ont changé : TDD, BDD, DDD, documentation du code, intégration continue
    – certains matériels sont livrés avec les logiciels propriétaires. il faut payer pour monter de version…
    – la migration des applications en rupture technique aurait un coût et un délai inacceptable, non seulement la MOE (le développeur), mais aussi les MOA (valider les nouvelles spécifications, tester et retester…)

    Finalement, ce qui est dur, c’est d’être DSI, d’aller voir son patron en disant j’ai besoin de 100 millions d’euros pour me passer d’IE6 et tu verras, après, notre SI sera meilleur et nous serons plus performant. Et le patron te répond qu’il t’a déjà confié 20 millions pour un projet qui a foiré…

    • http://www.mathieurobin.com/ Mathieu

      Effectivement, le point de vue est fondamentalement différent. Après comme dit, certaines raisons sont bonnes d’autres non. Il ne peut pas y avoir de jugements arbitraires même si techniquement on ne peut pas/devrait pas continuer dans cette direction.
      J’aime bien ta « liste » de choses à prendre en compte coté DSI d’ailleurs.

  • Pluriels

    Un dernier complément, sur les usines logicielles, ou l’intégration continue : sur des applications qui devront avoir 5-10 ans de durée de vie, il faut également que l’outillage puisse être embarqué.
    Si dans 5 ans, je confie mon application à la société X avec mes tests, elle devra installer SimpleTest.
    => ah non c’est plus possible, avec la sortie d’Atoum en 2010, SimpleTest a été abandonné et le site a disparu…
    (j’en profite pour remercier les auteurs de ces outils, je sais qu’ils passent par là !)

    • http://www.mathieurobin.com/ Mathieu

      Je lui ai passé le mot au cas où. J’ai même l’impression que ça lui a fait plaisir 😉

  • Guibsou

    Et sinon, tu débogues aussi pour netscape ? 😀
    Sérieusement, avec le fric qu’ils ramassent (banques, assurances, mutuelles), on va pas me faire croire qu’ils peuvent pas se permettre de migrer les navigateurs de leur parc.
    En plus ça leur justifirait une augmentation (vu qu’il faut se justifier pour tout aujourd’hui).
    Après, ça reste une histoire de gros sous, mais si je devais passer (je sais pas combien de temps ça te prend) autant de temps sur ie6 que sur les autres navigateurs , je penses que j’irai au taf à reculons !
    Au pire, tu fais une applet qui dectete ie6 , le desinstalle et qui installe un navigateur recent. Avec ça, tu contribues à leur migration (ça merite meme un ptit bakchich :D)

    Guibsou, extremiste aussi !

    • http://www.mathieurobin.com/ Mathieu

      Du tout, Netscape ne génère à ma connaissance plus aucune visite. Et c’est très bien ainsi. Quand à ta façon arbitraire de travailler, certes il faut sérieusement inciter ces boites à avancer, autant on ne peut pas le faire ainsi.
      D’ailleurs, ton applet Java n’aura jamais les droits que tu requières. Et une telle action te ferait perdre ces clients une bonne fois pour toutes.

  • So

    Personnellement, même si ces entreprises ne veulent/ne peuvent pas migrer leurs applications, il devrait être encouragé d’utiliser des navigateurs plus récents à côté d’IE6. Ne pas limiter l’installation sur les postes à IE6. Un minimum d’éducation des employés est nécessaire.

    • http://www.mathieurobin.com/ Mathieu

      On est d’accord sur le principe qu’il ne faut pas juste baisser bêtement la tête. Le minimum est d’en parler avec le client pour qu’il arrête de maintenir IE 6 et donc migre, mais si il refuse, c’est lui le client après tout. L’éducation des employés n’a que peu de sens là dedans. Il y a un coût de formation certes mais minime par rapport aux coûts de tests. Sachant que j’ai tendance à croire que la plupart des gens ne sont plus à titre privé sur IE 6 mais sur des versions plus récentes voire sur d’autres navigateurs.

  • http://www.poeme-france.com/ Illusion

    Bonjour,

    Le lien pour la version de Chrome pour les entreprises et celui ci : https://www.google.com/intl/fr/chrome/business/browser/

    Sinon personnellement, je pense que de plus en plus même en entreprise le fait des rester avec IE6 pose problème vu qu’il n’est pas supporter par les dernière version de windows. Se qui entraîne que lors de l’achat d’un nouvel parque informatique les solution afin de pouvoir installer IE6 on aussi un coût non négligeable et qui de plus demande une certaine formation car les utilisateur on de plus en plus l’habitude des version récente des navigateurs.

    • http://www.mathieurobin.com/ Mathieu

      Honnêtement un truc développé à l’époque pour IE 6, si il n’a pas été rénové depuis, ça ne fonctionnera pas ou très mal sur Chrome. Et là, bah tu l’as dans l’os, soit tu seras contraint de retourner à IE 6, soit tu y reviendras par la force des choses parce que tout simplement, c’est trop dur de travailler dans un environnement qui déconne 1 fois sur 2. D’autant que certaines industries ne fournissent pas forcément l’accès à Internet aux postes de leurs employés. J’ai bossé quelques mois dans une industrie spatiale. Pour des raisons de sécurité, on n’avait pas accès à Internet. Il y a toujours des moyens variés pour finir par pouvoir l’installer, mais la majorité des gens n’ont pas forcément envie de se prendre la tête.

      Pour la suite, je suis d’accord. Il commence à y avoir des coûts de formation, une maintenance complexe parce que peu de développeurs savent et acceptent de travailler dans ces « conditions ». La migration finira forcément par arriver. Mais pour certains sites, pour certains business, il est malheureusement encore nécessaire de maintenir la compatibilité avec IE 6. C’est mon cas. Ça ne m’empêche pas de prôner les mises à jour automatiques et l’éducation du client.

      • http://www.blog-note.com/ kornemuz

        Sachant que l’utilisateur n’aura pas besoin de mettre à jour son navigateur s’il n’a pas accès à internet 😉

Articles liés