DeepSeek Harness : quand tout devient vraiment un plugin

Lorsque nous parlons d’agents d’IA, nous commençons presque toujours par le modèle. Quel modèle écrit le meilleur code ? Lequel comprend les contextes les plus longs ? Lequel résout le plus de tâches dans un benchmark ? C’est compréhensible, mais désormais insuffisant. Un agent ne se résume pas à un modèle de langage. Il lui faut des outils, une mémoire, des sessions, des autorisations, un environnement d’exécution, de la planification, une journalisation et une interface permettant aux humains d’intervenir.

C’est précisément pourquoi la Developer Preview de DeepSeek Harness me paraît si passionnante. DeepSeek résume son idée par une formule remarquablement claire : Everything is a plugin. Les outils supplémentaires ne sont pas les seuls éléments interchangeables. Les modèles, skills, sessions, sandboxes, systèmes de stockage, boucles d’agents, mécanismes de planification et même l’interface utilisateur sont traités comme des plugins.

Au premier abord, cela ressemble à une décision technique destinée aux développeurs. En réalité, cette approche porte un message plus large sur la prochaine phase de l’IA. Si l’intelligence vient du modèle, mais que la capacité de travailler concrètement vient du harness, cette seconde moitié ne doit pas devenir un bloc opaque appartenant à un seul fournisseur.

L’agent est bien plus que son modèle

DeepSeek formule l’équation très simplement : un agent égale un modèle plus un harness. Le modèle traite le langage et produit des décisions. Le harness le relie à l’environnement réel. Il fournit des fichiers, enregistre les outils, gère l’état, lance des sous-agents, exécute des commandes et décide quelles informations reviendront dans le contexte lors du prochain appel au modèle.

Un harness n’est donc pas un simple emballage autour d’un modèle. Il détermine ce qu’une réponse du modèle peut réellement devenir. L’agent peut-il seulement produire du texte ou modifier un fichier ? Voit-il tout le dépôt ou un seul répertoire de travail ? Une commande s’exécute-t-elle directement sur l’hôte, dans un conteneur ou dans une sandbox distante ? Une personne doit-elle approuver une action ? L’état persiste-t-il entre plusieurs sessions ? Rien de tout cela n’est une propriété du modèle. Ce sont des décisions prises par l’environnement d’exécution qui l’entoure.

De la réponse à l’action

Dans une conversation simple, cette séparation est à peine perceptible. Une question entre, une réponse sort. Mais dès qu’un agent travaille dans un dépôt, traite des tickets, accède à des systèmes internes ou prend en charge des tâches longues, le harness devient au moins aussi important que le modèle. Il traduit une intention exprimée en langage en une suite d’étapes réelles, puis renvoie leurs résultats au modèle sous forme de nouveau contexte.

C’est exactement là qu’une technologie impressionnante en démonstration devient, ou non, un outil fiable. Un excellent modèle doté d’un mauvais contexte, d’autorisations trop larges et d’une gestion de sessions peu fiable reste un mauvais agent. Il peut raisonner brillamment tout en modifiant le mauvais fichier, en utilisant un état obsolète ou en échouant à reprendre proprement après une erreur. À l’inverse, un modèle un peu moins puissant peut être étonnamment utile dans un environnement bien conçu, parce qu’il dispose des bons outils, travaille dans des limites claires et laisse une trace compréhensible de son activité.

L’architecture fait partie du résultat

DeepSeek Harness rend cette couche visible. Le noyau Cordis monte des plugins, résout les dépendances et peut retirer des composants. Les capacités sont fournies comme des services. Un plugin peut, par exemple, implémenter un shell, un autre l’exposer comme outil au modèle et un troisième utiliser cet outil dans un workflow. La configuration permet de remplacer l’implémentation concrète sans reconstruire tout le harness.

DeepSeek va plus loin que nombre de plateformes qui autorisent seulement quelques outils supplémentaires sous forme d’extensions. La connexion au modèle, le registre d’outils, le journal de session et la boucle d’agent elle-même sont aussi des plugins. D’après l’architecture, aucun noyau privilégié ne doit être corrigé à chaque extension. Le nouveau comportement est monté à côté des composants existants et peut supprimer proprement ses enregistrements lorsqu’on le retire.

L’idée n’est pas entièrement nouvelle. Depuis des décennies, systèmes d’exploitation, navigateurs, éditeurs et plateformes reposent sur des composants modulaires. La nouveauté tient à la cohérence avec laquelle DeepSeek applique ce principe à un agent d’IA complet. L’architecture de l’agent n’est plus acceptée comme un produit figé, mais comme un ensemble de décisions que l’opérateur peut modifier.

