En rétroconstruisant 200 startups IA, on découvre que 73 % ne font guère plus que du simple prompt engineering

• Après avoir rétroconçu 200 startups IA, il apparaît que nombre d’entre elles affirment disposer d’une technologie propriétaire alors qu’en pratique elles fonctionnent en appelant des API externes
• Parmi les entreprises étudiées, 73 % utilisent simplement les API d’OpenAI ou de Claude, en y ajoutant tout au plus une interface ou quelques fonctionnalités basiques
• Une grande partie des startups mettant en avant leur « LLM propriétaire » n’étaient en réalité que des wrappers GPT-4 envoyant des requêtes vers api.openai.com, avec une simple couche de prompt système, puis vendus avec des marges de plusieurs dizaines à plusieurs centaines de fois
• La plupart des services mettant en avant une architecture RAG habillaient aussi en « infrastructure propriétaire » une stack standard d’une quarantaine de lignes combinant OpenAI text-embedding-ada-002, Pinecone/Weaviate et GPT-4 ; avec environ 30 000 dollars de coûts mensuels pour 1 M de requêtes et 150 000 à 500 000 dollars de chiffre d’affaires, ils affichaient une structure de marge de 80 à 94 %
• À l’inverse, 27 % de l’ensemble regroupaient des sociétés wrapper transparentes sur leur stack, avec des mentions comme « Built on GPT-4 », des builders entraînant réellement leurs propres modèles, ou des équipes disposant de véritables différenciateurs techniques comme le vote multi-modèles ou des frameworks d’agents
• L’enquête montre ainsi que de nombreuses startups IA sont en fait des business de services fondés sur des API, tout en se présentant comme de l’infrastructure IA propriétaire ; elle souligne aussi que investisseurs, clients et développeurs peuvent tous le vérifier en ouvrant simplement l’onglet réseau dans les DevTools, et insiste sur la nécessité d’une communication technique honnête dans l’écosystème IA

---

Vue d’ensemble

• Les applications web de 200 startups IA financées par des investisseurs externes ont été analysées en suivant leur trafic réseau, leur code et leurs appels API, afin de comparer leurs promesses marketing à leur stack technique réelle
  • Le point de départ était le soupçon qu’une entreprise affirmant disposer d’une « infrastructure de deep learning propriétaire » ne faisait en réalité qu’appeler l’API OpenAI
  • Cette société avait levé 4,3 M$ et financé son développement sur le récit selon lequel elle aurait « construit une infrastructure fondamentalement différente »
• L’enquête a révélé un écart significatif entre les promesses et l’implémentation réelle dans 73 % des entreprises, dont une grande partie n’étaient que de simples wrappers autour d’API de modèles tiers
  • Les 200 startups analysées ont été sélectionnées via YC, Product Hunt, LinkedIn et des publications « We’re hiring » ; les sociétés de moins de 6 mois ont été exclues, et l’étude s’est concentrée sur celles ayant levé des fonds externes et formulé des affirmations techniques concrètes
  • L’analyse a été menée de manière passive, au niveau des outils de développement du navigateur, sans accès à des systèmes privés, sans contournement d’authentification et sans violation des CGU

Méthodologie

• Un pipeline d’analyse automatisé a été mis en place avec Playwright, aiohttp, etc., et trois types de données ont été collectés de manière systématique pour chaque site de startup
  • capture_network_traffic(url) pour capturer les en-têtes réseau et les motifs de requête
  • extract_javascript(url) pour la décompilation et l’analyse des bundles JS
  • monitor_requests(url, duration=60) pour suivre pendant 60 secondes les schémas d’appels API
• Les informations suivantes ont ensuite été structurées pour chaque site
  • claimed_tech : les affirmations techniques présentes dans les textes marketing et sur le site
  • actual_tech : la stack réelle observée via les en-têtes HTTP, les bundles JS et les appels API
  • api_fingerprints : les empreintes d’API tierces extraites à partir des domaines appelés, des en-têtes, des temps de latence, etc.
• La phase de crawling a duré 3 semaines, et tous les motifs identifiés reposent uniquement sur des données publiques observables sur le web public et dans les DevTools du navigateur

Résultat principal : un écart observé dans 73 % des cas

