Journal Ma découverte de l'IA, et de sa mise en exploitation personnelle.

Sommaire

• • Mon profil
  • Premier essai : Ollama sous Ubuntu
  • Le matériel
  • Le sous-produit : un workflow avec Claude
  • Deuxième essai : llama.cpp, Debian, et un patch
  • Ce que je cherchais à savoir
  • Trois mois plus tard
  • Pourquoi Claude a écrit un harness custom
    • Mes principes :
    • La parcimonie
  • Première mise au travail
  • L'écueil : aucune convention de projet
  • La méthode : liveusb, SSH, et YOLO
  • Parenthèse : plan, budget, handoff
  • Un détour plus funky : le mediacenter
  • Ce qui a coincé
  • Pourquoi le mode YOLO ne m'empêche pas de dormir
  • Intermède : une fuite de watercooling
  • Où j'en suis

Salutations à tous.
Ma présence en ces lieux a pour objet de partager mon expérience dans le montage d'un setup local d'inférence sur du matériel de récupération, tout juste suffisant pour que le résultat soit utilisable (ça je ne le savais pas au départ).

Mon profil

sysadmin Microsoft depuis 25 ans, la dernière fois que j'ai mis les mains dans le monde Unix c'était sur des terminaux X sur serveurs Solaris et tout le monde avait peur du bug de l'an 2000…
Dans ce domaine, mon niveau de compétence est donc voisin de woualou, ou peau d'balle.
Je précise que le CLI me gonfle, le sysadmin Linux me gonfle, et même si j'ai le plus grand respect pour tous ceux qui mettent les mains dedans, cela ne m'intéresse pas.

Par contre, tout ce qu'on peut faire avec, ça m'intéresse…

Je bidouille pas mal, un peu de tout. Mécanique, électronique, micro-contrôleurs…

J'ai choisi cet espace car j'ai constaté que le contenu sur la question disponible dans la langue de Molière est assez pauvre, alors j'ai décidé d'ajouter ma modeste pierre.

D'autant que malgré mes recherches assistées par IA, je n'ai pas trouvé de homelabeur qui pousse de petits agents jusqu'au vibe-sysadmin, ou vibe-coding.

Tous ceux qui ont essayé et partagé semblent avoir laissé tomber pour se rabattre vers les modèles frontières, sans même parler d'une approche « agents en mode YOLO ».

Pour soutenir ma découverte de l'IA, je me suis offert un abonnement Claude Max, sans lequel rien n'aurait été possible, même s'il a souvent montré ses limites (ou les miennes, je suis mal placé pour le déterminer).

Premier essai : Ollama sous Ubuntu

C'est donc tout naturellement que mon choix s'est porté sur Ubuntu, sur les conseils de Claude.

Après 2 jours de bricolage, j'avais un stack Ollama avec chat multimodal openwebui, AUTOMATIC1111, searXNG, un proxy swap pour basculer d'un modèle à l'autre et une mécanique fonctionnelle qui semblait tenir la route pour tourner sur mon matériel très limite.

Le matériel

Puisque je parle matériel : i7 7700k, Asus Z270i mini-ITX, 32 Go DDR4, Nvidia Titan Xp (Pascal) 12 Go, SSD NVMe 1 To, HDD 7200T 3 To.

C'est une machine de récupération, une borne de démo pro faite pour un salon et mise hors service (merci les pré-requis Windows 11).

Largement insuffisant pour être confortable, il faut ruser. Mais il est possible d'y faire tourner des modèles qui semblent intéressants à des vitesses correctes.

Sauf que voilà. C'était inutilisable. Les images générées ne ressemblaient à rien, les capacités de cognition et d'intégration des outils pas très au point ; au final ça ne dépassait pas le niveau du POC.

Amusant pour jouer avec pendant un jour ou deux, mais sans plus.

Le sous-produit : un workflow avec Claude

Le résultat de première intention n'était pas très funky, mais il en a émergé un sous-produit intéressant.

