L’architecture organisationnelle est sensible à l’échelle

Le billet de ce jour fait suite à l’excellent article de Bertrand Duperrin sur l’effet de l’échelle sur les modes d’organisation.  La taille d’une organisation influe sur les modes de prise de décision, de transfert d’information ou de coopération, ce qui fait que les « bonnes recettes » à 10 personnes ne fonctionnent pas forcément à 100 ou encore moins à 1000. Plus précisément, un grand nombre de problèmes apparaissent lorsque la taille augmente, et l’efficacité n’est pas proportionnelle à la force de travail disponible. Cette constatation n’est pas sans rappeler ce qu’on observe dans les systèmes parallèles (cf. la loi d’Admdhal) qui montre que la puissance que l’on obtient en multipliant les processeurs est compensée par la tâche croissante de synchronisation. Ce n’est pas une surprise : les petites structures souffrent moins des problèmes de coordination et de synchronisation !

Bien entendu, la taille n’est pas simplement l’expression du nombre de collaborateurs de l’entreprise. La véritable question est de savoir si l’ensemble des collaborateurs et des équipes sont indépendants ou interdépendants. Si l’on introduit le « diamètre informationnel » (nombre moyen de personnes avec lesquelles chacun a besoin d’interagir pour réaliser ses objectifs), on peut définir un « coefficient de transversalité comme le rapport de ce diamètre sur la taille de l’entreprise (DI/N).  Ce coefficient est semblable au coefficient de complexité que l’on peut définir pour un système d’information : s’il est proche de un, on a une complexité maximale, tandis que s’il est proche de 0, on est en présence de « complication », c'est-à-dire la multiplication d’entités indépendantes. De nombreuses grandes entreprises ont des coefficients faibles car elles sont constituées de multiples agences, branches, projets indépendant. C’est le cas par exemple dans la construction. A l’inverse, dans la téléphonie mobile, le coefficient de transversalité est élevé. Pour reprendre une citation de Martin Bouygues qui date d’une dizaine d’année, « des milliers d’employés collaborent pour chacun des clients ». La tentation d’éviter les tares des grandes organisations opérationnelles en les découpant en plus petites est pertinente si le coefficient est faible, et pas forcément efficace dans le cas contraire. Ce qui nous ramène à la thèse initiale : la bonne organisation dépend du contexte et de la taille.

Il a y a de nombreux indices qui conforte la thèse de Bertrand Duperrin. Sans être exhaustif (ce qui dépasse le cadre d’un billet de blog), voici quatre pistes intéressantes :

