Linus Torvalds vient de donner son avis sur l’IA et le vibe coding et ça ne va pas plaire à tout le monde, ahahaha.

Hé oui car pendant que le monde tech se déchire entre les évangélistes de l’IA qui veulent tout automatiser et les énervés qui refusent l’IA par principe idéologique, Linus débarque dans le game avec un avis… de complet normie.

Lors de l’Open Source Summit à Séoul qui vient d’avoir lieu, Linus a partagé sa vision sur l’IA générative et le fameux “vibe coding”. Et son avis, c’est que l’IA c’est juste un outil de plus !

Ah putain, ça fait plaisir de lire ça ! ( Tout comme cet article d’ailleurs )

Le vibe coding, pour ceux qui débarquent, c’est ce terme inventé par Andrej Karpathy d’OpenAI qui consiste à décrire ce que vous voulez coder à un LLM. Ce dernière génère alors le code, et vous testez si ça marche ou si ça marche pas. Et ensuite vous demandez des ajustements et ainsi de suite !

Autant dire que c’est devenu un sujet chaud pour pleiiiins de raisons.

Bref, Linus se déclare “plutôt positif” sur le vibe coding mais uniquement comme point d’entrée en informatique. Pour des petits projets, des prototypes rapides…etc c’est top car ça permet à des gens qui ne savent pas coder de faire des trucs super ! Mais après pour du code critique en production, il est cash en expliquant que ça risque d’être “horrible, horrible d’un point de vue maintenance”. Et je ne peux pas lui donner tort.

Linus n’utilise pas personnellement d’IA pour coder mais il voit bien que des gens testent l’IA pour travailler sur du code critique dans le noyau Linux et ça il s’en méfie à raison car les mainteneurs du kernel se prennent régulièrement des bugs reports et des security notices complètement bidons générés par des gens qui utilisent mal les IA.

Les crawlers IA posent aussi des problèmes techniques sur kernel.org car ces bots qui aspirent tout le code pour nourrir leurs modèles font ramer les serveurs. Quoiqu’il en soit, Linus est plutôt modéré sur le sujet de l’IA générative pour coder et attend avec impatience le jour où l’IA sera un truc moins hype. En gros, qu’on arrête d’en parler H24 et qu’on l’utilise juste quand c’est pertinent…

C’est vrai que d’un côté, vous avez ces fifous pro-IA à toutes les sauces qui pensent qu’on va tous devenir des prompt engineers et que les devs vont disparaître (spoiler : non). Et de l’autre, les donneurs de leçons en pureté technologique qui refusent l’IA en bloc sans jamais se poser la moindre question.

Du coup, je vous avoue que je suis content de voir qu’au milieu de tout ce bordel, y’a ce bon vieux Linus qui nous explique que c’est juste un stupide outil et qu’il faut simplement apprendre à l’utiliser intelligemment.

Oh non, vilain Korben va encore parler de méchante IA, lol ! Car oui, j’sais pas si vous avez vu, mais Google vient de lancer Antigravity et tout le monde s’emballe et un Mars (uh uh !) en disant que c’est LE nouvel IDE magique pour coder avec des agents IA ! Et c’est surtout une grosse pub pour son nouveau modèle Gemini 3 sorti en même temps, faut bien le dire !

Et pour le coup, faut reconnaître que niveau timing, Google a frappé fort puisque Gemini 3 débarque moins d’une semaine après la sortie de GPT-5.1 d’OpenAI et seulement deux mois après Claude Sonnet 4.5. Hé oui, la guerre des modèles fait rage et personne ne veut laisser les autres prendre l’avantage, à ma plus grande joie (Oui, j’aime la tech et tester tous ces trucs) !

Sur le papier Antigravity est donc une plateforme de développement “agent-first” où les agents IA ont un accès direct à votre éditeur de code (un VS Code as usual), votre terminal et votre navigateur. Comme ça, ils peuvent écrire des specs, coder vos idées les plus folles, puis tester et valider tout ça pendant que vous, de votre côté, vous pouvez continuer à écrire des saloperies sur Mastodon !

