DeepSeek ouvre son infrastructure d’agents afin que chaque composant puisse être remplacé

DeepSeek a publié la première préversion développeur de Harness, et l’enjeu derrière le titre de Google News est particulièrement concret. L’entreprise ne se contente pas d’ajouter des plugins à un nouvel agent de programmation. Elle a rendu interchangeables l’adaptateur de modèle, le registre d’outils, le journal de session, le sandbox, la boucle d’agent et l’interface utilisateur.

Cette conception place DeepSeek Harness en dessous de produits tels que Claude Code, Codex et d’autres agents de programmation prêts à l’emploi. Ces produits offrent aux développeurs un agent assemblé, doté de points d’extension définis. DeepSeek propose une base configurable capable de produire de nombreux agents, dont l’un peut ressembler à un assistant de programmation.

Cette distinction met également en lumière la plus grande incertitude du projet. DeepSeek affirme que chaque élément peut être combiné, remplacé ou étendu, mais le logiciel reste une préversion développeur. Sa documentation avertit explicitement que des changements incompatibles avec les versions précédentes surviendront. Le lancement constitue donc à la fois une proposition d’architecture et un test inachevé visant à déterminer si une modularité extrême peut résister à une utilisation en production.

Ce que le titre de Google News annonçait réellement

DeepSeek a ouvert les mécanismes qui entourent un modèle d’IA, plutôt que de publier un nouveau modèle avec une nouvelle interface de chat.

DeepSeek Harness, également appelé dsh, est une infrastructure d’agents open source publiée sous licence MIT. Une infrastructure d’agents est le logiciel qui entoure un modèle et gère les prompts, les outils, les fichiers, l’état, les autorisations et les appels répétés au modèle.

Le dépôt officiel du projet décrit une idée directrice : « Everything is a Plugin ». Cela inclut les modèles, compétences, outils, sessions, sandboxes, systèmes de fichiers, boucles, orchestration et l’interface présentée aux utilisateurs.

DeepSeek indique que la version actuelle est une préversion développeur. Les utilisateurs peuvent lancer son interface navigateur via une commande npm, qui sert l’application localement par défaut. Les développeurs peuvent également compiler le dépôt depuis le code source.

La publication publique a suivi des signes montrant que DeepSeek constituait une équipe dédiée à Harness. Cependant, le code compte davantage que le précédent signal de recrutement. Il fournit aux développeurs un système concret à examiner, modifier et exécuter sans dépendre d’une démonstration produit.

Cela explique pourquoi l’information a circulé dans Google News comme davantage qu’un simple lancement de dépôt. DeepSeek est devenu largement connu pour ses modèles compétitifs, mais Harness déplace l’attention vers le logiciel qui détermine comment un modèle accomplit un travail réel.

Un modèle de langage brut reçoit une entrée et génère une sortie. Un agent opérationnel doit aussi décider quand appeler un outil, quel historique conserver, où les commandes peuvent s’exécuter et quand une approbation humaine est requise.

Ces décisions expliquent souvent pourquoi deux produits utilisant des modèles similaires se comportent différemment. Le système environnant peut se remettre d’une commande échouée, maintenir un plan, compresser le contexte ou empêcher une opération de fichier dangereuse. Il peut également mal gérer chacune de ces responsabilités.

DeepSeek fait de ce système environnant le produit. Son application web livrée est une composition possible des composants sous-jacents, et non une implémentation privilégiée que chaque utilisateur doit accepter.

Le framework repose sur Cordis, que DeepSeek décrit comme un méta-framework pour des logiciels composés dynamiquement. Cordis permet aux plugins d’apporter des services, des événements typés et des effets réversibles à un contexte partagé.

Un effet réversible est une modification suivie qui peut être annulée lorsque le composant qui l’a apportée est déchargé. Cela fournit à l’environnement d’exécution un moyen structuré d’ajouter ou de supprimer des capacités sans laisser derrière lui un état inconnu.

Cette fondation soutient la promesse plus large de DeepSeek. Les développeurs devraient pouvoir remplacer un fournisseur de système de fichiers local par une implémentation distante, changer l’adaptateur de modèle ou introduire une autre boucle d’agent par configuration.

La publication n’établit pas que chaque combinaison fonctionnera de manière fiable. Elle établit en revanche que DeepSeek a tracé des frontières de plugins autour de composants que d’autres produits d’agents traitent fréquemment comme fixes.

