Malgré les efforts marketing considérables des GAFA, des gros éditeurs de logiciels, des prophètes et des Cassandre de l’IA, il faut reconnaître que l’impact économique réel de l’IA dans les grands groupes français est quasi homéopathique. Combien de groupes du CAC40 connaissez-vous qui ont ne serait-ce qu’1% de leur revenu ou de leur marge imputables à l’IA ?

Et pourtant ce n’est pas faute d’essayer. Combien de CDO ? Combien de Head of Data Science ou mieux Head of Artificial Intelligence ? Combien de légions de Data Scientists ? Combien de Data Lakes ou d’incubateurs aux noms évocateurs ? L’IA se paierait-elle de mots ?

J’ai eu l’occasion ces trois dernières années de croiser plus d’une trentaine d’équipes de Data Science, dans des grands groupes français et scandinaves, et je crois qu’il faut se faire une raison : ça traîne.

Dans la suite nous essaierons de distinguer trois formes d’IA qui ne subissent pas les mêmes freins. La seconde, les IA de processus métiers, qui semble la plus impactante à moyen terme, sera au coeur de notre réflexion :

1. Les IA de commodité, qui visent à fluidifier des processus existants comme un détecteur de spam dans un serveur de mail. Celles-ci progressent plutôt bien car s’inscrivent dans un schéma d’innovation IT classique et sont en partie externalisables
2. Les IA de processus métiers, qui repensent un processus comme une nouvelle politique de maintenance d’équipement ou un nouveau mode de tarification
3. Et les IA tournées client qui offrent de nouveaux produits/services à la clientèle en changeant l’expérience client. Les trois formes d'IA n'étant bien entendu pas mutuellement exclusives.

Mais pourquoi ça traîne ? Lors d’une mission longue que j’effectuais à l’Assistance Publique des Hôpitaux de Paris - pour mettre en place SAP – j’ai rencontré un directeur d’hôpital qui avait un critère infaillible pour savoir la lenteur avec laquelle un hôpital basculerait sur SAP : « je compte le nombre de blouses blanches brodées aux initiales des médecins ». Quelles sont les blouses brodées pour l’Intelligence Artificielle ? Qu’est-ce qui en freine à ce point le déploiement ?

L’erreur de casting chez les Data Scientists

Un non-GAFA, lorsqu'il n'est pas totalement numérique, a un mal fou à extraire la connaissance de ses données historiques de manière programmatiquement exploitable. Non seulement parce qu’elles ont été stockées le long de vieux processus, biaisées donc par celui-ci, mais encore parce que jusqu’à présent seuls des êtres humains ont accédé à ces données et de manière le plus souvent agrégée, via des KPIs et des outils de Business Intelligence simplificateurs. Je vais me servir de l’exemple d’un groupe de resorts (type club) qui cherche à exploiter la data des bracelets de paiement pour améliorer ses offres commerciales sur site. On imaginera que les bracelets donnent à la fois des informations transactionnelles (« Le petit Danois a consommé une glace à la réglisse à 15h05 ») et de géolocalisation (« Il est sorti de la piscine à 14h58 et y est retourné après 17 minutes »). La passion des Danois pour la réglisse salée n'est pas le propos de cet article, mais on considérera ce goût comme "normal" chez un danois.

Une première génération de Data Scientists va donc devoir être consacrée à ré-interpréter et débiaiser ces données historiques (Y avait-il la queue chez le glacier ? Etait-ce le jour d’arrivée de la famille danoise ?), tout en créant des couches de savoir, des ontologies, autour de toutes les familles de données utiles à la prise de décision que l’on veut augmenter. (Quelles sont les offres promotionnelles de glaces qui ont été poussées vers ce petit Danois ? Quelle était la météo ce jour-là ? Quelles sont les grandes typologies de clients vis-à-vis des glaces ? Est-ce que tous les membres d’une même famille prennent des glaces en même temps ou seul l’enfant ? Madame a-t-elle pris une bière au bar au même moment ?) On est bien loin du Deep Learning. C’est parfois du Data Engineering de compétition, certes, avec un certain flair business, mais ce n’est pas des Data Scientists qu’il vous faut, ou alors vous allez les sacrifier sur l’autel de vos illusions.

