Eloge du courriel

Depuis quelques mois, et faisant écho à la déclaration de Thierry Breton qui souhaite supprimer l’usage de l’email en interne chez ATOS, j’entends beaucoup de gens qui prédisent la fin de l’email, et la suprématie des outils 2.0. Dans mon propre livre, j’ai commenté les faiblesses structurelles du courrier électronique, et les avantages à ouvrir des canaux alternatifs de communication, pour désengorger nos boites aux lettres et profiter des nouvelles formes de communication, mieux adaptées à la coopération.

En revanche, je ne crois pas un seul instant à la disparition de l’email, ni même que cela soit souhaitable. C’est peut-être la conséquence de mon âge (j’ai commencé ma carrière professionnelle à peu près au moment ou l’email se répandait dans les entreprises technologiques), mais je suis persuadé que :

• le courrier électronique est un excellent canal de communication,
• même face aux alternatives 2.0, il restera un outil clé dans la panoplie des entreprises,
• l’enjeu est plutôt la « déprolifération », c’est-à-dire débarrasser ce canal des abus (précisément parce qu’il est trop facile d’emploi), pour lui retrouver son efficacité systémique.

Par email, j’entends un moyen de communication textuel (avec des pièces jointes additionnelles), asynchrone, vers un ou plusieurs destinataires désignés explicitement par un identifiant (adresse email), et donc connu(s). Je considère que la boite à message de Facebook relève de l’email : le fait que le réseau soit ouvert (n’importe qui peut vous envoyer un message) ou fermé (seuls les membres de votre réseau peuvent vous envoyer un message) est une modalité.  Il est clair qu’elle joue un rôle clé dans l’abus de l’email avec le spam, mais c’est facile à traiter (je vais y revenir dans ma troisième partie).

1. Forces et Faiblesses

Les forces structurelles de l’email se déduisent naturellement de sa caractérisation en tant que canal :

• Le mode asynchrone introduit un découplage temporel qui fluidifie l’écoulement de l’information lorsque les taux de charge (taux d’occupation) augmentent. J’en ai parlé abondamment dans ce blog, c’est l’objectif de mon modèle SIFOA. Nous en faisons tous l’expérience : lorsque nous sommes débordés, trouver le temps pour se téléphoner ou se voir devient difficile.
• La communication textuelle a un triple avantage. Premièrement, elle force à réfléchir et à synthétiser ses idées. C’est la « force de l’écrit », un avantage souligné depuis des temps immémoriaux. Deuxièmement, il y un avantage systémique puisque l’écriture place un effort sur l’émetteur et facilite la prise de connaissance du récepteur avec l’information, ne serait-ce qu’en termes de nombre de mots par minutes. Pour finir, elle est éminemment partageable (trop facilement d’ailleurs !). La communication textuelle facilite la diffusion, lorsque le contenu se prête à cette forme textuelle (cf. plus loin).
• L’email apporte la traçabilité, un avantage déterminant dans la gestion des demandes. Cette traçabilité est complète : qui, quand, quoi – c’est un outil de communication transactionnel, au sens informatique du terme.-       
• L’email est un outil ouvert et interopérable : il permet un fonctionnement en « entreprise étendue », avec des partenaires, des fournisseurs, etc. Ce point est évident et admis par tous, je ne vais donc pas y revenir dans ce message et m’intéresser plutôt à l’usage interne de l’email (au sein de l’entreprise).

On peut également mentionner une force conjoncturelle, liée aux outils, qui vient du fait que les « lecteurs email » ont 20 ans d’existence et d’amélioration continue. Ils sont supérieurs, par conséquent, à bon nombre d’outils « Web 2.0 » - en particulier dans le monde du « gratuit ».  En particulier, j’apprécie :

• Le pilotage temporel, avec une timeline implicite (depuis toujours), et une orientation « personne ». Nous sommes câblés, d’un point de vue neuronal, pour ranger nos informations par période temporelle et en les associant à des personnes. C’est ce que fait implicitement tout lecteur email, et c’est ce qui manque à de nombreux outils de « knowledge management » (KM) ou de « gestion documentaire ». C’est le cas des outils modernes 2.0 (la révolution du KM  est précisément de constater que « who » est encore plus important que « what »), mais rendons justice au courriel.
• La dualité cloud/device, c’est-à-dire la combinaison d’un repository sur le cloud, accessible depuis n’importe quel device et d’un mode de consultation indépendant de la connectivité réseau (et cela des années avant Dropbox). Quelque chose qui me manque sur bon nombre d’outils 2.0 ou de partage communautaire de document type Intranet.
• Une ergonomie optimisée, avec beaucoup de drag&drop, de raccourcis, de favoris, de "customisation" implicite par apprentissage.

Examinons maintenant les faiblesses, en adoptant la même décomposition structurelle/conjoncturelle. Les défauts structurels de l’email sont les pendants des caractéristiques :

• L’utilisation de l’écrit n’est pas toujours adaptée !  D’une part l’écrit peut compliquer et formaliser de façon inutile un message (« un schéma vaut mieux qu’un long discours ») et, d’autre part, l’écrit stérilise, le plus souvent, le message de son contenu émotionnel qui peut être essentiel pour la compréhension. Nous le savons, le courriel n’est pas adapté pour régler des différents, pour traiter des sujets délicats, etc.
• Le mode asynchrone réduit la « bandwidth », c’est-à-dire la capacité à se synchroniser avec les besoins et les réactions du destinataire. C’est pour cela qu’il faut éviter l’email dès que l’appropriation du message pose question. On ne sait pas comment le lecteur réagit, ce qui limite fortement les cas d’utilisation. C’est le piège principal : on utilise l’email pour son asynchronisme (pas besoin de synchroniser les agendas), et la communication échoue à cause de cette non-synchronisation.
• La traçabilité produit des problèmes de gestion et de purge (accumulation). Tout ne mérite pas d’être traité comme une transaction … la force des outils 2.0 est de reconnaître le mode « conversation ».
• L’effet club : on ne parle qu’à ceux que l’on connait ! C’est une des faiblesses systémique les plus profondes et qui justifie le passage à l’Entreprise 2.0, c’est-à-dire le passage à des outils qui permettent de communiquer vers des destinataires que nous ne connaissons pas.  Cette faiblesse est partagée avec le téléphone, et c’est un problème crucial pour les grandes entreprises, à l’heure où il est vital d’utiliser « le cerveau de tous ».

