Le modèle Ajax AI de PewDiePie devient local après un différend avec OpenAI sur une suspension

PewDiePie a dévoilé un assistant local de 9 milliards de paramètres après avoir affirmé qu’OpenAI avait suspendu son compte à deux reprises durant son développement. Le modèle PewDiePie Ajax AI transforme ce différend en une affaire plus vaste qu’une querelle entre un créateur et une entreprise d’IA.

Ajax est une version personnalisée du modèle Qwen3.5-9B d’Alibaba. Il est développé pour alimenter Odysseus, l’espace de travail auto-hébergé de Felix Kjellberg dédié à la recherche, à la navigation, aux e-mails, aux calendriers et à d’autres tâches quotidiennes.

Le conflit porte sur la distillation de modèles, un procédé qui utilise les résultats d’un modèle plus grand pour aider à entraîner un modèle plus petit. Kjellberg affirme qu’OpenAI s’est opposé à son activité, tandis qu’OpenAI n’a pas confirmé publiquement les raisons précises à l’origine des deux actions prises sur son compte.

Cette absence de vérification est importante. Le récit de la suspension repose actuellement sur la description de Kjellberg et sur un e-mail affiché dans sa vidéo. Ajax lui-même n’est pas encore disponible pour des tests indépendants.

Malgré cela, le projet révèle une véritable fracture. Les fournisseurs d’IA cloud veulent protéger leurs modèles et leurs services contre l’extraction. Les développeurs d’IA locale veulent des systèmes plus petits qu’ils peuvent personnaliser, inspecter et exécuter sans envoyer en permanence leurs données vers les serveurs de tiers.

Ce qui a changé avec le modèle PewDiePie Ajax AI

Ajax fait évoluer les expérimentations d’IA locale de Kjellberg, de l’assemblage d’outils existants vers la modification d’un modèle pour un espace de travail précis.

La couverture initiale du lancement décrit Ajax comme un assistant toujours actif construit autour de Qwen3.5-9B. Ce modèle de base contient environ 9 milliards de paramètres, soit les valeurs numériques ajustées pendant l’entraînement.

Neuf milliards de paramètres représentent encore un modèle conséquent. Toutefois, cette échelle reste modeste face aux tailles non divulguées et aux besoins d’infrastructure associés aux principaux systèmes cloud.

Cette fondation plus légère soutient le rôle prévu pour Ajax. Kjellberg ne le présente pas comme un modèle universel censé répondre à toutes les questions possibles. Il l’adapte à Odysseus, où des outils peuvent effectuer de nombreuses tâches qui dépendraient autrement des connaissances internes du modèle.

Ces outils incluraient notamment la recherche web, la navigation, l’accès aux e-mails et aux calendriers. Le modèle interprète une demande, décide quel outil utiliser et traite les informations renvoyées. Cette organisation est souvent appelée IA agentique, c’est-à-dire un logiciel capable d’entreprendre plusieurs actions pour atteindre un objectif donné.

Une demande telle que retrouver un message, consulter un calendrier et rédiger une réponse ne nécessite pas toujours un modèle de pointe. Elle exige une sélection fiable des outils, une extraction précise et des garde-fous autour des actions importantes.

Cette distinction explique pourquoi un petit modèle local peut rester utile malgré des connaissances générales plus limitées. Sa valeur provient du système combiné, et non uniquement du nombre de faits encodés dans ses poids.

Ajax promet également un traitement local. Un modèle d’IA local fonctionne sur du matériel contrôlé par l’utilisateur au lieu d’envoyer chaque requête à un service d’inférence distant. Cela peut réduire l’exposition des données à des tiers, sans pour autant sécuriser automatiquement le logiciel environnant.

La page publique du projet présente encore Ajax comme « coming soon ». Au moment de l’annonce, elle ne fournissait ni poids téléchargeables, ni exigences matérielles définitives, ni licence confirmée, ni résultats d’évaluation indépendants.

Le mot « lancement » peut donc être facilement mal compris. Kjellberg a révélé le modèle et démontré son orientation, mais le public ne dispose pas encore d’une version finalisée que les chercheurs peuvent reproduire.