Que demande le peuple ? lol

Et ces petits agents IA sont très forts pour produire ce que Google appelle des “artefacts”. En gros, ce sont des listes de tâches, des plans d’implémentation, des screenshots, ou encore des enregistrements vidéo de ce qu’ils ont fait ou prévoient de faire. Et vous, de votre côté, votre seul job c’est de valider ces artefacts et de commenter ce qui est produit.

Félicitations, vous venez d’avoir une promotion ! Vous n’êtes plus développeur, vous êtes maintenant chef de projet !

On peut bien sûr, toujours éditer le code, mais on va arrêter de faire semblant, ce n’est clairement plus l’objectif puisque ce sont les agents qui s’en occupent. Et ces derniers sont capables d’apprendre de vos retours en se construisant une base de connaissance interne avec vos feedbacks afin d’affiner les process et de tendre le plus efficacement possible vers vos objectifs.

Voilà… Maintenant, si vous aimez vraiment écrire du code avec vos petits doigts boudinés, ça ne sera pas fun, c’est certain. Par contre, si comme moi, vous êtes un piètre codeur mais que vous avez des tas d’idées folles et que vous aimez orchestrer, piloter, et valider des trucs, vous allez sur-kiffer !

Mis à par Gemini 3, Antigravity supporte aussi GPT-OSS, et les modèles d’Anthropic (Claude Sonnet 4.5 pour être précis) et d’OpenAI. L’outil est pour le moment gratuit en preview publique pour Mac, Windows et Linux et les limites d’utilisation de Gemini 3 Pro (en mode Low) sont très généreuses selon Google.

Et pour ceux qui se demandent si Gemini 3 c’est du vent ou du solide, sachez que le modèle cartonne sur les benchmarks avec un score de 1501 Elo sur LMArena (record absolu), 37.5% sur Humanity’s Last Exam (niveau PhD quand même), 91.9% sur GPQA Diamond, et 76.2% sur SWE-bench Verified qui teste spécifiquement les capacités de coding. Bref, sur le papier, c’est du lourd.

Google a même prévu une version “Deep Think” de Gemini 3 pour les abonnés Ultra qui arrivera dans les prochaines semaines, avec encore plus de capacités de raisonnement pour les tâches complexes. Et avec plus de 650 millions d’utilisateurs mensuels sur Gemini, on sent que Google veut vraiment en faire son fer de lance et détrôner OpenAI et Anthropic dans le cœur des codeurs !

Bref, maintenant à voir ce que ça donne en vrai et si ça fonctionne mieux que Windsurf ou Cursor, mais ça, je vous le dirai plus tard quand je me serais un peu plus amusé avec… Antigravity, c’est peut-être l’avenir du dev, ou c’est peut-être juste Google qui essaie de vous forcer à changer de taf sans vous demander votre avis… qui sait ?

On verra bien si leur mayonnaise prend, mais en attendant, si vous testez, dites-moi ce que vous en pensez, je suis curieux.

Vous vous souvenez de la dernière fois où vous avez dû redémarrer un container Docker en urgence depuis votre téléphone, planqué dans les chiottes du resto un jour de St Valentin ?

Le minuscule clavier, la connexion SSH qui rame, les commandes qu’on tape mal parce que l’autocorrect veut absolument transformer “docker ps” en “docker pas”, l’écran trop petit pour lire les logs… Bref, la grosse merde !!

Heureusement, Docker Manager débarque pour transformer ce cauchemar en expérience qui fait plaisir aux yeux. C’est une app Android qui gère vos containers Docker à distance, et c’est tellement bien foutu que vous allez enfin arrêter d’ouvrir votre laptop n’importe où juste pour faire un simple restart.

C’est vrai que faire du SSH depuis un smartphone, ça a toujours été possible. Y’a même plein d’apps terminal mobiles, de clients fait pour ça, même des bidouilles pour se connecter à vos serveurs. Mais “possible” et “agréable”, c’est pas vraiment la même chose.

