Personne à l’intérieur d’un bon esprit va vouloir réécrire son système ERP. Et pourtant, il y a de bonnes chances que les interfaces utilisateurs de type Web (mon côté puriste ne les appelleraient pas comme cela, mais bon) soient codées en dur pour Internet Explorer 6. Quand on a un grand succès et qu’on veut empêcher d’autres de coper notre succès par des moyens techniques, lorsqu’on voudra changer de technologie on va tomber sur plein de petits problèmes assez sournois merci au niveau de la rétrocompatibilité. Et on devient son propre pire compétiteur…
Et ce n’est pas que Internet Explorer 6. En fait pas tellement Internet Explorer 6, le vrai centre où tout est relié est Word et Excel (ou Office, mais surtout Word et Excel). Pour la plupart des gens qui travaillent avec un ordinateur, le logiciel le plus souvent utilisé n’est pas un navigateur Web, c’est Word et Excel. Et tout s’y intègre, tout est plogué sur Word et Excel, même la gestion de contenu Web. Le copy paste Word / Web qui amène avec lui la problématique ISO-8859-1 vs Windows 1252. Heureusement que Wordpress transforme les guillemets en &8217;, parce que je suis coupable moi même d’utiliser Word pour écrire des articles. C’est beaucoup plus convivial qu’un textarea dans un gestionnaire de contenu, même pour Wordpress.
Imaginez que vous voudriez supprimer Word au nom des standards ouverts, vous tomberiez sur plein de problèmes : tout est plogué sur Word. Ton lecteur d’écran ? Marche juste avec Word. Ton outil de gestion de finance, exporte en Excel. Les standards ouverts ne servent à rien s’ils ne sont pas implémentés. J’aurais tendance à dire que pour une moyenne à grosse entreprise, la plupart des systèmes informatiques sont plogués à Word et que si vous enlevez Word, ils ne fonctionneront plus. OpenOffice n’a certainement pas les mêmes API, et les reverse enginerer est sûrement épouvantable, au moins autant que le format .doc lui-même. (Quoique Alfresco essai de le faire pour Sharepoint).
De cette manière, je n’ai pas beaucoup de difficulté à dire que Office a un écosystème aussi gros que le Web, du moins en entreprise. Vous pourriez faire supporter par OpenOffice les standards d’accessibilité pour les connecter au système de texte à voix, ce dernier va probablement mieux marcher avec Word et Windows, qui ont leur propre standard. (Remarque, j’ai peut-être tort et je n’ai pas vérifié, je suis blogueur, pas journaliste, mais j’expose ceci pour faire suivre un raisonnement, pas représenter la réalité dans ses détails). À la maison, moins de choses nous obligent à utiliser Word. À part échanger des documents avec le bureau. C’est un format d’échange de documents passablement utilisés. Mais on peut utiliser autre chose, OpenOffice, ou des documents purement Web, dans certains cas éloignés des PDFs.
Office a été choisi par beaucoup de monde et je suis pas mal certains que nous sommes avec pendant assez longtemps encore. (Ça ne change pas qu’au niveau interface, il est certainement très correct et encore pas mal mieux que Google docs, qui lui a son propre écosystème).
Quand vous choisissez un produit, une solution, vous vous ploguez sur son écosystème. Il est fort possible que plein d’autres décisions soient influencées par cet écosystème. Si, par exemple, tous les éléments de cet écosystème rendent plus complexe et plus coûteuse vos opérations au jour le jour et que venu le jour où les limites de votre patience sont dépassés vous risquez de souffrir (votre portefeuille et votre mental probablement aussi). Placer une entreprise dans un écosystème, c’est comme de mettre une grenouille dans l’eau et de la chauffer tranquillement. Il vaut mieux s’assurer que la température cible ne soit pas fatale.
C’est la grosse question, l’éléphant dans la salle de réunion, pour les outils du cloud computing aussi. Les gens ont encore peur de cet écosystème par contre, et il n’est pas tout à fait évolué, trop Mammouth encore. Mais quand tout le monde va avoir donné ses données à un fournisseur (probablement qu’il y en aura un qui sortira du lot, comme Microsoft l’a fait auparavant), ce sera difficile de se sortir de son pouvoir.
En gros, si les morceaux de l’écosystème ne sont pas déploguables et ne respectent pas des standard ouvert, vous aurez des problèmes lors des mises à niveau et des remplacements. Les coûts risquent d’être élevés. Mais vous avez le choix, je ne les comprends pas encore, mais il doit y avoir des avantages à choisir des standards opaques. En fait oui, il y a des avantages : un certain nombre de choses fonctionnent out of the box. Vous ne partez pas de rien.
Mais toute cette intégration va à l’encontre de la compartimentation des outils logiciels, fondement des architecture orientés services. Quand on réussit à avoir une vraie architecture orientée services (ou plutôt dans le cas des contenus standardisé (ouvertement) une architecture orientée ressources, c’est plus facile de choisir une composant qui respecte le standard et choisir celui qui est le meilleur et non celui-qui vient avec la solution ou un de ceux qui fonctionne avec l’écosystème et qui est fortement intégré lui aussi. Les interfaces utilisateurs des outils se ventant d’être des architectures orientés services ont tendances à ne pas respecter la philosophie de base, mais bon je sors du sujet (il y en avait un ?)
On ne choisi pas le meilleur produit, on choisi le meilleur qui s’intègre avec notre architecture. Par contre, si on suivait des standards ouverts simples (je dis simples, parce qu’il y a des standards ouverts foutaisement compliqués), on aurait plus de choix. (Des fois trop c’est comme pas assez, mais bon…)
Personnellement, je pense que le HTML (même le 5) est trop mal foutu pour créer une base à un nouvel écosystème. Par contre je pense que les navigateurs sont la base de l’écosystème du cloud computing (côté client en tout cas, regardez, je parlais de Word, un logiciel client, c’est pourtant probablement l’outil qui a le plus d’impact sur les architectures d’entreprise et ça me surprendrait qu’ils soient présent dans les graphiques d’architecture, remarquez, moi non plus je ne le mets pas, il est comme on peut dire implicite). Non, je retire ce que j’ai dit, HTML est assez mal foutu pour faire parti d’un écosystème complexe, .doc a bien réussi, c’est clair que HTML peut le faire aussi. Il faut juste bien définir tous ses quirks et tous ses bogues et ses mauvaises manières de faire et on pourra bâtir n’importe quoi dessus, y compris des patentes mal faites et épouvantables, mais qui vont fonctionner suffisamment bien pour nous faire sauver plus de temps qu’il nous en fait perdre. Mouaip, c’est bien ce que HTML 5 est en train de faire hein? Là voilà la recette secrète de Google, définir les bogues pour pouvoir bien construire par dessus!
C’est drôle, parce qu’il faut regarder la fondamentale inertie des systèmes informatiques pour bien comprendre toute l’affaire.
J’ai un pool énorme de documents mal foutu (en .doc ou .html) et je veux les garder utilisables dans le futur (pérennité), et je veux même en créer d’autres de la même manière parce que j’y suis habitué. Je veux aussi créer un paquet de trucs qui les utilise parce que les contenus de tous ces documents sont la source de l’intelligence que je veux utiliser.
En fait, ce qui fait qu’il est difficile de ne plus utiliser l’écosystème Word, ce n’est pas ou peu le format .doc, mais bien les couches applicatives par dessus. De la même manière, on pourrait utiliser un format libre et ouvert (mettons comme le HTML) le rendre suffisamment moche pour avoir besoin de créer des couches par dessus pour faire du vrai travail et ensuite c’est cette couche sur lequel un écosystème se créer et qui ensuite peut forcer à utiliser certains produits faisant parti de cet écosystème. Il faudrait que cette couche par dessus soit aussi ouverte et standardisée que celle en dessous et n’appartienne à aucun revendeur. En fait, lorsqu’on travaille avec des outils de portail, c’est un peu aussi ce qui se passe. Pour être capable de faire fonctionner la personnalisation (comme exemple les boîtes minimisables dans un portail) on ajoute un paquet de javascript dont l’utilisation se fait par génération (outils de portlets de base, JSF sur les portails Java, ou encore du .net comme les Web parts de Sharepoint).
Ces morceaux s’intégrent mal au concept de flux de documents et sont difficilement personnalisables (je parle en termes de programmation CSS) et il faut utiliser les outils des revendeurs au lieu des standards HTML et CSS que l’on serait supposé utiliser normalement. Et je ne parle pas des problèmes que cela cause aux outils d’accessibilité, parce que ceux-ci sont plogués sur le standard de la technologie de base et non pas celle de la couche au dessus. Quoique cela pourrait changer. En fait j’imagine un jour ou l’on pourrait ploguer une technologie d’assistance à l’une de ces couches applicatives au lieu de HTML et rendre cette couche plus accessible que le HTML lui même. Ce serait vraiment Mal de faire cela et j’espère n’avoir donné l’idée à personne. Par contre, j’ai l’impression que ce serait pour le moins très compliqué…
Les outils de portails n’ont pas tellement bien fonctionné en industrie sauf dans les cas où l’on met l’effort nécessaire (c’est pourquoi ceux qui comprennent que mettre beaucoup d’énergie et de gouvernance dans un projet portail d’entreprise (et de comprendre leurs limitations et leurs forcent) finissent par réussir à avoir qqch de fonctionnel et qui réponds aux besoins, je le sais j’ai réussi deux fois dans ma carrière à contribuer à faire marcher Websphere Portal, et là je vais peut-être m’attaquer à Sharepoint - watch this space).
Pour dire que si l’on veut gagner les coeurs de tout le monde, pas juste les architectes d’entreprise, il va falloir trouver une couche applicative par dessus le HTML qui est intéressante pour les développeurs autant pour les technos propriétaires que libres. Attention, la techno elle-même pourrait être libre et ça ne changerait rien, si elle se plogue super facilement aux services de qqun (du cloud computing tiens!) et qu’elle facilite l’appropriation des données (et c’est là le champs de bataille) on va tous être pris à utiliser cet écosystème dans le futur. Dans un autre ordre d’idée, même si tout le monde pourrait revendre par exemple JBoss, personne le fait parce que l’expertise du produit appartient à une seule compagnie. Si la création elle même de la couche applicative est suffisamment complexe, pas personne d’autres que son créateur va pouvoir se l’approprier. Pour qu’elle soit complexe, cela va prendre une couche de base moche et mal foutue, c’est-à-dire HTML + CSS + Javascript + DOM.
Cette pattente là super compliqué, mais facile à utiliser sera accessible par trois morceaux de technologies : les navigateurs (équivalent de Word), les moteurs de recherches (le système d’exploitation) et les outil de cloud computing (l’équivalent de toutes les applications qui font parti de l’écosystème). (Bon ok, ma comparaison est bouetteuse, mais bon… je voulais montrer un point). Cette couche applicative devra être aussi facile d’utilisation que Visual Basic si on veut qu’elle réussisse (je pense que Visual Basic est l’une des raisons pourquoi l’écosystème Word est si grand en ce moment, mettons que c’est .NET maintenant, une très bonne évolution).
La même raison pourquoi le format .doc est si mal foutu, accable le HTML, le don’t break the Web, ou en français la rétrocompatibilité. Aussi le pave the cowpath, ou encore en français, le continuer à faire les mêmes erreurs parce que c’est plus facile. (Bon, je l’ai dit ce que je pensais des orientations du WG de HTML et pourquoi je ne me sens pas capable d’y participer intelligemment et positivement).
XHTML a essayé de briser ce cercle vicieux et à échoué lamentablement, je dirais qu’à cause de manque de support de application/xml+xhtml des outils de l’écosystème Word (les gestionnaires de contenus où le copy paste Word est mandaté, à commencer par Frontpage). Ben oui, encore Word, on est chanceux que l’encodage de base du Web ne soit pas Windows-1252.
Il faudrait donc, que quelqu’un crée cette couche avant qu’un revendeur le fasse, la rende facilement utilisable avec un support génial chez tous les éléments de l’écosystème et out-Microsfter Microsoft et Google. Je pensais que HTML5 serait cette technologie et qu’on aurait pas besoin de créer une couche applicative je suis de moins en moins certain que c’est possible. Je pense que HTML 5 + CSS 4 + Javascript x devraient avoir des composants natifs qui font la même chose qu’un GWT, un JSF ou un ASP.NET et standards + un mapping avec un langage côté serveur qui remplacerait la partie vue des JSP, ASP et PHP de ce monde. (Imaginez, le langage de vue, (dans le sens modèle vue contrôleur) serait le même que vous travailliez en Java, en PHP, en C# ou en Ruby… ça ça serait cool! Pour voir à quoi je pense que ce langage devrait ressembler, regarder la technologie Facelets (ça se plogue avec JSF). Mais pour faire cela, ça prendrait de la vision et beaucoup beaucoup beaucoup d’énergie et d’argent, du genre à ce qui a servi à créer Java dans les années 90s.
Tout ça aussi pour dire que pour sortir IE 6 des entreprises (et par conséquent Windows XP) va falloir beaucoup d’effort encore et que cela va prendre du temps! et que pour faire mieux que HTML 5 faudrait encore plus d’efforts et de temps (et probablement une vision moins fermée du Web que celle des revendeurs de navigateur Web) ! Finalement Karl a raison, nous sommes tous dans nos grottes.
