OpenHarmony est-il un choix viable comme OS embarqué pour vos équipements ? ── Comparaison avec Windows IoT et Linux embarqué

Dans notre précédent article, « Qu’est-ce qu’OpenHarmony ? », nous avons distingué trois réalités bien distinctes : OpenHarmony, HarmonyOS et HarmonyOS NEXT. Il est maintenant temps de passer à la pratique. OpenHarmony est-il réellement un choix viable comme OS embarqué sur un équipement ?

Pour un fabricant d’équipements, certains éléments du choix d’un OS se décident avant même toute comparaison fonctionnelle. On ne peut pas installer un OS maintenu seulement 2 ans sur un équipement destiné à fonctionner 10 ans. Si vous utilisez une caméra dont le SDK fournisseur n’existe que pour Windows, cet OS est d’emblée hors course. Cet article compare, du point de vue de l’échelle de temps de l’équipement et de l’approvisionnement, Windows IoT Enterprise LTSC, le Linux embarqué (basé sur Debian ou Yocto) et OpenHarmony, et résume dans un tableau de décision les conditions qui justifient l’adoption et celles qui doivent la faire écarter.

Précisons que cet article n’est ni « un plaidoyer pour OpenHarmony » ni « une mise en garde à l’éviter ». Nous travaillons habituellement sur des logiciels d’équipement Windows, mais nous avons observé à de nombreuses reprises des décisions prises sans véritable comparaison des options, uniquement parce qu’une technologie est « nouvelle » ou « d’origine chinoise ». L’objectif ici est de rassembler des éléments de décision.

1. La conclusion, d’abord

• La durée de maintenance est le principal point de bascule. La branche Release de la communauté OpenHarmony dure 2 ans (1 an de maintenance active + 1 an de maintenance passive), et même la branche LTS ne dépasse pas 3,5 ans (2 ans + 1,5 an). Ce n’est pas la même donne que les 10 ans de Windows 11 IoT Enterprise LTSC 2024.¹²
• De plus, aucune branche LTS n’a été ouverte ces dernières années. Des LTS sont sorties au début (1.1.0 LTS, 3.0-LTS), mais dans le tableau officiel de calendrier de maintenance, la dernière LTS reste 3.0-LTS, datant de septembre 2021. Toutes les branches publiées depuis 3.1 sont de type Release.³⁴
• La version communautaire ne peut donc pas être installée telle quelle sur un produit. Pour l’adopter, il faut soit acheter la maintenance vendeur d’une distribution commerciale, soit disposer en interne d’une équipe qui maintienne sa propre branche jusqu’à la gestion des CVE. Huawei explique qu’« OpenHarmony a donné lieu à plus de 100 versions commerciales », et c’est cette couche commerciale qui constitue la véritable filière d’adoption.⁵
• La limite basse en ressources d’OpenHarmony est écrasante. Le système léger fonctionne à partir de 128 KiB de MCU au minimum. Windows 11 IoT Enterprise LTSC exige au minimum 2 Go de mémoire et 16 Go de stockage pour les appareils à usage spécifique — les deux OS ne jouent tout simplement pas dans la même cour.⁶⁷
• Les actifs logiciels Windows existants ne sont pas réutilisables. Il n’existe pas d’environnement d’exécution correspondant à C#/.NET, Win32, COM ou WPF/WinForms ; l’interface passe par ArkTS + ArkUI, les pilotes par HDF — un tout autre système. Ce n’est pas un portage, c’est une reconstruction.
• Le véritable goulet d’étranglement, ce sont les SDK des fournisseurs. La plupart des SDK de caméras industrielles, de contrôleurs de mouvement et de bibliothèques de communication PLC ne sont proposés que pour Windows, éventuellement pour Linux. La disponibilité d’un pilote pour OpenHarmony est un point à vérifier avant même de comparer les OS.
• Il n’existe quasiment aucune information ni support de premier niveau en japonais. La documentation officielle n’existe qu’en chinois et en anglais, sans version japonaise.⁸ Disposer de personnel capable de lire une documentation technique en chinois ou en anglais est, en pratique, une condition préalable.
• Certains usages lui conviennent clairement. Les produits destinés au marché chinois, les appareils dont la valeur produit repose sur la mise en réseau de plusieurs équipements (DSoftBus), les appareils IoT à écran souhaitant utiliser l’interface ArkUI, ou les gammes voulant couvrir du MCU jusqu’aux appareils riches dans un même système.⁹

