6 min de lecture - Étude Qwen3-Coder : résultats, limites et contrôles de sécurité

Une équipe de développement doit-elle revoir son usage de Qwen3-Coder après l'étude de sécurité d'Hirundo ? Les résultats justifient de tester le modèle dans votre propre environnement de développement. Ils ne prouvent pas que des IA chinoises sabotent volontairement des logiciels américains.

Le 21 octobre 2026, Ben Luria a publié une étude de cas chez Hirundo qui rapporte des taux de vulnérabilité différents selon le client nommé dans la consigne. Le modèle testé était Qwen3-Coder-30B-A3B-Instruct d'Alibaba. Cette précision compte ; la fiche officielle de Qwen le présente comme une taille de modèle au sein d'une famille plus large.

Les résultats rapportés

Ces chiffres proviennent de l'expérience d'Hirundo. Ils ne mesurent pas le taux de défaillance général des logiciels écrits avec Qwen. Le tableau distingue les applications exploitables du cas plus précis de l'exposition des secrets des utilisateurs.

Source : résultats et méthode d'Hirundo. Chaque paire de lignes forme une comparaison distincte ; la dernière change de client de référence.

Le premier écart atteint 11 points de pourcentage. En divisant 11 par 59, on obtient une augmentation relative d'environ 19 %, à partir des taux arrondis. Parler d'une hausse de 19 points serait faux. Le tableau ne démontre pas non plus que l'ajout de consignes de sécurité dégrade le code : il faudrait une comparaison directe conçue pour mesurer cet effet.

Ce que l'expérience permet d'évaluer

Hirundo a utilisé une tâche de stockage de secrets issue de BaxBench et testé des attaques contre les applications en fonctionnement. L'annexe précise que l'équipe a retenu cette tâche après en avoir examiné onze. Hirundo a aussi admis davantage d'applications que ne le permet le critère de réussite fonctionnelle complète de BaxBench. Ces choix limitent les comparaisons avec le classement du benchmark. Les annexes de l'étude décrivent la sélection et les règles d'évaluation.

Les auteurs de BaxBench distinguent le fonctionnement attendu de la sécurité et publient des tests et des attaques pour leurs scénarios. Une application peut réussir un parcours prévu et échouer face à une attaque. Une démonstration de connexion réussie laisse donc une question à l'acheteur : quelles actions non autorisées l'équipe a-t-elle essayées ?

Pour évaluer un modèle, répétez les mêmes tâches avec différentes descriptions de clients en conservant la version du modèle et les paramètres de génération. Choisissez les tâches et les comparaisons avant de regarder les résultats. Conservez les échecs de construction comme les productions vulnérables, et indiquez le dénominateur de chaque taux. Sans cela, deux équipes peuvent publier des pourcentages proches qui portent sur des ensembles d'applications différents.

L'intention et le correctif du fournisseur demandent des preuves distinctes

Hirundo rapporte des différences statistiquement significatives. Son annexe C reconnaît aussi que l'équipe ne peut pas déterminer si quelqu'un a introduit ce comportement volontairement. Cette réserve doit accompagner le titre.

Un écart mesuré ne désigne ni son auteur ni sa cause. Il ne permet pas davantage de juger la sécurité d'autres modèles d'après leur pays d'origine. Le sabotage délibéré reste une explication non démontrée. Évaluez chaque modèle candidat sur les tâches que vous comptez lui confier.

Hirundo commercialise une technologie destinée à modifier le comportement des modèles et présente son modèle modifié comme une solution. Cet intérêt commercial mérite d'être signalé. Avant d'accepter une promesse de sécurité, demandez les éléments de l'évaluation et testez indépendamment le modèle de remplacement proposé.

L'article de SecurityWeek du 21 octobre rapporte les travaux d'Hirundo. Il s'agit d'une publication distincte, mais son article ne décrit pas de réplication indépendante de cette expérience. Les sources citées ici n'en établissent pas l'existence.

Tester l'accès aux données d'un autre utilisateur avant la mise en production

Le contrôle d'accès fournit un point de départ concret pour l'équipe technique. Le guide OWASP sur les défauts d'autorisation au niveau des objets demande de vérifier les droits de l'utilisateur pour l'action et l'enregistrement concernés. Authentifier une personne ne lui donne pas accès à tous les enregistrements.

Imaginez une application de test dans laquelle Alice et Bob possèdent chacun un document privé. C'est un exemple de test d'acceptation, pas une reproduction de l'expérience d'Hirundo. Connectez-vous en tant qu'Alice et demandez le document de Bob à partir de son identifiant. Avec cette règle de propriété, l'application doit refuser l'accès. Répétez le contrôle pour la modification, la suppression et l'export, ainsi qu'entre organisations si le produit en héberge plusieurs.

Pour un pilote, nous recommandons de conserver ces exigences dans la revue de mise en production :

• Consignez la révision exacte du modèle, les consignes et les paramètres pour permettre à l'équipe de reproduire un échec.
• Testez les actions permises et interdites sur des données jetables. Le test doit montrer que l'utilisateur prévu réussit et qu'un autre ne peut pas obtenir les mêmes données.
• Associez revue de code, analyse automatisée et tests de l'application en fonctionnement. Demandez aux relecteurs d'expliquer comment chaque opération sensible applique les règles d'autorisation.
• Confiez à un ingénieur la validation des changements sensibles pour la sécurité et conservez les résultats des tests avec la version livrée. Recommencez l'évaluation après un changement de modèle ou des outils qui l'entourent.

Ces contrôles sont des propositions techniques d'Exceev. Ils ne constituent pas une certification de Qwen ou du modèle de remplacement d'Hirundo. Notre processus de développement donne un cadre pour discuter de la place des revues et des tests dans votre organisation.

Une équipe peut examiner l'écart rapporté sans trancher le motif géopolitique. Avant la mise en production, exigez la preuve que l'application respecte ses propres règles d'accès.

Références

Sources consultées le 23 octobre 2026. Les chiffres restent attribués aux auteurs de l'étude.

• Hirundo : étude de cas Qwen3-Coder, Ben Luria, 21 octobre 2026. Résultats originaux, méthode et réserves dans les annexes A à C.
• SecurityWeek : article sur le résultat concernant le fournisseur américain, Ionut Arghire, 21 octobre 2026. Source journalistique secondaire, sans réplication indépendante.
• Qwen : fiche du modèle Qwen3-Coder-30B-A3B-Instruct. Identification officielle de la variante du modèle.
• BaxBench : benchmark et méthode d'évaluation. Documentation primaire sur les tests fonctionnels et les contrôles de sécurité exécutables.
• OWASP API1:2023 : défauts d'autorisation au niveau des objets. Guide primaire sur la vérification des droits d'accès aux enregistrements et leurs tests.