dimanche, juillet 30, 2017

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



1. Introduction


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

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

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

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



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


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


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

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

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

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


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

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

4. Lean Startup

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

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

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

6. Importance du temps

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


7. Rôle du management

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

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

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



3. Décoder les développeurs



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

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


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


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



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

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

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


4. Contrôler et mesurer le développement 


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


5. Autonomie des équipes et pair -programming 

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

 4. Conclusion


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

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

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






lundi, mai 08, 2017

"Grec et chinois" : anticipation et agilité




1. Introduction


Le 23 Janvier je suis intervenu à une conférence coorganisée par l’AFIA et le MEDEF sur l’intelligence artificielle. Je me suis appuyé sur les premiers travaux du groupe de travail de l’Académie des technologies pour évoquer l’impact grandissant des progrès de l’Intelligence Artificielle sur les entreprises, en particulier dans le monde de la finance et de l’assurance. Les slides sont disponibles en ligne, la dernière slide de conclusion contient une « Pyramide de Maslow » qui décrit les conditions pour cultiver les possibilités et bénéfices de l’Intelligence Artificielle dans les entreprises. L’objectif du billet de ce jour est d’expliquer ce schéma, qui rassemble beaucoup des idées que je développe dans ce blog.


Le titre de ce billet est bien sûr un clin d’œil au livre de François Jullien, « Conférence sur l’efficacité ». Savoir profiter des progrès constants de l’Intelligence Artificielle relève précisément du « jardinage de l’émergence » qui est le thème du livre, une nouvelle définition de l’efficacité dans un monde complexe, non-linéaire, dans lequel les approches velléitaires et mécanistes ne fonctionnent plus. Sans rentrer dans le détail, rappelons que François Jullien oppose deux modèles de pensée : le modèle grec, dont nous sommes les héritiers, qui construit sa stratégie sur la finalité de façon déductive, sous la forme d’un plan d’action, et le modèle chinois qui définit une stratégie inductive construit un potentiel de situation et laisse les opportunités guider l’action. Le « modèle grec » cherche à imposer sa volonté au monde – et permet de façonner le monde de la sorte. C’est le modèle idéal pour construire des cathédrales et des TGVs. Il repose sur l’hypothèse que nous comprenons le monde et que nous pouvons anticiper ce qui va se passer. Le modèle et le plan y jouent un rôle fondateur. Le « modèle chinois » s’adapte continument à la réalité du monde et ne fait pas les mêmes hypothèses. C’est donc un meilleur modèle pour naviguer dans l’incertain. L’action volontaire est remplacée par une transformation continue. Il ne s’agit pas bien sûr d’opposer de façon binaire ces deux approches mais de savoir les combiner. En particulier, c’est le titre de ce billet, de savoir combiner les bénéfices de l’anticipation et de l’agilité. Dans la grande tradition de l’art militaire de Sun Tzu, c’est parce que qu’on a anticipé pour jardiner son potentiel de situation que l’on peut faire preuve d’agilité et saisir les opportunités. Je ne connais pas de meilleure façon de penser la stratégie des systèmes d’informations.


La thèse de ce billet est simplement qu’il faut penser l’émergence de l’Intelligence Artificielle dans nos entreprises, et donc dans nos systèmes d’informations, dans ce double temps : le temps long de l’anticipation et du jardinage, et le temps court de l’agilité, pour saisir des opportunités qui sont par essence fugaces dans un monde d’hyper-compétition. Cette thèse va être développée en quatre partie. La première porte sur cette opposition entre le temps court et le temps long, sur les pas de François Jullien. La seconde section s’intéresse entre la dualité entre les connaissances et la pratique, ce qui est également essentiel pour comprendre comment profiter de l’Intelligence Artificielle. L’usage de la technologie qui crée de la valeur sur les opportunités est un usage émergent, tiré par la pratique et les outils. Nous allons retrouver les problématiques d’émergence et d’adaptation continue à son environnement (homéostasie) du livre « Exponential Organisations » qui est un autre marqueur de ce blog.  La troisième section porte sur l’« osmose de l’innovation », qui sont les conditions pour que l’entreprise puisse bénéficier du flux continu d’innovation que des partenaires externes peuvent lui apporter. Ce sont les conditions de l’open innovation, particulièrement importante dans les cas de l’Intelligence Artificielle puisque les investissements massifs des GAFA et des venture capitalists dans l’IA font que l’entreprise doit accueillir des idées, compétences et outils externes, bien plus qu’internes. La dernière section appliquera toutes ces idées pour expliquer ma proposition sur ce que sont les conditions nécessaires à la bonne valorisation de l’intelligence artificielle dans les entreprises.