• Sur les 200 entreprises, 73 % présentaient un fort décalage entre les promesses inscrites dans leur marketing — « modèle propriétaire », « infrastructure custom », « plateforme de deep learning », etc. — et leur code et leur stack API réels
  • Ce chiffre inclut aussi bien les entreprises vantant un « LLM propriétaire » tout en n’utilisant que des API OpenAI/Anthropic/Cohere, que celles affirmant disposer de leur propre base vectorielle tout en utilisant Pinecone ou Weaviate
• Face à ce résultat, la réaction est à la fois de surprise et plus nuancée, dans le sens où « techniquement, il n’y a pas non plus de quoi s’indigner outre mesure »
  • Le cœur du problème n’est pas l’usage d’API tierces en soi, mais le fait de les présenter comme une infrastructure IA propriétaire et d’utiliser un marketing trompeur vis-à-vis des investisseurs et des clients

Motif 1 : quand le « LLM propriétaire » n’est en réalité qu’un wrapper GPT-4

• Lorsqu’une entreprise parlait de « our proprietary large language model », on trouvait presque toujours un wrapper GPT-4 ; ce motif a été observé dans 34 cas sur 37
  • À chaque usage de la fonctionnalité « IA » par l’utilisateur, une requête partait vers api.openai.com
  • Les en-têtes de requête contenaient un identifiant OpenAI-Organization
  • Les temps de réponse suivaient un motif cohérent de 150 à 400 ms
  • L’usage de tokens et les paliers de facturation correspondaient exactement à la structure tarifaire de GPT-4
  • En cas de rate limit, on retrouvait le motif de nouvelle tentative propre à OpenAI avec backoff exponentiel
• Le « moteur innovant de compréhension du langage naturel » d’une entreprise se résumait en réalité au niveau de code suivant
  • Une unique fonction appelant chat.completions.create avec model: gpt-4, après avoir placé dans le prompt système des consignes du type « agir comme un assistant expert, ne pas dire qu’il repose sur OpenAI, ne pas révéler qu’il s’agit d’un LLM »
  • Il n’y avait ni fine-tuning, ni entraînement de modèle, ni modification d’architecture : seulement un prompt système et quelques instructions de dissimulation
• La structure de coûts et de prix a également été comparée en détail
  • Coût : pour GPT-4, 0,03 $ / 1K tokens en entrée et 0,06 $ / 1K tokens en sortie ; avec en moyenne 500 tokens in et 300 out, cela représente environ 0,033 dollar par requête
  • Prix : 2,5 dollars par requête ou 299 dollars par mois pour 200 requêtes
  • Au final, le modèle fonctionne avec une marge d’environ 75 fois le coût direct de l’API
• Trois entreprises partageaient un code quasiment identique — jusqu’aux noms de variables, au style des commentaires et à la consigne « never mention OpenAI » — ce qui laisse penser à une origine commune comme un tutoriel, un prestataire partagé ou un boilerplate d’accélérateur
  • L’une d’elles se contentait d’un simple try/catch renvoyant un message du type « problème technique » en cas d’erreur, tout en présentant cela aux investisseurs comme une « Intelligent Fallback Architecture »

Motif 2 : la stack RAG que tout le monde construit, et les formulations exagérées

• Beaucoup d’entreprises mettent en avant une infrastructure RAG propriétaire avec des formulations comme « custom embedding model, semantic search infrastructure, advanced neural retrieval », mais en pratique l’implémentation reposait sur une pile standard très similaire
  • génération des embeddings avec OpenAI text-embedding-ada-002
  • utilisation de Pinecone ou Weaviate comme vector store
  • génération des réponses avec GPT-4 en y ajoutant du contexte
• Après avoir décompilé le code présenté sous le nom de « Proprietary Neural Retrieval Architecture », l’enquêteur a constaté qu’il s’agissait d’une structure appelant exactement ces trois étapes en environ 40 lignes de code Python
  • conversion de la question en embedding
  • recherche des documents top-k dans la base vectorielle
  • concaténation des textes trouvés puis envoi à GPT-4 comme message system
  • envoi simultané de la question utilisateur comme message user pour générer la réponse
• La structure de coûts et de prix montrait elle aussi de très grands écarts
  • embeddings OpenAI : 0,0001 dollar par 1K tokens
  • requête Pinecone : 0,00004 dollar par appel
  • completion GPT-4 : 0,03 dollar par 1K tokens
  • soit un coût total d’environ 0,002 dollar par requête
  • alors que la facturation réelle au client allait de 0,5 à 2 dollars par requête, soit une marge de 250 à 1000 fois le coût API
