Test d'intrusion de produits IA : robots, objets connectés et IA embarquée

Un test d'intrusion de produits IA est un test de sécurité portant sur des appareils intégrant de l'IA – par exemple des robots, des caméras IA, des assistants vocaux ou de l'IA embarquée dans des machines. Il examine le matériel, le firmware, la radio, l'API cloud, l'application, le modèle embarqué sur l'appareil et l'intégration LLM. La question centrale : un attaquant peut-il prendre le contrôle du produit ou l'amener à agir dans le monde physique ?

Un pentest IoT examine le matériel, le firmware, la radio et le cloud. Pour un produit IA s'ajoutent les attaques contre le modèle et l'intégration LLM – injection de prompt, jailbreaks, extraction de modèle, exemples adverses – ainsi que la question des conséquences physiques qu'une attaque peut avoir via les actionneurs et les capteurs. Pour les appareils sans fonction IA, nous recommandons notre pentest IoT.

Oui. Sont notamment documentés des accès root via Bluetooth sur des robots Unitree (UniPwn, 2025), des jailbreaks de robots pilotés par LLM avec des taux de réussite allant jusqu'à 100 % lors de tests de recherche (RoboPAIR, 2024) et une faille critique dans le logiciel de cobot d'Universal Robots (CVE-2026-8153, CVSS 9,8). Les points d'entrée typiques sont les interfaces radio, les services réseau, les API cloud et le planificateur IA lui-même.

Oui, si les sorties du modèle deviennent des commandes sans vérification ou si le modèle dispose de droits trop étendus – dans l'édition 2026 de l'OWASP, il s'agit d'Improper Output Handling (LLM10) et d'Excessive Agency (LLM03). Des chercheurs ont montré que des commandes vocales, des textes dans le champ de la caméra ou des invitations d'agenda peuvent piloter des robots, des drones et des appareils domotiques. C'est pourquoi nous vérifions de manière ciblée si une couche de sécurité déterministe intervient entre la planification IA et les actionneurs.

Pour la couche IA : l'OWASP Top 10 for LLM Applications 2026, l'OWASP Top 10 for Agentic Applications 2026, l'OWASP AISVS 1.01, l'OWASP AI Testing Guide, l'OWASP GenAI Red Teaming Guide et MITRE ATLAS. Pour l'appareil et la radio : l'OWASP ISTG, l'OWASP ISVS, l'OWASP IoT Top 10, la méthodologie d'analyse de firmware OWASP FSTM et, pour les robots, DDS Security avec SROS 2. Côté normes : ETSI EN 303 645, EN 18031, ETSI EN 304 223 et IEC 62443-4-1/-4-2.

MAESTRO est un framework de modélisation des menaces de la Cloud Security Alliance pour l'IA agentique, comportant sept couches d'architecture, de Foundation Models à Agent Ecosystem. STRIDE indique quel type de menace pèse, MAESTRO où elle naît dans l'architecture IA. Pour les produits dotés de capteurs et d'actionneurs, nous ajoutons une couche dédiée au monde physique – Microsoft répertorie d'ailleurs déjà les exemples adverses dans le domaine physique comme une classe de menaces à part entière dans la modélisation des menaces des systèmes d'IA/ML.

Le CRA n'impose pas de procédure appelée « pentest », mais exige à l'annexe I, partie II, des essais et examens efficaces et réguliers de la sécurité du produit. Un test d'intrusion est le moyen usuel d'en apporter la preuve. Les obligations de notification s'appliquent depuis le 11 septembre 2026, toutes les autres exigences à partir du 11 décembre 2027.

Oui : l'annexe III du CRA cite en classe I les assistants virtuels à usage général pour la maison intelligente (point 16), les produits pour la maison intelligente dotés de fonctions de sécurité, comme les caméras de sécurité, les systèmes de surveillance des bébés et les systèmes d'alarme (point 17), les jouets connectés dotés de fonctions d'interaction sociale ou de localisation (point 18) ainsi que certains wearables (point 19). Le règlement d'exécution (UE) 2025/2392 mentionne explicitement les enceintes connectées dotées d'un assistant vocal. Pour la classe I, une autoévaluation (module A) n'est possible que si des normes harmonisées, des spécifications communes ou un schéma européen de certification de cybersécurité au moins de niveau « substantiel » sont intégralement appliqués (art. 32, paragraphe 2, du CRA) – tant qu'aucune norme n'est publiée au Journal officiel, la voie passe en règle générale par un organisme notifié.

Cela dépend de la législation applicable au produit. Pour l'IA utilisée comme composant de sécurité dans des produits relevant de l'annexe I, section A – par exemple les jouets, les équipements radioélectriques ou les dispositifs médicaux –, les obligations applicables à l'IA à haut risque, y compris l'art. 15, s'appliquent selon l'omnibus numérique à partir du 2 août 2028, lorsqu'une évaluation de la conformité par un tiers est prévue. L'omnibus a transféré les machines à la section B : pour l'IA dans les robots et les machines, les exigences sont introduites par des actes délégués au titre du règlement « Machines », lui-même applicable à partir du 20 janvier 2027. Les obligations de transparence au titre de l'art. 50 s'appliquent déjà depuis le 2 août 2026.

Avec un concept de sécurité fonctionnelle convenu : zone de test définie, arrêt d'urgence à portée de main, vitesses réduites et validation par les responsables de la sécurité fonctionnelle du fabricant. Nous examinons d'abord les scénarios critiques en simulation ou sur un jumeau numérique, avant de les reproduire sur le système réel.

Oui. Nous vérifions si des fichiers de modèle se trouvent sans protection sur l'appareil ou dans l'application, si le processus de chargement et la signature sont sûrs et dans quelle mesure le modèle résiste aux exemples adverses, aux données de capteurs manipulées et à l'empoisonnement. Le cas échéant, nous évaluons également les risques de canaux auxiliaires sur les accélérateurs (ISTG-PROC-SIDEC).

Oui. Nous analysons le firmware, les services et le trafic réseau à la recherche de connexions non documentées, de tunnels de télémaintenance et de fonctions cachées. Exemples issus de la recherche : la télémétrie cachée de l'Unitree G1 et le tunnel d'accès à distance de l'Unitree Go1 (CVE-2025-2894).

L'approche la plus efficace est en boîte grise ou blanche : deux à trois appareils de test, un accès à l'application et à l'environnement de test cloud, la documentation d'architecture et – si possible – des images de firmware et des extraits de code source. Un test en boîte noire est possible, mais couvre une surface d'attaque moindre dans le même temps.

Cela dépend de la catégorie de produit, du nombre d'interfaces, de la profondeur de test et des modules souhaités. Après un entretien de cadrage gratuit, vous recevez une offre à prix forfaitaire. Un test ciblé d'un seul appareil, rapport compris, dure en général quelques semaines.

Au minimum avant chaque mise en production majeure et après toute modification importante du firmware, du modèle ou des fonctions cloud. Les modèles et les techniques d'attaque évoluant rapidement, nous recommandons en outre un retest annuel – le CRA exige des tests réguliers pendant toute la période de support.