mercredi, septembre 05, 2018

Réinventer les processus et les applications avec l’Intelligence Artificielle




1. Introduction


Le billet de ce jour est tiré de la lecture de l’excellent livre proposé cette année par Accenture, « Human+AI », qui fait écho au livre de Booz-Allen, « The Mathematical Corporation », dont j’ai parlé dans un précédent billet. Même si j’ai déjà beaucoup écrit sur le sujet, la lecture de ce livre m’a permis d’approfondir un certain nombre de points clés :


  • L’Intelligence artificielle est avant tout une technologie d’enrichissement de l’humain. Elle apporte une valeur maximale dans une symbiose homme-machine. 
  • L’IA est portée des applications logicielles, ce n’est pas une nouvelle technologie « hors sol » mais une modalité des systèmes logiciels. 
  • L’IA permet de réinventer la façon dont nous travaillons ; elle permet de revisiter et d’approfondir nos connaissance métier, elle permet d’absorber de la complexité, de la variété et de l’aléas dans nos traitements pour reconstruire des nouveaux processus métier. 
  • L’IA souffre en ce moment d’un cycle de « hype » (mais c’est naturel et classique avec la plupart des technologies du monde informatique) qui rend difficile un jugement calme et lucide. Le chemin de l’utilisation du potentiel de ces approches sera long, car il reste des difficultés multiples, mais la course a déjà commencé. 

J’ai eu la chance de participer à une table ronde lors du précèdent Transform AI à Paris, animé par Paul Daugherty, et je suis frappé par la convergence des points de vue des acteurs de l’IA qui opèrent dans le monde de l’entreprise. Je représentais l’Académie des technologies pour parler de notre rapport sur l’IA et l’apprentissage, et j’ai pu constater que les différents intervenants avaient des points de vue très semblables, qui sont remarquablement synthétisés et illustré dans le livre dont je vais parler aujourd’hui.

Ce billet est organisé comme suit. La section suivante propose un résumé des idées clés de « Human+AI ». Je me suis concentré sur les idées essentielles et j’ai eu du mal à en sélectionner moins de 10, parce que ce livre est très riche bien qu’il soit court. La section 3 revient sur certains de ces points que j’avais évoqué brièvement dans des billets précédents pour les approfondir. Cette section porte sur la construction de systèmes intelligents qui utilisent différentes capacités tirées de l’IA. Je conclurai brièvement sur ce que l’analyse contenue dans ce livre nous enseigne par rapport à certaines questions du rapport Villani.


2. « Réinventer le travail à l’age de l’Intelligence Artificielle »