A coté de ces défauts structurels, nous avons des faiblesses conjoncturelles liées au mode d’usage actuel. Sans être exhaustif, il me semble que nous avons trois problèmes principaux :

•  Le spam : c’est-à-dire l’utilisation du canal par des flux inutiles du point de vue du lecteur. Les anti-spams ne sont pas une solution suffisante. Le fait de traiter les messages de façon uniforme indépendamment de leur provenance n’est plus acceptable aujourd’hui, à l’heure des réseaux sociaux. C’est la raison principale pour laquelle les jeunes ont abandonné cet outil et n’y reviennent que lorsqu’ils y sont forcés par leur entrée dans la vie professionnelle. En revanche, ils utilisent le mode « courriel » de Facebook : le problème n’est pas le textuel asynchrone, c’est bien l’ouverture aveugle.
• La sur-utilisation dans le cadre de l’entreprise : le fait que trop d’information passe par le canal email. Cet abus est précisément la conséquence de la facilité d’utilisation de l’outil …
• La faiblesse du protocole de distribution : l’abus des pièces jointes crée des multiples copies qui rapidement se désynchronisent. L’utilisation des liens est une solution si les outils sont très rapides et efficaces, mais c’est rarement le cas. Nous attendons une approche « Dropbox » pour que les pieces jointes soient à la fois locale (rapidité) et partagées … et il est toujours possible d’utiliser Google docs !

Cette analyse des faiblesses n’est pas relative : je n’ai pas pointé les domaines pour lesquels l’email est moins adapté que d’autres formes de communication ou d’autres outils. C’est parce qu’il est évident que l’email doit être combiné précisément avec ces autres formes de communication, au lieu d’être un outil fourre-tout. C’est la thèse défendue dans ce blog depuis 5 ans et dans mes deux livres, Performance du SI et Processus et Entreprise 2.0.

2. Analyse comparée : pourquoi le courriel est utile et nécessaire ?

Quelle est la concurrence avec la quelle il faut comparer l’email ? Je vais séparer le monde de la communication électronique et le monde des autres formes de communication, parce qu’il est essentiel de rappeler que les outils électroniques ne remplacent pas le contact physique.

Dans le monde des outils électroniques introduit avec l’arrivée du Web 2.0, on peut citer trois groupes (j’agrège et je simplifie) :

• La messagerie instantanée (IM), dont l’immense avantage est d’éviter l’encombrement. C’est un outil de conversation, le message est éphémère : s’il n’est pas saisi, on passe à autre chose. On peut placer le micro-blogging (le statut de FaceBook ou le message Twitter) dans la même catégorie. Il me semble évident qu’il y a un avantage systémique à distinguer les transactions des conversations. Les messages « périssables » ne devraient pas encombrer les boites aux lettres, et l’idée d’ajouter une date de péremption, même si elle est intéressante, ne remplace pas l’ergonomie immédiate de la messagerie instantanée.
• La communication « broadcast vers sa communauté », qui correspond à l’usage des outils « de type Facebook » dans l’entreprise. Le point clé est double : communiquer vers ceux que mon message intéresse, au moment où cela les intéresse. On évite de la sorte l’effet club : la structure de communauté permet de rencontrer de nouveaux destinataires, autour d’un contenu ou d’un thème.
•  La communication « content-centric », telle que les sites communautaires de partages de documents. Toutes ces plateformes qui proposent des formes enrichies des « intranets d’entreprise ou  de département » sont bien mieux adaptées que l’email à la collaboration sur un « artefact numérique » (un document, un powerpoint, une maquette numérique, etc.).

Je ne vais pas m’étendre sur l’impérieuse nécessité des entreprises à capturer et apprivoiser l’usage de ces nouveaux canaux de communication 2.0, c’est mon sujet favori et habituel. Ce qui m’intéresse aujourd’hui, c’est qu’une fois ces outils introduits et ces pratiques mises en place, il reste de la place pour l’email ! Mais il faut d’abord rappeler qu’il existe d’autres alternatives « 0.0 » à l’email :

• Le coup de téléphone : son intérêt est d’offrir un meilleur feedback, parce que synchrone, et de permettre l’informalité de la communication orale. Dans certains cas la formulation écrite apporte un plus, mais dans de nombreux cas, elle est soi trop concise soit trop verbeuse, alors qu’un coup de fil permet d’adapter la quantité d’information.
• Le déplacement, pour passer voir son interlocuteur, représente l’étape suivante en termes de « bandwidth », c’est-à-dire de richesse du feedback. Des que les émotions entrent en jeu, parce qu’il y a désaccord par exemple, le contact physique permet de décoder, dans les expressions du visage et dans les postures corporelles, tout ce qui est nécessaire pour un vrai échange.
• La visio-conférence se situe à mi-chemin entre les deux ; plus la technologie progresse (téléprésence), plus on se rapproche des bénéfices d’un contact direct.
• La patience, qui consiste à attendre la prochaine réunion, ou la prochaine rencontre, pour aborder de vive voix le sujet. J’insiste souvent dans ce blog sur l’importance de la réactivité et la rapidité de diffusion d’information. Il y a aussi beaucoup d’information non urgentes, pour lesquelles il vaut mieux attendre le bon moment, plutôt que de « pousser » une email qui sera mal compris (si il est lu).
• L’instauration de points de rencontre réguliers et fréquents, qui créent un canal de communication précieux. La pratique des « stand-up meetings » quotidiens ouvre un espace de communication informel qui est bien plus efficace que l’email pour de nombreux sujets.

