dimanche, juin 03, 2018

La transformation numérique émerge de l’excellence logicielle




1. Introduction


Une idée clé de ce blog, comme de son cousin anglophone, est que la transformation numérique est une affaire de compétences. Autrement dit ce qui détermine en premier lieu le succès d’une stratégie numérique est son exécution, et cette exécution est avant tout une question de capacité, donc de compétences.
  • En particulier, je me suis intéressé à la synergie entre LeanStartup (« from customer to code ») et Devops (« from code to customer ») dans plusieurs de mes billets.

Le billet de ce jour est avant tout une fiche de lecture du livre de Nicol Forsgreen, Jez Humble et Gene Kim, « Accelerate ». Ce livre est la meilleure référence que je connaisse sur cette relation entre les performances des entreprises dans le monde numérique et leurs capacités logicielles de développement et déploiement. C’est probablement parce que les auteurs sont particulièrement pertinents et compétents sur le thème des « software factories » et des méthodes modernes de production et déploiement continus de logiciel. C’est également parce que ce livre est le résultat d’une approche quantitative et analytique, basée sur l’étude de plus de 20000 entreprises. Même si ce type d’approche est toujours soumise à questionnement, la méthode et les résultats obtenus font de ce livre une contribution fondamentale pour le dialogue entre métiers et informaticiens.

Ce billet est organisé comme suit. La deuxième partie est un résumé personnel et orienté des principales leçons que je tire de la lecture de « Accelerate ». Je l’ai structuré autout de dix points qui me semblent essentiels pour les entreprises qui sont engagées dans une « transformation numérique ». La partie suivante, beaucoup plus courte, revient sur la double flèche Lean Startup/ DevOps pour introduire la dimension fondamentale de l’effectuation. Cette partie fait suite au billet précédent sur les écrits de Philippe Silberzan. Les principes de l’effectuation capturent ce qui est dans le titre du billet : ce que l’on sait faire, ce qu’on a à portée de main, détermine le terrain de jeu que l’on peut pratiquer à une échelle de temps compatible avec le monde numérique. J’en déduis quelques conséquences sur le sujet de l’innovation numérique. Les observations contenues dans Accelerate ainsi que les lois empiriques de l’effectuation montrent à quel point la réussite d’une stratégie numérique est une question de compétences, de femmes et d’homme et d’attitude face à l’incertitude.


2. Construire des organisations digitales performantes grâce à DevOps 