Le titre de cette section est le sous-titre du livre de Paul R. Daugherty et H. James Wilson, « Human + Machine – Reimagining Work in the Age of AI ». Cet excellent livre comporte deux parties, la première fait le point sur l’utilisation de l’IA aujourd’hui et la seconde porte sur la réinvention des processus avec l’IA. Je recommande chaleureusement la lecture du livre, et en particulier je considère la lecture de cette première partie comme obligatoire pour tout manager dans une entreprise. Ce livre combine trois qualités remarquable : il est très bien écrit et facile à lire, ses analyses sur l’utilisation de l’IA aujourd’hui, sur ce qui marche et pourquoi, sont superbement pertinentes et, pour finir, il est illustré de nombreux exemples. Selon mon habitude, je vais me contenter de relever ici quelques idées clés de ce livre, je vous laisse le lire pour comprendre en détails les exemples qui illustrent ces idées.



  1. L’intelligence artificielle est un système d’apprentissage avec « des humains à l’intérieur ». La symbiose humains et IA est la marque de fabrique du livre, à la fois les humains qui fabriquent l’IA et ceux qui l’utilisent. Les auteurs définissent l’IA comme des “systèmes qui étendent les capacités humaines en détectant, comprenant, agissant et apprenant ». L’idée que la combinaison « homme plus IA” est supérieure à l’homme ou la machine seule n’est pas nouvelle (exemple des tournois d’échec), mais on trouve ici des exemples industriels : “In a MIT study … researchers determined that human-robot interactions in the car plant were about 85% more productive than either humans or robots on their own ». Le livre cite aussi des exemples ou les deux rôles humains sont combines : dans une banque, les professionnels qui utilisent les systèmes d’assistance intelligent participent également à leur développement et apprentissage.

  2. L’intelligence artificielle n’est pas un enjeu de demain : les technologies d’aujourd’hui apportent déjà des bénéfices et des opportunités de transformation aux entreprises qui les utilisent. Les exemples abondent, depuis l’utilisation d’assistants intelligents pour assister les vendeurs, les outils d’analyse pour marketeurs (lire le témoignage de Marc Benioff qui utilise Einstein pour prédire les ventes chez Salesforce) ou l’exemple spectaculaire de Capital One, une banque qui s’est réinventée par sa stratégie logicielle. Dans un contexte plus industriel, l’exemple de Rio Tinto (mining) qui utilise l’IA pour le contrôle et l’optimisation de sa flotte d’engins est remarquable dans sa diversité de l’utilisation des données pour optimiser des aspects multiples du cycle de vie des engins. Une remarque fondamentale de cet ouvrage est que l’IA est un absorbeur de complexité : elle permet de réintroduire de la flexibilité et de l’adaptabilité des processus métiers devenus trop complexes. Les auteurs parlent d’une troisième « vague », après celle de l’automatisation, celle de l’adaptabilité : « the third wave has created a huge, dynamic, and diverse space in which humans and machine collaborate to attain orders-of-magnitudes increases in business performance ».

  3. Tirer parti de l’Intelligence Artificielle nécessite une profonde transformation culturelle, dans la continuité de la transformation digitale. Les auteurs proposent l’acronyme MELDS (Mindset, Experimentation, Learning, Data, Skills) pour synthétiser les différentes composantes de cette transformation : « Based on our observations of companies at the forefront of implementing advanced AI technologies, we have uncovered five key management practices”. Je ne vais pas détailler ces 5 pratiques, on retrouve ces idées dans le rapport de l’Académie des technologies. Je voudrai juste souligner l’importance des deux premières : « mindset », qui est rattachée à l’envie nécessaire et à la conviction que la technologie permet une réinvention complète des processus métiers, et « experimentation » qui de façon duale exprime le « lâcher prise » nécessaire du management de l’entreprise pour piloter un processus d’innovation émergent. Notons également que « The lesson here is that identifying opportunities for re-imagination takes time – executives must capture the current business context, distill insights from various observations, and identify the potential value impact of the reimagined process”. Une autre citation sur le même theme: “These firms … recognise that AI is not your typical capital investment; its value actually increases over time and it, in turn, improves the value of people as well”.

  4. La mise en œuvre de l’Intelligence Artificielle suit une courbe d’expérience, la durée est nécessaire pour comprendre et s’approprier ce qui est possible à un moment donné. Même si certains exemples mentionnés sont sophistiqués, il faut commencer de façon simple: « Don’t be intimidated by the scale of the data that you encounter. Focus on simple AI challenges first and move on from here ». Cette progression dans le cycle d’expérience est accompagnée par l’utilisation de technique de visualisation (parce que voir aide à comprendre – cf l’approche de MondoBrain) et de développement de méthodes d’explications, en particulier lorsque des algorithmes « boites noires » sont employés. L’exemple de LIME (Local Interpretable Model-agnostic Explanation) est une bonne illustration : « LIME doesn’t care about the actual AI algorithms used. … To perform an autopsy of any result, it makes slight changes to the input variation and observes how they alter that decision”. Cette approche est emblématique d’une vision systémique et évolutionnaire du développement des systèmes intelligents que j’ai déjà mentionné plusieurs fois, y compris lorsque je parle de GTES.

  5. L’Intelligence Artificielle est un riche ensemble de méthodes qui sont le plus souvent utilisés de façon hybride. Les exemples de la section “Moving well beyond RPA” sont illustratifs de la possibilité d’enrichir des assistants intelligents avec des briques multiples, depuis des méthodes de NLP jusqu’à de l’apprentissage profond. Le développement de Google Duplex est un bon exemple, celui de Virgin Trains proposé dans le livre est aussi très intéressant, tout comme SparkCognition : « a product called Deep Armor, which uses a combination of AI techniques including neural networks, heuristics, data science and natural-language processing to detect threats never seen before ». L’utilisation des approches « génératives » est une autre forme d’hybridation, consistant à mélanger une IA de résolution avec une IA de génération de problèmes aléatoires, avec des exemples enthousiastes fournis par Autodesk : « these techniques are not a threat, they are more like superpowers ». On trouve dans le livre d’autres exemples d’IA évolutionnaire, comme chez Airbus. Cette notion d’hybridation se retrouve bien sûr dans les robots qui sont des concentrés d’intégration de fonctions cognitives : vision / perception / prévision / adaptation / réflexion. Alain Berthoz souligne fort justement dans ses conférences que la prévision de son environnement est une des premières caractéristiques de l’intelligence biologique dans les systèmes vivants.

  6. La mise en place d’applications enrichies par l’IA doit être vue de façon systémique comme une boucle. Cette notion qui a été fortement développée dans les communications de l’Académie des technologies trouve également sa place dans ce livre : « Note that AI feedback loops create dynamic, virtuous cycles of learning and development”. La notion de boucle commence bien sûr avec le principe même de l’apprentissage automatique, mais s’étend avec le cycle itératif du développement du système intelligent (et émergent – cf. Kevin Kelly) pour terminer dans la boucle de coopération entre l’humain utilisateur et l’assistant-machine. L’exemple d’ordonnancement intelligent (car adaptatif de façon continue) de Percolata au Japon illustre la puissance de la combinaison d’une vision de boucle systémique et d’optimisation de la machine.

  7. L’Intelligence Artificielle n’est pas une technologie isolée, c’est une modalité des systèmes logiciels. Le livre illustre avec des schémas très clairs le fait que les capacités de l’IA, dont les différentes formes d’apprentissage automatique, sont portées par des applications logicielles. Cette liste de capacités est complète et contient l’optimisation locale, les systèmes déductifs, la représentation de connaissance, les méthodes prédictives, la reconnaissance de sons, de texte, d’images, etc. L’importance des compétences logicielles est illustré par l’exemple de Siemens : « As factories become increasingly high tech, they require more workers with software smarts. Siemens, for instance, has recognized this and plans to hire seven thousand more people by 2020 in positions related to training and using collaborative robotics, software engineering, and computer science”. Les auteurs insistent à juste titre sur l’importance de la vélocité logicielle, à la fois dans la production d’applications qui sont les véhicules de ces nouvelles technologies (pour déployer une stratégie IA, il faut maitriser le mieux possible son parc applicatif et son cycle de production logiciel) et dans la vélocité de traitement des informations. « Some data is fast … time-critical data needs to be accelerated through the supply chain » : une des technologies logicielles importante à maîtriser est celle du traitement des flux (« streams »). On retrouver ici l’importance de l’EDA (event driven architecture).

  8. Les opportunités d’applications de l’IA sont partout dans l’entreprise et doivent être gérées comme un écosystème émergent. Les exemples abondent pour comprendre que les opportunités sont partout dans la chaîne de valeur. L’exemple de GNS Healthcare montre une application spectaculaire en amont : « It was the first time that I know of that machines discovered new medical knowledge … Straight from the data. There was no human involved in this discovery”. L’exemple de Nike qui utilise l’IA pour créer des nouveaux designs de pointes pour ses chaussures d’athlétisme illustre l’approche de méthodes « génératives » évoquées plus haut. Le message qui transparait de tous ces exemples est l’importance de l’expérimentation (cf. MELDS), parce qu’on ne sait pas à l’avance ce qu’on va trouver.

  9. L’Intelligence Artificielle est une opportunité de réinventer le développement de produits. Pour les entreprises, c’est sans nul doute le message le plus important et le plus révolutionnaire. C’est particulièrement clair dans le domaine de la R&D, je reproduis ici une citation longue : « The use of AI in the different stages of R&D – observations, hypothesis generation, experimentation design, and so on – is producing remarkable gains at all levels and in a variety of fields. Discoveries made over the course of a decade are being replicated, within a matter of months, resulting in dramatic time and cost savings. This has led to a fundamental rethinking of how companies manage their R&D activities. » Ce message est disruptif dans le sens où une entreprise qui ne tiendrait pas compte de ces conseils pourrait voir un de ses concurrents, plus faible ou moins compétent, rattraper et inverser son retard en R&D produit parce que sa bonne utilisation de l’IA lui permet de tirer plus de connaissance métier des mêmes expérimentations ou retours d’usage client. D’un point de vue épistémologique (au sens anglo-saxon), l’IA est un accélérateur maïeutique d’acquisition de compétence (sourire). Cette pratique de l’expérimentation est remarquablement expliquée par Jef Bezos pour qui les entreprises qui ne pratiquent pas l’expérimentation et la valorisation des échecs se retrouvent dans des positions très délicates où elles sont obligées de faire de « gros paris » très risqués. Selon les mots des auteurs du livre : « AI is rapidly making inroads in business. Its swift adoption means that questions on both the opportunities and risks are at the forefront of most discussions”.

