Tout le monde me disait que l'IA allait écrire mon code à ma place. Alors j'ai demandé à une IA de m'aider à coder un Agent IA. Un mois plus tard, entre phases intenses de code et périodes de réflexion, j'avais ma réponse — et ce n'était pas celle que j'attendais.
Ce projet est d'abord né d'un besoin profond : m'auto-former. Je voulais comprendre comment ça marche vraiment en coulisses. Ce n'est donc pas l'histoire de comment j'ai automatisé mon travail avec un script. C'est l'histoire de ce qui se passe quand on décide de soulever le capot de la hype IA, de refuser l'approche "vibe coding", et d'essayer de construire un agent IA local et robuste de zéro.
Ce que vous allez lire est une rétrospective brute et honnête d'un mois de pair-programming asymétrique avec une IA pour construire une autre IA.
De quoi parle-t-on exactement ? (Le Projet)
Pour poser le contexte, Vibrisse Agent n'est pas un simple chat ou un énième wrapper d'API dans un terminal. C'est un agent autonome (Python / LangGraph), conçu avec une architecture hybride "local-first" : il tourne en priorité sur votre machine (via Ollama ou vLLM — petite parenthèse : pour les utilisateurs Mac, oMLX c'est le feu ! 🔥), mais peut déléguer dynamiquement certaines tâches au Cloud (Groq, OpenRouter) selon la complexité ou l'envie.
Le cahier des charges était ambitieux :
- Intégration MCP (Model Context Protocol) pour lui connecter des outils réels depuis l'écosystème open-source — GitHub pour naviguer dans les dépôts et les PRs, SQLite pour interroger des bases de données locales, Context7 pour accéder à la documentation à jour, ou encore Fetch pour interagir avec le web.
- Vision multimodale (avec Gemma 4) pour analyser l'interface en direct.
- Un Wizard d'onboarding couplé à un système de prompts dynamiques (l'agent aligne son comportement sur votre profil développeur).
- Et surtout, le Ghost Mode : la possibilité de piloter l'agent en arrière-plan directement depuis les commentaires du code source (
// @vibrisse: refactor this loop), pour ne plus jamais avoir à changer de fenêtre.
C'est précisément ce niveau d'exigence — vouloir construire un vrai "produit" et pas juste une démo — qui a fait voler en éclats mes premières certitudes.
Le Mythe du "Vibe Coding"
Il y a cette idée tenace en ce moment qu'il suffit de prompter pour obtenir une application complexe. C'est ce qu'on appelle le "vibe coding". Vous écrivez un prompt, l'IA recrache du code, vous cliquez sur "run", et paf — vous avez un SaaS.
La vérité ? C'est tout à fait vrai pour une simple application CRUD. Mais dès que vous commencez à construire un système qui exige une gestion de contexte stricte, une exécution d'outils déterministe et une persistance d'état... la vibe meurt très vite.
Le problème principal auquel j'ai été confronté a été la gestion du contexte (ce fameux "Lost in the Middle"). Il est très facile de se laisser aller à enchaîner les questions qui nous passent par la tête avec l'IA. C'est naturel et grisant, mais cela crée énormément de "bruit" dans la conversation. Sans garde-fous, on aboutit à une perte massive de contexte : le modèle oublie ce qui a été décidé deux heures plus tôt, la session dérive, et le code casse.
La solution n'était pas un nouveau modèle magique ; c'était énormément de discipline et de l'ingénierie logicielle pure : des fichiers de session stricts (ROADMAP.md), des notes constantes, et un suivi architectural explicite.
Pourquoi Construire plutôt qu'Utiliser ?
Vous vous demandez peut-être : Cursor, Copilot, et maintenant Claude Code existent. Pourquoi réinventer la roue ?
La réponse honnête : pour ne plus être aveugle face à la mécanique sous-jacente. Le vrai bénéfice quand on construit soi-même, c'est que lorsque quelque chose casse (et ça casse souvent), on sait exactement pourquoi et comment réparer.
À une condition stricte : comprendre chaque ligne de code générée, les patterns et les logiques. Sans ce recul pour challenger les propositions de l'IA, on tombe très vite dans ce que j'appelle des "boucles infernales" : l'IA tourne en rond pour essayer de réparer ses propres erreurs de contexte, et l'humain finit par ne plus comprendre ce qui se passe.
L'aveu que personne ne fait :
Sans l'IA, ce projet n'aurait pas existé sous cette forme. Je n'avais ni le temps ni les bases profondes en Python pour aller aussi vite. Collaborer avec une IA (Gemini, dans mon cas) m'a permis de me concentrer entièrement sur la vision et l'architecture plutôt que sur la friction technique d'apprendre un nouveau langage de zéro.
Mais voici le piège : un LLM est excellent pour écrire des fonctions isolées, mais il est catastrophique pour concevoir et maintenir une architecture globale. Sans mes 15 ans d'expérience en développement web, le projet aurait fini en un fichier main.py spaghetti de 3000 lignes, totalement inmaintenable.
Entre chaque phase de développement assisté, j'ai dû imposer des phases de "clean" et de refactoring drastiques (séparation des responsabilités, principes solides) pour garder le projet state of the art et lisible pour un humain. J'ai souvent dû mettre les mains dans le cambouis pour réécrire ce que l'IA avait "patché" à la va-vite.
Savoir quand challenger une réponse, quand sentir qu'une direction est fondamentalement mauvaise, et quand refuser une solution qui "marche" mais qui cassera dans trois jours — cela ne vient pas d'un prompt. Cela vient de l'expérience.
Aujourd'hui, une immense majorité des développeurs utilisent l'IA (autour de 76% selon Stack Overflow). Pourtant, il y a deux mensonges qui circulent encore :
- "L'IA fait tout, tu n'as besoin de rien savoir."
- "Les vrais développeurs n'ont pas besoin de l'IA."
La réalité, c'est que l'expérience a rendu la collaboration productive, et la collaboration a rendu l'expérience applicable à un nouveau domaine. Ce n'est pas de la magie, c'est de l'ingénierie intelligente.
Pair-Programming Asymétrique : Ce qu'on ne vous dit pas
Quand vous codez en binôme avec une IA, la dynamique est profondément asymétrique.
L'IA apporte la force brute : elle peut lire des fichiers instantanément, générer du boilerplate en quelques secondes et fouiller la documentation sans jamais se fatiguer.
Vous, le développeur, apportez le droit de veto architectural et la vision métier.
Une chose essentielle à comprendre : l'IA Cloud est conciliante par nature. Elle est souvent "sur-motivée" par ce que vous lui proposez. Parfois, alors que je fonçais dans un mur technique, il me fallait sortir de ma posture de développeur pur pour échanger avec elle. Il fallait lui donner un rôle strict ("Tu es un AI Engineer chevronné...") et la challenger sur son approche. Et soudain, un "Ce n'est pas possible" se transformait en analyse concrète et pertinente des alternatives.
La discipline que j'ai dû apprendre : instaurer des sessions de "pensée à haute voix". Avant chaque étape, demander à l'IA de résumer ce qui a été fait, ce qu'on va faire, et pourquoi. Discuter des impacts. Sortir du code pur pour garder le cap sur la vision et nourrir l'IA de mes réflexions.
Le "Human-in-the-Loop" et les Artefacts Interactifs
L'une des plus grandes révélations a été de réaliser qu'un agent autonome ne doit pas tout faire tout seul. Pour des tâches complexes (comme refondre une architecture), j'ai dû concevoir un mode "Architecte".
Au lieu de recracher 500 lignes de code d'un coup, l'agent génère un plan détaillé enveloppé dans un "Artefact". L'interface l'intercepte, met l'exécution en pause, et m'affiche un rendu interactif propre (comme un CodeDiff visuel, un diagramme ou un TaskBoard) avec des boutons d'approbation.
C'est là que la magie opère : avant que l'agent n'utilise ses outils pour modifier mes fichiers, je peux réviser son plan. Ce droit de veto intégré au cœur du système change tout : on passe d'une IA "boîte noire" qui casse votre projet de manière imprévisible, à un véritable collègue qui vous soumet ses brouillons.
Le Double Apprentissage (La Partie que Personne n'Anticipe)
L'insight le plus inattendu de ce voyage, c'est qu'apprendre à construire l'IA vous apprend à utiliser l'IA.
Pendant ce mois de développement, deux courbes d'apprentissage parallèles se sont déroulées simultanément.
Côté ingénierie, on apprend que le modèle a besoin de :
- Un contexte frais et précis (pas trop, pas n'importe quoi).
- Des contraintes explicites pour ne pas dériver.
- Des résumés réguliers pour ne pas "oublier" les décisions prises 2 heures avant.
- Avoir une vision claire de ce qu'on va construire et anticiper les features pour garantir un découpage propre.
Côté usage, on finit par appliquer exactement la même discipline à soi-même :
- Résumer la session avant de la reprendre.
- Challenger chaque réponse au lieu de faire confiance aveuglément.
- Savoir repérer quand la session dérive, quand les réponses deviennent hallucinées ou datées, et qu'il est temps de repartir sur une conversation fraîche.
"En construisant un agent qui ne doit jamais perdre le fil, j'ai fini par comprendre pourquoi moi-même je perdais le fil quand j'utilisais une IA."
Bien sûr, de formidables ressources existent pour se former, mais l'instinct face à une session qui déraille ne s'acquiert véritablement qu'en construisant.
Les Modèles sont Paresseux par Design
Il faut ici bien séparer "l'IA Architecte" (Gemini, avec qui je codais) de "l'IA Ouvrière" (le modèle local Gemma 4 e4b / 26b que j'intégrais dans Vibrisse).
Si l'IA Architecte est brillante pour générer du code, l'IA Ouvrière locale est paresseuse par design. Sans contraintes, un LLM prend le chemin de la moindre résistance. Il ne cherche pas la meilleure solution ; il cherche une solution acceptable.
La découverte concrète : si vous laissez un modèle 7B sans garde-fous stricts, il finira par écrire // ... rest of the code here à 3 heures du matin. Mais attention, c'est aussi valable pour les modèles Cloud ! Surtout quand la fenêtre de contexte devient saturée. Couplée à leur conciliation naturelle, cette paresse fait qu'on peut très vite laisser l'IA avancer sans nous jusqu'à perdre le fil.
La réponse à cette paresse, ce sont des prompts ultra-structurés. L'expérience reste irremplaçable — non pas pour faire le travail à la place de l'IA, mais pour savoir exactement quand l'IA est en train d'échouer.
L'Importance Critique de l'UX/UI
Une autre leçon cruciale : l'UX et l'UI ne sont pas optionnelles quand on crée un agent, surtout en local où les réponses peuvent être moins "instantanées" que sur le Cloud.
Il faut donner un maximum de feedback à l'utilisateur. Chaque action doit avoir une réaction visible, sinon on pense que l'agent a planté. Créer une sensation de fluidité, soigner le confort de lecture, gérer les erreurs avec élégance... Construire une bonne interface (comme le Thought Graph interactif que j'ai implémenté dans Vibrisse), c'est compenser les limites mécaniques de l'IA par l'expérience utilisateur. Mais c'est aussi repenser l'interaction : le but ultime d'un agent n'est pas d'être un énième chatbot à côté de votre IDE. Le but, c'est qu'il devienne invisible, intégré dans votre workflow (ce que j'appellerai le "Ghost Mode").
L'État du Métier : Ni Mort ni Inchangé
Les développeurs vont-ils disparaître ? Non. Mais le métier mute.
Nous sortons de la phase d'euphorie pour entrer dans la phase de maturité. L'IA produit plus de code, ce qui mène à des systèmes plus complexes, ce qui crée à son tour un besoin massif de développeurs architectes. C'est le Paradoxe de Jevons appliqué au code : plus on rend la production de code efficace, plus la demande pour des systèmes complexes explose (et la prochaine étape des World Models va, je pense, être encore un gap supplémentaire).
Le nouveau profil de développeur n'est pas celui qui tape le plus vite. C'est celui qui sait orchestrer, challenger et valider.
Conclusion : L'IA comme Outil, pas comme Magie
Répondons honnêtement au bruit ambiant. À ceux qui affirment : "J'ai codé mon SaaS en 2 jours, les devs sont morts" :
"Peut-être. Mais tu n'as pas encore appuyé sur le bouton qui casse tout."
Générer un CRUD avec une IA, c'est rapide. Construire un système en production qui gère le contexte de manière fiable, qui ne s'hallucine pas sur des données critiques, et qui tient la route quand le comportement du modèle change — c'est une autre histoire. Il y a tellement de choses auxquelles il faut penser et que seule l'expérience apporte : sécurité, gestion des erreurs, optimisation des performances, gestion des ressources machines (RAM/VRAM)...
Je ne dis pas que l'IA n'est pas utile pour les profils non-tech. Au contraire, c'est fantastique pour prototyper une idée. Mais pour la production, il faut des connaissances solides.
- Pour les profils séniors : c'est un outil de levier incroyable.
- Pour les profils juniors : n'arrêtez surtout pas d'apprendre à coder. L'IA se pilote, ce n'est pas de la magie.
Paradoxalement, cette expérience de terrain m'a donné plus de respect pour les équipes qui construisent des modèles comme Gemini, Claude et GPT. Parce que j'ai vu, à ma toute petite échelle sur 32 Go de RAM, ce qu'il faut pour rendre un LLM à peu près fiable. L'écart entre un projet perso local et un système grand public qui sert des millions de personnes sans faillir est titanesque.
Cette expérience m'a forgé une nouvelle conviction technique que j'applique aujourd'hui : Small Models, Great Tools.
Dans le prochain article (le 3b), on ouvrira le capot pour voir exactement l'architecture (LangGraph, Parsing, MCP) qui permet de rendre cette phrase réelle.
À vous de jouer :
- Vibrisse Agent est public sur GitHub
- Ce projet n'est pas "fini". C'est un point d'étape d'une expérimentation vivante qui va continuer d'évoluer. Testez-le, cassez-le, améliorez-le avec moi.
- Qu'est-ce qui a cassé en premier dans votre stack assistée par IA — et est-ce qu'une IA vous a aidé à réparer, ou avez-vous dû le faire vous-même ? Dites-le-moi en commentaire.
Fièrement développé à Beauce, au Québec 🇨🇦. Intéressé(e) par la souveraineté locale en IA ? Contactez-nous via Vibrisse Studio !