Cette différence crée la tension centrale. Des mécanismes plus facilement remplaçables donnent davantage de contrôle aux développeurs, mais ils créent aussi davantage d’interfaces, de relations de dépendance et de modes de défaillance à gérer.

Pourquoi DeepSeek Harness met la pression sur les agents de programmation finalisés

DeepSeek remet en question l’idée selon laquelle les développeurs ne devraient personnaliser un agent qu’à ses marges.

La plupart des assistants de programmation exposent des mécanismes d’extension tout en préservant un centre assumé. Les développeurs peuvent ajouter des outils, connecter des services externes, installer des compétences ou modifier des instructions. Le produit conserve toutefois la maîtrise de sa boucle principale, de son modèle de session et de son interface.

DeepSeek Harness déplace vers l’intérieur la frontière de ce qui peut être remplacé. Sa documentation d’architecture indique qu’il n’existe aucun noyau privilégié que les développeurs doivent corriger.

Même la boucle d’agent par défaut est enregistrée via le même contexte partagé que les autres capacités. Cette boucle contrôle la manière dont l’entrée utilisateur devient des requêtes au modèle, des appels d’outils, des résultats et des étapes ultérieures.

Cela ne rend pas Claude Code, Codex ou des produits similaires obsolètes. Les agents de programmation matures réunissent l’installation, les mises à jour, l’authentification, l’accès aux modèles, les règles de sécurité et les choix d’interface dans une expérience cohérente.

Cet assemblage a une valeur réelle. Un développeur qui doit corriger un test aujourd’hui préférera peut-être un outil doté de paramètres par défaut judicieux à un framework exigeant des choix architecturaux.

DeepSeek exerce plutôt une pression sur les équipes de recherche, les ingénieurs de plateformes et les organisations qui souhaitent d’autres paramètres par défaut. Ces utilisateurs peuvent avoir besoin d’un sandbox personnalisé, d’une passerelle interne vers les modèles, d’un stockage contrôlé ou d’un chemin d’exécution auditable.

Un adaptateur de modèle remplaçable est particulièrement important. Il sépare le comportement de l’agent d’une dépendance exclusive envers un seul fournisseur de modèles.

La propre documentation API de DeepSeek traite déjà d’infrastructures tierces, dont l’agent de programmation extensible Pi. Le guide d’intégration Pi contient également un avertissement précisant que DeepSeek ne garantit ni l’efficacité ni la sécurité de tiers.

Harness propose une autre réponse. Au lieu de demander aux développeurs d’adapter les modèles DeepSeek à un agent externe, DeepSeek peut fournir l’architecture environnante tout en autorisant d’autres fournisseurs de modèles.

Le principal affrontement porte ainsi moins sur DeepSeek face à une entreprise nommée que sur une base hautement configurable face à un produit d’agent finalisé et assumé.

La voie de la base permet à une organisation de définir le fonctionnement de son système. Une équipe pourrait utiliser un modèle pour la planification, un autre pour la génération de code et un modèle local pour la classification de données sensibles. Les fournisseurs peuvent se trouver derrière une frontière d’adaptateur partagée.

Cette même équipe pourrait attribuer différents outils à différents agents. Un spécialiste des bases de données pourrait recevoir un accès en lecture seule, tandis qu’un agent de déploiement obtiendrait des contrôles de publication strictement limités.

Ces restrictions peuvent résider dans des capacités enregistrées et des politiques d’exécution. Elles ne doivent pas dépendre uniquement d’une phrase dans un prompt système.

La voie du produit assumé implique d’autres compromis. Elle limite le nombre de choix que les utilisateurs doivent comprendre, concentre les tests sur les parcours pris en charge et crée une cible de support cohérente.

DeepSeek Harness met donc la pression sur les produits établis au niveau de l’architecture, pas nécessairement au niveau de l’utilisateur quotidien. Les concurrents doivent décider quelle part de leurs mécanismes internes les développeurs devraient pouvoir remplacer.

Ils peuvent garder le centre sous contrôle et étendre les extensions prises en charge. Ils peuvent exposer des SDK et des services de plus bas niveau. Ils peuvent aussi soutenir qu’un remplacement complet crée une complexité opérationnelle sans bénéfice pratique suffisant.

La réponse immédiate imposée ne sera peut-être pas un framework équivalent. Le signal le plus fort viendra de la manière dont les fournisseurs d’agents clarifieront leurs frontières architecturales et rendront davantage de comportements inspectables.

