mcorbin

(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 😅)

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.

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

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...).

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)

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.

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)

(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).

Ça y est, on sort enfin du déni : nous, français, avons trop longtemps cédé à la tentation de se soumettre à d'autres pays, en particulier les États-Unis, pour notre Tech. Bon, ok, et après ? Et après, il y a tout un modèle à reconstruire, et pas qu'un modèle technologique 😅 Oh que non, va falloir La Souveraineté Française dans la Tech - Première Partie 🇫🇷

Ça y est, on sort enfin du déni : nous, français, avons trop longtemps cédé à la tentation de se soumettre à d'autres pays, en particulier les États-Unis, pour notre Tech. Et donc il va falloir refactorer notre rapport à la Tech, et à la Société, en profondeur 😉

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.

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.

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.

Je viens de demander à Claude Code (Opus 4.5) de résoudre le problème de system design qui était demandé quand je faisais passer des entretiens SRE.

Bilan: Il fait exactement les mêmes erreurs que les profils plutôt juniors (over engineering, propose des trucs qui marchent pas quand on creuse...)

Au contraire ceux qui vont dire ça c'est ceux qui ont de vrais problématiques de productivité et peuvent pas se permettre de perdre du temps à configurer le vrack ovh.

J'ai par exemple un skill qui décrit quel format j'attends pour une description de pull request.
Exposer le tool pour exécuter l'action ça pourrait être via un mcp.

Pour de la doc vaste le mcp est imo intéressant car permet (je présume) de rechercher, vs un skill où tout serait ajouté au contexte.

On se voit demain aux cloud native days 😁

C'est peut être vrai parfois mais répéter ça c'est occulter le vrai problème (et donc empêche de réfléchir à la bonne solution).

Après, quand une boîte FR a un produit qui marche, il est utilisé.
Rien que Mistral par exemple on le voit en entreprise (j'utilise leur OCR en prod par exemple).
Mais faut pas se tromper de combat: un bon produit doit etre la prio, le "prenez nous car FR" ça marchera jamais.

Et dans un marché mondial, avec les concurrents étrangers qui eux n'auront aucun scrupule à prendre le meilleur produit pour accélérer, je vois pas comment c'est possible de se prendre la pénalité de faire un choix de souveraineté.

J'ai mes sites perso sur un vps OVH 😅
Le multi provider c'est ultra coûteux, donc autant prendre celui qui a tout (et est carré niveau sécurité/certifs/...) et où on sait que ça marche.
Pour la majorité des boîtes passer du temps à contourner les limitations locales c'est pas possible.

La bureautique c'est ce qui m'inquiète le moins, même les trucs comme slack etc en vrai si il fallait bouger ca bougerait.

Quand ta vision tech a 10 ans de retard, ce sera la même pour tes produits et quand tu te réveilles c'est la course pour rattraper (souvent en moins bien) mais c'est déjà trop tard, et je pense pas que ce soit la bonne stratégie vs parfois tenter d'être en avance sur le marché.

Et je rajouterai que c'est pas seulement la faute des entreprises consommatrice.
Le manque d'offre vient aussi des providers FR engluées dans de vieilles visions techniques (iaas/baremetal, 0 tooling, anti ́kube...) qui ont longtemps travaillé sur une roadmap/produits qui intéressent personne.

J'utilise proton/linux... pour le perso.
Mais pour le pro faut se rendre à l'évidence c'est juste très compliqué (notamment sur le cloud) car ́les US ont 10-15 ans d'avance sur tout.
A un moment c'est aussi une faute professionnelle de dire "allez on tue la boîte en passant chez OVH".

Qui est d'accord ?

Apres ́le risque de l'AI (que j'utilise énormément) c'est de se penser compétent dans un domaîne sans comprendre qu'on fait en fait n'importe quoi.

Yeah but always had the feeling that as a ops you undergo the consequences of the upper layer (dev) because not in the loop for architectural/technical decisions having impacts on reliability, or costs etc, even in "modern" companies (you built it you run it etc).
It's really hard to cope with this.

Platform eng is nice (I'm a strong advocate for it, built platforms etc) but it's also easy to finish into a state where "a 5 dev team is responsible for 2 services, the platform team for _everything else_,".

And without shared objectives between dev and ops we're back to silos/frustrations etc

..., recommendations usually ignored, often lower salaries (in France at least).
And the job is _way_ more difficult then dev, as you said : I did both at staff/senior staff level, back to dev atm after 3.5 years on ops side, it's a breeze of fresh air (like: I freed 80 % of my brain ram).