2. Temps court et temps long


Un des aphorismes préférés du monde digital et des startups est « Fail Fast », rendu célèbre par des grandes entreprises de la Silicon Valley. Il est souvent mal compris et utilisé pour justifier qu’il faille abandonner rapidement si un projet ne réussit pas – et cela d’autant plus qu’on fonctionne sur un modèle de pensée grec qui cherche à imprimer son action sur le monde. « Fail Fast » est un principe de systémique, qui s’applique au « cycle time » et pas au « lead time ». Autrement dit, l’aphorisme est à comprendre dans un monde d’itérations continues, et il signifie qu’il faut savoir échouer le plus rapidement possible, parce qu’il faut itérer plusieurs fois pour réussir. Plus ce qu’on cherche à faire est ambitieux – et dynamique – plus il est essentiel de raccourcir le temps des itérations. C’est très précisément le principe fondateur du Lean Startup.
Il est par ailleurs clair que temps court et temps long ne s’opposent pas. Le temps long est celui de la préparation, le temps court est celui de l’action. C’est une évidence depuis des siècles pour les militaires ou les sportifs de haut niveau – en particulier les sportifs de l’extrême comme les alpinistes. Le fait que la prévision devienne de plus en plus difficile dans un monde complexe ne signifie pas qu’il ne faut pas se préparer. Je vous renvoie ici à Nassim Taleb, qui s’inscrit précisément dans un mode « chinois » de préparation du potentiel de situation « antifragile », capable de profiter des opportunités et de s’enrichir des aléas. Taleb remet à l’honneur les exercices, la pratique des « war games », des « katas » du monde lean, pour construire ce potentiel. Dans le monde du système d’information, le temps long est celui de la construction du potentiel (modèle, données, API, etc.) tandis que le temps court est celui du projet agile qui rencontre le besoin de l’utilisateur.
Le temps long est nécessaire pour développer les capacités d’innovation qui s’expriment dans le temps court. Le parallèle entre l’innovation et les métaphores agricoles chères à François Jullien pour expliquer le modèle chinois est frappant.  Une partie du travail est visible (lorsque la plante pousse) mais une partie ne l’est pas (lorsqu’on prépare le sol). Les « slow hunchs » chers à Steven Johnson sont semblables à la germination des graines. Je vous revoie également au livre « Lean Enterprise – How High Performance Organizations Innovate at Scale » que j’ai commenté dans un billet précédent.
L’illustration suivante représente les différents cycles de temps qui participent à la démarche lean du Toyota Way. Le temps T0 est le temps court de la satisfaction client. C’est le temps du processus, mesuré par le takt time. Le temps T1 est celui du cycle de l’amélioration continu, celui du kaizen. C’est déjà un temps plus long et plus complexe, puisque l’amélioration continue est un processus émergent. Le temps T2 est celui de la construction des compétences, le temps long du potentiel de situation. Comme nous le rappelle Michael Ballé, le kaizen est un outil de résolution de problème, dont l’objectif final est de développer les compétences, à la fois dans le domaine systémique du produit ou service que l’on construit et dans le domaine de la collaboration d’équipe. C’est le « secret génial du lean » : il n’y a pas de meilleure façon de « casser les silos » et d’apprendre la collaboration à une équipe plurifonctionnelle que de résoudre ensemble des problèmes clients – ce que mon expérience de construction de set-top box à Bouygues Telecom confirme merveilleusement. La biologie et la science des systèmes complexe nous confirment les intuitions du lean :
  • Pour que les organismes survivent ils doivent être adaptables, et cela passe par la minimisation du temps de réponse (temps de cycle T0)
  • Pour être agiles et rapides, il faut apprendre (temps T2) par la pratique (temps T1)



3. Technologie et Outils

