Comment adresser efficacement toutes ces plateformes sans multiplier par autant les temps et coûts de développement ?

1. Déporter l’intelligence côté serveur : En rendant votre application mobile cliente d’un service hébergé, vous diminuez substantiellement la quantité de code à porter d’une plateforme à une autre.
2. Utiliser des frameworks multi-plateformes : PhoneGap ou encore Sencha facilitent la création d’une application basée sur des standards web (HTML5, Javascript, CSS3) permettant une écriture unique pour une diffusions sur plusieurs plateformes.
3. Créer des habillages trans-plateformes : Les tailles d’écran variant sensiblement entre les plateformes mais aussi dans une même famille, créer des habillages dynamiques, où les éléments se placent et se dimensionnent les uns par rapport aux autres évite la tâche fastidieuse d’adaptation de l’habillage pour chaque taille d’écran : il peut y en avoir plus de 200 !

Devolia accompagne ses clients et ses partenaires dans la conception et la réalisation d’applications mobiles connectées, sur toutes les plateformes

C’est par cette phrase un tantinet sévère que Steve Jobs s’est adressé au monde la semaine dernière au sujet de Flash, d’HTML 5 et de sa vision quant à l’avenir du web mobile.

Le débat était déjà très animé depuis la sortie de l’iPhone et son non-support volontaire et assumé de Flash. Ranimée, la polémique est l’occasion de faire le point sur les avantages et les inconvénients des 2 technologies (souvent plus complémentaires que concurrentielles) et de leur impact pour la communication d’Entreprise.

• Flash est le mieux supporté : le taux d’installation de Flash sur les ordinateurs tourne autour de 95%, suivant les versions. Autant dire qu’il est le plug-in le plus présent pour les contenus animés, bien devant Silverlight par exemple. Forcer un utilisateur à installer un plug-in, c’est se couper des visiteurs en entreprise qui ne disposent pas de droits suffisants sur leur ordinateur.
• Flash est le moins bien référencé : c’est toujours et encore la bête noire de Flash. Malgré quelques annonces de la part de Google, des contournements plus ou moins performants, un site en Flash restera toujours moins bien référencé dans les moteurs de recherche qu’un site en HTML. Cela compte pour des sites commerçants, ou des marques à la notoriété en cours d’établissement.
• Apple règne sur le web mobile : que ça nous arrange ou non, force est de constater la domination d’Apple sur le web mobile. Les ventes spectaculaires de l’iPad aux Etats-Unis confirment la tendance. Il est donc important de jouer avec eux pour avoir une chance d’exister en mobilité.
• HTML 5 sera adopté en entreprise à plus de 90% dans 5 à 10 ans : alors que les navigateurs actuels supportent HTML 5 dans une partie seulement de ses possibilités, l’adoption de ces navigateurs en entreprise va prendre du temps. Combien d’entre-vous sont encore sous Internet Explorer 6 ? Il est pourtant sorti il y a près de 9 ans…
• Apple va bientôt contrôler toutes les tailles d’écran : téléphone, tablette, ordinateur portable, ordinateur de bureau… la suite est évidemment le téléviseur. Alors que les constructeurs historiques de télés peinent à s’entendre sur un format commun de widget pour la rendre un peu plus interactive, Apple risque rapidement de jeter un nouveau pavé dans la marre. Ceux qui auront déjà parié sur les technologiques Apple auront un train d’avance
• HTML c’est standard : édicté par le W3C, le consortium du web, HTML est certainement le standard le plus utilisé pour l’affichage de données numériques. Sur le web, les téléphones mais aussi les set-top-box ou encore les interfaces de GPS, écrans intégrés à votre électroménager. Se baser sur un standard est l’assurance d’une large adoption.

1 partout la balle au centre ? S’il faut conclure à ces faits, c’est en insistant sur la réflexion et l’analyse nécessaires en amont de chaque projet, portant sur sa cible, sa pérennité, ses objectifs. Flash demeure la référence de l’animation sur le web bien que son avenir sur les écrans Apple est très incertain. Une fois n’est pas coutume, il n’y a pas ici de technologie miracle couvrant tous les besoins, mais bien des choix adaptés à chaque problématique.

Notre expertise

Devolia accompagne ses clients dans la conception de dispositifs de communication multi-canaux (web, mobile, print) et multi-technologiques (un serveur pour de multiples clients : HTML, Flash, iPhone…)

Là où tout n’est que process, certifications et ré-assurance, comment pourrait-on adopter quelques lignes de codes – sans dire qu’il faut souvent les compiler soi-même – issues de mystérieux barbus solitaires, éparpillés au-travers du monde ?