Voici d’abord, en un seul tableau, l’évaluation d’ensemble par axe et par option. C’est un résumé de ce que traite chaque chapitre suivant. Les symboles suivent une échelle à 4 niveaux : ◎ = convient tel quel / ○ = convient sous conditions / △ = attention requise / × = ne convient pas.

Comme on le voit, OpenHarmony obtient ◎ sur deux axes seulement : la limite basse en ressources et la mise en réseau d’équipements, tandis que les trois axes actifs existants / SDK / information en japonais sont notés ×. Cette configuration ne traduit pas une « supériorité ou infériorité » mais le fait que les conditions de compatibilité sont restreintes. Le tableau de décision du chapitre 8 détaille, cas par cas, quelles conditions correspondent.

2. Aligner les termes de la comparaison ── que compare-t-on exactement ?

Avant de commencer la comparaison, clarifions les objets en jeu. Le mot « OS » recouvre des couches différentes selon les cas, et les mélanger fausse la discussion.

Deux termes du tableau méritent une précision. Yocto n’est pas un OS fini, mais un cadre qui combine des recettes (des définitions de procédures de build) pour construire une distribution Linux propre à votre produit. LTSC (Long-Term Servicing Channel) est un mode de diffusion de Windows qui fournit uniquement des mises à jour de sécurité sur une longue période, sans mise à jour fonctionnelle — une option adaptée aux usages où l’on veut figer la configuration, comme un équipement.

Le point essentiel à retenir ici est qu’OpenHarmony n’est pas un « produit fini que l’on achète et installe » comme Windows IoT. Sa position se rapproche davantage de Yocto : un cadre à partir duquel on construit la configuration de son propre produit. Contrairement à Yocto toutefois, le framework d’UI et le modèle d’application sont déjà déterminés d’un seul bloc, ce qui l’empile plus haut.

Les définitions des types de système d’OpenHarmony sont les suivantes.⁶

Dans le contexte de l’intégration sur équipement, les cibles de comparaison sont surtout le système standard (équipement avec IHM) et le système léger (nœuds de capteurs, modules de communication). Le système compact se positionne plutôt du côté des produits de type caméra.

3. Comparaison des durées de support ── laquelle correspond à l’échelle de temps de l’équipement ?

Les PC ou cartes intégrés à un équipement doivent fonctionner pendant un cycle de vie similaire à celui de l’équipement lui-même, de l’ordre de 10 ans. Sous cet angle, les écarts entre options sont flagrants.

Ce tableau s’appuie sur les informations officielles de juillet 2026. Comme les durées de support et les dates de fin sont révisées, vérifiez toujours les sources primaires juste avant de prendre une décision d’adoption. Voici où vérifier :

• OpenHarmony : Version Lifecycle Management (politique de gestion du cycle de vie) et Version Definitions (types de branches et tableau de calendrier de maintenance)¹³
• Windows : Microsoft Lifecycle (cycle de vie par produit)²
• Debian : Debian Wiki LTS¹⁰
• Yocto Project : Releases¹¹

Notamment pour OpenHarmony, comme indiqué plus loin, les branches 5.x et 6.x ne figurent pas encore dans le tableau de calendrier de maintenance. Si vous envisagez une version qui n’apparaît pas dans ce tableau, considérez que sa durée n’est pas encore fixée.

Deux points méritent une lecture plus approfondie.

Premièrement, la « maintenance passive » d’OpenHarmony réduit la qualité du support. Selon la politique officielle de gestion du cycle de vie, la période de maintenance active voit la communauté publier des versions taguées de manière planifiée pour corriger bugs et vulnérabilités de sécurité, tandis que la période de maintenance passive n’inclut plus de planification ni de publication de versions taguées : seules les vulnérabilités de sécurité graves ou critiques et les bugs majeurs sont corrigés.¹ Autrement dit, la période « réellement utilisable en confiance » doit être considérée comme égale à 1 an pour la branche Release et 2 ans pour la LTS.

