Apache Adobe Flex TutorialTutoriaux Adobe Flex & AIR en Français

Interview avec Michaël Chaize – Flex et le monde de l'entreprise

Il y a deux semaines, j'ai publié un billet nommé "Point important sur les décisions d'Adobe sur le futur de la Flash Platform et de Flex" sur flex-tutorial.fr, pour partager mon ressenti à chaud sur les dernières décisions prises par Adobe. Un article qui a pas mal circulé parmi les développeurs mais aussi dans certaines SSII voire lu par certains clients (2500+ vues en quelques jours). Au delà de cela, un nombre important de commentaires, tous très intéressants qui reflètent bien l'état d'esprit actuel des développeurs je pense.

Depuis ce billet, Adobe a mis à jour son annonce "Your questions about Flex" (http://blogs.adobe.com/flex/2011/11/your-questions-about-flex.html) pour répondre aux nombreuses questions que ce billet a soulevées. Avec notamment une nuance sur le fait que HTML5 était une bonne solution pour faire de l'applicatif en entreprise, l'annonce qui avait le plus surpris au départ.

On en a aussi appris davantage sur le passage de du SDK Flex en Open Source avec notamment l'ajout de BlazeDS, des derniers composants Spark (architecture Flex 4) manquants et du compilateur Falcon ultra-rapide pour Flex 5. Un point qui a aussi été survolé est la cession des outils de tests à la communauté. Cela assure que l'intégration de patchs ne brisera pas le système, même s'ils n'ont pas une couverture de code maximale.

Depuis ce billet, Michaël Chaize (Adobe evangelist) a aussi publié ses impressions dans un billet nommé "Flexcursion with Apache":

http://www.riagora.com/2011/11/flex-is-open/

Une vision intéressante que j'ai voulu approfondir sur flex-tutorial.fr.

Salut Michaël, pour ceux qui ne te connaissent pas, une petite présentation sur ton parcours chez Adobe?

Salut Fabien. Après avoir travaillé en agence interactive en tant que développeur Flash, j'ai créé avec un associé une société d'édition de logiciels autour du format PDF. Nous étions un partenaire privilégié d'Adobe que nous avons rejoint en 2006 au moment de la sortie de Flex 2 et de la création de la communauté des Tontons Flexeurs. Je travaillais dans l'équipe avant-vente pour accompagner les comptes du CAC40 dans leur stratégie de mise en place de RIA. En 2010, Ben Forta m'a proposé de représenter la plateforme Flash en Europe au sein de l'équipe des Developer Evangelists. Depuis je travaille avec Greg Wilson et Christophe Coenraets entre autres pour évangéliser Flex auprès des développeurs Java, PHP et auprès des directions informatiques.

La création d'un back-end est un cas classique d'utilisation de Flex. Celui-ci est le plus souvent "masqué" derrière un intranet. En ajoutant à cela des données confidentielles et un accès sécurisé, on obtient souvent des applications avec peu de visibilité externe. Penses-tu qu'il y a une partie cachée de l'iceberg Flex en entreprise?

C'est certain ! Je me souviens des premières campagnes de promotion de Flex. On expliquait que les interfaces riches optimisaient le parcours des utilisateurs et que donc Flex aurait du sens sur un site de eCommerce par exemple (l'exemple du FlexStore illustrait cette promesse). Mais au final, c'est toujours le marché et la communauté qui orientent les usages d'une technologie. Un besoin est rapidement né dans le milieu des applications d'entreprise : la possibilité de rapidement concevoir et déployer des interfaces riches connectées à un, voire plusieurs services distants. Les développeurs Java en l'occurrence n'avaient pas de solution viable. La technologie Swing, les JSF, ou le JavaFX n'étaient pas convaincantes à cause de leur manque de maturité et de productivité. Flex est rapidement apparu comme la technologie la plus naturelle pour industrialiser le développement d'interfaces. Je dirais que 90% des applications Flex sont sur l'intranet de l'entreprise, parfois exposées à des partenaires ou clients extérieurs sur l'extranet. Beaucoup d'interfaces Flex sont lancées pour adopter une méthodologie de développement d'applications recentrée sur les besoins des utilisateurs et ainsi pallier aux manque d'ergonomie et de bon sens des interfaces proposés par des éditeurs. SAP par exemple doit proposer une interface par défaut qui doit répondre à un maximum de métiers et de profils utilisateurs. Au final, la méthode consiste à présenter tous les champs disponibles dans la base de données et de laisser l'utilisateur jongler avec ces informations. C'est une approche "system-centric". Flex permet d'industrialiser une approche "user-centric" en développant rapidement des interfaces qui répondent aux besoins métier des utilisateurs et en incluant le Design au coeur du processus de développement.

