Mauvaise adéquation entre la sélection du programme d’éducation et de formation tout au long de la vie et les objectifs de l’entreprise
De nombreuses entreprises se lancent à corps perdu dans les grands modèles de langage (LLM) sans bien comprendre ce qu’elles cherchent à résoudre. La technologie en elle-même n’est pas une solution. C’est un outil. Si vous choisissez un LLM uniquement parce qu’il est bien classé dans les benchmarks ou qu’il semble prometteur dans une démo, et que vous ne l’adaptez pas aux besoins réels de votre entreprise, vous perdrez du temps, de l’argent et de la crédibilité en interne.
Ce type de désalignement est plus fréquent que vous ne le pensez. Selon Beatriz Sanz Saiz, Global AI Sector Leader chez EY, l’une des principales erreurs commises par les organisations est de ne pas aligner la sélection des LLM sur les résultats de l’entreprise. Cela signifie qu’elles se laissent entraîner par le battage marketing au lieu de fonder leurs décisions sur des cas concrets. C’est comme si vous achetiez un jet alors que vous n’aviez besoin que d’une voiture. M. Saiz souligne également la complexité cachée de l’intégration de ces systèmes dans l’infrastructure existante, qui n’est pas prête à l’emploi. Cela prend les équipes au dépourvu et retarde la livraison.
Maitreya Natu, Senior Scientist chez Digitate, l’a très bien dit : les entreprises choisissent souvent un modèle d’abord, puis y adaptent un cas d’utilisation. C’est l’inverse. Commencez par le problème. Quel goulot d’étranglement essayez-vous d’éliminer ? Quelles décisions seraient plus intelligentes, plus rapides ou plus évolutives avec un LLM ? Si les réponses ne sont pas claires, vous n’êtes peut-être pas encore prêt.
Naveen Kumar Ramakrishna, de Dell Technologies, met en évidence une tendance similaire : les LLM sont intégrés dans des projets parce qu’ils sont populaires, et non parce qu’ils sont nécessaires. Parfois, des solutions plus simples, comme un système basé sur des règles ou un petit modèle d’apprentissage automatique, auraient mieux fait l’affaire. Les équipes se lancent dans des projets de grande envergure sans véritable raison et se retrouvent dans un gouffre de coûts, de retards et de performances douteuses.
Si vous n’adaptez pas l’outil à la tâche, vous rencontrerez des problèmes d’utilisation, vous ne répondrez pas aux attentes et, dans de nombreux cas, vous n’arriverez même pas à la production. La confiance dans votre feuille de route en matière d’IA en prend un coup et il devient difficile d’obtenir le feu vert pour les projets futurs. Soyez donc stratégique, et non réactif.
L’importance d’un problème bien défini et de résultats mesurables
Avant même de penser à la sélection d’un modèle, clarifiez le problème. Cela semble évident, mais c’est l’étape que les entreprises sautent le plus souvent. Il doit s’agir d’une session de travail réunissant les responsables techniques, les chefs d’entreprise et les utilisateurs finaux, afin de définir les frictions, le flux de travail actuel et les critères de réussite. Pas de vagues objectifs d’optimisation. Des mesures réelles liées au débit, à la précision, au temps de réponse ou au coût.
Naveen Kumar Ramakrishna, de Dell, le dit clairement : sans une solide compréhension du problème, vous construisez pour les mauvaises cibles. Le résultat ? Vous surinvestissez dans d’énormes modèles pour de petites tâches ou vous déployez des modèles génériques là où la spécificité est nécessaire. Dans tous les cas, il y a du gaspillage.
Max Belov, directeur technique de Coherent Solutions, ajoute une autre couche importante : identifiez le type de tâche dont il s’agit. S’agit-il d’un chatbot ? D’un résumé de document ? De la génération de code ? Différents LLM excellent dans différents domaines. Des modèles comme GPT-4 ou Claude v3.5 Sonnet offrent de bonnes performances générales. D’autres, comme LLaMA de Meta ou Gemma de Google, sont des logiciels libres et se prêtent à un réglage fin. Déterminez ce point dès le départ afin que votre modèle soit adapté à votre charge et à votre domaine réels.
La définition de résultats mesurables permet de garder les pieds sur terre. C’est ainsi que vous d « éviter les dérives. Et une fois que vous avez atteint votre première étape, vous avez établi le bien-fondé de la mise à l » échelle à l’aide de données réelles, et non d’un retour sur investissement théorique. C’est ce que veulent les équipes de direction : des preuves, pas de l’enthousiasme.
Une fois que le cas d’utilisation est clair, validez vos idées dans le monde réel. Effectuez quelques essais pilotes. Évaluez la facilité d’utilisation et voyez si le modèle s’adapte bien aux cas particuliers et aux conditions de mise à l’échelle. Vous découvrirez les problèmes à un stade précoce, avant de vous engager dans des contrats, des intégrations ou des infrastructures irrécupérables.
On attend des cadres qu’ils gèrent les risques et qu’ils aient un impact. Pour bien investir dans le LLM, il faut d’abord définir clairement le problème à résoudre et la manière dont les performances seront mesurées. Tout le reste en dépend.
Évaluation du coût total de possession et de l’évolutivité
Le coût total de possession (TCO) va bien au-delà des frais de licence ou de l’accès à l’API. L’exécution de modèles de langage de grande taille peut évoluer rapidement en termes de consommation de calcul, d’utilisation de la bande passante et de dépendance à l « égard de l’infrastructure. Si vous n » évaluez pas rapidement les implications à long terme, ce qui est au départ un projet d’IA passionnant peut devenir une charge insoutenable pour les ressources.
Naveen Kumar Ramakrishna, de Dell Technologies, a déclaré qu’il y a un an, n’importe qui pouvait accéder librement à leurs modèles hébergés en interne. Aujourd’hui ? L’accès est limité. Pourquoi ? L’augmentation du trafic et des coûts de calcul. C’est un signal d’alarme clair. La plupart des entreprises sous-estiment les dépenses d’exécution, en particulier les coûts des jetons, la latence de l’inférence et les implications de la charge de données. Elles pensent que le gros du travail s’arrête après la mise au point, mais c’est précisément à ce moment-là que les coûts réels commencent à augmenter.
Ken Ringdahl, directeur technique d’Emburse, l’a dit sans ambages : il est essentiel de comprendre les modèles de croissance de vos cas d’utilisation. Testez les modèles sous pression. Ne pensez pas que vous utiliserez le même modèle de la même manière dans six mois. Chaque requête adressée à un LLM coûte du temps de calcul. Pour les modèles plus importants, ce coût augmente considérablement. Si votre utilisation augmente de manière inattendue, en raison d’une adoption interne ou d’une demande des utilisateurs, les coûts suivront. Sans contrôle des tarifs ni planification architecturale, vous perdez le contrôle.
En outre, les problèmes de performance n’affectent pas seulement les utilisateurs, mais aussi les coûts d’infrastructure. Si les résultats ne sont pas exacts, les utilisateurs réinterrogent le système. Cela augmente le nombre de transactions et la charge du système sans pour autant augmenter la valeur des résultats. Le gaspillage de jetons, la latence et l’inefficacité informatique peuvent devenir des responsabilités récurrentes.
Les dirigeants doivent exiger une modélisation des coûts dès le départ. Comprenez les charges d’inactivité et les charges de pointe, les scénarios de redondance et les schémas d’utilisation de l’informatique. Choisissez le modèle le plus petit qui réponde au cas d’utilisation et intégrez les contraintes dès le début. Les LLM apportent de la valeur lorsqu’ils sont bien dimensionnés, et pas seulement lorsqu’ils sont puissants.
La nécessité de personnaliser et d’affiner les modèles disponibles sur étagère
Les LLM prêts à l’emploi semblent prometteurs à première vue, mais la plupart des environnements professionnels ne sont pas prêts à l’emploi. La façon dont vos équipes travaillent, la terminologie qu’elles utilisent, les documents qu’elles traitent, rien de tout cela n’est générique. Cela signifie que les modèles à usage général ne sont souvent pas à la hauteur lorsqu’ils sont placés dans des flux de travail réels sans un certain niveau d’adaptation.
Maitreya Natu, de Digitate, a mis en évidence cette erreur fondamentale : les entreprises utilisent des modèles génériques pour résoudre des problèmes spécifiques à un domaine et doivent ensuite réparer manuellement ce qui aurait dû être automatisé dès le départ. Cela annule tout gain de productivité et augmente les coûts opérationnels. Les modèles généraux peuvent servir de support au prototypage et à l’idéation, mais les cas d’utilisation à haute fiabilité, en particulier dans les industries réglementées ou techniques, nécessitent un meilleur alignement par le biais d’une mise au point ou d’un affinement du modèle.
Max Belov, directeur de la technologie chez Coherent Solutions, approfondit la question. Certains modèles sont optimisés pour les conversations, comme les assistants virtuels ou les chatbots. D’autres sont plus performants lorsqu’ils sont utilisés pour résumer des documents techniques, générer du code logiciel ou traiter des tâches multimodales. Vous devez cartographier l’ensemble des compétences pour fonctionner. Sans cela, vous risquez d’avoir un modèle techniquement avancé mais peu performant en contexte.
La personnalisation signifie également l’intégration de données propriétaires ou d’invites conçues pour refléter votre activité réelle. Cela nécessite un travail de préparation. Vous avez besoin de flux de travail clairs, de scripts de cas d’utilisation et d’ensembles de formation étiquetés. Une fois déployés, ces modèles doivent être contrôlés, ajustés et évalués en permanence pour s’assurer qu’ils sont alignés.
Du point de vue des dirigeants, la conclusion est simple : ne traitez pas les MLD comme des logiciels de base. Évaluez où se termine le logiciel standard et où commence la personnalisation. Intégrez l’adaptation à votre calendrier de mise en œuvre, budgétez en conséquence et affectez des équipes capables de traduire la logique d’entreprise en données linguistiques. C’est là que les gains d’efficacité se transforment en avantage concurrentiel.
Validation par des essais pilotes et l’engagement des parties prenantes
Si vous envisagez sérieusement de déployer des LLM, la validation par des tests en conditions réelles n’est pas facultative, elle est nécessaire d’un point de vue opérationnel. Les équipes ont besoin de plus qu’une performance technique sur papier. Elles ont besoin de savoir comment le modèle se comporte sous contrainte, avec des entrées réelles, dans leur environnement spécifique.
Beatriz Sanz Saiz, d’EY, souligne l’importance de mener des programmes pilotes contrôlés. Testez quelques modèles sélectionnés avec des cas d’utilisation ciblés. Mesurez la pertinence des résultats, la latence, l’adaptabilité et la gestion des défaillances. Ce processus révèle rapidement comment le modèle réagit à la complexité, à l’échelle et au comportement non standard. Il permet également de déterminer si les performances du modèle correspondent à la structure de votre charge de travail et aux exigences de votre entreprise.
L’implication des parties prenantes de toutes les unités opérationnelles au cours de cette phase permet de faire émerger rapidement les attentes des utilisateurs. Les ventes, la conformité, l’ingénierie, les opérations, chacune de ces équipes apporte un contexte unique. Si les réponses du modèle manquent de profondeur ou de clarté, vous le saurez immédiatement. Cette boucle de rétroaction n’est pas du bruit, c’est de la précision.
Ken Ringdahl, d’Emburse, rend également ce point tangible. Il conseille de tester des techniques d’incitation spécifiques, telles que les types de messages sans coup férir, à un coup férir ou à quelques coups férir, sur plusieurs modules d’apprentissage tout au long de la vie. L’objectif est de déterminer le modèle qui fonctionne le mieux dans des conditions d’utilisation réelles. Les personnes dispersées dans les différents services interagiront différemment avec le modèle. Vous devez savoir quelle version offre une précision constante à l’échelle.
Au niveau de la direction, cela se résume à la limitation des risques. Les essais pilotes permettent d’éviter les échecs sans coûts massifs. Vous obtenez des données sur les performances, des informations sur les frictions et de la crédibilité auprès des parties prenantes internes. Si vous vous lancez dans la production sans cette phase, vous vous exposez à des surprises coûteuses. Si vous validez correctement, vous établissez une stratégie de déploiement défendable, étayée par des preuves.
L’avantage des modèles linguistiques spécifiques à un domaine (DSLM)
Si votre entreprise opère dans un domaine spécialisé, comme les assurances, la juricomptabilité, les soins de santé ou le droit, vous devriez sérieusement évaluer les DSLM. Les modèles linguistiques spécifiques à un domaine sont conçus pour être précis dans des environnements spécialisés. Ils comprennent la structure, la terminologie et les résultats attendus d’une manière que les modèles à usage général ne peuvent tout simplement pas comprendre.
Beatriz Sanz Saiz, d’EY, note que les DSLM sont de plus en plus courants dans des secteurs tels que la fiscalité indirecte et la souscription d’assurance. Pourquoi ? Parce que lorsque la précision et l’efficacité ne sont pas négociables, les DSLM sont opérationnels. Un modèle généraliste peut comprendre le contexte à un niveau superficiel, mais un DSLM formé sur des ensembles de données spécifiques à l’industrie offre une plus grande certitude, moins d’ambiguïté et une réduction du travail à refaire.
La spécialisation ne signifie pas qu’il faille renoncer à la flexibilité. De nombreux DSLM sont conçus pour prendre en charge la formation modulaire. Cela signifie que l’intégration de vos données propriétaires dans des tâches spécifiques au processus, à l « évaluation des risques, à la classification des sinistres, à l’interprétation de la conformité, devient plus transparente. Vous contrôlez l » évolution des performances en dispensant une formation sur des sujets importants pour votre secteur d’activité.
Ce type de modèle accélère également l’adoption interne. Lorsque les résultats reflètent les attentes et que le langage utilisé correspond à l’environnement opérationnel, la confiance dans le système s’accroît plus rapidement. Les chefs de projet deviennent des défenseurs plutôt que des sceptiques. Les gains d’efficacité deviennent visibles sans intervention humaine constante.
Les dirigeants qui réfléchissent au retour sur investissement à long terme doivent se demander si la précision du domaine justifie la mise à niveau d’un modèle général. Pour la plupart des moyennes et grandes entreprises opérant dans des secteurs complexes, c’est le cas. L’écart entre une précision générale de 85 % et une pertinence contextuelle de 96 % peut se traduire par un impact commercial significatif. Plus le modèle se rapproche de la façon dont votre entreprise parle et pense, plus il sera performant.
L’intégration, la qualité des données et la compatibilité sont des facteurs critiques
Les LLM n’apportent pas de valeur ajoutée de manière isolée, ils fonctionnent à l’intérieur des systèmes. Trop d’organisations sous-estiment ce qu’il faut faire pour intégrer un modèle linguistique dans les systèmes de production, les flux de travail et les plates-formes. C’est là que les projets échouent.
Naveen Kumar Ramakrishna, de Dell Technologies, en a fait l’expérience. Les problèmes d’intégration, les dépendances entre plateformes et les problèmes de données non pris en compte ne ralentissent pas seulement les projets, ils peuvent les envoyer dans des limbes indéfinis. De nombreuses organisations ne comprennent pas parfaitement leurs propres pipelines de données ou la manière dont leurs informations circulent dans les systèmes. Lorsque des disparités dans la structure, la qualité ou l’échelle des données sont découvertes tardivement, elles entraînent des retouches coûteuses en temps et en argent.
Les équipes ont également tendance à supposer qu’elles peuvent se déployer sur n’importe quel environnement, on-prem, hybride, cloud public, sans contraintes. Mais en réalité, les LLM interagissent différemment avec l’infrastructure. Les incompatibilités affectent les performances, la latence et les coûts. Vous devez évaluer l’environnement d’hébergement dès le début avec la même attention que celle que vous portez au modèle lui-même.
La qualité des données est un autre angle mort. Si votre modèle est formé ou affiné sur des données internes bruyantes ou incohérentes, la précision se dégradera rapidement. Un étiquetage incohérent, des lacunes dans les enregistrements historiques ou un mauvais formatage compromettront la fiabilité des résultats. Cela signifie que les équipes en aval devront vérifier ou ajuster manuellement les résultats, réduisant ainsi à néant tout gain de productivité.
Du point de vue de la direction, l’intégration et la qualité des données ne sont pas des considérations techniques secondaires, elles sont essentielles à l’adoption. Assurez-vous que vos équipes cartographient l’écosystème de données actuel et valident la compatibilité de l’ensemble de la pile, y compris les API, les outils d’orchestration et l’infrastructure de surveillance. L’objectif n’est pas seulement de faire fonctionner un LLM, mais de s’assurer qu’il apporte une valeur ajoutée sans interrompre vos processus.
Garantir la sécurité et la confidentialité des données dans les déploiements de LLM
La sécurité et la confidentialité des données ne sont pas des caractéristiques, ce sont des exigences. Si vous déployez des LLM sans comprendre comment vos données sensibles sont stockées, traitées ou formées, vous vous exposez à des risques opérationnels et de réputation.
Max Belov, directeur technique chez Coherent Solutions, souligne que les déploiements sur site ou dans un cloud privé offrent les niveaux de contrôle les plus élevés. Pour les organisations qui traitent des données réglementées ou qui sont soumises à des cadres de conformité stricts, il ne s’agit pas d’une option. C’est la base. Les modèles basés sur le Cloud peuvent être très performants et évolutifs, mais selon le fournisseur, les politiques de résidence, de conservation et d’accès aux données peuvent être peu claires ou difficiles à appliquer.
Naveen Kumar Ramakrishna, de Dell, présente un argument stratégique : la confidentialité des données doit être au cœur de l’architecture. Cette décision a une incidence sur tous les aspects, depuis le choix du fournisseur jusqu’à l’alignement de la politique interne. Si vous ne voulez pas que des données sensibles quittent votre environnement, structurez votre mise en œuvre en conséquence.
Ken Ringdahl, d’Emburse, conseille d’examiner tout modèle externe avec la plus grande attention. L’utilisation des jetons, les entrées des clients, les journaux et même les invites peuvent contenir des informations privées. Avant que les données ne soient envoyées hors de la plateforme, les détails sensibles doivent être nettoyés ou expurgés, en particulier dans des secteurs tels que les services financiers, le droit ou la santé. Ne partez pas du principe que le fournisseur de la plateforme vous met en conformité, validez tout.
Ce qui échappe souvent aux dirigeants, c’est que les faux pas en matière de protection de la vie privée n’entraînent pas seulement des sanctions. Ils sapent la confiance et ralentissent l’adoption. Le modèle peut fonctionner, mais si les parties prenantes n’ont pas confiance dans le traitement des données, elles l’éviteront. Intégrez la protection de la vie privée dans votre conception, par le biais d’une stratégie environnementale, d’un examen des fournisseurs, de protocoles internes et d’une formation.
La sécurité n’est pas vérifiée à la fin. Commencez par fixer des objectifs en matière de protection de la vie privée, structurez-les et déployez des modèles qui renforcent la confiance au fur et à mesure qu’ils se développent.
Adopter des solutions à code source ouvert, évolutives et rentables
Vous n’avez pas besoin du modèle le plus grand ou le plus populaire du marché pour créer de la valeur. Ce dont vous avez besoin, c’est d’un modèle linguistique qui corresponde à votre activité, qui s’adapte au fil du temps, qui vous permette de maîtriser vos coûts et qui vous donne le contrôle. C’est exactement là qu’interviennent les logiciels libres et les LLM à petite échelle.
Naveen Kumar Ramakrishna, de Dell Technologies, recommande de commencer modestement, de déployer le modèle le plus simple qui gère efficacement la tâche et de l’adapter intelligemment en fonction des résultats mesurables. Un modèle plus petit, s’il est correctement formé ou ajusté avec des données pertinentes, peut surpasser un modèle plus grand qui n’est pas optimisé pour votre domaine ou votre type de tâche. Il coûtera également beaucoup moins cher à exploiter et à intégrer.
Les LLM à code source ouvert, comme Mistral, la série LLaMA de Meta ou Gemma de Google, vous donnent un contrôle total sur le déploiement. Vous évitez le verrouillage du fournisseur, ce qui réduit les risques en cas de modification des prix ou des conditions commerciales. Vous avez également la possibilité d’adapter et d’héberger les modèles sur votre infrastructure, dans le cloud, sur site ou hybride. C’est essentiel si votre stratégie de données dépend du contrôle et de la conformité.
Max Belov, directeur technique de Coherent Solutions, note que certaines des plateformes les plus adaptées aux entreprises proposent désormais des modèles hautement personnalisables, dotés de fonctions de conformité avancées et s’intégrant facilement dans des configurations de clouds privés. Ces cadres ouverts permettent aux équipes d’affiner les performances, d’adapter l’utilisation à la demande et d’intégrer les LLM dans les applications d’entreprise avec un minimum de perturbation. Cela signifie une réduction de la latence, une plus grande réactivité et une plus grande confiance de la part des parties prenantes internes.
Cette voie encourage également un état d’esprit plus itératif. Vous pouvez valider les performances dans des charges de travail réelles, prouver la valeur commerciale, puis allouer plus de capacité de calcul ou étendre les cas d’utilisation selon les besoins. Vous ne prenez pas un engagement surdimensionné basé sur la perception du marché, vous construisez un déploiement basé sur les réalités du système.
Pour les équipes dirigeantes, en particulier celles qui gèrent les coûts et les attentes en matière de retour sur investissement, les modèles à source ouverte et de taille adaptée sont des options stratégiques. Ils s’alignent mieux sur les cycles budgétaires à long terme, la gouvernance informatique et la résilience opérationnelle. Il s’agit ici d’une question de contrôle et non de compromis. Choisissez le modèle qui correspond à votre infrastructure, à vos données et à vos objectifs de croissance, et pas seulement celui qui a le vent en poupe.
Dernières réflexions
Les LLM ne sont pas magiques, ce sont des systèmes. Si vous voulez qu’ils donnent des résultats, vous devez les traiter comme n’importe quel autre actif stratégique. Cela signifie qu’il faut les aligner sur les objectifs réels de l’entreprise, construire autour de votre propre infrastructure et des réalités des données, et prendre des décisions basées sur les résultats, et non sur le battage médiatique.
Le coût réel d’une mauvaise planification n’est pas seulement un gaspillage de ressources informatiques. Il s’agit de l « échec de l’adoption, du blocage de l’innovation et de la perte de confiance interne. Les dirigeants n’ont pas besoin d » être des experts en transformateurs ou en boucles de formation. Mais ils doivent s’approprier le processus de décision, définir les problèmes, valider les cas d’utilisation et exiger de la clarté de la part de leurs équipes.
Commencez modestement. Restez concentré. Cherchez à obtenir une traction dès le début, puis augmentez la taille de votre entreprise avec discipline. Les entreprises qui y parviennent ne sont pas celles qui ont les plus grands modèles. Ce sont celles qui prennent les décisions les plus intelligentes avec ce qu’elles ont.
