Imaginons un service de Middle Office chargé de traiter au quotidien les demandes de ses clients (réclamations, modifications de contrat, demandes de documents, etc.), qui lui parviennent par écrit ou par téléphone. Trois équipes se partagent le flux. Le délai moyen de réponse est de quatre jours, les clients s'en plaignent. La direction veut accélérer le traitement des demandes.

Un projet IA est lancé, et un chef de projet désigné. Pour tous les acteurs, accélérer le traitement des demandes, c'est accélérer le travail des gestionnaires, et la solution cible apparaît évidente : un assistant qui analyse chaque demande écrite, la catégorise et rédige un projet de réponse que le gestionnaire n'a plus qu'à relire et ajuster. Les demandes téléphoniques restent hors périmètre. Les objectifs du POC sont fixés en conséquence : réduire le temps de traitement des tâches incombant au gestionnaire.

Pour préparer l'extension, l'assistant est paramétré à partir de l'historique des trois équipes, notes des appels téléphoniques comprises, et l'on rassemble leurs modèles de réponse. Le POC est étendu à une partie du flux écrit de chaque équipe. Avec le volume et la diversité des demandes, le risque change d'échelle. Par prudence, on ajoute un contrôle propre au POC : chaque projet de réponse est vérifié sur le fond par un second gestionnaire avant de partir en validation chez le responsable. Ce contrôle étant une précaution du projet, et non une étape du processus amenée à perdurer, sa durée n'est pas comptée dans le temps de traitement des gestionnaires mesuré dans le cadre du POC.

Entre-temps, les catégories ont été harmonisées, les modèles de réponse standardisés et validés, la relecture renforcée, et le contrôle propre au POC a été levé. Les indicateurs du POC sont au vert : l'assistant fonctionne, et le temps de traitement des tâches incombant au gestionnaire est bien tombé à dix minutes.

