mardi, octobre 31, 2017

Utiliser les données pour prévoir : jeux, incertitude et apprentissage



1. Introduction


Le billet de ce jour porte sur la prévision et l’usage de « smart data ». Même si ce terme est flou, j’utilise « smart data » ici pour faire une distinction avec « big data » : pas forcément des énormes volumes de données, mais l’utilisation de méta-données et de modèles qui rendent l’usage plus « smart », pour reprendre les propos de Pedro Domingo in the « The Master Algorithm : How the Quest for the Ultimate Learning Machine Will Remake Our World» : « there is no such thing as learning without knowledge ». Opposer « big » et « smart » data est un peu artificiel et relève plus du marketing que de la science, mais il existe de multiples façons de faire de l’analyse de données et la pratique montre une certaine différence dans la façon dont on traite des petabytes de données et des centaines de gigas. Dans le second cas, la richesse de la boite-à -outils des algorithmes est bien plus grande.  
         
La prévision est le sujet chaud du moment, c’est en fait plus de la moitié des “use cases” de « l’intelligence artificielle » dans les entreprises, l’autre moitié étant la reconnaissance de situations et de motifs. Pour vous en convaincre, vous pouvez regarder les « use cases » de prediction.io, une startup qui proposé précisément des méthodes d’« intelligence artificielle » pour permettre de faire des prévisions. Je reviendrai dans un prochain billet sur cet emploi du terme « intelligence artificielle » pour parler des méthodes d’apprentissage, au moment de la sortie du rapport de l’ADT. On retrouve cet usage partout : le pitch de « DAVinci Labs » est : « Artificiel Intelligence solution to create real values for enterprises » ; les « use cases » sont également majoritairement lié à la prévision. Si vous avez plus de temps, vous pouvez lire la centaine de pages du rapport d’Olivier Ezratty « Les applications de l’intelligence artificielle » consacrées aux applications (à partir de la page 180), pour constater que la moitié des applications sont bien liées à la prévision. On peut même constater qu’une partie de l’autre moitié, les applications de diagnostics par reconnaissance de situation, sont une autre forme de prévision (la catégorie est liée à un jugement sur le futur).

Il n’y a pas de surprise dans le fait que la prévision soit au cœur des systèmes d’aide à la décision, selon l’adage que « gouverner, c’est prévoir ». En revanche, il y une forme de paradoxe dans le développement des méthodes d’ « IA appliquée aux smart data » dans un monde incertain et complexe qualifié de VUCA (Volatility, Uncertainty, Complexity and Ambiguity). La première partie conduit à développer et promouvoir la prévision, tandis que les caractéristiques de complexité du monde VUCA du 21e siècle conduisent à renoncer à la prévision en faveur de l’adaptabilité. La première réponse simple à ce paradoxe est de séparer les échelles de temps : le monde moderne reste fortement prévisible à court-terme (avant que les boucles complexes ne puisse jouer leur rôle perturbateur), c’est le moyen et long terme qui sont, comme la météorologie, hors d’atteinte de nos modélisations. Mais cette réponse cache une réalité plus complexe : la frontière entre ces deux mondes est floue et variable selon le problème considéré. Les extrêmes (le très court-terme linéaire) et long terme (chaotique) sont de peu d’intérêt, c’est à la frontière (« edge of the chaos ») que la vie compétitive de la prévision se situe J


Une bonne façon d’introduire ce sujet est de vous suggérer la lecture de « The Signal and Noise – The Art and Science of Prediction » de Nate Silver. Dans ce livre passionnant l’auteur se livre à une mise en garde détaillée et argumentée des dérives de l’utilisations du « big data ». Dès l’introduction, il rappelle qu’il n’y pas de connaissance dans les datas, c’est nous qui les faisons parler. Lorsqu’on oublie ceci, cela peut conduire à des désastres comme celui de la crise de 2008 : « our naive trust in models, and our failure to realize how fragile they were to our choice of assumptions, yielded disastrous results ». Dans le monde nouveau de l’abondance des data, le rapport « signal/bruit » diminue, nous avons des déluges de données mais celles qui sont utiles sont plus dilluées – c’est précisément le thème de l’approche « smart data ». Une grande partie du livre est consacrée au modèle Bayésien, à la fois en tant que technique de prévision – cela reste une approche simple et robuste utilisée partout dans le monde, en particulier chez Google – et en tant que modèle de pensée : distinguer en permanence notre conception du monde avant (priori) et après l’observation (postériori) – « when we fail to think like Bayesian, false positives are a problem not just for mammograms but for all science ». Les « bonnes entreprises » ne passent trop de temps sur les modèles, elles font beaucoup d’expériences pour améliorer, modifier ou abandonner ces modèles, dans une approche évolutioniste. Cette approche de boucle d’apprentissage permanent va être le fil rouge de ce billet: « Today’s forecast is the first forecast of the rest of your life ». Nate Silver reconnait bien sûr le dilemme de la prévision dans une monde complexe et incertain “finding patterns in random noise», mais souligne que la prévision et la complexité ne sont pas forcément antagonistes : « given that forecasters in most domains  are prone to overconfidence, it is admirable that weather forecasters are hard on themselves and their forecasting peers. But the improvements they have made refute the ideas that progress is hopeless in the face of complexity”.

Ce court billet est organisé selon le plan suivant. La première partie va enfoncer une porte ouverte, celle de l’intérêt et de l’efficacité de la prévision à court-terme. Il n’y a pas besoin de s’étendre, puisqu’une partie du succès des Google, Amazon ou Facebook repose sur leur capacité à prévoir ce qui va nous plaire. La seconde partie va de façon duale, nous rappeler que, comme Nassim Taleb l’a magistralement expliqué, le monde dans lequel nous vivons ne se prête plus à la prédiction. La complexité et l’incertitude nous demandent de « gouverner autrement » et de remplacer les « plans stratégiques » par des « scénarios stratégiques » … voire des « jeux stratégiques ». La troisième partie va tenter d’explorer une synthèse entre ces deux approches contradictoires, pour explorer l’usage de modèles et de prévisions dans un monde incertain. Je vais prendre trois exemples pour illustrer comment il est possible de tisser l’analyse et l’humilité, la prévision et la prudence, le volontarisme et le lâcher-prise dans une même stratégie. Le lecteur attentif aura remarqué la persistance du thème « grecs et chinois » dans les billets du moment.


2. Le futur proche se projette dans le monde numérique


Nous vivons dans un monde qui, au travers des applications numériques de nos smartphones, s’appuie de plus en plus sur la prévision à court-terme. Nous recevons des notifications pour nous prévenir des bouchons, d’une averse, d’une chose que nous allions oublier, d’une opportunité à saisir.  Plus près de nous, notre cerveau est une machine à prévoir le futur immédiat. Qu’il s’agisse de voir, de se déplacer, de jouer avec une balle ou de communiquer, nos circuits cérébraux sont en calculs permanents pour prévoir ce qui va se passer : comment rattraper une proie ou un objet, quelles syllabes ou quels mots vont venir chez un interlocuteur ou une page qu’on lit, comment naviguer dans une foule dense pour attraper son métro, etc. Les premières expériences de Deep Learning appliquées aux vidéos montrent la capacité naturelle à prévoir un futur proche à partir du passé (je vous recommande cet interview de Yan Le Cun). Le futur proche se prête bien à la prévision car il contient peu de boucles complexes de rétro-ajustement et les modèles simples d’interpolation – dont bien sûr les régressions linéaires – donnent de bons résultats. Le monde du « Web Squared », grâce à son abondance de senseurs et de données, permet d’enrichir encore plus ces projections à court terme. Nos objets numériques projettent une petite partie de leurs futurs sur nos vies, depuis tous les assistants de sécurité actives de nos voitures jusqu’à la maintenance prédictive de nos machines-outils.