Pour terminer cette section, et après avoir été extrêmement élogieux en introduction, je dois signaler que j’ai également quelques points de divergence. Même si le rôle du logiciel est souligné, on ne retrouve pas les compétences de software engineering et de déploiement à large échelle de logiciels distribués dans les compétences clés de la deuxième partie, ce qui manque de mon point de vue. Deuxièmement, le machine learning est mis en position centrale, en l’opposant aux algorithmes classiques qu’il faut programmer. Dans la pratique, il faut toujours programmer, d’autant plus qu’on a besoin de construire des systèmes hybrides, je vais y revenir dans la section suivante. Pour finir, la liste des « compétences de demain » de la deuxième partie est intéressante pour la réflexion, mais quelque peu exotique par rapport aux enjeux d’ingénierie qui sont bien réels. Je mentionne ici ces réserves pour mémoire, elles ne changent en rien la très haute opinion que j’ai de ce livre, ni ma forte recommandation de le lire.




3. Construire des Systèmes de systèmes enrichi par l’IA



J’ai présenté plusieurs fois le rapport de l’Académie des technologies, en particulier lors de la soirée « INRIA Business Club », je viens de mettre ma présentation en ligne. Pour ceux qui trouvent que mes schémas sont trop conceptuels, je vous propose l’illustration suivante.





