IA embarquée (edge) ou cloud : où faire tourner l'inspection ?

Comparatif de l'exécution embarquée et de l'exécution serveur pour une inspection véhicule, et pourquoi l'architecture hybride s'impose en pratique.

Une inspection de véhicule au smartphone mobilise deux familles de traitements très différentes : un guidage en temps réel pendant la capture, qui doit réagir image par image, et une analyse fine des dommages, qui tolère quelques secondes mais exige de la précision. Ces deux besoins ne se satisfont pas au même endroit.

Cet article compare l'exécution embarquée, dite edge, et l'exécution côté serveur sur sept critères concrets, puis décrit l'architecture hybride qui s'impose en pratique.

Edge et cloud : de quoi parle-t-on exactement

L'IA embarquée, ou edge, désigne l'exécution du modèle directement sur le terminal de l'utilisateur, à l'aide des accélérateurs matériels du téléphone. Le modèle est intégré à l'application, converti dans un format mobile puis souvent quantifié, c'est-à-dire recodé sur des entiers plus courts pour réduire sa taille et accélérer son exécution.

L'exécution cloud consiste à transmettre l'image ou la vidéo à un serveur, qui exécute le modèle et renvoie le résultat. Le terminal ne fait que capturer, compresser et afficher. Les ressources de calcul sont alors mutualisées et pratiquement sans limite de taille de modèle.

Ces deux options ne s'excluent pas. La question n'est pas « edge ou cloud » mais « quel traitement à quel endroit », comme le montre l'analyse des critères qui suivent.

Latence et guidage en temps réel

C'est le critère le plus discriminant. Un guidage utile doit réagir pendant que l'utilisateur bouge : indiquer qu'il est trop près, que la face avant n'est pas entièrement cadrée, que le mouvement est trop rapide. Ce retour doit intervenir en quelques dizaines de millisecondes, faute de quoi il décrit une situation déjà passée et devient contre-productif.

Un modèle embarqué atteint ce budget sans difficulté particulière, puisqu'aucune donnée ne quitte le terminal. Une boucle passant par le réseau additionne la compression de l'image, le trajet aller, l'attente d'exécution côté serveur et le trajet retour. Même sur un réseau performant, la variabilité de cette latence rend le guidage image par image peu fiable, et la moindre dégradation de couverture l'interrompt.

À l'inverse, l'analyse détaillée intervient après la capture. Une seconde ou deux d'attente y sont sans conséquence sur l'expérience, ce qui ouvre la voie au traitement serveur. Cette distinction structure les parcours de capture vidéo guidée.

Connectivité et consommation de données mobiles

Les inspections se déroulent rarement dans de bonnes conditions réseau. Parkings souterrains de concession, sous-sols d'immeuble, parcs de stockage éloignés, zones blanches : la couverture y est intermittente ou nulle. Une architecture entièrement dépendante du réseau échoue purement et simplement dans ces situations, ou contraint l'utilisateur à se déplacer, ce qui dégrade le taux de complétion du parcours.

Le volume transmis est le second enjeu. Une vidéo d'inspection complète pèse plusieurs dizaines de mégaoctets. Multiplié par le nombre d'inspections mensuelles d'un réseau, ce volume représente une charge réelle sur les forfaits des opérateurs de terrain, en particulier en itinérance. Deux stratégies limitent la facture :

• sélection embarquée des images : le terminal ne transmet que les vues utiles, nettes et correctement cadrées, plutôt que le flux intégral ;
• transmission différée : la capture se termine hors ligne, les données partent lorsque le terminal retrouve une connexion, idéalement en réseau local sans fil.

Ces deux mécanismes supposent une intelligence embarquée capable de juger de la qualité d'une prise de vue, ce qui ramène à un modèle local même dans une architecture majoritairement serveur.

Batterie, chauffe et ressources du terminal

L'exécution embarquée n'est pas gratuite. Faire tourner un réseau de neurones sur chaque image sollicite simultanément le capteur photo, l'écran et l'accélérateur de calcul. Sur une session prolongée, deux effets apparaissent : une consommation de batterie sensible et une élévation de température qui déclenche la limitation thermique du processeur. La cadence d'inférence chute alors, et le guidage se dégrade au moment où l'utilisateur en a le plus besoin.

Plusieurs leviers atténuent ce phénomène : n'analyser qu'une image sur trois ou sur cinq plutôt que chacune, réduire la résolution d'entrée du modèle de guidage, suspendre l'inférence lorsque le terminal est immobile, et utiliser les accélérateurs dédiés plutôt que le processeur généraliste. Le parc réel de terminaux impose par ailleurs de prévoir un mode dégradé pour les appareils anciens ou d'entrée de gamme.

Le cloud ne connaît aucune de ces contraintes, mais transfère une partie du coût énergétique sur la transmission radio, elle aussi consommatrice lorsqu'elle porte sur des dizaines de mégaoctets.

Taille des modèles et précision atteignable

Un modèle embarqué doit tenir dans l'application, se charger rapidement et s'exécuter avec une mémoire limitée. Cette contrainte impose des architectures compactes, une réduction de la résolution d'entrée et une quantification qui abaisse la précision numérique des calculs. Ces transformations dégradent généralement la qualité des prédictions, en particulier sur les petits objets, ceux-là mêmes qui posent déjà le plus de difficultés en inspection : rayures fines, éclats, impacts.

