Réaliser des projets d’IA

Lisez la transcription :

Nous essayons de retranscrire nos podcasts à l’aide d’un logiciel. Veuillez nous excuser pour les éventuelles fautes de frappe, le bot n’étant pas correct à 100 %.

Galen Low : Vous faites encore ces rêves. Vous savez, celui où tous les autres chefs de projet de votre équipe sont des cyborgs ? Ou celui où le produit d’IA que votre équipe est en train de construire prend conscience de lui-même et asservit l’humanité ?

Détendez-vous.

Bien sûr, l’intelligence artificielle est un sujet brûlant en ce moment, mais c’est aussi quelque chose qui existe sous une forme ou une autre depuis des décennies. Et c’est partout autour de vous : elle suggère des formulations pour vos mails, elle vous recommande des vidéos, elle calcule le meilleur itinéraire pour aller au travail, etc.

Mais oui, lancer des projets qui impliquent l’IA est une grande responsabilité, et franchement, une inévitable. Et comme pour toute technologie en évolution rapide, tous les projets ne sont pas forcément promis au succès. Donc… cette pression que vous ressentez est bien réelle, et légitime.

Si vous essayez de comprendre l’intelligence artificielle et la manière dont elle va impacter la gestion de projets numériques, cet épisode est pour vous. Nous allons mordre à pleines dents dans les raisons pour lesquelles les projets d’IA échouent et ce que nous, en tant que chefs de projet, pouvons faire pour donner à nos projets liés à l’IA toutes les chances de réussir.

Bonjour à tous, merci de nous écouter. Je m’appelle Galen Low et je représente le Digital Project Manager. Nous sommes une communauté de professionnels du numérique ayant pour mission de s’entraider pour acquérir des compétences, gagner en confiance et créer du lien, afin d’accroître la valeur de la gestion de projet dans un monde digitalisé. Si vous voulez en savoir plus, rendez-vous sur thedigitalprojectmanager.com.

Bien. Aujourd’hui, nous allons parler des projets incluant de l’intelligence artificielle et de la manière dont les pratiques agiles peuvent aider à naviguer dans certaines des complexités autour de la création d’un produit basé sur l’IA.

Sont avec moi aujourd’hui Kathleen Walch et Ron Schmelzer, partenaires dirigeants et analystes principaux de Cognilytica, et également animateurs du podcast AI Today – un podcast consacré à des analyses pratiques et concrètes sur l’actualité de l’intelligence artificielle.

Kathleen, Ronald, bienvenue !

Ronald Schmelzer : Merci de nous recevoir.

Kathleen Walch : Oui, nous sommes ravis d’être ici.

Galen Low : C’est tellement agréable de vous avoir à l’émission. Pour les auditeurs, on déconnait sur les podcasts car Ron et Kathleen parlent d’IA en podcast depuis, quoi, six ans maintenant ?

Kathleen Walch : Pratiquement, oui.

Galen Low : J’ai donc glané tous leurs conseils et leurs secrets et je ressens un peu de pression.

Je me sens un peu intimidé, mais je pensais qu’on allait rentrer directement dans le vif du sujet. L’IA est aujourd’hui un thème tellement intéressant dans le monde de la gestion de projet, et plus largement. Votre podcast est énormément écouté. Tout le monde essaye vraiment de rester à la page sur ce sujet qui évolue très rapidement et est, en général, plutôt incompris.

Mais avant d’entrer dans le vif du sujet, j’aimerais savoir, pouvez-vous nous parler un peu de Cognilytica ? Qu’est-ce qui vous a poussé à créer votre organisation et comment aidez-vous les gens à naviguer dans le monde de l’intelligence artificielle ?

Kathleen Walch : Bien sûr. Cognilytica existe à peu près depuis aussi longtemps que notre podcast, donc depuis 2017. Et tout a commencé parce que Ron et moi avions déjà travaillé ensemble dans le passé dans une entreprise appelée Tech Breakfast, qui était en fait un événement de démonstration matinale.

Très entrepreneurial, pas forcément axé sur l’IA, mais plus largement sur la technologie. L’objectif était de mettre en lumière tout ce qui se fait dans les différentes régions des États-Unis. On était présents dans une douzaine de villes, de Boston à New York, la région de DC, le nord de la Virginie, le Maryland. On en avait aussi au Texas, en Caroline du Nord, et en Californie, bien sûr.

C’est à partir de Tech Breakfast que nous avons commencé à beaucoup voir émerger les assistants vocaux en particulier et la technologie vocale. On s’est dit, d’accord, il y a peut-être quelque chose à creuser ici. Et c’est là qu’est né Cognilytica. Cognilytica est donc devenu un cabinet de conseil et d’éducation concentré sur la recherche en IA. Très vite, on s’est rendu compte que les gens qui lançaient des projets d’IA — le terme intelligence artificielle a été inventé en 1956 —

