Du terminal au vibe-coding

Sys, réseau, cybersécurité

J’ai commencé par là. Des terminaux, des configs, des pare-feux, du monitoring, de l’analyse de vulnérabilités. Le genre de boulot où une erreur de frappe dans un fichier de conf peut couper un réseau entier.

J’ai adoré ça. Vraiment. Comprendre comment les systèmes communiquent, comment les sécuriser, comment les casser pour mieux les protéger — ça m’a donné une chose qui ne s’apprend pas dans un tuto YouTube : la logique.

Pas la logique théorique des cours d’algo. La logique pratique. Celle qui fait que quand un truc ne marche pas, tu sais où chercher et comment raisonner pour trouver.

L’entrepreneuriat, les échecs

À un moment, j’ai voulu faire autre chose avec cette base technique. Monter des projets. Lancer des boîtes.

Ça n’a pas marché. Plusieurs tentatives, plusieurs échecs. Le genre de période où tu apprends énormément mais où ton compte en banque ne suit pas le rythme de tes ambitions.

Ces échecs m’ont appris un truc essentiel : la technique ne suffit pas. Avoir les compétences pour construire un produit ne garantit en rien de savoir le vendre, le positionner, ou même de choisir le bon problème à résoudre.

Le no-code : une vraie révolution

Après ces tentatives, je me suis mis au no-code en freelance. Bubble.io, Webflow, n8n, Airtable, Notion, Zapier, Xano — l’arsenal complet.

Et c’était une révolution. Sincèrement.

Pouvoir construire une app fonctionnelle sans écrire une ligne de code, la livrer à un client en quelques jours, itérer en temps réel — pour quelqu’un qui venait du monde des terminaux, c’était libérateur. Le no-code a rendu accessible ce qui demandait avant des mois de développement et une équipe complète.

Mais le no-code a ses limites. Des limites frustrantes quand tu as une vision précise de ce que tu veux construire. Les plateformes t’enferment dans leurs logiques. Tu te retrouves à contourner des limitations au lieu de résoudre ton vrai problème. Et dès que tu sors du cas d’usage prévu, tu tapes un mur.

Le no-code, c’est extraordinaire pour aller vite sur du standard. Dès que tu veux du sur-mesure, ça coince.

Le vibe-coding : la suite logique

Et puis l’IA est arrivée. Pas les chatbots gadgets. Les vrais modèles capables de comprendre ce que tu veux construire et de le coder.

Le vibe-coding, c’est exactement la suite du no-code — sans les murs. Tu décris ce que tu veux, l’IA construit, tu ajustes. Sauf que cette fois, le résultat est du vrai code. Pas une plateforme propriétaire. Pas un vendor lock-in. Du code que tu possèdes, que tu peux modifier, déployer où tu veux.

J’ai commencé avec Bolt.new. L’outil parfait pour se lancer : tu décris ton app, il génère le code, tu itères directement dans le navigateur. Avec Bolt Cloud, tu n’as même pas à te soucier de la base de données, de l’hébergement ou du déploiement — tout est géré. Pour quelqu’un qui vient du no-code, c’est la transition idéale : même simplicité d’usage, mais du vrai code en sortie.

Les limites arrivent quand les projets grossissent. Le contexte de l’agent est limité, tu perds en contrôle sur l’architecture, et tu restes dépendant de leur plateforme pour l’exécution. Pour un MVP ou un prototype rapide, c’est imbattable. Pour un projet que tu veux faire évoluer sur la durée, ça montre ses limites.

C’est là que je suis passé à Claude Code. L’approche est radicalement différente : pas d’interface web, pas de cloud intégré. C’est un agent IA directement dans ton terminal, qui travaille sur tes fichiers, dans ton environnement, avec ton stack. Tu gères ton propre hébergement, ta propre base de données, ton propre Git — mais en échange, tu as un contrôle total. L’agent comprend l’intégralité de ton projet, respecte ton architecture, et tu peux le guider avec une précision chirurgicale.

Le compromis est clair : Bolt.new te fait gagner du temps sur tout ce qui entoure le code. Claude Code te fait gagner en qualité sur le code lui-même. Et avec un passé en sys/réseau/cybersécurité, le fait de devoir gérer l’infra soi-même n’est pas un inconvénient — c’est un retour en terrain connu. J’ai commencé par l’un, je travaille aujourd’hui avec l’autre. Je ferai un article dédié à mon setup et mon workflow de travail.

Et c’est là que mon parcours sys/réseau/cybersécurité prend tout son sens. La logique que j’ai construite pendant des années à debugger des infrastructures, c’est exactement ce qu’il faut pour piloter un agent IA. Savoir décomposer un problème, formuler une demande précise, identifier quand l’IA part dans la mauvaise direction — ça ne s’improvise pas.

Je ne code pas. Mais je sais exactement ce que je veux, et je sais comment l’obtenir.

Ce que l’IA ne fait pas (encore)

J’ai voulu pousser l’expérience plus loin. Tester ce qui se passe quand tu laisses une IA développer en continu, en autonomie totale.

J’ai utilisé OpenClaw avec plusieurs modèles — Anthropic, OpenAI, QWen. L’idée : configurer un agent pour qu’il développe seul, feature après feature, sans intervention humaine constante.

Le résultat ? Décevant.

Pas parce que les modèles sont mauvais — ils sont impressionnants. Mais parce que sans un humain pour tenir la barre, tout dérive. L’architecture se dégrade commit après commit. Les hallucinations s’accumulent. L’agent prend des décisions qui semblent logiques localement mais qui sabotent la cohérence globale du projet.

En quelques heures de développement autonome, tu te retrouves avec une base de code que même l’IA ne comprend plus vraiment.

L’amplificateur, pas le remplaçant

C’est la leçon que je retiens de tout ce parcours.

L’IA est un amplificateur brutal. Si tu sais ce que tu veux, si tu as la logique pour décomposer tes besoins et la discipline pour garder le cap, tu peux construire des choses que tu n’aurais jamais pu faire seul. Plus vite, plus propre, plus ambitieux.

Mais l’IA ne remplace pas la décision humaine. Elle ne remplace pas la vision produit. Elle ne sait pas pourquoi tu construis ce que tu construis, ni pour qui.

Ceux qui annoncent que l’IA va remplacer les développeurs passent à côté du sujet. Le vrai changement, c’est que la valeur se déplace. Elle n’est plus dans la capacité à écrire du code. Elle est dans la capacité à décider quoi construire, comment le penser, et comment le piloter.

Le terminal, le no-code, le vibe-coding — trois étapes, une même constante : c’est toujours l’humain qui décide.