L'IA générative modifie une partie du développement embarqué — mais pas la partie décisive. Ce qui s'est déplacé, ce qui s'est intensifié, et ce que vous obtenez en tant que client.
L'IA générative est aujourd'hui capable de produire des pilotes standard, des automates simples et du code passe-partout en SystemVerilog, VHDL, C ou Python. C'est réel, c'est utile, et cela a réduit la charge de certaines tâches de routine.
Une question légitime se pose : que reste-t-il alors à apporter pour un développeur expérimenté en embarqué et FPGA ?
La réponse est concrète.
Une IA est un exécutant rapide. Elle produit ce qu'on lui demande — pas ce qui est nécessaire. Demander à une IA d'« écrire un pilote UART » donne un pilote UART. Mais pas celui qui fonctionne réellement avec ce domaine d'horloge, cette affectation de broches, ce comportement temporel et cette gestion d'erreurs dans l'environnement cible.
La véritable expertise d'ingénieur ne consiste pas à générer du code. Elle consiste à rédiger une spécification précise : ce qui doit exactement se produire, sous quelles conditions, avec quelles tolérances, avec quel comportement en cas de défaut, dans quelle plage de température, sur quelle durée de vie.
Une meilleure IA n'y change rien. Au contraire : plus les outils deviennent puissants, plus il est décisif de les instruire correctement.
Une IA n'ajoute pas d'exigences auxquelles le client n'a pas pensé. Elle n'invente pas de cas particuliers. Elle livre exactement ce qui est dans la spécification — et rien de plus. Ce qui n'est pas spécifié manque dans le résultat.
Le risque se déplace ainsi entièrement sur la spécification elle-même. Une spécification inexpérimentée décrit correctement ce que le client a demandé et passe à côté de tout ce que le rédacteur n'a jamais vécu : la défaillance rare d'un capteur sous certains gradients de température, le comportement lors d'un brown-out simultané et d'un blocage du bus I²C, un reset de chien de garde pendant une séquence d'écriture flash, le couplage électromagnétique sur de longs câbles de capteurs, le comportement au redémarrage après un reset involontaire pendant une opération d'écriture critique.
Ces points ne sont pas des exigences du client. Ce sont des exigences qu'un développeur expérimenté ajoute parce qu'il sait que sinon elles ne figureront nulle part. Une spécification est ainsi toujours aussi un catalogue de risques — et la profondeur de ce catalogue est proportionnelle à l'expérience du rédacteur.
Lors d'une enquête de sécurité sur un dispositif de perfusion, à laquelle un fabricant de dispositifs médicaux m'a fait appel, une défaillance pertinente pour la sécurité s'est manifestée par l'apparition simultanée de deux défauts isolés : la défaillance matérielle d'un composant mémoire et une routine de vérification erronée pour ce même composant. Chaque défaut pris isolément était maîtrisable. Seule la combinaison a produit l'état de défaillance non détecté.
C'est précisément cette analyse combinatoire qui doit être activement ajoutée dans une spécification. À partir de l'exigence « vérifier la mémoire », un outil génère une routine de vérification. L'expérience ajoute l'exigence supplémentaire que la défaillance de la routine de vérification elle-même ne doit pas conduire à un état de défaillance silencieux. Aucun outil ne formule cette seconde exigence de lui-même.
S'y ajoutent les pièges proches du matériel qui ne figurent pas dans les fiches techniques, mais dans la tête des développeurs qui les ont déjà traqués :
Pour la plupart des tâches, il existe plusieurs solutions qui fonctionnent fondamentalement. Mais seules quelques-unes répondent aux exigences de sécurité, de fiabilité et de durée de vie que le produit concret demande.
Un système d'IA choisit ce qui apparaît fréquemment dans ses données d'entraînement. Un développeur expérimenté choisit ce qui ne mène pas à la catastrophe dans un système relevant de la sécurité. Cette décision de sélection n'est pas un détail d'implémentation. C'est la véritable ingénierie.
En cas de dommage, le législateur exige la preuve que le produit, au moment de sa mise sur le marché, correspondait à l'état de l'art. C'est la condition centrale pour qu'un fabricant puisse se dégager de la responsabilité du fait des produits. Avec la nouvelle directive européenne sur la responsabilité du fait des produits et la loi nationale de transposition qui en découle, cette charge de la preuve est explicitement renforcée pour les logiciels et les produits intégrant du logiciel.
L'état de l'art n'est pas un état statique. C'est ce qui est considéré comme usuel parmi les professionnels — et il évolue actuellement de manière accélérée parce que de nouveaux outils et méthodes relèvent le standard du marché en cycles courts.
Il en résulte : qui développe aujourd'hui un système embarqué doit connaître et utiliser les méthodes plus performantes actuellement disponibles. Qui ne le fait pas crée pour son donneur d'ordre un risque de responsabilité concret. Cela suppose précisément un développeur qui maîtrise à la fois les outils établis et les outils nouveaux et qui peut effectuer le bon choix.
J'utilise les outils d'IA là où ils permettent un gain de temps mesurable sans créer de risque : premier jet de code passe-partout, génération de bancs de test, documentation, vérification de lisibilité.
Je ne les utilise pas en remplacement de :
Le résultat : moins de charge pour le travail de routine, qualité constamment élevée sur les tâches qui portent réellement le projet, et un processus de développement documenté conforme à l'état de l'art actuel.
Vous mandatez un développeur avec plus de 35 ans d'expérience en FPGA et embarqué, qui connaît les outils actuels et sait juger de leurs limites. Vous n'obtenez ni un « projet généré par IA » ni un « projet sans IA ». Vous obtenez un système fonctionnel pour lequel une personne concrète prend la responsabilité — et qui, en cas de sinistre, peut être démontré comme ayant été développé conformément à l'état de l'art.
Si vous avez un projet embarqué qui exige précisément cette profondeur, parlons-en directement. Premier entretien et estimation grossière sont gratuits et sans engagement.