Pourquoi « tout est un plugin » est si séduisant

L’idée des plugins déplace le pouvoir d’un produit fini vers un environnement d’exécution composable. Je peux remplacer un fournisseur de modèles sans reconstruire toute ma façon de travailler. Je peux échanger un shell local contre une variante mieux isolée. Je peux employer un autre stockage, une logique de session différente ou ma propre interface. Outre l’accès à ses propres modèles, DeepSeek documente d’autres fournisseurs et des endpoints personnalisés compatibles avec OpenAI.

Changer de modèle sans tout recommencer

Un agent devient ainsi une infrastructure que j’assemble en fonction de mon environnement. Une petite équipe de développement n’a peut-être besoin que d’un accès aux fichiers, de Git et de tests. Une équipe de sécurité voudra en plus des requêtes réseau, des sandboxes isolées, des approbations plus strictes et des journaux immuables. Une entreprise peut utiliser sa propre passerelle de modèles, tandis qu’un laboratoire privé se connecte à un modèle local à poids ouverts.

C’est stratégiquement important, car les modèles évoluent actuellement très vite. Aujourd’hui, un fournisseur excelle dans le code ; demain, un autre peut dominer les longs contextes ou l’utilisation des outils. Dans un produit fermé, changer de modèle revient souvent à changer également de plateforme. Les sessions, règles, autorisations, intégrations et méthodes de travail doivent être reconstruites. Dans un environnement modulaire, le modèle peut rester un composant que l’on remplace par un autre fournisseur ou par un endpoint auto-hébergé.

Le changement ne sera pas parfaitement fluide. Les modèles diffèrent dans leurs formats de rôles, leur raisonnement, leurs appels d’outils, leur prise en charge des images et leur comportement en cas d’erreur. Ces différences doivent être proprement gérées par les adaptateurs concernés. Mais c’est précisément ici qu’apparaît la valeur d’une interface nette : les particularités d’un fournisseur ne se répandent pas sans contrôle dans tout le produit.

Une infrastructure interchangeable, pas seulement des boutons

La séparation entre définition, fournisseur et consommateur d’une capacité est particulièrement intéressante. Une interface Bash décrit ce que la capacité sait faire. Un fournisseur décide où et comment les commandes s’exécutent réellement. Ce n’est qu’un autre plugin qui en fait un outil que le modèle est autorisé à appeler. De telles interfaces sont importantes parce qu’elles offrent un point de contrôle clair. On peut y intégrer délais d’expiration, isolation, approbations et journalisation sans reprogrammer chaque boucle d’agent.

Le potentiel devient évident lorsque plusieurs capacités partagent le même environnement d’exécution. Si le système de fichiers et les processus passent d’un environnement local à une sandbox distante, le shell, le terminal et la navigation dans le code peuvent les suivre ensemble. Pour l’utilisateur, la capacité reste semblable, tandis que le cadre opérationnel et de sécurité change fondamentalement en dessous. Ce type d’interchangeabilité vaut bien plus qu’un interrupteur supplémentaire dans une interface.

Les différents modes d’exécution montrent aussi ce que DeepSeek prépare. Le mode standard fournit l’agent de code complet. En mode Code, le modèle peut orchestrer plusieurs appels d’outils grâce à du code TypeScript généré. Le mode Minimal réduit l’environnement au shell et à l’éditeur pour les benchmarks. Le mode Creator permet d’explorer les plugins et les presets personnalisés. Chaque cas d’usage n’a donc pas besoin de charger la même immense boîte à outils.

Les profils et bundles en font davantage qu’une collection d’extensions disparates. Un profil peut définir un environnement d’agent pour un objectif précis. On peut imaginer un profil léger pour le développement local, un profil plus restreint pour les systèmes de production et un profil d’analyse forensique particulièrement détaillé dans sa journalisation. Les capacités reposent sur les mêmes composants, mais leur combinaison et leurs limites correspondent au risque concerné.

Là où le potentiel devient concret

L’architecture est passionnante, mais sa valeur ne se révèle que dans des situations concrètes. Un système de plugins n’est pas une fin en soi. Il doit permettre d’adapter plus rapidement un agent à des besoins réels sans construire une nouvelle plateforme pour chaque usage.

De l’outil personnel à la plateforme d’entreprise