Pour les acheteurs d’entreprise, il ne s’agit pas d’une distinction abstraite. Un système de session fixe peut entrer en conflit avec les exigences de conservation. Un sandbox fixe peut ne pas prendre en charge l’infrastructure d’une organisation. Un pipeline d’outils fixe peut ne pas disposer des étapes d’approbation requises.

Les développeurs qui suivent ce lancement via Google News devraient donc se concentrer sur la propriété. DeepSeek propose que les équipes possèdent davantage de la pile d’agents, même lorsque cette propriété implique un travail supplémentaire.

Tout est un plugin, y compris la boucle d’agent

Le mécanisme notable n’est pas le nombre de plugins, mais l’absence d’un centre protégé que les plugins ne peuvent remplacer.

Une instance DeepSeek Harness en cours d’exécution est assemblée sous forme d’arbre de plugins. Les profils définissent des compositions nommées, tandis que les bundles regroupent des lignes de configuration et le code que ces lignes montent.

DeepSeek fournit des modèles web et headless. Le bundle de base fournit des adaptateurs de modèles, des outils, de la persistance, des contrôles de sandbox, des politiques d’approbation, des identifiants, des paramètres et de la télémétrie.

Des bundles supplémentaires peuvent ajouter une application navigateur ou un exécuteur à usage unique. Les couches de configuration s’appliquent dans l’ordre, et les correctifs ultérieurs peuvent remplacer des lignes ou en introduire de nouvelles.

Cette organisation permet à deux agents de partager une grande partie du même code tout en exposant des capacités différentes. Un profil peut inclure une interface navigateur et un shell local. Un autre peut fonctionner sans serveur au sein d’un workflow automatisé.

Le projet répartit le comportement central en paquets. Les sessions possèdent un journal d’événements en ajout seul, ce qui signifie que les événements enregistrés sont ajoutés plutôt qu’écrasés silencieusement. Les outils disposent d’un registre à portée limitée et d’un pipeline d’exécution protégé.

Le paquet de prompt système assemble les sections de prompt et les schémas d’outils. Le paquet de modèle de langage fournit le vocabulaire des messages et la frontière d’adaptateur de fournisseur. Le paquet d’agent expose les agents actifs et les événements associés.

Un tour peut comporter plusieurs étapes. Chaque étape consiste en une requête au modèle et les outils appelés à partir de cette requête.

Avant l’exécution, les plugins peuvent inspecter ou rejeter le travail au moyen d’événements définis. La sortie du modèle est diffusée en continu dans la session, les appels d’outils passent par des étapes pré-exécution et post-exécution, et les résultats peuvent déclencher une autre requête au modèle.

Cette structure événementielle est importante, car l’extensibilité seule ne garantit pas un comportement cohérent. Les plugins ont besoin de points convenus où ils peuvent observer, modifier ou arrêter le processus.

DeepSeek utilise des événements de session persistants pour les faits qui doivent survivre à un rechargement. Il utilise des événements d’agent en direct pour le travail actuellement en cours. Les événements de capacité permettent aux politiques et aux adaptateurs de se connecter aux sous-systèmes sans importer l’intégralité de la boucle.

Le journal de session sert de source de vérité pour le contexte visible par le modèle. DeepSeek affirme que tout élément atteignant une requête au modèle doit pouvoir être reconstruit à partir de ce journal.

Ce choix relie plusieurs fonctionnalités souvent mises en œuvre indépendamment. La reprise, le fork, les transcriptions, la persistance, la relecture et la télémétrie peuvent dériver du même flux d’événements.

L’alternative consiste à maintenir des représentations distinctes pour l’interface, le contexte du modèle, l’historique enregistré et le système d’observabilité. Ces copies peuvent diverger après des erreurs, des annulations ou une compression du contexte.

La conception de DeepSeek ne peut pas éliminer automatiquement ces divergences. Les implémentations de plugins peuvent toujours contenir des bugs. Toutefois, une source d’événements commune offre aux développeurs un endroit défini pour examiner ce qui s’est passé.

Les points d’articulation des capacités ajoutent une autre couche. DeepSeek définit un point d’articulation par une interface de service, un fournisseur mettant en œuvre cette interface et un consommateur utilisant le service.

Considérez l’accès au système de fichiers. Un outil destiné au modèle peut demander une opération sur un fichier, tandis qu’un fournisseur de système de fichiers décide où et comment cette opération s’effectue.

Remplacer le fournisseur peut rediriger cette capacité depuis un espace de travail local vers un bac à sable distant. Les opérations associées du shell, du terminal et du serveur de langage peuvent alors partager cet environnement d’exécution.