Deuxièmement, aucune branche LTS n’a été ouverte ces dernières années. La dernière LTS figurant au tableau officiel de calendrier de maintenance est 3.0-LTS (septembre 2021) ; 3.1, 3.2, 4.0 et 4.1 sont tous de type Release.³ Des LTS existaient bien avant cela — l’index des notes de version conserve 1.1.0 LTS (avril 2021) et sa lignée — mais toutes sont désormais en fin de vie.⁴ De plus, les branches 5.x et 6.x ne figurent pas encore dans ce tableau de calendrier de maintenance. Dans la perspective d’un cycle de vie d’équipement de 10 ans, cela signifie que l’on ne peut pas savoir à l’avance, version après version, quelle durée de maintenance sera attachée à quelle branche.

À l’inverse, Windows 11 IoT Enterprise LTSC 2024 suit une politique de cycle de vie fixe, avec une date de fin déterminée dès le départ : le 10 octobre 2034.² Debian publie également le support standard et la période LTS de chaque version, et le Yocto Project indique explicitement que les versions LTS sont supportées 4 ans.¹⁰¹¹

Il ne s’agit pas ici de dire qu’OpenHarmony est de moindre qualité. Ce modèle de maintenance ne prévoit simplement pas l’usage consistant à « installer la version communautaire telle quelle sur un produit et la laisser telle quelle ». Dans l’adoption industrielle réelle, les fournisseurs de distributions commerciales maintiennent eux-mêmes leurs propres branches et proposent cette maintenance à titre payant. Au moment de l’adoption, la question à poser n’est pas « combien de temps OpenHarmony est-il supporté ? » mais « quelle branche cette distribution maintient-elle, jusqu’à quand, et selon quel SLA ? »

4. Les options matérielles

La communauté annonce la prise en charge de 22 cartes de développement.¹³ En extrayant celles pertinentes pour les équipements :

Il est important de noter que les fournisseurs de SoC ne sont pas exclusivement chinois. La présence du NXP i.MX8M Mini et de la gamme STM32 de ST dans la liste de compatibilité a une portée concrète pour les fabricants d’équipements japonais : il devient possible d’étudier ces options à partir de familles de SoC déjà utilisées.

Les points de vigilance sont toutefois tout aussi importants.

• La liste des cartes compatibles et les cartes industrielles réellement disponibles sont deux choses différentes. Ce qui figure ici est surtout des cartes d’évaluation ; il faut vérifier séparément si OpenHarmony est officiellement pris en charge sur une carte industrielle garantie sur 10 ans d’approvisionnement. La colonne « usage prévu » du tableau reflète le positionnement documentaire, et ne constitue ni une garantie d’approvisionnement ni une confirmation de distribution au Japon.
• La disponibilité doit être vérifiée individuellement depuis le Japon. Les cartes de cette liste ciblent surtout le marché chinois et ne sont pas forcément disponibles chez un distributeur national. Avant de commander une carte d’évaluation, vérifiez par une demande directe : (1) la page de vente du fabricant de la carte et sa disponibilité sur les places de marché transfrontalières, (2) la présence d’un distributeur national, (3) le lot minimum de production en série et la durée d’approvisionnement garantie. Si ce point bloque, toute la suite de la validation technique s’arrête net.
• Si vous l’installez sur votre propre matériel, le portage devient un travail interne. Là où Windows IoT permet de « acheter une licence via un distributeur OEM et laisser le fournisseur livrer les pilotes », OpenHarmony implique un travail effectué en interne ou par le distributeur.
• Le traitement des pilotes dépend du niveau où on les utilise. OpenHarmony dispose d’un socle de pilotes unifié appelé HDF (Hardware Driver Foundation), conçu indépendamment de la plateforme et du noyau, et applicable à tous les types de système.⁹ Cependant, comme le noyau du système standard est Linux, il reste possible d’intégrer tel quel un pilote de noyau Linux existant et de l’utiliser via les interfaces Linux classiques comme V4L2 ou les périphériques d’entrée. Le travail d’adaptation devient nécessaire seulement si vous voulez exposer ce périphérique aux services système et frameworks d’OpenHarmony via HDI. Si vous disposez déjà d’un BSP Linux, il n’est pas nécessaire d’estimer « réécrire tous les pilotes en HDF ». Décidez d’abord quels périphériques doivent être exposés au framework d’OpenHarmony, et ne budgétez que cette portion.

