Quel LLM choisir ? Trouver le modèle adapté à tes besoins

Tu hésites entre ChatGPT, Claude et Gemini, ou tu aimerais utiliser une IA directement sur ton PC ? Pour choisir, pars du travail que tu veux lui confier : rédiger un texte, comprendre un document, programmer ou automatiser une tâche. Le bon point de départ ne sera pas forcément le même.

Ces assistants s’appuient sur des grands modèles de langage, ou LLM (Large Language Models). Le modèle traite ta demande ; l’application détermine aussi les fichiers, les outils et les fonctionnalités auxquels tu as accès. Choisir un assistant en ligne et choisir un modèle à installer sur ton ordinateur sont donc deux décisions liées, avec des contraintes différentes.

Ce guide t’aide à choisir un LLM selon ton usage, ton budget et ton matériel. Il présente sept modèles de référence, locaux et cloud, avec des pistes pour commencer et les compromis à connaître. Le tableau ci-dessous te donne une première orientation ; les portraits et la méthode de comparaison t’aident ensuite à vérifier ce choix sur ton propre travail.

Quel LLM choisir selon ton usage ?

Repère la ligne qui correspond à ton besoin principal et commence par la piste proposée. Lorsque plusieurs modèles sont cités, choisis d’abord selon les outils dont tu disposes ou les ressources de ta machine. Tu pourras ensuite comparer les résultats avant de changer d’abonnement ou de t’équiper.

Ces recommandations sont des points de départ, pas des spécialités exclusives. Elles reposent sur les caractéristiques documentées des modèles et les évaluations disponibles, sans prétendre à un comparatif réalisé par TekBrut.

Pour départager deux candidats, commence par une tâche que tu connais et compare les corrections nécessaires pour obtenir un résultat utilisable. Les sections suivantes détaillent les capacités, les outils et les coûts à prendre en compte.

Comprendre ce que tu choisis vraiment

Quand tu utilises ChatGPT, Claude ou Gemini, tu ne dialogues pas simplement avec un modèle d’intelligence artificielle. Tu passes par une application qui te propose différentes fonctionnalités : conversation, analyse de documents, recherche d’informations ou utilisation d’outils. Le modèle est chargé de traiter ta demande et de produire une réponse, mais l’environnement dans lequel il fonctionne détermine aussi ce que tu peux lui confier et ce qu’il peut accomplir.

Cette distinction est essentielle pour faire un choix pertinent. Un modèle capable d’analyser un document ne pourra pas nécessairement le faire dans toutes les applications qui le proposent. De même, ses compétences en programmation ne signifient pas que ton assistant pourra accéder à un projet, parcourir ses fichiers ou exécuter des tests dans l’environnement du projet. La qualité du modèle compte, mais les possibilités de l’outil qui l’accompagne peuvent être tout aussi déterminantes.

La nature des contenus que tu souhaites analyser constitue un autre critère important. Si le texte reste au cœur de leur fonctionnement, certains modèles peuvent également traiter des images, des enregistrements audio ou des vidéos. On parle alors de LLM multimodaux.

Cette capacité prend tout son intérêt lorsque ton travail ne se limite plus à une conversation écrite : interpréter un graphique, examiner une capture d’écran ou confronter un document à un enregistrement ne mobilise pas nécessairement les mêmes fonctionnalités.

Mais accepter un fichier ne signifie pas toujours en exploiter correctement tout le contenu. Un PDF peut, par exemple, être traité à partir de son texte extrait, sans que sa mise en page, ses tableaux ou ses illustrations soient fidèlement interprétés. Au-delà des formats annoncés, c’est donc la manière dont ton outil exploite réellement tes documents qui mérite ton attention.

La quantité d’informations transmise compte également. La fenêtre de contexte définit la quantité de contenu qu’un modèle peut prendre en compte lors d’une même demande. Pour le texte, cette capacité se mesure en tokens, des unités qui représentent des mots, des fragments de mots ou des signes.

Tes instructions, les documents transmis et la partie de l’historique conservée puis envoyée par l’application occupent cet espace, qui doit également tenir compte de la place nécessaire à la réponse. Une fenêtre plus étendue permet donc de fournir davantage d’informations au modèle en une seule fois.

Cette capacité ne garantit toutefois pas que toutes les informations seront correctement exploitées. Un modèle peut accepter un rapport de cent pages sans nécessairement en comprendre chaque détail ni retrouver tous les éléments importants. Une décision peut passer inaperçue, un passage être mal interprété ou deux informations être confondues. Et contrairement à une mémoire persistante, la fenêtre de contexte ne permet pas, à elle seule, de conserver des informations d’une conversation à l’autre.

Au-delà des contenus qu’il peut traiter, regarde aussi les actions que ton assistant peut réaliser. Certains systèmes utilisent des outils externes pour rechercher une information, consulter un fichier ou lancer une commande. On parle alors d’appel d’outils, ou tool calling : le modèle demande une opération, puis une couche logicielle transmet cette demande à l’outil concerné, récupère son résultat et applique les règles d’autorisation prévues.

LLM et agent IA : quelle différence ?

Les appels d’outils peuvent aussi s’inscrire dans un travail plus large, où le modèle choisit les étapes à suivre et les adapte aux résultats obtenus. C’est le principe d’un agent IA.

Un agent n’est pas simplement un LLM plus performant. C’est un système qui s’appuie sur un modèle pour poursuivre un objectif, décider des actions à entreprendre et exploiter leurs résultats pour faire progresser son travail. Là où une conversation classique peut t’expliquer comment corriger un programme, un agent disposant des outils et des autorisations nécessaires peut examiner les fichiers d’un projet, proposer des modifications, exécuter des tests et ajuster son travail en fonction des erreurs rencontrées.

Cette capacité à enchaîner des actions ne signifie pas pour autant qu’un agent est automatiquement plus fiable qu’un assistant conversationnel. Son autonomie reste encadrée : certaines opérations peuvent nécessiter ton intervention ou ton approbation. Et contrairement à une automatisation dont toutes les étapes sont définies à l’avance, un agent peut adapter son déroulement aux informations qu’il découvre.

Pour organiser ce fonctionnement, les systèmes agentiques s’appuient sur un environnement logiciel souvent appelé harness, ou agent harness. Celui-ci encadre l’exécution du modèle, organise les interactions avec les outils et contribue à la gestion du contexte au fil du travail. Il peut être intégré directement à l’application ou fonctionner comme une couche distincte.

Pour choisir un assistant destiné à programmer, analyser des données ou automatiser certaines tâches, examine donc les outils réellement disponibles, les ressources auxquelles ils peuvent accéder et les opérations qui nécessitent ton autorisation. Ces possibilités concrètes comptent autant que les capacités annoncées du modèle.

↑ Retour au sommaire

Local ou cloud : quels compromis pour ton usage et ton budget ?

Choisir entre un modèle accessible dans le cloud et un LLM exécuté localement ne revient pas simplement à décider si tu préfères installer un logiciel ou ouvrir une application. Ce choix détermine où les calculs sont effectués, quelles ressources sont nécessaires et jusqu’où tu peux maîtriser ton environnement de travail. Il influence également la confidentialité de tes données, les performances accessibles et, bien entendu, le coût de ton utilisation.

Avec le cloud, les calculs sont réalisés sur les serveurs d’un fournisseur. Tu peux ainsi profiter de modèles exigeants sans posséder le matériel nécessaire pour les faire fonctionner chez toi. L’accès est généralement plus simple, les mises à jour sont prises en charge par le service et tu n’as pas à gérer toi-même l’infrastructure. En contrepartie, tu dépends des conditions du fournisseur, des fonctionnalités proposées et des limites de ton offre. Tes données sont également traitées à distance, selon des règles qui varient d’un service à l’autre.

En local, le modèle fonctionne sur ton propre ordinateur. Tu peux choisir les modèles que tu installes et conserver davantage de contrôle sur leur environnement d’exécution. Cette autonomie a toutefois ses exigences : le matériel doit être suffisamment dimensionné, les performances dépendent de ta configuration et l’installation demande parfois davantage de travail. Le local n’est donc ni automatiquement plus économique, ni nécessairement plus performant. Son principal intérêt réside dans la maîtrise qu’il peut t’apporter, à condition d’en accepter les contraintes.

Combien coûte réellement ton choix ?