Une des clés essentielles pour comprendre le développement des technologies est la codépendance entre l’outil et l’usage.  L’usage est guidé et façonné par l’outil, mais l’outil évolue et se transforme en fonction de l’usage – il n’y a pas d’outil sans usage. Dans l’apprentissage des connaissances, l’outil et la pratique jouent un rôle fondamental. C’est un des thèmes fondateurs de l’Académie des technologies. Ces idées sont par exemple illustrées dans le rapport de 2015 sur le Big Data.  Le rôle essentiel des outils est particulièrement important dans le domaine de la transformation numérique. La codépendance est quasi paradoxale : les outils sont au service de la transformation – et leur mise à disposition n’a pas d’efficacité sans une ambition et une histoire partagée … mais la transformation nécessite les bons outils – en particulier la simplicité d’utilisation – et la capacité laissée à tous de se les approprier. Il suffit d’ajouter peu de contraintes pour transformer un « best-seller du travail collaboratif » en plateforme d’entreprise apathique.
De la même façon, la construction des « Exponential Information Systems », les systèmes d’informations qui utilisent et profitent de la révolution exponentielle des technologies numériques, passe par la pratique et expérimentation continue des meilleurs outils.  C’est une des principales limitations des entreprises traditionnelles face aux entreprises disruptives, qu’il s’agisse de startups ou d’entreprises qui viennent du monde du logiciel. « Software is eating the world » … et il s’agit de prendre les bons couverts. Ne pas utiliser les mêmes piles logicielles, les mêmes librairies, les mêmes outils open-source que les concurrents les plus agiles revient à se tirer une balle dans le pied. Et il ne s’agit pas seulement d’une vision mécaniste de l’efficacité (temps T0 : l’outil permet d’aller plus vite) mais bien de la capacité à apprendre plus vite comment travailler autrement (temps T1) pour développer des nouvelles compétences sur le temps T2. Les outils modernes pour construire des logiciels ne sont pas réservés à une nouvelle génération d’informaticien, ils sont ce qui forme une nouvelle génération de développeurs.
Je vous recommande très chaleureusement la lecture de l’article « ING’s agile transformation » de McKinsey avec l’interview de Peter Jacobs et Bart Schatmann. Non seulement c’est un très bon article sur l’agilité – « It’s about minimizing handovers and bureaucracy, and empowering people », avec de très bonnes explications sur l’importance des « squads » et du travail en équipe cross-fonctionnelle – « Spotify was an inspiration on how to get people to collaborate », mais il contient également une vision sur l’adaptation continue de l’entreprise – et son système d’information - grâce à une approche DevOps – « The integration of product development and IT operations has enabled use to develop innovative new product features ». Le déploiment de DevOps illustre parfaitement le propos précédent : l’enjeu n’est pas simplement de travailler plus vite, c’est de travailler autrement, pour à la fin travailler beaucoup mieux … et beaucoup plus vite.  Une fois de plus, les outils jouent un rôle fondateur, ils définissent le potentiel de situation de l’équipe.

Une fois de plus, j’emprunte dans ce billet beaucoup au livre « Exponential Organizations » de Salim Ismail, Michael Malone et Yuri Van Geest. Ce livre donne un certain nombre de clés pour comprendre ce qui est nécessaire à l’adaptation continue des entreprises au changement exponentiel de leur environnement. Je voudrai souligner ici quatre points :
  • Le monde des Exponential Organizations est un monde ouvert dans lequel les entreprises doivent absorber le plus de valeur possible de l’extérieur, en particulier sous la forme d’open innovation qui sera le sujet de la section suivante.
  • Le changement est « distribué » aux frontières (Interfaces) – on retrouve ici la métaphore biologique du BetaCodex, sur laquelle je reviens dans la section suivante. La vitesse de changement impose que celui-ci ait lieu de l’extérieur (la frontière) vers l’intérieur. L’entreprise s’adapte au changement de son environnement (par exemple ses clients) au lieu de décliner une stratégie qui vient du centre décisionnel. C’est le principe de l’homéostasie digitale dans le contexte de la transformation numérique.
  • Le changement commence par la pratique (Experimentation). La supériorité du « learn by doing » est un symptôme de la complexité de l’environnement. Cette complexité exige une adaptation, qui se fait implicitement dans l’apprentissage par expérimentation pratique, parce que la pratique est plus facilement intégrée dans l’environnement réel.
  • Comme dans tout système complexe, le changement rapide exige une finalité claire (Purpose). Pour citer Isaac Getz, l’autonomie sans finalité commune produit le chaos. Dans un monde sans planification, c’est la finalité qui guide la construction du potentiel de situation, de façon émergente.


4. Innovation et Osmose




Le besoin d’ “open innovation” – aller trouver les innovations à l’extérieur de l’entreprise, les idées, les compétences et les talents – est une des conséquence de cet environnement complexe en perpétuelle évolution. Je n’y reviens pas, c’est une des idées clés de « Exponential Organizations » et de ce blog. La stratégie de l’entreprise n’est pas une stratégie d’investisseur (sauf s’il s’agit d’un fond d’investissement ou de capital risque) :  pour créer de la valeur propre, il faut que ce qui est repéré à l’extérieur puisse être « intégré » dans l’entreprise – sous des formes multiples. La métaphore biologique qui inspire cette section est celle d’une cellule qui cherche à profiter de ressources disponibles dans son environnement. Si l’acteur innovant est autonome – par exemple une startup – et n’a pas vraiment besoin des ressources de l’entreprise, l’expérience montre qu’il s’agit plus d’une démarche d’investissement ou d’un partenariat de distribution que la co-création de valeur à laquelle aspire la démarche d’open innovation.