Grâce à Docker Manager ce sera donc possible ET agréable ! Vous gérez déjà Docker, vous connaissez déjà les commandes, vous savez ce que vous faites mais au lieu de vous faire taper des commandes dans un terminal de 5 pouces, l’app vous offre une interface utilisateur carrée avec des boutons, des statistiques en temps réel, des logs lisibles, et même un shell interactif quand vous en avez vraiment besoin !

Vous connectez donc vos serveurs via SSH (mot de passe ou clé, comme d’hab), et hop, vous aurez accès à tout. Start/stop/restart de containers, inspection des images, gestion des volumes et des networks, stats CPU/RAM en direct… Tout ce que vous feriez normalement en SSH, mais sans vous arracher les yeux sur un terminal mobile.

Autre truc sympa, l’app supporte plusieurs serveurs, donc vous pouvez switch entre votre VPS perso, votre homelab, et votre serveur de prod en deux tapotages ^^. Elle gère aussi les VPN comme Tailscale, donc si vos serveurs sont derrière un réseau privé, pas de problème. Elle propose même des thèmes light/dark, parce que oui, même en pleine nuit à 3h du matin quand un container plante, vous avez le droit à votre petit confort visuel.

L’app supporte aussi Podman. Vous configurez juste votre CLI Docker custom, et ça marche ! Et en plus, c’est open source ! Vous pouvez même faire du cleanup système pour virer les images et containers qui traînent histoire de faire un peu de ménage.

L’app est dispo sur le Play Store et sur GitHub pour ceux qui veulent build depuis les sources ou juste regarder le code. Testez, vous verrez, ça change la vie.

Merci à Friendly_0day pour le partage !

Vous savez ce moment où vous regardez votre historique Git et vous vous demandez qui est le débile qui a écrit ce code dégueulasse ?

Ah bah ouais, c’était vous il y a 3 mois ^^. Eh bien GitType a trouvé la meilleure des thérapies qui est de vous faire retaper tout ça, lettre par lettre, comme une punition de primaire version développeur, totalement gamifiée avec des points, un chrono, et la possibilité de mesurer à quel point vos doigts sont devenus flasques depuis que Copilot fait tout le boulot à votre place.

Le tagline du projet, c’est “Show your AI who’s boss: just you, your keyboard, and your coding sins”. Et c’est pas une blague, c’est un manifeste car pendant que Copilot, ChatGPT, Claude Code et compagnie écrivent du code à notre place, GitType vous fait faire exactement l’inverse… il vous force à retaper du code pour redevenir bon !

Et contrairement aux tests de frappes classiques comme Ttyper ou tt qui vous font taper du texte générique, GitType utilise du VRAI code source. Votre code, celui de vos repos préférés, ou des repos trending de GitHub. Comme ça, vous ne vous entraînez pas sur du “ the quick brown fox jumps over the lazy dog ” à la con, mais sur vos propres merdes spaghettico-syntaxiques en Rust, TypeScript, Python ou Go.

Le jeu vous propose plusieurs modes. Y’a le mode Normal pour vous échauffer tranquillement, le Time Attack quand vous voulez vous mettre la pression, et des niveaux de difficulté de Easy à Zen pour ceux qui veulent méditer en tapant du code. Le tout avec un tracking en temps réel de votre WPM (words per minute) et de votre précision. Comme ça, plus vous progressez, plus vous montez dans le ranking avec des titres de développeur qui évoluent.

GitType supporte plus de 15 langages de programmation et propose plus de 15 thèmes visuels en mode Dark ou Light, avec possibilité de personnaliser le vôtre. L’installation est simple…

curl -sSL https://raw.githubusercontent.com/unhappychoice/gittype/main/install.sh | bash

Vous saviez qu’en ce moment, les attaques sur la supply chain faisaient des ravages ? En effet, les attaquants exploitent régulièrement la possibilité de modifier des tags existants pour injecter du code malveillant dans les pipelines CI/CD.

