Lettre à ma fille

Depuis ta naissance, je suis tenté d'immortaliser le moment par autre chose que des photos, insuffisants clichés statiques colorés. Je préfère y ajouter le piquant des sensations, et de l'atmosphère du moment.

Le 17 Juillet 2012 est une date lovée dans un contexte que je souhaitais te transmettre pour la mémoire. Tu liras ces notes très subjectives et parfois engagées, mais ne m'en veut pas, je les fige telles quelles pour ne pas risquer de prendrre mes distances plus tard et lisser des angles trop aigus.

Commençons par ce qui s'appelle à cette époque « les réseaux sociaux ». Je n'ai annoncé ta naissance sur aucun d'entre eux ni envoyé aucun SMS groupé. J'ai estimé que tu étais mon petit miracle qui mérite mieux que cela. Alors j'ai partagé quelques photos dans le cercle de famille pour tes grands parents sur Google+, encore considéré comme un réseau élitiste, et nous avons envoyé des SMS à quelques amis, loin de la cacophonie d'un Facebook boulimique d'abonnés que beaucoup voient sombrer tout comme ont sombré les desseins spéculateurs d'un Internet , mais les subprimes sont déjà passés par là et le monde n'est plus impressionable.

Linux rapporte des milliards à des petits malins au chapeau rouge qui ont fait d'un mouvement libre, une entreprise aux profits intarissables. Mais l'Open Source reste toujours un combat de l'intelligence contre l'assistanat, malgrés le larmoiement de quelques cerveaux atrophiés et peureux. Le choix implique le changement et certains doutent de leurs capacités à s'adapter, comme si d'avoir survécu durant des dizaines de milliers d'années n'était pas une preuve suffisante pour l'homme de son pouvoir de régénération.

Sur le front de l'Est, une nouvelle occasion a été offerte à une poignée d'intrigants pour embraser une nouvelle fois le moyen orient, la fumée au-dessus de la Palestine, de l'Egypte et de la Lybie se dissipe à peine que certains regrettent déjà l'odeur du napalme le matin et les syriens stratèges invincibles ont découvert trop tard leur talon d'achille : le mal extérieur qui ronge de l'intérieur et qui oppose Sunnites contre Alaouites, ennemis acestraux tapis dans l'ombre se guettant les uns les autres. La fin est ineluctable pour le dernier bastion baassiste et les médias dégoulinants de compassion me font zapper vers d'autres horizons. J'ai banni les journaux télévisés comme vecteur d'information et je papillonne deci, delà pour tromper une main-mise manipulatrice mais heureusement encore suffisament grossière pour que mon esprit n'en soit pas duppe.

L'industrie de France cherche un second souffle après des échecs de stratégies ambitieuses mais tardives. L'état se renouvelle et les vainqueurs sociaux-démagos-comunistes à grands renforts de communication poussive, jouent les sauveurs, hurlants sur la berge des conseils inutiles à des noyés en détresse. A défaut de sauver ils compatissent, honteux eux même des orgies providentielles d'années d'insouciance. « Compassion » est le nouveau mot pour remplacer le génant « Propagande ».

Tu es née l'année d'un hommage planétaire à Marley, le dernier prophète connu, chantre d'une musique lancinante où l'on devine à la fois la souffrance et l'espoir. Je l'ai écoutée en boucle à Oran dans mon guetto universitaire. Je te garderai le DVD pour tes dix huit ans ; tu le regardera en souriant de la qualité de l'image et du son, comme j'ai souri en écoutant les vinyles de papa.

Rock&Folk a publié un hommage à David Bowie et son Stardust hallucinant aux cheveux de feu, Iggy Pop reprend Henri Salvadore, bizarre, et le livre des 50 ans des Rolling Stones est sorti en librairie.

Tu étais dans ton berceau, agée de onze jours lors de la cérémonie d'ouverture des jeux olympiques de Londres. Mohamed Ali et Haile Gebrselassie ont fait le déplacement pour porter le drapeau des jeux ; la cérémonie fut empreinte de rock anglais, les Arctic Monkeys ont repris « Come together » des beatles avant qu'un ex-Beatles, Paul Mc Cartney, ne cloture à cappella avec le fameux « Hey Jude », quanrante ans après Abbey Road. Fantastique ! Ta maman et moi rêvons de t'emmener à un concert rock, peut-être Metallica au Stade de France l'année prochaine, on verra si tes petits tympans seront capables de supporter les solos de Kirk Mammett.

Michel Serres a écrit « Petite poussette », le conte d'un grand père philosophe, narrateur d'histoire d'avenir à une génération de petits virtuoses du pouce. Tu le lira quand tu sera grande et tu me dira si l'oracle avit tord ou raison.

J'oubliais, Rod Johnson a quitté SpringSource, tu ne le connaitras peut-être pas, mais il fut le créateur d'un contre-mouvement qui a décuplé l'ingéniosité des gens à trouver des solutions simples à des problèmes complexes. Dans son mot d'adieux il fait référence à un livre pour enfant « Oh, the Places You'll Go! » que je te lirai un jour. Cette année 2012 est aussi l'année d'Alan Turing, celui grâce à qui ces mots te parviennent.

Bien que cela risque de ne pas signifier grand chose pour toi le jour où tu le liras, sache que ce texte a été écrit avec LibreOffice 3.5 sous Ubuntu 12.04 « Precise Pangolin », sur un ASUS ZenBook 13 pouces, Core i7, 4Go de RAM et 256 Go SSD.

J'ai aussi vérifié certaines références de ce texte sur Wikipedia qui a plus de onze ans d'existance aujourd'hui.

Mental Oriented Architecture

Lorsque l’on traverse un désert, le vide qui nous entoure, loin de nous apaiser, met nos sens en ébullition. Dans cet espace de quiétude, nous percevons un pressentiment pesant, imperceptible, croissant au fur et à mesure que les mirages s’estompent et rebroussent notre marche. Cette parabole illustre parfaitement le défaut d’inspiration qui nous ronge au milieu du désert d’annonces réchauffées et insipides, d’où il est vain de tirer une quelconque substance nutritive pour notre esprit.