Donc le concept n’est pas nouveau. Ça existe depuis des décennies aujourd’hui, mais ça reste perçu comme nouveau. Et pour beaucoup de gens, c’est peut-être le cas, finalement. Ils n’en avaient jamais vraiment entendu parler avant. Ce n’est qu’au cours de la dernière décennie ou presque que c’est devenu un sujet grand public. Les gens interagissent avec quotidiennement via les assistants vocaux, via leur téléphone, via la reconnaissance faciale, etc.

On a donc constaté que les gens ne menaient pas correctement leurs projets d’IA et que le taux d’échec était élevé. On s’est dit, ok, prenons du recul, analysons la situation et essayons de comprendre ce qui cloche, pourquoi c’est le cas. Sur notre podcast, nous avons une série sur les échecs de projets d’IA qui creuse les raisons courantes de ces échecs.

Cela peut venir de problèmes de qualité ou de quantité de données. Peut-être que le retour sur investissement n’est pas forcément là. Les gens veulent faire de l’IA juste pour faire de l’IA. Une autre grande raison, c’est aussi que, pour n’importe quelle raison, les gens survendent l’IA et finalement livrent moins que promis : ils font de grandes promesses sur ce que l’IA peut réaliser, sont exaltés par la technologie, et bien sûr livrent en dessous car souvent le projet est hors de portée.

Ils ont eu les yeux plus gros que le ventre. On s’est donc dit qu’il fallait vraiment axer sur la formation de base, montrer et expliquer comment bien mener un projet d’IA, ce qui inclut le respect des bonnes pratiques méthodologiques. Je vais laisser Ron se présenter et poursuivre à ce sujet.

Ronald Schmelzer : Excellente introduction.

Je suis Ron Schmelzer, également partenaire dirigeant chez Cognilytica. Et vous savez, une des choses que nous avons constatées, et en partie la raison du succès du podcast, c’est que nous consacrons beaucoup de temps aux concepts, aux explications, voire à la terminologie.

Parce que tout cela est parfois très confus. On a parfois l’impression que c’est presque volontairement confus. On utilise les mêmes mots pour désigner des choses différentes, et différents mots pour désigner la même chose, car l’intelligence artificielle est un ensemble de communautés voisines mais distinctes. Il y a les roboticiens traditionnels et ceux qui travaillent dans les systèmes de contrôle.

On a tout un groupe de spécialistes statistiques, d’analystes de données. Des linguistes et des gens du traitement du langage naturel. Il y a des gens qui travaillent en cybernétique et dans les systèmes de contrôle, et ils disent : nous utilisons ce terme pour désigner cela, et d’autres disent "ah, intéressant, nous aussi". Mais personne ne règle vraiment le problème, tout est amalgamé. Pendant ce temps, plein de chercheurs, et du jour au lendemain, les gens deviennent très enthousiastes pour l’IA et y injectent énormément d’argent — parfois des milliards de dollars.

Et tout à coup, ces chercheurs se retrouvent chez Microsoft, Amazon, Google, Facebook, etc., et mènent ces projets. Comme l’a dit Kathleen, nous passons le plus clair de notre temps à l’éducation : nous avons lancé très tôt chez Cognilytica des formations sur les fondamentaux de l’intelligence artificielle, ses applications, etc.

Et ça a pris très vite, on a fini par faire beaucoup de formations pour les gouvernements, des institutions fédérales, étatiques, locales, internationales, Australie, UK, Singapour, tellement de pays avec qui nous avons travaillé, ainsi que de grandes organisations et entreprises. Et on pourrait se dire, après toutes ces années, ils savent ce qu’ils font.

Mais en fait, on arrive et on est encore surpris. Comment peut-on faire tout ça sans avoir les bases ? Et c’est ce qui nous mène à cette méthodologie, dont on va parler, qui explique comment mener des projets d’IA. Parce qu’on a remarqué chez beaucoup d’organisations qu’elles faisaient sans cesse les mêmes erreurs.

Et ce n’est pas qu’ils ne sont pas intelligents, au contraire. Certains des chercheurs les plus brillants du domaine travaillent pour ces entreprises, et la technologie est là. Donc il faut chercher ailleurs, et comme vous le savez, la véritable recette magique qui fait fonctionner tout ça, c’est la gestion de projet — et c’est pour ça qu’on est là.