Ajax se situe ainsi entre un projet personnel fonctionnel et un produit public. Il semble exister dans l’environnement de Kjellberg, mais ses performances pratiques restent une affirmation rapportée par son créateur.

Cette incertitude n’efface pas l’événement. Elle en définit plutôt le stade actuel. Un créateur de premier plan a placé le modèle local lui-même au centre de son environnement informatique et de son contenu public.

Kjellberg avait auparavant expérimenté plusieurs modèles hébergés localement, des systèmes de récupération d’information et des groupes d’agents comparant les réponses. Ajax recentre ces expérimentations sur un assistant plus ciblé.

Ce changement crée la tension centrale. Le modèle plus petit est censé moins dépendre de l’IA cloud, mais son historique de développement rapporté impliquait encore les résultats d’un grand fournisseur commercial.

Ajax est local au moment de l’inférence, c’est-à-dire qu’il peut générer des réponses sur le matériel de l’utilisateur. La question sans réponse concerne la part de connaissances générées dans le cloud qui a intégré son processus d’entraînement, et dans quelles conditions.

Pourquoi le différend sur la distillation avec OpenAI est important

Le différend ne porte pas sur l’existence de la distillation. Il concerne qui peut utiliser les résultats d’un fournisseur, à quelle échelle et dans quel but concurrentiel.

La distillation de connaissances implique généralement qu’un modèle enseignant performant produise des exemples, des étiquettes, des classements ou des traces de raisonnement pour un modèle élève plus petit. L’élève apprend à partir de ce matériel synthétique au lieu de ne s’appuyer que sur des données créées manuellement.

Les développeurs utilisent plusieurs variantes de cette technique. Un modèle enseignant peut générer des paires de questions-réponses. Il peut classer plusieurs réponses proposées, critiquer des erreurs ou créer des exemples pour un domaine restreint.

Cette méthode peut rendre un modèle plus petit plus utile sans reproduire l’architecture du modèle enseignant. Elle peut aussi transférer des comportements distinctifs à une échelle qui préoccupe le fournisseur exploitant ce modèle.

Kjellberg affirme qu’OpenAI a suspendu son compte à deux reprises. D’après le récit rapporté, un e-mail affiché dans sa vidéo indiquait la distillation comme motif d’une désactivation.

Il aurait fait appel et récupéré son accès. Il affirme qu’une deuxième suspension a suivi après avoir généré ce qu’il appelait des données initiales pour Ajax.

OpenAI n’a pas publié de déclaration identifiant les requêtes de Kjellberg, son volume d’utilisation, le type de compte ou les éléments justifiant chaque action. Aucune partie indépendante n’a publié de journaux permettant d’établir exactement ce qui s’est passé.

Les lecteurs devraient donc distinguer trois affirmations. Kjellberg affirme que deux suspensions ont eu lieu. Un e-mail montré dans sa vidéo aurait employé le mot « distillation ». L’historique complet de l’application des règles n’est pas public.

Les règles d’OpenAI rendent néanmoins le conflit plus large très clair. Ses conditions commerciales interdisent l’utilisation des résultats pour développer des modèles d’IA concurrençant OpenAI, sauf dans certains cas autorisés.

Ces mêmes conditions limitent l’extraction de données du service en dehors des méthodes approuvées. Elles précisent également que les clients sont propriétaires de leurs résultats, sous réserve du contrat et du droit applicable.

Ces dispositions créent une distinction que les utilisateurs peuvent facilement manquer. Posséder un résultat individuel n’accorde pas nécessairement le droit de collecter des résultats à grande échelle pour n’importe quel objectif ultérieur.

OpenAI a des raisons légitimes de tracer cette limite. L’entraînement et l’exploitation de modèles de pointe exigent d’importants investissements en données, en calcul, en ingénierie et en sécurité. Une extraction sans restriction pourrait permettre à un autre développeur de copier des comportements de valeur sans supporter des coûts comparables.