Le livre qui sert de support au billet de ce jour, “Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”, est remarquable à un double titre. En premier lieu, c’est une excellente synthèse de l’approche DevOps et CICD (Continuous Integration and Continuous Delivery). Ceci n’est pas une surprise puisque le deuxième auteur, Jez Humble, est un des spécialistes reconnus du sujet. Son livre « Continuous Delivery » est la référence du domaine et un « must read » pour ceux qui mettent en place une chaine CICD. En deuxième lieu, ce livre se place dans la grande tradition américaine des livres qui souhaitent ancrer leurs recommandations dans l’analyse des faits. Pas moins de 20000 entreprises ont été questionnées sur leurs pratiques de développement logiciel pour essayer de déterminer celles qui ont un impact sur leur performance. Comme le sous-titre du livre l’indique « Building and Scaling High Performing Technology Organizations», l’ambition des auteurs est de proposer une synthèse des meilleures pratiques des entreprises performantes et de relier la performance de l’entreprise à la qualité du processus de production de logiciel. Comme le montre les exemples des best-sellers célèbres « In Search of Excellence » et « Good To Great », cette approche n’est pas exempte de risque et prête facilement le flanc à la critique (comme toujours, « corrélation n’est pas causation »). Néanmoins, comme pour ces deux livres, je pense que nous avons ici un ouvrage remarquable et très utile. Même si la démarche de démontrer les liens entre pratique logicielle et efficacité économique des entreprise numérique est éminemment complexe, cette approche est nécessaire et utiles pour ceux qui doivent convaincre les « parties prenantes » de l’entreprise.
Selon mon habitude, je propose ici un résumé illustré des quelques points qui m’ont le plus intéressé. Je vous recommande chaleureusement, on l’aura compris, de lire ce livre en entier et tranquillement.  La partie méthodologique,  que je n’aborde pas ici, cherche à nous convaincre de la validité de cette approche fondée sur l’analyse de réponses à des questionnaires détaillés. La dernière partie, que je ne fais qu’effleurer, est un témoignage détaillé de la banque ING aux Pays-Bas.

  1. La capacité à construire et déployer du logiciel est la fondation sur laquelle se construit le succès des entreprises numériques. Le monde est en accélération permanente à cause de la technologie, et au cœur de cette accélération se trouve le logiciel. Cela concerne toutes les organisations dans tous les secteurs d’activité. L’excellence logicielle est par conséquent un enjeu de compétitivité pour les entreprises : “This is true because software delivery is an exercise in continuous improvement, and our research shows that year over year the best keep getting better, and those who fail to improve fall further and further behind”. Ce message s’adresse à toutes les entreprises, puisque “software is eating the world”: “In all of our research, one thing has proved consistently true: since nearly every company relies on software, delivery performance is critical to any organization doing business today”. Cette excellence logicielle s’exprime et se mesure en termes de capacités. Les auteurs ont une profonde méfiance à l’encontre des modèles de maturités, parce qu’ils enferment ceux qui les pratiques dans le faux confort d’un horizon borné, tandis que le monde des capacités numérique est en bouleversement perpétuel : «  Maturity models define a static level of technological, process, and organizational abilities to achieve. They do not take into account the ever-changing nature of the technology and business landscape”. Faire de ses capacités numérique le premier enjeu d’une stratégie numérique implique de se concentrer sur les femmes et les hommes de l’entreprise, et de construire un “capital humain”. Maitriser les processus de développement et déploiement devient un tel levier de performance qu’il est essentiel d’associer ces compétences de la façon la plus intime possible avec le « core business » de l’entreprise : « The fact that software delivery performance matters provides a strong argument against outsourcing the development of software that is strategic to your business, and instead bringing this capability into the core of your organization”.

  2. La  « transformation digitale » n’est pas un objectif ou une destination, c’est un état d’esprit et une attitude. On retrouve ici une idée brillamment exprimée par Fred Cavazza dans son billet «La transition numérique a commencé il y a 20 ans, nous sommes maintenant dans une phase d’accélération digitale ». Le livre contient plusieurs exemples de mise en garde sévère contre une vision “mécanique” de la transformation consistant à implémenter des nouveaux processus, comme le développement agile, de façon uniforme, sans se soucier des changements culturels et du fort besoin de leadership pour créer une organisation apprenante. Cela d’autant plus que ces pratiques agiles sont souvent mal comprises pour produire ce que les auteurs appellent le « faux agile » : “However, much of what has been implemented is faux Agile—people following some of the common practices while failing to address wider organizational culture and processes. …Many development teams working in organizations that claim to be Agile are nonetheless obliged to follow requirements created by different teams. This restriction can create some real problems and can result in products that don’t actually delight and engage customers and won’t deliver the expected business results”. Beaucoup de ces entreprises n’ont pas modifié leur façon de voir le monde et continuent à produire des spécifications qui sont envoyées à des équipes de développement qui produisent des projets avec une forte granularité et, par conséquence, un lead time qui reste long : “In this model, employees feel little control over the products they build and the customer outcomes they create, and little connection to the organizations they work for ».

  3. L’approche DevOps est le socle commun des entreprises qui excellent dans le développement et déploiement de logiciel. DevOps a émergé comme une pratique commune à un petit nombre d’organisations qui avaient le même problème de produire de façon scalable et répétable des systèmes distribués sûrs, résilients, et capables d’évoluer à une fréquence rapide. DevOps a conduit à formaliser les processus de construction, d’intégration et de déploiements continus (CICD : Continuous Integration and Continuous Delivery ) : « Continuous delivery is a set of capabilities that enable us to get changes of all kinds—features, configuration changes, bug fixes, experiments—into production or into the hands of users safely, quickly, and sustainably”. Ces objectifs sont des objectifs “systémiques” – qui caractérise le système complet de la “software factory” – et ils ne peuvent être atteint qu’au moyen d’une collaboration étroite entre tous ceux qui sont impliqués dans les différentes phases du processus de construction/livraison du logiciel (d’où le nom de DevOps). Ces pratiques CICD permettent d’atteindre la régularité « industrielle » que l’on attend d’une « usine » logicielle : « CD helps us achieve one of the twelve principles of the Agile Manifesto: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”. Un des indicateurs les plus efficaces pour évaluer la distance qu’il reste avec cet état de “sustainable development” est ce que les auteurs qualifient de “peur du déploiement”: “The fear and anxiety that engineers and technical staff feel when they push code into production can tell us a lot about a team’s software delivery performance. We call this deployment pain, and it is important to measure because it highlights the friction”. Pour développer la capacité de CICD il faut travailler sans relâche sur la suppression de cette “douleur du déploiement”. Cela passe bien sûr, dans une approche résolument lean, sur l’accélération du rythme des déploiements. On retrouve par ailleurs les bonnes recettes de la construction de systèmes résilients qui facilitent le travail de mise en œuvre et de pilotage :  « In order to reduce deployment pain, we should: Build systems that are designed to be deployed easily into multiple environments, can detect and tolerate failures in their environments, and can have various components of the system updated independently; Ensure that the state of production systems can be reproduced (with the exception of production data) in an automated fashion from information in version control; Build intelligence into the application and the platform so that the deployment process can be as simple as possible.”  Pas de surprise ici, je vous renvoie à mon cours sur « QoS et performance des systèmes distribués » – un peu ancien, mais les fondamentaux sont immuables – sur le sujet, en deux parties

  4. Les auteurs proposent de mesurer la performance des « software factories » avec un petit nombre de métriques : le « lead time » de livraison, la fréquence de déploiement, le temps nécessaire pour rétablir le service (MTTR) et le taux d’échec des procédures de changement. Dans l’esprit de la double flèche “from customer to code” et “from code to customer” ils décomposent le lead time en deux parties : le temps de concevoir et valider un produit ou une fonctionalité, puis le temps pour le mettre entre les mains des clients. Pour réduire la fréquence de livraison, il faut bien naturellement travailler par « petits lots » : “ Reducing batch size is another central element of the Lean paradigm—indeed, it was one of the keys to the success of the Toyota production system.” Ces quatre métriques sont à contraster avec les 24 pratiques qui ressortent de l’analyse statistique de la performance des 20000 entreprises étudiées. Je vous renvoie au schéma complet qui se trouve ici. Une partie des résultats de l’analyse statistique de la corrélation pratique/performance est tout à fait attendue et sans surprise. Par exemple, l’utilisation efficace des outils de contrôle de versions est fortement corrélée avec la performance. Ces pratiques sont majoritairement inspirées du Lean Software management et de DevOps. Le point fondamental est qu’il s’agit de pratiques, qu’il faut du temps et de la patience pour mettre en œuvre : « Practice patience. Your current way of work took decades to entrench. It’s going to take time to change actions and thought patterns until they become new habits and, eventually, your new culture. Practice practice. You just have to try it: learn, succeed, fail, learn, adjust, repeat. Rhythm and routine, rhythm and routine, rhythm and routine”.

  5. L’analyse proposée des bonnes pratiques des organisations logicielles performantes s’articule autour des concepts du « Lean Manufacturing».  Un des intérêts du livre est la sélection de 24 pratiques qui sont validées par leur corrélation avec la performance des entreprises qui les pratiquent. On retrouve des pratiques tirées du monde agile, du « Lean Software » à la Mary & Tom Poppiendieck, du « Lean Product Development » et de DevOps. Les auteurs expliquent les concepts communs tirés du Toyota Way et leur interprétation scientifique dans un contexte de pilotage de files d’attentes. Par exemple : « Once utilization gets above a certain level, there is no spare capacity (or “slack”) to absorb unplanned work, changes to the plan, or improvement work. This results in longer lead times to complete work.” Pour les auteurs, les éléments principaux du lean qui s’appliquent au logiciel sont : la limite du “work in progress”, le management visuel, le feedback de la mise en œuvre (production), et les processus allégés d’approbation du changement. L’exemple d’ING qui est développé dans la deuxième partie du livre permet d’apprécier des exemples de mise en oeuvre de ces pratiques de management visuel : “ Four distinct zones are visualized: strategic improvement, performance monitoring, portfolio roadmap, and leadership actions, each with current information about targets, gaps, progress, and problems ». Les techniques de visualisation et pilotage de résolution de problèmes sont variées et ont évolué au cours du temps: « Over the years, they have experimented with different problem-solving methods, including A3, Kata, Lean startup, and others, and finally settled on a blend of elements that they found helpful, creating their own approach. In our walk today, we have seen evidence of multiple problem-solving initiatives in flight and visualized on the walls.”

  6. Dans une perspective Lean, les tests et la sécurité doivent être introduits le plus tôt possible dans le processus de développement. Les résultats confortent le fait que dans CICD, il y a « continuous testing », à chaque étape du cycle de production déploiement : « Testers serve an essential role in the software delivery lifecycle, performing manual testing such as exploratory, usability, and acceptance testing, and helping to create and evolve suites of automated tests by working alongside developers”. Le panel d’entreprise étudié comprenait différentes formes de production des jeux de test automatisés, intégrées à la chaîne de développement ou séparées, et l’analyse montre que les deux formes sont possibles et également efficaces, du moment que l’exécution des tests automatiques est systématique et fréquente. Les auteurs ont également étudié la façon dont les entreprises intègrent, testent et valident les exigences de cybersécurité. Leur recommandation est très claire, il faut intégrer la sécurité dès le début dans l’ensemble du cycle de développement : « High-performing teams were more likely to incorporate information security into the delivery process. Their infosec personnel provided feedback at every step of the software delivery lifecycle, from design through demos to helping with test automation”. Les développeurs, par conséquent, sont des acteurs actifs de la cybersécurité du système d’information, et doivent connaitre les différentes recommandations de l’état de l’art, comme par exemple celles de l’OWASP.  C’est ce que les auteurs appellent le « shiftleft » de la sécurité : « We found that when teams “shift left” on information security— that is, when they build it into the software delivery process instead of making it a separate phase that happens downstream of the development process—this positively impacts their ability to practice continuous delivery. This, in turn, positively impacts delivery performance.”
  7. Toujours dans cette perspective Lean, les organisations efficaces sont en premier lieu des organisations apprenantes. Comme cela a été dit plus haut, la performance numérique passe en premier lieu par le capital humain : « People are at the heart of every technology transformation. With market pressures to deliver technology and solutions ever faster, the importance of hiring, retaining, and engaging our workforce is greater than ever”.  Le rythme d’évolution exponentiel des technologies oblige à adresser l’apprentissage permanent des employés (c’est une question de flux, un rythme aussi rapide ne peut pas se traiter simplement par attrition et embauche). C’est ce qui conduit irrémédiablement au principe de l’organisation apprenante, dans un monde numérique ou apprendre signifie faire : « Our analysis is clear: in today’s fast-moving and competitive world, the best thing you can do for your products, your company, and your people is institute a culture of experimentation and learning, and invest in the technical and management capabilities that enable it”. Cet objectif de progrès continu se traduit dans l’organisation mais surtout dans la culture et la pratique quotidienne, avec un fort emprunt aux approches Lean et à l’héritage de Deming : “This practice of rapid exchange of learning, enabling the frontline teams to learn about strategic priorities and the leaders to learn about customer experience from frontline team customer interaction, is a form of strategy deployment (Lean practitioners use the term Hoshin Kanri). It creates, at all levels, a continuous, rapid feedback cycle of learning, testing, validating, and adjusting, also known as PDCA”.  L’exemple détaillé de l’organisation d’ING montre également des emprunt au modèle « distributed agile » de Spotify : « There are also chapters, comprised of members of the same discipline (for example, the Data Analytics Chapter), who are matrixed across squads and bring specialized knowledge to promote learning and advancement among squad members".

  8.  Performance et résilience riment dans un monde complexe. Les auteurs font plusieurs fois référence au mouvement « Rugged software movement ». Si ce mouvement n’a pas connu un grand succès, son manifeste reste un document très pertinent et utile. Comme cela a été dit plus tôt, la résilience fait partie des objectifs initiaux du mouvement DevOps. Comme les systemes numériques modernes sont complexes – fréquence et richesse du changement et complexité des interactions avec les utilisateurs - , les pannes sont également complexes et leur traitement relève de l’émergence . Prévenir et traiter les erreurs est donc une pratique qui nécessite de l’entrainement. On trouve donc sans surprise des recommandations pour faire des exercices fréquents de validation de plan de « disaster recovery »: « Use Disaster Recovery Testing Exercises to Build Relationships … Creating a training budget and advocating for it internally. Emphasize how much the organization values a climate of learning by putting resources behind formal education opportunities” - ma reference sur ce sujet est le livre de Klaus Schmidt, « High Availability and Distaster Recovery ».  La resilience s’obtient également en favorisant l’automatisation et le monitoring proactif permanent. Ces recommandations sont dans la ligne directe du livre de référence de Google « … » dont je ferai une synthèse dans un prochain billet. « Make monitoring a priority. Refine your infrastructure and application monitoring system, and make sure you’re collecting information on the right services and putting that information to good use …  Practices like proactive monitoring and test and deployment automation all automate menial tasks and require people to make decisions based on a feedback loop. Instead of managing tasks, people get to make decisions, employing their skills, experience, and judgment”.

  9. La culture des organisations logicielle performantes est fondée sur l’autonomie et l’intégrité. On retrouve ici le message principal de “Good to Great” – la première marque des organisations performantes est la culture d’intégrité, le fait de dire « les choses telles qu’elles sont » et de faire circuler les mauvaises nouvelles le plus rapidement possible. Le premier adversaire de l’intégrité c’est la peur : “As Deming said, ’whenever there is fear, you get the wrong numbers’. Before you are ready to deploy a scientific approach to improving performance, you must first understand and develop your culture”. Comme la culture se construit au moyen de l’exemplarité, le leadership du management est essentiel dans une usine logicielle. Il faut, selon l’expression de Deming, « chérir ses erreurs » et accepter les difficultés telles qu’elles se présentent. Il faut aussi savoir prendre le recul pour permettre aux squads de travailler dans un contexte de charge « lean » qui permettent cet apprentissage et amélioration continue :  « A courageous and supportive leader is crucial to help teams “slow down to speed up,” providing them with the permission and safety to put quality first (fit for use and purpose) which, in the long run, improves speed, consistency, and capacity while reducing cost, delays, and rework”. La deuxième charactéristique des organisations performantes dans un environnement complexe – on retrouve ici une des idées fondamentales développées dans ce blog et le pilier de l’Entreprise 3.0 – l’autonomie laissée aux équipes. L’autonomie des équipes est une conditions essentielle de l’agilité et de la performance: «  Our analysis showed that the ability of teams to try out new ideas and create and update specifications during the development process, without requiring the approval of people outside the team, is an important factor in predicting organizational performance as measured in terms of profitability, productivity, and market share”.  Les auteurs constatent que les entreprises dans lesquelles les équipes ont des processus d’approbation/validation très légers voire inexistants sont celles qui ont également les meilleures performances en termes de déploiement logiciel. Cette autonomie s’exprime de multiples façons, et particulier et cela mérite d’être souligné, dans le choix des outils « Our analysis shows that tool choice is an important piece of technical work. When teams can decide which tools they use, it contributes to software delivery performance and, in turn, to organizational performance”. L’autonomie ne signifie pas l’autarcie, les équipes doivent partager et apprendre les unes des autres (d’où le modèle Spotify avec ses guildes et ses chapitres). Les ressources logicielles partagées facilitent cette organisation. Par exemple, le développement sur un « tronc commun » est un facteur d’efficacité : « Our research also found that developing off trunk/master rather than on long-lived feature branches was correlated with higher delivery performance”. Les mouvements latéraux sont fortement encouragés: « Encouraging practitioners to move between departments. An admin or engineer may find as they build their skills that they’re interested in a role in a different department. This sort of lateral move can be incredibly valuable to both teams”.

  10. Du point de vue de l’architecture, il faut rechercher la modularité qui permet de donner l’autonomie requise aux équipes et la flexibilité nécessaire aux systèmes. Le livre brièvement d’architecture, en faisant surtout – sans surprise – un plaidoyer pour la modularité : « Make large-scale changes to the design of their system without depending on other teams to make changes in their systems or creating significant work for other teams” La partie la plus intéressante sur l’architecture est la référence à la Loi de Conway  qui stipule que l’architecture des systèmes d’information est liée aux flux interne d’information et se calque par conséquence sur l’organisation de l’organisation. Il ne faut pas ignorer la Loi de Conway : soit on joue avec en modifiant fréquemment l’organisation, soit on lutte contre en favorisant les rotations fréquentes des collaborateurs. Cette dépendance entre communication et architecture est également une difficulté lorsqu’on pratique l’ « agile distribué » : « Another challenge the coaches are experimenting with is dispersed teams. With recent restructuring, some squads now have members from more than one country, so the coaching team is experimenting with, and measuring, ways to maintain the same high level of collaboration and learning among cross-border squads (it’s very hard to virtually share two pizzas)”. La combinaison du management visuel partagé et des rites communs permet de palier une partie de ces difficultés.  