La capacité à prévoir à court-terme est un différentiateur fort dans le monde de l’entreprise. C’est une évidence pour les acteurs du monde numérique, mais c’est vrai de tous les acteurs qui opèrent des capacités, depuis le transport jusqu’aux usines de production. Ceci explique l’engouement spectaculaire pour les techniques d’intelligence artificielle et d’apprentissage signalé en introduction. Comme il s’agit d’une compétition, c’est le niveau de performance relatif qui compte, pas la valeur absolue de la prévision. Il « suffit » de mieux prévoir l’appétence d’un client pour un produit que ses compétiteurs pour en tirer un « supplément de valeur ». Lorsque la prévision est de qualité suffisante, elle permet d’améliorer l’expérience client, en éliminant des choix inutiles. De fait, la prévision court-terme est une composante essentielle de la boite-à-outils de composition des interfaces utilisateurs. Microsoft, Apple, Google utilisent des centaines de « learners » dans les produits et services qu’ils nous proposent, dont le but est de fluidifier notre navigation tout en corrigeant nos erreurs. Dans le monde de l’entreprise, le « buzzword » du moment est la prévision « next best action ». Ici aussi, les plateformes qui proposent des algorithmes d’IA pour optimiser la meilleure réponse à un événement client se multiplient. Il convient de noter qu’il n’est pas forcément facile de prévoir la meilleure prochaine action, mais qu’il est beaucoup plus efficace de prévoir le « cadre », c’est-à-dire l’ensemble des quelques actions parmi lesquelles il faudra choisir. C’est tout le principe de l’approche de Google qui cherche à vous aider à répondre plus vite aux emails en prédisant 3 réponses « probables ».

Dans un grand nombre de cas d’utilisation dans nos entreprises, les données collectées pour faire des prévisions ne qualifient pas de « big data », mais le défi pour en tirer de la connaissance n’en est pas moins excitant. Dans une conversation passionnante avec Olivier Duchesnes de DAVinci Labs, je lui ai demandé de me parler de son infrastructure Hadoop pour traiter les « big data » de ses clients. DAVinci dispose en effet de telles capacités sur le cloud … mais la plupart des projets utilisent des données qui tiennent sur un ordinateur de bureau. On retrouve ici encore l’approche « smart data » qui distingue une phase de collectes dans un océan de données, pour constituer une base pertinente d’information qui est accessible à l’ensemble des méthodes modernes de data science, y compris celle qualifiée d’ « intelligence artificielle » par les nécessités du marketing moderne. Je vous recommande fortement de lire le livre précédemment cité « The Master Algorithm » pour comprendre les différentes approches qui sont disponibles aujourd’hui.

Un cas particulier de la prévision sur des petits volumes de données est celui des séries temporelles. Selon les experts auditionnés par l’ADT, la prévision à partir de peu de données est une des frontières « difficile » de l’intelligence artificielle – par opposition aux succès spectaculaire du Deep Learning lorsque des milliards de jeux données sont présents. Ceci n’est pas une surprise : moins il y a de données, plus le modèle, le contexte et le « common sense knowlege » jouent un rôle important . Le livre de Pedro Domingo est très éclairant sur les difficultés propres et les approches à aborder dans le cas des « small data ». Le risque d’overfitting est d’autant plus grand qu’on s’éloigne du domaine simple de la projection “linéaire” du futur très proche. C’est par exemple le cas lorsqu’on cherche à analyser des données de biométrie (qui, vue de loin, ont un caractère très chaotique avec des variations multi-échelle qui ne sont pas sans rappeler les cours de marché, et qui sont les signatures de la « complexité du vivant »). Je cite Pedro Domingo : « Scientists everywhere use linear regression because that’s what they know, but more often than not the phenomena they study are nonlinear, and a multilayer perceptron can model them. Linear models are blind to phase transitions; neural networks soak them up like a sponge.” L’approche retenue dans l’application de self-tracking Knomee est de construire un algorithme par génération de code (exploration et apprentissage par renforcement), dans un espace contraint (modèle de biorythmes). Le modèle défini un espace d’algorithmes qui ont les bonnes propriétés systémiques (on retrouve un principe de GTES: utiliser des courbes en S comme générateurs au lieu de fonctions linéaires). Les méthodes classiques d’analyse statistiques servent à orienter la partie exploration aléatoire/générative vers les motifs les plus significatifs. Pour éviter l’overfitting, une première approche selon le « Master Algorithm » est d’appliquer un rasoir d’Occam : « For example, we can … machine-learning ». Cependant, il n’est pas possible d’obtenir des performances robustes, même en ayant éliminé l’overfitting: les biorythmes sont difficiles à prévoir (contrairement à la météo, la valeur précédente est un pauvre prédicteur, et il n’est pas facile de faire mieux que la moyenne mobile sur une courte durée). Pour obtenir une prévision « améliorée », il faut inclure le protocole d’évaluation de la robustesse de la prévision – sur lequel nous allons revenir dans la prochaine section - dans l’évaluation du « fitness » pour le renforcement. De cette façon l’algorithme ne passe pas seulement son temps à améliorer de façon incrémentale sa précision avec chaque nouvelle donnée, mais également à évaluer sa propre robustesse en s’observant « en train de prévoir ». La forte complexité algorithmique est compensée par le fait de travailler sur des petites séries temporelles. En revanche l’intérêt de cette approche en boucle d’apprentissage permanent est de pouvoir travailler sur un individu unique (nous sommes tous différents) et sur une période de temps courte (et donc de suivre les évolutions au cours des mois).

3. Gouverner n'est plus prévoir