J'avais mis en place avec Claude un workflow qui me satisfaisait et qui me permettait de prendre en charge tous les arbitrages, tandis que lui me proposait toutes les options envisageables, et en bout de chaîne les mettait en application via Claude Code, sous supervision partagée avec un mécanisme de revue, de vérification de non-régression, de benchmarks et de rollback.

Pas le plus économe en tokens et en temps, mais adapté à mon profil newbie Linux/IA/dev et d'une grande robustesse, pour ce que je peux en juger au vu du résultat.

Deuxième essai : llama.cpp, Debian, et un patch

Comme les résultats de mon premier essai étaient insatisfaisants, je suis passé sous llama.cpp/llama-swap, openwebui, sous CUDA 12 et Debian, avec un petit patch custom pour llama.

Le patch corrige sur mon setup le support des checkpoints de speculative decoding pour les architectures hybrides/récurrentes — concrètement, Qwen 3.6.
C'est Claude qui l'a fait.

Sans cela c'était inutilisable, le prefill était trop long, même avec peu de contexte car le cache de prompt inter-tours ne fonctionne pas avec les modèles hybrides. Déjà que mon setup est poussif…

• qwen 3,6 35B A3B Q4 et ses dérivés (Ornith, abliterated) : environ 23 tk/s de génération
• prefill : aux alentours de 500 (pas envie de vérifier dans la doc)
• Gemma 4 26B A4B : un peu moins

Ce que je cherchais à savoir

J'ai piloté Claude pour qu'il procède à une analyse continue des mécanismes de défaillance connus propres aux petits modèles et aux outils associés, afin d'y apporter méthodiquement des remédiations, avec pour objectif d'étendre au maximum le périmètre opérationnel de ces outils et d'éliminer toutes les défaillances documentées sur le web et constatées sur mon projet.

Avec cette démarche j'espérais pouvoir me faire une idée précise de ce qu'il est et sera possible de faire avec ces outils, la conception du setup devant le rendre totalement indépendant des modèles utilisés, limité seulement par le hardware, poussé à ses limites.

Rétrospectivement cela s'est avéré assez ambitieux, mais j'ai été tellement impressionné par les performances de Claude, la facilité à le maintenir sur la bonne trajectoire et à l'amener à fournir les bonnes informations puis à construire l'intégralité des livrables et de la documentation avec un niveau de complexité que j'arrive tout juste à appréhender ; que sur le moment je me suis dit : Allons-y !

J'allais essayer de faire construire à Claude son (tout) petit frère.

Trois mois plus tard

Après 3 mois de découverte et de travail intensif, j'ai à présent un serveur llama.cpp qui tourne et sert des modèles MoE pour la plupart, un serveur openwebui, plusieurs agents et personae basés sur qwen-agent pour du sysadmin, du codage, de la recherche internet, la documentation des opérations, le tout sur une distribution Debian.

C'est Claude Code qui a tout « fait », j'ai essentiellement arbitré les choix architecturaux et recadré Claude quand il se laissait emporter par le porn-engeeniring.

Pourquoi Claude a écrit un harness custom

