IA pour les applications métier : CRM, support, ERP, documents
Quand chaque application métier se branche sur son propre fournisseur d'IA, les clés d'accès, les budgets et le suivi de la consommation se dispersent, sans vue d'ensemble sur qui consomme quoi. Une passerelle d'IA interne et unique centralise ces accès. Elle attribue une clé et un budget par application, garde les données sensibles sur votre infrastructure, et rend la dépense traçable application par application.
Le constat : intégrer l'IA dans chaque application coûte cher
Quand chaque application métier embarque son propre fournisseur d'IA, le même travail se répète dans chaque équipe : négociation de contrat, gestion d'une clé distincte, surveillance des coûts, classification de la sensibilité des données, mise à jour des modèles. Les clés se multiplient, les budgets deviennent opaques, et la conformité exige un effort propre à chaque intégration. Un changement de fournisseur impose de redévelopper les connecteurs là où l'organisation possède déjà une équipe support.
Le passage à une API interne unique inverse la charge. Les applications appellent un point d'entrée stable, et la plateforme se charge de la sélection du modèle, des clés, des budgets et de la journalisation. Les équipes métier consomment une capacité, elles n'intègrent plus un fournisseur différent pour chaque nouvelle application.
Une API interne unique derrière le parc applicatif
Le CRM, le support client, l'ERP et la gestion documentaire adressent la même API, exposée par la passerelle LiteLLM sur le réseau interne. Chaque application conserve son code et son interface utilisateur ; la fonction d'IA change de fournisseur sans recompilation. La plateforme applique la politique de sécurité, route la requête et ventile le coût.
| Application métier | Usage de l'IA | Avant : intégration par fournisseur | Après : API interne unique |
|---|---|---|---|
| CRM | Suggestion de relance, résumé de compte, qualification de piste | Clé éditeur distincte, modèle dédié, budget séparé | Clé virtuelle par application, modèle local ou externe au choix |
| Support client | Réponse assistée, classification de ticket, recherche dans la base de connaissances | Intégration SaaS propre, données parfois envoyées hors UE | Aiguillage automatique vers le modèle local selon la sensibilité |
| ERP | Aide à la saisie, détection d'anomalie, synthèse de commande | Connecteur développé au cas par cas, traçabilité partielle | API unifiée, journal d'appel centralisé |
| Gestion documentaire | Résumé, extraction d'entités, recherche sémantique, génération de brouillon | Plusieurs éditeurs en parallèle, clés dispersées | Une clé virtuelle par application, télémétrie par usage |
La migration vers l'API interne ne retire rien aux applications : elle leur retire la complexité de choisir et d'intégrer un fournisseur. La même interface sert le modèle souverain local et le modèle externe, selon la décision du routeur sémantique.
La passerelle LiteLLM : clés virtuelles, budgets et quotas
LiteLLM agit comme une passerelle compatible OpenAI placée devant les modèles. Chaque utilisateur, équipe ou application reçoit une clé virtuelle, distincte de la clé de l'éditeur. La clé virtuelle porte trois garde-fous : un plafond de requêtes, un plafond de jetons et un budget exprimé sur une fenêtre temporelle cumulée. Les alertes préviennent avant l'atteinte des limites, et la dépense se ventile par clé, par utilisateur, par équipe et par modèle.
Les modèles locaux, dont le coût marginal est nul, restent accessibles après épuisement du budget d'un modèle externe. Ce repli souverain garantit la continuité de service quand la dépense plafonnée est atteinte, et il préserve la latence pour les charges sensibles. Le choix du modèle se décide au niveau de la passerelle, jamais dans le code applicatif.
Le routeur sémantique : le bon modèle au bon endroit
Le routeur sémantique classe chaque requête avant l'appel de modèle. Par similarité d'embeddings, il distingue le contenu confidentiel du contenu public, puis oriente la demande vers un modèle souverain local ou vers un modèle externe. Le filtrage prévient la fuite de données, et la couche de décision journalise ce choix. L'application n'a plus à décider seule si le contenu sort ou reste ; la politique s'applique une fois, en un point centralisé.
La micro-segmentation eBPF apportée par Cilium restreint les destinations sortantes par service. Hubble rend visible chaque flux de la couche 3 à la couche 7. Tetragon surveille les exécutions, les élévations de privilèges et les connexions non autorisées, et journalise chaque tentative. Aucune donnée ne quitte la plateforme par un canal imprévu, et toute la chaîne reste démontrable à un audit.
L'architecture derrière l'API interne
L'API interne posée devant le parc applicatif s'appuie sur un ensemble de briques documentées dans le dossier d'architecture. La fiche LiteLLM décrit la passerelle, les clés virtuelles et les quotas. La fiche du routeur sémantique précise la classification et la politique de routage. La fiche des serveurs MCP privés couvre les connecteurs auto-hébergés qui outillent les agents sans exposer d'API externe. La couche API et exposition rassemble les interfaces et les protocoles de la plateforme. La couche modèles recense les modèles souverains et distants disponibles. La couche runtime d'inférence héberge vLLM, Triton, Dynamo et llama.cpp, et adapte le moteur à la charge et au matériel.
Cette organisation fait de l'API interne un composant de plateforme et non un développement isolé. Les applications s'intègrent une fois, et la plateforme évolue en amont, sans toucher au parc applicatif.
Mesurer coût et valeur par application
VictoriaMetrics et VictoriaLogs collectent les métriques et les journaux de toute la stack : inférence vLLM, passerelle LiteLLM, agents, politiques réseau Cilium et Hubble, télémétrie matérielle. Un flux unique et interrogeable indique qui consomme quoi, où se situe la latence et quelle application apporte de la valeur. La dépense se lit au niveau de la clé virtuelle, donc au niveau de l'application qui appelle l'API.
Le rapprochement entre le coût d'IA et le processus métier devient possible. Une direction commerciale compare le coût d'IA par opportunité traitée dans le CRM. Une équipe support mesure le coût d'IA par ticket résolu. Une équipe finance suit la part locale et la part externe, et arbitre la fenêtre de bascule entre les deux régimes. La décision d'investissement sur les accélérateurs souverains se nourrit de ces données, et le budget de l'année suivante se construit à partir de l'usage réel de l'année courante.
Questions fréquentes
Pourquoi une API IA interne plutôt qu'un fournisseur par application ?
Une API interne mutualise les clés, les budgets et la télémétrie, et permet de basculer d'un modèle externe vers un modèle local sans redévelopper les applications métier. La souveraineté des données et la maîtrise des coûts deviennent démontrables.
Comment chaque application reçoit-elle sa clé et son budget ?
LiteLLM attribue à chaque application une clé virtuelle, associée à un plafond de requêtes, à un plafond de jetons et à un budget sur une fenêtre temporelle. Les alertes préviennent avant l'atteinte des limites.
Que devient le contenu sensible passé par une application métier ?
Le routeur sémantique classe la requête avant l'appel de modèle et oriente le contenu confidentiel vers un modèle souverain local, tandis que le contenu public peut emprunter un modèle externe. Le choix est journalisé.
Alimentez vos applications métier
Un échange sans engagement pour évaluer la migration de votre parc applicatif vers une API IA interne souveraine.
Réserver un échange