mabillot.com
Proof of Concepts · 2025 — 2026 09 entrées · MAJ juin 2026

Carnet de POCs_
Data, Agentic AI, conteneurs.

Neuf retours d'expérience documentés, du LDAP local à l'agent IA persistant sur VPS, en passant par une lakehouse Iceberg/Trino, une passerelle S3 privée inter-comptes, la maîtrise des clés de chiffrement sur CloudHSM dédié, et une todo-list Flask portée jusqu'à Kubernetes. Pas de tutoriel marketing : chaque page expose la démarche, les choix techniques, les arbitrages économiques et les pièges rencontrés.

Auteur
David Mabillot · Nantes
Profil
Architecte Data & IA
POCs publiés
09
Domaines
Data · Agentic · Infra
Posture

Je ne me positionne pas comme développeur applicatif. Mon métier est de cadrer, concevoir, challenger et sécuriser les architectures. Le prototypage en est, à mes yeux, une composante essentielle : il permet de dé-risquer les choix avant qu'ils ne coûtent cher. Je teste les hypothèses jusqu'à leurs limites concrètes, j'identifie ce qui casse en conditions réelles saturation, dérive, frontières de sécurité puis j'en tire des patterns et des référentiels réutilisables par les équipes. Les outils IA accélèrent cette boucle ; ils ne remplacent pas l'arbitrage architectural.

C'est aussi une passion durable : je prototype le soir et le week-end des sujets que des équipes mettront peut-être en production demain. Cette curiosité me maintient en veille active et nourrit mon jugement d'architecte.

Toutes ces explorations ne répondent pas au même objectif. Certaines naissent d'un besoin concret rencontré en mission ; d'autres relèvent d'une exploration plus libre une référence de cinéma, une technologie que je veux comprendre pour elle-même, une intuition à tester. Je tiens à cette distinction : l'exploration sans contrainte immédiate d'utilité construit souvent l'avance qui profite ensuite au travail.

01 / 03

Data Platform

Plomberie data et authentification : annuaire LDAP local, lakehouse complète Spark + Iceberg + Trino + S3 + Glue, et un POC OIDC complet ("Sign in with Google") pour comprendre l'authentification déléguée moderne. Trois angles, même obsession : poser des briques reproductibles, isolées, et comprendre ce qui se passe sous le capot.

POC · 01.01

LDAP Playground

Python + Docker + Apache Directory Studio

Bac à sable LDAP local pour modéliser une entreprise fictive (GrosChat) avec 50 utilisateurs, 3 régions (IDF, Savoie, CentreEst) et un groupe datastudio-users. Bascule possible vers ldap.forumsys.com pour tester sans rien installer. Pensé pour les architectes qui veulent expérimenter l'authentification annuaire avant de la brancher sur une vraie appli.

Ce que la page couvre
  • Lancer un OpenLDAP local avec osixia/openldap en une commande Docker
  • Authentification Flask + ldap3 contre un annuaire public
  • Scripts Python : peuplement, enrichissement, attribution de statuts
  • Connexion Apache Directory Studio · navigation visuelle de l'arbre
Python LDAP3 Docker Flask Directory Studio
NiveauIntermédiaire
FormatCode + manipulation
CibleDev · Architecte · IT
Ouvrir le POC
POC · 01.02

Spark + Iceberg + Trino + S3 + Glue + DBeaver

Lakehouse moderne · format transactionnel · catalogue managé

Architecture data complète : créer une table Iceberg stockée sur S3, référencée dans AWS Glue, peuplée par PySpark, puis interrogée depuis Trino et visualisée dans DBeaver. La page joue aussi le rôle de glossaire pédagogique (Parquet vs CSV, Iceberg vs Hive, rôle du S3FileIO).

Ce que la page couvre
  • Image mentale : S3 = hangar · Parquet = caisses · Glue = registre · Iceberg = inventaire
  • Script PySpark complet avec tous les JARs AWS SDK alignés
  • ACID, snapshots, évolution de schéma, partitionnement dynamique
  • Code source téléchargeable en ZIP
