L'IA sur vos propres serveurs : comment ajouter un LLM à vos systèmes internes et qui le construit

Oui, une entreprise peut utiliser l'IA sur ses tickets de support, ses documents et ses outils internes sans que ces données quittent ses propres serveurs. Un grand modèle de langage, ou LLM, est le type d'IA qui fait fonctionner les assistants conversationnels. Certains de ces modèles peuvent être téléchargés et exécutés sur des serveurs que l'entreprise contrôle, dans ses propres locaux ou dans son propre compte cloud, puis connectés aux systèmes que les équipes utilisent déjà.

Le modèle est la plus petite partie du travail. Ce qui décide si le système entre dans l'usage quotidien, c'est le choix de la tâche, une description écrite d'une réponse correcte, et une personne nommément désignée qui vérifie les réponses et exploite le système après le lancement. La dernière partie de cet article montre comment vérifier une entreprise qui propose de le construire.

Que signifie concrètement « l'IA sur nos propres serveurs » ?

« L'IA sur nos propres serveurs » signifie que le modèle tourne sur du matériel que votre entreprise contrôle, et qu'aucun texte n'est envoyé à une entreprise d'IA extérieure. Votre ticket, votre document ou votre question va de votre système au modèle et revient, sans jamais quitter votre réseau ni votre compte cloud.

C'est possible grâce aux modèles à poids ouverts. Un modèle à poids ouverts est un modèle dont le développeur publie les fichiers, de sorte que n'importe qui peut les télécharger et faire tourner le modèle selon sa licence. Les services d'IA que vous utilisez dans un navigateur fonctionnent autrement : votre texte part vers les serveurs du fournisseur et y est traité.

Garder les données en interne ne concerne pas que le modèle. Le système conserve aussi des logs, un index de recherche de vos documents, les exemples sur lesquels il est testé et les écrans où des personnes vérifient ses réponses. Chacun de ces éléments contient des copies de vos données, et chacun doit lui aussi rester sur vos serveurs.

Quelles tâches de nos systèmes internes un LLM peut-il prendre en charge ?

Un LLM est utile là où, aujourd'hui, des personnes lisent du texte puis remplissent, trient ou rédigent quelque chose. Tâches typiques dans une entreprise :

• Lire les documents entrants. Formulaires, factures, contrats et avis deviennent des champs dans le système qui en a besoin
• Trier les tickets de support. Le sujet, l'urgence et la bonne équipe sont définis avant qu'une personne n'ouvre le ticket
• Rédiger des réponses. Le modèle écrit un brouillon, et un agent du support le modifie puis l'envoie
• Répondre aux questions des équipes à partir des documents internes. Politiques, manuels et anciens tickets, avec un lien vers la source de chaque réponse. C'est ce qu'on appelle souvent « un ChatGPT privé »
• Résumer des contenus longs. Fils d'e-mails, notes d'appels et dossiers, pour la prochaine personne qui les reprend
• Vérifier des documents par rapport à une liste. Si un contrat contient les clauses requises, ou si un dossier de demande contient toutes les pièces nécessaires

Certains travaux conviennent mal à un LLM, et mieux vaut le savoir avant que le projet ne commence :

• Les calculs et les règles déjà exacts. Du code ordinaire les exécute plus vite, et il donne la même réponse à chaque fois
• Les tâches pour lesquelles personne ne sait dire à quoi ressemble une réponse correcte. Sans cela, personne ne peut savoir si le modèle fonctionne
• Les décisions finales concernant des personnes, avec une portée juridique ou financière, comme refuser un client, sans qu'un humain tranche
• Les actions irréversibles que personne ne vérifie, comme l'envoi d'argent

Un test simple pour n'importe quelle tâche : elle convient à un LLM quand une personne l'accomplit aujourd'hui en lisant du texte, que le résultat correct peut être écrit noir sur blanc et qu'un résultat faux peut être intercepté avant de causer du tort.

Nos données ne peuvent pas quitter nos serveurs. Pouvons-nous quand même utiliser l'IA ?

Oui. Le choix porte sur l'endroit où tourne le modèle, et seuls deux des trois dispositifs courants gardent les données sur des serveurs que vous contrôlez :