Il y a beaucoup de choses qu’il n’est pas possible de prévoir, mais nous sommes néanmoins tentés de le faire. Il y a tout d’abord les phénomènes purement aléatoires, le « random noise » que l’on retrouve souvent, en particulier dans le monde de l’IoT et des senseurs connectés. Une des premières choses qu’on devrait vérifier avec une plateforme de prévision ou avec une application qui collecte des données à des fins de prévision est sa capacité à détecter un bruit aléatoire avec la réponse « désolé ! je n’ai rien à dire ». Un deuxième type de données qui ne se prêtent pas à la prévision sont celles issues de systèmes fortement complexes et non-linéaires, pour lesquels des boucles d’amplification produisent des « effets papillons ». Il peut s’agir de la modélisation à long terme d’un système météorologique, mais également de l’adoption d’un service au travers un déploiement viral – tels que les réseaux sociaux – ou encore de la variation des prix sur un marché (pour citer Nate Silver « The central claim of the theory is that the movement of the stock market is unpredictable to any meaningful extent ». On aura reconnu ici un des thèmes centraux de Nassim Taleb que j’ai plusieurs fois développé dans ce blog. Plus profondément, l’émergence de comportements collectifs intelligents (ce que Nate Silver appelle le « herding ») est une signature de la complexité des systèmes qui conduit aux « power laws » (l’extremistan de Taleb).

Il reste néanmoins de nombreux domaines qui se prêtent bien à la prévision, mais il faut un peu de prudence et surtout un peu de connaissances en statistiques. Le monde des prévisions est rempli de « faux positifs », d’algorithmes qui semblent bien expliquer le passé mais sont incapables de fournir une performance robuste. Dans un monde d’abondance de données et de performances spectaculaires des algorithmes d’intelligence artificielle sur certains types de problèmes, il est fréquent de rencontrer des attentes irréalistes, et des mauvais réflexes consistant à augmenter la quantité de données ou de traitement pour améliorer les performances. Je vous recommande chalheureusement la lecture de « Everybody Lies: Big Data, New Data, and What the Internet Can Tell Us About Who We Really Are» de Seth Stephens-Davidowitz. Outre le fait que ce livre est particulièrement divertissant et nous apprends beaucoup de choses sur qui nous sommes, il contient une très bonne introduction au “curse of dimensionality” et autres pièges de la modélisation de données. On retrouve des propos assez semblables à ceux du livre de Nate Silver. Ce fléau de dimensionalité (une des formes d’overfitting) survient lorsqu’il y a trop de variables explicatives disponible par rapport à ce qu’on cherche à prévoir ou expliquer : « The curse of dimensionality is a major issue with Big Data, since newer datasets frequently give us exponentially more variables than traditional data sources—every search term, every category of tweet, etc. » Tous ces bais sont d’autant plus fréquent qu’on dispose de beaucoup de données et de beaucoup de puissance de calcul. On considère souvent que « data is the new code », mais en fait les algorithmes sont générés en fonction des données et des protocoles d’apprentissage et de validation. Comme cela a été dit plus tôt dans le cas des courtes series temporelles, la forme la plus importante de connaissance est le protocole que l’on applique pour tester la validité de la prévision.

Lorsque la complexité rend la prévision trop difficile ou trop peu robuste, cela ne signifie pas que l’analyse des données ou la formulation de modèle est inutile, mais l’utilisation est forcément différente. Dans un monde complexe, ce qu’il faut apprendre, ce n’est pas ce qui va se passer mais comment réagir à ce qui pourrait se passer. C’est le centre des recommandations de Nassim Taleb dans « The Black Swan » et encore plus dans « Antifragile ». C’est le principe des « war games » et des « serious games », comme cela a été développé dans un précédent billet. C’est aussi la proposition de valeur de COSMO TECH qui utilise des méthodes sophistiquées pour modéliser des systèmes complexes avec des agents qui encapsulent des facettes du comportement. La simulation n’est pas un outil de prévision, c’est un outil pour développer une meilleure compréhension du système. Cette pratique du « jeu sérieux » peut être confiée à des humains, qui vont développer des nouvelles compétences « systémiques », ou elle peut être automatisée dans une approche de théorie des jeux évolutionnaire. C’est tout le principe de l’approche GTES (Game-Theoretical Evolutionary Simulation) que j’ai présentée dans plusieurs billets.

Gouverner n’est donc plus simplement prévoir, même si la prévision reste un outil de choix. Gouverner c’est aussi comprendre et distinguer ce qui n’est pas prévisible de ce qui pourrait l’être, c’est comprendre que toute prévision doit être constamment validée dans une boucle d’apprentissage et que le succès dans le passé n’est pas indicateur de la robustesse d’une méthode de prévision dans le futur. Il est tentant de faire un parallèle avec le « dual loop learning » de Chrys Argyris : la première boucle est celle du « machine learning » à partir des données, la seconde boucle est une remise en cause et ré-évaluation permanente à partir de deux questions : celle prévision est-elle robuste ? la situation est-elle en train de changer ?  Exactement comme pour le pilotage agile, l’approche itérative à cycle court est la meilleure façon de s’adapter constamment à un monde qui change. Je peux également citer Cathy O’Neil dans son livre dont je parlerai en conclusion : « Equally important, statistical systems require feedback—something to tell them when they’re off track. »


4. Jouer avec les modèles


Je vais maintenant revenir sur la question posée en introduction : comment utiliser données, modèles et prévision “on the edge of the chaos”, dans cette zone limite entre le monde (grec) des systèmes linéaires qui se prêtent bien à la prévision et celui (chinois) des systèmes chaotiques qui relèvent des conseils de Nassim Taleb. Le problème est intéressant car « ignorer Taleb » c’est prendre le risque des « crises de 2008 » et « ignorer Google » c’est prendre le risque d’être moins efficace que ses concurrents pour satisfaire ses clients. Je vais utiliser trois exemples qui correspondent à trois cas de figure différents d’interaction entre les parties « chaudes » et « froides » des modèles :
  • La « fusion» correspond au cas de figure ou la nature chaotique est intrinsèque à l’ensemble du système et où il serait vain de vouloir faire des prévisions. Il est néanmoins possible d’utiliser des données, des méthodes et des algorithmes pour créer des simulations qui servent à l’éducation et la compréhension systémique (cf. COSMO TECH ou GTES). Dans ce cas, le terme de « jouer avec les modèles » prend tout son sens.
  •  La « combinaison » correspond au cas où il existe des sous-problèmes qui se prêtent bien à la modélisation et la prévision, mais qui sont couplés avec le système global. Il n’est pas possible de faire des prévisions globales, mais il est possible d’appliquer des modèles et des analyses prédictives sur certains aspects.
  • La « séparation » correspond au cas où il existe, au sein d’un système complexe difficile à prévoir, des sous-systèmes qui sont structurants et réductibles. Dans ce troisième cas, il est possible de faire des prévisions, même si elles ne sont que partielles.



J’ai travaillé pendant une dizaine d’année, de 2001 à 2012, sur l’utilisation de la théorie des jeux pour modéliser les évolutions de part de marché dans la téléphonie mobile, en particulier lors de ruptures telles que l’arrivée de la 3G ou l’arrivée d’un quatrième opérateur. J’ai déjà évoqué ces travaux dans plusieurs billets de ce blog, lors d’exposés – en particulier celui de 2010 à l’INRIA, et dans plusieurs articles, dont celui de CSDM 2012. Je mentionne ce travail ici parce que c’est un exemple parfait de modélisation incertaine du premier type : la simulation n’est pas une prévision, mais l’ensemble des simulations forment un jeu qui permet de mieux comprendre la situation. Ce travail s’appuie sur un modèle simple de fonctionnement financier des opérateurs téléphonique (tel qu’on le voyait en 2005), dû à Philippe Montagner (président de Bouygues Telecom à cette époque) et intégré sous forme de compétition entre acteurs sur le même marché. L’approche GTES consiste à faire des milliers de jeux, chaque jeu étant la recherche d’un équilibre de Nash dans des conditions de marché données (nous ne connaissons pas le futur, donc l’approche Monte-Carlo permet d’explorer l’incertitude). Nous avons également participé à des « serious games » organisés par McKinsey sur le même principe : chaque équipe représente un opérateur et un simulateur informatique représente le marché. L’intérêt de l’approche GTES est de pouvoir démultiplier l’espace qui est exploré. Cela fait presque 10 ans que les premières simulations de l’arrivée de Free sur le marché ont été faite, et avec le recul, on peut apprécier l’intérêt de cette approche par rapport aux méthodes économiques plus classiques. Les trajectoires et les caractérisations produites par le modèle donnaient une bonne indication de ce qui allait se passer.

La dimension analytique de l’approche « Lean Startup » est un bon exemple du deuxième cas de figure : il n’est pas possible de prévoir le succès d’un nouveau service dans le monde numérique, mais les pratiques d’innovation accounting et de growth hacking apportent de la rigueur à une partie de ce processus d’innovation. Ce qui est fascinant dans l’approche d’Eric Ries, c’est la décomposition du processus de création de valeur de l’innovation en des étapes « aléatoires/imprévisibles » (ce qui revient au même) telles que l’idéation, l’appropriation et l’adoption, avec des étapes qui se modélisent, se mesurent et s’analysent : la capture, l’usage, la recommandation. Le Lean Startup consiste à faire vite et peu cher pour les étapes incertaines, pour se retrouver en condition de créer à coup sûr de la connaissance (positive ou négative) sur ce qui est utile au client. La grande rupture du Lean Startup a été de déplacer l’attention de l’idéation (volatile, multiple, non-différentiante dans la majorité des cas) vers la satisfaction validée du client (ce qui crée la valeur). Dans son nouveau livre « The Startup Way », Eric Ries insiste sur le fait que nous sommes dans un monde imprévisible : « a startup should be understood as a human institution designed to create a new product or service under conditions of extreme uncertainty ». Mais cette imprévisibilité ne signifie pas que la mesure et l’utilisation des données ne sont pas au cœur du processus : « a modern company attempts to maximize the possibility and scale of future impact. Project teams report and measure leading indicators using innovation accounting ». De la même façon, la phase ultérieure de « Growth Hacking » consiste à piloter un phénomène éminemment complexe et difficile à prévoir (l’adoption dans les comportements récurrents et la recommandation) en utilisant des modèles et des mesures.

Je vais terminer par un exemple plus simple et plus pragmatique, celui de la modélisation des coûts du système d’information. Je travaille sur ce sujet depuis 1998, lorsqu’il m’a été demandé de construire un modèle des coûts informatiques de Bouygues Telecom. Ces vingt ans sont une suite d’échecs et de progrès, liés à l’incorporation progressive des facteurs humains, complexité et incertitude, tout en faisant l'expérience de la citation de Georges Box: "Tous les modèles sont faux mais certains sont utiles". Nous sommes ici dans le troisième cas de figure : certains aspects sont très difficiles à prévoir (la création de valeur ou l’arrivée de nouveaux besoins liés à l’évolution du métier) et d’autres sont au contraire très faciles à modéliser (les cycles de vies, les couts de possession, le vieillissement et l’accumulation). Dans un monde complexe et incertain, l’exercice du plan stratégique a perdu en intérêt, pourtant un certain nombre d’actions clés pour construire « le potentiel de situation » du système d’information doivent s’inscrire dans un plan à long terme. Dans cet exercice stratégique, il faut tenir compte de ce qui est incertain – par exemple le flux entrant des opportunités et contraintes réglementaires – et ce qui est modélisable mais plein de surprises, comme l’usage et la stabilisation de la qualité de service. Voici ce que je retiens des nombreuses années d’utilisation de tels modèles hybrides :
  • Un bon modèle hybride incertain utilise des « grandeurs » (KPI / métriques) connues et accessibles, qui sont comparables et pour lesquels le benchmarking s’applique. Plus le monde est incertain, plus les grandeurs manipulées doivent être intuitives.
  •  Le modèle doit être suffisamment simple pour fonctionner en « glass box », c’est-à-dire que les résultats ne suffisent pas, il faut pouvoir d’approprier le « raisonnement » du système d’aide à la décision. C’est une conséquence essentielle de la complexité et de l’incertitude.
  • Ce type de modèle est utilisé en mode « scénarios / jeux », mais ce qui compte c’est la partie stable des simulations, sur laquelle les décisions long terme sont faites.
  • Ces modèles hybrides permettent de comprendre les arbitrages fondamentaux court-terme versus long-terme qui sont nécessaire pour développer le SI de façon durable, sans accumuler les dettes techniques ou figer le « potentiel de situation ».

5. Conclusion


Dans son livre “Weapons of Math Destruction – XXX” Cathy O’Neil propose un “serment d’Hippocrate” pour les data scientists que je reproduis ici parce qu’il résume bien les thèmes que nous avons abordés :
  • I will remember that I didn’t make the world, and it doesn’t satisfy my equations.
  • Though I will use models boldly to estimate value, I will not be overly impressed by mathematics.
  • I will never sacrifice reality for elegance without explaining why I have done so.
  • Nor will I give the people who use my model false comfort about its accuracy. Instead, I will make explicit its assumptions and oversights
  • I understand that my work may have enormous effects on society and the economy, many of them beyond my comprehension. 

Cedric Villani a fort justement recommandé la lecture de ce livre dans une de ses interviews au sujet de sa mission sur l’Intelligence artificielle. Cathy O’Neil fait un remarquable travail d’analyse sur deux points essentiels : la capacité des systèmes « intelligents » à absorber les biais des données collectées pour leur apprentissage et l’importance de comprendre le système produit par l’algorithme et l’environnement. Autrement dit, ces « systèmes intelligents » produisent eux-mêmes des effets sur l’environnement auquel ils sont appliqués. La combinaison d’un système intelligent et d’un environnement non moins intelligent constitue un systèmes complexe dont il peut être difficile de prévoir les conséquences.

Pour conclure, voici un résumé des trois points qui me semblent essentiels :
  •  Il n’y a pas d’intelligence sans prévision. La prévision fait partie intégrante de notre capacité de raisonnement et de prise de décision, elle est également un des critères les plus utilisés pour évaluer l’ « intelligence » d’un système ou d’une personne. Les assistants personnels de demain, des robots domestiques aux remplaçants de Siri, seront doté à la fois d’un sens commun et d’une capacité réflexive à prévoir.
  • L’humilité est nécessaire pour atteindre un degré supérieur d’apprentissage – elle est indispensable pour progresser dans un monde incertain. L’humilité permet d’éviter de tomber dans le piège toujours présent de la « narrative fallacy ». Savoir évaluer l’incertitude et connaître ses bais est une exigence difficile du monde VUCA du 21e siècle.
  • La cybernétique de l’apprentissage en double boucle – qui représente la nécessaire réflexion (hansei) sur son propre apprentissage - est la marque de l'adaptation à un environnement complexe et incertain. La fréquence et l’ampleur de cette mise en cause permanente dépend de la complexité et l’incertitude de l’environnement. Apprendre de son passé exige une remise en cause régulière – c’est tout l’art de l’oubli – d’autant plus grande que le futur est incertain.

dimanche, juillet 30, 2017

Américains et Japonais : Culture logicielle et apprentissage par la pratique et la résolution de problème



1. Introduction


Mon livre de 2011, « Processus et Entreprise 2.0 – Innover par la collaboration et le lean management » devait s’appeler « Lean Entreprise 2.0 » mais ce titre a été jugé comme trop obscur. Pourtant, le livre est construit autour de la complémentarité de deux cultures très différentes, la culture collaborative « du Web 2.0 » venue des Etats-Unis et la culture d’amélioration et d’apprentissage continus du « Toyota Way ». Le chapitre 9 est consacré à cette double provenance de cultures différentes, avec des tensions et des apports, et aussi des éléments communs puisque des racines du « Toyota Way » viennent des idées et travaux autour du TQM (Total Quality Management) rendus célèbres par Edward Deming. Ce livre a été écrit il y a sept ans mais j’ai continué depuis à m’intéresser, et à pratiquer, des approches mixtes qui combinent ces deux influences à la rencontre du lean et de la culture logicielle. C’est très clairement le cas du Lean Startup, qui a été le cœur de mon attention depuis 2012. C’est également vrai pour l’approche « lean software development » que j’ai implémenté au sein des différentes « lean software factories » auxquelles j’ai contribué.

Le titre de ce billet est évidemment un clin d’œil au billet précédent, mais c’est bien la combinaison de traits culturels issus du monde japonais du Toyota Way et du monde américain de la culture du logiciel qui va me servir de fil rouge. Les deux livres dont je vais parler dans ce billet sont eux aussi placés sous le signe de la double culture … Ce thème n’est pas nouveau, on le trouve déjà dans d’autres ouvrages dont j’ai parlé dans ce blog (je pense en particulier à « The Lean Enterprise » -) mais ces livres apportent des éclairages originaux et rafraichissant sur le sujet.

Le livre de Cecil Dijoux est un livre sur la transformation numérique à la suite de nombreux autres tels que ceux de Gilles Babinet ou Nicolas Collin et Henri Verdier, mais sous l’angle d’analyse de la pensée Lean, ce qui conduit un ouvrage profond et décapant, une sorte de suite des « Géants du Web », dans laquelle l’importance des compétences et des pratiques joue un rôle fondamental. Dans ce livre, culture logicielle et apprentissage par la pratique et la résolution de problèmes, sont progressivement introduit comme des évidences nécessaires à l’adaptation profitable des entreprises à la vague des opportunités et défis du monde numérique.

Le livre suivant est un livre de sociologie consacré aux développeurs, proposé par l’équipe « The Boson Project ». Ici le point de départ est la culture logicielle, ce livre est une réponse logique à Cecil Dijoux qui nous invite à mieux comprendre et respecter les « doers du monde numérique ». Mais les « bonnes pratiques » du développement nous conduisent également à retrouver des racines d’apprentissage continu et de collaboration qui font un autre pont entre culture logicielle et  « lean management ».



2. Ce que signifie l’avènement du numérique


Je vous recommande très vivement de lire ce livre ! c’est un livre court, synthétique qui va droit à l’essentiel avec quelques illustrations très pertinentes autour des messages principaux. En particulier, Cecil Dijoux s’appuie sur une excellente bibliographie, une véritable curation des meilleurs livres ou articles pour comprendre les enjeux du monde modernes et des organisations. Une autre pépite du livre est la « liste de questions à se poser » fournies dans chaque chapitre, qui rend la lecture plus personnelle et plus pertinente pour chacun. Afin d’éviter que l’action de le résumer n’affadisse complètement le propos, j’ai choisi sept idées qui me semblent essentielles, mais c’est un choix éditorial et personnel.


1. Importance du “Why” et du “North Star”

Les nouvelles organisations sont construites autour du pourquoi – on retrouve ici le « start with why » de Simon Sinek. Dans le monde du lean, c’est la métaphore de l’étoile polaire qui capture l’importance vitale du but comme outil de construction de l’organisation. Le thème du livre étant la transformation numérique, Cecil Dijoux emprunte la définition suivante à Ludovic Cinquin : « La transformation numérique c’est l’exploitation radicale des possibilités d’Internet ». Le numérique n’est pas un objectif, c’est un moyen : « En d’autres termes, le numérique est un outil d’apprentissage, car il permet l’expérimentation rapide à des échelles très importantes pour valider (ou invalider) des hypothèses. L’exemple typique est celui de Facebook mettant en production une fonctionnalité pendant 45 secondes pour en valider la pertinence ». Le challenge principal des entreprises est bien celui décrit dans « Exponential Organizations » : celui de s’adapter continument et d’apprendre collectivement dans un monde qui change de plus en plus vite, soumis au flot continu de la transformation « exponentielles » des technologies, en particulier des technologies numériques. Pour saisir les opportunités du monde numérique, le premier défi à relever est celui de l’apprentissage permanent. Le pilotage par le « why » est la déclinaison dans l’entreprise du rôle fondamental de la finalité des systèmes complexes. Cette finalité doit être claire – comprise par tous – c’est le point essentiel de la métaphore de l’étoile polaire – et simple, pour résister à la complexité de l’environnement.  J’emprunte au livre cette superbe citation de Dee Ward Hock : « Une raison d’être et des principes simples et clairs font émerger un comportement intelligent et complexe. Des réglementations complexes sont émerger un comportement simple et stupide ». Pour terminer cette lecture systémique, on peut dire que le principe d’organisation proposé est la combinaison de trois choses : (a) une finalité définie par le pourquoi, de façon simple et claire (b) un chemin qui définit le comment de façon incrémentale, - par petits pas, nous allons y revenir – (c) une boucle de questionnement continue par l’écoute (des clients/utilisateur) et la mesure (avec une forte emphase sur la simplicité de ce qui est mesuré).

2. Co-développement de la stratégie et l’exécution

Le deuxième chapitre s’intitule « pourquoi l’exécution est la stratégie » et commence par cette proposition : « Car la stratégie, à l’ère du numérique, n’est pas dans les idées ou les concepts mais, bien plus qu’à toute autre époque, dans l’exécution, collée au plus près du réel opérationnel ». Un des messages constant et fort du livre est l’impérieuse nécessité de sortir du Taylorisme. Ceci de décline de multiples façons, comme par exemple dans le domaine de l’architecture : « L’architecture (technique et logicielle) n’y est pas préconçue pendant des mois. Elle émerge de la résilience du système développé grâce aux tests automatiques qui vont permettre de « refactorer » le code en permanence. Une démarche qui relève de l’impensable pour nos architectes SI imprégnés de la culture tayloriste, à savoir : « nous pensons et vous exécutez » ». Le co-développement de la stratégie et de l’exécution s’articuler autour de l’émergence et de la résilience. L’émergence désigne ici la capacité à exploiter la sérendipité, dans la droite ligne du potentiel de situation cher à François Jullien. Je vous renvoie aux exemples passionnants de la page 18 (Facebook, Twitter, etc.) qui montre à quel point le succès vient de la capacité à saisir des opportunités non anticipées – encore faut-il avoir les moyens (les compétences techniques) pour le faire (le potentiel de situation se construit par les apprentissages précédents). La résilience est une exigence fondamentale de l’excellence de l’exécution. L’idée clé du livre est de montrer que la résilience est un choix stratégique qui modèle l’organisation, le système que l’on construit et les pratiques de développement. Cela conduit, de façon paradoxale comme le souligne Cecil Dijoux, à faire des choix simples et prudents, à préférer construire sur des technologies fiables et éprouvées plutôt que de d’absorber trop de risques liés à l’effervescence du monde logiciel.


3. Racines « lean » dans les pratiques du numérique

Beaucoup des bonnes pratiques du monde numérique, en particulier dans le développement logiciel mais aussi dans l’organisation du travail et des équipes, peuvent être expliquées grâce à des « principes lean ». On retrouve des principes de flux tirés, de management visuel et de résolution de problème dans les méthodes agiles. Je partage cette analyse – avec de nombreux autres – même s’il ne faut pas aller trop loin dans le « réductionnisme » : il y a des idées du monde agile qui ne viennent pas du « Toyota Way », et à l’inverse le « lean software development » apporte des nouvelles dimensions – en particulier sur la vision produit et long-terme – aux méthodes agiles. On retrouve donc au cours du livre des « bonnes pratiques » des organisations modernes capables de profiter pleinement de la transformation numérique : organisation en squads (équipes cross-fonctionnelles autonomes), utilisation massive du visual management (à la fois pour la résolution de problème, l’apprentissage collectif du système complexe commun, de l’organisation et pilotage du travail en flux tiré et « petits lots », les « gemba walks » des managers (aller sur le terrain, écouter et voir, monter le respect). Régis Médina donne une formidable clé de lecture sur l’apport du lean : « Le Lean nous apprend qu’il faut d’abord développer le potentiel des employés pour développer de bons produits ». C’est également le message sur lequel j’avais conclu mon intervention au Lean IT Summit en 2013. Je vous recommande également les nombreux témoignages qui montrent la force de ces pratiques lorsqu’elles permettent à une équipe autonome de prendre en charge son propre apprentissage. Je reproduit ici une double citation (page 41) parce que ce thème est central : « de nombreux penseurs du Lean (Dan Jones, Michael Ballé) ont compris depuis fort longtemps qu’appliquer les seuls outils du Lean (5S, Kanban, ..) ne suffisait pas à transformer son entreprise en organisation apprenante. Ils nous rappellent sans cesse que l’efficacité du système passe par l’apprentissage permanent, de tous, chaque jour, à travers la résolution de problème par l’approche scientifique. … . Si le Lean est un mode de management parfaitement adapté au monde du numérique, c’est parce qu’il place l’apprentissage permanent au cœur de la stratégie de l’entreprise ».

4. Lean Startup

Le livre de Cecil Dijoux fait la part belle à l’approche « Lean Startup » et son cycle « Build, Measure, Learn » : « En appliquant ce modèle de boucle infinie (construire, mesurer, apprendre), les entreprises du numérique établissent un rapport objectivé à la réalité, adapté aux changements de celle-ci, en faisant levier de la radicalité d’Internet ». Je ne peux qu’applaudir à cette mise en valeur, même si je trouve que le rôle central de l’observation et de la promesse (le Unique Value Proposition de Ash Maurya) est un peu laissé de côté (il ne suffit pas de produire des connaissances validées, encore faut-il qu’elles soient utiles). Les pages qui expliquent et justifient le principe « des petits lots » - l’approche itérative – sont remarquables, tout comme l’impérieuse recommandation de mettre le client au centre de cette boucle : « En raison du principe de l’obsession du client, les équipes se doivent d’être rapprochées et reliées au client. Ce lien est incarné dans l’approche du flux tiré : les équipes ne produisent que ce que le client attend, quand il l’attend ». Je vous renvoie également à l’excellent livre de Marco Tinelli – « Le Marketing Synchronisé ». 

 5. L’importance des équipes cross-fonctionnelles et autonomes

Un autre message clé développé tout au long du livre est de s’appuyer sur la responsabilisation de ceux qui font (et donc qui savent). Voici ce que le livre propose pour réfléchir à comment inscrire l’exécution au cœur de la stratégie numérique : « Identifier dans votre organisation les doers (développeurs, designers, utilisateurs avancés des nouveaux outils numérique) et les personnes disposant de compétences en humanités pour vous entourer et vous aider à définir les premières hypothèses que vous allez tester ». Une équipe cross-fonctionnelle fonctionne mieux lorsqu’elle est co-localisée : « La encore, de très nombreuses études sociologiques démontrent l’efficacité de la co-localisation … plus des personnes sont éloignées, moins la communication est efficace ». Ce mode de travail demande une certaine prudence avec la sous-traitance – je reprends ici une citation d’Henri Verdier «  Une petite musique agaçante commence à s’instiller dans la société française, qui voit dans la sous-traitance le gage de l’efficacité. Je n’y souscris pas. » Un peu plus loin, au sujet des sociétés les plus avancées du numérique, Cecil Dijoux écrit : « Je constate qu’elles mettent en œuvre très peu, voire aucun, des conseils de l’orthodoxie de la stratégie d’entreprise – externalisation comprise ». Il y a au cours des pages (cf. page 29) de nombreux témoignages sur l’importance des développeurs, ce qui va faire le lien avec le livre suivant : « Je me rappelle ainsi d’une réunion chez un client ou le responsable des études … s’étonnait que je m’intéresse de très près aux développeurs et pas suffisamment aux managers ou chefs de projets ». Dans la tradition du Lean, les managers sont invités à changer leur regard sur les « ouvriers de production » du numérique, à savoir les développeurs – ce sera le sujet de la partie suivante.

6. Importance du temps

La prise en compte du temps, à la fois dans la chrono-analyse globale et dans l’obsession de la maîtrise des délais, est une caractéristique du lean qui est parfaitement adaptée au monde numérique. Beaucoup des questions que l’auteur pose au lecteur sont liée au temps : « Quel est le temps de réponse des outils que vous mettez à disposition de vos équipes ? Supérieur à une seconde, à 2 secondes, à 3 secondes ? Est-il acceptable pour vos employés ? Ces outils sont-ils fiables ? … ». Le livre insiste sur l’importance des outils et de l’automatisation pour raccourcir les cycles. On retrouve ici la synergie entre les méthodes modernes (et rapides) de déploiement continus de type DevOps et les méthodes de conception de produits et services numériques de type Lean Startup. Au-delà de l’outillage et des bonnes pratiques d’intégration continue, de test continu et de déploiement continu, il s’agit également d’une question d’organisation et de « mindset ». Cecil Dijoux insiste à juste titre sur le « focus », le fait de ne faire qu’une chose à la fois : « Des équipes à temps plein sur un seul sujet. De très nombreuses études de science cognitives démontrent que pour une personne en train de traiter deux sujets, le risque d’erreur est double et le temps de réalisation est doublé ». L’obsession du temps client, de la performance perçue (temps d’attente), de la fiabilité est une des caractéristiques des « Géants du Web » qui est également mis à l’honneur dans ce livre. Cela se retrouve dans le traitement de la fiabilité, avec un rappel sur les MTTR (temps moyen pour réparer) versus MTBF (temps moyen entre deux indisponibilités) qui m’a fait penser à mon cours à Polytechnique il y a 10 ans.  Les méthodes et pratiques de développement modernes contribuent à la fiabilité et à la satisfaction des clients parce qu’elles permettent de réduire significativement le temps moyen de réparation.


7. Rôle du management

Le livre consacre un chapitre entier au rôle des managers, parce qu’il ne souscrit pas – moi non plus – à la théorie d’une entreprise autoorganisée sans managers : « contrairement à ce que l’on peut prétendre, le management, et donc les managers, à toujours un rôle dans les organisations du XXIe siècle, et ce rôle est prépondérant. Toyota l’a montré au XXe siècle et Google, à travers deux études passionnantes, le montre au XXIe siècle ».  Les deux projets auxquels il est fait référence sont le projet Aristote et le projet Oxygen. Tout comme  Cecil Dijoux, je vous recommande fortement la lecture de l’article de Charles Duhigg sur le projet Artistote : « What Google Learned from its quest to build the perfect team » ainsi que l’article de David Garvin « How Google sold its engineers on management ». Le projet Oxygen permet de définir le profil du manager/coach adapté aux nouvelles formes d’organisation – et oui, ce rôle existe (« In light of this research, the Project Oxygen team concluded that managers indeed mattered »).  D’une certaine façon, il n’y pas de surprise dans la définition de ce profil (coach / support / communiquant / orienté résultats / intéressé par le développement des collaborateurs / suffisamment technique pour écouter les doers / empathique / …) mais l’intérêt vient de la méthode – rigoureuse et fondée sur les faits – et de l’origine, Google, qui n’est pas une entreprise « classique »). Le manager joue un rôle essentiel de facilitateur de l’apprentissage, individuel et collectif, même si la responsabilité de cet apprentissage revient au collaborateur et à l’équipe. « Le Lean est, comme le rappelle Michael Ballé, un système d’éducation permettant le développement des personnes jusqu’à leur autonomie ». A la fin du livre, Dan Jones insiste sur la dimension sociale du management : « J’ai toujours cru que changer d’organisation sociale était beaucoup plus lent qu’exploiter les opportunités qu’ouvrent les nouvelles technologies. L’organisation sociale est la clé. Le Lean est essentiel parce qu’il aide à créer des organisations plus agiles, capable de faire face au défi du numérique grâce à l’implication de chacun dans l’amélioration ».

Avant de passer au livre suivant, je tiens à souligner que ne suis pas d’accord avec tout ce qui est écrit dans cet ouvrage. Une partie de l’opposition un peu simpliste entre la vision du DSI et celle du digital, page 57 par exemple, me semble relever plus de la rhétorique que de la réalité (on trouve d’ailleurs, un peu plus loin page 62, des propos plus nuancés). De la même façon, la charge contre les processus est un peu caricaturale et vise plutôt l’abus des procédures que la démarche processus elle-même. Mon désaccord le plus profond porte sur la valeur de l’intégration. Je ne souscris pas à l’affirmation, page 61, que l’intégration n’apporte pas de valeur au client. Il s’agit d’une vision purement statique (à un instant t donné, l’intégration est une fonction cachée, invisible, qui n’apporte pas de valeur perçue). Dans une vision dynamique, les capacités d’intégration sont un potentiel de situation, qui apportent une forte valeur au client.

En revanche, je suis particulièrement en phase avec l’obsession du rôle central du client qui est développée du début à la fin du livre. Je termine avec cette citation de Régis Medina, qui insiste avec beaucoup de justesse : « Rendez visibles les problèmes. Assurez-vous que les problèmes des clients sont recueillis et analysés. Sélectionnez ceux qui doivent être gérés au cas par cas. Vous n’avez nul besoin d’outils ou de statiques sophistiqués ; contentez-vous d’écouter vos clients et de traiter les problèmes les uns après les autres »



3. Décoder les développeurs



J’ai décidé de compléter ce compte-rendu par un autre, plus synthétique, du livre de Benjamin Tainturier et Emmanuelle Duez qui s’intitule « Décoder les développeurs – Enquête sur une profession à l’avant-garde ». Les auteurs commencent par définir son objectif de la façon suivante :  « Ce livre aimerait reconnaitre les mérites des développeurs, élaguer les forêts sombres du « développement », du « langage », du « code », pour éclaircir les sous-bois qui effraient les entreprises ». C’est avant tout un livre de sociologie, nourris d’entretiens et d’étude de situation, dont je vous recommande d’autant plus la lecture que je vais faire un exercice particulier de mettre en exergue quelques points qui font écho aux propos précédents. Il y a beaucoup d’autres contributions à découvrir comme par exemple une analyse du logiciel dans la typologie des services et des biens.

1. Développer c'est concevoir et exécuter à la fois 


Je commence par cette première affirmation – que je partage bien évidemment – à cause de la symétrie avec la partie précédente. Je cite : « Développer amalgame donc nécessairement concevoir et exécuter. Séparer ces deux étapes de création n’a guère de pertinence hors de l’usine taylorienne ». Les auteurs introduisent la caractérisation de « cols ciels » pour désigner les programmeurs qui sont à la fois des « cols blancs » - des concepteurs – et des « cols bleus » - des ouvriers d’un atelier industriel avec ses pratiques. L’insistance sur les pratiques (par rapport aux principes) est essentielle : « L’agile conseille les meilleures pratiques et dispense une nouvelle pensée du travail, qui s’est imposée progressivement aux développeurs. Méfiance cependant, car toute liste prétendument exhaustive de principes dit « agiles » est immédiatement caduque : en figeant l’organisation dans des commandements, cette liste perdrait sa raison d’être ». L’analyse que fait le livre de l’importance de la communication dans la pratique agile, à la fois en tant qu’outil et qu’objectif, est tout à fait remarquable (dans la droite ligne de « Processus et Entreprise 2.0 », pourrais-je dire :) ). On retrouve plusieurs points fondamentaux, tels que l’utilisation du management visuels pour rendre explicites les marges de manœuvres de chacun aux autres.