J'ai beaucoup travaillé sur le scaffolding des agents, en testant plusieurs harness, et j'ai décidé d'en faire un avec le framework qwen-agent, qui soit strictement limité à ce dont j'ai besoin, et rattrape les échecs pour en faire des tremplins vers le succès futur (je sais, c'est un peu pompeux, mais c'est l'idée).
Je n'ai pas obtenu de bons résultats avec les harness qui sont partagés avec les modèles frontières :

• trop d'outils
• des schémas d'outils trop verbeux
• des prompts types longs comme le bras avec plein de garde-fous qui échouent, alors que je pense qu'il faut les placer dans le scaffolding ou l'environnement (snapshots, aveuglement aux credentials, bac à sable, etc.)
• une tendance générale à vouloir « tordre le bras » du modèle alors qu'il faut, je pense, le laisser libre de faire ce qu'il sait faire comme il sait le faire, et ne contraindre que ce qui échoue (comme la trajectoire calquée sur le frontière par le RL agentique)

Mes principes :

• Limiter les outils à ce qui est nécessaire
• toujours respecter les outils et le formalisme canoniques présents dans la distribution du modèle (se renseigner au préalable).
• utiliser les schémas et le prompt pour signifier les différences éventuelles par rapport à ce qui est canonique, toute différence n’étant justifiée que parce qu’elle est nécessaire au fonctionnement du setup.
• Limiter autant que possible les responsabilités du modèle à ce qu’il doit faire. Le reste doit être géré par le harness et l’environnement.

Si mon agent s’appelle task et pas 007, c’est parce que c’est le nom que « connaît » qwen pour cette fonction, il sait ce que fait task sans avoir besoin d’en être informé.

Les seules informations qu’il reçoit sont les particularités liées au setup, dans leurs conséquences, pareil pour l’outil de recherche, il s’appelle à dessein comme celui d’openai.

Quand j’ai appliqué ce principe, mon orchestrateur est passé de galérien qui passe 3 appels et se met à délirer à des sessions de chat où j’interviens 3 fois au début pour cadrer et il enchaîne ensuite +40 tool calls variés entre recherche internet, agent codage/sysadmin, consultation ou mise à jour de notes en toute autonomie jusqu’au livrable.

Si je lui dis que task est limité en temps, cela n’a aucun effet, il n’a pas de notion réelle du temps.

Si je lui dis que task a un contexte limité et qu’il faut procéder par étapes successives, cela fonctionne bien mieux. Il faut trouver les bons leviers.

Mon agent n’a pas à gérer sa connexion à la machine sur laquelle il travaille, ni aucune authentification, ni aucune procédure de confinement ou de sécurité, aucune contingence en fait. Il doit faire un snapshot pour le sysadmin, et un Git pour le codage, et ensuite se mettre au travail en consignant au fur et à mesure, tout cela est parfaitement dans sa distribution et les trajectoires sur lesquelles il a été récompensé.

Les prompts de mon orchestrateur et de mon agent se situent entre 700 et 1200 tokens (de mémoire, un peu +, un peu -).

Comme ça il met toutes ses capacités au service de son objectif, et pas dans le respect de contraintes qui ne font que le distraire et le détourner de sa tâche.

La parcimonie

Le principe général est la parcimonie, everything, everywhere, all at once. Avant de rajouter quelque chose visible du modèle, il faut toujours se demander si c’est vraiment indispensable.

Première mise au travail

Après avoir obtenu de bons résultats avec Qwen 3.6 35B A3B Q4, Ornith, Mirothinker (pour la recherche internet), monté un pipeline de recherche internet inspiré de deep_research d'OpenAI, j'ai décidé de mettre tout ce petit monde au travail.

Premier chantier : monter un serveur openwebui sur une machine séparée, et séparer le backend du frontend.

Je dois avouer une chose, je suis du genre à être comme hypnotisé par le ballet d'une machine à commande numérique multiaxes, et regarder mon agent au travail me fait le même effet.

Je trouve ça extraordinaire de le voir enchaîner les commandes shell, raisonner, buter sur des problèmes, réfléchir, essayer autre chose, encore et encore jusqu'à ce que cela fonctionne (ou pas), consigner, et retourner au charbon.

Quand ça foire (timeout, erreur de parsing, etc.), c'est tout aussi impressionnant. Le fallback de synthèse du run prend le relais, livre sa synthèse, l'orchestrateur l'analyse, réfléchit à une stratégie en tenant compte des causes de l'échec et renvoie l'agent au charbon.

C'est à la fois enthousiasmant et un peu terrifiant.

L'écueil : aucune convention de projet

Mais avant de lancer quoi que ce soit, il a fallu que j'évite un écueil que je n'avais pas vu venir.

Je n'avais défini aucune convention de développement et de nommage avec Claude, et le code et la structure du projet sur la machine d'inférence s'en sont ressentis. Je me suis rendu compte que parfois il avait du mal à le reprendre lui-même, et moi je ne comprenais rien à la structure des dossiers, car il n'y en avait aucune.

Ce que j'ai constaté, c'est que Claude Opus et Fable adorent le porn-engineering, et foncent tout droit vers le code à chaque occasion ; et une fois que le code fonctionne, ils sont contents et proposent d'en rester là en laissant derrière eux un chantier dégueulasse, mais avec du code qui fonctionne (enfin, pour ce que j'ai pu faire et constater).