Cette problématique de l’intégration est d’autant plus importante que l’approche est souvent vue comme un palliatif pour corriger les cycles trop lents d’une (grande) entreprise. C’est la métaphore souvent entendue du « porte-avion et des vedettes » : L’organisme lent et gros s’associe avec des plus petits et plus rapides qui sont mieux à même d’explorer et détecter les nouvelles possibilités. Cette métaphore est valide pour ce qui concerne l’ambition, l’association avec des petites structures augmente « la surface de contact » avec les marchés et avec les opportunités technologiques. Elle passe sous silence en revanche les conditions de contact et de collaboration entre le porte-avion et les petits bateaux. Pour que les échanges fonctionnent bien – cela va de partager le même langage, pouvoir identifier les mêmes opportunités au partage de données et de services – il doit exister une certaine homogénéité entre les différents acteurs, à la fois en termes de culture et de biorythme.

La métaphore de l’osmose exprime cette condition de l’open innovation : la « pression innovante » doit être équilibrée des deux côtés de la « membrane » (dedans et dehors de l’entreprise) pour que les échanges fonctionnent et que la cocréation de valeur puisse se produire.  C’est ce que j’ai essayé d’illustrer dans le schéma ci-dessous. Pour que l’association avec un petit acteur innovant fonctionne, l’entreprise doit adapter sa culture (cf. « Exponential Organizations ») – pour pouvoir se synchroniser et reconnaitre de façon commune des opportunités -, sa technologie – pour permettre les échanges de données et de services – et son « biorythme » - l’échelle de temps de ses décisions et actions. Dans le domaine de l’échange de données, tout le monde ne parle plus que d’API (Application Programming Interfaces), à juste titre, mais cela ne suffit pas. Pour que cette collaboration logicielle se développe, il faut des API, une pratique logicielle commune et une vision partagée de l’ALP (Application Lifecycle Management) pour que les biorythmes s’ajustent de façon durable – par exemple sur ce que chacun attend de l’autre en matière de réactivité. On retrouve ici notre dualité temps long/ temps court (selon la citation de Louis Pasteur, « le hasard ne sourit qu’aux esprits bien préparés ») : le temps d’association et de cocréation de valeur avec la startup doit être un temps court, mais le temps d’équilibrage des pressions (construire la bonne culture, les bonnes API et les bonnes pratiques) est un temps long, celui de la préparation.




5. Intelligence Artificielle et Emergence


Je peux maintenant revenir au sujet de mon intervention lors de la matinée du MEDEF et de l’AFIA, lorsque je j’ai cherché à partager mes convictions sur les conditions nécessaires pour profiter de cette « révolution exponentielle » de l’apprentissage et de l’intelligence artificielle. Ces convictions sont le fruit de mon expérience, renforcée par ma visite à la Singularity University en Septembre. Pour résumer, il me semble que ces conditions sont au nombre de quatre : disposer de données, pratiquer les outils logiciels modernes, être organisés en « squads » cross-fonctionnels et promouvoir une culture d’entreprise favorable à l’autonomie et l’expérimentation. Sans rentrer dans le détail – j’y reviendrai une fois que le rapport de l’Académie des technologies sera publié – voici une brève explication sur chacun des 4 points :

  • Il y a un consensus total sur le fait qu’il faut des données pour développer des « solutions intelligentes ». C’est vrai de façon générale, et encore plus lorsqu’on parle de « deep learning ». Tous les rapports sur l’IA – comme l’excellent rapport de France IA - convergent sur ce point, tout comme les différents experts que nous avons rencontrés à l’Académie des technologies. Pour une entreprise, la collecte et préparation des données relève du temps long : il s’agit de construire des « training sets » pour les algorithmes apprenants de demain. Sur ce thème, je vous recommande la lecture savoureuse de l’article de Martin Goodson.
  • L’importance de la « culture logicielle » et de l’environnement de travail est la conséquence logique de la seconde section de ce billet. C’est particulièrement vrai pour le domaine de l’IA : on trouve quasiment tout ce qu’on veut dans le monde open-source, mais il faut avoir la pratique de l’intégration et l’assemblage.
  • Le travail en équipe cross-fonctionnelle est essentiel car il n’y a pas de recette pour diagnostique à l’avance la création de valeur. L’apport des algorithmes « intelligents » est lui-même un phénomène complexe, difficile à prévoir. La pratique est pleine de surprises : des déceptions et des bonnes surprises. Le mode agile est particulièrement indiqué pour développer ce type d’opportunités.
  • La complexité et l’incertitude exigent également de laisser une véritable autonomie aux équipes agile. La découverte de l’innovation nécessite une vraie capacité d’expérimentation. Par ailleurs, la révolution de l’IA est pervasive : à coté de quelques gros sujets tels que la voiture autonome ou l’assistant personnel sur le téléphone, il s’agit d’une multitude d’opportunités pour l’ensemble des tâches de l’entreprise. Cette dispersion des opportunités exige une distribution du contrôle, selon les principes des « exponential organizations ».