3. Lean Startup, DevOps and effectuation


Le schéma de la figure suivante est tiré d’une présentation à Xebicon en 2015 et représente la double nécessité pour les entreprises de maîtriser à la fois les méthodes d’innovation centrée sur le client du Lean Startup et les capacités de déploiement de DevOps. Il faut à la fois savoir concevoir, exécuter et déployer ses produits dans un cycle permanent et rapide. Les auteurs de « Accelerate » arrivent à la même conclusion:  « In the following year, we flipped the model and confirmed that software delivery performance drives Lean product management practices. Improving your software delivery capability enables working in small batches and performing user research along the way, leading to better products




Depuis 2015, j’ai évolué dans cette analyse et il me semble maintenant important d’introduire dans ce schéma l’influence de l’effectuation. L’effectuation est une « boucle de retour » du bas (développement) vers le haut (conception). Autrement dit, il faut tenir compte de ce que l’on sait faire lorsqu’on imagine le produit de demain. C’est la conséquence naturelle des idées de Philippe Silberzahn développées dans le précédent billet. Il y a une double boucle de retour qui doit influencer le processus d’innovation : la boucle de retour client – ce que le client pense de ce qui lui est proposé – et la boucle de retour de sa propre réalité de ses capacités. L’effectuation traduit précisément que la stratégie numérique est ancrée dans les capacités numériques. Il ne sert à rien – même en écoutant religieusement ses clients selon un processus LeanStartup exemplaire – de concevoir des produits pour lesquels on ne dispose pas des compétences numériques nécessaires.

