En combinant OpenCode, Ollama et Qwen3-Coder, je peux faire tourner un assistant IA local pour coder sans abonnement, sans cloud et sans envoyer mon code ailleurs. Le vrai sujet, c’est le bon setup, la machine suffisante et quelques vérifications simples avant de s’en servir sérieusement.
Pourquoi choisir un assistant IA local ?
Je choisis un assistant IA local quand je veux coder avec l’IA sans exposer mon code, sans dépendre d’un abonnement et sans perdre le contrôle sur les modèles utilisés.
Avec une stack locale comme OpenCode, Ollama et Qwen3-Coder, l’idée est simple. OpenCode sert d’interface, un peu comme le poste de pilotage pour discuter avec l’assistant et l’utiliser dans mon workflow de dev. Ollama joue le rôle du moteur local. Il télécharge les modèles, les lance sur ma machine, et expose une API utilisable par d’autres outils. Qwen3-Coder, lui, est le modèle spécialisé code. Il comprend mieux les fichiers, les fonctions, les erreurs, les refactorings et la génération de scripts qu’un modèle généraliste classique.
Le premier vrai bénéfice, c’est la confidentialité. Mon code reste sur ma machine. Pour une base métier, un produit interne, un client bancaire ou santé, ça change tout. J’ai déjà vu des équipes bloquées non pas par l’IA, mais par la peur d’envoyer du code métier dans un service externe. Une solution locale débloque souvent les tests internes, surtout sur des projets sensibles.
Le deuxième point, c’est le coût. Une fois installé, je peux utiliser mon assistant sans payer chaque requête. Bien sûr, la machine consomme de l’énergie et il faut parfois une bonne carte graphique, mais je ne suis pas dépendant d’un abonnement mensuel pour chaque développeur.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
Le troisième intérêt, c’est l’usage hors-ligne. Une fois les modèles téléchargés, je peux continuer à travailler sans connexion. C’est pratique en déplacement, sur un réseau fermé, ou dans une entreprise où l’accès Internet est très filtré.
Le dernier avantage, c’est le contrôle. Je choisis le modèle, sa taille, son contexte, l’environnement, les mises à jour. Mais il faut rester lucide. Local ne veut pas dire meilleur dans tous les cas. Les performances dépendent de la machine, du modèle choisi et de la qualité du prompt. Un petit modèle mal guidé peut produire du code moyen. Un bon prompt sur un modèle adapté peut déjà faire gagner beaucoup de temps.
| Besoin | Intérêt du local | Point de vigilance |
| Protéger le code | Le code reste sur la machine | Il faut sécuriser le poste local |
| Réduire les coûts | Pas de paiement à la requête après installation | La machine doit être assez puissante |
| Travailler hors-ligne | Les modèles restent disponibles sans Internet | Il faut les télécharger avant |
| Contrôler l’IA | Je choisis le modèle et l’environnement | La qualité dépend du modèle et du prompt |
Quelle machine faut-il prévoir ?
Pour faire tourner un assistant IA local pour coder, je partirais sur un ordinateur récent avec au moins 8 Go de RAM. Ça démarre. Mais honnêtement, pour travailler correctement avec un modèle de code autour de 7B, comme qwen2.5-coder:7b, 16 Go de RAM changent vraiment l’expérience.
Le piège, c’est de se dire “si ça se lance, c’est bon”. Pas vraiment. Si la machine est trop juste, l’assistant va répondre lentement, parfois bloquer quelques secondes, et le confort de pair-programming disparaît vite. Vous voulez poser une question, obtenir une réponse, tester, corriger. Pas attendre comme si vous compiliez un vieux projet Java en 2008.
| Configuration | Matériel conseillé | Impact attendu |
| Minimale | Ordinateur récent, 8 Go de RAM, 10 Go d’espace libre | Ça peut fonctionner, mais les réponses risquent d’être lentes, surtout avec plusieurs apps ouvertes |
| Confortable | 16 Go de RAM, processeur récent, 15 Go d’espace libre | Expérience beaucoup plus fluide avec un modèle 7B, utilisable au quotidien |
| Très confortable | 32 Go de RAM ou GPU correct selon l’usage | Plus de marge pour coder, lancer Docker, un navigateur, un IDE, et garder l’assistant réactif |
Le modèle qwen2.5-coder:7b occupe environ 4 à 5 Go sur le disque. Je préfère prévoir 10 à 15 Go d’espace libre, parce qu’il faut installer Ollama, télécharger le modèle, garder un peu de cache, et éviter de finir avec un disque saturé pour une raison bête.
Côté système, vous avez le choix. Windows fonctionne. macOS Intel aussi. macOS Apple Silicon marche très bien, souvent même mieux grâce aux puces M1, M2, M3 ou M4. Linux est aussi une très bonne option, surtout si vous êtes déjà à l’aise avec cet environnement.
Le prérequis qu’on oublie souvent, c’est le terminal. Pas besoin d’être administrateur système. Mais il faut savoir lancer une commande, lire une erreur simple, vérifier qu’un outil est installé, par exemple avec une commande de version. Si le terminal vous panique complètement, ça vaut le coup de prendre 30 minutes avant, sinon la moindre erreur d’installation va vous faire perdre du temps.
Comment installer Ollama proprement ?
J’installe d’abord Ollama, parce que c’est lui qui exécute les modèles localement et qui permet ensuite à OpenCode de s’appuyer sur une IA disponible sur la machine. Sans ça, OpenCode n’a pas vraiment de “cerveau” local à appeler.
Je pars toujours de la page officielle d’Ollama. Ça évite les vieux tutos, les commandes qui traînent depuis deux ans, ou les dépôts pas très clairs. Sur macOS et Linux, l’installation se fait avec la commande officielle :
curl -fsSL https://ollama.com/install.sh | sh
Sur Windows, je passe par l’installeur .exe officiel depuis le site d’Ollama. Rien de spécial à bricoler. Je lance l’installation, puis je laisse Ollama tourner en arrière-plan. C’est souvent là que les gens bloquent bêtement : Ollama est installé, mais le service ne tourne pas, donc rien ne répond.
Une fois installé, je vérifie que la commande est bien disponible :
ollama -v
Si ça me renvoie une version, c’est bon signe. Si la commande ne répond pas, je vérifie trois choses : l’installation, le PATH, et le fait qu’Ollama tourne bien en arrière-plan. Le PATH, c’est juste la liste des endroits où votre terminal cherche les commandes. Si Ollama n’y est pas, votre machine ne sait pas où le trouver.
Ensuite, je télécharge le modèle. Pour coder, je choisis un modèle de la famille Qwen Coder disponible dans Ollama au moment de l’installation. Je reste prudent sur les noms exacts, parce que les tags changent. Avant de lancer la commande, je vérifie toujours le nom exact dans le catalogue officiel d’Ollama.
Par exemple, si le tag est bien disponible :
ollama pull qwen2.5-coder:7b
Là, je surveille surtout trois choses. Le téléchargement peut prendre un moment, le modèle consomme plusieurs Go sur le disque, et le premier lancement est parfois plus lent. C’est normal. Une fois chargé, les réponses deviennent souvent plus fluides. Chez un client, on avait cru que “ça ramait”, alors que c’était juste le premier chargement du modèle.
Je fais ensuite un test simple :
ollama run qwen2.5-coder:7b
Checklist rapide avant de passer à OpenCode :
- Ollama installé
- Version vérifiée avec ollama -v
- Modèle téléchargé
- Test de génération réalisé
Comment connecter OpenCode au modèle local ?
Une fois Ollama opérationnel, j’installe OpenCode et je le configure pour utiliser le modèle local servi par Ollama. L’idée est simple : Ollama fait tourner le modèle sur votre machine, OpenCode sert d’assistant de code dans votre terminal, et les deux discutent en local.
L’installation d’OpenCode peut se faire de plusieurs façons. La méthode la plus simple, dans beaucoup de cas, passe par npm. Npm, c’est le gestionnaire de paquets livré avec Node.js. Il faut donc avoir Node.js et npm disponibles sur la machine avant de lancer quoi que ce soit. Je préfère être clair ici : je ne vous donne pas une commande npm au hasard, parce que ce genre d’outil évolue vite. Le bon réflexe, c’est de reprendre la commande exacte dans la documentation officielle d’OpenCode au moment où vous l’installez.
Le flux logique est assez direct. J’installe OpenCode, je vérifie qu’il se lance correctement, puis je sélectionne ou je déclare Ollama comme fournisseur local. Ensuite je choisis le modèle Qwen Coder que j’ai déjà téléchargé dans Ollama. Le point important, c’est le nom du modèle. Il doit correspondre exactement à celui connu par Ollama, sinon OpenCode ne saura pas quoi appeler.
Pour vérifier que tout marche, je ne commence jamais par un gros refactoring. C’est le meilleur moyen de croire que l’outil est nul alors qu’on lui demande juste trop, trop tôt. Je prends un petit dossier de code, deux ou trois fichiers, et je teste des demandes simples.
Voici les prompts que j’utilise souvent pour valider la connexion et la qualité des réponses :
- Explique ce fichier en 10 lignes
- Propose un test unitaire pour cette fonction
- Trouve les effets de bord possibles
- Réécris cette fonction en gardant le même comportement
Sur un projet client, j’avais vu une équipe partir directement sur “réorganise toute l’architecture”. Résultat, réponse lente, approximative, et frustration. Quand on a repris avec une fonction isolée, l’assistant est devenu utile en cinq minutes.
Les erreurs fréquentes sont presque toujours les mêmes : le modèle n’a pas été téléchargé dans Ollama, OpenCode est lancé avant Ollama, le nom du modèle est mal écrit, la machine est trop juste en RAM ou en GPU, ou alors on attend des résultats trop ambitieux dès le premier test. Je commence petit, je valide la chaîne, puis j’augmente progressivement la difficulté.
Quels usages sont vraiment utiles au quotidien ?
Les usages les plus utiles sont ceux qui réduisent les petites frictions du développement sans remplacer votre jugement. C’est vraiment ça le bon angle. Un assistant IA local pour coder n’est pas là pour décider à votre place, ni pour valider qu’un code est propre. Il est là pour vous faire gagner quelques minutes, souvent répétées vingt fois dans la journée.
Je m’en sers surtout pour débloquer des moments un peu pénibles. Comprendre un fichier inconnu. Résumer une fonction trop longue. Générer une première version de tests. Documenter un bout de code que personne n’a envie de toucher. Reformuler une erreur obscure en langage normal. Proposer un refactoring limité, c’est-à-dire une petite amélioration de structure sans changer le comportement du code. Créer des snippets, donc des petits morceaux de code réutilisables. Vérifier une logique simple avant de perdre du temps dessus.
Le point important, c’est de garder des demandes courtes. Si vous balancez tout un projet à l’assistant, même local, vous récupérez souvent une réponse vague. Je préfère donner un fichier, une fonction, un message d’erreur, puis une consigne claire. Par exemple : “Explique ce que fait cette fonction, sans proposer de changement”. Ou “Écris trois tests unitaires pour ce cas, en gardant le style existant”.
Dans les missions data et automatisation, je vois souvent un truc assez net. Le gain vient moins du code généré que du temps gagné pour comprendre, nettoyer et itérer. Un fichier CSV mal fichu, un script Python repris après six mois, une règle métier à traduire dans Make ou n8n… C’est là que l’assistant local devient agréable. Il aide à reprendre le fil sans exposer vos données partout.
Mais la confidentialité ne dispense pas de rigueur. Je relis toujours le code. Je teste avant commit. Je limite ce que j’envoie à l’assistant. Je ne lui donne pas un accès mental illimité à mon projet. Installer localement permet de garder le contrôle, mais il faut aussi garder le contrôle dans la manière de s’en servir.
| Tâche | Prompt type | Risque | Vérification recommandée |
| Comprendre un fichier inconnu | Explique ce fichier en 10 lignes, sans proposer de modification. | Faible | Comparer avec le code réel et les imports. |
| Générer des tests | Crée des tests unitaires pour cette fonction avec ces cas limites. | Moyen | Lancer les tests et relire les assertions. |
| Documenter une fonction | Ajoute une docstring claire sans changer le code. | Faible | Vérifier que la documentation décrit bien le comportement. |
| Proposer un script | Écris une première version simple de ce script Python. | Moyen | Tester sur un jeu de données réduit. |
| Refactoring limité | Suggère une simplification sans modifier la logique métier. | Élevé | Faire un diff, relire, lancer les tests avant commit. |
Alors, est-ce que ça vaut le coup de le faire en local ?
Pour moi, oui, si votre priorité c’est de garder la main sur votre code, vos données et vos coûts. La combinaison OpenCode, Ollama et Qwen3-Coder donne une base solide pour tester un assistant IA de programmation local, sans abonnement et utilisable hors-ligne une fois le modèle installé. Il faut juste rester lucide : une machine trop juste ralentira tout, et l’IA ne remplace pas les tests ni la relecture. Le bon usage, c’est le pair-programmer privé qui explique, propose, débloque et accélère. Le bénéfice pour vous, c’est simple : coder avec l’IA sans lâcher le contrôle.
FAQ
- Qu’est-ce qu’un assistant IA local pour coder ?
C’est un assistant de programmation qui tourne sur votre machine au lieu d’utiliser un service cloud. Avec une stack comme OpenCode, Ollama et un modèle Qwen Coder, je peux demander de l’aide sur du code, générer des tests ou comprendre un fichier sans envoyer le projet vers une plateforme externe. - Pourquoi utiliser Ollama avec OpenCode ?
Ollama sert à télécharger, gérer et exécuter les modèles IA localement. OpenCode sert d’interface de travail pour interagir avec l’assistant dans un contexte de développement. Les deux ensemble permettent d’avoir une expérience plus pratique qu’un simple modèle lancé dans un terminal. - Est-ce qu’il faut une grosse machine pour utiliser Qwen3-Coder ?
Pas forcément une machine énorme, mais il faut être réaliste. 8 Go de RAM est un minimum, 16 Go est beaucoup plus confortable pour un modèle autour de 7B. Il faut aussi prévoir de l’espace disque, car un modèle comme qwen2.5-coder:7b prend environ 4 à 5 Go, avec une marge recommandée de 10 à 15 Go libres. - Un assistant IA local fonctionne-t-il sans Internet ?
Oui, une fois Ollama installé et le modèle téléchargé, l’assistant peut fonctionner hors-ligne. Internet reste utile au départ pour récupérer les outils et les modèles, puis pour consulter les documentations officielles ou mettre à jour l’environnement. - Est-ce que l’IA locale remplace un développeur ?
Non. Je la vois plutôt comme un pair-programmer privé. Elle aide à comprendre, générer, reformuler et proposer des pistes, mais le développeur doit relire, tester et décider. Le vrai gain vient du temps gagné sur les tâches répétitives et les blocages courts.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent passer de l’expérimentation IA au vrai usage business, avec des outils maîtrisés, mesurables et propres. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez mettre en place ce type d’assistant IA local dans votre entreprise, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’automatisation IA ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.





