iiinova — where your digital self keeps evolving

mcorbin @mcorbin.bsky.social · 11/09/2026

*ouvre grafana* *~190 déploiements en prod les 5 dernières heures* Donc non on dirait que c'est bon même le vendredi aprem 👍

040

mcorbin @mcorbin.bsky.social · 09/09/2026

I was waiting for this answer 🤣

050

mcorbin @mcorbin.bsky.social · 09/09/2026

En Moselle oui, et escargot dans le reste de la Lorraine.

020

mcorbin @mcorbin.bsky.social · 09/09/2026

Huge mistake for "croissant au chocolat" in Lorraine, can't let that happen. We also say "pain au chocolat", croissant au chocolat is something else (a real croissant with a chocolate bar and optionally sugar on top)

320

mcorbin @mcorbin.bsky.social · 17/08/2026

L'équipe opentelemetry a annoncé que les span events sont deprecated et seront retirés du protocole. J'explique dans cet article de blog pourquoi je pense que c'est une très mauvaise idée: mcorbin.fr/en/posts/202...

mcorbin.fr

OpenTelemetry traces: why deprecating span events is a terrible idea

062

mcorbin @mcorbin.bsky.social · 04/07/2026

A cause des LLM c'est devenu frustrant de coder dans le train avec la connexion qui saute toute les minutes 😅

020

mcorbin @mcorbin.bsky.social · 22/06/2026

Ça marche chez moi, bizarre

100

mcorbin @mcorbin.bsky.social · 21/06/2026

Il ́le sait mais faut pump surtout avant l'IPO 🤣

100

mcorbin @mcorbin.bsky.social · 21/06/2026

Ca faisait longtemps que je n'avais pas écrit un article de blog, il fallait changer ça. Le mythe du "coding is solved" mcorbin.fr/posts/2026-0...

mcorbin.fr

Le mythe du "coding is solved"

260

mcorbin @mcorbin.bsky.social · 16/06/2026

And also being able to ship first iterations of products that don't need immediate rework (or that out the team in firefighter mode).

020

mcorbin @mcorbin.bsky.social · 16/06/2026

A bit off topic but that's also why I'm very cautious when I hear someone saying "product first", i saw it used a lot to not take responsability about terrible tech (which at the end hit teams productivity and customers)

020

mcorbin @mcorbin.bsky.social · 16/06/2026

Until the day it breaks ofc. It's hard to explain but the best team find the right balance between shipping good products and avoid over optimizing (like: doing tech for tech and shipping nothing), there's a sweet spot where teams ship quality at high speed and is able to iterate quickly on issues.

220

mcorbin @mcorbin.bsky.social · 16/06/2026