Notez que la validation peut commencer même pendant que l’approvisionnement des cartes est en suspens. Le chapitre 9 propose une procédure pour vérifier la structure et le déroulement du démarrage sous QEMU avant d’acheter du matériel réel. Et si le SoC de votre propre carte est déjà déterminé, il peut être plus pertinent d’estimer directement l’effort de portage vers ce SoC plutôt que de chercher une carte d’évaluation.

5. Environnement de développement et langages ── les actifs existants sont-ils réutilisables ?

Du point de vue des actifs logiciels d’équipement, la situation est simple. Un logiciel d’équipement écrit pour Windows n’est pas réutilisable sur OpenHarmony. Ni C#/.NET, ni Win32, ni COM, ni WPF n’ont d’environnement d’exécution correspondant. Il faudra réécrire l’interface en ArkTS et ArkUI, et les couches basses en C/C++.

L’obstacle le plus concret est l’état de prise en charge des SDK fournisseurs. SDK de caméras industrielles, bibliothèques de contrôleurs de mouvement, middleware de communication PLC, bibliothèques de traitement d’image — dans la réalité, la plupart de ces éléments sont d’abord disponibles pour Windows, parfois pour Linux si vous avez de la chance. Une prise en charge pour OpenHarmony n’est guère à espérer. Par conséquent,

Avant de comparer les OS, dressez la liste des périphériques et middlewares dont l’équipement a besoin, et vérifiez pour chacun l’état de la prise en charge OpenHarmony.

Discuter en se fondant uniquement sur un tableau comparatif d’OS sans faire cet exercice mène toujours à un échec en aval. Lorsque nous recevons une consultation sur un logiciel d’équipement, nous commençons systématiquement par établir cette liste.

L’environnement de développement propose deux points d’entrée : le GUI DevEco Device Tool (édition, débogage et flashage du code sous Windows, compilation sous Ubuntu — une configuration hybride) et la procédure en ligne de commande.¹⁴ La récupération du code source se fait avec l’outil repo, avec des miroirs indiqués sur gitcode.com, gitee.com et GitHub.¹⁵

6. Licence et propriété intellectuelle

OpenHarmony n’est pas régi par une licence unique. Il faut vérifier périmètre par périmètre.

Résumer la situation en disant « OpenHarmony est sous Apache 2.0, donc pas de souci » revient à négliger les obligations GPL de la partie noyau du système standard. La règle est de lister les dépôts inclus dans le périmètre de l’équipement et de vérifier chaque fichier LICENSE un par un. C’est là une différence pratique par rapport à Windows IoT (une licence commerciale unique suffit).

Une précision sur la GPLv2 s’impose. L’obligation naît au moment de la distribution, pas au moment de la modification. Modifier le noyau et le faire fonctionner uniquement sur une machine de test interne ne crée pas d’obligation de mise à disposition ; c’est au moment où l’équipement est livré au client que naît l’obligation de fournir au destinataire le code source correspondant au binaire distribué. Pour un fabricant d’équipements, « livraison = distribution », donc une réponse finira par être nécessaire dans tous les cas, mais il est utile de garder cette distinction en tête : l’obligation de divulgation n’existe pas dès le stade du prototypage interne (pour les modalités précises de conformité, consultez votre service juridique et propriété intellectuelle).

7. Certification et participation à l’écosystème

Pour qu’un produit revendique publiquement une « compatibilité OpenHarmony », il doit passer l’évaluation de compatibilité de la fondation OpenAtom. Le socle technique est XTS (X Test Suite) d’OpenHarmony ; la documentation officielle explique qu’il « fournit une série de suites de tests de compatibilité OpenHarmony, comprenant l’ACTS (suite de tests de compatibilité applicative), actuellement prise en charge, et la DCTS (suite de tests de compatibilité des dispositifs), prise en charge dans le futur ».⁹ Autrement dit, selon la documentation officielle (à juillet 2026), seule l’ACTS est actuellement fournie, la DCTS étant prévue pour plus tard.