C'est indubitablement de ma faute : Je n'ai pas considéré que je devais prendre en charge cet aspect et définir un cadre strict dès le départ. Impressionné par Claude, je me suis imaginé qu'il travaillerait « proprement » de lui-même. Un dév pro ou amateur n'aurait pas eu ce problème.

En plus, le constat que les modèles pondent du code qui marche mais merdique à comprendre et à maintenir n'est pas une découverte d'hier, c'est bien documenté sur le web, mais je l'ai découvert après.

Je ne suis pas compétent pour en juger, mais il semble que le code généré par IA ne soit pas très apprécié des développeurs et des mainteneurs ; alors il fallait faire au mieux, l'essentiel étant que les modèles puissent s'y retrouver ; ce n'est pas moi qui vais y mettre le nez, sauf pour modifier les fichiers de prompting.

J'ai donc préféré repartir sur de bonnes bases pour cette nouvelle machine, surtout avec des petits modèles locaux à la manœuvre. J'ai dû peaufiner le scaffolding face à la réalité opérationnelle, et déterminer préalablement des conventions avec l'orchestrateur.

Il m'a conseillé des conventions de nommage, de structuration et de codage, et j'ai tout approuvé, en partant du principe qu'une convention en vaut une autre, l'essentiel étant qu'elle soit respectée. Respecter ses « préférences » de première intention me permet aussi de m'assurer dans une certaine mesure qu'elles sont bien représentées dans sa distribution et qu'il les maniera et les respectera sans difficultés.

La méthode : liveusb, SSH, et YOLO

La méthode :
Je démarre la machine cible sur liveusb Debian, je définis un password, je mets à jour le gestionnaire de paquets, et j'installe openssh-server.

Ensuite je démarre un chat avec l'orchestrateur sur la machine d'inférence et je lui demande de configurer le bazar.

C'est parti en mode YOLO !

Avec Ornith à la manœuvre, comme agent et comme orchestrateur, depuis la machine d'inférence qui rassemblait jusque-là le frontend et le backend, et via un harness utilisant une connexion SSH, le couple a installé et configuré Debian, configuré openwebui en accès externe possible avec la sécurité quivabien (firewall, liste blanche, chiffrement, etc.), l'a câblé sur le serveur llama.cpp, et m'a refactoré une copie de lui-même conforme aux conventions de sa nouvelle machine.

C'était au passage un bon test de sysadmin et de refactoring multi-fichiers pour le setup local et le scaffolding.

