vendredi, novembre 30, 2018

Comment promouvoir l’informatique Lean et Agile face à la complexité et à l’inertie ?


1.     
Introduction



Nous vivons une période paradoxale de montée en force de l’approche agile et d’une dénaturation progressive des termes et des idéaux du manifeste agile . On retrouve le terme « agile » partout depuis 10 ans dans la littérature sur le management, dans toutes les déclarations stratégiques des entreprises et dans les principes modernes d’organisation. Dans son article « The State of Agile Software », Martin Fowler dresse un réquisitoire éclairant contre le « faux-agile », que je trouve remarquablement pertinent.  Pour résumer, le « faux agile » est un abus de procédures  et d’outils (baptisés le « complexe industriel ») conduisant  à un abus de structuration et d’organisation au détriment de l’autonomie des équipes. Les processus de développements deviennent fixes et universels, alors qu’ils devraient s’adapter et évoluer en continu.  La compétence technique passe au second plan, alors qu’elle est essentielle dans l’approche agile, et la culture projet reste prédominante au lieu d’évoluer vers une approche produit.

Au fur et à mesure que l’approche agile est devenue « incontournable », elle s’est vue souvent mariée à l’approche « lean ». Lean et agile sont à la fois proches et complémentaires : ils sont très compatibles car construits sur des principes « souches » communs et ils s’enrichissent car ils ne répondent pas aux mêmes questions. Il y a eu de nombreux débats il y a dix ans sur le positionnement relatif, lorsque le « lean software » a commencé à être formalisé, mais aujourd’hui la plupart des organisations revendiquent la double influence. Ce mouvement s’est accéléré avec la montée en visibilité de DevOps  et de l’approche CICD (Continuous Integration and Continuous Delivery), qui sont clairement sous la double influence du lean et de l’agile. Grace aux travaux de Nicole Forsgreen et Jez Humble, dont l’excellent livre « Accelerate », nous avons maintenant les preuves d’efficacité de ces approches « lean / agile » du développement logiciel.   
         
L’approche « Lean Software », telle que magistralement popularisée par les livres de Mary et Tom Poppendieck  est une évolution logique, et une approche complémentaire, qui renforce une démarche agile. Par exemple, on y retrouve des éléments clés qui sont prônés par Martin Fowler dans l’article précédent : l’importance du refactoring continu, l’importance du développement continu des compétences ou l’approche produit. Mais la double mise en œuvre des principes, des rituels, des pratiques lean et agile n’est pas simple et pas forcément intuitive. Il s’agit d’une démarche de transformation émergente, ce qui signifie que sa mise en œuvre est entre les mains des acteurs, par opposition à une approche volontariste et descendante. Tout n’est pas non plus simplement entre les mains des équipes, l’environnement joue également un rôle critique dans la faisabilité de la mise en place.

Ce qui m’intéresse précisément dans ce billet est la complexité et la difficulté de mise en œuvre d’une approche véritablement lean et agile dans une organisation de développement. Je vais chercher à caractériser les conditions nécessaires pour faire émerger cette transformation. Il faut en premier supprimer les contraintes qui bloquent cette émergence parce qu’elles invalident les principes lean et agiles. L’autonomie, les marges de manœuvres, la flexibilité et l’accès continu à la boucle de feedback sont nécessaires pour que la transformation lean et agile puisse commencer. Pour que cette transformation émergente progresse et devienne systématique, la gouvernance doit aussi évoluer : ce qui est mesuré et ce qui est apprécié doit changer par rapport à la conduite standard des projets telle qu’on la pratiquait il y a 20 ans.
Ce billet est organisé comme suit. La section 2 revient sur ce que le lean peut ajouter à l’agile, même si ce thème est maintenant un peu éculé. Je n’ai pas la prétention de couvrir le sujet ici – cela demanderait plus de place et plus de compétences – mais simplement de faire quelques rappels et poser les concepts nécessaires pour la suite de mon propos. La section 3 considère l’entreprise comme un système et se pose la question des conditions nécessaires pour que la transformation lean et  agile puisse s’accomplir. Certains aspects tels que la « customer centricity » sont maintenant bien compris –même si cela reste une démarche difficile  -, d’autres comme l’acceptation de l’incertitude restent plus difficiles. La dernière section rassemble quelques conseils sur les modes de pilotage – comment mesurer et évaluer les résultats. Sans surprise, il existe une synergie entre des nouveaux modes d’organisation – ce que j’ai appelé l’entreprise 3.0 dans des billets précédents  – et les nouvelles approches de développement de produits logiciels ou numériques.

