IA en périphérie et déploiement en temps réel

L'IA en périphérie réussit ou échoue dans l'ingénierie de déploiement, pas dans le modèle ni dans le silicium : choisir le matériel adapté à la charge de travail, optimiser le modèle pour qu'il tienne sur ce matériel sans détruire la précision, construire un pipeline d'inférence assorti de garanties de latence déterministes, et maintenir le système à jour et surveillé une fois qu'il fonctionne dans une antenne-relais, un véhicule, une usine ou une installation de défense. Cette ingénierie de déploiement est la discipline autour de laquelle nos missions sont construites.

La sélection du matériel est une décision d'ingénierie, pas une relation avec un fournisseur

Le paysage du silicium pour la périphérie en 2026 est le plus fragmenté qu'il n'ait jamais été. Chaque plateforme présente un profil de couverture d'opérateurs, une architecture mémoire, une chaîne d'outils de compilation et une courbe de coût à grande échelle différents.

Le mauvais choix ici est coûteux et difficile à défaire. Un modèle optimisé pour TensorRT sur Jetson ne se transfère pas vers l'architecture de flux de données de Hailo ou le SDK QNN de Qualcomm sans un travail de réoptimisation qui peut prendre des semaines. Avant de nous engager, nous profilons les charges de travail par rapport aux plateformes candidates (éclairés par nos recherches sur la latence de l'edge computing industriel) :

• Analyse de la couverture des opérateurs pour l'architecture du modèle.
• Modélisation de la bande passante mémoire — le véritable goulot d'étranglement sur les FPGA est la bande passante DDR, pas le calcul.
• Simulation de l'enveloppe thermique sous charge soutenue.
• Coût total de possession au volume de déploiement cible.

Une mission est cadrée pour produire une recommandation matérielle assortie d'une justification quantifiée, pas une préférence pour un fournisseur.

Une optimisation de modèle qui ne détruit pas ce que le modèle a appris

Faire tenir un modèle sur du matériel de périphérie est un pipeline, pas une étape unique, et l'ordre compte :

1. Recherche d'architecture dans les limites du matériel : budget de FLOP, ensemble d'opérateurs pris en charge, plafond mémoire.
2. Entraînement tenant compte de la quantification (QAT) visant une précision INT8 ou INT4 avec calibration par canal. La quantification post-entraînement est plus rapide mais peu fiable — les propres benchmarks de NVIDIA montrent une perte de précision catastrophique sur les architectures EfficientNet avec la PTQ après repliement de la batch-norm, tandis que le QAT peut égaler ou dépasser la précision de référence FP32.
3. Élagage structuré guidé par une analyse de sensibilité, supprimant la capacité redondante sans déclencher les chutes de précision que provoque l'élagage non structuré.
4. Distillation de connaissances à partir d'un modèle enseignant plus grand pour récupérer la précision perdue lors des étapes de compression.

Choix de la chaîne d'outils de compilation

Le choix de la chaîne d'outils de compilation détermine ce qui est possible, c'est pourquoi nous choisissons par cible plutôt que de recourir par défaut à celle que nous avons utilisée en dernier :

• TensorRT offre systématiquement l'inférence la plus rapide sur le matériel NVIDIA, mais il est propriétaire et réservé à NVIDIA.
• Apache TVM est multiplateforme et open source mais nécessite un réglage important ; sans réglage, il est moins performant qu'ONNX Runtime, tandis qu'avec réglage il peut égaler TensorRT sur les architectures de type transformeur (benchmark MDPI Electronics, 2025).
• Xilinx Vitis AI gère la quantification INT8 pour les cibles FPGA mais présente une couverture partielle des opérateurs qui impose une réimplémentation manuelle de couches.

La latence déterministe n'est pas la latence moyenne