De son côté, la documentation communautaire sur la procédure de certification décrit XTS comme un ensemble en trois parties, ACTS, HATS (compatibilité de la couche d’abstraction matérielle) et DCTS — ce qui diverge de la documentation officielle.¹⁹ Le déroulement lui-même, où le demandeur effectue son propre développement de conformité et son autotest avant de soumettre un rapport de test, reste commun.

Lors de l’estimation de la charge de travail, ne présumez pas que la DCTS est une exigence obligatoire. Vérifiez directement auprès du guichet de certification quelles suites sont réellement exigées au moment de la demande. Ce genre de situation où « la documentation officielle et la documentation communautaire ne concordent pas », combinée à l’absence d’information de première main en japonais, doit être anticipée comme un coût de communication lors de l’adoption.

Pour un usage limité à la validation interne ou à un équipement ponctuel, la certification n’est pas nécessaire, mais elle devient incontournable pour tout produit revendiquant publiquement une compatibilité, ou souhaitant être traité comme membre de l’écosystème. C’est un poste à budgéter dès le départ.

8. Tableau de décision ── conditions justifiant l’adoption, conditions imposant d’y renoncer

Avant d’aborder le tableau de décision, résumons en une image le déroulement qui y mène. L’ordre de vérification des prérequis compte : les exigences de marché et de produit d’abord, l’examen technique ensuite. Même si c’est techniquement réalisable, si la maintenance ne peut pas être figée par contrat, cela ne peut pas être installé sur un équipement.

flowchart TD
    S["Choisir l'OS à installer sur l'équipement"]
    Q1["Produit destiné au marché chinois, ou<br/>exigence de compatibilité OpenHarmony"]
    Q2["La mise en réseau de plusieurs équipements (DSoftBus)<br/>est-elle au cœur de la valeur produit ?"]
    Q3["Les SDK fournisseurs pour les périphériques et middlewares<br/>sont-ils disponibles sous OpenHarmony<br/>(ou peut-on les développer en interne pour le reste) ?"]
    Q4["La maintenance peut-elle être figée par contrat<br/>(fournisseur de distribution commerciale,<br/>ou dispositif interne jusqu'à la gestion des CVE) ?"]
    Q5["Dispose-t-on de personnel capable de lire<br/>une documentation technique en chinois ou en anglais ?"]
    OH["Étudier OpenHarmony sérieusement<br/>Approvisionnement via une distribution commerciale"]
    OTH["Windows IoT LTSC ou Linux embarqué<br/>Décision selon les actifs existants et les SDK fournisseurs"]
    NG["Renoncer à OpenHarmony"]

    S --> Q1
    Q1 -->|"Oui"| Q3
    Q1 -->|"Non"| Q2
    Q2 -->|"Oui"| Q3
    Q2 -->|"Non"| OTH
    Q3 -->|"Disponible / développable en interne"| Q4
    Q3 -->|"Non disponible"| NG
    Q4 -->|"Peut être figée"| Q5
    Q4 -->|"Ne peut pas être figée"| NG
    Q5 -->|"Oui"| OH
    Q5 -->|"Non"| NG
    NG --> OTH

Figure 1 : Arbre de décision pour l’adoption d’OpenHarmony. Le fondement de chaque bifurcation correspond aux lignes du tableau de décision ci-dessous

Le principal argument de cet article est que, parmi ces bifurcations, ce sont Q3 (SDK fournisseurs) et Q4 (contrat de maintenance) qui font échouer la plupart des dossiers en pratique. Le tableau de décision ci-dessous décline chaque bifurcation de ce schéma en situations concrètes.

9. Si l’adoption est retenue, que faire en premier ?

Si le tableau de décision penche vers l’adoption, voici l’ordre d’attaque à suivre.