2.  Ajouter des racines Lean à la pratique agile


Je commence tout de suite par poser mon parti pris : lorsque je parle de « lean agile », je m’intéresse à l’enrichissement de la méthode agile par des principes, des méthodes et des rituels tirés du lean. C’est parce que je considère le « lean management » comme une approche plus fondamentale et plus générale, qui s’applique à un processus, tandis que l’agile est plutôt  une modalité de fabrication d’un artefact (logiciel, projet ou produit, mais ceci se généralise à d’autres développements).

Ce n’est pas la première fois que j’aborde ce sujet dans mes blogs. Le premier billet date de 2012, il était fortement inspiré par la lecture de Mary and Tom Poppendieck. Ce billet est construit autour d’un enrichissement progressif des principes, en partant du manifeste agile pour l’enrichir avec des principes lean. J’ai également abordé la combinaison lean et agile en 2016 en l’observant du point de vue métier. Dans ce billet, je décris (sommairement) l’Agile de la façon suivante : «  La satisfaction du client est le fondement d’une démarche de développement produit. Ceux qui construisent (un produit, un service, une expérience) doivent être responsables du processus de construction. La communication personnelle, face à face, est le ciment de la méthode agile. Les rituels d’équipes utilisent les tableaux et les murs pour favoriser la communication. Les défis complexes requièrent des équipes cross-fonctionnelles qui travaillent ensemble, de façon synchronisée et itérative. » De façon symétrique, le lean me semble caractérisé de la façon suivante : « La satisfaction du client/utilisateur est la fondation d’une démarche lean, c’est le but commun à toutes les équipes. L’approche « pull », dirigée par la demande client, donne le tempo commun à l’ensemble de l’organisation. Elle est matérialisé par le kanban, et suppose une simplification et une fluidification du processus, c’est un objectif de long terme. Les équipes progressent et capitalisent grâce à une standardisation de leurs pratiques. Le kaizen est un outil pour apprendre à travailler ensemble via la résolution de problèmes. Le lean est une méthode pour l’apprentissage collectif de la complexité. C’est pour cela qu’il repose sur le management visuel, sur l’inspection en équipe de la réalité et qu’il se méfie de l’abstraction (cf. le genchi gembutsu). »

L’influence du Lean dans le monde digital est devenue de plus en plus visible au cours de la dernière décennie. Cette observation était déjà bien visible dans le livre de référence « Les Géants du Web ». Mais avec DevOps, avec le développement du Lean Startup  les emprunts au lean management « façon Toyota Way » sont particulièrement saillants.  Je vous recommande par exemple la lecture du billet de César Gon, le CEO de CI&T dans « planet lean » intitulé « With digital lean finally reaches CEOs ».  J’ai également fortement insisté sur les principes lean présents dans le livre « Accelerate » précédemment cité. Cette intensification des racines lean dans le développement digital permet de souligner trois apports essentiels par rapport aux pratiques agiles :
  • Le lean conduit à développer l’anticipation en pensant sur une échelle de temps plus longue, celle de la construction de compétences. Ceci ne signifie pas développer des choses inutiles en cherchant à prévoir le futur mais bien à réfléchir à son potentiel de situation, avec une véritable démarche d’architecture. Je vous renvoie ici à mon billet sur « Lean Architects – Do we need abstraction ?». Cet apport de l’approche lean à l’architecture dans les développements agiles est le sujet du livre de de James Coplien and Gertrud Bjørnvig « Lean Architecture for Agile Software Development ».
  • Le lean développe la pensée systémique, ou plus précisément l’apprentissage collectif du fonctionnement du système et sa capitalisation sous forme visuelle. Je vous renvoie ici au livre magistral de Michael Balle, « The Lean Manager». Pour prendre un exemple différent et plus proche du logiciel, je vous recommande les interventions de Paul Allspaw dans lesquelles il enseigne de « rendre les problèmes visibles », dans la plus pure tradition lean.
  • La puissance du kaizen comme démarche d’amélioration et d’apprentissage continu va bien plus loin que les pratiques de rétrospectives et de résolution de problèmes propres aux démarches agiles.

