Points clés
- La société AI CTO est dirigée par AI, qui est le produit en soi, et non une fonctionnalité. Ce rôle diffère radicalement de celui d'un produit CTO dont certaines fonctionnalités utilisent simplement AI.
- La stratégie technologique consiste à choisir entre « construire » et « acheter » les modèles de base. La plupart des directeurs techniques (CTO) de AI achètent le modèle de base et se différencient au niveau de la recherche, du réglage fin, des agents et de l'expérience produit.
- La structure organisationnelle de l'ingénierie sépare la plateforme, le produit et la recherche. La conception organisationnelle basée sur les limites des services fonctionne moins bien lorsque la couche de modèle recoupe les fonctionnalités.
- L'évaluation et le red teaming sont des disciplines d'ingénierie dotées de personnel dédié. Il ne s'agit pas d'événements ponctuels liés au lancement. Les équipes qui livrent des produits AI fiables ont des pipelines d'évaluation sur le même chemin critique que le travail sur les fonctionnalités.
- Le coût de l'inférence est le nouveau coût d'infrastructure. L'économie des jetons par fonctionnalité est un indicateur de premier ordre pour CTO, sinon l'entreprise commercialise des démos qui perdent de l'argent à grande échelle.
Le CTO dont l'entreprise a construit un moteur de recommandation en 2018 et le CTO dont l'entreprise construit un produit natif AI en 2026 n'exercent pas le même métier. Le CTO de 2018 disposait d’un organigramme axé sur les services, d’une structure de coûts de type SaaS, d’un rythme d’évaluation trimestriel axé sur la disponibilité et la livraison de fonctionnalités, ainsi que d’une liste de fournisseurs dominée par des prestataires d’infrastructure. Le AI de 2026 dispose d’une organisation d’ingénierie structurée autour de la boucle modèle-données-évaluation, d’une structure de coûts dominée par l’économie de l’inférence, une discipline d'évaluation qui s'exécute en continu sur le même chemin critique que le produit, et une liste de fournisseurs dominée par des fournisseurs de modèles de base dont le CTO doit suivre les feuilles de route avec le même niveau de détail qu'un CTO de 2018 réservait au fournisseur de cloud.
Cette page s'adresse au CTO qui est en pleine transition vers la forme native du rôle AI, ainsi qu'au conseil d'administration ou au CEO cherchant à vérifier si un candidat a réellement déjà créé l'une de ces entreprises. Le document complémentaire est le AI CIO, qui traite de l'évolution parallèle dans les entreprises où le AI s'inscrit dans le parc informatique plutôt qu'au cœur du produit.
Construire ou acheter le modèle de base
La décision stratégique déterminante pour une entreprise AI CTO en 2026 est son approche vis-à-vis de la couche du modèle de base. Dans la pratique, cette décision prend trois formes, et presque toutes les entreprises natives de AI dont la taille est inférieure à celle d’un laboratoire de modèles de base se retrouvent dans la deuxième catégorie.
Construire son propre modèle de base à partir de zéro. Le coût d’un modèle de pointe compétitif s’élève toujours à plusieurs centaines de millions de dollars, les talents capables de le former se concentrent dans une poignée de laboratoires à l’échelle mondiale (OpenAI, Anthropic, Google DeepMind, ainsi qu’un petit groupe de challengers bien financés), et tout modèle de base que l’on forme aujourd’hui accuse un retard de six à neuf mois par rapport à la pointe de la technologie au moment de sa commercialisation. Cette voie est pertinente pour les laboratoires de modèles de base eux-mêmes, pour les contextes réglementaires où la dépendance externe est intenable, et pour un petit nombre d'entreprises où le modèle lui-même est le produit plutôt qu'un composant. Pour presque toutes les autres entreprises natives de AI, le calcul ne tient pas la route.
Achetez le modèle de base, construisez la différenciation par-dessus. C'est le modèle qui s'est imposé dans la plupart des entreprises SaaS natives de AI. L'entreprise CTO sélectionne un ou deux fournisseurs de modèles de base, les traite comme des partenaires stratégiques au même titre que les fournisseurs de cloud dans une entreprise SaaS traditionnelle, et concentre ses investissements en ingénierie sur la couche de recherche, le pipeline de réglage fin, l'échafaudage de l'agent, la discipline d'évaluation et l'expérience produit. La différenciation réside dans ce que l'entreprise fait avec le modèle, et non dans le modèle lui-même. C'est à ce modèle que la plupart des entreprises AI et CTO consacrent la majeure partie de leur temps.
Tout acheter, ne construire que l'interface produit. Idéal pour les entreprises natives AI en phase de démarrage qui valident encore l'adéquation produit-marché, où les capacités de l'équipe sont trop limitées pour investir dans les couches de récupération et d'évaluation, et où la question immédiate est de savoir si quelqu'un paiera pour ce que le produit produit. La plupart des entreprises qui survivent à la validation passent de ce modèle au précédent en 12 à 18 mois.
« Dans une entreprise native AI, la stratégie technologique et la stratégie vis-à-vis des fournisseurs de modèles de base ne font qu’un. Le CTO qui considère le modèle comme une simple relation fournisseur n’a pas encore compris l’enjeu. »
Conception de l'organisation technique autour des produits natifs de AI
La structure organisationnelle qui s'est stabilisée dans la plupart des entreprises natives de AI en 2026 se divise en trois fonctions de premier niveau, ce qui diffère de la division par limites de service qui domine les organisations d'ingénierie SaaS traditionnelles.
Équipe de la plateforme de modèles
Gère la couche de modèle de bout en bout : l'infrastructure d'inférence, la logique de routage des modèles, la couche de mise en cache, le pipeline d'évaluation, ainsi que l'observabilité et la télémétrie relatives au comportement des modèles en production. Sa taille évolue en fonction de la complexité du produit plutôt que de l'effectif brut de l'entreprise. Une structure allégée (5 à 10 % de l'ingénierie) est la norme dans les entreprises natives AI en phase de démarrage ; les entreprises dont la complexité des produits exige un investissement plus important dans la plateforme auront une structure plus lourde, représentant parfois 15 à 25 % d'une organisation, lorsque l'exploitation de la plateforme constitue la contrainte limitante sur la vitesse de développement des produits.
Ingénierie produit
Organisée autour de cas d'utilisation verticaux ou d'interfaces produit qui exploitent la plateforme de modèles. Chaque équipe est responsable de sa partie du produit, s'intègre à la couche de plateforme et livre des fonctionnalités. La structure des équipes est familière à quiconque issu d'une entreprise SaaS traditionnelle, mais les livrables sont différents. Au lieu de livrer un service gérant un workflow CRUD, l'équipe livre un workflow piloté par AI qui dépend du bon fonctionnement de la plateforme modèle dans des cas limites que l'équipe ne peut pas facilement tester de manière isolée.
Recherche appliquée
Gère le réglage fin, le travail sur les modèles personnalisés, le pipeline d’expérimentation et les paris techniques plus poussés sur le comportement des modèles. La plupart des entreprises natives AI disposent d’une petite fonction de recherche appliquée (5 à 15 personnes dans la plupart des entreprises de moins de 500 employés) étroitement liée à la feuille de route du produit plutôt que de mener des programmes de recherche indépendants. Son rôle est de traduire la recherche de pointe en ingénierie livrable, et non de publier des articles.
L'évaluation et le « Red Teaming » en tant qu'ingénierie de premier plan
La discipline de l’évaluation est la différence la plus marquante entre les directeurs techniques (CTO) de AI dont les produits survivent au-delà de la deuxième année et ceux dont les produits se dégradent discrètement. Trois pratiques spécifiques se dégagent chez les entreprises qui maîtrisent ce domaine.
Des suites d'évaluation sur le chemin critique. Maintenues avec la même rigueur d'ingénierie que la suite de tests. Un changement de modèle qui échoue à l'évaluation est déployé à peu près aussi souvent qu'un changement de code qui échoue à la suite de tests, c'est-à-dire presque jamais. La suite couvre les capacités de base, les modes de défaillance connus issus d'incidents de production et les cas limites à longue traîne qui se sont accumulés au fur et à mesure que le produit a mûri. La couverture s'étend avec la surface du produit, et non avec la couche de modèle.
Le « red teaming » comme pratique opérationnelle continue. Une équipe dédiée (parfois au sein de l’organisation de la plateforme, parfois une organisation sœur relevant directement du CTO) effectue des sondages continus pour détecter les injections rapides, les jailbreaks, les schémas d’hallucination, les surfaces de biais et d’autres modes de défaillance des modèles. La cadence est hebdomadaire ou quotidienne selon le stade de développement de l’entreprise. Les conclusions de l’équipe rouge sont intégrées à la suite d’évaluation, à la logique de routage des modèles et au backlog de l’équipe produit en tant que problèmes standard.
Pipelines d'évaluation en ligne. Les sorties des modèles de production sont échantillonnées et comparées en continu à des traces de référence, à des standards de référence conservés à part, ou à des évaluations utilisant un LLM comme juge. Les régressions silencieuses, c'est-à-dire les cas où le produit fonctionne toujours mais où la qualité s'est dégradée d'une manière dont aucun utilisateur ne s'est encore plaint, sont signalées avant qu'elles ne s'accumulent et ne deviennent un problème de désabonnement. C'est cette discipline qui distingue les entreprises qui apprennent à partir des données de production de celles qui se contentent de livrer et d'espérer que tout ira bien.
Le cadre OpenAI Evals, les modèles d'évaluation publiés par Anthropic et les cours d'évaluation de DeepLearning.AI ont tous convergé vers des disciplines similaires au cours des deux dernières années ; les modèles publiés sont suffisamment aboutis pour qu'il n'y ait aucune excuse pour qu'un AI CTO néglige ce travail.
L'économie de l'inférence en tant que métrique CTO de premier ordre
Dans la plupart des entreprises natives de AI en 2026, le coût de l'inférence est le poste de coût variable le plus important, souvent supérieur à celui de l'infrastructure, et souvent comparable à la masse salariale une fois pris en compte le coût des ventes. Les entreprises AI CTO qui ne considèrent pas cela comme un indicateur de premier ordre prennent leurs décisions de tarification à l'aveuglette et voient leurs marges s'éroder discrètement à mesure que l'utilisation augmente.
La discipline qui importe est l'économie unitaire par fonctionnalité. Pour chaque fonctionnalité majeure du produit, trois chiffres : les jetons consommés par service (entrée plus sortie, y compris tout agent ou infrastructure de récupération), la marge brute par service au niveau de tarification actuel, et la courbe d'évolution prévue à mesure que l'utilisation augmente. Les directeurs techniques de AI qui gardent ces chiffres en tête pour les dix principales fonctionnalités prennent des décisions en matière de tarification, de routage et d’architecture qui se renforcent mutuellement. Ceux qui ne le font pas finissent par devoir expliquer une compression des marges à la direction de CFO au bout de 18 mois.
Quelques modèles architecturaux reviennent systématiquement dans les entreprises qui ont bien cerné l’économie de l’inférence. Routage des modèles : utiliser des modèles plus petits et moins coûteux pour les requêtes qu’ils peuvent traiter et réserver les modèles de pointe aux requêtes qui les exigent. Couches de mise en cache pour les modèles de requêtes répétitives, pour les encodages, pour les complétions partielles. Des barrières de fonctionnalités par niveau qui alignent les fonctionnalités coûteuses en inférence sur des niveaux de revenus capables d’absorber le coût. La plupart des entreprises intègrent également une observabilité de type « LLM-as-judge » afin que les décisions de routage puissent être vérifiées plutôt que simplement acceptées. Aucun de ces éléments n’est nouveau en 2026, mais c’est la discipline consistant à les traiter comme un travail d’ingénierie fondamental plutôt que comme des optimisations à revoir plus tard qui distingue les directeurs techniques (CTO) de AI dont les entreprises survivent à la mise à l’échelle produit-marché de ceux dont les entreprises échouent.
Lectures connexes
Le pilier des cadres technologiques couvre le rôle plus large dont le AI CTO est une variante. La page sœur sur AI CIO traite de l'évolution parallèle dans les entreprises où le AI s'inscrit au sein du parc informatique. Pour une vue au niveau du portefeuille au-dessus de l'organisation d'ingénierie, voir AI Strategy Executive. Pour la comparaison des rôles entre CTO, CAIO et CDAO, consultez CAIO vs CTO vs CDAO. Pour discuter d'une décision spécifique concernant le choix entre « construire ou acheter » ou la structure organisationnelle, prenez rendez-vous avec un expert.
Le parcours fractionné vers AI CTO est une réalité. Consultez fractional Chief AI Officer pour la variante à temps partiel du même poste, ou AI conseil en stratégie pour l'alternative sous forme de projet lorsque le travail a un début et une fin définis.
Questions fréquemment posées
En quoi le modèle AI CTO se distingue-t-il du modèle CTO classique ?
Quatre axes de travail qui ne se présentent pas de la même manière dans un rôle produit CTO traditionnel. Premièrement, la décision « construire ou acheter » concernant le modèle de base lui-même : quel fournisseur, sous quelle licence, avec quelle stratégie de réglage fin, et quel plan de migration si un meilleur modèle est disponible dans six mois. Deuxièmement, la structure organisationnelle d'ingénierie qui soutient un produit natif AI, qui diffère de la structure organisationnelle axée sur les limites de service qui fonctionne pour le SaaS traditionnel. Troisièmement, l'évaluation et la discipline de la « red team » qui se situent sur le même chemin critique que la livraison des fonctionnalités, car la couche du modèle peut se dégrader silencieusement d'une manière que la dégradation des services traditionnels ne permet pas. Quatrièmement, l'économie de l'inférence : la structure des coûts d'un produit natif AI est dominée par les jetons consommés plutôt que par l'infrastructure louée, et le CTO qui ne considère pas cela comme un indicateur de premier ordre livre des produits qui perdent de l'argent à grande échelle.
Une entreprise spécialisée dans le AI devrait-elle développer ses propres modèles de base ou utiliser des modèles externes ?
En 2026, pratiquement aucune entreprise native de AI dont la taille est inférieure à celle d'un laboratoire de modèles de base ne devrait former des modèles de base à partir de zéro. Le coût du pré-entraînement d'un modèle de base compétitif se maintient à plusieurs centaines de millions de dollars, et le domaine évolue encore si rapidement que tout modèle que vous formez aujourd'hui aura déjà six à neuf mois de retard sur l'état de l'art au moment de sa mise en service. La stratégie qui fonctionne pour la grande majorité des entreprises natives de AI consiste à acheter le modèle de base, puis à se différencier au niveau de la couche de récupération, du réglage fin, de l'échafaudage de l'agent, du pipeline d'évaluation et de l'expérience produit. Les entreprises qui devraient développer leurs propres modèles de base sont celles pour lesquelles le modèle lui-même constitue le produit (laboratoires de modèles de base) ou celles où les exigences réglementaires rendent toute dépendance externe intenable (certains contextes liés à la défense, à la santé ou aux services financiers).
En quoi la structure organisationnelle d'une entreprise d'ingénierie native AI diffère-t-elle de celle d'une entreprise SaaS traditionnelle ?
Les structures d'ingénierie SaaS traditionnelles s'articulent autour des limites des services : une équipe chargée du paiement, une équipe de facturation, une équipe de recherche, une équipe de notifications. Ces limites correspondent à l'architecture, et l'organigramme ne fait que la renforcer. Les produits natifs AI ont une structure différente, car la couche modèle recoupe les fonctionnalités du produit et le « flywheel » des données prime sur la décomposition des services. La structure qui s'est stabilisée en 2026 dans la plupart des entreprises natives AI comporte trois fonctions de premier niveau : une équipe de plateforme de modèles qui gère la couche modèle, l'infrastructure d'inférence et le pipeline d'évaluation ; une fonction d'ingénierie produit organisée autour de cas d'utilisation verticaux qui exploitent la plateforme ; et une fonction de recherche appliquée qui gère le réglage fin, le travail sur les modèles personnalisés et le pipeline d'expérimentation. Les proportions exactes varient en fonction du stade de développement de l'entreprise, mais la séparation entre la plateforme, le produit et la recherche est constante parmi les entreprises qui commercialisent des produits AI fiables.
Quelles sont les compétences en matière d'évaluation et de simulation d'attaques (red teaming) que doit acquérir un AI CTO ?
L'évaluation est l'équivalent natif de AI des tests de régression, à cette différence près que la couverture de test doit être établie de manière délibérée et que les modes de défaillance sont plus subtils. Trois pratiques distinguent les entreprises qui commercialisent des produits AI fiables de celles qui se contentent de proposer des démos. Premièrement, les suites d'évaluation sont maintenues sur le même chemin critique que le développement des fonctionnalités, avec le même niveau de qualité : une modification de modèle qui échoue à la suite d'évaluation est livrée à peu près aussi souvent qu'une modification de code qui échoue à la suite de tests, c'est-à-dire presque jamais. Deuxièmement, le « red teaming » en tant que pratique opérationnelle régulière plutôt qu’un événement ponctuel lors du lancement : une équipe dédiée recherche chaque semaine des injections de prompt, des jailbreaks, des schémas d’hallucination et des surfaces de biais. Troisièmement, des pipelines d’évaluation en ligne qui comparent les sorties des modèles de production à des traces de référence mises de côté, signalant toute dégradation silencieuse avant qu’un client ne s’en aperçoive.
À quoi ressemble concrètement l'économie inférentielle pour un AI CTO ?
Le coût de l'inférence est devenu le poste de coût variable le plus important dans la plupart des entreprises natives du AI, souvent supérieur à celui de l'infrastructure et souvent comparable à la masse salariale une fois pris en compte les coûts de vente. La discipline qui compte : l'économie unitaire par fonctionnalité. Pour chaque fonctionnalité, quel est le coût en jetons pour traiter une seule requête utilisateur, quelle est la marge brute par requête, et comment cela évolue-t-il à mesure que l'utilisation augmente ? Les entreprises CTO qui ne disposent pas de ces chiffres pour leurs dix principales fonctionnalités prennent leurs décisions tarifaires à l'aveuglette. Les directeurs techniques qui en disposent ont tendance à converger vers un schéma similaire : utilisation intensive du routage de modèles (des modèles plus petits et moins chers pour les requêtes simples, des modèles de pointe pour les plus complexes), des couches de mise en cache pour les schémas répétitifs, et des barrières de fonctionnalités par niveau qui alignent le coût d'inférence sur le niveau de revenus.
En quoi le modèle AI CTO diffère-t-il des modèles AI strategy executive ou CAIO ?
Le AI CTO est chargé de la conception du produit. Le AI strategy executive ou le Chief AI Officer est responsable de la stratégie de portefeuille au sein des entreprises où le AI fait partie d'un ensemble de projets sur lesquels l'entreprise mise, plutôt que d'être le produit phare en soi. Dans une entreprise où le AI est au cœur de l'activité, le AI CTO assume souvent une grande partie du rôle du AI strategy executive, car la stratégie produit de l'entreprise et sa stratégie AI ne font qu'un. Dans une entreprise traditionnelle ajoutant le AI à un portefeuille de produits existant, le CAIO définit la stratégie du portefeuille et le CTO existant (ou son équivalent au sein de l'organisation technologique) en assure la mise en œuvre sur le plan technique. Voir AI Strategy Executive pour le traitement au niveau du portefeuille et CAIO vs CTO vs CDAO pour la comparaison des rôles.
Quelle est la rémunération habituelle pour un poste de type AI ou CTO ?
La rémunération est supérieure à celle d'un produit traditionnel CTO à un stade comparable de développement de l'entreprise, en raison de la concentration de la demande. La rémunération des entreprises natives de AI en 2026 s'élève généralement à un salaire de base compris entre 400 000 et 700 000 dollars lors des levées de fonds de série B et au-delà, la rémunération totale dépassant les 2 millions de dollars aux stades ultérieurs, et les attributions d'actions étant fortement orientées vers le potentiel de hausse lorsque l'entreprise est positionnée dans un secteur AI en vogue. Les laboratoires de modèles de base et les entreprises pionnières dans le domaine du AI offrent les rémunérations les plus élevées, les rapports publics pour la période 2024-2025 indiquant que la rémunération totale des responsables techniques seniors du AI dépasse les 5 millions de dollars au sommet du marché. La prime de rémunération diminue à mesure que l'entreprise mûrit et que le label AI se banalise au sein de sa catégorie de produits.
Quel est le type de panne le plus courant sur les modèles AI et CTO ?
Un sous-investissement dans l'évaluation et un surinvestissement dans le dernier modèle en date. Ce schéma se retrouve chez les entreprises « AI-native » qui commercialisent un produit basé sur le modèle de pointe du moment, obtiennent d'excellents résultats lors des démonstrations, déploient le produit auprès des premiers clients, puis voient l'expérience en production se dégrader à mesure que les cas limites s'accumulent. L'instinct de l'équipe est de passer au modèle de pointe suivant dès sa sortie, ce qui entraîne un sprint d'intégration de six semaines et une nouvelle série de résultats de qualité « démo » sans résoudre le problème sous-jacent : il n'y avait tout simplement pas de suite d'évaluation pour détecter les régressions silencieuses dès le départ. Les équipes qui survivent à la deuxième année sont celles qui ont mis en place une discipline d'évaluation parallèlement au produit, et non celles qui ont couru après chaque mise à jour du modèle.
Need Expert Technology Guidance?
20+ years leading technology transformations. Get a technology executive's perspective on your biggest challenges.