Un développeur seul peut commencer avec un shell local, un éditeur de fichiers et un modèle. Dès que l’outil est utilisé par une équipe, d’autres exigences apparaissent : identités centralisées, espaces de travail séparés, approbations pour les actions critiques, passerelle de modèles, maîtrise des coûts, sessions persistantes et piste d’audit exportable. Dans une application monolithique, le fabricant décide si ces fonctions apparaissent et quand.

Dans un environnement modulaire, les entreprises peuvent ajouter elles-mêmes les éléments manquants ou remplacer les fournisseurs existants. Il n’est pas nécessaire de réinventer l’agent. La même interface et la même logique d’agent peuvent utiliser d’autres modèles derrière une passerelle d’entreprise, exécuter les commandes dans une sandbox interne et stocker les sessions dans un système maîtrisé en interne. Voilà la différence entre un outil pratique et une plateforme contrôlable.

Plusieurs zones de confiance avec les mêmes composants

Toutes les tâches ne méritent pas les mêmes droits. Un agent qui résume de la documentation n’a pas besoin d’accéder à la production. Un agent de réponse aux incidents peut avoir besoin de journaux et de requêtes réseau, mais ne doit pas modifier la configuration. Un agent de déploiement peut appliquer des changements, mais devrait exiger des approbations plus strictes, des tokens plus courts et une journalisation particulièrement claire.

Des services et profils bien séparés permettent d’exprimer cette distinction dans l’environnement d’exécution. Le modèle n’a pas à comprendre chaque détail de sécurité et à le respecter volontairement. L’environnement détermine techniquement quelles capacités existent. Pour la sécurité, c’est essentiel : une capacité qui n’est pas montée n’est tout simplement pas disponible comme outil direct pour le modèle.

Un écosystème pour les spécialistes

Aucun fournisseur ne construira à lui seul la meilleure sandbox, le meilleur stockage de sessions, tous les systèmes d’entreprise et tous les adaptateurs de modèles. Un modèle de plugins ouvert permet aux spécialistes de résoudre particulièrement bien une seule couche. Un fournisseur de sécurité pourrait proposer un environnement d’exécution renforcé. Un projet de stockage pourrait fournir des sessions infalsifiables. Une équipe de plateforme interne pourrait relier approbations et identités à sa propre organisation.

Lorsque ces composants s’assemblent grâce à des interfaces stables, un écosystème naît à la place d’une application unique toujours plus grande. C’est probablement le plus grand potentiel de DeepSeek Harness. DeepSeek ne doit pas gagner tous les cas d’usage. Il suffit que son architecture devienne l’endroit où d’autres proposent et combinent leurs capacités.

La traçabilité n’est pas un détail

Après les plugins, la deuxième idée forte est le journal de session en ajout uniquement. Selon DeepSeek, tout ce que voit le modèle est enregistré sous forme d’événement. Cela comprend les instructions système, les appels d’outils et leurs résultats, les injections de contexte ainsi que la planification des sous-agents. La reprise, la création de branches, la recherche et la répétition reposent sur le même flux d’événements.

Pour les développeurs, c’est pratique, car une exécution défectueuse peut être reconstituée. Pour la sécurité et l’exploitation, c’est encore plus important. Si un agent modifie un fichier, lance une commande ou envoie des données à un service, le dernier message du chat ne suffit pas. Je dois pouvoir comprendre quel contexte était présent, quel outil est intervenu et à quel endroit une décision est devenue une action.

Dans les applications classiques, une erreur peut souvent être reliée à une entrée et à un chemin de code déterministe. C’est plus difficile avec les agents. À partir de la même mission générale, un modèle peut déduire des étapes intermédiaires différentes, utiliser les outils dans un autre ordre et réagir à des résultats inattendus. Sans historique complet, il ne reste que l’affirmation selon laquelle l’agent aurait pris une décision. Cela ne suffit ni au débogage ni à l’analyse d’un incident de sécurité.

Faire du flux d’événements la source de vérité ouvre une deuxième possibilité : des expériences plus comparables. Une session peut être dérivée à un point précis et continuer avec un autre modèle, un prompt modifié ou d’autres capacités. On ne compare alors plus seulement le modèle qui écrit la plus belle réponse. On peut étudier l’effet d’une modification concrète sur le même état de travail réel.

Pour les entreprises, cela pourrait devenir à terme une sorte de journal de changements et d’incidents pour les agents. Qui a donné la mission ? Quelle politique était active ? Quelles données le modèle a-t-il reçues ? Quelle action a été approuvée ? Quel résultat est revenu ? Ces questions deviendront importantes dès que les agents ne se contenteront plus de conseiller, mais déclencheront des changements dans de vrais systèmes.