Le coût constitue souvent l’un des principaux critères de choix, mais comparer le prix d’un abonnement à celui d’une carte graphique ne suffit pas. Pour comprendre ce que tu vas réellement dépenser, il faut distinguer trois situations : utiliser un assistant en ligne, accéder à un modèle par l’API d’un fournisseur cloud ou faire fonctionner un LLM sur ton propre matériel.

Avec un abonnement cloud, tu paies généralement un montant régulier pour accéder à une application, à ses modèles et à certaines fonctionnalités, dans les limites de l’offre souscrite. Une API permet quant à elle d’intégrer un modèle à tes propres outils. Lorsqu’elle est proposée par un fournisseur cloud, son utilisation est souvent facturée selon la quantité de données traitées, notamment les tokens envoyés et générés.

L’abonnement à une application n’inclut pas nécessairement l’utilisation de son API : les accès et la facturation peuvent être séparés. Cette distinction devient importante lorsque tu automatises des tâches ou analyses de nombreux documents. Une utilisation occasionnelle et un traitement intensif ne représentent pas nécessairement le même budget.

OAuth, API et abonnement : trois notions différentes

Lorsque tu connectes un logiciel à un service, trois notions peuvent entrer en jeu.

L’API permet aux logiciels de communiquer entre eux. OAuth est un mécanisme d’autorisation qui permet à une application d’accéder, avec ton accord, à certaines ressources d’un service sans que tu aies à lui transmettre ton mot de passe. Cet accès repose généralement sur des jetons d’accès. Toutes les API n’utilisent cependant pas OAuth : certaines fonctionnent notamment avec des clés API.

L’abonnement et les conditions commerciales déterminent, quant à eux, les usages inclus et leur éventuelle facturation. Selon le service et le logiciel utilisé, un accès autorisé par OAuth peut relever des fonctionnalités comprises dans ton abonnement ou d’une facturation distincte.

À retenir : le mode de connexion ne détermine pas à lui seul ce que tu peux utiliser gratuitement ou non. Ce sont les droits et les conditions prévus par le fournisseur qu’il faut vérifier.

En local, la dépense ne disparaît pas : elle change de nature. Si tu possèdes déjà un ordinateur suffisamment équipé, tu peux exécuter certains modèles sans payer chaque requête à un fournisseur. Il reste néanmoins la consommation électrique, les éventuelles évolutions matérielles et le temps consacré à l’installation et à la maintenance.

Si tu dois acheter une carte graphique ou monter une machine spécialement pour cet usage, l’investissement initial peut devenir conséquent. Et rien ne garantit qu’il sera amorti par rapport à un abonnement.

Le bon calcul dépend donc autant de ton matériel actuel que de la fréquence et de la nature de ton utilisation. Quelques demandes par semaine ne justifient pas nécessairement l’achat d’une machine dédiée. À l’inverse, un PC déjà bien équipé peut rendre l’exécution locale particulièrement intéressante, à condition que les modèles qu’il peut accueillir répondent réellement à tes besoins.

Au-delà du budget, le confort d’utilisation mérite également d’être pris en compte. Selon le matériel, son refroidissement et la charge de travail, la chaleur dégagée et le bruit des ventilateurs peuvent devenir gênants, particulièrement dans une petite pièce ou un environnement de travail partagé. Ce sont des contraintes parfois secondaires pour un usage ponctuel, mais qui peuvent peser davantage lorsque les modèles fonctionnent plusieurs heures par jour.

Si tu envisages de t’équiper, notre guide Quel PC pour l’IA locale ? t’aidera à comprendre les besoins en mémoire, le rôle de la carte graphique et les compromis matériels à connaître avant d’investir.

Confidentialité, souveraineté et autonomie

Le budget n’est toutefois pas le seul critère : la nature des données que tu comptes traiter peut orienter ton choix. Cette question devient particulièrement importante lorsque tu travailles avec des informations personnelles, des documents professionnels ou des données sensibles. Reformuler un texte destiné à être publié n’implique pas les mêmes précautions qu’analyser des contrats, des dossiers clients ou des documents internes à une entreprise.

Dans le cloud, les informations que tu transmets sont traitées sur l’infrastructure du fournisseur. Cela ne signifie pas qu’elles deviennent publiques ou qu’elles sont systématiquement utilisées pour entraîner ses modèles. Les conditions varient selon les services et parfois entre une application grand public, une offre professionnelle et une API.

Avant de confier des données sensibles à un assistant, il est donc important de comprendre comment elles sont utilisées, combien de temps elles peuvent être conservées et quelles garanties de confidentialité s’appliquent réellement à ton offre. Pour des documents professionnels, vérifie également que l’utilisation envisagée et le service choisi sont autorisés par ton organisation.

Cette question rejoint celle de la souveraineté des données. Derrière ce terme se trouve un enjeu plus large que leur simple protection : savoir où tes informations sont stockées et traitées, qui peut y accéder, quelles règles juridiques encadrent leur utilisation et dans quelle mesure tu dépends d’un prestataire. La localisation géographique d’un serveur ne suffit donc pas, à elle seule, à garantir une maîtrise complète de tes données.

Le local permet d’aller plus loin dans cette maîtrise. Avec un modèle, une application et des outils fonctionnant entièrement sur ta machine, tes documents peuvent être analysés sans être envoyés à un fournisseur externe.

Mais cette confidentialité dépend de l’ensemble de ton installation : un connecteur distant, une synchronisation automatique ou une fonctionnalité reposant sur une API distante peuvent faire circuler des informations hors de ton ordinateur, même si le modèle principal fonctionne localement.

Tu restes également responsable de la sécurité de ta machine, de ses accès et de tes sauvegardes. Exécuter un LLM en local te donne davantage de contrôle sur tes données, mais ne dispense pas de protéger l’environnement qui les accueille.

L’autonomie constitue une autre différence importante. Un assistant cloud dépend d’une connexion Internet, de la disponibilité du service et des limites imposées par ton offre. Une installation entièrement locale peut continuer à fonctionner hors ligne, une fois les composants nécessaires téléchargés.

En contrepartie, tu dois gérer son fonctionnement, ses mises à jour et les ressources qu’elle mobilise sur ton ordinateur. Ce qui représente une contrainte pour certains utilisateurs peut aussi être un avantage pour ceux qui souhaitent conserver la maîtrise de leurs outils.

Ces deux approches ne sont d’ailleurs pas incompatibles. Tu peux parfaitement privilégier un assistant cloud pour certaines tâches et réserver un modèle local aux documents que tu préfères conserver sur ton ordinateur. L’essentiel n’est pas de choisir un camp, mais de comprendre ce que chaque solution te permet de faire, ce qu’elle exige et les compromis que tu es prêt à accepter.

↑ Retour au sommaire

Les modèles cloud : leurs intérêts et leurs limites

Maintenant que nous avons posé les principaux critères de choix, intéressons-nous aux modèles eux-mêmes. Les trois références cloud retenues dans ce guide ne constituent ni un classement des meilleurs LLM, ni une sélection exhaustive. Elles illustrent différentes approches du travail avec l’intelligence artificielle, depuis la rédaction et l’analyse de documents jusqu’à la programmation et au traitement de contenus multimédias.

Pour chacune, nous examinerons ce qui justifie sa présence dans cette sélection, les usages pour lesquels elle mérite d’être envisagée et les limites à connaître. Nos recommandations reposent sur les capacités documentées et les évaluations disponibles, sans prétendre à des tests comparatifs réalisés par TekBrut.

Claude Sonnet 5.5 : un modèle polyvalent pour le travail quotidien

Tous les travaux ne nécessitent pas de mobiliser le modèle le plus puissant ou le plus coûteux d’une gamme. C’est précisément dans cette logique que s’inscrit Claude Sonnet 5.5, développé par Anthropic. L’éditeur le présente comme un complément plus rapide et moins coûteux à Opus 5.5 pour les tâches bien délimitées, notamment la rédaction et la révision de documents, l’analyse d’informations ou la correction de code.

Ses tarifs API sont inférieurs à ceux d’Opus, mais le coût final et le temps nécessaire dépendent aussi du travail demandé et du niveau d’effort utilisé. Son intérêt réside donc dans le compromis qu’il propose entre capacités, rapidité et coût d’utilisation.

Prenons un document professionnel qui mélange décisions actées, propositions encore ouvertes et informations parfois contradictoires. Le véritable enjeu n’est pas simplement d’obtenir un résumé agréable à lire, mais de restituer fidèlement ce qui a été décidé, de distinguer les hypothèses des engagements et d’identifier les passages qui demandent une clarification.

