Pourquoi l'IA industrielle passe du cloud à l'usine

Un défaut apparaît sur un composant qui circule sur une chaîne de production. Une caméra capture l’image, un modèle d’IA l’analyse et la pièce est retirée avant d’atteindre l’étape suivante. L’ensemble du processus de décision peut devoir s’effectuer en quelques millisecondes. Envoyer l’image vers une plateforme cloud distante, attendre une réponse et dépendre d’une connexion externe ininterrompue introduit des délais que le processus ne peut pas toujours tolérer. C’est pourquoi l’IA industrielle se rapproche de plus en plus des machines qui génèrent les données. Au lieu de transmettre chaque image, signal de vibration ou mesure de machine vers un environnement cloud central, les fabricants déploient des capacités de calcul directement au sein des usines, des cellules de production et des équipements industriels. Cette évolution est souvent qualifiée d’« edge » IA. Ce terme peut sembler n'être qu'une nouvelle tendance en matière d'infrastructure, mais le raisonnement industriel est simple : certaines décisions sont trop urgentes, trop gourmandes en données ou trop cruciales sur le plan opérationnel pour dépendre entièrement d'un traitement à distance. Le cloud ne disparaît pas de l’IA industrielle. Il reste précieux pour l’entraînement des modèles, la comparaison des performances entre les sites et la gestion de vastes réseaux de production. L’architecture émergente répartit le travail de manière plus réfléchie. Les plateformes centrales assurent l’évolutivité et la coordination, tandis que la périphérie gère les décisions qui doivent rester proches de la production.

L'usine ne peut pas toujours attendre le cloud

De nombreuses applications bureautiques peuvent supporter un léger retard. Un assistant de document qui met plusieurs secondes à préparer un résumé peut tout de même s'avérer utile. Les systèmes de production fonctionnent dans des conditions différentes.

Une application de contrôle qualité peut inspecter des dizaines de pièces par seconde. Un système de surveillance des machines doit détecter une vibration anormale avant qu'elle n'entraîne des dommages matériels. Un véhicule autonome circulant dans un entrepôt doit réagir immédiatement lorsqu'une personne ou un obstacle se trouve sur son chemin.

La valeur d'un système d'IA dépend en partie de sa rapidité d'action. Même un modèle extrêmement précis perd de son utilité lorsque la réponse est fournie après que l'événement de production concerné s'est déjà produit.

L'exécution du modèle en périphérie réduit la distance entre l'observation et la réponse. Les données peuvent être traitées sur un ordinateur industriel, un contrôleur, un capteur ou un serveur local de l'usine, sans passer par un centre de données externe. La réponse est ainsi plus rapide et moins dépendante de la qualité du réseau global.

Cela revêt une importance particulière dans les applications en boucle fermée, où la sortie de l'IA modifie le processus lui-même. Un système peut ajuster le réglage d'une machine, rejeter un produit défectueux ou modifier le mouvement d'un équipement. Plus l'IA se rapproche du contrôle physique, plus il devient difficile de considérer la latence comme un simple détail technique.

La production doit se poursuivre même lorsque la connexion est interrompue

Les usines ne peuvent pas partir du principe que la connectivité externe sera toujours disponible. Les réseaux peuvent tomber en panne, les services cloud subir des interruptions et les sites distants peuvent disposer d'une bande passante limitée. Une chaîne de production qui dépend d'une connexion continue à une plateforme distante hérite de toutes ces vulnérabilités.

L'IA en périphérie permet à certaines applications de continuer à fonctionner en local. Un système d'inspection visuelle peut ainsi poursuivre la classification des produits, tandis qu'une application de surveillance continue d'analyser les signaux des machines, même en cas d'interruption de la communication avec la plateforme centrale.

Le système pourra synchroniser les résultats ultérieurement, une fois la connexion rétablie. Il n'est pas nécessaire d'interrompre la production simplement parce que l'infrastructure numérique globale est temporairement indisponible.

Il ne faut pas confondre cette capacité avec une indépendance totale vis-à-vis des systèmes centraux. Les modèles nécessitent toujours une maintenance, un suivi des performances et des mises à jour occasionnelles. Toutefois, un déploiement en périphérie bien conçu permet de dissocier la continuité opérationnelle immédiate de la coordination à plus long terme.

