En tant qu’investisseurs technologiques de longue date, nous avons vu les frontières entre applications et infrastructures s’estomper plus rapidement qu’à tout moment depuis l’ère du cloud. Battery General Partner Dharmesh Thakker a récemment retracé ce changement dans son post LinkedIn. En résumé : l’ère de l’informatique en nuage était l’âge d’or des investisseurs en capital-risque, et le pari gagnant était le « gros milieu » – pensez aux bases de données, aux outils d’observabilité et de sécurité situés entre les applications métier et l’infrastructure brute qui les sous-tend. La couche SaaS et d’infra-données se situait confortablement au-dessus des puces et des calculs qui inquiétaient quelqu’un d’autre — à savoir les hyperscalers. Mais aujourd’hui, avec les applications d’IA désormais étroitement liées aux centres de données, aux puces et aux infrastructures qui les gagent, les choix d’infrastructures sont devenus essentiels pour générer des marges et, en fin de compte, construire une entreprise durable.

Les entreprises qui gagnent actuellement en IA ne se situent pas d’un côté de cette ligne ; Au lieu de cela, ils possèdent toute la pile, de la terre à la jetons.

Prenons Cursor comme exemple. Cursor a commencé comme un outil d’autocomplétion alimenté par l’IA, entièrement propulsé par des modèles de fondation tiers — principalement GPT-4 d’OpenAI et Opus d’Anthropic. Mais il n’est pas resté longtemps un plugin de complétion de code. Il est devenu un IDE (environnement de développement intégré) entièrement agent et, au fil du temps, a commencé à développer Composer, un modèle personnalisé et spécialisé, entraîné sur la façon dont les ingénieurs travaillent réellement dans Cursor.

Ce faisant, Cursor est devenue une entreprise d’IA entièrement intégrée verticalement —données, modélisation et exploit— travaillant ensemble comme un seul système. Avec l’acquisition par SpaceX, elle ajoute désormais du calcul à la fois pour l’entraînement et l’inférence. Et demain, si Elon décide d’acheter ou de construire une puce, Cursor deviendrait la première entreprise en dehors de Google à posséder l’ensemble de la pile, des puces aux jetons.

Le parcours de Cursor pourrait devenir l’architecture de référence pour les entreprises d’applications d’IA agentique gagnantes. Pour tester cette thèse, nous avons récemment réuni des vice-présidents de l’ingénierie issus des principales entreprises d’applications IA et les avons associés à des leaders du côté de l’infrastructure IA (semi-conducteurs, inférence et constructeurs de modélisations), autour de bons vins et de bons plats. Les sujets de discussion : Comment ces mondes autrefois séparés convergent-ils, et que faut-il pour être un ingénieur à succès à l’ère de l’IA ?

Trois gardes se sont manifestés au cours de la conversation de la soirée.

1. La thèse de l’IA full-stack est désormais un véritable débat, pas seulement un slogan.

Depuis une décennie, l’ère SaaS nous apprend que l’infrastructure et les applications peuvent prospérer comme des couches séparées. La question provocante sur la table : l’IA brise-t-elle cela ? Un camp a soutenu que construire une entreprise d’IA durable nécessite de posséder toute la chaîne : modèle, inférence et flux de travail, car c’est le seul endroit où vit un avantage durable.

Le chemin pour y arriver ressemble à ceci. Commencez par des modèles open source de pointe d’Anthropic ou OpenAI pour avancer rapidement et trouver l’adéquation produit-marché. Une fois là, passez à des modèles open source et open-weight comme GLM, Kimi et faites votre propre inférence pour le coût et le contrôle. Le hic, c’est que cette migration est plus difficile qu’elle n’en a l’air : l’ingénierie des prompts est profondément spécifique au modèle, donc changer de modèle a tendance à casser des choses de manière non évidente. Les équipes qui font bien cela traitent la performance des modèles comme une discipline, construisant des évaluations approfondies et des benchmarks afin de pouvoir échanger un modèle et mesurer si la qualité tient la route. Comme l’a partagé un responsable de l’infrastructure lors du dîner, son équipe de performance du modèle se comporte comme des traders quantitatifs, cherchant l'« alpha » dans l’optimisation par noyau et multiplication matricielle. Un seul changement architectural a déjà rendu l’inférence d’un client plusieurs fois moins chère du jour au lendemain — preuve que de petites inefficacités, exploitées à grande échelle, génèrent de réelles économies.

L’opinion contraire soutenait que le layering de type SaaS fonctionne toujours, et que toutes les entreprises de logiciels applicatifs n’ont pas besoin de devenir des ateliers de modèles conscients des puces pour réussir. Ce qui est clair, c’est que la réponse n’est plus évidente. La fracture entre les hauts dirigeants de l’ingénierie est elle-même un signe que l’ancienne hypothèse — bâtie sur le modèle de quelqu’un d’autre — est désormais remise en question.