Galen Low : C’est drôle, ce que vous disiez sur l’intelligence artificielle qui trouve son origine dans les années 50 : j’imagine toute cette technologie de science-fiction, qui sort des romans, puis devient réelle… Et en fait, cette notion de l’IA et des raisons pour lesquelles les projets d’IA échouent, on va y venir. Mais je me dis que c’est comme la téléportation — un concept de fiction que des gens essaient de réaliser, avec une obsession sur le comment, sans forcément se demander pourquoi la téléportation ? Quel impact métier cela aurait-il ?

Et comment relier ça à la mise en production concrète ?

Ronald Schmelzer : Oui, c’est exactement ça — d’ailleurs, il y a une actualité toute fraîche sur un des constructeurs de véhicules autonomes qui vient d’abandonner la partie. La société Argo, valorisée à un milliard, vient de fermer, licencier 2 000 personnes, et revend son équipe et ses technologies à Ford et VW.

Dans un article, ils disent que la hype est retombée et que les véhicules autonomes, ce n’est peut-être pas pour tout de suite. Mais ça illustre bien votre propos : par exemple, Kathleen adore l’idée du véhicule autonome, mais il manque un "conducteur". Il n’y a ni conducteur devant, ni vrai moteur économique. Donc, est-ce juste une quête ? Ou faut-il un retour concret sur investissement pour que ça marche ?

Galen Low : J’aime beaucoup ça. Et pour rebondir : souvent, quand on pense projets d’IA, on pense à ça, n’est-ce pas ? Voitures autonomes, conception conversationnelle, chatbots, etc.

Mais l’intelligence artificielle, c’est bien plus vaste. On pourrait faire le point pour nos auditeurs : quand on parle de livrer un projet qui implique de l’IA, quels autres exemples peut-on citer ?

Kathleen Walch : Oui, c’est un point qu’on a aussi pas mal étudié. Parce que quand on parle d’IA, on ne parle pas toujours de la même chose. On peut parler de chatbots, de véhicules autonomes, comme ceux que j’adore et que j’attendais avec impatience.

Ça pourrait aussi être, je ne sais pas, de la maintenance prédictive, par exemple. Ça entre dans la catégorie générale de l’IA, mais ce ne sont pas du tout les mêmes types de projets. Ce qui complique la discussion. Nous avons donc recensé les sept patterns de l’IA, car tous les projets observés entrent dans l’un ou plusieurs de ces schémas.

En résumé, il y a les systèmes conversationnels — ordinateur vers humain, humain vers ordinateur, humain vers humain (traduction automatique, par exemple). Les systèmes autonomes — l’idée est d’enlever l’humain du système : véhicules autonomes, mais aussi logiciels autonomes.

Par exemple, automatiser le routage optimal d’un flux machine ou éliminer les goulets d’étranglement dans un process. Ensuite, la reconnaissance — extraire de l’information à partir de données non structurées (la majorité aujourd’hui !), comme la reconnaissance faciale, la vision par ordinateur, etc. Après, il y a les systèmes pilotés par les objectifs — apprentissage par renforcement, trouver le meilleur chemin dans un labyrinthe, etc. Les jeux sont un exemple classique.

Il y a aussi le pattern "motifs et anomalies" — déceler motifs et exceptions dans les données. Ensuite, l’hyper-personnalisation : il ne s’agit plus de regrouper les gens par catégories, mais de les considérer individuellement. On pense tout de suite à la publicité ciblée, mais imaginez la médecine ou les soins personnalisés à l’extrême.

Enfin, les analyses prédictives : utiliser les données passées ou actuelles pour aider l’humain à faire de meilleures prédictions.

Raisonner ainsi aide beaucoup : par exemple, mon application de traitement du langage naturel fait partie du pattern conversationnel — cela nous dirige vers le succès du projet d’IA, en identifiant quelles données sont nécessaires, quels algorithmes, quelles compétences doivent être mobilisées… Cela permet de cadrer les échanges.

Galen Low : J’aime bien le mot patterns, car au départ, on pense motifs, tendances, mais là c’est plus comme en couture, non ?

On a un patron de robe ou un patron de pantalon, et cela te guide dans une direction, t’offre un point de départ plutôt que de te lancer sans rien, juste avec un bout de tissu. Je dis n’importe quoi ?

Ronald Schmelzer : Non, c’est exactement ça. Pattern, c’est un mot anglais très polysémique.

Parfois je pense à l’emporte-pièce, le cookie cutter, car lorsqu’on entraîne un système d’apprentissage automatique, tout n’est qu’histoire de reconnaissance de motifs, de patterns.

Mais le pattern compte : si je veux apprendre un motif linguistique, je ne peux pas utiliser le même modèle pour la reconnaissance d’images. Il existe un but ultime, appelé "intelligence artificielle générale" (AGI), cette idée qu’une intelligence unique pourrait tout apprendre : reconnaissance, conversation, autonomie, etc.