Pour conclure, je peux maintenant inclure l’illustration que j’ai présentée le 23 Janvier. Il s’agit d’une pyramide de conditions pour que les entreprises puissent bénéficier des progrès constants (et surtout ceux à venir) de l’Intelligence Artificielle (au sens large). Comme dans une pyramide de Maslow, chaque condition est un prérequis pour celle qui est au-dessus. Ce schéma est clairement abstrait, voire sibyllin, et je n’avais pas le temps de l’expliquer durant un exposé aussi court. En revanche, le lecteur attentif devrait reconnaitre l’ensemble des arguments qui ont été développés dans ce billet.




mardi, janvier 31, 2017

Applications mobiles et conversations : la voie de la raison


1. Introduction


Les chatbots sont ces petits robots qui ont fait leur apparition sur les plateformes de messaging, de WeChat à Facebook. Ce serait peu dire que l’engouement pour les chatbots est un évènement marquant de l’année 2016. Il y a bien longtemps que le Cluetrain Manifesto annonçait que les marchés sont des conversations, mais avec l’arrivée des chatbot le concept du « commerce conversationnel » a pris un nouvel essor. Ceci conduit Forbes à écrire « Get ready for the chatbot revolution : they’re simple, cheap and about to be everywhere”, pour prendre un exemple parmi des centaines.

Au même moment, on constate à la fois un ralentissement dans l’augmentation de la pénétration des smartphones, et une concentration de l’usage des apps au profit des blockbusters et au détriment des nouveaux entrants. Il y a une vraie logique dans l’entrée d’une « phase plateau » des smartphones, puisque la technologie marque un temps d’arrêt, et que cela conduit à un ralentissement des renouvellements, tandis que la pénétration a atteint un niveau qui n’est pas loin de la saturation, à condition économique constante. Le ralentissement de la phase de croissance continue que nous avons connu depuis 10 ans se traduit logiquement dans le taux de chargement des applications.  Les places sur les écrans de nos smartphones sont chères, car elles sont liées à une place dans le « top of mind ». Les expériences qui « justifient une app », par leur fréquence d’usage et la valeur apportée restent rares. Dans la très grande majorité des cas, une approche de « Web app », produite sur le navigateur du mobile – dont les capacités ne font que progresser-, est amplement suffisante.

La combinaison de ces deux tendances fait qu’on voit apparaitre depuis plusieurs mois des articles annonçant la fin des applications mobiles. Les chatbots vont remplacer les apps parce qu’ils sont plus faciles à utiliser et ne nécessitent pas de téléchargement. La fin des apps mobiles n’est pas un thème nouveau, mais la compétition avec les chatbots devraient porter le coup de grâce, sans compter les progrès spectaculaires de la reconnaissance vocale, qui devraient faire du smartphone un objet auquel on parle.

L’objectif du billet de ce jour est d’essayer de trouver un compromis – la « voie de la raison » - entre l’enthousiasme justifié pour les chatbots en tant que nouveau canal d’interaction et le scepticisme raisonné face au « hype », et en particulier l’idée que cette approche signifierait la fin des applications mobile. Je partage cet enthousiasme, et les premières expérimentations auxquelles j’ai pu être associé confortent  mon intérêt, mais je suis absolument pas convaincu pas les arguments qui prévoient la fin des applications mobiles. Je pense qu’une révolution arrive, en terme d’interface homme-machine, mais qu’elle va s’ajouter au reste plus que le remplacer les autres techniques d’interaction (hormis les quelques cas dans lesquels le méthodes actuelles sont inefficaces).

