L'IA remplacera-t-elle les ingénieurs en systèmes embarqués ? Au plus près du métal

44 % d'exposition à l'IA et 26 % de risque d'automatisation. Pour quiconque a passé des années à maîtriser les arcanes des microcontrôleurs, des systèmes d'exploitation temps réel et de la compatibilité électromagnétique, ces chiffres devraient rassurer — ils figurent parmi les plus bas que nous mesurons dans l'ensemble du secteur technologique.

Ces chiffres sont inférieurs à ceux des data scientists, des développeurs web full-stack et même de la plupart des rôles en cybersécurité.

Qu'est-ce qui rend l'embarqué aussi défendable ? Trois facteurs, qui se renforcent mutuellement. Premièrement, le travail est physiquement contraint d'une manière que les domaines purement logiciels ne connaissent pas. Deuxièmement, les chaînes d'outils sont fragmentées, spécifiques aux fournisseurs et mal représentées dans les données d'entraînement de l'IA. Troisièmement, les conséquences des bugs sont souvent critiques pour la sécurité, ce qui rend les entreprises extrêmement réticentes à laisser l'IA écrire du firmware de production sans révision rigoureuse.

Cet article analyse ce qui arrive à l'ingénierie embarquée en 2025, là où l'IA apporte réellement de la valeur, pourquoi elle en apporte moins que dans d'autres domaines logiciels, et ce qu'un ingénieur embarqué devrait faire différemment — si tant est qu'il doive changer quoi que ce soit — au cours des cinq prochaines années. Les données s'appuient sur l'analyse des tâches O\*NET, l'Anthropic Economic Index (2026), le U.S. Bureau of Labor Statistics et des enquêtes sectorielles de l'IEEE Computer Society et d'Embedded Computing Design.

Pourquoi l'embarqué bénéficie du fossé défensif le plus solide

Le score d'exposition de 44 % et le score de risque de 26 % ne sont pas le fruit du hasard. Ils reflètent des caractéristiques structurelles du travail embarqué qui résistent à l'automatisation.

La proximité matérielle. Le travail d'un ingénieur embarqué consiste à faire fonctionner correctement un logiciel sur du silicium spécifique. La carte embarque des résistances et des condensateurs aux tolérances particulières. Le microcontrôleur possède des registres qui se comportent de manière surprenante aux températures extrêmes. L'alimentation électrique présente des caractéristiques de bruit que la fiche technique ne mentionne pas. Chaque projet est une combinaison unique de réalités physiques, et le travail de l'ingénieur consiste à naviguer dans cette singularité. Les assistants IA entraînés sur des motifs de code moyen ne sont pas bien adaptés à cette tâche.

La fragmentation des chaînes d'outils. Un développeur web peut travailler avec le même stack React, Node et TypeScript sur des centaines de postes. Un ingénieur embarqué peut utiliser le Keil microcontroller development kit (MDK) pour un projet Cortex-M, la GNU Compiler Collection (GCC) pour une carte Arm Linux, l'Espressif Integrated Development Framework (ESP-IDF) pour un dispositif IoT, et un SDK spécifique au fournisseur pour un processeur de signal numérique (DSP) — le tout dans le même trimestre. Les données d'entraînement de l'IA pour ces chaînes d'outils sont maigres et obsolètes. Les suggestions de code sont souvent erronées de manière subtile, prenant plus de temps à déboguer qu'une rédaction de zéro.

Les contraintes temps réel. Un code fonctionnant correctement mais prenant 200 microsecondes de plus qu'attendu peut faire osciller un contrôleur de moteur, rater un échantillon de capteur ou manquer une échéance dans une boucle critique. Raisonner sur la temporisation exige de comprendre les effets de cache, la latence des interruptions, le comportement du DMA et l'arbitrage de bus. Il s'agit d'une connaissance d'ingénierie que les outils IA ne capturent généralement pas bien. [Affirmation]

Sécurité et réglementation. De nombreux produits embarqués sont soumis à des normes — ISO 26262 pour l'automobile, IEC 62304 pour les dispositifs médicaux, DO-178C pour l'avionique. Ces normes imposent des processus de développement spécifiques, une traçabilité et une documentation. Elles rendent organisationnellement difficile l'utilisation de code généré par IA en production. Les entreprises ne sont pas prêtes à risquer leur certification en introduisant l'IA dans le processus de développement sans un vetting approfondi.

Là où l'IA aide vraiment les ingénieurs embarqués

