Deux systèmes déployés
Ce que je livre, illustré par des systèmes réels.
Chaque projet ci-dessous a été réellement déployé, et son code source est public. Les schémas donnent le principe de fonctionnement ; les mécanismes concrets de sécurité et de robustesse sont détaillés juste en dessous. Pour chacun, une ligne dit ce qu'il démontre pour une mission de FDE.
Une chaîne DevSecOps complète, montée par Terraform et détruite en fin de session
Un GitLab auto-hébergé, ses runners, un cluster Kubernetes avec Argo CD et un environnement isolé par utilisateur, déployés en une commande sur un cloud souverain. Chaque modification passe onze contrôles de sécurité bloquants, et aucune mise en service ne se fait sans décision humaine.
Déploiement réel validé le 26/09/2026 — merge request, gates, fusion humaine, MR GitOps, Argo CD Synced et Healthy
Principe de fonctionnement
Sécurité
Une plateforme qui exécute le code d'autrui
- Onze contrôles bloquants — tests et couverture, SAST, secrets sur tout l'historique, SCA et SBOM, IaC, scan d'image, DAST sur l'application démarrée
- La CI ne détient aucun identifiant du cluster — elle propose l'état désiré, Argo CD le tire
- Runners non privilégiés — pas de Docker-in-Docker ; construction d'image par Buildah sur un runner dédié
- Kubernetes durci — Pod Security Admission
restricted, NetworkPolicy par namespace, conteneur non-root en lecture seule - Moindre privilège des jetons — deux jetons distincts, détruits après usage, expirant à 30 jours
- Chaîne d'approvisionnement de la CI — actions épinglées par SHA, images par digest, Dependabot avec délai de carence
Robustesse
Reproductible, traçable, jetable
- Infrastructure entièrement en code — 15 ressources pour la plateforme, 29 pour les environnements, recréées à l'identique
- State Terraform protégé — bucket privé, versionné, verrouillé
- Scan hebdomadaire des images — une image verte le jour de la PR ne le reste pas
- Journal de sécurité — chaque constat réel tracé : CVE critiques sur Tomcat, régression proposée par Dependabot, faux positif DAST
- Destruction en fin de session — coût maîtrisé, aucune infrastructure oubliée
En mission FDE : monter chez un client une chaîne de livraison complète, reproductible et sécurisée, sur son cloud ou un cloud souverain, puis la lui remettre documentée. Code source sur GitHub
Stack & qualité
Agents IA qui surveillent des pipelines et proposent des correctifs
Mirador écoute les workflows GitHub Actions de plusieurs dépôts, classe chaque anomalie par niveau de risque, et propose une correction — automatique pour les cas bénins, soumise à validation humaine pour tout le reste. Jamais de commit direct.
Validé de bout en bout en production — détection d'un échec, Issue portant la correction, puis PR réelle après /approuver
Principe de fonctionnement
Sécurité
Un agent qui agit sur du code : la surface est prise au sérieux
- Validation HMAC-SHA256 de chaque webhook — un événement non signé n'agit pas
- GitHub App, JWT RS256 — jetons à durée de vie limitée, pas de PAT permanent
- Identité de l'approbateur vérifiée contre la liste des responsables du dépôt
- Moindre privilège — la clé d'exécution ne peut que publier, rien d'autre
- Jamais de commit direct — uniquement des Issues et des PR revues par un humain
- Rotation des secrets documentée — procédure issue d'un post-mortem réel
Robustesse
Détection déterministe d'un côté, proposition IA de l'autre
- File + Dead Letter Queue (3 tentatives) — aucune perte silencieuse d'événement
- Idempotence par identifiant de livraison — déduplication des événements répétés
- Journal append-only (writer unique, checksum) — audit inviolable
- Human-in-the-loop gradué — seul le risque le plus bas agit seul, le reste attend un humain
- Dégradation gracieuse — si l'IA est indisponible, l'Issue s'ouvre quand même ; la détection ne dépend pas de Claude
En mission FDE : déployer un agent IA qui agit sur un système réel du client, avec un niveau d'autonomie calibré sur le risque, une validation humaine et un audit complet. Code source sur GitHub
Stack & qualité
La méthode
Une même discipline, du prototype à la production.
Ces principes ne sont pas des slogans : ce sont les décisions récurrentes que l'on retrouve dans chacun des systèmes ci-dessus, et que j'applique en mission chez un client.
Gouvernance
Human-in-the-loop
L'automatisation propose ; l'humain valide toute action sensible. Le degré d'autonomie est calibré sur le risque.
Accès
Moindre privilège
Chaque composant ne détient que les droits strictement nécessaires. Les identités sont cloisonnées et les secrets rotables.
Pannes
Dégradation sûre
En cas de défaillance, le système échoue du côté sûr : il n'ouvre jamais une porte qu'il devrait fermer.
Traçabilité
Auditabilité
Journaux append-only, journal de sécurité, identifiants de corrélation : chaque action est reconstituable a posteriori.
Reproductibilité
Tout en code
Infrastructure, pipelines et contrôles sont versionnés : ce qui a été déployé une fois se redéploie à l'identique.
Transfert
Équipe autonome
Documentation, travaux pratiques, formation : la mission se termine quand l'équipe interne exploite le système seule.