Cette distinction est importante pour les fabricants qui évaluent la résilience de leurs systèmes. Ils doivent savoir quelles applications d'IA peuvent être suspendues en toute sécurité, lesquelles nécessitent un processus de secours et lesquelles doivent continuer à fonctionner localement dans presque toutes les circonstances.

Le transfert des données industrielles coûte cher

Les usines modernes peuvent générer d'énormes quantités de données. Les caméras haute résolution, les capteurs acoustiques, l'imagerie thermique et les systèmes de commande des machines peuvent produire des flux continus dont le transfert et le stockage deviennent rapidement coûteux.

Toutes ces informations ne sont pas forcément utiles. Une caméra chargée de surveiller un processus stable peut enregistrer des milliers de produits normaux pour chaque défaut inhabituel. Un capteur de vibrations peut générer des mesures en continu, alors que les ingénieurs s'intéressent principalement aux tendances indiquant une détérioration.

Le traitement en périphérie permet aux fabricants d'analyser les données brutes localement et de ne transmettre que les informations pertinentes. Le système peut ainsi envoyer les anomalies détectées, des images sélectionnées, des mesures compressées ou des indicateurs de performance agrégés, plutôt qu'un flux continu.

Cela permet de réduire la charge sur le réseau et les coûts liés au stockage dans le cloud. Cela peut également rendre les projets d'IA industrielle plus réalisables dans des environnements où la connectivité est limitée ou lorsque le nombre de machines rendrait une transmission en continu peu rentable.

Cette approche nécessite une grande prudence. Conserver trop peu de données peut compliquer l'analyse des défaillances ou le réentraînement ultérieur du modèle. En revanche, tout envoyer dans le cloud peut s'avérer inutile et coûteux. Les fabricants doivent donc établir des règles précisant quelles données restent sur site, lesquelles sont transférées et pendant combien de temps chaque type d'information est conservé.

L'architecture des données devrait refléter l'objectif de l'application plutôt que de reposer sur l'hypothèse selon laquelle une collecte plus importante de données se traduit automatiquement par une meilleure intelligence artificielle.

Les connaissances sensibles relatives à la production peuvent rester au sein de l'usine

Les données industrielles révèlent souvent bien plus que l'état d'une machine. Elles peuvent mettre en lumière les volumes de production, les paramètres de processus, la conception des produits, les problèmes de qualité et la manière dont une entreprise fabrique un composant exclusif.

La transmission de ces informations à une plateforme externe peut être acceptable dans le cadre d'un contrat et d'une architecture de sécurité adaptés. Dans d'autres cas, l'entreprise peut préférer les conserver au sein de l'usine ou dans sa propre infrastructure contrôlée.

L'IA en périphérie permet de réduire le volume de données opérationnelles sensibles qui quittent le site. Le modèle traite les images ou les signaux localement et ne transmet que la classification ou l'alerte qui en résulte. Un fabricant peut ainsi utiliser l'IA sans avoir à transférer l'intégralité des données brutes de production à un tiers.

Cela vaut tout particulièrement pour les secteurs où la propriété intellectuelle fait partie intégrante du processus de production. Un bruit inhabituel, un réglage de machine ou un type d'usure des outils peuvent révéler des informations que les concurrents jugeraient précieuses.

Le traitement local n'élimine pas les risques liés à la sécurité. Les terminaux périphériques doivent eux-mêmes être protégés, mis à jour et surveillés. Une usine abritant des centaines d'ordinateurs industriels connectés peut constituer une vaste surface d'attaque lorsque ces systèmes sont mal gérés.

L'avantage réside dans le contrôle. Les fabricants peuvent décider où les informations sont traitées et réduire les transferts inutiles au-delà des frontières organisationnelles et géographiques.

L'IA en périphérie rend l'inspection visuelle plus évolutive

La vision industrielle est l'une des applications les plus évidentes de l'IA industrielle en périphérie. Les caméras permettent d'inspecter des surfaces, de vérifier l'assemblage, d'identifier les composants manquants et de détecter des écarts qui seraient difficiles à repérer en s'appuyant uniquement sur des règles conventionnelles.

Le volume des données d'image rend le traitement local particulièrement intéressant. Plutôt que de transmettre chaque image, le modèle peut classer les produits à proximité de la chaîne de production et ne conserver que certains exemples sélectionnés. Le système est capable de réagir suffisamment rapidement pour retirer une pièce défectueuse ou alerter un opérateur avant que d'autres unités ne soient affectées.

