Brillants cancres

La semaine dernière, une nouvelle a particulièrement réveillé les vieux démons faiseurs de bulles : l'entrée en bourse de LinkedIn. Une société faisant 3 millions de dollars de résultat, valorisé à 9 milliards de dollars. Comment peut-on valoir 3000 fois ce que l'on rapporte ?!
Je suis comme tout le monde, nostalgique de cette époque éphémère où un projet d'intranet en CGI-Perl était facturé à 1 million de francs, où les consultants menaient grand train tous frais payés. Une époque où les négociations commerciales se résumaient à... une signature de contrat. Les clients payaient sans sourciller car ils écoutaient tous, les cabinets de conseils qui les hypnotisaient à coups de carrés magiques pour leur vanter les futurs miracles de ce que l'on appelait : les nouvelles technologies. Une période bénie !
Comment expliquer cet engouement démesuré pour un domaine amplement surestimé ? Comment des sociétés de bricoleurs informatiques du dimanche ont-elles pu être revendues à temps pour une fortune, puis valoir leur vraie valeur, c'est-à-dire rien, quelques mois plus tard ?
Ces brillants cancres ont compris que vendre honnêtement une très bonne qualité de haut niveau mais incompréhensible n'était pas rémunérateur. La fortune se trouve ailleurs et ceux qui la saisissent sont avant tout des faiseurs de rêves !
L'informatique d'avant bulle était une machine à rêves ou l'Internet promettait une vie nouvelle dans le nouveau cosmos virtuel de la toile. Tout le monde voulait son shoot intersidéral et entrait ainsi dans le club hype de ceux qui se distinguent de la masse. On se projetait dans les yachts des nouveaux patrons de startups, en se répétant que le rêve acheté était déjà un billet d'entrée dans cette réalité rêvée.
Le rêve, l'exaltation, le nouveau monde, une expérience unique... Ce qui permet de vendre au prix le plus fort est la capacité à téléporter un client dans une réalité parallèle, accessible pour seulement une poignée d'initiés, bien heureux d'en profiter avant la curée.
Cela ressemble trait pour trait à ce que nous vivons aujourd'hui : Le Cloud, les réseaux sociaux et les applications mobiles, des promesses de gains substantiels et de vie meilleure... à condition d'être le premier !
La suite nous la connaissons : promesses trop lentes à se réaliser, patience épuisée, peur panique, ventes massives, ventes à perte, effondrement des valeurs boursières, suicides, chômeurs, leçons puis longue disette.
Revenons à nos killer-apps : LinkedIn, facebook et twitter. J'aurais bien voulu faire partie de leurs investisseurs de première heure, alors, j'essaye tant bien que mal de me rattraper en investissant à tour de bras sur tout ce qui porte leurs traits de caractères : simple, creux, hype, social et bleuté.
Alors un conseil : si vous êtes un ancien cancre rêvant de prendre sa revanche, précipitez-vous, créez un site web en flash, bleuté de préférence, transférez-y la liste de vos contacts facebook, créez le buzz sur youtube et twitter puis faîtes vous inviter par BFM. La suite nous la connaissons...

Avenir dans les nuages ou avenir nuageux ?

La semaine dernière ont eu lieu les grandes joutes des dieux du Cloud : Marc Bennioff et Larry Ellison se sont affrontés à Paris à deux jours d'intervalle dans un pugillat verbal des plus acérés.


Ce qu'il fallait retenir tient en quelques points :

• Le Cloud c'est l'avenir !
• Le Cloud ce n'est pas de la virtualisation !
• Le Cloud est mort, vive le Cloud2 !
• Quest-ce que le Cloud2 ?! Réponse : L'extension du Cloud aux réseaux sociaux !
• Pourquoi autant de « ! ». Réponse : Parce que !!!

