La plupart des tutoriels Kubernetes commencent par eksctl create cluster ou gcloud container clusters create. Un plan de contrôle managé, des groupes de nœuds à auto-scaling, des load balancers qui apparaissent avec une simple annotation. Le cloud abstrait entièrement le matériel.

Nous avons pris la direction opposée. Cinq machines physiques — quatre ThinkPads et un MacBook Pro de 2012 — exécutant k3s, avec chaque workload ordonnancé et exploité par nous. Pas de plan de contrôle managé. Pas de groupe de nœuds à auto-scaling. Pas de load balancer cloud. Juste Linux, containerd et Flannel sur du fer que l'on peut toucher.

Mais nous utilisons bien des services cloud. AWS achemine nos e-mails. Cloudflare se place devant chaque requête HTTP. Une instance Lightsail relaie le trafic UDP de nos appels vidéo. Tailscale nous connecte au cluster depuis n'importe où.

Cet article explique comment nous avons décidé ce qui va où, et pourquoi l'architecture résultante n'est pas un compromis — c'est une conception délibérée.

La plupart des architectures d'identité d'entreprise n'ont pas commencé comme ce qu'elles sont aujourd'hui. Elles ont démarré en 1999 avec Active Directory, ont accumulé des intégrations LDAP au cours de la décennie suivante, et sont désormais à mi-chemin d'une migration vers l'identité cloud via Microsoft Entra ID — portant le poids de chaque couche qui l'a précédée.

Nous avons construit notre plateforme de zéro. Nous n'avons jamais eu de domaine on-premises. Nous n'avons jamais configuré LDAP. Nous avons sauté directement à la pile de protocoles que les entreprises passent des années et des sommes importantes à essayer d'atteindre. Cet article explique ce que nous avons choisi, pourquoi, et comment l'architecture d'identité résultante se compare au standard d'entreprise.

La plupart des déploiements IA d'entreprise font tôt la même erreur d'architecture : donner à chaque équipe une clé d'API directe vers OpenAI ou Anthropic et considérer le travail fait. Le résultat est prévisible — aucune visibilité sur les coûts, aucun contrôle d'accès, aucune piste d'audit, et des données sensibles envoyées aux API cloud sans le moindre garde-fou.

Une vraie passerelle IA d'entreprise change la forme du problème. Au lieu de nombreuses équipes parlant à de nombreuses API, vous avez un seul endpoint qui gère le routage, la limitation de débit, l'expurgation des données personnelles, le cache et l'observabilité. Les équipes la consomment de la même manière, que le modèle tourne sur votre propre matériel ou sur le parc GPU d'un fournisseur cloud.

Cet article couvre la conception complète d'une telle passerelle, construite sur Kubernetes avec LiteLLM comme couche de proxy, Ollama et vLLM pour l'inférence locale, et Presidio pour la protection des données personnelles — avec une configuration réelle qui tourne en production.

La plupart des articles comparant vLLM et Ollama présument que vous avez un GPU. Les benchmarks montrent une utilisation impressionnante de la VRAM. Les schémas d'architecture incluent des pilotes CUDA. La recommandation — vLLM gagne — vient avec un astérisque implicite : à condition d'avoir le matériel pour.

Nous ne l'avions pas. Notre cluster d'inférence, c'est quatre ThinkPads, chacun avec un i7-8565U (4 cœurs, 8 threads, jusqu'à 4,6 GHz en turbo), 16 Go de RAM, et aucun GPU d'aucune sorte. Nous avons d'abord utilisé Ollama. Puis nous l'avons remplacé par vLLM. Voici le compte-rendu honnête de cette migration : ce qui a cassé, ce qui s'est amélioré, et à quoi ressemblent réellement les compromis quand vous faites tourner de l'inférence LLM sur des CPU x86 grand public.

Chaque article sur l'IA d'entreprise se termine de la même façon. Utilisez Amazon Bedrock. Utilisez Azure OpenAI Service. Utilisez Google Vertex AI. Ces plateformes offrent conformité de niveau entreprise, confidentialité des données et garanties de non-entraînement.