Soyons clairs : l'IA n'est pas inutile en embarqué. Elle aide simplement de manière plus ciblée que dans d'autres domaines.

La génération de squelettes de drivers. Générer le code boilerplate pour un driver SPI, UART ou I2C est quelque chose que les assistants IA réalisent raisonnablement bien, notamment pour les familles de microcontrôleurs populaires. L'ingénieur doit encore vérifier le comportement temporel et électrique, mais la frappe est considérablement réduite.

La conception de machines à états. Esquisser les états et les transitions d'un protocole de communication ou d'une routine de gestion de capteurs est une activité modulaire que l'IA accélère. L'ingénieur revoit la conception et corrige les erreurs avant l'implémentation.

La documentation. Rédiger des manuels de référence technique, la documentation de Board Support Package (BSP) et les fichiers d'historique de conception pour les produits réglementés. L'IA gère le fardeau rédactionnel pendant que l'ingénieur assure l'exactitude technique.

La génération de cas de test. Produire les stubs de tests unitaires pour des implémentations de machines à états ou du code de driver. Les outils de couverture vérifient ensuite que les tests exercent réellement les chemins de code.

La lecture des fiches techniques. Les puces embarquées modernes ont des manuels de référence de 500 pages. L'IA peut résumer des sections, extraire des tableaux d'affectation de broches et vous aider à trouver le registre dont vous avez besoin. C'est genuinement précieux pour un ingénieur noyé dans la documentation fournisseur.

Les données de l'Anthropic Economic Index montrent une utilisation croissante de l'IA dans l'embarqué, mais à un rythme bien plus lent que dans le développement web ou le code d'application général. Environ 38 % des ingénieurs embarqués déclarent utiliser régulièrement une assistance IA contre 76 % des développeurs web. [Estimation] Cet écart est cohérent avec le schéma documenté par l'Anthropic Economic Index (2026), qui a constaté que le codage reste la catégorie d'usage IA la plus courante, mais que le travail le plus automatisable se concentre dans les motifs routiniers et bien documentés — précisément le type de travail que les chaînes d'outils embarquées, avec leur documentation maigre et fragmentée, ne génèrent pas. [Fait]

Là où l'IA est insuffisante

La liste des tâches embarquées avec lesquelles l'IA peine est longue et bien connue des praticiens :

Le débogage de mise en route (bring-up). Lorsqu'on met sous tension une nouvelle carte pour la première fois et que rien ne fonctionne, la cause peut être : un pochoir de pâte à braser erroné, un composant inversé sur la nomenclature, une alimentation bruyante, une horloge qui ne démarre pas, un quartz qui n'oscille pas à cause d'une capacité parasite, un programmateur mal connecté, ou un firmware avec un subtil bug d'ordonnancement. Travailler sur cette liste exige d'être au banc avec un oscilloscope, un analyseur logique et un multimètre. L'IA ne peut pas aider de manière significative.

La co-conception matériel-logiciel. Dès le début du projet, des décisions sont prises sur le choix du microcontrôleur, les périphériques à utiliser, et les fonctionnalités à implémenter en matériel versus logiciel. Prendre les bonnes décisions exige de connaître intimement le silicium et les contraintes logicielles. C'est l'activité la plus créatrice de valeur dans un projet embarqué, et l'IA y échoue parce qu'elle requiert un jugement holistique sur de nombreux compromis.

L'optimisation de la consommation et de la thermique. Extraire les derniers 30 % d'autonomie d'un dispositif IoT, ou maintenir un système sous les limites thermiques avec un refroidissement passif, exige une connaissance approfondie de chaque mode de fonctionnement et de chaque chemin de courant. Les outils IA ont une vision limitée de la carte spécifique sur laquelle vous travaillez.

Le débogage de compatibilité électromagnétique. Quand votre appareil échoue aux tests d'émissions rayonnées à une fréquence spécifique, trouver pourquoi implique de tracer les chemins de courant de retour, d'examiner les plans de masse et éventuellement de reconcevoir des portions du PCB. C'est un travail physique d'ingénierie qu'aucune IA ne peut faire à distance.

L'analyse des pannes terrain. Quand un produit déployé commence à tomber en panne sur le terrain après six mois, trouver la cause racine peut nécessiter : rappeler des unités du terrain, examiner les composants défaillants au microscope, effectuer des tests de durée de vie accélérée et corréler les pannes aux lots de fabrication. Rien de tout cela n'est assistable par IA.