Mais on ne sait pas exactement comment le cerveau fonctionne. Nous avons des régions spécialisées pour la vision, le langage — mais on n’a pas vingt cerveaux différents… L’AGI, c’est l’idée de rassembler tout ça, mais on n’y arrive pas encore. On parle donc d’IA spécialisée, ou IA étroite, où chaque "motif" est traité séparément.

C’est pour ça que la notion de pattern importe : un bot d’échecs ou de poker imbattable ne sert à rien en reconnaissance d’images. C’est comme être fabricant de vêtements : ok, vous faites des habits, mais le marché de la robe n’a rien à voir avec celui de la doudoune ! Vous ne vous lancez pas dans la chaussette sans adaptation...

C’est vraiment une bonne analogie.

Galen Low : C’est fascinant, car comme vous l’avez dit, on ne comprend pas tout du fonctionnement du cerveau, et on essaie pourtant de le reconstituer pièce par pièce. On découvre que la quête de l’AGI, c’est aussi la quête de la compréhension du cerveau humain. On démarre par régions/fonctions, mais on ambitionne plus général ensuite, avec de meilleures métaphores que celles que je propose dans ce podcast.

On a évoqué précédemment la problématique des livraisons de projets d’IA : où sont les malentendus, les difficultés ? Juste pour creuser cette question : en quoi livrer un projet d’IA est-il différent d’un autre projet, ou même d’un autre projet digital ?

Quels sont les fondamentaux à maîtriser en tant que chef de projet pour réussir ?

Ronald Schmelzer : Excellente question, c’est la raison même de notre présence ici ! On voit partout de grands cerveaux mobilisés pour résoudre de gros enjeux… et les échecs sont retentissants : on estime entre 70% et 80% des projets d’IA qui échouent : abandonnés, entreprises fermées, licenciements massifs…

C’est un échec immense. Mais il y a aussi des échecs plus modestes : arrêt du projet, réaffectation des équipes… Ce qu’on constate, c’est que très souvent, les problèmes sont d’ordre méthodologique. Deux points donc : un, les experts data et IA ne connaissent pas les bases de la gestion de projet ; deux, les chefs de projet, quand ils arrivent, considèrent un projet d’IA comme un autre, comme un projet logiciel classique. Or il y a de grandes différences. La principale, c’est que les systèmes d’IA dépendent entièrement des données. Vous allez me dire : tout projet digital dépend des données ? Mais pas forcément.

Vous pouvez faire un site web, une appli mobile, du cloud sans données au début ; les données arrivent après, mais ne changent pas vraiment le fonctionnement. Tandis qu’un système d’apprentissage automatique apprend tout à partir des données. Même si vous et moi construisons exactement le même chatbot avec la même technologie, si j’utilise un jeu de données différent du vôtre, on peut avoir des résultats radicalement différents. Exemple fameux de Microsoft : le Tay bot, laissé en apprentissage ouvert auprès des internautes…

Imaginez la suite : en 24h, le bot est devenu raciste, etc., ils ont dû le retirer, car rien de bon ne sort d’une formation libre sur Internet.

Donc… il faut gérer les projets d’IA avec une approche "data-centric". Ce qui implique des démarches très précises, sur lesquelles Kathleen pourra rebondir.

Kathleen Walch : Exactement. Si vous voulez faire un projet centré sur la donnée, il faut la bonne mentalité, des méthodes et pratiques spécifiques.

Or beaucoup n’en tiennent pas compte : ils appliquent les schémas traditionnels des projets logiciels, et ça ne marche pas. C’est pourquoi nous militons pour la bonne conduite de projets d’IA, avec notamment l’adoption du CPMAI (Cognitive Project Management for AI). Nous avons aussi vu que certains, surtout au début, hésitaient sur le point de départ : par la donnée, ou par le métier ?

On parle d’IA centrée donnée, donc la donnée prime... Mais en réalité, il faut toujours commencer par la compréhension métier : si le problème n’est pas réel, à quoi bon ? Beaucoup se laissent embarquer par l’engouement IA, poussés par la direction ou la mode, mais à l’arrivée vous aurez gaspillé temps, argent et ressources à développer un produit peu utile. Sans vrai retour sur investissement, votre management ne voudra plus relancer de projet IA après cela ("Vous avez dépensé 5 millions de dollars pour quoi ?"). C’est une autre grande source d’échecs.

Galen Low : C’est amusant de réfléchir à la notion de contexte. Toutes les disciplines, les métiers, viennent de cette vision "en tunnel", à ne s’attacher qu’à leur propre domaine, sans voir le contexte global.

