Vous avez peut-être utilisé de l'IA embarquée ce matin sans y penser. Selon l'appareil et l'application, la détection d'un visage avant une photo, un mot d'activation ou une transcription hors ligne peuvent être calculés localement. D'autres fonctions ressemblantes sollicitent encore un serveur. L'expression décrit donc le lieu où le modèle s'exécute, pas seulement ce que l'utilisateur voit à l'écran.
Le terme apparaît dans les offres d'emploi et les programmes de conférences, mais il est souvent expliqué par des spécialistes à d'autres spécialistes. Cet article prend l'autre chemin.
Sommaire
- Ce que veut dire « embarqué », concrètement
- Ce que change le fait de calculer sur l'appareil
- Sur l'appareil ou sur un serveur : le tableau des différences
- Comment on fait tenir un modèle dans un appareil
- Pourquoi le sujet compte particulièrement à Toulouse
- Ce que l'IA embarquée ne résout pas
- Questions fréquentes
Ce que veut dire « embarqué », concrètement
Un système embarqué est un calculateur intégré dans un objet dont la fonction principale n'est pas l'informatique générale. Parler d'IA embarquée, c'est parler de modèles exécutés sur ce matériel, au plus près du capteur ou de l'usage. L'edge AI est un ensemble plus large : le calcul peut avoir lieu dans l'objet, mais aussi sur une passerelle ou un serveur local proche. La documentation d'Azure IoT Edge décrit ainsi des modules exécutés localement sur des équipements et administrés à distance depuis une interface cloud.
La différence tient à un seul geste
Dans une architecture distante, l'appareil collecte une donnée, l'envoie à un serveur, attend la réponse puis l'affiche. Dans une architecture embarquée, il peut produire le résultat localement. Cela ne signifie pas qu'il n'envoie jamais rien : mises à jour, télémétrie ou résultats agrégés peuvent encore circuler. Le choix modifie surtout la dépendance au réseau, le trajet de la donnée, les contraintes matérielles et la manière de maintenir le système.
Où elle se trouve déjà, sans le dire
Illustrative use case. Un équipement peut analyser localement un signal de capteur lorsque le délai réseau serait incompatible avec sa fonction. Un autre peut effectuer une première classification sur place, puis transmettre seulement un résultat agrégé. Ces mécanismes décrivent des architectures possibles, pas le fonctionnement garanti de tous les véhicules, appareils auditifs ou caméras industrielles.
Ce que change le fait de calculer sur l'appareil
Trois choses changent, et elles ne vont pas toutes dans le même sens : la latence, la confidentialité et la structure des coûts.
La latence
Le temps de réponse dépend moins d'un aller-retour réseau lorsque toute l'inférence est locale. Le gain réel varie toutefois avec le modèle, le processeur et la tâche. Google présente son cadre LiteRT comme un outil d'exécution sur appareil, avec accélération matérielle et quantification, et lui associe faible latence et confidentialité. Il s'agit de la description de son propre produit, pas d'une garantie applicable à toute architecture embarquée.
La confidentialité
Une donnée qui ne quitte pas l'appareil ne peut pas être interceptée en transit ni stockée ailleurs. L'argument est fort et demande de la précision : l'embarqué réduit une catégorie de risques, il ne les supprime pas tous. L'appareil peut être compromis, et rien n'interdit techniquement à une application de calculer localement puis d'envoyer le résultat. Le traitement local est une propriété du système, pas une garantie automatique. Nous abordons cette distinction dans notre article sur l'IA et la vie privée.
La structure des coûts
Le calcul sur serveur se paie à l'usage : chaque requête alourdit la facture. Le calcul embarqué concentre plutôt le coût dans le matériel et dans le travail nécessaire pour adapter le modèle. Cette différence ne rend pas l'une des options automatiquement moins chère. Elle déplace le moment où l'on paie, ainsi que la personne qui supporte ce coût. Mettre à jour un modèle sur des appareils physiques reste aussi plus lourd que remplacer un fichier sur un serveur.
Sur l'appareil ou sur un serveur : le tableau des différences
Comparer sans transformer les options en absolus
| Critère | Calcul sur l'appareil | Calcul sur un serveur |
|---|---|---|
| Temps de réponse | Peut éviter l'aller-retour réseau | Dépend aussi de la liaison et de la charge distante |
| Fonctionnement hors ligne | Possible si toutes les dépendances sont locales | Impossible sans mécanisme local de secours |
| Trajet de la donnée | Peut rester local ; télémétrie possible | Transite vers une infrastructure distante |
| Taille de modèle possible | Contrainte par le stockage, la mémoire et l'énergie | Contrainte par l'infrastructure et le budget |
| Coût | Matériel, adaptation, tests et maintenance | Infrastructure, trafic et exploitation |
| Mise à jour du modèle | Manuelle ou à distance selon le produit | Centralisée, sans être nécessairement instantanée |
Les architectures hybrides sont courantes
Le choix dépend de la contrainte dominante : temps de réponse ou confidentialité d'un côté, taille du modèle ou fréquence des mises à jour de l'autre. Beaucoup de systèmes combinent les deux.
Hypothetical implementation. Un appareil pourrait effectuer une première classification localement, puis transmettre au serveur seulement l'information nécessaire à une fonction plus complexe. Une architecture hybride évite de transformer la décision en duel abstrait entre appareil et cloud. Elle oblige surtout à préciser quelles données peuvent sortir, quelles fonctions doivent rester disponibles hors ligne et comment les mises à jour seront distribuées pendant la durée de vie du produit.
Comment on fait tenir un modèle dans un appareil
Faire tourner un modèle sur un appareil suppose de le réduire, et cette réduction est un métier à part entière.
Adapter le modèle et le logiciel
Étape 1 : vérifier que le modèle tient sur la cible. La documentation d'ONNX Runtime Mobile demande de vérifier que le modèle tient sur le stockage de l'appareil et peut être chargé en mémoire. Elle recommande ensuite de mesurer taille de l'application, latence et consommation sur la plateforme visée.
Étape 2 : réduire ce qui peut l'être. La quantification réduit la précision numérique des poids ; LiteRT et ONNX Runtime la documentent comme une méthode d'optimisation. D'autres leviers consistent à choisir un modèle déjà conçu pour le mobile ou à construire un runtime ne contenant que les opérateurs nécessaires. Toute réduction doit être comparée au niveau de qualité attendu.
Mesurer sur le matériel réel
Étape 3 : mesurer sur l'appareil réel, pas sur une machine de développement. Cette étape ne doit pas être remplacée par un test sur ordinateur : la chaleur, la gestion d'énergie et les autres applications en cours peuvent modifier les temps observés.
Le test doit donc reprendre les conditions d'usage prévues : appareil chargé ou presque vide, réseau absent, température élevée, autres fonctions actives. Il ne suffit pas de vérifier que le modèle démarre. Il faut observer si sa réponse reste acceptable au fil du temps et si l'appareil continue d'assurer sa fonction principale. C'est ce passage du prototype au matériel réel qui transforme une démonstration en choix technique défendable.
Pourquoi le sujet compte particulièrement à Toulouse
Une proximité industrielle réelle
L'IA embarquée n'est pas un sujet régional, mais elle croise ici une industrie majeure. L'INSEE recense 108 900 salariés hors intérim fin 2022 dans la filière aéronautique et spatiale en Occitanie, dont 82 800 dans l'activité aérospatiale, soit 6 % de l'emploi salarié marchand non agricole régional. Les systèmes qui doivent continuer à fonctionner sans liaison disponible illustrent l'intérêt du calcul local, sans permettre de conclure que tous les logiciels embarqués utilisent de l'IA.
Nous n'avons pas de chiffre sur les structures qui y déploient de l'intelligence artificielle. Le poids de la filière rend le sujet pertinent à Toulouse, mais ne prouve ni le nombre de projets ni leur maturité. Pour aborder le marché du travail sans attribuer de déploiement à une entreprise, consultez notre article sur travailler dans l'IA à Toulouse.
Ce que cette proximité ne permet pas d'affirmer
Le poids de l'aéronautique ne permet pas de déduire combien de systèmes utilisent réellement un modèle d'apprentissage automatique, ni à quel stade. Il justifie l'intérêt local du vocabulaire, pas une revendication sur les déploiements de la région.
Ce que l'IA embarquée ne résout pas
Qualité du modèle et données d'entraînement
Elle ne rend pas un modèle meilleur par elle-même. Réduire sa taille ou sa précision peut dégrader certains résultats ; l'écart doit être mesuré sur la tâche réelle plutôt que supposé. L'arbitrage peut porter sur la qualité, l'étroitesse du domaine couvert ou le temps d'ingénierie nécessaire pour conserver un résultat acceptable.
Elle ne règle pas la question des données d'entraînement : l'exécution locale ne change rien à leur origine. Elle n'est pas gratuite en énergie non plus ; la consommation se déplace vers la batterie de l'appareil. Nous traitons cette question dans notre article sur l'IA et l'environnement.
Notre limite d'expérience
Nous n'avons déployé aucun système d'IA embarquée et nous ne sommes pas un organisme de formation. Dans nos rencontres, nous traitons donc d'abord « embarqué » comme un terme à clarifier, sans prétendre transmettre une méthode d'ingénierie. Une fois posée la question du lieu où se produit le calcul, les principaux arbitrages deviennent plus faciles à discuter.
Questions fréquentes
Quelle est la différence entre IA embarquée et edge AI ?
« IA embarquée » désigne généralement un modèle exécuté dans l'équipement qui assure la fonction. « Edge AI » couvre plus largement le calcul proche de la source des données, y compris sur une passerelle ou un serveur local. Les deux ensembles se recouvrent donc sans être identiques. Dans la pratique, les termes restent parfois employés l'un pour l'autre, ce qui justifie de demander où le calcul a réellement lieu.
Faut-il une connexion internet pour utiliser une IA embarquée ?
Pas nécessairement. Si le modèle, le logiciel et toutes leurs dépendances sont présents sur l'appareil, l'inférence peut fonctionner sans liaison. Une connexion peut toutefois rester nécessaire pour l'activation, les mises à jour, la télémétrie ou une partie distante du service. Il faut donc tester le produit hors réseau plutôt que déduire son autonomie de l'étiquette « embarqué ».
Faut-il être ingénieur pour comprendre ce sujet ?
Non pour comprendre le choix, oui pour le mettre en œuvre. Saisir l'arbitrage entre appareil et serveur, avec ses effets sur la vitesse, la confidentialité, le coût et les mises à jour, ne demande aucune formation technique. Concevoir, réduire et certifier le modèle est un autre métier ; il n'est pas nécessaire de l'exercer pour participer à la décision.
Envie d'en parler avec des gens qui en font ? Consultez les prochaines rencontres, découvrez qui nous sommes, ou écrivez-nous. Pour situer ce sujet dans un programme, voyez notre typologie des salons d'intelligence artificielle et notre méthode pour choisir les événements IA qui valent le déplacement.
Nos rencontres se tiennent à Toulouse et dans son agglomération. Elles sont gratuites et ouvertes à tous les niveaux. L'adhésion à l'association est distincte et facultative : 25 € par an, avec un tarif solidaire à 10 € pour les personnes concernées par le RSA, l'ASPA, l'ASI, l'AAH, l'ASS ou le CEJ.