Tirer de l'IA une valeur pour les affaires : mener des projets d'IA

Tout au long de cette série d'articles, j'ai coflété les différentes saveurs de l'IA (IA générative et " ancienne " IA, y compris l'apprentissage automatique/AA, le traitement du langage naturel/NLP, etc.), car les composants IA d'une solution répondent généralement tous à un schéma similaire, à savoir une entrée définie provenant de l'entreprise (par exemple, des données structurées ou un texte d'invite) aboutissant à une sortie particulière (par exemple, des données numériques prédites ou un texte généré), qui circule dans le reste de la solution et, en fin de compte, dans l'entreprise.

Toutefois, à ce stade, il convient de faire un bref intermède pour souligner la principale différence entre l'IA générique et les autres variétés, en particulier la manière dont le modèle est développé, car elle a des implications majeures pour les étapes pratiques du développement et de la mise en œuvre d'une solution d'IA.

Les modèles d'IA traditionnels, tels que ceux développés dans les projets AA, prennent un ensemble de données d'entraînement (souvent sourcées dans ce but particulier) et le combinent avec un algorithme sélectionné dans ce même but, ce qui permet d'obtenir un modèle entraîné spécifique aux données sur lesquelles il a été entraîné et à l'application pour laquelle il a été développé. Si l'on reprend l'exemple de l'identification de l'attrition des clients dans l'article précédent, les données seraient ici spécifiques à cette organisation, et le modèle qui en résulterait serait adapté à ce cas d'utilisation particulier.

Cette description passe sous silence les détails du processus de développement d'un modèle de AA que de nombreux data scientists et ingénieurs des données ne connaissent que trop bien. Par exemple, l'un des premiers obstacles auxquels ils seront confrontés sera de mettre la main sur les données nécessaires à l'entraînement d'un modèle, ce qui peut souvent constituer un défi dans de nombreuses organisations. Les étapes suivantes nécessitent l'exploration des données, l'identification d'algorithmes et d'approches appropriés, puis l'entraînement et le test des différentes itérations du modèle. Tout cela peut être long et fastidieux, souvent considéré comme un art autant que comme une science, et - pire que tout - le scientifique des données peut découvrir qu'il n'y a pas de signal dans les données et qu'il est impossible de construire un modèle pour prédire le phénomène qu'il s'attendait à pouvoir prédire !

Cependant, l'un des avantages des approches traditionnelles de l'IA, telles que l'AA, est qu'il existe des processus (relativement) matures et bien définis pour développer et tester ces modèles, puis les déployer en production (par exemple, ce document de 2014 a été en quelque sorte un " appel aux armes " pour de nombreux praticiens dans ce domaine). Cela ne veut pas dire que c'est sans défis, et il y a beaucoup d'incertitudes (certainement par rapport aux projets logiciels ordinaires), mais une fois que le modèle a été correctement testé et approuvé (c'est-à-dire qu'il " fonctionne "), il peut alors être déployé, en suivant les diverses recommandations de meilleures pratiques de MLOps.

D'autre part, les approches d'IA générative commencent par un modèle général pré-entraîné (grand modèle de langage, ou plus génériquement appelé "modèle de base"), qui est ensuite adapté à l'application particulière en fournissant différentes informations dans l'invite (par exemple, le libellé de l'invite, des informations organisationnelles spécifiques), afin de manipuler la sortie du modèle de base de la manière souhaitée.

Une fois encore, cette description de haut niveau ne tient pas compte de la plupart des détails. Par exemple, la phase de démarrage avec un modèle de base impliquera probablement l'itération sur différents modèles pré-entraînés ainsi que sur des messages-guides (et des données contextuelles) afin de déterminer si l'idée est possible. Ensuite, il peut y avoir une phase de cadrage du problème pour relier la solution au problème de l'entreprise, suivie de la collecte et du traitement des données. Essentiellement, il est plus facile de créer rapidement un prototype de solution, puisque le besoin de données de formation a été supprimé, mais le cadrage du problème pour faire correspondre la solution à l'entreprise peut être moins facile à comprendre, peut devoir être adapté à cette solution particulière et donc prendre plus de temps. De la même manière, le test des performances du modèle/de la solution peut également être moins bien compris (contrairement aux mesures standard utilisées en AA, telles que la précision ou le rappel), et prendra donc également plus de temps ; il en va de même pour le déploiement et le suivi, toujours en raison de la nature plus personnalisée de la solution.

Tout ceci suppose que la solution Gen IA utilise un modèle de base standard, tel que GPT-4.5 d'OpenIA, Gemini 2.5 de Google ou R1 de DeepSeek, qui peut être interrogé comme une interface de programmation d'application par le développeur. Bien que les modèles de base puissent être créés à partir de zéro, nous pensons que la plupart des organisations n'envisageront pas de le faire ; il serait peut-être plus probable d'affiner un modèle existant, mais cela reste relativement rare (par exemple, https://www.kadoa.com/blog/is-fine-tuning-still-worth-it).

Pourquoi ce détour par les différences entre l'"ancienne" IA et l'IA générative est-il important ? Je pense qu'il l'est pour au moins deux raisons : Premièrement, il est important de savoir où les différents défis peuvent se produire et donc quelles parties peuvent prendre plus de temps dans un projet. La figure 1 montre où plus de temps et de ressources - à la fois pour l'équipe de projet interne et pour les parties prenantes externes - peuvent être nécessaires pour les différents types de projets d'IA.

Deuxièmement, le prototypage rapide étant relativement facile dans les projets d'IA, les problèmes de compréhension et d'accès aux données de l'organisation - qui constituent depuis longtemps un problème dans les projets d'IA traditionnels - ne sont découverts qu'à un stade ultérieur, par exemple après la mise au point des prototypes initiaux. En effet, il se peut que les défis liés à la mise en correspondance des éléments du prototype d'IA avec une solution globale qui s'intègre au problème de l'entreprise et aux données disponibles fassent que peu de projets parviennent à la production et que nombre d'entre eux se soldent par un échec.

De même, les éléments sur mesure du projet peuvent s'avérer difficiles, le plus important étant peut-être l'essai convaincant de la solution. Cette étape est essentielle pour s'assurer que l'organisation accepte que la solution soit déployée en production et acceptée en service. D'autres éléments peuvent être des processus généralement plus mécaniques tels que le déploiement et la surveillance. Il est essentiel de s'assurer que ces étapes sont possibles avant d'engager les parties prenantes et de financer un projet.

alors que les approches traditionnelles de l'IA concentrent les efforts sur les premières étapes de la collecte des données et de la construction du modèle (ce qui prend souvent plus de temps que souhaité pour arriver à ce stade), les approches de l'IA générique peuvent montrer des progrès rapides dans le prototypage, mais nécessitent potentiellement un investissement plus important dans les étapes ultérieures d'un projet. Comme toujours, il s'agit de généralisations, mais nous espérons qu'elles illustrent les tendances générales de ces projets.

Pour en revenir au point de départ de cette série, le retour sur investissement est apparemment en baisse pour les projets d'IA. Peut-être est-ce lié à l'augmentation des projets d'IA générique et à la capacité de créer rapidement des prototypes, avant même de s'engager avec les affaires ? Cela pourrait-il conduire à une mauvaise répartition des ressources, car les démonstrations convaincantes qui ne peuvent pas être converties en applications utiles gagnent du financement et de l'attention au détriment de projets moins ambitieux et moins attrayants qui sont en fait plus pratiques et plus utiles ? Il s'agit bien sûr de pures spéculations de ma part, mais la réponse reste la même, et c'est la principale leçon à tirer de cette série d'articles, quelle que soit la saveur de l'IA, à savoir qu'il faut d'abord s'engager avec les affaires pour comprendre le besoin de l'entreprise et le contexte environnant pour toute solution potentielle que nous prévoyons de construire.

Dans cette série, j'ai mis en évidence certaines des étapes que les personnes qui se lancent dans un projet d'IA typique devront franchir, en dehors de la tâche consistant à construire le modèle d'IA. Ces articles se sont concentrés en particulier sur la compréhension du problème de l'entreprise, les discussions avec les parties prenantes, la mise en correspondance de la solution avec la logique de l'entreprise et les aspects pratiques de la gestion d'un projet d'IA. Tout au long de ces articles, l'accent a été mis sur la création de valeur pour l'entreprise dans le cadre du projet d'IA, ce qui, je l'espère, constituera un point de départ utile pour d'autres.