Comment Arm a grandi en licenciant des conceptions de CPU pour le mobile et l'embarqué — et pourquoi logiciels, outils et compatibilité peuvent compter plus que posséder des usines.
Arm n'est pas devenu influent en expédiant des boîtes de puces finies. Il a pris de l'ampleur en vendant des conceptions de CPU et la compatibilité — des pièces que d'autres entreprises peuvent intégrer dans leurs propres processeurs, dans leurs produits, selon leurs calendriers de fabrication.
« Licence d'IP CPU » signifie essentiellement vendre un jeu de plans éprouvé plus le droit légal de les utiliser. Un partenaire paie Arm pour utiliser une conception de CPU particulière (et des technologies associées), puis l'intègre dans une puce plus large qui peut aussi inclure GPU, blocs IA, connectivité, fonctionnalités de sécurité, etc.
La division du travail ressemble à ceci :
Dans les semi‑conducteurs, « une meilleure fabrication » est un avantage puissant — mais souvent temporaire, coûteux et difficile à étendre à de nombreux marchés. En revanche, la compatibilité se cumule. Quand beaucoup d'appareils partagent une base commune (jeu d'instructions, outils, support OS), développeurs, fabricants et clients bénéficient d'un comportement prévisible et d'un pool croissant de logiciels.
Arm illustre clairement comment l'adéquation à l'écosystème — standards partagés, chaînes d'outils et vaste réseau de partenaires — peut devenir plus précieuse que la possession d'usines.
On gardera l'histoire à haut niveau, on expliquera ce qu'Arm licence réellement, et on montrera comment ce modèle s'est répandu dans le mobile et l'embarqué. Ensuite, on détaillera l'économie en termes simples, les compromis et risques, et on conclura par des leçons pratiques de plateforme applicables au-delà des puces.
Pour un aperçu rapide de la mécanique commerciale, allez à /blog/the-licensing-economics-plain-english-version.
Arm ne « vend » pas des puces au sens habituel. Ce qu'il vend, c'est la permission — via des licences — d'utiliser la propriété intellectuelle d'Arm (IP) dans des puces que d'autres conçoivent et fabriquent.
Il est utile de séparer trois couches qui sont souvent confondues :
Les licences d'Arm se situent principalement aux deux premières couches : les règles (ISA) et/ou une conception de coeur prête à intégrer. Le licencié construit le SoC complet autour.
Les discussions se ramènent souvent à deux modèles :
Selon l'accord, les licenciés obtiennent typiquement du RTL (code de description matérielle), des configurations de référence, de la documentation, des éléments de validation et du support ingénierie — les ingrédients nécessaires pour intégrer et expédier un produit.
Ce qu'Arm ne fait généralement pas, c'est fabriquer les puces. Cette partie est gérée par le licencié et la fonderie qu'il choisit, plus les partenaires de packaging/test.
La fabrication de puces est chère, lente et pleine d'« inconnues ». Un modèle de licence évolue parce qu'il permet à de nombreuses entreprises de réutiliser une conception CPU déjà validée — fonctionnellement, électriquement, et souvent en silicium. La réutilisation réduit le risque (moins de surprises en phase tardive) et raccourcit le time-to-market (moins de conception depuis zéro, moins de bugs à traquer).
Un coeur CPU moderne est l'un des blocs les plus difficiles à réussir. Lorsqu'un coeur éprouvé est disponible en tant qu'IP, les partenaires peuvent concentrer leurs efforts sur la différenciation :
Cela crée une innovation parallèle : des dizaines d'équipes peuvent construire des produits distincts sur la même fondation, au lieu d'attendre la feuille de route d'une seule entreprise.
Dans une approche verticalement intégrée, une seule entreprise conçoit le CPU, conçoit le SoC, le valide et expédie la puce finale (et parfois les appareils aussi). Cela peut produire d'excellents résultats — mais l'échelle est limitée par la capacité d'ingénierie de l'organisation, l'accès à la fabrication et la capacité à servir de nombreux créneaux à la fois.
La licence inverse cela. Arm se concentre sur les problèmes réutilisables du « coeur », tandis que les partenaires concourent et se spécialisent autour de cette base.
À mesure que davantage d'entreprises expédient des conceptions CPU compatibles, les développeurs et éditeurs d'outils investissent plus dans compilateurs, débogueurs, systèmes d'exploitation, bibliothèques et optimisations. De meilleurs outils facilitent l'expédition du prochain appareil, ce qui augmente encore l'adoption — une boucle flywheel écosystémique qu'un seul fabricant a du mal à reproduire.
Les puces mobiles sont nées sous des contraintes sévères : appareils minuscules, pas de ventilateurs, surface limitée pour évacuer la chaleur, et une batterie que l'utilisateur attend durable. Cette combinaison force les concepteurs de CPU à considérer la consommation et le thermique comme des exigences de première classe. Un téléphone ne peut pas « emprunter » des watts supplémentaires longtemps sans chauffer, réduire la fréquence ou vider la batterie.
Dans cet environnement, la métrique gagnante n'est pas la gloire des benchmarks bruts — c'est la performance par watt. Un CPU légèrement plus lent sur le papier mais économisant l'énergie peut offrir une meilleure expérience utilisateur réelle car il maintient la vitesse sans surchauffe.
C'est une grande raison pour laquelle la licence Arm a explosé dans les smartphones : l'ISA et les coeurs Arm correspondaient à l'idée que l'efficacité est le produit.
La licence d'IP CPU d'Arm a aussi résolu un problème de marché : les fabricants de téléphones voulaient variété et concurrence parmi les fournisseurs de puces, mais ils ne pouvaient pas se permettre un monde logiciel fragmenté.
Avec Arm, plusieurs partenaires de conception pouvaient construire des processeurs mobiles différents — ajoutant leurs propres GPU, modems, blocs IA, contrôleurs mémoire ou techniques de gestion d'énergie — tout en restant compatibles au niveau CPU.
Cette compatibilité importait à tous : développeurs d'apps, éditeurs d'OS et fournisseurs d'outils. Quand la cible sous-jacente reste constante, les toolchains, débogueurs, profileurs et bibliothèques s'améliorent plus vite — et coûtent moins à maintenir.
Les smartphones se sont vendus à grande échelle, ce qui a amplifié les bénéfices de la standardisation. Les volumes élevés justifiaient des optimisations plus poussées pour les puces Arm, encourageaient un support logiciel et outils plus large, et faisaient de la licence Arm le « choix sûr » pour le mobile.
Au fil du temps, cette boucle de rétroaction a permis à l'IP CPU licenciée de surpasser des approches reposant principalement sur l'avantage manufacturier d'une seule entreprise.
« Embarqué » n'est pas un marché unique — c'est un fourre‑tout pour des produits où l'ordinateur est intégré : appareils domestiques, contrôleurs industriels, équipements réseau, systèmes automobiles, dispositifs médicaux et une vaste gamme de matériels IoT.
Ce que ces catégories partagent n'est pas tant des fonctionnalités que des contraintes : budgets énergétiques serrés, coûts fixes et systèmes qui doivent se comporter de manière prévisible.
Les produits embarqués sont souvent commercialisés pendant de nombreuses années, parfois une décennie ou plus. Cela signifie que la fiabilité, le patching de sécurité et la continuité d'approvisionnement comptent autant que la performance maximale.
Une fondation CPU compatible sur le long terme réduit le turn-over. Les équipes peuvent garder la même architecture logicielle, réutiliser des bibliothèques et corriger des bogues sans tout réécrire pour chaque nouvelle puce.
Quand une gamme de produits doit être maintenue longtemps après le lancement, « ça tourne encore le même code » devient un avantage commercial.
Utiliser un jeu d'instructions Arm largement adopté dans de nombreux appareils facilite le recrutement et l'exploitation :
Ceci est particulièrement utile pour les entreprises qui expédient plusieurs produits embarqués simultanément — chaque équipe n'a pas besoin de réinventer une plateforme.
Les portefeuilles embarqués ont rarement un seul « meilleur » appareil. Ils ont des paliers : capteurs low‑cost, contrôleurs milieu de gamme et unités compute haut de gamme pour gateways ou automobile.
L'écosystème Arm permet aux partenaires de choisir des coeurs (ou de concevoir les leurs) qui conviennent à différents objectifs de puissance et de performance tout en gardant des bases logicielles familières.
Le résultat est une famille de produits cohérente : points de prix et capacités variés, mais workflows de développement compatibles et chemins de montée en gamme plus fluides.
Une bonne fonderie peut rendre les puces moins chères. Un bon écosystème peut rendre les produits moins chers à concevoir, expédier et maintenir.
Quand de nombreux appareils partagent une fondation CPU compatible, l'avantage n'est pas seulement la performance‑par‑watt — c'est que les applications, systèmes d'exploitation et compétences techniques se transfèrent entre produits. Cette transférabilité devient un actif commercial : moins de réécritures, moins de bogues surprises, et un vivier de talents plus large connaissant déjà les outils.
La stabilité ISA/ABI à long terme d'Arm signifie que le logiciel compilé pour un appareil Arm fonctionne souvent sur des puces plus récentes — parfois avec une simple recompilation.
Cette stabilité réduit des coûts cachés qui s'accumulent au fil des générations :
Même de petits changements comptent. Si une entreprise peut passer de « Puce A » à « Puce B » sans réécrire des pilotes, sans revalider toute la base de code ou sans reformer l'équipe, elle peut changer de fournisseur plus vite et respecter ses délais.
La compatibilité ne concerne pas seulement le coeur CPU — elle englobe tout ce qui l'entoure.
Parce qu'Arm est une cible répandue, de nombreux composants tiers arrivent « prêts » : bibliothèques crypto, codecs vidéo, runtimes ML, piles réseau et SDKs d'agents cloud. Les fournisseurs de silicium livrent aussi des SDK, BSPs et codes de référence pensés pour être familiers aux développeurs ayant travaillé sur d'autres plateformes Arm.
La scale manufacturière réduit le coût unitaire. La compatibilité d'écosystème réduit le coût total — temps d'ingénierie, risque et time‑to‑market — souvent davantage.
La licence d'Arm ne se résume pas à obtenir un coeur CPU ou une ISA. Pour la plupart des équipes, le facteur décisif est de pouvoir construire, déboguer et expédier le logiciel rapidement dès le premier jour. C'est là que la profondeur de l'outillage de l'écosystème se cumule discrètement au fil du temps.
Un nouveau fournisseur de puce peut avoir une microarchitecture excellente, mais les développeurs posent toujours des questions basiques : Puis‑je compiler mon code ? Puis‑je déboguer les plantages ? Puis‑je mesurer la performance ? Puis‑je tester sans le matériel ?
Pour les plateformes Arm, la réponse est généralement « oui » dès le départ car l'outillage est largement standardisé :
Avec la licence d'IP CPU, de nombreuses entreprises expédient des puces compatibles Arm. Si chacune requérait une toolchain unique, chaque nouveau fournisseur serait perçu comme une nouvelle plateforme à porter.
Au lieu de cela, la compatibilité Arm permet souvent de réutiliser des systèmes de build existants, pipelines CI et workflows de débogage. Cela réduit le « coût plateforme » et facilite la victoire d'un nouveau licencié sur des designs sensibles au time‑to‑market.
L'outillage fonctionne mieux quand la pile logicielle est déjà disponible. Arm bénéficie d'un large support pour Linux, Android et une gamme d'RTOS, plus des runtimes et bibliothèques courants.
Pour beaucoup de produits, cela transforme la bring‑up d'une puce en une tâche d'ingénierie répétable plutôt qu'en projet de recherche.
Quand les compilateurs sont stables, les débogueurs familiers et les ports OS éprouvés, les licenciés itèrent plus vite : prototypes plus tôt, moins de surprises d'intégration et sorties plus rapides.
En pratique, cette vitesse explique en grande partie pourquoi le modèle de licence Arm monte en échelle — l'IP CPU est la fondation, mais les outils et chaînes logicielles la rendent utilisable à grande échelle.
Le modèle d'Arm ne signifie pas que toutes les puces se ressemblent. Il signifie que les partenaires partent d'une fondation CPU qui « colle » déjà à l'univers logiciel existant, puis concourent sur la façon dont ils construisent le reste.
De nombreux produits utilisent un coeur CPU Arm (ou un cluster de coeurs) comme moteur général, puis ajoutent des blocs spécialisés qui définissent le produit :
Le résultat est une puce qui exécute des OS, compilateurs et middleware familiers, tout en se distinguant sur la performance‑par‑watt, les fonctionnalités ou la liste de matériaux.
Même lorsque deux fournisseurs licencient une IP CPU similaire, ils peuvent diverger via l'intégration SoC : contrôleurs mémoire, tailles de cache, gestion d'énergie, blocs ISP/caméra, DSP audio et façon dont tout est connecté sur la puce.
Ces choix impactent le comportement réel — autonomie, latence, thermique et coût — souvent plus qu'une petite différence de vitesse CPU.
Pour les fabricants de téléphones, marques d'appareils et OEM industriels, une base logicielle Arm partagée réduit le verrouillage. Ils peuvent changer de fournisseur (ou sourcer en double) tout en conservant une grande partie du même OS, apps, pilotes et outils — évitant de « réécrire le produit » si l'approvisionnement, les prix ou la performance changent.
Les partenaires différencient aussi en fournissant designs de référence, piles logicielles validées et conceptions de cartes éprouvées. Cela réduit le risque pour les OEM, accélère les travaux réglementaires et de fiabilité, et compresse le time‑to‑market — parfois plus décisif qu'un score de benchmark légèrement supérieur.
Arm grandit en livrant des plans de conception (IP CPU), tandis que les fonderies grandissent en livrant de la capacité physique (wafers). Les deux permettent beaucoup de puces, mais ils créent de la valeur de manières différentes.
Une puce moderne passe typiquement par quatre acteurs distincts :
L'échelle d'Arm est horizontale : une fondation CPU peut servir de nombreux concepteurs de puces, dans de nombreuses catégories de produits.
Parce qu'Arm ne fabrique pas, ses partenaires ne sont pas liés à une stratégie manufacturière unique. Un concepteur de puce peut choisir une fonderie et un procédé adaptés au travail — en équilibrant coût, consommation, disponibilité, options de packaging et calendrier — sans que le fournisseur d'IP doive « retoucher » une usine.
Cette séparation encourage aussi l'expérimentation. Les partenaires peuvent cibler des points de prix ou des marchés différents tout en s'appuyant sur une même base CPU.
L'échelle d'une fonderie est contrainte par la construction physique et des cycles de planification longs. Si la demande change, ajouter de la capacité n'est pas instantané.
L'échelle d'une IP est différente : une fois qu'une conception CPU existe, de nombreux partenaires peuvent l'implémenter et fabriquer où cela a du sens. Les concepteurs peuvent parfois déplacer la production entre fonderies (selon les choix de design et accords) plutôt que d'être liés à une feuille de route d'usine. Cette flexibilité aide à gérer le risque d'approvisionnement lorsque les conditions manufacturières évoluent.
Arm gagne de l'argent principalement de deux façons : frais de licence initiaux et royalties récurrentes.
Une entreprise paie Arm pour le droit d'utiliser des conceptions CPU (ou des parties d'entre elles) dans une puce. Ce paiement couvre le travail qu'Arm a déjà fait : concevoir le coeur, le valider, le documenter et le rendre utilisable par de nombreuses équipes de conception.
Pensez‑y comme payer pour un design de moteur éprouvé avant de commencer à construire des voitures.
Une fois que les puces sont intégrées dans des produits réels — téléphones, routeurs, capteurs, appareils — Arm peut recevoir un petit montant par puce (ou par appareil, selon l'accord). C'est là que le modèle s'amplifie : si le produit d'un partenaire devient populaire, Arm en profite aussi.
Les royalties alignent aussi les incitations de façon pratique :
Les royalties récompensent l'adoption large, pas seulement un gros contrat ponctuel. Cela pousse Arm à investir dans les éléments peu glamour qui facilitent l'adoption — compatibilité, designs de référence et support sur le long terme.
Si les clients savent que le logiciel et les outils continueront de fonctionner sur plusieurs générations de puces, ils peuvent planifier leurs feuilles de route avec moins de risques. Cette prévisibilité réduit les coûts de portage, raccourcit les cycles de tests et facilite le support des produits sur des années — en particulier dans l'embarqué.
Un diagramme simple pourrait montrer :
Arm → (licence) → Concepteur de puce → (puces) → Fabricant d'appareils → (appareils vendus) → Royalties retournent vers Arm
Un écosystème piloté par la licence peut évoluer plus vite qu'une entreprise qui construit chaque puce elle‑même — mais cela implique aussi renoncer à un certain contrôle. Quand votre technologie devient une fondation utilisée par de nombreux partenaires, votre succès dépend de leur exécution, de leurs décisions produits et de la façon dont la plateforme se comporte dans le monde réel.
Arm n'expédie pas le téléphone final ni le microcontrôleur final. Les partenaires choisissent nœuds de procédé, tailles de cache, contrôleurs mémoire, fonctionnalités de sécurité et schémas de gestion d'énergie. Cette liberté est voulue — mais elle peut rendre la qualité et l'expérience utilisateur inégales.
Si un appareil est lent, surchauffe ou a une autonomie médiocre, les utilisateurs blâment rarement un « coeur » spécifique. Ils blâment le produit. À la longue, des résultats inconsistants peuvent diluer la valeur perçue de l'IP sous‑jacente.
Plus les partenaires personnalisent, plus l'écosystème risque de dériver vers des implémentations « semblables‑mais‑différentes ». La portabilité logicielle tient généralement, mais les développeurs peuvent tomber sur des cas limites :
La fragmentation apparaît souvent non pas au niveau du jeu d'instructions mais dans les pilotes, le comportement firmware et les fonctionnalités plateforme entourant le CPU.
Un modèle d'écosystème affronte deux fronts : architectures alternatives et conceptions internes des partenaires. Si un grand client décide de concevoir son propre coeur CPU, le volume de licences peut chuter rapidement. De même, des concurrents crédibles peuvent attirer des projets en proposant des prix plus simples, une intégration plus étroite ou une voie plus rapide vers la différenciation.
Les partenaires misent des années de planning sur une plateforme stable. Des feuilles de route claires, des termes de licence prévisibles et des règles de compatibilité constantes sont essentiels. La confiance dépend aussi d'une bonne gouvernance : les partenaires veulent la certitude que le propriétaire de la plateforme ne changera pas de direction de manière inattendue, ne restreindra pas l'accès ou n'entravera pas leur capacité à se différencier.
L'histoire d'Arm rappelle que l'échelle ne signifie pas toujours « posséder plus d'usines ». Cela peut vouloir dire faciliter la construction par beaucoup d'autres d'appareils compatibles qui restent compétitifs chacun à leur façon.
D'abord, standardisez la couche qui génère le plus de réutilisation. Pour Arm, c'est l'architecture d'instructions et l'IP coeur — assez stable pour attirer logiciels et outils, mais évolutive par étapes contrôlées.
Ensuite, faites en sorte que l'adoption soit moins coûteuse que le changement. Des conditions claires, des feuilles de route prévisibles et une documentation solide réduisent la friction pour les nouveaux partenaires.
Troisièmement, investissez tôt dans les éléments « ennuyeux » : compilateurs, débogueurs, designs de référence et programmes de validation. Ce sont les multiplicateurs cachés qui transforment une spécification technique en plateforme utilisable.
Quatrièmement, laissez les partenaires se différencier au‑dessus de la fondation partagée. Quand la base est compatible, la concurrence se déplace vers l'intégration, l'efficacité énergétique, la sécurité, le packaging et le prix — des domaines où beaucoup d'entreprises peuvent gagner.
Une analogie logicielle utile : Koder.ai applique une leçon de plateforme similaire au développement d'applications. En standardisant la « couche fondation » (un workflow piloté par chat soutenu par des LLMs et une architecture d'agents) tout en permettant aux équipes d'exporter le code source, déployer/héberger, utiliser des domaines personnalisés et revenir via des snapshots, elle réduit le coût plateforme d'expédition d'apps web/mobile/backend — comme Arm réduit le coût plateforme de construire des puces sur une ISA partagée.
La licence et la construction d'écosystème sont souvent le meilleur pari quand :
L'intégration verticale est souvent plus forte quand vous avez besoin d'un contrôle serré sur l'approvisionnement, le rendement ou une expérience matériel/logiciel très couplée.
Si vous réfléchissez à une stratégie de plateforme — APIs, SDKs, programmes partenaires ou modèles de tarification — parcourez d'autres exemples dans /blog.
La compatibilité est puissante, mais elle n'est pas automatique. Elle se gagne par des décisions cohérentes, un versioning soigné et un support continu — sinon l'écosystème se fragmente et l'avantage disparaît.
Arm licence généralement la propriété intellectuelle (IP) des CPU—soit l'architecture du jeu d'instructions (ISA), soit un coeur CPU prêt à être intégré, ou les deux. La licence vous donne des droits légaux et des livrables techniques (comme le RTL et la documentation) pour que vous puissiez concevoir votre propre puce autour de cette IP.
L'ISA est le contrat logiciel/matériel : le « langage » des instructions que le CPU comprend. Un coeur CPU est une implémentation concrète de cette ISA (la microarchitecture). Un SoC (system-on-chip) est le produit complet qui inclut des coeurs CPU plus le GPU, contrôleurs mémoire, E/S, radios, blocs de sécurité, etc.
Une licence de coeur vous permet d'intégrer un coeur CPU conçu par Arm dans votre SoC. Vous vous chargez surtout de l'intégration, de la vérification et de la conception système autour d'un bloc CPU éprouvé.
Une licence d'architecture vous autorise à concevoir votre propre coeur CPU qui implémente l'ISA Arm : il reste compatible Arm tout en vous laissant plus de contrôle sur les choix microarchitecturaux.
Les livrables courants incluent :
Parce que l'IP CPU est réutilisable : une fois qu'un coeur est validé, de nombreux partenaires peuvent l'intégrer en parallèle dans des produits différents. Cette réutilisation réduit le risque (moins de surprises tardives), accélère les plannings et permet à chaque partenaire de se concentrer sur ce qui le différencie (gestion d'énergie, caches, accélérateurs personnalisés, etc.).
L'avantage manufacturier aide le coût unitaire et parfois la performance, mais il est cher, cyclique et difficile à appliquer à tous les segments.
La compatibilité d'écosystème réduit le coût total du produit (temps d'ingénierie, portage, outils, maintenance) car logiciels, compétences et composants tiers se transfèrent entre produits. Sur plusieurs générations, ce « coût de réécriture » devient souvent déterminant.
Les appareils mobiles sont limités par la consommation et le thermique : la performance soutenue importe plus que les pics brefs. Le modèle Arm a aussi permis la concurrence sans chaos logiciel : plusieurs fournisseurs pouvaient livrer des puces différentes (GPU/modem/NPU, stratégies d'intégration) tout en gardant une base CPU/logicielle compatible.
Les produits embarqués ont souvent des cycles de vie longs (années) et nécessitent maintenance, correctifs de sécurité et continuité d'approvisionnement.\n\nUne base CPU/logicielle stable aide les équipes à :
C'est précieux quand il faut supporter des appareils longtemps après leur mise sur le marché.
Un outillage mature réduit le « coût plateforme ». Pour les cibles Arm, les équipes peuvent en général s'appuyer sur des compilateurs établis (GCC/Clang), des débogueurs (GDB/intégrations IDE), des profileurs et des OS supportés (Linux/Android/RTOS). Cela permet une mise au point plus rapide, moins de surprises liées aux toolchains, et des itérations plus rapides même avant d'avoir le silicium final.
Typiquement deux sources de revenus :
Les royalties récompensent l'adoption large et incitent Arm à maintenir la compatibilité, la documentation et le support à long terme.\n\nPour un détail ciblé, voir /blog/the-licensing-economics-plain-english-version.
Vous n'obtenez généralement pas une puce fabriquée : la fabrication est gérée par le licencié et le fonderie qu'il choisit.