2. Les développeurs sont des ouvriers métiers du 21e siècle



Le livre propose une comparaison très intéressante entre différentes professions ouvrières et structure de compagnonnages, et le développement logiciel. Cette analogie est manifeste dans l’existence de la « conscience professionnelle » des développeurs, qui dépasse le cadre du projet ou de l’organisation à laquelle ils sont rattachés : « Les ouvriers de métier, les développeurs, bénéficient, en effet, d’une position favorable sur le marché du travail. Ce détail structure la conscience professionnelle, cette conscience de remplir une fonction essentielle, et rare, de la société ». Hors contexte, cette affirmation peut sembler surprenante, je vous engage donc à lire le livre pour la comprendre véritablement, mais disons qu’on peut l’interpréter dans le contexte du monde numérique qui a vu la revalorisation du développement. Cette conscience professionnelle fait que le lien entre le développeur et son code est fort, et dépasse un lien contractuel ou marchand. Le développeur moderne appartient à des écosystèmes et des communautés multiples, qui dépassent son entreprise. L’organisation multiple de Spotify, avec des tribeschapters et guilds tient compte de cette réalité sociologique. A titre d’illustration, le fait d’avoir commencé ma vie professionnelle en développant en LISP est un marquage fort, qui a changé ma façon de penser et crée une familiarité forte, des décennies plus tard, avec les gens qui partagent la même expérience. Cette conscience professionnelle est associée à une esthétique professionnelle – ce qu’on trouve dans tous les compagnonnages avec des « beaux gestes » et de « beaux ouvrages ». Dans le monde du développement agile, « Cet objectif commun c’est le « beau code », la bonne programmation ».  Je vous renvoie à un précédent billet dans lequel je faisais l’apologie du « beau code ». Cela conduit à la notion essentielle de « Software Craftmanship » : «  Du coté des developpeurs, le mouvement « Software Craftmanship », ou « artisanat logiciel »,  pose les principes d’un nouveau genre de programmation, promouvant l’artisanat plus que l’exécution ». Cette collection de pratiques et de savoirs organisé en artisanat apporte la flexibilité nécessaire pour apprendre et améliorer en continu, en dehors d’un cadre méthodologique trop restreint :  « Le Software Craftmanship a été créé pour combler les incohérences, les absences du Scrum, l’orientation business trop marquée du Scrum. Le Software Craftmanship recolle les morceaux techniques ».