Un thème commun aux trois apports du lean que je viens de mentionner est la maitrise de la complexité. C’est particulièrement important avec les méthodes agiles puisque l’approche incrémentale produit de la complexité (c’est pour cela que Martin Fowler insiste sur le refactoring).  Le lean dispose de plusieurs outils propres pour lutter contre la complexité. Premièrement le value stream mapping (l’obsession de la valeur crée pour le client) et son complémentaire, l’élimination des muda, mura and muri  est une combinaison vertueuse pour alléger de façon continue et simplifier. Deuxièmement, la construction et la pratique du standard – propre à chaque équipe, comme l’explique très bien Martin Fowler, et comme me le répète Michael Ballé – est également un outil de prévention de la complexité. L’utilisation du standard est un filtre qui, combiné à la pratique du kaizen dont il est l’outil de capitalisation, produit de la simplification. Notons pour terminer, en écho à l’article de Martin Fowler, que les experts du lean qui ont beaucoup pratiqué sont suprêmement modestes dans leurs conseils sur les rituels et les outils. Lorsque nous avons commencé à développer l’approche du Lean Software Factory à Bouygues Telecom en 2012, mon sensei m’a forcé à me limiter à quatre pratiques : Team problem solving, Project Room, Reduce WIP & Love your code. 

Mon tropisme personnel pour la fiabilité des systèmes me pousse à voir dans le lean un apport fondamental aux méthodes agiles dans le domaine du « system engineering ». S’il est vrai que dans certains cas, en particulier dans le domaine des interfaces utilisateur, il vaut mieux coder et itérer plutôt que de chercher une spécification parfaite et abstraite, il existe également des situations inverses. Ayant commencé ma vie logicielle en programmant des compilateurs, j’ai à l’esprit des multiples exemples un peu anciens, mais mes dix dernières années d’expérience de conception de services fournissent également des situations où les problèmes de conception se résolvent à l’avance avec un tableau, des feutres, des schémas et des équations. Dans ces situations, le principe lean de détection de la non-qualité au plus tôt passe par l’abstraction et la formalisation, plutôt que l’expérimentation qui est très coûteuse. Je ne recommande pas de résoudre des équilibrages de files d’attente par essai/erreur, comme le montre le célèbre exemple du Beer Game.

Je ne suis pas forcément très satisfait de ma caractérisation de la combinaison lean+agile (c’est effectivement un sujet complexe), mais l’expérience m’a montré qu’il était facile de voir si cette transformation combinée avait « pris » de façon efficace en regardant trois critères. Lorsque ces trois pratiques sont présentes sur un plateau de développement, c’est en général un très bon signe d’appropriation en profondeur qui est corrélé avec d’excellents résultats (en termes de satisfaction client, bien sûr) :
  • La « voix du client » est présente sur le plateau de développement, sous la forme de témoignages rassemblés et de métriques détaillées d’usage. Je vous renvoie par exemple à la pratique du Customer Feedback Learning Loop.
  •  Le visual management fait la part belle à des schémas systémiques qui expliquent le fonctionnement du produit en cours de fabrication. Je vous recommande à ce sujet le billet « arrêtons de confondre le management visuel et le reporting au mur » de Catherine Chabiron.
  • Le suivi des plans d’action issus du kaizen est matérialisé par un document du type A3 de Toyota, dont la vie (des ratures jusqu’aux mises à jour régulières) témoignent de l’utilisation réelle.


3. Les conditions systémiques du Lean & Agile



La première chose évidente que je souhaite souligner c’est qu’il est impossible à une organisation de développement d’être « agile toute seule ». Paradoxalement, on peut appliquer le lean à petite échelle et en réaction isolée par rapport à son environnement (penser au self-lean). Cela marche moins bien, mais ça marche quand même. On peut également appliquer l’approche lean à des cycles non-agiles : on peut faire du « lean waterfall » et du « lean CMMi ». A contrario, pour tirer les bénéfices systémiques de la démarche agile d’adaptation continue et itérative vers une cible incertaine, c’est le système entier qui doit comprendre les fondamentaux : nous vivons dans un monde marqué par la variabilité et l’incertitude, où l’action prime sur l’idée et dans lequel la vitesse de changement s’accélère par rapport aux décennies précédentes. Par système entier, je pense aux parties prenantes principales : les directions métiers, la direction générale, les utilisateurs. L’importance de l’adhésion globale aux principes agiles n’est pas une nouveauté : si on lit le manifeste agile attentivement, il est clair que ce n’est pas simplement une histoire d’informaticien mais de collaboration entre parties prenantes. On pourrait même dire que le premier prérequis pour fonctionner de façon agile, c’est l’envie. La gouvernance et les règles dont nous allons parler ensuite ne sont que des conséquences.