La conformité réglementaire. Construire un dossier de sécurité pour une pompe à perfusion médicale, rédiger la Spécification des Exigences Système pour un ECU automobile, ou assembler le fichier d'historique de conception pour une soumission FDA. Ces documents doivent être défendables et précis, et ils nécessitent des semaines de travail minutieux de la part d'ingénieurs embarqués et de spécialistes de la sécurité.

Les tâches par niveau de risque

Cartographie de l'inventaire de tâches O\*NET pour les ingénieurs en systèmes embarqués :

Forte exposition (50 %+) : rédaction de code driver standard ; production de stubs de tests unitaires ; génération de documentation ; réalisation de revues de littérature pour les nouveaux composants ou normes ; rédaction de propositions de conception.

Exposition modérée (25-50 %) : implémentation de protocoles de communication ; conception de machines à états ; rédaction de code de couche application par-dessus un RTOS ; réalisation de revues de code sur des implémentations routinières.

Faible exposition (moins de 25 %) : débogage de mise en route ; co-conception matériel-logiciel ; travaux de compatibilité électromagnétique ; optimisation de la consommation et de la thermique ; construction de dossiers de sécurité ; analyse des pannes terrain ; développement de tests de fabrication.

Le schéma est sans ambiguïté. Le travail le plus exposé à l'IA est celui qui disposait déjà d'exemples de code en ligne et de discussions actives dans des forums populaires. Le travail le moins exposé est celui qui réside dans la documentation fournisseur, les notes d'application et l'expérience personnelle des ingénieurs embarqués — une connaissance qui ne figure pas bien dans les données d'entraînement de l'IA. [Estimation]

Les sous-rôles embarqués et leurs trajectoires

Au sein de l'ingénierie des systèmes embarqués, différents sous-rôles font face à des avenirs différents.

Les ingénieurs firmware pour l'électronique grand public font face à une exposition modérée. Les cycles produit sont courts, les contraintes de sécurité sont plus souples, et la génération de code IA par motifs est raisonnablement utile. Score de risque pour ce sous-rôle : environ 35 %.

Les ingénieurs embarqués temps réel pour le contrôle industriel font face à une exposition plus faible. Le travail implique une analyse temporelle complexe, des garanties strictes de temps réel et une intégration avec des protocoles industriels comme CAN et EtherCAT. Score de risque : environ 22 %.

Les ingénieurs embarqués à criticité sécurité dans l'automobile, le médical et l'avionique font face à la plus faible exposition. La combinaison de charge réglementaire et d'implications sécuritaires maintient les ingénieurs humains au cœur du processus de développement. Score de risque : environ 15 %.

Les ingénieurs embedded Linux font face à une exposition plus élevée parce qu'une grande partie de leur travail se situe dans des applications espace utilisateur où les données d'entraînement de l'IA sont abondantes. Ils écrivent essentiellement des applications Linux avec des considérations embarquées, et la partie applicative est significativement automatisable. Score de risque : environ 38 %.

Les ingénieurs de mise en route et de Board Support Package font face à la plus faible exposition de toutes. Leur travail consiste fondamentalement à faire démarrer des cartes uniques, et ce travail est intrinsèquement manuel. Score de risque : environ 12 %.

Conditions du marché et rémunération

Le marché du travail embarqué en 2025 est dominé par trois tendances. La demande d'ingénieurs embarqués augmente dans l'électrification automobile, l'innovation en dispositifs médicaux et la deuxième vague de déploiement IoT. L'offre est contrainte car les carrières embarquées sont plus difficiles à intégrer que le développement web ; la courbe d'apprentissage est plus raide et l'outillage moins accessible. Et les entreprises qui fabriquent des produits embarqués ont tendance à fidéliser leurs ingénieurs plus longtemps que les entreprises purement logicielles, ce qui signifie que les talents expérimentés atteignent rarement le marché ouvert.

Les données salariales de Glassdoor, Levels.fyi et de l'enquête salariale de l'IEEE montrent que les ingénieurs embarqués seniors gagnent entre 165 000 $ et 285 000 $ aux États-Unis, les spécialistes à criticité sécurité dans l'automobile et le médical commandant le haut de cette fourchette. [Estimation] Ces chiffres se situent confortablement au-dessus du salaire médian officiel pour la classification fédérale la plus proche : selon le Bureau of Labor Statistics (2024), les ingénieurs en matériel informatique ont gagné un salaire médian de 155 020 $ en mai 2024, avec une croissance de l'emploi projetée à 7 % d'ici 2034 et environ 4 700 ouvertures par an. [Fait] C'est une perspective plus rapide que la moyenne pour un domaine que beaucoup supposaient que l'IA viderait de sa substance, et cela explique pourquoi les talents embarqués expérimentés atteignent si rarement le marché ouvert.