Il s’agit d’une forme de modularité plus profonde que l’ajout d’une commande à un assistant existant. Elle modifie l’emplacement et la politique du travail de l’assistant sans réécrire chaque consommateur.

Les sous-agents utilisent une frontière similaire. Un fournisseur peut créer un agent enfant dans Harness. Un autre peut déléguer la tâche à un produit distinct tout en préservant l’interface parente.

Cordis fournit le modèle de composition sous-jacent. Son article de présentation du framework décrit la composabilité temporelle comme le fait de retirer un composant et d’inverser complètement ses effets.

L’article définit la composabilité spatiale comme la déclaration de dépendances et la réaction aux changements du contexte partagé. Cordis combine ces concepts via des effets suivis, la résolution des dépendances, la réconciliation de configuration et le remplacement à chaud des modules.

L’article a été publié sous la forme d’un brouillon daté du 13 août 2026. Ses auteurs avertissent qu’il s’agit d’une prépublication en cours de révision et que son contenu pourrait évoluer sensiblement.

Cet avertissement est important. Un vocabulaire formel peut faciliter la discussion d’une architecture, mais il ne valide pas à lui seul ses performances, sa fiabilité ou sa sécurité.

Le mécanisme de DeepSeek reste convaincant parce qu’il aligne la théorie sur une structure de dépôt observable. Le document d’architecture désigne les services, paquets, événements, couches de configuration et points de remplacement.

Le résultat ressemble davantage à un environnement d’exploitation pour agents qu’à un assistant unique. Les modèles et les outils sont des applications de cet environnement, tandis que le système de contexte et d’événements les coordonne.

Pour les développeurs, l’avantage réside dans une recomposition maîtrisée. Pour DeepSeek, l’avantage est d’ordre stratégique. Ses modèles peuvent y participer, mais Harness n’exige pas que tout l’écosystème dépende d’une seule famille de modèles.

L’avertissement sur la Developer Preview est le véritable risque

L’affirmation de flexibilité de DeepSeek est visible dans le code, mais la préparation à la production reste non démontrée et explicitement écartée.

Le dépôt avertit en lettres capitales que des changements rompant la compatibilité surviendront. Ce n’est pas une simple note de version. Cela modifie la façon dont les organisations devraient évaluer le projet.

Une équipe peut expérimenter avec DeepSeek Harness dès aujourd’hui. Elle ne devrait pas supposer que les profils, contrats de plugins, fichiers de configuration ou services internes resteront stables au fil des mises à jour.

Cette incertitude est particulièrement importante pour un framework conçu autour d’interfaces remplaçables. Chaque composant personnalisé dépend d’un contrat, même lorsque l’architecture réduit au minimum le couplage direct.

Si ces contrats changent, les développeurs de plugins doivent mettre à jour leurs implémentations. Une modularité profonde peut contenir un changement, mais elle ne peut pas supprimer le coût de maintenance des frontières.

La configuration présente également un risque subtil. Le système de superposition documenté remplace toute la configuration d’une ligne ciblée au lieu de combiner automatiquement chaque valeur imbriquée.

Cette règle peut être prévisible pour des opérateurs expérimentés. Elle peut aussi entraîner des paramètres manquants lorsque les utilisateurs supposent qu’un correctif partiel préservera les champs non spécifiés.

Le défi plus large est celui des tests combinatoires. Un produit fini peut valider un ensemble limité de combinaisons de modèles, d’outils, de bacs à sable et d’interfaces.

Un framework qui permet à chaque couche de changer fait face à une surface de compatibilité bien plus vaste. DeepSeek ne peut pas tester de manière réaliste chaque adaptateur de modèle tiers avec chaque pipeline d’outils et fournisseur de stockage.

La responsabilité se déplace donc vers les auteurs de profils et les équipes de déploiement. Ils doivent tester la composition exacte qu’ils prévoient d’exploiter.

La sécurité exige une prudence similaire. Les bacs à sable et politiques d’outils remplaçables permettent une isolation plus forte, mais cette capacité de remplacement ne garantit pas une configuration sûre.

Un fournisseur de sous-processus permissif peut compromettre une liste d’outils soigneusement restreinte. Un plugin personnalisé peut mal gérer des identifiants, exposer un contexte sensible ou contourner le comportement d’approbation attendu.

L’open source aide les examinateurs à inspecter ces chemins. Cela ne signifie pas que chaque plugin portant un sujet dsh-plugin a fait l’objet d’un audit de sécurité.

