Guide maintenance prédictive IA 2026 : la méthode Nehos en 4 phases

#Chapitre 1 — État de la maintenance industrielle France 2026

La photographie 2026 du parc industriel français est sans ambiguïté : une grande partie des ETI et grandes entreprises manufacturières opère encore en maintenance majoritairement réactive ou préventive systématique calendaire. C'est cette répartition qui explique les niveaux de pertes observés sur le terrain.

#Le coût caché de la maintenance non planifiée

Les benchmarks sectoriels (McKinsey Industry 4.0, France Industrie, ADEME industrie) convergent vers un constat : la maintenance non planifiée pèse une part importante des coûts totaux de maintenance d'une ETI manufacturière française. Ces pertes se décomposent en trois grandes catégories : la production perdue (heures d'arrêt × marge horaire, généralement la part la plus lourde), le coût direct d'intervention en urgence (pièces, sous-traitants, heures supplémentaires), et le coût indirect (qualité dégradée, pénalités client, déclassement). Le chiffrage exact se fait site par site, pendant la phase d'audit.

Ce coût caché est massivement sous-estimé dans la comptabilité analytique. Beaucoup d'ETI agrègent leurs interventions de maintenance sous une ligne unique « maintenance » sans isoler ce qui est planifié de ce qui est subi. Une de nos premières missions dans la phase audit est typiquement de reconstituer cette ventilation à partir des bons de travaux GMAO et des journaux d'arrêt production sur 12 à 24 mois glissants.

#Pénurie de compétences : un accélérateur structurel

La pénurie de techniciens et d'ingénieurs de maintenance expérimentés est largement documentée dans l'industrie française (France Industrie). Les départs en retraite des baby-boomers ne sont compensés ni par les sorties d'écoles d'ingénieurs, ni par les BTS / DUT industriels qui peinent à recruter. Cette pénurie est structurelle.

Conséquence directe : la maintenance prédictive cesse d'être un sujet d'optimisation pour devenir un sujet de continuité d'activité. Quand une ETI manufacturière perd son technicien sénior expert capable de diagnostiquer une vibration anormale au son, il n'y a souvent personne pour le remplacer. L'IA prédictive devient le seul moyen réaliste de conserver cette capacité de diagnostic sur le parc.

#Pression réglementaire NIS2 et AI Act

Deux régimes réglementaires accélèrent l'adoption. NIS2 (Directive UE 2022/2555, transposée en France octobre 2024) impose aux opérateurs essentiels — dont les énergéticiens régionaux, les industries critiques, certains acteurs de l'eau, du transport, de la santé — un niveau de résilience opérationnelle élevé.

Une maintenance majoritairement réactive ne tient pas l'examen NIS2 d'un contrôle d'inspection. L'AI Act, en application progressive jusqu'au 2 août 2027, classe les systèmes IA appliqués à l'infrastructure critique comme à haut risque (Annexe III, point 2). Concrètement : un opérateur énergétique qui déploie une IA prédictive sur ses transformateurs HTA doit appliquer le régime haut risque complet (gestion des risques, gouvernance des données, journalisation immuable, supervision humaine, audit biais, déclaration européenne).

Voir le secteur Énergie & Industrie Nehos pour le détail des spécificités réglementaires sectorielles, et le glossaire AI Act pour le détail des obligations.

#Chapitre 2 — Classique vs prédictive vs prescriptive : Maturity Model M0-M5

Nous utilisons en mission un modèle de maturité simple et opérationnel à six niveaux (M0 à M5). Il permet de positionner objectivement un site industriel avant d'engager une démarche prédictive et de calibrer le saut visé.

#M0 — Maintenance réactive pure

Les interventions se font uniquement après défaillance. Pas de plan préventif, pas de GMAO ou GMAO non utilisée. Les arrêts non planifiés pèsent très lourd dans le budget maintenance. Profil typique : PMI familiale, parc machines vieillissant, équipe maintenance réduite. La marche vers M1 est obligatoire avant toute démarche prédictive — il faut d'abord structurer la donnée.

#M1 — Préventive systématique calendaire

