L'IA en edge en production : quatre modes de défaillance et les preuves qui les détectent

Sauf mention contraire, les citations de sources publiées en anglais sont traduites par nos soins ; les extraits de textes juridiques de l'Union européenne reprennent leur version française officielle.

Un modèle peut réussir son évaluation hors ligne et pourtant échouer en tant que produit. En edge, le système livré comprend le modèle converti, le runtime, l'accélérateur, le boîtier, les capteurs, le mécanisme de mise à jour, les opérateurs et le chemin de reprise. La question utile n'est donc pas seulement le modèle fonctionne-t-il ? Elle est : quelles preuves montrent que ce système précis continue de fonctionner à l'intérieur de son périmètre d'exploitation prévu ?

Ce livre blanc utilise quatre classes de défaillance comme pre-mortem : l'artefact déployé, l'enveloppe d'exploitation en régime soutenu, l'entrée terrain et le cycle de vie de la flotte. Elles ne constituent pas une affirmation statistique sur chaque incident, et elles ne s'excluent pas mutuellement. Elles offrent un moyen compact de révéler des lacunes coûteuses avant qu'un pilote ne devienne une flotte. Pour chaque classe, ce document expose le mécanisme, les signaux de détection, les mesures d'atténuation, la mesure et la recherche qui les étaye.

Statut des sources — revues le 4 novembre 2026. Les mécanismes s'appuient sur de la documentation primaire, des articles de recherche et des synthèses du droit de l'UE publiées par la Commission européenne. Les seuils et limites d'acceptation doivent être fixés pour le produit concerné ; ce document n'invente pas de chiffres universels. Les quantités marquées hypothétiques sont des illustrations.

Synthèse

• Le calcul livré est une chaîne, pas un fichier de poids : la documentation d'ONNX Runtime indique que la quantification « peut affecter négativement la précision d'un modèle », et le partitionnement du graphe ainsi que le prétraitement modifient eux aussi ce qui s'exécute.
• La précision moyenne peut masquer la régression qui compte : des travaux de recherche sur les réseaux compressés ont constaté que la compression « affecte de manière disproportionnée les performances du modèle sur la longue traîne sous-représentée de la distribution des données » ; les critères de mise en production doivent donc porter sur les tranches critiques.
• Le débit de pointe est la mauvaise métrique d'achat : la documentation Jetson décrit un bridage pour surintensité dont « l'OS hôte n'est pas notifié », et une prépublication de 2026 a mesuré un téléphone perdant « près de la moitié de son débit en deux itérations ».
• La confiance seule n'est pas une alarme de dérive : les benchmarks de décalage de distribution font état de « performances hors distribution nettement inférieures aux performances en distribution », et la calibration post-hoc « s'avère effectivement insuffisante » en cas de décalage.
• La mise à jour et la reprise exigent un modèle de menace et une validation (commit) conditionnée au niveau applicatif : TUF nomme les attaques par retour arrière (rollback) et par gel (freeze), tandis qu'un schéma A/B seul gère un échec de démarrage, pas une version qui démarre et décide mal.
• L'exposition avant un arrêt est une variable de conception : un modèle de raisonnement original la borne par la taille de la cohorte, le rythme d'installation, la latence de détection et la latence de propagation de l'arrêt.
• Les preuves expirent quand le système change : une matrice d'impact des changements originale montre lequel des quatre dossiers de preuves chaque type de changement invalide.

Le problème et pourquoi il compte maintenant

Du pilote à la flotte

Un pilote peut être jugé sur la précision mesurée sur des données réservées et sur une unité de démonstration qui fonctionne. Une flotte est jugée sur la question de savoir si de nombreuses heures-appareil d'exploitation, sur plusieurs sites et révisions matérielles, restent à l'intérieur d'un périmètre acceptable, et si l'organisation peut modifier et remettre en état les appareils lorsque ce n'est pas le cas.

Une étude de cas publiée dans ACM Computing Surveys, Challenges in Deploying Machine Learning, rattache les difficultés rapportées aux étapes du processus de déploiement et conclut que « les praticiens rencontrent des problèmes à chaque étape du processus de déploiement ». Operationalizing Machine Learning, fondé sur des « entretiens ethnographiques semi-structurés avec 18 MLE », nomme « trois variables qui déterminent le succès d'un déploiement de ML en production : vélocité, validation et versionnage ». Le déploiement en edge ajoute des contraintes physiques à chacune : la validation doit se faire sur la cible, et le versionnage doit couvrir le matériel et le firmware, pas seulement le code.

Contexte réglementaire et d'assurance

