Vous avez dépensé entre 50 k€ et 500 k€ en outils IA, pilotes et contrats fournisseurs au cours des dix-huit derniers mois. Vous ne pouvez pas me dire — avec des chiffres — si quoi que ce soit fonctionne. Pour les opérateurs industriels, l'écart est encore plus marqué : l'IA n'atteindra jamais l'atelier, le véhicule ou le poste de distribution si la frontière OT/IT n'est pas cartographiée, si les pipelines de données capteurs n'ont pas été validés, et si le régime de sécurité (ISO 26262, IEC 61508, IEC 62443) n'a pas été évalué. Il s'agit de la phase Découverte de la Hyperion Lifecycle, compressée en deux semaines et facturée au forfait. J'ai audité plus de 30 initiatives IA et mis dix ventures IA en production, dont Auralink (1,7 M de lignes de code de production, arXiv 2603.08736) et des travaux sur des systèmes physiques autonomes. Les schémas d'échec se répètent. Je sais quels écarts sont bloquants pour un déploiement physique par opposition à ceux que vous pouvez traiter dans une seconde vague.
La frontière OT/IT n'est pas cartographiée et votre IA ne peut pas la franchir en toute sécurité. Les opérateurs industriels ont des réseaux de production qui n'ont jamais été conçus pour le trafic d'inférence IA — anneaux PROFINET, automates de sécurité sur sous-réseaux isolés, bus CAN de véhicules avec des budgets de synchronisation stricts. Votre équipe IT a approuvé un fournisseur IA cloud. Votre équipe OT, non. Les deux domaines ne partagent ni un cadre de gouvernance des données, ni un protocole de réponse aux incidents, ni une posture de sécurité réseau qu'un régulateur sous IEC 62443 accepterait.
Les pipelines de données capteurs n'ont jamais été validés pour l'entraînement IA. Les journaux historiques semblent complets. En pratique, les capteurs thermiques de la ligne 3 ont un décalage d'horodatage de 200 ms, les données de vibration ont été collectées à une fréquence d'échantillonnage différente de celle indiquée dans la fiche technique, et la convention de labellisation a changé en 2022 sans enregistrement de migration. Un modèle entraîné sur ces données aura des biais que personne ne pourra expliquer une fois en production.
La disponibilité pour l'inférence en périphérie n'a pas été évaluée. Faire fonctionner un modèle sur un Jetson, un Intel NUC ou un ECU embarqué est un problème d'ingénierie différent de le faire fonctionner dans un conteneur cloud. Quantification, budget de latence, empreinte mémoire, comportement déterministe sous défaillance capteur, dégradation gracieuse lors d'une partition réseau — rien de tout cela n'est documenté dans le contrat de votre fournisseur IA actuel, et rien n'a été testé sur votre matériel de production réel.
La maturité du régime de sécurité est inconnue. Votre secteur dispose presque certainement d'une norme de sécurité fonctionnelle ou de cybersécurité — ISO 26262 pour l'automobile (ASIL), IEC 61508 pour l'industrie (SIL), IEC 62443 pour la cybersécurité OT, ISO 10218 pour la robotique. Votre pilote IA n'a été scoped contre aucune d'elles. Cet audit vous dit exactement quelles preuves manquent et combien de temps il faudra pour combler l'écart.
Il s'agit d'une mission au forfait, avec un périmètre et une échéance fixes. Semaine un : découverte et évaluation technique — architecture OT/IT, pipelines capteurs, matériel en périphérie, documentation du régime de sécurité. Semaine deux : synthèse et livrable écrit.
Entretiens structurés de 60 minutes avec le directeur d'usine ou VP Ingénierie, le responsable OT/SCADA, le responsable ML ou données, l'ingénieur sécurité ou certification, et deux ingénieurs d'exploitation travaillant quotidiennement dans l'environnement de production. Je révise également vos schémas d'architecture réseau, la documentation de votre pilote IA actuel, vos contrats fournisseurs, et toute évaluation de sécurité existante ou analyse d'écart IEC 62443 / ISO 26262.
Évaluation approfondie selon quatre dimensions IA physique : (1) frontière OT/IT — segmentation réseau, chemins de flux de données, modèle de zone et conduit IEC 62443 ; (2) pipelines de données capteurs — intégrité des horodatages, cohérence de la fréquence d'échantillonnage, provenance du labelling, qualité des données historiques ; (3) disponibilité pour l'inférence en périphérie — évaluation du matériel cible, budget de latence et mémoire, viabilité de la quantification, comportement lors de partition de connectivité ; (4) maturité du régime de sécurité — quelle norme s'applique, quels artefacts existent, lesquels manquent pour un déploiement en production.
Chaque écart classé selon quatre niveaux : bloquant de déploiement physique (l'IA ne peut pas passer au matériel de production sans cela), bloquant du régime de sécurité (un ingénieur de certification rejettera le déploiement sans cette preuve), bloquant d'intégration OT (l'IA ne peut pas lire ou écrire dans le stack opérationnel sans cela), et carnet de durcissement (à traiter avant de passer d'un site à cinq). Chaque élément reçoit une estimation d'effort et une suggestion de responsable.
Une feuille de route à 90 jours — projets précis, responsables, métriques de succès — séquencée de sorte que les travaux sur la frontière OT/IT et les travaux sur les preuves de sécurité progressent en parallèle avec tout travail d'amélioration du modèle. Livrée lors d'une restitution de 90 minutes à votre équipe de direction.
Directeurs d'usine, VP Ingénierie et directeurs d'exploitation chez des industriels, OEM automobiles, utilities énergétiques et opérateurs d'infrastructure ayant un pilote IA dans la zone IT mais ne pouvant le faire passer la frontière OT ni le déployer sur le matériel de production. Ingénieurs sécurité ou certification nécessitant une vue indépendante des preuves que l'équipe ML n'a pas encore produites. CAIO d'entreprises industrielles ou automobiles préparant un engagement T3 ou T4 de déploiement IA physique et nécessitant une évaluation externe avant de signer le prochain contrat fournisseur. Ce service n'est pas pour les entreprises SaaS pures sans opérations physiques.
Parce que votre équipe OT/IT comprend la topologie réseau mais ne l'a pas évaluée sous l'angle des flux de données d'inférence IA, des pipelines de mise à jour de modèles et des exigences de preuves du régime de sécurité. L'audit n'est pas une évaluation de sécurité réseau — c'est une évaluation de la capacité de votre architecture OT/IT à supporter un déploiement d'IA physique à l'échelle de la production.
L'évaluation est scoped aux normes qui régissent votre secteur : ISO 26262 et SOTIF (ISO 21448) pour l'automobile, IEC 61508 pour l'industrie (SIL), IEC 62443 pour la cybersécurité OT, ISO 10218 pour la robotique, et Annexe III du règlement EU IA pour les systèmes autonomes et industriels à haut risque. Je ne confonds pas les normes cyber (UNECE R155/R156) avec les normes de sécurité fonctionnelle (ISO 26262/IEC 61508) — elles régissent des domaines de défaillance différents et nécessitent des preuves différentes.
Alors le rapport le dira, par écrit, avec les écarts spécifiques documentés. Environ un audit industriel IA sur quatre conclut que le travail d'intégration OT/IT est le chemin critique — pas le modèle — et que procéder sans y remédier produira un déploiement raté à coût significatif. Ce constat est précieux : il évite qu'un engagement de déploiement physique de 16 semaines ne se heurte à un bloquant structurel en semaine huit.
L'évaluation d'un fournisseur est conçue pour vous qualifier pour son prochain produit. Cet audit est conçu pour vous dire ce que votre déploiement IA physique requiert réellement — y compris des constats qui pourraient recommander de ne pas renouveler un contrat fournisseur. Je n'ai pas de produit à vendre après l'audit ; le livrable est le classement.
Découvrez d'autres services qui complètent cette offre
30 minutes. Je diagnostique votre situation, je vous dis honnêtement si ce service convient — et sinon, lequel conviendrait.