Même en gestion de projet, on retrouve ce biais : le PMO, mercenaire, parachuté pour réussir n’importe quel projet — mais sans vraiment mesurer ce que piloter un projet data implique, par rapport à un site ou un CRM, ni la différence de dynamique. On traite la gestion de projet comme une compétence générique, sans reconnaître que la curiosité, la spécialisation et la compréhension du contexte sont des ingrédient cruciaux.

De plus, qu’on soit data scientist ou chef de projet, si on n’est pas aligné sur la stratégie métier, les objectifs du projet ET de l’organisation, on passe à côté de l’essentiel. Même sur les véhicules autonomes, tout cela peut changer très rapidement ; en IA la compétition est féroce, les objectifs mouvants, personne ne sait vraiment où il va, ni s’il poursuit le même but que les autres. Sans ce contexte, on avance à l’aveugle et, soudain, on vous arrête, sans comprendre pourquoi.

Ronald Schmelzer : Même en dehors de l’IA, sur des projets big data — et l’IA est un sous-ensemble du big data —, ce manque de centrage "donnée" se manifeste de façon très concrète :

Certains disent : il me faut telle donnée, je vais créer un modèle pour de la prédiction, de la recommandation, un chatbot… Mais ont-ils vu la donnée ? La possèdent-ils ? Souvent, le projet démarre sans même qu’on regarde les données. Puis l’on constate l’absence de la moitié des données, ou leur mauvaise qualité, ou l’impossibilité d’accéder à l’information, ou des contraintes de confidentialité ou de sécurité inattendues. Le projet s’enlise alors sur cette question d’accès, de nettoyage des données, et c’est ce qui décidera du succès ou de l’échec !

Vous pouvez avoir l’idée du siècle, mais si la donnée manque ou n’est pas accessible (restrictions médicales, qualité faible, etc.), il faudra stopper, puis démarrer un autre projet pour nettoyer, enrichir, labelliser la donnée. Et tout à coup on réalise qu’on n’a ni le temps ni les ressources pour ça… Voilà comment le projet "roule sur des roues branlantes" qui sautent vite, et qu’après 12 ou 18 mois vous n’avez rien livré, car vous attendez la donnée !

Il arrive parfois que le marché ait déjà muté : pandémie, chaîne d’approvisionnement rompue, etc. On n’a pas à inventer ces situations : Walmart a misé des millions sur des robots inventoriant ses rayons, puis tout annulé, jugé impossible à industrialiser.

Et j’ajoute : si même Walmart échoue, il faut rester humble. Moralité : comment procéder de façon plus agile et itérative ? Notre mantra c’est : "pensez grand, démarrez petit, itérez souvent". Peut-être qu’on aurait pu utiliser un jeu de données réduit, éviter d’embêter tout de suite les problèmes de robotique et commencer avec un simple chariot et une caméra… Autrement dit, dissocier le pattern "reconnaissance" du pattern "autonome", d’où l’importance de l’approche par patterns.

Galen Low : L’IA, c’est l’escalade des exigences : il doit forcément sortir un robot qui me cuisine le petit-déjeuner ! Première itération : une simple suggestion personnalisée de recette, à faire soi-même… Démarrons simple. Vous avez aussi parlé d’agilité, et j’ai promis d’aborder ce sujet. Or, on dirait qu’en agile, l’itération est la clef car tout évolue vite… Est-ce LA méthodologie idéale ? Ou y a-t-il des limites à l’agilité pour l’IA ?

Kathleen Walch : Oui, beaucoup d’organisations sont agiles, ou du moins aspirent à l’être… On rencontre souvent du "wagile", mélange de waterfall et d’agilité où on prétend être agile sans l’être vraiment. Comme Ron l’a expliqué, certains projets prennent 12 à 18 mois alors qu’ils ne devraient pas. Donc, l’agilité doit être adaptée aux projets d’IA en comprenant qu’il s’agit de projets data, à piloter comme tels, mais en gardant l’esprit agile.

Ronald Schmelzer : Oui, j’aime bien visualiser l’agile comme une spirale continue. Beaucoup de schémas d’agile sont des spirales. Vous avez votre projet principal, avec comme composant la création de ce modèle d’IA ou du système d’IA — ce n’est pas une fin en soi, mais un moyen. Si vous faites un outil de diagnostic, la techno est clé, mais ce n’est pas l’objectif ultime.

On peut donc imaginer deux spirales entremêlées : l’itération du projet global (fonctionnalités, intégration, etc.) et, perpendiculaire à celle-ci, l’itération sur le modèle d’apprentissage automatique (préparation des données, entraînement, etc.), avec des cycles et rythmes peut-être différents.

