Dans le cadre de notre partenariat avec Octo pour leur Université du SI (USI 2009 pour les initiés), je continue la série d’entretiens avec Didier Girard, directeur des opérations et de l’innovation de la SSII Sfeir, qui animera une session invitant les geeks et les boss à réfléchir à tout ce que Google apporte désormais aux responsables informatiques . Et à la façon dont cela est déjà en train de bouleverser le paysage économique.

De fait, si les Google Docs ou le serveur d’applications Java Google AppEngine sont loin d’être parfaits, ils sont tout à fait capables de remplir certaines fonctions (voire tout ce dont on peut avoir besoin, selon son profil ou le but de son application), gratuitement ou pour une dépense très modique. Du coup, ce sont non seulement les éditeurs de logiciels commerciaux mais aussi les acteurs du Libre qui sont obligés de s’interroger, en même temps que les DSI, sur leur stratégie.

Je ne sais pas si ce qui sortira de toute cette agitation autour du cloud et du Saas aboutira à quelque chose de vraiment exploitable par les grandes entreprises, mais au moins Google aura eu le mérite de secouer la fourmilière.

Interview de Didier Girard Lire la suite…

J’ai gagné mon pari avec un collègue d’IDG News Service : l’annonce faite hier soir lors de son Campfire par Google concernait bien le support de Java par son App Engine (serveur d’applications supportant jusqu’à présent Python), et non celui de PHP. Ayant donc obtenu confirmation ce matin, j’ai téléphoné à Didier Girard, directeur technique de la SSII Sfeir, grand dispensateur de sagesse via application-servers.com et grand manitou de GWT , dont le petit doigt me disait bien que quoi que Google allait annoncer, il le testait déjà depuis un certain temps (bon, en même temps, sachant que Didier sera l’un des intervenants de la conférence développeurs Google demain soir, ça paraissait logique). Interview. Lire la suite…

« La nature a horreur du vide. » C’est ainsi que Marc Jalabert, responsable de la division Plateforme et Ecosystème de Microsoft France, tentait l’autre jour de m’expliquer pourquoi une centaine de partenaires – y compris bon nombre de ‘coopétiteurs’ – se presse aux TechDays au Palais des Congrès de Paris, pour y tenir salon. De fait, il n’y a plus vraiment de grand salon généraliste, et Microsoft France a su montrer l’année dernière, lors de la première édition de ces TechDays, qu’on pouvait attirer des foules moyennant un programme technique bien maîtrisé et un coût d’entrée nul. (L’événement est même victime de son succès : on s’y presse, on s’y bouscule, et on est refoulé à certaines sessions. Vivement les webcasts !)

Car voilà la seconde raison : on peut ici, sans bourse délier, approfondir ses connaissances sur un vaste ensemble de technologies (Microsoft ou très liées à l’univers .Net, bien sûr, faut pas déconner, non plus). Plusieurs experts étrangers font en effet le déplacement à Paris, et c’est l’occasion rêvée de discuter avec eux. Citons par exemple Erik Meijer ou Don Syme. Et en France, quelqu’un comme Jean Ponce (qui bosse sur un projet lié au partenariat Inria-Microsoft), dont la session promet d’être intéressante. Citons aussi, côté Français, les experts de DotNetGuru (Sébastien Ros, Sami Jaber, Didier Girard…).

Mais la qualité technique ne tient pas, et de loin, à la seule présence de ces noms connus. Car à la différence de nombre d’éditeurs présents en France, Microsoft compte en interne un grand nombre de techniciens, des gens qui connaissent les produits et ne se contentent pas de passer des messages marketing. Quoiqu’on puisse penser de Microsoft en tant qu’éditeur, je tenais à saluer ces personnes-là, et la volonté de la filiale française de s’ancrer dans le réel, et de travailler avec les communautés d’utilisateurs.

Pour tâter un peu moi-même de la mise en place de conférences techniques (le Forum SOA), je sais combien la tâche est difficile. Donc avant de critiquer le contenu, je tenais à ce préambule

