• les requirements sont flous ou manquent de clarté ou de detail
• le Product Owner peut liberer 80% au moins de son temps a l’equipe
• l’architecture doit être mature

Peu importe si ces critères sont justifiés ou non, ce qui est gênant c’est qu’on confond “critère de selection” et “contrainte d’application”.

Critère de sélection n’est pas contrainte d’application

Le problème est que ces critères sont définis à partir d’une culture et d’un cadre d’une organisation traditionnel. Si j’applique l’agilité sur ce projet dans mon organisation traditionnel, ça fait quoi ? mais justement … on veut faire de l’agile ou pas? ?

Disons qu’il est naturel de vouloir se fixer un cadre pour répondre aux projets : “ton projet ne corresponds pas, tous les risques sont cumulés pour appliquer correctement l’agilité”… Disons que tout n’est pas si simple.

Faisons une métaphore, imaginez que vous désirez vous rendre autonome dans vos déplacements de tous les jours… acheter une voiture ! oui certes mais vous n’avez pas le permis et en plus vous n’avez pas beaucoup d’argent !

Que faire … Tout d’abord passer son permis…! ça parait légitime car c’est investissement sur la durée, quasi indispensable… et ensuite acheter une voiture. Si vous n’êtes pas fortunés vous allez certainement acheter à crédit (surtout la première).

Si vous aviez à faire votre choix par rapport à des “critères d’acceptances”, comment cela aurait-il fait changer votre projet ? ça se serait certainement passé autrement, car vous auriez eu :

• critère no 1 : le véhicule doit se conduire sans permis
• critère no 2 : l’investissement du véhicule doit être très léger et correspondre à mon pouvoir d’achat

Pourquoi ce n’est pas cohérent ? car ces critères se basent sur votre capacité organisationnelle, financière, technique, culturelle actuelle. En plus tout le monde le sait les voitures sans permis coutent plus chère :-O

En fait il faut prendre en compte le changement nécessaire pour accéder à ce nouvel outils (formidable). Comme tout nouvel usage, il s’agit de prendre en compte les nouveaux modes organisationnels, et ainsi le nouveau paradigme cible. C’est ainsi que le changement de l’agilité s’opère.

Une fois le permis acquis et le financement obtenu, les nouveaux critères pourraient être :

• ne pas prendre une voiture trop puissante (car le funki’conducteur risque de rouler trop vite.)
• prendre un diésel (car le conducteur effectue de longues distances régulièrement)
• etc..

Je peux exprimer cette incohérence sur un autre axe : imaginez un chef de projet qui désire savoir si son projet peut être agile … vous passez votre moulinette agile et tout est négatif. Vous lui dites “impossible!, le PO n’est pas disponbile, les règles métiers sont compliqués, le projet est important, la technologie est cobol, … tout ça n’est pas très adéquat pour l’agilité. Mais si ce chef de projet a vraiment besoin de l’agilité ?  priorisation de la valeur, livraison fréquente … en dehors des contraintes structurel qui peut l’empêcher ? pourquoi ne pourrait on pas opérer ce projet en agilité ?

L’application de l’agilité sur un projet doit se baser sur des attentes et non sur des contraintes

Disons qu’il faudra plutôt mesurer l’attente, la motivation et pourquoi pas la capacité au changement de l’équipe à passer au nouveau mode opérationnel agile. ça serait plutot des critères subjectifs qu’objectifs ? certainement ! De toute façon il s’agit de comprendre l’agilité par l’équipe concernée et de déterminer elle-même si elle cela va lui apporter de la valeur.

L’application de l’agilité s’inscrit dans un décalage organisationnel, culturel, humain & technique, du coup nos critères habituels (issus d’un paradigme traditionnel) ne sont pas valables. Il s’agit de se fixer dans le contexte cible agile, et ensuite on vérifie si on peut atteindre cet objectif. 

Bref .. Enter the matrix! :

Voici quelques idées (que je n’ai jamais appliqué tel quel). Un projet peut aborder l’agilité, si :

Attentes : 

• Le besoin en exploration/expérimentation fonctionnelle est forte
• Il y a un fort besoin de valeur opérationnelle rapide
• Il y a un fort besoin de réduction des risques techniques
• Il y a un fort besoin de piloter le projet par la valeur

Motivation:

• le responsable de projet maitrise les principes agiles et est très motivé à initier l’agilité
• Le manifesto et la philosophie agile sont compris et appliqués
• …

Capacité au changement :

• Le product owner / le scrum  master / responsable ont les capacités de faire face aux difficultés hierarchiques et politiques lié au changement
• Le travail en collaboration, en communautés au sein de l’entreprise sont déjà utilisés.
• …

Si vous avez des idées.. ?

Xebia (avec certains partenaires juridiques), ont eu l’initiative de publier, sous licence creative common, un template de contrat agile open source. Je me suis donc précipité  étant donné que c’est un sujet que j’estime, ayant travaillé sur la mise en place d’une contractualisation chez plusieurs clients (notamment pour le premier projet agile CNRS) , et dernièrement chez un grand équipementier technologique militaire.. ekito (boite dans laquelle je travail) étant tiers de confiance “agile”.

Effectivement l’idée d’un contrat agile générique est séduisante, pour moi la position en tant que prestataire/client/agiliste est la suivante :