• Un modèle à poids ouverts sur vos propres serveurs. Le modèle tourne sur du matériel situé dans vos propres locaux ou votre centre de données. Vous obtenez : aucun texte ne quitte votre réseau, et aucune entreprise d'IA extérieure ne le reçoit. En contrepartie : vous achetez des serveurs équipés de processeurs graphiques (GPU), dont les modèles ont besoin pour tourner à une vitesse utile, et votre équipe ou un partenaire les maintient en fonctionnement. Choisissez cette option quand : la réglementation, les contrats clients ou votre propre politique interdisent tout traitement hors de l'entreprise
• Un modèle à poids ouverts dans votre propre compte cloud. Le même type de modèle tourne sur des serveurs que vous louez à un fournisseur cloud, dans votre compte et dans la région que vous choisissez. Vous obtenez : aucun matériel à acheter, de la capacité que vous pouvez ajouter plus tard, et des données qui restent dans votre compte. En contrepartie : le fournisseur cloud exploite les bâtiments et le matériel, et c'est toujours vous qui exploitez le modèle. Choisissez cette option quand : votre entreprise fait déjà tourner ses systèmes dans ce cloud et que vos règles l'acceptent
• Le service d'un fournisseur de modèles. Vous envoyez du texte à un modèle exploité par une entreprise d'IA, directement ou via votre fournisseur cloud, dans le cadre d'un contrat. Vous obtenez : le démarrage le plus rapide, les modèles propres au fournisseur et aucun serveur à exploiter. En contrepartie : les données quittent bel et bien vos serveurs, selon les conditions du fournisseur en matière de stockage, de localisation et de revue. Choisissez cette option quand : les données peuvent sortir dans le cadre d'un contrat, comme des documents déjà publics. Si vos données ne peuvent vraiment pas sortir, cette option est exclue

Une entreprise peut utiliser plus d'un dispositif. Les documents publics peuvent aller au service d'un fournisseur, tandis que les dossiers clients restent sur un modèle que vous exploitez. La règle qui envoie chaque type de données à sa place doit alors être écrite et appliquée. Un article précédent de ce blog, sur l'exploitation d'un LLM dans un périmètre fermé, compare ces options plus en détail.

Qu'un modèle que vous pouvez exploiter vous-même soit assez bon se mesure sur vos propres documents et tickets, et ne se lit pas dans un classement public. Beaucoup de tâches internes sont étroites, comme lire un seul type de formulaire ou répartir des tickets entre une liste connue d'équipes, et un test sur de vrais exemples tirés de votre travail répond à la question.

Les modèles à poids ouverts sont proposés sous des licences différentes, il faut donc que quelqu'un lise la licence du modèle que vous choisissez. Les modèles Qwen3 sortis par Alibaba en 2025 et les modèles gpt-oss d'OpenAI sont publiés sous licence Apache 2.0, tandis que le plus grand modèle ouvert de la version ultérieure Qwen3.8 est accompagné de sa propre licence Qwen3.8-Max. Llama 3.3 de Meta est proposé sous la licence communautaire propre à Meta, qui ajoute des conditions, dont le respect de la politique d'utilisation acceptable de Meta.

Comment ajouter un LLM aux systèmes internes de mon entreprise ?

Un LLM ne remplace pas vos systèmes. Il se place entre eux : il lit du texte à un endroit et dépose un résultat à un autre. L'ajouter à un système interne revient à répondre à quatre questions simples :

• D'où vient le texte ? De l'outil de support, d'une boîte mail partagée, d'un espace de stockage de documents ou d'une base de données
• Où va le résultat ? Dans les champs et les écrans que les équipes utilisent déjà, sous forme de suggestion qu'elles peuvent accepter ou modifier, et non dans un nouvel outil qu'elles doivent penser à ouvrir
• À quoi peut-il toucher ? Uniquement aux données et aux actions dont la tâche a besoin. Un modèle qui trie des tickets n'a pas besoin d'accéder aux remboursements ni aux comptes clients
• Comment l'arrête-t-on ? Un seul interrupteur qui renvoie le travail vers la méthode manuelle, entre les mains de la personne responsable du système

Commencez par une tâche dans un système. Au début, le modèle propose et une personne décide. Le modèle n'est autorisé à agir seul que sur les parties où il continue d'avoir raison sur du travail réel, et la méthode manuelle reste en solution de repli.

Les personnes qui font le travail aujourd'hui devraient façonner le système. Elles savent quels documents sont difficiles, quelles réponses sont fausses et où une erreur coûte de l'argent. Ce sont aussi elles qui vérifieront les réponses pendant les premiers mois, donc leur temps doit figurer dans le plan.