Toutes ces alternatives 0.0 servent à palier la faiblesse du message écrit et à réintroduire l’importance de l’appropriation. Si l’on combine les forces du 0.0 et du 2.0, on obtient le périmètre de l’email (textuel, nominatif et asynchrone) par différence. Le message doit être clair (adapté à l’écrit), il doit être significatif (justifiant l’utilisation d’une forme transactionnelle de communication) et il doit être personnel (la désignation de l’interlocuteur est constitutive de la communication). Dans la pratique, l’email reste donc:

• Un bon outil de signalisation, pour faire savoir qu’une information est disponible (l’email ne contient pas le contenu, qui est sur un site partagé) mais un signal (mise à disposition, mise à jour, etc.). Il ne faut pas abuser de la signalisation mais à l’inverse le mode « pull » (ou l’on va chercher ce dont on a besoin) ne suffit pas non plus. Il existe d’autres façon de faire des notifications, mais pour certains sujets important, il faut une forme transactionnelle de notification (voire avec un « accusé de reception ») et l’email est approprié dans ce cas.
• Un bon outil de diffusion des décisions, pour faire circuler un relevé de décision clair, comme le compte-rendu d’une réunion. Le coté nominatif est approprié, et la capacité à transmettre est également un avantage.
• Un bon outil pour enregistrer une demande : la forme écrite force à formuler et préciser la demande, l’aspect transactionnel  facilite la gestion et le pilotage, et le coté nominatif renforce l’engagement. Ce n’est pas le seul outil pour gérer des demandes : dans le cadre de la gestion des processus métiers, il existe des plateformes mieux adaptées car plus spécialisées, en particulier pour gérer le workflow qui s’en déduit. En revanche, le courriel est un outil naturel pour gérer les demandes « hors processus ».
• Un bon outil pour prendre contact, pour initier une relation. De façon paradoxale, l’email est un outil naturel pour construire les réseaux et les communautés du 2.0. L’aspect asynchrone est important pour franchir une « barrière », l’email est un canal privé – par opposition à un blog ou un mur – qui est utile pour aborder des sujets confidentiels, incertains ou sensibles (mais en dehors d’un contexte émotionnel qui suggère la rencontre en personne).
• Un bon outil pour conduire une collaboration informelle sur un temps long : cela existe encore ! Je vais faire ici la même remarque, même si le temps s’accélère, il reste de la place pour les processus lents, pour la gestation d’idées. J’y reviendrai dans un prochain billet : l’innovation nécessite souvent du temps.

3. Petite prospective : comment le courriel doit évoluer?

Pour conclure ce billet, je vais livrer quelques réflexions sur les évolutions qui me semblent nécessaires dans nos outils « lecteurs d’email », pour faciliter la restriction de l’usage et sa meilleure adaptation aux défis de communication de l’entreprise :

• Il faut réintroduire la notion de cercles (à la Google+) et de groupes fermés dans l’email. Il n’est pas logique de ne pas isoler les flux qui proviennent de ses propres réseaux, avec la structuration calquée sur l’organisation (hiérarchique et projet) de l’entreprise. On m’objectera que c’est déjà facile à faire avec la notion de requête et de groupes dynamiques (sous Outlook par exemple). Il n’en reste pas moins que les outils email sont en retard sur ce sujet.
• Il faut déplacer le support de la collaboration vers des plateformes 2.0 pour se limiter à la coopération par email.
• Il est urgent, de façon plus générale, de réduire l’usage des communications électroniques pour retrouver, d’une part, l’efficacité des rencontres, mais aussi pour retrouver l’efficacité des outils électroniques lorsque ceux-ci sont utilisés à bon escient.
•  La gestion du courrier électronique doit progresser en termes de gestion du cycle de vie des messages et introduire des mécanismes de purge ou d’archivage semi-automatique et pertinent. Une partie de ces idées est implémentée mais il faut progresser, par exemple en distinguant les conversations des transactions de façon plus automatique et plus simple.
• Pour finir, il faut que les outils soient accordés avec des « règles de bon usage », liées à une vision systémique – cf. LEMM : Lean Email Management. C’est un sujet complexe : il existe de nombreuses chartes, mais il est difficile de les faire appliquer. Pour que le courrier électronique ne soit pas victime de son succès, pour que nos boites email retrouvent une taille « humaine » et que nous bénéficions à nouveau de l’efficacité de ce canal, il faut que nos outils incorporent des garde-fous, une déclinaison interne du concept d’anti-spam.

Grammaire de l’inaction et programmation fractale

Aujourd’hui je me propose de commenter deux petites contributions personnelles qui datent de plus de 10 ans, mais que je souhaite revisiter à l’aune du lean management, parce que le lean apporte un éclairage sur ces deux paradoxes.

La première contribution est une « grammaire de l’inaction », un générateur de plans de travail qui permettent de procrastiner, c’est-à-dire de parler de tout sauf de ce que l’on va faire. Cette construction ludique est une sorte de blague de potache « geek », une réaction de jeune collaborateur  face à des présentations de « consultants » que je trouvais fortement ennuyeuses à l’époque. Je suppose que je ne suis pas le seul à avoir assisté à une présentation d’un nouveau projet, d’un nouveau plan de transformation, d’une nouvelle démarche de changement et d’avoir trouvé que :

• Au bout de 30 slides, on ne sait toujours pas de quoi l’on parle,
• Le discours est un « discours méta », qui ne porte ni sur le problème et encore moins sur la solution, mais plutôt un « discours de la méthode », sur le « comment » et pas sur le « quoi »,
• Les même slides peuvent resservir d’un projet à l’autre, d’une entreprise à l’autre, elles sont complètement génériques (d’où l’expression « slides de consultants »).