Pour un ingénieur embarqué qui se demande s'il doit changer de spécialité, la réponse en 2025 est généralement non. Le domaine est en bonne santé, le travail est intéressant, et la menace IA est gérable. Les ingénieurs qui souhaitent progresser devraient viser la profondeur (devenir l'expert de référence sur une famille de microcontrôleurs ou un domaine particulier) plutôt que la largeur (courir après le modèle de langage populaire du trimestre).

Sur quoi se concentrer jusqu'en 2030

Conseils concrets pour les ingénieurs embarqués planifiant les cinq prochaines années :

Choisissez un secteur vertical et maîtrisez-le. Automobile, médical, aérospatial, industriel, IoT grand public — chacun a ses propres normes, ses familles de puces dominantes et ses pénuries de talents. Les ingénieurs reconnus dans un secteur vertical gagnent plus et ont plus d'options de carrière que les généralistes.

Apprenez les cadres réglementaires de votre domaine. ISO 26262, IEC 62304, DO-178C (FAA), ISA/IEC 62443 pour la cybersécurité industrielle. Les ingénieurs qui comprennent ces normes sont rares et précieux.

Maintenez vos compétences de banc. Utilisation de l'oscilloscope, expertise en analyseur logique, intuition sur l'intégrité du signal, soudure. Ce sont des compétences physiques que l'IA ne menace pas et qui distinguent les ingénieurs embarqués opérationnels des codeurs qui ciblent de petits processeurs par hasard.

Restez à jour sur les RTOS et les modèles bare-metal. FreeRTOS, Zephyr, Threadx, Apache NuttX. Savoir les utiliser, mais surtout savoir quand ne pas les utiliser et basculer en bare metal, est une connaissance à fort levier.

Cultivez une culture interdisciplinaire. De nombreux projets embarqués nécessitent de travailler avec des concepteurs matériels, des ingénieurs mécaniques et des équipes de validation. Les ingénieurs capables de communiquer aisément avec ces groupes deviennent rapidement des référents techniques. L'IA ne menace pas cette compétence ; elle amplifie son importance car le goulot d'étranglement devient de plus en plus la coordination, non la vitesse de codage. [Affirmation]

La vision à long terme honnête

Dans cinq ans, à quoi ressemblera l'ingénierie des systèmes embarqués ? Probablement très proche d'aujourd'hui, avec quelques changements en marge. L'IA prendra en charge davantage du code driver standard, la rédaction de documentation et la conception de machines à états routinières. Les ingénieurs embarqués passeront plus de temps sur l'architecture, le débogage, la co-conception matériel-logiciel et le travail réglementaire. Le rôle nécessitera légèrement moins de frappe et légèrement plus de réflexion — ce qui est généralement une bonne direction pour une carrière d'ingénieur.

Pour un ingénieur embarqué qui lit cet article : vous avez bien choisi. Le travail que vous faites est parmi les plus défendables contre le déplacement par l'IA dans l'ensemble du secteur technologique. Les compétences qui vous rendent précieux — la patience au banc, le raisonnement minutieux sur la temporisation et les ressources, la maîtrise simultanée du matériel et du logiciel — sont exactement les compétences que l'IA ne peut pas reproduire. Continuez à les développer.

Pour les détails sur l'automatisation par tâche et sous-rôle, les données salariales régionales et les prévisions détaillées sur cinq ans, consultez notre profil de profession Ingénieurs en systèmes embarqués.

Historique des mises à jour

• 2026-05-24 : Ajout de citations de sources primaires intégrées du U.S. Bureau of Labor Statistics (ingénieurs en matériel informatique : médiane de 155 020 $, croissance de 7 % d'ici 2034) et de l'Anthropic Economic Index (2026) sur les modèles d'automatisation des tâches de codage.

---

Analyse basée sur la modélisation de l'automatisation des tâches O\NET, l'Anthropic Economic Index (2026), le U.S. Bureau of Labor Statistics, les enquêtes de l'IEEE Computer Society, les rapports sectoriels d'Embedded Computing Design et les données de l'OCDE AI Policy Observatory. Recherche et rédaction assistées par IA ; revue et édition humaines par l'équipe éditoriale d'AIChangingWork.*