Il y a un réflexe dans notre métier, et je l'avais aussi : un nouveau domaine métier apparaît, et la main se tend vers « …donc c'est un nouveau microservice ». Ça fait moderne. Ça fait scalable. Ça fait ce que font les ingénieurs sérieux.

Sur le système d'information ktayl-solution — une plateforme Kubernetes à six nœuds faisant tourner tout le SI d'un assureur simulé — j'avais construit quatre domaines exactement ainsi : polices, sinistres, souscription, identité, chacun avec son dépôt, sa CI, sa base de données, son couloir de promotion. Puis je me suis arrêté et j'ai posé la question qui compte plus que n'importe quel choix de framework : est-ce la bonne architecture, ou seulement celle qui est à la mode ?

Cet article est la réponse à laquelle je suis arrivé — le monolithe modulaire d'abord — et, honnêtement, sa moitié la plus précieuse : la décision que je n'ai délibérément pas prise.

La conversation de pointe en IA a discrètement changé de sujet. Pendant deux ans, c'était « quel est le modèle le plus intelligent ? ». Aujourd'hui, ceux qui livrent réellement des systèmes agentiques posent une autre question : « que met-on autour du modèle ? »

Cette machinerie environnante porte un nom — le harnais. Le modèle est le moteur. Le harnais, c'est le châssis, la direction, la ceinture et les freins. Un moteur génial boulonné à rien vous tue au premier virage ; un moteur modeste dans une voiture bien conçue vous ramène à la maison à chaque fois. Sur le système d'information ktayl-solution — une plateforme Kubernetes à six nœuds qui fait tourner tout le SI d'un assureur simulé — j'ai passé des mois à construire le harnais qui permet à un agent IA de faire un vrai travail d'ingénierie sur une infrastructure en production sans que je retienne mon souffle.

Cet article, c'est ce harnais, concept par concept. Pas la théorie — les règles réelles que j'ai mises en place, pourquoi chacune existe, et l'incident qui l'a le plus souvent imposée.

En durcissant la reprise après sinistre du système d'information ktayl-solution, une question légitime s'est posée : on réplique déjà les sauvegardes vers Cloudflare R2 — alors pourquoi garder un serveur MinIO qui tourne sur le contrôleur ? Ne pourrait-on pas le retirer et passer full cloud ?

L'offre gratuite de R2 est généreuse, le stockage objet cloud est durable, et avoir un service de moins à exploiter est toujours séduisant. C'est donc un instinct raisonnable. C'est aussi faux — et environ une heure après m'être expliqué pourquoi, je l'ai prouvé à la dure en supprimant le mauvais préfixe de bucket. Cet article, c'est ce raisonnement, et l'incident bien réel qui l'a validé.

ArgoCD réconcilie tout ce qui est à l'intérieur de mon cluster : 95 applications, de Vault à la passerelle IA, toutes déclarées dans Git et synchronisées en continu. Mais ArgoCD ne peut pas formater un disque, installer open-iscsi ni corriger une route par défaut. Il existe une couche en dessous du GitOps — le système d'exploitation de chaque nœud bare-metal — et si cette couche n'est pas codifiée, « l'infrastructure reproductible » n'est qu'une demi-vérité.

Pour le système d'information ktayl-solution, cette couche appartient à un petit dépôt : minicloud-ansible. Environ 200 lignes de tâches réparties en quatre rôles, qui font une seule chose et la font bien : rendre les prérequis OS d'un cluster k3s à 6 nœuds reproductibles et auditables. Cet article explique comment je l'utilise pour exploiter la plateforme de l'organisation.

Une alerte de supervision s'est déclenchée : le watchdog de la plateforme était DOWN. En quelques minutes, le tableau devenait moche — le DNS du cluster refusait les connexions, et peu après, les volumes de stockage distribué ont cessé de se reconstruire. Une cascade de manuel.

Voici le post-mortem complet : comment la panne s'est propagée, pourquoi la cause évidente s'est révélée être un symptôme situé à trois niveaux de la racine, le correctif, et — surtout — la prévention livrée pour qu'elle ne puisse pas se reproduire de la même manière. Chaque changement évoqué ici est une pull request publique et vérifiable.

La plateforme en question — minicloud — est un environnement Kubernetes de qualité production tournant sur des ThinkPads reconditionnés, construite et opérée en solo comme simulation du système d'information d'une entreprise. Du bare-metal, aucun plan de contrôle managé, aucun filet de sécurité. C'est précisément pour cela qu'elle enseigne bien.

Si vous exploitez sérieusement un cluster Kubernetes, vous finissez par heurter le mur Docker Hub. Un matin, votre pipeline CI se met à échouer avec toomanyrequests: You have reached your pull rate limit. Ou pire — il échoue pendant une reprise de cluster à 2 h du matin, quand vos nœuds tirent des images pour redémarrer des workloads critiques et que Docker Hub décide que vous avez dépassé votre quota anonyme de 100 pulls par 6 heures.

Le conseil standard est d'ajouter de l'authentification. Mais cela ne fait qu'augmenter la limite — cela n'élimine pas la dépendance à un service externe pendant vos moments les plus vulnérables. La réponse de production est un cache proxy pull-through, et sur un cluster k3s auto-hébergé, Harbor + les miroirs k3s font que chaque nœud se comporte comme si Docker Hub était local.

Quand vous construisez une plateforme Kubernetes de production de zéro, vous accumulez des identités non-humaines plus vite que prévu. Au moment où la plateforme minicloud a atteint sa maturité opérationnelle — un cluster k3s bare-metal de 5 nœuds exécutant plus de 70 workloads — elle comptait plus de 35 identités non-humaines distinctes réparties en six catégories différentes. La plupart sont invisibles en exploitation normale. Vous ne les remarquez que lorsque l'une casse.

Cet article cartographie chaque type d'identité non-humaine utilisé sur la plateforme, explique comment ils diffèrent, et documente les leçons opérationnelles tirées de ceux qui ont causé des incidents.

Chaque cluster Kubernetes qui utilise cert-manager pour le TLS porte en lui le même risque silencieux : la clé privée de la CA qui signe tous vos certificats internes se trouve dans un secret Kubernetes, stocké en clair dans le datastore de votre cluster.

Sur les clusters managés avec chiffrement etcd au repos, ce risque est correctement atténué. Sur k3s avec kine et SQLite — comme tournent beaucoup de clusters bare-metal — la table des secrets est en clair. Quiconque peut lire state.db depuis le nœud du plan de contrôle peut extraire la clé privée de votre CA et forger des certificats que tout votre cluster fait confiance.

Cet article couvre comment nous avons migré la clé privée de la root CA minicloud dans le moteur de secrets PKI de HashiCorp Vault, avec le même certificat de CA pour que rien d'autre n'ait à changer — aucune reconfiance, aucune interruption, aucun changement sur nos 43 ressources Certificate.

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.