Vous codez en PHP, Python ou JavaScript dans une PME de Lille, une ESN de Valenciennes ou un service numérique de collectivité à Amiens, et vous voulez une aide à la rédaction sans coller le dépôt sur un cloud tiers. Ce tutoriel pose une alternative locale à Copilot : l’extension Continue dans VS Code, branchée sur un modèle de code open source servi par Ollama sur votre machine. On détaille l’installation, le choix du tag modèle (toujours à recopier depuis la documentation du jour), l’autocomplétion, le chat contextuel, et la manière d’évaluer les performances chez vous — sans scores inventés ni tok/s de labo IAHDF. IAHDF reste indépendant : aucun éditeur ne paie ce contenu.
Pourquoi un assistant de code local ?
Les assistants cloud (Copilot et équivalents) envoient des fragments de code, parfois de larges contextes, vers des infrastructures externes. Pour un dépôt contenant des secrets de staging, des règles métier d’une mutuelle régionale, ou du code d’un marché public, ce flux peut être interdit par contrat ou par politique interne. Un assistant local reverse le modèle : le LLM tourne sur votre GPU (ou CPU), Continue reste une couche d’UI dans VS Code, et le réseau vers Internet n’est utile que pour télécharger le modèle une fois.
Cela ne rend pas magiquement « conforme » un poste mal sécurisé : un laptop familial partagé, un Wi-Fi café, un dépôt sur un disque non chiffré restent des risques. Mais le geste technique — code + prompts qui ne sortent pas — répond à la question fréquente des ateliers IAHDF : « Une alternative locale à Copilot ? ». Oui, avec des compromis de confort selon la carte graphique et la taille du modèle.
Continue est une extension open source pour VS Code (et JetBrains selon les versions) qui orchestre chat, édition inline et complétion. Elle parle à plusieurs backends ; ici on cible Ollama en local. Si vous découvrez Ollama, le parcours premiers pas Ollama pose les bases avant ce tutoriel avancé.
Architecture : VS Code, Continue, Ollama
Trois couches. VS Code édite les fichiers et fournit le contexte (fichier ouvert, sélection, parfois workspace selon la config). Continue transforme ce contexte en requêtes vers un modèle (complétion tab, chat latéral, commandes d’édition). Ollama charge le modèle de code, expose une API HTTP locale, et renvoie les tokens. Vous pouvez remplacer Ollama par un autre runtime plus tard ; le principe reste le même.
- Continue
- Extension d’assistant dans l’éditeur : chat, complétion, actions sur sélection. La config YAML/JSON évolue : suivez la doc officielle Continue du jour.
- Modèle de code
- LLM entraîné ou adapté pour compléter et expliquer du code (familles type Qwen Coder, DeepSeek Coder, CodeLlama, etc.). Le tag exact change : ne le recopiez pas d’un article daté.
- Ollama
- Runtime local qui tire, quantifie et sert des modèles via une API. Voir aussi glossaire Ollama pour le vocabulaire pull / tag / Modelfile.
- Contexte
- Ce que le modèle « voit » (fichier, sélection, historique de chat). Plus c’est large, plus la VRAM et la latence montent.
Matériel : ordres de grandeur à vérifier chez vous
Pour un modèle de code dense dans la famille 7B–14B en quantification moyenne, une carte NVIDIA avec de l’ordre de 16 à 24 Go de VRAM est souvent citée comme zone de confort pour l’autocomplétion réactive et un chat raisonnable. Avec moins de VRAM, une quantification plus agressive ou un modèle plus petit restent possibles, au prix d’une latence plus élevée ou d’un contexte plus court. Sur Mac Apple Silicon, la mémoire unifiée change le calcul : un Mac avec une quantité de mémoire confortable (souvent citée autour de 32 Go et plus pour expérimenter sérieusement) est un ordre de grandeur à confronter à votre usage réel.
Ces chiffres ne sont pas des mesures de labo IAHDF. Ils ne remplacent pas un essai sur votre machine de Roubaix ou votre tour de bureau à Beauvais. Fermez les autres applications GPU (jeux, autre LLM, rendu 3D) pendant les tests. Si vous visez un serveur partagé plutôt qu’un poste développeur, le tutoriel serveur GPU France aborde l’hébergement ; ici on reste sur le poste de code.
Prérequis : VS Code, Ollama, terminal
Vous devez avoir Visual Studio Code installé et à jour, un compte utilisateur avec droits d’installation d’extensions, et un terminal pour vérifier Ollama. Installez Ollama depuis le site officiel, confirmez `ollama --version`, puis tirez un petit modèle de test avant le modèle de code pour valider proxy, antivirus et espace disque — problèmes fréquents en entreprise à Lille ou Douai.
Préparez un dépôt d’essai non sensible (petit projet open source, sandbox interne, exercice). Ne branchez pas Continue sur le monorepo client le premier jour : vous voulez juger latence et qualité de suggestion sur du code que vous pouvez montrer et jeter.
Pas à pas : de Ollama à Continue opérationnel
Installer et vérifier Ollama
Téléchargez Ollama depuis le site officiel, installez-le, ouvrez un terminal et lancez une commande de version. Sur Windows, laissez le service démarrer avec la session ; sur Linux, vérifiez que le démon écoute en local. Tirez d’abord un modèle minuscule pour confirmer que le pull fonctionne derrière le proxy d’entreprise éventuel. Notez le chemin des modèles et l’espace disque libre : un modèle de code pèse souvent plusieurs gigaoctets selon la quantification. Ne configurez encore aucune extension : isolez les problèmes runtime avant d’ajouter VS Code.
Choisir et tirer le modèle de code (tag exact du jour)
Ouvrez la bibliothèque Ollama ou la fiche Hugging Face / documentation du runtime que vous utilisez. Cherchez une famille explicitement présentée pour le code (par exemple une variante « Coder » d’une lignée Qwen, DeepSeek ou équivalent open source). Copiez le tag exact publié le jour J — suffixes de quantification et de variante évoluent. Lancez `ollama pull` avec ce tag, puis `ollama run` pour un essai conversationnel court (« explique cette fonction Python »). Si le modèle charge mais répond trop lentement pour vous, testez une quantification plus légère ou un tag plus petit avant d’aller dans Continue.
Installer l’extension Continue dans VS Code
Dans VS Code, ouvrez le panneau Extensions, recherchez Continue (éditeur open source Continue.dev), installez la version publiée sur le marketplace que vous utilisez, puis rechargez la fenêtre si demandé. Ouvrez la vue Continue (icône latérale) et refusez, pour ce tutoriel, toute connexion à un fournisseur cloud tant que vous n’avez pas besoin d’un modèle distant. Créez ou ouvrez le fichier de configuration Continue selon la doc du jour (souvent un YAML dans le dossier utilisateur ou du workspace). L’emplacement exact et les clés changent : suivez la documentation officielle plutôt qu’un screenshot d’article daté.
Brancher Continue sur l’API Ollama locale
Dans la config Continue, déclarez un modèle de type Ollama (ou API compatible) pointant vers l’hôte local et le port Ollama habituel, avec le même tag que celui que vous venez de tirer. Assignez ce modèle au rôle chat et, si proposé séparément, au rôle autocomplétion / tab. Enregistrez, rouvrez un fichier source, et envoyez un message court dans le panneau chat (« résume ce fichier en trois puces »). Si Continue affiche une erreur de connexion, vérifiez qu’Ollama tourne, que le pare-feu local n’bloque pas, et que l’URL dans la config correspond à celle attendue par Continue pour Ollama le jour J.
Activer et calibrer l’autocomplétion
Activez la complétion inline si elle est désactivée par défaut dans votre version. Ouvrez un fichier du dépôt d’essai, placez le curseur dans une fonction inachevée, et observez le délai avant la suggestion grisée. Ajustez dans Continue (et éventuellement Ollama) la taille de contexte et les options de complétion : trop de contexte ralentit ; trop peu donne des suggestions hors sujet. Désactivez temporairement d’autres extensions de complétion IA pour éviter les conflits. Sur un poste à Arras partagé avec d’autres tools GPU, fermez Open WebUI ou un second modèle chargé si la latence explose.
Utiliser le chat avec sélection et fichiers
Sélectionnez une fonction, ouvrez le chat Continue, et demandez une explication, un test unitaire, ou une revue de sécurité légère. Ajoutez explicitement les fichiers nécessaires via les mécanismes d’attachement de Continue (libellés variables selon version) plutôt que de coller tout le dépôt. Posez des consignes claires : langage, style du projet, « ne invente pas d’API ». Vérifiez toujours le diff avant d’accepter une édition. Pour du PHP Symfony ou du Python Django typiques des stacks HdF, fournissez un extrait de conventions (nommage, couche service) dans le prompt système Continue si votre version le permet.
Évaluer le confort sans chiffres inventés
Construisez une petite grille qualitative : latence perçue à la tabulation (agréable / acceptable / bloquant), pertinence des suggestions sur votre stack, taux de rejets manuels, bruit ventilateur, stabilité après une heure. Notez la machine (CPU/GPU/RAM) et le tag modèle dans un README d’équipe. Ne publiez pas de « tok/s » comme vérité IAHDF : mesurez chez vous si besoin avec les outils du runtime, pour vous. Si le confort est insuffisant, réduisez le modèle, la quantification, ou le contexte — ou réservez Continue au chat ponctuel plutôt qu’à la complétion permanente.
Durcir le poste avant le code sensible
Vérifiez qu’aucun provider cloud n’est resté actif dans Continue. Documentez pour l’équipe : tag Ollama, version Continue, URL locale uniquement. Ajoutez le fichier de config Continue au dépôt seulement s’il ne contient pas de secrets ; sinon, gardez un modèle de config sans clés. Pour les données et secrets, relisez les bonnes pratiques internes et, côté culture IAHDF, les rappels sur ce qu’il ne faut pas coller dans un prompt. Quand le poste est stable, ouvrez un vrai projet — toujours avec revue humaine du code généré.
Installer Continue et éviter les pièges cloud
Continue propose souvent un onboarding qui mentionne des modèles distants. Pour ce tutoriel, votre objectif est explicite : backend local seulement. Après installation, ouvrez la configuration et listez les modèles déclarés. Supprimez ou commentez toute entrée qui pointe vers une API hébergée tant que votre politique l’interdit. Si une fonctionnalité « indexation du codebase » envoie des embeddings ailleurs, désactivez-la ou configurez-la pour rester locale selon la doc du jour.
Gardez Continue à jour via le marketplace, mais épinglez mentalement la version qui « marchait » sur le poste de démo : une mise à jour peut renommer des clés YAML. En atelier à Lens, prévoyez une config modèle (fichier d’exemple) que les participants copient plutôt que de cliquer au hasard dans l’UI.
Choisir le modèle de code open source
Les familles évoluent vite. Ce qui comptait il y a six mois (taille, licence, support Ollama) peut être dépassé. La méthode durable : (1) lister les besoins (langages du projet, licence acceptable pour votre structure, VRAM disponible), (2) ouvrir la documentation officielle Ollama / éditeur du modèle le jour J, (3) copier le tag exact, (4) tester sur votre dépôt d’essai avec la même grille qualitative.
Privilégiez les modèles explicitement positionnés pour le code si votre usage principal est la complétion. Un modèle généraliste « chat » peut expliquer du code correctement mais compléter moins bien. Inversement, un modèle code peut être moins à l’aise pour rédiger un mail métier — ce n’est pas le sujet ici. Ne citez pas de classement IAHDF : il n’y en a pas.
# Vérifier Ollama ollama --version # Copier le tag EXACT depuis la doc / bibliothèque du jour # (exemple de forme — ne pas inventer le suffixe) ollama pull TAG_EXACT_MODELE_CODE # Essai conversationnel hors VS Code ollama run TAG_EXACT_MODELE_CODE # Lister les modèles locaux ollama list # Exemple d’extrait de config Continue (schéma à adapter à la doc Continue du jour) # models: # - name: code-local # provider: ollama # model: TAG_EXACT_MODELE_CODE # apiBase: http://localhost:11434
Autocomplétion : gestes et limites
L’autocomplétion locale brille sur les motifs répétitifs du projet : wrappers d’API internes, formulaires Symfony, fixtures de test. Elle se trompe sur les API peu représentées dans le contexte ouvert, les libs maison sans docstring, et les règles métier implicites. Traitez chaque suggestion comme une proposition de collègue junior : lisez, compilez, testez.
Si la suggestion arrive trop tard pour votre rythme de frappe, baissez le contexte, changez de quantification, ou désactivez la complétion et gardez uniquement le chat à la demande. Un assistant lent en permanence fatigue plus qu’il n’aide. Sur un portable de mission à Saint-Quentin, le mode chat ponctuel est souvent le meilleur compromis batterie / chaleur / utilité.
Chat et édition assistée
Le chat Continue sert à expliquer un module, générer des tests, proposer un refactor ciblé, ou traduire un snippet. Fournissez la sélection pertinente plutôt que « tout le repo ». Demandez un format de sortie exploitable (diff, liste de fichiers touchés, critères d’acceptation). Refusez les réponses qui inventent des packages Composer ou npm inexistants : vérifiez sur packagist / npm avant d’installer.
Pour une équipe mixte (devs confirmés + stagiaires d’une école lilloise), documentez deux prompts types dans le wiki interne : « explique pour revue » et « propose un test PHPUnit ». Homogénéiser les prompts réduit les écarts de qualité entre personnes.
Juger les performances sans folklore
Mesurez ce qui compte pour vous : délai avant première suggestion, délai de réponse chat sur un fichier de taille typique, charge GPU pendant la frappe, stabilité après veille Windows. Si vous instrumentez avec les logs Ollama ou un outil système, gardez les résultats dans un compte-rendu interne daté — pas comme benchmark public « validé IAHDF ».
Quand plusieurs personnes partagent une machine (salle projet à Tourcoing), un seul gros modèle chargé peut saturer la VRAM : coordonnez les plages, ou montez un service partagé plus sérieux (voir serveur GPU France et, pour de la charge multi-utilisateurs type API, vLLM en production).
| Symptôme | Vérifier d’abord |
|---|---|
| Continue : erreur de connexion | Ollama démarré, URL locale, tag exact |
| Complétion très lente | VRAM libre, taille contexte, autres process GPU |
| Suggestions hors sujet | Fichier / sélection joints, modèle « code » vs chat |
| Code inventé (libs fantômes) | Revue humaine + vérif registry packages |
| Fuite cloud involontaire | Providers dans config Continue, clés API absentes |
Déployer dans une équipe HdF
Standardisez une config Continue « local only », un tag Ollama validé ensemble, et une page wiki : installation, dépannage proxy, qui contacter. Interdisez le mélange cloud/local sur les dépôts réglementés sauf décision écrite. Formez à la revue de code assistée : l’outil accélère la frappe, pas l’acceptation aveugle.
Pour les freelances et TPE de la région, le bénéfice immédiat est souvent pédagogique (apprendre une API) autant que productif. Gardez un œil sur la dette : trop de code généré non compris devient un coût de maintenance.
Limites franches
Continue + Ollama ne remplace pas un linter, une CI, ni un pair humain sur une revue de sécurité. Les modèles de code hallucinent des fonctions, des flags CLI et des schémas SQL. Sur du legacy COBOL ou des DSL maison rares, attendez-vous à peu de magie. Si votre besoin est « 50 utilisateurs en parallèle sur une API », ce n’est plus un poste VS Code : orientez-vous vers un serveur d’inférence.
Questions fréquentes
Est-ce vraiment une alternative à Copilot ?
Pour le geste « compléter et discuter du code sans l’envoyer dehors », oui, avec un confort qui dépend de votre GPU et du modèle. Copilot cloud reste souvent plus fluide sur machines modestes. Le critère décisif chez beaucoup d’équipes HdF est la souveraineté du code, pas un score de benchmark. Testez deux semaines sur un vrai projet avant de trancher.
Quel tag modèle dois-je utiliser ?
Celui publié le jour J dans la documentation officielle Ollama (ou du runtime choisi) pour la famille de modèles de code que vous retenez. Ne recopiez pas un tag d’un tutoriel ancien. Vérifiez licence, taille approximative et quantification sur la fiche, puis validez chez vous avec votre grille qualitative.
Puis-je m’en passer de GPU NVIDIA ?
Oui, avec des limites de confort. Apple Silicon, certains GPU AMD, ou un gros CPU peuvent servir, surtout avec un modèle plus petit ou une quantification plus serrée. Le geste Continue reste identique. Jugez la latence sur votre stack réelle plutôt que sur une démo marketing.
Continue envoie-t-il mon code par défaut ?
Cela dépend de la configuration et des providers activés. Avec un backend Ollama local uniquement et sans indexation cloud, le trafic utile reste sur la machine. Auditez la config après chaque mise à jour d’extension. En cas de doute, coupez le réseau pendant un essai et vérifiez que le chat local fonctionne encore.
Comment partager la config en équipe sans secrets ?
Versionnez un fichier d’exemple sans clés, documentez le tag Ollama, et laissez chaque poste pointer vers localhost. Les secrets d’éventuels providers cloud n’ont rien à faire dans le dépôt. Un README d’une page à Arras vaut mieux qu’un long wiki non lu.