• Il existe de nombreuses dimensions caractéristiques des réseaux sociaux et des interactions humaines. Dans un billet précédent, je citais Dunbar et Christian Morel. Je ne reviens pas sur l’importance du nombre de Dunbar, souligné justement par Bertrand Duperrin. Je pense que la taille de 150 est un seuil critique dans la gestion des organisations, et ceci est conforté par 20 ans de discussions avec des managers opérationnels. Les expériences citées par Christian Morel et par d’autres montrent que la responsabilisation est très sensible à l’échelle : dès que le groupe augmente, chacun sens sa responsabilité diluée et bientôt personne ne se sent responsable.
• Ces dimensions sont essentielles dès qu’on observe la dynamique d’un groupe par exemple dans une réunion. Cette importance critique du nombre de participants est liée en premier lieu au besoin d’appropriation et de reformulation, un sujet que j’ai évoqué maintes fois dans ce blog. C’est ce qui explique qu’en dehors des réunions d’information, il existe des tailles idéales pour des réunions de brainstorming ou de prises de décision, entre 7 et 10. Je vous renvoie au chapitre 4 de mon dernier livre.
• Plus globalement, si l’on observe l’organisation de la coordination d’une entreprise au moyen de ses processus, il y a une coexistence de tâches dont la complexité est linéaire en fonction de l’activité et d’autres dont la complexité est plus ou moins quadratique. C’est le thème principal de ce blog et de mon dernier livre : dans le monde complexe du 21^e siècle, les activités de communication qui sont nécessaires pour coordonner des tâches obtenues par décomposition d’un objectif unique prennent une part sans cesse croissante du temps actif disponible. C’est ce qui explique les limites de la Taylorisation : en décomposant/spécialisant, on multiplie des interfaces qui, contrairement à la vision mécanique du 20^e siècle, exigent des flux d’information de coordination à complexité quadratique. Cette complexité en O(n^2) est le produit du nombre de ruptures (linéaire) et de la complexité du sujet traité (au minimum linéaire). On pourrait même dire pour simplifier que si la complexité du processus est linéaire en fonction de l’activité, on est dans un monde compliqué et on applique la décomposition de Descartes, et si la complexité est quadratique ou plus, on est dans un monde complexe.
•  On pourrait penser  qu’il s’agit d’un exercice rhétorique, mais l’impact des dimensions caractéristiques des organisations sur l’efficacité des transferts d’information se constate, se modélise et se simule. C’est précisément l’objet de l’approche SIFOA que j’ai présenté il y a quelques années. Dès que l’organisation dépasse une certaine taille, les échanges indirects (qui passent par la médiation d’une autre personne, d’un groupe ou d’un support) dominent les échanges directs. De plus, en fonction de la taille, la longueur de ces chaines augmente (ce qui est fort logique) et cela modifie profondément le temps pour transmettre (la latence), la fidélité et l’appropriation. Si l’on souscrit à la thèse de March & Simon qu’une des fonctions clés du management est de gérer les flux d’information, il est clair que cette structure de management est forcément sensible à l’échelle.

Le fait que l’architecture organisationnelle soit sensible à l’échelle a plusieurs conséquences importantes, qui doivent nous conduire à être méfiants par rapport aux messages simplificateurs et trop zélés qui circulent sur le thème « small is beautiful » :

1. Le modèle de la start-up n’est pas un modèle universel indépendant de l’échelle. On trouve partout des articles sur la puissance des « small teams ». Il ne s’agit pas de nier cette évidence sociologique et factuelle, mais tout ne peut pas être accompli par des petites équipes. Un des rôles de l’organisation et du management est précisément de coordonner des équipes « à taille humaine » pour relever « des grands défis ».  On lit pas mal d’article en ce moment sur « la fin du management », l’efficacité des organisations sans management, la puissance de l’auto-organisation, etc. Le thème à la mode devient « se débarrasser des managers ». Au contraire, tout comme Philippe Korda que je cite dans le chapitre 9 de mon dernier livre (qui traite précisément du rôle des managers), je pense que le management a une responsabilité essentielle dans la transformation de l’entreprise face aux défis de l’agilité et de la complexité.  Il est clair que tout ce que j’écris depuis quelque temps d’appuie sur la « puissance des petites équipes », en particulier les méthodes agiles de développement et le lean software development. En revanche, il ne faut pas s’y tromper, ces bénéfices sont très fortement dépendant de l’échelle et on n’organise pas une grande équipe comme une petite (ce qui est très bien expliqué par Bertrand Duperrin). De la même façon, je souscris aux thèses de Clay Shirky et je considère l’auto-organisation comme une des vertus de l’entreprise 2.0. En revanche, tout ne se règle pas par auto-organisation.
2. Il faut donc bénéficier des avantages des « small teams », au sein d’une architecture modulaire semblable à celle du système d’information. Le terme de modularité n’est pas une surprise, puisque l’objectif d’une architecture modulaire est précisément de casser (le plus possible) les effets négatifs d’une complexité quadratique des interactions. Une architecture  ou une organisation modulaire identifie des « modules » les plus indépendants possibles. Michael Ballé m’a fait fort justement remarquer que le « lean management » gère cette problématique avec des équipes autonomes et indépendantes, reliées par des interfaces « dures » (stables et contraignantes). Une des craintes des spécialistes du lean par rapport aux pratiques 2.0 est qu’elles créent des interfaces « molles » et renforce les dépendances. Cette crainte est légitime et mérite d’être adressée : il faut pratiquer le « social business » de façon modulaire, avec des règles. Pour poursuivre le parallèle avec le monde du système d’information, on retrouve les principes du SOA : organiser en termes de services, définis par des interfaces « strictes » pour favoriser l’encapsulation, c’est-à-dire l’autonomie locale. J’aurai donc pu intituler ce billet « Organizational Design is not scale-free », pour faire un clin d’œil avec un billet précédent « SOA is not scale-free ».
3. Les équipes doivent être organisées au sein d’une structure, avec un véritable management qui joue un rôle, et qui s’appuie sur une culture propre aux grandes organisations, celle de la maîtrise de la complexité. Ce sujet mériterait un billet (voire un livre) à lui tout seul, un des aspects les plus intéressants (car lié de façon antagoniste aux principes lean et agiles) est le besoin de synthèse. Manager et piloter une grande organisation exige de pouvoir abstraire et synthétiser. Cette constatation, qui était une évidence il y a 20 ans, est confrontée au principe opposé de réalisme, du genchi genbutsu, du travail sur la situation réelle, sur les « signaux faibles », tel qu’exprimé par Henri Mintzberg. On trouve ici une autre tension créatrice, entre le pilotage de ce qui est complexe (pour lequel il faut se méfier de la synthèse et de l’abstraction) et le pilotage de ce qui est compliqué. Je n’ai pas de solution « magique », mais la conviction que le « lean manager » d’une organisation de 10000 personnes ne travaille pas comme celui d’une organisation de 100 personnes.