Un journal ne constitue toutefois pas encore une piste d’audit complète. Conservation, contrôle d’accès, intégrité, contenus sensibles et export doivent toujours être soigneusement résolus. Un journal intégral peut lui-même devenir un risque s’il contient des prompts, du code source, des résultats d’outils ou des identifiants. Malgré cela, j’apprécie la décision fondamentale : les informations visibles par le modèle ne doivent pas arriver par un canal latéral caché, mais par un flux d’événements que l’on peut reconstruire.

L’open source devient une arme stratégique

Le fait que ce projet vienne de Chine le rend encore plus intéressant. DeepSeek ne publie pas seulement des poids de modèles, mais construit désormais visiblement plusieurs couches de la stack. DeepSeek V4 est disponible avec ses poids et son code sous licence MIT. Le Harness, lui aussi sous MIT, ajoute maintenant un environnement ouvert pour le travail agentique. En dessous, Cordis fournit même son propre modèle de plugins et de composition.

Cela correspond à une évolution que j’ai déjà décrite dans mon article sur l’IA, la sécurité et la lutte pour la stack complète. La Chine ne veut pas seulement consommer des applications d’IA. Les entreprises chinoises construisent des modèles, des logiciels d’inférence, des filières matérielles et désormais l’infrastructure des agents qui vient s’y ajouter. DeepSeek avance à un rythme que l’Occident ne peut plus expliquer avec l’ancienne image d’une simple industrie de copie.

Dans cette course, l’open source n’est pas qu’un idéal. C’est un moyen de distribution, une source de confiance par l’inspection et un accélérateur d’écosystème. Celui qui publie poids, code et interfaces invite les développeurs du monde entier à trouver des erreurs, construire des intégrations et transformer sa conception en standard de fait. Un harness ouvert peut être stratégiquement plus précieux pour DeepSeek qu’une nouvelle interface de chat fermée, parce qu’il reste pertinent même lorsque des modèles d’autres fournisseurs s’y exécutent.

C’est un point remarquable. DeepSeek construit une plateforme dans laquelle DeepSeek lui-même reste interchangeable. À court terme, cela paraît presque contradictoire. Pourquoi un fournisseur de modèles faciliterait-il le passage à un concurrent ? À long terme, cette position peut précisément être la plus forte. Si les développeurs bâtissent leurs agents, plugins, règles de sécurité et sessions sur cet environnement, le harness devient une infrastructure commune. DeepSeek perdra peut-être quelques appels de modèles, mais gagnera de l’influence sur l’architecture de tout l’écosystème.

L’ouverture accélère aussi l’apprentissage. Dans un produit fermé, l’évolution de l’architecture centrale reste largement entre les mains du fabricant. Un projet ouvert est utilisé dans des environnements que l’équipe d’origine n’aurait jamais pu anticiper complètement. Il en résulte des rapports de bugs, de nouveaux adaptateurs, des backends alternatifs et un savoir opérationnel. Dans un domaine aussi jeune que le logiciel agentique, ce retour d’expérience peut compter davantage qu’une première version parfaite.

C’est là que réside le côté intelligent de l’approche par plugins. DeepSeek n’a pas besoin de construire lui-même chaque stockage, chaque sandbox et chaque système d’entreprise. Il fournit une architecture dans laquelle d’autres peuvent insérer ces capacités. Si l’écosystème grandit, chaque nouvelle intégration profite au noyau.

La Chine ne construit pas seulement un modèle, mais tout un chemin autour de lui

La portée géopolitique ne réside donc pas uniquement dans les scores de benchmarks. Un pays ou une zone économique ne devient pas technologiquement souverain simplement parce qu’un modèle puissant a été entraîné quelque part. Il lui faut du matériel, des logiciels d’inférence, des outils de développement, des interfaces, de l’expérience d’exploitation et des développeurs qui construisent des produits dessus. DeepSeek Harness est un nouveau composant dans cette chaîne.

Le récit occidental sur la technologie chinoise accuse souvent un retard sur cette évolution. Ceux qui voient encore principalement la Chine comme un imitateur bon marché ignorent la vitesse avec laquelle des architectures originales y sont publiées et proposées aux développeurs du monde entier. DeepSeek n’a pas besoin de rester en tête dans chaque catégorie. Il suffit de maintenir un faible écart, d’itérer rapidement et d’ouvrir son travail pour que d’autres puissent construire dessus.

L’écart avec les meilleurs modèles fermés se réduit