• 42 entreprises utilisaient une pile et une structure de code presque identiques, et 23 autres partageaient un schéma similaire à plus de 90 %
  • les différences portaient surtout sur le choix Pinecone vs Weaviate, les noms de variables, ou l’ajout éventuel d’un cache Redis
  • certains cas allaient jusqu’à ajouter un cache Redis et le commercialiser comme un « optimization engine », ou une logique de retry présentée comme un « Intelligent Failure Recovery System »
• L’article estime aussi l’économie d’une startup à 1 million de requêtes par mois
  • coûts : environ 100 dollars pour les embeddings, 40 dollars pour l’hébergement Pinecone, environ 30 000 dollars pour les completions GPT-4, soit un total d’environ 30 140 dollars par mois
  • revenus : 150 000 à 500 000 dollars par mois
  • soit une structure d’activité avec une marge brute très élevée de 80 à 94 %

Schéma 3 : ce que signifie réellement « nous avons fait notre propre fine-tuning »

• En retraçant l’infrastructure des entreprises qui affirment « nous avons fine-tuné notre modèle nous-mêmes », l’enquête les répartit en deux grandes catégories
  • une minorité (environ 7 %) exécute réellement ses propres jobs d’entraînement via AWS SageMaker, Google Vertex AI, etc., stocke les artefacts de modèle dans des buckets S3, puis exploite des endpoints d’inférence distincts avec supervision d’instances GPU
  • la majorité utilisait en réalité l’API de fine-tuning d’OpenAI, dans une structure qui revenait surtout à « envoyer à OpenAI des données d’exemple et des prompts pour stockage »
• Dans le premier cas (véritable entraînement interne), l’infrastructure d’entraînement et le pipeline de déploiement restent dans une certaine mesure visibles même depuis le navigateur, alors que dans le second, cela se manifeste le plus souvent par un simple appel à un endpoint OpenAI unique

Comment distinguer rapidement les sociétés wrappers

• Motifs du trafic réseau

  • En ouvrant DevTools (F12) → onglet Network dans le navigateur et en observant les requêtes émises pendant l’usage des fonctions IA du service, on peut faire une distinction simple
    • api.openai.com
    • api.anthropic.com
    • api.cohere.ai
    • si des domaines de ce type apparaissent directement, il s’agit fondamentalement d’un wrapper d’API de modèles tiers
  • La latence de réponse sert aussi d’empreinte
    • dans le cas de l’API OpenAI notamment, il existe un motif de latence caractéristique avec une concentration des réponses dans la plage 200 à 350 ms, ce qui permet d’inférer le modèle backend

• Bundles JavaScript et exposition de clés

  • Une autre méthode simple consiste à rechercher les mots-clés suivants dans le code source de la page et les bundles JS
    • openai, anthropic, claude, cohere, sk-proj- (préfixe des clés de projet OpenAI), etc.
  • Au cours de l’enquête, 12 entreprises déployaient leurs clés API directement dans le code frontend ; un e-mail de signalement leur a été envoyé, mais aucune n’a répondu

• Matrice du langage marketing

  • L’article organise sous forme de tableau les motifs entre le langage des copies marketing et l’implémentation technique réelle, sous le nom de « Marketing Language Matrix »
    • lorsque des termes techniques concrets apparaissent, comme « type d’instance GPU, architecture de serving, taille du modèle », il y a davantage de chances que l’entreprise dispose réellement d’une certaine infrastructure propre
    • à l’inverse, plus le discours se limite à des buzzwords abstraits comme « advanced AI », « next-gen intelligence » ou « proprietary neural engine », plus il est probable que l’intérieur ne soit qu’un wrapper d’API tierce

Carte de la réalité de l’infrastructure et paysage des startups IA

• L’article synthétise, à travers plusieurs diagrammes, la carte de la réalité actuelle de l’infrastructure des startups IA
  • beaucoup de startups existent sous la forme d’une fine couche applicative posée sur des fournisseurs de modèles comme OpenAI, Anthropic ou Cohere
  • au-dessus de chaque couche s’empilent des services cherchant à se différencier par le workflow, l’UX, les données métier ou les pipelines