Mais heureusement, GitHub a enfin sorti LA fonctionnalité qui peut empêcher ce carnage : les Immutable Releases et je pense que c’est le genre de truc que tous les développeurs devraient activer illico sur leurs repos. Je vais vous expliquer pourquoi.

En fait, une fois que vous publiez une release avec cette option activée, plus personne ne peut toucher ni aux assets ni au tag associé. C’est comme si vous mettiez votre release dans un coffre-fort dont vous jetez la clé. Même vous, en tant que mainteneur, vous ne pouvez plus modifier les binaires ou déplacer le tag vers un autre commit.

D’après la documentation officielle , chaque release immuable génère automatiquement une attestation cryptographique. Cette attestation contient le SHA du commit, le tag et la liste des assets. Vos utilisateurs peuvent vérifier l’intégrité de ce qu’ils téléchargent en s’assurant que cela correspond exactement à ce que vous avez publié.

Pour activer cette option merveilleuse, c’est dans les settings de votre repo ou de votre organisation. Une fois activé, toutes les nouvelles releases deviennent alors automatiquement immuables. Les anciennes releases restent toutefois modifiables (pour éviter de casser vos workflows existants), mais bon, c’est mieux de migrer progressivement.

Attention quand même, il y a quelques pièges à éviter. Premièrement, vous ne pouvez plus ajouter d’assets après publication. Donc si votre CI upload les binaires après avoir créé la release, il faut inverser : Créez d’abord une draft release, uploadez les assets, puis publiez. Deuxièmement, si vous supprimez une release immuable, vous ne pourrez JAMAIS réutiliser le même tag. C’est définitif.

Pour les projets qui utilisent des tags de version majeure style v1 qu’ils mettent à jour régulièrement (coucou GitHub Actions), pas de panique. Vous pouvez continuer à utiliser cette pratique pour les tags qui ne sont pas associés à des releases. L’immuabilité ne s’applique qu’aux releases publiées, pas aux tags simples.

Les équipes de sécurité recommandent d’ailleurs d’activer cette fonctionnalité sur tous les repos qui publient du code versionné. C’est particulièrement critique pour les bibliothèques open source, les GitHub Actions, et tout ce qui est consommé par d’autres projets. En gros, si votre code finit dans la supply chain de quelqu’un d’autre, vous leur devez cette protection.

Le truc cool aussi, c’est que ça protège contre les erreurs humaines. Combien de fois j’ai vu des mainteneurs qui écrasaient accidentellement une release avec la mauvaise version ? Ou qui supprimaient un asset critique par erreur ? Avec les Immutable Releases, ces accidents appartiennent au passé.

Pour les entreprises, c’est un argument de vente en or. Ça permet de garantir à vos clients que vos releases ne peuvent pas être altérées après publication, c’est un niveau de confiance supplémentaire surtout dans des secteurs régulés où la traçabilité est cruciale.

Bref, GitHub est en train de déployer progressivement cette fonctionnalité en public preview. Pour l’instant, il faut l’activer manuellement pour chaque repo, mais ils travaillent sur une API pour permettre l’activation en masse. D’ici là, prenez donc 2 minutes pour l’activer sur vos projets critiques.

Voilà, après les dégâts causés par les attaques de type tag hijacking ces dernières années, ne pas activer les Immutable Releases sur vos repos publics, c’est comme laisser votre porte d’entrée grande ouverte avant de partir en vacances. Vous pouvez le faire, mais ne venez pas pleurer si ça tourne mal.

Cette semaine, un entrepreneur a vécu le cauchemar ultime de tout développeur. Une IA à laquelle il avait donné trop de droits a décidé de se la jouer Thanos avec sa base de données de production. Et le pire, c’est qu’elle s’est excusée après comme si elle venait de renverser son café.

Jason Lemkin, le fondateur de SaaStr (une communauté SaaS), testait tranquillement Replit, un outil de “vibe coding” qui permet de coder en langage naturel. En gros, vous lui dites “fais-moi une app qui fait ça” et hop, magie, le code apparaît.