Like teams shipping awful services (super slow, can't handle the load, bad architecture etc) and then pushing to add resources (more compute memory, scaling DBs...) indefinitely because "product first" (e.g "i don't want to take responsability for my crap"), never digging on the real root causes.

120

mcorbin @mcorbin.bsky.social · 16/06/2026

Yes, having a product mindset is super important as a engineer and we should feel a bit bad when we fail to deliver to paying customers. But I also saw teams that used this as a way to hide issue: the performance topic is also a good example here that I noticed over the years.

130

mcorbin @mcorbin.bsky.social · 16/06/2026

... like flaky tests, slow CI, bad local dev env, bad engineering practices... because "everyone is doing it in the company" (or because responsibility is diluted, or people get used to crappy things with time and "live with it"). I want people that don't accept the status quo and pushes for better.

130

mcorbin @mcorbin.bsky.social · 16/06/2026

...have a p99 at 150ms (which is huge): we're looking at it because it's not something we expect at all. Lots of teams will just consider everything under 1 sec as "good enough" even if it makes no sense technically. Finally, teams that dont takes shortcuts (sacrificing quality for speed)..

130

mcorbin @mcorbin.bsky.social · 16/06/2026

- Having product-oriented SLOs, caring about the product quality - ownership (people investigating incidents, bugs, answering questions...) - strong tech expectations: recent example: In one of my project I have an HTTP GET endpoint (really simple, good indexes, supposed to be fast) that...

130

mcorbin @mcorbin.bsky.social · 06/06/2026

Nice, c'est de la speed paint?

110

mcorbin @mcorbin.bsky.social · 06/06/2026

C'est du mistral small, pas de guardrails etc donc oui on peut lui faire dire des trucs marrants, mais mon but n'est pour l'instant pas d'investir sur ce sujet :D

000

mcorbin @mcorbin.bsky.social · 06/06/2026

Stack: python, fastapi, sqlite, donc déployable sur n'importe où. Pour le LLM + embedding j'utilise Mistral (pydantic ai comme framework donc support d'autres modèles possibles dans le futur). Prompt versioning etc built in. Je vais bosser la partie backoffice et ensuite j'open source.

100

mcorbin @mcorbin.bsky.social · 06/06/2026

Mon blog (mcorbin.fr) fait peau neuve. J'ai décidé d'écrire mon propre blog engine (qui sera open source, c'est encore un mvp là). Le but c'est d'avoir une plateforme AI-first (relecture, traduction...) + une AI dans le blog lui même (RAG etc). Hésitez pas à tester (sans abuser) c'est rigolo

110

mcorbin @mcorbin.bsky.social · 24/05/2026

Ouais l'orga joue beaucoup, quand ton équipe SRE est même pas rattaché à la tech (pas si rare que ça) c'est immediatement finito par exemple.

120

mcorbin @mcorbin.bsky.social · 23/05/2026

Il y a aussi des problemes d'ownership dans tes exemples :D Mais sinon, dans la majorité des organisations, les dev sont plus "puissants" (= on plus d'influence/pouvoir, auront le dernier mot) que les ops/SRE. C'est pour ça qu'il est svt + simple de pousser des sujets SRE... en étant dev :D

120

mcorbin @mcorbin.bsky.social · 23/05/2026

Après être dans le chemin critique en permanence est pas bon aussi :D Mais n'empêche, beaucoup d'orgas même "modernes" sont broken sur ce sujet.

210

mcorbin @mcorbin.bsky.social · 23/05/2026

C'est ce que je voulais dire en effet dans " voir participent pas à l'archi". Après, peu d'équipes SRE ont aussi les compétences en archi/ingéniérie logicielle pour participer, on reste souvent sur des profils infra. C'est le serpent qui se mord la queue (les 2 pb s'alimentent et créent un mur).

010

mcorbin @mcorbin.bsky.social · 23/05/2026

Sinon, cloud > * la majorité du temps mais ça fait 10 ans qu'on a ce débat (et ça sert à rien de comparer les prix bruts vu que 1) personne paye les prix publics du cloud 2) c'est pas du raw compute qui est acheté mais le logiciel/integrations/tooling/secu/certifs/tolerance aux pannes).

010

mcorbin @mcorbin.bsky.social · 23/05/2026

Je suis d'accord mais en vrai beaucoup de SRE vont jamais voir le code produit par les dev voir participent pas à l'archi, du moins en France (ce qui est problématique d'ailleurs, quasi personne fait du "vrai" SRE IMO). Par contre savoir dev est essentiel pour platformiser la prod.

310

mcorbin @mcorbin.bsky.social · 06/04/2026

"You've hit your limit · resets 6pm (Europe/Paris)" Je peux retourner jardiner.

0100

Reposted by mcorbin

Alexis "Horgix" Chotard @horgix.fr · 31/03/2026

Go go @mcorbin.bsky.social, now talking at the @awscloud.bsky.social event on AIOps & Resilience About GenAI, from his standpoint in the Qonto "AI Labs". Pretty sure it will be useful learning to us at @payfiteng.bsky.social :) Wish I could share pictures, but notes only it will be!

111

Reposted by mcorbin

Exoscale - The European Public Cloud @exoscale.com · 30/03/2026

Europe’s first official home for Karpenter is here. 🇪🇺 Exoscale is now the 1st European cloud provider verified for Karpenter. Stop "paying for peak". Get dynamic, scale-to-zero efficiency with 100% sovereign SKS. Check the official listing: github.com/kubernetes-sigs/karpenter #K8s #SKS

github.com

GitHub - kubernetes-sigs/karpenter: Karpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity.

Karpenter is a Kubernetes Node Autoscaler built for flexibility, performance, and simplicity. - kubernetes-sigs/karpenter

052

mcorbin @mcorbin.bsky.social · 22/03/2026

Y'a des strat pour éviter partiellement ça mais globalement ça marche comme ça. C'est le + gros point noir d'aws d'ailleurs (le reste imo ça va le rapport qualité/prix), même si au final ça passe car souvent c'est pas le truc à optim en prio quand faut chercher du $.

010

mcorbin @mcorbin.bsky.social · 22/03/2026

Le pb de l'egress c'est que tu payes le coût X fois meme pour du multi az/region (coût equivalent au multi cloud d'ailleurs). Exemple: Ton log part de ton pod vers un kafka. Possible changement d'AZ. Il est consommé (logstash): same. Poussé à ES: same. ES réplique: same. T'as paye 4 fois l'egress.

110

mcorbin @mcorbin.bsky.social · 02/03/2026

Tous les jours github down et claude down en ce moment.

120

mcorbin @mcorbin.bsky.social · 01/03/2026

Ca monte très vite malheureusement, et c'est par process (je fais tourner 2 workers par instance de l'app là, donc quasi 1gb, et chaque worker type celery/kafka... ça rajoute également).

100

mcorbin @mcorbin.bsky.social · 01/03/2026

Une app python classique (fastapi/sqlalchemy/quelques libs...) j'ai 450mb utilisé idle (0 traffic) 😅

120

mcorbin @mcorbin.bsky.social · 01/03/2026

Franchement on a trollé longtemps java/la jvm sur la consommation mémoire mais Python est largement pire 😅

260

mcorbin @mcorbin.bsky.social · 15/02/2026

(Bon je dis sécurité++ sur l'on prem mais je voulais plutôt dire sécurité juridique/réversibilité mais pas technique, car avant d'avoir du chiffrement/iam partout + des trucs comme nitro nieau hyperviseur facilement utilisables il y a du boulot 😅)

120

mcorbin @mcorbin.bsky.social · 15/02/2026

Genre, aller sur aws/gcp... c'est obvious pourquoi énormément le monde le fait. L'on prem, dans certains cas, aussi (sécurité++/trucs étatiques, grosses boîtes avec besoins spécifiques...). L'entre deux? Je sais plus quoi en penser.

110

mcorbin @mcorbin.bsky.social · 15/02/2026

Et clairement aujourd'hui je pense que si on a les moyens de gérer le hardware (tech, $, orga... car ça reste un métier à part + une certaine scale) c'est surement plus intéressant que d'aller sur un cloud où faut ménager la chèvre et le chou

100

mcorbin @mcorbin.bsky.social · 15/02/2026

Oui ça se fait et quelques belles boites montrent que c'est possible. L'article est contre intéressant car il propose une approche open source alors que d'habitude on est plus sur des alternatives souveraines proprietaires (clever, ovh, scaleway...).

110

mcorbin @mcorbin.bsky.social · 15/02/2026

C'est léger sur la partie tech où c'est un peu plus compliqué que "je mets kube/postgres/grafana stack LGTM et j'ai remplacé aws/gcp avec 1M$ save/an" 😅 Et certaines parties sont étranges (rds c'est PG, kube vient de Google et tout l'écosystème est maintenu par les gafam, minio pb de license etc)

100

mcorbin @mcorbin.bsky.social · 08/02/2026

En effet, itérer et savoir pivoter quand ça fonctionne pas. Mais le narratif aujourd'hui n'est plus à destination des tech comme toi et moi, ça cible les politiciens (qui osef de la tech) avec des arguments souverains pour avoir un marché réservé, et je trouve que c'est la pire stratégie à avoir.

110

mcorbin @mcorbin.bsky.social · 08/02/2026

Et les retours sont mal pris. Si tu dis "on est sur <offre US> parce que <produit>", on va te dire "c'est faux t'en a pas besoin" Les mêmes personnes qui vont dire "en FR la tech c'est sale" vont ensuite traiter d'incompétent les tech qui expliquent de vrais manques (dont l'auteur de l'article btw)

100

mcorbin @mcorbin.bsky.social · 08/02/2026

(La raison étant que les offres étaient galère à utiliser, pas prod ready, trop d'incidents etc, et donc que c'était plus intéressant de tout refaire en bare metal... Franchement j'avais un peu arrêté de suivre le sujet en France et je m'attendais pas à ré-entendre des discours comme ça).

110

mcorbin @mcorbin.bsky.social · 08/02/2026

A l'inverse, Mistral je le vois en entreprise car sur certains use cases leurs modèles sont suffisants et certains de leurs produits (genre l'OCR) marchent bien également. Mais sur le reste, faut que les boîtes se mettent à penser produit et surtout produit qui marche/répond aux besoins des clients.

000

mcorbin @mcorbin.bsky.social · 08/02/2026

J'ai parlé avec pas mal de monde au cloud native days cette semaine (la conf + soirée derrière), bah 100 % des gens sur OVH/Scaleway n'utilisaient pas leurs offres k8s as a service mais faisaient tourner kube sur du bare metal monté en interne (ou via Enix etc), c'est juste pas possible en 2026.

220

mcorbin @mcorbin.bsky.social · 08/02/2026

C'était intéressant, merci. J'ai bien aimé la dernière partie sur se satisfaire du label FR, car je remarque ça aussi: plus personne ne parle du produit, ça se contente du "c'est souverain", sauf que cette stratégie marche pas et ça ne peut pas être le seul argument de nos acteurs locaux.

110