DeepSeek Harness se lance et place le runtime d’agent au-dessus du modèle

DeepSeek a publié DeepSeek Harness v0.1 le 13 août 2026, ouvrant un nouveau front qui dépasse la seule performance des modèles. Cette préversion destinée aux développeurs fournit un runtime open source permettant d’assembler des agents à partir de modèles, outils, compétences, sessions, sandboxes et interfaces interchangeables. Cette initiative place DeepSeek en concurrence directe avec les couches logicielles qui transforment les modèles de langage en produits fonctionnels.

Il ne s’agit pas d’un nouveau checkpoint de modèle. DeepSeek Harness, également appelé dsh, détermine comment un modèle reçoit son contexte, appelle des outils, gère les fichiers, conserve les sessions et réalise un travail en plusieurs étapes. Lors de tâches réelles, ces choix peuvent compter autant que le modèle sous-jacent.

Cette sortie modifie également la position de DeepSeek sur le marché des développeurs. Jusqu’à présent, de nombreuses équipes utilisaient les modèles DeepSeek au sein de produits d’agents contrôlés par d’autres fournisseurs ou des projets indépendants. DeepSeek peut désormais influencer à la fois le moteur de raisonnement et le runtime qui l’entoure.

L’enjeu central n’est donc pas simplement DeepSeek face à un autre fournisseur de modèles. Il oppose un runtime ouvert et composable à des agents verticalement intégrés tels que Claude Code et OpenAI Codex. DeepSeek promet davantage de composants remplaçables, mais le statut de préversion reporte une plus grande part de la responsabilité d’intégration et de sécurité sur les développeurs.

DeepSeek Harness est un runtime, pas une nouvelle sortie de modèle

Le changement important est que DeepSeek fournit désormais le logiciel qui contrôle ce qui se passe avant, pendant et après chaque appel de modèle.

Un harness d’agent est la couche de runtime qui relie un modèle aux outils, à la mémoire, aux fichiers, aux autorisations, aux interfaces et aux boucles d’exécution. Il décide de ce que le modèle peut observer, des actions qu’il peut demander et de la manière dont le système traite ces demandes.

DeepSeek présente son nouveau projet comme un harness d’agent open source construit autour d’un principe : « Everything is a plugin. » Le dépôt officiel du projet répertorie les modèles, outils, compétences, sessions, sandboxes, systèmes de fichiers, boucles, mécanismes d’orchestration et interfaces utilisateur comme des composants remplaçables.

Cette liste révèle l’ampleur de la sortie. DeepSeek ne propose pas seulement une fenêtre de chat de programmation dotée d’un workflow fixe. L’entreprise publie une couche d’assemblage à partir de laquelle les développeurs peuvent construire différents produits d’agents.

La préversion initiale pour développeurs inclut une interface web qui s’exécute localement. Les développeurs disposant de Node.js peuvent la lancer via le package @deepseek-ai/dsh, l’interface étant servie par défaut sur une adresse locale.

Le dépôt inclut également un profil headless pour les tâches sans interface graphique. Un exemple documenté demande à l’agent de résumer un espace de travail depuis la ligne de commande. Un autre expose des sessions d’agent via un protocole d’automatisation utilisant JSON-RPC sur l’entrée et la sortie standard.

Ces points d’entrée confèrent plusieurs rôles possibles à DeepSeek Harness. Un développeur individuel peut l’exécuter comme interface locale d’agent. Une équipe peut utiliser ses packages comme fondations pour un agent interne. Une entreprise de produits peut intégrer certains services sans adopter l’interface complète.

DeepSeek a publié le projet sous licence MIT. Cette licence permet une utilisation, une modification et une redistribution étendues, à condition de conserver les mentions de copyright et de licence requises.

Le choix de licence est important, car un harness se trouve exceptionnellement proche de l’environnement opérationnel d’une organisation. Il peut accéder aux dépôts, aux lignes de commande, à la documentation interne, aux identifiants et aux services externes. Les entreprises doivent souvent pouvoir inspecter ou modifier cette couche avant de l’approuver.

Le dépôt présente la v0.1 comme une préversion pour développeurs, et non comme un produit d’entreprise finalisé. DeepSeek avertit explicitement que des changements incompatibles avec les versions précédentes surviendront. Les développeurs devraient donc considérer cette sortie comme une invitation à expérimenter et à contribuer, plutôt que comme la promesse d’interfaces stables.