Ce billet s’adresse à tous les chefs de projet en agence à qui on a dit un jour « non PHP c’est pas pro [...] code-le en .NET« , à tous les développeurs à qui on a assuré que « Oracle c’est plus secure que MySQL pour le e-commerce » ou encore à tous les chargés de communication qui ont dû, trop de fois, sacrifier leurs projets « [...] que si on le sort, Stratégies et CB News ne parleront plus que de nous » sur l’autel de l’immobilisme et du principe de précaution poussé à outrance, valeurs chères à certains DSI.

10 arguments, ni plus ni moins, pour réconcilier corporate et open-source.

1. Ça marche : trivial ? Non, et c’est parfois utile de le rappeler. Les systèmes open-source fonctionnent, et bien. Les grands hébergeurs vous le diront : haute disponibilité rime avec UNIX. Les administrateurs reprendront en cœur qu’ils n’ont pas redémarré leur Apache depuis le passage à l’euro et les développeurs que si PHP est né comme un langage de script, il sait aujourd’hui être audité en production pour détecter les goulets d’étranglement ou encore piloter une qualité de service.
2. C’est performant : WordPress – le moteur open-source qui anime ce blog – nous dit que le code est de la poésie. Et les codeurs n’hésitent pas à passer des nuits sur chaque routine pour diminuer sa consommation de ressources. Résultat ? Nombre de grands acteurs ont choisi des solutions open-source pour leur performance. FFmpeg transcode plus vite que vite. PHP – langage interprété à l’exécution, rappelons-le – rivalise avec des binaires CGI – compilées dans le dur -.
3. C’est sécurisé : au diable l’argument « tout le monde peut trouver des failles« . Car c’est bien pour ça qu’elles sont rapidement comblées. La communauté s’est même imposée une éthique de la révélation des failles au porteur du projet et ne la diffuse généralement pas avant sa résolution. Nombre de mises en garde ont été transmises aux éditeurs de solutions propriétaires pour les avertir de failles majeures, mises en garde restées lettres mortes.
4. C’est pas cher : attention cependant à ne pas confondre ouvert et gratuit. L’essentiel des solutions open-source sont gratuites. L’utilisation commerciale de certaines exige une licence. Néanmoins, mis bout-à-bout l’ensemble de la chaîne logicielle nécessaire à déployer un service web, il y a nécessairement des gains financiers à l’arrivée. L’open-source, solution anti-crise.
5. C’est à la pointe du progrès : ils ont beau travailler sur des PC éventrés, sur des Linux en mode texte, force est de constater que les codeurs open-source arrivent généralement à devancer ou tout du moins se maintenir au niveau des éditeurs. Presque chaque outil commercial, d’autant plus sur le web, a son pendant ouvert.
6. C’est ouvert : et alors me direz-vous ? Et bien ça permet par exemple de l’adapter facilement à un besoin spécifique, d’ajouter une fonctionnalité, et pourquoi pas… de contribuer soi-même à la communauté autour du projet !
7. C’est connu de tous : « Cherche programmeur Cobol / Fortran / Turbo Pascal« . Votre DRH n’a qu’à bien se tenir. Vous voulez pérenniser votre code ? Valoriser votre patrimoine logiciel ? L’open-source, c’est aussi la garantie de trouver une légion de programmeurs capable de reprendre le projet là où il s’est arrêté.
8. C’est bien documenté : Très actifs sur le web, il y a de grandes chances qu’un geek ait rencontré le même problème que vous, et qu’un autre geek l’ait aidé, sur l’un des nombreux forum qui traitent des projets open-source. D’ailleurs, n’oubliez pas de lire le manuel, ils sont généralement d’une incroyable qualité.
9. Même les plus grands s’en servent : Si les 8 arguments précédents n’ont pas fonctionné, passez au name-dropping : Facebook. Wikipedia. YouTube. Netvibes. Des nains du web ? Pour l’anecdote – si votre DSI aime particulièrement un éditeur de Redmond aux États-Unis – Hotmail serait hébergé sous un système UNIX.
10. C’est révolutionnaire : C’est une posture, certes, mais à l’heure où le bling-bling est montré au doigt, où l’on pousse son 4×4 à la décharge pour enfourcher un Vélib’, pourquoi ne pas faire son effet sans pour autant porter un t-shirt du Che au comité de direction ?

• Le Web 1 nous a apporté le signal
• Le Web 2 nous a apporté le bruit

Vite, un filtre ! Pour devenir le nouveau Mark Zuckerberg, trouvez les valeurs idéales de R, R1, R2, R3, R4 et C !

Vous avez une heure.

Ultra externalisation contre ultra disponibilité

Le SaaS, c’est fantastique, tout le monde en convient dans la presse, sur les blogs, dans les conférences. Mais ces beaux projets survivent-ils au passage par les DSI ? Rarement.

Que reproche-t-on aux architectures consommant des services tiers ?