Les formes de contractualisation agile sont très variables du contexte du client, du prestataire, et surtout de la relation entre les deux.. chaque contrat est donc (très) différent, cela dépend aussi fortement de la condition du projet au sein du client ! … en fait tout dépend de la manière dont chacun veut prendre et partager les risques. Chez un certain client, on ne voudra absolument tolérer un partage de risque , chez d’autre ce n’est pas un problème.

Voici donc mes remarques :

• je pense qu’il manque quand même les points essentiels d’un contrat agile : comment & par qui, est estimé l’effort (içi en points), comment est organisé le travail en équipe intégrée, le cérémonial.. et la disponibilité des personnes (par exemple si le Product Owner n’est pas du tout disponible et que les développeurs sont bloqués  que se passe t’il ? ), il manque aussi la définition du niveau des “spécifications” : comment et jusqu’a quel niveau les stories sont spécifiés ?

• l’engagement coté prestataire porte notamment sur la livraison minimal d’une partie du sprint backlog (appelée ici prédictibilité) et sur la productivité. Je pense que ces deux points ne sont pas l’idéal, car l’engagement est partiel sur le premier (75%). Pour le deuxième (engagement sur la productivité) cela amène souvent aux dérives qu’on connait sur les projets traditionnels, c’est à dire tout faire pour avoir une bonne productivité au détriment de la qualité.

• je trouve que le contrat parle (trop) des principes de développement (beaucoup de place à XP notamment) ce qui intéresse et rassure les équipes techniques, mais apporte de la confusion aux juristes et acheteurs.

• vu que le travail se fait en toute transparence et que le client connait les équipes, comment le prestataire estime le nombre de développeurs à positionner, c’est un point essentiel important pour le client.   la vélocité est elle utilisée pour calculer les effectifs?

• on ne parle nul part (sauf erreur) des points métiers au niveau des stories (business value/valeur commerciale), cela veux t’il dire que c’est la sauce du product owner uniquement et que le prestataire n’a pas connaissance ? comment est priorisé le backlog est ce le procut owner ? Mais que se passe t’il si un problème de cohérence amène le prestataire à revoir ce positionnement ?

• je trouve qu’il manque un exemple de backlog avec les stories.
• il n’est pas abordé la notion de confiance et de bon sens de chacune des parties (client/prestataire), “jouer le jeux de l’agilité” qui permet aussi de partager les risques … mais attention , souriez vous êtes filmé ! c’est-à-dire que si quelqu’un ne joue pas le jeu on peut préciser dans le contrat quels sont les points de sorties.
• je ne trouve pas claire la clause de réajustement, notamment avec l’intervention d’un médiateur

• comment est gérée l’intégration continue, sujet souvent sensible, qui doit être le plus intégré possible chez le client, et en général le prestataire va vouloir utiliser ses propres outils de productivité.

• il n’y a pas de definition of done

• il est inscrit les engagements côté prestataire, mais il manque ceux du client. Par contre j’ai l’impression que cette proposition a tendance à favoriser le prestataire en terme de partage des risques.

• on ne parle pas du tout d’outil agile de partage du backlog, est ce que tout est par postit ? (sujet souvent abordé)

• je pense qu’il y a une bonne description des pratiques agiles, par contre cela peut porter à confusion, par exemple que veut dire la présence du manifeste agile ? disons qu’il vaudrait mieux faire un lien sur un site de référence agile plutôt que d’incorporer les éléments génériques agile de scrum ou xp.

• on ne parle par de l’amélioration continue, et comment la gérer ?

• au dela du contrat agile ce qui est intéressant aussi c’est le workflow global de la contractualisation : par exemple comment comparer les propositions de plusieurs prestataires (uniquement le prix ? )

sur la forme :

• 52 pages pour un template de contrat agile, je trouve ça beaucoup ! (par exemple l’appel d’offre finalisé du CNRS en comportait 50 avec les annexes)
• il faudrait un support plus collaboratif, comme un wiki
• et enfin … pour les prochaines versions! il pourra être abordé les contractualisations au niveau du secteur public par exemple, très différent (et beaucoup plus complexe) juridiquement.

Conclusion :

Alors un ”contrat agile open source” est-il légitime ?  Même si pour moi chaque contexte est tellement différent,  l’idée de partager un template est une excellente idée. J’approuve donc le sens de cette approche avec les réserves ci-dessus…  .. disons que la réflexion est grandement intéressante, et permet surtout d’avancer sur les principes, de manière collaborative.

Maintenant, appliquer “tel quel” ce contrat n’est pas possible bien entendu, pour moi. Donc si l’objectif de ce projet est d’apporter de la valeur “intellectuelle” & agile aux clients et aux prestataires, alors OUI.

Donc bonne continuation a ce projet, et dites-nous comment y participer (peut être autrement que par le mail fourni, notamment avec une plateforme plus collaborative ?)

Souvenez-vous de “terra incognita”, cet endroit où l’information est inconnue de la DSI, mouvante, émergente, non structurée… la DSI est bien incapable de la connaitre. Car la DSI n’innove pas, Monsieur, la DSI est dans l’opérationnel. Alors la solution ne proviendrait-t’elle pas de structures (jeunes) qui mettent à disposition des nouveaux services à forte valeur ajoutée, qui utilisent l’information non structurée du terra incognita…