C’est un exemple de travail pour lequel Sonnet 5.5 mérite d’être envisagé. Tu peux lui demander une version restructurée du document, accompagnée des ambiguïtés relevées et des passages qui justifient ses conclusions. Une reformulation élégante reste inutile si elle transforme une simple suggestion en décision officielle.

Sonnet 5.5 peut également analyser du code, proposer des corrections et aider à comprendre l’origine d’une erreur. Pour intervenir sur un projet plutôt que commenter du code dans une conversation, il faut toutefois un environnement donnant accès aux fichiers, aux modifications et aux tests, comme Claude Code. Les outils disponibles et les autorisations accordées déterminent alors jusqu’où l’assistant peut réellement intervenir.

Cette polyvalence a néanmoins ses limites. Selon Anthropic, Opus 5.5 conserve un avantage sur les travaux complexes et ouverts qui exigent de maintenir un jugement cohérent sur une longue durée.

Sonnet peut lui aussi participer à des missions agentiques exigeantes, mais ses avantages de rapidité et de coût ne suffisent pas à en faire systématiquement le choix le plus pertinent. Pour les projets ouverts qui demandent de maintenir des arbitrages cohérents sur de nombreuses étapes, Opus 5.5 mérite donc aussi d’être comparé.

Ses capacités multimodales ont également un périmètre précis. Sonnet 5.5 accepte le texte et les images en entrée, mais produit des réponses textuelles. Sa documentation API ne prévoit pas de traitement natif des entrées audio ou vidéo.

Une application peut proposer des fonctionnalités supplémentaires, comme la transcription d’un enregistrement avant son analyse, mais elles ne doivent pas être confondues avec les capacités directement documentées du modèle. Cette distinction compte si tu travailles régulièrement avec des réunions enregistrées ou des contenus audiovisuels.

Côté pratique, tu peux utiliser Sonnet 5.5 directement dans l’application Claude, sous réserve des fonctionnalités et limites de ton offre. Les développeurs peuvent également y accéder par l’API d’Anthropic, sous l’identifiant claude-sonnet-5-5, avec une facturation distincte selon les conditions du service.

Sonnet 5.5 mérite donc d’être envisagé pour réviser des documents ou avancer sur des tâches de code bien définies. Si ton travail exige un jugement soutenu sur un projet ouvert ou le traitement natif de l’audio et de la vidéo, compare aussi les autres options du guide.

↑ Retour au sommaire

GPT-6.1 Sol : quand l’IA doit aussi faire avancer le travail

Corriger un bug ne consiste pas toujours à réécrire une fonction. C’est notamment pour les tâches qui demandent davantage qu’une réponse isolée que GPT-6.1 Sol, développé par OpenAI, mérite d’être considéré.

L’éditeur le positionne sur la programmation complexe, l’utilisation d’ordinateurs et les travaux professionnels nécessitant plusieurs étapes. Une particularité mérite toutefois d’être précisée dès le départ : au moment de son annonce, Sol est accessible dans Codex et ChatGPT Work, mais pas dans les conversations ChatGPT classiques.

Imaginons qu’une mise à jour provoque une erreur sur un site web. Un assistant conversationnel peut examiner le message d’erreur et suggérer des pistes de correction. Avec un environnement adapté, comme Codex, Sol peut aller plus loin : explorer les fichiers concernés, rechercher l’origine du problème, préparer un correctif et exécuter les tests disponibles.

Si ceux-ci révèlent une nouvelle anomalie, le système peut exploiter leurs résultats pour ajuster la proposition. L’intérêt n’est plus seulement d’obtenir une réponse plausible, mais de pouvoir confronter cette réponse au fonctionnement réel du projet.

Cette approche ne se limite pas au développement logiciel. Dans ChatGPT Work, Sol peut également contribuer à des tâches impliquant plusieurs documents, applications ou étapes de traitement, selon les outils et les autorisations disponibles. Préparer un rapport à partir de différentes sources, rechercher des informations dans un dossier ou organiser un travail documentaire sont autant de situations dans lesquelles cette capacité peut devenir utile.

Il ne s’agit pas d’une exclusivité de Sol, mais d’une bonne illustration de ce que nous avons expliqué précédemment : les capacités du modèle et celles de son environnement se complètent.

Pour départager ces systèmes, il faut donc regarder leurs résultats sur des tâches définies, mais aussi les ressources nécessaires pour les accomplir. Dans une comparaison indépendante d’Artificial Analysis, Sol au niveau d’effort Max obtient un meilleur résultat sur GDP.pdf, une évaluation portant sur l’analyse de documents professionnels complexes, qu’Opus 5.5 en configuration Max avec repli automatique.

Cette configuration d’Opus reste toutefois devant sur Terminal-Bench 4.0, consacré à la programmation agentique, ainsi que sur l’Intelligence Index de l’organisme. Ces résultats ne désignent pas un vainqueur universel : ils montrent que deux modèles très capables peuvent se départager différemment selon le travail demandé.

Le coût apporte un autre élément de décision. Aux tarifs API de base, les tokens d’entrée et de sortie de Sol coûtent moitié moins que ceux d’Opus 5.5. Cet avantage peut compter lorsque les appels se multiplient, mais il ne se traduit pas automatiquement par une facture divisée par deux : la quantité de contexte utilisée, l’effort de raisonnement et le nombre d’étapes nécessaires influencent le coût réel d’une mission.

Sonnet 5.5 affiche par ailleurs les mêmes tarifs API de base que Sol. Entre ces deux modèles, le prix par token ne suffit donc pas à faire la différence. Dans sa propre gamme, OpenAI présente également Sol comme une alternative à GPT-6 Astra, proche de ses performances sur certaines évaluations pour un tarif API sensiblement inférieur.

La fenêtre de contexte constitue un autre argument intéressant, à condition d’en comprendre les implications. La documentation API de Sol annonce une capacité pouvant atteindre 1,05 million de tokens, tandis que Codex et ChatGPT Work utilisent par défaut une fenêtre de 500 000 tokens. De tels volumes permettent d’envisager des travaux sur des dossiers importants, sans garantir que chaque information sera correctement retrouvée ou interprétée.

Il faut aussi tenir compte de la tarification : dans l’API, les requêtes dépassant 272 000 tokens en entrée entraînent une majoration appliquée à l’ensemble de la requête, et pas seulement à la partie dépassant ce seuil. Cette majoration spécifique ne concerne pas les usages couverts par l’abonnement dans Work et Codex.

Les capacités multimodales de Sol ont également leurs limites. Le modèle accepte le texte et les images en entrée, mais produit des réponses textuelles et ne traite pas nativement l’audio ou la vidéo. Ces contenus nécessitent donc des fonctionnalités ou des outils complémentaires.

Enfin, une modification peut corriger un problème tout en provoquant une régression ailleurs. Les tests disponibles, la revue des changements et les autorisations restent essentiels avant d’appliquer un correctif à des fichiers importants ou à des ressources partagées.

Côté pratique, l’accès à Sol dans ChatGPT Work et Codex dépend des forfaits éligibles et des conditions du service. Les développeurs peuvent également l’utiliser via l’API OpenAI, sous l’identifiant gpt-6.1-sol. Pour exploiter ses appels d’outils par cette voie, il faut utiliser la Responses API, avec les conditions de facturation correspondantes.

GPT-6.1 Sol mérite ainsi d’être envisagé lorsque ton travail nécessite d’exploiter plusieurs ressources, d’enchaîner des opérations et de vérifier leurs résultats. Son positionnement économique et ses résultats documentés sur certaines tâches professionnelles justifient sa présence dans cette sélection.

Opus 5.5 reste néanmoins à comparer, notamment au vu de ses résultats sur certaines évaluations de programmation agentique. Le choix dépendra autant de la nature du travail que de l’environnement dans lequel tu comptes le réaliser.

↑ Retour au sommaire

Gemini 4 Argon : quand les informations ne tiennent pas dans un seul format

Un document ne raconte pas toujours toute l’histoire. Une présentation peut contenir les chiffres d’un projet, tandis qu’un enregistrement vidéo en montre les résultats et qu’une discussion audio apporte des précisions absentes du support écrit. Analyser ces éléments séparément, c’est parfois passer à côté de ce qui les relie. Gemini 4 Argon, développé par Google DeepMind, mérite particulièrement d’être envisagé lorsque ton travail nécessite de réunir et de confronter plusieurs types de contenus.

