Aller au contenu

AIRiver — l'IA de votre choix

/plugins/airiver/ — AIRiver relie InfraRiver à un modèle de langage : un modèle local (Ollama, par défaut, rien ne sort de votre réseau) ou un service compatible OpenAI que vous choisissez (vLLM, LiteLLM, Ollama en /v1, Mistral, la passerelle IA interne de votre organisation…).

Champ Type Description
Provider Liste Ollama (modèle local) ou Service compatible OpenAI. Changer de fournisseur, de modèle, d'URL ou de clé oblige à refaire le test de branchement.
Modèle Texte Nom exact du modèle. Avec Ollama, les modèles installés sont proposés à la saisie ; avec un service OpenAI, saisissez le nom que le service attend.
Endpoint Texte Ollama : http://127.0.0.1:11434. Service compatible OpenAI : l'URL de base qui se termine par /v1 (par exemple https://llm.exemple.com/v1) ; InfraRiver appelle {URL}/chat/completions et {URL}/models.
Clé d'API Mot de passe Service compatible OpenAI uniquement. Envoyée en en-tête Authorization: Bearer, chiffrée en base, jamais affichée ni écrite dans un journal. Laissée vide, la clé enregistrée est conservée ; une case permet de la supprimer.
Budget de l'assistant (jetons / jour / personne) Nombre (défaut 200 000, 0 = illimité) Jetons (question + réponse) qu'une personne peut consommer par jour avec l'assistant. Au-delà, l'assistant répond par un message clair jusqu'au lendemain (UTC).
Appel d'outils Résultat du test Le test de branchement vérifie aussi que le service sait appeler des outils (nécessaire à l'assistant IA). Sans cela, l'assistant est indisponible. Pour vLLM : lancer le serveur avec l'analyse des appels d'outils activée.
Vérifier le certificat TLS Case Cochée par défaut. À décocher uniquement pour un service interne à certificat auto-signé.
Test automatique (minutes) Nombre, 1 à 1440 (défaut 5) Délai entre deux tests de branchement automatiques du service compatible OpenAI. Modifié, il s'applique tout de suite. Chaque test envoie une courte requête au service ; un délai plus long réduit ce trafic mais retarde la reprise après une panne.
Mesure de vitesse : toutes les … (minutes) Nombre, 0 ou 5 à 1440 (défaut 15) Délai entre deux mesures de la vitesse de l'IA. 0 = jamais (mesure à la demande seulement). Chaque mesure envoie deux courtes questions fixes, sans aucune donnée de votre inventaire, et consomme environ 500 jetons (comptés sous la fonction speed_probe) ; le coût par jour est affiché sous le champ. La carte « Vitesse de l'IA » à côté du champ montre le niveau en mots simples, le détail, les 24 dernières heures en barres et le bouton « Mesurer maintenant ». Fonctionne avec Ollama comme avec un service compatible OpenAI.
Température Nombre 0 = déterministe, 1 = plus varié. Une valeur basse est préférable pour la classification.
Timeout Nombre Délai maximal d'attente d'une réponse avant échec.
Threads CPU, Keep-alive Nombre, texte Propres à Ollama, ignorés avec un service compatible OpenAI.
Seuil de contexte Nombre Un appel qui dépasserait ce seuil est refusé plutôt que tronqué.

Ce qu'il vous faut côté IA

InfraRiver ne fournit pas de modèle imposé : il se branche à l'IA que votre organisation a choisie. Trois cas courants, tous pris en charge de la même façon :

  • un moteur installé chez vous, sur vos serveurs (avec ou sans carte graphique) : Ollama, vLLM, NVIDIA NIM, TGI, llama.cpp… ;
  • un service cloud compatible OpenAI : Azure OpenAI, l'API Mistral, OpenAI… ;
  • votre propre passerelle d'IA (LiteLLM ou équivalent), qui elle-même appelle l'un des précédents.

Ce qu'InfraRiver attend du service, quel qu'il soit :

Exigence Pourquoi Vérifié par le test de branchement
Format d'API OpenAI (/v1/chat/completions, /v1/models) — ou Ollama en natif c'est le seul langage qu'InfraRiver parle aux services distants oui
Respect d'un schéma JSON imposé (response_format) indispensable aux fonctions structurées (classification, synthèse, filtre) — voir ci-dessous oui
Décompte des jetons dans la réponse comptage de la consommation et budgets oui (facultatif)

Passerelle ou moteur : qui fait quoi

  • Le moteur (Ollama, vLLM, NIM…) fait tourner le modèle sur la machine, avec ou sans carte graphique.
  • La passerelle (LiteLLM…) ne fait tourner aucun modèle : elle reçoit les demandes au format OpenAI, contrôle la clé d'API, applique quotas et budgets, compte la consommation, puis transmet au moteur ou au service qui est derrière.

Pour InfraRiver, ce qu'il y a derrière la passerelle n'a aucune importance : il ne parle qu'à l'adresse que vous lui donnez. Vous pouvez aussi brancher directement un moteur qui parle le format OpenAI, sans passerelle.

