Tabby est souvent l'un des premiers noms que regardent les équipes qui veulent un assistant de programmation dont le code ne quitte jamais le réseau interne. C'est un assistant de programmation par IA auto-hébergé, centré sur la complétion de code, avec aussi des fonctions de questions-réponses et de discussion, souvent vu comme une alternative déployable en local à GitHub Copilot. L'attrait est direct : le service tourne sur votre propre serveur, l'inférence se fait dans le réseau, il fonctionne hors ligne et n'envoie aucune télémétrie à l'extérieur. Pour les équipes soumises à des règles de conformité strictes, cette prémisse peut peser plus qu'une complétion un peu plus intelligente.
Informations sur le dépôt officiel
La plateforme est GitHub, l'organisation s'appelle TabbyML et le projet tabby, qui a dépassé les 33 000 étoiles sur GitHub. Le projet fournit des extensions pour les éditeurs courants, dont VS Code et la famille JetBrains, et peut indexer les dépôts connectés, de sorte que la complétion s'appuie sur le contexte du projet en cours au lieu de deviner à partir d'un seul fichier.
Pourquoi des équipes le choisissent
Les outils en nuage démarrent vite, mais le code doit partir vers un service extérieur, et les contextes de la finance, de l'administration et de la grande industrie échouent souvent à l'examen interne sur ce point précis. Tabby trace la frontière à l'intérieur du réseau : la forme officielle est un service autonome lancé par une seule commande Docker, sans dépendance à une base de données externe ni à un arrière-plan en nuage. Une machine dotée d'une carte graphique suffit pour commencer, les cartes grand public sont prises en charge, et le fonctionnement peut être entièrement hors ligne. Un service partagé unique permet aussi à l'administration de regrouper les accès en un seul endroit, au lieu d'abonnements extérieurs pris séparément par chacun.
Les deux factures : matériel et exploitation
La première facture est la carte graphique. Le modèle de code en arrière-plan se choisit soi-même ; parmi les choix courants de cette catégorie figurent StarCoder, CodeLlama, DeepSeek-Coder et les modèles de code Qwen, et le plafond de qualité de la complétion est fixé par le modèle retenu. Un modèle plus grand complète en général mieux et consomme aussi plus de mémoire vidéo ; pour un service partagé en équipe, il faut une marge pour les utilisateurs simultanés, et une machine à GPU allumée en permanence ajoute l'électricité et le refroidissement aux coûts de long terme. La seconde facture est l'exploitation. Démarrer le conteneur n'est que le début : l'indexation des dépôts reste à votre charge, et les changements de modèle, les montées de version et les diagnostics de mémoire insuffisante tombent de votre côté. Vérifiez aussi la frontière avant le déploiement : la gestion des utilisateurs au niveau de l'équipe et des analyses plus fines relèvent du périmètre de l'édition entreprise, donc distinguez d'avance ce que couvre la partie open source auto-hébergée de ce qui demande une décision séparée, au lieu de découvrir le manque après la mise en service.
Les vrais pièges et les limites
L'écart le plus net est la qualité de complétion. Face aux outils de programmation en nuage les plus avancés, un petit modèle local traite correctement le code court et les fragments routiniers, mais peine sur les raisonnements complexes à travers plusieurs fichiers, et ses propositions demandent davantage de relecture humaine. Une équipe qui attend le remplacement à l'identique de la meilleure expérience en nuage ressentira nettement la baisse. Ce n'est pas non plus l'option sans effort : index, modèles et compatibilité des extensions demandent un suivi continu, sans le confort d'ouverture immédiate d'un service en nuage. Sa valeur ne grandit que lorsque la condition selon laquelle le code ne doit pas quitter le réseau est réellement vraie et que l'équipe accepte d'en porter les coûts de machine et d'exploitation ; l'auto-hébergement pour d'autres raisons est rarement rentable.
À qui il convient, et à qui il ne convient pas
Il convient aux petites équipes avec des exigences de conformité ou d'intranet, aux environnements hors ligne et aux équipes qui veulent regrouper leur service de complétion sous un même toit ; ces équipes acceptent des complétions un peu plus faibles en échange du code gardé à l'intérieur. Il ne convient pas aux développeurs individuels en quête de la meilleure qualité de complétion, pour qui essayer directement un outil en nuage est en général plus rentable, ni aux équipes sans serveur à GPU ou sans personne pour assumer l'exploitation. Avant de décider, faites-le tourner une semaine sur un dépôt réel et jugez les réussites de complétion, la vitesse de réponse et l'usage mémoire avant de le rendre permanent.