Il s'agit également d'un domaine où les conditions industrielles diffèrent considérablement de celles d'un laboratoire contrôlé. L'éclairage change, les surfaces réfléchissent la lumière différemment, les matériaux varient et les machines génèrent des vibrations. Un modèle qui donne de bons résultats lors d'un essai pilote peut voir ses performances se dégrader lorsqu'il est confronté à une autre équipe de travail, à un autre lot de fournisseur ou à une autre cadence de production.

L'infrastructure en périphérie ne se limite pas à l'inférence, c'est-à-dire au moment où le modèle évalue de nouvelles données. Elle permet également de collecter le contexte de production pertinent et des exemples sélectionnés en vue d'un réentraînement. Les images associées à un nouveau type de défaut peuvent être envoyées vers un environnement central, intégrées à un modèle mis à jour, puis redistribuées vers les sites de production concernés.

Il en résulte une interaction permanente entre l'action sur le terrain et l'amélioration au niveau central.

La surveillance des machines tire parti de l'intelligence locale

La maintenance prédictive est souvent présentée comme une application d'analyse dans le cloud. Les données des capteurs sont collectées sur les machines, transmises à une plateforme centrale, puis analysées afin de détecter les signes d'une défaillance future.

La technologie « edge » prend toute sa valeur lorsque la surveillance doit être continue, que le volume de signaux est important ou qu'une alerte doit être déclenchée immédiatement. Un capteur intelligent peut analyser directement les données de vibrations, de température ou acoustiques et détecter les écarts avant d'envoyer une alerte.

Le traitement local permet également de distinguer les signaux pertinents du bruit industriel habituel. C'est important, car les environnements industriels ne sont pas statiques. Une machine peut se comporter différemment selon le matériau, l'outil, la vitesse et l'étape de production. Une mesure isolée provenant d'un capteur n'a souvent que peu de sens sans contexte opérationnel.

La recherche sur les systèmes de capteurs industriels à auto-apprentissage s'intéresse de plus en plus à cette relation entre les signaux et les conditions de processus. L'objectif n'est pas simplement de détecter qu'une mesure a changé, mais de déterminer si ce changement indique une usure de l'outil, un problème de qualité ou une variation attendue de la production.

Il reste toutefois difficile d'y parvenir de manière fiable. Les modèles doivent fonctionner en dehors des tests contrôlés, s'adapter sans entraîner de comportement instable et fournir des alertes auxquelles les équipes de maintenance peuvent se fier. Une application qui génère trop de fausses alertes finira par être ignorée.

L'IA en périphérie rend techniquement possible la surveillance en temps réel. Elle ne dispense toutefois pas d'une validation minutieuse par rapport au processus physique.

L'« edge » et le « cloud » ont des rôles différents

Les débats sur l'informatique en périphérie et l'informatique en nuage peuvent laisser entendre que les fabricants doivent choisir une architecture plutôt qu'une autre. L'IA industrielle est toutefois plus susceptible de s'appuyer sur les deux.

Le cloud est particulièrement adapté à l'entraînement de modèles nécessitant une grande puissance de calcul, à l'analyse de données à grande échelle et aux comparaisons entre usines. Un fabricant peut s'en servir pour identifier des schémas de défaillance récurrents, évaluer les performances à l'échelle d'un réseau de production et coordonner la mise en service de modèles mis à jour.

L'edge est mieux adapté à l'exécution locale, aux décisions à faible latence et aux applications qui doivent continuer à fonctionner en cas de problème de connectivité. Il permet de traiter les données sensibles à proximité de leur source et de filtrer les informations avant leur transmission.

Un modèle d'inspection visuelle peut ainsi être entraîné de manière centralisée à partir d'exemples provenant de plusieurs usines, puis déployé localement sur chaque ligne de production. Les données de performance et les cas inhabituels sont renvoyés vers la plateforme centrale, où le modèle est amélioré avant que la version suivante ne soit distribuée.

Ce cycle « de la périphérie au cloud » s'impose progressivement comme l'architecture industrielle la plus réaliste. Il allie apprentissage centralisé et action locale, plutôt que de contraindre chaque étape à s'inscrire dans un même environnement.

