Lucie : comment Linagora veut contenir le coût de son IA générative française

Faire tourner une intelligence artificielle générative ne consiste pas seulement à entraîner un modèle puis à le rendre accessible sur une page web. Chaque question posée par un utilisateur mobilise des puces coûteuses, de l’électricité, de la mémoire et une infrastructure capable d’absorber des pics de fréquentation. Pour Lucie, son assistant open source en français, Linagora cherche donc à résoudre une équation centrale : proposer un service crédible sans reproduire les dépenses des géants américains du cloud.

Au 15 janvier 2025, l’entreprise mise sur un ensemble de choix complémentaires : des processeurs graphiques moins chers que les puces vedettes du marché, une organisation sur plusieurs clouds et, à plus long terme, l’étude d’architectures de modèles susceptibles de réduire la quantité de calcul nécessaire. Cette stratégie répond à deux impératifs souvent liés dans l’IA générative : la maîtrise des coûts et la souveraineté des données.

Lucie n’est pas ChatGPT, mais vise le même type d’usage

L’expression « ChatGPT français » résume une ambition, mais elle peut prêter à confusion. ChatGPT est le nom de l’assistant d’OpenAI. Lucie est, de son côté, le projet d’assistant virtuel open source porté par Linagora. Les deux services appartiennent à la même grande famille d’outils : des assistants capables de produire du texte et de dialoguer à partir d’instructions rédigées en langage naturel.

Lucie s’appuie sur un modèle de langage de 7 milliards de paramètres. Un paramètre est une valeur ajustée pendant la phase d’apprentissage afin que le modèle puisse repérer des régularités dans les textes et générer une réponse. Le nombre de paramètres renseigne sur l’échelle d’un modèle, mais ne suffit pas à mesurer sa qualité. Les données utilisées, les méthodes d’entraînement, l’adaptation à une langue, les garde-fous et les conditions d’exécution comptent tout autant.

Le format de 7 milliards de paramètres place Lucie parmi les modèles qui peuvent être plus simples à déployer qu’un très grand modèle, tout en restant capables de répondre à de nombreuses demandes conversationnelles. Cette taille n’élimine toutefois pas les coûts : lorsqu’un service est utilisé simultanément par un grand nombre de personnes, les calculs nécessaires à chaque réponse deviennent rapidement un poste de dépense majeur.

Pourquoi le coût de l’inférence est déterminant

À chaque prompt, c’est-à-dire à chaque consigne ou question envoyée à l’assistant, le modèle doit analyser le contexte puis générer une réponse, mot après mot. Cette opération d’inférence sollicite principalement des processeurs graphiques, ou GPU. Ces puces ont été conçues pour effectuer de nombreux calculs en parallèle, une caractéristique particulièrement adaptée à l’IA.

Le problème est que les GPU les plus puissants sont aussi rares, énergivores et onéreux. Il ne suffit donc pas de sélectionner la puce qui obtient les meilleures performances théoriques. Une entreprise qui fournit un assistant doit évaluer un compromis plus concret : combien coûte une carte, combien consomme-t-elle, quel débit peut-elle fournir, et combien de cartes faudra-t-il installer pour répondre à la fréquentation attendue ?

C’est dans cette logique que Linagora étudie les GPU de génération antérieure ou moins haut de gamme. L’objectif n’est pas de battre à tout prix les performances d’une infrastructure constituée de cartes très récentes. Il est de disposer d’une capacité de calcul compatible avec les besoins de Lucie à un coût soutenable.

Des RTX A4000 plutôt que des GPU très haut de gamme

Pour son environnement de test, Linagora s’appuie sur Exaion, le cloud d’EDF. L’infrastructure lui donne accès à des cartes Nvidia RTX A4000 dotées de 16 Go de mémoire graphique, issues d’un supercalculateur. Le choix permet aux équipes de mettre au point et d’évaluer Lucie sans s’orienter immédiatement vers les GPU les plus coûteux du marché.

Les montants et caractéristiques avancés par Linagora illustrent l’écart économique recherché. Une RTX A4000 est estimée à 1 500 dollars, quand une Nvidia H100 peut atteindre 25 000 dollars. La différence est considérable, même si ces deux cartes ne jouent pas dans la même catégorie de puissance et ne répondent pas exactement aux mêmes usages.

L’enveloppe thermique, souvent désignée par l’acronyme TDP, donne un ordre de grandeur de la chaleur et de l’énergie à gérer pour un composant. Avec 140 watts, la RTX A4000 est présentée comme moins énergivore que les 350 watts de la H100. Pour une infrastructure qui fonctionne en continu, cet écart peut peser sur la facture électrique, mais aussi sur le refroidissement nécessaire dans les centres de données.

Les équipes de Linagora citent également des cartes Nvidia L4 parmi les options envisagées. Là encore, le raisonnement consiste à comparer les ressources disponibles selon les besoins réels de l’inférence plutôt que de concentrer tous les investissements sur les GPU les plus chers.

Dix prompts par seconde, un premier repère à interpréter

Les essais menés avec la RTX A4000 permettent à Linagora de traiter environ 10 prompts par seconde. Ce chiffre fournit un indicateur utile, mais il ne se lit pas comme un nombre fixe d’utilisateurs servis à la seconde. La longueur des questions, la taille des réponses, le contexte conservé dans une conversation et le nombre d’utilisateurs simultanés influencent tous la capacité effective d’un assistant.

