Depuis quelques semaines, je bricole avec des modèles de langage (LLM) en dehors du cadre habituel de mes labs de cybersécurité. L'idée de départ était simple : disposer d'un assistant IA rapide et souverain, sans dépendre uniquement des géants américains du secteur. Le résultat a fini par dériver vers quelque chose d'un peu plus ambitieux — faire collaborer plusieurs modèles entre eux, comme un petit comité qui se relit et s'affine lui-même.
Voici le récit de ces deux expérimentations, avec les galères incluses — parce que c'est souvent là qu'on apprend le plus.
Pourquoi héberger son propre assistant IA
Premier réflexe : essayer l'inférence locale sur mon serveur, avec Ollama. Sur du matériel CPU-only, même avec des modèles relativement légers (3 à 8 milliards de paramètres), la vitesse de génération plafonnait entre 2 et 8 tokens par seconde — largement trop lent pour un usage fluide au quotidien. Verdict sans appel : pour un assistant réactif, il fallait sortir du tout-local et passer par une API externe.
Le choix s'est porté sur Infomaniak AI Tools, un service suisse qui héberge des modèles open-source (Mixtral, Llama, Gemma, Mistral, et d'autres) derrière une API compatible OpenAI. Deux raisons à ce choix : la cohérence avec mon infrastructure existante (j'utilisais déjà Infomaniak pour mes sauvegardes chiffrées), et une approche plus respectueuse du RGPD que d'envoyer systématiquement des données vers des serveurs américains.
Construire l'assistant : Open WebUI et ses pièges
Une fois l'API choisie, j'ai déployé Open WebUI en conteneur Docker sur mon serveur, connecté à l'API Infomaniak plutôt qu'à Ollama. L'interface est propre, personnalisable, et fonctionne bien une fois configurée.
Deux leçons à retenir de cette phase :
Le nom exact des modèles compte. L'API Infomaniak refuse un nom de modèle mal orthographié — mais l'erreur retournée liste tous les identifiants valides, ce qui simplifie grandement la correction.
Un réflexe à avoir avec les conteneurs : vérifier ce qu'ils exposent réellement. Un point de vigilance classique avec Docker : un conteneur peut, selon sa configuration, se retrouver plus exposé que prévu sur le réseau. C'est exactement le genre de chose que je vérifie systématiquement après chaque déploiement — et cette fois, la vérification a payé, avec un ajustement rapide pour restreindre l'accès au strict nécessaire. Une bonne illustration de pourquoi l'audit post-déploiement fait partie intégrante du processus, pas une étape optionnelle.
Après un sous-domaine dédié, un certificat Let's Encrypt et un peu de personnalisation visuelle, l'assistant tournait en HTTPS, accessible depuis un bot Discord privé pour les questions du quotidien.
Et si plusieurs modèles se corrigeaient entre eux ?
Une fois l'assistant simple en place, l'idée suivante a émergé : et si, au lieu d'interroger un seul modèle, une question passait par plusieurs modèles à la suite, chacun affinant la réponse du précédent ? Une sorte de comité de relecture automatisé.
J'ai construit ça avec les Agent Flows d'AnythingLLM, un éditeur visuel no-code qui permet d'enchaîner des appels API et des instructions LLM sans écrire une ligne de backend. La chaîne retenue :
Gemma 4 → Mistral Small → Nemotron → Ministral
Chaque modèle reçoit la question initiale et la réponse du modèle précédent, avec pour consigne de l'affiner, la corriger ou la compléter.
Les obstacles techniques (et ce qu'ils révèlent)
Ce projet a été une bonne leçon sur les limites concrètes de l'orchestration multi-modèles :
Le JSON est plus fragile qu'il n'y paraît. La réponse brute d'une API de chat est un objet JSON structuré, pas du texte prêt à l'emploi. Dès qu'on réinjecte le texte d'une réponse dans l'appel suivant, chaque retour à la ligne, tabulation ou guillemet non échappé casse la requête. La solution a été de forcer chaque maillon intermédiaire à produire du texte brut, sans aucune mise en forme — markdown, tableaux et listes à puces inclus.
Les longues réponses finissent par tout ralentir. Sans limite de longueur, chaque maillon de la chaîne enrichissait considérablement le prompt du suivant, jusqu'à provoquer des timeouts serveur (erreurs 504) sur le dernier appel. Plafonner la taille des réponses (max_tokens) et imposer une consigne de concision a résolu le problème — au prix d'un compromis : sur une question à plusieurs volets, la chaîne peut se concentrer sur une partie de la question et en oublier une autre, sans erreur visible pour le signaler.
Une chaîne qui « affine » peut aussi halluciner. C'est le point le plus intéressant, à mon avis. Un modèle intermédiaire peut introduire une information incorrecte ou inventée en toute confiance, présentée comme une « précision » ou un « enrichissement » de la réponse précédente. Sans garde-fou explicite, rien n'empêche cette dérive de se propager jusqu'à la sortie finale. Ce n'est pas un bug à corriger, mais une caractéristique structurelle de ce type d'architecture — à garder en tête avant de faire confiance aveuglément à une sortie « consolidée » par plusieurs IA.
Ce que j'en retiens
Techniquement, les deux briques fonctionnent : un assistant réactif et souverain d'un côté, un mécanisme de raffinement multi-modèles de l'autre. Mais l'exercice a surtout été utile pour comprendre où se situent les vraies limites de ce genre de système — la fragilité du format d'échange entre étapes, le compromis entre robustesse et exhaustivité, et surtout l'idée qu'un consensus entre plusieurs IA n'est pas automatiquement synonyme de fiabilité.
La prochaine étape sera de travailler sur un détecteur de questions à plusieurs volets en amont de la chaîne, pour éviter qu'une partie de la question ne se perde en route. À suivre.
Article rédigé dans le cadre de mes expérimentations personnelles sous la bannière HIVE — Hardening, Investigation, Vérification, Expertise.