
DevOps, Cloud & Industrialisation Production
Pipelines CI/CD, IaC Terraform, K8s Docker, monitoring et continuité de service chez Pichet, Smile et ACCENSEO. Cloud AWS et OVH dédié. Industrialiser livraison, observabilité et réponse incident sur des SaaS en production.
Ma définition
Le DevOps et la production cloud, c'est dans ma définition la pratique qui transforme un bout de code en système de production fiable, observable et récupérable. Ça couvre CI/CD, infrastructure-as-code, monitoring, continuité, stratégie de tests, et les workflows Git avancés. Sans DevOps mature, l'équipe paie en astreintes ce qu'elle gagne en vélocité, et la dette d'observabilité ne se rattrape jamais à coût raisonnable.
Je l'exerce sur 3 échelles que je tiens en parallèle :
- Dev local : Docker Compose, pnpm/Turborepo, environnements reproductibles via Vagrant ou devcontainers.
- CI/CD : GitHub Actions / Bitbucket Pipelines / GitLab CI selon le contexte client, plans Terraform validés avant tout apply.
- Production cloud : AWS (EC2, RDS, S3, Lambda, EKS, VPC) côté ACCENSEO + OVH dédié Docker (Traefik, Tailscale, GHCR, restic, Netdata, Healthchecks.io). Côté legacy Pichet, Kubernetes Claranet (GKE puis AWS EKS) déployé via GitLab CI + Helm, observabilité Centreon + New Relic + SOFT Monitor.
11 ans de progression du déploiement manuel chez Zend (2014) jusqu'à l'IaC Terraform AWS multi-tenant chez ACCENSEO (2025-2026), avec 15 références DevOps + 7 cloud + 7 monitoring + 7 deployment dans le portfolio.