J’en étais à ce stade de réflexion, lorsque par un enchaînement hasardeux de liens, je suis tombé sur un document étonnant autant qu’émouvant d’Alan Kay, décrivant pour le compte de Xerox en Août 1972, la première ébauche d’un laptop. Un ordinateur portable agréable à manipuler capable, entre autres, de se connecter à une librairie scolaire par le réseau « ARPA » ! Je ne puis m’empêcher de penser que quarante ans plus tard, mon Kindle récupère tout seul en Wifi, un eBook que je viens d’acheter en un clic dans la librairie Amazon!
Ne nous emballons pas, car en même temps, je continue mes exercices de contorsion pour insérer un schéma au milieu d’un paragraphe rédigé sous MS Word. Il semble qu’il y’ai une sorte d’ « étape » que certains systèmes ont du mal à franchir.

Les systèmes informatiques deviennent l’extension de nos cinq sens. Nous en attendons une information et une ergonomie d’utilisation fidèles à notre modèle mental. Ces systèmes excellent à représenter des données puis y superposent des algorithmes pour y accéder, les traiter et nous les présenter. Dans un effort constant d’abstraction, des paradigmes sont nés pour illustrer ces systèmes telles qu’ils sont sensés être dans la réalité : des personnes, des comptes bancaires, des contrats, des agences de voyage, des dérivées d’actions…etc. Nous avons dilué les algorithmes dans ces entités abstraites que nous avons spécialisé à l’infini créant ce qu’on appelle l’Orientation Objet. Une représentation commode pour ceux qui s’en contentent, mais l’utilisateur ne s’en sort toujours pas, ou avec des migraines. Comment cet utilisateur que nous voulons plier aux modèles de nos systèmes, représente t-il son monde ? Quel parcours son esprit effectue t-il intuitivement pour réserver un billet d’avion, virer de l’argent ou acheter sur Internet ? En d’autres termes : à quoi devraient ressembler les applications du domaine public ou celui interne aux entreprises, pour que leurs utilisateurs ne les adoptent pas par dépit ?
Réduire le fossé entre la vision du concepteur et celle de l’utilisateur, tel est l’objectif des futurs paradigmes.

Lors d’une conférence sur l’avenir de la modélisation Objet, James Coplien exhorte ses auditeurs à étendre leurs modèles d’entités pour adopter une approche DCI dans laquelle le logiciel ne devrait plus être conçu comme un ensemble d’entités logiques, mais plutôt comme un ensemble de rôles de composition. Cela bouleverse notre vision des systèmes informatiques qui deviennent non plus des conteneurs de données mais des espaces de services se pliant aux rôles que l’utilisateur aura tout loisir leur attribuer. Cette vision des choses a l'intérêt de moins marginaliser la conception qui se rapproche ainsi de la perception mentale que l'on se fait d'un système, une perception d'utilisateur, tantôt concepteur, tantôt client.

Alan Kay a imaginé le petit Dynabook comme un appareil informatique utile et intuitif qui a donné naissance aux notebooks, netbooks et autres tablettes. Sur les traces d’un autre gourou au nom imprononçable, de nombreux concepteurs se sont engouffrés dans la brèche DCI. Je suis curieux de savoir ce qui naîtra de ce foisonnement d’idées autour de cette nouvelle approche. Moins de migraine pour les utilisateurs, j’espère.

Iznogoud

Suggérer, dans le monde du marketing, c'est implanter une idée dans un esprit pour le guider à faire des choix agréables, sans suspecter de manipulation. Nous obtenons un client satisfait et au plaisir contagieux. Le graal du marketing! Comment y arriver?

Un article d'Yseulis Costes, brillante co-fondatrice de 1000mercis.com, professionnelle et spécialiste du marketing, nous détaille à l'occasion de l'anniversaire de l'e-mail, l'histoire de ce canal de communication et de son évolution à travers les âges son omniprésence et ses futures avancées… Déception: une trouvaille vieille de 40 ans que l'on continue à presser faute d'une plus fertile imagination.

Combien d'e-mails envoyez-vous hors contexte professionnels? Vous souvenez-vous de la dernière fois où vous avez ouvert un e-mail publicitaire qui a passé votre filtre anti-spam? L'e-mail, c'est bon pour les dinosaures qui ont certes décidé de jouer les prolongations au boulot, mais seulement au boulot.

J'en étais là de mes réflexions lorsque j'en suis arrivé à penser que mes choix m'ont finalement souvent été "suggérés" par un tiers de confiance, une personne qui n'est pas toujours présente à mes côtés ou joignable et on ne sait d'ailleurs même pas si quelqu'un de notre réseau saurait répondre et même s'il y'en avait, on hésiterait à le déranger. Quelle alternative? Facebouc, touiteur les foromes? Mouais…

Imaginez une sorte de conseiller omniprésent, chuchotant à votre oreille au moment précis où un choix s'impose, en fonction de vos goûts, de votre culture ou de votre humeur: cadeaux, livres, immobilier, placements, vacances… Le google d'avant guerre laisserai place au bon vizir personnel, tout-puissant auprès de qui les annonceurs se bousculeraient pour s'accorder ses faveurs. Je souriais à mes divagations en pensant aux romans d'Assimov, au scénario d'I-Robot ou au célèbre petit personnage enturbanné créé par Goscinny, lorsque je suis tombé quelques jours plus tard sur une révélation du genre qui nous réconforte sur le fait que nos cogitations ne sont pas le résultat d'un délire hallucinogène, mais que nous ne pouvons que nous résigner à regarder, amorphes, la réalisation de nos idées par des gens plus doués que nous. Moche pour le moral!

Cette révélation se nomme "Siri", le nouvel assistant équipant le dernier iPhone 4S. Siri, le bon génie dont l'effet est aussi transcendant que le mégalithe de "2001 l'odyssée de l'espace". Il nous projette hors du pléistocène vers un monde aux multiples possibles. Pour le moment, il est à peine plus intelligent qu'une Barbie parlante, mais l'idée est là et me semble en mesure de balayer toutes les autres: moteurs de recherche, réseaux sociaux et … e-mails marketing.

Je ne suis pas fan d'Apple. Je n'en ai jamais possédé et je ne rêve pas d'en posséder un jour. Pour moi l'informatique se résume à des écrans noirs défilant des traces tcpdump, des lignes de commandes truffées d'expressions régulières et des stack traces d'exceptions CORBA sur des EJB 2.x. Et puis vint Siri, un concept encore embryonaire de conseiller, capable de nous rassurer, nous amuser, nous dénicher des bons plans. Il s'en suivra certainement un débat sur l'effet manipulateur mais peu importe, l'idée est bien là et l'évolution de la technique lui sera prodiguée en priorité.