Bon évidemment, après un billet comme ça, je vais me faire taxer de pro-microsoftisme. Donc qu’on se détrompe, je peux dire du bien des gens (par exemple dire que Bernard Ourghanlian est un puits de science) tout en critiquant leur discours quand ça le mérite (en l’occurrence quand le même Bernard Ourghanlian explique le passé, le présent et le futur de la virtualisation, en restant focalisé sur les seuls développements de Microsoft). Autre anecdote avec le même Monsieur Technique et Sécurité de Microsoft France. Hier, nous avons parlé lors d’une conférence de presse des efforts réalisés par Microsoft pour optimiser le développement pour des architectures à plusieurs coeurs - en évoquant PFX, et au-delà. A terme, nous a expliqué Bernard Ourghanlian, .Net pourra générer du code parallèle, donc optimisé pour fonctionner sur du multi-CPU multi-coeurs. Parce qu’actuellement, comme on l’a vu dans la démo lors de la première conférence, si vous exécutez un code lambda sur un double quadri-coeur, seul le coeur 1 est utilisé. Diantre, me suis-je dit, l’OS ne s’occupe-t-il pas déjà de répartir les threads, comme Microsoft nous l’avait dit ? J’ai donc demandé à Bernard Ourghanlian quel mécanisme Windows met en oeuvre pour gérer les puces multi-coeurs. Réponse : “Windows s’en sort plutôt bien.” Oui mais concrètement ? “Il s’en sort plutôt bien avec une dizaine de coeurs.” Certes, mais je parlais du mécanisme. “Il profitera d’avancées comme la mémoire transactionnelle.” Bon, merci quand même.

L’agilité, c’est bon, mangez-en !

Bon, au moins, si vous n’êtes pas un expert en méthodes agiles (enfin, même si vous en êtes un, après tout), mais que vous vous intéressez à la façon dont on peut améliorer à la fois la productivité et la qualité des projets de développement, je vous invite à vous pencher sur le sujet. Et à venir aux Rencontres agiles 2007, organisées par Didier Girard et Bernard Notarianni.

J’avoue - un peu honteusement - que nous n’avons pas consacré beaucoup d’articles à ce sujet. Ceci dit, nous sommes aussi, en quelque sorte, tributaires de l’actu. Or, il y a une actu : ce séminaire gratuit du 18 décembre. J’ai donc sauté sur l’occasion pour apporter ma pierre à l’édifice.

Je vous propose en premier lieu une interview de Didier Girard qui, sous sa casquette de directeur technique de Sfeir, a mis sur pied une équipe agile pour répondre aux demandes de certains clients. Suivront un entretien avec Bernard Notarianni, et avec Claude Aubry, qui interviendront aussi lors des Rencontres agiles. Je compilerai le tout sur le site, mais j’offre la primeur aux plus agiles de mes lecteurs, ceux qui viennent sur le blog

Interview de Didier Girard

Quels sont les bénéfices des méthodes agiles ?

Les bénéfices sont étonnants. L’objectif est de maximiser la valeur : le budget investi par l’entreprise reste identique à celui d’un projet classique, mais on optimise le retour sur investissement. Avant de le vivre, j’avais du mal à l’imaginer. Le périmètre fonctionnel du projet n’est pas forcément défini au départ : on délivre au bout de 15 jours, donc le client peut remettre en cause son périmètre tous les 15 jours. Mais au moins cela part rapidement en production, et le client est content. On a vu des gens applaudir, il y a même de la jalousie de la part des utilisateurs non concernés par le périmètre et qui voient l’application sur le poste de leurs collègues, je n’avais jamais vu ça.

Pouvoir remettre un projet en cause aussi souvent n’a-t-il pas des implications sur son architecture ?

A partir du moment où on respecte disons les normes de câblage et de plomberie, bref l’état de l’art, le périmètre peut être remis en cause. Mais de toute façon, les fondements sont rarement remis en cause dans un projet.

Les méthodes agiles sont-elles accessibles à tous ?

Eh bien, tout le monde ne peut pas intervenir dans un projet agile. Il faut être capable de se remettre en cause, d’accepter la critique. Les méthodes agiles impliquent le devoir de s’améliorer. Un projet agile démarre tous les matins par une réunion où on se pose trois questions : ce que j’ai fait hier, ce que je vais faire aujourd’hui et si j’ai des problèmes. Si quelqu’un tire au flanc, cela se verra très vite. Idem pour quelqu’un qui a du mal à avouer qu’il a des difficultés. L’important pour le client n’est donc pas le choix de la SSII mais celui de l’équipe. Au sein de la SSII, je sélectionne les profils capables de mener l’équipe au succès.

Dans la mesure où une SSII gagne de l’argent sur les avenants au contrat dans le cadre d’un projet au forfait, quel est l’intérêt de passer à des méthodes agiles ?

Il y a un risque dans la mesure où on peut être sorti à tout moment - à la fin de chaque itération, en fait. En revanche, contrairement au forfait, il n’y a pas de prise de risque budgétaire. Si on livre effectivement en temps et en heure, et avec de la qualité – auditée par un cabinet externe – alors c’est ‘win-win’, pour le client et la SSII.

Du coup, tous les clients devraient s’emparer de cette méthode ?