En revanche, on peut tirer de ces observations un certain nombre de principes qui gouvernent les liens entre l’échelle et l’organisation du management. Par symétrie et pour rester concis, je vous propose les trois points suivants :

1.  La structure de coordination de l’entreprise – en particulier les réseaux créés par l’Entreprise 2.0 - est une structure multi-échelle, elle ne globalise pas les problèmes, mais elle se décline de façon fractale à des échelles multiples. C’est la réponse que propose Andrew Mc Caffee dans son livre Entreprise 2.0 à la critique légitime exprimée plus haut. L’objectif du « social business » n’est pas de décloisonner l’entreprise au point de la transformer en « bazar » (clin d’œil assumé a Eric Raymond). Le management est également un des réseaux sociaux spécialisé de l’entreprise et sa structure doit posséder la même propriété de « modularité / self-similarité » que celle qui est attendue des plateformes collaboratives 2.0.
2. La science des réseaux sociaux nous enseigne qu’une bonne structure de coordination est « scale-free » dans un sens très particulier qui signifie que la répartition des degrés dans les nœuds de connexion suit une « power law », ce qui implique qu’il existe de nombreux nœuds très connectés. La nature et l’ingéniosité humaine font très fréquemment appel à la puissance des « scale-free networks ». Pour reprendre quelques exemples proposés par  D. Watts et  A.-L. Barabasi, les réactions chimiques de notre métabolisme sont organisées avec un réseau dont la robustesse est la conséquence de sa structure. Le Web est un autre exemple de réseau auto-organisé qui s’appuie sur une distribution « scale-free ».  Les réseaux « scale-free » combinent un maillage serré et un maillage large, les nœuds à forts degrés jouent un rôle de connecteur – pour reprendre l’analyse de Malcom Gladwell – et la distribution en « loi de puissance » garantit qu’ils sont suffisamment nombreux pour obtenir une grande efficacité et une forte robustesse. On évite de la sorte les « bottlenecks », les nœuds à trop forte centralité qui seraient « des points de passage obligés » et donc des « lieux de pouvoir » (cf. les « Structural holes » de Ronald Burt). Bertrand Duperrin cite un article très intéressant sur les architectures « podulaires ». Un réseau podulaire est la combinaison de  petits sous-graphes fortement connectés (les pods) dans un maillage plus large. On retrouve très précisément la structure des « petits mondes » de Duncan Watts, ainsi que la nécessité de combiner les «liens faibles » et « la puissance des cliques ». J’ai publié cet année un article intitulé «Efficiency of Meetings as a Communication Channel : A Social Network Analysis » lors de la conférence Management and Social Networks qui démontre que la structure des réseaux de comités est plus efficace si elle applique ce principe des petits mondes, l’hybridation entre des petits groupes fortement connectés et des réunions plus vastes et plus transverses.
3. Les conclusions de Daniel Pink sur la motivation offrent une clé pour comprendre les principes du management de la  « Lean Enterprise 2.0 ». J’ai cité de nombreuses fois Daniel Pink, auteur de l’excellent A Whole New Mind, qui présente plusieurs talks passionnants sur TED sur la motivation (dont la célèbre version animée). Rappelons que sa conclusion est que la motivation des collaborateurs s’appuie sur trois choses : l’autonomie, la maîtrise (mastery en anglais, le sens de progresser chaque jour dans la maîtrise et le perfectionnement d’une pratique) et le sens, le fait de savoir que son travail contribue à quelque chose de plus grand, de pouvoir placer sa propre action par rapport à un objectif (comme le propose Philippe Korda, il faut lire Viktor Franckl sur ce sujet).  On trouve dans cette conclusion une clé d’articulation pour le management : l’autonomie est fournie par l’utilisation de « small teams », le « mastery » est une des ambitions des pratiques du lean, et le management est bien là pour expliquer et nourrir le « sens ».  Ce sens est à la fois la stratégie, le « true North », mais c’est également une histoire qui permet à chacun de comprendre comment il contribue par son travail à la réalisation de l’objectif commun.

