Réalisations

Des plateformes, de bout en bout.

Cadré, construit, et livré avec des docs et des runbooks que les équipes utilisent vraiment. Les noms des clients restent confidentiels, et les chiffres qui pourraient en identifier un sont décalés ; le travail et les ratios sont tels que décrits.

Migration · récent

Migration complète vers un nouveau domaine

Migrée sans interruption, et l’échéance actionnaires tenue.

Problème

Une plateforme d’entreprise devait changer de domaine de bout en bout, à l’échelle.

Contrainte

Aucune interruption, une échéance actionnaires non négociable, et la stack historique en service pendant toute l’opération.

Contribution

DNS, passerelles API créées et reprises, certificats managés, ingress, nouveaux microservices, et le réseau vers la stack historique.

Livrables

La plateforme migrée, et les tests qui ont prouvé que rien n’avait cassé.

dnsapi gatewaycertificatesingress

Fiabilité · 2026

Reprise d’un GitLab auto-hébergé

Un RPO d’une heure, écrit noir sur blanc, et deux chemins de restauration que l’équipe peut répéter.

Problème

Une instance GitLab auto-hébergée devait passer les correctifs CVE alors qu’une migration de fond échouait depuis quatre mois.

Contrainte

Le service de production devait rester utilisable pendant que la panne était tracée à travers GitLab et PostgreSQL.

Contribution

Montées de version menées, migration diagnostiquée comme un bug amont, et approche de reprise définie.

Livrables

Conception des sauvegardes horaires, procédure de snapshot, runbook de reprise et deux chemins de restauration documentés.

gitlabpostgresqldisaster recoverygce

Coûts · récent

Facture Kubernetes réduite d’un tiers

31 vCPU de réservations récupérés sur trois clusters, sans aucune modification applicative.

Problème

Presque tous les services embarquaient le même bloc CPU et mémoire copié-collé : personne ne pouvait dire lesquels étaient surdimensionnés et lesquels étaient à l’étroit.

Contrainte

Sur GKE Autopilot, c’est la request qui est facturée et non l’usage, et les chiffres devaient tenir pour les charges qui avaient besoin de plus autant que pour celles qui avaient besoin de moins.

Contribution

Mesurer d’abord : 30 jours de dashboards d’utilisation bâtis sur les métriques conteneur déjà présentes dans la plateforme, sans nouvel agent ni collecteur. Puis dimensionner chaque charge sur son régime observé, dans les planchers de requests et les ratios mémoire/CPU propres à Autopilot, en baissant les requests là où la mesure le justifiait et en remontant les deux qui étaient throttlées.

Livrables

Les dashboards d’utilisation, une feuille de dimensionnement par charge de travail, et une règle de dimensionnement documentée que l’équipe réutilise pour ses nouveaux services.

kubernetesgke autopilotpromqlfinops

Coûts · 2026

Facture Kafka, mesurée : de 58 k$ à 9 k$ par an

Environ 84 % par an identifiés, face à l’usage mesuré plutôt qu’à une projection d’éditeur.

Problème

Le Kafka de production tournait sur Confluent Cloud à 58 k$ par an pour 7 % de charge cluster.

Contrainte

La comparaison devait tenir au tarif public face à l’usage mesuré, pas à des projections d’éditeur.

Contribution

Alternatives réelles chiffrées, estimation bâtie sur le mauvais modèle de prix corrigée, et la seule dépendance qui conditionne vraiment la migration nommée.

Livrables

Une base d’usage mesurée, une comparaison chiffrée, et la dépendance bloquante nommée.

kafkafinopsgcpflink

Tests sans risque · 2025

Sandbox GCP proche de la prod

Les clients valident leurs intégrations de bout en bout, et la production n’est jamais touchée.

Problème

Les clients avaient besoin d’un endroit réaliste pour tester leurs intégrations d’API publiques de bout en bout.

Contrainte

L’environnement devait se comporter comme la production, sans accès ni risque sur la production.

Contribution

Sandbox GCP isolée construite avec Terraform, avec les chemins d’API et Auth0 concernés reproduits.

Livrables

Infrastructure versionnée, configuration d’environnement, chemin de déploiement et documentation d’exploitation.

terraformgcpauth0

Chaîne de release · récent

Versioning et automatisation des releases

La production livre exactement l’image validée par la QA, et les releases se coupent toutes seules.

Problème

Les releases étaient coupées à la main : la production ne livrait pas forcément l’image validée par la QA.

Contrainte

Ça devait se brancher sur n’importe quel repo sans câblage sur mesure.

Contribution

Des composants et des scripts qui incrémentent la version de develop, coupent les branches de release, créent des branches de hotfix depuis n’importe quelle release et génèrent les changelogs via CodeRabbit.

Livrables

Des composants réutilisables, une chaîne de release documentée et des changelogs générés.

componentssemverrelease flowcoderabbit

Boucles de retour · 2026

Notificateur de pipeline Slack et Google Chat

Environ 20 % de temps dev en moins perdu sur les échecs : la correction démarre dès que le pipeline passe au rouge.

Problème

Les résultats de pipeline restaient dans la CI : un échec attendait que quelqu’un aille voir.

Contrainte

Ça devait atteindre l’équipe là où elle travaille déjà, sur deux plateformes de chat différentes.

Contribution

Chaque déploiement, health check et rollback publié avec l’environnement concerné. Un échec de CI ou de tests unitaires crée lui-même le ticket Jira, rempli avec le détail de l’échec et assigné au bon développeur.

Livrables

Le notificateur lui-même, l’intégration Jira, et des liens par environnement.

slackgoogle chatjira apigitlab ci

Visibilité · 2026

Dashboard de sprint pour toute la société

Utilisé par le CEO, le CTO et le directeur technique.

Problème

Les données de sprint vivaient dans Jira, dans une forme lisible par la seule équipe.

Contrainte

Ça devait être ouvert à toute la société tout en restant sous contrôle d’accès.

Contribution

Récupère les données de sprint chez Atlassian et les réorganise : filtres, graphiques, archive des sprints passés et comparaisons d’un sprint à l’autre.

Livrables

Le dashboard, hébergé sur GCP avec accès via IAP.

jira apigcpiapcharts

Observabilité · 2026

Logs centralisés vers BigQuery

Chaque log à une requête, pour le triage comme pour les post-mortems.

Problème

Les logs GKE étaient éparpillés entre les clusters : le triage commençait par une chasse.

Contrainte

Les mêmes données devaient servir au triage à chaud et à l’archive de long terme.

Contribution

Les logs GKE routés vers des datasets BigQuery organisés.

Livrables

Les datasets, les dashboards construits dessus, et une archive de post-mortem.

cloud loggingbigquery

Votre plateforme, sur cette liste l’an prochain.

Chacune de ces missions a commencé par une équipe qui savait que quelque chose clochait et n'avait personne dont c'était le travail de le régler. Voir un exemple de rapport d'audit →

Contactez-nous

← Retour à l'accueil