3. Développeurs et chefs de projets / complexité et complication 

On retrouve dans ce livre, traité plus en profondeur, la question de l’opposition entre développeurs et chefs de projet. D’un point de vue sociologique, plusieurs témoignages confirme l’héritage du Taylorisme noté par Cecil Dijoux plus haut, à savoir la moindre reconnaissance des doers. Plusieurs systèmes de valeurs cohabitent, avec un hiatus « pour les développeurs les plus passionnés, devenir chef de projet, et cesser de coder, n’est pas évoluer, mais bien régresser ». Je n’ai pas le temps de rentrer dans ce débat – ce n’est pas mon objet – mais il me semble que ces deux rôles sont également nécessaires dès qu’on passe à l’échelle, et qu’il faut mélanger complexité et complication. La complexité exige de reconnaître le rôle du développeur et d’abandonner le taylorisme. La complication des grands programmes / produits / systèmes nécessite des fonctions d’orchestration, de pilotage et de communication propres aux chefs de projet. Le passage des équipes agiles à l’échelle, et l’intégration de ces équipes dans des programme de grande taille dépasse le périmètre de ce billet (et du livre). Pour aller plus loin voire SAFE (Scaled Agile FramEwork), surtout dans sa version 4.5.


4. Contrôler et mesurer le développement 