L’innovation digitale est dans le code

L’innovation est un des thèmes a la mode, on en parle partout, la fonction de directeur de l’innovation s’est développée et est mise a l’honneur dans des conférences spécialisées (par exemple: les rencontres nationales des directeurs de l’innovation). Elle reçoit l’attention de toutes sortes de consultants qui proposent des méthodes pour cultiver, favoriser, faire émerger (nous sommes bien dans le management de l’émergence) les innovations dans les entreprises. “Innovation” est un terme polysémique qui désigne aussi bien l’innovation interne, tournée vers l’amélioration continue des processus, que l’innovation externe, dont le but est de développer des nouveaux produits et services. Pour donner plus de sens à segmentation, je vous conseille de lire cet article de Cecil Dijoux sur la vision de Peter Drucker. Dans ce billet, je vais m’intéresser de façon spécifique au deuxième type d’innovation, dans le domaine particulier du monde numérique (qui concerne de plus en plus d’entreprises). Le fil rouge de ce billet est que le discours “innovation sociale” (l’innovation est l’affaire de tous, tissons les liens faibles, encourageons les bonnes idées, faisons des concours, etc.), même s’il est pertinent dans le cadre de l’innovation continue (premier type) - et je dois reconnaitre que je me le suis approprie dans mon livre “Processus et Entreprise 2.0” (lien) ;) - manque de “mordant” pour être efficace et approprié pour produire des innovations numériques utiles.               

La première conviction forte est que, dans ce monde numérique du 21e siècle, ce ne sont pas les idées qui comptent, c’est la réalisation irréprochable qui apporte simplicité et utilité au client. Tout le monde a les mêmes idées, et il n’est vraiment pas difficile de produire des idées. Ce qui distingue les entreprises, c’est d’une part la rapidité d’exécution, mais encore plus la qualité de l’exécution. Pour paraphraser Steve jobs, “the innovation is the code”. Beaucoup de consultants sont venus dans mon bureau pour me proposer des “ideation methods”, des méthodes pour produire des idées. Comme je l’ai déjà écrit, je suis un disciple de “The Lean Startup”: ce qui mesure la valeur du processus d’innovation n’est pas la création d’idées, mais la validation par un feedback utilisateur des “idées qui marchent”, ce qu’Eric Ries appelle le “validated learning”. Il faut donc aller chercher ce retour client, le plus rapidement possible (un principe lean mais également une obligation par rapport aux concurrents) et itérer jusqu’a l’obtention d’une véritable innovation utile, qui, selon la formule consacrée, “résout un problème du client”.      