Ce billet est organisé selon le plan suivant. La première partie va souligner l’importance de la conversation – sous forme écrite avec un chatbot ou vocale avec Siri ou Alexa – comme méthode d’interaction. Même s’il faudra du temps pour avoir des conversations réellement intelligentes avec les machines, une très grande partie de nos moments de vie se contentent très bien d’une conversation simple – ce que je qualifie de « dumb bots » - qui est à la portée de la technologie d’aujourd’hui et représente un vrai progrès par rapport aux alternatives – remplir un formulaire sur le Web par exemple. La seconde partie va rappeler quelques évidences sur le design d’interaction, pour redécouvrir que tout n’est pas réductible à une conversation. Nous avons 5 sens, et il faudra continuer d’en profiter, avec ou sans intelligence artificielle. La dernière partie va s’intéresser simplement à l’évolution des applications mobiles en co-évolution avec les chatbots. Les smartphones vont continuer – au moins dans les 10 ans à venir – à progresser en termes de capacité logicielles et matérielles via l’incorporation de senseurs. Les applications deviennent des systèmes, dont l’implémentation est distribuée (mobile et cloud et objets) et dont les interfaces sont également distribuées.


2. Une révolution se prépare : l’interaction conversationnelle 


L’utilisation des chatbots est un élément de différenciation du moment de la plupart des acteurs innovants, comme les startups. L’interaction à travers un “agent conversationnel” (chatbot) présente de nombreux avantages, même si le service reçu est simple. Au-delà du côté « naturel » du dialogue en langage naturel, le principe de la conversation est à la fois rassurant et simple. Les premiers retours des utilisateurs pour qui on remplace un formulaire web par un dialogue simple - qui demande les informations une par une - sont très positifs. Ce sont les « dumb bots » que je mentionnais plus haut : des chatbots limités dans leurs capacités et qui interviennent sur des domaines limités. La première étape de la révolution est maintenant parce que la technologie pour les dumbot est très facilement disponible et mature, et parce que les bénéfices clients sont déjà réels. Les plateformes actuelles permettent déjà des réaliser des dialogues plus conviviaux et plus robustes que l’état de l’art des formulaires web assortis d’assistants en Javascript. Plus on dispose de nombreux exemples de dialogues, plus il est possible d’entrainer le chatbot à donner des réponses pertinentes. Par un effet vertueux, un chatbot qui commence à bien fonctionner devient un collecteur de dialogues, ce qui permet de continuer à progresser (et c’est pour cela qu’il faut commencer).

Je peux citer ici à nouveau Norm Judah, le CTO de Microsoft, et reprendre ses arguments d’un billet précédent. Les bots permettent d’ouvrir les interactions avec les services digitaux à de nouvelles familles d’utilisateurs :

  • Ceux qui n’ont pas accès à un smartphone où ne sont pas familier avec l’utilisation des apps. Il faut se rappeler que même si la pénétration des smartphones frise la saturation, plus de la moitié des utilisateurs se contentent des apps pré-chargées et n’en ajoute pas d’autres.
  •  Les utilisateurs qui ne sont pas familiers avec la conceptualisation implicite de la plupart des interfaces utilisateurs du web. La navigation dans les menus, les listes déroulantes, les choix de catégorie qui reposent sur des abstractions, sont autant de barrières en fonction des origines socio-culturelles des utilisateurs.



Si l’état courant des plateformes de bots favorise le choix réaliste de domaines très précis de dialogue, les « dumb bots » vont devenir de plus en plus « smart » parce que la reconnaissance du langage va fortement progresser dans les années à venir. Je vous renvoie à la présentation que j’ai faire au MEDEF – lors de la journée co-organisée avec l’AFIA. Le chemin vers les assistants « vraiment intelligents » sera long. Même à la Singularity University, Ray Kurzweill pense qu’il faudra encore dix ans avant d’avoir des conversations convaincantes sur des domaines généraux. Pour l’instant, lorsqu’il faut traiter des demandes variées, la meilleure méthode est de combiner l’intelligence humaine et l’intelligence artificielle, à la façon de Wiidii ou de Facebook M. Mais il faut s’attendre à des progrès rapides et des étapes marquantes dans cette route vers les assistants « généraux ». Si vous voulez vous convaincre des progrès rapides dans ce domaine, je vous recommande la lecture de cet article, qui relate le fait que les robots de reconnaissance vocale battent les meilleurs humains en train de « texter » des messages. Lors d’une compétition organisée par Baidu, la reconnaissance vocale sur smartphone est 3 fois plus rapide et 20% plus précise que les meilleurs accros au mobile messaging. Ce n’est pas un hasard si Andrew Ng déclare : « 2017 will be the year of the conversational computer ».

