On a tous vécu cette scène. Un collègue revient d’une conférence, les yeux brillants, et lâche la phrase fatale : « Il faut qu’on intègre l’IA dans nos process. » Tout le monde hoche la tête. Et puis rien ne se passe parce que personne ne sait vraiment par où commencer. Ce n’est pas un manque d’ambition. C’est un manque de méthode. Pour ceux qui veulent justement construire cette méthode, Bpifrance Université a mis en ligne une série de tutoriels gratuits et très concrets qui déroule les étapes d’un projet IA de A à Z. Avant d’y aller, voici les grandes questions qu’on y explore et pourquoi elles méritent qu’on s’y arrête sérieusement.
La feuille de route ou l’art de ne pas se disperser
Le réflexe le plus courant quand on veut se lancer dans l’IA, c’est de faire la liste de tout ce qu’on pourrait faire avec. La prévision des ventes, le tri des e-mails, l’analyse des retours clients… La liste grossit vite. Et c’est exactement là que ça déraille.
Parce que la vraie question n’est pas « qu’est-ce que l’IA peut faire », mais « qu’est-ce qui me pose vraiment problème en ce moment ». Ce n’est pas la même chose. La première approche mène à du tourisme technologique. La seconde mène à un projet utile. Une bonne feuille de route IA commence toujours par un diagnostic honnête du terrain, pas par un catalogue d’outils. On choisit un premier cas d’usage précis, on évalue ce qu’il rapporterait concrètement et ce qu’il demanderait réellement, et on avance sur cette base.
C’est moins excitant qu’une grande vision. Mais c’est ce qui marche.
Les données et les équipes, les deux angles morts de tout projet IA
Il y a une conversation qu’on a inévitablement à un moment du projet et qui refroidit l’enthousiasme général. Quelqu’un demande d’où viendront les données, dans quel état elles sont, si elles sont accessibles. Et là, silence gêné.
La réalité est que la plupart des organisations ont des données éparpillées, incomplètes ou stockées dans des formats que personne ne maîtrise vraiment. Un modèle d’IA ne fait pas de miracles avec ça. Il amplifie ce qu’on lui donne. Si les données sont mauvaises, les résultats le seront aussi, peu importe la sophistication de la technologie.
L’autre angle mort, c’est humain. Les personnes qui utiliseront la solution au quotidien ne sont pas forcément préparées à travailler avec elle. Pas parce qu’elles manquent de capacités, mais parce qu’on ne les a pas formées. Ni même vraiment intégrées au projet dès le départ. Ces deux chantiers, la donnée et la montée en compétence des équipes, sont ceux qu’on remet toujours à plus tard. Et c’est souvent eux qui font trébucher un projet par ailleurs bien conçu.
Faire ou faire faire, une décision qui engage plus qu’on ne le croit
À un moment du projet, il faut trancher. Développe-t-on quelque chose en interne ou fait-on appel à un prestataire ? Achète-t-on une solution du marché ou construit-on quelque chose sur mesure ? Ce choix arrive souvent trop tôt, quand le problème n’est pas encore bien cerné, et il est souvent fait sous pression commerciale ou par mimétisme avec ce que font les autres.
Pourtant c’est une décision structurante. Elle engage du budget, du temps, des dépendances futures et la capacité à faire évoluer la solution. Chaque option a ses avantages réels et ses contraintes réelles. Une solution du marché déploie vite mais s’adapte peu. Un développement sur mesure offre de la flexibilité mais demande des compétences internes. Comprendre ces arbitrages avant de signer quoi que ce soit, c’est éviter de se retrouver coincé deux ans plus tard avec un outil qui ne correspond plus à rien.
La cybersécurité, le sujet qu’on préfère remettre à après
Quand on branche un système d’IA sur les outils existants d’une organisation. On ne fait pas qu’ajouter une fonctionnalité. On ouvre des portes entre des systèmes qui ne se parlaient pas. Et certaines de ces portes peuvent être exploitées par des personnes mal intentionnées.
Des données manipulées en entrée peuvent fausser les décisions que prend le modèle. Un accès non sécurisé à l’ERP peut paralyser des opérations entières. Ce n’est pas de la paranoïa. Ce sont des scénarios qui se sont produits dans des entreprises ordinaires qui pensaient que ce genre de choses n’arrivait qu’aux autres.
La bonne nouvelle est qu’on n’a pas besoin d’une équipe de spécialistes pour identifier les risques principaux et se protéger correctement. Il suffit d’y penser au bon moment. C’est-à-dire avant le lancement et non après, et d’impliquer les bonnes personnes dès la phase de conception.
La conduite du changement, ou pourquoi les gens résistent à ce qui est pourtant bon pour eux
C’est le chapitre que tout le monde saute et que tout le monde regrette d’avoir sauté. On imagine que si la solution est bonne, les gens l’adopteront naturellement. L’expérience montre que c’est rarement comme ça que ça se passe.
Les collaborateurs qui résistent à un nouvel outil IA ne le font pas par mauvaise volonté. Ils le font parce qu’ils n’ont pas été informés des raisons du changement. Parce qu’ils ont peur pour leur poste ou pour leurs habitudes de travail. Ou simplement parce qu’on ne leur a jamais demandé leur avis. Ce sont des réactions humaines parfaitement compréhensibles. Et elles se gèrent, à condition d’y penser dès le début du projet.
La conduite du changement n’est pas une couche qu’on ajoute à la fin. C’est un fil qui doit traverser tout le projet, du cadrage jusqu’au déploiement. Les projets qui se plantent se plantent rarement pour des raisons techniques. Ils se plantent parce que les gens qui devaient s’en emparer ne l’ont pas fait.
La gouvernance IA, pour ne pas repartir de zéro à chaque fois
Quand un premier projet IA aboutit, on est soulagé. On a appris énormément. Et puis on passe à autre chose, et six mois plus tard on recommence à peu près depuis le début sur un nouveau projet, en refaisant les mêmes erreurs.
C’est exactement ce que la gouvernance IA cherche à éviter. Ce mot un peu austère désigne simplement la façon dont une organisation s’organise pour que ses projets d’IA se parlent. Capitalisent les uns sur les autres et restent alignés sur une stratégie claire. Qui décide quels projets lancer en priorité ? Comment évalue-t-on ce qui marche ? Comment partage-t-on ce qu’on a appris d’un projet à l’autre ?
Ce n’est pas réservé aux grandes entreprises avec des directions dédiées. Même à une petite échelle, se poser ces questions après un premier succès change complètement la trajectoire de ce qui vient ensuite.