Dans ton billet tu parles d'un décalage de 2-3 ans en entreprise en plus des 3-5 ans annoncé par Adobe pour que les technologies HTML5 rattrapent Flex et Flash Player. Les périodes de migration sont effectivement longues, notamment sur le renouvellement des postes (XP toujours très présent). Penses-tu que la poussée HTML5 peut influencer ces temps de migration, vers Windows 7 + IE9/10 par exemple?

Je ne pense pas. Un grand compte ne migre pas vers un nouvel OS pour accueillir une nouvelle technologie web. Elle doit avant s'assurer que tout son "legacy", toutes ses applications existantes fonctionnent correctement sous un nouvel OS ou un nouveau navigateur, vérifier les procédures d'audit, les mécaniques de déploiement, les compatibilités logicielles, etc… Une migration touche le quotidien de dizaines de milliers d'utilisateurs, un plantage n'est pas permis. Dans le navigateur, je suis encore fasciné par le nombre d'activeX utilisés sous IE, du nombre de sites développés en interne avec des frameworks différents, des technologies différentes, etc… Mon conseiller bancaire par exemple passe régulièrement d'un navigateur à un écran mainframe, à du client-server et à un autre écran VB pour effectuer une simple opération comme un virement.

Les grands comptes sont aujourd'hui le résultat de plusieurs fusions et acquisitions et cela se ressent au niveau du socle informatique. Plus qu'un choix technologique comme Flex ou HTML5 , il faut entreprendre un chantier de refonte des postes utilisateurs sur un même socle technique, et exposer toutes les anciennes applications sous forme de service. Il faut aussi avoir conscience que HTML continuera d'évoluer, ne va pas rester figé dans sa forme actuelle, même le langage JavaScript évoluera, ainsi que les versions de navigateurs. Dans 5 ans, on parlera certainement d'IE12 sous Windows 9.

C'est maintenant la communauté des flexeurs avec le soutien d'Adobe qui va préparer la suite et notamment la version 5. Un gros break avait été fait entre Flex 3 et 4 pour prévoir la nouvelle architecture, notamment au niveau des skins. Ce break s'est révélé difficile pour certaines structures qui sont restées en Flex 3 mais décisif pour le résultat que l'on peut obtenir avec Flex pour mobile. Penses-tu que Flex 5 doive apporter un nouveau changement ou "simplement" apporter des évolutions pour répondre aux demandes des utilisateurs?

Je pense en effet que l'architecture Spark était un mal nécessaire, et pas seulement pour permettre la migration sur mobile. Le fait de découpler le design d'un composant de sa logique offre beaucoup plus de liberté d'expression et permet de mieux structurer son code. Certains clients sont restés en Flex 3 mais la migration vers Flex 4 peut être douce. J'ai rencontré dernièrement une banque qui avait écrit un script en Python pour faciliter et achever une migration en deux jours. Si l'on suit bien le guide de migration, l'effort n'est pas immense.

Je pense que Flex 5 doit déjà assurer la migration de tous les composants vers Spark et consolider l'ensemble du framework pour qu'il soit encore plus performant. Flex est encore récent sur mobiles, il y a du coup encore beaucoup de pistes à explorer pour innover et améliorer le framework.

La communauté Spoon qui sera en charge de Flex semble assez jeune mais pleine d'espoir. Combien de temps va durer la tutelle d'Adobe, cruciale pour le bon démarrage de cette initiative?

Spoon a un an. C'est une jeune initiative mais les membres actuels sont des développeurs Flex très expérimentés. Cette alliance s'appelle Spoon parce qu'ils ne pouvaient pas faire de Fork. Le deal entre Adobe et Spoon étaient de les laisser améliorer Flex dans une branche séparée et de recouper tous les 6 mois pour faire notre marché. C'était un premier pas vers l'implication de la communauté dans Flex, mais le modèle n'était pas efficace.