Le plus difficile est d'assurer la cohérence. Les fabricants doivent savoir quelle version d'un modèle est installée sur chaque appareil, quand elle a été mise à jour et si ses performances ont évolué. Le déploiement de l'IA sur des centaines de machines pose un problème de gestion qui relève autant de l'exploitation de logiciels industriels que de la science des données.

L'IA locale nécessite toujours une gestion centralisée

Le fait de décentraliser l'intelligence vers les machines ne signifie pas pour autant que chaque site de production puisse fonctionner de manière indépendante.

Les appareils périphériques nécessitent des correctifs de sécurité, des contrôles d'accès et une surveillance. Les modèles doivent faire l'objet d'une gestion des versions, de tests de performances et d'un processus de mise à jour contrôlé. Les journaux doivent être disponibles lorsqu'une décision erronée affecte la qualité ou la production.

En l'absence de gestion centralisée, l'IA en périphérie peut rapidement se fragmenter. Différents sites peuvent utiliser des modèles différents, appliquer des règles incohérentes ou reporter des mises à jour importantes, car l'arrêt du système est source de désagréments. L'entreprise perd alors la capacité de comprendre le comportement de l'application sur l'ensemble de son réseau.

Les plateformes industrielles sont de plus en plus souvent conçues pour répondre à ce problème en permettant la gestion centralisée des modèles et des applications, tout en garantissant leur exécution locale. Une entreprise peut ainsi déployer un modèle validé, surveiller son état et le remplacer sans avoir à reconstruire l'application dans chaque usine.

Ce contrôle centralisé revêt une importance particulière lorsque l'IA intervient dans les décisions opérationnelles. Le fabricant doit pouvoir savoir quel modèle a évalué un produit ou généré une alerte. Si un défaut échappe au contrôle, les ingénieurs doivent être en mesure de reconstituer la configuration du système à ce moment-là.

La périphérie rapproche le calcul de la production. La gouvernance doit toutefois continuer à s'étendre à l'ensemble de l'organisation.

Le « Factory Hardware » n'est pas un centre de données classique

Dans le domaine de l'IA industrielle, on ne peut pas se contenter d'installer une infrastructure cloud standard à côté d'une machine et partir du principe que cela fonctionnera.

Les environnements de production sont exposés à la poussière, à la chaleur, aux vibrations et aux interférences électromagnétiques. Les équipements peuvent être amenés à fonctionner pendant des années, alors que le matériel informatique grand public est remplacé beaucoup plus fréquemment. Les créneaux de maintenance sont limités, car la mise à jour d'un appareil peut interrompre la production.

Les systèmes industriels en périphérie nécessitent donc un matériel robuste et un cycle de vie adapté aux technologies opérationnelles. Ils doivent pouvoir se connecter aux contrôleurs, capteurs et réseaux industriels existants, dont certains ont été conçus bien avant que l'IA ne devienne d'actualité.

La capacité de calcul constitue une autre contrainte. Les modèles avancés peuvent nécessiter des processeurs puissants, mais les usines sont également soumises à des contraintes d'espace, d'énergie et de refroidissement. Un modèle qui fonctionne bien dans un centre de données en cloud devra peut-être être compressé ou adapté avant de pouvoir fonctionner efficacement à proximité de la machine.

Ces compromis confèrent toute son importance au choix du modèle. Le modèle le plus complet est rarement le choix qui s'impose d'emblée. Dans les applications industrielles, on tire souvent davantage profit d'un modèle plus petit et spécialisé, qui réagit rapidement et de manière fiable, que d'un système plus général consommant nettement plus de ressources.

La cybersécurité s'intègre désormais à l'architecture de l'IA

Le déploiement de l'IA en périphérie réduit certains risques liés au transfert de données, tout en créant de nouvelles responsabilités en matière de sécurité. Chaque appareil connecté peut devenir un point d'entrée, en particulier lorsqu'il relie des systèmes opérationnels à l'infrastructure informatique de l'entreprise ou à des plateformes de gestion externes.

Les fabricants doivent protéger le modèle, les données qu'il traite et les actions qu'il peut déclencher. Un pirate informatique qui manipulerait un système d'inspection visuelle pourrait entraîner le rejet de produits conformes ou la validation de produits défectueux. Une ingérence dans un modèle de maintenance pourrait masquer les signes d'une défaillance de l'équipement.