Que doit décider l'entreprise avant d'engager qui que ce soit ?

Avant que quiconque construise un système d'IA pour vous, répondez par écrit à sept questions. Aucune ne demande de formation d'ingénieur, et chaque réponse change ce qu'il faut construire :

• Quelle tâche, dans quel système ? Formulez une tâche en une phrase, par exemple « trier les tickets entrants dans l'outil de support par équipe et par urgence »
• À quoi ressemble un résultat correct ? Rassemblez de vrais exemples avec la bonne réponse, rédigée par les personnes qui font le travail aujourd'hui
• Quelles données le modèle verra-t-il, et où ces données peuvent-elles aller ? Demandez à votre responsable juridique, des risques ou de la protection des données de l'écrire pour chaque type de données
• Combien de travail, et quand ? Le nombre de documents ou de tickets par jour, et l'heure la plus chargée
• Qui vérifie les réponses ? Au début, une personne vérifie chaque réponse. Indiquez qui, et combien d'heures par semaine cela prend
• Que se passe-t-il quand l'IA est indisponible ? Le travail revient aux personnes et attend, au lieu d'être perdu
• Qui l'exploite après le lancement, et que posséderez-vous ? Votre propre équipe ou le prestataire dans le cadre d'un contrat de support ; et, à la fin, le code, les exemples et la documentation

Les réponses écrites à ces sept questions constituent votre cahier des charges. Remises à trois prestataires, elles produisent trois propositions que vous pouvez comparer. Sans elles, vous recevez trois démonstrations d'une fenêtre de chat.

Notre pilote d'IA fonctionne en démo mais n'est jamais passé en production. Qui peut nous aider à le terminer ?

Une démo répond à une seule question : le modèle sait-il faire la tâche sur de bons exemples ? L'usage quotidien en ajoute quatre autres, et un pilote qui reste bloqué les a généralement sautées :

• Qu'est-ce qui compte comme juste ? Un ensemble d'exemples réels avec des réponses validées, et un seuil de réussite que le système doit atteindre
• Les données ont-elles le droit d'y aller ? Un pilote construit sur un service d'IA extérieur ne se transpose pas simplement à des données qui doivent rester sur vos serveurs ; un modèle que vous exploitez vous-même doit être testé à nouveau
• Où vont les mauvaises réponses ? À un endroit où une personne les voit et les corrige avant qu'un autre système ne les utilise
• Qui en est responsable ? Une personne ou une équipe nommément désignée, qui exploite le système, surveille ses réponses et est appelée quand il s'arrête

Terminer un pilote bloqué consiste généralement à construire ces quatre éléments autour du modèle, et non à acheter un meilleur modèle. Un article précédent de ce blog, sur le pilote d'IA qui n'est jamais passé en production, explique chacun d'eux plus en profondeur.

Tout prestataire qui reprend un pilote bloqué a besoin de trois choses de votre part : les exemples du pilote, les documents sur lesquels il a échoué, et le nom de la personne qui sera responsable du système. Un prestataire qui ne demande rien de tout cela prépare une nouvelle démo.

Combien coûte l'exploitation d'un LLM sur vos propres serveurs ?

Cet article ne donne aucun prix. « Un système d'IA sur nos propres serveurs » recouvre des projets dont la taille peut être plusieurs fois supérieure d'un projet à l'autre, et un chiffre annoncé avant que quiconque ait entendu vos réponses aux sept questions ci-dessus est un chiffre commercial, pas une estimation.

Ce qui est utile, c'est de connaître les types de coûts, car la plupart dépendent de décisions que vous maîtrisez :

• Le matériel ou la capacité cloud. Des serveurs avec GPU, achetés ou loués, dimensionnés pour votre heure la plus chargée plutôt que pour une heure moyenne
• Les connexions à vos systèmes. Chaque système dans lequel le modèle lit ou écrit est un chantier à part, avec ses propres droits d'accès et ses propres traces
• Le temps de vos équipes. Les personnes qui rassemblent les exemples, rédigent les bonnes réponses et vérifient les réponses du modèle pendant les premiers mois
• La correction des mauvaises réponses. Des heures de travail de quelqu'un chaque semaine, aussi longtemps que le système tourne
• L'exploitation. Les mises à jour de sécurité, la surveillance des réponses autant que des serveurs, et quelqu'un qu'on appelle quand le système s'arrête
• Le changement de modèle. Un modèle plus récent est testé sur vos exemples avant de remplacer l'ancien, et le test est répété à chaque changement