Nous le proposons, mais tous les clients ne sont pas mûrs pour cette approche. Dans certains comptes, les interlocuteurs n’ont pas assez de poids pour remettre en cause la façon de travailler. C’est une méthode très responsabilisante : ce que le client aura, c’est ce qu’il aura demandé. Il faut assumer le fait que certaines fonctionnalités viendront en dernier, voire ne sortiront pas. Il faut aussi mettre en place des bonnes pratiques, que la recette, par exemple, soit rapide : si cela doit durer toute une journée, que fait l’équipe pendant ce temps ? Il faut donc automatiser la recette, éventuellement en créant les jeux de tests à partir des spécifications formelles. Il faut outiller l’agilité, sinon cela ne fonctionne pas.

Tout projet peut-il être candidat aux méthodes agiles ?

Certains disent que tout peut y passer. Pour moi, ce n’est pas tant un problème de taille du projet que de taille de l’équipe. On ne butera pas sur la méthode elle-même, mais sur la constitution de l’équipe. Si 100 personnes y adhèrent, il n’y a pas de problème ; on peut ensuite découper en équipes plus réduites. Il faut reconnaître qu’aujourd’hui, les succès en France sont plutôt avec des équipes d’une dizaine de personnes.

Alerté par Didier Girard , notre expert français à nous qu’on a sur GWT, et par Sami ‘gourou .Net’ Jaber , sur Volta, j’ai profité de ma présence au TechEd pour me lancer sur la piste de cette idée prometteuse : un modèle de développement retardant le plus possible l’exploitation des spécificités d’une plateforme. Le but, comme l’explique Erik Meijer, inventeur du concept, dans un PDF , est "democratize the clouds", autrement dit permettre à tous les développeurs d’écrire simplement des applications distribuées.

Hélas, un email à Erik Meijer et des discussions successives avec des responsables Corp de Microsoft m’ont confirmé qu’il ne s’agissait encore que d’un projet de recherche, connu de quelques responsables seulement dans la division développeurs. Maintenant, si "la communauté des développeurs", si chère à Soma, harcelait Microsoft sur le sujet, l’idée pourrait véritablement émerger et au moins faire l’objet de discussions ouvertes.

Vous avez déjà sûrement vu ce nom quelque part : Adam Bosworth, ex-architecte en chef de BEA , suite au rachat de Crossgain, et désormais vice-président de Google. Un monsieur, souvent qualifié de visionnaire, qui sait de quoi il parle, donc. Il s’est fendu d’une grande note , dans son Weblog, au sujet de la tendance Kiss.
Pour les non initiés, Kiss signifie "keep it simple, sloppy". Traduction littérale : gardez-le simple, négligé. Autrement dit, ne vous embarrassez pas en bâtissant d’énormes cathédrales, sachez aussi recourir au "vite fait" pour couvrir un besoin.
Adam Bosworth fait donc l’apologie du Kiss. Je vous conseille vivement de lire ce qu’il écrit, c’est bien argumenté et instructif. Certains commentaires le sont d’ailleurs tout autant, tel celui d’Eric Newcomer , CTO (directeur technique) d’Iona. En résumé, Adam Bosworth estime que les grandes réussites ressortent des principes du Kiss : HTML s’est imposé comme format d’affichage, plutôt qu’un .doc beaucoup plus riche ; PHP est bien plus utilisé pour les sites Web que des langages dits plus rigoureux… Il en vient ensuite à cet exemple typique de cathédrale que constitue l’ensemble des normes liées aux services Web : WS-Reliablity, WS-policy, WS-Routing, etc. Et se pose la question : pourquoi une telle complexité, que seuls Microsoft et IBM ont les moyens de comprendre, alors que du XML sur HTTP font largement l’affaire ?
Réponse intéressante de Newcomer (bon, il a aussi des produits à vendre, et je le soupçonne de connaître par coeur toutes les normes WS-quelquechose) : jolie démonstration, et affirmation vraie en théorie, mais qui ignore le contexte. Autant il peut être gênant, mais pas grave, de subir une défaillance lorsqu’il s’agit par exemple d’accéder à un blog, autant exposer une entreprise ou des services disons vitaux à des risques de défaillance peut être grave.
Or, tout l’édifice de normes est justement là pour prévenir ces défaillances. D’ailleurs, à voir le frilosité des entreprises à mettre en oeuvre des technologies qui n’ont pas été moult fois éprouvées ailleurs, on imagine mal le concept Kiss guider des développements d’entreprise. Faut-il pour autant l’éliminer complètement ? Je ne crois pas. Lors d’une conversation avec Didier Girard , directeur technique de la SSII Improve, celui-ci me disait qu’il fallait des architectes, pour mettre en place ces édifices, des structures suffisamment souples pour évoluer dans le temps, mais suffisamment rigides pour que des programmeurs puissent coder, agir selon les principes Kiss, sans que cela ne remette en cause la structure de l’ensemble, et donc sa maintenabilité et son évolutivité.
Une démarche plus mesurée, qui devrait avoir plus de succès en France, où l’on a la douce nostalgie de Merise et des plans quinquennaux