• Règlement sur la cyberrésilience (Cyber Resilience Act). La synthèse de la Commission européenne sur le CRA indique que le règlement répond à « l'absence de mises à jour de sécurité en temps utile » et « impose aux fabricants de gérer les vulnérabilités tout au long du cycle de vie de leurs produits ». Les obligations de notification « s'appliquent à partir du 11 septembre 2026 », et « les principales obligations introduites par le règlement s'appliqueront à partir du 11 décembre 2027 ».
• Règlement sur l'intelligence artificielle. La présentation du règlement sur l'IA par la Commission énumère, pour les systèmes à haut risque, un « niveau élevé de robustesse, de cybersécurité et d'exactitude » et exige que « les fournisseurs disposent d'un système de surveillance après commercialisation ». Après que l'omnibus sur l'IA est « entré en vigueur le 27 juillet 2026 », les règles de l'annexe III « ont été reportées au 2 décembre 2027 », et les règles applicables aux systèmes « intégrés dans des produits réglementés (annexe I) bénéficient d'une période de transition prolongée jusqu'au 2 août 2028 ». La question de savoir si un produit edge donné est à haut risque relève de la classification, à laquelle ce document ne répond pas.
• Rapport du NIST sur la surveillance. Le rapport du NIST AI 800-4, Challenges to the Monitoring of Deployed AI Systems énumère six catégories de surveillance — fonctionnalité, exploitation, facteurs humains, sécurité, conformité et impacts à grande échelle — ainsi que des obstacles, dont « la détection de la dégradation des performances et de la dérive » et « la fragmentation de la journalisation sur une infrastructure distribuée ». Il ne propose pas de score de dérive universel, et une équipe produit ne devrait pas en proposer non plus.

Aucun de ces textes ne prescrit l'ingénierie décrite ci-dessous ; ils augmentent le coût de ne pas pouvoir montrer ce qui est déployé, surveillé et mis à jour.

Le système livré

flowchart LR
  A["Point de contrôle d'entraînement"] --> B["Conversion et quantification"]
  B --> C["Runtime et fournisseurs d'exécution"]
  C --> D["Accélérateur et pilotes"]
  D --> E["Boîtier, alimentation et thermique"]
  E --> F["Capteurs et conditions terrain"]
  F --> G["Décisions et opérateurs"]
  G --> H["Surveillance et retour d'information"]
  H --> U["Mise à jour et reprise"]
  U --> B
  B -.-> M1["Frontière 1 : artefact"]
  E -.-> M2["Frontière 2 : enveloppe"]
  F -.-> M3["Frontière 3 : entrée terrain"]
  U -.-> M4["Frontière 4 : cycle de vie de la flotte"]

Analyse technique approfondie : quatre modes de défaillance

Mode de défaillance 1 : l'artefact déployé n'est pas l'artefact évalué

Mécanisme

Les checkpoints d'entraînement peuvent être convertis, fusionnés, quantifiés ou compilés pour un accélérateur cible. Trois mécanismes modifient le calcul :

1. Transformation numérique. La documentation d'ONNX Runtime sur la quantification indique : « La quantification n'est pas une transformation sans perte. Elle peut affecter négativement la précision d'un modèle. » La quantification statique « exécute d'abord le modèle sur un ensemble d'entrées appelées données de calibration » ; le jeu de calibration fait donc partie du modèle. Une forte baisse de précision « peut être causée par la saturation », et « la quantification par canal peut améliorer la précision des modèles dont les plages de poids sont étendues ».
2. Partitionnement du graphe. ONNX Runtime attribue les nœuds via l'interface GetCapability() des execution providers ; les providers sont « classés par priorité », et un nœud s'exécute sur le provider préféré « s'il en est capable, sinon via CPUExecutionProvider ». Un opérateur non pris en charge peut donc basculer silencieusement vers un composant plus lent.
3. Écart de pipeline. Les Rules of Machine Learning de Google définissent l'écart entraînement-service (training-serving skew) comme « une différence entre les performances pendant l'entraînement et les performances en service », y compris « un écart entre la manière dont vous traitez les données dans les pipelines d'entraînement et de service ». Sur un appareil embarqué, cet écart peut provenir d'une réimplémentation du redimensionnement, de l'ordre des couleurs, de la normalisation ou de la conversion d'unités.

Pourquoi la moyenne le masque

What Do Compressed Deep Neural Networks Forget? (Hooker et al.) a constaté que la précision globale « dissimule des différences significatives » : un sous-ensemble d'exemples, les Pruning Identified Exemplars, est « systématiquement plus affecté par l'introduction de la parcimonie », et ces exemples « sont surreprésentés parmi les images atypiques ou bruitées ». A White Paper on Neural Network Quantization (Nagel et al.) indique que la quantification post-entraînement sur 8 bits peut atteindre une précision proche de celle en virgule flottante, mais un chiffre de précision agrégé peut masquer une régression sur une classe rare et lourde de conséquences.

Signaux de détection