• Leur fragilité en terme de disponibilité : en multipliant les sources de services, vous multipliez les probabilités distinctes de panne : la probabilité de panne de votre système est le produit des probabilités de panne de chacun des services que vous utilisez (sans compter la probabilité de panne intrinsèque de votre propre application).

• La difficulté de la montée en charge : à moins d’être éditeur dudit service, impossible de garantir la mise à jour hardware des machines hébergeant l’application pour supporter une montée en charge.

• L’impossibilité pratique de réaliser une redondance d’un service tiers : aucun éditeur ne propose un service avec une syntaxe commune : pour basculer sur un autre éditeur en cas de panne, il faut savoir consommer autant d’API externes différentes.

• L’impossibilité pratique de définir et encore moins de garantir une qualité de service : c’est la qualité de service la plus basse des services tiers qui définit la qualité de service globale du service.

• Leur fragilité en terme de pérennité : la mort d’un service tiers entraîne la mort de votre application.

• Leur fragilité en terme d’opposabilité : pas de conditions générales d’utilisation standardisées et une difficulté à prouver la défaillance d’un service donné pour faire valoir sa responsabilité en cas de panne globale de l’application.

En somme, les éditeurs de service manquent d’un cadre légal et pratique mais surtout d’une manière standard (sous forme de flux par exemple) d’éditer leur garanties de services et condtions d’accès. A quand un consortium internationnal des éditeurs de SaaS ?

Aux éditeurs de clients (resp. de serveurs) des années 90, les années 2010 vont-elles introduire des éditeurs d’interfaces riches (resp. de sevices) ?

C’est en tout cas la sensation que m’a donnée la conférence de Mike Potter, qu’il tenait hier soir à Paris. Mike a immédiatement insisté sur les capacité de Flex / AIR a consommer nativement des flux XML, JSON et même de transtyper / transmettre des objets natifs Java, PHP, .NET entre back-end et front-end. On voit rapidement l’intérêt de la chose : rendre protocolaire (à l’image du client / serveur) l’accès à tout service (n’est-ce pas là le principe du SOA ?) et développer vite des interfaces qui consomment ces services.

Les éditeurs de service font donc leur grand retour, en s’affranchissant de choix technologiques encore incertains sur le front-end, ne mettant à disposition qu’une API externe. Sans retomber dans le fantasme de SOAP / OASIS et une improbable interopérabilité entre fournisseurs de services, la capacité à proposer des interfaces riches consommant des services (mais surtout des mashups les mettant en relation) va être grandement stimulée.

Restent toutefois à résoudre les limites intrinsèques du SOA : comment empêcher / limiter simplement la possibilité d’utiliser un client non signé pour un service donné ? L’open-source ne pouvant être généralisé pour les applications commerciales, les éditeurs ne souhaitent pas nécessairement que des clients « tiers » puissent se connecter à leur service, surtout si leur modèle économique repose sur l’affichage de publicités par exemple (il suffirait d’omettre leur implémentation dans le client !).

Ajoutez donc une couche

Du plus bas niveau jusqu’au plus haut, l’informatique fonctionne selon des modèles de couches empilées ou interconnectées par des services. Les applications riches n’inventent rien de plus qu’une réorganisation de ces couches, en plaçant d’avantage de transport entre les couches métiers, données et présentation. À savoir une pile touchant au bas niveau venant s’intercaler aux plus hautes couches des applications.

Conséquence immédiate de ce chamboulement : l’apparition de contraintes et de notions sagement reléguées aux DSI et à leurs amis au coeur de nos applications : ping, QoS, mode connecté… les applications riches vont donc faire travailler ensemble les hommes des réseaux avec les équipes de développement logiciel. L’objectif étant de définir et de garantir une qualité de service pour chacun des produits logiciels.

À l’heure du tout P2P, le client-serveur prend sa revanche mais cherche encore ses langages

Les applications riches ont donc réintégré un modèle client-serveur malmené entre les couches de présentation, métiers et données. Depuis, la guerre des langages est ouverte pour imposer un langage back-end et front-end, et le support de leur communicaiton.

Le front-end a évidemment remis Javascript et le DOM au coeur des enjeux. Cependant, les frameworks riches des éditeurs apportent chacun leur langage (Silverlight et les langages .NET, JavaFX et Java, Flex et Actionscript) aussi le choix devient maintenant pluriel.

Le back-end est aussi le théâtre de luttes entre les langages ancestraux (PHP, Perl) et les nouveaux venus (Ruby). Le choix de la nouveauté est ici essentiellement politique, étant tout aussi performant, plus productif et plus robuste de maintenir les équipes dans leurs langages back-end de prédilection, tant que ceux-ci savent communiquer avec l’extérieur !