Revenons à notre article sur l'histoire de l'email. Vous n'en avez plus envie? Moi non plus!

Mandelbrot les SI et la Commission Européenne

Cette période que nous vivons est révélatrice du talent des hommes à gérer leurs crises. Un talent génial par son cheminement, médiocre par son résultat. C'est ainsi depuis Neandertal.
Ce talent est celui des meilleurs d'entre nous, que nous avons désigné pour créer des solutions à nos problèmes et en assurer l'application. Leur talent s'est pleinement exprimé à construire par imbrication, juxtaposition, concaténation, fusion... un amalgame de lois, de normes, de règles, de procédures, regroupées en institutions, organisations, associations d'une complexité telle, qu'il n'est pas possible aux autres humains d'en comprendre les rouages, ni même d'en critiquer les résultats.
Un travail d'orfèvres auquel se sont attelés des générations de nantis des plus talentueux d'entre nous, capables de schémas cognitifs qu'ils sont les seuls élus, parmi les élus à pouvoir en décrypter le cheminement. Chaque voie aboutissant à une chambre à plusieurs issues, chacune débouchant sur un dédale de couloirs se terminant par des alcôves révélant d'autres ouvertures, puis des labyrinthes, puis des anti-chambres, puis des trappes, des escaliers, c'est sombre, une lumière au bout, c'est peut-être la sortie, non, une autre chambre éclairée et parsemée de hiéroglyphes, donnant sur de multiples issues identiques vers d'autres couloirs sans fin, au bout de l'un d'eux une voie audible, nous la suivons, un personnage habillé d'un costume étrange imprimé de symboles abstraits, débitant un discours tout en métaphores, complexe, intelligent, mais notre problème est simple : sortir ! Nous passons notre chemin, la voix s'éteint au loin et devant nous un abîme de labyrinthes ... Des années de génie administratif, politique, économique, grassement nourri par des contingents de serviteurs dévoués et consentants.
Souvent, lors de mes pérégrinations professionnelles, lorsque je suis confronté à la complexité absconse et procédurale d'une entreprise, maintenue par les dogmatiques gardiens du temple SI, je pense à la commission européenne, à l'ONU ou au FMI, ces regroupements de talents pensant et façonnant la complexité comme personne d'autre. Je trouve que ces constructions relèvent d'un même modèle, comme si une seule fonction mathématique donnait des résultats structurellement identiques, suivant un ou plusieurs facteurs de dimension : Un SI, l'ONU, le FMI, l'AFSSAPS … Avec une infinité de ramification dès qu'on y regarderait de plus près.
Benoît Mandelbrot, en étudiant les objets à complexité récursive a révélé au monde les fractales, des constructions mathématiques s'étendant à l'infini, des objets qu'il désigne d' « auto-similaires ».

Je suis convaincu que les esprits de ces talentueux constructeurs de labyrinthes ainsi que leurs œuvres alambiquées, découlent de la même formule pour aboutir aux mêmes résultats: un dédale infini, notre perte!

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 !

Eloge de la lenteur

Un article étonnant de Philosophie Magazine chamboule notre rapport au temps et remet en question la paternité de l'horloge.
Tout le monde s'accorde à dire que l'horloge mécanique a été inventée en Europe au XIIIème siècle. Pourtant les chinois disposaient dès le premier millénaire, d'un système de clepsydre très sophistiqué, utilisé principalement dans l'étude du mouvement des astres, savoir nécessaire pour établir les prévisions astrologiques dont l'empereur se servira pour exercer son pouvoir. Le temps selon les chinois est donc un luxe réservé aux décisions de l'empereur. Le peuple quant à lui ne peut disposer de ce privilège. Alors dirons nous, comment prévoir le temps ou comment définir un délai et le respecter? Eh bien sur ce sujet, deux cultures s'opposent: dans l'occident, le temps sert à borner une réalisation par un début et une fin. Dans la civilisation chinoise, le temps importe peu pour une réalisation, seule la perfection compte!
Imaginons ce que serait nos projets dans un monde régit par la perfection et non pas par la "deadline". Nous n'aurions certainement pas des smartphones, mais nous aurions des moyens de communication qui répondent parfaitement à nos besoins sans bugs et sans stress pour les SAV.
Pensez à un travail que vous avez réalisé en prenant votre temps. Imaginez à quoi il aurait pu ressembler si on vous avait imposé de le livrer pour telle-date-au-plus-tard!
Le pouvoir dans la culture occidentale se mesure par la capacité à faire respecter les délais, quelle humiliation que de ne pas livrer en temps et en heure. On préfèrerait produire une immondice et y adjoindre une série de correctifs plutôt que de prendre le temps de tester et de peaufiner. J'ai déjà vu des chefs de projets à la limite de la dépression parce que leur projet risque de prendre du retard. J'ai souvent proposé de prendre le temps de produire quelque chose de correcte plutôt que de se précipiter et de perdre toute crédibilité vis-à-vis des utilisateurs. Eh bien non, rien n'y fait. La seule chose qui restera du projet ce n'est pas l'aventure humaine et technologique, la réalisation innovante ou la satisfaction des clients. Non, tout ce qui sera retenu ce sera le RETARD!
Dans la bande dessinée "Le petit Nicolas" de Sempé et Goscinny, Geoffroy est un garçon décrit comme lunatique et toujours en retard. D'ailleurs la maîtresse ne l'a jamais félicité à cause de son retard, sauf une fois: il venait d'avoir un p'tit frère.
Un long conditionnement qui a débuté sur nos bancs d'école et qui ressort et guide nos comportement d'hommes actifs. Maintenant que la cause est identifiée, levez vous du canapé et reprenez le dessus sur vos vieux démons scolaires!

Bonne année 2011 !