On peut demander, pour démarrer : "Équipe IA, donnez-moi la version la plus simple possible." On peut commencer par un chatbot tout bête ou une simple heuristique, puis le rendre progressivement plus intelligent. On itère ainsi à deux niveaux : la vie du projet principal et celle du modèle data.

Il existe des méthodologies comme CPMAI qui spécifient les étapes : compréhension du métier, go/no-go IA (9 feux de signalisation), compréhension des données, préparation, développement puis évaluation et mise en production du modèle. Le tout itéré dans le cadre d’un sprint agile. CPMAI ne remplace pas l’agile, il s’y imbrique, en expliquant quoi faire à chaque itération.

Galen Low : J’adore ça, car il faut des cadres pour réfléchir et guider l’action. Dans mon milieu de gestion de projet, beaucoup se considèrent "puristes" et veulent suivre la méthodo à la lettre, alors que l’agile prône justement l’adaptabilité ! On a donc besoin de référentiels, à ne pas appliquer rigidement mais comme points d’attention souples.

Kathleen, tu as évoqué le wagile — ma réaction aussi est : OK, Ron explique que si on néglige la donnée au départ, on court à la catastrophe… Mais cela n’implique pas forcément un bloc waterfall pour la collecte, on peut itérer aussi sur la data. On est tellement conditionnés à la linéarité qu’on a du mal à penser en spirales entremêlées. Ça "casse le cerveau", non ? On veut retrouver des étapes linéaires dans un truc non linéaire, ce qui nous piège parfois. Mais l’itération est toujours possible, que ce soit sur le cœur IA ou sur l’analyse métier — les deux peuvent s’entrelacer. Grave erreur de les faire séparément en espérant raccorder plus tard. Comme ce fameux avion construit par deux équipes différentes : la partie avant par une équipe, l’arrière par une autre, et personne n’a vérifié que le câble qui les relie était suffisant. Résultat : impossible à relier, projet fichu ! Ce sont les points d’intégration qui comptent.

Ronald Schmelzer : Exactement. Kathleen a plein d’exemples clients… En fait on trébuche toujours sur les hypothèses cachées.

On part du principe qu’il faut énormément de données (pétaoctets), donc on sort les artilleries lourdes type deep learning, qui sont, certes, top, mais très coûteuses en nettoyage, en préparation, en entraînement… On gère ça façon waterfall, étape par étape. Pourtant, rien n’oblige à tout faire d’un coup : et si, pour votre première itération, on utilisait quelques mégaoctets et une bête arborescence de décisions pour tester le concept ? On aurait beaucoup moins de nettoyage, on pourrait tout entraîner sur un simple ordinateur portable, tout irait plus vite, coûterait moins cher.

Ce n’est qu’une première étape, pas l’objectif final ! C’est là que les cycles IT/data s’entrecroisent : les points de raccord, ces fameux câbles de l’avion. Il suffit de mesurer à chaque étape : "à quoi vont se connecter les deux parties ?". On aurait pu tirer une simple corde d’un bout à l’autre pour mesurer la longueur de l’avion avant même d’avoir le câble… puis remplacer la corde par le câble plus tard, sans tout jeter !

Kathleen Walch : En suivant une démarche pas-à-pas, tout le monde est sur la même longueur d’onde, on évite l’improvisation totale qui fait foirer bien des projets — bien plus courant qu’on ne le croit. Les étapes sont claires : au moment de l’analyse métier, on fait ceci, au moment de l’analyse des données, cela… On évite les mauvaises surprises, du genre : 5 mois sans rien avoir livré, pourquoi ? Où sont passés les 5 millions investis ? Et parfois même juste accéder aux données prend des mois… c’est parfois un vrai changement culturel. Il faut alors un soutien de la direction. Mais comme disait Ron, commençons « small » : une quantité de données accessible — donc pas besoin de briser des silos ou d’aller négocier des accès à des données hyper sensibles au sein de l’entreprise.

Galen Low : C’est aussi l’occasion d’aborder un point délicat : parfois les attentes sont décalées, que ce soit côté direction (qui veut un robot mais reçoit un chariot qui scanne trois codes-barres…) ou côté équipe (qui bâtit quelque chose avec un enthousiasme débordant, pour un résultat qui n’est pas celui promis après 5 millions d’investissement…). Comment aligner les attentes ? Avec qui, à quel moment, ces conversations doivent-elles avoir lieu pour éviter l’improvisation et l’échec ?

Kathleen Walch : D’abord, il faut comprendre ce que l’IA peut ou ne peut pas faire. Ce n’est pas une technologie universelle. Il faut avoir conscience que parfois, il vaut mieux un système déterministe classique, une simple automatisation, plutôt que de l’IA, qui sera toujours probabiliste. Si la régularité parfaite est requise, l’IA n’aura pas le comportement attendu, il vaut mieux ne pas forcer — ça évite beaucoup d’ennuis.

