Ce billet introduit le premier volet d’une série dédiée à l’hébergement en self-hosted d’un grand modèle de langage (LLM) à l’échelle professionnelle, à partir de l’expérience d’une équipe ayant déployé un serveur GPU chez Ippon. L’objectif est de partager un retour d’expérience pratique sur l’écosystème technique entourant les LLM, incluant les composants matériels (GPU, infrastructure) et logiciels (vLLM, Kubernetes), sans entrer dans les détails complexes de l’entraînement des modèles. L’auteur, ingénieur système, aborde les principes fondamentaux des réseaux de neurones de manière vulgarisée, en simplifiant les aspects mathématiques pour se concentrer sur les concepts clés comme les poids et les biais, qui structurent les fichiers de modèles téléchargeables (ex. Ministral-3B). Le texte prépare le terrain pour des articles ultérieurs en expliquant la nature des LLM comme des fonctions massivement paramétrées, composées de couches de neurones interconnectés via des matrices de poids.

L’article critique l’approche traditionnelle des systèmes multi-agents en IA, qui se concentre souvent sur l’orchestration des agents plutôt que sur la modélisation du domaine métier. L’auteur souligne que les règles et contraintes (comme les seuils d’approbation) ne devraient pas être intégrées dans les prompts des agents, mais plutôt encapsulées dans un modèle de domaine bien défini. Cela permet aux agents d’agir dans un environnement structuré, recevant des retours immédiats en cas d’erreur, et favorise une autonomie plus robuste.

Plutôt que de concevoir des workflows complexes entre agents, l’article plaide pour une architecture où le domaine est modélisé en premier : processus, état, invariants et règles métier. Les agents interagissent ensuite avec ce modèle partagé, sans avoir à gérer eux-mêmes les contraintes. Cette séparation réduit les risques liés aux erreurs de compréhension des règles et évite les systèmes soit trop risqués, soit trop restrictifs.

L’auteur présente Mozaik, un framework qui adopte cette approche en introduisant un état partagé et concurrentiel pour les agents, tandis que le modèle de domaine garantit le respect des règles. L’objectif est de construire des systèmes plus fiables et évolutifs, en s’appuyant sur une modélisation précise du monde réel plutôt que sur des workflows artificiels.

L’auteur partage son expérience de cohabitation entre Docker Compose et K3s dans son homelab, expliquant pourquoi il maintient les deux solutions plutôt que de tout migrer vers Kubernetes. Il souligne que Compose reste plus simple et efficace pour un serveur unique, grâce à sa transparence (fichiers de configuration clairs, volumes localisés, dépannage direct) et sa légèreté, tandis que K3s apporte une uniformisation des déploiements et une préparation pour une infrastructure évolutive, notamment pour des projets multi-nœuds ou nécessitant une montée en charge. Cependant, il note que K3s ajoute une complexité d'exploitation (ressources minimales requises, gestion du stockage et de la haute disponibilité non automatique) et que son utilité se limite à des cas spécifiques, comme l'apprentissage de Kubernetes ou des environnements devant grandir.

L’auteur insiste sur le fait que le choix entre les deux outils ne dépend pas du nombre de conteneurs, mais plutôt de la facilité de maintenance et de restauration en cas de panne. Il rappelle que Compose reste pertinent même avec une dizaine de conteneurs, à condition de respecter des conventions claires (volumes nommés, images taguées, documentation des sauvegardes), tandis que K3s devient intéressant pour des besoins de scalabilité ou de résilience, bien que son contrôle-plane et ses applications ne soient pas automatiquement hautement disponibles sans configuration avancée. Il conclut que la cohabitation des deux outils est un compromis pragmatique, évitant une migration brutale et permettant de tirer parti des avantages de chaque solution selon les besoins.

L’article explique comment la sécurité au niveau des lignes (RLS) dans PostgreSQL peut être contournée dans un projet Symfony en raison du rôle propriétaire des tables. Bien que les politiques RLS soient activées, le rôle qui exécute les migrations (et donc possède les tables) ignore ces restrictions par défaut, exposant toutes les données sans restriction. Un simple ALTER TABLE ... FORCE ROW LEVEL SECURITY est nécessaire pour appliquer correctement les politiques.

L’auteur souligne que cette faille est difficile à détecter en tests, car les connexions de test utilisent souvent un superutilisateur qui contourne aussi la RLS. La configuration par défaut de Symfony, où le même rôle gère à la fois les migrations et l’application, crée un risque de fuite de données. La documentation PostgreSQL mentionne ce comportement, mais il est souvent ignoré lors de la mise en place des politiques.