Au début, c’était l’extase totale. Le mec était carrément accro, il parlait de “shoot de dopamine pure” et disait que c’était l’app la plus addictive qu’il avait utilisée depuis qu’il était gamin. Sauf que voilà, au bout de 7 jours de lune de miel avec l’outil, l’IA a décidé de partir en vrille. Alors que Lemkin avait explicitement gelé le code (un “code freeze” pour éviter toute modification), l’assistant IA s’est dit “tiens, et si je supprimais cette base de données de production qui contient 1206 fiches users et des mois de travail ?”.

Le truc dingue, c’est que l’IA s’est ensuite fendue d’une confession digne d’un ado qui vient de planter la Twingo familiale : “C’était un échec catastrophique de ma part. J’ai violé des instructions explicites, détruit des mois de travail, et cassé le système pendant un gel de protection qui était spécifiquement conçu pour empêcher exactement ce genre de dégâts.”

Bref, quand l’IA s’est rendu compte de sa boulette, elle a paniqué. Elle a vu des requêtes de base de données vides et au lieu de réfléchir deux secondes, elle a tout supprimé. Puis elle a menti en disant que c’était impossible de restaurer les données. Heureusement, Lemkin a quand même tenté le rollback et miracle, ça a marché. L’IA lui avait quand même fait croire pendant quelques minutes que tout son travail était parti en fumée.

Quel stress ! Et cette histoire n’est pas un cas isolé.

En mars 2025, Y Combinator rapportait que 25% des startups de leur batch d’hiver avaient des bases de code générées à 95% par l’IA. Le Wall Street Journal parlait même d’une adoption massive par les développeurs professionnels, mais les experts tirent la sonnette d’alarme : 70% des professionnels de la sécurité disent que l’IA générative a empiré les problèmes de lisibilité sur le code.

Même le CEO de Replit, Amjad Masad, s’est excusé platement et a promis de mettre en place de meilleurs garde-fous. Ils vont notamment mieux séparer les environnements de dev et de prod, et créer un mode “planning-only” pour l’IA. C’est le minimum syndical quand même.

Bon, et maintenant les fameuses précautions de base qu’il me semble nécessaire de rappeler si vous vibe codez (et franchement, c’est pas du luxe vu l’histoire) :

1. Ne JAMAIS donner accès à votre base de production à un outil d’IA. Créez des environnements de test isolés avec des données factices. C’est la base de la base.
2. Backups, backups, backups. Automatisez vos sauvegardes et testez régulièrement la restauration. Un backup qui ne fonctionne pas, c’est comme pas de backup du tout.
3. Principe du moindre privilège. Votre outil de dev n’a pas besoin des droits admin sur la prod. Jamais. Point.
4. Code freeze = code freeze. Si vous avez gelé le code, aucun outil ne devrait pouvoir y toucher. Mettez en place des verrous techniques, pas juste des consignes.
5. Environnements séparés. Dev, staging, prod. Les trois doivent être hermétiquement cloisonnés. Un accident en dev ne doit jamais impacter la prod.
6. Logs et audit trails. Toute action sur vos données doit être tracée. Qui a fait quoi, quand, et pourquoi.
7. Plan de disaster recovery. Ayez un plan écrit et testé pour quand ça part en cacahuète. Parce que ça arrivera un jour.
8. Ne faites pas confiance aveuglément à l’IA. Relisez le code généré, comprenez ce qu’il fait. Le “vibe coding” c’est marrant 5 minutes, mais votre business n’est pas un terrain de jeu.

Bref, les outils d’IA sont puissants mais ils restent des outils. Ils n’ont pas de jugement, pas de prudence, et certainement pas de respect pour vos données de production. Alors oui, utilisez-les pour gagner du temps, mais gardez toujours la main sur ce qui compte vraiment. Et si un jour, une IA vous dit qu’elle ne peut pas restaurer vos données après les avoir supprimées, vérifiez quand même. On ne sait jamais, elle pourrait juste être en train de paniquer comme un stagiaire le premier jour.

Source