La sécurité doit donc être conçue en parallèle de l'application. Les appareils doivent utiliser des identités contrôlées, des autorisations restreintes et des mécanismes de mise à jour sécurisés. La segmentation du réseau permet de limiter la portée des actions d'un attaquant si un système est compromis.

Les usines doivent également prévoir un plan d'exploitation en cas d'indisponibilité d'un système en périphérie. Une chaîne de production ne doit pas devenir dangereuse simplement parce qu'une application d'IA a été mise hors service lors d'un incident de sécurité. Une inspection manuelle, des règles conventionnelles ou une autre méthode de secours peuvent encore s'avérer nécessaires.

Plus l'IA s'implique dans les opérations physiques, plus la cybersécurité et la sécurité fonctionnelle se recoupent.

Toutes les applications industrielles d'IA ne doivent pas nécessairement être déployées en périphérie

L'intérêt du traitement local peut inciter les fabricants à intégrer dans leurs usines davantage de capacités informatiques que nécessaire. L'infrastructure en périphérie engendre des coûts propres : matériel, déploiement, maintenance et assistance spécialisée sur plusieurs sites.

Les applications qui ne nécessitent pas d'intervention immédiate peuvent s'avérer plus efficaces dans le cloud. La planification stratégique de la production, l'analyse comparative à l'échelle du réseau et l'analyse de la demande à long terme tirent généralement profit d'une centralisation des données et des capacités de calcul. Un rapport généré une fois par semaine ne nécessite pas de temps de réponse de l'ordre de la milliseconde.

Le choix de l'emplacement approprié dépend de la tâche à accomplir. Les fabricants doivent tenir compte de la latence, de la connectivité, de la sensibilité des données, du volume, des exigences en matière de disponibilité et des conséquences d'une interruption.

Un test utile consiste à se demander ce qui se passe lorsque la connexion au cloud est interrompue. Si le processus peut attendre, une exécution centralisée peut suffire. Si la qualité de la production, la sécurité ou la continuité risquent d’être affectées, la capacité locale prend alors toute son importance. Une deuxième question concerne les données elles-mêmes. Lorsque les informations brutes sont trop sensibles, trop volumineuses ou évoluent trop rapidement pour être transférées efficacement, leur traitement à la source peut s’avérer plus pertinent.

Commencez par la contrainte de production

Les entreprises industrielles n’ont pas besoin d’une stratégie d’IA en périphérie déconnectée de leurs priorités opérationnelles. Elles doivent identifier les cas où l’architecture actuelle empêche le bon fonctionnement d’une application utile. Peut-être que l’inspection visuelle est trop lente lorsque les images quittent le site. Une usine éloignée ne peut pas compter sur une connectivité stable. Les données des machines sont trop volumineuses pour être transférées de manière rentable, ou encore les connaissances relatives à la production doivent rester au sein de l’installation. Ces contraintes constituent un point de départ plus clair que le simple fait d’adopter la technologie en périphérie parce qu’elle est à la mode. Le fabricant peut définir le temps de réponse requis, le niveau d’interruption acceptable, les données pertinentes et le processus de secours avant de choisir l’infrastructure. Les projets pilotes doivent être testés dans des conditions réelles de production plutôt que dans des environnements de réseau et de laboratoire idéaux. L’entreprise doit mesurer non seulement la précision du modèle, mais aussi la latence, la fiabilité, les besoins en maintenance et l’impact d’une panne. Le modèle doit ensuite être considéré comme un élément d’un système industriel plus vaste. Les capteurs, la connectivité, le matériel informatique, les contrôles de sécurité et les procédures humaines déterminent tous ensemble si l’application crée de la valeur opérationnelle. L’IA industrielle se rapproche des machines, car les usines imposent des contraintes que le calcul centralisé ne peut pas toujours satisfaire à lui seul. Les décisions doivent être prises rapidement, la production doit rester disponible et les données sensibles ne peuvent pas être déplacées sans limite. L’usine du futur ne concentrera probablement pas toute l’intelligence en un seul endroit. Elle assurera l’apprentissage et la coordination de manière centralisée, exécutera certaines tâches de manière sélective en périphérie et maintiendra un contrôle humain lorsque les enjeux l’exigeront. L’architecture importera moins par l’emplacement apparent de l’IA que par sa capacité à agir avec la rapidité, la fiabilité et la sécurité requises par la production.