Westrum Organizational Culture et Machine Learning – Partie 2 : Changer la culture

Cet article fait partie de la série “Accélérer le Delivery de projets de Machine Learning”, traitant de l’application du framework Accelerate dans un contexte incluant du Machine Learning. Si vous n’êtes pas familier avec le framework Accelerate, ou si vous souhaitez avoir plus de détails sur le contexte de cet article, nous vous invitons à commencer par lire l’article introduisant cette série. Vous y trouverez également le lien vers le reste des articles pour aller plus loin.

Cet article aborde la capacité "Westrum Organizational Culture" d'Accelerate appliqué au Delivery de projets de Machine Learning et est lui-même divisé en deux parties :

• Partie 1 : Impacts de la culture sur le delivery
• Partie 2 : Changer la culture

Dans un article précédent, nous avons parlé de l’impact de la culture sur le Machine Learning Delivery. Nous avons défini les différentes typologies de culture au sens de Westrum et proposé des pistes pour identifier dans quelle culture organisationnelle on évolue. Nous avons ensuite analysé les réactions typiques de chacune des trois cultures face à certaines pratiques courantes du Machine Learning Delivery.

Dans beaucoup d'entreprises, faire le constat d'une culture, c'est commencer à vouloir la changer. Les projets qui mettent en œuvre du Machine Learning constituent bien souvent une innovation, et à ce titre une confrontation à la culture de l'entreprise. Dès lors qu'elle semble se manifester sous la forme d'un obstacle incontournable (parfois appelé "l'inertie" ou "la résistance au changement"), nous prenons à cœur de tenter de changer cette culture, de créer une nouvelle culture ou plus modestement "d'acculturer" l'entreprise aux innovations (technologique et méthodologiques) que nous voulons mettre en place. La question pratique devient alors, non pas tant "comment changer la culture ?" (s'il y avait une méthode universelle pour changer la culture d'une entreprise, il semblerait incroyable que la culture qui "résiste" reste à ce point stable dans la plupart des entreprises), mais "que faire vis-à-vis de la culture ?"

1. La bulle générative

Nous le voyons bien : mettre du Machine Learning en production est bien plus simple dans une organisation générative. Malheureusement, la culture de l’organisation où on se trouve est bien plus souvent subie que choisie. Comment fait-on pour mener un projet de delivery de Machine Learning dans une organisation bureaucratique ou pathologique ?

Une démarche qui marche bien chez OCTO est la mise en place d’une bulle générative dans l’organisation que nous conseillons. Il s’agit concrètement de négocier des exceptions dans l’organisation afin de pouvoir fonctionner comme une équipe générative au sein du projet de delivery de Machine Learning. Cela permet à nos équipes de s’auto-organiser et de travailler au mieux selon les pratiques qu’elles jugent le plus pertinentes, en se pliant le moins possible à un mode de fonctionnement qui, nous l’avons vu, met des bâtons dans les roues de notre delivery.

Certaines organisations bureaucratiques en ont d’ailleurs conscience : elles essaient depuis un certain temps de s’aménager des bulles génératives afin de s’initier à la Data Science. C’est ainsi qu’en 2016, deux tiers des entreprises du CAC 40 avaient un Data Lab. Elles s’essaient au sein de ces structures au Machine Learning, mais aussi à l’agile, au travail en équipes multidisciplinaires, à la “culture start-up”… Elles se donnent en somme les moyens de développer un savoir-faire stratégique : la Data Science.

Mais comment négocier de telles exceptions, particulièrement au sein d’organisations où c’est une nouveauté ? La réponse passe souvent par le sponsor. Dans des organisations pathologiques et bureaucratiques, avoir le bon interlocuteur ouvre des portes : si le leader est de notre côté, les équipes suivent par peur ou par discipline. Dans les organisations bureaucratiques, les règles s’appliquent surtout au bas de la pyramide : le leadership bénéficie de plus de largesses (c’est in fine lui qui édicte les règles) et peut très rapidement débloquer des situations. Si la direction met en avant un sujet stratégique, alors récupérer des données ou avoir les ressources nécessaires pour mettre un modèle qui y répond en production devient bien plus simple. C’est dans ce contexte qu’on peut pousser pour la formation d’équipes s’inspirant du modèle des tiger teams : une équipe de choc, constituée d’experts (Data Scientists, mais aussi développeurs, POs, UXs…), qui a comme mission de mettre un algorithme de Machine Learning  en production, et dispose pour cela de moyens exceptionnels.