• Sur cette base, une large part des startups IA apparaît en réalité comme des entreprises de service ou de plateforme, avec un décalage entre cette réalité et leur manière de se présenter comme des « entreprises d’infrastructure IA propriétaires »

Pourquoi faut-il s’en soucier ?

• À la question « si ça fonctionne bien, en quoi est-ce un problème ? », l’enquêteur répond selon quatre points de vue
  • investisseurs : une part importante des fonds investis aujourd’hui dans nombre d’entreprises finance non pas la recherche IA ou le développement de modèles, mais en pratique une couche de prompt engineering et de workflow
  • clients : ils paient un prix incluant une prime de plus de 10 fois le coût API réel, alors que des fonctionnalités proches peuvent souvent être implémentées directement dans un simple projet de week-end
  • développeurs : derrière l’image brillante des « startups IA », il s’agit souvent en réalité de services wrappers à faible barrière à l’entrée ; il faut donc reconnaître qu’il est possible de construire soi-même quelque chose de similaire en peu de temps
  • écosystème : une situation dans laquelle 73 % des entreprises IA exagèrent ou induisent en erreur sur la technologie reflète un état proche d’une bulle et crée des incitations malsaines

Spectre des wrappers : tous les wrappers ne sont pas mauvais

• À travers un schéma intitulé « Wrapper Spectrum », l’article explique qu’il existe aussi des niveaux qualitatifs différents parmi les sociétés wrappers
  • à une extrémité, on trouve des wrappers qui se contentent d’ajouter une fine interface utilisateur à une API tierce
  • à l’autre, on trouve des wrappers avancés qui fournissent des workflows spécialisés par domaine, une excellente UX, une orchestration de modèles et des pipelines de données à forte valeur
• Le message central ne porte pas sur le simple fait d’être ou non un wrapper, mais sur l’honnêteté et la manière d’apporter de la valeur
  • les entreprises qui utilisent des API tierces tout en le déclarant avec transparence, et qui se différencient par la résolution de problèmes, l’expérience ou les données, sont évaluées positivement

Les 27 % qui font les choses correctement

• Catégorie 1 : wrappers transparents (Transparent Wrappers)

  • Les entreprises de ce groupe indiquent explicitement sur leur site des mentions comme « Built on GPT-4 » et assument clairement que ce qu’elles vendent, c’est le workflow, l’UX et l’expertise métier
    • Exemple : un service qui fournit une automatisation de documents juridiques en combinant GPT-4 et des modèles juridiques
    • Exemple : un service basé sur Claude spécialisé dans le routage de tickets de support client
    • Exemple : un service de workflow de contenu combinant plusieurs modèles et un processus de relecture humaine

• Catégorie 2 : les vrais builders (Real Builders)

  • Ce groupe réunit des entreprises qui entraînent réellement leurs propres modèles
    • Une IA de santé qui exploite des modèles auto-hébergés afin de respecter la conformité HIPAA dans le secteur médical
    • Un service qui entraîne et exploite des modèles de risque personnalisés pour l’analyse financière
    • Un service qui développe et déploie des modèles de computer vision spécialisés pour l’automatisation industrielle

• Catégorie 3 : les combinaisons innovantes (Innovators)

  • On y trouve des entreprises qui utilisent des modèles tiers, mais qui ont construit par-dessus une architecture réellement nouvelle
    • Un système qui améliore la précision via un vote entre plusieurs sorties de modèles
    • Un système qui exécute des tâches complexes en créant un framework de mémoire et d’agents
    • Des cas introduisant une nouvelle forme d’architecture de retrieval
  • Ces entreprises ont en commun de pouvoir expliquer leur architecture en détail et de disposer d’une structure effectivement construite par elles-mêmes

Leçons tirées : le problème avant la stack, et l’honnêteté

• Après trois semaines d’enquête, on peut résumer ainsi
  • Le problème à résoudre compte plus que la stack technique elle-même, et une grande partie des meilleurs produits observés avaient en réalité une structure qu’on pourrait qualifier de « simple wrapper »
  • Cela dit, l’honnêteté est une dimension à part entière, et la différence entre un wrapper intelligent et un wrapper trompeur, c’est la transparence
  • La ruée vers l’or de l’IA crée des incitations qui poussent à faire de fausses déclarations, à cause des attentes des investisseurs et des clients qui veulent de l’« IA propriétaire »
  • Et construire sur des API n’a rien de honteux en soi ; le problème, c’est de le dissimuler et de l’habiller en « architecture de réseau neuronal propriétaire »