Cet avertissement ne rend pas le lancement anodin. Il précise ce qui a changé le 13 août. DeepSeek est passé de la fourniture d’intelligence par le biais de modèles et d’API à la fourniture de la structure opérationnelle qui transforme l’intelligence en action.

Pourquoi DeepSeek remonte dans la pile des agents

L’accès aux modèles devient interchangeable, tandis que le harness détermine de plus en plus si un agent est utile, contrôlable et difficile à remplacer.

Un modèle brut peut générer du code, analyser une demande ou suggérer une commande. Il ne peut pas inspecter de façon autonome un dépôt ni modifier un fichier, à moins qu’un autre système ne lui fournisse ces capacités. Le harness fournit ce système.

Cette distinction devient visible lors de tâches longues. Un agent de programmation doit décider quels fichiers inspecter, quelles informations conserver et quand appeler un outil. Il doit détecter les commandes qui échouent, réviser son plan et préserver une session cohérente.

Deux produits utilisant le même modèle peuvent obtenir des performances différentes parce que leurs harnesses font des choix différents. L’un peut proposer des descriptions d’outils plus claires. Un autre peut résumer le contexte plus efficacement. Un troisième peut isoler les commandes dans une sandbox plus robuste.

Cette réalité exerce une pression sur les fournisseurs de modèles. Si un agent externe contrôle l’interface, le workflow, les intégrations d’outils et l’historique utilisateur, le modèle sous-jacent peut devenir une entrée interchangeable. Le fournisseur du harness conserve la relation client et décide quels modèles reçoivent du trafic.

DeepSeek Harness répond directement à ce risque. Il offre à DeepSeek une couche logicielle dans laquelle ses modèles peuvent devenir l’option par défaut, tout en laissant le composant modèle interchangeable. L’entreprise cherche à gagner de l’influence sur le runtime sans abandonner une architecture ouverte.

Le calendrier suit également le passage du secteur des assistants conversationnels vers des agents capables d’accomplir un travail en plusieurs étapes. Les développeurs évaluent désormais bien plus que la qualité des réponses. Ils s’intéressent à la fiabilité des outils, à la gestion du contexte, à la sécurité d’exécution, à l’observabilité et à la récupération après erreur.

La documentation de DeepSeek reflète elle-même ces préoccupations opérationnelles. Son guide de développement sépare les systèmes hôte et client, documente les contrôles automatisés et décrit des tests avec API simulées et réelles. Il fournit aussi des interfaces pour le web, l’usage headless et l’automatisation.

Il s’agit d’une surface produit différente de celle d’un endpoint d’API. Une API peut rester stable pendant que les développeurs externes inventent les workflows qui l’entourent. Un harness doit coordonner de nombreux services dont le comportement évolue à mesure que des plugins entrent ou sortent d’une session active.

DeepSeek obtient également un moyen d’apprendre auprès des développeurs. Un système public de plugins peut révéler quels outils, workflows et modèles d’agents attirent l’adoption. Ces retours peuvent influencer l’entraînement futur des modèles, le comportement d’utilisation des outils et la conception des API.

Cette stratégie rappelle un modèle de plateforme bien connu. Une entreprise fournit d’abord un composant technique de base. Elle s’installe ensuite dans la couche d’orchestration où les développeurs combinent ce composant avec des données, des outils et des expériences utilisateur.

Cependant, DeepSeek ne se contente pas de refermer la pile autour de ses propres services. Sa conception de plugins de modèles permet à d’autres fournisseurs ou à des modèles locaux d’occuper la même position. Cette ouverture crée la tension la plus intéressante de cette sortie.

Si l’architecture fonctionne, DeepSeek peut devenir une plateforme d’agents influente même lorsque les développeurs combinent plusieurs modèles. Dans le cas contraire, le projet pourrait surtout servir d’interface supplémentaire pour l’API de DeepSeek.

La distinction dépendra de l’adoption au-delà de la base d’utilisateurs existante de DeepSeek. Les développeurs devront juger les contrats de plugins plus faciles à étendre que les frameworks concurrents. Les équipes devront également faire confiance au runtime qui entoure des outils et fichiers sensibles.

Le pari de DeepSeek Harness : tout doit être remplaçable

DeepSeek parie que les développeurs d’agents accordent plus de valeur à la composabilité qu’à la commodité d’un produit étroitement contrôlé.

L’architecture du projet s’appuie sur Cordis, que DeepSeek décrit comme un méta-framework de composabilité spatio-temporelle. En pratique, Cordis gère des services dont la disponibilité et les relations peuvent évoluer au fil du temps et selon les contextes d’exécution.