Une nouvelle année est une nouvelle itération dans notre histoire personnelle, un "sprint" de plus dans la réalisation de la fameuse oeuvre, dont on pourra savourer la ligne parfaite, épurée, aboutie... avant de recommencer de plus belle et en mieux. Nous sommes insatiables! En tout cas j'espère pour vous que vous l'êtes, autrement la vie serait insipide!
J’ai récemment découvert le blog d’Olivier Roland, un autodidacte éclairé doué d’un enthousiasme à toute épreuve. Il s’est fixé comme défi de lire 52 livres en 52 semaines ! Cette boulimie de savoir s’explique : combien de fois avez-vous changé d’avis sur un sujet après avoir lu quelque part un court article, découvert par hasard, ou après avoir écouté un débat télévisé. Vous êtes par la suite étonné d’une telle découverte qui a changé quelque chose en vous et vous vous jurez de revenir sur le site ou le blog en question, promesse évidemment non tenue. Combien d’occasions similaires avons-nous raté ? Vous vous résigner et vous vous dites que vous n’avez pas le dont d’ubiquité.
Un conseil : persévérez, lisez le plus possible ! Mais pas n’importe quoi. Olivier Rolland énumère quelques perles documentaires inconnues, pourtant étonnement célèbres, au vu des évaluations Amazon.
Dans le même ordre d’idées, un autre adepte de self-made-man, Josh Kaufman, présente la méthode Personal MBA pour atteindre soit-même un niveau équivalent à celui de MBA, en lisant de manière ciblée un panel de livres sur tous les domaines: économie, organisation, développement personnel, management... etc. Essayez, c'est passionnant et c'est mieux votre compte bancaire!
Donc pour cette nouvelle année, lisez! Autant que vous pouvez ! Pour sortir du nuage de flou dans lequel nous plongent tous les jours, les masses d'informations incertaines. Lisez, vous serez imbuvable quelques temps avec votre science infuse; juste le temps de digérer puis de réorganiser et enfin de piocher, non sans y avoir ajouté une pointe d'humour, dans la mine de savoir dont vous disposerez. Vous serez enfin quelqu'un qu'il sera bon de connaître.
Bonne année encore et n'oubliez pas de faire un geste pour Wikipedia et de relayer le message!

Agile ou contortioniste?

Pourquoi la méthode Agile a du mal à s'imposer dans les projets informatiques?
Une réponse intéressante à cette question a été postée sur le site DZone. L'auteur explique que que le client trop impliqué par Agile, se comporte comme s'il ne voulait pas qu'on lui reproche le disfonctionnement de l'application qu'il a contribué à spécifier. Plus crûment, il ne veut pas être blâmé en cas de problème. D'où vient ce sentiment?
Le plus souvent, une solution informatique en entreprise est imposée plus que choisie. Dès lors, elle cesse d’être une solution pour devenir un fardeau. La vision simplificatrice de l’entité « Client » occulte tous les aspects humains entourant la réalisation d'un projet.
Agile est une méthode pragmatique, bâtie sur l’hypothèse d’un monde faillible et d’un contexte humain contraint et donc peu coopératif et peu constructif par nature. Cette méthode a brisé la linéarité irréaliste de Waterfall en petits incréments, dont le but est de faire apparaître les imperfections, le plus tôt possible.
Voici un exemple type d'un dialogue Agile entre Marlene, du service de Gestion et Fred, un développeur:
F: Voici ma compréhension de ce cas d’utilisation. Êtes-vous d’accord ?
M: Oui.
F: Alors passons à la réalisation…. Qu’en pensez-vous maintenant ?
M: Ce n’est pas bon, vous n’avez pas bien compris ce que je voulais dire.
F: Pourtant je l'ai écrit et vous l’avez relu… Recommençons…. Qu’en pensez-vous maintenant ?
M: C’est beaucoup mieux. Il reste deux trois détails
….
M: Là c’est parfait !
Une fois l’application mise sur rails, on se rend compte que ce cas d’utilisation mérite d’être revu. Il faut refaire appel aux service de Fred et Marlene qui avait validé ce cas, risque d’être pointée du doigt et le vivra mal.
C’est de cette situation que souffre Agile. Le fait que le client s’implique à ce point dans le processus de développement et le risque qu’il en soit blâmé. Ceux qu’on doit blâmer, traditionnellement, ce sont les fournisseurs, non ?! Pourtant Marlene ne devrait pas avoir de soucis à se faire, l'éventualité de redévelopper un cas d'utilisation fait partie d'Agile et ne coûtera pas plus chère à l'entreprise.
Agile remet en question les situations schizophrènes comme par exemple: le client ne maîtrise pas son métier et ne peut pas l'admettre et le fournisseur n'a aucun moyen de lui soutirer des informations et ne peut pas s'en plaindre. Alors on fait avec... Une situation Ubuesque qui a mené en deux décennies, à une belle pagaille dans les SI.
Alors on tente de remplacer cela par un processus qui répartit les responsabilités ou, disons, en crée là où il n’y en avait pas auparavant. Une méthode qui tient compte de l'imperfection des hommes et des logiciels pour peut-être moins de stress inutile dans les projets.
Un projet ne peut être quantifié seulement par une durée, un budget et un taux de cas d’utilisations couverts. Il faudrait y ajouter une composante que nous avons totalement occulté : la sérénité.
J. Stiglitz a introduit un indicateur de « bien être » dans l’évaluation du PIB, ce qui révèle que des pays supposés riches ne le sont pas réellement. Pourquoi ne pas en faire autant pour les projets informatiques ? Cela révèlera peut-être que certains projets sont plus aboutis que d’autres, même si la sacro-sainte « deadline » n’a pas été respectée.

L'interface "est" le système

