Revenir sur l’IA : témoignages authentiques de dirigeants
Leçons de l’IA: De nombreux dirigeants négligent les enseignements précieux des projets d’IA échoués ou suspendus, alors qu’ils mettent en lumière des informations essentielles.
Faire une pause plutôt que pousser: Les entreprises ont souvent intérêt à suspendre leurs initiatives d’IA afin d’établir des processus fondamentaux et d’améliorer la qualité des données.
Le manuel d’abord: L’automatisation ne devrait intervenir qu’après l’exécution manuelle, afin de garantir que les processus sont clairement définis et compris.
Mesurer l’impact: La réussite repose sur l’évaluation des processus actuels et de l’impact potentiel de l’IA avant le début de sa mise en œuvre.
L’importance de la documentation: Une documentation efficace doit consigner non seulement les processus, mais aussi le raisonnement qui sous-tend les décisions et les exceptions.
La plupart des récits sur l’adoption de l’IA sont racontés depuis le podium des vainqueurs. Bien moins de dirigeants parlent du moment où ils ont décidé de tout arrêter — l’automatisation qui a été annulée, le déploiement qui a été suspendu, le projet pilote qui a dû être reconstruit de zéro. Pourtant, c’est souvent dans ces récits que se trouvent les véritables enseignements.
Nous avons interrogé trois experts qui ont vécu ces situations : qu’est-ce qui a été annulé, pourquoi, et que feriez-vous différemment ? Leurs réponses convergent vers un thème étonnamment cohérent : le problème ne vient presque jamais de l’IA elle-même.
Quand la bonne décision consiste à faire une pause plutôt qu’à aller de l’avant
Pour la plupart des organisations, abandonner complètement un investissement dans l’IA n’est pas réaliste une fois l’argent dépensé. Tejinder, cadre supérieur chez Deloitte Consulting, affirme clairement qu’une suppression pure et simple n’était pas envisageable compte tenu des investissements déjà réalisés — mais qu’une pause délibérée l’était. Lorsque les résultats n’étaient pas à la hauteur, son équipe a pris du recul et a « commencé par examiner les fondamentaux », en se demandant si les processus sous-jacents étaient établis, 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 résolues, la réactivation avait du sens », explique-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 de la montée en 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 constaté que plusieurs organisations retardaient volontairement l’expansion de leurs initiatives d’IA après avoir reconnu qu’elles n’étaient pas prêtes sur le plan opérationnel. » Dans ces cas, le recul n’était pas un échec — c’était une réorientation. « Plutôt que d’étendre immédiatement l’IA, la direction a réorienté son attention vers le renforcement des fondations de l’organisation », explique Dave. Cela signifiait que « les organisations investissaient dans la documentation des processus métier, la standardisation des flux de travail, l’amélioration de la gouvernance des données et le développement des compétences des employés grâce à des formations structurées et à la gestion du changement. »
Plutôt que d’étendre immédiatement l’IA, la direction a réorienté son attention vers le renforcement des fondations de l’organisation.
N’automatisez pas ce que vous n’avez pas fait manuellement
Parfois, revenir en arrière signifie annuler purement et simplement un projet — et découvrir que c’était la bonne décision depuis le début. Jaime Gil Martinez, fondateur et consultant principal chez Swift Ops Solutions, l’a appris à ses dépens. « J’ai un jour créé une automatisation pour produire des supports marketing pour un client qui n’avait jamais exécuté le processus manuellement », se souvient-il. « Comme c’était nouveau pour lui, nous avons tous les deux pensé qu’il valait mieux créer directement une automatisation à partir de zéro. Sur le papier, cela semblait logique. Avec le recul, c’était une erreur de débutant. »
Le système fonctionnait techniquement. « L’automatisation marchait », explique Gil Martinez. « Le problème, c’est qu’à chaque fois qu’un résultat était nécessaire, il fallait reconsidérer ou ajuster quelque chose (une cible différente, un format différent, une mise en page différente), alors je n’arrêtais pas de la reconstruire. Après quelques cycles de ce genre, le schéma était évident : j’automatisais un processus que personne n’avait encore défini. »
Après quelques cycles [d’ajustements], il était évident que j’automatisais un processus que personne n’avait encore défini.
La solution consistait à revenir en arrière. « Nous avons donc annulé le projet et recommencé à produire les supports à la main », explique-t-il. « C’est là que résidait l’intérêt : chaque série manuelle nous apportait ce qui nous manquait, à savoir des exemples de référence et une vision claire de ce qui variait et de ce qui ne variait pas. Nous avons ensuite repris l’automatisation, et ces résultats manuels sont devenus la base de connaissances que nous avons transmise à l’IA. » Cette expérience lui a inspiré une règle qu’il applique désormais à sa propre entreprise et à celles de ses clients : « n’automatisez rien avant de l’avoir fait manuellement au moins trois fois. Ensuite, vous pourrez commencer à l’envisager. »
L’étape que tout le monde néglige : mesurez avant de construire
Demandez à Gil Martinez ce qui manque à la plupart des plans d’adoption de l’IA, et sa réponse est immédiate : « Mesurer avant de construire. La plupart des entreprises ne disposent pas de deux chiffres au moment de se lancer : la qualité réelle de leur processus actuel, et l’impact que l’IA pourrait concrètement avoir sur celui-ci. Sans ces deux éléments, impossible de déterminer l’efficacité de la mise en œuvre ou de savoir si son coût était justifié. »
Il évoque une clinique qui souhaitait 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 savez pas combien de temps cela prend, vous ne savez pas combien cela vous coûte. » Avant de construire quoi que ce soit, sa première étape a donc consisté à calculer le nombre d’heures consacrées à la planification et la valeur financière de ces heures. « Cela nous a donné la référence de départ : deux semaines de travail entièrement manuel. L’automatisation a ramené ce délai à une journée de travail assisté par l’IA, pour un coût inférieur à leurs dépenses équivalentes actuelles. » Avec ces chiffres en main, « la décision s’est imposée d’elle-même ».
Dave constate une autre lacune, tout aussi essentielle : la préparation ne concerne pas uniquement la technologie. « L’étape que les organisations négligent le plus souvent, selon moi, consiste à évaluer les capacités de leur personnel avant de mettre en œuvre l’IA », explique-t-elle. Et les lacunes ne concernent que rarement la formation aux outils. Dans plusieurs évaluations des capacités, « les analyses ont systématiquement révélé que les principales lacunes 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 est claire : « La préparation technologique et la préparation du personnel sont deux défis différents. Une adoption durable de l’IA nécessite les deux. »
Quand l’IA s’appuie sur un processus qui n’est pas prêt
Que se passe-t-il concrètement lorsque l’IA est ajoutée à un processus immature ? Tejinder l’a constaté directement lorsque « l’IA a été intégrée à un processus métier (traitement des commandes et répartition) qui n’était pas suffisamment mature » — le résultat a été une solution truffée de bugs. Mais il précise clairement où se situait le problème : « Je ne pense pas que l’IA était le problème ici », affirme-t-il, en pointant plutôt du doigt la maturité des processus, les problèmes de données de référence, les lacunes non comblées dans les exigences et les tests insuffisants.
L’IA a été intégrée à un processus métier (traitement des commandes et répartition) qui n’était pas suffisamment mature.
Dave décrit la même dynamique dans le cadre de ses évaluations : différents services effectuant le même travail de manière différente, une documentation incomplète et des exceptions qui n’existent que dans la tête des employés. « La crainte était que l’IA ne fasse que reproduire des 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 reproduire ces incohérences à grande échelle au lieu de les améliorer. » La conclusion, selon ses propres termes : « La leçon récurrente était que les organisations devraient améliorer leurs processus avant d’essayer de les automatiser. »
Si les processus sont incohérents ou mal documentés, l’IA va souvent reproduire ces incohérences à grande échelle au lieu de les améliorer.
Gil Martinez a lui aussi connu ce genre de revers — une application de génération de prospects qui « a échoué de manière spectaculaire la première fois ». Le développement est passé d’un fonctionnement semi-manuel à une automatisation complète sans exigences ni tests définis. « Mon erreur a été de supposer que l’IA trouverait seule une partie de la logique, parce que cette logique me semblait évidente et simple », reconnaît-il. Les choses ont ensuite dégénéré. « Le code est devenu ingérable et entièrement contrôlé par l’IA, au point que je ne pouvais plus revenir à une étape stable. C’est à ce moment-là que j’ai compris que le problème était structurel, et pas simplement lié à des bugs. »
La récupération a nécessité une remise à zéro complète. « La solution était aussi douloureuse qu’évidente : recommencer », explique-t-il. « Cette fois, j’ai détaillé chaque exigence ainsi qu’un test pour chacune d’entre elles, j’ai construit la solution progressivement et donné à l’IA des instructions claires pour consigner les échecs et les réussites, tout en utilisant un contrôle de version approprié. » Cette seconde tentative, menée avec rigueur, « a pris environ la moitié du temps que j’avais perdu lors de la première pour parvenir à une solution exploitable et de qualité production. »
More Articles
- Le problème de gouvernance des données liées à l’IA que les responsables des opérations ne peuvent ignorer
- Un leader de la livraison chez Google explique comment les workflows agentiques transforment les modèles de gestion de produit
- La confidentialité dès la conception : élaborer une stratégie d’IA qui ne compromet pas la confiance
À quoi ressemble réellement une bonne documentation pour l’IA
Derrière ces trois histoires se trouve la même solution : une documentation qui décrit la manière dont le travail est réellement effectué. Pour Dave, cela signifie aller au-delà des listes de tâches. « Une bonne documentation des processus explique non seulement ce que font les collaborateurs, mais aussi pourquoi ils prennent certaines décisions », explique-t-elle. Et les informations les plus précieuses sont généralement celles qui ne sont jamais consignées. « L’une des erreurs les plus courantes des organisations consiste à ne documenter que le flux de travail standard. La plus grande part des connaissances organisationnelles se trouve souvent dans les exceptions, les décisions fondées sur le jugement et les choix contextuels effectués par les employés expérimentés. »
Gil Martinez l’exprime à travers un prisme que les responsables de projet reconnaîtront de plus en plus : « Une bonne documentation des processus ressemble à l’ingénierie des invites. Les mêmes éléments que nous avons appris à donner à l’IA dans une invite (rôle, contexte, tâche, instructions, contraintes) devraient apparaître au niveau du projet. » Ce changement a des implications sur la manière dont les professionnels consacrent leur temps. « Le temps d’exécution des humains disparaît, externalisé à l’IA ; nous devons donc nous concentrer sur une bonne planification et sur la validation des résultats. Nous devons nous comporter comme des responsables de l’IA. »
Conclusion : l’ordre des étapes constitue la stratégie
Aucun de ces dirigeants ne regrette d’avoir investi dans l’IA. Ce qu’ils regrettent — ou ont vu d’autres regretter —, c’est l’ordre des opérations. Tejinder résume ainsi la situation : « L’adoption de l’IA en entreprise échoue lorsque le modèle est déployé avant la mise en place des fondamentaux opérationnels. Le bon ordre 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 accusent l’IA, alors que le problème sous-jacent réside presque toujours dans l’environnement dans lequel l’IA a été déployée. » Revenir en arrière, finalement, n’est pas un échec. C’est le fait de déployer avant d’être prêt qui l’est.
Vous souhaitez découvrir davantage d’informations de ce type ? Inscrivez-vous gratuitement à un compte DPM pour écouter d’autres experts comme ceux-ci.