• les performances agrégées semblent acceptables alors qu'une classe ou une condition d'exploitation importante régresse ;
• un opérateur non pris en charge bascule vers un execution provider plus lent ;
• le prétraitement diffère par l'ordre des couleurs, le redimensionnement, la normalisation ou les unités des capteurs ;
• le hash du modèle est correct, mais le runtime, le jeu de calibration ou la version du compilateur n'est pas celui qui a été approuvé.

Mesure

Conditionnez la décision à la pire tranche critique, pas à la moyenne :

$\Delta_s = M_s^{\text{référence}} - M_s^{\text{déployé}}, \qquad \text{validé} \iff \forall s \in S_c,\ \Delta_s \le \tau_s$

Ici, chaque tranche s appartient à l'ensemble S_c pondéré par les conséquences, M est la métrique de la tâche, la référence est le pipeline en virgule flottante approuvé, le chiffre déployé provient de l'appareil cible exécutant le bundle complet, et la tolérance tau_s est fixée par tranche par le product owner. ONNX Runtime fournit des « API Python permettant de mettre en correspondance les tenseurs de poids et d'activations » entre modèles en virgule flottante et quantifiés — « c'est ce qu'on appelle le débogage de la quantification » — ce qui peut aider à analyser une tranche en échec.

Critère de vérification

Évaluez le bundle déployable sur l'appareil cible et comparez les sorties intermédiaires lorsque la chaîne d'outils le permet. Si une couche sensible ne peut pas atteindre le seuil d'acceptation après quantification, conservez une précision plus élevée pour cette partie ou choisissez une autre cible. Ne laissez pas une classe critique pour la sécurité ou la qualité se diluer dans une moyenne au moment de la décision. Rassemblez dans un seul enregistrement de mise en production :

1. le checkpoint source et son hash ;
2. la configuration de conversion/quantification et la version de l'outil ;
3. les versions et la provenance des jeux de données de calibration/évaluation ;
4. l'implémentation du pré- et du post-traitement ;
5. l'identité du runtime, du backend, du pilote et de l'appareil cible ;
6. les résultats par classe, par condition et par conséquence ;
7. la décision d'acceptation et son responsable nommé.

Preuves à conserver. Une model card ne suffit pas. Conservez le manifeste signé du bundle, la nomenclature de la chaîne d'outils, le journal de conversion, le rapport de placement des opérateurs, le rapport d'évaluation, les limites connues et la cible de retour arrière.

Mode de défaillance 2 : la cible ne tient pas son enveloppe d'exploitation en régime soutenu

Mécanisme

Un kit de développement sur un banc ouvert n'est pas le système thermique déployé. Le boîtier, la température ambiante, le flux d'air, le montage, la poussière, l'alimentation et les charges de travail cohabitantes déterminent les fréquences et le débit soutenables. Le guide puissance et performances de Jetson Linux pour la série Orin de NVIDIA documente plusieurs couches de contrôle entre le modèle et sa fréquence d'horloge :

• Modes d'alimentation. Le module « prend en charge plusieurs budgets de puissance optimisés, tels que 10 watts, 15 watts et 30 watts », sélectionnés avec nvpmodel.
• Gestion thermique logicielle. « La gestion thermique utilise des points de déclenchement pour communiquer avec les zones thermiques » ; le bridage réduit la fréquence et la tension, ce qui « aide à contrôler la température » ; et « un point de déclenchement critique provoque un arrêt thermique logiciel ».
• Protection matérielle. Pour les « alarmes OC » de surintensité, le firmware « déclenche un bridage matériel des horloges ». « Comme le bridage logiciel, le bridage matériel peut réduire les performances », et « l'OS hôte n'est pas notifié de ces événements ». L'ultime sécurité « est une réinitialisation thermique matérielle, ou thermtrip ».

Ces détails sont propres à un fournisseur ; l'enseignement général est que les contrôles de puissance et thermiques contraignent dynamiquement les performances, et que certains sont invisibles à moins que l'équipe ne lise les compteurs — le guide énumère des nœuds sysfs donnant « le nombre d'événements OC survenus ».

stateDiagram-v2
  state "Fréquences nominales" as Nominal
  state "Bridage logiciel" as Soft
  state "Bridage matériel" as Hard
  state "Mode produit dégradé" as Degraded
  state "Arrêt thermique ou réinitialisation" as Shutdown
  [*] --> Nominal
  Nominal --> Soft : point de déclenchement franchi
  Nominal --> Hard : alarme de surintensité
  Soft --> Nominal : la température redescend
  Hard --> Nominal : l'événement disparaît
  Soft --> Degraded : plancher d'échéance manqué
  Hard --> Degraded : plancher d'échéance manqué
  Degraded --> Nominal : marge rétablie
  Soft --> Shutdown : point de déclenchement critique
  Shutdown --> [*]

Le mode produit dégradé (« Degraded product mode ») n'est pas une fonctionnalité de la plateforme : c'est au produit de le définir (délestage de charge, fréquence d'images réduite, état sûr ou message à l'opérateur).