Spark Iceberg Trino AWS S3 AWS Glue DBeaver Parquet
NiveauAvancé
FormatArchitecture + code
LivrablesZIP téléchargeable
Ouvrir le POC
POC · 01.03

OIDC — Sign in with Google

FastAPI + authlib · flow Authorization Code + PKCE · clin d'œil au Grand Budapest Hôtel

POC d'authentification déléguée complet en local : un "Sign in with Google" qui fonctionne de bout en bout, avec deux versions du serveur — l'une via la lib authlib (~40 lignes utiles), l'autre à la main pour montrer ce que la lib fait sous le capot (PKCE, JWKS, vérification des claims). Deux modes de lecture ("Mode simple" / "On ouvre le capot"), captures du flow réel, et un clin d'œil au talk Devoxx de Julien Topçu qui vulgarise OAuth 2.1 via le film de Wes Anderson.

Ce que la page couvre
  • Le paysage : OAuth 2.0, OIDC, SAML, SSO, Kerberos — leurs relations en un schéma
  • Le flow Authorization Code + PKCE étape par étape, avec diagramme de séquence
  • Vocabulaire essentiel : state, nonce, PKCE, JWT, claims, JWKS, at_hash
  • Code complet des deux versions, boutons copier, pièges rencontrés (IPv6, at_hash, SSO silencieux)
  • Trois captures du flow réel : page d'accueil → écran Google → dashboard connecté
FastAPI authlib OIDC OAuth 2.0 PKCE JWT uvicorn
NiveauIntermédiaire
FormatPédagogique + code
Modes lectureSimple · Capot
CibleDev · Architecte sécurité
Ouvrir le POC
POC · 01.04

Passerelle S3 privée · PrivateLink + Fargate + rclone

Partage inter-comptes d'un bucket S3 sans droit IAM direct sur le bucket

Exposer un bucket S3 d'un compte propriétaire (gros chat) à un compte consommateur (baleine) via un endpoint privé S3-compatible, sans donner à baleine de grant IAM direct sur le bucket. Le flux passe par PrivateLink → NLB interne → ECS Fargate → rclone serve s3 ; la lecture réelle est portée par le Task Role côté propriétaire. Compromis assumé et documenté : on déplace l'autorisation du data-layer S3/IAM vers une couche réseau/applicative, au prix d'un composant à opérer et d'une perte d'attribution CloudTrail native par consommateur.

Ce que la page couvre
  • Le vrai compromis architectural face au natif bucket-policy + sourceVpce
  • Runbook CLI autonome de bout en bout · deux comptes · checkpoints reproductibles
  • Endpoints internes (S3 gateway, ECR api/dkr, logs) · AZ résolues dynamiquement
  • Révocation à 5 niveaux · nettoyage complet idempotent · contrôle de coûts
  • Section honnête « réalisé vs durcissement » : TLS, secrets, HA, attribution restent à faire
AWS PrivateLink NLB ECS Fargate rclone AWS S3 ECR IAM
NiveauAvancé
FormatArchitecture + runbook
Comptes02 (cross-account)
StatutPOC · faisabilité prouvée
Ouvrir le POC
POC · 01.05

Clés maîtrisées sur CloudHSM dédié · Custom Key Store KMS

Garder la garde du matériau de clé quand un éditeur tiers traite vos données dans son compte AWS

Réflexion d'architecture anonymisée : un éditeur tiers exploite des données sensibles dans son propre compte AWS, et l'on veut qu'il chiffre exclusivement avec des clés dont le matériau reste non extractible dans un cluster CloudHSM dédié que nous possédons. La question décisive n'est pas la solidité du chiffrement — identique partout — mais la garde du matériau de clé : qui le détient, et qui peut couper l'accès. Le Custom Key Store adossé à CloudHSM cumule API KMS native et racine de confiance mono-locataire, avec révocation unilatérale à trois étages et traçabilité opposable.