Côté serveur, aucune de ces limites ne s'applique. Il devient possible d'exécuter des modèles plus profonds, d'analyser les images en pleine résolution, de combiner plusieurs modèles spécialisés et d'agréger les résultats sur l'ensemble des vues d'un même véhicule. Une analyse à l'échelle du dossier complet, qui recoupe les vues pour éliminer les doublons et consolider les dommages, est difficilement envisageable sur un terminal.

Cette différence de capacité doit être quantifiée plutôt que supposée : le même protocole de mesure de performance des modèles doit être appliqué aux deux variantes, sur le même jeu de test, pour objectiver l'écart réel.

Déploiement, versionnement et coût d'infrastructure

Un modèle serveur se met à jour en une opération : la nouvelle version est déployée, tous les utilisateurs en bénéficient immédiatement, et un retour arrière est possible en quelques minutes. Un modèle embarqué suit le cycle de l'application mobile, avec validation par les magasins d'applications et adoption progressive par les utilisateurs. Plusieurs versions du modèle coexistent alors dans le parc pendant des semaines.

Cette coexistence a une conséquence directe sur la traçabilité : un rapport d'inspection doit indiquer quelle version du modèle a produit ses conclusions, faute de quoi il devient impossible d'expliquer un écart entre deux dossiers. Certains dispositifs permettent de télécharger un modèle mis à jour sans republier l'application, ce qui réduit la latence de déploiement mais impose une gestion rigoureuse de la compatibilité.

Sur le plan économique, les structures de coût s'opposent. L'embarqué déporte le calcul sur des terminaux déjà payés : le coût marginal d'une inspection supplémentaire est proche de zéro, au prix d'un effort d'ingénierie d'optimisation et de compatibilité. Le cloud facture à l'usage, avec un coût qui croît linéairement avec le volume, mais il mutualise les ressources et supprime les problèmes de parc hétérogène. Au-delà d'un certain volume, l'arbitrage devient une question de calcul et non de principe, et rejoint les considérations d'intégration par interface applicative.

Confidentialité et localisation des données

Une vidéo d'inspection contient bien plus que de la tôle : plaque d'immatriculation, intérieur du véhicule, parfois des passants ou une adresse visible en arrière-plan. Le traitement embarqué présente ici un avantage structurel, puisqu'une partie de l'analyse peut s'effectuer sans qu'aucune image ne quitte le terminal. Il permet notamment d'appliquer localement un floutage des visages et des plaques avant toute transmission, réduisant l'exposition des données.

Le traitement serveur implique en revanche un transfert, donc des questions de localisation de l'hébergement, de chiffrement en transit et au repos, de durée de conservation et d'encadrement contractuel des sous-traitants. Ces obligations sont parfaitement gérables, mais elles doivent être documentées ; elles sont détaillées dans notre article sur les données personnelles présentes dans les images d'inspection.

Le choix d'architecture n'est donc pas neutre au regard de la conformité, en particulier pour les usages impliquant des particuliers, comme les états des lieux en autopartage.

Tableau comparatif et architecture hybride

Critère	IA embarquée (edge)	Traitement cloud
Latence	Quelques dizaines de millisecondes, stable	Variable, dépendante du réseau
Guidage temps réel	Adapté	Inadapté en pratique
Fonctionnement hors connexion	Possible	Impossible
Données mobiles consommées	Faibles à nulles pendant la capture	Élevées, proportionnelles au média transmis
Batterie et température	Sollicitation forte du terminal	Sollicitation limitée au transfert
Taille et finesse du modèle	Contrainte par la mémoire et la quantification	Pratiquement sans limite
Mise à jour	Cycle applicatif, versions coexistantes	Immédiate et centralisée
Coût marginal par inspection	Proche de zéro	Croissant avec le volume
Exposition des données	Réduite, traitement local possible	Transfert à encadrer contractuellement
Hétérogénéité du parc	Contrainte forte	Sans objet

La lecture de ce tableau ne désigne pas un gagnant : elle désigne une répartition. L'architecture hybride place sur le terminal un modèle léger chargé du cadrage, de la détection de flou, du suivi de la progression autour du véhicule et de la sélection des images utiles. Elle réserve au serveur les modèles lourds de détection et de qualification des dommages, la consolidation à l'échelle du dossier, la lecture de la plaque d'immatriculation et la production du rapport.

Cette répartition procure trois bénéfices simultanés : un guidage fluide même sans réseau, un volume transmis réduit à ce qui est réellement exploitable, et une qualité d'analyse qui n'est pas bridée par le téléphone. Elle autorise aussi un floutage local avant transmission, qui réduit l'exposition des données personnelles sans dégrader l'analyse technique de la carrosserie.

Son coût est celui de la complexité : deux modèles à maintenir, deux cycles de mise à jour, une cohérence à garantir entre ce que le terminal annonce pendant la capture et ce que le serveur conclut ensuite. Un utilisateur guidé vers une vue jugée correcte par le modèle embarqué, puis informé que cette vue est inexploitable après analyse serveur, perd confiance dans l'outil. Chez Lucius AI, cette cohérence est traitée comme une exigence de conception, décrite sur la page consacrée à notre technologie.

Le bon point de départ reste l'usage : volumétrie attendue, qualité de couverture réseau sur les sites concernés, sensibilité des données, parc de terminaux, et niveau de finesse exigé du rapport. Pour confronter ces paramètres à votre contexte, vous pouvez prendre contact.