Pour que les équipes s’approprie des modes de fonctionnement lean et agile, il faut qu’elles disposent de marges de manœuvre. Je retrouve ici ma citation favorite d’Yves Morieux « Coopérer, c’est mettre ses marges de manœuvres au service des autres » et des idées que j’ai développées dans mon livre en 2010  et qui sont magistralement exposée par Reinertsen dans « The Principles of Product Development Flow». Le fonctionnement lean évite les taux de charge de 100% qui conduisent inexorablement à une amplification des aléas. Cette règle est d’autant plus importante que l’incertitude propre aux domaines complexes et digitaux produit du stress chez les parties prenantes, qui se traduit à la fois par le fait d’être pressé et velléitaire, ce qui produit alors une surcharge par rapport à la capacité de l’équipe et qui conduit à la fois à l’inefficacité et la conclusion fausse que les méthodes agiles ne fonctionnent pas vraiment. Fonctionner de façon lean demande donc une certaine maturité sur sa propre capacité, pour ménager de façon continue et durable les marges de manœuvre qui vont permettre d’absorber les aléas et de progresser de façon continue. Tout ce qui permet d’apprendre et de progresser, depuis la formation à la rétrospective en passant par le kaizen réclame un mode de fonctionnement « non-saturé ». Ce « buffer » doit être piloté et utilisé par l’équipe, puisque c’est elle qui conduit sa transformation lean & agile et prend en charge son amélioration continue. De plus, une équipe qui fonctionne en surcharge devient autiste (cf. Yves Morieux), elle n’écoute plus ses clients et coupe sa boucle d’adaptation, produisant in fine moins de satisfaction client et donc moins de valeur.