Sa principale particularité, dans notre sélection cloud, tient à l’étendue de ses entrées multimodales documentées. Argon peut recevoir du texte, des images, des PDF, des enregistrements audio et des vidéos, puis produire une réponse écrite à partir de ces informations.

Là où certains outils doivent d’abord transformer un enregistrement en transcription textuelle, Argon dispose de capacités natives pour analyser directement les contenus audio et vidéo. Cette différence ne garantit pas une meilleure compréhension, mais elle élargit les possibilités de travail sur des sources qui ne se résument pas à du texte.

Imaginons que tu disposes d’une formation filmée et de son manuel PDF. Tu souhaites en tirer une procédure claire, mais certaines manipulations montrées à l’écran ne correspondent pas exactement aux instructions écrites.

Avec un accès prenant en charge ces deux formats, tu peux demander à Argon de reconstituer les étapes, d’identifier les divergences et de signaler les passages qui méritent une vérification. L’intérêt n’est pas simplement de résumer deux fichiers, mais de faire dialoguer leurs informations pour mieux comprendre l’ensemble.

Une limite mérite toutefois d’être connue : dans le traitement vidéo standard, les images sont échantillonnées par défaut à raison d’une par seconde. Une manipulation très brève peut donc échapper à l’analyse, ce qui rend indispensable le contrôle des passages importants dans la vidéo originale.

Il serait toutefois réducteur de présenter Argon comme un modèle consacré uniquement aux documents et à la vidéo. Google le positionne également sur la programmation complexe, le raisonnement scientifique et les tâches professionnelles nécessitant plusieurs étapes. Sa documentation prévoit notamment les appels d’outils, la recherche dans des fichiers et l’exécution de code. Dans un environnement adapté, comme Google Antigravity, il peut ainsi participer à des travaux agentiques.

Sa fenêtre de contexte apporte une autre dimension à ces usages. La Gemini API documente une capacité d’environ un million de tokens, avec une limite commune aux informations fournies et à celles générées. Cela permet d’envisager l’analyse de dossiers particulièrement volumineux, comprenant potentiellement plusieurs sources et formats.

Mais disposer d’un tel espace ne signifie pas que le modèle retrouvera systématiquement chaque détail. Plus les documents sont nombreux et hétérogènes, plus il devient important de vérifier les conclusions et de contrôler les références utilisées.

Les évaluations publiées par Google donnent quelques indications sur ses capacités. Sur LVBench, consacré à la compréhension de vidéos longues, Argon obtient 91,7 %, contre 83,7 % pour Claude Opus 5.5. Mais les conditions de comparaison méritent d’être examinées : Google indique avoir utilisé une image par seconde pour Argon et 600 images par vidéo pour Opus, en raison des limites des API. Les deux modèles ne reçoivent donc pas nécessairement la même représentation visuelle du contenu analysé.

Sur Terminal-Bench 4.0, consacré à la programmation agentique, le rapport s’inverse : Opus atteint 66,4 % contre 57,4 % pour Argon. Là encore, les résultats ne proviennent pas d’une confrontation entièrement réalisée dans un dispositif unique : Google a calculé celui d’Argon et repris celui d’Opus du classement officiel.

Ces chiffres restent des indications utiles, mais ils reflètent aussi les environnements et les méthodes employés pour évaluer les modèles. Nous reviendrons sur leur interprétation dans la section consacrée aux benchmarks.

Argon possède également des limites fonctionnelles à connaître. Malgré la variété des contenus qu’il peut analyser, il produit du texte et ne génère pas nativement d’images, d’audio ou de vidéos. Pour créer ces contenus, il faut recourir à d’autres modèles ou fonctionnalités. Le traitement de fichiers multimédias volumineux peut aussi représenter une consommation importante de tokens, avec des conséquences sur le coût lorsque tu utilises l’API.

Côté pratique, tu peux accéder à Argon dans l’application Gemini avec une offre Google AI Pro ou Ultra, sous réserve des fonctionnalités et limites associées. Les développeurs peuvent également l’utiliser via la Gemini API, sous l’identifiant gemini-4-argon.

Celle-ci propose Argon sur son palier payant, sans quota gratuit pour ce modèle. Google mentionne également la possibilité de l’essayer dans AI Studio pour les abonnés Google AI Ultra, un accès dont les conditions doivent être distinguées de la facturation des appels API.

Sur le plan tarifaire, Google annonce des prix de lancement jusqu’au 30 novembre 2026, puis une hausse à compter du 1er décembre 2026. Ces conditions sont susceptibles d’évoluer : mieux vaut donc consulter la grille tarifaire officielle avant de prévoir une utilisation intensive.

Attention également à ne pas confondre les capacités documentées de l’API avec les fonctionnalités effectivement accessibles dans l’application Gemini : les formats acceptés et leurs limites peuvent différer.

Gemini 4 Argon constitue donc une option particulièrement intéressante lorsque ton travail exige de croiser des documents, des images et des enregistrements tout en bénéficiant de capacités de raisonnement avancées. Pour des tâches principalement textuelles ou un projet de programmation, Sonnet et Sol restent des alternatives pertinentes.

Le choix d’Argon prend surtout son sens lorsque ses possibilités multimodales répondent à un besoin concret, plutôt que lorsqu’elles constituent simplement des fonctionnalités supplémentaires dont tu n’auras pas l’usage.

↑ Retour au sommaire

Les modèles locaux : choisir selon ton besoin et ta machine

Faire fonctionner un LLM sur son propre ordinateur introduit une contrainte supplémentaire : le modèle doit non seulement répondre à tes attentes, mais aussi fonctionner dans de bonnes conditions sur ton matériel. Deux modèles capables d’accomplir des tâches similaires peuvent imposer des exigences très différentes en matière de mémoire, de puissance de calcul et de confort d’utilisation.

Pour cette sélection, nous avons retenu quatre modèles de tailles différentes, sans chercher à établir une progression automatique du moins performant au plus puissant. Leurs capacités se recoupent, mais leur poids, leurs caractéristiques et les ressources nécessaires pour les exploiter peuvent orienter ton choix.

Nous utiliserons Ollama comme point de départ pratique, avec des variantes quantifiées qui réduisent la taille des modèles en diminuant la précision numérique de leurs paramètres. Cette compression facilite leur exécution sur du matériel plus accessible, au prix de possibles compromis sur la qualité des réponses.

Les tailles annoncées correspondent aux fichiers téléchargés : elles ne représentent pas la totalité de la mémoire nécessaire pendant l’utilisation, qui dépend également du contexte, des calculs et du logiciel employé.

Qwen3.5-4B : découvrir l’IA locale sans équipement démesuré

Faire ses premiers pas dans l’IA locale ne nécessite pas forcément une carte graphique haut de gamme. Avec ses quelque quatre milliards de paramètres, Qwen3.5-4B, développé par Alibaba Qwen, représente le modèle le plus léger de notre sélection. Son intérêt tient d’abord à cette accessibilité : permettre d’explorer des usages concrets sur des configurations moins ambitieuses, sans mobiliser d’emblée les ressources exigées par des modèles beaucoup plus volumineux.

Mais sa taille ne résume pas ses capacités. Qwen3.5-4B est un modèle multimodal, capable de traiter du texte et des images. Il prend également en charge le raisonnement et peut participer à des systèmes utilisant des appels d’outils, lorsque l’environnement logiciel le permet. Autrement dit, choisir un modèle compact ne signifie pas nécessairement renoncer aux fonctionnalités que l’on associe aujourd’hui aux assistants plus évolués.

Prenons un exemple concret. Tu souhaites remettre de l’ordre dans des notes d’inventaire contenant des descriptions incomplètes, des références de matériel et quelques photographies d’étiquettes. Tu peux demander à Qwen d’organiser les informations, de distinguer les références identifiées de celles qui restent incertaines et, avec une interface adaptée, d’examiner les images pour compléter certains champs.

L’intérêt est de pouvoir traiter ce travail directement sur ta machine, tout en conservant la possibilité de vérifier chaque information à partir des documents originaux. Cette capacité ne garantit évidemment pas une transcription parfaite des références photographiées.

Pour démarrer, la variante qwen3.5:4b proposée par Ollama représente environ 3,3 Go de fichiers dans sa déclinaison llama.cpp, composant de vision compris. Les poids du modèle de langage utilisent une quantification Q4_K_M.