C'est en tout cas ce qu'affirme Vinayak Hegde dans la liste des 97. Dans cette même liste on peut lire une contribution de Einar Landre qui affirme pour sa part que l'architecte doit se focaliser principalement sur l'interface.
Le premier évoque la relation de l'humain avec le système, le second parle de la relation des systèmes entre eux. Peut-on établir un parallèle?
Dans ces deux affirmations, l'interface joue le rôle d'intermédiaire dans l'établissement de relations.
Dans la culture populaire, un agent intermédiaire peut faire ou défaire une bonne entente, quelle que soit la bonne foi des deux parties.
Pourquoi alors cette confiance en un intermédiaire incontournable? Quelle est la pérennité d'une telle association? Réponse: aucune des parties prenantes à la relation ne veut s'adapter à l'autre, car cette adaptation induit une dépendance. Autrement dit, chaque partie portera en elle, une définition de l'autre. L'intermédiaire devient alors un facilitateur!
Lorsque les systèmes s'interfacent entre eux, on parle de "découplage". Lorsqu'ils s'interfacent avec des humains, on évoque... "l'intuition". Dans les deux cas on fait appel à l'agent adaptateur.
Les systèmes entre eux, pour réduire leur dépendance, sont conçus en faisant appel à des modèles respectant les principes fondamentaux que sont la Séparation des responsabilités et l'inversion de contrôle. Quant à l'humain, sa communication avec le système passe par l'image au sens figuré, que lui retransmettent ses sens. Les interfaces se sont donc adapté à ce mode de communication: vue, ouïe, toucher, (goût et odorat?). Il y a quelques années elles étaient minimalistes: clavier, écran et symboles, ce qui nécessitait un effort cérébral important pour mémoriser l'association des symboles informatiques au monde réel. Au fil des années, de plus en plus de sens sont stimulés et la symbolique disparaît peu à peu: la communication est devenue graphique, s'est colorée, animée et sera bientôt holographique. L'action passait par le clavier, elle est devenue tactile, orale... bientôt télékinétique?
Nous déployons de moins en moins de moyens rationnels pour communiquer avec le système, qui pour sa part nécessite de plus en plus d'intelligence pour rendre possible cette simplification. Ne sommes-nous pas en train de nous atrophier à l'avantage des systèmes que nous concevons?
Disons que notre intelligence change; nous évoluons vers un futur plus heuristique que rationnel.
Un jour, doués de cette nouvelle forme d'intelligence, nous finirons par concevoir des systèmes qui seront intelligents, certes d'une intelligence à l'image de notre passé d'humain atrophié, mais alors une nouvelle étape sera alors franchie, celle où interfaces et systèmes se confondrons.

OWF!

Il y'a quelques jours, a eu lieu l'Open World Forum. Si vous y étiez, vous auriez remarqué que le perfecto en cuir de Simon Phipps tranchait franchement avec le costume-cravate du DSI de Sanofi-Aventis :-)
Il ne s'agissait pas d'une énièmme messe d'évangélisation de l'humanité à la voie sacrée de la FSF, avec RMS en post-babacool, pronant l'amour du software libre et le rejet de la vile monaie! Non, il s'agissait d'un autre type d'évennement, un show orchestré par des acteurs aguerris aux règles du business qui présentaient leurs solutions. De vraies solutions robustes; concurrentes directes de solutions commerciales, pour des utilisations stratégiques en entreprise: Cloud Computing, Virtualisation, BPM, BI, CMS...
Ce forum a soulevé de nombreuses questions de fond:
Comment cette culture, hérétique il y'a dix ans, est-elle devenue aujourd'hui une réelle alternative? Est-ce mimétique ou conjoncturel? Quel est l'avenir du logiciel libre face au logiciel commercial? Comment transformer une solution Open Source en opportunité business?
Je n'ai pas trouvé de réponses à toutes ces questions. J'ai cependant observé que la curiosité a disparu pour laisser place à une véritable adoption, réfléchie et pragmatique. Les DSI présents (Bull, Sanofi-Aventis, Safran, PriceMinister...) se sont tous déclarés comme déjà utilisateurs de solutions Open Source et prêts à considérer les offres; du moment que la performance est au rendez-vous. La révolution appartient déjà à l'histoire!
La gêne perceptible, car il y'en a, est due au fait que l'Open Source expose beaucoup plus la responsabilité des dirigeants. Point de contrat commercial exhorbitant, adossé à des clauses telles que que seules de puissantes firmes logicielles peuvent se permettre de parapher. L'Open Source ramène aux fondements d'un métier, de notre métier: la compétence, la passion, l'honnêteté. Aucun dirigeant n'est sûr de disposer, dans son projet d'intervenants sûrs, partageant ces valeurs. Alors, il préfèrera les firmes. A grand renfort de communication, elles ont imposé à notre subconscient l'image de la perfection. Personne ne reprochera à ce dirigeant de s'être mépris en choisissant une perfection admise par tous.
Seulement voilà, tout cela est en train de changer, la maturité de ce métier explique de moins en moins la délégation de responsabilité. Les défaillances répétées des firmes ont érodé définitivement le mythe de la perfection. Nous redescendons vers une réalité moins brillante: les paradigmes sur lesquels sont construites les nouvelles architectures d'aujourd'hui ont moins de dix ans d'existence. Alors faisons profil bas, dénouons le nœud de notre cravate et comme Simon Phips, revêtons notre blouson en cuir de baroudeur de l'informatique, abandonnons notre égo et tentons de construire, enfin, des systèmes par la seule force de notre intelligence.

L'art de la maquette

Lors d'une visite de la Sagrada Familia à Barcelone, j'ai été frappé par l'audace de Gaudi. Oser reproduire les frondaisons d'une forêt dans une cathédrale pour exprimer des sentiments abstraits: l'élévation, l'origine de la vie, la beauté maîtrisée de la nature et sa copie inachevée par l'homme. Audacieux!
Comment peut-on oser la réalisation d'oeuvres monumentales en gardant une totale assurance dans ces créations? Comment peut-on se permettre de telles audaces?
La réponse je l'ai eu un peu plus loin. Alors que je m'avançait dans la crypte je me suis retrouvé devant une reproduction inversée en structure de fil de fer de la Colonia Guëll. De petites bourses de sables maintenaient les arrêtes vers le bas en augmentaient la courbure de leur arc en fonction de leur poids. Le tout faisait penser à un hologramme sortie d'un logiciel de modélisation d'architecture. Gaudi avait, au début du 20ème siècle, inventé la maquette 3D!
Pourquoi cette structure de maquette complexe alors que du plâtre, comme il était d'usage à son époque, aurait suffit? Les maquettes en dur, il en a construit plusieurs, encore bien conservées à ce jour. Celle qui m'a attiré donnait au visiteur, une sensation de légèreté, une cathédrale immense, flotant dans les airs, comme les colonnes de la Sagrada, semblables à d'immenses arbres dont les sommets s'élèvent vers le ciel pour soutenir le plafond de la cathédrale. Tout un symbole... Gaudi ne voulait pas seulement modéliser une forme, mais un concept! Il tentait d'approcher et de "peaufiner" l'émotion que susciterait son oeuvre une fois terminée.
Lorsque l'on opère un changement dans les systèmes d'informations, nous réalisons ce que nous appelons des POC. Ces derniers, comme leur acronyme l'indique, doivent représenter un concept et non pas un sous ensemble de l'architecture finale. Le plus souvent nous nous contentons d'y tester des procédures d'installation, nous passons ensuite à la réalisation et nous nous étonnons de découvrir d'énormes disfonctionnements pendant le projet. Nous aurons non seulement perdu tout l'intérêt d'un POC, mais en plus, nous scellerons à jamais toute tentative de réarchitecture ou même de compréhension ou de modification future.
La plupart du temps, le système d'information est vu comme un agrégat de logiciels et de matériel plutôt que comme un ensemble de concepts.
Les partisants de SOA honnissent l'architecture en "silos", Je trouve cette image très éloquente... passer du silot à la cathédrale ne revient-il pas à délaisser l'alimentaire pour le spirituel. OK, me direz vous, mais seulement le dimanche!