Mais si vous avez commencé par recruter des Data Scientists, parce-que vous avez surestimé la digestibilité de vos données, la tentation va être grande de les utiliser à contre-emploi. Leur valeur ajoutée – et leur moral – s’en trouve considérablement affaiblis. Il faut certes des Data Scientists, dès les phases initiales, pour penser au flux décisionnel (« Quelle promotion pousser pour une certaine catégorie de clients, dans un certain contexte d’achat et dans un objectif de maximisation de marge » ? « Quelles sont les sources de données qui ont des chances d’avoir un impact sur la consommation de glace ? »). Mais il ne faut pas mettre tout de suite les poussins dans la broyeuse.

Penser « Data Lake » au lieu de penser « Data Flow »

Je suis souvent étonné de voir la vitesse à laquelle un DSI vous parle de la profondeur de son Data Lake : en téra-octets. Mais si vous parlez de flux, la réponse peut prendre un peu plus de temps. Or c’est du flux, et de sa maîtrise, que proviendra la valeur ajoutée de la décision.

·        Il y a d’abord les flux entrant et sortant. En général, dans un bon Data Lake, le flux provient d’un système informatique, comme un logiciel de réservation, un logiciel de caisse, ou un outil de gestion de maintenance voire un équipement lui-même comme la porte d'un cottage, un machine outil, une montagne russe ou un sauna. Ou tout bonnement des flux externes comme la météo ou les dates de congés scolaires des danois. Si le site web déverse dans le Data Lake son « Google analytics », quelle en est la latence ? Permettra-t-elle une prise de décision dynamique le long du parcours client ? Puis en aval de la Data Science, cette fois, des interfaces entre le Data-Lake et les applications sont-elles opérantes, performantes à l’échelle d’un clic, d’une fin de repas au restaurant, d'un parcours logistique ? Les interfaces sont-elles prêtes, les firewalls sont-ils préparés à ces nouveaux flux quand une partie des composants figurent à l'extérieur de l'entreprise ?

·        Puis le flux de traitement analytique lui-même. En Revenue Management par exemple, une bonne prévision peut prendre plusieurs secondes. C’est parfait pour un logiciel classique de « cold analytics » (calcul à froid en mode "batch" au milieu de la nuit) mais dans un centre d’appels commercial, on attend un peu plus de réactivité pour savoir si ce client pour ce type d’offre mérite une procédure particulière en fonction de la question qu’il pose. Cela amène parfois à créer plusieurs familles d’outils de prédiction selon le mode de consommation que l’on imagine. On en baisse en quelque sorte la qualité pour gagner en réactivité puisque c’est le produit pertinence.impact qui compte.

·        Enfin, le méta-flux de traitement. J’entends par là tout ce qui concerne le versioning, l’identification des auteurs des algorithmes de nettoyage et de traitement, la fraîcheur des données le long du flot. C’est à mon sens l’énorme valeur ajoutée d’une bonne plateforme de Data Science, c’est celle qui crée un effet de « patrimoine » et non un simple archivage à plat.

Croire que IA = BIG DATA

C'est une confusion naturelle puisque les GAFA, avec leurs centaines de millions de clients et donc leurs milliards d'interactions/jour, ont fortement mis en avant le Machine Learning et le Deep Learning comme éléments clés de leur conception/personnalisation de produit. Et d'offrir l'algorithme en Open Source, en poussant le Cloud pour stocker le tout. Mais toutes les entreprises n'ont pas des milliards de clics.

A trop s'acharner sur la prédiction on peut en oublier la décision, ou mieux la séquence de décisions qui amène à un objectif commercial ou opérationnel donné. Le travail en séquence de décisions, dans des conditions d'incertitudes, fait lui aussi l'objet de révolution dans le domaine de l'Intelligence Artificielle : Le Reinforcement Learning. Rappelons-nous qu'AlphaGo Zero, la dernière génération d'IA joueuse de Go, n'a besoin d'aucune donnée d'entrée, d'aucune partie humaine jouée. Elle les génère elle-même, 4,9 millions de fausses parties en 3 jours, pour finir par devenir la meilleure joueuse au monde avec la simple connaissance des règles du jeu. Beaucoup de processus de l'entreprise peuvent se simuler, en s'inspirant de données passées - mêmes incomplètes - ou avec des scénarios décrivant les futurs possibles. Quand le profil de risque de la décision est très dissymétrique, la machine s'avère nettement plus douée que l'homme. C'est déjà le cas en gestion de stock ou en pricing par exemple.