Interventions planifiées à intervalle régulier indépendamment de l'état réel (vidange tous les X mois, révision tous les Y cycles). GMAO en place, plan de maintenance documenté. Le coût des arrêts non planifiés reste élevé. Profil typique : ETI manufacturière avec un parc de dizaines de machines et une équipe maintenance structurée. C'est le niveau de départ de la majorité des ETI françaises.

#M2 — Préventive conditionnelle

Interventions déclenchées par des indicateurs d'état (température, vibration, heures de fonctionnement) lus manuellement ou via capteurs simples. Pas encore de modélisation prédictive. Profil : ETI mature, équipes maintenance structurées avec techniciens vibration / thermographie qualifiés.

#M3 — Prédictive par règles métier

Déploiement de capteurs IoT, collecte continue, règles de seuils paramétriques (si vibration > X mm/s alors alerte). Pas d'IA encore. Le gain est déjà mesurable. Profil : grands sites industriels matures, énergéticiens, certains opérateurs eau/transport.

#M4 — Prédictive IA

Modélisation par algorithmes d'apprentissage automatique (XGBoost, LSTM, Random Forest, anomaly detection non supervisée) entraînés sur l'historique. Détection d'anomalies subtiles, prédiction de fenêtre de défaillance. C'est le niveau cible standard pour une ETI manufacturière en 2026.

#M5 — Prescriptive IA

L'IA ne se limite plus à prédire la défaillance mais recommande l'action optimale (quand intervenir, quelles pièces commander, quel technicien mobiliser) en intégrant les contraintes production, le stock pièces, la disponibilité des équipes. Couplage avec le planning ERP. Cible pour les ETI matures à moyen terme, déjà en place sur certains grands sites énergétiques et aéronautiques.

#Cible réaliste : passer de M1 à M4

En pratique, la trajectoire que nous accompagnons le plus souvent est M1 vers M4. Sauter directement à M5 est un piège classique : l'organisation n'absorbe ni la transformation technologique ni la transformation culturelle. La méthode Nehos en 4 phases (chapitre 6) est conçue pour cette trajectoire M1→M4.

Le coût d'instrumentation dépend du nombre de points de mesure par machine (typiquement quelques points par machine critique) et du type de capteur : vibration, sondes thermiques fixes, unités acoustiques ultrasoniques. Il se chiffre au devis, après relevé des machines.

#Couche 2 — Gateway OPC-UA et acquisition

L'acquisition agrège les flux capteurs et les expose au réseau IT. Le standard de facto est OPC-UA (Unified Architecture, IEC 62541), maintenu par l'OPC Foundation. Avantages : interopérabilité native multi-constructeurs, chiffrement TLS, signature des messages, modèle d'information riche.

La gateway physique est typiquement un automate industriel ou un IPC durci (Siemens IOT2050, Beckhoff CX, ou solutions souveraines comme Pulse). Voir le glossaire OPC-UA pour le détail du protocole.

L'alternative ou complément, surtout pour les déploiements cloud-native, est MQTT (broker EMQX, recommandé en open source pour les charges ETI ; HiveMQ payant pour les grands déploiements). EMQX gère sans problème plusieurs centaines de milliers de devices connectés simultanément, supporte MQTT 5.0, WebSocket, Kafka bridge.

#Couche 3 — Base temporelle et stockage

Le stockage doit absorber des dizaines à centaines de milliers d'événements par seconde sans s'effondrer. InfluxDB (versions 2 et 3) est le choix dominant en 2026 sur l'open source. Compression efficace des séries temporelles, requêtes Flux performantes, intégration native avec Grafana pour le dashboarding.