Dans un monde complexe - et le domaine numérique/logiciel est complexe - pour produire “une idée qui marche”, il faut faire et pas seulement réfléchir. On retrouve ici une des idées clés de mes présentations à Lean IT Summit et Entreprise 2.0 Summit, exposée dans le premier chapitre de mon livre. Le véhicule propose par Eric Ries est le MVP (Minimum Viable Product): il s’agit de montrer au client “du code qui marche”, selon le motto de l’IETF  “nous croyons a un consensus grossier et a du code qui tourne”. C’est bien la recette pour construire le MVP: obtenir un consensus grossier entre marketing, designer et développeur (et surtout pas une spécification détaillée) et laisser les développeurs produire le MVP, en cycle itératif (lien sur BDIS) et en mode plateau/agile. La véritable innovation se produit par alchimie, par la participation des différentes voix et parce qu’on laisse suffisamment d’autonomie a ceux qui produisent le code pour exprimer leur talent.    

L’innovation n’est pas portée par des idées, elle est portée par des femmes et des hommes. C’est ce qu’expriment les quelques maximes du “pretotyping manifesto”:

• innovators beat ideas
• doing beat talking
•  commitment beats committees

Il n’y a pas de surprise ici, puisque le mouvement “pretotyping” est inspiré, entre autres, par Eric Ries. J’aurai pu citer certaines « vérités » de Google, rappelées par Mark Striebeck : « Focus on the user and all else will follow », « Fast is better than slow ». Chez Facebook, on trouve :

•      code wins
•         done is better than perfect

Toutes ces maximes tournent autour de deux idées : l’innovation est dans le code (dans l’acte) et il faut produire ce code selon une approche de « Lean Startup ». Ceci conduit rapidement au concept de Lean Software Development, mais cela sera le sujet d’un autre billet.

Promouvoir l’innovation numérique ne consiste donc pas à organiser des grands concours pour récompenser les bonnes idées (ces concours ont leur utilité propre néanmoins), mais à donner des moyens et de l’autonomie à ceux qui peuvent transformer l’idée en MVP (ce qui est plus qu’un POC - proof of concept). Remarquons d’ailleurs que des entreprises américaines regroupent les deux puisque la récompense du concours d’idée est précisément l’accès à des moyens pour développer l’idée. Le management a donc un rôle essentiel à jouer, dont la première partie consiste à savoir s’effacer. Je vous renvoie au chapitre 9 de « Processus et Entreprise 2.0 ». De la même façon, toujours pour citer Steve Jobs, « you can’t ask customers what they want and try to give it to them ». La co-invention avec le client est une approche intéressante, mais c’est un cas particulier. En général, ce que le client connait, c’est son problème, pas la solution. Le client a un rôle central dans la validation du MVP, mais l’innovation est dans la l’acte de fabrication et son itération.               

Pour conclure, je vais revenir sur ce thème du management de l’émergence. L’innovation se produit au carrefour de plusieurs principes contradictoires, créant des lieux de frottement et de tension. Concrètement, je vois trois oppositions:               