Des préoccupations de sécurité existent également. Des requêtes systématiques peuvent viser des schémas de raisonnement cachés, des limites de sécurité ou des réponses distinctives. Un fournisseur peut traiter cette activité différemment du développement ordinaire d’applications.

Le contre-argument porte sur l’asymétrie. Les développeurs d’IA ont entraîné des modèles sur d’immenses collections de contenus créés par des humains, souvent sans négocier de licences individuelles. Les utilisateurs peuvent raisonnablement se demander pourquoi les entreprises de modèles exigent un contrôle plus strict lorsque leurs propres résultats deviennent du matériel d’entraînement.

Cette critique ne permet pas de déterminer si Kjellberg a respecté un contrat particulier. Elle explique toutefois pourquoi l’histoire a attiré l’attention au-delà de son audience.

Le différend concentre un débat général dans un exemple accessible. Une personne affirme avoir utilisé un grand service d’IA en développant un modèle local. Les règles du fournisseur se réservent le droit d’empêcher le développement de modèles concurrents à partir de ses résultats.

Le silence d’OpenAI sur ce cas précis laisse aussi des classifications cruciales non résolues. On ne sait pas si Ajax était considéré comme un concurrent commercial, une tentative d’extraction, un volume de génération de données synthétiques enfreignant les règles, ou autre chose.

Cette distinction importe aux développeurs indépendants. Un petit modèle expérimental et un concurrent financé peuvent présenter des risques économiques différents, mais les systèmes d’application automatisés peuvent reconnaître des schémas d’activité plutôt que l’intention.

Les fournisseurs ont également peu d’incitations à révéler leurs méthodes de détection. Des explications détaillées pourraient aider les extracteurs à grande échelle à les contourner. Cependant, une application vague des règles peut rendre plus difficile la planification d’expérimentations légitimes.

Ajax fait passer la distillation de modèles d’une question de politique abstraite à une question d’accès. Les développeurs peuvent utiliser des modèles cloud pour créer des applications, mais ils risquent de perdre cet accès lorsque l’application commence à reproduire les capacités du modèle.

Les petits modèles locaux contestent le modèle par défaut de l’IA cloud

L’argument le plus solide d’Ajax n’est pas qu’un modèle de 9 milliards de paramètres surpasse l’IA de pointe. C’est que de nombreuses tâches courantes ne nécessitent pas d’IA de pointe.

La fiche officielle du modèle Qwen décrit Qwen3.5-9B comme un modèle multimodal prenant en charge le texte, les images, la vidéo, l’utilisation d’outils et les frameworks de service local. Ses poids utilisent la licence Apache 2.0.

Cette fondation accessible donne à Ajax des capacités qui auraient autrefois exigé un effort d’entraînement personnalisé bien plus important. Kjellberg peut partir d’un modèle fonctionnel, en affiner le comportement et le connecter à ses logiciels existants.

L’accès aux outils modifie l’équation des performances. Un assistant n’a pas besoin de mémoriser les réunions d’un utilisateur s’il peut interroger un calendrier. Il n’a pas besoin de disposer de chaque fait actuel dans ses poids s’il peut rechercher sur le web.

La récupération d’information joue un rôle similaire. Un système peut parcourir une collection privée de documents, placer les passages pertinents dans la requête et demander au modèle de répondre à partir de ce contexte.

Cette méthode, appelée génération augmentée par récupération, peut réduire la dépendance à la mémoire du modèle. Elle n’élimine pas les erreurs, mais permet à de plus petits modèles de travailler avec des informations actuelles ou propres à l’utilisateur.

Un développeur qui maintient des documents techniques locaux pourrait appliquer la même approche à une base de connaissances consultable. Le modèle devient une interface vers des informations sélectionnées plutôt que l’unique source de réponses.

L’approche présente des limites pratiques. Les appels d’outils peuvent échouer. Les résultats de recherche peuvent contenir de fausses informations. Un modèle peut mal comprendre une entrée de calendrier, choisir le mauvais destinataire d’e-mail ou agir avant d’avoir levé une ambiguïté.