Les modèles à poids ouverts ont longtemps été considérés comme une alternative intéressante pour les laboratoires et les cas particuliers, tandis que les capacités réellement puissantes restaient chez quelques fournisseurs fermés. Cette vision résiste de moins en moins. L’écart n’a pas disparu dans toutes les disciplines, mais il se comble plus vite que beaucoup ne l’avaient prévu.

Dans ses propres évaluations, DeepSeek place ses modèles V4 directement à côté des meilleurs modèles fermés actuels. Selon le benchmark, V4 Pro s’en approche, obtient des scores comparables ou reste nettement derrière. Les résultats ne sont pas uniformes en ingénierie logicielle, utilisation d’outils, connaissances factuelles et tâches de raisonnement très difficiles. C’est précisément pourquoi il ne faut pas désigner un « vainqueur » à partir d’un seul tableau.

Le point le plus important est l’écart temporel. Des capacités qui semblaient récemment réservées aux plus grands laboratoires américains apparaissent aujourd’hui, quelques mois plus tard, dans des modèles dont les poids peuvent être téléchargés, auto-hébergés et étudiés. « Quelques mois seulement derrière les meilleurs modèles » n’est pas une constante scientifiquement mesurable, mais décrit assez bien à quel point l’avance des systèmes fermés peut désormais sembler courte.

Cela change aussi la valeur économique d’une avance. Si un modèle fermé est dix pour cent meilleur pour une tâche précise, cela peut être décisif. Mais si un modèle ouvert est assez bon, fonctionne sur sa propre infrastructure et peut être intégré dans sa propre zone de sécurité, le calcul global peut malgré tout lui être favorable. Contrôle, emplacement des données, coûts prévisibles et possibilité d’adaptation font aussi partie de la performance, même si un benchmark ne les mesure pas.

Il ne faut pas oublier le matériel. Des poids disponibles ouvertement ne signifient pas qu’un modèle de 1,6 billion de paramètres fonctionne aisément dans une baie de serveurs. DeepSeek V4 Pro est un immense modèle mixture-of-experts. Même si seule une partie de ses paramètres est active pour chaque token, la mémoire, le coût d’inférence et l’exploitation restent exigeants. L’ouverture supprime la barrière d’accès au code et aux poids, pas la réalité physique des grands modèles.

Malgré tout, la simple existence de ces poids modifie le marché. Les chercheurs peuvent étudier le modèle. Des fournisseurs peuvent le déployer sur leur propre infrastructure. Les communautés peuvent créer des quantifications et optimiser l’exécution. Les entreprises disposent au moins d’une alternative à la dépendance totale envers une seule API.

La compétition se déplace ainsi. L’intelligence brute du modèle reste importante, mais la valeur durable réside de plus en plus dans les pipelines de données, les évaluations, l’environnement d’exécution, la sécurité, la distribution et l’intégration aux processus réels. Un harness ouvert correspond exactement à cette évolution. Plus les modèles deviennent interchangeables, plus la plateforme qui leur fournit de manière fiable contexte, outils et limites prend de la valeur.

Ouvert ne signifie pas automatiquement digne de confiance

Malgré tout mon enthousiasme, il serait naïf d’assimiler automatiquement « open source chinois » et souveraineté. Ceux qui utilisent le service hébergé de DeepSeek continuent d’envoyer leurs données à un fournisseur externe. Seuls un endpoint de modèle auto-hébergé et un harness contrôlé changent véritablement la souveraineté des données. Même alors, la provenance, le processus de build, les dépendances et les mises à jour font toujours partie de la chaîne d’approvisionnement.

Les plugins renforcent cette responsabilité. Un plugin n’est pas un thème inoffensif. Il peut enregistrer des outils, accéder à des services et exécuter du code sur le système. Pour les installations depuis des dépôts Git, la documentation de DeepSeek avertit explicitement que des scripts de build autorisés peuvent s’exécuter sur l’hôte, en dehors de la sandbox de l’agent. Elle recommande de n’autoriser que des sources de confiance et de fixer les dépendances à un commit précis.

C’est exactement le bon avertissement. Une plateforme ouverte de plugins crée de l’interchangeabilité, mais aussi une nouvelle chaîne d’approvisionnement. Chaque fournisseur supplémentaire peut accéder aux prompts, fichiers, identifiants ou outils exécutables. Un plugin compromis n’a pas besoin d’un jailbreak spectaculaire du modèle s’il fait déjà légitimement partie de l’environnement d’exécution.

