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.

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