Un corollaire de cette observation est que la l’apprentissage continu des compétences qui définit le « terrain de jeu de l’effectuation » a des conséquences importantes sur la mise en place de la « transformation numérique » souhaitée par les entreprises :
  •   L’  « Innovation as a Service” est principalement un mythe. La pratique de l’apprentissage continue a un coût et représente un risque. Si ce n’était pas le cas, le modèle de « marketplace » des expertises aurait déjà triomphé. Cela ne signifie pas qu’innover se fait de façon autonome et sans appel à l’extérieur ! Cela signifie que le lieu de création de valeur est le lieu de l’apprentissage. C’est ce qui explique la guerre des talents, par exemple dans le domaine du Machine Learning.
  •  Pour reprendre un aphorisme de « Skin in the game » de Nassim Taleb, « no pain, no gain » : les entreprises ne peuvent pas externaliser leur apprentissage. Il y a ici une extension de la « théorie de l’entreprise » de Coase : l’entreprise permet d’internaliser les coûts de de l’apprentissage (en addition aux coûts de transaction).



La combinaison des deux principes fondamentaux de l’effectuation et le modèle distribué de l’organisation face à la complexité implique qu’il existe une forme inévitable de redondance : l’apprentissage se fait à plusieurs endroits. On ne peut pas éviter que dans le « learn by doing », il y ait une certaine répétition des « doing ». Comme les équipes sont différentes, ce n’est pas le même « learning ». Je suis frappé de voir le nombre de directeurs de l’innovation dont la première tâche dans leur poste est de « rationaliser les POC », c’est-à-dire supprimer les redondances. Ce qui est dommage, c’est de faire la même chose à plusieurs endroits dans le savoir et sans profiter de l’opportunité de créer une communauté de savoir, de pratique et de partage. En revanche, dans une Entreprise 3.0 articulée autour d’une finalité unique, fonctionnant en un réseau d’équipe autonomes dans un mode d’apprentissage permanent, il est naturel et logique que ces équipes sélectionnent des terrains d’apprentissage semblables pour entretenir et développer leurs compétences techniques.



samedi, mars 31, 2018

L'entreprise face à la complexité : de la prévision au jeu



1. Introduction


Le billet de ce jour est la suite du précédent sur le sujet de la prévision et l’utilisation des méthodes quantitatives dans un monde incertain. C’est un sujet qui me tient doublement à cœur et dont je traite souvent dans ce blog, soit sous l’angle du nécessaire changement dans les méthodes de management et de pilotage des entreprises – par exemple sous le vocable de l’Entreprise 3.0 – et sous l’angle des méthodes d’aide à la décision dans un monde incertain et complexe – c’est le thème de l’approche GTES (Game-Theoretical Evolutionary Simulation).

Ce billet s’inscrit également dans une ligne de pensée inspirée par Nassim Taleb, que je cite très souvent, presque autant que François Jullien. Tout ce qui va suivre est évidemment fortement inspiré de la trilogie « Fooled by Randomness », « The Black Swan » et « Antifragile ». La figure ci-dessous représente le dilemme qui formait la base de mon intervention il y a quelques mois lors des 50 ans d’INRIA, et qui correspond à la question suivante : une fois que l’on a compris en écoutant Nassim Taleb qu’il existe deux mondes – le monde linéaire et prévisible et le monde complexe et non linéaire, imprévisible – que se passe-t-il à la frontière ? Comment aborder des situations – les plus communes – qui sont un mélange de caractéristiques structurées/linéaires/stables et complexes/incertaines ?



J’ai lu avec un très grand plaisir le livre de Philippe Silberzahn, « Bienvenue en incertitude », qui est comme moi un lecteur et un admirateur de Nassim Taleb.  Ce livre détaille toutes les conséquences de la pensée de Nassim Taleb pour le pilotage et management des entreprises. On pourrait le décrire comme un manifeste « contre le prévision » et pour une nouvelle façon de vivre avec l’incertitude. Il se trouve que je lisais en parallèle le livre de Josh Sullivan et Angela Zutavern, « The Mathematical Corporation – Where Machine Intelligence and Human Ingenuity Achieve the Impossible», qui est à l’opposé un manifeste pour l’utilisation de nouveaux outils et nouvelles méthodes quantitatives face à la complexité et l’incertitude. Là où le premier livre se situe sur la partie droite du dessin, à côté du cygne noir, le second se situe sur la partie gauche. Cette double lecture illustre donc parfaitement bien le dilemme : « les méthodes de prévision ont-elles leur place dans un monde incertain ? »

Le plan de ce billet est on-ne-peut-plus canonique : thèse / antithèse / synthèse. La thèse sera énoncée par le livre « Bienvenue en incertitude ». Dans un monde incertain et complexe, il faut « changer de logiciel » et abandonner la prévision et le plan stratégique au profit de l’effectuation et de la construction d’un potentiel de situation. On reconnait ici le clin d’œil à mes héros François Jullien et Nassim Taleb. L’antithèse sera fournie par « The Mathematical Corporation », avec de multiples exemples qui montrent l’avantage compétitif que tirent certaines entreprises de l’utilisation massive de leurs données couplées avec des algorithmes d’apprentissage et d’intelligence artificielle. On pourrait bien sur convoquer ici les succès des Facebook, Google ou Critéo, ou encore faire référence au rapport de l’Académie des technologies sur le Big Data. En clin d’œil à Nassim Taleb, j’ai du « skin in the game » de ce côté de l’argument, étant donné ce à quoi je passe mes journées. Je conclurai donc avec une brève synthèse qui va tenter de dénouer cette apparente contradiction. Sans surprise, je rejoindrai les conclusions du billet précédent.

2. La fin de la prévision ?