Cadre d’évaluation et conseils concrets

• Test de reproductibilité en 48 heures

  • L’auteur propose un critère simple pour évaluer toute « startup IA »
    • « Peut-on reproduire sa technologie cœur en 48 heures ? »
    • Si oui, il s’agit techniquement d’un wrapper, et
      • si l’entreprise présente honnêtement sa stack, c’est une entreprise acceptable
      • si elle la cache tout en revendiquant une « infrastructure IA propriétaire », c’est une entreprise à éviter

• Conseils pour les fondateurs

  • Les principes proposés aux fondateurs sont les suivants
    • communiquer honnêtement sur la stack
    • concurrencer par l’UX, les données et l’expertise métier
    • ne pas prétendre avoir construit ce qu’on n’a pas construit
    • accepter que « Built with GPT-4 » n’est pas une faiblesse, mais une description honnête

• Conseils pour les investisseurs

  • Les points de vérification proposés aux investisseurs sont les suivants
    • demander un diagramme d’architecture
    • réclamer les factures d’API OpenAI, Anthropic, etc. pour vérifier le niveau réel de dépendance
    • valoriser les entreprises wrapper comme des entreprises wrapper
    • récompenser par des incitations les équipes qui dévoilent honnêtement leur stack

• Conseils pour les clients

  • Les actions concrètes proposées aux clients sont les suivantes
    • ouvrir l’onglet Network du navigateur et vérifier les requêtes sortantes
    • poser directement des questions sur l’infrastructure et l’usage des modèles
    • vérifier si l’on ne paie pas une marge de plus de 10x inutile sur de simples appels API
    • évaluer selon les résultats réels et la capacité à résoudre le problème, plutôt que sur les promesses techniques

En une phrase : la réalité des « startups IA »

• « La plupart des “startups IA” ressemblent davantage à des activités de services qui remplacent des coûts salariaux par des coûts d’API »
  • Ce n’est pas un mauvais business model, mais une réalité qui doit être assumée et expliquée honnêtement

Développements et réactions après l’enquête

• Semaine 1 : l’auteur pensait au départ qu’environ 20 à 30 % utiliseraient des API tierces, mais note que le résultat a été bien plus important
• Semaine 2 : un fondateur lui a demandé « comment vous êtes entré dans notre environnement de production ? », et l’auteur a répondu qu’il avait simplement regardé l’onglet Network du navigateur
• Semaine 3 : deux entreprises ont demandé le retrait des résultats de l’enquête, mais l’article précise qu’aucun nom d’entreprise n’a été publié et que cela reste toujours le cas
• Hier : un VC a demandé un audit de ses sociétés en portefeuille avant le prochain board, et l’auteur indique avoir accepté

Plan de publication des données et outils

• Sur la base de cette recherche, il est prévu de publier la méthodologie et les outils

• Ce qui sera publié sur GitHub (gratuitement)

  • le code complet de l’infrastructure de scraping
  • des techniques d’extraction d’empreintes d’API
  • des scripts de détection que tout le monde pourra exécuter
  • un recueil de patterns de temps de réponse pour les principales API d’IA

• Analyse avancée (réservée aux membres)

  • le cas d’une « licorne IA » valorisée 33 millions de dollars par mois qui n’utilise en réalité que 1 200 dollars par mois de coûts OpenAI
  • une structure présentée comme un « modèle à 100 millions de paramètres » alors qu’elle se résume en fait à trois system prompts
  • du code de production servi publiquement (côté client, extraits anonymisés)
  • un framework de cinq questions qui révèle immédiatement un wrapper
  • des études de cas comparant les présentations aux investisseurs et l’infrastructure réelle

Message final et nécessité d’une « ère de l’IA honnête »

• L’enquête a été menée sans divulguer les noms des entreprises, en ne partageant que les patterns, et souligne la conviction que le marché finira par récompenser la transparence
• Il a effectivement été confirmé que 18 entreprises créent, au sens propre, de nouvelles technologies,
  • et leur adresse ce message d’encouragement : « vous savez qui vous êtes, continuez à construire »
