Entre 2024 et 2025, nous avons construit deux générations d'assistant IA pour les ingénieurs et les équipes d'un grand groupe du spatial, sur une documentation qui ne devait pas sortir de l'entreprise. La première, en 2024, tournait entièrement sur les serveurs internes du groupe : un modèle ouvert (Llama 3.1), un GraphRAG appuyé sur Neo4j, un pipeline d'évaluation. La seconde, de janvier à mai 2025, a repris le projet en RAG agentique sur un cloud français (OVHcloud), avec Qwen 2.5 14B servi par vLLM et Ollama, une recherche hybride, un découpage des documents par modèles visuels et une évaluation suivie dans Langfuse.
Ce récit ne contient aucun chiffre de performance : nous ne publions pas de mesure pour cette mission. Il décrit ce que nous avons construit, pourquoi, ce que chaque choix a coûté, et ce que nous referions. Les leçons de ce projet sont aussi à la base de notre offre d'agent IA souverain déployé chez vous, que nous proposons aujourd'hui à des entreprises plus petites, notamment des sous-traitants du spatial et de l'aéronautique.
Points clés à retenir
- Sur une documentation qui ne doit pas sortir, tout tourne dans le périmètre du client : modèle de langage, embeddings, reranking, base de recherche et journaux, sans appel à une API externe
- Le GraphRAG (Neo4j) aide quand les questions portent sur des relations entre documents, mais il coûte cher à maintenir à chaque nouvelle version du corpus
- La reprise de 2025 en RAG agentique (agents qui résument, filtrent et raisonnent en boucle ReAct) obtient une partie de cet effet au moment de la question, sans graphe à tenir à jour
- La lecture des PDF complexes et l'évaluation sont au cœur du travail, plus que le choix du modèle ; Qwen 2.5 14B servi par vLLM et Ollama est resté interchangeable
- Le même socle se transpose à une PME ou à un sous-traitant du spatial, à une échelle adaptée, avec un pilote de 4 à 6 semaines sur un premier corpus
Le contexte : une documentation qui ne sort pas
Le client est un grand groupe du spatial. Nous ne le nommons pas, et nous ne détaillons ni ses programmes ni ses documents. Le besoin, lui, se décrit simplement : permettre à des ingénieurs et à d'autres équipes (RH notamment) de poser une question en langage courant et d'obtenir une réponse tirée de la documentation interne, avec la source.
Deux corpus étaient concernés. Un corpus RH et un corpus technique, utilisé par les ingénieurs. Les deux avaient la même contrainte de départ : les documents ne partent pas vers un service d'IA extérieur. Pas d'API d'un fournisseur de modèles : tout ce qui touche aux documents tourne dans le périmètre retenu par le client. En 2024, cela voulait dire les serveurs internes du groupe ; en 2025, un cloud français. C'est la situation que l'on retrouve dans la plupart des entreprises industrielles qui découvrent que leurs équipes collent déjà des documents internes dans ChatGPT faute d'outil interne.
Le corpus technique contenait des PDF complexes, avec les difficultés classiques de la documentation d'ingénierie : mises en page sur plusieurs colonnes, schémas qui portent une partie de l'information, tableaux où la réponse tient dans une cellule, renvois d'un document à l'autre. Sur ce type de corpus, la difficulté n'est pas de faire répondre un modèle de langage. Elle est de lui donner le bon passage, lu correctement.
2024 : une première version entièrement sur site
Llama 3.1 sur les serveurs internes
La première version a été installée sur les serveurs internes du groupe, avec Llama 3.1, un modèle ouvert dont les poids se téléchargent et tournent sans connexion à un service extérieur. Ce choix découlait directement de la contrainte : si rien ne sort, le modèle doit tourner à l'intérieur. Le projet a été mené par une équipe de trois personnes et a livré deux assistants conversationnels, l'un sur le corpus RH, l'autre sur le corpus technique.
Faire tourner un modèle ouvert sur site n'est pas, en général, la partie la plus longue d'un tel projet. Le travail porte surtout sur la lecture des PDF et sur l'évaluation, ce qui rejoint ce que nous voyons sur tous nos projets : le serveur d'inférence règle le débit, pas la qualité des réponses. Notre comparatif vLLM ou Ollama revient sur cette distinction.
Pourquoi un graphe sur ce corpus
Sur le corpus technique, nous avons construit un GraphRAG : les entités présentes dans les documents et leurs relations sont extraites, stockées dans Neo4j, puis parcourues au moment de la question, en plus de la recherche par similarité.
La raison tient à la forme de la documentation d'ingénierie. Une recherche vectorielle classique renvoie les passages qui ressemblent à la question. Elle marche bien quand la réponse est écrite à un seul endroit. Elle marche moins bien quand la réponse suppose de suivre un fil : un équipement relève d'un sous-système, qui renvoie à une spécification, qui renvoie à une procédure. Un graphe rend ces liens explicites et permet de les suivre, là où la similarité de texte ne les voit pas.
Ce que le graphe coûte à maintenir
Un graphe de connaissances a un coût que l'on mesure mal au moment de la démonstration. Il se paie à chaque évolution du corpus :
- L'extraction des entités et des relations passe par le modèle de langage. Sur un modèle hébergé en interne, c'est long, et il faut la refaire à chaque nouvelle version d'un document.
- Le schéma (quels types d'entités, quelles relations) se décide au départ et doit évoluer avec les documents. Un schéma trop pauvre ne sert à rien, un schéma trop riche produit un graphe bruité.
- La base de graphe est un composant de plus à exploiter, sauvegarder et superviser, avec ses propres requêtes (Cypher) à tester.
- L'évaluation devient plus difficile : quand une réponse est fausse, il faut savoir si l'erreur vient de l'extraction, du parcours du graphe, de la recherche ou de la génération.
Le graphe n'est donc pas un mauvais choix en soi. C'est un choix qui engage sur la durée, et qui doit se justifier par des questions qui en ont réellement besoin.
Un pipeline d'évaluation dès la première version
Dès 2024, l'assistant était livré avec un pipeline d'évaluation : un jeu de questions avec leur réponse attendue, rejoué à chaque modification de la chaîne. C'est la règle que nous appliquons partout. Sans elle, un changement de découpage, de modèle ou de prompt peut améliorer une question et en dégrader dix autres sans que personne ne s'en aperçoive. Notre méthode (notation binaire, 20 à 50 questions dès les premiers jours) est détaillée dans l'article évaluer un RAG : Ragas, Langfuse ou notation binaire.
2025 : la reprise en RAG agentique sur cloud français
De janvier à mai 2025, nous avons repris le projet sur une autre architecture : un RAG agentique, hébergé sur un cloud français, OVHcloud.
Pourquoi ce changement
Les raisons propres au client lui appartiennent. Ce qui pèse en général dans ce type de bascule, et que nous retrouvons d'un projet à l'autre :
- La capacité de calcul. Un cloud français donne accès à des GPU sans acheter ni exploiter de matériel, et permet d'ajuster la capacité quand l'usage grandit. Le prix à payer : il faut que le niveau de sensibilité des documents concernés autorise cet hébergement, ce que décide la sécurité du client, document par document.
- Le coût de maintenance du graphe. Un RAG agentique obtient une partie de ce que donnait le graphe (suivre un fil entre plusieurs documents) en enchaînant plusieurs recherches au moment de la question, sans structure à reconstruire à chaque mise à jour du corpus.
- Les modèles ouverts ont progressé. Entre 2024 et 2025, les modèles de taille moyenne sont devenus capables de suivre des instructions en plusieurs étapes et d'appeler des outils de façon fiable, ce qui rend une boucle d'agents réaliste sur un modèle auto-hébergé.
Le découpage des documents avec des modèles visuels
La lecture des PDF reste la première source d'erreurs d'un RAG sur documentation technique. Une extraction de texte brute mélange les colonnes, perd la structure des tableaux et ignore les schémas. Dans la version 2025, le découpage des documents s'appuie sur des modèles visuels : la page est traitée comme une image, le modèle repère sa structure (titres, paragraphes, tableaux, figures), et les morceaux indexés respectent cette structure au lieu de couper au milieu d'un tableau.
C'est plus lent et plus coûteux à l'indexation qu'une extraction de texte. Sur un corpus où une partie de l'information est dans les tableaux et les schémas, c'est la condition pour que la bonne réponse puisse simplement être trouvée. Notre article sur le RAG multimodal : images, PDF et tableaux détaille les options.
La recherche : hybride, requêtes réécrites, reranking
Trois briques ont été ajoutées entre la question et le modèle :
- La recherche hybride, BM25 et sémantique. La documentation d'ingénierie est pleine de références, d'acronymes, de codes et de noms propres. La recherche sémantique comprend le sens d'une question mais rate souvent une référence exacte ; BM25, la recherche par mots-clés, la trouve. Les deux classements sont fusionnés.
- La réécriture des requêtes. Une question posée en cours de conversation (« et pour l'autre version ? ») n'est pas une bonne requête de recherche. Le modèle la reformule en question autonome, en tenant compte de tout l'échange, avant de chercher. Ne prendre en compte que le dernier message est l'un des bugs que nous rencontrons le plus souvent en audit.
- Le reranking avec un modèle ouvert. Un modèle spécialisé reclasse les passages trouvés selon leur pertinence réelle pour la question. Il est hébergé avec le reste : aucun passage ne part vers un service extérieur pour être noté.
Les agents : résumer, filtrer, raisonner en boucle
Le cœur de la version 2025 est une chaîne d'agents spécialisés. Un agent résume les documents longs récupérés pour n'en garder que ce qui sert la question. Un agent filtre les passages et écarte ceux qui sont hors sujet, pour que le modèle ne réponde pas à côté à partir d'un extrait qui se ressemble. Un agent raisonne en boucle sur le mode ReAct : il examine ce qu'il a trouvé, décide s'il lui manque une information, relance une recherche ciblée, puis répond quand il a ce qu'il faut.
Cette boucle a un coût. Chaque question déclenche plusieurs appels au modèle, donc plus de latence et plus de capacité GPU qu'une recherche suivie d'une réponse. Elle se justifie sur les questions qui demandent plusieurs étapes. Sur les questions simples, elle n'apporte rien, et nous avons vu sur d'autres projets que passer en agentique ne fait pas toujours monter la note. Le choix des frameworks est discuté dans notre article sur les frameworks d'agents IA.
Qwen 2.5 14B, servi par vLLM et par Ollama
Le modèle retenu est Qwen 2.5 14B, un modèle ouvert de taille moyenne. Un modèle de cette taille tient sur un seul GPU de datacenter, ce qui garde l'hébergement simple, et laisse assez de marge pour une boucle d'agents qui appelle le modèle plusieurs fois par question.
Il était servi par deux outils. Leurs rôles habituels diffèrent : Ollama sert à itérer vite : changer de modèle, comparer deux versions d'un prompt, tester une quantification. vLLM sert la charge : il traite en parallèle les requêtes de plusieurs utilisateurs, ce qui compte d'autant plus qu'un RAG agentique multiplie les appels. Les deux exposent une API compatible OpenAI. L'application ne dépend donc ni de l'un ni de l'autre, ni du modèle : remplacer Qwen 2.5 par un modèle plus récent revient à changer une adresse et un nom, puis à rejouer l'évaluation. C'est la même logique que nous appliquons quand il faut changer de modèle dans un RAG en production.
Langfuse et LLM juge pour l'évaluation
La version 2025 a été suivie avec Langfuse, auto-hébergeable, qui garde la trace de chaque requête : la question, les passages trouvés, les étapes des agents, la réponse. Quand une réponse est mauvaise, on voit à quelle étape le problème est apparu. Pour noter les réponses à grande échelle, un LLM juge compare chaque réponse à la réponse attendue et rend un verdict. Un juge se vérifie lui aussi : on contrôle à la main un échantillon de ses verdicts avant de lui faire confiance. Notre article sur Langfuse et l'observabilité LLM détaille ce montage.
| Brique | Version 2024 | Version 2025 |
|---|---|---|
| Hébergement | Serveurs internes du groupe | Cloud français (OVHcloud) |
| Modèle de langage | Llama 3.1 (modèle ouvert) | Qwen 2.5 14B (modèle ouvert), servi par vLLM et Ollama |
| Recherche | GraphRAG : graphe de connaissances dans Neo4j en complément de la recherche par similarité | Recherche hybride BM25 et sémantique, réécriture des requêtes, reranking avec un modèle ouvert |
| Raisonnement | Pas d'agents : recherche (graphe et similarité), puis génération | Agents qui résument, filtrent et raisonnent en boucle (ReAct) |
| Lecture des documents | Travail spécifique sur les PDF complexes | Découpage appuyé sur des modèles visuels |
| Évaluation | Pipeline d'évaluation sur jeu de questions | Langfuse et LLM juge |
| Coût propre à l'approche | Maintenir le graphe à jour | Plusieurs appels au modèle par question, donc de la latence et de la capacité GPU |
L'acculturation des équipes : la partie que l'on sous-estime
La mission comprenait l'acculturation des équipes à l'outil. Un assistant documentaire n'est utile que si ses utilisateurs savent ce qu'il fait bien, ce qu'il fait mal, et comment vérifier une réponse. À notre sens, cette partie doit couvrir au minimum :
- Ce que l'assistant connaît : quels corpus, quelle date de mise à jour, ce qui n'y est pas.
- Comment lire une réponse : ouvrir la source citée, vérifier la version du document, ne pas reprendre une valeur sans l'avoir vue dans le texte d'origine.
- Comment poser une question : donner le contexte (programme, sous-système, type de document) plutôt qu'un mot isolé.
- Comment signaler une erreur : chaque réponse fausse remontée devient une question du jeu d'évaluation. C'est ainsi que le jeu grossit avec les vrais usages.
Dans un environnement d'ingénierie, la règle de fond est claire : l'assistant aide à retrouver l'information, il ne prend pas de décision de conception. La responsabilité reste à l'ingénieur, et les citations sont là pour qu'il puisse vérifier en quelques secondes.
Les contraintes du secteur : Diffusion Restreinte et contrôle export
Le spatial et la défense ajoutent des contraintes que l'on ne retrouve pas dans une PME de services. Nous les citons ici sans entrer dans le détail réglementaire, que traite notre article sur ITAR, Diffusion Restreinte et assistant IA.
- Diffusion Restreinte. L'instruction interministérielle n° 901 fixe les exigences des systèmes d'information qui traitent des informations sensibles, dont celles portant cette mention, et impose leur homologation avant mise en service. Un assistant IA qui lit ces documents fait partie de ce système.
- Contrôle export. Pour des données techniques soumises à une réglementation d'export, la question porte notamment sur qui peut y accéder, y compris les personnes qui administrent l'hébergement et détiennent les clés de chiffrement.
- Cloisonnement. Tous les ingénieurs n'ont pas accès à tous les programmes. L'assistant doit hériter des droits des sources : un document qu'un utilisateur ne peut pas ouvrir ne doit jamais nourrir sa réponse.
- Journalisation. Qui a posé quelle question, quels documents ont été servis : ces journaux restent chez le client, exploitables par sa sécurité.
Ces statuts (homologation, conformité export) sont ceux du système et du projet du client, pas d'un logiciel. Notre rôle est de livrer un assistant qui s'installe là où la sécurité le décide (serveurs internes, réseau isolé, cloud français) et qui fournit les éléments dont elle a besoin. Les étapes d'un déploiement de ce type dans un contexte industriel sont décrites dans déployer une IA on-premise dans l'aéronautique.
Ce que nous referions, ce que nous ne referions pas
Nous formulons ces leçons comme des règles d'ingénierie, valables au-delà de ce projet.
Ce que nous referions
- Mettre l'évaluation en place avant tout le reste. Un jeu de questions réelles, noté en juste ou faux, rejoué à chaque modification. C'est le seul moyen de savoir si une brique ajoutée (graphe, agents, reranking) apporte quelque chose.
- Traiter la lecture des documents comme un chantier à part entière. Sur une documentation d'ingénierie, le découpage appuyé sur des modèles visuels n'est pas un luxe : c'est ce qui rend les tableaux et les schémas exploitables.
- Combiner recherche par mots-clés et recherche sémantique. Les références exactes, les codes et les acronymes sont partout dans ce type de corpus.
- Garder le modèle interchangeable. Une API standard entre l'application et le serveur d'inférence, et le jeu d'évaluation pour décider d'un changement de modèle.
- Citer la source et la version du document dans chaque réponse, et soigner la façon dont l'information est présentée. Dans un RAG, l'interface compte autant que la recherche.
- Prévoir l'acculturation dans le périmètre du projet, avec un circuit de remontée des erreurs qui alimente l'évaluation.
Ce que nous ne referions pas
- Ajouter une brique sans mesure de son apport. Graphe, boucle d'agents ou reranking ont chacun un coût (maintenance, latence, capacité GPU). Sans comparaison sur le jeu d'évaluation, on ne sait pas si ce coût est justifié.
- Construire un graphe de connaissances pour tout le corpus d'emblée. Nous le réserverions aux questions qui portent réellement sur des relations entre documents, une fois établi qu'une recherche hybride bien réglée ne suffit pas.
- Faire passer toutes les questions par la boucle agentique. Une question simple n'a pas besoin de trois appels au modèle. Orienter les questions selon leur difficulté économise de la latence et du calcul.
- Laisser la sécurité découvrir l'architecture à la fin. L'hébergement, les droits et la journalisation se décident avec elle au cadrage, pas au moment de la mise en service.
Ce que disent nos autres missions RAG
Ces constats viennent de l'ensemble de nos projets RAG, pas de la mission spatiale, pour laquelle nous ne publions pas de chiffres.
- Un RAG basique répond correctement à environ 50 à 70 % des questions. C'est ensuite que le travail commence.
- En audit, la cause la plus fréquente d'un mauvais résultat est un bug dans la chaîne de traitement (modèle d'embeddings différent entre indexation et recherche, un seul passage récupéré, seule la dernière question prise en compte), pas le modèle de langage.
- Tableaux, graphiques et schémas restent la principale source de problèmes à la lecture des documents.
- Une brique de plus n'est pas toujours un gain : sur un autre projet, le reranking faisait passer de 89 % à 92 % de bonnes réponses, et nous ne l'avons pas gardé parce que le temps de réponse comptait davantage.
Ce que cela donne pour une PME ou un sous-traitant du spatial et de l'aéronautique
Un sous-traitant du spatial ou de l'aéronautique a les mêmes contraintes qu'un grand groupe, à une autre échelle : des spécifications clients qu'il ne peut pas envoyer à un service américain, des procédures qualité, des retours d'expérience, des exigences de traçabilité. En général, il n'a ni équipe IA interne ni centre d'excellence. Ce que nous avons appris chez un grand groupe se transpose, en plus simple.
| Point | Grand groupe du spatial | PME ou sous-traitant |
|---|---|---|
| Corpus de départ | Plusieurs corpus en parallèle (RH, technique) | Un seul corpus bien délimité : procédures qualité, spécifications client, retours d'expérience |
| Hébergement | Serveurs internes, puis cloud français | Un serveur GPU dans vos locaux, une machine compacte ou une instance sur un cloud français, selon la sensibilité |
| Recherche | Graphe, puis RAG agentique | Recherche hybride et citations d'abord ; agents seulement si l'évaluation montre des questions en plusieurs étapes |
| Équipe projet | Une équipe projet de trois personnes en 2024 | Un référent métier et un contact informatique côté client |
| Ce qui ne change pas | La lecture des PDF, les droits d'accès, les citations, le jeu d'évaluation et la journalisation locale | |
C'est ce que nous livrons sous le nom d'agent IA souverain déployé chez vous : un socle développé et maintenu par Tensoria, installé dans votre environnement (serveurs internes, réseau isolé ou cloud français), qui répond sur votre documentation avec la source et la version du document, respecte les droits d'accès hérités de vos outils, peut agir dans vos logiciels quand c'est utile, journalise tout localement et arrive avec son jeu d'évaluation. Le modèle reste interchangeable : modèle ouvert sur site, cloud souverain, ou API d'un fournisseur si vous l'acceptez pour certains documents.
Le format reprend ces leçons, sur un périmètre plus court :
- Un pilote de 4 à 6 semaines sur un premier corpus, avec une mesure de départ sur vos propres questions.
- Le déploiement dans l'environnement choisi avec votre informatique et votre sécurité.
- Le suivi en production : évaluation rejouée à chaque mise à jour du corpus ou du modèle, journaux, évolutions.
Côté matériel, une petite équipe peut démarrer sur une machine compacte, comme nous l'expliquons dans notre article sur le DGX Spark en entreprise. Si vous comparez avec des interfaces open source à installer vous-même, notre article sur LibreChat, AnythingLLM et Onyx dit ce que chacune couvre et ce qui reste à construire autour. Pour situer l'ensemble du chantier (ingestion, recherche, évaluation, coût), voyez notre guide du RAG en entreprise, et pour le détail de l'offre, la page agent IA souverain.
Questions fréquentes sur l'assistant IA pour ingénieurs du spatial
Pour aller plus loin
- Agent IA souverain déployé chez vous : le socle qui reprend les leçons de cette mission, son format et son modèle commercial.
- ITAR et Diffusion Restreinte : quel assistant IA a le droit de lire vos spécifications.
- vLLM ou Ollama : lequel pour servir un modèle ouvert en entreprise.
- Pipeline RAG en production : les étapes de l'ingestion au suivi, et ce qui casse à chacune.
- RAG souverain avec Mistral : architecture et hébergement en France.
- IA et documentation technique aéronautique : les cas d'usage côté industriel.
- IA et spatial à Toulouse : les cas d'usage du NewSpace, de l'observation de la Terre aux phases AIT.
- IA souveraine : nos développements hébergés en France ou chez vous.
Formation
Pour que vos équipes appliquent ces usages sur leurs propres documents, voir notre formation RAG, construite sur vos cas.