Il a réussi, en plusieurs sessions de chat successives avec reprise documentée par handoff entre les sessions (le budget de l'orchestrateur est limité à 64k tokens, et il commence à devenir con vers 40k), donc je suis passé à la suite.

Parenthèse : plan, budget, handoff

Une parenthèse architecturale.

En session sysadmin, au début de la première session, le modèle du chat crée une note avec le plan (pour Debian Indestructible il l'a récupérée sur le net), ensuite je surveille le budget tokens dans openwebui, et quand je vois qu'il se rapproche de 40k, ou qu'il se met à délirer et s'arrête (si je lui ai demandé d'enchaîner jusqu'au livrable), je demande l'écriture d'un handoff dans les notes openwebui, qui contient ce qui reste à faire.

Ensuite la session suivante prend connaissance du plan, du handoff, et fait un audit de la machine avec l'agent sysadmin et repart au combat.

Un détour plus funky : le mediacenter

La suite, c'est le refactoring de l'agent de recherche, mais c'est un très gros morceau car il est très complexe, et je ne suis pas du tout sûr qu'il y arrive, alors j'ai décidé de faire quelque chose d'un peu plus funky :

Ce qui est censé être mon mediacenter n'est qu'un PC Windows sur lequel je regarde la TV avec molotov-free et Chrome, les sites des chaînes gratuites et YouTube, le niveau zéro quoi.
J'ai donc décidé de déterminer quelle serait la bonne config pour mes usages avec Claude, et de mettre mes IA locales au travail.

J'ai sorti un autre ProDesk 400 G4 mini du placard, 16 Go, SSD 256 Go, Core i3 8100T, liveusb Debian, mot de passe, openssh, et YOLO !

Je voulais quelque chose de facile à maintenir, comme un dépôt Git, vu que le sysop est un agent en mode YOLO. J'ai donc opté pour une Debian (j'y suis j'y reste), configurée en Mode Indestructible suivant le layout openSUSE, guide disponible sur :

https://github.com/JMarcosHP/Debian-Indestructible

Ça a été laborieux, j'ai dû m'y reprendre 3 fois (à cause de mon scaffolding et du secure boot) pour que ça fonctionne bien « from scratch », mais j'ai à présent une Debian Indestructible avec Gnome et openssh-server au démarrage.

Ce qui a coincé

Le secure boot des HP ProDesk est apparemment hors de la distribution de mes modèles, la procédure de mise à jour du BIOS échouait. Comme je n'y tenais pas tant que ça, je l'ai désactivé.

Le scaffolding de l'agent ne rattrapait pas bien certaines terminaisons de session sur erreur, comme une erreur de parsing JSON, ou une coupure manuelle (j'ai un visualiseur pour l'agent, son budget, son thinking, ses paroles et llm calls, et je peux le couper en plein vol si je crois qu'il part en vrille).
J'ai donc modifié cela avec Claude pour que le modèle du chat reçoive bien un résumé par llm de ce que l'agent a fait, de la trajectoire de son raisonnement et des causes de son échec, en cas de fin « inattendue » de l'appel de l'agent, basé sur les traces de l'agent (tout est loggué et horodaté : thinking, llm calls, paroles, retours de commandes shell, etc.).

Comme ça, quand ça fonctionne, un run de l'agent qui se termine mal est un cahot sur la route du succès.

L'agent consigne également tout ce qu'il fait et les problèmes rencontrés avec leurs solutions dans un fichier de consignation horodaté et amendé au fur et à mesure de ses actions, et chaque session consulte le dernier en date ainsi qu'un fichier décrivant son environnement avant toute opération.

Pourquoi le mode YOLO ne m'empêche pas de dormir

En sysadmin, un snapshot bootable avant chaque intervention mutante, et le mode YOLO ne devrait plus être un souci pour mon cas d'usage. Son potentiel de nuisance sur le réseau est très limité : l'agent n'a accès à aucun credential — ils sont dans des valves openwebui — et il ne connaît que sa propre machine.

En mode dev, je le fais travailler dans une machine virtuelle par SSH, mode YOLO, il fait ce qu'il veut, installe ce qu'il veut, il travaille dans un dossier Git, et la machine est snapshotée. S'il casse quelque chose, pas grave, rollback et on repart. Il a la vision et un écran virtuel, de quoi faire des screenshots et des zooms pour contrôler les GUI ou utiliser une image comme exemple, et une carte son virtuelle au cas où.

Intermède : une fuite de watercooling

Au passage j'ai eu un accident de water-cooling et j'ai dû changer de carte mère, et aussi de boîtier parce qu'en mini-ITX ça ne courait pas les rues, et de ventirad parce qu'une fuite m'a suffi. À présent c'est toujours une Asus strix, mais en H270F ATX. Remplacement, allumage, ça fonctionne, ouf. Le setup reste quasi identique.

Où j'en suis

Maintenant je passe à l'installation/configuration de Kodi + FreeTube, mais avant je dois compléter l'environnement de l'agent : son accès à Context7 n'est pas fonctionnel faute de clef API. Ce ne sera sans doute pas utile pour la config du mediacenter, mais c'est une des fonctionnalités dont je l'ai doté, que j'ai laissée en suspens et qui finira bien par lui être utile.

J'en suis là. Si quiconque a des questions, je tenterai d'y répondre.