• Après l’enquête, sept fondateurs ont pris contact en privé,
  • certains étaient sur la défensive, d’autres reconnaissants, et trois ont demandé comment faire évoluer leur marketing de « proprietary AI » vers « built on best-in-class APIs »
  • l’un d’eux aurait confié : « Nous savions que nous mentiions, les investisseurs l’attendaient, tout le monde faisait pareil ; maintenant, comment est-ce qu’on arrête ? »
• En conclusion, l’article insiste une nouvelle fois sur le fait que la ruée vers l’or de l’IA ne s’arrêtera pas, mais qu’une ère de l’honnêteté doit commencer, et rappelle que n’importe qui peut vérifier la vérité par lui-même en ouvrant simplement l’onglet Network des DevTools (F12)

[geekygeek]

Parmi les commentaires, il y en a un qui dit : « L’existence même de l’auteur est douteuse. La source des données n’est pas claire non plus, et on ne peut pas capturer le trafic réseau comme on veut. Une vérification de base est nécessaire », et je suis d’accord.
Le lien LinkedIn indiqué sur son profil Medium renvoie aussi vers une page inexistante, et il semble que cette personne n’existe pas, à la base. Le fait qu’au 25 novembre, il continue de mentionner GPT-4 plutôt que GPT-4o est également étrange.

Qu’un développeur au point d’intégrer jusqu’à un système de paiement par abonnement pour monétiser le service implémente la communication avec l’API d’IA côté client plutôt que côté serveur, au point que cela se détecte aussi facilement… c’est difficile à croire.

[mhj5730]

Quand on essaie de créer des agents, l’ingénierie de prompt apparaît comme une application de l’IA dotée d’une productivité tout à fait remarquable.

[GN⁺]

Avis Hacker News

• 2023 a été l’année des démos de prompt à répétition chaque semaine
  Même lors d’un événement AWS, un intervenant a occupé une heure entière à ouvrir Claude et à taper des prompts au hasard
  Dans notre équipe aussi, on a passé six mois à construire des « agents » en leur greffant des outils, des connecteurs et un système d’évaluation, pour finalement revenir à du simple prompt engineering

  • On nous a même lancé en plaisantant : « La prochaine étape, ce n’est pas l’offshoring ? »
  • J’ai du mal à prendre au sérieux ceux qui utilisent le prompt engineering sérieusement. Quand je vois ce terme dans un mail d’entreprise, je passe simplement à autre chose
  • Cela dit, je me demande si ce projet fonctionnait vraiment. Beaucoup d’entreprises disent créer des AI Agents, mais je n’en ai jamais vu un qui tourne correctement. Dès qu’on essaie de fermer la boucle, le LLM patauge
  • Au final, on fabrique juste une nouvelle solution qui réemballe une solution existante, donc on dirait bien que le développement logiciel continuera éternellement

• Un mentor m’avait dit autrefois qu’« un expert en technologie est quelqu’un qui sait une ou deux choses de plus que les autres »
  Du coup, je trouve la vague actuelle du prompt engineering assez naturelle. Plus une technologie est nouvelle, plus elle évolue en ajoutant une ou deux couches au stack existant

  • J’ai aussi entendu dire que le secret d’un bon consultant, c’est de savoir quoi lire en allant à une réunion
  • Même un simple ajustement de prompts demande énormément de temps en tests et tuning. Le plus important, c’est de trouver la bonne variante pour chaque modèle
  • Personnellement, je trouve plus intéressante l’approche qui réduit les stacks complexes et obtient le même effet via une stratégie de simplification

• Dire que « ce n’est que du prompt engineering » sous-estime la difficulté réelle de construire des systèmes performants
  Concevoir des métriques d’évaluation, gérer les tool calls, le caching, etc., ce n’est pas juste une histoire de prompts. Si une entreprise peut montrer des résultats, elle lèvera facilement des fonds

  • En pratique, beaucoup restent au niveau prompt + CRUD, et la plupart des entreprises sont en fait essentiellement des boîtes CRUD
  • Si l’argent afflue, ce n’est pas à cause des résultats mais à cause de la bulle IA et de l’obsession des investisseurs pour le rendement. En réalité, on vend des pelles au lieu d’exploiter la mine d’or
  • Seuls ceux qui ont déjà mis en place un vrai processus d’évaluation comprennent à quel point c’est difficile
  • Mais la plupart des projets IA internes n’évaluent même rien. Même chez les FAANG, on est à moins de 5 %