La page propose également une déclinaison MLX d’environ 4 Go, destinée aux environnements Apple Silicon. Une fois Ollama installé, la commande ollama run qwen3.5:4b permet de lancer un premier échange. Cette voie d’accès est documentée, mais n’a pas fait l’objet d’un essai spécifique par TekBrut dans le cadre de ce guide.

Attention toutefois à ne pas confondre la taille des fichiers téléchargés avec la mémoire nécessaire au fonctionnement du modèle. Celui-ci doit également disposer d’espace pour traiter le contexte et réaliser ses calculs. Une exécution sur processeur est envisageable, mais son confort dépendra de la machine et des réglages utilisés. Une carte graphique compatible peut accélérer le traitement, sans être une condition absolue pour commencer.

La documentation de Qwen annonce par ailleurs une fenêtre de contexte native de 262 144 tokens, une capacité importante pour un modèle de cette taille. Mais pouvoir théoriquement accueillir un long document ne signifie pas qu’une configuration modeste pourra exploiter cette fenêtre dans son intégralité.

Dans Ollama, la fenêtre effectivement utilisée dépend également des réglages : lancer le modèle n’active pas nécessairement toute cette capacité. À mesure que le contexte augmente, les besoins en mémoire et les contraintes d’exécution peuvent devenir déterminants.

Cette compacité ne permet toutefois pas de présumer de sa fiabilité sur tous les travaux. Pour des instructions complexes, des raisonnements prolongés ou des documents comportant de nombreuses informations interdépendantes, il faut vérifier que la variante utilisée répond réellement à tes exigences.

Les capacités de raisonnement et d’appel d’outils documentées ne suffisent pas non plus à garantir une exécution agentique fiable. Qwen3.5-4B mérite d’être considéré pour ce qu’il permet d’accomplir avec des ressources contenues, pas parce qu’il serait capable de remplacer systématiquement des modèles beaucoup plus exigeants.

Ses poids sont distribués sous licence Apache 2.0, ce qui offre une liberté appréciable pour l’utilisation et le déploiement, dans le respect des conditions de la licence. Cela ne signifie pas pour autant que l’ensemble de ses données d’entraînement et de sa chaîne de développement soient publiquement accessibles.

Qwen3.5-4B constitue ainsi un point de départ intéressant pour découvrir l’IA locale, organiser des informations, travailler sur des documents courts ou expérimenter certaines fonctionnalités multimodales sans téléchargement massif. Si les résultats ne répondent plus à tes exigences, d’autres modèles de notre sélection mériteront d’être comparés. Mais le passage à un modèle plus lourd devra se justifier par un bénéfice réel, pas simplement par un nombre de paramètres supérieur.

↑ Retour au sommaire

Ministral 3 8B Instruct : une autre approche du travail en local

Un assistant local ne sert pas uniquement à répondre à des questions. Il peut aussi participer à des tâches répétitives, organiser des informations et produire des résultats destinés à être réutilisés dans d’autres outils.

Pour ces usages, la capacité à respecter des instructions précises et à restituer les informations dans un format cohérent devient particulièrement intéressante. C’est dans cette perspective que Ministral 3 8B Instruct 2512, développé par le français Mistral AI, trouve sa place dans notre sélection.

Issu d’une famille conçue pour fonctionner sur des équipements locaux ou embarqués, Ministral 3 8B combine compréhension du texte et des images, prise en charge de nombreuses langues, appels d’outils et génération de réponses structurées.

Mistral documente explicitement le français parmi les langues prises en charge et met en avant le suivi des instructions système. Ces caractéristiques en font un candidat à considérer pour construire un assistant personnalisé, capable de respecter des consignes de présentation et de s’intégrer à un environnement logiciel.

Imaginons une petite entreprise qui reçoit régulièrement des demandes d’assistance technique. Les messages arrivent en français, parfois accompagnés d’une capture d’écran, et ne contiennent pas toujours toutes les informations nécessaires pour identifier le problème.

Avec une application adaptée, Ministral peut être utilisé pour analyser ces demandes, relever les éléments manquants et préparer une réponse claire pour le client. Il peut également restituer les informations sous une forme structurée, avec des champs distincts pour le matériel concerné, le problème signalé ou les vérifications à effectuer.

C’est notamment là que les sorties structurées, souvent présentées au format JSON, prennent leur intérêt. Plutôt que de produire uniquement un paragraphe destiné à être lu, le modèle peut fournir des informations organisées selon une structure définie par le logiciel.

Elles deviennent alors plus faciles à exploiter dans un tableau, une base de données ou un système de suivi. L’intérêt n’est plus seulement de générer une réponse, mais de produire un résultat qui puisse s’intégrer à un véritable processus de travail.

Avec un moteur compatible, le logiciel peut aussi imposer les champs et les types de valeurs attendus. Mais respecter cette structure ne garantit pas l’exactitude des informations : une référence de matériel erronée reste erronée, même dans un JSON parfaitement formé.

Ces possibilités ne sont pas exclusives à Ministral : Qwen3.5-4B prend lui aussi en charge les images et les appels d’outils. Ministral constitue une autre option à comparer, pas une étape automatiquement supérieure. Le fait que Mistral documente explicitement le français ne démontre pas, à lui seul, une meilleure qualité rédactionnelle dans cette langue. Pour départager les deux modèles, il faudra comparer leurs résultats sur les mêmes contenus et dans des conditions similaires.

Pour l’essayer localement, la variante ministral-3:8b disponible sur Ollama représente environ 6 Go de fichiers, avec une quantification Q4_K_M. Elle nécessite Ollama 0.13.1 ou une version ultérieure compatible et peut être lancée avec la commande ollama run ministral-3:8b.

Comme pour Qwen, cette taille correspond au téléchargement, pas à la mémoire totale mobilisée pendant l’exécution. Elle demande davantage d’espace de stockage que la variante Qwen3.5-4B retenue précédemment ; les besoins en mémoire et le confort d’exécution restent à examiner sur ta machine. Cette différence ne permet donc de présumer ni d’un gain de qualité, ni d’une vitesse d’exécution donnée.

Le modèle dispose d’une fenêtre de contexte de 262 144 tokens dans sa configuration documentée, présentée par Mistral comme une capacité de 256k. Cela ne signifie pas qu’elle sera entièrement disponible dès le premier lancement. Le contexte effectivement configuré, la mémoire de ta machine et les réglages du moteur d’inférence restent déterminants. Pour des échanges courts ou des tâches structurées, il n’est d’ailleurs pas nécessaire de mobiliser toute cette capacité.

Une distinction mérite également d’être faite entre les variantes de la famille. Nous retenons ici Ministral 3 8B Instruct, une version adaptée au dialogue et au suivi d’instructions. Mistral publie séparément une variante Reasoning, destinée à des usages de raisonnement plus approfondis. Les évaluations de cette dernière ne doivent donc pas être attribuées automatiquement à la version Instruct, pas plus que les performances des poids d’origine ne garantissent celles de leur conversion quantifiée.

Le modèle est distribué sous licence Apache 2.0, comme Qwen3.5-4B. Il peut également être utilisé à distance à travers les services de Mistral, sous l’identifiant ministral-8b-2512. Cette possibilité offre une autre manière de l’essayer sans l’héberger soi-même, mais elle implique alors de prendre en compte les conditions du service et le traitement distant des données.

Ministral 3 8B Instruct mérite donc d’être envisagé si tu souhaites construire un assistant local multilingue, travailler avec des consignes précises ou intégrer ses réponses à des outils existants. Face à Qwen3.5-4B, il demande davantage de ressources de stockage dans les variantes retenues, sans avantage général démontré par notre sélection documentaire. Son intérêt devra se confirmer sur les tâches que tu lui confies.

↑ Retour au sommaire

Gemma 4 12B-it : une approche différente de l’IA multimodale en local

Faire fonctionner un modèle multimodal sur son ordinateur ne consiste pas seulement à disposer de suffisamment de mémoire pour charger ses paramètres. Il faut aussi traiter les images, les sons et les différentes informations qui accompagnent une demande.

Ces opérations peuvent mobiliser des ressources supplémentaires et compliquer l’exécution locale. C’est précisément sur cet aspect que Gemma 4 12B-it, développé par Google DeepMind, propose une approche intéressante.

