Le tableau de bord de Cenk : le paradoxe de l'IA dans le monde de l'embarqué
L’histoire distillée de 25 études.
Mardi matin, 9 h 14. Dans une petite start-up IoT à Ankara, Cenk, ingénieur firmware senior, fixe son écran. Il doit configurer un échantillonnage ADC basé sur DMA sur une carte STM32. Il demande à Claude — le code arrive, compile, se flashe. Les capteurs produisent des données. Cenk sourit. La semaine suivante, douze compteurs d’eau intelligents sur le terrain se mettent à geler de façon aléatoire. Le coupable : une mauvaise configuration de l’horloge d’un périphérique. Le compilateur n’a rien pu voir ; le silicium, si. Cenk regarde son tableau de bord et se demande : est-ce que cet outil nous fait vraiment gagner du temps, ou nous donne-t-il simplement l’impression d’être rapides ?
Cenk n’est pas seul. Deux des études les plus marquantes de 2025 se contredisent ouvertement. Dans l’expérience contrôlée de METR, 16 développeurs open source expérimentés ont mis 19 % de temps en plus pour accomplir leurs tâches avec des outils d’IA — alors qu’ils avaient prédit un gain de 24 %, et qu’ils croyaient encore, après coup, avoir été 20 % plus rapides. La même année, un RCT conjoint de Microsoft, du MIT et de Princeton portant sur 4 867 développeurs a mesuré une augmentation de 26 % des PR hebdomadaires. Deux études, deux directions opposées. Laquelle domine dans le monde des systèmes embarqués ?
L’outil enseigne, accélère, démocratise — vraiment
Les preuves sont solides. Dans l’étude d’Englhardt présentée à CHI 2024, le workflow homme–IA a fait passer le taux de réussite de compilation de capteurs LoRa de 25 % à 100 % — même des utilisateurs sans aucune expérience matérielle ont pu construire des capteurs fonctionnels. Dans la même étude, GPT-4 a réduit la consommation de courant de la puce nRF52 d’un facteur 740× grâce à une optimisation de puissance spécifique au contexte — jusqu’à 12,2 microampères. Dans l’étude d’un an de TATA 1mg portant sur 300 ingénieurs, les développeurs juniors ont vu des gains de productivité allant jusqu’à 77 %. Selon DORA 2025, 90 % des développeurs utilisent désormais l’IA ; 80 % rapportent des effets positifs sur la productivité.
Du code qui compile n’est pas du code qui fonctionne
Dans le benchmark EmbedAgent de juin 2025, DeepSeek-R1 n’a atteint que 55 % de pass@1 sur 126 tâches embarquées ; le portage multiplateforme le faisait chuter à 29 % sur ESP-IDF. Plus frappant encore : Claude-3.7-Thinking a dépensé 78 % de ses tokens de raisonnement non pas à planifier, mais à réparer son propre code bogué — l’effet d’overthinking. Un article de 2026 paru dans Future Internet a testé 27 LLMs sur une stack IoT complète (capteur → InfluxDB → Grafana) ; presque tous ont produit du firmware qui compilait mais qui était faux pour le matériel. Incompatibilités de versions de bibliothèques, bit-fields de registres incorrects, formules de capteurs hallucinées.
Le monde de l’embarqué a une particularité : les bugs vivent loin. Dans une application web, un bug se contente de rafraîchir la page ; dans un firmware, un bug briquette dix mille appareils sur le terrain. L’analyse de GitClear sur 211 millions de lignes de code montre que le code dupliqué a augmenté de 48 % entre 2020 et 2024 ; dans les dépôts riches en IA, la dette de refactoring accumulée est 34 % plus élevée. Pour les équipes IoT, ce n’est pas un problème de luxe — la mémoire est comptée, la batterie est comptée, les mises à jour OTA coûtent cher. Du code gonflé signifie une autonomie réduite, qui signifie des rappels clients. Dans l’enquête Stack Overflow 2025, la méfiance active envers l’IA est passée de 31 % à 46 %.
Quelle porte gardez-vous, et laquelle ouvrez-vous ?
Les deux camps ont raison — dans des conditions différentes. Voici l’hypothèse qui émerge du croisement de cinq études : les LLMs offrent de solides gains en IoT sur les tâches bornées, vérifiables et jetables. Écrire un parseur de protocole, générer une fonction de calibration de capteur, échafauder un test de régression, rédiger de la documentation. En dehors de cette frontière — conception au niveau système, routines critiques en timing, intégration multi-composants, modules safety-critical — la capacité s’effondre nettement. Le gain ne vient pas de l’outil mais de la discipline d’ingénierie construite autour. Comme le formule DORA : l’IA est un amplificateur.
Le mardi suivant, Cenk participe au deuxième test terrain. Cette fois, l’équipe vérifie à l’oscilloscope chaque ligne DMA écrite par le LLM. Deux heures de travail supplémentaires — moins cher qu’une semaine de rappel sur le terrain. Son tableau de bord reste ouvert ; les chiffres de productivité montent — plus lentement cette fois, mais durablement. En 2026, la vraie question pour les équipes IoT n’est pas « faut-il utiliser l’IA ? ». La vraie question est : quelle porte gardez-vous, et laquelle ouvrez-vous ? Parce que ce qui sépare −19 % de +26 %, ce n’est pas le modèle — c’est la discipline de son usage.
Sources :
- METR arXiv:2507.09089
- Cui et al. Microsoft/MIT RCT
- EmbedAgent arXiv:2506.11003
- MDPI Future Internet 18(2):94
- Englhardt CHI EA 2024
- GitClear Code Quality Report 2025
- DORA 2025
- Stack Overflow Developer Survey 2025
- Khare et al. arXiv:2509.19708.