Embaucher un Chief Data Officer qui ne code plus (ou qui n’a jamais codé)

Il est tellement facile en face du Comex de dessiner des plans sur la comète pour l’Intelligence Artificielle à 5 ans, quand la seule limite est la taille de la police de caractères du Power Point. C’est acceptable pour un consultant qui décrit une vision macro-économique de la technologie, mais pas pour un CDO. La stratégie IA d’une entreprise trouve son facteur limitant dans la qualité de la donnée collectée (ou à collecter/générer) et dans la résistance des processus à leur « disruption décisionnelle ». Pour s’en rendre compte et donc un tant soit peu anticiper, le décideur du Comex doit toucher du doigt cette donnée et rester un minimum au contact avec les Data Scientists pour comprendre où ça coince et définir les bonnes priorités, avec les bons budgets. Il me semble une hygiène saine d’encourager cette démarche à l’aide de séances de manipulation concrète de jeux de données de l'entreprise. Comme il est plus dur de le demander au Directeur Commercial c’est au CDO de s’y coller. Le story telling n’en sera que plus savoureux.

Le couple maudit « KPI/Business Rules »

La blouse brodée de l’Intelligence Artificielle se situe peut-être dans cet usage addictif du cocktail KPI/Business Rules que font les grands groupes pour piloter leur processus métiers. Le KPI est un prisme déformant de la décision, agrégateur, qui décompose un raisonnement en silo. Il vient faire barrage à la boucle de décision/feedback dont a besoin l’IA pour se nourrir, sentir l’impact de la décision et apprendre. La Business Rule, quant à elle, vient rigidifier le processus - minimiser l’espace du réalisé – et crée une excroissance logicielle dont il est extrêmement délicat de se sevrer.

La business rule, c’est l’arthrose décisionnelle.

Les éditeurs de logiciels le savent bien : ils en vivent. La culture du 80/20 est redoutablement prégnante. Quand j’initie des audits Pricing je suis presque systématiquement déçu du peu de « Price Point » explorés par l’entreprise. Les augmentations ou baisses de prix sont souvent très simples (+10%, -20%) et les clichés sont abondants « le prix doit finir par 9 », « Il faut au moins être 10% au-dessous d’Amazon pour passer » et implémentés en dur dans les Business Rules des algorithmes. On retrouve les mêmes patterns en maintenance prédictive ("refaire une chaussée tous les 10 ans") ou en gestion de stock ("quand le seuil pour les produits A est atteint alors réapprovisionner").

Confondre Product Owner et assistance à maîtrise d’ouvrage

La mode est au développement agile et on ne peut que s’en réjouir. Même si le cérémonial fait un peu penser à une salle de classe d’école Montessori par moment, il y a énormément de vertu à cette forme de développement et de structuration d’équipe que cela semble une bonne affaire pour l’Intelligence Artificielle. Pour autant que les Product Owners soient matures en termes de pilotage de projets de transformation et cultivés analytiquement. J’insiste sur ce dernier point. Or, par définition, de tels types de profils sont très rares en entreprise, qui n’ont pas eu ou peu eu de motifs d’en générer jusqu’à présent. Il faut penser Data Science dans la tactique même d'évolution du produit.

Piloter un produit IA-intensif n’est pas une mince affaire et tout ne s’explique pas avec un MVP en 15 jours de sprint. Une des raisons est le risque intrinsèque que l’on prend quand on fait un choix de méthodes d’IA sur une certaine typologie de donnée.

·        Il faut que la donnée s’y prête de bonne grâce, d’une part, et cela se pense à l’origine, sinon on se retrouve à attendre un an pour avoir des capteurs au bon endroit d’une chaîne logistique. La profondeur de la donnée intervient souvent comme facteur limitant d'une approche IA.
·        Que le produit prédictibilité.impact apporte du bénéfice. On peut sous-prévoir un comportement client qui abandonne son acte d’achat sur le web mais cela suffit pour faire une grossière contre-proposition. Mais on peut aussi changer son fusil d’épaule selon le type de prédictibilité que l’on est capable d’obtenir (sur un sous-ensemble de clients par exemple). On voit encore trop souvent des projets Data Science initiés par le métier avec un « objectif » à 99% de qualité de prévision. Comme si cette incantation suffisait à éliminer le risque. Cette exploration des zones prédictibles, des faux positifs et négatifs est au coeur de la démarche itérative et donnera naissance à des branches de décisions diverses
·        Cette démarche à tâtons peut se faire en agile, mais le niveau d'incertitude doit être appréhendé par des approches spécifiques comme le « dual track » : des équipes pionnières dédiées à des études un peu amont pour dégrossir, ouvrir des voies ou les condamner.