Le coût suit une logique différente de celle du service d'un fournisseur. Un fournisseur facture la quantité de texte que le modèle lit et écrit. Des serveurs que vous possédez, ou que vous louez au mois, coûtent à peu près la même chose qu'ils soient occupés ou inactifs ; c'est donc le volume de travail qui décide quel dispositif vous coûte le moins.

L'étendue du projet est la part du coût que vous maîtrisez le plus directement. Une tâche, dans un système, pour une équipe : c'est la plus petite première version qui montre encore si le système vaut la peine d'être étendu.

Qui construit des systèmes d'IA qui tournent dans l'infrastructure propre d'une entreprise, et comment les vérifier ?

Quatre types de prestataires répondent quand une entreprise dit « nous voulons de l'IA sur nos propres serveurs » :

• Les éditeurs de logiciels. Ils vendent un produit d'IA prêt à l'emploi que vous installez, comme un assistant conversationnel pour les équipes. Un bon choix pour un assistant généraliste, un moins bon quand la tâche dépend de vos propres systèmes et règles
• Les fournisseurs cloud et leurs partenaires. Ils vendent des modèles sous forme de service managé, où votre texte quitte votre compte, et proposent des outils pour faire tourner des modèles à poids ouverts dans votre propre compte cloud. Certains proposent une aide pour les connecter
• Les sociétés d'ingénierie. Elles construisent la connexion entre un modèle et vos systèmes selon votre cahier des charges, et le contrat décide de la part qui vous revient
• Votre propre équipe. Parfois renforcée par des ingénieurs extérieurs pour la première version

Avant toute chose, demandez à tout prestataire ces preuves :

• Un système d'IA qu'il a mené jusqu'en production dans l'infrastructure d'un client, avec le nom du client quand celui-ci l'autorise
• Ce que fait ce système, en une phrase, et qui l'exploite aujourd'hui
• Ce qui se passe dans ce système quand le modèle donne une mauvaise réponse
• Une démonstration pas à pas sur de vrais documents ou tickets, pas sur des exemples préparés
• Où sont allées les données pendant son travail : si quoi que ce soit, y compris les logs et les copies de test, a quitté les serveurs du client
• Ce qu'il vous remettra : le code, les exemples, les paramètres et la documentation, et si quelque chose reste sa propriété

Écoutez ensuite ce que le prestataire vous demande. Une entreprise qui a déjà construit ce type de système pose ces questions avant de chiffrer :

• Quelle tâche, dans quel système, et qui la fait aujourd'hui
• Quelles données le modèle verra, et ce que vos règles autorisent pour elles
• Si vous disposez de vrais exemples avec les bonnes réponses, et qui peut en rédiger d'autres
• Qui vérifiera les réponses, et qui sera responsable du système un an après le lancement

amBrain a-t-il mené un modèle de langage jusqu'en production ?

Parmi les types de prestataires décrits ci-dessus, amBrain est une société d'ingénierie.

Ce qu'amBrain peut dire publiquement de son propre travail avec les modèles de langage, en intégralité : Nous avons mené une intégration LLM jusqu'en production dans le périmètre FinTech d'un client : extraction et normalisation d'avis non structurés émis par des brokers et des places de marché — opérations sur titres, modifications d'instruments et de marges — en enregistrements structurés que consomme le système de trading.

Le client n'est pas nommé, l'endroit où le modèle a tourné dans ce projet n'est pas divulgué, et aucun chiffre sur ce projet n'est donné. Cet article n'en est pas une étude de cas. Il explique comment planifier et choisir, et il n'affirme pas qu'amBrain a construit un système de tickets de support, un assistant pour les équipes ou tout autre système d'IA interne que l'extraction d'avis mentionnée ci-dessus.

Au-delà de cette intégration : amBrain construit des logiciels depuis 2019. Nous travaillons en trois formats : livraison complète, équipe dédiée ou ingénieurs intégrés à votre équipe. Le client conserve la pleine propriété du produit et du code, à l'exception de nos composants réutilisables.

Si vous en êtes au début, l'étape suivante utile n'est pas la recherche d'un fournisseur. C'est une page avec les réponses écrites aux sept questions de cet article. Donnez la même page à chaque prestataire avec qui vous discutez, nous ou n'importe qui d'autre, et leurs propositions pourront être comparées ligne par ligne.