Une fois qu’on a le bon sponsor, être un consultant est un atout dans cette négociation. Faire partie d’une organisation externe, appelée pour son expertise sur le sujet, apporte de la crédibilité aux recommandations. Si des experts, qui ont mis en production des algorithmes de Machine Learning proposent une manière de travailler et demandent certaines ressources pour le faire, le leader a plus de chances de suivre.

Comment faire marcher cette organisation atypique dans la durée ?

figcaption {color: grey; text-align: center; font-style: italic}

La bulle générative : S’aménager un environnement de travail permettant la bonne circulation de l’information

Comme souligné antérieurement, “culture eats strategy for breakfast” : ce n’est pas parce que nous avons carte blanche sur l’organisation de notre équipe en début de projet que le naturel ne va pas revenir au galop. Souvent, la hiérarchie demande des comptes en jours / homme, veut une roadmap à un an, des jalons et des comités de pilotage, puisqu’elle est habituée à suivre les projets de cette façon-là. Il s’agit alors de s’accorder sur un contrat d’interface avec l'organisation hôte. Quelles sont les informations sur l’avancement du projet qui sont pour elle essentielles ? Quelles métriques doit-on suivre dans tous les projets de delivery ? Ces pratiques et ces mesures ne seront pas forcément celles que l’équipe aurait adoptées spontanément, et ne seront probablement pas celles qu’elle utilisera pour s’auto-évaluer, mais elles servent à communiquer avec l’extérieur de la bulle.

Cette interface permet de continuer à fonctionner de façon générative à l’intérieur de la bulle. Avoir un ambassadeur, chargé de faire le pont entre l’équipe et l'organisation hôte est également essentiel pour maintenir la bulle générative dans la durée. Cette personne a comme mission de préserver les équipes des obligations propres à l’organisation “hôte”. Elle produit par exemple les métriques demandées et participe aux comités de pilotage, parmi d’autres obligations. Elle est également responsable de défendre le fonctionnement génératif de l’équipe, face à des offensives probables de personnes ne comprenant pas pourquoi les pratiques de l’organisation ne sont pas suivies dans cette configuration.

Il ne faut cependant pas se voiler la face : la bulle générative est extrêmement fragile. Elle est soumise aux frictions entre sa culture et celle de l’organisation hôte, subies principalement par l’ambassadeur, mais parfois également par les équipes lorsque ce dernier n’arrive pas à faire tampon.

En effet, le rôle de l’ambassadeur est très délicat et difficilement tenable dans la longueur. Il doit être à la fois assertif et diplomate sur les messages passés à l’organisation hôte afin qu’ils soient bien compris. Illustrons ceci par un exemple. Supposons que l’équipe conclut, suite à une expérimentation, qu’il faut abandonner une piste. Dans une organisation bureaucratique, il faudra faire attention à ce que la conclusion de cette expérimentation ne soit pas perçue comme un échec (cette question ne se pose pas dans une organisation générative, où il existe un droit à l’erreur). L’ambassadeur devra alors présenter cette information sous le bon angle : “nous avons économisé de l’argent en ne suivant pas cette piste”.

Cependant, il est illusoire d’attendre qu’il fasse un sans-faute. D’autant plus qu’avec le temps, la fatigue de l’ambassadeur grandit. En s'efforçant d'être diplomate, il peut par exemple brouiller son message : “ Les résultats de notre expérience nous montrent qu’il vaut mieux ne pas continuer dans cette voie. Mais votre idée est très intéressante, peut-être qu’en revoyant certaines hypothèses…” Le récepteur du message peut alors comprendre “oui, mais” plutôt que "non", et demander à l’équipe de continuer de creuser. L’équipe revient alors à la case départ, alors qu’elle sait déjà que c’est superflu. Elle subit dans cet exemple la culture bureaucratique.
Comme toute bulle, la bulle générative finira un jour par éclater. L’enjeu se trouve dans sa postérité : n’aura-t-elle été qu’une brève parenthèse dans la vie de l’organisation, ou un tremplin vers d’autres façons de faire, proposant des solutions à ses nouveaux défis ?

2. Prendre le bâton de pèlerin