Pouvoir lire le code source est un avantage, mais ne constitue pas encore un audit de sécurité. Quelqu’un doit réellement examiner le code, vérifier les builds, figer les versions et contrôler les mises à jour. À mesure que l’écosystème de plugins grandit, la provenance devient presque aussi importante que la fonction. Un plugin utile provenant d’une source inconnue peut représenter un risque plus grave qu’une fonction manquante.

Pour une exploitation sérieuse, je n’utiliserais donc qu’un petit nombre de plugins vérifiés. Les versions doivent être figées, les autorisations séparées, les secrets gérés hors de la configuration et les connexions sortantes contrôlées. Les sandboxes doivent réellement isoler, pas seulement en porter le nom. Le journal de session doit être protégé et contrôlé pour détecter les données sensibles. Surtout, « tout est un plugin » ne doit pas finir par signifier « chaque plugin peut tout faire ».

Le potentiel à long terme dépend donc aussi de la gouvernance. Une bonne plateforme exige des preuves de provenance compréhensibles, des artefacts signés, des builds reproductibles, des dépendances claires et un moyen de restreindre les capacités selon le profil. Si DeepSeek et la communauté prennent au sérieux ces fondations peu spectaculaires, l’ouverture pourra offrir un véritable contrôle. Dans le cas contraire, la promesse des plugins ne deviendra qu’une très vaste surface d’attaque.

Ce que j’attends de DeepSeek Harness

DeepSeek qualifie volontairement le projet de Developer Preview et annonce des changements incompatibles. C’est le bon moment pour lire, expérimenter et effectuer des tests avec des données non critiques. Ce n’est pas encore une raison de faire dépendre de lui des processus de production centraux.

La question passionnante est de savoir si cette architecture propre donnera naissance à un écosystème robuste. Il lui faut des versions signées, une provenance traçable des plugins, des modèles d’autorisations clairs, des builds reproductibles et un processus de mise à jour qui ne réclame pas un nouvel acte de confiance à chaque changement. Il faut aussi vérifier si les plugins de différents fournisseurs se combinent vraiment bien alors que le projet évolue rapidement.

Je veux également voir si l’interchangeabilité promise tient dans la pratique. Sur le papier, un adaptateur de modèle est facile à remplacer. Dans la réalité, les modèles diffèrent dans leurs appels d’outils, leur raisonnement, leurs formats de contexte, leur prise en charge des images et leurs modes d’échec. Une interface ouverte réduit ces différences, elle ne les fait pas disparaître.

Malgré ces réserves, DeepSeek Harness est pour moi l’un des projets d’IA les plus intéressants de l’année. Non parce qu’il devrait déjà être le meilleur agent de code. Ce qui est passionnant, c’est qu’une entreprise chinoise d’IA ouvre la couche située au-dessus du modèle et en fait un système modulaire. Tandis que d’autres fournisseurs intègrent toujours plus profondément leurs agents dans des plateformes fermées, DeepSeek mise sur une architecture où même son propre modèle n’est qu’un plugin interchangeable.

Mon impression et ce rythme incroyable

La Developer Preview révèle déjà beaucoup de potentiel à mes yeux. L’interface rend concret le principe des plugins, et la vue Trajectory montre que la traçabilité est prévue dès l’origine plutôt qu’ajoutée après coup. Le projet est encore jeune et beaucoup de choses évoluent, mais cette architecture ouverte semble constituer une base sur laquelle quelque chose d’important peut naître très vite.

Il se passe actuellement tant de choses dans l’IA que quelques semaines de décalage suffisent à paraître dépassé. Est-ce vraiment surprenant quand Alphabet prévoit à elle seule 175 à 185 milliards de dollars de dépenses d’investissement pour 2026 et Meta 115 à 135 milliards supplémentaires, dans les deux cas largement consacrés à l’infrastructure d’IA ? Des centaines de milliards affluent soudain vers la même idée, la même compétition et le même avenir.

Ce capital ne garantit pas de bons produits. Mais il explique pourquoi les modèles, centres de données et plateformes d’agents progressent à un rythme qui semblait impossible il y a quelques années. Les modèles deviennent plus interchangeables, les poids ouverts rattrapent rapidement leur retard et la différenciation décisive se déplace vers le harness. DeepSeek accélère visiblement sur ces trois sujets. Ceux qui construisent l’infrastructure de l’IA ne devraient pas y voir seulement un récit de concurrence chinoise, mais une invitation à réévaluer leur dépendance aux stacks fermées.

À la prochaine,
Joe