Corrélation VS Causalité

Un jour, j'ai eu à traiter un incident de production qui s'est déclaré sous la forme d'une application de production qui s'est brusquement ralentie au point de ne plus fonctionner.Dans le même temps, un serveur hébergeant un service utilisé par cette application s'est arrêté de fonctionner.

Déferlement d'e-mails, cacophonie de sonneries de téléphone et confusion généralisée. Que faire?! Quelques redémarrages de services plus loin et le système était reparti tant bien que mal.
De par sa rareté, le problème était difficile à reproduire. Une démarche simpliste dans ce cas, est de tenter plusieurs interventions sur les différents services impliqués, dans différents ordres pour tenter d'en déduire la séquence fatale. Peu efficace. Cette Méthode empirique s'appuie sur la dépendance intuitive entre des phénomènes.
La seule conclusion à laquelle nous aboutissons (permettons nous un peu de probabilités), est que les variables aléatoires correspondant aux éventualités d'occurrence d'un résultat sont liées entre elles plus ou moins fortement. Cette liaison s'exprime, dans la théorie de la probabilité, par une corrélation définie par son coefficient. Plus ce dernier est élevé plus forte est cette liaison.
La corrélation ne suffit pas pour se prononcer sur ce que l'on tente de vérifier réellement: une causalité! La modéliser n'est pas une mince affaire!
Introduisons un autre niveau de probabilité: celui concernant l'occurrence de relations de causalité entre les variables aléatoires. Nous obtenons un graphe (de causalités) et une table de probabilité. Le tout est appelé: réseau Bayésien.
Dans ce graphe les relations de cause à effet ne sont pas déterministes mais probabilistes. Nous n'exprimons plus une cause mais une probabilité précise qu'un effet soit du à cette cause.
Appliqué à notre problème, cela nous aurais permis d'exclure les fausses pistes jusqu'à se rapprocher de l'origine du problème.
Dans une architecture distribuée modélisée par un graphe acyclique fortement connexe, les nœuds représentent des services (ou des serveurs) et les arcs sont les protocoles réseau les reliant. Nous disposons d'une connaissance (le savoir empirique cumulé par notre expérience sur cette architecture) et des inférences (observations intuitives sur notre système). Comment vérifier ces inférences? Posé ainsi, le problème se modélise de lui même en réseau Bayésien.
Combien de fois avons nous entendu des phrases contenant des termes comme: "très probable", "peu probable"... et combien de fois nous en avons été peu convaincus, nous avons cependant refermé le dossier par manque d'outils, mais aussi, avouons le... par paresse ;-)

Bonne année 2010!

"Souviens-toi que le Temps est un joueur avide
Qui gagne sans tricher, à tout coup!" Charles Baudelaire

C'est ainsi que commence l'exposé de Francesco Cirillo, intitulé: "La technique du Pomodoro".
Pomodoro signifie "Tomate" en italien. Ce fruit importé des amériques avait à l'époque la couleur jaune dorée, les italiens le baptisèrent "Pomme d'or". Le Pomodoro est aussi ce minuteur de la forme d'une tomate, gradué que l'on trouve souvent dans les cuisines. F. Cirillo a choisi ce nom d'objet anodin pour baptiser sa technique de gestion du temps.
Cette technique vient du constat suivant: nous ne savons pas estimer la durée de ce que nous accomplissons.
Selon Bergson, la perception du temps n'est pas celle d'une durée mais celle d'une succession de situations simultanées. Seule la mémoire permet d'estimer la durée entre deux successions. Cette durée est donc subjective.
Notre dépendence au temps est telle qu'une réalisation même aboutie peut être perçue comme inachevée, de par le caractère subjectif de la durée que nous y avons consacré. Ainsi, nos tâches journalières se suivent et le goût d'inachevé est chronique.

Faut-il reconsidérer notre perception du temps?

C'est en tout cas l'idée de la technique du Pomodoro basée sur une décomposition fine des tâches, bornées dans un intervalle de temps fini et mésurable (grace au minuteur). Cette technique ne s'arrête pas là, elle nous impose aussi des moments de réflexion ou de "feedback", ne serait-ce que pour apprécier, pour une fois qu'une tâche planifiée soit terminée...dans les temps. Ainsi, s'opère l'association dans l'esprit, des deux notions d'achèvement et de durée. On aquière alors la faculté de percevoir le temps en unités de tâches, en réalisations et non plus en positions simultanées des aiguilles d'une horloge.

Quant aux autres résolutions, inspirez-vous de la liste d'Andy Lester dans PragPub:

• Soyez positifs
• Améliorez votre expression écrite
• Soyez pertinents sur votre CV
• Arrêtez d'être omniscient
• Evitez de dramatiser
• Surveillez votre cote sur Internet

et j'ajouterais ... faites simple!

Gold rush

Récemment, un ami me disait toute la déception que lui avait apporté Java. Qu'il avait abandonné son vieux C pour se plonger dans la nouveauté de l'époque, pour se rendre compte qu'il était temps de renoncer.

Au début, mus par un enthousiasme euphorique, mon ami, tout comme des foules de développeurs chevronnés et d'apprentis gourous, se sont rués vers le Klondike de l'informatique de la fin des années 90: Java.

