Agent de code local avec LM Studio et OpenPilot
Configurez un agent de code local avec LM Studio et OpenPilot : modèles Qwen 3, serveur compatible OpenAI, réglages, sécurité et limites. Essayez-le.
Créer un agent de code local avec LM Studio et OpenPilot
Les agents de programmation ne sont plus cantonnés aux assistants intégrés aux grands environnements de développement. On peut aussi en faire tourner un sur sa propre machine avec un modèle local, tout en gardant la main sur les fichiers qu'il lit et sur les commandes qu'il exécute. Le hic, c'est que l'installation n'est pas toujours aussi simple qu'on l'espère : modèle trop lourd, fenêtre de contexte trop courte, serveur local mal réglé... et on passe vite de « ça devrait marcher » à « où est-ce que j'ai fait planter ça ? ».
LM Studio facilite une partie du travail. L'application permet de télécharger et charger des modèles, puis de les exposer via un serveur compatible avec l'API d'OpenAI. OpenPilot s'y connecte pour lire et modifier des fichiers dans un dossier choisi, ou lancer des commandes, avec une validation demandée pour les actions sensibles.
Ce guide fait le tour de la configuration de bout en bout : choix de Qwen 3, connexion au serveur, premiers tests sur un projet. On parle aussi des limites des modèles locaux, des précautions à prendre et des compromis à accepter avant d'envisager ce type d'outil dans une équipe.
Pourquoi associer LM Studio et OpenPilot
OpenPilot est une application de bureau libre pensée pour faire travailler un agent de code dans un dossier défini par l'utilisateur. L'agent peut lire et modifier des fichiers, exécuter des commandes shell, et demander une validation avant certaines actions sensibles. L'intérêt, quand on associe ça à LM Studio, c'est d'utiliser un modèle qui tourne chez vous, plutôt qu'un service distant piloté par un éditeur.
LM Studio sert ici de gestionnaire de modèles et de serveur local. On y recherche et télécharge des modèles, on consulte une estimation de leurs besoins mémoire, puis on les charge. Ensuite, le serveur expose une interface compatible avec l'API d'OpenAI, format que OpenPilot sait utiliser.
Un montage simple, mais pas magique
Le plus important, c'est de comprendre la séparation des rôles. LM Studio exécute le modèle et fournit l'interface réseau locale. OpenPilot, lui, orchestre les échanges entre le modèle, les fichiers et les outils du projet. L'agent n'est donc pas « dans » LM Studio : c'est OpenPilot qui prépare le contexte, puis récupère les résultats.
Cette façon de faire permet aussi de changer de modèle selon le besoin, sans changer d'outil côté agent. Ça marche bien pour des essais, des modifications ciblées, ou des tâches répétitives sur un dépôt. Et si vous êtes en équipe, c'est un moyen pratique de comparer l'inférence locale à des solutions hébergées.
Juste une mise en garde : « local » ne veut pas dire « sans risque ». Le serveur tourne sur votre machine, mais l'application peut avoir ses propres réglages de télémétrie, et l'agent peut accéder aux fichiers du répertoire autorisé. Prenez donc le temps de vérifier les paramètres et de bien choisir le dossier de travail.
Quand cette approche est pertinente
Tout dépend de votre priorité principale. Un modèle local est intéressant si vous voulez :
- tester sans dépendre d'une clé d'API distante,
- comparer plusieurs modèles,
- limiter l'envoi du contenu du projet à un fournisseur externe.
C'est aussi un bon choix pour comprendre comment un agent fonctionne réellement : quelles informations il lit, quels outils il sollicite, et quand il demande une validation.
En revanche, si votre objectif est d'obtenir les meilleurs résultats sur des tâches vraiment complexes, un modèle local de petite taille ne sera pas forcément le bon pari. Les résultats dépendent du modèle, de votre machine, de la longueur de contexte, et de la nature de la tâche. Plutôt que chercher « le modèle idéal », raisonnez par cas d'usage.
Pour démarrer, vous pouvez consulter le dépôt GitHub d'OpenPilot et son site officiel. Si vous comparez d'autres façons de lancer un agent local, le guide de configuration avec Ollama propose une alternative.
Configurer LM Studio et lancer un modèle
Tout commence par le choix du modèle. Dans LM Studio, le guide recommande la famille Qwen 3, avec de bons résultats sur les versions 8B et 27B. Si vous ne savez pas encore ce que votre machine encaisse, commencez par le 8B : c'est une manière simple de valider que l'ensemble fonctionne avant de monter en taille.
La mémoire disponible compte beaucoup. La charge dépend du modèle et de ses réglages, et LM Studio donne une estimation avant le chargement. Ça aide à éviter de sélectionner un modèle qui ne tient pas vraiment à l'aise sur la machine. Cela dit, les « capacités réelles » varient selon la mémoire vive, la mémoire vidéo et la configuration : ne traitez pas une valeur affichée comme une promesse de fluidité dans tous les cas.
Régler la fenêtre de contexte
Le réglage le plus facile à sous-estimer, c'est la longueur du contexte. Quand un agent travaille, il ne s'appuie pas uniquement sur votre dernière consigne. Il peut inclure le contenu de fichiers, des résultats d'outils et l'historique des échanges. À chaque tour, tout ça prend de la place dans la fenêtre disponible.
Avec une valeur par défaut, un contexte trop court se remplit vite. Ce n'est pas toujours accompagné d'un message d'erreur clair : l'agent peut perdre le fil, répondre de façon confuse, ou s'interrompre en plein milieu d'une tâche. Si ça vous arrive, regardez d'abord la longueur de contexte configurée au chargement du modèle.
Augmentez-la autant que votre machine le permet, sans supposer que « plus grand » est toujours mieux. Il y a une limite pratique imposée par la mémoire. Et même avec une fenêtre plus large, demander de traiter trop de fichiers, ou une tâche trop vaste, peut rendre le travail moins lisible. En résumé : le bon réglage, c'est celui qui permet au modèle d'absorber le nécessaire, sans mettre la machine en difficulté.
Démarrer le serveur local
Dans LM Studio, ouvrez l'onglet Developer puis activez Start server. Par défaut, le serveur écoute sur http://localhost:1234. L'URL de base compatible avec OpenAI à fournir à OpenPilot sera donc http://localhost:1234/v1.
Vous pouvez aussi démarrer le serveur depuis un terminal :
lms server startSi vous avez changé le port dans les réglages de LM Studio, utilisez l'adresse correspondante (pas le port par défaut). Avant de continuer, vérifiez que le serveur tourne bien et que le modèle choisi est chargé : l'agent en a besoin pour répondre.
Installer OpenPilot et le connecter
Une fois le serveur prêt, installez OpenPilot en fonction de votre système. Les versions indiquées dans le guide source sont :
- Windows : utilisez
OpenPilot-Setup.exe. Une version portable est aussi disponible dans la section publications. - macOS : une version bêta est proposée en
.dmg, pour Apple Silicon et Intel. - Linux : pas encore d'installateur. Le projet peut être lancé depuis les sources avec Node.js 20 (ou une version plus récente) :
git clone,npm install, puisnpm start.
Autre point important : les versions mentionnées ne sont pas signées. Sur Windows, SmartScreen peut afficher un avertissement : la procédure indiquée par le projet consiste à cliquer sur More info, puis Run anyway. Sur macOS, faites un clic droit sur l'application puis choisissez Open. Ce sont des indications du mainteneur, pas une invitation à contourner les contrôles sans vérifier. Téléchargez depuis les canaux officiels et assurez-vous de comprendre le risque lié à une version non signée.
Renseigner la connexion au modèle
Au premier lancement, l'assistant de configuration demande les infos de connexion. Utilisez :
- Nom : l'identifiant du modèle chargé, tel qu'il apparaît dans LM Studio.
- URL de base :
http://localhost:1234/v1, sauf si vous avez changé le port. - Clé d'API : LM Studio n'en exige pas par défaut. Une valeur de remplacement suffit. Si vous avez activé l'authentification dans les réglages du serveur, saisissez le jeton correspondant.
Le nom doit correspondre à celui que LM Studio expose. Si la connexion échoue, commencez par vérifier l'adresse et le port, puis l'état du serveur, le modèle chargé et les paramètres d'authentification. Évitez de modifier plusieurs réglages en même temps : c'est comme travailler avec les yeux fermés, et le diagnostic devient vite pénible.
OpenPilot permet ensuite d'ajouter d'autres modèles dans ses paramètres et de choisir un modèle par conversation. C'est pratique pour comparer : un modèle plus petit et plus rapide face à un modèle plus volumineux. Le compromis est classique : le plus puissant n'est pas forcément le plus réactif, et « rapide » ne veut pas dire « bon pour votre tâche ».
Tester l'agent sans prendre de risques inutiles
Pour le premier essai, choisissez un dossier géré par Git, ou un projet « jetable ». Avec Git, vous verrez clairement ce qui est modifié et vous pouvez revenir en arrière si ça part dans le décor. Un répertoire de test limite aussi les dégâts, surtout quand vous apprenez comment l'agent lit et modifie réellement votre projet.
Évitez de commencer par une demande trop floue du type « améliore tout le projet ». Une tâche ciblée permet de vérifier à la fois la connexion, l'accès aux fichiers et la qualité des modifications. Le guide propose par exemple : « Examine package.json et ajoute dans README.md une section Scripts qui explique chacun des scripts. »
Cette demande est utile parce qu'elle contient une cible (un fichier source), un fichier à modifier, et un résultat vérifiable. Vous pouvez comparer la description de la doc avec les scripts réellement présents dans package.json, puis regarder le diff avant de garder le changement.
Observer les actions, pas seulement la réponse finale
OpenPilot affiche les lectures et modifications de fichiers, ainsi que les commandes shell, sous forme de cartes. L'application demande aussi une approbation (ou un refus) pour les actions sensibles. Cette visibilité est cruciale : un agent de code n'est pas uniquement un générateur de texte. Il agit sur votre environnement, et la qualité du résultat dépend autant des opérations qu'il tente que de la réponse finale.
Prenez le temps de lire les cartes et les demandes de confirmation. Si une commande ne colle pas à la tâche, ou si un fichier inattendu est concerné, refusez et reformulez la demande. La validation humaine n'aide que si l'info est claire et si la personne qui valide prend réellement le temps de vérifier.
Pour un usage régulier, gardez un cycle simple :
- Décrivez une modification précise et son périmètre.
- Laissez l'agent inspecter les fichiers nécessaires.
- Examinez les commandes et changements proposés.
- Validez uniquement ce que vous attendez.
- Vérifiez le diff et lancez vos tests habituels.
Ce processus n'élimine pas les bugs. Mais il réduit le coût d'une erreur et rend vos essais plus faciles à reproduire. Et si vous répétez la même demande sur plusieurs projets, cette discipline devient encore plus importante : une ambiguïté ponctuelle se corrige, une ambiguïté répétée peut entraîner une série de changements à rattraper.
Limites, sécurité et critères de choix
Les petits modèles locaux sont souvent pratiques pour des modifications ciblées, mais ils sont moins solides sur des suites longues d'étapes. Une tâche qui demande d'explorer un dépôt, de comprendre plusieurs dépendances, de modifier beaucoup de fichiers et de vérifier des comportements peut vite dépasser leurs capacités. Dans ce cas, la solution pragmatique consiste à découper en sous-tâches et à contrôler chaque résultat, ou à passer à un modèle plus grand si votre machine le permet.
Le guide mentionne aussi un point de fonctionnement : OpenPilot ne dispose pas encore d'un mécanisme de protection contre les boucles. Un modèle peut donc répéter une action ou une réponse. Si ça arrive, arrêtez l'exécution et reformulez la demande, plutôt que de laisser l'agent continuer sans supervision. C'est une limite à intégrer si vous voulez l'utiliser sur un projet important.
Local ne veut pas dire sans réglages de confidentialité
La télémétrie est activée par défaut selon les informations fournies par le projet. Elle porte sur des données d'usage anonymes : ouvertures de l'application, fonctionnalités et modèles utilisés, et nombre de jetons. Le projet indique qu'elle ne comprend pas les conversations, les fichiers, les chemins d'accès ou les clés.
Vous pouvez la désactiver pendant la configuration initiale ou dans Settings, puis About. Et si c'est une équipe : ne vous contentez pas de l'étiquette « local ». Vérifiez les réglages disponibles, informez les utilisateurs et appliquez les règles internes pertinentes. Dans un cadre professionnel européen, le fait que ça tourne « chez vous » ne remplace pas l'analyse des flux de données ni les exigences de sécurité et de conformité, notamment celles liées au RGPD.
Autres limites, plus concrètes : la version macOS est indiquée comme bêta, les applications ne sont pas signées et aucun installateur Linux n'est fourni. Donc oui, le système d'exploitation, le niveau de support attendu, et la capacité de l'équipe à installer depuis les sources comptent dans la décision.
Une grille de décision simple
Avant d'en faire un outil de travail régulier, posez-vous ces quatre questions :
- Votre tâche est-elle vraiment circonscrite ? Les petites modifications documentaires ou localisées sont de meilleurs premiers cas d'usage qu'une refonte complète.
- Votre machine peut-elle exécuter le modèle choisi ? Regardez la mémoire et le contexte, pas seulement le nombre de paramètres annoncé.
- Les changements sont-ils réversibles et vérifiables ? Un dépôt Git, des tests et une revue du diff réduisent le coût des erreurs.
- Les utilisateurs comprennent-ils les limites de confidentialité et de fonctionnement ? Documentez la télémétrie, les confirmations et les systèmes pris en charge.
Si c'est favorable, commencez par un pilote sur un dépôt non critique plutôt que de déployer tout de suite. Et si les résultats sont décevants, cherchez la cause avant de conclure que « l'IA locale ne marche pas » : modèle, contexte, taille de la tâche et configuration peuvent tous jouer.
Conclusion
Associer LM Studio à OpenPilot permet de tester un agent de code local sans monter une infrastructure complexe : choisissez un modèle, augmentez si besoin son contexte, démarrez le serveur compatible avec OpenAI, puis connectez OpenPilot à l'adresse locale. La configuration tient en quelques étapes ; le vrai travail commence ensuite, dans le choix des tâches et le contrôle des modifications.
Pour un premier essai, utilisez un dépôt Git (ou un projet sans enjeu), demandez un changement limité, puis vérifiez chaque action. Les modèles locaux sont utiles, mais la taille du modèle, la fenêtre de contexte et la tenue sur des tâches longues comptent autant que la simplicité de mise en place.
Vous pouvez consulter le projet OpenPilot, tester sur une tâche sans risque et partager vos résultats (bons ou moins bons) en indiquant le modèle LM Studio utilisé. Ces retours concrets aideront à mieux comprendre ce qui marche vraiment avec l'outil.