L'équivalent de Jev existe déjà chez OpenAI et Gemini : ce qui protège une startup quand l'IA copie tout

Une startup crée un outil réussi, puis, au bout d'un certain temps, une fonction similaire apparaît dans l'API des grands laboratoires. C'est déjà arrivé avec Jev, un classificateur rapide et peu coûteux : OpenAI comme Gemini ont lancé des équivalents. On dit qu'ils sont pour l'instant moins bien calibrés que le modèle d'origine, mais ils sont déjà utilisables.

Ce qui a exactement été copié

Un classificateur est un petit modèle rapide. Il n'écrit pas d'essais, mais répond à une question étroite : à quelle catégorie appartient la requête, faut-il laisser passer le message, faut-il escalader. Pour de telles tâches, un grand modèle n'est pas nécessaire ; ce sont donc la vitesse et le prix qui décident. Les liens du post montrent que la documentation d'OpenAI comme AI Studio de Google comportent désormais des sections sur les decisions, c'est-à-dire sur une classe de tâches similaire.

La conclusion pratique est simple. Si vous avez bâti une partie de votre produit autour d'une classification peu coûteuse, vous avez désormais un choix. Mais vérifiez la calibration sur vos propres données : selon les retours, c'est précisément là que les copies perdent encore face à l'original.

On copie tout ce qui vaut la peine d'être copié

L'auteur de la chaîne affirme qu'il en ira de même pour toute startup prometteuse. À défaut, on peut lancer un agent de code (le post cite Fable et Astra) sur le produit lui-même et sur tous les posts publics de l'entreprise, et lui demander de reproduire la technologie. Le modèle le fera.

Les objections sont connues. Reproduira-t-il 100 % des fonctionnalités ? Mais pourquoi 100 %, si vous n'en avez besoin que de 10 % ? Qui assurera la maintenance ? Le même modèle. Chacune de ces réponses peut être contestée, mais pour beaucoup d'acheteurs elles suffiront.

L'auteur n'en parle pas de façon abstraite. Son équipe chez BitGN développe Company Brain et commence déjà à le déployer dans d'autres entreprises. Derrière le système, il y a 9 mois de recherche, de développement et d'optimisations. Et il sait avec certitude que plus d'une équipe a déjà lancé Fable ou Codex sur tous les matériaux et API disponibles pour reproduire le système. On ne peut pas l'empêcher : les binaires fuitent, et à partir de l'API et des documents, on les rétro-ingénierise jusqu'au code source pour les reproduire.

Où chercher la protection, alors

La conclusion de l'auteur : l'atout ne doit pas reposer sur le secret. Il a lui-même publié les mots-clés de la couche technique de Company Brain : FoundationDB et LMDB, tests déterministes, fault injection et replay, changesets immuables, snapshot isolation, OCC, autorisation basée sur les capabilities, SDK versionnés pour chaque entreprise, recherche respectant les droits d'accès, audit de la provenance des données. Ce n'est qu'une petite partie de la liste. N'importe quel agent peut la lire, et l'auteur trouve cela normal.

La logique est la suivante : le coût de développement et de reproduction des technologies baisse, donc la base conceptuelle et les sources cessent d'être des douves. La valeur et l'avantage concurrentiel se déplacent vers ce qui passe encore mal à l'échelle via l'IA. En exemple, le post évoque un module de formation sur la progressive disclosure : quiconque y a accès a vu le code et lu les documents obligatoires pour participer au développement du noyau. Je le lis ainsi : la protection réside dans les personnes et le savoir accumulé, non dans le dépôt.

L'équipe prévoit actuellement la prochaine version de Company Brain, afin qu'elle passe mieux à l'échelle dans les grandes entreprises.

Que faire concrètement

Trois questions à poser à l'équipe avant la sortie, et non après :

• Si un agent lit notre API, notre documentation et notre blog, qu'est-ce qu'il ne pourra pas reproduire du produit ?
• Qu'est-ce qui s'accumule chez nous avec le temps sans se trouver dans le dépôt : données, expérience de déploiement, calibration sur des cas réels, confiance des clients ?
• Pouvons-nous dévoiler l'architecture sans crainte ? Sinon, c'est peut-être que nous n'avons pas de douves.

L'auteur souligne qu'il faut intégrer cette inéluctabilité dans le développement dès aujourd'hui et en faire une partie du plan. Dans ce cas, divulguer les spécifications de la couche technique n'est pas effrayant.

Limites

C'est l'opinion d'un praticien intéressé : il vend sa propre technologie, et le post ne donne aucun chiffre sur la fréquence à laquelle les copies remplacent réellement l'original. Sur les équivalents de Jev, il n'y a que des « on dit », sans mesures indépendantes de calibration. La thèse « seuls 10 % des fonctionnalités sont nécessaires » ne convient pas à tous : dans les secteurs régulés et les intégrations complexes, l'exhaustivité compte. Mais la direction est claire : si un agent reproduit un produit à partir de documents, miser uniquement sur « nous sommes les premiers » ne protège plus.