Ce que la page couvre
  • KMS managé vs Custom Key Store vs CloudHSM direct : le vrai critère est la propriété du matériau
  • Chiffrement par enveloppe expliqué en 3 schémas (écriture, lecture, architecture cible inter-comptes)
  • Doctrine alias ARN vs key ARN figé · POC obligatoire par consommateur · plan B de migration
  • Rotation manuelle, cycle de vie multi-générations, kill switch à 3 étages, supervision & coûts
  • Annexes : matrice des autorisations par usage · runbook de compromission (4 scénarios)
AWS KMS CloudHSM Custom Key Store FIPS 140-3 Enveloppe IAM CloudTrail
NiveauAvancé
FormatArchitecture + schémas
Comptes02 (cross-account)
StatutNote d'architecture anonymisée
Ouvrir le POC
02 / 03

Agentic AI

Trois POCs autour des agents IA, lus dans l'ordre. Data sur AgentCore pose le vocabulaire (tools, handoff, RAG, guardrails). Hermes Setup raconte une installation native sur VPS avec systemd, Telegram, mémoire persistante. Hermes Subagents conclut sur la question coûts : DeepSeek pour itérer, Haiku quand la robustesse compte, Sonnet seulement si vraiment nécessaire.

POC · 02.01

Data (Star Trek) — OpenAI + AWS Bedrock AgentCore

Pipeline agentique complet · control plane / runtime plane

Page pédagogique sur l'Agentic AI avec un persona inspiré du Lt. Cmdr. Data. Démontre les six briques fondamentales : guardrail en entrée, RAG via Vector Store, WebSearch, handoff multi-agent vers un Calculator, et productionisation via Bedrock AgentCore (container → ECR → runtime scalable). Le pattern OpenAI logique + AWS hébergement est explicité pas à pas.

Ce que la page couvre
  • Six cas observables : prompt bloqué, réponse directe, greeting, calcul, RAG, web_search
  • Setup projet uv + PyCharm + .env, ingestion corpus dans Vector Store
  • FileSearchTool + WebSearchTool + AST parser sûr pour le Calculator
  • Build container, push ECR, déploiement AgentCore, logs CloudWatch
OpenAI Agents SDK Bedrock AgentCore Vector Store RAG Multi-agent Guardrails
NiveauAvancé
FormatPédagogique + code
Livrablesdata_lines.txt + scripts
Ouvrir le POC
POC · 02.02

Hermes Agent · persistant sur VPS

Ubuntu 24.04 durci · systemd · Telegram · mémoire SQLite

Installation native d'un agent IA self-hosted sur VPS — pas de Docker, pas de gateway intermédiaire, clés API directes auprès de chaque provider. L'agent vit en permanence, parle français depuis Telegram (texte + vocal), garde la mémoire d'une session à l'autre, et exécute des briefings automatiques. Doctrine clé : modèle puissant en interactif, modèle léger en cron, sinon la facture explose pendant que tu dors.

Ce que la page couvre
  • Durcissement Ubuntu 24.04 : user non-root, SSH key-only, UFW, fail2ban, unattended-upgrades
  • Couches systeme · runtime · Hermes · providers · Telegram, expliquées une à une
  • Polling Telegram (pas de webhook) · allowlist par pairing code · home channel pour les crons
  • OpenRouter (DeepSeek interactif / Gemini Flash Lite cron) · Tavily · FAL · Edge TTS · Groq Whisper
  • Garde-fous anti-emballement : isolation des sessions cron, credit limit côté provider
Hermes Agent Nous Research OpenRouter Telegram Ubuntu 24.04 systemd Tavily FAL
Durée install~2h45
Sections08 chapitres
FormatRetour d'expérience anonymisé
Ouvrir le POC
POC · 02.03