C’est-à-dire que la structure idéale du Saas permettrait à ces entreprises innovantes de proposer des services de A…Z… en terme de processus métier. Par exemple une entreprise qui propose des services de réservation de voyage complets, entre la réservation de l’hôtel, de l’avion, du train…. tout ça grâce à terra incognita. Et cette entreprise Saas fournirait une interface à peut prêt stable aux entreprises… Dans un environnement sécurisé.

En effet, pourquoi pas sous-traiter la gestion de l’information mouvante, émergente, et non structurée  ?

Culturellement, la DSI ne pourra pas maitriser elle même ce milieu, car le risque est trop élevé. Alors disons que terra incognita sera bien un nouvel eldorado de l’information et ses ressources infinies pourraient rapportées très gros…

Alors, oui… “in the beginning, long time ago”*.. l’homme a bestialement tué, élevé, manger ces bêtes sauvages …  l’homme a reconnu “Un visage réellement sale et une queue frisée*” , qu’il a fallu ensuite nommé, car ces sales bêtes à quatre pattes vivaient auprès des hommes…. elles devenaient de plus en plus familières…. “je pense que je vais l’appeler cochon”*.

Si l’homme a dû nommer les animaux, et qu’il a réussi à dresser la bête, grâce aux progrès technologiques,  il est passé à l’internet directement : – ) ; il a alors essayé de nommer l’internet… enfin de nommer l’information qu’il trouvait sur l’internet.

Au début c’était un peu difficile, et comme l’information n’a pas de nom, il a fallu trouver un moyen de l’éduquer pour l’élever, de l’appeler, de la transmettre … Dans un premier temps Il a dû se contenter d’utiliser des “mots clefs” pour appeler ces pages webs.

Le problème des mots clefs et qu’il obtient des dizaines de résultats. Et en plus ces résultats sont issus d’une vision un peu arriérée (hier) et surtout d’une page statique … une genre de page (déjà) morte. alors qu’à l’homme on lui demande de savoir ce qui se passe à coté de lui, maintenant, par exemple quand il utilise son instrument de déplacement appelé “voiture”. Quoi bon d’avoir des pages mortes.?

Il a donc eu l’idée de nommer l’information par rapport à ses envies, ses amis , sa situation … c’est alors que “man gave name to all his activities” … bon disons que l’homme a donné un nom a ce qu’il fait, tous les jours, avec qui et comment , et où… c’est ainsi que l’homme obtena plus facilement l’information qu’il désira, en temps réel.

J’espère que vous vous retrouverez… In the beginning, long time ago… google search nous a aidé à trouver l’information, maintenant facebook ou twitter ou tout autre réseau social va nous aider à obtenir l’information, sans la chercher. De plus elle aura un sens par rapport à ce que vous vivez… amis, envies, occupations: là, maintenant.

Oublions les mots clefs… et surtout gardons les noms uniquement pour les animaux.

Si vous voulez la suite, écoutez la chanson de bob…

*reprises de la chanson

Première rupture : Le Gros système

Deuxième rupture : La Direction du Système d’Information

Troisème rupture : La modélisation du besoin métier & l’éclatement des compétences informatiques

Quatrième rupture : Externalisation & Gouvernance du SI

Cinquième rupture : L’agilité

Sixième rupture : ?

Peu importe ce que définit chacune de ces ruptures, (tout est dans le titre), ce que je voudrais essentiellement, c’est orienté le lecteur pour qu’il réalise à quel point l’informatique a régulièrement présenté des palliatifs pour les problèmes qu’elle a rencontré… par exemple, externaliser les développements pour être plus agile en ressource … ou modéliser le métier par des concepteurs pour mieux définir le besoin…  ces palliatifs peuvent sembler une bonne idée à ce moment-là, mais avec du recul peuvent se révéler être d’une certaine incohérence, voir dans le mauvais sens par rapport à ce qu’il est voulu.

L’agilité est l’une de ces ruptures (elle paraitra peut être décalée à l’avenir : certainement) en tous cas ce qui compte c’est comprendre pourquoi elle est une solution aux problèmes actuels. (Pour la sixième rupture, j’ai des idées… si vous en avez, je suis preneur !)

power flower! ça colle bien à l'agilité ça

Jeudi 4 novembre s’est déroulé l’agile tour de Lille, ou j’ai présenté une conf : “Gérer son backlog avec Greenhopper”. C’est la deuxième session agile tour que je présente cette année, en tant qu’ekito.

La journée avait très mal débuté pour moi, car j’ai été dès 5H pris en blocage par un barrage (manif retraite) à l’entrée de l’aéroport Blagnac, en discutant un peu j’ai pu passé le barrage, mais j’ai du laissé ma voiture en plan … heureusement je l’ai récupéré sans PV ni sabot, mais je n’ai pas le seul. OUF.

Et me voici arrivé à la ville des chtis que j’ai quittée il n’y a pas si longtemps…, distante de 1000km de toulouse, un autre monde quoi. En tous cas c’est avec joie de retourner au pays des chti !