L’exploitation locale déplace aussi les responsabilités. Un service cloud gère généralement les mises à jour du modèle, la mise à l’échelle et une grande partie du travail de sécurité. Un utilisateur auto-hébergé doit gérer les logiciels, les autorisations, le stockage et le matériel.

Cet arbitrage est au cœur du modèle PewDiePie Ajax AI. Un contrôle accru peut apporter davantage de confidentialité et de personnalisation. Il supprime aussi certains éléments du filet de sécurité opérationnel fourni par un service géré.

Le matériel reste une autre question non résolue. Le modèle sous-jacent est suffisamment petit pour un déploiement local en termes relatifs, mais une vitesse utile dépend de la quantification, de la mémoire disponible, de la longueur du contexte et de la charge de travail.

La quantification réduit la précision utilisée pour stocker les poids d’un modèle. Elle peut diminuer les besoins en mémoire, même si une compression agressive peut affecter la précision ou le comportement.

Les formats quantifiés finaux d’Ajax n’ont pas été publiés. Les spécifications minimales du système Odysseus complet non plus. Exécuter un modèle conversationnel et faire fonctionner un agent toujours actif doté de plusieurs outils peuvent imposer des exigences différentes.

Le projet n’établit donc pas qu’un ordinateur domestique ordinaire puisse reproduire l’expérience de Kjellberg. Il montre qu’un assistant ciblé peut être construit autour d’un modèle bien plus petit que les systèmes derrière les principaux produits hébergés.

Cette approche exerce une pression limitée mais significative sur les fournisseurs cloud. La plupart des utilisateurs n’entraîneront pas de modèles et ne maintiendront pas de serveurs. Les développeurs et les équipes techniquement compétentes peuvent toutefois comparer une dépendance récurrente au cloud avec du matériel qu’ils contrôlent.

La confidentialité ajoute une autre incitation. Les e-mails, calendriers, historiques de navigation et documents personnels constituent un ensemble de données particulièrement sensible. Maintenir l’inférence en local peut réduire la quantité de ces informations transmise à un fournisseur de modèles.

Local ne signifie pas isolé. Ajax peut toujours contacter des moteurs de recherche, des sites web, des serveurs de messagerie ou d’autres services en ligne pendant l’exécution de tâches. Chaque connexion crée ses propres enjeux de confidentialité et de sécurité.

La comparaison utile n’oppose donc pas une « IA locale privée » à une « IA cloud non sûre ». Elle porte sur différentes frontières de confiance.

Un assistant cloud demande aux utilisateurs de faire confiance au fournisseur pour le traitement des données, les contrôles d’accès et les politiques de conservation. Un agent local leur demande de faire confiance à leur propre machine, aux fichiers du modèle, au code environnant et à chaque service connecté.

Ajax privilégie la seconde configuration. Son succès dépendra de la question de savoir si les utilisateurs jugent ce contrôle supplémentaire digne de l’effort d’installation et de maintenance.

La suppression des refus crée un test de sécurité plus exigeant

Le comportement de refus réduit d’Ajax constitue un choix de produit, mais ses affirmations en matière de sécurité ne pourront pas être évaluées avant que le modèle et les méthodes de test ne deviennent publics.

Kjellberg décrit Ajax comme moins restrictif que les assistants grand public. Des informations publiées indiquent qu’il a utilisé Heretic, un outil open source conçu pour modifier le comportement de refus des modèles.

Ce processus est parfois appelé abliteration. Il cherche à identifier les représentations internes associées aux refus et à les affaiblir sans réentraîner entièrement le modèle.

Les refus sont les réponses qu’un modèle fournit lorsqu’il décline une demande. Les fournisseurs les utilisent pour bloquer des instructions nuisibles, protéger les données personnelles et gérer les risques juridiques ou liés aux politiques.

Des refus mal conçus peuvent être frustrants. Un modèle peut rejeter une fiction inoffensive, des recherches en sécurité, une discussion médicale ou une analyse politiquement sensible parce qu’un classificateur de sécurité manque de contexte.

Réduire les refus inutiles peut rendre un modèle local plus utile. Cela peut aussi supprimer les frictions liées à des demandes qui méritent une gestion prudente.

