Je viens de réaliser quelque chose qui me dérangeait à propos de toute cette histoire de Cursor. Tu sais ce que c’est que cet outil d’IA de 29,3 milliards de dollars dont tout le monde est obsédé ? Il s’avère que le cerveau derrière Composer 2 n’est pas ce que tu pensais.

La semaine dernière, des développeurs ont commencé à analyser les réponses de l’API et ont trouvé quelque chose d’intéressant dans le chemin du modèle : kimi-k2p5-rl-0317-s515-fast. Kimi K2.5. C’est le modèle open-source de Moonshot AI, en Chine. Pas exactement caché dans les petits caractères, mais certainement pas mis en avant non plus.

Le vice-président de l’éducation des développeurs chez Cursor l’a reconnu quelques jours plus tard, en disant qu’environ 25 % de la puissance de calcul provient de la plateforme Kimi, le reste étant issu de leur propre entraînement. Il a qualifié l’omission dans l’article de « erreur ». Sauf que c’est la deuxième fois. Lors du lancement de Composer 1, les gens ont remarqué qu’il utilisait le tokenizer de DeepSeek — aussi jamais mentionné. À quel moment cela cesse-t-il d’être une erreur ?

Mais voici le truc : utiliser Kimi K2.5 est en fait une décision intelligente. Le modèle est solide pour la génération de code, il est open-source donc les coûts d’acquisition sont pratiquement nuls, et pour une entreprise axée sur l’intégration au niveau du produit et de la chaîne d’outils, cela a tout son sens commercial. Le problème n’est pas le choix technique. C’est le silence.

Mais il y a un problème de conformité dont on ne parle pas. Kimi K2.5 utilise une licence MIT modifiée avec une exigence spécifique : si un produit commercial a plus de 100 millions d’utilisateurs actifs mensuels ou plus de 20 millions de dollars de revenus mensuels, il faut afficher de manière visible « Kimi K2.5 » dans l’interface utilisateur. Cursor dépense environ $2B par an — c’est environ 8 fois le seuil. L’exigence est claire. Elle a été ignorée.

Je ne suis pas avocat, mais cela importe parce que l’industrie du logiciel a passé deux décennies à apprendre à respecter les licences open-source. Nous sommes passés de procès pour GPL à l’adoption des SBOM comme pratique standard. La licence des modèles d’IA en est probablement encore à ses débuts dans ce même parcours. Si des entreprises peuvent passer outre quelque chose d’aussi simple que l’ajout d’un label, qu’en est-il des aspects plus complexes — flux de données, auditabilité des modèles, conformité transfrontalière ?

Il existe un concept appelé « Taxe de Confiance » qui s’applique ici. Des utilisateurs payant 20 $ par mois pour ce qu’ils pensent être une technologie propriétaire de pointe, découvrant ensuite qu’il s’agit d’un modèle open-source gratuit avec quelques modifications ? Cette confiance se fissure. Surtout quand Cursor a déjà connu des problèmes de tarification avec le plan Pro « Illimité » où les gens ont consommé leurs crédits mensuels en trois jours.

La vraie question, c’est ce que les utilisateurs paient réellement. Si c’est pour les capacités du modèle, il suffit d’appeler directement l’API Kimi — beaucoup moins cher. Si c’est pour l’expérience produit et l’intégration à la chaîne d’outils, alors il faut être clair à ce sujet, au lieu de laisser penser que tout est développé en interne. Apple ne prétend pas fabriquer ses propres puces. C’est TSMC qui les fabrique. Personne ne se sent trompé parce qu’il sait ce pour quoi il paie réellement.

Ce qui est vraiment intéressant ici, c’est le changement structurel plus large : les modèles open-source chinois deviennent la base invisible des applications d’IA mondiales. DeepSeek, Tongyi Qianwen, Kimi — ce sont eux qui alimentent discrètement des systèmes partout dans le monde. Le PDG de Hugging Face a littéralement dit que l’open source chinois est « la plus grande force façonnant la pile technologique IA mondiale ». Je ne plaisante pas.

Pour les entreprises, cela pose un vrai problème. Vos développeurs routent du code via des modèles dont vous ne connaissez même pas l’origine. Dans les industries réglementées — finance, santé, gouvernement — c’est un cauchemar de conformité. La souveraineté des données, les réglementations transfrontalières, tout cela devient flou. Certains parlent de « Shadow AI », comme l’était le Shadow IT. Les développeurs intègrent ces modèles dans leurs IDE et pipelines sans que les équipes de sécurité en aient conscience.

L’industrie du logiciel a fini par résoudre cela avec les SBOM — la liste des composants logiciels. Elle indique quels éléments vous utilisez, leurs versions, les vulnérabilités connues. L’IA a besoin de la même chose. Un AI-BOM est déjà discuté dans les cercles de sécurité. Il devrait inclure : le modèle de base, la source et le traitement des données d’entraînement, la méthode de fine-tuning, le déploiement, les flux de données.

Pour les développeurs qui choisissent des outils, cela signifie auditer les sources des modèles de la même façon que vous auditez les licences des dépendances. npm audit, pip check — ce sont des standards. L’audit des modèles pourrait être la prochaine étape. Pour les fournisseurs d’IA, divulguer proactivement les sources des modèles n’est pas une faiblesse, c’est un investissement dans la confiance à long terme. La première entreprise à faire du AI-BOM une norme pourrait même en tirer un avantage concurrentiel.

En résumé : Kimi K2.5 est vraiment bon. Le travail technique de Moonshot mérite du respect. L’expertise produit de Cursor est réelle. Le problème n’a jamais été « un modèle chinois a été utilisé ». Dans un écosystème open-source, une bonne technologie ne devrait pas porter une étiquette nationale. Le problème, c’est qu’on ne nous l’a pas dit. À mesure que ces agents IA s’intègrent plus profondément dans nos flux de travail, en manipulant plus de code, de données et de décisions, nous devrions au moins savoir qui pense réellement derrière les coulisses.