A 14H le public arrive, beaucoup d’amis et d’anciens collèges… D’ADEO (leroy merlin) : Christian Verlinde – Responsable CMMi & Méthodes, Frederic Lebail – Architecte, Olivier Hesdin - Architecte) et d’Oxylane (Stéphane Fasquel – Responsable des dev , Alexandre Godin – Coach Java & Agile, Pierrick Durrand - Chef de projet & responsable produit, Bastien Roger - Chef de projet & responsable produit d’un PLM), Mais aussi des personnes très sympathiques venant des SSII (notamment Pascal Lecercq - Architecte à Proxiad)

Voici les présentations auxquels j’ai assisté:

Céline STAUDER – Optimiser le ROI de votre produit avec une bonne priorisation de votre backlog

La présentation de Céline fait le focus sur l’un des points essentiels de scrum : la création des user stories et leur priorisation. Il y a un point que j’ai retenu (parmi d’autres), c’est la possibilité de faire diminuer la granularité d’une user story lorsqu’on passe d’un backlog à l’autre … du product backlog au sprint backlog. En gros la granularité s’affine pour arriver à un élément idéal dans le sprint (pas trop gros biensur). Cela correspond donc à l’affinement de la profondeur fonctionnelle de la user story. Intéressant. (pour ma part j’ai pour habitude de créer la user story avec une certaine granularité, et n’y bouge plus pendant son cycle de priorisation).

D. Thouvenin – Trois clés pour intégrer les retours de bugs dans Scrum

Scrum fait l’impasse sur les bugs, a chacun de trouver une solution, l’idée ici est de définir un protocole de priorisation, et en fonction de la”criticité”/”facile à corriger” le bug est soit traité à chaud, soit réintroduit dans le backlog. Exposé intéressant.

Pierre Pezziardi – L’informatique conviviale: libérez les énergies de la DSI !

J’ai fait le déplacement sur Lille “aussi” pour participer à son intervention, Pierre Pezziardi est l’un des fondateurs d’octo, DSI de la bred maintenant. Le thème “informatique conviviale” me tenait à coeur, car elle correspond à une vision SI (Management du SI) de l’agilité, et notamment d’une approche Lean de la chose. Ce qui est intéressant dans la démarche de Pierre est le coté “organisationnel”, c’est à dire purement humain lié à l’organisation de l’entreprise et à sa restructuration en petites équipes : pour éviter les silos entre les équipes, il souligne en quelques sorte, que la seule issue est bien basée sur l’humain. Le deuxième point que j’ai retenu est l’importance des tests, même dans un système legacy. Effectivement avec l’agilité, le goulot est bien les tests, seule solution : les automatiser. Présentation extrêmement intéressante, d’autant que Pierre est un excellent orateur. Il donne la vision d’un DSI éveillée.

Gildas Le Nadan – Le mouvement devops : synergie développement/exploitation et plus encore

Didier Girard m’avait parlé de devOps sujet intéressant pour rendre l’infrastructure de l’entreprise plus “agile”. Gildas nous a merveilleusement éclairé sur ce principe émergent : c’est à dire liée l’exécution (le run, la prod) des applications à de la valeur… en général on fait l’impasse sur l’importance de ce lien. En gros il s’agit de créer une agilité entre les études et la prod (d’ou le terme dev – ops) enfin parlant même entre l’entreprise et la prod, car elle apporte autant de valeur que les études. Merci à Gildas, ce sujet va m’intéresser, car il correspond à une des clefs de ma vision “labs” de l’informatique (cf prez innovation et DSI ) .

Voilà, excellente succession de conf donc!

un peu d'art brut dans un monde d'agiliste

Concernant la mienne, Gérer son backlog avec GreenHopper, je suis plutôt satisfait, la salle était comble, pas mal de questions et un intérêt pour le produit. Le challenge de faire une présentation en 20′ a été réussi et j’attends avec très grand plaisir vos commentaires (possibles ci dessous) ! Maintenant j’ai peut être été vite sur certains sujets, d’ou une frustration. Mais l’essentiel était d’abord avoir une première idée.

Les organisateurs (Julien Jakubowski - Octo, François Wauquier - Sfeir, Jérémie Hattat – Proxiad) ont été très brillants et on réussit leur journée. Bravo à eux !

La soirée s’est suivi avec un after, et on a pus disctuer avec Guillaume Duquesnay - consultant chez octo, Ignacio Lizarralde – Consultant octo en mission chez ETO. Laurent Bossavit, Agiliste fondateur de l’institut agile. (j’oublie d’autres personnes autour du bar, si quelqu’un pouvait m’aider.)

J’ai longuement discuté avec Guillaume Lours, agiliste et architecte Java de proxiad Rouen, très intéressant et je compte le rencontrer au futur agile tour de rouen!

Et c’est à ce moment précis que la plus belle récompense et révélation de la journée apparue : il s’agissait d’une découverte venant des Ardennes belges : LA CHOUFFE (il devait être 21H00 … très tard pour ce genre de rencontre)

agile ch'tour: la révélation de la journée!