Kjellberg aurait déclaré qu’Ajax conserve des limites pour les instructions impliquant des dommages envers soi-même ou autrui. Il a également indiqué que les conseils dangereux et directement exploitables restent hors de l’usage prévu.

Ces déclarations décrivent l’objectif de conception. Elles ne constituent pas une preuve indépendante que les garde-fous fonctionnent de manière cohérente.

Un modèle peut refuser une demande nuisible directe, mais s’y conformer lorsque la même intention est répartie sur plusieurs prompts. Un agent disposant d’un accès au web et aux fichiers crée des voies supplémentaires auxquelles un chatbot classique n’est pas confronté.

L’injection de prompt en est un exemple. Une instruction malveillante intégrée à une page web ou à un e-mail peut tenter d’annuler la demande de l’utilisateur. Un agent pourrait alors divulguer des informations ou effectuer une action non souhaitée.

Le traitement local n’empêche pas cette attaque. La menace entre par le contenu que l’agent lit, et non par l’endroit où l’inférence est effectuée.

Les autorisations des outils comptent également. Un assistant capable de rechercher dans un calendrier présente moins de risques qu’un assistant autorisé à supprimer des événements. Rédiger un e-mail est différent de l’envoyer automatiquement.

Odysseus pourrait éventuellement traiter ces questions par le biais d’écrans de confirmation, de périmètres d’accès, de journaux ou d’une exécution isolée. La documentation publique n’a pas encore établi le modèle de sécurité final.

Une évaluation indépendante de la sécurité devrait tester plusieurs couches. Les chercheurs devraient examiner la cohérence des refus, l’utilisation abusive des outils, la résistance aux injections de prompt, les fuites de confidentialité et le comportement après de longues conversations.

L’évaluation des performances exige la même prudence. Un score de benchmark du modèle Qwen sous-jacent ne prouverait pas qu’Ajax fonctionne bien après le fine-tuning et la modification des refus.

Le fine-tuning peut améliorer les tâches ciblées tout en affaiblissant des capacités sans rapport. La modification de la sécurité peut également créer des changements comportementaux qui n’apparaissent pas dans une courte démonstration.

Les détails de publication manquants importent donc davantage que l’étiquette « non censuré ». Sans poids téléchargeables, informations d’entraînement versionnées ou évaluations reproductibles, les observateurs extérieurs ne peuvent pas déterminer ce qu’Ajax refuse ni avec quelle fiabilité il accomplit les tâches.

La licence soulève une autre question ouverte. Qwen3.5-9B utilise Apache 2.0, mais une publication dérivée nécessite toujours des conditions claires pour les poids ajoutés d’Ajax, les données d’entraînement et les logiciels de support.

La provenance des données d’entraînement synthétiques mérite une attention particulière. Si des sorties d’OpenAI ont contribué à une part significative de l’ensemble d’entraînement, les utilisateurs potentiels doivent comprendre les implications contractuelles et pratiques.

Cela ne rend pas automatiquement le modèle illégal ou inutilisable. Cela fait de la provenance un élément de la qualité de la publication, au même titre que les benchmarks et les exigences matérielles.

La controverse peut facilement détourner l’attention de ces questions d’ingénierie ordinaires. La décision d’application d’OpenAI est spectaculaire, mais les utilisateurs doivent au final savoir si Ajax fonctionne et s’ils peuvent l’exploiter en toute sécurité.

Le profil public de Kjellberg garantit l’attention. Il ne remplace pas la documentation du modèle, les résultats de red teaming ou des tests reproductibles.

C’est l’angle sceptique essentiel. Ajax présente une stratégie plausible d’IA locale, mais les preuves actuelles proviennent principalement de son créateur. Les affirmations restent provisoires jusqu’à ce que d’autres personnes puissent exécuter le même modèle dans des conditions contrôlées.

Ce qu’il faut surveiller avant qu’Ajax devienne une véritable alternative

Trois signaux détermineront si Ajax devient un assistant local crédible ou reste une expérience personnelle intéressante.