Le logiciel comme un service plutôt que comme un produit. Sans sarcasme, en voilà une idée qu'elle est bonne !
Jusqu'à présent, un fournisseur de service tel un opérateur de télécommunication ou un fournisseur d'électricité, mettait à disposition des usagers, un service consommable imédiatement et facturable à l'usage ou au forfait. Peut-on placer le logiciel dans cette catégorie d'usage ?
Pour ceux que la programmation a amené vers l'informatique (et non l'inverse), la règle n°5 de Rob Pike, stipule que les données prévalent sur le logiciel. Cette maxime a été adoptée depuis quelques décénnies pour construire des logiciels sous forme de données structurées et d'un habillage fonctionnel.
Celui qui détient le logiciel, détiendrait les données. On préfère donc être propriétaire de son logiciel puisque l'on veut rarement partager ces données : commerciales, stratégiques, financières ou personnelles.
Le Cloud, qui n'est autre qu'un socle mutualisé hébergeant des logiciels à usage d'utilisateurs, deviendrait implicitement un coffre-fort pour leurs données. Est-ce que cela a de l'avenir et pour quel genre d'usage?
Toute institution bien établie, garante des données de ces clients (banque, assureur...), ne peut déléguer cette garantie à une institution tierce. Le risque d'une défaillance existe dans les deux cas, mais la délégation diluant les responsabilités, des sanctions seraient compliquées à appliquer. Le trouble social qui s'en suivra impliquera l'intervention des états qui ne peuvent se permettre une telle situation car... too big to fail !
Il reste tous les autres usages, non soumis à une obligation légale : TPI, PMI/PME et autres services publiques peu critiques. Pour ceux là, pas d'interventionnisme car... too small to be relevant !
Ce genre de service intéresse donc les petites structures, disposant de peu de moyens d'investissement et acceptant de fait, le risque que représente un tel modèle logiciel. Nous savons depuis peu que ces utilisateurs sont presque aussi nombreux en volume de marché que les grandes institutions du CAC40 ou du Fortune 500.
Ce modèle économique devenu populaire depuis 2004, a bouleversé notre perception du marché. Cette longue traine statistique intéresse tous les exclus du modèle fermé traditionnel.
Marc Bennioff a concrétisé son idée en 1999, cinq ans avant le fameux article de Chris Anderson. Le génie, c'est donc cela : créer l'usage qui fera naître le modèle !

Condom Architect

J'ai eu ces derniers jours à réfléchir sur le métier d'architecte. L'éternel incompris de l'informatique, à cheval entre le savant-cosinus et le super-admin. Un rôle indéfinissable et nécessaire, mais nécessaire à quoi?!
En tout cas on entendra fatalement à un moment donné d'un projet, ce cri "munchien" de désespoir: De grâce, un architecte!!! Un cri qui arrive généralement lorsque le projet amorce la pente douce progressivement raide vers le gouffre de sa fin déshonorrante.

Quelques questions pour commencer :
Est-ce qu’un bon spécialiste peut faire un bon architecte ?
Un bon spécialiste dans une équipe d’architecte ne risque t-il pas de devenir… un bon spécialiste dans une équipe d’architecte ?

Cela m'amène à me poser la question : Qu’est ce qu’un architecte ? (ou qu’est-ce qu’il n’est pas ?)
Sans être aussi caricatural que Martin Fowler dans sa description du "Matrix Reloaded Architect", voici ce que pourrait être une charte d'architecte:

• Ne pas écrire de scripts, de code Java ou C/C++, ou résister à l'envie de le faire. Se placer plutôt comme mentor en donnant des normes et des bonnes pratiques et rappeler que le développement est un art. Ce qui suppose d’être bien au dessus des compétences classiques d’un développeur. De temps en temps, mettre les mains dans de cambouï, écrire des portions de code pour accélérer les choses et pour rester crédible (et aussi pour ne pas s'ennuyer!).

• Ne pas exécuter de commandes d’administration ou résister à l'envie de le faire. Donner plutôt un support de (très) haut niveau pour administrer ou analyser un élément du SI : OS, Middleware, logiciel… Pousser les intégrateurs et les administrateurs à être autonômes et à rechercher d'eux même en leur dévoilant quelques astuces méconnues dans leur spécialité.