Pour fonctionner efficacement en mode lean & agile, il faut pouvoir mesurer la valeur créée en continu et dès que possible, afin de profiter de la force systémique de la rétroaction en boucle courte. Cela suppose deux choses : d’une part un accès régulier et simple aux utilisateurs pour collecter ce feedback le plus tôt possible , et d’autre part la véritable délégation de responsabilité qui fait que le product owner – membre de l’équipe – est habilité à tirer les conséquences de ce feedback, sans avoir à attendre la validation d’un comité d’hippos.  On retrouve ici le rôle fondamental de l’autonomie et la responsabilisation (empowermentde la  « squad agile » Dès que le projet ou produit atteint une certaine taille et qu’il est nécessaire de faire collaborer plusieurs squads, il est fondamental d’aligner toute l’organisation sur la satisfaction du client pour optimiser l’expérience utilisateur. Cette obsession de la satisfaction client a le grand avantage d’être mesurable (et donc relativement objective), de donner du sens et de fédérer les énergies grâce à l’empathie dont nous sommes tous dotés.  C’est la raison, fondée sur mon expérience, pour laquelle je considère que la présence de la « voix du client » est fondamentale sur les plateaux de développement. Cette obsession de la satisfaction client explique également le rôle fondamental des designers dans les squads.

Une démarche agile permet de mieux gérer les surprises, les bonnes comme les mauvaises découvertes au cours du développement, mais encore faut-il les accepter. Comme le remarque Philippe Silberzahn, l’agilité est un moyen. Dans l’esprit de l’effectuation, il faut savoir accepter l’incertitude et les surprises (ce qui matérialise l’incertitude : s’il n’y avait pas de surprise il n’y aurait pas d’incertitude) - je vous renvoie ici au livre de Philippe Silberzahn « Bienvenue en incertitude » - et c’est bien entendu l’affaire de tous. L’agilité n’est pas une technique pour absorber les incertitudes du développement logiciel pour les masquer au métier. Plus généralement, cette solidarité des parties prenantes  est nécessaire parce que le fonctionnement agile n’est pas « un long fleuve tranquille » et demande plus d’engagement de la part des équipes que le mode « bureaucratique » des organisations Taylorisées de type « waterfall ». Essayons de l’illustrer en comparant deux méthodes de travail. La première est une méthode d’agence, qui est fondée sur l’encapsulation des objectifs et activité, cherche à masquer la complexité, fonctionne avec des échanges asynchrones, une priorisation établie par le donneur d’ordre (le métier), une vision statique et absolue de la « voix du client ». La seconde est une méthode de partenariat, qui suppose la transparence, l’exposition de la complexité, qui exige des échanges synchrones, donne à l’équipe qui fait la capacité de prioriser et considérer la « voix du client » comme une conversation dynamique. Les sociologues nous ont appris que la deuxième méthode est plus engageante, donc plus fatigante. On parle souvent du « droit à l’erreur » nécessaire dans les environnements complexes, ce n’est pas simplement parce que se tromper permet d’apprendre ! C’est parce que le refus de l’erreur conduit à des méthodes du premier type, qui favorisent des solutions médiocres qui évitent les risques, et produisent alors une satisfaction client médiocre.

4. Gouvernance Lean & Agile : Pratiquer le « lâcher prise » sans dériver ni abdiquer


L’émergence des modes de travail lean et agile passe par une évolution de la gouvernance des projets et processus de développement. Avant de donner cinq illustrations concrètes, je rappelle que ce thème est également développé dans le livre de Jurgen Appelo « Management 3.0 – Leading Agile Deloppers, Developing Agile Leaders ». Je reprends de mon compte-rendu précédent les deux citations suivantes qui résument bien le propos : « One of the things I learned in this past decade is that Agile Software development is the best way to develop software. But I’ve also learned that old-style management is the biggest obstacle to the adoption of Agile software development around the world” ; “The real reason for empowerment is the manageability of the complex system itself. Smart managers don’t just empower people to enjoy the radiant faces of employees. They empower people to prevent the whole system to break down”.

La première idée importante pour la gouvernance est qu’il est nécessaire de combiner le temps court et le temps long. L’agilité, d’un point de vue stratégique, s’exprime sur le temps court, mais elle se prépare sur le temps long. L’introduction d’une perspective lean permet de mieux comprendre ce paradoxe et d’apprécier les différents rythmes d’apprentissage. La pratique de l’anticipation et de la planification ne sont pas forcément obsolètes, mais elle s’applique à la construction du « potentiel de situation », des « capacités » (capabilities) communes. Cette activité de temps long peut être centralisée et planifiée car il y a finalement peu d’incertitude. En revanche, la réalisation de l’opportunité exige le temps court, celui de la réaction et de la délégation. Comme les opportunités ne se prévoient pas (ou mal), le domaine d’exercice de l’agilité n’est pas celui de la planification. C’est aussi pour cela que l’injonction « fail fast » s’applique au cycle court de saisie de l’opportunité et elle n’exclue pas la persévérance dans la construction des capacités.

La deuxième règle de gouvernance est de pratiquer une véritable distribution du pouvoir de décision vers des équipes autonomes. C’est une des idées forces de Jurgen Appelo dans son livre, qu’il relie très justement à la complexité des situations – c’est bien entendu un des six principes de l’entreprise 3.0 que je développe dans ce blog. Cette organisation en réseau d’équipes distribuées et autonome, maillées par des organisations transverses (chapitres et guildes) qui favorisent l’apprentissage sur des échelles de temps différents est ce qui a rendu le modèle Spotify célèbre dans le monde agile. Mais on pourrait tout aussi bien ici invoquer les principes du Betacodex qui reposent précisément sur l’adéquation entre un modèle distribué « biologique » et la complexité de l’environnement. La responsabilisation n’est pas une décision, c’est la conséquence d’un certain nombre de prérequis de gouvernance : l’autonomie, l’accès aux moyens et l’orientation vers le client en particulier et l’extérieur en général.

Une troisième observation essentielle sur notre environnement complexe, qui est fondamentale lorsque l’on parle de transformation numérique, est qu’il faut laisser le client choisir l’écosystème logiciel dans lequel l’entreprise va apporter sa valeur. C’est vrai dans le grand-public, puisque les écosystèmes de services dominants sont imposés par quelques grands acteurs et qu’il convient d’aller à la rencontre des utilisateurs là où ils se trouvent. C’est également vrai dans le monde B2B, dans lequel les entreprises clientes construisent leurs propres plateformes par agrégation et orchestration de service (avec une accélération liée au Cloud, au SaaS et au XaaS). Ce n’est pas une coïncidence si les notions d’exposition de services et d’API jouent aujourd’hui un rôle clé dans le développement. L’histoire des APIs permet d’apprécier cette forme de « lâcher prise » qui consiste à laisser d’autres écosystèmes, externes à l’entreprise (ceux d’une entreprise cliente en B2B), prendre la responsabilité de la composition, et de l’expérience utilisateur, des services fournis par cette entreprise. Cette observation a une conséquence essentielle sur la gouvernance : il faut associer aux décisions ceux dans l’entreprise qui connaissent les écosystèmes logiciels. Autrement dit, la technologie n’est pas un élément de l’exécution, mais une compétence stratégique.

La gouvernance des projets et produits développés de façon lean et agile doit d’adapter au rythme rapide et incrémental qui est nécessaire pour créer plus de valeur. La fréquence des échanges et des décisions doit augmenter, et les parties prenantes doivent le plus possible adopter les modes de travail des équipes : une chose à la fois, communiquer de façon synchrone, se déplacer là où l’action se passe (le célèbre « genchi genbutsu » du lean). Cette contrainte n’est pas simple et conduit forcément à la délégation et l’autonomie. En effet, comme je l’ai remarqué dans un billet précédent, le produit du temps passé par sujet, du nombre de sujets traité par une personne et du taux de compression (du niveau d’abstraction auquel ce sujet est traité) est plus ou moins constant. Cela force les managers dont le « scope » augmente à choisir entre plus d’abstraction (au risque de ne comprendre que superficiellement) ou une fréquence faible (ce qui ralentit la pertinence du processus adaptatif de la démarche agile). On en déduit que dans un monde complexe (qui rend l’abstraction difficile et dangereuse), moins un manager passe de temps sur un sujet, plus il doit rester humble et réduire sa voix dans le processus de décision.

La cinquième conséquence sur la gouvernance est également inspirée des principes de l’entreprise 3.0 : « L’entreprise doit disposer d’une vision unique, comprise et partagée par tous, distribué à tous les composants de l’entreprise. Une finalité unique, que chacun décline localement en fonction de son contexte et ses moyens, en vertu du principe d’holomorphisme des systèmes complexes ». Pour pouvoir faire fonctionner efficacement un réseau distribué d’équipes autonomes, il faut une stratégie exprimée en termes de finalité (le fameux « start with why »). Sur l’importance de cette finalité claire, je vous renvoie à l’excellent livre de Cecil Dijoux « Ce que signifie l’avènement du numérique ». Dans le monde logiciel, on parle de programme « déclaratif » par opposition à « impératif ». Comme le souligne Isaac Getz, « l’autonomie sans vision partagée, c’est le chaos ».

5. Conclusion

Ce billet est, sous une forme détournée, une réflexion sur trois de mes thèmes préférés :
  • La mise en place des « usines logicielles » autour de Dev0ps, telles que décrites dans « Accelerate ». Depuis 10 ans, je revendique le terme d’usine car il est pour moi porteur de rigueur, d’effort et d’outillage (par opposition au « mindset » et aux « soft skills »), rencontrant de temps à autre une certaine résistance. Les dernières années et les derniers témoignages des acteurs que j’admire semblent me donner raison.
  • Le « Software craftmanship », c’est-à-dire la reconnaissance et le développement (conjoint) de l’expertise technique dans le développement logiciel. C’est pour moi la racine « extreme programming » de l’approche lean agile. On peut invoquer le « dieu de la transformation digitale » autant de fois qu’on le souhaite chaque jour, sans « l’amour du code », il est difficile d’être compétitifs face aux acteurs innovants du 21e siècle.
  • Le pilotage des transformations émergentes, autrement dit l’efficacité au sens de François Jullien.

Ces trois dimensions se combinent pour tisser un lien entre les nouvelles formes d’organisations et l’efficacité des processus de développement numérique. Il y a un lien fort entre ce qui est dit dans ce billet et celui sur l’Entreprise 3.0 qui est, de beaucoup, l’article le plus consulté sur ce blog. Le moment se rapproche où je pourrai mettre mes idées au clair sous la forme d’un nouveau livre, dédié à ces nouvelles formes d’organisations de développement logiciel.







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.