01 Le problème
Un modèle entraîné et un système certifiable parlent rarement la même langue
Les modèles d’IA sont conçus sur des machines à la puissance et à la mémoire presque illimitées. Les systèmes qui en tireraient le plus, dans les airs, en orbite, sur le champ de bataille, sont à l’opposé : petits, contraints en énergie, et souvent soumis à la réglementation de sécurité la plus stricte qui soit. Entre un modèle qui fonctionne en laboratoire et un modèle sur lequel un avion ou un satellite a réellement le droit de s’appuyer, la route est longue.
Une partie de cette route est une étape de traduction : décider exactement comment le modèle est agencé sur le matériel. Sur un FPGA, une puce que l’on reconfigure pour l’adapter à la tâche plutôt qu’un processeur figé, cela revient à choisir parmi un nombre immense d’implémentations possibles. Mais dans un domaine réglementé, le véritable obstacle n’est pas seulement la performance. C’est de savoir si le résultat peut être certifié, et aujourd’hui, pour l’inférence IA sur FPGA, il ne peut généralement pas l’être.
02 Pourquoi cela compte
Les systèmes qui ont le plus besoin d’IA embarquée sont ceux qui peuvent le moins l’adopter
L’avionique, le spatial et la défense reposent sur du matériel dont la sûreté doit être démontrée avant d’être accordée, encadré par des normes comme la DO-254 en aéronautique et l’ECSS dans le spatial. Ces normes exigent un degré de prévisibilité et de traçabilité que l’inférence IA moderne, et les architectures FPGA qui la portent, ne savent pas encore démontrer. Ainsi, les domaines qui ont le plus à gagner de l’intelligence embarquée sont précisément ceux qui ne peuvent pas la certifier. Dans le même temps, l’inférence est devenue la principale tâche du matériel d’IA, et son coût énergétique la pousse hors du centre de données, vers l’appareil lui-même. Combler cet écart aurait une valeur considérable.
Systèmes critiques
Avions, satellites et systèmes de défense ne peuvent déployer une intelligence qu’ils ne peuvent certifier. C’est une voie certifiable qui permettrait à ces domaines d’utiliser l’IA embarquée.
Autonomie
Un système qui raisonne à bord ne dépend pas d’une liaison réseau qui peut être lente, absente ou contestée. C’est l’inférence en périphérie qui permet à une machine de décider sur le terrain, en quelques millisecondes, par elle-même.
Souveraineté
L’Europe fabrique comparativement peu de processeurs de qualité militaire haut de gamme. Tirer davantage du silicium que l’on peut réellement se procurer transforme une contrainte d’approvisionnement en avantage de conception.
03 Pourquoi cela est difficile
L’efficacité est la partie facile. Prouver qu’elle est sûre est la partie difficile
Faire tenir un modèle d’IA sur un FPGA revient déjà à choisir parmi plus de designs possibles que quiconque peut tester à la main, et les estimations habituelles de leurs performances ne sont pas fiables. La difficulté la plus profonde, dans un système réglementé, est l’assurance. Des normes comme la DO-254 et l’ECSS ont été écrites pour du matériel dont le comportement peut être tracé et justifié de bout en bout, et ni l’IA moderne ni les outils qui la portent sur le silicium n’entrent encore dans ce moule.
Un espace combinatoire
Précision, parallélisme, flux de données et allocation des ressources se multiplient en bien plus de combinaisons que quiconque peut essayer à la main. La plupart sont mauvaises, et les bonnes ne sont pas évidentes à l’avance.
Pas encore de voie certifiée
Les normes d’assurance matérielle ont été écrites avant l’apprentissage automatique. Il n’existe pas de recette admise pour certifier un modèle appris et son implémentation, et c’est précisément l’écart qu’examine cette recherche.
Une traçabilité de bout en bout
La certification demande que chaque décision de conception soit justifiée et tracée. Une recherche automatisée incapable d’expliquer pourquoi elle a choisi une implémentation donnée est difficile à défendre devant une autorité.
Un temps de réponse déterministe
Les systèmes certifiés ont besoin d’une réponse dans un délai fixe, à chaque fois. Optimiser la vitesse moyenne ne suffit pas quand c’est le pire cas qui doit être borné et prouvé.
Des estimations trompeuses
Les outils de conception prédisent la vitesse et l’usage des ressources en amont, mais ces prédictions s’écartent souvent de ce que fait réellement le matériel, si bien qu’un design prometteur peut décevoir seulement après des heures de compilation.
La précision en jeu
Réduire un modèle pour qu’il tienne peut coûter en précision. Le plus dur est de pousser l’efficacité à sa limite sans dégrader discrètement le comportement même pour lequel le modèle a été choisi.
04 Notre approche
Traçable jusqu’à la porte logique, et exploré plutôt que deviné
Nous traitons le passage du modèle entraîné au matériel comme quelque chose à prouver, non à tenir pour acquis. Trois choix portent ces travaux, et ensemble ils rendent plausible un résultat certifiable là où une chaîne d’outils sur étagère l’exclut.
Transparent jusqu’à la porte logique
L'implémentation reste lisible jusqu'aux portes logiques, sans boîte noire de synthèse haut niveau ni IP propriétaire au milieu. Les standards d'assurance demandent cette transparence. Les chaînes d'outils haut niveau habituelles la perdent.
Vérifié face à la référence, au bit près
On vérifie que le matériel reproduit exactement le modèle entraîné, jusqu’au dernier bit, et non qu’il s’en approche seulement. Toute une classe d’erreurs entre le modèle certifié et celui réellement déployé est éliminée par construction.
Des compromis cherchés, non choisis à la main
La précision, la surface logique, les performances temporelles et la consommation entrent réellement en conflit, et aucun design ne l’emporte sur tous ces plans. Plutôt que de façonner une seule configuration à la main, nous explorons l’espace automatiquement et faisons émerger un ensemble d’implémentations, chacune traçable individuellement, à choisir selon de vraies priorités.
05 Où cela en est
La chaîne fonctionne. La certification est le front ouvert
Cette ligne précède l'entreprise : elle est née d'une pratique d'ingénierie avionique, et c'est pourquoi la certifiabilité en est la contrainte de conception. C'est de la recherche appliquée, pas un produit fini. La chaîne fonctionne de bout en bout, du modèle entraîné au matériel vérifié contre lui, et les premiers résultats justifient de continuer. L'approche s'aligne sur les cadres d'assurance émergents pour l'IA embarquée en vol, DO-254 et ECSS entre autres. La méthode elle-même n'est volontairement pas décrite ici et est protégée par une preuve d'antériorité datée. La souveraineté et l'absence de dépendance à un fournisseur découlent des mêmes choix de conception.