• Ne pas remplacer le chef de projet mais l’assister à mener à terme son projet, sans le « vampiriser », en ramenant sans cesse le débat sur les éléments clés du projet : objectif métier, délai, budget, intégration au SI et performances contractuelles. Considérer les projets comme des étapes plutôt que des aboutissements.

• Partager, communiquer, évangéliser sur les projets et aussi sur les concepts inhérents au SI, en simplifiant les choses le plus possible, cela évite le rejet et permet l’adhésion des parties prenantes. On adhère à un projet quand on comprend ses dimensions techniques et métier.

D'où la définition suivante:
Un architecte technique est un consultant interne, un référent technique multi-spécialiste (expertise), capable d’expliquer sans donner de leçons (communication, pédagogie et modestie), d’accélérer une réalisation sans se l’approprier (délégation). Il doit planifier, fédérer puis clôturer (gestion).
C’est l’électron libre qui maintien le système en mouvement.

Pour terminer sur un peu de légèreté, j'ai lu récemment une BD satirique dans laquelle un architecte était comparé à un... préservatif! On s'en passerait bien vu sa capacité à enlever tout plasir. Mais quand les choses vont mal, on commence vraiment à regretter de ne pas avoir eu le bon sens de l'utiliser :-)

Culture de café ou culture d'entreprise?

Dans une récente analyse publiée pour Forester, Mike Gualtieri pose une question polémique: Est-ce que Java est une impasse pour les applications d’entreprises?

Une avalanche de commentaires passionnés s'en est suivie sur la toile. Il est vrai que les annonces de Mike ont de quoi titiller les égos: adopté par plus de 70% des grandes entreprises, près de 60 JSR, courbe d'apprentissage croissante, multiplications de frameworks palliatifs et enfin : 68% de projets inaboutis.

L'étude soutient que l'une des causes d'inadéquation de Java pour construire des applications d'entreprises est sa tentative de couvrir tout le spectre des sept qualités d'un logiciel: expérience, disponibilité, performance, échelonnage, adaptabilité, sécurité et économie.

Vouloir atteindre la perfection est certes une preuve d'ambition mais cela montre surtout un manque de pragmatisme, car de toutes ces qualités seulement deux se détachent aujourd'hui comme des tendances: l'expérience utilisateur et l'adaptabilité.
Un logiciel ennuyeux pour les utilisateurs est un échec et si l'on ne peut pas le modifier dans des délais et des coûts raisonnables, alors il disparaîtra. Il se trouve que Java n’a pas été inventé par des spécialistes des applications d’entreprise, d’où la faillite des premières versions d’EJB. Il n’a aussi jamais été pensé pour le confort de l’utilisateur final, d’où l’échec d’AWT puis de Swing et enfin de JSF. Java s'est embourbé dans des modèles inutilement complexes, des architectures "bitte schön, danke schön", comme les décrit Christophe Thiry, de manière hilarante dans son blog.

L’étude met en avant les nouveaux paradigmes de développement. L’avenir, pressenti depuis longtemps mais concrétisé depuis peu, appartient à ceux qui réduiront les délais, les coûts et la distance avec le cœur de métier de l’entreprise. Des architectures événementielles représentent cette nouvelle tendance où différents outils sont employés à différentes phases d’un modèle métier (et non plus d’un programme): conception, implémentation et action. Ces paradigmes offrent beaucoup plus qu'une évolution, ils promettent d'humaniser l'informatique.

Le principal argument mis en avant par les entreprises, pour justifier la continuité de la stratégie Java est… historique : J’ai investit dans Java, j’ai plusieurs applications en production, je suis obligé de supporter ma croix et pour longtemps encore…Cela ne vous rappelle-t-il pas un autre langage. Eh oui, Cobol, toujours là et pour longtemps encore ! De là à dire que Java subira le même sort, il n’y a qu’un pas. Je trouve cependant cette étude rassurante : il y’aura toujours du boulot pour les développeurs Java. Dieu merci !