The most damaging phrase in the language is: We’ve always done it this way.
Grace Hopper
Mois : Mai 2013
Note de lecture : Les logiciels de gestion hautement intégrés, par Jean-Michel Tysebaert
Note : 1 ; Tromperie sur la marchandise.
En empruntant ce livre, je pensais apprendre des choses sur les progiciels intégrés, leur périmètre, leurs avantages et leur mise en place dans l’entreprise. Las, il y a clairement tromperie sur la marchandise! En fait, la seconde partie du titre parle bien d’ingénierie métier, et le livre est entièrement consacré à cela (avec parfois une paire de pages consacrés à l’aspect SI, histoire de justifier le titre).
Le lien avec les progiciels style SAP existe bien, et réside dans la philosophie de “l’ingénierie métier”. Le message transmis est en gros celui-ci: “la seule voie est la voie systémique, celle où les processus d’entreprise se conforment à des standards établis par des chercheurs, ceux qui ne font pas cela sont des cons”. Bref, une copie du message SAP, il faut adapter l’entreprise, pas le progiciel. L’auteur lâche d’ailleurs que c’est le progiciel qui suggère le besoin : on ne saurait être plus dans une logique de pseudo-spécification dictatoriale.
Bref, j’ai été déçu par la nature du contenu, le message et le style très académique, dont on voit nettement qu’il s’agit d’un support de cours. A propos de cours, un quart du livre est carrément dédié à la description des pratiques comptable, cela peut être intéressant dans certains contextes, mais est ici hors sujet. En résumé, le livre est à coté de la plaque pour aborder la problématique progiciel, et la pertinence du contenu “processus métier” est hautement discutable. En refermant la dernière page, outre un soulagement, j’ai eu l’impression d’avoir lu un ouvrage vieux d’un quart de siècle alors qu’il fut édité en 2001 ! Allez savoir pourquoi ? Fort heureusement l’édition et la distribution de ce livre sont quasi-confidentiels, faites quand même attention à l’éviter si vous tombez dessus…
Référence complète : Les logiciels de gestion hautement intégrés : Préparation par l’ingénierie de métier – Jean-Michel Tysebaert – Technip 2001 – ISBN : 2-7108-0788-2
Stoos Satellite Paris : qui sommes-nous ?
Au commencement…
Eh bien au commencement, il y a eu l’annonce de la conférence Stoos Connect à Amsterdam. Bien sûr, le Stoos Network existait avant cela, sans pour autant pouvoir revendiquer une longue histoire. Mais sur l’hexagone, il n’y avait rien d’organisé.
Afin de bénéficier de la conférence, Oana Juncu et Yannick Grenzinger ont pris l’initiative de rechercher un lieu nous permettant d’assiter à la conférence en livestream. Ce qui fut fait à La Cantine.
Autant le dire, nous n’étions pas nombreux. D’ailleurs nous ne le sommes toujours pas et ce n’est pas non plus notre but premier. Le livestream était assez médiocre, les interventions de qualité inégales, mais nous avons vécu nos meilleurs moments … pendant les pauses ! Pour les curieux, vous trouverez un compte-rendu (par votre serviteur) des différentes interventions ici (première partie), ici (seconde partie), ici (troisième partie) et enfin ici (dernière partie).
Bref, nous sommes sortis de là avec des sentiments mitigés à propos de ce premier Stoos Connect, mais avec l’envie de continuer ensemble pour voir où cela pourrait nous mener. Personnellement, j’ai bien aimé le groupe, ce fut vraiment la bonne surprise de cette rencontre et ce sentiment semble partagé.
Donc oui, nous allons essayer de faire quelque chose.
Au fait, oui : qui sommes-nous ?
Notre première action a été de créer une communauté Google Plus que nous avons pompeusement nommée : Stoos Paris. Dans le vocable du Stoos Network, chaque émanation locale s’appelle un “satellite”. Nous sommes donc le Stoos satellite in Paris !
Aujourd’hui la page de la communauté Google Plus est notre point de rencontre. Il n’y a pas d’association, pas de site web dédié, etc… Nous n’en avons pas l’usage aujourd’hui. Nous verrons plus tard si le besoin s’en fait sentir…
Puis nous avons eu notre première (et aujourd’hui unique) rencontre. C’était le 5 Février.
Quand je vous disais que nous n’étions pas nombreux…
Pas d’agenda compliqué pour cette première rencontre, mais le désir de répondre au “pourquoi”, “quoi” et “comment” de ce Stoos Satellite Paris. Nous avions aussi fait une vidéo, mais elle a hélas disparu avec le matériel ayant servi à la prise de vue…
Nous nous étions aussi fixé comme objectif de nous rencontrer à interval de 3 semaines ou 1 mois, ce que nous ne sommes pas parvenus à faire jusqu’à présent.
Prochaine étape
Nous n’avons pas abdiqué ! Nous allons de nouveau nous rencontrer courant Mai et voir quelles actions nous pouvons entreprendre.
Les femmes n’ont jamais eu envie de porter un fusil, pour moi c’est quand même un signe d’élégance morale.
Pierre Desproges
L’histoire des écritures, par Clarisse Herrenschmidt
Les échos sur la keynote de cette chercheuse du CNRS à Devoxx 2013 étaient arrivés jusqu’à moi par de multiples canaux. Cette présentation est en ligne, nous pouvons en partager le bonheur. A 70 ans (je crois), Mme Herrenschmidt a l’énergie d’une horde de geeks ! Et elle nous convie pendant 40 minutes à un voyage dans le temps depuis les premiers systèmes de comptage, jusqu’à Alan Turing !
Le support de présentation est moins utile, mais si vous souhaitez revoir à loisir les artéfacts présentés par l’oratrice, il est là.
Rencontre avec Manfred Mack
Damné RER C !
Je prévois mon trajet, je prends une avance raisonnable, et ce foutu train n’arrive qu’après m’avoir fait attendre 30 minutes. Damnation !
Cette rencontre avec Manfred Mack est un déjeuné-rencontre comme Christine Koehler en organise régulièrement. La dernière était en Février, une rencontre avec Christopher Schoch.
Cette rencontre-là avait pour but de mettre en lumière de possibles modèles d’entreprise du XXIème siècle et d’en discuter entre nous. C’est en fait l’objet de son livre, Pleine Valeur paru il y a une dizaine d’année.
On parle ici de co-création de valeur, ou comment se rendre mutuellement meilleurs !
Plus précisément, Manfred Mack évoque l’approche développée par Spi-Batignolles dans l’offre Concertance dont l’origine remonte à la réponse à un appel d’offre pour la construction d’une soufflerie pour un consortium regroupant Renault et Peugeot. Non seulement Spi-Batignolles a pu répondre avec un tarif plus bas, mais le coût final s’est même avéré encore moins élevé, sans pour autant hypothèquer la satisfaction du client !
Pour se faire, Concertance s’appuie sur 3 axes :
- La recherche d’optimisations en amont
- Un fonctionnement en équipe projet conjointe fournisseur-client
- La transparence
Les deux derniers points sont réellement à l’encontre de le la culture BTP, comme nous le confirme Manfred !
Le principe est d’avoir toujours : Coût < Prix < Valeur perçue
L’approche managériale est adaptée en conséquence : on demande ainsi aux managers d’être toujours capables de montrer comment et en quoi les plans qu’ils proposent contribuent à la création de valeur.
Les points abordés par Manfred Mack me rapellent beaucoup les principes du Lean tels qu’ils sont mis en oeuvre chez Toyota.
D’ailleurs Spi-Batignolles a fini par élargir cette approche à l’entreprise elle-même : si l’on considère les clients comme des partenaires, pourquoi n’en serait-il pas de même avec les collaborateurs ? C’est ainsi que l’entreprise a mis en place son projet “zéro accident” avec réussite, semble-t-il. Mais au-delà de cet exemple, il est frappant de constater l’influence de ce nouveau mode de pensée sur l’ensemble de l’entreprise.
Comme le dit Manfred Mack : on obtient au final une meilleure performance en abandonnant le focus purement financier pour la création d’une “sur-valeur”.
Le dernier point concerne les conditions initiales nécessaires : Une direction en recherche “d’autre chose” donc un PDG visionnaire.
Le monde du BTP est bien le dernier où j’aurais pensé voir ce type d’approche. Manfred Mack semble en tout cas être extrêmement enthousiaste sur ce qui a été accompli avec Concertance. Il endosse depuis un moment déjà un rôle d’évangéliste dans le monde professionnel comme celui de le formation des futurs diplômés.
Christine Koehler nous a proposé ensuite de discuter par petits groupes de 4, sur 3 questions gravitant autour de cette approche.
Dans mon groupe, la majorité des participants étaient intéressés par les questions d’intelligence collective et de co-développement. L’idée de “penser autrement” les relations entre client et fournisseur semblait en tout cas une pensée partagée.
Notre second tour de discussion a tourné autour des points importants de cette approche. Plusieurs éléments en vrac:
- L’importance d’un objectif commun entre client et fournisseur.
- La nécessité d’établir une confiance.
- Effacer la notion de rôle telle qu’on l’entends généralement, qui implique un retranchement derrière un périmètre et des responsabilités non partagées.
- La nécessité de travailler sur ses peurs et les peurs des collaborateurs. Et au contraire valoriser les personnes et les parties prenantes.
- L’importance de l’expérimentation.
La 3ème question était plus personnelle : en quoi cette démarche nous concerne plus personnellement ?
Chaque membre du groupe appréhende nécessairement ce point avec sa propre sensibilité, selon ce qui le touche le plus. Ainsi nous avons soulevés des points tels que :
- La déonthologie par rapport aux clients : travailler pour résoudre les vrais problèmes. Ce ne sont pas nécessairement ceux pour lesquels les clients nous ont appelés.
- Contribuer au plaisir dans le travail : Accomplir une mission non pas parce que l’on fait un travail que l’on nous a demandé, mais parce qu’on fait quelque chose d’utile, qui aidera réellement ce client en adressant son problème de départ.
- Gagner en légèreté : Rendre le travail plus agréable et plus efficace.
- Pouvoir faire plus demain que ce que l’on fait aujourd’hui.
Je vois un fil directeur à travers ces points : notre besoin semble de nous sentir en harmonie avec notre travail, d’assouvir un véritable besoin sinon physiologique, du moins intellectuel.
Pour finir Manfred nous suggère de réfléchir à cette question fondamentale qui guide cette démarche : Qu’est-ce que la valeur ? Pas seulement la valeur financière !
Cette question et d’autres points soulevés par Manfred Mack figurent dans le support que Christine a eu la gentillesse de mettre à disposition.
Agissez comme s’il était impossible d’échouer.
Winston Churchill
Note de lecture : How to Change the World, par Jurgen Appelo
Note : 6 ; Court, mais passionnant et instructif
Plutôt qu’un livre, c’est un livret de l’aveu même de l’auteur. Long, ou plutôt court de 70 pages et un petit format. Il vous durera 1 journée de lecture bien assidue ou plus si, comme moi, vous le lisez à dose filée. L’auteur de Management 3.0 n’a pas perdu la main, c’est sûr : c’est bien écrit, pertinent et ça repose sur des références sérieuses !
S’agit-il vraiment de changer le monde ? Parce que là, ça ne paraît pas très sérieux ! En fait, il s’agit plutôt de changer une organisation ou une entreprise. Donc un petit monde. Mais si 500000 personnes font de même, là peut-être… Mais nous n’allons pas extrapoler aujourd’hui.
Pour Jurgen Appelo, impulser un changement c’est agir sur un système complexe (un des thèmes favoris de l’auteur) en travaillant sur 4 aspects. Le premier chapitre, long de 8 pages expose cette approche dans ses grandes lignes.
D’abord « danser avec le système ». C’est le sujet du second chapitre et couvre 11 pages. Pour cela, Jurgen a un modèle (ou plutôt il en emprunte un). D’ailleurs, l’auteur a un modèle pour tout ! C’est beau la technique… Ici, c’est le modèle PDCA, la fameuse roue de Deming,
Après (ou en même temps, ou avant) avoir travailler sur le système, il faut travailler sur les personnes, créer la volonté de changer. Dans le chapitre 3 qui est dédié à ce thème, Jurgen nous présente le modèle ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) pour amener les personnes de la prise de conscience à l’action. 12 pages sont consacrées à cela.
Une organisation, ce ne sont pas seulement des personnes, ce sont des interactions entre ces personnes. Le chapitre 4 vaillamment intitulé « stimulate the network » s’appuie sur la courbe d’adoption des technologies (la fameuse courbe de Moore avec son fossé) pour aborder les différentes populations. C’est ce qu’aborde la substance de ce chapitre : innovateurs, early adopters, early majority, late majority et laggard. A chaque population, son approche ! 11 pages suffisent au propos.
On finit ce tour des aspects par l’environnement. Sur ce volet, l’auteur emploie le modèle des « 5 I ». Il y en avait 4 à l’origine, mais il en a rajouté un : Information, Identity, Incentives, Infrastructure et Institution. Le vilain petit canard est « Infrastructure ».
Le chapitre de conclusion remet tout cela en perspective.
C’est vraiment un petit opuscule, qui nous donne un peu l’impression de manger un bonbon acidulé : le goût est bon, mais il ne dure pas longtemps. Pourtant la substance est là, et je pense qu’elle va me servir de boussole quand je devrais aborder des questions d’agilification d’entreprise ! Un dernier point que j’ai bien aimé et m’aidera certainement : la check-list figurant en fin de chacun des 4 chapitres principaux.
Jurgen Appelo avait fait une présentation sur le thème de ce livre (pardon, livret)lors du printemps agile à Caen. Vous trouverez ici mon résumé sur cette présentation, ainsi que le support visuel de l’auteur.
Voilà un petit qui vaut chaque minute que j’ai passé à le lire !
Référence complète : How to Change the World, change management 3.0 – Jurgen Appelo – Jojo Venture BV 2012 – ISBN : 9789081905114
Il existe aussi un traduction française, faite par Yannick Grenzinger disponible en eBook chez Lulu.
Pourquoi CloudBees ? avec Sacha Labourey
Sacha Labourey n’est pas un inconnu pour moi. Pour vous non plus peut-être. Soat nous poposait une rencontre avec cette figure marquante du monde Java à la veille de Devoxx France (je sais, ça fait déjà un bail …), je ne pouvais que sauter sur l’occasion.
Pour ceux qui l’ignoreraient, Sacha Labourey fut le CTO de JBoss après le départ de Marc Fleury, mais c’est en tant que fondateur et CEO de CloudBees qu’il se présentait à nous ce soir-là.
En fait de présentation, j’ai hélas rarement mis de photo aussi médiocre sur mon blog, mais c’est ainsi. La voilà.
CloudBees propose une plateforme pour héberger la totalité du cycle de vie d’une application Java sur le cloud. En l’occurrence, il s’agit du cloud d’Amazon, mais ils travaillent activement à rendre leur plateforme indépendante de l’infrastructure du géant de l’e-commerce afin de donner plus de flexibilité au client.
Hardware as a commodity
A la base, il y a la conviction que l’on se dirige vers une commoditifaction (est-ce vraiment un mot ?) du hardware. Sacha Labourey évoque le parallèle avec l’électricité : si à ses débuts, il fallait posséder son propre générateur et gérer les aléas de la régularité de l’alimentation, aujourd’hui nous nous sommes “débarassés” du problème chez des prestataires. Nous n’avons plus que des prises de courant nous délivrant un courant normalisé, le reste est l’affaire de ce prestataire.
Ce mouvement inéluctable : spécialisation -> standardisation -> régulation, Sacha Labourey le voit s’appliquer aujourd’hui à l’infrastructure.
Doit-on aujourd’hui encore s’occuper des machines, de les configurer, gérer les mises à jours système et même les “piles logicielles” ? Existe-t-il une valeur spécifique à se construire sa pile logicielle spécifique ? Si elle existe, elle doit être marginale (du moins dans la plupart des cas) et ne justifie pas les efforts et le détournement de focus de la problématique métier que l’on souhaite adresser.
C’est là la proposition de valeur de CloudBees : rendre l’infrastructure aussi facile à exploiter qu’une prise électrique !
Cloud vs cloud vs cloud
On peut rappeler rapidement les 3 types de cloud proposés, ils sont déjà très connus:
- IaaS : Ce sont les briques de base de l’IT. On pense à Amazon EC2, Rackspace, …
- SaaS : Des solutions logicielles standardisées prêtes à l’emploi. Salesforce est probablement le premier nom qui vient à l’esprit.
- PaaS : Il s’adresse aux développeurs. L’objectif est de ne plus avoir à gérer les serveurs et les services standard fonctionnant dessus : serveur d’application, load balancing, etc..
Le focus est sur le “S” final : voir les facilités comme des services, disponibles sous forme d’API. Cette dématérialisation offre aussi un avantage fort : la possibilité de faire des essais (donc des erreurs) et de commencer petit. On peut ainsi itérer rapidement sans devoir attendre des mises à disposition de serveurs et des installations logicielles. Elles sont prêtes et peuvent être exploitées tout de suite. Et être abandonnées tout aussi rapidement (le serveur ne finit pas à la cave).
Pour Sacha Labourey, une architecture typique d’entreprise serait la suivante :
- Au niveau back-office : les systèmes “legacy”, très stables, intégrant peu d’innovation.
- Au niveau front : des applications pour mobile (par exemple) communiquant avec un back-end évoluant très rapidement au rythme des nouvelles fonctionnalités disponibles dans l’appli mobile. Cette partie est peu stable et est le siège de beaucoup d’innovations
- Une communication front / back selon les protocoles mis à disposition par le back-office
Aujourd’hui la partie front / produit est subordonnée aux frictions entre développeurs et départements “opérations”. Les personnes en charge des opération privilégient la sureté de fonctionnement et renaclent le plus souvent à déployer des solutions logicielles qui n’ont pas été validées en interne, ou en tout cas ne satisfont pas des critères d’acceptabilité.
PaaS et innovation
Pour améliorer la capacité à mettre en ligne, la tendance actuelle est le “devops”, faire travailler ensemble développement et opération et outiller les opérations de déploiement afin de pouvoir pratiquer très souvent des déploiement automatisés. Je fais là un gros raccourcis et ne rends probablement pas justice à ce qu’il y a derrière devops, mais l’idée est là.
CloudBees revendique du “no ops” ! Plusieurs facteurs sont nécessaire pour permettre cela. On verra aussi que c’est un peu une simplification, l’IT ne disparait pas.
- Standardiser les environnements : à l’image de l’électricité délivrée en voltage et fréquence constants, la standardisation des environnements est un facteur clé. Chez CloudBees, ces environnements standards sont les ClickStacks.
- Travailler en SLA : pour pouvoir se passer d’ops, il ne faut pas avoir à se soucier de contingences d’infrastructure telles que stockage, clustering, etc… Il faut pouvoir signer un engagement de performance, à charge du prestataire de faire les mises en oeuvre d’infrastructure nécessaires pour garantir cet engagement.
Avec le SLA vient la question du support : une plateforme intégrant des sous-systèmes tiers peut être sujete à des dysfonctionnements (ou des mauvaises utilisation) de n’importe lesquels de ces composants. Il est logique que le support de service intègre complètement le support ou la délégation de support de ces composants.
Bien sûr, cela n’a de sens que si l’on est capable de mettre cela en oeuvre non seulement sur l’environnement de production, mais aussi sur les autres environnements utilisés dans le cycle de développement : environnements de développement, d’intégration, de stagging, etc… Le support du cycle de vie de l’application est donc l’étape suivante logique. L’intégration continue y joue un rôle clé.
Cycle de vie applicatif et gouvernance
C’est Jenkins qui est au centre du cycle de vie applicatif chez CloudBees. Il faut dire que Kohsuke Kawaguchi, la figure emblématique de ce projet open-source est un des leaders techniques de CloudBees !
Aujourd’hui, la partie faible me semble être toute la partie acceptance testing, AB testing etc… Mais c’est déjà le point faible de pas mal de projets. CloudBees propose quand même un environnement de stagging permettant de tester ses applications en conditions réelles : beescloud.com
Dans cette image que Sacha Labourey nous dresse, nous voyons une entreprise avec de nombreux projets, sur chacun d’eux les développeurs font des choix indépendants transformant le système d’information en gigantesque tour de Babel. Justement ce que l’IT cherche à éviter et lui vaut cette image d’épine dans le pied. Quel doit être le travail et la position du département IT, alors ?
C’est ce que Sacha Labourey appelle l’IT pragmatique : laisser faire, mais rester informés. Puis travailler en consolidation des différents projets ensuite (comment ? mystère …). De toute façon, si on bloque les projets trouveront le moyen de passer quand même !
Donc l’IT ne disparait pas, mais elle cesse de s’occuper d’infrastructure pour se concentrer sur les workflow de données, de services, etc… Elle reste le gardien du temple.
Tirer les leçons
Sacha Labourey a une vision très radicale non pas de l’IT de demain, mais de celle d’aujourd’hui :
- Passer son IT sur le cloud inquiète toujours. Mais la peur ne peut pas être une stratégie ! Rester organisés à l’ancienne peut nous valoir de voir un département de 20 personnes se faire griller la politesse par “4 punks dans une cave” comme le dit Sacha !
- Il faut profiter des gains compétitifs que représentent des services prêts à l’emploi.
- Aujourd’hui, les investissements ne prenant pas en compte le cloud sont déjà de la création de dette ! Méditez là-dessus mes amis…
Ce que j’en vois
Sacha Labourey nous a bien secoué sur une vision du développement se passant dans le cloud, en rupture avec nos habitudes actuelles. Et il est très convainquant sur l’aspect des choses que nous n’avons plus à prendre en charge…
Pour aborder cette rupture, il faut permettre la montée en compétence progressive des équipes. Le ClickStart que propose CloudBees s’apparente surtout à des assistants logiciels. Il faut apprendre à travailler avec son usine logicielle dans le cloud. D’après notre orateur de la soirée, cela va vite. Mais quand même…
Accepter la standardisation : c’est une condition sine qua non.
On peut avoir un développement produit dans le cloud. Mais qu’en est-il de la communication front-back, si le back-office est dans les murs de l’entreprise ? C’est très probablement un point faible. A moins que le back-office soit lui-même dans le cloud, ce qui est la solution préconisée par Sacha Labourey. Un tel choix nous amène rapidement à des considération de vulnérabilité de notre entreprise, dont les avoir ont quitté les murs pour être localisés … à des endroits que nous ne savons même plus localiser ! Mais ne sommes-nous pas déjà, voir plus, vulnérables avec l’informatique chez nous ? Il y a eu pas mal d’échange avec Sacha Labourey sur ce sujet et j’avoue que ces arguments ne manquent pas de fondements. Je ne vais cependant pas les développer plus avant, cela m’emmènerai trop loin.
La présentation de ce soir-là avait un ciblage très managérial, j’ai un petit regret là-dessus, surtout que notre orateur est un expert de haut niveau. Mais ce point m’était connu à l’avance, je n’ai donc pas de regrets à avoir.
Si vous avez le courage de voir le contenu complet, la video a été mise en ligne par Soat.
Il vous faudra un peu de la persévérance, car la video dure 2h30 … et contrairement à ce que Sacha annonce au début, il oubliera de répéter les questions !
Il me reste à remercier Soat pour cette opportunité d’en savoir plus sur le développement sur le cloud en général et sur Cloudbees en particulier, avec l’un des grands noms du monde Java.
Soat a également mis en ligne sur son blog une présentation plus technique de CloudBees en détaillant les étapes de mise en oeuvre.
4 (bonnes) raisons d’aller au Scrum Boat le 21 Mai
Oyez, oyez !
Le Scrum User Group organise ce 26 Juin un “Scrum Boat”. Qu’est-ce que c’est ? En quelques mots :
- Une soirée entre agilistes, sur une péniche avec des ateliers (le programme va être publié très prochainement)
- Un cocktail pour échanger entre nous.
- Une balade sur la Seine, car nous serons sur une péniche et il serait dommage de ne pas en profiter.
- Une fin de soirée dansante dont la durée dépendra de votre propre résistance.
Vous voulez en être ? Qu’avez vous à faire ?
- Vous pouvez voter pour la ou les sessions qui attirent le plus votre attention. C’est toujours sur IdeaScale !
- Vous pouvez (devez) vous inscrire via la billetterie en ligne : eh oui, l’évènement est payant, mais la participation très modique : 30 euros.
- Voir les informations publiées sur l’évènement sur Meetup. Attention, vous pouvez vous inscrire via Meetup, mais c’est l’inscription via la billetterie en ligne qui fait foi.
J’avais posté quelques photos dans le post que j’avais fait à propos de l’appel à animateurs.
A l’origine prévu pour le 21 Mai, l’évènement a été reporté au 26 Juin.
Dépêchez-vous : le nombre de places est limité !
Software Freethinker 
