Les refus de DeepSeek V4.1 Flash supprimés : de 81,6 % à 4,3 % sur 838 prompts

Imaginez que vous achetiez un coffre-fort avant de découvrir que sa serrure à code peut être retirée avec un tournevis en une soirée. C’est à peu près le tableau que dresse une publication virale sur X à propos de DeepSeek V4.1 Flash. Son auteur affirme que quelqu’un a supprimé la plupart des refus du modèle grâce à OBLITERATUS, un outil open source gratuit publié par Pliny.

Ce qui est exactement affirmé

La publication ne présente que quelques faits. Selon son auteur, le modèle d’origine refusait de répondre à 81,6 % des 838 prompts de test. Après modification, le taux de refus serait tombé à 4,3 %. L’outil est décrit comme gratuit et ouvert, sans autre précision technique.

Ce que nous ignorons est tout aussi important. Nous ne savons pas quels prompts composaient précisément ce jeu de 838 éléments, comment un refus était défini ni qui a effectué la mesure. Aucune donnée n’indique comment les performances du modèle ont évolué sur des tâches ordinaires telles que le code, le raisonnement ou les contextes longs. La publication ne fournit aucun lien vers une expérience reproductible et sa portée reste modeste, avec environ 4,6 milliers de vues. Ces chiffres doivent donc être considérés comme une affirmation, et non comme le résultat d’une vérification.

Pourquoi cela est possible en principe

Le refus d’un modèle de langage ne repose pas sur un « bouton » distinct. Il est façonné par l’entraînement et inscrit dans les poids. Les chercheurs ont montré depuis longtemps que, pour de nombreux modèles, le comportement de refus correspond à une direction relativement étroite dans les représentations internes. En identifiant cette direction et en la « soustrayant » des activations ou des poids, le modèle cesse de répondre par un refus aux sujets interdits. Cette technique est appelée ablation des refus et, dans la communauté, également « obliteration ». Le nom OBLITERATUS suggère cette famille de méthodes, mais la publication ne confirme pas la mise en œuvre précise employée.

La caractéristique essentielle de cette approche est qu’elle nécessite un accès aux poids, mais pas de réentraînement coûteux. Pour tout modèle ouvert, la question se formule donc généralement ainsi : quand une version sans refus apparaîtra-t-elle, et non si elle apparaîtra.

Ce que les développeurs et les équipes produit doivent en faire

Premièrement, ne considérez pas l’alignement intégré comme votre unique ligne de défense. Si votre produit utilise un modèle ouvert, les refus du modèle de base ne garantissent pas sa sécurité. Il vous faut vos propres filtres en entrée et en sortie, une modération distincte et une journalisation. La panoplie habituelle comprend un classificateur de requêtes, une vérification des réponses et des limites appliquées aux actions dangereuses des agents.

Deuxièmement, si vous utilisez des checkpoints réentraînés par des tiers provenant de Hugging Face ou de plateformes similaires, vérifiez leur provenance. Un modèle portant un nom proche de celui de l’original peut se comporter de façon totalement différente de la version officielle. Exécutez votre propre batterie de tests red team avant toute mise en production, en particulier pour les agents ayant accès à des outils et à des données.

Troisièmement, pour les équipes qui publient des poids ouverts, cet épisode rappelle l’importance du modèle de menace. L’alignement inscrit dans les poids protège contre les usages abusifs accidentels, mais pas contre les détournements délibérés. Des mesures supplémentaires sont nécessaires : licence, surveillance des usages via une version API et publications distinctes selon les niveaux de risque.

Limites et conclusion

La source est unique : une publication sur un réseau social accompagnée d’un titre émotionnel. Pour les développeurs, ce n’est pas une raison de paniquer, mais de revoir leurs hypothèses. Si vous construisez votre produit sur une API fermée, votre situation est différente : les poids sont inaccessibles et cette méthode ne peut pas fonctionner. Si vous utilisez des modèles ouverts, ajoutez à votre liste de contrôle la question suivante : que se passera-t-il lorsque les refus disparaîtront ? La réponse doit inclure une couche de protection que vous contrôlez vous-même, et pas uniquement celle du développeur du modèle.

L’histoire de DeepSeek V4.1 Flash ne sera probablement pas la dernière du genre. Plus un modèle ouvert est puissant, plus les outils permettant de supprimer ses restrictions apparaîtront rapidement, et plus l’architecture de sécurité qui l’entoure deviendra importante.