En 2026, l'industrialisation production open-source converge autour d'une chaîne d'outils CNCF (Cloud Native Computing Foundation) que je tiens à jour en parallèle des chantiers ACCENSEO :
- Kubernetes : 82 % d'adoption en production, OS de fait des workloads IA (66 % de l'inférence GenAI y tourne).
- IaC : OpenTofu, entré au CNCF en avril 2025, devient le pivot par défaut depuis Terraform pour rester sur licence ouverte sans casser les modules, prolongeant les patterns Terraform posés chez ACCENSEO.
- GitOps : Argo CD domine (91 % des organisations cloud-native), validant les workflows plan-et-apply en PR que j'applique sur les déploiements multi-tenant.
- Observabilité : la stack ouverte est Prometheus + OpenTelemetry + Grafana (Loki, Tempo, Mimir), 67 % Prometheus et 41 % OTel en prod, axe sur lequel j'aurais remplacé ELK et SOFT Monitor sur les legacy Pichet / Smile / Zend.
- Supply chain : Sigstore (cosign), SBOM SPDX et Trivy / Grype obligatoires sous le EU Cyber Resilience Act (signalement vulnérabilités septembre 2026, SBOM décembre 2027), alignant l'Europe sur l'EO 14028 US.
- FinOps : OpenCost et Karpenter délivrent 20 à 30 % d'économie cloud sans perte de perf, intégrés sur l'IaC multi-tenant ACCENSEO pour l'attribution des coûts par locataire.
- Plateforme interne : Backstage cumule ~89 % de part de marché IDP, 55 % des organisations ont adopté le platform engineering.
- DORA 2025 (DevOps Research & Assessment) : le rapport abandonne les paliers elite/high pour sept archétypes d'équipes, l'IA augmente le throughput de +2 à +18 % mais dégrade la stabilité, replaçant le Value Stream Management au centre.
Côté francophone, LeMagIT confirme qu'OpenTelemetry est devenu must-have en France, et Le Monde Informatique suit l'extension de FinOps au-delà du cloud public via FOCUS 1.3.
Mes éléments de preuve
Anecdote 1 : Codifier l'infrastructure ACCENSEO en double stack : AWS multi-tenant Terraform et OVH dédié auto-hébergé
Quand j'ai monté ACCENSEO en 2024, j'ai posé une règle non négociable dès le premier client : aucune configuration manuelle, tout en code. Les missions touchaient à la santé, à l'immobilier institutionnel et à la finance - donc à des bases de données plusieurs centaines de Go de RAM en production (PostgreSQL, MongoDB), des audits réguliers et un besoin de reproductibilité totale entre dev, staging et production. Fin 2025, j'ai ajouté une seconde stack OVH dédié auto-administrée en parallèle d'AWS - les deux ne se concurrencent pas, elles me permettent au contraire de proposer le bon compromis client par client : hyperscaler quand le scale l'impose, dédié quand la souveraineté donnée prime.
Côté AWS multi-tenant, j'ai codifié l'ensemble en Terraform : EC2 (applicatifs), RDS PostgreSQL (bases managées), S3 (stockage et backups), CloudFront (CDN), Lambda (serverless), API Gateway, EKS (orchestration conteneurs), VPC + Security Groups + IAM (réseau et sécurité). Workspace Terraform par environnement client, plans validés en CI GitHub Actions / Bitbucket Pipelines avant tout apply, Infracost intégré pour le FinOps (revue automatique du coût avant chaque merge), tunnels SSH pour les accès aux bases.
Côté OVH dédié, j'ai cadré une stack open-source 100% reproductible : Traefik + docker-socket-proxy (reverse proxy en sandbox), BuildKit + GHCR (build et registry), nftables / fail2ban / auditd / AppArmor (sécurité OS), Netdata + Dozzle + GlitchTip (observabilité), AWStats / GoAccess / Webalizer (analytics), UptimeRobot + Healthchecks.io (uptime), GitHub Actions + Trivy (CI/CD avec scan vulnérabilités), PostgreSQL + PostGIS + Valkey + pgAdmin (datastore), msmtp + Resend (mail), restic + Cloudflare R2 + Veeam + Synology NAS (backup), Tailscale (VPN mesh zero-trust), Terraform + OVH API (IaC), Ubuntu Server + systemd + logrotate + cron (OS).
Sur les deux stacks : déploiements zero-downtime, backups automatisés et chiffrés côté client, plans de reprise d'activité testés trimestriellement.
Zéro configuration manuelle sur l'ensemble du parc client, environnements rebuildables en minutes sur AWS (workspaces Terraform) ou en quelques heures sur dédié OVH (stack complète redéployée). FinOps explicite dans chaque PR (Infracost AWS, coût mensuel total maîtrisé OVH). Backups chiffrés côté client avec redondance NAS, accès SSH zero-trust via Tailscale.
Ma force : être capable de configurer aussi bien des infrastructures cloud avancées (AWS multi-tenant en Terraform) que des serveurs dédiés sur-mesure (OVH avec stack open-source complète). Sur les missions ACCENSEO, ça me permet de proposer le bon compromis entre hyperscaler et auto-hébergement selon le besoin client - scale et élasticité d'un côté, souveraineté donnée et FinOps maîtrisé de l'autre. Cette double maîtrise transforme aussi ma posture commerciale : je peux promettre à un client un environnement reproductible et un budget infra transparent dès le devis, ce qui me différencie des consultants qui empilent les serveurs ad hoc.
Anecdote 2 : Outiller l'observabilité de la plateforme PSR Pichet
La plateforme PSR (réception de leads partenaires) du Groupe Pichet ingérait jusqu'à un lead toutes les 2 secondes en pic, depuis une dizaine de partenaires externes (SeLoger, Myopla, Cooper Advertising...) avec des SLA stricts. Chaque lead perdu valait potentiellement des dizaines de milliers d'euros en ventes immobilières manquées. Sur ce périmètre, j'ai travaillé en binôme avec Thomas R. sur les pans techniques principaux et coordonné avec les équipes marketing et les prestataires externes côté intégration partenaires. Sans observabilité par partenaire, on naviguait à l'aveugle - et un incident sur l'API d'un partenaire pouvait passer inaperçu pendant des heures.
Avec Thomas R., on a bâti l'observabilité partenaire par partenaire : dashboards Prometheus + Grafana dédiés (volume, taux d'erreur, latence) avec un onglet par API connectée, alertes email temps réel sur chaque seuil critique, et observabilité native de l'APIM (analytics, throttling, OAuth). J'ai versionné l'API sur 5 versions consécutives documentées sur Confluence, avec stratégie de migration progressive pour les anciens partenaires. Sur l'infrastructure, déploiement sur AWS EKS avec Kubernetes + Docker + GitLab CI, et audit de sécurité formel en 2023 qui a renforcé les contrôles d'accès et les règles pare-feu.
Zéro incident majeur de perte de leads sur 3 ans, diagnostic des anomalies inter-systèmes accéléré (de quelques heures à quelques minutes), SLA respectés sur tous les partenaires, et délai d'intégration partenaire passé de plusieurs semaines à quelques jours grâce à l'industrialisation du pipeline.
Ce projet a verrouillé chez moi un réflexe : investir dans l'outillage de monitoring dès le jour 1 d'une plateforme critique, parce que la dette d'observabilité ne se rattrape jamais à coût raisonnable. Sur les missions ACCENSEO, c'est désormais le premier livrable que je pose sur n'importe quelle infra cliente que je reprends.
Anecdote 3 : Industrialiser le pipeline ESB Pichet sur 4 ans
Le périmètre ESB du Groupe Pichet, c'était plus de 100 flux d'intégration en production entre 20 applications métier, et un trafic critique 24/7 sur les flux comptables et financiers. Sur ce périmètre, j'ai travaillé en binôme avec Kalala M. sur les pans techniques principaux et coordonné avec la direction technique interne de la DSI Pichet, ainsi qu'avec les équipes métier des 20 applications. À mon arrivée, le déploiement de chaque flux passait par des opérations manuelles dispersées et le monitoring SOFT Monitor générait 2 377 notifications par mois sans tri possible.
Avec Kalala M. et la direction technique interne de la DSI Pichet, on a industrialisé le pipeline brique par brique. Côté CI/CD, on a mis en place une chaîne GitLab CI complète avec critères d'arrêt explicites sur chaque déploiement (tests, lint, plans Terraform). Côté qualité opérationnelle, on a imposé des post-mortems blameless sur tout incident critique, formalisé 7 types de documentation technique (DAA architecture applicatif, DAT architecture technique, DAU automatisation, DEX exploitation, DFX flux, DIN installation, DMI migration), et un runbook par flux maintenu à jour. Pour l'observabilité, on a mené l'évaluation ELK Stack (Elasticsearch + Logstash + Kibana) en remplacement de SOFT Monitor, et cadré le passage à MongoDB Atlas pour les flux non-relationnels.
Taux d'incident à un chiffre maintenu sur 4 changements de DSI consécutifs (2021 à 2024), un fait souvent souligné en COPIL. Le framework de post-mortem que j'ai posé est devenu le standard du département pour tous les incidents critiques.
Sur ce projet j'ai compris que la maturité DevOps n'est pas une question d'outils mais de discipline : un système simple tenu en SRE light bat toujours un système complexe abandonné après son achat.
Mon autocritique
Senior, sur 11 ans de progression du déploiement manuel chez Zend (2014) à l'IaC Terraform AWS multi-tenant chez ACCENSEO (2025-2026). La couverture est complète : CI/CD GitHub Actions, infrastructure-as-code Terraform, conteneurisation Docker, observabilité (SOFT Monitor + dashboards), continuité (sauvegardes croisées, rollback testé), workflows Git adaptés au contexte. 15 références DevOps + 7 cloud + 7 monitoring + 7 deployment dans le portfolio. Ce qui reste à muscler : Kubernetes en production hors EKS-via-Terraform, OpenTelemetry à grande échelle et FinOps avancé.