La majorité de ceux qui ont connu le Klondike, à en croire London, sont revenus, fourbus, alcooliques, avec comme seul gain, une pépite porte-bonheur en pendentif. Ceux qui ont connu Java ont eu un sort moins dramatique, quoique la déception a été à la hauteur des attentes, après quelques cycles interminables de Garbage Collector.

Cet ami qui se plaignait de Java, a aussi admis que ce langage lui a facilité l'apprentissage de la conception par objets et la notion de "Thread".

"Apprendre"…depuis la renaissance et jusqu'au début du 20ème siècle, les familles nobles apprenaient à leurs rejetons le grec et le latin. Non pas pour demander une adresse ou le chemin des toilettes dans un restaurant, mais juste pour… se distinguer. Il était alors de bon aloi d'auréoler son allocution de citations de Platon et de quelques proverbes latins.

Ce genre d'apprentissage élitiste avait pourtant une origine bien plus sérieuse. Les savants de la renaissance lisaient les écrits de leurs prédécesseurs grecs et latins, pour apprendre sur les réflexions anciennes et créer le système de pensée, qui distingua plus tard le siècle des lumières. Ces deux langues ont donc été perçues durant longtemps, comme vecteurs de savoir.

Ce mouvement est similaire à l'apparition de l'algèbre dans les démonstrations de physique du 19ème siècle. Grace à Newton, l'emploi d'équations différentielles s'est démocratisé et a ouvert la voie à de nouvelles théories mieux armées pour formaliser les observations informelles de Galilée. Cela a poussé, plus tard, des générations de chérubins, futurs apprentis nobelists, à verser dans l'étude du langage du moment, clé de toutes les portes de la science: les mathématiques.
Le grec et le latin ne sont plus appris à l'école. Sur des projets internationaux, le pragmatisme est de rigueur; on parle donc Globish! De même, les mathématiques sont de moins en moins considérées comme un passeport pour l'avenir social des enfants. On préférerait qu'ils apprennent le Jazz, la voile ou le Thaï-Chi.

Qu'adviendra t-il de Java?
Java est une langage qui s'inscrit dans la lignée des accélérateurs d'apprentissage. Il a démocratisé la conception par objets et par patterns. Il a permis d'élever la syntaxe des langages informatiques à un plus haut niveau, permettant ainsi de réduire la courbe d'apprentissage, de notions restées trop vagues même dans l'esprit de gens qui prétendaient le contraire: threads, accès concurrents, programmation réseau…etc
Nous sommes sûrs aujourd'hui que les langages informatiques modèlent le processus de pensée et donc d'innovation. Nous savons aussi que la richesse syntaxique et conceptuelle d'un langage, rendent réalisables des rêves d'architectes. Java fait partie d'une famille de langages dont les membres ont subi des mutations syntaxiques pour s'adapter aux mutations technologiques.
On continue d'étudier le grec et le latin à l'université…en plus d'autres langues. Les mathématiques sont toujours essentielles pour formaliser la science, en plus de la logique et des méta-langages.
Se demander quel langage sera celui de l'avenir, est réducteur de nos ambitions d'avenir. Il faudrait peut être se demander quels langages seront ceux de l'avenir. Cela conjugue d'emblée nos rêves au pluriel.

Solow VS Moore: entre paradox et conjecture

J'ai assisté récemment à un excellent séminaire autour d'ITIL et la gouvernance informatique, présenté par Romain Hennion de Thyses. Dans ce séminaire, qui se voulait un état de l'art, un débat a émergé en aparté de la présentation et a donné lieu à un échange que j'ai trouvé très riche d'enseignements.
Le sujet polémique portait sur la capacité réelle de l'informatique à dégager de la valeur. Selon Robert Solow, « L'ère de l'informatique est visible partout sauf dans les statitiques de productivité ». Selon Gordon Moore, le coût d'une puissance de calcul diminue chaque année et durant la même période, la puissance de calcul double pour le même prix.
Donc, d'une part, une puissance technologique en augmentation constante pour un prix de moins en mois élevé et d'autre part, le constat sévère que la productivité n'y est pas nécessairement liée.
La course au plus puissant et au plus complet aboutit souvent à la multiplication d'imperfections, qui finissent par éclipser l'effort de sophistication qui a été fourni en amont et donc, à moyen terme, cela fini par jeter le discrédit sur le produit, sur l'éditeur ou sur la technologie elle même.
Cela a été observé dans de nombreux projets informatiques voulant atteindre la perfection dès la première version. Il s'ensuit alors le sacrifice de la qualité sur l'autel des délais. Souvent, au tout début, lors de la phase de prospection, les utilisateurs n'en demandent pas autant. Ils acceptent, cependant les propositions alléchantes de l'éditeur qui leur propose beaucoup plus que la concurrence pour le même prix sur le principe de la loi de Moore. Il obtiennent un produit qui, finalement, doit souvent évoluer pour être corrigé ou optimisé provoquant retards et déceptions. Les utilisateurs ont alors des doutes sur la réelle valeur ajoutée du produit. Au mieux pour eux, ils factureront les pénalités de retard à l'outsourceur et au pire, ils seront obligés de reconsidérer leur stratégie en retard sur le calendrier. Tout cela est peu productif et rejoint le fameux paradox de Solow.
Un article de The Economist loue le retour au « POGE », le principe du "good enough" que l'on pourrait traduire par le "juste assez". Il s'agit d'un principe pragmatique tenant compte de la complexité des systèmes et de notre incapacité à prévoir tous les états-transitions possibles dans un système connexe. La stratégie consiste à réduire les ambitions fonctionnelles pour gagner en efficacité. L'exemple le plus frappant est le succès des NetBooks, ces ordinateurs portables sous-équipés mais remplissant parfaitement leur rôle: surfer sur Internet. Le succès a été immédiat.
Dans un monde qui se relève d'un cycle d'hyper-activité, il nous revient de discréditer le paradox et de réduire la conjecture.
Louable résolution, sommes nous tentés de dire...jusqu'à ce qu'une annonce d'Intel analysée sur le blog de Gilles Fontaine, nous apprend que le géant des circuits imprimés est en train de préparer une puce capable de doubler la puissance d'un processeur, pour le même coût avec une consommation d'énergie moindre. Ainsi, un datacenter de 200 serveurs, pourra être remplacé d'ici deux ans par un seul serveur.
Finalement, il faut se faire une raison: le moteur de la technologie est...la déraison!