Le premier signal est une publication publique reproductible. Ajax a besoin de poids ou d’adaptateurs téléchargeables, d’une licence claire, d’informations de version et d’instructions que des utilisateurs indépendants peuvent suivre.

Une publication permettrait aux développeurs de vérifier si le modèle PewDiePie Ajax AI est réellement basé sur la version de Qwen indiquée. Ils pourraient aussi examiner l’intégrité des fichiers, les besoins en mémoire, les options de quantification et la complexité de l’installation.

La reproductibilité renforcerait l’argument en faveur de l’IA locale, même si Ajax se montre moins performant que les modèles de pointe. Sa promesse centrale concerne le contrôle et la spécialisation, non la victoire dans tous les benchmarks généralistes.

Des retards persistants, un accès restreint ou l’absence de conditions de licence affaibliraient cet argument. Ils laisseraient le public dépendant des démonstrations du créateur du projet.

Le deuxième signal est le test indépendant. Ajax a besoin d’évaluations couvrant l’exécution des tâches, l’utilisation des outils, l’exactitude factuelle, la latence et le comportement de sécurité.

Les meilleurs tests refléteraient son environnement prévu. Les benchmarks génériques de questions-réponses disent peu de choses sur la capacité d’un agent à effectuer correctement une recherche, sélectionner la bonne entrée de calendrier ou éviter d’agir sur un e-mail malveillant.

Les évaluateurs devraient documenter le matériel et les paramètres du modèle. Un résultat produit sur un vaste système multi-GPU peut ne pas prédire l’expérience sur un ordinateur personnel typique.

Les tests de sécurité devraient inclure les contournements de refus, les injections de prompt, l’exposition de données sensibles et les appels d’outils non intentionnels. Toute affirmation d’exploitation privée devrait aussi préciser quelles tâches contactent encore des services externes.

De solides résultats indépendants montreraient que des modèles locaux ciblés peuvent accomplir un travail pratique malgré leur taille réduite. Des résultats faibles renforceraient l’avantage des fournisseurs cloud en matière de fiabilité et de maintenance.

Le troisième signal est la clarification du différend avec OpenAI. OpenAI pourrait confirmer la catégorie d’application sans révéler ses méthodes de détection, ou Kjellberg pourrait publier des archives plus complètes et davantage de détails sur l’entraînement.

Un récit plus clair aiderait les développeurs à distinguer l’usage autorisé de données synthétiques de la distillation concurrentielle interdite. Il montrerait également si la controverse reflète un comportement inhabituel ou une limite de politique que de nombreux petits créateurs pourraient rencontrer.

Le silence n’empêcherait pas le développement de modèles locaux. Il maintiendrait l’incertitude autour de l’utilisation de sorties d’IA commerciale pour des expérimentations susceptibles de devenir à terme des modèles publics.

La position d’OpenAI en matière d’application et la qualité de publication d’Ajax sont des questions distinctes. L’entreprise peut avoir des restrictions défendables même si Ajax devient utile. Ajax peut démontrer une approche locale précieuse même si Kjellberg a enfreint ces restrictions.

L’issue globale ne sera pas une victoire simple de l’IA locale ou cloud. La plupart des utilisateurs continueront à choisir la commodité, tandis que certains développeurs privilégieront le contrôle, la personnalisation et la localisation des données.

Ajax compte parce qu’il offre à ce second groupe un cas d’essai visible. Un petit modèle connecté à de bons outils peut couvrir davantage de tâches quotidiennes que ne le laisse penser son nombre de paramètres.

Pour l’instant, les lecteurs devraient considérer l’annonce comme une orientation documentée plutôt que comme un produit validé. Surveillez la publication de poids publics, de tests d’agents reproductibles et d’un dossier d’entraînement plus clair.

Si ces éléments arrivent, le projet local d’IA Ajax apportera des preuves sur la quantité de travail pouvant être déplacée hors des modèles de pointe hébergés. Dans le cas contraire, le différend sur l’interdiction par OpenAI restera plus développé que l’assistant lui-même.