La découverte de plugins devient elle-même un problème de confiance. Les développeurs ont besoin de connaître la provenance, la compatibilité des versions, les signaux de maintenance et le code qui accède aux sessions ou aux identifiants.

Les écosystèmes de paquets traditionnels peinent déjà face aux dépendances malveillantes et aux modules abandonnés. Un plugin d’agent peut jouer un rôle encore plus sensible, car il peut observer les prompts, le code source, les résultats d’outils et l’état d’exécution.

Le journal append-only crée un autre compromis. Un historique d’événements détaillé facilite la relecture et l’audit, mais le contexte du modèle stocké peut contenir du code propriétaire, des documents internes ou des données utilisateur sensibles.

Les organisations doivent décider où ce journal réside, qui peut y effectuer des recherches, combien de temps il reste disponible et comment les exigences de suppression sont appliquées.

Le framework propose le stockage comme une préoccupation remplaçable. La préparation à l’entreprise dépendra de la capacité des déploiements réels à configurer la conservation et les contrôles d’accès sans affaiblir les garanties de relecture.

L’attention de Google News risque également de transformer l’enthousiasme architectural en affirmations de performances non étayées. DeepSeek n’a pas établi avec ce lancement que Harness rend ses modèles plus précis que ceux de ses concurrents.

La sortie ne fournit pas de benchmark neutre montrant que la composition de plugins améliore l’exécution des tâches. Elle ne prouve pas non plus que la récupération de Cordis produit de meilleurs résultats lors de travaux de longue durée.

Un harness performant peut rendre un modèle plus utile en lui apportant les bons outils et le bon contexte. Il ne peut pas corriger toutes les limites du modèle sous-jacent.

Une planification faible reste une planification faible. Une sélection incorrecte d’outils peut toujours provoquer un échec. Un agent peut conserver un journal parfait d’une approche infructueuse.

Les retours d’utilisateurs publiés immédiatement après une sortie peuvent révéler des pistes utiles, mais ils ne remplacent pas des tests contrôlés. Les premiers adoptants s’auto-sélectionnent, les configurations varient et la nouveauté peut influencer le jugement.

Les développeurs devraient évaluer le framework à l’aide de dépôts représentatifs et de tâches reproductibles. Les tests devraient inclure des opérations interrompues, des autorisations refusées, des outils défaillants, la compression du contexte et les mises à niveau de plugins.

Ils devraient également comparer des configurations de modèles et d’outils équivalentes. Sinon, un résultat favorable pourrait refléter un meilleur modèle, un ensemble d’autorisations plus large ou une tâche plus simple plutôt que le harness.

DeepSeek mérite d’être reconnu pour avoir décrit précisément la sortie. L’avertissement de developer preview définit une attente honnête : le projet évolue rapidement.

La question suivante est de savoir si DeepSeek maintiendra cette clarté à mesure que l’adoption progressera. Un versionnage stable, des guides de migration, des rapports de sécurité et des tests de compatibilité compteront davantage que le slogan de lancement initial.

Que surveiller après l’attention de Google News

Trois signaux indiqueront si DeepSeek Harness devient une infrastructure durable ou demeure une expérience admirée.

Le premier signal est la stabilisation des contrats. Les développeurs devraient surveiller les notes de version afin d’y repérer des politiques de compatibilité définies concernant les plugins, les profils, les événements de session et les interfaces de capacités.

Les changements cassants sont normaux durant un aperçu précoce. La mesure importante est de savoir si ces changements convergent vers des surfaces stables documentées.

Des outils de migration renforceraient les arguments en sa faveur. Des périodes de dépréciation claires et des schémas de configuration vérifiables par machine réduiraient le coût de maintenance des profils personnalisés.

Si DeepSeek stabilise les principales jointures sans figer les progrès architecturaux, son argument en faveur du framework deviendra plus solide. Des réécritures répétées d’intégrations de plugins l’affaibliraient.

Le deuxième signal est l’existence de preuves opérationnelles indépendantes. Les équipes ont besoin de tests reproductibles impliquant de vrais dépôts, de longues sessions, des défaillances d’outils et des bacs à sable contraints.

La réussite des tâches n’est qu’un indicateur parmi d’autres. Les évaluateurs devraient aussi mesurer le comportement de récupération, le travail dupliqué, la précision du contexte, l’application des autorisations et l’effort requis pour diagnostiquer les défaillances.

Les benchmarks devraient distinguer la capacité du modèle du comportement du harness. Le même modèle devrait, dans la mesure du possible, être exécuté avec différentes configurations de harness.