Une application traditionnelle initialise souvent ses dépendances une seule fois et les considère comme fixes. Un environnement d’agents fonctionne différemment. Une session peut activer un outil pour une tâche, créer un contexte d’exécution limité, puis supprimer les deux lorsque la tâche est terminée.

La fondation Cordis de DeepSeek est conçue pour cet environnement changeant. Les plugins peuvent fournir des services, consommer d’autres services et réagir à l’évolution de leur contexte environnant. Le framework lui-même reste en développement actif et son API n’est pas stable.

DeepSeek Harness applique cette approche à l’ensemble de la pile d’agents. Un adaptateur de modèle devient un plugin. Il en va de même pour une collection d’outils, un système de fichiers, une sandbox, un gestionnaire de sessions, une interface utilisateur ou une boucle d’orchestration.

Cette structure donne aux développeurs plusieurs formes de contrôle. Ils peuvent remplacer un modèle sans reconstruire l’interface. Ils peuvent modifier une sandbox sans réécrire la boucle d’agent. Ils peuvent introduire un outil propre à leur entreprise tout en préservant le reste du runtime.

La même conception peut prendre en charge différents modes de fonctionnement. Un client web a besoin de composants orientés navigateur et d’un processus hôte. Un déploiement headless nécessite une surface d’automatisation sans la même couche visuelle. Les plugins à portée limitée permettent aux deux configurations de partager des services sans devenir des applications identiques.

C’est le mécanisme qui sous-tend le message « everything is a plugin ». Il ne s’agit pas seulement d’un slogan de marketplace. Le dépôt est organisé comme un vaste espace de travail TypeScript comprenant des packages hôte, des packages client, des applications, des exemples, de la documentation et des dépendances intégrées.

L’architecture de DeepSeek distingue également l’hôte, où fonctionnent les services privilégiés, du client, où s’exécutent les composants d’interface. Cette frontière est importante, car un agent ne devrait pas accorder à un composant de navigateur un accès illimité aux capacités du système.

Le projet génère des interfaces distantes entre ces deux côtés. Les services hôte peuvent déclarer des méthodes appelables, tandis que les composants client consomment des contrats générés. Cette approche vise à maintenir l’interface synchronisée avec les définitions de services sous-jacentes.

Pour les développeurs, l’intérêt réside dans la personnalisation sans devoir maintenir un fork complet. Une entreprise pourrait créer un outil de dépôt en lecture seule, un magasin de documents restreint ou une boucle de révision spécialisée. Elle pourrait ensuite empaqueter ce comportement sous forme de plugins.

Un cas d’usage concret pourrait concerner une équipe d’ingénierie examinant un dépôt inconnu. L’agent pourrait charger un plugin de recherche de code, un système de fichiers en lecture seule et un modèle sélectionné pour l’analyse. Il n’aurait pas besoin d’accéder aux identifiants de déploiement ni aux commandes d’écriture.

Une autre équipe pourrait créer un agent de recherche interne. Elle pourrait combiner des sources web approuvées, des documents locaux, un stockage de sessions et un modèle distinct pour la synthèse finale. L’interface utilisateur pourrait évoluer sans remplacer ces services sous-jacents.

Cette modularité facilite également l’expérimentation. Les équipes peuvent comparer deux modèles avec les mêmes outils et la même logique de session. Elles peuvent tester différentes boucles d’orchestration sans changer de modèle. Cette séparation peut révéler quel composant améliore réellement une tâche.

Cette position indépendante du modèle donne à DeepSeek un avantage stratégique, mais aussi un risque stratégique. Prendre en charge d’autres modèles peut élargir l’audience du projet. Cela peut également amener les développeurs à découvrir qu’un autre modèle fonctionne mieux au sein même du runtime de DeepSeek.

DeepSeek semble disposé à accepter ce compromis. L’entreprise cherche à se faire une place dans l’architecture des agents, sans exiger un contrôle exclusif sur chaque composant.

Une architecture ouverte met la pression sur les agents de programmation intégrés

DeepSeek Harness remet en question l’idée selon laquelle le modèle, l’interface, les outils et la boucle d’orchestration doivent former un produit unique et indissociable.

Claude Code et OpenAI Codex ont habitué les développeurs à attendre d’un agent qu’il puisse inspecter des projets, exécuter des commandes, modifier des fichiers et rendre compte des résultats. Leurs conceptions intégrées réduisent la configuration nécessaire et donnent à chaque fournisseur un contrôle plus étroit sur l’expérience complète.