2. L’ingénierie d’inférence devient un nouveau muscle pour toutes les entreprises d’IA.

L’inférence était autrefois quelque chose que l’on externalisait à un fournisseur de modèles ; De plus en plus, c’est une compétence que l’on développe en interne. À mesure que de plus en plus d’entreprises adoptent des modèles open source et effectuent leurs propres inférences, le savoir-faire efficace devient rapidement une part essentielle de chaque organisation de plateforme. La raison est simple : la qualité de votre service direct sur un modèle détermine votre marge brute, donc tirer plus de chaque jeton devient un problème d’ingénierie de première classe plutôt qu’une réflexion après coup.

Un second thème, lié : la formation et l’inférence sont des métiers fondamentalement différents, et nécessitent du matériel différent pour maximiser l’efficacité des jetons. La formation est une énorme tentative ponctuelle d’enseigner un modèle ; L’inférence est le travail régulier et sensible à la latence consistant à répondre aux demandes à grande échelle. Les clusters construits pour l’un ont tendance à mal convenir à l’autre. Nous voyons déjà les premiers signes de cette scission. Google a récemment divisé sa toute nouvelle génération de puces en deux conceptions distinctes, l’une conçue pour l’entraînement et l’autre pour l’inférence. Attendez-vous à plus de cette spécialisation, car l’ère des agents rend le décalage trop coûteux pour être ignoré.

3. Tokenomique et effets du second ordre des agents codants

L’économie du développement natif de l’IA ne constitue plus d’erreurs d’arrondi. Une entreprise à la table dépense environ 1 000 $ par ingénieur par mois pour des agents de codage et prévoit facilement tripler ce chiffre avec des modèles plus performants comme Fable. Dans une organisation de ~200 ingénieurs, cela estime à 5 à 7 millions de dollars par an en dépenses symboliques. C’est un facteur de coût majeur — qui croît de façon exponentielle à mesure que les agents prennent en charge davantage de travail.

Cela pousse les équipes d’ingénierie à construire leurs propres systèmes internes pour gérer et optimiser les dépenses de jetons. Plus particulièrement, les passerelles LLM qui se situent entre les ingénieurs et les modèles sous-jacents, acheminant chaque requête vers le modèle le plus rentable pour la tâche et mettant en cache de manière agressive pour éviter de payer deux fois pour le même travail. Coinbase* en est un bon exemple. En plaçant par défaut les ingénieurs vers des modèles à poids ouvert moins coûteux comme GLM 5.2 ou Kimi 2.7 via une passerelle interne et en intégrant un routage et un cache intelligents, cela a réduit de moitié sa facture IA, même si l’utilisation des tokens continuait d’augmenter. Le signal plus large est que la gestion des coûts devient un indicateur de premier ordre pour les équipes d’ingénierie, aux côtés de la latence et de la fiabilité.

La prochaine frontière : des ingénieurs qui parlent les deux langues

À mesure que la pile s’effondre en systèmes intégrés, les ingénieurs les plus précieux ne seront pas ceux qui ne construisent que des applications ou qui optimisent uniquement l’infrastructure. Ce sont eux qui maîtrisent les deux, qui comprennent l’ajustement fin, la distillation et l’économie de l’inférence aussi facilement que l’UX et le design de workflow, et qui savent quand posséder une couche crée un réel avantage par rapport à un effort qu’il vaut mieux dépenser ailleurs.

Cela remodele discrètement la façon dont les meilleures entreprises s’organisent. Les rôles sont de plus en plus déterminés non pas par la couche de la pile que vous possédez, mais par le résultat dont vous êtes responsable. C’est l’équivalent organisationnel du passage du prix par siège à un prix basé sur les résultats : la valeur se mesure par ce qui est livré, pas par votre position dans la pile. Les équipes qui continuent de définir les rôles couche par couche laissent un levier démesuré sur la table.

Nulle part cela n’est plus clair que dans l’évolution des profils d’embauche. L’équipe de performance modèle n’existait presque pas il y a dix-huit mois ; aujourd’hui, c’est l’une des fonctions les plus recherchées en IA, et les profils qui la remplissaient auraient semblé déplacés il y a un an. Beaucoup sont des traders quantitatifs et des ingénieurs HFT, appréciés pour leur obsession de la latence, leur instinct de coût par cycle et leur discipline d’évaluation et de rétrotest qui correspondent presque parfaitement efficacement aux modèles de service. D’autres viennent d’un parcours en sciences quantitatives, maîtrisent les données à grande échelle, l’extraction de signaux et l’optimisation contrainte, exactement la boîte à outils pour tirer davantage parti de l’inférence, de l’ajustement fin, de l’orchestration du contexte et des workflows, et même de la latence vocale.

La question valable à un milliard de dollars de savoir si les applications et l’infrastructure finiront par fusionner ou rester séparées reste ouverte. Mais ce sont les ingénieurs qui se préparent pour le monde fusionné sur ceux sur lesquels nous miserions.