Vous plaisantez monsieur Tanner

J'aime bien comparer un projet informatique à un projet de construction de maison. Juste pour souligner le...décalage.
Imaginez, une fois votre maison construite, que vous ne soyiez pas sûr que les murs puissent tenir debout plus d'un an. Alors, vous prévoyez une aile dédiée aux maçons. Ils habiteront chez vous pour qu'ils puissent colmater tous les jours les imperfections de leur propre travail.
Un exemple: aujourd'hui, le résultat de l'audit compris dans le contrat de TMA, indique que le bidet des toilettes du 1er, risque de s'effondrer dans le séjour au rez de chaussée. C'est très embêtant et ce n'est pas normal mais vous remerciez votre sous-traitant d'avoir été proactif. Car au fond c'est un peu votre faute. Vous auriez du opter pour du béton armé de bonne qualité avec un contrat de support « Platinum », au lieu de vous servir gratuitement dans la carrière désaffectée à ciel ouvert de votre région.
On vous dresse un devis et on vous propose un « backup »: durant les travaux, vous pourrez vous soulager chez les voisins. Le service est dégradée et externalisé mais reste dans la limite de la QoS. Une preuve quand même rassurante de résilience de votre SI.
Un jour vous décidez de construire une cabane dans votre jardin pour y entreposer votre matériel de jardinage. Devis de projet (hors contrat de TMA). Votre fournisseur en profite pour « expérimenter » une nouvelle organisation très à la mode, conseillée par un cabinet de consulting de renom (évidemment vous n'en savez rien). Le prix est cependant très compétitif. La raison: pour rogner sur le coût de la main d'œuvre, la cabane sera construite en Égypte et sera ensuite transportée jusque dans votre jardin. Une fois sur place, les rangements intérieurs ne vous conviennent pas. Ce n'est pas ce qui était prévu au départ, on ne vous avait montré jusque là que l'aspect extérieur. Retour en Égypte. Pour votre sous traitant c'est la banqueroute, les délais s'allongent, vous lui intentez un procès, vous vous séparez à l'amiable grâce à la brochette d'avocats qui vous ont coûté une fortune. Mais il y'a une note positive: vous avez retenu la leçon et capitaliserez pour le futur. Et puis vous êtes déjà heureux de ne pas payer des indemnités de résiliation de contrat. Vous optez pour une autre équipe de maçons. Ils vont construire la cabane directement dans votre jardin...et logeront chez vous entre temps. Pour leur commodité, vous allez aussi investir dans une machine expresso et un bon stock de dosettes, car vous avez d'autres projets en tête!
Là, le drame: vos finances sont en berne, le banquier bloque vos comptes et votre femme, excédée, demande le divorce. Vous quittez la maison sans vos boutons de manchettes après y avoir consacré toute votre énergie. Il ne restait que cette maudite cabane à terminer et vous auriez pu entamer la certification ISO 20000! C'est injuste! Mais vous allez rebondir. Vous actionnez votre réseu et fort de votre expérience, on vous propose un poste...de contermaitre dans une entreprise de maçonnerie. Avec un peu de chance, vous arriverez à séduire une riche bourgeoise qui vous accueillera sous son toit...dont vous aurez supervisé l'isolation.

YAM: Yet Another Middle Tiers Technology

Un article de JavaLoby a attiré mon attention. Encore une tentative d'Antonio Goncalves d'évangéliser les brebis égarées. L'article date déjà d'un an et ressemble à un cri du cœur: Pourquoi JEE 5, spécification de "rupture" n'arrive toujours pas à percer?! Je me suis posé la même question surtout quand je vois que la prochaine version JEE6 est déjà en gestation. Revenons à l'essentiel...
Qu'est ce qui représente la chose la plus précieuse pour une entreprise? Réponse: ses données et ses traitements métier. Il s'agit du bien le plus important que peut posséder une entreprise, son savoir faire. Il y'a souvent une association dans nos esprits entre la notion de bien précieux et la notion de coffre fort. L'entreprise possède son coffre fort pour y entreposer ce qui assure sa survie: ce coffre fort c'est le MainFrame! Même la direction générale sait ce qu'est un IPL. Non pas pour ces caractéristiques techniques mais surtout pour la frayeur tétanisante qu'invoque un arrêt du système informatique central. Il y'a toujours eu le MainFrame et le reste de l'informatique. Cette dichotomie est évidemment particulièrement palpable dans la distribution des budgets informatiques.
Jamais aucun dirigeant n'acceptera de sortir le capital de sa société hors du coffre fort, sauf pour le remettre dans un autre coffre fort au moins aussi sûr que le précédent. La technologie qui se substituera à ce coffre fort sera assurée d'une longévité enviable.
Unix a déjà perdu la bataille de ce créneau. Trop libre, conçu pour des esprits trop intelligents. Il a été transformé par ces pratiquants en technologie chaotique pour gourous rétifs et dispersés. il ne sera qu'une technologie de middle tiers, un système fourre-tout se battant avec d'autres systèmes alternatifs.
JEE est en train d'empreinter le même chemin. Un discours dispersé autour de cette technologie fait naître le doute dans l'esprit des décideurs. Son association avec Java et une politique de versions illisible, conjuguée à une suractivité communautaire et une multiplicité d'implémentations et de compléments sous forme de frameworks et autres APIs, fait penser que jamais la stabilité n'arrivera.
On ne sais plus si dans cinq ans, les choix d'architecture actuels ne seront pas complètement obsolètes voire hors de propos à cause d'une énième "rupture". On peut donc sans prendre de risque, déduire que JEE est condamnée à des projets "miettes" faute d'être suffisamment adulte pour se stabiliser et s'industrialiser.
Une réputation est très difficile à rectifier. Pour qu'une technologie survive, il faut que son discours soit homogène et que sa stratégie soit lisible. Il faut qu'elle se forge une réputation de stabilité, car la production n'admet pas l'incertitude et l'expérimentation. Il faut enfin que sa maîtrise soit assimilée à un savoir faire qui donnera naissance à un véritable corps de métier. Elle sera alors "bancable" et percera le marché vérouillé des coffres forts. Si JEE et Unix n'arrivent pas à redorer leur blason alors ils ne seront que des technologies de middle tiers...parmi d'autres.