Cette intégration offre de réels avantages. Le fournisseur peut optimiser les descriptions des outils pour son modèle, ajuster la gestion du contexte et coordonner les mises à jour du produit. Les utilisateurs bénéficient d’une frontière de support plus claire lorsqu’un problème survient.

L’approche de DeepSeek part d’une priorité différente. Au lieu de prendre chaque décision à la place du développeur, elle expose ces décisions sous forme de composants remplaçables. Les équipes peuvent déterminer quel modèle, système de fichiers, sandbox et boucle participent à un déploiement.

La différence tient moins aux listes de fonctionnalités qu’à la maîtrise du système. Dans un agent intégré, le fournisseur possède l’environnement d’exécution et laisse les utilisateurs configurer certaines parties. Dans DeepSeek Harness, les développeurs peuvent posséder l’environnement d’exécution et l’assembler à partir de packages.

Cette distinction compte pour les organisations ayant des exigences inhabituelles en matière de sécurité ou d’infrastructure. Une entreprise peut avoir besoin que les commandes s’exécutent dans un système de conteneurs précis. Elle peut exiger que les journaux restent sur un réseau interne. Elle peut vouloir des fournisseurs de modèles distincts selon les classifications de données.

Une architecture de plugins peut répondre plus directement à ces contraintes. Mais chaque personnalisation ajoute aussi un composant à examiner, tester, mettre à jour et prendre en charge.

Les produits intégrés peuvent progresser plus vite pour les flux de travail courants, car leurs équipes optimisent un parcours défini. Un harness ouvert peut avancer plus vite aux marges, car des acteurs externes n’ont pas besoin d’autorisation pour créer de nouvelles intégrations.

La concurrence se jouera donc sur l’effort demandé aux développeurs. DeepSeek Harness réussira si la personnalisation économise davantage de travail que le framework n’en crée. Il rencontrera des difficultés si les équipes consacrent leur temps à résoudre la compatibilité des plugins et à suivre des contrats instables.

La documentation actuelle de DeepSeek révèle une ambition d’ingénierie substantielle. Le dépôt prend en charge plusieurs générations de Node.js dans l’intégration continue, sépare les builds navigateur et hôte, et comprend de nombreux contrôles automatisés. Ces détails indiquent que DeepSeek entend faire du projet une plateforme réutilisable.

Le guide utilisateur présente également l’interface web comme un point d’entrée parmi d’autres, plutôt que comme le produit dans son ensemble. Cela étaye l’idée que dsh est une infrastructure pour agents, et pas simplement une application de chat de marque.

Toutefois, la documentation et l’architecture ne démontrent pas la fiabilité en production. Des comparaisons indépendantes doivent tester des combinaisons complètes de harness et de modèle dans des tâches identiques. Les scores de benchmarks portant uniquement sur les modèles ne permettent pas de savoir si l’environnement d’exécution se remet d’échecs d’outils ou protège correctement les fichiers.

Cette comparaison doit également éviter un faux dilemme. Les développeurs ne sont pas tenus de n’utiliser qu’un seul agent. Une équipe peut adopter un produit intégré pour le développement courant tout en testant DeepSeek Harness pour des flux de travail internes spécialisés.

Cette sortie affaiblit plutôt l’hypothèse selon laquelle l’agent officiel d’un fournisseur de modèles doit être un ensemble fermé. DeepSeek montre qu’un environnement d’exécution officiel peut rester inspectable et extensible.

Cette décision pourrait pousser les concurrents à exposer une plus grande partie de leurs couches d’orchestration. Elle pourrait aussi encourager des projets indépendants à adopter des conventions de plugins compatibles. Aucun de ces résultats n’est garanti par l’aperçu initial.

Le premier test sera de savoir si des développeurs externes créent des plugins utiles plutôt que de simples wrappers superficiels. Le deuxième sera de savoir si ces plugins restent compatibles à mesure que DeepSeek fait évoluer le framework. Le troisième sera de savoir si les équipes les déploient pour des travaux durables.

La compatibilité et la sécurité restent les volets non démontrés

L’aperçu donne aux développeurs du contrôle, mais leur transfère aussi la responsabilité des interfaces instables, de la confiance accordée aux plugins et des autorisations des outils.

DeepSeek indique clairement que des changements rompant la compatibilité auront lieu. Cet avertissement doit orienter toute décision de déploiement précoce. Une équipe peut évaluer le logiciel aujourd’hui sans supposer que les contrats de plugins actuels survivront à la prochaine version.