La plupart des benchmarks d'IA en périphérie rapportent le temps d'inférence moyen — un chiffre quasi inutile pour les déploiements critiques pour la sécurité. Ce qui compte, c'est le temps d'exécution dans le pire des cas (WCET): la durée la plus longue que l'étape d'inférence prendra jamais sous stress thermique, pression mémoire, fluctuation de puissance et contention de l'ordonnancement de l'OS. Un système dont la moyenne est de 2 millisecondes mais qui grimpe parfois à 15 millisecondes pendant les pauses de ramasse-miettes n'est pas un système temps réel (une contrainte autour de laquelle est construite notre démo fonctionnelle d'inspection industrielle par IA en périphérie ). C'est un système rapide qui, parfois, n'est pas assez rapide.

Notre approche consiste à construire des pipelines d'inférence conçus pour la queue de distribution, pas pour la moyenne :

• Tampons mémoire pré-alloués pour éliminer la gigue d'allocation.
• Affinité CPU épinglée pour empêcher la migration par l'ordonnanceur.
• Prétraitement accéléré par le matériel pour tenir le chemin des données hors du CPU.
• Post-traitement des sorties avec calibration de la confiance ajustée à la distribution de sortie décalée du modèle quantifié.

Sur les cibles FPGA, nous concevons pour une inférence déterministe inférieure à la milliseconde, sans aucune couche d'ordonnancement logiciel ; la fusion de capteurs à base de FPGA a démontré une latence de 5,51 ms avec une précision de 99,3 % dans des benchmarks académiques (Springer, 2025). Pour les cibles à base de GPU, nous utilisons les graphes CUDA et les lancements de noyaux persistants afin de minimiser la surcharge du pilote, avec une analyse WCET qui caractérise la latence de queue sous throttling thermique. Le throttling thermique à lui seul peut réduire la vitesse d'inférence de 30 à 50 % sur les charges de travail soutenues (benchmark militaire SINTRONES), de sorte qu'un système conçu uniquement pour le cas moyen échoue précisément dans les conditions où la fiabilité importe le plus.

Mises à jour OTA pour les modèles fonctionnant sur le terrain

Déployer un modèle est le début, pas la fin. Les modèles dérivent à mesure que le monde change autour d'eux — dégradation des capteurs, évolutions environnementales, changements dans la chaîne d'approvisionnement qui modifient la distribution des données. Détecter la dérive en périphérie est plus difficile que dans le cloud car la bande passante est limitée et vous ne pouvez pas renvoyer la télémétrie brute en flux vers un système central sans faire exploser votre budget de connectivité. Nous mettons en œuvre une détection de dérive côté périphérie à l'aide de méthodes statistiques — la divergence KL et l'indice de stabilité de population — calculées localement, seules des métriques de synthèse étant envoyées en amont. Lorsque la dérive dépasse les seuils, le système peut déclencher des flux de réentraînement automatisés ou signaler pour examen humain.

Le mécanisme de mise à jour lui-même comporte des risques, et le bon choix dépend du contexte réglementaire :

• Automobile : Les règlements UNECE R155 et R156 sont obligatoires pour toutes les nouvelles homologations de type de véhicule depuis juillet 2024. Le R155 exige un système de gestion de la cybersécurité sur l'ensemble de la chaîne d'approvisionnement ; le R156 exige un système de gestion des mises à jour logicielles pour l'ensemble du cycle de vie du logiciel du véhicule. Tout modèle d'IA livré par OTA relève du R156.
• Dispositifs médicaux : Le projet de directive de la FDA de janvier 2025 sur les fonctions logicielles des dispositifs dotés d'IA introduit le plan de contrôle des changements prédéterminés (PCCP), permettant des mises à jour de modèle post-commercialisation sans nouvelle soumission tant que les changements restent dans des paramètres préapprouvés. La FDA a autorisé 295 dispositifs médicaux dotés d'IA/ML en 2025, dont 62 % classés comme logiciels en tant que dispositif médical.
• Défense et souveraineté : L'OTA n'est souvent pas du tout une option. Les environnements isolés (air-gapped) utilisent des supports physiques signés cryptographiquement ou des diodes de données unidirectionnelles, avec une vérification d'intégrité conforme aux exigences de sécurité au niveau des composants de la norme IEC 62443-4-2 (cette catégorie de déploiement en périphérie refusé et déconnecté est ce pour quoi notre démo fonctionnelle d'autonomie de drone en environnement privé de GPS est conçue).