Et comme on l’a vu, l’une des causes majeures d’échec de l’IA depuis l’invention du terme en 1956, c’est la sur-promesse et la sous-livraison. Cela a causé deux "hivers de l’IA" (périodes de désillusion, où l’investissement et la recherche chutent). Aujourd’hui on parle de "printemps de l’IA" mais à continuer ainsi, on redoute l’arrivée d’un nouvel hiver. D’où l’importance de fixer des attentes réalistes, bien cadrer le projet, comprendre ce qu’on cherche à résoudre. Si l’IA est la bonne solution, alors il faut suivre les bonnes pratiques assurant le succès.

Galen Low : Cette responsabilité de l’équipe qui délivre — c’est presque comme de la confiance d’investisseur : si vous créez de la défiance, l’avancée de l’IA s’en trouve compromise.

Ronald Schmelzer : Oui, et on comprend parfaitement pourquoi la tentation est forte, car les problèmes difficiles touchent à nos compétences humaines fondamentales : si on arrivait à automatiser ça, ce serait la promesse réalisée de la transformation numérique. Avec toutefois des revers, comme l’emploi aveugle d’algorithmes décisionnels qui bloquent un compte YouTube sans recours, etc. L’approche "intelligence augmentée" est donc raisonnable : garder l’humain dans la boucle tout en réduisant sa charge, rassurer sur le contrôle. Cela facilite la progression de la transformation numérique.

Galen Low : Abordons le sujet de la résistance à l’IA : pas seulement chez les décideurs, mais aussi dans les équipes culturelles ou métier, qui peuvent être tentées de tout rejeter, par peur du "monstre IA". Comment gérer ce type de résistances ? Et l’inverse : comment convaincre le convaincu que l’IA n’est pas à chaque fois la bonne solution ?

Kathleen Walch : Il y a beaucoup à dire… Le plus important c’est l’adhésion de la direction, car la crainte de l’IA peut être tant émotionnelle que rationnelle, et il faut adresser les deux. Personne ne souhaite être remplacé par la machine (même si de nombreuses études montrent le paradoxe de l’automatisation — plus d’emplois créés que détruits). L’humain et la machine ont chacun leurs atouts. En déléguant à la machine les tâches répétitives, pénibles ou dangereuses (pensons aux entrepôts), on peut confier à l’humain ce que la machine fait mal, comme la livraison du "dernier kilomètre", ou les interactions nécessitant de l’empathie. Le bot s’occupe du basique, mais parfois l’humain est nécessaire.

Le soutien de la direction est donc clé pour rassurer ("on ne va pas vous remplacer, mais vous aider !"). Il est aussi essentiel de recueillir les retours : s’assurer qu’on élimine vraiment les tâches pénibles et non les favorites des utilisateurs ! Cela paraît évident, mais beaucoup d’équipes ne consultent jamais l’utilisateur final sur ses "douleurs" métier : commençons par là, quitte à n’automatiser que l’entrée de données, pour améliorer la vie des équipes, qui se sentiront valorisées et libérées pour se concentrer sur leur vrai métier.

Ronald Schmelzer : Il y a aussi un contexte général de défiance envers le management, accentué par la crise du Covid : l’employeur a parfois mal géré la relation, la crise du télétravail, etc. Il est sain d’instaurer un contrôle réciproque… Mais essaie-t-on de recentrer le travail sur le métier ? Le rôle d’un service client est d’améliorer la relation client, pas de faire de la saisie. Si 6h sur 8 sont consacrées à de la saisie, ni l’employeur ni l’employé n’en tirent vraiment parti.

C’est là que l’automatisation (basique, puis "intelligente"), peut rapporter à tous. On l’a tous vécu : contact avec une administration ou grande entreprise, attente interminable pour obtenir une info basique… L’introduction d’IA ou de RPA permettrait de recentrer le métier sur l’essentiel, de résorber les backlogs, etc. Encore faut-il être prêt à repenser les processus, car ce défi est avant tout un enjeu de conduite du changement, pas de technologie.

C’est souvent sur les usages les plus anodins que les gains potentiels sont les plus importants.

Galen Low : Belle transition avec la question que tout le monde se pose : l’IA va-t-elle remplacer les chefs de projet ?

Kathleen Walch : Excellente question ! Ce que l’on voit, c’est que les rôles nécessitant "l’humain" ne disparaîtront pas, mais évolueront. On craint souvent que l’IA soit tueuse d’emplois (job killer), mais en fait, elle tue peut-être des catégories d’emploi. Toute technologie transformatrice a bouleversé la vie et la manière de travailler. Le PC a éliminé "des salles entières de secrétaires". Mais il y a eu de nouveaux métiers (qui connaissait un "community manager" en 1960 ? Maintenant c’est commun !). Le métier change, il ne disparaît pas.