J’ai eu le plaisir de discuter et travailler avec Philippe Silberzahn plusieurs fois, lorsque je travaillais pour AXA. Il m’a beaucoup appris sur l’effectuation, un sujet sur lequel il a écrit
un livre que j’ai commenté dans ce blog. Son livre « Bienvenue en incertitude » est un livre passionnant, remarquablement écrit et fort érudit. Selon mon habitude, je ne relève ici qu’une dizaine d’idées clés mais je ne suis aucunement exhaustif.

  1. Nous sommes entrés dans une nouvelle ère, celle où la prévision structurée à long terme devient impossible. Ce livre contient de nombreux exemples, souvent réjouissants, de prévision erronées, à la fois dans le résultat mais surtout dans la fausse confiance des auteurs de la prévision. En particulier, les exemples tirés de l’industrie pétrolière sont particulièrement édifiants « Autrement dit, le CFA a une influence considérable sur la façon dont la finance mondiale fonctionne. Et pourtant, dans l’un de ses manuels de formation, on peut lire : « L’industrie pétrolière se caractérise par un haut niveau de prévisibilité ». Philippe Silberzahn arrive rapidement à nous convaincre que « Les erreurs sont massives, c’est l’échelle-même de ces prédictions qui est fausse à un point qu’elles en deviennent absurdes ». Bien sûr, certains domaines se prêtent à prévision « Il existe naturellement des domaines où la prédiction sur base d’apprentissage fonctionne. C’est par exemple le cas en médecine avec les crises cardiaques », mais de façon générale, « Le facteur nouveauté introduit donc une incertitude fondamentale dans l’environnement qui rend celui-ci complétement imprédictible ».
  2. Une des causes racines de cette impossibilité à prévoir est la complexité croissante du monde, en particulier de ce que nous cherchons à prévoir. On trouve dans ce livre un rappel de la différence fondamentale entre complexe et compliqué, et les raisons qui font que le monde évolue vers une complexité croissante (je vous renvoie, modestement ou non, à mon propre livre). La nature complexe des systèmes qui nous entourent les rendent hors d’atteinte de nos méthodes de prévisions : « Il en va de même de la plupart des systèmes humains au sein desquels nous évoluons. Comme l’observe Nassim Taleb, le changement profond de nos environnements se fait par sauts et bonds, et non par modification progressive ». Malheureusement, nous avons tous hérité d’un logiciel d’analyse Cartésien ou « grec au sens de Jullien » qui nous pousse à utiliser la décomposition réductionniste : « Mais le mot analyse n’est pas neutre. Il vient du grec analusis qui signifie décomposition d’une chose en ses éléments, d’un tout en ses parties. L’analyse procède d’une approche réductionniste : elle vise à comprendre un objet en le décomposant en ses constituants». Pour plus de détail sur cette idée essentielle, je vous renvoie à ce billet sur quelques caractéristiques des systèmes complexes, dont leur non prédictibilité, avec la référence naturelle à Nassim Taleb.

  3. Le fait de s’appuyer sur les données n’est pas un remède à l’impossibilité de prévoir, d’autant plus que nous sommes toujours sous l’emprise du « narrative fallacy ». Non seulement les données du passé ne permettent pas de prévoir le futur dans un système complexe – depuis le célèbre « butterfly effect » des systèmes chaotiques jusqu’aux amplifications non-linéaires des boucles de renforcement, mais les données du passé nous apparaissent souvent comme différente de la réalité qu’elle décrivent ! C’est le point génial du premier libre de Taleb, « Fooled by randomness », nous lisons les données en les filtrant par les histoires que nous nous racontons. Comme l’écrit Philippe Silberzahn, « Les faits qui remettent en question des croyances de base – et de ce fait menacent la vie et l’estime de soi des gens – ne sont tout simplement pas absorbés ». De plus, comme il le souligne également, « Ce qui est important n’est pas forcément quantifiable » (contrairement à la fausse idée que ce qui ce ne se mesure pas n’existe pas – le 21e siècle n’est plus le siècle du positivisme).

  4. Il faut apprendre à vivre sans l’outil à tout faire de la prévision, repenser sa vision du pilotage et du management. Il est temps de revisite le célèbre « gouverner, c’est prévoir » : « Les théories dominantes de la décision reposent sur la prédiction en vertu du principe « il faut prévoir pour savoir, et il faut savoir pour agir » pour le transformer en « gouverner, c’est anticiper » : « Ne pas prévoir ne veut pas dire ne pas anticiper, il faut passer de la prévision au jeu, pour construire ses capacités de réactions à des événements imprévisibles ». Ce livre contient de nombreux exemples qui démontre que si la prévision est impossible, l’anticipation est nécessaire, et il convient de continuer à scruter le futur, d’une façon différente. Comme le remarquait Nassim Taleb, on ne peut pas prévoir l’occurrence des cygnes noirs, mais on peut évaluer les impacts possibles. C’est tout le principe des plans de fiabilisation et de « disaster recovery ». Philippe Silberzahn cite un exemple édifiant d’un petit incident de production qui se transforme en désastre pour une entreprise :  « Quand un simple câble ruine vingt ans de stratégie, c’est que le câble est stratégique, ou aurait dû l’être. Ce câble n’ajoute peut-être pas de valeur, pour parler comme les consultants, mais il peut en détruire énormément s’il est mal géré. ». Anticiper sans prévoir est un changement radical de posture managériale puisque tout nos processus de gouvernance hérite de la tradition de la planification :  « C’est sur elle que reposent les processus les plus importants : le processus budgétaire, celui d’allocation de ressources, les plans commerciaux, les plans d’affaire, le développement des produits. Le paradigme prédictif imprègne de manière intime la totalité du fonctionnement d’une organisation moderne jusqu’à sa culture. ». Cela conduit l’auteur à écrire que le besoin de prévision est une idéologie et à citer François Dupuy : « Quelle que soit l’incertitude du monde, on demande toujours à un dirigeant d’avoir une ‘stratégie claire’, non pas parce qu’elle est juste, mais parce qu’elle sécurise tous ceux que l’imprévisibilité de l’avenir angoisse ».


  5. Il faut développer son « potentiel de situation » plutôt que de continuer à construire des plans stratégiques. Pour reprendre les termes de François Jullien, il s’agit de perdre une part « grecque » de notre logiciel et d’acquérir des éléments de sagesse « chinoise ». L’auteur nous propose d’investir en préparation et pas en prédiction. Cette anticipation est essentielle car la réactivité ne suffit pas. La réactivité permet de valoriser le potentiel de situation, dans un temps court, mais la construction du potentiel relève du temps long. Autrement dit, l’agilité chère aux organisations modernes ne suffit pas : « Bien sûr l’agilité est utile dans un environnement qui change ; la plupart des grandes organisations font preuve de lourdeur pachydermique : la moindre initiative nécessite 200 slides Powerpoint et 27 réunions, mais elle a des limites ». La notion de préparation passe également par les jeux (sérieux) et les exercices, mais il faut aller plus loin que de construire des scénarios, il faut pratiquer : « Les scénarios trouvent cependant rapidement leurs limites : ils sont souvent basés sur l’évolution d’une ou deux variables seulement, sans quoi la complexité devient telle que l’ensemble n’est plus gérable ». Notons que c’est précisément ce type de remarque qui fonde l’approche GTES pour explorer un espace beaucoup plus vaste de combinaisons, tout en capturant cette autre remarque essentielle de Philippe Silberzahn : « Le système n’évolue pas seulement de lui-même, mais en fonction de comment les acteurs pensent qu’il va évoluer ».

  6. Philippe Silberzahn propose quatre attitudes face à l’incertitude et met à l’honneur l’effectuation, dans la lignée de son livre précédent. Dans une matrice à quatre cases du plus bel effet, il propose : le plan lorsqu’il est à la fois possible de prédire et contrôler, l’adaptation lorsque la prédiction est difficile mais le contrôle possible, la vision lorsque la prévision est possible mais le contrôle difficile et la transformation lorsque les deux sont difficiles. C’est dans cette quatrième case que s’inscrit l’effectuation : faire avec ce que l’on a pour être un acteur transformant de son futur. Le pragmatisme de l’effectuation s’oppose au contrôle qui voudrait réaliser les conditions de départ d’un plan, d’un projet, d’une innovation. On fait avec ce que l’on a, avec le monde tel qu’il est. La deuxième idée fondamentale de l’effectuation est qu’on construit le futur (modestement, sur un territoire donné) au lieu de le prévoir. Je vous recommande chaleureusement de lire soigneusement ces pages du livre, c’est à la fois très élégant et très profond. Cette analyse permet de comprendre parfaitement la différence entre un projet classique de système d’information et un projet digital. Dans un monde sans prévision, il reste une division profonde entre l’approche adaptative de la transformation et la pure adaptabilité.

  7. Au regard des principes de l’effectuation, ce livre propose un certain nombre de critiques à l’attention de l’approche « Lean Startup ». Philippe Silberzahn est connu pour ses prises de position critiques à l’égard du Lean Startup, par exemple chez GE. Ce livre permet de mieux comprendre ces réticences, à la lumière des la différence entre les rationalités effectuales et causales. L’approche effectuale interroge une démarche UVP qui ne serait que tirée par l’observation et l’analyse des besoins du client. Il convient également de ce demander ce qui est possible, disponible, présent. C’est d’ailleurs pour cela que les auteurs de « The Lean Enterprise » propose le concept de « innovation thesis » : il faut chercher les problèmes dans des domaines où on dispose d’une légitimité (le « unfair advantage » du lean canvas) et il faut également construire son potentiel de situation pour mieux « effectuer ». Suivre une approche Lean Startup de façon « grecque » - en partant d’un UVP optimal construit à partir des besoins et désirs des clients risque de conduire à l’échec et à la frustration. Notons également que cette analyse permet de comprendre pourquoi l’entreprenariat – au sens de l’effectuation -  est « antifragile » - au sens  de Taleb - et pourquoi la Silicon Valley attribue de la valeur aux précédents échecs. L’innovation entreprenariale est un « serious game », les échecs précédents augmentent le potentiel de situation de l’effectuation pour les parties suivantes.

  8. Ce livre est un véritable manuel de vie, à utiliser dans l’entreprise comme dans sa vie personnelle.  L’application de ces principes est un travail personnel, où chacun s’implique nécessairement :  « Les hypothèses sur lesquelles repose le travail d’anticipation ne sont pas désincarnées, elles sont le reflet de l’identité de l’acteur et de son institution qui les produisent. Ces hypothèses ou croyances se forgent au cours de la vie professionnelle, personnelle et institutionnelle au travers des diverses expériences vécues.»  A plusieurs reprises, l’auteur nous invite à développer une modestie « épistémique » et à accepter un monde complexe dans lequel tous les problèmes n’ont pas de solutions, et toutes les solutions ne sont pas accessibles à nos raisonnements. Au contraire, il nous suggère de privilégier : « La conversation plutôt que la formalisation, les cas particuliers plutôt que les principes généraux, le contingent plutôt que l’intemporel, l’identité plutôt que les données, le contrôle plutôt que la prédiction, ce sont donc cinq heuristiques ou principes d’action en incertitude pour, non pas seulement s’en protéger mais surtout en tirer parti et s’y complaire. » J’en profite pour conclure avec ma citation préférée d’Emmanuel Kant : « On mesure l'intelligence d'un individu à la quantité d'incertitudes qu'il est capable de supporter."