Personne n'a observé le processus dans son ensemble : l'attention s'est entièrement portée sur l'étape de traitement par les gestionnaires, sans rapporter la demi-heure qu'elle représentait aux quatre jours que met une demande à traverser le processus de bout en bout. Deux présupposés ont présidé au cadrage du POC : que l'on savait où se situait le problème (le temps de traitement des tâches incombant au gestionnaire), et que la solution était évidente (l'accélérer).

Les objectifs du POC ont été établis sur la base de ces présupposés : on s'est focalisé sur la tâche, pas sur le processus (voir la notion d'optimum local et d'optimum global développée dans notre article consacré à l'ouvrage de José Gramdi, La boucle vertueuse de l'excellence). Or, ce qui préoccupait les clients, c'était le délai de réponse. La direction ne l'a pas formulé : sa consigne (« accélérer le traitement des demandes ») a été comprise comme une affaire de temps de traitement. Des objectifs construits à partir de la Voix du Client, comme le veut la phase Définir d'une démarche DMAIC (Définir, Mesurer, Analyser, Améliorer, Maîtriser), auraient porté sur ce délai (voir notre article sur la Voix du Client en gestion de projet). Les objectifs du POC relevaient en réalité de la Voix du Business : un gain de productivité, légitime en soi, mais sans retombée garantie pour le client.

Paramétré à partir de l'historique des trois équipes, l'assistant en a reproduit fidèlement les incohérences. On pourrait n'y voir qu'un problème de qualité des données, donc un problème technique. Ce serait oublier que les données sont le sous-produit des processus, la trace d'une manière de faire. Si le processus n'est pas standardisé, les données ne peuvent pas l'être ; et les notes des appels téléphoniques, rédigées par chaque gestionnaire à sa manière, ajoutaient encore à la variabilité. Une IA paramétrée à partir de ces données reflète alors ce que l'on a consigné (approximations comprises), et non ce que l'on devrait faire. Nettoyer les données sans standardiser le processus revient à vider la baignoire sans fermer le robinet.

C'est un principe de base de l'amélioration continue : on ne peut pas améliorer un processus qu'on n'a pas d'abord stabilisé autour d'un standard (voir notre article consacré à la standardisation). On ne peut pas davantage l'automatiser. Car améliorer un processus, c'est d'abord le rendre robuste, c'est-à-dire répétable et le moins variable possible.

Pourquoi une partie des erreurs a-t-elle franchi la relecture des gestionnaires ? Pas par négligence. Les projets de réponse étaient propres, bien rédigés, plausibles, et les gestionnaires, passés du rôle de rédacteur à celui de relecteur, les lisaient de moins en moins en détail. Le phénomène porte un nom, la « complaisance envers l'automatisation » : Raja Parasuraman et Dietrich Manzey ont montré en 2010 qu'il touche aussi bien les novices que les experts, et que l'entraînement ne suffit pas à l'éviter. Un processus manuel défaillant fait du bruit ; un processus automatisé défaillant peut rester silencieux un certain temps. Sans le contrôle propre au POC, décidé par prudence, l'erreur de modèle aurait pu atteindre les clients. On ajoute ainsi à un problème de qualité un problème de détection, soit une combinaison coûteuse.

Rappelons que le Business Case reposait sur des gains de productivité. Or, plus un défaut est détecté tard dans le processus, plus sa correction coûte cher (voir notre article sur l'autoqualité). On l'observe notamment dans le développement logiciel : Barry Boehm et Victor Basili estimaient, en 2001 déjà, que trouver et corriger un défaut logiciel après livraison coûte souvent 100 fois plus cher qu'au stade de la conception (un facteur qu'ils ramenaient plutôt à 5 pour les petits systèmes non critiques). Le contexte diffère de celui de notre service et l'ordre de grandeur varie ; le sens, lui, ne change pas. Arrêtée à la source, au moment de la conception du modèle de réponse, l'erreur aurait coûté une simple correction. Détectée au contrôle, elle a coûté la reprise de dizaines de dossiers. Si elle avait atteint les clients, elle aurait coûté des réclamations à traiter et de la confiance à reconquérir. De quoi entamer sérieusement les économies promises par le Business Case.

Au mois 4, les indicateurs du POC étaient au vert, le délai client au rouge : c'est ce que l'on appelle couramment l'effet pastèque. Pour comprendre pourquoi le délai n'a pas bougé, il suffit de suivre une demande de bout en bout. Sur quatre jours, elle passait une demi-heure (dix minutes avec l'assistant) entre les mains d'un gestionnaire ; le reste du temps, elle attendait : d'être affectée, d'être validée par un responsable, ou qu'une autre entité fournisse une information manquante. Un constat banal dans les activités de service (voir notre synthèse de l'ouvrage Making IT Lean).

Notre service est fictif, mais sa trajectoire est banale. Les données disponibles sur les projets IA proviennent de sources et de méthodologies différentes, et aucune n'est parfaite. Elles convergent néanmoins.

Mettre en œuvre une approche processus passe par quatre étapes : identifier et classer les processus, les formaliser, organiser leur pilotage, puis les piloter selon les principes du PDCA (pour Plan, Do, Check, Act, voir notre article sur l'amélioration continue). Ces étapes constituent les prérequis d'un projet IA qui a une chance de réussir. On peut en tirer cinq questions, valables pour n'importe quel processus, à se poser avant de lancer le moindre POC.

Première approche : stabiliser d'abord, automatiser ensuite. C'est le terrain naturel de la démarche DMAIC, présentée dans notre article sur le Lean Six Sigma. La phase Mesurer aurait montré, dès le départ, que l'essentiel des quatre jours se passait en attentes (d'affectation, de validation) et en allers-retours avec une autre entité. L'analyse aurait pu conduire à supprimer la validation systématique pour les demandes standard, à harmoniser les catégories entre les équipes et à fixer un délai de réponse interne à l'autre entité. La phase Maîtriser aurait ensuite permis d'ancrer ces changements : un standard partagé par les trois équipes, un propriétaire désigné pour le processus de bout en bout, des indicateurs suivis en PDCA.
Une fois le processus maîtrisé, l'assistant IA serait arrivé sur un terrain prêt, avec un standard à amplifier, des indicateurs pour prouver son apport et un propriétaire pour le gouverner. Cette approche est moins spectaculaire. Elle peut révéler, au passage, qu'une bonne partie du gain attendu via l'IA pouvait être obtenue sans elle.

Dans notre exemple, le projet a été lancé à partir d'une solution, et non d'un problème. Partir de la solution est parfois nécessaire (un changement d'ERP ou une contrainte technologique externe, par exemple). Même dans ce cas, le rôle du chef de projet ne se limite pas à la mettre en œuvre : il lui revient de challenger le besoin, de faire exprimer à la direction un objectif SMART et de s'assurer que le problème et ses causes sont réellement connus. Présent dès le cadrage du POC, notre chef de projet aurait pu demander à la direction ce qu'elle entendait par accélérer le traitement des demandes, et s'étonner que les objectifs du POC ne reflètent pas la Voix du Client : portant sur le temps de traitement, ils ne remplissaient pas le critère d'alignement de la méthode SMART.

Borner le rôle du chef de projet à celui d'un super exécutant, chargé de mettre en œuvre des solutions clé en main, constitue donc, de notre point de vue, une erreur. La valeur ajoutée d'un chef de projet s'exprime pleinement lorsqu'on lui confie un enjeu de performance à traiter : poser les bonnes questions, analyser le processus, identifier les causes racines de ses dysfonctionnements, proposer et mettre en œuvre les solutions qui y répondent, et accompagner le changement qu'elles impliquent. Autrement dit, décider sur quoi l'on branche l'IA avant de la brancher.

Revenons alors à la prophétie de départ. Gartner évoquait 80 % des tâches de gestion de projet et de PMO absorbées par l'IA, en citant la collecte de données, le reporting et le suivi. Soit : ce sont précisément des tâches d'exécution, a priori les plus faciles à automatiser. Et encore : de notre expérience, savoir où en est réellement une tâche, et ce qui reste à faire, demande souvent une discussion avec ceux qui la réalisent, tant l'information est rarement disponible, d'emblée, sous une forme exploitable. Or, automatiser ces tâches suppose que les flux d'information sur lesquels elles reposent soient fiables, et notre exemple montre ce qu'il advient lorsqu'ils ne le sont pas.

Si l'IA reprend une part croissante des tâches d'exécution, elle rend d'autant plus nécessaire ce qu'elle ne fait pas : poser le problème avant de choisir la solution, puis accompagner les changements que celle-ci induit. C'est en cela que les chefs de projet ont, nous semble-t-il, encore de beaux jours devant eux.

Garbage in, garbage out : l'expression apparaît dans la presse américaine dès 1957, dans le jargon des mathématiciens de l'armée qui faisaient tourner les premiers ordinateurs. L'idée est plus ancienne encore : en 1864, Charles Babbage, pionnier des machines à calculer, racontait qu'on lui avait demandé à deux reprises si, en entrant de mauvais chiffres dans sa machine, on en obtiendrait les bonnes réponses, avouant ne pas parvenir à concevoir « le genre de confusion d'idées » qui pouvait provoquer une telle question. Plus d'un siècle et demi plus tard, on se la pose à propos de l'IA. La règle vaut toujours, à deux nuances près : la sortie médiocre est produite plus vite, et elle a l'air plus convaincante.