Dans le secteur de la gestion de projets, l’IA touche tous les domaines (banque, assurance, santé, finance, automobile…), et la gestion de projet y aura recours aussi : pour être augmentée, pour remplacer certaines tâches, certes, mais pas forcément le rôle. Le contenu et le quotidien du poste évolueront, mais le métier survivra.

Ronald Schmelzer : Exactement, il y a toujours ces moments de transformation : or, ironie du sort, plus il y a de projets IA, plus il faut de chefs de projet ! Car la plupart des échecs d’IA viennent d’un manque de structuration. Regarder sa journée type : combien de temps passé en réunion, à tracer, documenter, coordonner… l’essentiel c’est la communication. Demain, des outils IA automatiseront comptes-rendus, prédictions, alertes… Mais le chef de projet restera l’animateur/chef d’orchestre du succès, garant du lien entre métier et réalisation.

C’est pourquoi on pense que les initiales PM pourraient changer de signification, le rôle existera toujours, même métamorphosé. D’ailleurs, il faudrait proposer des contenus "IA pour chefs de projets" car ce sujet mérite toute l’attention !

Galen Low : Ça me plaît, tout le monde ici est rassuré : votre rôle est sans doute à l’abri même si votre quotidien va évoluer. Pour terminer, on parle beaucoup de la connaissance de l’IA, qui fait peur à beaucoup… Comment un chef de projet peut-il "comprendre suffisamment l’IA" pour poser les bonnes questions, imaginer une version simple, les alternatives (la "corde à la place du câble") ?

Kathleen Walch : C’est justement ce qui nous a motivés à proposer la certification et la formation CPMAI : ce sont des parcours accessibles à tous, même sans bagage technique ou mathématique, pour apprendre les fondamentaux et la gestion de projets IA. Si la certification n’est pas l’étape immédiate, on propose aussi un module d’introduction gratuit sur AItoday.live/cpmai. Il prend 3h, il donne une vue complète du CPMAI, comment l’appliquer pour réussir vos projets. C’est une démarche en étapes successives, facile d’accès, qui prévoit des retours-arrière possibles, et donne des exemples concrets.

Ronald Schmelzer : Oui, et on a aussi bâti un glossaire dans notre podcast (après 5-6 ans d’épisodes !). On y passe en revue chaque mot, chaque terme (AGI, hiver de l’IA, patterns, etc.), de la base (définir "donnée", puis "big data", etc.). C’est très utile. Et on espère s’impliquer plus dans la communauté PM : participer à des événements, croiser les publics, inviter les chefs de projet à nos interventions IA (cela peut paraître intimidant mais, rassurez-vous, la maîtrise de la terminologie suffit le plus souvent !).

Galen Low : Cet esprit de "pollinisation croisée" est excellent — il faudra organiser un événement commun, inviter nos deux communautés à dialoguer : voilà comment apprendre, progresser et réussir.

Kathleen Walch : Complètement.

Galen Low : Super. Un immense merci à Ron et Kathleen pour votre participation : ce fut un vrai plaisir et très enrichissant. J’espère que nos auditeurs en tireront un précieux enseignement. Je mets les liens vers votre podcast et les ressources AI Today, ainsi que Cognilytica, ci-dessous pour les curieux qui voudraient approfondir.

Encore merci pour votre temps et vos réflexions.

Kathleen Walch : Merci à vous, c’était vraiment super sympa.

Galen Low : Qu’en pensez-vous ?

La conduite d’un projet d’intelligence artificielle nécessite-t-elle une démarche spécifique ? Ou un projet n’est-il, au fond, qu’un projet comme les autres ?

Racontez-nous : une technologie ou un outil à base d’IA a-t-il déjà semé la pagaille sur votre projet ? Comment avez-vous résolu le problème ?

Et si vous souhaitez développer vos compétences de chef de projet stratégique, rejoignez notre communauté !

Rendez-vous sur thedigitalprojectmanager.com/membership pour accéder à une communauté solidaire qui partage ses connaissances, résout des problématiques complexes et façonne l’avenir de notre métier, ensemble.

Des modèles robustes, des sessions de formation mensuelles qui vous font gagner temps et énergie, un réseau d’entraide via nos discussions Slack, nos événements en direct, nos groupes mastermind… Être membre de notre communauté, c’est compter sur plus d’un millier d’alliés pour évoluer sereinement dans la gestion de projet digital.

Si cet épisode vous a plu, abonnez-vous et restez connectés sur thedigitalprojectmanager.com.

À bientôt, et merci pour votre écoute.