• la tension entre le “temps court” et le “temps long”. Il faut les deux pour innover : un temps court pour l’action et l’itération, mais également un temps long pour l’incubation. Je vous recommande l’excellent talk de Steven Johnson, dans lequel il parle des « slow hunchs ». Pour les disciples du lean, le « takt time » s’applique dans l’action, dans le processus de « validated learning », pas dans la phase préliminaire de gestation des idées. C’est un point important, plus large que l’innovation : tout ne se fait pas rapidement lorsqu’on « fait du lean ». Pour reprendre les métaphores agricoles de François Jullien, il y a un travail de préparation de la terre, qui se fait en amont et sur un temps long. Dans son très bon livre « The Myths of Innovation », Scott Berkun déclare que « The best lesson from the myths of Newton and Archimedes is to work passionately but to take breaks ».
• la tension entre la “force des liens faibles” et le “pouvoir des cliques”. C’était un des thèmes clés de la conférence « Management et Réseaux Sociaux » qui s’est tenue à Genève le mois dernier. Je ne reviens pas sur l’avantage des réseaux de liens faibles. C’est la thèse de Mark Granovetter, que j’ai exprimée de multiples fois dans ce blog. Ces liens faibles servent à sortir du cadre, à résoudre des crises, à produire des idées nouvelles. En revanche, les réseaux de liens forts (les gens que nous côtoyons quotidiennement) sont également très intéressants. Ils  ont un « cluster rate » élevé (forte transitivité, ils forment des cliques, c’est-à-dire des sous-graphes complets, des groupes de personnes fortement connectées). Les sociologues constatent que cet « environnement de clique » produit une plus grande intimité, une plus forte intensité émotionnelle et une plus grande confiance mutuelle. Le groupe produit un langage commun, il intensifie le support mutuel.  Ce sont précisément les caractéristiques d’une petite équipe (une start-up par exemple). La conclusion des sociologues est qu’il faut produire des organisations ambidextres, qui savent combiner liens faibles et liens forts, réconcilier « closure » et « brokerage ».
• la tension entre l’expertise et la pluridisciplinarité. L’expertise est nécessaire pour innover, c’est ce qu’exprime cette autre maxime de Google « It's best to do one thing really, really well ». Il faut également combiner les talents et diversifier les contributions. Le mécanisme qui réconcilie cette tension entre l’expertise et l’ouverture est celui de la plateforme (cf. le livre amusant de Jeff Jarvis, « What would Google do ? »). La plateforme est l’outil qui permet d’implémenter une stratégie d’innovation ouverte (contrairement à ce qu’on pourrait penser, ce n’est ni le chéquier pour acheter les solutions, ni le tableur Excel pour sélectionner les meilleures idées ;)). La plateforme est également le cœur des développements en « open source », une bonne synthèse entre expertise et multi-compétences.

C’est pour cela qu’il est difficile de proposer des méthodes, il faut savoir cultiver les contraires. Les concepts de méthode et d’innovation ne sont pas inconciliables, mais il faut plutôt s’appuyer sur les pratiques. Ce n’est pas un hasard si l’excellent livre de Langdon Morris «Permanent Innovation » fait référence à la citation d’Aristote « Nous sommes ce que nous faisons de manière répétée. L’excellence n’est donc pas une action mais une habitude ». Manager l’excellence, comme manager l’innovation, relève de la culture des habitudes.  Son chapitre 12, qui s’intitule « Doing It » contient 40 recommandations qui sont essentiellement des pratiques. Il faut également produire un alignement rigoureux sur ce que Michael Ballé appelle le “True North”. Il faut allier la variété des opinions et des points de vue à l’unicité de l’objectif, ciment d’une véritable collaboration et de création de valeur. Je conclurai en citant Geoffrey Moore dans “Dealing with Darwin”: « The lack of cooperation, however, is often caused by those very same leaders’ falling prey to the other enemy of innovation: lack of corporate alignment”.

Social Business Excellence : Le management du 21e siècle relève du jardinage

Je viens de mettre mes slides de « E2.0 summit » en ligne. Je n’ai malheureusement pu assister qu’à une petite partie, je ne vais donc pas faire de compte-rendu, mais plutôt partager quelques réflexions. Je vais partir de l’excellent exposé de Rawn Shah, avec qui je partageais le plaisir de faire le keynote d’introduction sur le thème « Social Business Excellence ». Le cœur de l’exposé était une analyse de la valeur créée par la pratique de l’entreprise 2.0, ce que l’on appelle « Social Business ». C’est un terme polysémique qui est en train d’évoluer. Au sens original de « business with a social objective » se rajoute une dimension de « faire de la collaboration un moteur de création de valeur » pour l’entreprise.  Autrement dit, « social business » désigne la pratique 2.0 dans l’entreprise (au sens large, indépendamment des outils, mais telle que je la décris dans « Processus et Entreprise 2.0 »).  Rawn distingue quatre dimensions/étapes de cette création de valeur :