Dans le même temps, nous avons fait l'acquisition de Day Software, une société qui a développé un CMS d'entreprise basé sur des solutions Apache. C'est grâce à leur expérience que l'idée de se rapprocher d'Apache est née. Du coup la tutelle sera partagée entre Adobe, Spoon et aussi des grands éditeurs et clients qui ont des projets critiques développés en Flex et qui s'annonceront au fur et à mesure. L'objectif n'est pas de donner Flex à la communauté, mais juste de lui permettre de contribuer et d'influencer la roadmap. Aujourd'hui, Adobe décide des nouveautés, les développe dans le secret pour les révéler à Max ou 360Flex par exemple, et décide de quels bugs sont prioritaires. C'est ce type de gouvernance qui va changer.

Lors de ta dernière session Connect, tu disais que les développeurs RIA Flex d'aujourd'hui seraient sûrement les développeurs RIA les plus à l'aise avec HTML5 de demain. Je partage cet avis. Pendant ces prochaines années, à quelles technologies devraient s'intéresser les développeurs Flex?

Il est impossible de réduire les compétences d'un développeur de RIA à un langage. C'est une culture, un savoir-faire, qui va de la sensibilité au design jusqu'à l'architecture d'une application côté client. Les développeurs doivent suivre les tendances et s'intéresser de près ou de loin à plusieurs technologies à la fois. C'est difficile de miser sur une autre technologie aujourd'hui, on ne peut que constater la prédominance de JQuery sur le web. J'espère qu'il évoluera avec plus des fonctions pour les applications d'entreprise. L'autre tendance à surveiller est la cross-compilation en natif pour les applications mobiles.

Dans l'avenir, Flex devrait-il devenir un peu comme J2EE, une solution uniquement axée entreprise pour des applications de gestion lourdes et complexes à maintenir? Penses-tu que Flex deMVvrait devenir une technologie de "niche"?

C'est un peu caricatural mais je comprends ce que tu veux exprimer. Il y a tout de même des systèmes J2EE qui sont légers et simples à maintenir, mais les architectures J2EE sont souvent anciennes et cumulent des couches qui sont plus ou moins bien conçues. Aucune technologie n'est à l'abri. En Flex, il suffit de mal implémenter un framework MVC pour arriver à une architecture lourde et difficile à maintenir. Si l'on regarde l'évolution des frameworks MVC Flex, l'injection de dépendances n'est pas arrivée de suite. En ce moment, des frameworks comme Gravity introduisent dans Flex des concepts OSGi.

Je pense que la grande différence entre Flex et J2EE, c'est le momentum. J2EE a facilité l'exposition de services (le mouvement SOA), la maintenance d'une logique métier et la couche d'accès aux données. Les interfaces riches sont encore en phase de démarrage chez les grands comptes car elles n'induisent pas qu'un choix technologique. Flex est déjà très mûr par rapport aux attentes du marché. Si les RIA mettent du temps à s'imposer en standard dans le monde de l'entreprise, c'est parce que cela impacts l'organisation des équipes informatiques et chamboule le modèle classique MOA/MOE pour le bien des utilisateurs. Flex ne va pas devenir une niche mais au contraire s'imposer de plus en plus comme la solution la plus mature pour construire une stratégie user-centric. L'arrivée des tablettes en entreprise va accélérer le mouvement car une interface mal conçue sur ces appareils conduira forcément à un échec et à un refus de la part des utilisateurs. Sur le desktop, ils sont assez "résignés" et acceptent des interfaces "system-centric" mal conçues.

Pourquoi Adobe n'a pas ciblé le monde de l'entreprise plus tôt? Notamment au niveau du support des systèmes de build très répandus en entreprise comme Maven qui ont toujours été un peu laissés de côté?

Je pense que Macromedia a senti en premier que le web deviendrait une plateforme applicative. Le tort a peut-être été de penser que cela s'appliquerait à des applications B2C et non pas des applications B2E. A leur décharge, j'imagine qu'il est plus simple de communiquer sur des applications publiques B2C, cela facilitait la communication autour de Flex et accélérait son adoption. Les autorisations sont très difficiles à obtenir pour montrer des applications d'une application de trading par exemple.