Le conseil est correct — pour les organisations qui peuvent utiliser une infrastructure cloud américaine.

Un nombre important et croissant d'organisations ne le peut pas. Certaines à cause du coût. Beaucoup à cause de la réglementation. Quelques-unes parce que leurs données ne peuvent littéralement pas franchir une frontière selon la loi qui régit leur secteur.

Cet article s'adresse à ces organisations. Il couvre deux problèmes distincts — la souveraineté des données et le coût — et les options concrètes disponibles pour chacun.

Ollama est la façon dont la plupart des équipes exécutent un grand modèle de langage localement pour la première fois. Vous l'installez en cinq minutes, lancez ollama pull mistral, et vous avez une API fonctionnelle. Cela ressemble à de la magie.

Puis vous essayez de servir dix utilisateurs à la fois. Ou cent. Ou vous devez auditer chaque requête pour la conformité. Ou votre équipe juridique demande où vont les données. C'est là que vous réalisez qu'Ollama a été conçu pour tout autre chose.

OpenShift Container Platform est une distribution Kubernetes d'entreprise avec des choix affirmés. Mon cluster minicloud est une pile k3s de 5 nœuds assemblée composant par composant à partir de projets CNCF. Après avoir traversé la construction complète — GitOps, observabilité, secrets, registre, OIDC, ingress, réplication de stockage, tests de chaos, correctifs de sécurité, mises à jour — je peux dire avec une certaine précision quelle est réellement la différence.

Ce n'est pas qu'OpenShift en fait plus. C'est qu'OpenShift a déjà fait chaque choix que vous auriez à faire vous-même, a empaqueté ces choix en une unité versionnée, testée et supportée, et les a imposés au niveau de l'architecture. Que ce soit un avantage ou une contrainte dépend entièrement de ce que vous cherchez à faire.

« Haute disponibilité » est l'un de ces termes dont tout le monde s'accorde à dire qu'il compte et que presque personne ne définit précisément. Sur un fournisseur Kubernetes managé, vous cochez une case pour le multi-AZ et vous passez à autre chose. Sur un cluster auto-géré, vous prenez six décisions d'architecture indépendantes, chacune avec son propre mode de défaillance, son compromis et son coût opérationnel.

Cet article documente chaque couche de HA sur minicloud — un cluster k3s de 5 nœuds sur des ThinkPads — explique le raisonnement derrière chaque compromis, et associe chaque couche à la façon dont EKS, GKE et AKS résolvent le même problème.

Microsoft Teams coûte de l'argent. Il envoie vos données de réunion vers des serveurs que vous ne contrôlez pas. Il requiert des comptes dans un tenant Microsoft. Et si les licences changent, votre visioconférence disparaît du jour au lendemain.

Jitsi Meet ne coûte rien, tourne sur du matériel que vous possédez, garde vos données à l'intérieur de votre réseau, et fonctionne avec n'importe quel navigateur — aucune installation d'application requise.

Voici l'histoire de comment je l'ai déployé sur un cluster Kubernetes bare-metal, résolu un problème réseau épineux avec des utilisateurs mobiles SFR 5G, et l'ai câblé à un système SSO à l'échelle de l'entreprise. À la fin de cet article, vous comprendrez comment les appels vidéo WebRTC fonctionnent réellement, et aurez une carte claire pour déployer Jitsi vous-même.

Chaque tutoriel Kubernetes mentionne etcd. Les schémas d'architecture montrent un cluster etcd à trois nœuds avec consensus Raft, élection de leader et réplication entre pairs. Si vous utilisez EKS, GKE ou AKS, ce cluster existe quelque part — vous ne pourrez simplement jamais le voir.

Si vous utilisez k3s, vous n'avez pas d'etcd du tout.

Cet article explique ce que k3s utilise réellement, ce que cela signifie de gérer soi-même les sauvegardes et la reprise, et où cela vous situe par rapport à un fournisseur managé.