Guides

Vous rédigez un prompt vague (« faites-moi une analyse de X ») et vous recevez un résultat générique que vous devez réécrire.

Traduisez en français. Style technique et direct. Conservez les chiffres, les noms propres et le marquage **gras**. Ne retournez que la traduction. Donnez au modèle : (1) un rôle/contexte concret, (2) le format de sortie exact, (3) 1-2 exemples de ce qui est acceptable et de ce qui ne l'est pas. Les trois modèles répondent mieux aux instructions structurées qu'à la prose libre.

Au lieu de « résumez ce contrat » : « Vous êtes un avocat examinant ce contrat de location. Fournissez une liste de maximum 5 clauses risquées, chacune sur une ligne : [clause] — [pourquoi elle est risquée] — [ce qu'il faut demander à la place]. »

Vous avez accès à plusieurs modèles et ne savez pas lequel utiliser pour quoi — vous finissez toujours par utiliser le même par habitude, pas par critère.

Posez-vous trois questions dans l'ordre : (1) les données sont-elles sensibles ? → si oui, utilisez d'abord le modèle local. (2) la tâche consiste-elle à générer du code ou du formatage long ? → Claude Opus/GPT-5.3-Codex. (3) avez-vous besoin d'un contexte énorme (documents longs) ? → Gemini. Tout le reste (chat, résumés, tâches courtes) → le modèle local le moins cher qui fonctionne bien.

Réviser un contrat contenant des données personnelles d'un client : modèle local (jamais hors de votre serveur). Refonte majeure d'un dépôt : Claude Opus ou GPT-5.3-Codex-Max. Résumer 300 pages d'un rapport : Gemini via la fenêtre de contexte.

Vous voulez tester un modèle local mais vous ne savez pas quel matériel vous faut ni par où commencer.

Pour Qwen3.6 27B (dense, le point idéal actuel) : un minimum de 16-24 Go de VRAM en Q4. Installez llama.cpp ou Ollama, téléchargez le modèle GGUF quantifié (Q4_K_M est l'équilibre standard qualité/taille), lancez le serveur local et connectez tout client compatible OpenAI à `http://127.0.0.1:8080/v1`.

`ollama pull qwen3.6:27b` → `ollama run qwen3.6:27b "explique-moi ce qu'est le RAG en 3 lignes"`. Premier output en minutes, pas en heures.

Les deux sont des passerelles de chat (WhatsApp/Telegram/etc.) vers des agents IA — lequel choisissez-vous et pourquoi ?

La question n'est pas « quel est le meilleur », mais « où voulez-vous que le modèle réside ». OpenClaw est open-source mais BYO-API-key : par défaut, vos messages transitent par le cloud d'un tiers (Claude/GPT/Gemini), bien que le gateway s'exécute sur votre machine. Imaginclaw fonctionne par défaut sur des modèles locaux (Hera), le cloud n'étant utilisé que comme fallback explicite.

Si vous exigez que aucun message ne quitte votre infrastructure (juridique, santé, données clients) : Imaginclaw ou un OpenClaw configuré exclusivement avec Ollama local. Si vous souhaitez la capacité frontière sans déployer d'infrastructure propre : OpenClaw avec l'API de Claude/GPT.

Il n'est pas évident de distinguer quand la différence entre 'local' et 'cloud' est une simple préférence technique et quand elle constitue une décision réelle de risque.

Posez-vous la question : si cette conversation était divulguée demain, qui serait lésé ? Données personnelles de tiers (clients, patients, employés), secrets commerciaux ou tout élément soumis à une obligation légale de confidentialité → le local est la réponse correcte, pas une préférence. Pour tout le reste, le cloud est plus simple et généralement suffisant.

Un cabinet d'avocats traitant des dossiers de clients : locaux, sans contestation (et en Colombie, avec une incidence réelle sous la Loi 1581 de 2012 sur la protection des données). Rédiger un brouillon de billet de blog : l'un ou l'autre.

Chaque nouvelle release déclare « dépasse X sur les benchmarks » — et c'est rarement une information qui vous aide à décider si cela vous convient.

Ignorez le benchmark du fournisseur. Élaborez 5 à 10 tâches réelles de votre propre travail (non génériques), exécutez-les contre le modèle actuel et le nouveau, et comparez-les à l'aveugle. Si vous ne constatez pas de différence réelle sur vos tâches, ne migrez pas uniquement en raison du score du benchmark.

Avant de migrer d'un modèle à un autre pour la révision de contrats : prenez 10 contrats déjà révisés par un humain, exécutez les deux modèles et comptez combien d'erreurs réelles (pas de style) chacun commet.

Le jargon de l'IA regorge de termes qui sonnent importants mais que personne n'explique en une phrase utile.

20 termes, une ligne chacun : **Token** — unité minimale de texte traitée par un modèle (pas un mot exact). **Contexte** — volume de texte que le modèle peut « voir » simultanément. **Quantification (Q4/Q8)** — compression d'un modèle pour réduire la VRAM occupée, avec une légère perte de qualité. **VRAM** — mémoire de la GPU, goulot d'étranglement réel pour exécuter des modèles locaux. **MoE (Mixture of Experts)** — modèle volumineux n'activant qu'une partie de ses paramètres par token (plus rapide qu'un modèle dense de même taille totale). **Fine-tuning** — réentraînement d'un modèle avec vos propres données. **RAG** — recherche d'informations réelles avant de répondre, plutôt que de se fier à la « mémoire » du modèle. **Agent** — modèle capable d'utiliser des outils (recherche, exécution de code, navigation) dans une boucle, pas seulement de générer du texte. **Hallucination** — le modèle invente un fait avec une confiance totale. **Température** — niveau d'aléatoire de la réponse (0 = déterministe, plus élevé = plus varié). **System prompt** — instruction invisible fixant le comportement du modèle avant votre message. **Fenêtre de contexte** — limite totale de tokens (votre prompt + la réponse) que le modèle peut gérer par tour. **Embedding** — conversion du texte en nombres pour permettre la comparaison par similarité. **Zero-shot / few-shot** — demander une tâche sans exemples vs. avec 1-2 exemples dans le prompt. **Open-weight** — les poids du modèle sont téléchargeables (ne signifie pas qu'il est léger ni facile à exécuter). **API** — moyen dont votre code communique avec un modèle exécuté sur un autre serveur. **Latence** — temps de réponse. **Throughput** — nombre de requêtes gérables en parallèle. **Prompt injection** — attaque où du texte malveillant contenu dans le texte traité par le modèle le fait dévier de ses instructions. **Guardrail** — règle externe au modèle bloquant ou corrigeant sa sortie.

Ce modèle dispose d'un contexte de 262K, ce qui signifie qu'il peut traiter environ 200 000 mots d'un coup, et non qu'il est plus intelligent.

Le modèle 'oublie' quelque chose que vous lui avez dit précédemment dans la même conversation, ou il coupe la réponse à mi-parcours.

Tout ce qui entre et sort d'un modèle est mesuré en tokens (environ ¾ d'un mot en espagnol/anglais). La fenêtre de contexte est une limite TOTALE partagée entre votre prompt, l'historique et la réponse — il ne s'agit pas de quotas séparés. Si vous vous approchez de la limite, le modèle commence à perdre les détails situés plus en arrière.

Un modèle doté d'un contexte de 128K et d'un historique de conversation de 100K tokens ne dispose que de 28K tokens libres pour votre prochain message et la réponse ; si vous demandez un long document, il sera tronqué ou excessivement résumé.

Vous voulez que le modèle « sache » quelque chose de spécifique à votre entreprise et il n'est pas évident quelle des trois techniques utiliser.

**Prompting** (insérer les informations directement dans le prompt) — pour les données mineures, évolutives, sans infrastructure. **RAG** (rechercher et récupérer des informations pertinentes avant de répondre) — pour les grandes bases de connaissances évoluant fréquemment (documents, politiques, catalogues). **Fine-tuning** (réentraîner le modèle) — uniquement lorsque l'on doit modifier le STYLE/comportement du modèle, pas pour ajouter des données — c'est plus coûteux et ce n'est pas la bonne méthode pour "enseigner des faits".

Un bot qui répond sur plus de 500 produits d'un catalogue qui change chaque semaine : RAG, pas de fine-tuning. Un bot qui doit toujours répondre dans un ton juridique spécifique, indépendamment du sujet : c'est là que le fine-tuning a du sens.

Les trois sont "open-weight" mais ont des exigences matérielles totalement différentes — l'étiquette ne vous indique pas si vous pouvez les exécuter.

Qwen3.6 27B dense : s'exécute sur 1-2 GPU grand public (16-24 Go de VRAM en Q4) — le seul des trois réellement accessible pour l'hébergement autonome individuel aujourd'hui. Kimi K3 (2,8T paramètres) et DeepSeek V4 (jusqu'à 1,6T) : poids ouverts, mais échelle de centre de données — centaines de Go de VRAM même quantifiés, conçus pour être servis via API d'un fournisseur ou un cluster dédié, et non pour votre bureau.

Si vous avez 1-2 GPUs et voulez exécuter quelque chose MAINTENANT : Qwen3.6 27B. Si vous voulez la capacité maximale open-weight et que vous n'avez pas d'objection à payer à un fournisseur pour l'héberger : Kimi K3 ou DeepSeek V4 via API.