• La capture d’information : le « social business » permet de mieux écouter les signaux faibles, au plus près des clients ou des événements. On peut dire que le social business implémente une forme « d’oreille distribuée ». L’entreprise 2.0 est mieux armée pour traiter les informations non-structurées.
• La collaboration/découverte : c’est la dimension la plus souvent évoquée, le « social busines » favorise la créativité et l’innovation.
• L’analyse, puisque le « social business » produit une intelligence collective. On retrouve ici des idées de « wisdom of crowds » et de « parallel processing ». Cette intelligence collective est particulièrement adaptée, par exemple, à la reconnaissance de patterns et, de façon logique, aux taches pour lesquelles on a facilement recours à une approche distribuée.
• La « transformation » de l’entreprise : le « social business » rend les processus de l’entreprise plus flexibles et plus résilients. La pratique 2.0 permet de mieux traiter les exceptions, un sujet que j’aborde également dans mon livre, et qui est très important car nous savons que le traitement des situations d’exception dans les processus absorbe beaucoup d’énergie et contribue de façon forte à la non-qualité. Le thème de la résilience, cher à Richard Collin, mériterai un billet à lui tout seul. Le lean, comme le social business, rendent l’entreprise plus robuste face aux crises (lire les livres de Jeffrey Liker).

Pour construire ce « social business » et profiter de ces bénéfices, il faut construire un écosystème de conditions favorables : « Online collaboration and social experience is a combination of many structured elements ». Une des slides de Rawn décrit cet écosystème sous la forme de plusieurs bulles :

• Les « lieux » : là ou les interactions et conversations qui constituent le « social business » prennent place, qu’il s’agisse de lieux réels ou virtuels,
• Les « objectifs / buts » : parce qu’une interaction suppose une communauté d’intérêt pour produire de la valeur, sous la forme de culture commune, de stratégie, d’intention, etc.,
• Les « personnes », organisées en réseaux, en communautés, ou dans la structure d’entreprise. La dimension humaine est bien évidemment fondamentale et se tisse autour de valeurs telles que le respect et la confiance, et de pratiques tels que la réputation et la transparence (pratique associée à la valeur « honnêteté intellectuelle »).

Faire émerger les conditions favorables pour que le « social business » fonctionne relève du management de l’émergence. Avec le paradoxe évident qu’il s’agit d’une action de long terme, alors que précisément son objet est de faire émerger une structure agile qui communique et réagisse le plus rapidement possible. Il faut revenir à François Jullien pour séparer le temps de la préparation et celui de l’action. Beaucoup de choses importantes s’obtiennent de façon émergente :

•  L’innovation, qui sera le sujet de mon prochain billet.
• L’auto-organisation (le sujet de nombreux exposés durant ces deux jours de conférence).
•  L’excellence, qui doit venir des acteurs eux-mêmes et ne peut être développée de l’extérieur par la contrainte. A ce sujet, je remercie Guillaume Fortaine d’avoir porté à mon attention cette superbe citation d’Aristote : « Nous sommes ce que nous faisons de manière répétée. L'excellence n'est donc pas une action mais une habitude." 

Nous sommes bien rentrés dans le monde de la complexité, il nous faut apprendre à manager les causes et non pas les effets. Michael Ballé insiste sur la pratique des « 5 pourquoi » comme un véritable cours de « systémie appliquée ». Se poser la question des 5 pourquoi consiste précisément à chercher les véritables causes (profondes) au lieu de se concentrer sur les symptômes.  Dans un monde simple,  il y a une dépendance presque linéaire entre les causes et les effets, et utiliser l’un plutôt que l’autre comme indicateur ne prête pas à conséquence. Dans un monde complexe, il faut manager les causes, tout en conservant un œil sur les effets – qui sont bien ce qui nous intéresse in fine.