Ce dessin exprime de façon métaphorique et simplifiée les idées essentielles de ma présentation, que l’on vient de voir également dans « Human+AI »

  • La valeur de l’IA est portée par des applications logicielles. Le terreau est la culture logicielle des entreprises. C’est pour cela qu’une partie des conditions de la « transformations digitale » s’appliquent. 
  • La fleur est une métaphore de la croissance progressive. C’est aussi une référence implicite à la persévérance de l’agriculteur. On peut ici faire référence à François Julien et au proverbe chinois : « Ce n’est pas en tirant sur la tige qu’on fait pousser la fleur plus vite ». 
  • Pour faire grandir cette fleur il faut des données, j’aurais pu ajouter « des données qualifiées ». 
  • Pour que les fleurs poussent, il faut avoir confiance dans l’innovation distribuée (des équipes autonomes auxquelles on fait confiance). 
  • On a tout à gagner à profiter de l’écosystème open-source (pour des raisons que j’ai exprimées ici). 
  • Le terme de science dans « data science » ne désigne pas l’abondance de connaissance mais le besoin d’une démarche scientifique « essai/validation/invalidation » et de beaucoup d’humilité car il est facile de se tromper et de prendre des « faux positifs » pour des innovations. 
La notion d’application logicielle enrichie par l’IA est une facilité qui représente le point de vue de l’utilisateur. Dans la réalité c’est bien un système qu’il faut construire. Comme il s’agit d’un système complexe, c’est en fait un système de système qu’il faut construire. C’est vrai de façon globale – un point de vue bien illustré dans les slides que je viens de citer – mais aussi en ce qui concerne la partie algorithmique qui est le plus souvent hybride. A ceux qui citent AlphaGo comme un exemple de la supériorité des réseaux neuronaux profonds par rapport aux techniques plus classiques (nos amis américains parlent de GOFAI : Good Old-Fashioned AI), je recommande vivement la vidéo de Siraj Raval qui vulgarise remarquablement l’approche de Deep Mind. On y voit, entre autres, la combinaison entre trois techniques : l’exploration arborescente (de type GOFAI), la « randomization » (Monte-Carlo Tree Search) et l’utilisation de réseaux neuronaux pour qualifier des positions. C’est un exemple parfait d’approche hybride, on trouvera d’autres exemples dans le rapport de l’Académie des technologies.