et comme les grands esprits se rencontrent on a pu trinquer avec Laurent Evain – fondateur d’iLove-web et de diiink.tv et Thibaut Bayart – Entrepreneur, qui sortaient tous de l’apéro entrepreneur (dans le bar d’a coté … ça partait mal, car on commençait à refaire le monde, heureusement que le bar fermait, on y serait encore. ça nous a pas empêché de finir par un welch cérémonial (au regrets de Didier Girard qui n’était pas là) au resto “Les Moules” qui ne ferme pas de la nuit.

Le lendemain a été très très dur après une nuit de 4H et des problèmes d’avions 1H30 de retard, le pire c’est que le contrôle de sécurité n’a pas permis d’importer dans le SUUUD ma Chouffe emportée, destinée à faire un cadeau à Claude Aubry… dommage.

je suis arrivé chez mon client pas du tout agile (le client final, pas l’équipe avec laquelle je travaille), où je suis scrum master. La dure réalité quoi, les illusions et utopies de la veille n’ont qu’a bien se tenir !.

Le thème a suscité beaucoup de réaction (commentaire sur ce post).

• Les DSI actuelles doivent changer pour faire face à de nombreux nouveaux défis
• Les DSI doivent accepter la mutation pour se rapprocher des métiers et de ses clients.

Comment mettre en place une organisation qui permette l’émergence de l’innovation… sur la durée ? Il s’agit de comprendre comment est-il possible pour la DSI de proposer une industrialisation pour les projets innovants. L’entreprise innovante est-elle simplement une entreprise plus agile ?

Au-delà de l’aspect contextuel, je m’efforcerai de présenter une vision possible pour mettre en place une organisation permettant d’introduire des sujets innovants au sein d’une DSI. Mais l’innovation peut elle s’y inscrire ? il s’agit probablement d’un paradoxe, car pour être innovante, une DSI doit être industrialisée.

Voici quelques titres de thèmes que je compte aborder (en cours d’écriture) :

1. 2010: L’odyssée de la D.S.I. (ou en est la DSI ?)
2. L’écosystème IT est perturbé, CARL ne peut plus contrôler. (les métiers prennent le contrôle)
3. bienvenue dans l’empire du partout, de la profusion… mais surtout de l’éphémère ! (émergence de nouveaux modèles)
4. Organisation innovante : pas besoin d’inventer ! (entreprise 2.0, entreprise plateforme ?)
5. everywhere, everybody, everything (l’innovation n’est pas une direction)
6. naitre et  (souvent) mourir
7. téléphone maison (industrialisation des projets innovants)
8. l’humanité sauvée : la sécurité, enfin pas si sur… (sécuriser le S.I.)
9. La guerre froide (le financement)

Je suis bien sûr attentif à vos commentaires !

résumé de la présentation :

L’entreprise a de plus en plus besoin d’avoir un rôle d’anticipation, en terme technologique, mais surtout en terme d’usage. Les DSI sont au coeur de cette innovation. L’iPhone, la géolocalisation, les réseaux sociaux , l’ubiquité, l’ergonomie… sont des exemples qui ne peuvent être traités de manière traditionnelle. Le client final va être amené à pouvoir accéder concrètement à ces nouveaux concepts pour permettre de valider les nouveaux usages, ou pourquoi pas, lui même participer à l’innovation. Cela impose de mettre en oeuvre une infrastructure adéquate où les applications pourront être testées rapidement dans des conditions réelles.

L’image est issue du film “2001: L’odyssée de l’espace” de Stanley Kubrick.

Chapitre 1 : Émergence des nouveaux défis
Chapitre 2 : Réponses apportées par l’agilité
Chapitre 3 : Utiliser scrum comme méthode opérationnelle
Chapitre 4 : Déroulement itératif d’un projet scrum
Chapitre 5 : Planifier une stratégie agile
Chapitre 6 : Sous traitance d’un projet agile
Chapitre 7. L’usine de développement logiciel
Chapitre 8 : Gouvernance du S.I. Agile
Chapitre 9. Retours d’expériences
Chapitre 10. : Bibliographie & Webographie

Une première partie, assez importante, permet de présenter les nouveaux défis des DSI ou des petits projet et le pourquoi des méthodes agiles.

Globalement le positionnement de l’ouvrage est axé sur la mise en place d’une méthode agile adaptée pour l’entreprise, avec les problématiques de sous traitance, de communication, d’adhésion par les différentes organisations de l’entreprise, mais aussi de ressource humaine. La partie plus opérationnelle scrum est traitée sur deux chapites (3 & 4). La partie Gouvernance du S.I. Agile permettra d’avoir une vision globale de l’agilité par rapport à plusieurs projets agile (scrum ou non) et j’introduirai l’agilité en terme d’innovation du S.I. J’aimerai aussi aborder de manière importante le rôle du Product Owner.

J’essaye sur tous les aspects abordés d’expliquer le pourquoi de tel ou tel règle, pour que le lecteur l’applique en la comprenant, ce qui essentiel pour la réussite d’un projet agile.

Je suis en ce moment en train d’écrire une première partie de 10 pages (début du chapitre 4) que je dois envoyer à ENI le 4 août. Comme ce qui est préconisé dans les méthodes agiles, je soutiens fortement le feedback utilisateur des lecteurs, ce qui permet de s’améliorer. Ainsi n’hésitez pas à réagir

Merci!

Avez-vous déjà rencontré ces “magasins éphémères” qui ont une date de fermeture programmée… il s’installe à côté de chez vous, en faisant un coup de buzz local… ils vendent leurs produits et s’en vont … Peut être était-ce le fameux magasin Toys’R'Us Express qui ouvre uniquement pendant les fêtes de noël et qui disparait ensuite…

Ce concept intéressant en termes marketing (mais désastreux en termes sociaux, mais c’est un autre sujet) marque le pas sur une nouvelle ère, qui s’engagera de manière structurelle (jetez un oeil sur cet interview L‘éphémère n’est pas une mode éphémère” de Gilles Lipovetsky auteur de  L’empire de l’éphémère, Gallimard)

Quelle sera la conséquence de ce passage à “l’ultra rapide” , ou les produits seront consommés qu’une fois, puis jetés.

Un exemple flagrant : prenons  le principe des “App Store” , et celui d’Apple : les applications iPhone, qui sont acquises à un prix minimes sont utilisées très peu de temps puis sont oubliées  … ils s’en vendent pourtant des millions. Par leur prix accessible, les consommateurs se permettent de faire l’acquisition de plusieurs applications… qui ne sont pourtant pas des produits “phares” ou “connus”. De part l’infidélité croissante des consommateurs (à leurs produits, à leurs marques) : l’usage de ces produits va devenir de plus en plus ponctuels. Cela va créer disposition particulière pour offrir la possibilité au consommateur d’acquérir encore plus de produits très variés et donc enrichir cette bonne vieille longue traine…

Ce principe de consommation, ou de répartition a été identifié par  Chris Anderson qui explique la découverte de cette surprenante réalité : ce n’est plus quelques produits qui concentrent l’essentiel des ventes , mais ce sont des multitudes et très variés produits qui vont constituer le 98% des volumes.

Pour faire face à cette variété, il est nécessaire d’oublier les méthodes traditionnelles de définition des produits… ou la conception et la production du produit prends des mois…  il va être nécessaire d’offrir un modèle ultra rapide qui va propulser une offre “variée” et “éphémère” , c’est à dire présente au bon moment au bon endroit …

Raison de plus pour adapter l’organisation des entreprises pour un modèle plus “agile” et “innovant”.  (cf. mes articles précédents : Le protectionnisme d’Apple : nécessaire (pour Apple) ? , Quelle sera l’entreprise 3.0 ? et Positionnement des différentes formes de Management )

Le “tout numérique”*  et l’arrivée de la génération “Home Numericus”** devrait forcer ce passage au tout éphémère et à la longue traine, le sujet est donc passionnant et ne fait que commencer…

*: c’est à dire l’informatique partout
** : référence aux génération Y,Z… qui connaissent très bien internet

Pour cela j’ai utilisé quatre grandes “directions” : organisation taylorienne, au plus juste, apprenante et dite de structure simple. Et j’ai positionné les différents types d’organisations (de management) par rapport à ces tendances.

Le graphique ci-dessous essaye de résumer ce positionnement. On peut dire par exemple que les organisations “taylorienne” et “au plus juste” sont les plus intensives en termes de rythme de travail. Les organisations de type “apprenantes” sont les plus innovatrices (on s’approche des besoins du client et on s’éloigne des problématiques de la production).

Ce graphique est toujours en revision, j’aimerai votre avis pour le faire évoluer ! déjà merci à Grégoire et François pour leurs commentaires.

C’est une décision très extrême, ressentie comme un retour en arrière en termes de bonne pratique pour les développements informatiques (les tendances étant l’open source), pourquoi aller à contre-courant ?

Par cette décision, Apple expose ainsi son plus gros point faible… très historique, c’est-à-dire le “déclin” qu’il a failli connaitre à partir de 1990, à cause de la concurrence grandissante des PC (offrant des machines moins chères et surtout proposant eux aussi une interface graphique). Si l’entreprise Apple était une personne, cette décision serait elle …comment dirais je, à cause d’une contrariété passée… ? le psy verrait en Steve Jobs, pardons en Apple surement la chose suivante : N’est ce pas une veille trahison, venant d’un certain bill gates, qu’Apple a perdu du terrain de l’ordinateur de bureau à cause des PCs installés avec Windows ?

Et si apple avait protégé son innovation sur son OS graphique et utilisation de la souris : Microsoft n’en serait surement pas là aujourd’hui ?

Plus récemment Apple se bat avec Adobe qui ne veut pas du Flash dans ses iPhone pour des raisons stratégiques pas encore très claires, Adobe faisant tout pour être sur les mobiles certes. (c’est d’ailleurs la raison essentielle de l’interdiction imposée dans l’iPhone OS 4.0)

Alors docteur, cette interdiction ?… une raison plutôt personnelle … ?

Je n’y crois pas, Apple est devenu une entreprise grand public ayant un pouvoir considérable (mobile, informatique, musique, presse…) . Même si Steve Job, qui est l’ “homme entreprise”, ses propres décisions ou son caractère un peu trop prononcé, ne peut pas justifier seulement cette décision.

Apple a besoin de s’inscrire sur le long terme, et ne plus revivre le déclin

Si on regarde le cycle de vie des entreprises d’hier et d’aujourd’hui, on remarque que le cycle est de plus en plus court :

Les entreprises doivent faire face au risque d’un déclin rapide, une erreur dans leur stratégie peut leur être fatale.

La croissance des entreprises prospèrent plus rapidement, grâce à la sectorisation/mondialisation, mais elle est rattrapée de plus en plus vite par ses concurrents.

Il y a aujourd’hui il y a une accélération de la croissance et une accélération du déclin. En 5 ans Facebook est apparu comme leader dans le domaine du web social.

L’innovation est le seul axe “de croissance” très vertueux pour l’entreprise… mais il faut garder ses arrières, et donc éviter que la concurrence ne prenne un peu trop vite cette innovation si couteuse et risquée à produire.

Aujourd’hui, il existe plusieurs solutions pour qu’une entreprise reste leader, et donc éviter le rapide déclin  :

• Acquérir ses concurrents : c’est ce que fait Oracle, Microsoft ou même Google …
• se protéger de ses concurrents : Ce que fait Microsoft (ex. : en fermant le code source des logiciels. )
• innover : Par exemple Twitter et Google (? j’aimerai un autre exemple, si vous pouvez m’aider)

Et si Apple a échoué dans les années 90 (alors que le marché à l’époque était en pleine explosion et moins concurrentiel), il ne peut plus adopter aujourd’hui une position trop “ouverte”.

Voici la position d’Apple : innover et se protéger de ses concurrents.

Apple par son positionnement leader en termes d’innovation et de maitrise globale de la fabrication de ses produits (voir mon avis sur l’entreprise 3.0) ne peut définitivement acquérir ses concurrents… car ils sont Adobe, Microsoft et Google… (quand même). Apple étant déjà en forte innovation, il ne peut se fiabiliser qu’en se protégeant.

Sa protection n’est pas un choix, mais une nécessitée.

Imaginez qu’Apple perde son iPhone (à cause de la concurrence)… on serait proche de la situation de 1990, même si les mac sont indépendants de l’iPhone et s’ils se vendent bien, ils ne forment pas la priorité stratégique d’Apple.

Si on retournait voir notre psy, peut être qu’il réussirait à dire qu’Apple fait cela à contrecœur … par rapport à sa propre philosophie (prenons celle de Steve Wozniak, plus “technologique”)… en effet n’est-ce pas donner une meilleure image ou plus facile d’être collaboratif et ouvert plutôt que de se montrer comme un vieux geek ermite ? Je sais que la perspective d’une entreprise fermée au développeur n’est pas très sexy ou très tendance… Mais Apple n’est plus Apple Computer … Les clients d’Apple ne sont plus des apple fans ou apple geek. Il ne faut pas se tromper  : le client est ce l’utilisateur ou le développeur ?

Bon je vous avouerai je suis comme vous bien triste de cette fermeture et de se protectionnisme vraiment trop visible qui nous impact fortement, développeurs… mais surement aussi les utilisateurs qui ne bénéficieront plus de l’innovation de petites boites voulant créer et mettre à disposition leurs sdk alternatifs…

Dommage donc, peut être que l’innovation Apple trouvera une autre solution moins radicale.

Les tendances convergent… Voici mon avis : Entreprise 3.0 est forcément héritière de l’entreprise 2.0, c’est-à-dire qu’elle est tournée vers l’extérieure, qu’elle capte et diffuse la connaissance des réseaux sociaux. (principe web 2.0) Elle utilise d’abord le réseau humain avant de penser aux machines (par exemple utiliser les forces de la génération Y).
Tout est basé sur la confiance. Elle ne cherche plus à se protéger de ses concurrents, mais plutôt à innover et à collaborer (principe de l’open source), elle est (et doit) donc constamment en “avance” sur son temps, donc créer de la valeur, au lieu de créer du gain économique.

Il faut inclure la perspective “entreprise agile”, c’est-à-dire que l’entreprise va se construire sur deux éléments qui la feront grandir : “ses clients” et ses “collaborateurs”. Elle doit connaitre et anticiper le besoin des clients, être en haute proximité avec eux, leur proposer constamment des nouvels idées et concepts (principe lab) et les valider rapidement dans son système de production et donc maitriser toute la chaine de production. (principe de l’organisation “plateforme”)

Par rapport à son développement, cet article peut présenter une piste : La qualité est elle la version 2.0 de la quantité ? et donc l’entreprise 3.0 est elle l’entreprise qui sait produire en quantité des éléments de qualité ? Si on parle qualité, ça veut dire avoir des vrais services/produit à valeur ajoutée, qui sont utilisés à 100% et produire de manière écologique, et durable.

Globalement l’entreprise 3.0 sera à l’opposée de l’entreprise “industrielle” sectorisée, qui présente un éclatement des moyens de réflexion/production et créant donc des liens complexes (B2B) avec son environnement : Jetez un oeil à cet article intéressant : “La chute des modèles économiques complexes” The Collapse of Complex Business Models.

Donc… le modèle 3.0 est il celui du fameux “Google” ? Sauf qu’a l’heure actuelle ce modèle idyllique n’est pas encore validable, Google est apparu en 10 ans mais pourrait disparaitre très rapidement (Facebook a dépassé google en termes de trafic web)… La question est “les succès de Google est-il dû à son innovation” ou le “succès de Google induit l’innovation possible” (voir l’article : L’innovation agile à la Google est-elle un modèle ou une anomalie ?)

Bref l’entreprise 3.0 pourrait être celle-ci :

Une entreprise qui est en relation avec ses clients finaux (humains), qui maitrise elle-même toute la chaine de production (innovation, capture du besoin, marketing, production, vente) ; qui évite la sous-traitance, car elle va valoriser et utiliser au maximum son capital humain (ses collaborateurs) et est donc équitable et durable… et le plus important : qui diffuse son savoir et son capital de connaissance de façon publique et collaborative…

Mais peut être que je confond entreprise 3.0 avec mon propre rêve de l’entreprise de demain.

“A chaque fois que je suis sur la route je me connecte …

1.La 1ère fois, j’ai oublié d’arrêter l’appli et mis l’iphone dans la poche … ça m’a un peu brûlé les cuisses parce qu’il s’est mis à chauffer sec !

2.Sinon ça m’a l’air de bien fonctionner, parfois j’ai du mal à démarrer l’appli, il faut s’y reprendre 2 ou 3 fois …

3.Hier soir, je me suis retrouvé dans un bouchon, il me l’a signalé. Ca ne m’a servi à rien parce que j’étais dedans mais la fonctionnalité fonctionne …

4.Quand l’appli démarre, j’ai parfois dans le message d’invite : … N’est-ce pas quand je suis le seul connecté ?”

Je réponds à Gilles:

1. Effectivement l’appli ne se met pas en veille, et du coups si on oublie de l’arréter, elle tourne !

2.Il y a un bug à ce niveau en effet

3.En effet c’est pas utile pour l’utilisateur, par contre pour les autres connectés (bon là t’étais le seul) , ils savent qu’il y a un bouchon a cet endroit. En regardant la courbe c’est plutot pas mal, l’appli à bien réagit. Je vais quand même ajouter un temps de présence du “bouchon” car si ta voiture n’est plus dans le bouchon, l’indicateur disparait tout de suite, alors que le bouchon non …

le cercle rouge représente le bouchon.

4.encore un ptit bug, en effet, le pb c’est qu’il met null quand la requete d’authentification échoue… ce qui est très embetant car du coup ça foire les données stockées. je corrigerais.

Pour tester l’appli c’est ici : http://www.elolozone.com/trafficWave/Accueil.html

Merci Gilles!

Pour que l’application puisse fonctionner sur votre iPhone, il est nécessaire que vous m’envoyez (en retour de ce mail) , l’UDID de votre iPhone.

C’est le numéro d’identification de votre iPhone; bien entendu c’est confidentiel. C’est la procédure “officielle” d’Apple pour permettre de distribuer et tester publiquement des applications.

Voici comme procéder : http://www.elolozone.com/trafficWave/UDID.html

Copiez l’UDID à partir d’ iTunes et collez le dans un email vide à beta@elolozone.com

A très bientôt… et préparez vous à suivre le fluide!

Je lui ai dis que ça allait être chaud car c’est vraiment bouché… il là il m’a répondu: mais à paris on dirait que c’est “fluide” …

on a mis 45 minutes.

Imaginons que j’avais avec moi une habitante de trifouilly-les-oies. Elle m’aurait répondu pareil ? Je ne pense pas, je crois qu’elle aurait été affolée de rater son train.

Le principe est de mesurer la “perception” de l’utilisateur, en lui posant la question : es tu dans un bouchon :

en répondant le serveur va d’une part fiabiliser ses seuils, et en plus “localiser” la perception de bouchon.

biennnn !

Ce graphique est le résultat de ma page jsp ( http://traffic-servlet.appspot.com/userStatGraph.jsp )…. désolé je n’ai pas eu le temps de faire de controleur

Le but, pour mon application trafficWave, est d’afficher ma courbe de vitesse en temps réel, à des fins de tests uniquement, et me permet de voir si les données enregistrées sur le serveur sont bonnes et si l’analyse du moteur de bouchons est bon !

Bref, voici le principe :

Une page jsp présente sur mon projet GAE (google app engine) récupère les données intéressantes, en l’occurrence se sont les 15 dernières minutes de mon trajet enregistré par trafficWave (appli de traffic).

et inclut l’appel à l’API google chart sous forme de source d’image :

<img src="http://chart.apis.google.com/chart?chds=0,150&chxr=0,0,36220.0|1,0,150&chxt=x,y&chdl=userSpeed|avrSpeedStreet&chco=FF0000,00FF00&chs=600x500&cht=lxy&chd=t:
-1|45.0,74.0,10.0,27.0,13.0,53.0,... etc...

J’ai donc ajouter sur mon appli iphone, une mini inclusion de page de test, qui affiche ce graphique :

et voilà …
bon il n’y a pas de ligne de code, mais ce n’est pas si simple d’écrire une requete qui affiche des données correctement. en plus on est vite limité par la longueur de la requete et donc du nombre de données à afficher (j’ai limité 100 points pour ma part, mais cela dépends de la taille de chaque nombre). Google a d’ailleurs trouver une bidouille, il s’agit de coder chaque nombre en lettre, réduisant ainsi la taille de la requête et permettant donc de présenter plus de données.
L’avantage réside encore une fois dans l’architecture “mashups” ou une simple requete permet de faire beaucoup de chose en peu d’effort, surtout dans ces cas ou l’utilisation est orientée test.

pas grand chose comme application, “Setting” et “Contacts”… :

Ensuite : Alberto Tafoya

Ensuite Dominik

Ensuite Yuriy :

… on dirait que les serveurs d’apple se mélange les pinceaux dans les sessions !