Le jardinage est une superbe métaphore pour cette activité de travail lent et profond sur les causes, que j’ai déjà employée à l’USI pour parler d’innovation. Cette métaphore est directement empruntée à la sagesse Chinoise et à François Jullien : travailler son jardin consiste à développer le potentiel de situation, la capacité d’émergence. C’est un travail de terrain, et pas un travail en chambre. Comme pour la résolution de problème, la préparation du potentiel se situe sur le gemba (pour parler lean). Il s’agit bien de travailler en amont, pour que la plante pousse plus vite et devienne plus belle. Mais, comme le rapporte François Jullien, « on ne fait pas pousser la plante plus vite en tirant sur la tige ». Ce n’est pas par hasard si le jardinage plait davantage aux femmes qu’aux hommes, ou aux plus vieux qu’aux plus jeunes : c’est une marque de sagesse J Le jardinage, comme toute pratique qui est tournée vers l’émergence, demande de l’humilité mais réserve des joies profondes. En écoutant les différents exposés sur l’entreprise 2.0 et les conditions systémiques de la réussite du social business, je me suis convaincu que le travail du manager du 21^e siècle est un travail de jardinage.

Au-delà de cette riche métaphore, je me suis également convaincu de l’importance du SMI (Système de Management Intégré – je commets ici un léger abus de langage) pour réussir cette transformation, c’est-à-dire sur la conjonction de :

• Organisation : la structure hiérarchique et transversale (projets et processus),
• Les règles de fonctionnement : les procédures, les objectifs, les rôles, les indicateurs,
• Les comportements : pratiques, risques et récompense, la reconnaissance, l’engagement, etc.

Réussir la transformation vers l’entreprise 2.0 nécessite d’agir sur ces trois dimensions de façon simultanée. Il faut transformer l’organisation, son système d’information, les outils mis à disposition. Il faut également modifier les règles, les objectifs, les indicateurs de succès. Les règles de fonctionnement doivent évoluer pour permettre au « social business » de se développer. Pour finir, il faut  faire évoluer les comportements, ce qui nous ramène précisément au jardinage et à l’émergence.

Une autre question commune à l’ensemble des exposés de cette conférence est liée à la motivation. Comment motiver les acteurs de l’entreprise pour ce changement, comment donner envie ? Je vous renvoie pour conclure à ma vidéo favorite de Daniel Pink (l’auteur de nombreux best-sellers, dont « A Whole New Mind »). Daniel Pink explique brillamment qu’il faut s’appuyer sur la motivation intrinsèque, et non pas sur la motivation extrinsèque (tels que les récompenses, les bonus, etc.), qui elle-même se développe à partir de trois principes :

• L’autonomie des acteurs,
• La capacité à « devenir un maître » de sa propre activité (mastery), c’est-à-dire à pouvoir constater sa progression, développer sa propre excellence jusqu’à faire l’expérience du flow de Mihaly Csikszentmihalyi.
•  Le sens collectif, c’est-à-dire la capacité de chacun à replacer son action dans une œuvre collective, donnant à son travail un sens « qui dépasse l’action individuelle ».

 Les lecteurs assidus du blog auront reconnus le “blueprint” du Toyota Way, l’essence de ce qu’est le lean management, lorsqu’il n’est pas bêtement confondu avec du cost-cutting et de l’embrigadement. Au contraire, la pratique du kaizen s'appuie sur l'autonomie des équipes, la recherche de l'amélioration continue, l'utilisation des standards en perpétuel dépassement et la résolution de problèmes développent les compétences dans une perspective d'expertise, et l'accent mis sur "la voix du client", la recherche permanente de l'élimination du muda fournit un sens collectif, celui de la satisfaction complète du client à travers un produit ou un service. Je vous renvoie au 9^e chapitre de mon dernier livre qui reprend les idées de Daniel Pink pour esquisser le rôle du manager dans une « lean entreprise 2.0 », un rôle de « jardinage pour favoriser l’émergence de l’excellence ».

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.