Cœur du rôle CTO scale-up. Sans DevOps mature, l'équipe paie en astreintes ce qu'elle gagne en vélocité. C'est ce qui rend les autres compétences livrables : une architecture sans pipeline reste théorique, une stratégie sans observabilité ne se mesure pas. Pour un poste CTO en industrie régulée, c'est aussi ce qui débloque les audits et les certifications.
Étapes clés du parcours : BTS IG (Informatique de Gestion) (2001) → Senior Software Engineer · lead développeur PHP Magento (2017) → Technical Lead · Flux et Produits : contenus et intégration d'entreprise (2019) → CTO · Founder · directeur technique (2024). Niveau actuel : 5/5 (Expert). Cette continuité témoigne d'une acquisition solide, éprouvée par la répétition et la diversité des contextes.
Mes principes opérationnels
- traiter le pipeline comme du code produit (revue de PR, tests, ADR)
- automatiser tôt et idempotemment les opérations effectuées en panique (rollback, restore, rotation de credentials)
- mesurer un seul indicateur (DORA elite cycle, par exemple) avant d'en empiler dix
- préférer un système simple tenu en SRE light à un système complexe abandonné après l'achat
Mon évolution dans cette compétence
Le DevOps et le cloud sont ce qui rend mes décisions CTO mesurables. Dans mon plan de carrière 2026-2028, ils me permettent d'opérer une production sans astreintes ingérables, de défendre un budget infra devant un board avec un FinOps explicite, et de faire passer un audit sécurité ou conformité sans surprise. Sans eux, la valeur perçue par le client se dégrade en silence à mesure que la base grandit.
L'objectif observable est d'opérer un cluster EKS multi-environnements avec budget transparent, alertes non bruyantes et rollback automatique testé chaque trimestre. L'effort principal porte sur Kubernetes en production (au-delà d'EKS-via-Terraform), OpenTelemetry à grande échelle et FinOps avancé.