Si l’on définit le concept de “test de Turing du chatbot intelligent”, il y a trois paramètres essentiels : le scope de la conversation, la durée de la conversation, et la sérendipité (est-ce que l’utilisateur pose une question ou est-ce qu’il s’agit d’apprendre quelque chose qu’on ne sait pas encore être intéressant). Sur une durée courte, avec un domaine défini et un mode requête, les techniques actuelles permettent déjà de faire illusion (i.e., « passer le test de Turing »), comme le témoigne l’exemple célèbre suivant. Un professeur a décidé de remplacer un de ses « assistants » pour répondre aux questions des élèves, et cela a très bien fonctionné. Les experts des chatbots insistent sur l’importance d’un domaine précis et bien délimité, car cela facilite grandement l’apprentissage supervisé, et permet d’obtenir une bien plus grande pertinence.


3. Design d’interaction 


Ce que nous venons de voir dans la section précédente ne signifie nullement que les chatbots sont une panacée en termes d’interactions. Rappelons-nous, suivant une formule célèbre, que le but du design est de minimiser les frictions et de maximiser le plaisir lors de l’utilisation d’un produit ou d’in service. Le domaine CMC (Computer Mediated Communication), auquel j’ai fait de nombreuses fois référence dans ce blog, est riche d’enseignement.  Chaque canal de communication se caractérise par sa densité, sa bande passante, sa capacité de feedback (entre autres). Le canal audio a ses forces et ses faiblesses, tout comme le canal textuel. L’utilisation de l’image et de la vue supporte une bien plus grande densité d’information. Il ne viendrait à personne l’idée de remplacer Google maps par un chatbot, même si certains « use cases » se prêtent au dialogue. De la même façon, le canal haptique, associé au toucher, permet un excellent niveau de feedback qui n’est pas accessible via le langage. Ici on peut penser aux applications de sketching ou de dessins, qui ne sont pas remplaçables par des dialogues. Au-delà de ces exemples caricaturaux (cf. "un dessin vaut mieux qu’un long discours"), les interfaces conversationnelles sont un des outils du design d’interaction, dans une large panoplie de solutions. Le fait que les progrès des techniques d’apprentissage viennent de faire un progrès spectaculaire et rendent les interactions conversationnelles robotisées faciles d’accès et beaucoup plus pertinentes ne modifie pas l’intérêt fondamental d’utiliser l’ensemble de nos sens pour faciliter le dialogue entre l’humain et la machine.

Sans rentrer dans trop de détail sur ce qui justifierait un billet séparé, voici quelques réflexions sur l’arrivée des chatbots dans la pratique du design d’interaction :

  • Le design d’interaction est au service de l’expérience, tournée vers le “job to be done” et le “unique value proposition” que le service doit apporter au client. Le choix du meilleur canal doit tenir compte du contexte d’utilisation. Par exemple le canal vocal respecte peu la «privacy » du client et produit une « nuisance sonore » (une externalité négative) qui le rende inadapté à de nombreux usages.
  • L’interaction homme-machine est une science, il existe beaucoup de principes et de méthodes fondées sur des expériences validées (clin d’œil à la data science des bots). Beaucoup d’expériences digitales abusent de la puissance des outils et de la richesse des écrans en fournissant beaucoup trop d’information (ce qui a permis à de nombreux acteurs de s’illustrer en prenant le contrepied). A l’inverse, les dialogues répétés et les pages multiples de certaines interfaces Web sont un retour arrière par rapport à la mise à disposition d’information complète.
  • Comme nous allons le développer dans la section suivante, il faut s’inspirer de la nature et favoriser la diversité des canaux d’interaction. Il y a des moments où la voix n’est pas adaptée mais il y a clairement des moments où c’est l’approche la plus naturelle, ce qui explique le succès d’Amazon Echo. Réduire l’effort nécessaire – cf. thinking, fast and slow - est un excellent principe de design biomimétique. La conversation est un mode plus confortable que la requête, mais avec un « cout de setup » et une énergie nécessaire supérieure (par exemple, à l’utilisation de Google dans la barre du navigateur).
  • Chaque année digitale vient avec ses modes, mais la « « mode précédente de l’environnement cliquable – pour reprendre une très belle formule de Joël de Rosnay – qui utilise les objets connectés comme des éléments du design d’interaction reste extrêmement pertinente. L’expérience favorise le design d’interactions simples, associées à un usage unique.  Un exemple simple est celui de la télécommande de la télévision (ou de la set-top box) qui résiste vaillamment à l’introduction de la reconnaissance vocale dans ces objets.