Données de recherche sur la charge soutenue

La prépublication de 2026 LLM Inference at the Edge (Tummalapalli et al.) a évalué « Qwen 2.5 1.5B (quantifié sur 4 bits) sur quatre plateformes » avec « un prompt fixe de 258 tokens sur 20 itérations à chaud par appareil ». Elle indique que « pour les plateformes mobiles, la gestion thermique prime sur la puissance de calcul de pointe comme contrainte principale » : « l'iPhone 16 Pro perd près de la moitié de son débit en deux itérations », et « le S24 Ultra subit un plancher de fréquence GPU strict imposé par l'OS qui interrompt entièrement l'inférence », tandis que « le Hailo-10H maintient 6.9 tok/s sous 2 W avec une variance quasi nulle ». Les auteurs qualifient ces résultats de « caractérisations du déploiement au niveau de la plateforme pour un seul modèle et un seul type de prompt ».

Mesure

MLPerf Inference (ISCA 2020) définit une méthode de mesure comparable de l'inférence. Ses règles d'inférence utilisent une « estimation de latence au 90%-ile avec arrêt anticipé » pour le scénario Single Stream, une « estimation de latence au 99%-ile avec arrêt anticipé » pour le scénario Multistream, et une durée minimale de « 600 secondes ». Deux enseignements sont transposables : rapporter un percentile de queue sous une charge définie, et fixer une durée minimale. La durée d'un benchmark ne prouve pas l'atteinte du régime thermique permanent ; le test produit doit durer jusqu'à ce que la température et les fréquences cessent de dériver au coin le plus chaud plausible.

Une métrique de raisonnement originale, le ratio de marge soutenue, rend la question d'achat explicite :