Les changements incompatibles sont fréquents durant un aperçu précoce. Ils permettent aux mainteneurs de corriger des abstractions fragiles avant qu’un écosystème plus vaste n’en dépende. Toutefois, des changements fréquents peuvent décourager les développeurs de plugins, qui doivent mettre à jour leurs intégrations à répétition.

Cordis introduit une autre couche d’instabilité. Son propre dépôt indique que l’API peut changer sans préavis. DeepSeek Harness dépend donc d’un méta-framework dont les contrats publics sont encore en cours de maturation.

Le problème de sécurité est plus conséquent. Un harness d’agent peut relier une sortie de modèle probabiliste à des actions système déterministes. Une réponse erronée du modèle devient plus grave lorsque l’environnement d’exécution peut exécuter des commandes, modifier des fichiers ou envoyer des données ailleurs.

La modularité des plugins ne crée pas automatiquement une isolation sûre. Un plugin peut étendre les capacités de l’agent, mais aussi élargir sa surface d’attaque. Les équipes doivent examiner les autorisations, l’accès réseau, la gestion des identifiants et la rétention des données pour chaque composant.

Les instructions dans les prompts ne constituent pas une frontière de sécurité suffisante. Un modèle auquel on demande de rester en lecture seule doit tout de même disposer d’outils qui imposent réellement ce comportement. L’environnement d’exécution doit empêcher les actions interdites même lorsque le modèle les demande.

La séparation entre l’hôte et le client fournit une frontière architecturale utile, mais la qualité de l’implémentation compte. Les développeurs ont besoin de preuves que les services privilégiés valident les requêtes et limitent correctement les périmètres. Ils ont également besoin de connaître clairement le comportement du système lorsqu’un plugin plante ou devient indisponible.

Les plugins tiers créent des préoccupations liées à la chaîne d’approvisionnement. Un package peut obtenir l’accès au code source, aux fichiers locaux ou aux identifiants d’API. Une mise à jour malveillante pourrait exploiter cet accès sans modifier l’interface utilisateur visible.

Les organisations devraient donc traiter l’installation de plugins comme l’approbation d’une dépendance, et non comme l’ajout d’une extension esthétique. Elles devraient figer les versions, examiner le code source, limiter les identifiants et exécuter les outils dans des environnements restreints.

L’observabilité est tout aussi importante. Les équipes ont besoin de traces indiquant quel modèle a généré une requête, quel plugin a agi, quels arguments il a reçus et ce qui a changé ensuite. Sans cette piste, le débogage et l’examen des incidents deviennent des exercices de conjecture.

Les documents publics de DeepSeek décrivent des contrôles de développement et une infrastructure de test. Ils n’apportent pas encore de preuve indépendante que chaque configuration prise en charge se comporte de manière sûre face à des entrées adversariales.

Le projet comprend un document de benchmark, mais les résultats de benchmarks exigent une interprétation prudente. Le score d’un agent reflète conjointement le modèle, les prompts, les outils, l’environnement, la politique d’orchestration et les règles d’évaluation.

Cette dépendance rend les comparaisons difficiles. Un score élevé obtenu avec DeepSeek Harness n’isole pas la contribution du harness à moins qu’un autre système utilise le même modèle et le même environnement. Un score de modèle issu d’un autre harness pose le même problème.

Les développeurs devraient également éviter de confondre l’activité d’un dépôt avec l’adoption. Les étoiles, forks et l’attention en ligne témoignent de la curiosité. Ils ne démontrent ni la rétention, ni l’utilisation en production, ni une réduction des coûts d’exploitation.

Les premières preuves les plus crédibles viendront de tâches reproductibles. Des équipes différentes peuvent-elles installer le même ensemble de plugins et obtenir un comportement comparable ? Peuvent-elles effectuer des mises à niveau sans reconstruire leurs intégrations ? Les administrateurs peuvent-ils restreindre les outils d’un agent sans s’appuyer sur les prompts ?

DeepSeek a donné aux développeurs suffisamment de code pour examiner ces questions. Il n’a pas encore fourni assez d’historique terrain pour y répondre définitivement.

Trois signaux montreront si DeepSeek Harness compte

La prochaine phase dépend de l’adoption des plugins, de la stabilité des interfaces et de preuves crédibles issues de déploiements complets d’agents.

Le premier signal sera l’existence d’une communauté utile de plugins tiers. DeepSeek invite les développeurs à étiqueter les dépôts compatibles avec le sujet dsh-plugin, créant ainsi un moyen de découverte en dehors de la base de code principale.

