À fin avril 2026, la question des modèles ouverts n'est plus de savoir s'ils sont intéressants. La vraie question : lequel termine le job dans votre harnais OpenClaw sans transformer chaque exécution cron en séance de baby-sitting — et la réponse a sensiblement bougé au cours des quatre dernières semaines.
Pour beaucoup d'équipes, la réponse est désormais oui, sous conditions — mais le quel a changé.
La sélection open source d'avril 2026 n'est pas celle que la plupart des équipes ont auditée en mars. GLM-5.1 est sorti le 7 avril et a pris la première place sur SWE-Bench Pro. Kimi K2.6 est passé en GA le 21 avril avec des essaims natifs de 300 agents et des sessions de coding autonomes de 12 heures. Qwen 3.6-27B a été publié le 22 avril — un modèle dense sous licence Apache-2.0 qui bat des concurrents MoE de 397B sur le coding agentique. DeepSeek V4 est arrivé le 24 avril et a ramené le prix frontier d'un ordre de grandeur. MiniMax M2.7 reste solide, mais sa licence est passée de MIT à non-commerciale — un changement discret qui le disqualifie pour beaucoup d'équipes.
OpenClaw n'est pas un harnais de benchmarks. C'est un runtime agentique : tool calls, éditions de fichiers, boucles répétées, sessions longues, hooks, automatisation de type cron, et coûts d'échec réels quand un modèle dérive du schéma ou refuse de s'arrêter. Cela change la façon dont vous devez évaluer cette sélection.
Ce guide est la version pratique, mise à jour pour le paysage de fin avril 2026 : quels modèles comptent spécifiquement pour OpenClaw, où nous les routerions en premier, où nous garderions Anthropic ou OpenAI dans la boucle, et comment tester le basculement sans casser la production.
Si vous voulez d'abord le contexte plus large des modèles frontier, lisez notre guide de terrain des modèles OpenClaw. Si votre préoccupation principale est la pression sur les coûts, complétez avec notre analyse DeepSeek sur le séisme tarifaire de l'open source.
Ce dont OpenClaw a réellement besoin chez un modèle
Un modèle peut être brillant sur un leaderboard et rester le mauvais choix pour OpenClaw.
À l'intérieur d'un déploiement OpenClaw, trois traits comptent davantage que les captures d'écran de benchmarks :
- Discipline de tool-call — le modèle appelle-t-il le bon outil avec le bon schéma, ou invente-t-il des champs qui n'existent pas ?
- Discipline d'arrêt — sait-il quand la tâche est terminée, ou continue-t-il à narrer, à boucler, ou à rouvrir un travail déjà fini ?
- Économie de contexte — fait-il confiance au contexte qu'il a, ou brûle-t-il des tokens à relire les mêmes fichiers et à redériver les mêmes faits ?
C'est la grille de lecture que nous utilisons ci-dessous.
La shortlist d'avril 2026 : quels modèles ouverts comptent
1. Kimi K2.6 — Le meilleur pour les boucles d'agent à long horizon et les essaims de tool-calls
Kimi K2.6 de Moonshot est passé en GA le 21 avril 2026, et c'est le modèle open-weight conçu le plus directement pour le travail qu'OpenClaw fait réellement.
Le profil runtime est l'élément clé. K2.6 est un MoE de 1T total / 32B actifs livré avec :
- Sessions de coding autonomes de 12 heures — pensées pour les tâches longues, pas pour les prompts à un seul tour
- Essaims de 300 sous-agents sur jusqu'à 4 000 étapes coordonnées — une architecture runtime, pas seulement un modèle
- SWE-Bench Verified à 80,2 % et Terminal-Bench 2.0 à 66,7 %
- Entrée vidéo native pour captures d'écran, enregistrements d'écran et états d'UI
- Fenêtre de contexte de 256K avec un comportement prévisible sur toute la plage
Pour OpenClaw, cela se traduit directement. Les longs jobs cron qui dérivent du schéma avec des modèles plus petits ont tendance à rester cohérents sous K2.6. Les chaînes tool-use multi-étapes dont le mode d'échec typique est « le modèle abandonne à l'étape 14 et se met à narrer » sont précisément ce que K2.6 a été affiné pour éviter.
Les réserves honnêtes :
- le harnais est plus opinioné que le schéma tool-use d'Anthropic ou la Responses API d'OpenAI — prévoyez du glue code
- « 300 sous-agents » est une affirmation runtime, pas de l'orchestration gratuite ; il vous faut toujours la logique de superviseur dans votre harnais
- les garde-fous sur les contenus liés à la Chine sont assez lourds pour le disqualifier sur certains workflows de contenu
Si votre déploiement OpenClaw est dominé par de longues boucles d'agent avec de nombreux tool calls par tâche — jobs de réparation, refactors par lots, recherche multi-étapes — K2.6 est le modèle que nous testerions en premier.
2. GLM-5.1 — Le meilleur pour le coding façon SWE-bench et l'exécution multi-étapes stable
GLM-5.1 de Z.ai est sorti le 7 avril 2026 et a pris la première place sur SWE-Bench Pro à 58,4 %, battant GPT-5.4 (57,7) et Claude Opus 4.6 (57,3) sur le benchmark de tâches vérifiées le plus difficile du domaine.
L'argumentaire pratique pour GLM-5.1 dans OpenClaw :
- MoE de 754B avec une fenêtre de contexte de 200K, sous licence MIT
- scores au top de la classe sur le benchmark qui correspond le plus directement à « réparer un vrai bug de bout en bout face à une suite de tests »
- tarification autour de 1,00 $ / 3,20 $ par million de tokens — nettement en dessous de GPT-5.5 et Opus 4.7
- déjà facile à router via OpenRouter et d'autres gateways
Où nous testerions GLM-5.1 en premier :
- automatisations à forte composante coding (debug, refactor, mises à jour de dépendances)
- jobs de réparation multi-étapes où l'exécution stable compte plus que la largeur brute
- boucles d'agent où un modèle plus faible a tendance à continuer à parler après la fin de la tâche
Compromis : GLM-5.1 est sous licence MIT mais entraîné sur des puces Huawei Ascend, et l'histoire de déploiement hors de leur API managée est moins mature que celle de DeepSeek. Si votre priorité est « le meilleur comportement de modèle non-Anthropic dans une boucle de coding façon OpenClaw », c'est l'option la plus solide du cycle. Si votre priorité est l'auto-hébergement à court terme, pesez soigneusement l'histoire infra.
3. DeepSeek V4 — Meilleur rapport prix/capacité pour les charges en volume et sensibles aux coûts
DeepSeek V4 est sorti le 24 avril 2026, avec deux modèles preview qui ont remis à zéro le plancher tarifaire de l'open source.
- V4-Pro à 1,6T total / 49B actifs, contexte 1M (128K effectif), sous licence MIT
- V4-Flash à 284B total / 13B actifs, contexte 1M, sous licence MIT
- tarification à 0,145 $ / 3,48 $ pour V4-Pro et 0,14 $ / 0,28 $ pour V4-Flash par million de tokens
- DeepSeek V4-Pro mène LiveCodeBench à 0,935 à fin avril 2026
L'histoire tarifaire complète est dans notre article DeepSeek V4. Pour OpenClaw spécifiquement, V4-Flash est le nouveau plancher pour le routing, la classification et l'extraction de premier passage — environ 17x moins cher que Claude Haiku 4.5 en sortie. V4-Pro est le nouveau plancher pour le raisonnement mid-tier en volume, derrière un vérificateur.
Où nous déploierions V4 en premier :
- automatisation en volume et workflows back-office
- extraction structurée à grande échelle
- couches de routing et de classification dans votre stack agentique
- agents internes où une verbosité occasionnelle est tolérable
Le bémol : la parité de benchmarks est avec Opus 4.6 et GPT-5.4 — la génération précédente, pas l'actuelle. L'écart d'éval sur les tâches de raisonnement les plus difficiles est réel. Et, comme Kimi, les contenus liés à la Chine sont fortement encadrés.
4. Qwen 3.6-27B — Meilleur défaut dense pour un auto-hébergement propre
Qwen 3.6-27B d'Alibaba a été publié le 22 avril 2026, et c'est l'histoire « poids ouverts que vous pouvez réellement faire tourner » la plus propre du mois.
- 27 milliards de paramètres, dense, sous licence Apache-2.0
- surpasse son grand frère MoE Qwen 3.5 de 397B sur les benchmarks de coding agentique
- tient sur un seul H100 80 Go non quantisé ; tourne quantisé sur un M5 Max ou M5 Studio
- latence d'inférence prévisible et déterminisme par batch (le dividende du modèle dense)
Pour OpenClaw, Qwen 3.6-27B a la bonne forme pour les équipes dont le premier objectif de migration est la simplicité opérationnelle :
- un seul fichier de modèle à gérer, pas de bizarreries de routing MoE
- coût et latence prévisibles pour la planification de capacité
- fine-tuning direct si vous voulez vous spécialiser sur des données internes
- licence Apache-2.0, aucune surprise de licence
Où nous aimons Qwen en premier :
- jobs cron à faible risque
- flux de résumé et d'extraction
- travail adjacent au code qui bénéficie d'un modèle que vous pouvez réellement posséder
- équipes qui veulent un fallback mono-modèle à l'intérieur de leur périmètre de données
Alibaba livre aussi Qwen 3.6-Plus (propriétaire, contexte 1M) pour l'enterprise ; traitez-le comme la couche API plutôt que l'histoire open-weights.
5. MiniMax M2.7 — Solide sur le papier, bloqué par le changement de licence
C'est ici que le cycle a basculé. MiniMax M2 était sous licence MIT ; M2.7 (18 mars 2026) est non-commercial.
Le modèle en lui-même est solide : MoE 230B / 10B actifs, contexte 200K, 0,30 $ / 1,20 $ par million de tokens, et des scores compétitifs sur les benchmarks de tool-use agentique. Pour la recherche, le prototypage et l'outillage interne, il est franchement bon.
Mais pour des produits générant du revenu dans des déploiements OpenClaw, la licence le disqualifie sans accord enterprise. C'est un changement majeur par rapport à ce que les équipes ont audité en mars, et cela mérite d'être signalé avant que quiconque n'architecture autour du prix de 0,30 $ / 1,20 $.
Conseils pratiques :
- ne livrez pas MiniMax M2.7 dans un produit commercial sans vérifier la licence par rapport à votre cas d'usage
- si votre plan précédent était M2 → M2.5 → M2.7, traitez M2.5 (MIT) comme la dernière option commercialement propre de la famille
- pour le cas d'usage runtime agentique sur lequel M2 était le plus fort, Kimi K2.6 est le remplaçant le plus propre — profil runtime différent, mais sans dragon de licence
6. Llama 4 Maverick — Meilleur en couche multimodale ou de routing
Llama 4 Maverick de Meta compte toujours, mais son rôle s'est resserré.
- 17B actifs / 400B total MoE
- multimodalité native (entrée vision)
- très grande fenêtre de contexte exposée par les providers
- écosystème mature (lm-evaluation-harness, vLLM, llama.cpp, tous les principaux moteurs d'inférence)
Pour OpenClaw, Maverick est le bon choix sur deux rôles spécifiques :
- routing et triage devant un agent downstream plus puissant
- prétraitement multimodal quand la compréhension d'image doit avoir lieu avant que la boucle d'agent ne se déclenche
Ce que nous ne ferions pas, c'est faire de Maverick le défaut sur les boucles autonomes difficiles. Sa valeur, c'est la largeur et la maturité d'écosystème, pas « voici le modèle en qui j'ai le plus confiance pour faire silencieusement la bonne chose pendant vingt étapes d'affilée ».
Pensez à Maverick comme une couche frontale intelligente, pas la dernière couche.
7. La shortlist spécialiste : modèles ouverts plus petits et branches vision
Trois autres compartiments à garder en vue :
Variantes Qwen 3.6-VL
Méritent une vraie attention pour les déploiements OpenClaw qui incluent captures d'écran, schémas, états d'UI ou travail visuel à forte composante documentaire. Si vous aimiez déjà Qwen sur le texte, la branche VL est l'extension naturelle.
Petits modèles ouverts (Llama 4 8B/3B, Qwen 3.6 small, Gemma 3, Mistral Small 4)
Excellents pour le routing, la classification, les courts jobs d'extraction et les retries pas chers sur du travail non critique. L'erreur consiste à leur demander de porter la boucle d'agent complète juste parce qu'ils sont peu coûteux.
Mistral Small 4
La dernière sortie de Mistral fusionne Magistral, Pixtral et Devstral en un seul modèle. Forte performance code-spécifique pour les déploiements européens où les relations enterprise de Mistral comptent.
Ce que nous déploierions réellement en premier (avril 2026)
Si nous montions un déploiement OpenClaw en avril 2026 et voulions un rollout open source réaliste, voici l'ordre dans lequel nous testerions :
| Type de job | Premier modèle à tester | Pourquoi |
|---|---|---|
| Longues chaînes de tool-call agentiques | Kimi K2.6 | Conçu pour des sessions de 12 h et des essaims de 300 agents |
| Boucles de coding ou de réparation difficiles | GLM-5.1 | Leader SWE-Bench Pro à 58,4 % |
| Workflows en volume, sensibles aux coûts | DeepSeek V4-Flash / V4-Pro | Sortie frontier-class la moins chère, de loin |
| Jobs cron à faible risque (défaut dense) | Qwen 3.6-27B | Apache-2.0, fichier unique, prévisible |
| Routing multimodal | Llama 4 Maverick ou Qwen 3.6-VL | Prétraitement vision-lourd avant le déclenchement de l'agent |
| One-shots critiques en production | Garder un fallback closed-model | La fiabilité compte toujours plus que l'idéologie |
Notez ce qui a changé depuis mars : MiniMax n'est plus dans ce tableau — le passage à une licence non-commerciale pour M2.7 le sort de la plupart du travail OpenClaw commercial. Kimi K2.6 est passé en tête parce que le profil runtime à long horizon agentique correspond directement à la forme d'OpenClaw.
Cette dernière ligne est la partie que beaucoup d'équipes ne veulent pas entendre : les modèles ouverts sont désormais assez bons pour faire tourner beaucoup de travail OpenClaw, mais toutes les charges OpenClaw ne devraient pas quitter la stack closed frontier au 27 avril.
OpenRouter d'abord, auto-hébergement ensuite
Pour la plupart des équipes, le mauvais plan de migration est de commencer par l'auto-hébergement.
La meilleure séquence :
- Routez d'abord via OpenRouter ou un autre provider
- Shadow-testez de vrais jobs OpenClaw face à l'incumbent (Opus 4.7 ou GPT-5.5)
- Mesurez les erreurs de tool-call, les taux de timeout, la stabilité de boucle, le coût par exécution réussie
- Décidez seulement ensuite si l'auto-hébergement vaut la charge opérationnelle
Pourquoi cela fonctionne mieux :
- vous séparez le risque qualité modèle du risque infra
- vous pouvez comparer rapidement GLM-5.1, K2.6, V4 et Qwen 3.6 sans changer le harnais
- vous évitez de blâmer le comportement du modèle pour des problèmes d'auto-hébergement
L'auto-hébergement vaut le coup quand l'une de ces conditions devient vraie :
- le volume de tokens est assez élevé pour que la marge provider devienne matérielle
- le contrôle des données compte plus que la commodité
- vous voulez une personnalisation plus profonde de la stack (fine-tuning, inférence custom)
- vous avez déjà le muscle ops pour posséder l'infrastructure d'inférence
Si rien de tout cela n'est vrai, provider-first reste le mouvement sain — et Qwen 3.6-27B est le chemin le plus propre si et quand vous le ramènerez à l'intérieur de votre périmètre.
Un playbook de migration sûr pour OpenClaw
Le rollout que nous recommanderions réellement.
Phase 1 — Shadow uniquement
Forkez quelques jobs OpenClaw à faible risque et faites tourner le candidat ouvert en parallèle de l'incumbent.
Mesurez :
- erreurs de schéma de tool-call
- retries par tâche réussie
- taux de timeout
- échecs de discipline d'arrêt
- coût par exécution réussie
Phase 2 — Modèle ouvert en primaire, modèle premium en chemin de secours
Une fois que le profil d'erreurs paraît acceptable, laissez le modèle ouvert prendre le premier passage.
Escaladez vers un modèle closed premium uniquement quand :
- la tâche échoue deux fois de la même manière
- la sortie est mal formée deux fois
- la tâche touche à un état de production et la confiance est faible
Phase 3 — Auto-hébergement uniquement après preuve d'adéquation au workflow
Ne vous auto-hébergez pas juste parce que la courbe de benchmark vous a donné l'impression que c'était inévitable.
Auto-hébergez une fois que vous avez la preuve que :
- le modèle correspond à votre charge OpenClaw
- le volume de la charge justifie l'effort
- votre équipe peut prendre en charge l'observabilité, les upgrades et la réponse aux incidents
C'est aussi la logique derrière notre prise de position sur le compute agentique et pourquoi le pricing flat-rate s'est cassé : le token pas cher n'est pas le workflow pas cher si la gestion des échecs mange les économies.
Ce que cela signifie pour les équipes utilisant OpenClaw en avril 2026
Le glissement stratégique est réel et la sélection a bougé.
Les modèles ouverts à fin avril 2026 sont des briques crédibles pour de vraies stacks OpenClaw — mais le quel a changé au cours des quatre dernières semaines. Kimi K2.6 remplace MiniMax M2 comme choix agentique à long horizon. GLM-5.1 remplace GLM-4.7 en tête de la shortlist coding SWE-bench. DeepSeek V4 remplace V3.2 avec une histoire tarifaire bien plus tranchée. Qwen 3.6-27B remplace Qwen3-235B comme défaut dense le plus propre pour l'auto-hébergement.
La mauvaise leçon est « tout basculer maintenant ».
La bonne leçon :
- testez la nouvelle sélection d'avril 2026 sur le travail qui tolère l'échec
- gardez les fallbacks premium (Opus 4.7, GPT-5.5) pour le travail qui ne tolère pas
- concevez le harnais pour que le choix de modèle devienne une décision de routing, pas une religion
- auditez les licences avant d'architecturer autour d'un modèle — le glissement MiniMax M2 → M2.7 est un coup de semonce
C'est là qu'est le levier.
FAQ
Quel modèle ouvert devrais-je tester en premier dans OpenClaw à fin avril 2026 ? Commencez avec Kimi K2.6 si votre charge est dominée par de longues boucles d'agent avec des tool calls fréquents — il a été conçu pour cette forme de travail. Commencez avec GLM-5.1 si votre charge porte sur des tâches de coding difficiles où l'exécution façon SWE-bench compte. Commencez avec Qwen 3.6-27B si votre priorité est la simplicité opérationnelle et un chemin propre vers l'auto-hébergement. Commencez avec DeepSeek V4-Flash si votre priorité est le coût sur des appels routiniers à fort volume.
Qu'est-il arrivé à MiniMax M2 par rapport à la version précédente de ce guide ? MiniMax M2.7 (le flagship actuel) a été livré sous licence non-commerciale, contrairement à M2 et M2.5 qui étaient MIT. Pour la recherche et l'outillage interne, il reste solide ; pour des déploiements OpenClaw commerciaux, la licence le disqualifie sans accord enterprise. Kimi K2.6 est le remplaçant le plus propre pour le rôle de boucle agentique.
Les modèles ouverts peuvent-ils remplacer entièrement Claude ou GPT dans OpenClaw à fin avril 2026 ? Pour certaines charges, oui. Pour toutes les charges, non. Les longues boucles agentiques, le travail de réparation de code, l'extraction en volume et les couches de routing sensibles aux coûts sont les premières cibles les plus faciles. Les one-shots critiques en production et le raisonnement à difficulté frontier méritent encore la prime du closed-model.
Quel modèle est le meilleur si je sais que je veux m'auto-héberger ? Qwen 3.6-27B pour la simplicité opérationnelle (dense Apache-2.0, fichier unique). DeepSeek V4-Flash pour le coût (16 Go quantisé tient sur un Mac Studio 128 Go). Kimi K2.6 si la charge a vraiment besoin du profil runtime à long horizon et que vous avez l'infrastructure d'orchestration. GLM-5.1 si le coding façon SWE-bench est la charge.
Les modèles ouverts fonctionnent-ils maintenant avec le tool use façon MCP ? Oui — bien plus crédiblement qu'il y a un an. Mais compatibilité n'égale pas fiabilité. Les modèles ouverts d'avril 2026 demandent encore plus de glue code que les schémas tool-use first-class d'Anthropic ou d'OpenAI. Testez la discipline de schéma, les retries et le comportement d'arrêt à l'intérieur de votre propre harnais avant de promouvoir l'un d'eux.
Quelle est la plus grosse erreur des équipes lors du basculement d'OpenClaw vers des modèles ouverts ? Traiter une victoire sur un benchmark comme une décision de déploiement. La vraie question n'est pas « quel modèle a le meilleur score ? » — c'est « quel modèle termine ce job OpenClaw proprement, de façon répétée, et assez bon marché pour avoir de l'impact, sous une licence que vous pouvez réellement livrer ? »
Bottom line
La sélection open source d'avril 2026 pour OpenClaw :
- Kimi K2.6 est le candidat open-weight le plus solide, conçu pour les longues boucles agentiques.
- GLM-5.1 est le candidat ouvert le plus solide pour le travail de coding façon SWE-bench.
- DeepSeek V4 (Pro et Flash) est le plancher tarifaire — le modèle ouvert frontier-class le moins cher et le petit modèle le moins cher.
- Qwen 3.6-27B est le défaut dense Apache-2.0 le plus propre pour les équipes qui veulent la simplicité de l'auto-hébergement.
- MiniMax M2.7 est solide mais bloqué par la nouvelle licence non-commerciale pour la plupart du travail commercial.
- Llama 4 Maverick est utile comme couche de routing ou multimodale devant le worker principal.
Le mouvement gagnant n'est ni « tout open » ni « tout proprio ». Le mouvement gagnant, c'est de construire une stack OpenClaw capable de router intelligemment entre les modèles ouverts d'avril 2026, avec un fallback closed-frontier sur le travail qui l'exige.
Si vous voulez de l'aide pour concevoir cette couche de routing — défauts, fallbacks, règles d'escalade, audits de licence — parlez à Context Studios. Nous avons déjà fait la partie pénible : repérer où les vrais modes d'échec apparaissent.