Un mauvais deal IT + BI + IA

Donner des recommandations sur la gouvernance de ces trois entités qui « s’occupent » de la data et de l’aide à la décision est une prouesse à laquelle je ne me livrerai pas. Mais clairement, ça va traîner si le deal est mal fait.
-         Chacune des trois cultures a ses atavismes, techniques, humains et fonctionnels. Et les Ayatollah y sont nombreux
-         Chacune a un style pour s’adresser au métier, ce style créant des modes de gouvernance et des pratiques différents (budgets, nature des spécifications, niveau d’externalisation, choix des outils de production, rapport à l’open source, à la disponibilité voire à la testabilité)
-         Et l’IA, la plus jeune des trois, la moins industrialisée, mais la plus intensivement consommatrice de données, se trouve facilement handicapée/étouffée par une des deux autres, tant elle en dépend.

On constate différentes surfaces de freinage. L’accès à la donnée en provenance du Système d’Information, nous en avons parlé. La certification des flux de données au sein du nouveau processus de décision, ainsi que son monitoring. En aval, l’accès du système d’information aux données ou recommandations de la plateforme d’IA.
Si l’entreprise est très immature en BI, le simple accès à la donnée, la transparence apportera des bénéfices immenses et IA et BI seront très liées, il faut les regrouper et sans doute créer des équipes hybrides. Si inversement la BI a une position forte dans les tableaux de bords des grands et petits décideurs, son remplacement sur une partie des processus sera plus complexe à mettre en place et il faudra faire évoluer l’équipe BI pour qu’elle soit un acteur de cette évolution. Enfin, sortir d’une culture maîtrise d’ouvrage maîtrise d’œuvre, traditionnelle en IT et en BI quand beaucoup de travaux sont externalisés ou délocalisés, n’est pas une mince affaire. 

Je suis de ceux qui pensent que l’IA fait partie d’une fonction IT étendue : elle ne peut vivre en isolation sous peine de ne jamais passer à l'échelle. Qu’un axe Data fort doit émerger et être mis en avant, autour de la plateforme IA, avec un rôle d’ingénierie de la donnée neutre et servant les deux fonctions BI et IA. Et qu’il est de la responsabilité de l’IT de créer un point de contact par domaine avec le métier, qui regroupe les trois fonctions, car l’IA in fine produit du logiciel aux mêmes exigences opérationnelles qu’une application transactionnelle. La distinction "transactionnel/décisionnel" est une vue de l'esprit à l'ère de l'IA. Mais le DSI n’ayant pas toujours développé cette sensibilité, il faut s’assurer de lui injecter les stéroïdes dans les bons muscles. 

Nous avons tous besoin de nos blouses brodées et les KPIs ont encore de beaux jours devant eux, ne serait-ce que pour contrôler si les bébés IA ne marchent pas en dehors des clous. Mais la chasse aux Business Rules est ouverte et la résistance des processus et de ceux qui les incarnent dans l’entreprise explique pour une grande part les freins constatés.

La création des nouvelles fondations de la donnée (en Lake et en flux) est une tâche immense presque toujours sous-estimée dans les pitchs des stratèges. Il s'agit de plusieurs années de travail acharné à la croisée de l'IT et de la Data Science. On peut toujours essayer d'utiliser de l'IA pour nettoyer les données, mais c'est faire trop d'honneur au bruit. La mise à disposition de ces nouvelles données, leur interprétation métier, est une révolution pour la culture BI traditionnelle aussi elle prend du temps, un temps incompressible. Enfin la refonte des processus métiers avec une approche IA native demande probablement de nouveaux Product Owners et de nouveaux décideurs pour les guider, leur servir de brise-glace et leur laisser les mains libres pour explorer, apprendre à dresser et cohabiter avec leurs IA. Lorsque des produits logiciels bousculent à la fois les flux de données, les processus et l'offre au client ils sont de véritables OVNI pour un grand groupe.