La qualité de ces plugins importe davantage que leur nombre. De fins adaptateurs peuvent créer un élan initial sans démontrer que l’architecture prend en charge des travaux exigeants. Des plugins pour des sandboxes sécurisées, l’authentification d’entreprise, l’observabilité et des systèmes de fichiers restreints constitueraient des preuves plus solides.

Une communauté saine a aussi besoin de mainteneurs au-delà de DeepSeek. Les développeurs indépendants doivent documenter la compatibilité, répondre aux défauts et mettre à jour les intégrations après les changements du framework. Sans cela, l’écosystème reste dépendant de l’équipe centrale malgré sa licence ouverte.

Si les développeurs créent des plugins substantiels pour différents cas d’usage, la thèse de l’environnement d’exécution ouvert se renforce. Si l’essentiel de l’activité reste dans le dépôt de DeepSeek, le projet ressemble davantage à un client officiel configurable.

Le deuxième signal sera la trajectoire de la v0.1 vers des contrats stables. Les ruptures inhérentes à la phase d’aperçu sont acceptables, mais les développeurs doivent voir quelles interfaces deviennent fiables.

DeepSeek peut renforcer la confiance grâce à des API de plugins versionnées, des guides de migration, des périodes de dépréciation et des tests de compatibilité. Un modèle de sécurité défini compterait autant qu’une interface de programmation stable.

La stabilité ne nécessite pas de figer chaque fonctionnalité. Elle exige de rendre les changements suffisamment prévisibles pour que les mainteneurs externes puissent s’y préparer. La discipline de test existante du projet fournit une base, mais les promesses publiques de compatibilité seront le véritable test.

Si les mises à niveau deviennent routinières, DeepSeek Harness pourra prendre en charge des produits durables. Si chaque version impose des réécritures majeures, les développeurs le réserveront aux expérimentations.

Le troisième signal sera une évaluation indépendante de flux de travail complets. Les tests devraient comparer les harnesses tout en contrôlant le modèle, l’environnement de tâche, les outils et les actions autorisées.

Les évaluations utiles devraient mesurer plus que l’accomplissement des tâches. Elles devraient enregistrer les actions non autorisées, la récupération après un échec d’outil, les interventions humaines, le temps d’exécution et l’exactitude des livrables.

Les tests de sécurité méritent un axe distinct. Les chercheurs devraient examiner l’injection de prompts, les dépôts malveillants, les plugins compromis, l’exposition d’identifiants et les tentatives d’évasion des sandboxes.

Des études de cas en production fourniraient une autre forme de preuve. Une équipe qui utilise DeepSeek Harness pour des travaux répétés peut indiquer à quelle fréquence les agents terminent correctement les tâches et quel niveau de supervision ils exigent. Ces observations révèlent des faiblesses que les démonstrations ponctuelles ne détectent pas.

Si des résultats indépendants montrent que sa modularité préserve la fiabilité, DeepSeek disposera d’une réponse convaincante aux agents intégrés. Si la personnalisation produit des comportements incohérents, les produits étroitement contrôlés conserveront un avantage.

Cette sortie établit déjà un fait : DeepSeek ne souhaite plus rivaliser uniquement au niveau du point de terminaison du modèle. L’entreprise veut que les développeurs construisent la couche opérationnelle autour des agents sur des fondations contrôlées par DeepSeek.

Pour les développeurs, la réponse raisonnable consiste en une expérimentation ciblée. Choisissez un flux de travail délimité, restreignez les outils disponibles et consignez chaque action. Comparez ce déploiement à un agent existant dans le cadre de la même tâche et du même processus de revue.

Les équipes qui documentent ces essais peuvent conserver leurs décisions et constats dans une base de connaissances d’ingénierie. Cette trace devient essentielle lorsque les plugins, les versions de modèles et les politiques de sécurité évoluent.

DeepSeek Harness mérite l’attention, car il fait de l’exécution des agents un terrain de concurrence explicite. Son architecture ouverte offre aux développeurs un degré de contrôle inhabituel, tandis que son statut de préversion laisse en suspens les questions de fiabilité et de gouvernance.

La question des prochains mois est concrète : les développeurs parviendront-ils à transformer des plugins interchangeables en systèmes fiables, ou les coûts d’intégration les ramèneront-ils vers des agents intégrés ? DeepSeek a présenté son argumentaire. Ce sont désormais les déploiements réels qui devront l’éprouver.