Retour en arrière sur l’IA : Récits authentiques de dirigeants
Leçons sur l’IA: Beaucoup de dirigeants négligent les enseignements précieux issus des projets d’IA abandonnés ou mis en pause, alors qu’ils révèlent des informations cruciales.
Privilégier la pause: Les entreprises tirent souvent profit d'une pause dans les initiatives IA afin d’établir des processus de base et d’assurer la qualité des données.
D’abord le manuel: L’automatisation ne doit venir qu’après l’exécution manuelle, pour garantir que les processus soient clairement définis et compris.
Mesurer l’impact: La clé du succès réside dans l’évaluation des processus actuels et de l'impact potentiel de l’IA avant de commencer son déploiement.
Importance de la documentation: Une documentation efficace doit recenser non seulement les processus, mais aussi les raisons des choix et les exceptions rencontrées.
La plupart des histoires d’adoption de l’IA se racontent depuis le podium des vainqueurs. Bien moins de dirigeants relatent le moment où ils ont coupé court — l’automatisation annulée, le déploiement suspendu, le pilote à reconstruire de zéro. Pourtant, ce sont souvent dans ces récits que résident les vraies leçons.
Nous avons interrogé trois experts qui y sont déjà passés : qu’est-ce qui a été annulé, pourquoi, et que referaient-ils différemment ? Leurs réponses convergent vers un constat étonnamment cohérent — le problème ne vient presque jamais de l’IA elle-même.
Quand il vaut mieux faire une pause plutôt que d’avancer coûte que coûte
Pour la plupart des organisations, abandonner purement et simplement un investissement IA n’est pas réaliste une fois l’argent investi. Tejinder, Senior Manager chez Deloitte Consulting, explique que le retrait pur et simple n’était pas envisageable vu les investissements engagés — mais une pause délibérée l’était. Lorsque les résultats n’étaient pas satisfaisants, son équipe a pris du recul et a “revu les bases d’abord”, se demandant si les processus fondamentaux étaient en place, si “la qualité des données” était “bonne” et si les planificateurs comprenaient le rôle des agents par rapport au leur. “Je pense qu’une fois ces questions clarifiées, la réactivation s’imposait naturellement,” témoigne-t-il.
Déverrouillez gratuitement
Créez un compte gratuit pour terminer la lecture de cet article et rejoindre une communauté de leaders innovants qui accèdent à des outils, des méthodes et des idées pour prospérer à l’ère de l’IA.
Have an account? Log In
Priyanka Dave, PhD, responsable du développement des compétences et propriétaire des processus d’apprentissage à l’Oregon State University, a observé le même schéma se répéter. « J’ai vu plusieurs organisations retarder volontairement l’expansion des initiatives d’IA après avoir constaté qu’elles n’étaient pas prêtes opérationnellement. » Dans ces cas, le retrait n’a pas été un échec, mais une redirection. « Plutôt que de déployer l’IA immédiatement, la direction a choisi de renforcer d’abord la fondation organisationnelle », détaille Dave. Cela passait par « la documentation des processus métier, la standardisation des workflows, l’amélioration de la gouvernance des données, et le développement des compétences des employés via des formations structurées et la gestion du changement. »
Plutôt que de déployer l’IA immédiatement, la direction a choisi de renforcer d’abord la fondation organisationnelle.
N’automatisez pas tant que vous ne l’avez pas fait manuellement
Parfois, revenir en arrière signifie annuler un projet purement et simplement — et découvrir que c’était en réalité la bonne décision. Jaime Gil Martinez, Fondateur et Consultant Principal chez Swift Ops Solutions, l’a appris à ses dépens. « J’ai un jour développé une automatisation pour créer des supports marketing pour un client qui n’avait jamais effectué ce processus manuellement auparavant, » se souvient-il. « Comme c’était nouveau pour eux, on s’est dit qu’il était préférable de tout automatiser dès le début. Sur le papier, l’idée paraissait sensée. Avec du recul, c’était une erreur de débutant. »
Le système fonctionnait d’un point de vue technique. « L’automatisation marchait », précise Gil Martinez. « Le problème, c’est qu’à chaque nouvel output, il fallait repenser ou ajuster quelque chose (nouvelle cible, nouveau format, nouvelle mise en page), donc je me retrouvais à tout reconstruire. Après quelques itérations, le schéma est devenu évident : j’automatisais un processus que personne n’avait encore défini. »
Après quelques itérations [d’ajustements], il est devenu évident que j’automatisais un processus que personne n’avait défini.
La solution a été de revenir en arrière. « Nous avons donc annulé le projet et recommencé à produire les supports à la main », explique-t-il. « Cela s’est révélé déterminant car chaque itération manuelle nous a apporté ce qui nous manquait jusque-là : des exemples de référence et une vue claire sur ce qui variait ou pas. Nous avons repris l’automatisation ensuite, et cette production manuelle est devenue la base de connaissances fournie à l’IA. » Cette expérience a donné naissance à une règle maintenant généralisée dans son entreprise et chez ses clients : « n’automatisez rien avant de l’avoir fait au moins trois fois manuellement. Après seulement, vous pouvez commencer à l’envisager. »
L’étape que tout le monde oublie : mesurer avant de construire
Demandez à Gil Martinez ce qui manque le plus souvent dans les plans d’adoption de l’IA, il répond immédiatement : « Mesurer avant de construire. La plupart des entreprises commencent sans deux chiffres essentiels : le niveau d’efficacité ou d’inefficacité de leur processus actuel, et l’impact réaliste que l’IA pourrait avoir dessus. Sans ces deux mesures, vous ne pouvez pas évaluer l’efficacité de votre implémentation, ni savoir si le coût était justifié. »
Il cite l’exemple d’une clinique de santé qui voulait automatiser la planification pour plus de 100 patients. « Ils ne savaient pas combien de temps cela leur prenait, seulement que c’était chronophage et frustrant, » explique-t-il. « Et si vous ne connaissez pas la durée, vous ne pouvez pas savoir combien cela vous coûte. » Avant de construire quoi que ce soit, sa première étape a donc été de calculer les heures consacrées à la planification et la valeur financière de ces heures. « Cela nous a donné une base : deux semaines de travail entièrement manuel. L’automatisation a réduit ce délai à une journée de travail assisté par IA, pour un coût inférieur à ce qu’ils dépensaient déjà. » Avec ces chiffres, « la décision s’est prise d’elle-même. »
Dave pointe une omission différente mais tout aussi critique : la préparation ne concerne pas que la technologie. « L’étape que je vois le plus souvent négligée par les organisations, c’est l’évaluation des compétences du personnel avant d’implémenter l’IA, » dit-elle. Et les écarts ne concernent rarement la prise en main des outils. Au fil de plusieurs évaluations de compétences, « les analyses ont régulièrement montré que les lacunes les plus importantes concernaient la pensée analytique, la pensée critique, la culture des données, la communication consultative et la résolution de problèmes. » Sa conclusion : « La préparation technologique et celle de la main-d’œuvre sont deux défis différents. Pour une adoption de l’IA durable, il faut les deux. »
Quand l’IA arrive sur un processus qui n’est pas prêt
Qu’est-ce qui casse vraiment quand on ajoute l’IA à un processus immature ? Tejinder l’a vu de près lorsque « l’IA a été intégrée à un processus métier (traitement et allocation des commandes) qui n’était pas assez mature » — le résultat : une solution pleine de bugs. Mais il précise où se situait le problème : « Je pense que l’IA n’était pas en cause ici, » affirme-t-il, pointant plutôt la maturité du processus, les problèmes de données maîtres, les besoins non couverts et des tests insuffisants.
L’IA a été intégrée à un processus métier (traitement et allocation des commandes) qui n’était pas assez mature.
Dave décrit la même dynamique à travers ses analyses : des services différents accomplissant les mêmes tâches de manières différentes, une documentation incomplète, des exceptions seulement connues des employés. « On craignait que l’IA ne fasse que reproduire ces pratiques incohérentes dans toute l’organisation, » explique-t-elle. C’est la conséquence d’un principe auquel elle revient souvent : « L’IA ne résout pas les problèmes organisationnels. Elle amplifie les systèmes existants. Si les processus sont incohérents ou mal documentés, l’IA va souvent amplifier ces incohérences plutôt que de les corriger. » Pour elle, la leçon est claire : « La leçon récurrente était qu’il vaut mieux améliorer les processus avant d’essayer de les automatiser. »
Si les processus sont incohérents ou mal documentés, l’IA va souvent amplifier ces incohérences plutôt que de les corriger.
Gil Martinez a lui aussi accumulé de l’expérience dans ce domaine — une application de génération de leads qui « a échoué spectaculairement la première fois. » Le projet est passé directement d’un mode semi-manuel à une automatisation totale sans exigences ni tests définis. « Mon erreur a été de supposer que l’IA trouverait d’elle-même certaines logiques, parce qu’elles semblaient évidentes et simples, » admet-il. Les choses se sont ensuite compliquées. « Le code est devenu ingérable et totalement sous le contrôle de l’IA, au point que je ne pouvais plus revenir à une étape sûre. C’est à ce moment-là que j’ai compris que ce n’était pas qu’un simple bug, mais une rupture structurelle. »
La solution a nécessité une remise à zéro complète. « La correction, aussi douloureuse qu’évidente : tout recommencer, » raconte-t-il. « Cette fois, j’ai défini chaque exigence et un test associé, construit petit à petit, donné à l’IA des instructions claires pour consigner les échecs et réussites, avec une gestion de versions appropriée. » Cette approche rigoureuse « a pris environ la moitié du temps gâché lors de la première tentative pour aboutir à une solution exploitable et de niveau production. »
À quoi ressemble une bonne documentation pour l’IA ?
Derrière les trois histoires se cache le même remède : une documentation qui reflète réellement la façon dont le travail s’effectue. Pour Dave, il faut aller au-delà de la simple liste de tâches. « Une bonne documentation de processus explique non seulement ce que font les gens, mais aussi pourquoi ils prennent certaines décisions, » affirme-t-elle. Et le contenu le plus précieux est souvent ce qui n’est jamais mis par écrit. « Une des erreurs les plus courantes des organisations consiste à ne documenter que le flux standard. Mais la connaissance organisationnelle la plus précieuse réside souvent dans les exceptions, les jugements empiriques et les décisions contextuelles prises par les employés expérimentés. »
Gil Martinez l’explique à travers une perspective que les chefs de projet vont de plus en plus reconnaître : « Une bonne documentation de processus reflète la conception de prompt. Les mêmes éléments que nous avons appris à donner à l’IA dans un prompt (rôle, contexte, tâche, instructions, contraintes) doivent apparaître au niveau du projet. » Ce changement a des conséquences sur la façon dont les praticiens passent leur temps. « Le temps d’exécution pour les humains disparaît, délégué à l’IA, il faut donc se concentrer sur une bonne planification et la validation des résultats. Nous devons agir comme des gestionnaires d’IA. »
Conclusion : La séquence fait la stratégie
Aucun de ces dirigeants ne regrette d’avoir investi dans l’IA. Ce qu’ils regrettent — ou ce qu’ils ont vu d’autres regretter — c’est l’ordre des opérations. Tejinder résume ainsi : « L’adoption de l’IA à l’échelle de l’entreprise échoue lorsque le modèle est déployé avant les fondamentaux opérationnels. La bonne séquence est d’abord la maturité des processus, la qualité des données et la clarté des rôles. L’IA vient ensuite. Lorsque les organisations inversent cet ordre, elles blâment l’IA, mais le problème réel est presque toujours l’environnement dans lequel l’IA a été placée. » Revenir en arrière, en réalité, n’est pas l’échec. Le véritable échec, c’est de déployer avant d’être prêt.
Vous voulez plus d’informations comme celles-ci ? Inscrivez-vous à un compte DPM gratuit pour lire davantage d’avis d’experts comme ceux-ci.