Choisir le moteur :

  • Ollama : le plus simple à installer, très bien pour quelques utilisateurs ; ralentit quand de nombreuses demandes arrivent en même temps.
  • vLLM : conçu pour la production et la charge simultanée — il traite plusieurs demandes à la fois sur la même carte graphique. Mesure sur une carte NVIDIA L40S avec Ministral 3 8B : 1,6 demande traitée par seconde une par une, 18 par seconde avec 16 demandes en parallèle. À privilégier pour un serveur d'IA partagé entre plusieurs applications ou de nombreux utilisateurs.

Le format imposé (schéma JSON) : codé dans InfraRiver

Le respect du format est géré par InfraRiver ; vous n'avez normalement rien à configurer.

  1. InfraRiver joint un « formulaire » à chaque demande structurée : avec la question, il envoie le modèle de réponse attendu (un schéma JSON : par exemple « un champ classe parmi ces 4 valeurs, un champ cause de 200 caractères au plus »), via le paramètre standard response_format du format OpenAI.
  2. Le moteur doit savoir n'écrire que dans les cases du formulaire (décodage contraint). C'est le cas de vLLM, d'Ollama (versions récentes), d'Azure OpenAI, d'OpenAI et de l'API Mistral avec leurs modèles récents. Certains moteurs anciens et certains modèles « à raisonnement » ne le font pas, ou renvoient une réponse vide.
  3. InfraRiver vérifie chaque réponse reçue avant de s'en servir ; une réponse non conforme est rejetée, jamais utilisée telle quelle.
  4. Le test de branchement envoie un petit formulaire et vérifie la réponse. S'il échoue, les fonctions qui en ont besoin sont désactivées automatiquement et la page le dit ; la narration en texte libre reste disponible.

Le seul cas où vous devez agir : une passerelle qui supprime les paramètres qu'elle ne connaît pas. Avec LiteLLM, l'option drop_params, si elle est activée, peut retirer response_format avant de transmettre la demande au moteur. Le test affiche alors « Schéma JSON NON respecté » : désactivez cette option (ou autorisez response_format) dans la configuration de votre passerelle, puis relancez le test.

Économie de tokens

AIRiver est conçu pour solliciter le modèle le moins possible — utile avec un service facturé au jeton comme avec une machine partagée :

  • Réponses réutilisées : une situation déjà analysée n'est pas redemandée au modèle (cache adressé par le contenu ; les réponses réutilisées sont comptées et signalées comme telles).
  • Cas identiques regroupés : le coût suit le nombre de situations distinctes, pas le nombre de serveurs.
  • Contexte compacté avant envoi : seuls les éléments pertinents partent, jamais le parc entier — c'est aussi une mesure de confidentialité.
  • Réponses courtes à format imposé : le modèle remplit des cases au lieu de rédiger ; c'est l'écriture qui coûte le plus cher.
  • Début de demande stable : les instructions communes sont placées en premier pour être réutilisées par le moteur.
  • Budget par module et comptage de chaque appel (y compris ceux évités) : vous voyez et plafonnez la consommation.

Où part la donnée

La page affiche en tête de la carte de connectivité où tourne l'IA :

  • Local : le service est sur ce serveur, les données n'en sortent pas ;
  • Distant (réseau privé) : une autre machine d'un réseau privé, les données compactées quittent ce serveur ;
  • Distant : un service hors de votre réseau, les données compactées quittent votre réseau.

Le même rappel (« Service compatible OpenAI · distant », en orange) accompagne les résultats IA de Risk Intel et de CrossRiver. Les données envoyées au modèle sont toujours compactées au préalable ; aucun fournisseur distant n'est configuré par défaut. Un Ollama sur une autre machine n'a aucune authentification : ne l'exposez jamais sur internet (tunnel ou pare-feu limité à l'adresse d'InfraRiver).

Test de branchement

Avec un service compatible OpenAI, le bouton Tester le branchement (administrateurs) vérifie, avec les durées mesurées :

  1. que le service répond et que le modèle est dans sa liste (si le service en fournit une) ;
  2. une réponse en texte libre ;
  3. que le service respecte un schéma JSON imposé (décodage contraint) ;
  4. que le service renvoie le décompte des jetons.

Fonctions disponibles selon le service

Fonction Exige le schéma JSON respecté
Classification des incohérences CrossRiver oui
Synthèse de posture de Risk Intel oui
Narration d'impact (TopoMap), suggestion de rattachement non (texte libre)

Tant qu'un service n'a pas réussi le test du schéma JSON, les fonctions structurées sont désactivées (la page le dit) ; les autres continuent de fonctionner. Un service jamais testé est traité de la même façon. Les durées fines (lecture du prompt, génération, chargement) ne sont fournies que par Ollama : avec un service compatible OpenAI, seuls les jetons lus et écrits sont enregistrés, les durées restent vides.

Gate RSSI : interrupteur global désactivant toute la couche IA en un clic, journalisé (auteur + horodatage). Désactivé, aucune fonctionnalité IA (narration de risque, classification CrossRiver…) ne s'exécute nulle part dans l'application.