Je vous recommande particulièrement les quelques pages sur la mesure appliquée au développement logiciel, en particulier dans le contexte agile. On y retrouve, de façon plus directe et percutante, quelques idées que j’ai exprimées dans un billet précédent : « Cet ouvrage se propose d’expliquer aux néophytes pourquoi évaluer les équipes de développeurs à la quantité de code produite n’a absolument aucun sens. Les décideurs qui ignorent ce point essentiel courent à la catastrophe. Voilà ce que des développeurs doués et durs à la tâche sont en droit d’attendre : un manager sensible au talent de ses équipes ». Mesurer la création de valeur n’est pas une attente illégitime – de celui qui paye par exemple – mais il faut une grande humilité car cette création de valeur est éminemment complexe. En vertu de ce qui a été dit dans la partie précédente, il vaut mieux choisir des métriques simples et techniques au main de l’équipe de développement, et juger de la création de valeur à travers de la boucle client. Le livre donne quelques exemples très pertinents d’arrêt de projets au mauvais moment (une fois que le pire est passé) parce que les parties prenantes souffrent de « l’illusion du contrôle » et préfèrent utiliser des KPI plutôt que faire confiance.


5. Autonomie des équipes et pair -programming 

On retrouve, de façon symétrique et sans surprise, de nombreux arguments sur l’importance du travail en équipe, organisées de façon cross-fonctionnelle et autonome (ce qui va de pair). Le travail en équipe commence par le binôme et les auteurs citent de nombreuses expérience réussies de pair-programming, dans la tradition de l’extreme programming. Je vous renvoie à l’incontournable livre de Rich Sheridan sur ce sujet.  Faire du code un objet collaboratif de communication – à travers les code reviews ou le debugging partagé – est une des bonnes pratiques de l’informatique moderne. Les auteurs citent Gerald Weinberg qui « observa que dans les boites ou les programmeurs ne marquent pas le territoire de leur code et encourage les autres à y chercher les bogues et les améliorations potentielles, les améliorations sont drastiquement plus rapide qu’ailleurs ». C’est d’ailleurs ce qui fait tout l’intêret de l’open-source, à la fois en tant que source de code et que pratique communautaire. Je vous recommande en particulier le témoignage page 56 que je cite partiellement :  « Chaque équipe travaille sur ses sujets mais cela n’empêche pas de se parler : ceux qui décident font et vice-versa. Il n’y a pas des couches de management qui décident en amont de ceux qui font. Il y a des managers humains plutôt que des managers projets ».  On ne peut que souligner le principe de « ceux qui décident font et vice-versa », fil rouge de mes billets de blogs et des livres que je commente depuis 10 ans. Le livre souligne d’ailleurs que les nouvelles méthodes de développement logicielle contribuent au renouveau de l’organisation du travail : « le point capital dans l’agilité, c’est de raccourcir la boucle de feedback, et à tous les niveaux ».

 4. Conclusion