Avec près de douze milliards de paramètres, cette version appartient à la famille Gemma 4, mais se distingue par son architecture dite Unified. Là où de nombreux modèles multimodaux utilisent des encodeurs spécialisés pour préparer les images ou les sons avant de les transmettre au modèle de langage, Gemma 4 12B se passe de ces encodeurs séparés.

Il utilise des mécanismes de projection plus légers pour transmettre les informations visuelles et audio au même modèle. L’objectif est de simplifier leur traitement et de réduire certaines contraintes d’exécution.

Cette particularité ne signifie pas que Gemma comprend mieux les images ou les sons que les autres modèles. Elle décrit d’abord la manière dont Google a conçu leur traitement. C’est une distinction importante : une architecture innovante peut présenter des avantages techniques sans constituer, à elle seule, une preuve de supériorité dans les usages réels.

L’intérêt devient plus concret lorsqu’on examine ses capacités. Gemma 4 12B peut traiter du texte, des images et, dans un environnement compatible, des entrées audio natives, puis produire une réponse textuelle. Google documente toutefois une limite de 30 secondes pour les séquences audio : il ne faut donc pas assimiler cette capacité à la prise en charge directe d’un long enregistrement.

Imaginons que tu disposes d’un schéma annoté accompagné d’un court commentaire vocal expliquant les modifications qui y ont été apportées. Tu pourrais demander au modèle de rapprocher les informations visibles et les explications enregistrées pour préparer une synthèse des changements. Le tout peut être réalisé localement, sans envoyer ces documents à un service distant, si l’ensemble des outils utilisés fonctionne sur ta machine.

Le modèle peut toutefois mal lire une annotation ou interpréter incorrectement un passage audio. Les rapprochements proposés doivent donc être contrôlés dans les sources originales.

Google a également prévu un réglage intéressant pour le traitement des images : le budget de tokens visuels. Dans les environnements qui l’exposent, ce paramètre permet de choisir la quantité d’informations utilisée pour représenter une image.

Un budget plus élevé préserve davantage de détails, ce qui peut être utile pour examiner des caractères de petite taille ou un document complexe, mais demande aussi davantage de calculs. Un budget réduit privilégie au contraire la légèreté du traitement. C’est un exemple concret de compromis entre précision potentielle et ressources mobilisées, sans garantie qu’augmenter ce budget corrige toutes les erreurs de lecture.

Gemma 4 12B ne se limite pas pour autant à ces usages multimodaux. Le modèle prend également en charge le raisonnement, la programmation et les appels d’outils. Google le positionne notamment pour des applications locales et des systèmes agentiques. Mais ces capacités ne suffisent pas à démontrer qu’il accomplira mieux ces tâches que Qwen ou Ministral : la qualité des résultats devra être appréciée dans l’environnement et sur les travaux réellement envisagés.

Pour commencer, la variante gemma4:12b disponible sur Ollama représente environ 8 Go de fichiers dans sa déclinaison llama.cpp, dont les poids principaux utilisent une quantification Q4_K_M. Une déclinaison MLX d’environ 7,7 Go est également proposée. Une fois Ollama installé, la commande ollama run gemma4:12b permet de lancer le modèle.

Cette voie d’accès documente le texte et les images en entrée. La prise en charge native de l’audio par Gemma 4 12B ne signifie pas qu’elle est automatiquement disponible avec cette variante Ollama. Pour exploiter cette capacité, il faut utiliser une chaîne logicielle compatible, comme celle documentée par Google avec Hugging Face Transformers.

Sur le plan matériel, Google présente Gemma 4 12B comme un modèle pouvant fonctionner sur certaines configurations disposant de 16 Go de mémoire graphique ou de mémoire unifiée. Il ne s’agit pas d’une garantie de confort pour tout ordinateur équipé de 16 Go de RAM : la quantification, le moteur d’inférence, la fenêtre de contexte et les autres composants en mémoire influencent les besoins réels.

Le modèle dispose par ailleurs d’une fenêtre de contexte de 262 144 tokens, présentée comme une capacité de 256K, dont l’exploitation effective dépend des réglages et des ressources disponibles.

Cette richesse fonctionnelle implique quelques compromis. Gemma occupe davantage d’espace que les variantes de Qwen3.5-4B et Ministral 3 8B retenues précédemment. L’exploitation de certaines capacités, notamment l’audio natif, peut également demander une chaîne logicielle différente de la voie Ollama présentée ici.

Ce sont des contraintes à prendre en compte avant de choisir, particulièrement si ton objectif est de disposer d’un assistant local facile à installer et à entretenir.

Distribué sous licence Apache 2.0, Gemma 4 12B-it peut être utilisé et adapté dans les conditions prévues par cette licence. Cette ouverture facilite notamment son intégration à des applications locales et à des projets personnalisés, sans signifier que toute sa chaîne d’entraînement soit publiquement accessible.

Gemma 4 12B-it mérite donc d’être envisagé si tu souhaites explorer un modèle local polyvalent, dont l’architecture accorde une place particulière au traitement des images et de l’audio.

Son intérêt se trouve autant dans les possibilités ouvertes par cette conception que dans les compromis matériels qu’elle propose. Face à Qwen et Ministral, son choix doit toutefois reposer sur des capacités dont tu as réellement besoin et que ton environnement permet d’exploiter.

↑ Retour au sommaire

Qwen3.8-27B : des ambitions agentiques sur ton propre matériel

Faire fonctionner un assistant IA en local pour rédiger un texte ou analyser un document est une chose. Lui confier un travail de programmation qui demande d’examiner plusieurs fichiers, de prendre des décisions et d’adapter ses actions aux résultats obtenus en est une autre. Avec Qwen3.8-27B, développé par Alibaba Qwen, nous abordons un modèle dont les ambitions dépassent largement la conversation classique, tout en restant accessible à certaines configurations personnelles bien équipées.

Avec ses 27 milliards de paramètres, Qwen3.8-27B appartient à la catégorie des modèles denses, dont les paramètres sont mobilisés au cours du calcul, contrairement aux architectures à experts qui n’en activent qu’une partie à chaque étape. Qwen le positionne notamment sur la programmation, la recherche, les travaux professionnels complexes et les tâches agentiques de longue durée.

Son intérêt dans notre sélection tient à cette combinaison : disposer de capacités avancées dans un modèle dont les poids peuvent être téléchargés et exécutés localement, sans dépendre nécessairement d’un fournisseur cloud pour chaque demande.

Imaginons que tu développes un outil Python chargé de traiter des rapports internes. Au fil des modifications, certaines fonctions deviennent difficiles à maintenir et tu souhaites réorganiser le programme sans modifier ses résultats. Avec un environnement agentique adapté, Qwen peut examiner les fichiers, proposer une restructuration, demander l’exécution des tests existants et exploiter les erreurs éventuelles pour réviser sa proposition.

L’intérêt n’est plus seulement d’obtenir du code, mais de faire progresser un travail en confrontant les modifications à leurs conséquences réelles. Cette capacité dépend néanmoins des outils disponibles et ne garantit pas que chaque correction sera pertinente.

Les évaluations publiées par Qwen donnent des raisons de s’intéresser à ce potentiel. Sur DeepSWE 1.1, consacré à la programmation agentique, l’éditeur rapporte un score de 42,2 pour Qwen3.8-27B, contre 13,3 pour son prédécesseur Qwen3.6-27B. Les tests utilisent notamment le harness Claude Code et une fenêtre de contexte de 256K tokens.

Ces résultats indiquent une progression importante dans les conditions retenues par Qwen, mais ils concernent les modèles de référence et un environnement d’évaluation précis. Ils ne constituent pas une mesure indépendante des performances de la variante quantifiée présentée dans ce guide.

Une autre caractéristique mérite l’attention : la possibilité d’adapter l’effort de raisonnement au travail demandé. Qwen3.8 peut fonctionner avec ou sans mode de raisonnement approfondi et propose différents niveaux d’effort dans les environnements compatibles. Une question simple ne nécessite pas forcément la même analyse qu’une modification logicielle impliquant plusieurs contraintes.

Ajuster cet effort peut aider à équilibrer le temps de réponse, la consommation de ressources et la profondeur du travail. Mais réduire le raisonnement n’accélère pas nécessairement une mission complète : si le modèle commet davantage d’erreurs et doit recommencer plusieurs étapes, le gain initial peut disparaître.