4. La fin des applications n’est pas encore en vue


Pour revenir à la question de l’introduction, le besoin de la richesse des modes d’interaction donne une première raison de penser que les chatbots ne vont pas signifier la fin des applications mobiles. Cette diversité va au contraire conduire à une vision étendue des applications, capables de se matérialiser sur plusieurs interfaces utilisateur. Je souscris à ce concept d’interface utilisateur à la demande « When I say On-Demand User Interfaces, I mean that the app only appears in a particular context when necessary and in the format which is most convenient for the user”. Cet article insiste fort justement sur la notion de produit. L’application est un produit qui se décline intelligemment sous plusieurs instanciations en fonction du contexte utilisateur, avec les interfaces adéquates.
                                                                              
Si l’on regarde ce que les gens font aujourd’hui avec leurs apps, on retrouve les categories best-sellers: la communications avec d’autres personnes, les news et le divertissement, les jeux. Dans la plupart des cas, le canal chatbot n’est pas le mieux adapté et il y a peu de chance que ces applications disparaissent. Si vous voulez vous en convaincre, regardez les applications des deux premiers écrans de votre smartphone et comptez celles qui pourraient être remplacé par un chatbot.  L’arrivée des applications vocales – on pense aux skills d’Alexa et leurs équivalents chez Google – vont donner lieu à des nouvelles plateformes, mais il s’agit de l’ajout d’un nouvel écosystème digital, pas de la fin du précédent.

De toutes façons, les chiffres ne supportent pas les analyses pessimistes que j’ai cités en introduction. Il y bien un léger tassement et une concentration en faveur des applications dominantes, mais la course technologique n’est pas terminée et il faut s’attendre à ce que les smartphones intègrent des nouvelles capacités, matérielles et logicielles, qui donneront lieux à des nouvelles applications. Sur le plan matériel, nous n’en sommes qu’au début de l’intégration des senseurs. Les domaines de la santé, de la prévention et du bien-être vont être bouleversés par l’arrivée de capteurs beaucoup plus sensibles et fiables de nos bio-mesures, depuis des choses élémentaires comme la température ou le rythme cardiaque jusque des mesures complexes de type ECG. Ces capacités nouvelles (en particulier par rapport au manque de précision/fiabilité des premières génération) vont donner lieu à des nouvelles applications. De la même façon, le machine learning et les réseaux neuronaux vont s’inviter sur les smartphones pour leur permettre d’analyser notre environnement (images et sons, mais aussi déplacements). Il faut s’attendre à voir apparaitre de multiples applications – y compris les évolutions de celles que nous connaissons déjà – qui vont exploiter ces capacités.

La notion d’application va également devenir de plus en plus polymorphe : des applications mobiles avec interfaces graphique – celles que nous connaissons aujourd’hui - , mais aussi des application mobiles en « tache de fond » qui s’exprimeront par d’autres canaux (e.g., messages ou notifications), des applications dans les plateformes (telles que les applications dans Facebook ou Wechat), des applications intégrées dans les navigateurs, ou des applications natives des OS (des « widgets » associés à des événements) ou des applications associées à des objets, tels que le bouton Nuimo que j’utilise avec plaisir depuis quelques mois. Tout ceci conduit à la notion d’application en tant que système, au lieu d’être une « destination », ce qui est très bien expliqué dans  l’article  « the end of the apps as we know them ». Voici un petit extrait pour vous donner envie de lire cet article : « Most of us building software are no longer designing destinations to drive people to. That was the dominant pattern for a version of the Internet that is disappearing fast. In a world of many different screens and devices, content needs to be broken down into atomic units so that it can work agnostic of the screen size or technology platform. For example, Facebook is not a website or an app. It is an eco-system of objects (people, photos, videos, comments, businesses, brands, etc.) that are aggregated in many different ways through people’s newsfeeds, timelines and pages, and delivered to a range of devices, some of which haven’t even been invented yet. So Facebook is not a set of webpages, or screens in an app. It’s a system of objects, and relationships between them ».  Cet article insiste sur l’importance des notifications et d’une approche orientée-évènement, un point sur lequel je ne peux être qu’en agrément.

Pour conclure, je reprendrai le titre de cet article de Techcrunch : « les nouvelles de la mort des apps ont été grandement exagérées », mais il n’en reste pas moins vrai que construire une application satisfaisante reste une aventure très difficile, comme l’explique très bien cet article sur la refonte d’Evernote.