Hermes Agent · coût des modèles & subagents

DeepSeek · Haiku · Sonnet — le moins cher n'est pas toujours le moins coûteux

Test concret : utiliser Hermes pour piloter des subagents sur une comparaison de frameworks d'agents IA (LangGraph, Strands, OpenAI Agents SDK, Claude Agent SDK). Contrainte de départ : Sonnet trop cher pour itérer. DeepSeek choisi pour le coût, intéressant en conversation mais moins robuste sur l'orchestration (timeouts, adhérence imparfaite). Bascule vers Haiku qui se révèle plus fiable. La page est une page d'expérimentation, pas une recommandation officielle — disclaimer explicite.

Ce que la page couvre
  • Démarche réelle du test : point de départ coût, cas d'usage, résultat inattendu, résultat final
  • Comparatif des modèles sur l'axe coût / robustesse / qualité conversationnelle
  • Architecture subagents · fiches par framework · post-mortem d'exécution
  • Disclaimer fort sur le statut LLM-généré du contenu analytique
Hermes Subagents DeepSeek V4 Claude Haiku LangGraph Strands Claude Agent SDK
TypeAnalyse comparée
Frameworks04 testés
StatutSnapshot daté · mai 2026
Ouvrir le POC
03 / 03

Conteneurisation

Une todo-list CRUD avec uploads, portée du poste local jusqu'à Kubernetes en quatre phases (P0 local → P1 Docker pur → P2 Docker Compose → P3 minikube). Capitalisation pédagogique destinée aux équipes transfuges du monde VM : à chaque étape, l'équivalent VMware/KVM est explicité.

POC · 03.01

Docker / Kubernetes — From Zero to Hero

Flask + Postgres + Traefik · 4 phases · monitoring Prometheus/Grafana

Récit d'une journée de conteneurisation (~7-8h) doublé d'une synthèse de référence en mode Manuel. La même appli, quatre contextes d'exécution, et à chaque étape la même question : comment les services se trouvent-ils, se parlent-ils, persistent-ils leurs données ? Choix volontairement simplifiés pour la lisibilité (Flask debug, secrets en clair, pas de TLS), avec une section dédiée à ce qu'il faudrait durcir pour la production.

Ce que la page couvre
  • Deux modes de lecture : Récit (9 sections) ou Manuel complet (14 sections)
  • Modèle mental Kubernetes pour transfuges VM : Pod, Service, Deployment, PVC, Ingress
  • Manifestes complets · monitoring Prometheus/Grafana · commandes utiles · debugging
  • Code source GitHub + image Docker Hub publique
  • Section « pièges » dédiée aux erreurs mentales du passage VM → conteneur
Docker Kubernetes minikube Traefik v3 Flask Postgres Prometheus Grafana Helm
Durée POC~7-8h
Phases0 → 3 (local → K8s)
Modes lectureRécit · Manuel
Repogithub.com/apidav44
Ouvrir le POC
04 / 04

Matrice de lecture

Lecture transverse : par où commencer selon le profil et le besoin.

Profil Pour découvrir Pour approfondir Pour la prod
Dev backend LDAP Playground · OIDC (mode simple) OIDC (on ouvre le capot) · Data agent Docker/K8s — Manuel
Architecte Data Spark/Iceberg/Trino — glossaire Spark/Iceberg/Trino — script complet · Passerelle S3 (PrivateLink) · CloudHSM — Custom Key Store Spark/Iceberg/Trino — Glue + S3 · CloudHSM — gouvernance des clés
Architecte IA Data agent · pipeline agentique Hermes Subagents · comparatif frameworks Hermes Setup · VPS durci + crons
Ops · transfuge VM Docker/K8s — Récit, phases 0 → 3 Docker/K8s — modèle mental K8s Docker/K8s — section production
Curieux · décideur Hermes Setup (récit narratif) Hermes Subagents (analyse coût)