Katie Drummond de WIRED a posé une question simple à Dan Swan, senior partner chez McKinsey et responsable mondial de la practice Tech & AI : qu'est-ce qui distingue les entreprises qui progressent réellement grâce à l'IA de celles qui n'y parviennent pas. La réponse était sans détour. La plupart des entreprises ne se transforment pas. Elles achètent des logiciels, les déploient dans l'organisation, et appellent cela une transformation.
C'est une affirmation qui doit mettre mal à l'aise bon nombre de dirigeants. Non pas qu'ils ne fassent rien avec l'IA, bien au contraire. La plupart des organisations ont désormais acheté une licence, font tourner un projet pilote ou utilisent un chatbot. Mais selon Swan, c'est précisément le problème. Réussir sa transformation IA, c'est repenser en profondeur la manière dont les gens travaillent, dont les flux de travail se déroulent et dont la direction décide. Le reste, c'est acheter des outils en espérant qu'ils s'appliquent d'eux-mêmes.
Il se trouve que ce sur quoi Swan s'appuie porte un nom : Rewired, le playbook de McKinsey sur ce qui fait réussir, ou échouer, une transformation. La première édition portait sur la transformation digitale en général, la dernière sur l'IA. L'enseignement qui relie les deux : ce qui valait pour une transformation digitale réussie vaut tout autant pour l'IA. Il ne s'agit pas d'abord de technologie. Il s'agit des personnes.
Pourquoi la plupart des trajectoires IA restent bloquées
McKinsey décrit la maturité IA comme une échelle à quatre échelons. Le premier consiste à interroger un modèle de langage, comme on utilise aujourd'hui ChatGPT ou Claude. Le deuxième consiste à intégrer un modèle de langage dans un logiciel existant, pensez aux comptes rendus automatiques d'une réunion Teams ou Outlook. Les troisième et quatrième échelons vont plus loin : repenser fondamentalement un processus complet, ou construire une nouvelle façon de faire des affaires qui n'aurait pas existé sans l'IA.
La plupart des entreprises ne dépassent jamais le deuxième échelon. Ce n'est pas un hasard. Le deuxième échelon est démocratisé. Chaque collaborateur disposant d'une licence Microsoft ou Google en tire immédiatement profit. Cela ne demande aucune décision difficile de la direction. Aucun processus à revoir, aucune équipe à faire travailler autrement, aucun investissement à défendre. C'est précisément pour cette raison que c'est un piège. Cela ressemble à du progrès, cela produit des citations enthousiastes pour l'intranet, mais cela n'apparaît nulle part dans les résultats financiers.
Trois principes qui font vraiment la différence
De Rewired, Swan tire trois principes pour dépasser ce piège. Le premier concerne la concentration. Choisissez deux ou trois domaines, et allez-y en profondeur avec un processus complet, plutôt que de disperser l'IA sur des dizaines d'applications isolées. Le schéma d'échec historique est connu : de petits projets pilotes qui ne passent jamais à l'échelle, qui ne deviennent jamais visibles dans les résultats financiers, et qui finissent surtout par générer de la frustration chez ceux qui y ont consacré du temps.
Le deuxième principe consiste à aller plus loin que l'accélération : changer fondamentalement un processus, ou construire quelque chose de nouveau, plutôt que de simplement faire tourner le même processus un peu plus vite. Le troisième est une question d'appropriation : traitez cela comme une véritable transformation d'entreprise, pas comme une transformation technologique. Le propriétaire du problème métier tient les rênes, pas le département IT.
Ces trois principes se rejoignent dans une seule question, la plus importante de tout l'entretien. Pas : où puis-je appliquer l'IA ? Mais : quel est le problème métier, et comment l'IA peut-elle aider à le résoudre ? Cela semble un détail. C'est la différence entre un projet technologique et un projet d'entreprise.
Ce que cela signifie à l'échelle d'une scale-up flamande
Les exemples cités par Swan se déroulent dans des entreprises comptant des dizaines de milliers de collaborateurs. Chez Toyota, un vice-président s'est un jour demandé tout haut : si Amazon peut suivre un livre à 10 dollars, pourquoi ne pourrions-nous pas suivre une voiture à 40 000 dollars ? La réponse est devenue un jumeau numérique de l'ensemble de la chaîne d'approvisionnement, qui traite aujourd'hui un milliard de décisions en 15 minutes, un travail qui nécessitait auparavant 100 personnes et 75 feuilles de calcul. Valeur estimée : environ 800 millions de dollars.
Pour une organisation de 50 à 500 travailleurs du savoir, cette échelle n'est pas la question. Le principe sous-jacent, lui, l'est. Ne pas lancer dix expérimentations IA en même temps dans dix départements, dont neuf s'éteindront discrètement après six mois. Choisir un processus qui compte vraiment, le traitement des commandes, le service client ou la planification, par exemple, et repenser ce processus en profondeur avec l'IA comme point de départ, pas comme une couche ajoutée à ce qui existait déjà.
Traduit à cette échelle, cela se résume à cinq points d'attention.
Choisissez un seul processus, pas dix expérimentations. Les projets pilotes dispersés donnent un sentiment de sécurité, car personne ne perd grand-chose s'ils échouent. C'est précisément pour cela qu'ils débouchent rarement sur quelque chose de durable. Une organisation qui teste un peu d'IA partout ne mesure finalement de différence nulle part.
Inversez la question. Pas « où pouvons-nous déployer l'IA », mais « qu'est-ce qui nous coûte aujourd'hui le plus de temps, d'argent ou de frustration, et comment l'IA peut-elle résoudre cela ». Cette inversion déplace la conversation du département IT vers la table de direction. Une question technologique produit un projet technologique. Une question d'entreprise produit un résultat d'entreprise.
Faites de vos collaborateurs des co-constructeurs, pas seulement des utilisateurs. Chez Toyota, les experts commerciaux, de production et de planification étaient à la table dès le premier jour. Non pas comme des utilisateurs finaux devant tester plus tard, mais comme des co-constructeurs qui ont ensuite gagné la confiance du reste de l'organisation. Qui n'aborde les gens du terrain qu'au moment du lancement a déjà construit l'édifice sans eux.
Pilotez d'en haut, pas à côté de chaque étape. McKinsey appelle cela « humans above the loop » plutôt que « humans in the loop ». L'humain donne la direction, veille à la qualité et intervient si nécessaire, au lieu de rester à côté de chaque étape pour la contrôler. Rester à côté de chaque étape pour la contrôler n'automatise rien. Cela ajoute simplement une couche de contrôle supplémentaire.
Attendez-vous à des douleurs de croissance qui s'atténuent. DBS, la banque évoquée dans Rewired, a commencé avec deux ou trois domaines prioritaires, avant d'étendre à quatre, cinq, six. Chaque vague suivante est allée plus vite, parce que l'organisation avait déjà développé des compétences : des données en ordre, des personnes capables de travailler avec des agents, des dirigeants qui savent comment piloter ce type de trajectoire. La première fois est la plus lente. Ce n'est pas un contre-argument, c'est l'investissement.
La vraie leçon
Swan est clair sur ce qui détermine en définitive le rendement, et ce ne sont pas des facteurs technologiques. Les propriétaires de processus doivent prendre pleinement possession du sujet : l'initiative doit venir d'eux, ne pas être quelque chose qui leur arrive depuis une feuille de route IT. Il faut ensuite développer les compétences des personnes qui vont effectivement utiliser les outils. Sans cela, l'investissement reste sur l'étagère, aussi bonne que soit la technologie. Et enfin, mesurer si l'impact visé est atteint, et si ce n'est pas le cas, comprendre pourquoi.
Les RH y jouent un rôle plus important que ne le pensent la plupart des organisations. Non pas parce que les RH doivent maîtriser la technologie, mais parce que l'état d'esprit et la communication, le développement des compétences, et la manière dont le travail lui-même est organisé, relèvent tous du terrain RH. Les compétences dont une équipe a besoin aujourd'hui auront déjà changé dans un an.
Ce qui perdure, selon Swan, est durable. Les entreprises qui s'engagent maintenant et tirent les leçons de cette première vague construisent un avantage qui ne disparaît pas dès qu'un concurrent achète le même logiciel.
C'est précisément cette logique, le problème métier d'abord, l'appropriation laissée au client, sur laquelle Rescope a construit sa propre approche 3R.
La question que Swan pose aux dirigeants d'entreprise est la même que devrait se poser chaque organisation de 50 à 500 travailleurs du savoir. Pas : avons-nous de l'IA ? Mais : avons-nous réellement repensé nos équipes, nos processus et notre direction, ou avons-nous simplement acheté un logiciel ?