Pour autant qu'elle ait les coudées franches au sein d'une bulle générative, et qu'elle puisse défendre et mener à bien un premier projet de Machine Learning, notre équipe n'en a pas fini avec la culture de l'entreprise. En effet, si la Data Science représente une évolution stratégique pour l'entreprise, ses dirigeants souhaiteront naturellement une extension de cette stratégie. L'équipe de Data Scientists, "victime de son succès", sera alors mandatée pour en produire de nouveaux et se retrouvera confrontée aux mêmes obstacles culturels. L'ambassadeur devra alors prendre son bâton de pèlerin, c'est-à-dire se charger de défendre l’équipe et ses convictions (initiée par la bulle générative), ainsi que son image. C'est typiquement le rôle qui correspond à l'activité de connexion (bridging) désignée par Westrum dans sa comparaison des différentes cultures. Dans une culture générative, ce type de rôle transverse est habituel, parce que cette culture ne crée pas de silos rigides.

En revanche, lorsqu'il navigue dans une culture bureaucratique, l'ambassadeur doit s'armer de patience et de pédagogie. Le travail commencé dans la bulle doit continuer à l'extérieur autant que faire se peut. L'activité de son équipe de Data Science, qui était peut-être initialement perçue par le reste de l'entreprise comme une simple "expérimentation" a maintenant un caractère stratégique. Ce statut justifie à la fois la mise en place d'une action transverse et explique un ensemble de réactions qui vont de l'attention polie (on est d'accord pour en parler) à l'indifférence caractérisée (désolé, pas le temps).

Dans les silos bureaucratiques, l'activité est localement optimisée. La contribution aux actions transverses fait donc l'objet d'une attention et d'une dotation en budget extrêmement limitées. Paradoxalement, aussi bien les équipes opérationnelles sur le terrain, que l'upper management, sont souvent disposés à casser les règles, à mettre en place de manière très pragmatique des exceptions, puis de nouvelles règles plus souples. En revanche, le niveau managérial intermédiaire, qui doit défendre ses budgets, et gérer la complexité du quotidien, va généralement s'opposer plus ou moins directement aux prérogatives de l'équipe de Data Science. L'ambassadeur a alors besoin de défendre les demandes de son équipe, tout en intégrant les besoins et le contexte de ses interlocuteurs, faute de quoi ces demandes se verront soldées par une fin de non-recevoir. Ses compétences doivent s'étendre, car l'expertise et l'esprit de synthèse ne suffisent plus. Sa capacité à développer une vision stratégique incluant un plus grand nombre d'acteurs de l'entreprise, et donc un plus grand nombre de situations, ainsi que sa capacité à transmettre cette vision, vont être mises à l'épreuve. Il devra devenir un leader sans pour autant jamais "prendre les commandes".

Au sein d'une culture pathologique, un projet qui prend de l'envergure ne peut réussir sans une forme (plus ou moins noble) d'action politique. L'ambassadeur, dont la communication doit être "impeccable" (au sens des Accords Toltèques) doit aussi développer son art de la négociation, travailler les bonnes alliances, et aiguiser son sens politique. Les opposants à la stratégie (naysayers) doivent être rapidement repérés, et isolés par le jeu politique. Cette notion de "politique", qui peut sembler déplacée dans une entreprise, a pour autant toute sa place si l'on considère avec réalisme la forme en pyramide des entreprises bureaucratiques ou pathologiques, et la nature des relations interpersonnelles qui se forment à son sommet. Un sommet où les intérêts individuels sont parfois exacerbés, et où une puissante amitié ou inimitié peuvent faire toute la différence quant au déroulement d'une stratégie. Il est impossible de défendre, sans même parler d'accomplir, une stratégie d'innovation à grande échelle dans une grande entreprise sans faire de la politique.

3. Accepter une part de chaos

Comme mentionné dans la première partie de cet article, seulement 13% des projets de Machine Learning vont en production. Le chemin de l'équipe de Data Science est semé d'embûches. Ces obstacles, pour la plupart, ne sont pas techniques - une équipe cohérente, experte et libre de ses mouvements fait son affaire des problèmes techniques. Ils sont organisationnels et, si l'on y réfléchit bien, culturels. Comment change-t-on une culture ? Par où commencer ? Deux observations en guise de conclusion, ou plutôt d'inauguration du chemin vers l'extension de la Data Science dans l'entreprise :

1. Change-t-on jamais la culture ? Ce que nous désignons par ce terme, c'est la somme de nos représentations, de nos valeurs, de nos principes et pratiques qui se manifestent à travers une myriades de situations et d'interactions, d'une manière fractale. Par où commencer en effet ? Simon Wardley, via l'un de ses tweets ironiques, nous encourage à commencer par la doctrine, un ensemble de principes "universels" propres à produire des changements culturels dans l'entreprise. Pour l'équipe de Data Science, ces principes se matérialisent surtout par des pratiques concrètes ainsi que des explications hors de la "bulle" générative.

https://twitter.com/swardley/status/1329008675990740992

Patterns utiles quelque soit le contexte, identifiés par Simon Wardley

2. En supposant que vos projets de Machine Learning, tout expérimentaux et novateurs qu'ils soient, réussissent et passent en production, ce succès marque le début, et non la fin, du développement de cette discipline dans l'entreprise. En informatique d'une manière générale - et les projets de Machine Learning ne sauraient faire exception - les problèmes trouvent seulement des solutions provisoires. Un projet en succès, dans lequel l'état de l'art est parfaitement aligné au contexte et aux objectifs de ses sponsors, ne peut pas rester dans cet état de bénédiction. Le temps passe, le contexte et les objectifs changent, l'état de l'art mis en œuvre n'est plus tout à fait adapté. Le système "s'endette", le modèle drifte... jusqu'à la prochaine impasse.

Par exemple, une entreprise recrute un Data Scientist afin de mieux anticiper le taux d'attrition (churn) et mieux fidéliser sa clientèle sur son produit principal. Le Data Scientist met en place un modèle de prédiction au moyen d'un Notebook et le valide. Il s'agit ensuite de déployer cet outil de manière à ce que les conseillers en contact avec des clients soient notifiés sur le risque de churn. Le projet intègre donc deux nouveaux acteurs, Développeurs et Ops, lesquels sont bien en peine de faire leur travail habituel sur le livrable qui leur a été confié. Celui-ci "marchait" sur le poste du Data Scientist, mais repose en fait sur des composants non disponibles dans l'environnement de production. À charge aux développeurs de refondre le code afin de l'adapter. Mais ceux-ci ne comprennent pas suffisamment le modèle mathématique utilisé. La "démo", si convaincante auprès des dirigeants ne peut pas être industrialisée, c'est une impasse. Il est alors nécessaire de remettre à plat le produit, de noter ce qui manque (sur le papier : des pratiques plus industrielles, de meilleurs standards, une ouverture à de nouveaux modèles d'organisation, ou de nouvelles technologies, etc.), et de procéder à de nouvelles expérimentations. Cette démarche met en évidence de nouveaux obstacles, cette fois-ci non technologiques, mais relationnels et organisationnels.

Un projet de Machine Learning qui ne va pas en production se trouve précisément dans cette phase, où l'apprentissage n'est pas converti en valeur ajoutée pour l'entreprise. Il ne l’est pas parce qu'il manque l'intégration d'une idée transformatrice, une adaptation à la fois à la nouveauté du projet et à l'existant de l'entreprise, une idée qui aiderait à surmonter les blocages, les inquiétudes, les réactions de rejet a priori, mais aussi les contraintes de l'entreprise. Le travail non seulement de l'ambassadeur (et pourquoi pas de l'équipe entière)  a pour but cette adaptation, afin que la recherche aboutisse en un développement effectif au lieu de s'arrêter à la porte du laboratoire. Une fois cette phase d'intégration réalisée, l'entreprise s'est "Data-Scientisée", et le Data Scientist s'est un peu plus "fondu" dans l'entreprise. Un nouveau Status Quo a lieu, et le cycle recommence. Ce cycle peut être schématisé au moyen de la carte de polarité ci-dessous:

Cycle des performances entre production et apprentissage

En conclusion/inauguration : l'équipe de Data Science aura nécessairement affaire (et ce sera une friction) à la culture de l'entreprise, tout en étant un vecteur de changements culturels dans l'entreprise. Quelle que soit l'issue de cette évolution - et quelle que soit la date à laquelle on choisira de prendre la nouvelle "photo", c'est-à-dire au sommet du succès, ou bien face à l'épreuve -  l'équipe comme l'entreprise doivent se préparer à accepter une part de chaos dans cette aventure...