J’avais construit la « grammaire de l’inaction » qui suit comme une abstraction qui permet de générer un plan de travail très riche, au point que  l’action (le ) se trouve noyé, ou n’a plus besoin d’être détaillé puisque la matière pour produire les « slides » est riche (l’application de l’aphorisme « noyer le poisson »). C’est une grammaire au sens informatique du terme, en format BNF, puisqu’il s’agit d’une plaisanterie de geek. Je l’ai utilisé une fois en présentant un jeu de slides sur une « nouvelle stratégie informatique » d’un consultant célèbre, Mr TerShiBul (à lire à l’envers) … et personne n’a détecté de supercherie, ce qui a été une grande leçon d’humilité sur mes propres slides !

  (do)   ::=     (pre-validate) (do)  |

                   (plan)  (do)  (followup) |

                   (explain) (do) (training) |

                   (instrument) (!—set up measure --) (do) (measures analysis) |
                   (set up success criteria) (do) (check) |

                   (small scale POC) (partial do) (do) |  (!-- partial: spatial/geographical/organizational  --)

                   (quick wins) (first step : 80/20) (do) |

                   (list all possible action paths) (do)  (!— the longer the list, the less content --)

(pre-validate) ::= (prototype) (feedback) | ( stakeholders opinion poll) | (build ROI case)

(plan) ::=  (benchmark) (plan) |

                   (study) (plan) |

                   (data collection from the field) (plan) (verification) (!—check against data--)

Note: J'ai abandonné l'idée d'utiliser des "brackets", d'ou le recours aux parenthèses (confusion HTML/BNF). Cette grammaire ne demande qu’à s’enrichir, je suis preneur de nouveaux « patterns » :

C’est une grammaire de l’inaction dans le sens où, au lieu de s’occuper de ce qu’il y a à faire (le ), on peut dériver une longue chaine de choses à faire autour du . Le délicieux paradoxe est que le lecteur avisé aura reconnu tous les principes du management de la qualité, certains principes de la gestion du changement et du pilotage de projets, bref, tout ce que je prône dans mon dernier livre. Cette tension entre ma perspective d’aujourd’hui – un chantre du TQM – et ma perspective d’hier – stop au baratin (le terme anglais qui me vient à l’esprit est moins ragoutant) - , est résolue par le lean management. Plus précisément, par les trois principes suivants :

1. On parle des vraies choses : on décrit les problèmes de façon pratique et systémique (grâce au management visuel), on parle des solutions concrètes.
2. Comme tout ceci n’est pas forcément simple, on va « sur le terrain » (gemba ) pour confronter la situation, le problème. Parler d’une solution « en situation » est la meilleure façon d’éviter d’être « à coté de la plaque ».
3. On évite les listes trop longues, on se concentre sur quelques actions, on les priorise, et on travaille sur une chose à la fois, puis on recommence.

Bref, le lean est radicalement opposé au « discours de la méthode », même s’il repose sur une méthode (on laisse le méta pour les discussions de salon et les livres, on pratique la résolution de problème).

J’en viens maintenant à mon deuxième sujet, la méthode de développement logiciel que j’ai utilisée au cours des années (en particulier lorsque j’étais au e-Lab), et que j’avais baptisée de « Fractal Programming » il y a dix ans. J’ai profité des vacances d’Aout 2011 pour me lancer dans un projet logiciel, « Systemic Simulation of Smart Grids », et j’ai instinctivement réappliqué les mêmes principes :