Alternatives : TimescaleDB (extension PostgreSQL, intéressante si l'équipe maîtrise déjà Postgres), QuestDB (très performant mais moins riche fonctionnellement), Apache IoTDB (open source Apache, prometteur).

Le volume de données dépend du nombre de machines, du nombre de capteurs par machine et de la fréquence d'échantillonnage. Avec 10 Hz par capteur, il atteint rapidement des dizaines de millions de points par jour sur un parc d'ETI. Le stockage compressé InfluxDB reste raisonnable. Rétention recommandée : données brutes haute résolution sur 24 mois, données agrégées sur 5 ans.

#Couche 4 — Edge computing Nvidia Jetson

La modélisation prédictive doit pouvoir tourner au plus près de la machine, pour deux raisons : latence (un seuil critique doit déclencher une alerte en < 100 ms) et résilience réseau (un site industriel peut perdre WAN sans devoir perdre sa supervision). Nvidia Jetson Orin Nano (8 Go RAM, 40 TOPS) couvre une grande partie des besoins d'une ETI.

Jetson Orin NX (16 Go, 100 TOPS) pour les charges plus lourdes (computer vision combinée + prédictif). Voir documentation Nvidia Jetson developer.

L'alternative française est OVHcloud Edge ou les solutions Sigfox / Objenious sur LPWAN pour les sites éclatés à faible débit. Pour les sites avec excellente connectivité, l'edge peut être minimal et le calcul cloud (AWS SageMaker Edge, Azure IoT Edge, ou OVHcloud AI Endpoints).

#Couche 5 — Dashboard et alertes

La restitution opérationnelle doit être pensée pour les équipes maintenance, pas pour les datascientists. Grafana open source reste la référence dashboarding. Alertes via Slack / Teams / email / SMS pour les niveaux critiques, et idéalement push vers la GMAO existante (création automatique d'un bon de travaux). Intégration mobile pour le terrain via Grafana Mobile ou applications custom.

#Chapitre 4 — Modélisation IA : XGBoost, LSTM, Random Forest, Time-Series-Transformer

La modélisation prédictive applique trois familles d'algorithmes selon le contexte de données disponibles et la nature de la défaillance à anticiper. Le choix n'est jamais binaire — un déploiement réel combine généralement 2 à 4 modèles selon le type de machine et de panne.

#XGBoost — Tabular, défaillances bien caractérisées

XGBoost (Extreme Gradient Boosting) est l'outil de référence pour les données tabulaires avec features engineered. Idéal quand on dispose d'un historique GMAO riche (interventions, pièces remplacées, causes) couplé à des séries temporelles agrégées en features statistiques (moyenne, écart-type, kurtosis, skewness, FFT bands sur vibration).

On l'utilise par exemple en classification binaire « panne sous 30 jours / pas de panne », sur un historique de plusieurs mois représentatif des modes de défaillance.

Avantages : robuste, interprétable (SHAP values), entraînement rapide (quelques minutes à quelques heures sur ETI), excellent rapport performance/effort. C'est notre choix par défaut pour un POC.

#LSTM — Séries temporelles complexes, dépendances longues

LSTM (Long Short-Term Memory, famille des réseaux de neurones récurrents) et ses variantes GRU s'imposent quand la défaillance est précédée par une signature temporelle subtile sur plusieurs jours ou semaines. Exemple typique : dégradation progressive d'un roulement sphérique pendant 8-12 semaines avant rupture. XGBoost peine à capturer ces dépendances longues, là où LSTM excelle.

Limites : nécessite un volume de données d'entraînement substantiel (idéalement plusieurs cycles de défaillance complets), entraînement plus long (heures à jours sur GPU), moins interprétable. À réserver aux cas où XGBoost plafonne ou où la défaillance est intrinsèquement séquentielle.

#Random Forest — Baseline robuste, démarrage rapide

Random Forest (Breiman 2001) reste un excellent baseline. Moins performant que XGBoost en général mais plus simple à mettre en œuvre, moins sensible aux hyperparamètres, performances raisonnables même sur petits volumes de données (utile en début de POC avant d'avoir 18 mois d'historique). Notre recommandation : toujours produire un baseline Random Forest avant de passer à XGBoost ou LSTM, pour avoir un point de comparaison.

#Anomaly detection non supervisée

Quand l'historique de pannes labellisées est inexistant (cas fréquent en démarrage POC), l'anomaly detection non supervisée reste la voie pragmatique. Algorithmes : Isolation Forest, Autoencoder, One-Class SVM, LOF. L'idée : apprendre la signature « normale » du fonctionnement et détecter les déviations significatives. Avantage : pas besoin de labels. Limite : faux positifs élevés en démarrage, nécessite calibration progressive avec retours terrain.

#Hugging Face Time-Series-Transformer et nouveaux entrants

Depuis 2024-2025, les modèles Time-Series-Transformer disponibles sur Hugging Face (Amazon's autoformer, MOIRAI de Salesforce, Lag-Llama) émergent comme alternatives compétitives aux LSTM sur séries temporelles complexes. Avantages : zero-shot performant (utile en démarrage avant accumulation données), parallélisme entraînement supérieur.

Notre position pragmatique : tester en parallèle d'un baseline XGBoost / LSTM, basculer si le gain mesuré justifie le surcoût de complexité opérationnelle. Voir le glossaire LSTM et glossaire XGBoost pour les définitions techniques.

#Computer vision combinée — cas énergéticien régional

Pour les inspections visuelles (cuves de transformateur, lignes HT, équipements en milieu hostile), computer vision par CNN ou Vision Transformer complète utilement la modélisation vibratoire. Détection de fuites huile, traces d'arc, corrosion, végétation envahissante. Stack typique : YOLO v8/v9 ou Detectron2 entraînés sur dataset annoté in-house. Voir le glossaire computer vision.

#Chapitre 5 — Intégration GMAO : IBM Maximo, SAP PM, Carl Source

C'est le point qui décide du ROI réel. Une maintenance prédictive techniquement parfaite mais déconnectée de la GMAO existante reste un gadget supervisé manuellement par un technicien dédié — son ROI s'écroule. Avec intégration GMAO, l'alerte prédictive génère automatiquement un bon de travaux, alloue un technicien, commande la pièce de rechange, met à jour le planning production. C'est cette automatisation qui fait basculer le retour sur investissement.

#IBM Maximo Application Suite — Standard grandes industries

IBM Maximo (depuis 2020 Maximo Application Suite, MAS) est le standard sur les grands sites industriels énergie, oil & gas, transport, défense. Architecture Kubernetes, modules MAS Manage (GMAO cœur), MAS Predict (modèles prédictifs natifs), MAS Monitor (IoT), MAS Visual Inspection. Intégration avec une stack externe de maintenance prédictive (notre cas typique) via l'API REST Maximo OSLC ou via les Maximo Integration Services. Format pivot : OSLC AM (Asset Management).

Notre approche standard : développer un connecteur middleware Python ou Node.js qui consomme nos alertes prédictives (Kafka ou webhook), enrichit avec les métadonnées InfluxDB pertinentes, et crée le bon de travaux Maximo via l'API REST avec préfixe identifiant IA (ex : « WO-AI-2026-001234 ») pour traçabilité audit. Voir documentation IBM Maximo developer.

#SAP PM — Standard ETI industrielles ERP SAP

SAP Plant Maintenance (intégré SAP ERP / SAP S/4HANA) est le standard chez les ETI industrielles qui ont déjà SAP en ERP cœur. Avantages d'intégration native avec les modules production planning, materials management, finance. Intégration externe via SAP Cloud Platform Integration (anciennement CPI), via SAP API Business Hub, ou via OData services exposés par S/4HANA.

Notre connecteur type crée des notifications M1/M2/M3 selon la criticité et déclenche les ordres de maintenance (PM01-PM05) appropriés.

Point d'attention spécifique SAP : les autorisations SAP sont fines et la mise en production demande la coordination du Compétence Center SAP du client. Prévoir plusieurs semaines de validation processus côté SAP avant industrialisation. Voir documentation SAP PM.

#Carl Source — Standard collectivités et opérateurs eau / énergie

Carl Source (Carl Software, éditeur français) est leader sur les segments collectivités, opérateurs eau, opérateurs transport urbain, hôpitaux. Architecture web native, API REST documentée, intégration plus rapide que Maximo ou SAP PM (mise en service généralement plus courte).

De nombreux énergéticiens régionaux et opérateurs eau / assainissement français utilisent Carl Source, ce qui en fait un choix pertinent pour nos missions secteur Énergie & Industrie sous contrainte NIS2.

#GMAO propriétaires legacy — Stratégie strangler

Une partie significative des ETI manufacturières françaises opère encore avec des GMAO propriétaires développées en interne dans les années 2000 (souvent PHP 4/5 + MySQL, parfois Access ou Filemaker pour les plus anciennes). L'intégration directe est souvent impossible. Notre approche standard : pattern strangler fig progressif.

Voir notre guide legacy modernization strangler pour la méthode complète. À court terme, nous interfaçons via base de données partagée ou échange CSV scheduled si les API n'existent pas, en parallèle d'un plan de modernisation de la GMAO.

Cette expertise legacy industriel est portée chez Nehos par Mohamed Charfeddine (Lead Dev PHP fullstack), qui a piloté plusieurs réinitialisations GMAO sur ETI manufacturing 2024-2026.

#Dashboards temps réel et alertes opérationnelles

Indépendamment de la GMAO cible, le dashboard temps réel doit servir deux populations : les équipes maintenance (vue par machine, historique 30 jours, alertes en cours) et les directions opérations / industriel (vue agrégée, KPI MTBF / MTTR / OEE par ligne, tendances mensuelles, ROI maintenance).

Architecture typique : Grafana pour les opérationnels, Metabase ou Tableau pour les directions, alimentés depuis InfluxDB et la GMAO via une couche de federation (Trino / dbt + warehouse intermédiaire).

#Chapitre 6 — Méthode Nehos en 4 phases

Notre méthode est inspirée de la Méthode Nehos ROI-First IA générale, adaptée aux spécificités industrielles. Quatre phases, dont la durée totale dépend du scope et du niveau de maturité initial.

#Phase 1 — Audit de faisabilité

L'objectif est de répondre à trois questions avant tout investissement : la maintenance prédictive a-t-elle un ROI mesurable sur ce site ? Les données nécessaires existent-elles ou doivent-elles être créées ? Quelle est la trajectoire de maturité réaliste (M0→M3 ? M1→M4 ?) ?

Livrables : cartographie des machines critiques avec scoring criticité (impact production × probabilité défaillance × coût intervention), qualification de la donnée disponible (capteurs existants, historique GMAO, journaux d'arrêt), business case ROI cible avec sensibilité (scénarios bas / médian / haut), identification des 1-2 équipements pilotes les plus pertinents, plan d'instrumentation et budget. Phase chiffrée sur devis, en 48 h après un premier échange.

#Phase 2 — POC sur 1-2 équipements pilotes

L'objectif est de valider la chaîne complète sur 1 à 2 équipements pilotes sélectionnés en phase 1 : instrumentation, acquisition, modélisation, restitution. Pas encore d'intégration GMAO complète (mock acceptable), pas d'industrialisation du déploiement.

Livrables : instrumentation des machines pilotes (capteurs commandés, installés, calibrés), stack technique déployée (gateway OPC-UA, broker EMQX, InfluxDB, Jetson edge, dashboard Grafana), premier modèle prédictif entraîné sur l'historique disponible (ou en anomaly detection si historique absent), restitution des indicateurs : précision, rappel, faux positifs, délai moyen de détection avant défaillance, comparaison avec la maintenance préventive calendaire actuelle. Phase chiffrée sur devis.

#Phase 3 — Décision go / no-go formelle

C'est la phase la plus importante méthodologiquement et celle que la plupart des prestataires escamotent. Comité de pilotage dédié (Direction Industrielle, Directeur Maintenance, DSI, RSSI, contrôle de gestion, sponsor exécutif) en fin de POC. Présentation des résultats POC avec ROI mesuré et extrapolé sur le parc cible. Décision documentée d'industrialisation ou d'arrêt.

Critères de décision définis avec le client avant le POC : précision du modèle, taux de faux positifs, délai de détection avant défaillance sur les machines critiques, économies extrapolables sur le parc cible, retour sur investissement extrapolé, risque AI Act soutenable. Une décision no-go est acceptée et budgétée — c'est même un signal de maturité méthodologique.

#Phase 4 — Industrialisation

Déploiement sur le parc cible, intégration GMAO complète (Maximo / SAP PM / Carl Source / legacy via strangler), formation des équipes maintenance, supervision continue, audit AI Act haut risque si applicable.

Livrables : déploiement instrumentation parc cible (commande, installation, calibration), industrialisation stack technique (haute disponibilité, monitoring, sauvegardes), intégration GMAO bidirectionnelle (alerte → bon de travaux, retour → réentraînement modèle), formation équipes maintenance et opérations, dossier conformité AI Act (registre Annexe III, journalisation immuable, supervision humaine documentée, audit biais Aequitas), revue ROI à mois 6, 12, 18.

Phase chiffrée sur devis, en fonction du nombre de machines, du matériel et de l'intégration GMAO. Les économies cibles s'estiment à partir des mesures du POC, pas avant.

#Chapitre 7 — Exemples de situation : ETI manufacturing et énergéticien régional NIS2

Deux exemples de situation, construits pour illustrer la méthode. Ils ne décrivent pas des clients réels et ne comportent aucun résultat chiffré.

#Exemple 1 — ETI manufacturing avec un parc de machines critiques

Situation : une ETI française de transformation métallique, plusieurs sites de production, une quarantaine de machines critiques (presses hydrauliques, machines à commande numérique 5 axes, lignes de soudage robotisé, convoyeurs lourds). Niveau de maturité initial M1 (préventive calendaire), équipe maintenance dont plusieurs départs en retraite à anticiper. Sponsor : Directeur Industriel.

Phase 1 (audit) : diagnostic de la part des coûts de maintenance imputable aux arrêts non planifiés, à partir de la GMAO. Choix de 2 presses hydrauliques critiques comme pilotes (impact production maximal).

Phase 2 (POC) : instrumentation de chaque presse pilote avec capteurs vibration triaxiaux, sondes thermiques et capteur de courant moteur. Stack EMQX + InfluxDB + Jetson Orin Nano + Grafana. Modèle XGBoost comparé à une baseline Random Forest, entraîné sur l'historique GMAO. Mesure de la précision, du rappel, des faux positifs et du délai de détection.

Phase 3 (go formel) et phase 4 (industrialisation) : déploiement sur les machines critiques, intégration SAP PM (le client est sous SAP S/4HANA), formation des techniciens, chefs d'équipe et ingénieurs méthodes. Audit AI Act non requis (pas d'Annexe III pour la manufacture standard hors infrastructure critique), mais bonnes pratiques de journalisation immuable et de supervision humaine appliquées.

Ce que la démarche vise : une baisse des coûts de maintenance et des arrêts non planifiés, de meilleurs MTBF et MTTR sur les machines équipées, un retour sur investissement mesuré à partir des données du POC. Ce sont des objectifs, pas des résultats constatés.

Voir aussi le cas d'usage maintenance prédictive ETI manufacturing.

#Exemple 2 — Énergéticien régional NIS2, computer vision + prédictif fusionnés

Situation : un énergéticien régional français, distribution électrique BT/HTA, périmètre de plusieurs départements ruraux, un parc de transformateurs HTA et de nombreux kilomètres de lignes. Désigné opérateur essentiel NIS2, avec l'ANSSI comme référent.

Spécificité technique : double instrumentation. (a) Capteurs vibration + thermique + acoustique ultrasonique sur les transformateurs HTA pour détecter dégradation diélectrique, échauffement anormal, décharges partielles. (b) Computer vision par drone semestriel + caméras fixes sur points critiques pour détecter fuites huile transformateur, traces d'arc, végétation envahissante lignes HTA.

Stack : EMQX + InfluxDB cluster, Jetson Orin NX en edge sur sous-stations, modèle hybride XGBoost (séries temporelles) + YOLO v9 (computer vision), intégration Carl Source (GMAO de l'énergéticien). Hébergement chez un hébergeur qualifié SecNumCloud, selon le cadre NIS2 et la politique de souveraineté énergétique.

Conformité AI Act haut risque : système classé Annexe III point 2 infrastructure critique. Dossier à constituer : registre du système IA, gestion des risques documentée, gouvernance des données (qualité, biais, drift), journalisation immuable, supervision humaine explicite (toute action générée par l'IA validée par un opérateur sénior avant intervention), audit biais Aequitas régulier, déclaration européenne.

Ce que la démarche vise : un meilleur MTBF sur les transformateurs, un MTTR réduit, des défaillances majeures évitées, et une conformité NIS2 documentée pour l'audit ANSSI. Ce sont des objectifs, pas des résultats constatés.

Voir le secteur Énergie & Industrie Nehos pour le contexte sectoriel complet.

#Chapitre 8 — Conformité AI Act haut risque infrastructure critique

La maintenance prédictive appliquée à l'infrastructure critique relève systématiquement du régime haut risque AI Act au sens de l'Annexe III, point 2. Cette section synthétise les obligations et la méthode Nehos pour les couvrir sans surcoût excessif.

#Qui est concerné par le régime haut risque

L'Annexe III point 2 du Règlement AI Act vise les systèmes IA destinés à être utilisés comme composants de sécurité dans la gestion et l'exploitation d'infrastructures numériques critiques, du trafic routier, ou de la fourniture d'eau, de gaz, de chauffage ou d'électricité. Concrètement : la maintenance prédictive sur transformateurs HTA, lignes HT, postes électriques, stations de pompage, captages eau potable, équipements de transport public lourd, sites industriels classés Seveso.

À l'inverse, la maintenance prédictive sur une presse hydraulique d'une usine de transformation métallique standard ne relève pas du régime haut risque.

#Sept obligations clés à couvrir

Obligation 1 — Système de gestion des risques (article 9 AI Act) : analyse des risques continue sur tout le cycle de vie du système IA, documentée et révisée. Obligation 2 — Gouvernance des données (article 10) : qualité des données d'entraînement, validation et test, traçabilité, gestion des biais.

Obligation 3 — Documentation technique (article 11) : dossier technique complet maintenu à jour, accessible aux autorités. Obligation 4 — Journalisation et traçabilité (article 12) : log immuable de toutes les décisions du système, rétention minimum 6 mois en réglementaire, recommandation Nehos : plusieurs années.

Obligation 5 — Transparence et information utilisateur (article 13) : information claire des opérateurs sur la nature IA du système et ses limites. Obligation 6 — Supervision humaine (article 14) : un opérateur humain qualifié doit pouvoir comprendre, surveiller, suspendre, contredire le système à tout moment.

Obligation 7 — Robustesse, exactitude, cybersécurité (article 15) : niveau de performance documenté, résilience adversariale, sécurité IT alignée NIS2.

#Supervision humaine : le pivot opérationnel

Dans nos missions énergie / infrastructure, c'est la supervision humaine qui change la conception. Concrètement : une alerte prédictive IA ne déclenche jamais une intervention automatique non supervisée sur infrastructure critique. Un opérateur sénior valide chaque action avant exécution, avec une fenêtre temporelle proportionnée à l'urgence (validation immédiate possible 24/7, escalation hiérarchique au-delà d'un seuil de risque). Cette boucle humaine est documentée dans le dossier technique et auditée annuellement.

#Audit biais Aequitas et autres outils

L'audit biais est exigé par l'article 10 sur la gouvernance des données. Notre outil de référence est Aequitas (University of Chicago, open source) pour le scoring biais de représentation, équité prédictive, équité d'erreur sur sous-populations sensibles. Complété par Fairlearn (Microsoft, open source) pour la mitigation.

Sur maintenance prédictive infrastructure critique, l'enjeu biais est moins lié à des populations humaines qu'à des biais de représentativité données (sur-représentation de certains modèles de transformateurs, sous-représentation des sites ruraux isolés). Audit semestriel minimum.

#Méthode Nehos AI Act Compliance appliquée à la maintenance prédictive

Notre Méthode AI Act Compliance Nehos™ couvre l'intégralité des 7 obligations dans un cadre intégré. Sur les missions maintenance prédictive infrastructure critique, nous intégrons le dossier AI Act dès la phase POC pour éviter le surcoût d'une remise en conformité tardive.

Voir le glossaire AI Act, le glossaire edge computing et le service Conformité AI Act dédié pour aller plus loin.

Photos : abdo alshreef, cottonbro studio, Quang Nguyen Vinh sur Pexels.