1. Inventaire des périphériques et middlewares. Caméras, E/S, communication, mouvement, traitement d’image — vérifiez pour chaque fournisseur la disponibilité pour OpenHarmony. Si cela bloque ici, poursuivre les autres étapes n’a pas de sens.
2. Fixer le type de système. Décidez si vous construisez en léger, compact ou standard. Cela détermine à la fois le noyau (LiteOS-M / LiteOS-A / Linux) et la manière d’écrire les applications.
3. Vérification de la structure sous QEMU. Avant d’acheter une carte réelle, vous pouvez vérifier le déroulement de la compilation et du démarrage grâce aux environnements d’émulation fournis par device_qemu : Arm Virt (LiteOS-A / Linux), Cortex-M4, Cortex-M55, RISC-V, etc.²⁰
4. Figer la branche de maintenance et assurer la reproductibilité du build. Figez le manifeste de repo (indiquer un tag est la méthode la plus sûre), maintenez un miroir interne, et assurez-vous de pouvoir reconstruire le même binaire dans cinq ans.¹⁵ Le fait que l’hébergement amont soit centré sur gitcode.com est aussi, du point de vue de la continuité d’activité, une raison de maintenir votre propre miroir.
5. Inventaire des licences. Listez les dépôts inclus dans le périmètre, et organisez les obligations liées à Apache 2.0 / BSD / GPL.
6. Négociation du contrat de maintenance. Fixez par contrat, avec le fournisseur de la distribution commerciale, quelle branche est maintenue, jusqu’à quand et selon quel SLA. Si ce point n’est pas fixé, il faut suspendre la décision d’adoption.
7. Décision sur la nécessité de la certification (XTS). Si la compatibilité doit être revendiquée publiquement, budgétez-le dès le départ.

10. Conclusion

• OpenHarmony repose sur une conception techniquement cohérente : il couvre, dans un système unique, du MCU à 128 KiB jusqu’aux appareils riches de plus de 128 MiB, et embarque en standard la mise en réseau d’équipements (DSoftBus). Des cartes compatibles orientées usage industriel existent, incluant des SoC de NXP et de ST.
• En revanche, du point de vue du cycle de vie de 10 ans d’un équipement, la durée de maintenance communautaire (2 ans en Release, 3,5 ans en LTS) est clairement insuffisante. De plus, aucune branche LTS n’a été ouverte depuis 3.0-LTS en 2021. Adopter OpenHarmony suppose de s’appuyer sur la maintenance vendeur d’une distribution commerciale.
• Pour un fabricant d’équipements japonais, la condition d’adoption effective se résume à trois points. (1) Les SDK fournisseurs sont-ils compatibles avec OpenHarmony ? (2) Dispose-t-on de personnel capable de lire une documentation technique en chinois ou en anglais ? (3) Existe-t-il un fournisseur capable de figer la maintenance par contrat ? S’il manque un seul de ces trois éléments, Windows IoT Enterprise LTSC ou un Linux embarqué avec support commercial correspondra mieux à l’échelle de temps de l’équipement.
• À l’inverse, pour un produit destiné au marché chinois, un produit dont la mise en réseau d’équipements est au cœur de la valeur, ou une gamme voulant couvrir du MCU jusqu’au haut de gamme dans un système unique, cela mérite une étude sérieuse.

Le choix d’un OS n’est pas une question de « lequel est supérieur », mais de « lequel correspond le mieux à l’échelle de temps de l’équipement, à l’approvisionnement et au personnel disponible ». Les critères de choix côté Windows sont détaillés dans « Quelle version de Windows installer sur un PC industriel ? ».

Articles connexes

• Qu’est-ce qu’OpenHarmony ? ── Les différences avec HarmonyOS et HarmonyOS NEXT
• Quelle version de Windows installer sur un PC industriel ? ── Guide pratique Windows IoT Enterprise / LTSC
• La réponse concrète après la fin de support de Windows 10
• Guide pratique du mode kiosque Windows (Assigned Access)

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) accompagne le choix des socles d’exécution embarqués sur équipement, l’analyse de faisabilité de migration des logiciels d’équipement Windows existants, et la revue de configurations conçues pour un fonctionnement à long terme. N’hésitez pas à nous consulter même au stade où « un nouvel OS est envisagé, mais nous n’avons pas de quoi le comparer en interne ».

• Conseil technique et revue de conception
• Développement d’applications Windows temps réel souple
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Peut-on adopter OpenHarmony comme OS pour un équipement industriel sans risque ?