• Un programme est une résolution de problèmes emboîtés, de façon récursive (d’où le terme de fractal). La première étape est une approche top-down (qui correspond à une architecture fonctionnelle) qui décrit l’arborescence des problèmes à résoudre.
• Puisque j’utilise un langage fonctionnel de haut niveau d’abstraction, je produis directement du code (CLAIRE). Un des principes est de produire un programme qui est à la fois exécutable et sa propre description d’architecture.
•  J’utilise une approche « orientée-objet » qui fonctionne par raffinements successifs au fur et à mesure du développement du code (la structuration des données est une colonne vertébrale du code).
• En revanche, je commence par écrire le programme de test : cela donne le premier input pour les objets et valide les interfaces de l’architecture fonctionnelle.
• L’objectif est d’obtenir le plus rapidement possible un premier programme qui tourne. Le programme simple permet de valider les entrées/sorties avant que les erreurs soient cachées dans des fonctionnalités obscures. Le programme simple est également le « workbench » pour le développement des algorithmes qui vont suivre.A tout moment, je travaille sur un code exécutable avec des objets que je peux inspecter (un des avantages d'un outil qui descend de LISP).
•  Lorsqu’on commence à remplir le fractal, c’est-à-dire écrire des algorithmes qui résolvent des sous-problèmes, on commence par ce qui est le plus difficile, mais en appliquant une approche de raffinement successif. Chaque raffinement peut être testé contre son prédécesseur.

Cette notion de « Fractal Programming » n’est pas originale. On la retrouve sous plusieurs formes chez différents blogueurs. Il s’agit en quelque sorte d’une déclinaison de l’extreme programming pour une micro-équipe, voir un développeur isolé (ce qui est mon cas depuis 10 ans). Le terme est surtout utilisé pour décrire la génération de fractals par programme. 

En revanche, pendant je faisais mon jogging matinal, je me suis aperçu que mon expérience me permettait de réinterpréter ces principes avec une perspective de « lean management ». En particulier, le même proverbial « lecteur avisé » aura reconnu les principes suivants :

•  « fail faster to succed sooner », qui explique pourquoi il faut commencer par ce qui est difficile,
•  « produce a working piece of software as soon as possible »,  un des principes clés des méthodes agiles (dont SCRUM bien sur),
•   « test as early as possible », un autre principe clé du développement agile (commencer par les tests), qui est une des bases du livre de Eric Ries.
• La création d’algorithmes et de systèmes complexes se fait sur le terrain (ici, gemba = code), pas sur le papier. Ce qui n’empêche pas d’utiliser le tableau blanc, le meilleur outil de « management visuel » du programmeur ! 

Pour conclure, je vais citer le « pretotyping manifesto », qui n’existait pas il y a 15 ans, mais dont j’aurai pu m’inspirer (le lien avec Eric Ries est évident) :

• Innovators beat ideas
• Pretotypes beat productypes
• Building beats talking
• Simple beats complex
• Now beats later
• Commitment beats committees
• Data beats opinion

On est bien dans la philosophie lean : priorité aux femmes et aux hommes, priorité à l’action, priorité à ce qu’on peut faire tout de suite, priorité à ce qui est démontrable et factuel.

Prix du livre Qualité et Performance 2011

J’ai reçu il y a 15 jours le Prix du livre Qualité et Performance 2011  pour mon livre « Processus et Entreprise 2.0 »

Je suis très heureux d’avoir reçu ce prix prestigieux, eu égard à la qualité de son jury, composé pour moitié d’universitaires et pour moitié de managers et dirigeants ayant une expérience reconnue dans les domaines de la qualité et de la performance.

Ce prix fait suite à une série d’articles et de billets très positifs :

• De Bertrand Duperrin, sur son « Bloc Note »,
•  De Fred Cavazza, sur le blog entreprise 2.0,
•  De Benoit Arnaud, sur le EDHEC Management blog,
•  De Patrick Bégidis,  sur le blog de MeetingsOnDemand,
•  Un article sur le site d’Alternative économique,
• Un article dans Best Practices SI (n°75),
• Et sur le site BPM Bulletin.

A lire également, l’article de Richard Collin dans le monde, qui a eu la gentillesse de rédiger ma préface. 


Je viens de déposer dans ma "box" de talks publics ("my Shared Documents" en bas à gauche) un explosé intitulé "LeanEntreprise2.0" qui présente les idées clés du livre.

"Lean Startup" et "Lean Product Development"

Je profite de la période estivale pour vous parler de « The Lean Startup », un livre de Eric Ries qui sortira en Septembre. En attendant d’acheter le livre, vous pouvez voir ses exposés, par exemple sur YouTube, il existe aussi un Wiki dédié à sa méthode.
Le livre d’Eric Ries est avant tout un livre remarquable sur l’innovation. Eric Ries s'appuie sur des grands classiques (G. Moore, etc.), mais il va plus loin et il apporte des histoires illustratives qu'il explique très bien. C’est également le meilleur livre que je connaisse sur les startups et ce qui fait leur succès. J’y ai retrouvé les perles de sagesse que j’avais recueillies auprès de différents VC (venture capital) en Californie. Par exemple, il y a 5 ans, un très grand VC avec 25 ans d’expérience m’a livré la réflexion suivante : pour une start-up qui arrive avec un produit logiciel, il n’y a aucune corrélation entre son succès et la qualité de son premier prototype (ce qui est brutal !), le succès dépend entièrement de deux choses : le fait d’entendre les premiers clients qui sont placés face au produit, et le fait de savoir s’adapter, y compris de façon drastique, ce que Eric Ries appelle un pivot. C’est, pour finir, un très bon livre pour comprendre comment appliquer le lean dans le monde des services et le monde des “knowledge workers”, et ce qui justifie que je vous en parle. On retrouve ici le lean “façon-Toyota”, celui qui s’intéresse à l’individu, à l’apprentissage en équipe, à l’innovation, à l’excellence.

Comme toujours, voici une liste partielle des points saillants, orientée par mes propres questions et réflexions sur l’architecture organisationnelle:

• Le point le plus intéressant est le concept de « validated learning ». La question que se pose Eric Ries, au sujet d’une startup ou d’une « direction innovation » est la suivante : que produit le « processus innovation » et comment le mesurer ?. La réponse d’Eric Ries est que le processus d’innovation produit de la connaissance sur les besoins, attentes et usage du client. Le validated learning représente une idée créatrice de valeur, validée par des clients et donc démontrée par un objet (logiciel dans la plupart des cas). Je parle d’idée pour représenter le concept qui est « appris », mais cette idée est matérialisée par une expérience (cf. le MVP plus loin). L’objectif d’une start-up, ou d’une direction de l’innovation, est d’obtenir une masse critique de “validated learning”. Sa stratégie, du point de vue lean, est de maximiser la création de “validated learning”, et donc d’acquérir le plus vite possible l’expérience de ses clients et le savoir de ce qui leur est réellement utile. Comme dans toute approche lean, ce processus de création d’expérience est optimisé selon un cycle «build-measure-learn », ce que nous allons voir plus loin.
• Minimum Viable Product (MPV): C'est l'enseignement le plus pratique, le plus essentiel ... et le plus difficile pour une grande entreprise :) . Plutôt que de construire des produits riches et complets, qui peuvent - le plus souvent - passer à côté des vrais besoins des clients, il faut travailler avec des livraisons fréquentes de “petits produits”. De la sorte, (1) on évite les erreurs coûteuses et on rectifie le tir plus rapidement, (2) on est exposé beaucoup plus vite au retour des clients, et on peut commencer plus vite à apprendre de ces retours. C’est bien sûr une application du lean, puisqu’il s’agit de supprimer un des gaspillages les plus importants: créer des “features” que personne n’utilisera jamais ! Le minimum viable product apporte une solution au client, ce qui suppose qu’il existe une question (un problème). Ries propose de se poser les 4 questions suivantes :

• Est-ce que les clients sont conscients d’avoir un problème
• Si on leur propose une solution, est-ce qu’ils l’achèteraient ?
• Est-ce qu’ils achèteraient notre solution ?
• Est-ce que nous savons construire une solution ?