J’ai quelques réserves sur certains points précis – par exemple, je reste un ardent défenseur de l’approche « Lean Startup », mais je n’ai pas besoin de les couvrir ici puisque je vais le faire de façon implicite dans la partie suivante. Il est clair pour moi que l’ « impossibilité de la prévision » est soulignée de façon quelque peu caricaturale : c’est une question de complexité, mais aussi d’échelle de temps (la prévision à court-terme est de plus en plus précise) et de mode d’utilisation. La prévision doit être vue dans une boucle, mais c’est précisément le sujet du livre suivant.

3. La renaissance de la prévision ?


Le deuxième livre, « The Mathematical Corporation - Where Machine Intelligence and Human Ingenuity Achieve the Impossible »  est un livre de deux consultants de Booz & Allen, qui décrit comment un certain nombre d’entreprises utilisent les outils modernes de l’apprentissage et de l’Intelligence artificielle pour résoudre des problèmes métiers de façon significativement meilleure que par le passé. C’est un livre complètement diffèrent dans le ton et le style, mais qui est rempli d’exemples et d’observations « from the trenches » très intéressantes. Le pitch du livre est bien illustré par la citation suivante : «Future power is the ability to apply specific leadership techniques in league with machine intelligence technologies to see future possibilities and shape the future ».   Bien sûr, il contient des exagérations propres à ceux qui écrivent sur les choses qu’ils veulent vous vendre – un autre clin d’œil à « Skin in the Game ». Leur vision sur l’avènement du Quantum Computing relève du pur “wishful thinking ». Néanmoins je considère leur livre comme sérieux et important, en particulier parce que les observations et principes pratiques proposés à partir des expériences décrites sont corroborés par mes propres observations et investigations. Voici de façon symétrique une sélection d’une dizaine d’idées qui ont retenu mon attention.


  1. L’accroissement de la complexité est une formidable opportunité pour les entreprises agiles qui se dotent des bonnes capacités d’analyse et de réaction, grâce aux outils mathématiques (de la science des données à l’intelligence artificielle). Je cite les auteurs : « Complexity is a boon, not a burden. We can’t stress this point more strongly. Complexity in the way systems work is like the complexity inherent in finding gold-bearing mineral deposits—it’s only a barrier to extracting value if you don’t know how to mine for results. Otherwise, it’s treasure.”  Différentes techniques sont illustrées au cours du livre, avec différents exemples qui relèvent de la recherche opérationnelle, mais c’est l’apprentissage automatique qui tient, sans surprise, la vedette. L’apprentissage, sous ses formes profondes (réseau de neurones) ou plus classiques (méthodes dites « statistiques ») est utilisé de nombreuses façons : « Machine learning is not just a learning tool. It’s also a tool for approximation, prediction, and creating original understanding that enhances leaders’ higher-level capabilities to imagine the future and to thrive in it.” La notion de prévision n’est plus l’approche classique linéaire par étape, mais une approche iterative placée dans une boucle de contrôle (je renvoie le lecteur au rapport de l’Académie des technologie sur le Big Data, dont c’est l’idée centrale) : « This always the same idea: forget the insights - optimize future decisions based on cycle ». Du point de vue du chercheur opérationnel, la prévision passe du statut d’heuristique glouton à l’appentissage par renforcement.

  2. On peut faire des choses extraordinaires aujourd’hui avec suffisamment de données et les outils avancés d’apprentissage automatique. Cette affirmation n’a pas d’intérêt en soi, ce sont les exemples qui sont intéressants et qui font qu’il faut lire ce livre. Parmi ces exemples, j’ai relevé d’abord une utilisation de l’apprentissage par pour évaluer un flux (ejection fraction) à partir d’images vidéo : « Within three months, many of the teams had devised algorithms that enabled computers to read MRI cross sections as quickly as they are taken. The machines learned to find the specific image that shows the heart in its totally relaxed state (full of blood) and another in its totally contracted state (during pumping). They then compared the two and calculated the ejection fraction.” Ce qui est intéressant ici, c’est que si les données ont été préparées et annotées par des experts du sujet, l’équipe qui a produit le meilleur algorithme ne connaissait rien à la cardiologie : « The remarkable aspect about the winning team was that neither teammate knew anything about cardiology before the competition. Never before have organizations had at their disposal the global pool of talent to tackle the most complex problems of our time—including problems in fields of knowledge that data scientists know nothing about.” Un deuxième exemple intéressant est celui de la chaîne hôtelière IHG (Intercontinental) qui a utilisé des très gros volumes de données pour complètement revisiter sa segmentation client en produisant des dizaines de milliers de profils: “We concluded that advanced computation could identify more hidden relationships between customer attributes and likelihood-to-respond than is possible with… traditional modeling methods”. Le dernier exemple qui m’a le plus frappé est celui de Merck puisqu’il s’applique à l’optimisation de processus de production industriels qui m’intéresse professionnellement. « The manufacturing team used data science to conduct a large-scale analysis to integrate and analyze 5 terabytes of data using 15 billion calculations and more than 5.5 million batch-to-batch comparisons. They then created a “heat map” showing data clusters associated with high and low yields. Experts could look at the heat map, recommend changes, rework predictive models, and then run more analyses. … Merck uses a data lake for the petabytes of data its manufacturing plants generate. The data come in all formats, combining both in-house and outside data sets that extend backward up the production chain all the way to suppliers of raw materials. … In December 2016, it christened its first plant-wide analytics system in Singapore. A single dashboard will display real-time data flowing in from every part of the plant—manufacturing, tablet production, packaging, quality, warehousing, shipping, and so on.” Du point de vue de la CIO, la principale différence avec les outils précédents est le fait d’être passée d’une approche réactive à proactive : « We want to look at the data now and not wait until we have a problem ».

  3.  La première étape d’une stratégie d’entreprise qui embrasse la complexité est de collecter massivement des données. Par exemple, Ford a choisi d’équiper un ensemble de véhicules d’un très grand nombre de capteurs, puis de collecter de façon massive des données d’usage pendant une longue période de temps pour chercher ensuite, par data mining, à apprendre « the secrets of all factors having to do with transportation … patterns that most customers, and competitors, couldn’t see ». Cette stratégie de collecte de données doit être responsable et socialement acceptable : « The leaders of mathematical corporations have to get ahead of the curve of public opinion to avoid ethical questions that trigger an outcry from angry people, politicians, or both”. Il s’agit d’une approche pragmatique, qui est en premier lieu centrée sur le client dans le but de construire l’acceptabilité : “Because so many data today are personal—names, credit card numbers, locations, health records—you can’t avoid tough choices about how to collect and use people’s information. These choices are often not about what’s legal but about what’s “right” and “wrong.”  Le livre contient des illustrations sur des cas concrets et des informations pratiques très intéressantes. Par exemple, on apprend que 63% de la population US est identifiable de façon unique à partir du sexe, du code postal et de la date de naissance. Les témoignages des principaux acteurs des exemples d’applications donne la matière de ce guide pratique de la collecte de donnée. Par exemple, le CIO de Meck, Michele D’Alessandro, explique :  « for technology people, the idea of pulling in raw data, without formatting or organizing it in traditional ways, has been a leap. Most of her people are accustomed to making sense of data after sorting it into a well-defined taxonomy. Using raw and unstructured data for discovery requires both a new mind-set and skill set.”

  4. Il faut devenir « data-driven » précisément pour éviter la « narrative fallacy » et surmonter nos différents biais cognitifs qui s’expriment de plus en plus au fur et à mesure que la complexité augmente. Nous ne sommes pas équipés pour comprendre la richesse des interactions d’un monde complexe ni pour appréhender des très larges volumes de données. Les auteurs prônent une collaboration entre l’ingéniosité et intuition humaine et les capacités analytiques de la machine. Cette collaboration conduit à réinventer son métier et ses processus : « Kirk Borne says the detail you capitalize on in the mathematical corporation amounts to a new way of doing business. “It’s the purist form of evidence-based decision making, or data-driven decision making,” he says. The evidence comes from genuine analyses of the complexity of reality.”Tout au long du livre, le mot clé est celui d’itération. Il y a un co-développement entre l’intuition, la compréhension du problème et les méthodes analytiques. L’exemple de la FAA qui a choisi d’analyser de façon globale une volume massif de données de vols est illustratif : « At the FAA, the team applied its computing horsepower to a data sample of 52 million flights over five years. The sample included 5.25 million rows of data. The computations were even more complicated than anticipated because the data were not clean; the Bayesian belief network was needed because it can estimate missing values amid all that complexity”. Je cite cet exemple car j’entends trop souvent dire qu’on ne peut utiliser l’apprentissage ou l’intelligence artificielle que sur des données nettoyées et exacte. Ce n’est pas le cas, on sait depuis longtemps appliquer des méthodes d’apprentissage sur des données bruitées, mais il faut en avoir conscience ! ce qui pose problèmes ce sont les données fausses alors qu’on croit qu’elles sont justes.

  5. La boite à outils des techniques d’apprentissage et d’intelligence artificielle est large, il faut savoir les hybrider pour produire des solutions propres à chaque défi. On retrouve ici un des thèmes du nouveau rapport de l’Académie des technologies sur l’Intelligence artificielle. Cette boite à outils est loin d’être suffisante pour que les algorithmes deviennent autonomes, ce livre n’est pas naïf sur les possibilités de l’IA et de l’apprentissage aujourd’hui : « This is not to suggest that you will give over the job of leadership to a machine. Quite the opposite. Machines are still a long way from being that good. The mathematical corporation provides new and exciting ways for people to employ unique human qualities at a higher level.” Le livre cite l’exemple d’utilisation d’apprentissage a Berkeley pour découvrir des propriétés des assemblages cristallins pour obtenir des nouveaux matériaux : l’utilisation de l’ordinateur a accéléré de façon spectaculaire le travail de laboratoire grâce à la simulation et l’exploration numérique, mais le travail de compréhension sur la physique théorique est entièrement le fait des humains. Les nouvelles techniques de l’entreprise numérique lui servent d’amplificateur et de correcteur d’intuition : “The machine works better than the gut. Intuition has served leaders well (and still does) principally because the human mind absorbs and understands more detail and substance than we consciously know”. Le nouveau monde des données massives et des algorithmes intelligents est un monde passionnant, dans lequel la curiosité est une vertu cardinale : «  Curiosity. That’s the X factor. Inquisitiveness propels you to arrive at the best question—virtually never the one you started with—and remains core to finding the impossible strategy. It’s what spurs you to shatter thinking constraints, trust new cognitive tasks to the machine, take advantage of new technologies, test new ideas in a tireless stream of experiments, and collaborate with computers ».

  6. Le développement de ces techniques, des méthodes d’analyse, des capacités d’appréhension et de compréhension des environnement complexe prend du temps. Il s’agit d’un processus de développement itératif, lent et émergent : « Only in legend do you strike the mother lode immediately. The right questions and answers bubble up through successive cycles of questioning and experimenting, even if you collect gold nuggets along the way. The journey is all about arriving at a single question that produces the “aha” that completely changes your strategy”. Pour explorer l’espace des solutions algorithmiques, les auteurs recommandent de faire appel à la communauté des data scientists, par exemple avec l’organisation de concours sous Kaggle : « If the problem is tightly framed, you can even work with an organization like Kaggle, the start-up that sponsors competitions to solve data science problems. If you work with Kaggle, you team up with a network of more than a half million data scientists.L’opposition avec le livre de Philippe Silberzahn n’est pas aussi évidente qu’on pourrait le croire. Les auteurs ne défendent pas une vision classique de la prévision : « One hurdle is that people have long been taught that forecasting, especially related to human behavior, is a strength of human beings. But the power of people to call the future correctly is overrated.”.  La prévision moderne est une boucle systémique auto-correctrice, sur des échelles de temps courte et soumise à une évaluation critique constante. Tout cela prend du temps, il n’y a pas de « silver bullet » : « Although that’s a great aspiration—who doesn’t like the notion of finding treasure on the first day of the hunt?—the riches of machine intelligence normally accumulate through experimentation”. L’exemple de Meck est intéressant car il s’agit d’une transformation profonde du métier : « At Merck, manufacturing CIO D’Alessandro says that bringing together in-house and outside data underpins the company’s new manufacturing work. Whereas each part of a plant once optimized its own operations—supply chain, tablet making, packaging, shipping—data from all those parts are now combined. What’s more, Merck imports data sets on weather, transportation, imports/exports, and manufacturing machines and processes”. Ce point mérite d’être souligné : l’utilisation de l’intelligence artificielle conduit à une remise en cause profonde du métier industriel.

  7. Le temps ne sert pas seulement à développer et à améliorer les outils et les méthodes, il sert également à développer le « jugement » des acteurs humains. Ce point est la conséquence logique de ce qui vient d’être dit : puisqu’il faut conserver un œil humain et critique dans l’application des méthodes numérique, le rôle du management doit forcément évoluer. Comprendre et piloter cette coopération homme-machine devient un rôle fondamental du management : « Judging models, then, becomes an executive-level job. This doesn’t mean knowing how all the technology works. What it does mean is remaining ringside to be sure the organization makes the most of models and avoids pitfalls". On trouve dans le livre un petit aperçu des pièges classiques de l’apprentissage tels que l’overfitting ou les corrélations fortuites : « a common modeling problem is overfitting, shaping the model to fit the complexity of a particular problem so closely that errors in the data distort the output. …. Another failure is mistaking correlation for causation. In data science, the mass of data, adequately “tortured,” reveals correlations of all kinds».


  8. L’utilisation de données et d’outils sophistiqués exige une humilité, encore plus grande que par le passé, dans l’appréhension de situation complexes.  Les outils doivent rester au service de l’intuition humaine, il faut donc éduquer les décideurs pour qu’ils restent maître de leur processus de décision, et qu’ils aient l’humilité adaptée à la complexité de leur environnement. J’ajouterai, à titre de clin d’œil, qu’on peut commencer par lire le livre de Philippe Silberzahn. Cette référence à l’humilité est un trait commun aux deux ouvrages : « If you’re like us, you will realize something else: leading in this era requires a dose of humility. » L’humilité est nécessaire pour éviter (en partie) les erreurs (qui peuvent s’avérer des catastrophes) mais également pour voir les opportunités : « Machine intelligence “won’t help you if… people [don’t] admit when things didn’t work ». Je termine avec cette très jolie citation : « Scientific leaders do not excel because of how much they know but because of how much they inquire about what they don’t know».

  9.  Le nouveau monde décrit dans ce livre n’est pas celui de demain, c’est celui d’aujourd’hui. La technologie est déjà là, ce qui coince le plus souvent est l’attitude et la culture (le « mindset ») : « what holds back progress is not technology, but thinking”. Pour le dire avec des mots différent, la diffusion des méthodes d’apprentissage et d’intelligence artificielle n’est pas un problème d’offre mais de demande.  Il est clair que ce livre est un livre orienté, un livre de consultants, un livre résolument techno-optimiste, un livre de culture américaine, qui ce peut agacer certains : « The promise of using machine intelligence is that we will overcome our narrow-minded thinking by using rules derived from a fuller understanding of how humans act. In turn, we will be able to predict and shape behavior, whether for profit, competitive gain, protection, or social good.”  Une partie de ces affirmations ne résiste pas à la critique d’un Nassim Taleb ou d’un Philippe Silberzahn, mais les exemples du livre sont riches d’enseignement et le monde s’est emparé avec succès des approches et méthodes qui y sont proposées. Il serait donc naïf et contre-productif de l’ignorer. Je vais conclure ici en empruntant au livre cette citation de David Whyte : “Stop trying to change reality by attempting to eliminate complexity… apprentice yourself to the complex poetry of human endeavor.”