Cela dépend des conditions. Le facteur décisif est la gestion de la durée de maintenance : le cycle de vie des branches Release de la communauté OpenHarmony est de 2 ans (1 an de maintenance active + 1 an de maintenance passive), et même la branche LTS ne dépasse pas 3,5 ans. Si vous installez tel quel la version communautaire sur un équipement destiné à fonctionner 10 ans, les correctifs de sécurité s'arrêteront en cours de vie du produit. Pour l'adopter, il faut soit acheter la maintenance vendeur d'une distribution commerciale, soit disposer en interne d'une équipe capable de maintenir sa propre branche jusqu'à la gestion des CVE. Si vous ne pouvez pas mettre en place ce dispositif, Windows IoT Enterprise LTSC (10 ans) ou un contrat de support long terme sur du Linux embarqué commercial correspondra mieux à l'échelle de temps de l'équipement.

Entre OpenHarmony et le Linux embarqué, lequel est le plus léger ?

La limite basse d'OpenHarmony est plus faible. Le système léger d'OpenHarmony fonctionne à partir de 128 KiB de mémoire minimum sur des MCU Arm Cortex-M ou RISC-V 32 bits, le système compact à partir de 1 MiB, et le système standard à partir de 128 MiB. Le Linux embarqué classique suppose un processeur avec MMU et plusieurs dizaines de Mo de RAM au minimum, si bien qu'être capable de couvrir jusqu'au domaine des MCU avec le même système d'exploitation est une caractéristique propre à OpenHarmony. Attention toutefois : le noyau du système léger est LiteOS-M, dont l'environnement d'exécution est totalement différent de celui du Linux du système standard — ce n'est pas parce que c'est « le même OS » que « la même application y fonctionne ».

Peut-on porter un logiciel d'équipement Windows existant vers OpenHarmony ?

En pratique, cela revient à tout reconstruire. Un logiciel d'équipement écrit en C#/.NET, Win32, COM, WPF/WinForms n'a pas d'environnement d'exécution correspondant sur OpenHarmony. L'interface utilisateur devra être réécrite en ArkTS + ArkUI, les couches basses en C/C++, et les pilotes dans un tout autre système appelé HDF (Hardware Driver Foundation). De plus, les SDK des fournisseurs de caméras industrielles ou de contrôleurs de mouvement ne sont souvent proposés que pour Windows (et éventuellement Linux) — c'est là le véritable goulet d'étranglement du portage. Si vous voulez réutiliser vos actifs existants, il est plus réaliste de migrer vers Windows IoT Enterprise LTSC, ou de vous limiter à du Linux embarqué sur des périphériques pour lesquels un SDK Linux est disponible.

Faut-il une certification pour se prévaloir d'une compatibilité OpenHarmony ?

Pour qu'un produit puisse revendiquer une « compatibilité OpenHarmony », il doit passer l'évaluation (certification) de compatibilité de la fondation OpenAtom. Le socle technique est la suite de tests XTS (X Test Suite) d'OpenHarmony. Les sources divergent toutefois sur son contenu exact : à juillet 2026, la documentation officielle mentionne « l'ACTS (suite de tests de compatibilité applicative), actuellement prise en charge, et la DCTS (suite de tests de compatibilité des dispositifs), prévue pour le futur ». De son côté, la documentation communautaire sur la procédure de certification décrit un ensemble en trois parties incluant en plus HATS (compatibilité de la couche d'abstraction matérielle). Lors de l'estimation de la charge de travail, ne considérez pas la DCTS comme une exigence acquise d'office — vérifiez directement auprès du guichet de certification quelles suites sont réellement exigées au moment de la demande. Pour un usage purement interne de vérification, la certification n'est pas nécessaire, mais elle le devient pour tout produit revendiquant publiquement une compatibilité.

Quel est le niveau de support et d'information en japonais ?

La documentation officielle n'existe qu'en chinois et en anglais, sans version japonaise. Les discussions communautaires se déroulent aussi majoritairement en chinois. Les fournisseurs de distributions commerciales sont eux aussi principalement des entreprises chinoises, et les guichets offrant un support de premier niveau en japonais sont limités. Disposer en interne de personnel capable de lire une documentation technique en chinois ou en anglais devient donc, en pratique, une condition d'adoption. C'est là une différence nette par rapport à Windows ou aux principales distributions Linux.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.