• Voir un article parler de GPT-4 en novembre 2025, c’est suspect
  La méthodologie qui prétend identifier les fournisseurs d’IA via le trafic réseau paraît aussi étrange. Si le frontend appelle directement l’API, le risque d’exposition des clés de sécurité est élevé
  Cette enquête sent mauvais

  • OpenAI fournit des clés client permettant des appels directs. Voir la documentation officielle
  • Le fait de mentionner d’anciens noms de modèles ressemble aussi à une trace de génération par LLM

• La question qui revient, c’est : « Alors, qu’est-ce qu’il faut faire ? »
  Dans les années 90, ajouter une UI à un système console était déjà une excellente idée de startup

  • Le problème, c’est de se présenter comme une entreprise d’IA alors qu’on construit en réalité une appli CRUD. Pour les non-techniciens, la différence est difficile à voir
  • Le jour où OpenAI arrêtera de casser les prix, il faudra créer de petits modèles spécialisés par domaine
  • Il suffit de laisser agir la logique du marché. Cela dit, toute l’industrie logicielle est épuisée par la surchauffe autour de l’IA
  • C’est dangereux d’emballer une simple plateforme wrapper comme de « l’IA ». C’est une structure sans défense similaire à celle de la bulle internet
  • Il ne s’agit pas de construire une vraie IA, juste d’utiliser un LLM

• En réalité, ce phénomène était déjà courant dans les startups d’avant l’IA
  Il suffisait souvent d’améliorer l’UX autour d’une technologie existante pour gagner beaucoup d’argent. En interne, ce n’était qu’un assemblage d’outils open source, mais les marges étaient si élevées qu’un développement maison n’avait aucun intérêt

• Je pensais déjà cela juste après la sortie de ChatGPT.
  Si une entreprise disposait d’une vraie AGI, elle n’aurait aucune raison de la vendre. Elle construirait simplement ses propres services pour écraser la concurrence

  • En fait, même sans AGI, le même cycle se reproduit
    1. Une startup emballe GPT/Claude et crée un nouveau cas d’usage
    2. OpenAI ou Anthropic implémente directement cette fonctionnalité et la lance
    3. Le wrapper n’a aucun moat (barrière à l’entrée), et il est aussi facile pour l’éditeur du modèle sous-jacent de concurrencer

• Il n’y a que très peu d’entreprises qui construisent des LLM, et leurs fonctionnalités se ressemblent
  Au final, le cœur de l’automatisation, c’est le prompt engineering.
  Comme pour les apps mobiles, la big tech peut copier ça facilement si elle le décide. Perplexity et Cursor sont eux aussi en danger

  • En revanche, les idées au ROI trop faible n’intéressent pas la big tech. Il reste donc des opportunités sur des marchés de niche qui ne rapportent pas des centaines de millions

• L’article en question ressemble lui-même à du contenu généré par IA
  Il est difficile de croire que l’auteur a réellement analysé les données

  • L’existence même de l’auteur paraît douteuse. La source des données n’est pas claire et on ne peut pas capturer librement le trafic réseau des autres. Un minimum de vérification s’impose

• Beaucoup se demandent : « Comment cette personne a-t-elle pu collecter ces données ? »
  Si c’était dans mon entreprise, il serait impossible de rendre des données clients publiques de cette manière

  • Le lien LinkedIn en bas de l’article n’existe même pas. On ne sait même pas si Teja Kusireddy est une personne réelle
  • Certaines entreprises semblent appeler directement l’API OpenAI depuis le frontend, mais cela peut aussi venir d’informations qui ont fuité côté backend
  • Le fait d’observer des appels directs dans le navigateur paraît étrange. On peut aussi se demander si des requêtes sans OAuth ni authentification sont réellement possibles
  • Mettre une clé API dans le frontend est un trou de sécurité, donc la plupart passent par le backend. Sans explication détaillée, c’est difficile à croire
  • L’article complet est disponible via ce lien Medium. Il semble qu’aucun nom d’entreprise précis n’ait été donné à cause de NDA

[cgl00]

Pourquoi est-ce que ce serait malhonnête ? mdr