4. De la prévision au jeu

Le titre de ce billet est en fait le titre d’un livre que je voulais écrire il y a trois ans, avant de me lancer dans des aventures différentes. Je voulais montrer qu’il existe une nouvelle famille de méthodes quantitatives qui se rapprochent précisément de ce que préconise Nassim Taleb :
  • Des jeux, pour développer des réflexes de résilience, dans la grande tradition des « war games »,
  • Des simulations, non pas pour prévoir mais pour mieux comprendre (ce qui a donné lieu à l’approche GTES),
  • Des approches de théorie des jeux pour se forcer à prendre en compte les points de vue des différents acteurs – comme le rappelle Philippe Silberzahn, dans la plupart des systèmes complexes, celui qui modélise/analyse est un acteur du système complexe – sa perception modifie ses actions qui modifient le système.

Il y a donc deux façons de comprendre le titre « de la prévision au jeu ». Soit le jeu est vu comme un exercice pratique de développement de réflexes, dans ce cas il s’agit de suivre les traces de Taleb, Jullien et Silberzahn pour développer son potentiel de situation en pratiquant des exercices. Soit le jeu est vu comme un système itératif de « reinforcement learning », ce qui ouvre la porte à une approche de « Mathematical corporation », une approche qui utilise les données, la machine et des algorithmes sophistiqués. L’ambiguité de l’attitude face à la complexité, l’incertitude et l’anticipation est donc implicitement présente dans ce titre. C’est bien sûr volontaire, puisque je suis « en même temps » un partisan des deux approches.
Je peux donc conclure en formulant une réponse approximative à la question posée en introduction :
  1.  Le monde est à la fois complexe et linéaire, prévisible et imprévisible. Une des premières tâche du pilotage stratégique est de reconnaitre cette dualité et de comprendre ce qui se situe où. Il existe un « edge of the chaos », une frontière passionnante, et c’est à la fois un lieu de création de valeur et de prise de risques (ce qui va de pair).
  2. Cette séparation est doublement complexe et forcément fausse. C’est pour cela que l’humilité est la première caractéristique de la pensée stratégique dans un monde complexe. On retrouve d’ailleurs ce point souligné de façon égale dans les deux livres. On ne sait pas ce qu’on ne sait pas – bienvenue en incertitude – et dans un système complexe, certains comportements et caractéristiques échappent à la « connaissance »
  3. La prévision au sens classique est effectivement dangereuse, comme l’explique Philippe Silberzahn, et doit donc être réservée à des domaines précis et maîtrisés (cf. le point précédent). La prévision dans un monde complexe s’inscrit forcément dans un système complexe et itératif qui d’une part valide/invalide/étalonne la valeur ajoutée de cette prévision en permanence et d’autre part forme un cadre de protection pour limiter les conséquences d’une prévision erronée (dont l’occurrence est une certitude).