Je recommande chaleureusement de lire l’exemple de Dropbox, pour lequel le MVP est une vidéo qui décrit l’expérience client ! Drew Houston a utilisé une vidéo de 3 minutes pour valider (précisément !) une intuition sur ce que les clients attendaient d’une solution de synchronisation.

• Innovation Accounting: C'est la partie du livre qui relève de l’analyse systémique, ou Eric Ries définit le cycle build-measure-learn pour le processus d’acquisition de “validated learning”. Cette partie est difficile à résumer car elle contient un “cours systémique” sur les différents types de business models, et les indicateurs qui sont pertinents en fonction de ces business models. On retrouve ici le message clé du chapitre 2 de “Processus et Entreprise 2.0”: pas d’indicateur sans modèle (une mesure n’apporte rien si on ne peut pas l’interpréter avec un modèle de fonctionnement). Pour citer Eric Ries “When cause and effect is clearly understood, people are better able to learn from their actions”. L’objectif de l’ « innovation accounting” est d’établir la corrélation entre les progrès - vus et mesurés sur le de vue du client - et les changements sur le produit (ce que l’entreprise développe). Un des points clés est que l’approche “validated learning”, qui forme une sorte de roue d’amélioration continue, est une force de progrès : les réactions négatives des clients sont aussi importantes et utiles que les réactions positives. Elles contribuent dans les deux cas à accroître la connaissance acquise. Selon les termes d’Eric Ries, “the solution is a commitment to iteration”.
• Flows: Les flux de clients sont l’ingrédient principal des business models que nous venons d’évoquer. La section (hélas trop courte de mon point de vue) sur l'analyse des flux clients, des cycles de vie, des cohortes, devrait faire partie du kit de survie pour les managers. Il y a ici, rassemblées en quelques pages, des leçons que j’ai mis un certain temps à apprendre et qui sont essentielles. J'utilise ce type de situation lorsque je donne des exemples pratiques de l'intérêt de l'approche systémique (ma question préférée est : si on attend assez longtemps, est-ce que les parts de parc des opérateurs convergent vers les parts de parc ?)
• Small batches : il faut réduire la taille des “unités d’œuvre” (projets, logiciels, expériences, produits) et travailler avec un cycle rapide de petits incréments. Cette section est une application "text-book" du lean, mais elle est remarquablement expliquée et instanciée. Comme c'est un des axes majeurs d'amélioration pour les directions innovation et développement, c'est un apport majeur de mon point de vue (voir par exemple la remarque sur l'émergence du rework dès que les batchs sont trop importants). Les explications sur les "common misconceptions about the strengths of large batches" illustrent ce qui fait la force du livre : Eric Ries a bien compris et analysé nos résistances au changement (de façon de voir le monde) que représente le lean. Le cycle rapide permet de prendre en compte plus vite le retour client (cf. MVP) et de façon plus générale, il est mieux adapté à un environnement incertain puisqu’il permet de “corriger le tir” plus facilement (l’incertitude étant liée aux attentes clients, aux coûts de développement, à ce que font les concurrents, etc.)

• On retrouve au long du livre d’autres principes du TPS qui sont adaptés au monde de la start-up, comme par exemple la mise en œuvre des “5 Whys”.

La référence qu’Eric Ries sur le sujet de « small batches » est « The Principles of Product Development Flow » de Donald Reinertsen. Je me suis donc empressé de l’acheter et de le lire. Même si le style auto-glorifiant peut agacer, c’est un excellent livre, et c’est la meilleure référence que je connaisse sur le lien entre le lean et la théorie des files d’attente. Cette proximité

systémique est évidente (j’y ai fait allusion dans ce blog et dans mon livre), on la trouve mentionné dans les livres de Michael Georges par exemple. Mais le livre de Reinertsen est, de beaucoup, le plus complet sur ce thème. Pour que les choses soient claires, il ne s’agit pas de réduire le « lean » à une optimisation systémique de la tuyauterie ! Mais il y a une dimension systémique qui hérite de nombreuses disciplines de l’ingénierie de systèmes, depuis les files d’attentes aux réseaux de communication en passant par la conception de systèmes d’exploitation. C’est la contribution principale du livre de Reinertsen, avec une belle bibliographie qui démontre la largeur de sa culture en termes d’optimisation de systèmes. Voici une liste des points qui m’ont le plus intéressé, sachant que je n’insiste pas sur ce que je considère acquis (l'apport de la théorie des files d'attente et ses formules):

