Un ingénieur détaille sur Habr son service RAG local pour la documentation des API de CAO

Un ingénieur a publié sur Habr un retour d'expérience sur la construction d'un service RAG local destiné à exploiter la documentation des API de logiciels de conception assistée par ordinateur (CAO). Il justifie ce projet par la pression que subissent les sociétés d'ingénierie : leurs clients réduisent les budgets et les délais des projets.

Pourquoi la documentation de CAO s'est prêtée à l'automatisation

Selon l'auteur, l'ingénierie vit depuis quelques années sous le mot d'ordre « la même chose, mais moins cher et plus vite ». Les clients rognent sur les budgets et les délais, tandis que les prestataires cherchent quels processus optimiser. L'automatisation de la conception figure parmi les premières candidates. Les tâches répétitives abondent en conception, et une bonne partie d'entre elles peut être confiée à des scripts et à de petits utilitaires plutôt qu'exécutée à la main par un ingénieur.

• L'auteur : un ingénieur qui a construit seul un service RAG local pour une API de CAO
• La raison du projet : des tâches de conception répétitives, délégables à des scripts
• Le contexte général : la réduction des budgets et des délais imposée par les clients des prestataires d'ingénierie

Le projet porte bien sur les API des logiciels de CAO, et non sur les plans eux-mêmes. Les scripts et utilitaires servent le plus souvent à des actions répétitives : génération massive de rapports, vérification de la conformité des paramètres aux standards internes, traitement de fichiers par lots. Ce sont des tâches qu'un ingénieur effectue à la main des dizaines de fois par projet, mais qui sont mal rémunérées en tant que travail créatif.

Ce qu'apporte un RAG local dans ce cas de figure

Le RAG (retrieval-augmented generation, ou génération augmentée par la recherche) désigne une approche dans laquelle le modèle, avant de répondre, va chercher les passages pertinents dans sa propre base documentaire au lieu de s'appuyer uniquement sur ce qu'il a mémorisé pendant l'entraînement. L'approche convient particulièrement à la documentation des API de CAO. Ces API sont souvent décrites dans des manuels volumineux, éclatés et régulièrement mis à jour. Le déploiement local permet en outre de garder les données d'ingénierie sensibles et la documentation propriétaire dans le périmètre de l'entreprise, sans les envoyer vers des services cloud externes.

C'est pour cette raison que l'auteur a opté pour une solution locale plutôt que pour un assistant IA clé en main dans le cloud. Pour les données d'ingénierie, la confidentialité pèse souvent plus lourd que la facilité de configuration. L'accès à la version à jour de la documentation de l'API est critique, car les logiciels de CAO modifient régulièrement leurs interfaces et leurs méthodes. Un déploiement « en interne », sans transmission des requêtes à un service externe, règle aussi la question des fuites : formulations des cahiers des charges internes ou extraits de la documentation fermée de l'éditeur.

Quelles difficultés rencontrent généralement ce type de projet

La documentation technique d'une API se prête mal à un pipeline RAG classique. Elle regorge de tableaux de paramètres, de renvois vers d'autres sections, de mentions de version et d'une terminologie propre à chaque plateforme de CAO, que les méthodes standard découpent mal en chunks. Les développeurs de ce genre de service doivent en général traiter à part plusieurs chantiers : le découpage des documents en blocs cohérents, la mise à jour de l'index à chaque nouvelle version de l'API, et la vérification que le modèle ne confond pas des méthodes aux noms proches mais au comportement différent.

Ce travail manuel et minutieux ne se voit généralement pas dans le résultat final, mais il absorbe une part importante du temps d'un tel projet.

Ce que cela signifie

Cette histoire illustre une tendance plus large. Pendant que les grands éditeurs lancent des assistants IA généralistes, des ingénieurs isolés et de petites équipes construisent de plus en plus souvent des outils RAG locaux très spécialisés, taillés pour une routine précise : documentation, opérations standardisées, standards internes. Pour les bureaux d'études et les sociétés d'ingénierie, attachés à la confidentialité des plans et à la correspondance exacte avec la version de l'API, un tel outil local fait maison se révèle souvent plus pratique que de brancher un service IA cloud externe sur l'ensemble de la base documentaire de l'entreprise.