Un test crédible devrait aussi publier ses autorisations et les outils disponibles. Un agent doté d’un accès shell sans restriction ne devrait pas être comparé à la légère avec un autre opérant dans un bac à sable étroit.

Si des évaluations indépendantes démontrent une récupération fiable et une exécution inspectable, le mécanisme de DeepSeek gagnera en crédibilité. Si les résultats dépendent d’un réglage manuel intensif, le framework restera surtout utile aux spécialistes.

Le troisième signal est la qualité de l’écosystème de plugins. Le nombre de dépôts et l’attention sociale mesurent la curiosité, non une offre fiable.

Les plugins utiles nécessitent une documentation maintenue, une couverture de tests, des pratiques de sécurité et des informations explicites sur la compatibilité. Un écosystème digne de confiance a également besoin de processus pour signaler les paquets malveillants ou abandonnés.

DeepSeek encourage les développeurs à étiqueter les dépôts de plugins afin de faciliter leur découverte. L’étape suivante consiste à disposer d’un moyen fiable d’évaluer quelles extensions méritent l’accès aux outils, aux sessions et aux identifiants.

Ce signal déterminera qui adoptera le framework. Les équipes de recherche peuvent auditer elles-mêmes des modules expérimentaux. La plupart des équipes d’entreprise ont besoin d’un ensemble plus restreint de composants pris en charge et révisables.

Les réactions des concurrents méritent d’être suivies au regard de ces trois signaux. Un rival n’a pas besoin de copier Cordis pour valider la direction prise par DeepSeek.

Davantage de bacs à sable remplaçables, d’historiques d’événements exportables, de boucles d’agents documentées ou de SDK d’orchestration de plus bas niveau suggéreraient tous que les développeurs demandent davantage de contrôle sous l’interface.

Le silence ne signifierait pas automatiquement l’échec. Des produits établis peuvent continuer de s’imposer grâce à leur facilité d’utilisation, leur support et les performances intégrées de leurs modèles.

Le meilleur scénario pour DeepSeek serait un marché divisé. Les agents finalisés serviraient les utilisateurs qui veulent un outil cohérent, tandis que Harness servirait les équipes construisant des agents spécialisés à partir de composants interchangeables.

Cette division reflète l’histoire plus large du logiciel. Les frameworks et les applications finalisées coexistent souvent parce qu’ils résolvent des problèmes de propriété différents.

Les travailleurs du savoir n’utiliseront peut-être pas DeepSeek Harness directement, mais son architecture les affecte tout de même. Les systèmes d’agents touchent de plus en plus aux fichiers de projet, à la recherche interne, aux messages et aux connaissances organisationnelles.

Lorsque ces systèmes échouent, les utilisateurs doivent savoir quel contexte le modèle a reçu et quels outils ont agi. Un historique d’événements reconstructible peut rendre cette enquête plus concrète.

Les équipes qui construisent des flux de travail d’IA connexes devraient appliquer la même discipline à leurs sources d’information. Une base de connaissances IA maintenue peut préserver les documents et les décisions entourant la sortie d’un agent.

Cette pratique ne résout pas la sécurité à l’exécution. Elle aide les personnes à distinguer les conclusions générées des éléments de preuve et du contexte institutionnel utilisés pour y parvenir.

Le jugement final devrait rester circonscrit. DeepSeek a publié une proposition architecturale sérieuse, accompagnée de code fonctionnel, d’une documentation détaillée et d’une définition inhabituellement large d’un plugin.

Il n’a pas encore démontré que des développeurs ordinaires peuvent gérer cette flexibilité en toute sécurité. Il n’a pas démontré que les composants tiers resteront compatibles ni que la conception produit de meilleurs résultats sur les tâches.

Le titre de Google News saisit l’idée mémorable, mais les trois prochains mois devraient être évalués à l’aune de contrats stables, de tests opérationnels indépendants et de plugins dignes de confiance.

Si vous évaluez DeepSeek Harness, commencez par un flux de travail circonscrit. Consignez le modèle, les outils, les autorisations, le profil et le résultat attendu. Interrompez ensuite l’exécution, refusez un outil, remplacez un fournisseur, puis vérifiez si le journal des événements explique toujours le résultat. Cet exercice met à l’épreuve la thèse réelle de DeepSeek plus efficacement qu’une liste de fonctionnalités. La question n’est pas de savoir si tout peut devenir un plugin. Elle est de savoir si les équipes peuvent remplacer ces plugins sans perdre en fiabilité, en sécurité ou en capacité à comprendre ce qu’a fait leur agent.