Pour conclure, voici ce qui me semble essentiel en matière de transformation numérique, à la lumière des doubles cultures du développement logiciel et de l’amélioration continue en boucle centrée sur le client. Je le résume en quatre affirmations :
  1. La transformation numérique n’est pas un objectif en soi. C’est une composante nécessaire d’une transformation nécessaire pour mieux – ou continuer à bien – servir ses clients. La transformation est dictée par le changement externe (des attentes, des usages, de ce qui est possible). C’est pour cela que j’utilise souvent le terme d’homéostasie qui est une formulation abstraite de la vision d’Henri de Castries pour AXA lors que j’ai eu le plaisir de l’écouter en 2014.

  2. La transformation numérique est une course – à cause de l’hyper compétition. Toute entreprise fait de toute façon sa transformation numérique, la question c’est à quelle vitesse ? Reprenons la définition de Ludovic Cinquin « La transformation numérique c’est l’exploitation radicale des possibilités d’Internet ». Le défi n’est pas simplement d’y arriver, c’est d’y arriver mieux et plus vite que ses concurrents, les anciens comme les modernes. Comme disent les américains, « Time is of the essense ». 

  3.  La transformation est émergente : elle se pilote en laissant une organisation responsabilisée et autonome développer son potentiel de situation, guidée par une finalité simple et claire. Réussir sa transformation c’est construire des nouvelles capacités et les « libérer » : leur donner le moyen d’agir – c’est tout l’intérêt du livre de Cecil Dijoux. Pour reprendre les idées du billet précédent, « rien ne sert de courir, il faut partir à point »
  4. Jardiner l’émergence est un mélange de culture et de pratique – dans lequel on retrouve cette double racine de la culture logicielle moderne (je continue à citer « Les géants du web » mais le temps passe vite et les paradigmes clés de 2017 pour réussir l’ambition DevOps ont déjà évolué) et des pratiques d’amélioration et d’apprentissage continu qui font la quintessence du Lean Management