Ton infra te freine ?
Audit de 2 à 6 jours : coûts, résilience, performance. Puis une mission cadrée sur le levier le plus rentable.
Du grand groupe à la startup
+15 missions. 7 ans en prod.
+200 k€
Économisés chaque année par mes clients, cumulés
150+
Services migrés vers Kubernetes, 0 downtime
-72 %
Record de réduction d'une facture cloud
La méthode
Toujours dans cet ordre
La plupart des prestataires te vendent la mission avant d'avoir mesuré. Résultat : on optimise ce qui se voit, pas ce qui coûte. Je commence par l'audit, et l'audit décide de la mission. Si le rapport conclut que tu n'as pas besoin de moi, tu repars avec le rapport, point.
L'audit
2 à 6 jours, à partir de 2 900 € HT. Deux angles : ce que tu paies en trop, et ce qui va lâcher. Tu repars avec des findings chiffrés, triés par impact, et un plan d'action 90 jours utilisable sans moi.
Ce que contient l'auditLa mission à fort impact
On prend la première ligne de la table, celle qui rapporte le plus, et on l'exécute. Périmètre, livrables et prix fixés avant de commencer. Documentation et transmission incluses.
Les formats de missionLe run
Ce qu'on a construit, quelqu'un doit le tenir. Ton équipe, formée pendant la mission. Ou moi : 1 jour par mois, dès 1 500 € HT/mois, résiliable. Ça se décide à la fin, jamais avant.
Qui tient la barre aprèsL'audit
2 à 6 jours, deux angles : ce que tu paies en trop, et ce qui va lâcher. On mesure avant de toucher quoi que ce soit.
Ce que coûte l'audit
à partir de 2 900 € HT
2 à 6 jours selon la taille de ton infra. Le montant exact est écrit dans la proposition avant qu'on commence, et il ne bouge plus après.
Le rapport
Findings chiffrés, triés par impact, plus le plan d'action 90 jours.
Le dashboard
Tes coûts sous les yeux pendant 3 mois, pour suivre ce qui est appliqué.
La restitution
1h en visio avec ton équipe, chaque finding argumenté.
Rien n'est engagé avant : le diagnostic de 30 minutes est gratuit, et c'est lui qui fixe le prix.
Angle coûts · FinOps
Ta facture est le symptôme, quel que soit l'hébergeur : OVHcloud, Hetzner, Scaleway, AWS. Cartographie des dépenses, dimensionnement, architecture, engagements. C'est l'angle détaillé dans toute la suite de cette section.
Angle résilience & performance
C'est la prod qui tombe, la latence qui monte ou le déploiement qui coupe. Tests de charge sur ton infra réelle, points de rupture, SPOF, temps de reprise, chaîne de livraison. Le détail de cet angle.
Le second angle du même audit
Côté résilience & performance
Même format, même livrable : 2 à 6 jours, une table de findings triés par impact. Sauf qu'ici la colonne n'est pas « euros par an », c'est « ce qui tombe, quand, et combien de temps tu mets à te relever ».
Ce que je mesure
- Tests de charge sur ton infra réelle, pas sur un environnement de test qui ment. On cherche le point de rupture, pas la moyenne.
- Points uniques de défaillance : nœud, AZ, base de données, dépendance externe. Ce qui tombe si on débranche quoi.
- Backups et restauration : le backup existe, d'accord. Il restaure ? En combien de temps ? On le teste pour de vrai.
- Comportement sous charge : autoscaling, probes, limites CPU/mémoire, throttling, saturation des connexions DB.
- Détection : est-ce que tu apprends la panne par ton monitoring, ou par un client ?
- Chaîne de livraison : durée d'un déploiement, coupure pendant la bascule, capacité à revenir en arrière en moins de 5 minutes.
Ce que tu reçois
- Le palier de charge où ça casse, chiffré, et le poste responsable
- La liste des SPOF, classés par probabilité et par durée d'indisponibilité
- Ton temps de reprise réel après perte de la base, mesuré, pas estimé
- Le plan d'action 90 jours, trié par impact et par effort
- La restitution 1h avec ton équipe, findings argumentés un par un
Les deux angles se combinent souvent : c'est fréquemment le surdimensionnement qui masque un problème de résilience. On paie trois fois trop cher pour éviter un incident qu'un autoscaling correct réglerait pour moins cher.
Écris-Moi
Tests de charge puis correction avant l'ouverture : une prod stable le jour du lancement. Voir le cas
ValueXchange
Plateforme capable d'encaisser plusieurs salons en simultané, pics de charge compris. Voir le cas
Exxact Robotics
L'audit a débloqué plusieurs dizaines de k€ de budget et la reprise en main de l'infra. Voir le cas
Le premier angle
Côté coûts : le problème
Tu reçois ta facture cloud chaque mois. Tu la regardes 3 secondes, tu soupires, tu paies. Tu sais que tu paies trop. Mais tu ne sais pas combien, ni où ça part, ni combien ça coûterait de changer ça.
5 à 15 %
d'utilisation CPU réelle sur tes instances surdimensionnées. Tu paies un 4xlarge pour faire tourner ce qu'un large encaisserait.
24/7
tes environnements dev/staging tournent en continu alors qu'ils ne servent que 8h par jour.
Ressources orphelines
snapshots oubliés, volumes non rattachés, IPs réservées non utilisées, LB sans cibles. Restes d'anciens projets ou d'ex-employés qui s'accumulent en silence.
0
visibilité de ton équipe dev sur l'impact financier de ses choix d'architecture.
Chaque mois qui passe sans agir, c'est de l'argent brûlé.
Deux situations, deux façons de travailler
Le même audit, mais pas le même rôle pour moi. Dis-moi où tu en es, je m'adapte.
Tu n'as pas d'équipe infra
Je trouve et j'implémente. Tu n'as personne à mobiliser : je fais l'audit, je te restitue le plan d'action, et si tu veux, je mets en place les quick wins moi-même.
- Audit + implémentation par la même personne, pas de perte en route
- Zéro jargon dans la restitution : des euros par an et des actions
- Économies sans recruter ni former personne
Tu as une équipe infra
Je suis le second avis, la contre-expertise externe. Ton équipe garde la main sur l'implémentation, de bout en bout. Mon rôle s'arrête au rapport et à la restitution.
Et non, ton équipe ne va pas se sentir attaquée. L'objectif n'est pas de juger ce qui a été fait, mais de trouver ce qui peut encore l'être. Les findings sont formulés en mode « voici un levier qu'on peut activer », pas en mode « voici ce qui aurait dû être fait ».
- Ton équipe co-pilote les calls de cadrage et de restitution
- Elle reçoit le rapport en premier, pas après ton board
- Un regard externe qui n'a pas hérité des décisions passées, c'est tout
Un exemple de finding
Cas réel observé en mission, anonymisé. Représentatif du niveau de détail du rapport, pas une promesse de résultat identique chez toi. Celui-ci est sur AWS parce que c'est le plus démonstratif ; sur OVHcloud ou Hetzner le même travail porte sur le dimensionnement des machines et le remplissage du cluster, avec le même format de restitution.
FINDING-07 · Compute / EC2
Confiance : mediumInstances t3.2xlarge surdimensionnées pour contourner le throttling burstable
L'équipe avait choisi des t3.2xlarge parce que les t3.medium « manquaient de performance ». En réalité, le CPU throttlait une fois les crédits burstables épuisés. Le problème venait du mode burstable (vCPU partagés sur T3), pas de la taille. Passage sur des c5.large à performances constantes (vCPU garantis), plus autoscaling : taille divisée par 4, et le nombre d'instances passe de 12 à 5.
Économie estimée
-80 % sur ce workload
Effort
2 à 3 jours
Confiance
Medium (test de charge requis)
Pourquoi ce finding n'est pas évident : Compute Optimizer recommande de downsizer en restant sur T3, ce qui aurait reproduit le throttling. La clé, c'est le changement de famille (burstable vers compute optimized), pas la taille.
Le livrable, concrètement
Le cœur du rapport, c'est cette table : tous les findings priorisés par ROI. Tu la lis en 10 minutes, tu sais quoi faire et dans quel ordre.
Rapport d'audit · Findings priorisés par ROI
| Finding | Éco estimée €/an | Effort (jours) | Confiance |
|---|---|---|---|
| Environnements de recette allumés 24/7, éteints hors heures ouvrées | ~65 % du coût de ces envs | 0,5 | High |
Maquette illustrative du format, pas un rapport client. Première ligne : exemple générique pour donner l'échelle, lignes floutées : à quoi ressemble le reste de la table.
Cartographie complète
Dépenses par service, par compte, par tag, par environnement. Tu sais enfin où part l'argent.
Plan d'action 90 jours
Priorités, effort estimé, dépendances techniques. Implémentable par ton équipe ou par moi.
Dashboard Grafana
Connecté à tes coûts, mis à disposition 3 mois pour suivre l'implémentation. Tu vois la dérive avant qu'elle ne devienne un problème.
Restitution 1h avec ton équipe
En visio, findings argumentés un par un. Plus le playbook FinOps de revue mensuelle des coûts.
La méthode, outil par outil Pas de boîte noire : exactement ce que je regarde, et avec quoi. Section technique, saute-la si ce n'est pas ton sujet.
Accès read-only, jour 1
Sur AWS : un rôle IAM en lecture seule que tu crées toi-même (template CloudFormation ou Terraform fourni). En multi-comptes AWS Organizations, le même rôle est déployé sur chaque compte via StackSets, et j'analyse la facturation consolidée depuis le compte de management. Aucun workload touché, aucune donnée applicative lue, révocation en supprimant le rôle.
Sur Scaleway : clé API en lecture seule, scopée par projet IAM. Sur OVHcloud : un compte utilisateur en consultation sur le projet Public Cloud, plus l'accès aux factures détaillées de l'espace client. Sur Hetzner : un token API en lecture et l'export de facturation. Dans tous les cas, aucun workload touché, aucune donnée applicative lue, et tu révoques l'accès en un clic quand c'est fini.
Mesurer avant de toucher
Cost Explorer ventilé par les Cost Allocation Tags (je les active s'ils ne le sont pas), Cost and Usage Report quand il existe, Compute Optimizer et Trusted Advisor pour les premières pistes. CloudWatch pour les métriques CPU, et l'agent CloudWatch pour la mémoire si elle n'est pas collectée, activé le temps de l'analyse seulement. Sans données mémoire, pas de rightsizing sérieux. Côté Scaleway : export de facturation par projet et métriques Cockpit.
Sur OVHcloud et Hetzner, il n'existe pas d'équivalent de Cost Explorer : je pars de l'export de facturation détaillé et je branche une collecte de métriques (Prometheus, node-exporter, ou kube-state-metrics sur un cluster) le temps de l'analyse. C'est une étape en plus, mais elle n'est pas négociable : sans consommation CPU et mémoire réelle, un redimensionnement n'est qu'une intuition.
Passer les leviers dans l'ordre
- Ménage : ressources orphelines (volumes détachés, snapshots, IPs, LB sans cibles), rétention CloudWatch Logs, lifecycle S3.
- Dimensionnement : tailles et générations de machines, familles à crédits (burstable) contre ressources dédiées, extinction des environnements de test hors heures ouvrées. Sur OVHcloud et Hetzner, c'est le levier numéro un : le catalogue est simple, donc le gaspillage vient presque toujours d'un serveur choisi trop grand une fois, et jamais revu.
- Remplissage du cluster : sur Kubernetes, des nœuds à moitié vides se paient plein tarif. Réservations demandées contre consommation réelle, puis consolidation. C'est le poste le plus souvent ignoré chez les hébergeurs à prix fixe, parce que la facture ne bouge pas : c'est la capacité gâchée qui bouge.
- Stockage et sauvegardes : volumes détachés, snapshots empilés, classes de stockage objet, durées de rétention. Générique, et rentable partout.
- Réseau : sur AWS, passerelles NAT contre points de terminaison VPC et trafic entre zones — souvent une facture cachée à cinq chiffres. Sur OVHcloud et Hetzner, le trafic sortant est largement inclus : le poste disparaît, et c'est parfois à lui seul l'argument d'une migration.
- Instances interruptibles : candidats Spot et consolidation Karpenter sur AWS et Scaleway. Les charges critiques avec état restent en on-demand.
- Engagements en dernier : Savings Plans et Reserved Instances chez AWS, engagement mensuel ou annuel plutôt qu'horaire chez OVHcloud et Hetzner. Toujours après le dimensionnement, jamais avant : s'engager sur une infra trop grande, c'est verrouiller le gaspillage pour un an.
Restituer et outiller
Rapport avec la table des findings priorisés par ROI, plan d'action 90 jours, dashboard Grafana branché sur tes coûts, restitution 1h en visio avec ton équipe. Selon la formule : alertes budget, Cost Anomaly Detection, playbook de revue mensuelle.
Ce que l'audit a donné chez eux
Deux factures, deux contextes, même méthode : on mesure, on coupe ce qui ne sert pas, on dimensionne sur les métriques réelles.
Monnier Paris
Mode & retail luxe, plateforme e-commerce sur Heroku.
-72 %
sur la facture cloud
Ce qui a été fait
- · Audit des coûts, puis migration de Heroku vers AWS Elastic Beanstalk
- · Right-sizing basé métriques
- · Migration de la stack de logs
- · Pipeline GitLab CI avec S3 + AWS CLI
Florent Palomares · CTO, Monnier Paris
Écris-Moi
App de rencontre, infra sur AWS EKS, à l'approche du lancement.
-69 %
sur les coûts AWS
Ce qui a été fait
- · Sizing pods et storage basé sur les métriques réelles
- · Autoscaling : Karpenter, HPA, VPA
- · Charts Helm prod-ready, dimensionnés au juste besoin
La même mission comportait un volet stabilisation et monitoring avant lancement : il est documenté plus bas, dans les cas concrets.
Kevin Senechal · Fondateur, Écris-Moi
Les ~30 % accessibles, fais-les toi-même
Le guide gratuit détaille les 7 leviers que j'utilise en mission (rightsizing, savings plans, ménage), dans le bon ordre, avec les pièges. L'audit, lui, cherche ce que les leviers ne voient pas : l'architecture.
La mission à fort impact
L'audit a produit une table de findings triés par ROI. La mission, c'est l'exécution des premières lignes. Une seule règle : on ne démarre rien dont on n'a pas chiffré le gain.
Selon ce que l'audit remonte
Les formats de mission
Cinq formats, un seul mode de fonctionnement : périmètre et prix fixés dans la proposition écrite, avant de commencer.
Migration Cloud
Prix fixé avant de commencer
D'un VPS, d'Heroku ou de Render vers un vrai hébergeur, ou d'un cloud à un autre : OVHcloud, Hetzner, Scaleway, AWS. Dans les deux sens, rapatriement en Europe compris. Plan de retour arrière documenté avant la bascule, pas de coupure côté utilisateurs.
Voir les cas migrationTransformation complète
Prix fixé avant de commencer
Kubernetes n'est pas l'objectif, c'est un moyen. On revoit l'architecture des services, la chaîne de livraison et l'observabilité, et on migre depuis Docker Compose ou des VMs quand c'est la bonne réponse. Y compris quand c'est mal parti : chez Rakuten France, une transformation sauvée du désastre, 60+ services, 0 downtime.
Préparation au lancement
Loadtest, résilience, performance
Avant ton lancement : tests de charge sur ton infra réelle, puis correction des problèmes de résilience et de performance qu'ils révèlent. Chez Écris-Moi, une prod stable au lancement. Chez ValueXchange, une plateforme qui encaisse plusieurs salons en simultané.
Accompagnement long
Jusqu'à 2 ans en équipe
Renfort senior intégré à ton équipe infra : je prends les sujets en autonomie, je documente, je transmets. Chez Enedis, presque 2 ans en équipe Kubernetes on-premise, côté cloud privé interne.
Voir le cas EnedisFormation
Git, Docker, Kubernetes, projets CNCF
Formation de tes équipes sysadmin et dev sur ton infra réelle, pas sur un lab jetable : Git, Docker, Kubernetes et les projets CNCF qui tournent autour. Chez Rakuten France, 5 sysadmins formés pendant la migration : l'équipe est repartie autonome sur le cluster.
Recrutement
Ton premier profil infra
Si l'équipe n'existe pas encore : définition du poste, tri des candidatures, entretien technique mené avec toi. Puis je forme la personne recrutée sur ton infra pour qu'elle soit opérationnelle en semaines, pas en six mois. C'est le format que je recommande quand la bonne réponse est une embauche, pas un prestataire.
Recruter ou déléguer ?Comment ça démarre
Diagnostic gratuit, 30 min
Tu m'expliques ton contexte. Je te dis si je peux aider, comment, et combien. Sans engagement.
Proposition écrite
Forfait ou régie. Périmètre, livrables et conditions noir sur blanc.
Mission
Pour les migrations : plan de rollback documenté avant la bascule. Documentation et transmission incluses.
Le run
Une mission qui se termine sur un document de passation et plus personne, ça se dégrade en six mois. Deux suites possibles, décidées à la fin de la mission : ton équipe reprend, ou je reste.
Ton équipe reprend
C'est le cas par défaut, et c'est celui que je pousse quand tu as déjà des gens. La transmission est dans le forfait, pas en option : doc d'exploitation, runbooks, et formation de l'équipe sur ton infra réelle pendant la mission.
- Stack open source standard, opérable par n'importe qui d'autre
- Repo Git, charts et secrets t'appartiennent, aucun lock-in
- Chez Rakuten France, 5 sysadmins formés pendant la migration : l'équipe est repartie autonome
Je reste en renfort
dès 1 500 € HT/mois
Quand il n'y a pas d'équipe infra, ou pas encore. 1 jour par mois sur ce qu'on a construit ensemble : montées de version, incidents, évolutions. Volume ajustable à 2 ou 4 jours si ta charge grossit, résiliable avec un mois de préavis. Pas d'engagement de deux ans.
- Celui qui a construit l'infra est celui qui la maintient
- Un SRE senior coûte plus cher qu'un dev, et un seul ne suffit pas : il faut quelqu'un pour ses congés
- Chez Enedis, presque 2 ans en équipe Kubernetes on-premise
Je peux aussi t'aider à recruter ton premier profil infra et le former, si la bonne réponse est une embauche plutôt qu'un prestataire. Je le dis quand c'est le cas.
Si c'est toi qui signes
Ce que ça coûte, ce que ça rapporte, ce que tu risques
Trois questions reviennent à chaque fois, et elles n'ont rien de technique. Voilà les réponses, sans jargon.
Combien
2 900 € HT
C'est le point d'entrée : l'audit. Le montant est fixé au cadrage, écrit dans la proposition, et il ne bouge plus. Ce qui vient après se décide seulement une fois que tu as le rapport en main.
Pourquoi pas embaucher
4 à 6 mois
C'est le délai pour recruter un profil infra senior, à supposer que tu le trouves. Et un seul ne suffit pas : il faut quelqu'un pendant ses congés. Le chantier, lui, est là maintenant. Si l'embauche est quand même la bonne réponse, je te le dis, et je peux t'aider à recruter.
Et si ça se passe mal
Rien en plus
Le périmètre et le prix sont fixés avant de commencer : un imprévu technique est mon problème, pas une rallonge sur ta facture. Toute bascule a son plan de retour en arrière écrit à l'avance, et tout incident, son compte rendu.
Tu repars propriétaire de tout : le code d'infrastructure, les accès, la documentation. Rien n'est enfermé dans un outil maison, donc tu peux reprendre en interne ou changer de prestataire sans rien réécrire.
Cas concrets
Huit missions, du grand groupe à la startup. Contexte, ce qui n'allait pas, ce qu'on a fait, le résultat.
Gam'in
Startup edtech · OVHcloud
Contexte
Deux applications en production plus le site public. Un fondateur qui code lui-même, aucune équipe infra derrière lui. Une centaine de nouveaux clients par semaine, et l'exigence qui va avec : un socle de qualité, capable de suivre la croissance sans être réécrit dans six mois.
Problème
Tout tournait sur un seul VPS configuré à la main : un point de panne unique, des fichiers posés sur le disque de la machine, et aucun moyen d'essayer une modification avant de l'envoyer en production.
Ce qui a été fait
- · Socle Kubernetes managé sur OVHcloud, entièrement décrit en OpenTofu (cluster, bases managées, stockage objet, DNS, load balancer)
- · GitOps ArgoCD : un environnement de prévisualisation créé automatiquement à chaque pull request
- · Les deux applications rendues stateless, fichiers externalisés vers le stockage objet
- · PostgreSQL en haute disponibilité avec restauration à la minute près, secrets en coffre-fort, SSO devant les interfaces d'administration
- · Supervision, journaux, sauvegardes du cluster, HTTPS et DNS automatiques
- · Puis, dans un second temps, le site public et son CDN d'assets
Résultat
Il déploie seul
le fondateur pousse son code, la prévisualisation se crée, la production suit. Sans ops, et sans avoir appris Kubernetes
Écris-Moi
App de rencontre
Contexte
Lancement de l'app à préparer, infra sur AWS EKS.
Problème
Un cluster EKS qui crashait régulièrement (redémarrages intempestifs), à stabiliser avant le lancement. Et aucune visibilité sur ce qui se passait dedans.
Ce qui a été fait
- · Résolution des problèmes de stabilité du cluster
- · Monitoring et alerting : stack VictoriaMetrics + Grafana
- · Charts Helm prod-ready : PDB, HPA, VPA, Anti-Affinity
- · ACM + ALB pour certificats wildcard automatiques
Résultat
Prod stable au lancement
sans intervention manuelle, avec un monitoring qui alerte avant que ça casse
La même mission comportait un volet réduction de coûts : -69 % sur la facture AWS, documenté plus haut, dans l'étape audit.
Kevin Senechal · Fondateur, Écris-Moi
Exxact Robotics
Robotique agricole
Contexte
Plateforme de gestion d'un tracteur enjambeur de vigne autonome, héritée d'un ancien prestataire.
Problème
Une infra non maîtrisée, dont il ne restait qu'un compte AWS. Impossible de commercialiser le produit dans cet état.
Ce qui a été fait
- · Audit complet DevOps
- · Reverse engineering, documentation, IaC modulaire OpenTofu pour redéployer la plateforme rapidement
- · Cluster multi-AZ pour le jumeau numérique, avec environnements de preview
Résultat
Commercialisation débloquée
Exxact maîtrise l'infra de son produit · plusieurs dizaines de k€ de budget débloqués par le groupe suite à l'audit
Hugo Baltz · Ingénieur logiciel géomatique web full-stack, Exxact Robotics
Rakuten France
E-commerce & marketplace
Contexte
60+ services en Docker Compose legacy, infrastructure on-premise.
Problème
La bascule vers Kubernetes on-premise partait en vrille, techniquement et humainement. La stack était surchargée de technos qui font bien sur le papier, mais qui ne correspondaient en rien au niveau de maturité des équipes (des sysadmins habitués à administrer serveur par serveur, avec une maîtrise de Git relative) et n'avaient pas forcément de sens ensemble. L'équipe avait perdu l'envie, blâmait la techno et commençait à se rebeller contre un changement très mal engagé. Il fallait remettre la migration sur les rails, et surtout redonner à l'équipe sysadmin l'envie et les moyens de la porter elle-même.
Ce qui a été fait
- · Énorme ménage dans la stack : tout ce qui n'était pas 100 % utile et facilement apprenable par l'équipe a dégagé
- · Identification de ceux qui pouvaient porter le sujet, et une session de pair avec eux à chaque fois que je touchais quelque chose : Kubernetes et le GitOps se transmettent en faisant, pas en slides
- · Beaucoup de démos, pour challenger les choix et évangéliser en montrant plutôt qu'en affirmant
- · Refonte de quasiment tout, proprement, en pair programming avec leur nouvelle recrue : la confiance se construit en livrant ensemble
- · Tampon avec le responsable infra pour tempérer les objectifs de la direction et retrouver un rythme tenable
- · À chaque dysfonctionnement remonté par les devs : "je m'en occupe personnellement", puis la preuve que c'est fait
- · Cluster k0s multi-master HA + Calico CNI
- · CI/CD Jenkins + Helm charts génériques + SOPS
- · Migration progressive HAProxy/keepalived zero-downtime
- · Formation Kubernetes de 5 sysadmins
Résultat
Une migration sauvée du désastre
60+ services migrés, 0 downtime · code infra 300k → 10k lignes · équipe autonome
Thibaud Simond · Responsable Infrastructure, Rakuten France
Enedis
Opérateur du réseau de distribution d'électricité
Contexte
Une offre Kubernetes mutualisée à destination des projets métiers internes. Mission d'expertise pour fiabiliser la production, accompagner les équipes applicatives et contribuer à la prochaine génération de l'offre.
Problème
Trop de bruit d'alerting, des incidents récurrents traités à la main, et un contrôle d'allocation des ressources qui poussait les applications au throttling.
Ce qui a été fait
- · Refonte de l'alerting et de la réponse à incident (règles, routage, sévérités) : moins de bruit, résolution plus rapide
- · Autoremédiation déclenchée sur alertes Prometheus : les incidents récurrents se résolvent sans intervention humaine
- · Retrait de la "cloche" d'allocation : un script custom bloquait les rolling updates tant que les requests des pods n'étaient pas à 95 % de la consommation réelle. Les projets déclaraient des requests absurdement basses pour passer le contrôle, et tout throttlait. Son retrait a rétabli un dimensionnement sain et débloqué les déploiements
- · Coaching des équipes applicatives : onboarding Kubernetes, bonnes pratiques de déploiement, ateliers Performance et Résilience
- · Dashboards Grafana de qualité production pour la plateforme et les workloads métiers
- · Contribution à la V2 de l'offre : architecture, modèle de service, parcours utilisateur
Résultat
Une plateforme fiabilisée
alerting utile, incidents récurrents auto-résolus, déploiements débloqués, et des devs sensibilisés aux notions de performance et de résilience
Julien Faure · Product Owner Cloud Privé Kubernetes · Enedis
ValueXchange
Plateforme événementielle (salons B2B)
Contexte
Plateforme de salons B2B avec chat, visioconférence et scan de billets en temps réel.
Problème
Tenir la charge sur plusieurs salons simultanés, y compris pendant les pics.
Ce qui a été fait
- · Load testing intensif micro-services avec right-sizing
- · Chart Helm générique : Anti-Affinity, PDB, HPA, VPA
- · Staging isolé pour répétitions événement
- · Stack monitoring VictoriaMetrics + VMScrape/VMProbe
Résultat
Salons B2B tenus en charge
aucun dommage grave à l'image de ValueXchange auprès de ses clients exposants · code IaC réduit ÷4
Philippe Escalle · CTO, ValueXchange
Conservatoire Augmenté
LMS musique & xAPI
Contexte
Un LMS musique avec des contenus xAPI lourds : vidéo, audio, fichiers immersifs.
Problème
L'hébergement initial, une serverless function et un VPS, ne tenait pas la charge face à ces contenus lourds. Il fallait une infra souveraine française qui suive, à coûts maîtrisés.
Ce qui a été fait
- · IaC Terraform sur Scaleway Kapsule
- · GitOps ArgoCD + Image Updater
- · Stack monitoring Grafana + VictoriaMetrics
- · HA via PDB, HPA, VPA
- · Secrets et reloads automatisés : External Secrets Operator + Stakater Reloader
Résultat
LMS en prod, souverain
déploiements automatisés en GitOps, monitoring et HA en place, coûts maîtrisés
Emilie Zawadzki · CTO, Conservatoire Augmenté
Éstiam
École supérieure d'informatique · Lyon
Contexte
Initier des élèves de 3ᵉ année à dominante développement à Docker et Kubernetes, en vue d'une utilisation professionnelle. 3 mois, sur site.
Problème
Un public qui vise le développement applicatif, pas l'administration d'infrastructure : il fallait une autonomie d'usage (conteneuriser, comprendre les manifestes, déployer, déboguer) sans la gestion bas-niveau d'une plateforme qu'ils n'opéreront pas.
Ce qui a été fait
- · Module Docker : conteneurs, build d'images, volumes et réseau, Dockerfile, compose multi-services
- · Module Kubernetes : objets fondamentaux (Pods, Deployments, Services, ConfigMaps, Secrets, Ingress), manifestes YAML, déploiement et debug
- · Pédagogie par la pratique : chaque concept immédiatement mis en œuvre sur des exercices concrets
- · Posture orientée développeur : déployer son application, lire un manifeste fourni par l'équipe ops, déboguer un pod qui ne démarre pas
Résultat
Des devs autonomes
sur Docker et Kubernetes, à l'usage, sur les situations qu'ils rencontreront en poste
Ton contexte ressemble à un de ces cas ?
30 minutes, gratuit, sans engagement. On regarde si le format mission a du sens pour toi.
Réserver le diagnostic gratuit (30 min)Ce qu'ils en disent
"Sa pédagogie et son expertise nous ont permis de monter en compétence dans ce domaine. Il a été force de proposition et nous a même challengé sur d'autres scopes de l'infrastructure qui ne faisaient pas partie de sa mission. Si vous cherchez un expert Kubernetes et/ou devops arrêtez-vous ici."
Responsable Infrastructure · Rakuten France
"Notre plateforme est devenue capable de supporter sans difficulté plusieurs salons en simultané, y compris lors de pics de charge importants, avec un niveau de fiabilité et de performance remarquable. Une collaboration précieuse, que je recommande vivement."
CTO · ValueXchange
"Sa disponibilité et sa capacité à proposer une architecture à la fois robuste, évolutive et optimisée en termes de coûts ont été déterminantes pour la réussite du projet qui possédait bien des spécificités liées à l'hébergement de contenu xAPI dans un LMS. Je recommande vivement Arthur pour toute mission d'architecture cloud ou projet nécessitant une forte compétence Kubernetes."
CTO · Conservatoire Augmenté
"Arthur était équipier technique « Kubernetes on prem » au sein de l'équipe (dont je suis le Product Owner à Enedis) pendant pratiquement 2 ans. Il est bon techniquement, orienté utilisateur, avec une capacité importante à être force de proposition. Il a su s'intégrer rapidement à l'équipe et prendre les sujets en autonomie. Il a apporté une vue « out-of-the-box » intéressante à l'équipe."
Product Owner Cloud Privé Kubernetes · Enedis
"Merci Arthur pour ta disponibilité sur cette migration !"
CTO · Monnier Paris
-72 % sur la facture cloud
"Un énorme merci ! :)"
Fondateur · Écris-Moi
-69 % sur la facture AWS, prod stable au lancement
"Arthur travaille efficacement, rapidement et est à l'écoute. Un plaisir d'avoir travaillé avec lui."
Co-Fondateur · Tagether
Qui fait le travail
Arthur Zinck. Kubernetes en prod depuis 2019, après plusieurs années d'ops sur d'autres stacks. Bedrock Streaming, Rakuten, scale-ups et PME. Aujourd'hui freelance via z3k.tech : c'est moi qui fais la mission, du diagnostic à la transmission. Pas d'équipe à 30 où l'on perd des messages dans 5 Slack channels, pas de junior envoyé à ta place.
CKA
Certified Kubernetes Administrator
Délivrée par la Cloud Native Computing Foundation (CNCF) et la Linux Foundation. Exam hands-on de 2h, opérations cluster, networking, troubleshooting, sécurité.
CKS
Certified Kubernetes Security Specialist
La certif sécurité la plus exigeante de la CNCF. Pré-requis CKA. Exam de 2h sur le hardening cluster, supply chain security, runtime detection, network policies, secrets.
Ce que je fais
- →Migrations de VPS, Heroku ou Render vers OVHcloud, Hetzner, Scaleway ou AWS
- →Migrations vers Kubernetes, GitOps complet : ArgoCD, Helm, CloudNativePG, External Secrets
- →Préparation au lancement : loadtests, résilience, performance
- →Audits DevOps et FinOps
- →Formation équipes sysadmin / dev : Git, Docker, Kubernetes, projets CNCF
- →Run et renfort récurrent sur une infra que j'ai construite
Ce que je ne fais pas
- →Coder ton app (tu codes, j'opère)
- →Pentest applicatif / audit code
- →Stack data lourde (ML training, ETL TB+)
- →Latence sub-ms (HFT, gaming temps réel)
- →Compliance audit (je fournis l'infra, l'auditeur est externe)
Questions fréquentes
Ma facture cloud est petite. Ça vaut le coup ?
Souvent oui, mais rarement pour la raison que tu crois. Sur une petite facture, l'angle coûts seul rapporte peu : ce qui change la vie, c'est la prod qui tient debout, les sauvegardes qui restaurent vraiment et les déploiements qui ne coupent plus. C'est exactement ce que couvre le second angle de l'audit. On regarde ton cas au diagnostic de 30 minutes : si le chantier ne vaut pas son prix chez toi, je te le dis là, gratuitement.
Ça commence toujours par un audit ?
Oui. 2 à 6 jours pour mesurer ce qui coûte et ce qui casse, avec une table de findings chiffrés et triés par impact. C'est l'audit qui décide de la mission, pas l'inverse. Et le rapport est utilisable sans moi : tu peux le faire exécuter par ton équipe ou par quelqu'un d'autre.
Comment tu accèdes à mes données chez mon hébergeur ?
Un rôle IAM read-only temporaire que tu crées sur ton compte (CloudFormation template ou Terraform fourni). En multi-comptes AWS Organizations, le rôle est déployé sur chaque compte via StackSets, toujours en lecture seule. Permissions minimales : lecture EC2, RDS, S3 metadata, Cost Explorer, CloudWatch metrics. Pas de credentials persistants chez moi, pas d'accès à tes données applicatives (les buckets S3 contenant tes données ne sont jamais listés). Révocation = tu supprimes le rôle, fin de session. Sur Scaleway, OVHcloud et Hetzner, même principe avec une clé API ou un compte en consultation, révocable en un clic. NDA signé en début de mission si tu veux formaliser.
Quels clouds tu audites ?
AWS et Scaleway en profondeur (instances, storage, réseau, bases managées, Spot/RI/SP, Karpenter, Aurora vs RDS). Multi-comptes AWS Organizations supporté. OVHcloud et Hetzner aussi : l'angle y est différent, moins d'engagements et de services managés à arbitrer, plus de dimensionnement, de résilience et d'architecture — et c'est souvent là que se trouve le gros du gain. Sur GCP et Azure je ne fais pas d'audit coûts : mieux vaut un spécialiste. En revanche l'audit résilience et performance ne dépend pas du fournisseur, je le fais partout.
J'ai déjà une équipe infra, l'audit sert à quoi ?
À avoir un second avis. Ton équipe est dans le quotidien, elle a hérité des décisions passées et elle a rarement le temps de tout repasser au crible. Une contre-expertise externe trouve les angles morts (familles d'instances, engagements mal calibrés, réseau) sans rien retirer à ton équipe : elle garde la main sur l'implémentation, co-pilote les calls et reçoit le rapport en premier. Détail dans la section "Deux situations" plus haut.
Combien de temps entre signature et démarrage ?
2 à 3 semaines en moyenne. Le délai vient du planning, pas du setup, je commence par l'accès IAM (1-2 jours) puis 2-6 jours de mission selon la taille de l'infra. Si tu vises un démarrage rapide, dis-le-moi au call diagnostic, je peux parfois caler dans un trou de planning.
Quel est le livrable exact ?
Rapport PDF (10-20 pages selon la taille de l'infra) avec : cartographie des dépenses par service / compte / tag, table des findings priorisés par ROI (économie estimée, effort, dépendances, niveau de confiance high/medium/low), plan d'action 90 jours. Dashboard Grafana de tes coûts mis à disposition pendant 3 mois pour suivre l'implémentation. Restitution en visio 1h avec ton équipe. La structure de la table est montrée plus haut sur cette page.
Tu vas me vendre une mission à la fin de l'audit ?
L'audit est une prestation autonome : tu repars avec le rapport et tu en fais ce que tu veux, y compris le faire exécuter par ton équipe ou par quelqu'un d'autre. La mission est la suite logique quand tu n'as pas les bras en interne, pas une condition. Et si le rapport conclut que le gain ne vaut pas le chantier, je te le dis : c'est écrit noir sur blanc dans la colonne effort.
Pourquoi pas recruter un SRE en interne ?
Parce que le recrutement prend 4 à 6 mois et que le chantier, lui, est là maintenant. Un bon SRE coûte plus cher qu'un dev, et un seul ne suffit pas : il faut quelqu'un pour prendre le relais pendant ses congés. À deux, tu n'as pas assez de charge pour les occuper toute l'année. Une mission cadrée règle le pic, la formation laisse l'autonomie derrière, et ton temps de CTO reste sur le produit. Si l'embauche est quand même la bonne réponse, je te le dis, et je peux t'aider à recruter.
C'est quoi le risque si ça se passe mal ?
Toutes les migrations incluent un plan de rollback documenté avant la bascule. Les incidents arrivent : quand ça pète, on prévient vite, on diagnostique, on corrige, et tu as un post-mortem écrit. Le périmètre, les livrables et le prix sont fixés dans la proposition avant de commencer, donc un imprévu technique ne devient pas une rallonge de facture.
À la fin, je suis dépendant de toi ?
Non, et c'est volontaire. Stack open source standard (Kubernetes, ArgoCD, Helm, Terraform), repo Git, charts et secrets chez toi. Doc d'exploitation et runbooks livrés avec la mission, formation de ton équipe incluse quand elle existe. Tu peux reprendre en interne ou passer à un autre prestataire sans rien réécrire.
Forfait ou régie ?
Forfait dès que le périmètre est cadrable, ce qui est le cas de la quasi-totalité des missions issues d'un audit : tu connais le prix avant de signer et le dérapage est mon problème, pas le tien. La régie est réservée à l'accompagnement long en renfort d'équipe, où le périmètre bouge chaque sprint par nature.
Toujours pas prêt ? Garde au moins le guide.
Les 7 leviers détaillés (rightsizing, Spot + Karpenter, Savings Plans, gp2 vers gp3, NAT Gateway, et le reste), à appliquer toi-même.
Repars avec 2 ou 3 pistes,
même sans mission
30 minutes en visio. Tu me montres ta facture, ton archi ou ton dernier incident. Je te dis ce que je regarderais en premier, ce que ça coûte de corriger, et dans quel ordre. Tu ressors avec des pistes applicables sans moi.
Réserver le diagnostic gratuit (30 min)Gratuit, sans engagement, sans pitch déguisé. Et si tu n'as pas besoin de moi, je te le dis.
Tu préfères l'écrit ? Décris ta situation en 3 lignes, réponse sous 24h ouvrées. Ou regarde d'abord comment se déroule une mission.