SĂ©rie d'articles :
👉 Partie 1 : Ma traversée du désert (Du Terminal au GPU)
👉 Partie 2 : Souveraineté, RAG artisanal et l'éveil des Agents (Vous êtes ici)
👉 Partie 3 : Vibrisse Agent, autopsie d'un Cockpit sur mesure (À venir)
Disclaimer & Contexte : Tout comme dans le premier opus, cet article repose sur mon utilisation quotidienne avec un MacBook Pro M1 Pro (32 Go de RAM) et VS Code. L'objectif ici est d'explorer la transition technique et méthodologique entre l'usage d'un simple modèle conversationnel et un véritable écosystème agentique souverain.
Dans mon précédent article, je vous racontais ma réconciliation matérielle avec l'IA locale grâce aux optimisations récentes et à la quantification. Mais une fois que le moteur tourne en local, on fait quoi exactement ? On se contente de discuter ?
Au début, on passe tous par l'approche "naïve" : on installe Ollama ou LM Studio, on télécharge un modèle, et on l'utilise de manière brute dans un terminal ou une interface de chat classique. C'est fascinant les premières heures, mais on se heurte très vite à un plafond de verre. Un LLM utilisé brut reste un oracle passif : il répond à des questions isolées, mais il n'a ni mémoire persistante, ni esprit d'initiative, ni leviers d'action sur votre environnement de travail.
Puis, à force de recherche et documentation, j'ai eu un déclic. Au-delà de la performance pure, c'est avant tout une question de souveraineté numérique. Entre les scandales de télémétrie et les dépôts privés qui risquent d'alimenter discrètement l'entraînement des modèles Cloud, j'ai voulu construire mon propre "cerveau" de développement, entièrement sécurisé, sans jamais donner les clés de mon Mac à une entité distante.
C'est précisément là que j'ai commencé à décortiquer la mécanique des Agents.
1. De l'assistant au Sidekick : La découverte d'Hermes Agent
Ma réflexion a d'abord mûri en observant de loin le buzz grandissant autour d'outils autonomes comme OpenClaw. L'idée d'un assistant capable d'agir sur mon système me séduisait, mais je gardais une méfiance légitime à l'idée de confier un accès total à mon terminal et à ma propriété intellectuelle à l'écosystème d'un géant du Cloud.
Pourtant, à force de documenter mes workflows, une évidence s'est imposée : piloter un LLM via un agent devient vite indispensable pour automatiser les tâches complexes.
En cherchant une alternative open source et respectueuse de la vie privée, je suis tombé sur Hermes Agent, conçu par l'excellente équipe de Nous Research. La promesse ? Un architecture orientée "agentique" et optimisée pour l'appel d'outils (Tool Use). Contrairement à un simple Chat qui se contente de prédire le mot suivant, un agent dote le modèle d'une boucle de raisonnement lui permettant de définir une stratégie et de décomposer ses objectifs.
Pour propulser ce setup en local, j'ai misé sur le combo incontournable du moment : Gemma 4. Vivement recommandé par Nous Research pour faire tourner Hermes, ce modèle brille par son respect scrupuleux des instructions complexes et sa précision sur les formats de sortie structurés.
2. La hiérarchie cognitive : Gérer ses 32 Go de RAM sans exploser
L'erreur classique quand on débute en IA locale ? Vouloir un seul modèle géant pour tout faire. Comme évoqué en conclusion de mon premier article, charger un modèle lourd en continu aux côtés de macOS, VS Code et Chrome mène tout droit à la saturation de la mémoire unifiée et au swap intensif sur le SSD.
J'ai donc mis en place une stricte hiérarchie cognitive en séparant l'intellect de l'exécution pour préserver la réactivité de mon M1 Pro :
- Le matin (Deep Work) : Gemma 4 26B. C'est mon "Directeur Technique" (CTO). Il occupe environ 20 Go de RAM et je ne l'invoque que sur des sessions dédiées à la réflexion pure. Il excelle sur les tâches à très haute densité : audits approfondis d'architecture, revues de conception et planification complexe.
- La journée en continu (Sidekick) : Gemma 4 e4b. Une version légère, vive et tout-terrain qui reste en tâche de fond pour les opérations ancillaires : rédaction de documentation, génération de tests unitaires ou formatage de notes Obsidian. Il m'accompagne en permanence sans ralentir mon IDE ni faire chauffer la machine.
3. Le nerf de la guerre : Le RAG (et pourquoi le mien est artisanal)
Avoir un agent local compétent est une excellente base, mais sans contexte frais, un LLM finit inévitablement par halluciner des noms de variables ou des signatures d'API obsolètes. C'est là qu'intervient le RAG (Retrieval-Augmented Generation).
Cependant, les solutions RAG "clés en main" du marché se comportent souvent comme des boîtes noires. Qu'il s'agisse de chaînes d'abstraction trop opaques (comme dans LangChain) ou d'outils No-code où l'on perd la main sur le découpage du texte, ces solutions vectorisent souvent aveuglément votre base de code. Résultat : on finit par diluer l'attention du modèle avec du bruit technique non pertinent.
J'ai donc opté pour un RAG Artisanal (Hand-crafted Context). Ma méthodologie est chirurgicale :
- Je demande à mon Sidekick de scanner les dépendances d'un projet pour générer une première fiche d'identité brute (
CONTEXT.md). - Je repasse ensuite manuellement sur ce fichier pour y graver mes "vérités métier", mes conventions architecturales et mes choix de design.
# ID: Vibrisse Studio
# TYPE: Static / Immersive
# STACK: React 19, Vite, Three.js (R3F), GSAP, Tailwind CSS 3, Sass
# PERF_SCORE: High
## CONTEXTE TECHNIQUE
Site vitrine immersif utilisant une stack moderne centrée sur l'expérience visuelle.
Le rendu 3D est géré par Three.js via React Three Fiber.
Les animations et le séquençage sont orchestrés par GSAP.
## ATTENTION (CRITICAL)
- Mix complexe R3F + GSAP : synchronisation fine des cycles de vie requise.
- React 19 : surveiller la stabilité des hooks Three.js.
- Conflits potentiels Tailwind / Sass sur la spécificité des sélecteurs.
En nourrissant le prompt système du modèle 26B avec ces fiches ultra-denses, le résultat est sans appel : l'IA ne devine plus, elle sait. J'ai compris l'importance capitale de la densité de tokens utiles. Mon agent connaît désormais mes stacks et mes habitudes de dev, ce qui permet d'automatiser une veille ciblée, de surveiller les montées de versions critiques ou d'initialiser de nouveaux projets en appliquant directement mes patterns de prédilection.
💡 Note de veille : C'est d'ailleurs cette même philosophie de pureté et de portabilité du contexte développeur que l'on retrouve au cœur d'initiatives très inspirantes comme Context 7.
4. Qu'est-ce qu'un "Agent" au fond ? (Tools & Reasoning)
En expérimentant avec Hermes, j'ai saisi la différence fondamentale entre le Savoir (encodé dans les poids du LLM) et l'Orchestration (gérée par l'agent qui dispatche les actions). Deux concepts majeurs transforment le modèle en acteur autonome :
- Le Tool Use (Appel d'outils) : L'agent peut décider de formater sa réponse pour déclencher une fonction réelle (lire un fichier, chercher sur le web, exécuter une commande bash). C'est le passage de la parole à l'acte.
- Le CoT (Chain of Thought) : L'agent "pense tout haut" en décomposant son raisonnement selon le cycle Observation > Pensée > Action. Il est absolument fascinant de voir son IA locale écrire dans sa console : "Observation : il me manque des informations sur ce bug. Pensée : je dois vérifier les scripts d'initialisation. Action : appel de l'outil de lecture sur le fichier
package.json".
💡 Conseil de pro (L'impact des hyperparamètres) : Pour qu'un agent fonctionne de manière fiable, il faut impérativement brider la créativité du LLM. Réglez la température au plus bas (
0.0ou0.1). Un agent a besoin d'un déterminisme absolu pour émettre des appels d'outils au format JSON ou XML syntaxiquement parfaits, sous peine de faire crasher le parseur.
5. Le workflow hybride : Research > Plan > Implement
Inspiré par les méthodologies de figures de l'écosystème comme Mckay Wrigley, j'ai restructuré mon cycle de développement autour d'un flux hybride en trois temps :
- Research & Plan (Local & Privé) : L'intelligence et la confidentialité absolue. C'est ici que j'utilise mes modèles locaux pour concevoir l'architecture et affiner ma stratégie. Mes idées et ma propriété intellectuelle restent strictement confinées sur mon SSD.
- Implement (Cloud) : Une fois le plan d'action validé et rigoureusement structuré en local, je délègue la génération de code de masse aux API Cloud. C'est un compromis redoutable : j'économise les ressources de ma machine et je consomme mes tokens payants de manière purement utilitaire.
5 bis. Le miroir de la réalité : Agent Local vs IA Cloud (Claude, Gemini et compagnie)
Soyons totalement transparents : si vous avez l'habitude de travailler au quotidien avec des écosystèmes de pointe comme Claude Sonnet ou Gemini propulsé dans un environnement agentique avancé (comme Antigravity), le retour sur un modèle local de 4B ou 26B demande d'ajuster ses attentes.
La ligne de démarcation est très claire :
- Profondeur & Multitâche massive (L'avantage Cloud) : Des solutions comme Antigravity ou Claude Code se comportent comme des Architectes Seniors omniscients. Ils excellent dans le refactoring multi-fichiers massif, la lecture implicite de vos intentions les plus vagues et la vélocité de production pure. Leur fenêtre de contexte géante absorbe des architectures entières sans broncher. Pour donner un ordre d'idée (comme illustré dans une excellente vidéo d'IBM Technology), leur mémoire immédiate est capable d'encaisser l'intégralité des trois livres du Seigneur des Anneaux plus Le Hobbit, en gardant encore de la place libre pour votre code ! Un gouffre technique inatteignable pour une machine locale grand public.
- L'ingestion automatisée de contexte (Comment le Cloud lit notre système) : L'illusion de "magie" d'un agent Cloud repose sur ses mécanismes d'exploration active. Lorsqu'on lui confie une tâche, il interroge dynamiquement notre espace de travail local via des outils d'investigation chirurgicale (Grep search, listage d'arborescence, lecture ciblée d'AST ou de fichiers). Il cartographie instantanément les dépendances et injecte de manière autonome les blocs pertinents dans sa fenêtre de contexte (souvent de plusieurs millions de tokens). C'est cette capacité à aspirer et synthétiser un workspace entier en une fraction de seconde qui lui confère son omniscience, mais cela implique d'ouvrir les vannes et d'autoriser l'envoi de ces instantanés locaux vers une API distante.
- Souveraineté & Précision Métier (L'avantage Local) : Face à cette aspiration de données, l'agent local est votre Garde du Corps. Il brille par son intimité absolue avec vos patterns via le RAG artisanal. Vous possédez 100% de la donnée. Là où le Cloud facture chaque token lu et ingère vos invites sur des serveurs tiers, l'agent local itère en boucle fermée, sans friction de facturation, pour valider et protéger la logique intime de votre propriété intellectuelle.
C'est précisément cette complémentarité qui valide le workflow hybride : on ne demande pas à un agent local de réécrire 50 fichiers d'un coup (le Cloud le fait infiniment mieux et plus vite). On lui demande de garantir l'alignement, la sécurité et l'identité de notre code avant de déléguer l'exécution de masse.
6. Prompt Engineering : L'art de la précision chirurgicale
Piloter un agent local exige d'abandonner les prompts vagues ou implicites. Les modèles Cloud grand public sont entraînés pour lisser vos approximations et deviner vos intentions. Face à un agent local qui doit choisir le bon outil de manière autonome, le flou artistique ne pardonne pas.
Il faut redevenir un véritable artisan du prompt : concis, explicite et hautement structuré. Chaque contrainte doit être formulée clairement et le rôle du modèle strictement délimité. Plus votre prompt gagne en précision chirurgicale, plus votre agent gagne en fiabilité.
Mais ne vous y trompez pas : cette rigueur est tout aussi payante sur le Cloud. Si les modèles géants (Claude, GPT-4, Gemini) encaissent mieux le "bruit", un prompt d'une précision chirurgicale est la clé de la réponse parfaite dès le premier jet. Plutôt que d'itérer quatre fois pour corriger une erreur de syntaxe ou un oubli, un prompt parfaitement architecturé permet d'obtenir le résultat parfait dès la première seconde. C'est là que l'on passe de l'utilisateur de chat au véritable ingénieur de commandes : on ne discute plus, on pilote une intention.
# ROLE
Tu es un Senior Creative Developer spécialisé en React 19 et WebGL (R3F).
# OBJECTIF
Génère un composant React réutilisable nommé `FluidPortal.jsx` qui affiche une sphère 3D animée servant d'élément de transition visuelle.
# STACK TECHNIQUE
- React 19 (Hooks standard)
- @react-three/fiber + @react-three/drei
- GSAP 3.12 (pour les transitions d'Ă©tat)
- Tailwind CSS (pour le stylage des conteneurs)
# CONTRAINTES DE DESIGN
1. La sphère doit utiliser un `MeshDistortMaterial` avec une couleur violette profonde.
2. Au survol (Hover) : Augmenter la distorsion et la vitesse de l'onde via un tween GSAP fluide (durée : 0.4s).
3. Au clic : Déclencher une animation d'expansion (scale) qui remplit tout le conteneur avant d'exécuter une fonction callback `onAction`.
# EXIGENCES DE CODE
- Utilisation de `useFrame` pour la rotation continue sur l'axe Y.
- Gestion propre du curseur (`cursor-pointer`) via les événements Three.js.
- Code complet, auto-porteur, sans placeholders.
# OUTPUT FORMAT
Retourne uniquement le code du composant avec des commentaires JSDoc.
Conclusion : Le mur de la friction (et le syndrome du "Pourquoi pas moi ?")
Ce setup hybride et souverain est incroyable, mais il a un coût au quotidien : la friction. Maintenir mon RAG artisanal à la main finit par être lent. L'interface brute d'Hermes Agent frustre mon exigence de designer. Enfin, basculer mentalement d'un modèle à l'autre demande une attention constante pour éviter de déclencher un swap mémoire au pire moment.
Mais par-dessus tout, en tant que développeur, j'ai ce besoin viscéral de comprendre comment les choses fonctionnent sous le capot.
Lire des articles sur les agents autonomes, c'est bien. Utiliser les solutions des autres, c'est instructif. Mais la curiosité technique a fini par prendre le dessus, m'amenant à me poser cette question un peu folle :
"Et si je construisais mon propre Agent, de A à Z ? Juste pour voir si je peux le faire, et surtout pour comprendre comment les rouages s'emboîtent vraiment."
Ce qui ne devait être qu'un "test fou" pour décortiquer LangGraph et les bases vectorielles est devenu bien plus que ça. J'ai fini par concevoir et coder mon propre Cockpit agentique sur mesure, doté d'une interface graphique soignée, pour répondre à l'intégralité de mes frustrations.
On en reparle en détail dans la Partie 3 : le projet s'appelle Vibrisse Agent, et je vais vous montrer les entrailles de la bête.
đź“ş Pour les curieux :
Si la mécanique interne des agents vous passionne, je vous conseille vivement l'excellente chaîne YouTube d'IBM Technology. Pour ceux qui veulent voir où se dessine le futur des agents professionnels, je vous recommande vivement d'explorer IBM BOB et l'assistant Jules de Google. Ce sont de véritables références pour apprendre à sélectionner et orchestrer les outils les plus performants au sein de vos propres workflows.
Je vous recommande également cette superbe vidéo d'analyse technique de The Coding Sloth.
Fièrement développé en Beauce, au Québec 🇨🇦. La souveraineté locale en matière d'IA vous intéresse ? Connectons-nous !
Top comments (0)