Réflexions autour de Silverlight

Passé l’effet d’annonce, je vous propose 2 ou 3 petites réflexions sur Silverlight et la stratégie d’attaque de Microsoft.

Si l’on prend du recul sur ce qui c’est passé ces trois dernières années, il est possible de faire deux constats :

  1. Il y a eu un véritable foisonnement technologique avec une multiplication des langages et framework, mais la capacité d’adoption de toutes ces nouveautés par le marché est limitée) ;
  2. Les services ayant connu la plus forte croissance (MySpace, YouTube…) reposent sur l’exploitation de contenus audio et vidéo et sur l’utilisation de Flash comme lecteur universel.

A partir de là, Microsoft a choisi deux leviers pour accélérer l’adoption de Silverlight :

  • Les contenus vidéo qui sont particulièrement bien exploités par Silverlight (manipulation et nombreux traitements graphiques de façon native) de même que les services qui vont avec (hébergement et streaming) ;
  • La prise en charge d’un environnement de développement existant (la plateforme .Net) qui n’impose pas l’apprentissage d’un nouveau langage.

Je me permets néanmoins d’émettre des réserves sur ce dernier point. La promesse de Microsoft est la suivante : avec la nouvelle version de la plateforme .Net, vous utilisez le langage qui vous arrange le plus (C#, PHP, Python, Ruby…) et le code source est compilé pour être ensuite exécuté sur Silverlight via la machine virtuelle CLR (Common Language Runtime). On parle ainsi d’un environnement d’exécution universel (voir à ce sujet le billet suivant : The scoop on Silverlight for developers).

La promesse est belle, mais la réalité sera plus complexe : Le traducteur de la plateforme .Net saura-t-il respecter toutes les subtilités des autres langages de programmation ? Si vous avez commencé à développer en PHP ou en Ruby, pourquoi traduire tout cela avec la plateforme .Net qui est payante alors qu’il existe de nombreux framework de développement d’interfaces riches (Zend pour PHP, Ruby on Rails…) ? L’histoire nous a montré que Microsoft avait les moyens de ses ambitions, mais ils devront faire leurs preuves.

Il y a par contre une bonne nouvelle : Silverlight va à mon avis très fortement accélérer le développement de RIA dans le monde de l’entreprise (d’intranets riches ?). Adobe a fait (et fait encore) de gros efforts pour évangéliser les interfaces riches dans le monde de l’entreprise, mais c’est Microsoft qui risque de remporter la mise car Flash a très mauvaise réputation dans les grands compte (du moins pour une exploitation interne dans le cadre d’applications d’entreprise).

On peut ainsi espérer que Silverlight va créer des besoins au sein des entreprises : ces dernières disposent déjà des ressources de production (les développeurs .Net), il leur manque maintenant les ressources créatives (concepteurs d’interfaces riches). Là où les équipes créatives étaient cantonnées à la réalisation de sites web, peut-être vont-elles être sollicitées pour la conception d’applications internes sous forme de RIA ou de RDA.

Il va donc falloir s’attendre à de nombreux bouleversements dans le monde des applications d’entreprises ainsi qu’à une évolution vers des intranets 2.0 (reposant sur des interfaces riches et des services de collaboration en ligne). Pour plus d’infos, je vous recommande l’article suivant : Silverlight: The Web Just Got Richer.

Un commentaire sur “Réflexions autour de Silverlight

  1. Que dire sinon que je suis entièrement d’accord avec toi sur la plupart des points ! Merci Fred de nous faire vivre le Mix de l’intérieur.

  2. Des intranets en flash ??? Ca existe ça ? Non parce que, sauf vraiment si c’est bien fait mais je suis sur que tu ne parles que des sites qui sont bien faits, je ne mettrai jamais les pieds sur un truc pareil. Ca fait peut-être partie des points qu’il faut aborder à l’entretien d’embauche « Nous sommes d’accord pour la rémunération. Maintenant parlons sérieusement: votre intranet il utilise Flash ? »

  3. Absolument d’accord avec l’avant-dernier paragraphe, car je suis développeur d’applications d’entreprises, et que la mise au point d’une UI « correcte » Web ou Winforms représente un travail phénoménal. Grâce à XAML, fini de se bagarrer avec CSS (dans le cadre d’applications Web), et Winforms (avec lequel de bons résultats graphiques sont difficiles et longs à obtenir). Et à ce titre, XAML est plus que bienvenu. En revanche, une petite précision technique : XAML est un langage descriptif basé sur XML pour décrire l’interface utilisateur. Tout comme XUL. Bien qu’il puisse être généré à la volée, ce dernier n’est absolument pas produit à partir de C#, PHP ou autre, n’a absolument rien à voir avec le CLR. Il est possible de manipuler XAML à l’aide de tous ces langages par programmation et non de manière descriptive, grâce à un DOM (Document Object Model) particulièrement cohérent. En outre, le moteur de rendu XAML est particulièrement performant. La valeur ajoutée de XAML se situe aussi dans la productivité de développement. Une fois Blend (par exemple) maîtrisé, il me semble (je dis « il me semble », car il me manque un peu de pratique) que le temps de développement est fortement réduit. Le temps nous le prouvera… D’ailleurs, j’y retourne.

  4. Le champ de bataille choisi est donc bien celui de l’entreprise, là où .net est présent aujourd’hui et où la valorisation des contenus vidéos est un vrai sujet. Pour le reste, je te suis à 100% sur les enjeux d’appropriation que cette annonce va susciter, rajoutant à cela que ce que d’ajouter des ressources créatives n’est pas une décision neutre, tout autant que celle de devoir apprendre aux développeurs en place à faire autrement. Ce dont tu parles, c’est d’un autre métier ! Bref, si MS semble simplifier le coût d’adoption techno, le changement n’en reste pas moins important à décider et à mener.

  5. Certains développeurs sont un peu limité en ergonomie/design :D Par ailleurs, Zend Framework n’est pas encore au point, il faut mieux parler de Symfony (le plus carré) ou CakePhp (le plus accessible) :)

  6. Le point important de ton post me parait être au tout début de ce dernier :  » la capacité d’adoption de toutes ces nouveautés par le marché est limitée « . En effet, en admettant qu’on travaille pour des utilisateurs et pas juste pour notre banquier, on devrait peut-être se poser un moment et demande rà l’internaute-lambda ce qu’il souhaite/imagine/espère du web 2.0 (et des suivants..). On parle en ce moment énormément de l’interface de JOOST, de l’ergonomie des digg-like, de la VoIP qui se banalise.. mais quel serait réellement le % d’internautes qui savent ce que c’est ? Le grand défi, à mon sens, n’est plus d’avancer mais de resouder les wagons l’un à l’autre pour continuer à avancer ENSEMBLE.

  7. Pas d’accord avec toi ropib ! Pourquoi serait-il inconcevable d’envisager l’intégration de vidéos au sein d’un intranet ? Oui un intranet Full Flash ça peut exister et avoir su sens surtout si l’on exploite les possibilités didactiques offertes par l’interactivité pour plébiciter l’usage et la manipulation de ces outils en entreprise. Après tout dans des environnements ou l’on maitrise les postes clients, pourquoi ne pas songer à des outils de gestion full RIA !!! Quand je pense que la prochaine mouture de SAP repose entièrement sur Flex on est en droit de se poser la question.

  8. en effet flash a mauvaise réputation en entreprise, mais c’est surtout considéré comme inutile ! Ma première démo d’un drag & drop pour un intranet à un client c’est soldé par un ‘hum’ : on fera ca avec des listes déroulantes multiples et des boutons ‘<-‘ et ‘->’. Et là je ne parles pas des applications grands systemes (faites F18, tapez l id Z42X, …) Non les interfaces riches n’ont d’intérêts que pour les sites accessibles au public (d’un point de vue d’un manager dans une grande boîte (genre CAC40)). A moins que quelqu’un me contredise.

  9. Je te contredis wluigi :) dans l’équipe où je suis, on développe une application en Flex pour un grand groupe (plus de 2000 jours homme), et les premiers retours sont très bons. Mais il faut voir l’utilisation qui est faite : pas de drag&drop, utilisation très simple (mais pertinente) des « composants riches ». Et le client fait *wahou !*. La morale : pourquoi faire compliqué lorsque l’on peut faire simple ? Les effets *wahou* ne sont pas faits pour les applications d’entreprise, mais Flash/Flex a bien d’autres avantages pour percer en entreprise.

  10. Bon quelque petites précisions… Tout d’abord le .NET Framework n’est pas payant ni le plugin pour lire le XAML. Le C#, ironpython, vb.NET, PHP génére du langage précompilé (pas compilé en assembleur mais en CIL) qui est executé a la volé dans l’environement .NET grace au CLR. Concernant tes inquietudes au niveau fonctionnalité ca n’a pas lieu d’etre. Le projet mono ( http://www.mono-project.com ) qui refait le .NET framework en open source a déjà implémenté de nombreux language sans problème majeur (Boo,Nemerle, c#, vb.NET, python,ruby.net…). Tous ces langages ne sont pas forcement complets. En gros, le XAML est un remplacant du HTML plus complet et finalement derriere on retrouve les meme chose qu’en ASP.NET (avec quelque language de plus). Par contre on gagne en nombre de plate forme/browser supporté. J’attends de voir la réplique de Mono qui pourait etre un XUL + Mono. Bref, l’interet de Silverlight est d’avoir enfin débarassé le web du HTML qui devient vraiement trop vieux/ peu évolutif/ dificilement maintenable/… Apres il essaye de ratisser large et de ne pas avoir a tous réapprendre en maximisant le nombre de language suporté. Personnelement, je ne crois plus depuis longtemps a Flex. Mias par contre il faudra surveiller de pied ferme, la communauté du libre ( mono, RoR, XUL, …) et google qui a aussi des moyens de faire mal.Google web toolkit n’etait qu’un début je pense… Chez les grands comptes, après c’est un autre débat… Les utilisateurs en ont marre des systemes aussi moche que l’AS400. SAP est roi et la peu de chance de faire des ERP full web ( meme si openbravo est pas mal). Je crois plutot aux intranets qui vont avec et la on voit surtout le coté focntionnel et la video n’apporte pas grand chose.

  11. duff, stp peux-tu détailler pourquoi tu ne crois plus depuis longtemps à Flex ? j’étudie en ce moment les différentes technologies d’interfaces riches, dont évidemment WPF et Flex, et pour le moment je ne crois pas plus que ça en WPF, et je miserai plus sur Flex. Silverlight ne m’a pas du tout convaincu, mais il n’en est qu’à ses débuts c’est certain oui…

  12. Tout simplement car pour la version 1.0, il s’agit simplement de balise interprété coté client. Je travail dans une boîte d’édition et nous utilisons notre propre framework. La base et réalisé par un ensemble complexe de xsl. J’ai donc réalisé trés rapidement (une demie-journé) un plug-in qui fait que les dévelloppeurs, sans aucunement changer leurs habitudes, génére du HTML, du XAML ou les 2.

  13. Je reprend les commentaires de certains sur plusieurs points, mais suis en desaccord sur d’autres.

    – concernant silverlight et la techno XAML en general, ce n’est bien sûr pas payant, tout comme .NET en general. A la rigueur, on peut considerer que les outils de developpement sont eux payant (Visual Studio 2005, gamme Expression ) , mais il est possible de trouver des alternatives assez convaincantes (voir chez mono pour l’open source, la beta d’Orcas qui marche tres bien chez Microsoft, ou les versions Express de Visual Studio, elles aussi gratuites. Par contre, Expression Blend et autres n’ont pas pour le moment à ma connaissance de versions gratuites.

    – HTML vs XAML? Perso je n’y crois pas, car XAML est un langage de definition d’interface, alors qu’initialement, HTML est un langage de definition de contenus. Autrement dit, il n’est pas forcement optimal de faire du contenu en XAML (ca risque de devenir tres verbeux) et j’attend, par exemple, un editeur silverlight Wysiwyg qui fabrique du XAML (faisable, vous me direz)
    Dans tous les cas, on peut facilement faire de la conversion XAMLXHTML pour du texte simple, ce qui est l’important ;)

    – silverlight 1.0 tourne en javascript pour la partie client programmable, avec un plugin compilé pour lire/interpreter le XAML, et raccorder le tout au javascript créé par le programmeur. En 1.1, exit le javascript, tout est en .NET

    – Le projet Mono consiste à creer un framework .NET open source sous Linux est Windows. Vu la conception de .NET, ca veut dire que comme pour java, un programme compilé sous Windows (à l’aide du compilateur Mono ou Microsoft, on s’en fiche) tournera sur les plateformes .NET Mono ou Microsoft sous Linux, Mac OS ou Windows indifferement.
    Aux dernieres nouvelles, la plateforme Microsoft garde un avantage en vitesse, mais bon, y’a encore du boulot. A noter que le projet Mono est indirectement sponsorisé par Microsoft, signe que même à Redmond, les mentalités evoluent :)
    Donc Silverlight chez Mono, ca s’appelle Moonlight, et c’est equivalent à Silverlight 1.1 (la version .NET)
    Ca veut dire que ca fait exactement la même chose que silverlight, avec les mêmes fichiers en entrée, mais sous Linux, alors que silverlight n’existe actuellement que pour Firefox et IE, plus un navigateur MacOs dont je ne me souviens pas le nom, malheureusement.

    En attendant, il manque encore la TextBox à Silverlight 1.1 , ce qui est assez facheux. Il est toutefois prevu par Microsoft que ca s’arrange, de toute façon, on est encore en alpha :)

  14. Je développe un intranet mondial en Silverlight actuellement et, paralellement, je fais du Flex / Flash pour le plaisir.

    J’ai remarqué que Silverlight repose sur le framework DotNet 3.5 qui est relativement stable et éprouvé alors que Flex s’appuie sur un framework 1.0 qui vient sortir.

    Malgré cela, n’oublions pas que lecteur Silverlight en est à sa première version alors que la version 10 du player Flash va bientôt sortir …

    Donc pour l’instant, pour ce qui est de l’intéractivité et de l’innovantion, Flex conserve une longueur d’avance pour moi …

  15. Bonjour, article très d’intéressant.

    Pour moi le frein majeur à l’expension de silverlight c’est l’installation du plugin chez les grands comptes. Je me rappel qu’a l’epoque il y avait le même problème avec Flash, aujourd’hui Flash est considéré comme un élément de base. Tant que ce ne sera pas la même chose avec silverlight il ne pourra pas vraiment percer l’avance de Flash. Qui travaillant aujourd’hui dans le web ne pleure pas de devoir encore rendre son site compatible IE6 ? Mes clients me demandent tout le temps s’il faut installer des activeX pour utiliser notre progiciel… Une page faisant plus de 100 ko au démarrage est souvent un gros problème pour certaines boites déployés dans le monde entier…

    De ce point de vue on remarque que microsoft a l’intention d’avancer très vite en mettant de base silverlight dans windows 7. Comme on le sais 99% des grands comptes ont gardés windows XP sur leur réseau il y a de fortes chances qu’ils passent directement à windows 7.

    Pour moi, un des autres freins à silverlight est qu’il nécessite des compétences qui ne sont pas forcement encore sur le marché (français tout du moins) : Il faut un profil designer pour le vectoriel sachant développer un minima et /ou comprenant le XAML (un animateur flash ayant des connaissances en dotnet et xaml en gros)… Le problème est qu’un designer est aussi bon en code qu’un développeur bon en design (je caricature mais je suis pas loin …). Ajoutez à cela que le nombre de formation est encore trop accès code (en général 1 jour design pour 3 jours de code).

    De mon coté j’attends plus avec impatience de voir mes clients sous IE7 que voir silverlight installé chez mes grands comptes. Une des chose qui m’interresse le plus dans silverlight c’est la possibilité de faire du vrai push serveur car le système déconnecté du web commence à montrer des limites.

Laisser un commentaire