Terraform hands-on quotidien sur les projets multi-tenant ACCENSEO. Migration OVH dédié Docker en cours avec Traefik (reverse proxy), Tailscale (VPN mesh zero-trust), GHCR (registry images) et restic (backups chiffrés vers Cloudflare R2). GitHub Actions + Trivy sur tous les pipelines, Netdata en supervision continue.
Certification AWS Solutions Architect Associate (SAA) prévue 2026, AWS DevOps Engineer Professional ou Kubernetes CKA visée 2027. Possible cohorte SRE intensive (Google SRE Workbook + cohorte) déclenchée à l'atteinte du rôle CTO scale-up.
Mes garde-fous opérationnels
Lectures piliers sur la culture DevOps / SRE / FinOps :
- Pratiques SRE et DevOps : Site Reliability Engineering (Google, O'Reilly — lecture gratuite officielle), The Phoenix Project (Gene Kim et al., IT Revolution — roman culte), The DevOps Handbook (2e éd.) (Kim, Humble, Debois, Willis), Accelerate (Forsgren, Humble, Kim) pour la validation scientifique des métriques DORA.
- Infrastructure et observabilité : Infrastructure as Code (2e éd.) (Kief Morris, O'Reilly), Observability Engineering (Majors, Fong-Jones, Miranda) directement aligné avec OpenTelemetry.
- FinOps : Cloud FinOps (2e éd.) (Storment & Fuller, O'Reilly 2023) - référence officielle de la FinOps Foundation.
- Veille continue : release notes OpenTelemetry, écrits FinOps de Bret Mullinix, Cloudflare Blog, AWS Architecture Blog, GitHub Engineering. Homelab en Docker + Tailscale pour expérimenter les nouveautés sans risque production.