Cette communication avec l’extérieur – quelques années auparavant – chacun l’aurait naturellement associée avec XML. Mais voilà que JSON grignote son hégémonie. La raison est sa légereté et son interprétation native par Javascript… au détriment de nombreux apports de XML ! Attention ici au nivellement technologique par le bas !

Révolution de coton

En résumé, l’architecte d’applications riches doit maintenant composer avec les contraintes réseaux mais s’offrent à lui des opportunités plus souples en terme de langages et d’échanges de données. Charge à lui de faire les choix les plus judicieux pour une application homogène et pérenne !

Ressources humaines

Le recrutement est le premier domaine où une normalisation des flux est attendue : certains néo-sites de recrutement comme Moovement proposent déjà d’agréger vos publications d’offres à partir de flux XML : cependant, un travail manuel est à opérer systématiquement, aucune norme ne venant cadrer les champs de ces flux.

L’idée serait donc de proposer une norme, sous forme de DTD basée sur XML, pour la publication d’offres d’emploi, mais aussi une norme pour systématiser les Curriculume Vitae des candidats ! Libre à ces derniers d’y adjoindre une couche de présentation à l’aide d’un XML Stylesheet.

De telles normes viendraient progressivement simplifier le travail des sites de recrutement, et optimiser le « match making » entre offres et demandes. Elles recentreraient également le débat des sites de recrutement sur la qualité de leurs fichiers, plus que sur leur notoriété ou leurs interfaces. En France, l’ANPE aurait alors une belle carte à jouer face à un Monster.fr, aujourd’hui plus performant pour le retour à l’emploi.

Appels d’offres et candidatures

Plus généralement, au-delà du recrutement, ce sont l’ensemble des places de marché qui serraient susceptibles de se fédérer autour de normes communes. Une manière de cadrer la prospection (En tant que Directeur des Achats, je pourrai filtrer mes prestataires sur des champs précis de leur flux d’entreprise) mais aussi de normer numériquement les appels d’offres et leurs réponses.

Avantages immédiats : rationalisation du processus de décision sur des éléments analytiques et donc meilleur respect de la libre concurrence, meilleure lisibilité des offres et donc choix plus facile par les achats. En allant plus loin, un système automatisé pourrait aller jusqu’à organiser lui-même une shortlist dans le cadre d’un appel d’offres et pourquoi pas pré-sélectionner un vainqueur à partir d’éléments objectifs ! Le normage devient alors un outil d’aide au pilotage décisionnel.

Et demain ?

De manière encore plus générale, la suite logique de la dématérialisation et de la numérisation des process est leur automatisation (au possible), ces flux XML-normés en étant le medium : Bientôt une Déclaration Unique d’Embauche venant pinguer l’URSSAF et l’ASSEDIC tout en dépubliant automatiquement des banques de CV celui du nouvel employé ? À quand une TVA prélevée en temps réel suite à un ping XML signifiant une nouvelle recette ? Couplés à une nouvelle gamme de progiciels de gestion, l’entreprise de demain sera-t-elle pilotée en XML ?

Le framework préféré de Zazie

Connaissez-vous Joyent ? Il s’agit d’un sympathique éditeur californien d’applications web. Joyent est aujourd’hui sous le feu des projecteurs pour avoir annoncé le concurrent direct d’Apollo (ou l’armageddon vu par Adobe), Slingshot.

Slingshot est un framework pour applications hybrides desktop / web, basé sur Rails, le langage à la mode du moment. Il propose sensiblement le même triptyque qu’Apollo ou WPF/E : 2.0, browserless, synchronisation desktop / web.

4 nominés, 1 vainqueur ?

Le monde commence à se bousculer au portillon de l’application hybride desktop / web ; les widgets (pour lesquels Netvibes propose par ailleurs une API universelle, UWA) ont ouvert la marche, suivis de très près par un touche-à-tout Microsoft et son WPF/E, Adobe et sa fusée Apollo, Joyent et son outsider sur rails.

Que faut-il attendre de cette concurrence ? Plus de choix pour les développeurs et les éditeurs d’applications ! Il faut en effet parier que l’internaute aura à terme autant de runtimes installées sur sa machine que de frameworks sur le marché. Faites donc votre choix librement et codez sans entrave !

Construire dans l’urgence des solutions robustes et rapidement obsolètes : du paradigme de la SSII au tonneau des Danaïdes

Ça n’a jamais été un sentiment de facilité, avec la nécessité de toujours anticiper à deux ou trois ans pour continuer d’exister. C’est un chemin difficile que de choisir entre produits et solutions, avec une succession de technologies qui ne s’emboîtent pas. Il faut avoir la volonté d’exister demain…

Je vous invite à découvrir cet entretien « symptomatique » sur silicon.fr, bien loin des interviews des turbo-millionnaires issus du « racket 2.0″.