Linagora considère néanmoins ce débit comme insuffisant au regard de son ambition de montée en charge. C’est le point de bascule de sa réflexion : une carte peu coûteuse peut être intéressante à l’unité, mais il faut encore disposer d’assez de capacité pour que l’expérience reste fluide lorsque les requêtes se multiplient.

L’entreprise ne cherche donc pas uniquement à réduire le prix du matériel. Elle doit aussi répartir les charges, éviter l’engorgement et adapter l’infrastructure au volume de demandes. Cette exigence explique le choix d’une architecture dite multicloud.

Le multicloud, entre capacité de calcul et souveraineté

Une architecture multicloud consiste à utiliser les ressources de plusieurs fournisseurs plutôt que de dépendre d’un seul environnement. Dans le cas de Lucie, Linagora envisage de combiner des services, notamment ceux d’Exaion, d’OVHcloud et de Scaleway.

Cette organisation peut apporter de la souplesse. Elle permet de répartir une charge de calcul importante, de limiter le risque qu’un unique prestataire devienne un goulot d’étranglement et de choisir les ressources les plus adaptées à chaque besoin. Pour un assistant génératif, cette capacité d’ajustement est précieuse : la demande peut varier fortement selon les heures, les usages ou le succès du service.

Le multicloud n’est cependant pas une solution automatique à tous les problèmes. Il demande une orchestration technique plus complexe afin de faire circuler les traitements, d’assurer la disponibilité du service et de maintenir un niveau de sécurité cohérent entre plusieurs infrastructures. Le gain attendu vient de la possibilité de mieux dimensionner les ressources et de ne pas payer durablement pour une capacité inutilisée.

Pourquoi Linagora s’intéresse à l’architecture Mamba

Au-delà du matériel, Linagora envisage à l’avenir l’utilisation de modèles de type Mamba. Cette piste concerne la structure même du modèle, et non uniquement les serveurs qui l’exécutent.

Les grands modèles de langage actuellement les plus connus reposent très souvent sur l’architecture des transformers. Celle-ci est particulièrement efficace pour relier les éléments d’un texte entre eux, mais son coût de calcul et de mémoire peut augmenter fortement lorsque le contexte traité devient long. Les architectures Mamba reposent sur une autre approche, apparentée aux modèles à espace d’états. Elles sont conçues pour traiter des séquences de manière plus efficace et pour sélectionner l’information pertinente au fil du traitement.

Dans la stratégie évoquée par Linagora, Mamba pourrait réduire les besoins en mémoire et en puissance graphique. La promesse est importante : si un modèle demande moins de ressources pour fournir un résultat comparable sur certaines tâches, il devient possible d’envisager des coûts d’inférence plus faibles et une utilisation plus souple des GPU disponibles.

Il s’agit toutefois d’une orientation envisagée, pas d’une bascule déjà actée. Les architectures ne se comparent pas uniquement sur leur efficacité théorique. Elles doivent aussi être évaluées sur la qualité des réponses, leur comportement en français, leur compatibilité avec les outils existants et leur aptitude à des usages conversationnels réels.

La souveraineté numérique comme critère d’infrastructure

La maîtrise des dépenses est indissociable, pour Linagora, d’un autre enjeu : la souveraineté numérique. L’entreprise privilégie des infrastructures labellisées ou répondant aux exigences associées à SecNumCloud, le référentiel français de qualification pour des services cloud de confiance.

L’objectif est de mieux encadrer l’hébergement et le traitement des données, notamment pour les organisations sensibles à leur localisation ou aux règles juridiques applicables. Linagora met aussi en avant la volonté d’isoler les données de réglementations extraterritoriales, telles que le Cloud Act américain.

Cette préoccupation ne se réduit pas à une question de nationalité des serveurs. Elle concerne également le contrôle de la chaîne technique : fournisseur de cloud, conditions d’exploitation, accès aux données, sécurité des environnements et cadre contractuel. Pour des entreprises et des administrations, ces critères peuvent peser autant que les performances brutes d’un assistant.

Ce qu’il faudra surveiller pour Lucie

La trajectoire de Lucie dépendra d’abord de sa capacité à offrir une qualité de réponse utile, stable et adaptée aux attentes des utilisateurs francophones. Mais son modèle économique sera tout aussi décisif. Le choix de GPU moins chers comme les RTX A4000 permet de réduire la barrière d’entrée, sans suffire à lui seul à garantir le passage à l’échelle.

Les prochains arbitrages porteront sur la manière dont Linagora combinera les clouds envisagés, sur la capacité réelle de l’infrastructure à absorber davantage de requêtes et sur l’éventuelle intégration de modèles de type Mamba. Ces décisions détermineront si l’entreprise peut faire coexister trois objectifs parfois contradictoires : une IA performante, des coûts maîtrisés et un hébergement répondant aux attentes de souveraineté.

Pour les utilisateurs, l’enjeu est concret. Derrière la simplicité apparente d’une fenêtre de conversation, la qualité du service dépend d’une infrastructure lourde et de choix techniques très précis. La stratégie de Linagora montre qu’une IA générative française ne se joue pas seulement sur le modèle lui-même, mais aussi sur la capacité à le faire fonctionner durablement.