Qwen3.8-27B dispose également de capacités multimodales natives pour comprendre des images et des vidéos. Il peut donc être envisagé pour des tâches mêlant documents visuels et raisonnement, sans se limiter au développement logiciel.

Attention toutefois à distinguer les capacités du modèle de celles de sa distribution : la variante Ollama retenue ici documente le texte et les images en entrée, mais pas un traitement vidéo directement accessible par cette voie. L’utilisation de vidéos dépend d’un moteur et d’une chaîne de traitement compatibles.

Pour un premier essai, la variante qwen3.8:27b disponible sur Ollama représente environ 18 Go de fichiers dans sa déclinaison llama.cpp, composant de vision compris. Les poids principaux utilisent une quantification Q4_K_M, tandis que le composant de vision conserve une précision BF16. Une fois Ollama installé, la commande ollama run qwen3.8:27b permet de lancer le modèle.

Cette taille change sensiblement les contraintes matérielles. Pour envisager un chargement intégral sur carte graphique, il faut prévoir de la marge au-delà des fichiers du modèle : la mémoire nécessaire dépend notamment du contexte configuré et du moteur utilisé. Il faut également tenir compte des caches, des composants multimodaux et des autres ressources mobilisées pendant l’inférence.

Lorsque l’ensemble ne tient pas dans la mémoire graphique, certains moteurs peuvent répartir les calculs entre le processeur et la carte graphique, en utilisant également la RAM, au prix de performances potentiellement dégradées. La capacité de la machine à charger le modèle ne suffit donc pas à garantir une utilisation confortable.

La fenêtre de contexte native atteint 262 144 tokens, avec des possibilités d’extension jusqu’à un million de tokens dans certaines configurations logicielles. Cette extension ne doit pas être confondue avec la capacité immédiatement disponible après installation. Un contexte plus long mobilise davantage de mémoire, et son exploitation dépend des réglages du moteur.

Pour un usage agentique, il faut aussi réserver de la place aux instructions, aux résultats des outils et aux informations accumulées pendant le travail. La mémoire disponible et la qualité de la gestion du contexte peuvent devenir aussi déterminantes que les capacités du modèle lui-même.

Les progrès annoncés ne suffisent pas à faire de Qwen3.8-27B un substitut aux modèles cloud haut de gamme. Une mission locale peut également devenir longue et coûteuse en ressources lorsque les échanges et les appels d’outils se multiplient.

Distribué sous licence Apache 2.0, Qwen3.8-27B permet une utilisation et une intégration relativement libres de ses poids, dans le respect des conditions de la licence. Pour les utilisateurs qui souhaitent développer leurs propres assistants ou conserver la maîtrise de leur infrastructure, cette possibilité constitue un intérêt supplémentaire. Elle ne dispense toutefois pas de sécuriser l’environnement, les accès aux fichiers et les commandes qu’un agent est autorisé à exécuter.

Qwen3.8-27B mérite donc d’être considéré si tu disposes d’une machine suffisamment équipée et souhaites explorer des travaux locaux plus complexes, notamment en programmation ou avec un agent IA.

Sa véritable valeur ne réside pas dans son nombre de paramètres, mais dans la possibilité d’exploiter ses capacités sur ton propre matériel, avec les outils et les contraintes que tu maîtrises. Reste à vérifier que les résultats et le confort obtenus justifient les ressources mobilisées : c’est précisément ce qu’un essai dans ton environnement permettra de déterminer.

↑ Retour au sommaire

Comment départager deux modèles pour ton travail ?

Les fiches techniques et les présentations des éditeurs donnent une première idée des capacités d’un modèle. Mais lorsqu’il faut départager plusieurs candidats, une question revient rapidement : comment savoir lequel sera réellement le plus adapté à ton travail ? Les benchmarks apportent une partie de la réponse, à condition de comprendre ce qu’ils mesurent et, surtout, ce qu’ils ne permettent pas de conclure.

Un benchmark est une évaluation réalisée sur un ensemble de tâches selon un protocole défini. Certains examinent les capacités de raisonnement, d’autres la programmation, la compréhension de documents ou l’utilisation d’outils.

Ces résultats sont utiles pour identifier des points forts et orienter une sélection, mais deux scores obtenus sur des évaluations différentes ne sont pas directement comparables. Être excellent sur un test de programmation ne signifie pas nécessairement être le meilleur choix pour analyser des contrats, rédiger un rapport ou interpréter une vidéo.

Le protocole compte autant que le résultat affiché. Le niveau d’effort de raisonnement, la taille du contexte, les outils disponibles et le nombre de tentatives peuvent influencer les performances. Dans les évaluations agentiques, le harness intervient également : un même modèle peut obtenir des résultats différents selon la manière dont ses actions sont organisées. Pour les contenus multimodaux, la façon dont les documents, les images ou les vidéos sont transmis constitue une autre variable importante.

Un score ne mesure donc pas toujours les capacités du modèle isolément, mais celles d’un système placé dans des conditions précises. Même sur une évaluation identique, un faible écart ne suffit pas toujours à départager deux modèles : l’incertitude annoncée et la variabilité des résultats entre plusieurs essais comptent également.

Il faut enfin distinguer les résultats publiés par les concepteurs des modèles et les évaluations réalisées par des organismes tiers. Ces dernières apportent un regard extérieur à celui du concepteur.

Mais quelle que soit leur origine, il faut examiner les tâches, les réglages et les critères de réussite retenus : aucun protocole ne garantit de reproduire ton environnement ou tes usages. Et lorsqu’un modèle local est quantifié pour fonctionner avec moins de mémoire, les performances de ses poids d’origine ne se transfèrent pas automatiquement à la version installée sur ton ordinateur.

Mettre deux modèles à l’épreuve de ton travail

Une fois quelques candidats identifiés, inutile de leur faire passer une batterie de tests interminable. Le plus utile consiste à partir d’une tâche que tu réalises régulièrement et dont tu connais suffisamment le résultat attendu pour pouvoir juger les réponses. L’exercice doit être représentatif de ton travail, mais assez délimité pour que tu puisses vérifier les résultats sans y consacrer des heures.

Imaginons que tu souhaites préparer une fiche de prise en main d’un logiciel à partir de sa documentation technique. Tu attends une procédure claire, dans le bon ordre, qui conserve les prérequis importants et n’invente aucune fonctionnalité. Fournis aux deux modèles les mêmes documents et une consigne identique. Pour chaque cas, pars d’une conversation neuve, sans historique propre à l’un des candidats, et note les versions des modèles ainsi que les principaux réglages utilisés.

Avant même de lire leurs réponses, définis ce que tu vas contrôler : les étapes sont-elles complètes ? Les conditions d’utilisation sont-elles respectées ? Les explications sont-elles compréhensibles pour le public visé ? Sans critères définis à l’avance, on risque de préférer la réponse la mieux formulée plutôt que celle qui répond réellement au besoin.

Un seul essai ne suffit cependant pas toujours à départager deux candidats. Un modèle peut réussir une demande et rencontrer davantage de difficultés sur un cas pourtant similaire. Reproduis donc la comparaison sur quelques situations représentatives, en conservant des critères cohérents.

Si les résultats varient fortement, répéter une même demande peut également aider à apprécier leur régularité. L’objectif n’est pas d’obtenir une mesure scientifique, mais d’éviter de tirer une conclusion définitive d’une seule réponse particulièrement réussie ou décevante.

Il faut aussi regarder ce que chaque réponse te coûte réellement en travail. Un modèle qui génère rapidement un texte séduisant, mais oublie plusieurs informations importantes, peut finalement te faire perdre davantage de temps qu’un autre, plus lent, dont le résultat nécessite peu de corrections.

Le véritable gain se mesure donc moins à la vitesse d’apparition des mots qu’au temps nécessaire pour obtenir un travail utilisable et correctement vérifié. À cela s’ajoutent le prix des appels API, les limites des abonnements ou, en local, la consommation de ressources et le confort d’exécution.

Une dernière distinction mérite d’être conservée : comparer deux modèles ne revient pas toujours à comparer deux assistants complets. Si tu utilises le même moteur d’inférence, les mêmes documents et les mêmes outils, tu peux mieux isoler les différences entre modèles.

En revanche, lorsque tu compares deux applications ou environnements agentiques, leurs fonctionnalités, leur gestion des fichiers et leurs outils entrent également dans le résultat. Ce n’est pas un défaut de la comparaison : si tu cherches un assistant pour travailler au quotidien, l’expérience complète compte. Il faut simplement éviter d’attribuer au modèle seul les avantages apportés par son environnement.