• Le premier chapitre « What is the problem ? » commence avec une jolie liste de 12 difficultés liées à l’approche classique du développement de produit. Cette liste est fort pertinente, selon mon expérience, et s’applique aussi bien au développement de logiciel qu’au développement de services, deux activités que je pratique depuis fort longtemps. Ce sera le sujet du prochain European Lean IT Forum, que je vous recommande. Un des points clés (cf. Lean Startup) est que le « fast feedback is key to product development ».
• Un des aspects original du livre est d’aller chercher dans l’expérience de la stratégie militaire des leçons d’organisation, en favorisant le “decentralized control & alignment”.
• La dimension cruciale qui justifie l’application des principes lean au développement de produit est le « Cost of Delay », qui est souvent caché, mal compris voire ignoré. Le COD reçoit une attention toute particulière dans ce livre, avec de nombreux exemples. Dans le modèle générique d’entreprise que je développe (BPEM – le sujet d’un prochain billet et d’un article), je fais du COD une des métriques clé de la performance d’entreprise. Reinertsen propose une analyse dont il déduit des « formules sympathiques », comme celle de la page 69 qui donne le débit optimal en fonction du COD et du « Cost of Capacity ».
• Le livre est émaillé d’application aux organisations modernes et de citations réjouissantes (même si elles sont caricaturales) du type « Capacity is restricted because marketing resources tend to be spread across many opportunities with a low duty-cycle on each activity ».
• On trouve page 98 un joli diagramme systémique qui explique les avantages des « small batches » (cf. plus haut). L’application à l’activité de test logiciel (par exemple, p. 129) est très intéressante. Une citation a propos du TPS : « The 100-fold improvement in manufacturing cycle times was not achieved by finding bottlenecks and adding capacity to the bottlenecks. It was achieved by reducing batch size”. Je vous recommande la liste des examples pratiques, page 136, de “batch size” dans le monde du développement de produit ou de logiciel.
• De la même façon, le concept clé du WIP (Work in Process) est très bien expliqué. L’application de la formule de Little qui lie le WIP au cycle time est mentionné, puis de nombreux exemples/applications pratiques sont mentionnés : shedding requirements , purging low-value projects , blocking demands when WIP reached its upper limit, applying extra resources to an emerging queue, etc. Ce dernier point m’a évidemment rappelé les expériences faites il y a 6 ans sur l’optimisation des processus informatiques (OAI). Un des principes essentiel du maintien des SLA (qualité de service) est la bonne gestion des cas d’exception (cf. p. 160). On y trouver également une reconstruction brillante du heijunka de Toyota : le lissage de la charge à travers des mix d’activité. Une citation sur le contrôle de l’injection de nouveaux projets dans le cycle de développement : « By controling density, we control speed and throughput » (analogie avec l’injection de véhicule sur les autoroutes de Los Angeles pour éviter les bouchons).
• Un autre aspect original du livre est de faire le lien entre l’efficacité d’un processus de développement (vu comme un problème de flot) et les techniques employées dans les réseaux de données (ex : réseaux IP) , telles que le throttling. J’ai particulièrement apprécié ce point puisqu’il fait le lien entre mes deux démarches : l’optimisation des systèmes d’information (cf. mon autre blog et le papier précédemment cité) et l’optimisation de la performance d’entreprise. Reinertsen milite pour « The principle of Differential Service : Differentiate quality of service by workstream » (p. 161), qui est précisément que l’objectif de l’optimisation des processus dans un système d’information. Ce n’est donc pas une surprise si l’on retrouve des approches heuristiques semblables (en termes de priorisation par exemple). Je reviendrai sur ce point technique lorsque j’aurai eu l’occasion de faire des simulations computationelles. En passant, tout n’est pas parfait dans ce livre : la vision sur les algorithmes de scheduling est quelque peu naïve … le sujet est plus complexe que ce pense Reinertsen (il fut un temps ou j’étais un spécialiste de ce sujet).
• Pour finir, ce livre couvre en détail les aspects temporels de la gestion de processus : cadence, synchronization, … On trouve (ex : p.177) des explications imagées et pratiques pour saisir le rôle fondamental de la synchronisation dans le travail des « knowledge workers », une idée que j’ai souvent exprimée dans ce blog, mais qui est remarquablement expliquée par Reinertsen. Je cite par exemple : « Many people assume that holding meetings on-demand will provide faster response time than holding them on a regular cadence. This would be true if everyone was just sitting idle, waiting to be called to a meeting. However, most organizations are loaded to high-utilization rates. It takes time to synchronize schedules for a meeting. This adds an inherent delay, or latency, to the timing of an on-demand meeting”. Une autre citation que j’apprécie parce qu’elle recouvre ce que j’ai appris concrètement sur l’urbanisation des SI: “ In asynchronous circuit, we pass the signal to the next gate as soon as it arrives. This reduces delays, but it permits timing errors to accumulate. In general, asynchronous circuits are faster, but synchronous circuits are more stable”. Ce principe est appliqué avec bonheur aux revues de projet, montrant la supériorité d’une approche synchrone et régulière sur une approche asynchrone (telle que produite par l’email).

La Bureaucratie Moderne – l’organisation rétrograde mutante

J’ai terminé avec le plus grand bonheur la lecture du dernier livre de François Dupuy, « Lost in Management », ce qui m’a conduit à réfléchir sur les formes persistantes de bureaucratie. La bureaucratie peut être considérée comme l’aboutissement de l’organisation du 20^e siècle.

Commençons donc, comme d’habitude, par une liste de quelques points clés de « Lost in Management ». Il s’agit une fois de plus d’un livre qui ne se prête pas au résumé, puisque c’est le travail d’un sociologue, issu des observations « de terrain ». François Dupuy a un vrai talent (et j’ai eu le plaisir de l’entendre présenter ce livre lors d’une conférence de l’ ANVIE) de raconteur d’histoires, avec beaucoup d’humour et des formules qui font mouche. Ce qui suit ne fait donc pas justice à ce livre que je recommande chaleureusement :

