Contact
Illustration de la compétence DevOps, Cloud & Industrialisation Production - Jose DA COSTA
Compétence techniqueDevOps & Cloud

DevOps, Cloud & Industrialisation Production

Pipelines CI/CD, monitoring et continuité de service chez Pichet, Smile et ACCENSEO. AWS plus OVH VPS Docker sur l'infra actuelle. Industrialiser livraison, observabilité et réponse incident sur des SaaS en production.

Confiance personnelle
Expert5/5
FondamentalEn développementOpérationnelAvancéExpert
Évolution de cette compétence dans le temps

Chaque segment représente une période (parcours ou réalisation) où la compétence a été mobilisée. La couleur et la taille du point final reflètent le niveau atteint sur cette période.

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) + OVH VPS Docker, observabilité ELK ou SOFT Monitor selon legacy. 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, la stack d'observabilité est en train de se standardiser autour d'OpenTelemetry, devenu CNCF-graduated et nativement intégré chez Google Cloud, AWS X-Ray, Azure Monitor, Datadog, New Relic et Honeycomb. La CNCF documente précisément le passage des agents propriétaires à un pipeline ouvert dans How to build a cost-effective observability platform with OpenTelemetry, avec à la clé une réduction des coûts d'observabilité de 50 % et une amélioration mesurable du MTTR. Pour un CTO qui démarre une plateforme aujourd'hui, OpenTelemetry + FinOps explicite (Infracost) sont devenus le baseline non négociable. Côté francophone, IT SOCIAL résume bien les leviers concrets (échantillonnage, filtrage, tiering) dans Observabilité IT : comment démocratiser la visibilité à grande échelle sans exploser les budgets.

Mes éléments de preuve

Réalisation

Anecdote 1 : Codifier toute l'infrastructure ACCENSEO en Terraform AWS

Quand j'ai monté ACCENSEO en 2024, j'ai posé une règle non négociable dès le premier client : aucune configuration manuelle. Les missions clients touchaient à la santé, à l'immobilier institutionnel et à la finance, donc à des bases de données contenant 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. Sans IaC dès le jour un, je savais qu'on dériverait en quelques mois.

J'ai codifié l'ensemble de l'infrastructure en Terraform : EC2 (serveurs applicatifs), RDS PostgreSQL (bases managées), S3 (stockage objets et backups), CloudFront (CDN), Lambda (fonctions serverless), API Gateway (exposition REST), EKS (orchestration de conteneurs), VPC + Security Groups + IAM (réseau et sécurité). Chaque environnement client a son propre workspace Terraform avec plans validés en CI GitHub Actions / Bitbucket Pipelines avant tout apply, Infracost intégré au pipeline pour la discipline FinOps (revue automatique du coût avant chaque merge), et des tunnels SSH pour les accès sécurisés aux bases. Les déploiements sont zero-downtime, les backups automatisés, et les plans de reprise d'activité testés trimestriellement.

Zéro configuration manuelle sur l'ensemble du parc client, environnements rebuildables en minutes sur incident, et un FinOps explicite présent dans chaque PR - chaque modification d'infra montre son delta de coût avant d'être validée.

Cette discipline a transformé 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. C'est aussi la base que je rejouerai sur le prochain rôle CTO scale-up - traiter l'infra comme un livrable de produit, pas comme une corvée d'ops.

Réalisation

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. Sans observabilité par partenaire, on naviguait à l'aveugle - et un incident sur l'API d'un partenaire pouvait passer inaperçu pendant des heures.

J'ai bâti l'observabilité partenaire par partenaire : dashboards SOFT Monitor 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 Microsoft (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, j'ai déployé sur AWS EKS avec Kubernetes + Docker + GitLab CI, et passé un 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.

Réalisation

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, 18 K€/mois d'OPEX d'hébergement Docker/Kubernetes chez Claranet, et un trafic critique 24/7 sur les flux comptables et financiers. À 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.

J'ai industrialisé le pipeline brique par brique. Côté CI/CD, j'ai 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, j'ai 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é, j'ai mené l'évaluation ELK Stack (Elasticsearch + Logstash + Kibana) en remplacement de SOFT Monitor, et j'ai 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 parce qu'il était sans précédent dans le département. 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. C'est cette philosophie que je pose dans chaque mission ACCENSEO et que j'imposerai sur la prochaine plateforme scale-up.

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.

Première mobilisation significative : BTS IG (Informatique de Gestion). Progression jusqu'à CTO · Founder · directeur technique, avec un niveau actuel de 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 le projet à 24 mois, 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 ACCENSEO, migration OVH VPS Docker en cours (2026) avec Traefik en reverse proxy, GitHub Actions pour CI/CD multi-app monorepo. Master Expert en Ingénierie du Logiciel actif jusqu'en 2026.

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

Relecture annuelle de *Site Reliability Engineering* (Google), suivi continu des release notes OpenTelemetry et des écrits FinOps de Bret Mullinix. Veille hebdo Cloudflare blog, AWS Architecture, GitHub Engineering. Homelab en Docker + Tailscale pour expérimenter les nouveautés sans risque production.

Navigation circulaire