$H = \frac{\text{débit au percentile de queue, régime permanent, pire coin de l'enveloppe}}{\text{débit requis par le produit}}$

avec les services cohabitants en fonctionnement. Une valeur inférieure à 1 signifie que le produit ne satisfait pas son exigence à l'intérieur de son enveloppe déclarée ; une valeur proche de 1 ne laisse aucune marge pour la poussière, le vieillissement des ventilateurs ou une mise à jour vers un modèle plus lourd. Un ratio complémentaire, le débit en régime permanent rapporté au débit à froid, montre à quel point une démonstration courte était trompeuse. Aucun des deux n'a de seuil universel.

Signaux de détection

• la latence ou le respect des échéances de trame se dégrade après la montée en température ;
• la file d'attente s'allonge alors que des tests courts ont réussi ;
• des événements de tension ou thermiques déclenchent un bridage, des réinitialisations ou l'indisponibilité d'accélérateurs ;
• un processus cohabitant crée une pression mémoire ou accapare de la puissance de calcul pendant une fenêtre critique.

Critère de vérification

Définissez une matrice de l'enveloppe d'exploitation avant de choisir le matériel :

La métrique d'acceptation est le plancher soutenu à l'intérieur de l'enveloppe déclarée, avec un chemin de dégradation défini — et non le chiffre le plus élevé observé.

Preuves à conserver. Stockez la révision du boîtier/de la nomenclature, le firmware et le mode d'alimentation avec l'essai. Un résultat thermique ne peut pas être réutilisé après un changement de dissipateur, de politique de ventilation, de boîtier ou de charge de travail sans évaluer si une revalidation est nécessaire.

Mode de défaillance 3 : l'entrée terrain sort du périmètre validé

Mécanisme

Les systèmes physiques ne reçoivent pas un flux stationnaire. Les capteurs vieillissent, se déplacent, s'encrassent ou sont remplacés. L'éclairage, la météo, les surfaces, les recettes de procédé, le firmware et le comportement humain changent. Le modèle peut rester inchangé alors que la relation entre l'entrée, le contexte et la décision requise change. Trois types de changement appellent des détecteurs différents : la distribution des entrées se déplace (décalage de covariables), le capteur rapporte quelque chose de physiquement différent pour la même scène (défaut de mesure), ou la décision correcte pour une même entrée change (changement de concept). La surveillance des entrées peut révéler certains décalages de distribution et défauts de mesure ; déterminer si la décision requise a changé nécessite un contexte supplémentaire ou des preuves issues des résultats.

Données de recherche

• Le décalage dégrade la précision. WILDS rassemble des décalages réels, « tels que des décalages entre hôpitaux pour l'identification de tumeurs ; entre pièges photographiques pour le suivi de la faune », et indique que « l'entraînement standard produit des performances hors distribution nettement inférieures aux performances en distribution ».
• Les altérations du quotidien sont mesurables. ImageNet-C (ICLR 2019) « évalue les performances face à des altérations et perturbations courantes » plutôt que face à des attaques adverses. Pour un produit à caméra, une suite d'altérations permet de répéter les effets de la saleté, du flou et des changements d'éclairage.
• La confiance n'est pas une alarme fiable. Can You Trust Your Model's Uncertainty? (NeurIPS 2019) a étudié « l'effet du décalage du jeu de données sur la précision et la calibration » et a constaté que « la calibration post-hoc traditionnelle s'avère effectivement insuffisante », tandis que « certaines méthodes qui marginalisent sur plusieurs modèles donnent des résultats étonnamment bons ».
• La détection doit être conçue. Failing Loudly (NeurIPS 2019) a constaté qu'« une approche fondée sur des tests à deux échantillons, utilisant des classifieurs pré-entraînés pour la réduction de dimension, donne les meilleurs résultats » sur l'ensemble des décalages étudiés.

Le NIST AI RMF Core demande que les performances soient « démontrées dans des conditions similaires au(x) contexte(s) de déploiement » (MEASURE 2.3), que « les limites de la généralisabilité au-delà des conditions dans lesquelles la technologie a été développée soient documentées » (MEASURE 2.5), que le système « puisse défaillir de manière sûre, en particulier s'il est amené à fonctionner au-delà des limites de ses connaissances » (MEASURE 2.6), ainsi que des mécanismes permettant de « supplanter, désengager ou désactiver » (MANAGE 2.4).

Signaux de détection par couche

Les signaux rapides ne sont pas des preuves de préjudice, et les preuves de préjudice arrivent lentement ; aucun score de dérive unique ne porte la décision.

sequenceDiagram
  participant Dev as Appareil en périphérie
  participant Fleet as Backend de la flotte
  participant Own as Responsable de la réponse
  participant Ops as Opérateur du site
  Dev->>Dev: Consigner la décision avec l'identifiant du capteur et le contexte
  Dev->>Fleet: Envoyer les agrégats et des entrées échantillonnées
  Fleet->>Fleet: Comparer à la référence de validation
  Fleet->>Own: Lever une alarme avec la cohorte concernée
  Own->>Ops: Demander une inspection ou des échantillons étiquetés
  Ops-->>Own: Transmettre les constats
  Own->>Fleet: Décider de recalibrer, réentraîner, restreindre ou retirer
  Fleet->>Dev: Appliquer la configuration ou le mode de repli
  Note over Dev: Le mode sûr doit fonctionner si le backend est injoignable

Critère de vérification

Construisez la surveillance autour de la conséquence de la défaillance, et non autour de la métrique que la plateforme MLOps expose par défaut. Au minimum :

1. spécifier le périmètre d'entrée et d'exploitation prévu ;
2. journaliser l'identité du capteur, sa calibration/son firmware et le contexte pertinent avec chaque décision ou agrégat ;
3. surveiller séparément la qualité des données, la fonctionnalité du système, les interventions des opérateurs et les signaux de résultat ;
4. prédéfinir l'action de revue, de repli et de collecte de données pour chaque alarme ;
5. tester la détection avec des décalages et des défauts de capteur connus ;
6. prouver que le mode sûr/dégradé fonctionne lorsque la surveillance elle-même est indisponible.

Une statistique de distance entre distributions peut être utile, mais elle ne constitue pas à elle seule une preuve de préjudice. De même, une distribution d'entrée stable ne prouve pas que le modèle reste correct.

Preuves à conserver. Conservez la spécification de surveillance, la justification des alarmes, le responsable de la réponse, les échantillons d'événements terrain, l'analyse des corrections manuelles/abstentions et les décisions de recalibration, de réentraînement ou de retrait, versionnés par rapport aux identités de l'appareil, du capteur et du modèle.

Mode de défaillance 4 : la flotte ne peut pas être mise à jour ni remise en état de manière sûre

Mécanisme

Une équipe de laboratoire peut réinstaller une machine en panne ; un appareil distribué peut être distant, connecté par intermittence ou coûteux à atteindre. Les mises à jour de modèle interagissent avec le code applicatif, les schémas, la configuration et l'état mis en cache, et une image téléchargée n'est pas un produit remis dans un état connu et sain.

• Modèle de menace. The Update Framework nomme les attaques par retour arrière (rollback ; des fichiers « plus anciens que ceux que le client a déjà vus »), les attaques par gel indéfini (freeze) et les attaques par combinaison (mix-and-match), et ses principes incluent « la confiance doit expirer si elle n'est pas renouvelée » et « l'utilisation de clés multiples et un seuil/quorum de signatures ».
• Vérification à l'échelle de la flotte. Uptane, « un cadre de mise à jour logicielle sécurisée pour les véhicules terrestres », sépare un dépôt d'images (Image repository) d'un dépôt directeur (Director repository) qui « indique aux ECU quelles images seront installées ». Il exige que « la vérification complète SOIT effectuée par les ECU primaires » et que « les ECU DOIVENT disposer d'une source de temps sûre ». Ce schéma convient à toute flotte où ce qui existe et ce que cet appareil doit exécuter sont des décisions distinctes.
• Installation robuste. La RFC 9019 de l'IETF indique que « les appareils ne doivent pas tomber en panne lorsqu'une perturbation, telle qu'une coupure d'alimentation ou une interruption réseau » survient, et qu'« un appareil auquel on présente un manifeste et un firmware anciens mais valides ne doit pas être amené par la ruse à installer ce firmware ».
• Reprise. La documentation de Mender décrit « un schéma à double redondance (également appelé schéma A/B) » : « au premier démarrage qui suit une mise à jour, le Mender Client valide (commit) la mise à jour » ; si l'appareil redémarre avant la validation, le bootloader « reviendra à la version précédente en réinversant les partitions active et inactive ». La SP 800-193 du NIST formule l'objectif comme la protection, plus « la détection des modifications non autorisées qui surviennent » et « la reprise rapide et sécurisée après des attaques ».

Un schéma A/B résout un échec de démarrage, pas une version qui démarre, passe une vérification du système d'exploitation puis décide mal. L'étape de validation (commit) doit être conditionnée à la santé au niveau applicatif.

stateDiagram-v2
  state "Métadonnées vérifiées" as Verified
  state "Écrite dans l'emplacement inactif" as Written
  state "Démarrage d'essai" as Trial
  state "Contrôle de santé applicatif" as Health
  state "Validée (commit)" as Committed
  state "Annulée (rollback)" as Rolled
  [*] --> Verified : signatures, version et compatibilité validées
  Verified --> Written
  Written --> Trial : redémarrage
  Trial --> Health : démarre
  Trial --> Rolled : échec du démarrage ou redémarrage avant validation
  Health --> Committed : chaîne d'inférence et configuration validées
  Health --> Rolled : critères de santé non remplis
  Rolled --> [*]
  Committed --> [*]

Déploiement progressif et modèle d'exposition

Le SRE workbook de Google définit le canary comme « un déploiement partiel et limité dans le temps d'un changement dans un service, accompagné de son évaluation », note que l'impact « est directement proportionnel à la quantité de trafic exposée aux défauts », et exige que « vous puissiez comparer les signaux du canary aux signaux du groupe témoin ». Pour une flotte, l'équivalent du trafic est le nombre d'appareils exécutant la version.

Un modèle de raisonnement original, dérivé de cette proportionnalité plutôt que mesuré, borne le nombre d'appareils exposés avant l'arrêt d'une version :

$E \approx \min\Big(C_k,\; r \cdot \big(t_{\text{detect}} + t_{\text{halt}}\big)\Big)$

où C_k est la taille de la cohorte en cours, r le rythme auquel les appareils installent la version, t_detect le délai entre la première installation et une alarme fiable, et t_halt le délai nécessaire pour qu'une décision d'arrêt atteigne les appareils. Les défauts propres au terrain, détectés par des signaux de résultat lents, allongent t_detect ; les plafonds de cohorte comptent donc davantage que la vitesse de déploiement. Et pour les appareils connectés par intermittence, t_halt inclut le délai jusqu'à la prochaine connexion au serveur ; un appareil qui a déjà téléchargé un bundle peut l'installer avant d'apprendre l'arrêt. Arrêter un déploiement et rappeler une version sont deux capacités distinctes à tester.

Signaux de détection

• une combinaison valide mais incompatible de modèle, runtime et application atteint un appareil ;
• une coupure d'alimentation ne laisse aucune image amorçable ou opérationnelle ;
• une vérification de santé valide le système d'exploitation alors que le chemin d'inférence est défaillant ;
• le retour arrière restaure les binaires mais pas une configuration ou une base de données locale compatible ;
• un déploiement atteint une trop grande partie de la flotte avant qu'un défaut propre au terrain ne soit visible.

Critère de vérification

Traitez la mise à jour et la reprise comme une capacité produit dotée de ses propres tests d'acceptation :

• métadonnées et artefacts signés, rôles de clés de confiance et procédure de rotation/révocation ;
• manifeste de compatibilité tenant compte du matériel et des dépendances ;
• installation atomique ou conception équivalente résistante aux interruptions ;
• critères de santé au niveau applicatif, pas seulement un démarrage réussi ;
• retour arrière automatique ou chemin de reprise explicitement testé ;
• cohortes progressives avec conditions d'arrêt et un responsable de décision habilité ;
• injection de fautes pour un téléchargement interrompu, une installation interrompue, une signature invalide, un bundle incompatible, une vérification de santé en échec et une liaison de retour (backhaul) indisponible ;
• un chemin d'intervention sur site pour les appareils qui ne peuvent pas être remis en état à distance.

Preuves à conserver. Conservez la décision de mise en production, les signatures, la progression des cohortes, les résultats de santé, les événements d'arrêt/de retour arrière et les transitions d'état des appareils. L'enregistrement de mise à jour doit indiquer quel appareil a reçu quel bundle complet, pourquoi il a progressé, et quel chemin de reprise subsiste.

Données de recherche : ce que les sources établissent et n'établissent pas

Les résultats de recherche proviennent de benchmarks publics soumis à des décalages contrôlés ; leur transposition à un site particulier est donc une hypothèse à tester. Les documents des fournisseurs font autorité sur les mécanismes, mais restent muets sur les marges de conception. Les preuves propres au produit comblent cette lacune.

Analyse économique et décisionnelle

Facteurs de coût

Le coût de chaque mode de défaillance peut s'exprimer dans des unités qu'un product owner peut estimer :

• Artefact : heures d'ingénierie pour reconstruire l'évaluation sur le matériel cible ; heures-accélérateur pour la calibration et l'évaluation par tranche ; heures-appareil de décisions incorrectes après une mauvaise mise en production.
• Enveloppe : heures d'essai en chambre ou en boîtier ; marge matérielle achetée (watts de puissance thermique de conception, refroidissement) ; heures-appareil en mode dégradé.
• Entrée terrain : heures d'étiquetage pour les signaux de résultat ; bande passante de la liaison de retour pour les entrées échantillonnées ; temps des opérateurs consacré aux corrections manuelles et aux inspections.
• Cycle de vie : stockage d'une seconde partition ; heures d'ingénierie pour les clés et l'injection de fautes ; heures de technicien et temps d'arrêt pour les appareils qui ne peuvent pas être remis en état à distance.

L'asymétrie tient au fait que les coûts avant déploiement sont bornés et connus, tandis que les coûts sur le terrain croissent avec la taille de la flotte et le délai de détection.

Tableau de décision

Organisation et responsabilités

Les frontières traversent les lignes organisationnelles : machine learning, matériel, exploitation et sécurité de la plateforme. Chaque dossier de preuves a besoin d'un responsable nommé ayant l'autorité de bloquer une mise en production, et la décision d'avancer ou de suspendre a besoin d'un responsable capable de mettre en balance la conséquence pour le client et les quatre dossiers. La formulation de MANAGE 2.4 du NIST, des responsabilités « attribuées et comprises », constitue un test utile.

Une méthode à appliquer : la Boundary Evidence Review

La Boundary Evidence Review (revue des preuves aux frontières) est un outil de raisonnement de Hyperion, pas une norme publiée ni une preuve issue du terrain. Elle combine les quatre dossiers de preuves avec une matrice d'impact des changements, de sorte que les preuves sont traitées comme quelque chose qui expire lorsque le système change.

Étape 1 : une revue, quatre dossiers

Un critère n'est franchi que lorsque les preuves, le seuil d'acceptation et le responsable sont explicites. La démo a fonctionné ne constitue une entrée dans aucun dossier.

Étape 2 : la matrice d'impact des changements

L'enseignement original est que les frontières sont couplées : un changement visant l'une peut invalider silencieusement les preuves détenues pour une autre. La matrice est un raisonnement fondé sur les mécanismes ci-dessus ; les équipes doivent l'adapter à leur architecture. « Ré-exécuter » signifie que les preuves d'acceptation du dossier ne sont plus valides ; « revérifier » signifie qu'une évaluation bornée décide si une ré-exécution est nécessaire.

flowchart TD
  A["Changement proposé"] --> B["Consulter la matrice d'impact des changements"]
  B --> C{"Un dossier marqué ré-exécuter ?"}
  C -- "oui" --> D["Ré-exécuter les dossiers concernés sur la cible"]
  C -- "non" --> E{"Un dossier marqué revérifier ?"}
  E -- "oui" --> F["Le responsable évalue et consigne sa justification"]
  E -- "non" --> G["Consigner le changement au regard des preuves actuelles"]
  D --> H{"Tous les seuils atteints ?"}
  F --> H
  H -- "oui" --> I["Passer au déploiement progressif"]
  H -- "non" --> J["Suspendre, réorienter ou arrêter"]
  G --> I

Exemple détaillé (hypothétique)

Toutes les quantités ci-dessous sont hypothétiques, choisies à titre d'illustration uniquement. Un appareil d'inspection à caméra sur une ligne de production doit classer des pièces dans une échéance par trame. Un bundle proposé met à jour le runtime et fait passer le modèle de poids sur 16 bits à des poids entiers sur 8 bits afin de libérer de la puissance de calcul pour une seconde caméra.

• Consultation de la matrice. Une nouvelle quantification associée à une mise à jour du runtime marque le dossier artefact ré-exécuter, l'enveloppe revérifier, les moniteurs d'entrée terrain réétablir la référence et le dossier cycle de vie retester la compatibilité et le retour arrière.
• Artefact. Supposons que la métrique globale baisse d'une fraction de point, mais que la tranche rare « fissure capillaire » baisse de plus que sa tolérance. Le débogage de la quantification désigne le premier bloc de convolution ; conserver ce bloc en précision plus élevée ramène la tranche dans sa tolérance. La moyenne seule aurait été validée.
• Enveloppe. Avec la seconde caméra en fonctionnement, supposons que le débit de queue en régime permanent au coin le plus chaud du boîtier donne un ratio de marge soutenue de 0.9, alors que le chiffre à froid donnait 1.4. Acheter sur la base du chiffre à froid aurait conduit à livrer un dépassement d'échéance ; il faut donc changer soit la seconde caméra, soit la conception thermique.
• Cycle de vie. Supposons que les appareils se connectent au serveur toutes les quelques heures et que l'alarme fiable la plus lente (résultats de retouche) prenne environ une journée. Sans suspension entre les cohortes, les cohortes suivantes pourraient recevoir la version avant l'arrivée d'une alarme ; la première cohorte est donc plafonnée et maintenue pendant toute la fenêtre du signal de résultat.

Le changement qui ressemblait à « une simple mise à jour du modèle » a touché les quatre frontières.

Feuille de route de mise en œuvre

Limites et questions ouvertes

• Pas de seuils universels. Aucune source citée ne fournit d'écart par tranche, de ratio de marge, de statistique de dérive ou de taille de cohorte acceptable ; ce sont des décisions propres au produit, au secteur et au cadre réglementaire.
• La transposition n'est pas prouvée. Les résultats sur les décalages et les altérations proviennent de jeux de données publics ; le résultat sur la charge soutenue couvre un modèle et un prompt sur quatre plateformes.
• Spécificité fournisseur. Les mécanismes thermiques et d'alimentation cités proviennent d'un seul fournisseur ; d'autres accélérateurs exposent des contrôles différents et peuvent ne pas exposer de compteurs de bridage.
• Le changement de concept est lent à détecter. Lorsque la décision correcte change pour une même entrée, la surveillance des entrées seule ne le révèle pas ; il faut un contexte supplémentaire ou des preuves issues des résultats, et la latence de ces preuves borne le temps de réponse de tout moniteur.
• Le modèle d'exposition est une simplification. Il suppose un rythme d'installation constant et un temps de détection unique ; les flottes réelles présentent une connectivité hétérogène et plusieurs sources d'alarme.

FAQ

La quantification sur 8 bits est-elle sûre à livrer ?

Cela dépend des tranches qui comptent. Nagel et al. indiquent que la quantification post-entraînement sur 8 bits peut atteindre une précision proche de la virgule flottante ; d'autres travaux montrent que la compression peut pénaliser de manière disproportionnée les exemples atypiques. Conditionnez la décision à la pire tranche critique mesurée sur la cible.

Combien de temps doit durer un test d'endurance thermique ?

Jusqu'à ce que les fréquences, la température et la latence de queue cessent de dériver dans la condition de boîtier la plus chaude plausible, avec la charge cohabitante en fonctionnement. Un minimum de benchmark comme les 600 secondes de MLPerf garantit la comparabilité, pas le régime thermique permanent.

La confiance du modèle peut-elle servir d'alarme de dérive ?

Pas à elle seule. Il a été montré que la calibration se dégrade en cas de décalage du jeu de données ; la confiance devrait donc être une couche parmi d'autres, aux côtés de la santé des capteurs, des tests sur la distribution des entrées, de l'interaction avec les opérateurs et des signaux de résultat.

Un schéma de partitions A/B résout-il la reprise ?

Il résout un échec de démarrage. Il ne détecte pas une version qui démarre mais décide mal, et ne restaure pas une configuration ou des données locales incompatibles, à moins que la validation (commit) ne soit conditionnée à la santé au niveau applicatif et que le retour arrière ne couvre l'état.

La conclusion au niveau du système

Les défaillances de l'IA en edge peuvent être des défaillances d'intégration et de cycle de vie qui s'expriment à travers une interface en forme de modèle. C'est pourquoi la responsabilité produit compte : quelqu'un doit relier la conséquence pour le client, l'évaluation du modèle, l'enveloppe matérielle, l'exploitation et la reprise avant le prochain engagement. Pour la décision de placement en amont de ces frontières, voir Cloud, Edge or Controller? A Decision Architecture for Industrial AI ; pour les robots, voir Reliable Autonomy: From Robot Demonstration to Sustained Duty.

Utilisez ce document comme un pre-mortem, puis adaptez les seuils et les preuves à l'usage prévu, aux normes sectorielles et au droit applicable. Pour une revue structurée, le Physical AI Product System et la Product Decision Review transforment ces dossiers en une décision explicite : avancer, suspendre, réorienter ou arrêter.