Nous concevons une infrastructure de mise à jour adaptée au contexte : conformité SUMS automobile, documentation PCCP de la FDA, ou flux de travail sur supports physiques isolés avec traçabilité de la chaîne de possession.

Quand l'IA en périphérie est le mauvais choix

Toutes les charges de travail d'inférence n'ont pas leur place en périphérie. C'est le mauvais choix dans quatre situations :

• Les grands modèles de langage au-delà d'environ 7 milliards de paramètres — ils ne fonctionnent pas de manière significative sur le silicium de périphérie actuel en dehors de versions fortement quantifiées et aux capacités réduites.
• Les charges de travail aux architectures de modèle changeant rapidement, où vous prévoyez de changer de familles de modèles chaque trimestre — l'inférence dans le cloud les sert mieux, car chaque cycle d'optimisation spécifique au matériel ajoute des semaines.
• Les déploiements de faible volume, en deçà de quelques centaines d'appareils, qui atteignent rarement le point de bascule du TCO où l'investissement en matériel de périphérie devient rentable ; le coût de l'inférence dans le cloud à cette échelle est gérable.
• Les charges de travail où les données se trouvent déjà dans le cloud, comme l'analyse de données agrégées provenant de nombreux sites — pousser l'inférence vers la périphérie n'apporte rien.

Le point de bascule du TCO entre périphérie et cloud se situe généralement à 12 à 24 mois selon le volume de déploiement et la fréquence d'inférence. À grande échelle, les chiffres sont décisifs : 50 000 appareils exécutant 60 inférences par minute génèrent environ 3 milliards d'appels d'API par mois, ce qui se traduit par environ 300 000 dollars par mois de coûts d'inférence dans le cloud à eux seuls (analyse sectorielle CIO). Le matériel de périphérie pour cette flotte coûte plus cher au départ mais se stabilise à 10 dollars par appareil et par mois en coûts continus, avec une consommation électrique de 10 à 25 watts par nœud. Nous modélisons le seuil de rentabilité du TCO pour chaque mission afin que la décision repose sur des chiffres, pas sur des hypothèses.

IA multimodale et générative en périphérie

La périphérie ne se limite plus aux modèles de classification et de détection :

• Les modèles vision-langage Cosmos Nemotron de NVIDIA fonctionnent sur Jetson Orin pour le raisonnement multi-images.
• Le 10H de Hailo exécute des modèles de langage à 2 milliards de paramètres avec une latence de premier jeton inférieure à la seconde et un débit de plus de 10 jetons par seconde à moins de 5 watts.
• La plateforme Modalix de SiMa.ai s'est associée à Cerence pour amener CaLLM Edge, un petit modèle de langage embarqué de qualité automobile, sur le silicium de périphérie.
• Latent AI a lancé ce qu'elle présente comme la première plateforme d'IA agentique en périphérie du secteur, combinant l'optimisation de modèle avec un MLOps automatisé pour des flux de travail à base d'agents sur du matériel de périphérie.

Les appareils en périphérie peuvent désormais exécuter des systèmes de réponse à des questions visuelles, des interfaces opérateur en langage naturel (voir notre livre blanc sur l'impératif architectural au-delà des enveloppes d'API pour l'IA vocale), et de courtes chaînes de raisonnement qui nécessitaient auparavant des allers-retours vers le cloud. Les contraintes sont réelles : les fenêtres de contexte sont limitées, les temps de réponse augmentent avec la longueur de séquence, et une ingénierie de prompt soignée est nécessaire pour rester dans la distribution de sortie fiable du modèle quantifié. Nous aidons les équipes à identifier quelles capacités génératives tirent parti d'un déploiement en périphérie et lesquelles sont mieux servies par un appel au cloud avec mise en cache en périphérie.