Au terme de ces essais, tu n’as pas besoin de démontrer qu’un modèle est supérieur à tous les autres. Tu dois surtout pouvoir expliquer pourquoi il convient mieux à ton usage, sur ta machine ou dans ton environnement de travail, avec un coût et des contraintes que tu acceptes. C’est une conclusion bien plus utile qu’une première place dans un classement général.

↑ Retour au sommaire

Faire son choix sans chercher un vainqueur universel

La sortie d’un nouveau modèle ne rend pas automatiquement celui que tu utilises dépassé. Un meilleur score sur un benchmark, une fenêtre de contexte plus étendue ou une fonctionnalité supplémentaire n’ont de valeur que s’ils répondent à un besoin réel. À l’inverse, un assistant qui t’oblige à multiplier les corrections, contourner ses limites ou adapter constamment ton travail à ses contraintes mérite peut-être d’être remplacé, même s’il figure parmi les références du moment.

Ton choix n’a donc pas besoin d’être définitif. Les modèles progressent, les applications évoluent et les conditions d’accès changent. Tes propres besoins peuvent également se transformer.

Tu peux conserver un assistant qui fonctionne bien pour certaines tâches, en adopter un autre pour un usage particulier ou associer cloud et local lorsque cette complémentarité présente un véritable intérêt. L’essentiel n’est pas de rester fidèle à un fournisseur ni de courir après chaque nouveauté, mais de conserver la maîtrise de tes outils.

Les sept modèles présentés dans ce guide constituent des références pour éclairer tes décisions, pas un palmarès destiné à rester figé. Certains céderont leur place à de nouvelles générations, d’autres conserveront leur intérêt grâce à leur accessibilité, leur coût ou leurs possibilités d’intégration. Ce qui compte, c’est désormais de savoir reconnaître les évolutions qui méritent réellement ton attention.

Un choix éclairé ne consiste pas à trouver le modèle qui promet le plus, mais à comprendre ce qu’il peut t’apporter, les limites que tu acceptes et les raisons qui pourraient un jour te conduire à en choisir un autre.

Questions fréquentes pour choisir un LLM

Quel est le meilleur LLM ?

Pour rédiger ou analyser des documents, Claude Sonnet 5.5 est un point de départ dans notre sélection. Pour programmer avec un agent, regarde plutôt les possibilités de GPT-6.1 Sol dans un environnement adapté, de Claude Code ou de Qwen3.8-27B en local. Si tu veux découvrir l’IA sur ton PC avec un modèle plus léger, commence par Qwen3.5-4B.

Ces pistes répondent à des besoins différents : elles ne constituent pas un classement issu d’un comparatif TekBrut. Le meilleur LLM pour toi est celui qui fournit un travail fiable avec des outils, un coût et un temps de correction acceptables. Le tableau de choix rapide permet de préciser ton premier essai.

ChatGPT ou Claude : lequel choisir ?

Si tu utilises déjà ChatGPT et qu’il répond correctement à tes besoins, commence par comparer Claude sur une tâche où tu rencontres une limite précise : un texte qui exige trop de retouches, un document mal exploité ou des consignes difficiles à faire respecter. Si tu pars de zéro, soumets aux deux assistants le même travail représentatif avant de payer un abonnement.

Compare la justesse des réponses, les corrections nécessaires, les outils disponibles et les limites de l’offre envisagée. ChatGPT et Claude sont des applications : leurs modèles et leurs fonctionnalités font partie du choix. Le portrait de GPT-6.1 Sol dans ce guide ne constitue donc pas, à lui seul, un verdict « ChatGPT vs Claude ». Notre méthode de comparaison t’aide à les départager sur ton travail.

Quelle IA choisir pour rédiger et travailler en français ?

Pour un premier essai de rédaction, Claude Sonnet 5.5 fait partie des options retenues dans ce guide. Pour le départager avec ton assistant habituel, donne-lui un court texte à reprendre, le public visé et un exemple du ton attendu. Vérifie qu’il conserve les faits, respecte tes consignes et produit un français naturel sans ajouter d’informations.

Une réponse élégante peut malgré tout déformer le sens. Choisis l’assistant qui demande le moins de corrections de fond sur plusieurs textes représentatifs, plutôt que celui qui impressionne sur un seul paragraphe. Nous n’avons pas établi de classement spécifique des modèles en français.

Quelle IA choisir pour programmer ?

Pour expliquer une erreur ou écrire une fonction courte, commence par l’assistant auquel tu as déjà accès. Pour modifier plusieurs fichiers, lancer des tests et corriger un projet, privilégie un environnement agentique : les outils disponibles comptent autant que le modèle.

Parmi les pistes de ce guide figurent GPT-6.1 Sol dans un environnement compatible, Claude Code avec un modèle adapté, et Qwen3.8-27B pour explorer cette approche en local sur une machine suffisamment équipée. Vérifie les modifications et les résultats des tests : du code plausible n’est pas nécessairement correct. La section sur les LLM et les agents IA explique cette différence.

Peut-on utiliser un bon LLM gratuitement ?

Oui, tu peux commencer sans payer d’abonnement, en choisissant une offre cloud gratuite adaptée à ton besoin ou un modèle téléchargeable utilisable sur ton ordinateur. Dans le cloud, vérifie les modèles accessibles, les quotas et les fonctionnalités incluses : une offre gratuite peut suffire à un usage occasionnel sans convenir à un travail intensif.

En local, des modèles comme Qwen3.5-4B ou Ministral 3 8B Instruct permettent d’explorer cette possibilité. L’absence de paiement par requête ne supprime toutefois ni le coût du matériel, ni l’électricité, ni le temps d’installation. La section sur le coût réel aide à comparer ces deux approches.

Quel LLM choisir pour mon PC ?

Commence par un modèle relativement léger, comme Qwen3.5-4B, puis vérifie sa qualité et sa vitesse sur tes tâches avant de passer à plus gros. Relève la RAM disponible et, si tu utilises une carte graphique dédiée, sa VRAM : la taille du téléchargement ne suffit pas à connaître la mémoire nécessaire.

La variante du modèle, le moteur utilisé et la longueur du contexte influencent aussi cette consommation. Un modèle qui se charge peut rester trop lent pour ton usage. Notre guide Quel PC pour l’IA locale ? détaille les contraintes matérielles ; les portraits des modèles locaux permettent ensuite de choisir un premier candidat.

Sources et repères documentaires

Les liens intégrés dans les portraits renvoient aux informations de référence. Les principales documentations utilisées pour décrire les modèles, leurs capacités, leurs modes d’accès et les évaluations sont regroupées ci-dessous.

• Claude Sonnet 5.5 : présentation Anthropic, fiche du modèle, Claude Code.
• GPT-6.1 Sol : présentation OpenAI, fiche API, comparaison Artificial Analysis.
• Gemini 4 Argon : fiche Gemini API, fiche DeepMind, méthode d’évaluation, tarifs.
• Qwen3.5-4B : carte officielle, variante Ollama.
• Ministral 3 8B Instruct 2512 : carte officielle, variante Ollama, sorties structurées Ollama.
• Gemma 4 12B-it : carte officielle, audio Gemma, variante Ollama.
• Qwen3.8-27B : carte officielle, variante Ollama, contexte Ollama.
• Méthodologie : évaluations d’agents chez Anthropic, méthode d’Artificial Analysis, méthode d’Arena, bonnes pratiques d’évaluation OpenAI.

Notions générales et cadre d’utilisation

• OAuth et facturation : standard OAuth 2.0 (RFC 6749), distinction entre facturation ChatGPT et API OpenAI.
• Confidentialité et données professionnelles : questions-réponses de la CNIL sur l’IA générative, traitement des données par l’API OpenAI.
• Documents, outils et agents : traitement des PDF dans l’API OpenAI, appels de fonctions, workflows et agents selon Anthropic.
• Contexte et exécution locale : réglages du contexte dans Ollama, questions fréquentes Ollama.

Méthode TekBrut : les recommandations reposent sur les documentations des fournisseurs et les évaluations citées ; elles ne constituent pas un test comparatif des sept modèles réalisé par TekBrut. Les tarifs, disponibilités et limites peuvent évoluer : consulte les conditions officielles avant de souscrire une offre ou de prévoir une utilisation intensive.