• Les bureaucraties sont des organisations tournées vers leurs besoins internes. François Dupuy nous rappelle cette observation avec force. L’ « obsession du client » a remplacé l’écoute de celui-ci, et l’entreprise s’organise autour de ses besoins propres (reporting, procédures, décisions). Le « couple infernal intégration-processus » est l’outil principal de cette bureaucratie moderne. La bureaucratie engendre la segmentation car les organisations ont peur du risque et la segmentation des responsabilités est une protection contre la prise de risque.
• Les entreprises parlent beaucoup de simplicité, pourtant elles s’en méfient. Cela relève d’une tendance des organisations – et pas seulement des entreprises – à valoriser les thèmes qui sont à l’exact opposé de leurs pratiques (p. 164). La simplicité n’est pas la clarté : peu de choses sont « claires » dans la vie collective et le recours à la notion de transparence – « dis moi tout et je ne te dirais rien » - n’en paraît que davantage manipulateur (p. 246). C’est un point fondamental : dans un monde complexe, la simplicité de l’entreprise est une « simplicité des relations et des modes de travail », il ne s’agit pas de pouvoir tout formaliser et tout expliquer.
• Le cloisonnement protège les collaborateurs du sentiment de responsabilité. Les « silos » sont les «paradis des experts ». La forme segmentée et séquentielle du travail protège différemment les membres de l’organisation (p. 65). Cette forme, héritage du Taylorisme, permet à chacun « de vivre dans son coin », en développant sa propre logique, sans confrontation, mais sans réelle responsabilité non plus.
• Un des points essentiel du livre est que les règles « ne sont importantes que par l’usage que les acteurs en font ». Les règles ne définissent pas le jeu, elles le structurent (p. 145). On retrouve ici le « mythe de la clarté » : vouloir tout formaliser et attribuer tous les rôles sans ambigüité est d’une part réducteur et d’autre part générateur d’une complexité dans les modes de travail (la « clarté » chasse la simplicité).
• François Dupuy dénonce avec beaucoup d’humour l’abus des KPI. Il dénonce en premier lieu leur trop grand nombre, et les conflits logiques que cette abondance entraine. Cette « sur-contrainte » est contre-productive et entraine des comportements de défense. Plus profondément, cet abus traduit une volonté de sur-contrôle qui, parce qu’elle est privée de sens, conduit à une absence de contrôle. La direction dispose de tableaux de bord multiples, mais ne sait plus ce qui se passe. Pour contrer la tendance naturelle de la perte de pouvoir liée à l’accroissement de la complexité, les managers en demandent toujours plus en termes d’indicateurs, d’objectifs, de données, utiles ou non (p. 141).
• Il insiste sur l’importance du « management de terrain » et fait le lien avec le « Toyotisme » (le Toyota Production System de Taiichi Ohno). Les directions générales doivent relever le défi de la confiance dans le management de proximité (et ne pas céder à la tentation du panoptique).
• Un point remarquablement intéressant est l’importance du pouvoir local, avec une certaine forme d’arbitraire, au sens du libre arbitre. L’application bornée des règles, des méthodes ou des standards (qui est au contraire au lean management de Toyota) conduit à supprimer cette autonomie locale et ce pouvoir d’innover, ce qui tue la capacité à progresser. Je renvoie le lecteur à mon chapitre 2 ou aux écrits de Michael Ballé.
• Le livre se termine sur trois cas fort intéressants d’entreprises qui semblent avoir dépassé ces difficultés. On y trouve –surprise ?- des « chevauchements » dans les responsabilités, une organisation « floue », et la capacité à travailler ensemble sans être forcément proche, parce chacun bénéficie d’un haut degré d’autonomie, et a conscience de participer à un jeu collectif.

Il est clair en lisant François Dupuy, ou en regardant autour de soi (cf. les enquêtes sur le désinvestissement dans le travail), que les bureaucraties ne sont pas mortes. Elles ont évolué sous une forme mutante que je qualifierai de « bureaucratie moderne ». Voici quelques traits caractéristiques de ces organisations :

• Suivant les principes de Frederick Taylor, elles séparent ceux qui font de ceux qui disent comment faire. C’est le principe du « bureau des méthodes », un principe de spécialisation de l’organisation du travail (des autres).
• Les responsabilités sont découpées et spécialisées, ce que François Dupuy observe comme une « segmentation des responsabilités », qui une réponse à la peur du risque.
• La technique est subordonnée, vassalisée voire sous-traitée. « Il ne fait pas raisonner d’un point de vue technique » est devenu une excuse pour s’affranchir des contraintes techniques, qui sont reléguées dans des organisations satellites, et apparaissent souvent de façon tardive dans les processus de développements.
• L’écoute du client est devenue « l’obsession du client », une affaire de spécialistes.
• Face à un environnement qui se complexifie, l’entreprise cherche à minimiser ses risques et augmente de façon constante les étapes de validation préliminaire, au détriment de la rapidité.

Les lecteurs de ce blog auront tout de suite repéré que ces caractéristiques sont en contradiction avec les principes de l’entreprise du 21^e siècle, telle que je la décrit dans mon livre, ou plus simplement avec ceux du lean management.

• La séparation entre le métier et la technique est devenue contre-productive dans ce siècle de technologie numérique. L’intrication de la technologie dans nos processus et nos usages est trop forte pour que cette séparation fonctionne. L’innovation vient d’une compréhension conjointe des enjeux métiers et des enjeux technologiques. C’est ce que pratiquent avec bonheur les startups de la Silicon Valley (mon prochain billet sera sur « The Lean Startup » d’Eric Ries).
• La séparation entre l’opération et la conceptualisation ne fonctionne plus dans un monde complexe. C’est brillamment expliqué par Mintzberg dans « Managing » et c’est la base du « genchi genbutsu » du lean management.
• L’orientation client est l’affaire de tous et de toutes les oreilles de l’entreprise. C’est un autre principe du lean management.
• Le processus appartient à ses acteurs, auxquels il ne faut pas confisquer la responsabilité. Le principe du kaizen requiert des acteurs autonomes et responsables, c’est une condition indispensable pour le progrès.
• La surcharge d’indicateurs est le symptôme du sur-contrôle, d’une soif de « tout savoir » qui est incompatible avec la complexité des activités aujourd’hui. C’est la tentation du panoptique de Bentham.

Les caractéristiques opposées de l’entreprise du 21^e siècle, telles qu’elles émergent de façon consensuelle dans la majorité des ouvrages sur le management que j’ai pu citer (dans ce blog ou dans mon livre) sont :

• Le « lean management »,
• La co-construction, (qui conduit à des organisation floues avec des recouvrements),
• Le développement agile, avec le raccourcissement des chaînes de décision et l’implication de tous « sur le terrain »,
• La prise de risque, et donc la valorisation de la culture d’entreprenariat,
• La délégation, pour favoriser l’autonomie qui est vitale pour être plus rapide et plus pertinent.