AI is a learning loop with embedded humans” : j’ai choisi cette idée pour commencer mon résumé du livre car je la trouve particulièrement puissante. J’ai déjà développé abondamment le rôle de la boucle de développement de système. Il y a un co-développement des systèmes et des données qui favorise les stratégies audacieuses : un système médiocre et des données simplistes permettent de produire des interactions qui enrichissent les données, puis améliorent le système, ce qui conduit à des données plus fines, et ainsi de suite. C’est pour cela qu’un chatbot médiocre est en premier lieu un outil à produire des dialogues qui entraineront une prochaine génération d’assistant intelligent. Le rôle de l’humain (embedded) est multiple, comme cela a été dit dans la section précédente. Le co-développement du « centaure » (du couple agent humain et assistant intelligent) est une aventure formidable de réinvention des métiers, et une course à la création de nouveaux avantages compétitifs. La dimension de « boucle d’amplification » induit des avantages de « premier entrant » qui s’auto-entretiennent. Le « embedded human » est également celui qui aide à collecter, classer et qualifier les données. Le rôle de l’homme est ici fondamental, comme le montrent les exemples des avancées récentes (de la « vision machine » grâce à ImageNet à AlphaGo).


4. Conclusion



On aura compris que le livre « Human + AI » est résolument optimiste sur les possibilités que représente le développement de l’Intelligence Artificielle pour les entreprises. Il convient néanmoins de formuler les trois mises en garde suivantes :
  • Il faut éviter l’aveuglement sur ce qui brille, qui est évidemment favorisé sur les médias. Je vous renvoie au rapport de l’Académie des technologies.
  • La course – il s’agit bien d’une course à cause de la compétition mondiale – pour utiliser le mieux possible ces nouvelles capacités est un marathon, mais elle a déjà commencé. Je partage l’avis de Laurent Alexandre sur le retard de la France. 
  • Il s’agit d’une transformation pour les entreprises qui va souvent conduire )à la réinvention profonde des métiers / le monde va changer (pas avec le hype d’une IA extraordinaire mais avec de l’IA ordinaire et polymorphe qui est tissée au cœur de nos actions)
Je vais maintenant conclure avec des réponses à trois questions que Fabienne Billat m’a posées sur Twitter, qui font écho au débat autour du rapport Villani et des interrogations, également sur Twitter, de Laurent Alexandre.

Quelle stratégie pour construire un environnement européen favorable à l’IA ?
C’est une question très difficile (la critique est tellement plus facile), je ne prétends pas avoir la solution, mais des pistes construites sur une analyse systémique de ce qui bloque :

  • Il faut investir en R&D massivement, y compris dans la R&D amont, et sans savoir à priori quelles seront les technologies et méthodes qui auront le plus grand impact.
  • Il est nécessaire d’alléger la règlementation autour des données. Puisque RGPD est là, il faut introduire des modalités pour assouplir son application et des « zones franches » pour pouvoir expérimenter.
  • Il me semble absolument nécessaire d’investir dans l’enseignement technique de l’ingénierie logicielle, à tous les niveaux.
  • Enfin, il faut promouvoir la culture logicielle en Europe (par exemple, donner ces missions et des moyens supplémentaires aux instituts comme INRIA) de toutes les façons possibles : concours, conférences, ateliers, communication, etc.

Comment mieux former les dirigeants à l’Intelligence Artificielle, ses applications et sa mise en œuvre ? Quels devraient être les objectifs de ces formations ?


Comment éviter les biais dans la constitution des jeux de données ? Cette question est à la fois complexe et technique, je vous renvoie au livre de Cathy O’Neil pour en comprendre l’étendue. Je vois trois pistes :

  • Il faut diversifier les équipes ! dans les différents sens du terme, et en particulier bien sûr du point du vue du genre. Mais il est également critique d’éviter la trop grande homogénéité des parcours éducatifs, des niveaux sociaux-professionnels et des cultures.
  • Il faut s’appuyer sur le rôle de Chief Data Officer et instituer une véritable gouvernance des données, ce qui donne un cadre pour se poser la question des bais, des validations et de effets pervers systémiques que peuvent introduire les boucles que j’ai vantées dans la section précédente.
  • La stratégie « open data » que chaque entreprise devrait construire est une formidable opportunité de se faire aider par la communauté externe pour valider la pertinence scientifique de sa collection de donnée … et d’obtenir des diagnostics et des conseils sur des possibles biais.






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.