Je n'arrêtais pas d'essayer de réparer le modèle. Le problème, c'était la lumière.
Le premier chiffre que j'ai écrit au tableau pour cette construction était 97 pour cent. Le second était 14.
Ils décrivent le même modèle. Dans l'exemple d'emboutissage de notre recherche, un modèle de vision validé à 97 % de précision en laboratoire est placé sur une presse à emboutissage progressif de 200 tonnes tournant à 40 coups par minute et commence à rejeter à tort 14 % des bonnes pièces. Rien n'a changé à l'intérieur du modèle. Les entrées, oui : les reflets des plafonniers d'atelier qui se déplacent avec l'angle de frappe, le lubrifiant qui s'accumule différemment sur des matrices chaudes que sur des froides, les 50 premières pièces de chaque poste fabriquées avant que la presse n'atteigne l'équilibre thermique. La physique de la ligne a fait sortir les images de la distribution sur laquelle le modèle avait été validé, et aucun modèle, à quelque précision que ce soit, n'est digne de confiance là-bas.
J'ai passé la dernière partie de ce projet à construire une démo pour prendre cette phrase au sérieux. Elle s'appelle Inspection Trust Gate, et vous pouvez la regarder décider, pièce par pièce, sur veriprajna.com/fr/demos/inspection-qualite-ia-en-edge-l-inspection-trust-gate. Ce n'est pas un meilleur modèle de défauts. C'est la couche d'exécution entre le modèle de vision et l'actionneur de rejet du PLC, et son seul travail est de décider, pour chaque pièce, si le verdict du modèle est sûr à actionner.
Ce qui suit est l'histoire de la construction à travers les trois moments qui ont changé ma façon de penser l'IA d'inspection : un événement de dérive scripté à 06:00, un chiffre de benchmark que j'ai refusé de croire, et une règle que j'ai failli supprimer.
La solution n'est pas un meilleur modèle
J'ai résisté à cette phrase plus longtemps que je n'aurais dû. Quand un détecteur se comporte mal, chaque instinct de constructeur me dit de le réentraîner, de mettre à jour le backbone, d'acheter plus d'annotations. La recherche a continué de refuser de coopérer. Les systèmes AOI sortis de boîte rejettent à tort 5 à 15 % des bonnes pièces, et les systèmes bien calibrés descendent sous 2 %, ce que notre page solution appelle « un problème de calibration et de données, pas un problème d'architecture de modèle ». La même recherche rapporte que 84 % des projets d'intégration système échouent ou échouent partiellement, et que dans un déploiement d'inspection typique le travail d'intégration représente 60 % du calendrier du projet tandis que l'entraînement du modèle en représente 15 %. La phrase que je n'arrêtais pas de relire : « Le matériel, c'est un bon de commande. »
J'ai donc fait quelque chose qui m'a semblé légèrement hérétique : j'ai rendu le modèle de défauts de la démo délibérément quelconque. C'est une distance kNN à une texture de bonne pièce connue, un succédané PatchCore-lite, et il obtient un AUROC de 0,845 pour séparer les pièces saines des pièces défectueuses sur le split de test réservé MVTec AD metal_nut (vraies photographies de vraies pièces manufacturées, labels publics). Je ne cache pas ce chiffre et je ne le vends pas. En production, cet emplacement accueille votre pipeline NVIDIA Metropolis, votre système Cognex, votre modèle custom, derrière une interface fixe. Le produit, c'est la couche autour du moteur, pas le moteur.
La couche commence par une question à laquelle aucune métrique de précision ne répond : cette image est-elle à l'intérieur des conditions de capture sur lesquelles le modèle a été validé ? L'EnvelopeDetector de la démo calcule une distance de Mahalanobis dans l'espace des signaux physiques (exposition, contraste, plage dynamique, un proxy de mise au point, détail haute fréquence, dominante thermique, saturation, fraction d'éblouissement), ajustée sur les 220 images d'entraînement de bonnes pièces connues et rien d'autre. Quand une pièce tombe hors de cette enveloppe validée, la porte cesse entièrement de faire confiance à la sortie du modèle, aussi confiant que le modèle se sente à son sujet.
Même un modèle parfait n'est valide que sur des entrées situées à l'intérieur de son enveloppe validée.
C'est la phrase sur laquelle toute la construction repose. La dérive est une défaillance d'entrée, pas une défaillance de modèle, et une défaillance d'entrée n'apparaît jamais sur votre tableau de bord de précision. Elle apparaît dans votre bac de rebuts.
Que se passe-t-il à 06:00 ?
Le moment auquel je fais le plus confiance dans toute la démo est un horodatage. L'application rejoue un poste scripté déterministe sur la station « Line 3 - metal_nut press », en faisant passer de vraies photographies MVTec AD metal_nut à travers le pipeline complet. À mi-chemin, un marqueur traverse l'écran : « SHIFT CHANGE 06:00 - cold dies, bay lights on. » Puis 12 bonnes pièces arrivent corrompues par de l'éblouissement, du flou et une dominante thermique. Je veux être précis sur ce que c'est : les photographies sont réelles, la dérive est une corruption d'image honnête qui leur est appliquée, et l'application l'étiquette comme telle. Je n'avais pas de ligne d'emboutissage à filmer, et prétendre le contraire empoisonnerait tout le propos.
Ce qui se passe ensuite est la raison d'être de la démo. Le moniteur d'enveloppe passe au rouge. La porte lit chaque pièce dérivée comme hors de l'enveloppe validée et refuse de laisser le verdict du modèle toucher l'actionneur. Verdict après verdict revient HOLD, routé vers la file d'escalade pour un humain, tandis que le panneau à côté montre ce qu'une AOI naïve sans contrôle d'enveloppe aurait fait de la même image : REJECT.
La première fois que j'ai vu la file se remplir, j'ai cliqué sur une pièce mise en attente en m'attendant à une vague excuse du type « anomalie détectée ». À la place, le moniteur d'enveloppe a décomposé la violation signal par signal, parce que je l'avais construit à partir de mesures physiques plutôt que d'embeddings, et les mesures physiques peuvent s'expliquer elles-mêmes. Sur une pièce dérivée, la luminosité se situe à 7,6 sigma de l'ajustement validé et porte 87,1 % de la distance de Mahalanobis au carré. Ce n'est pas un modèle qui a un sentiment. C'est une lecture d'instrument.
À la fin de la phase de dérive, le tableau d'affichage est sans appel. La baseline naïve a mis au rebut automatiquement 12 bonnes pièces. Le Trust Gate en a mis au rebut automatiquement zéro, en les tenant toutes pour revue. Les mêmes images, le même modèle de défauts de substitution, les mêmes seuils sur le score de défaut. La seule différence est qu'un chemin a vérifié l'entrée avant de faire confiance à la sortie.
La baseline naïve et la porte ont vu les mêmes pièces et le même modèle. La seule différence était la permission d'actionner.
À propos de ce chiffre en dollars, parce que c'est là que les démos commencent habituellement à mentir : le panneau extrapole le taux de faux rejet naïf mesuré à un poste complet (40 coups par minute pendant 8 heures font 19 200 pièces) à 2,42 $ par pièce mise au rebut. Les 2,42 $ sont un ordre de grandeur sourcé, ancré dans un cas publié d'un fabricant de biscuits où une réduction de 8,7 % des déchets de rebut a économisé 94 k$ par an et 38 800 kg de produit. Ce n'est pas le chiffre d'un client, et le compteur est étiqueté projection partout où il apparaît. J'ai mesuré les faux rejets ; j'ai projeté les dollars ; l'interface dit lequel est lequel.
Une chose de plus que j'ai vérifiée avant de croire ma propre histoire de dérive : les pièces défectueuses injectées pendant la phase de dérive sont toujours détectées ou escaladées, jamais passées automatiquement. Sur l'ensemble du split réservé, ce chiffre est de 93 sur 93. Mettre en attente les bonnes pièces ne sert à rien si les mauvaises passent dans le chaos.
Mon contrôle d'enveloppe corrigeait-il sa propre copie ?
Le chiffre de benchmark dont je me suis le plus méfié était mon propre meilleur chiffre. Quand j'ai lancé le script de bench pour la première fois, le détecteur d'enveloppe séparait les images dérivées des images propres de façon essentiellement parfaite. Ma réaction immédiate n'a pas été la fierté. C'était la suspicion, parce que j'avais construit les deux côtés de l'examen : j'avais écrit les corruptions d'éblouissement, de flou et de dominante thermique, et j'avais choisi les signaux physiques que le détecteur surveille. Bien sûr qu'un détecteur d'éblouissement attrape l'éblouissement. Un relecteur un tant soit peu exigeant appellerait cela circulaire, et il aurait raison.
J'ai donc tenu une famille de dérive complètement à l'écart. Le détecteur n'a jamais été calibré contre la sous-exposition, ne l'a jamais vue pendant le développement. Puis j'ai relancé bench.py (plus récemment le 2026-07-17) sur le split de test réservé MVTec AD metal_nut : 22 bonnes pièces, 93 défectueuses, ajustement d'entraînement sur les 220 bonnes images seulement. Sur la famille sous-exposition réservée, le détecteur d'enveloppe a obtenu AUROC 1.000. C'est le chiffre qui porte la thèse, précisément parce qu'il a été gagné sur un mode de défaillance que je n'avais jamais conçu. Le script affiche « THESIS HOLDS » seulement si les chiffres mesurés soutiennent réellement l'affirmation ; je l'ai écrit ainsi pour que le marketing ne puisse pas dériver loin de la mesure.
Le reste du benchmark mérite son périmètre exact, alors le voici sans arrondi en ma faveur. Sur les bonnes pièces dérivées, la baseline naïve sans enveloppe rejette à tort 95,5 à 100 % par famille de dérive (éblouissement 100 %, flou 100 %, dominante thermique 100 %, sous-exposition 95,5 %, moyenne 98,9 %). Le Trust Gate en rejette à tort 0,0 %, en tenant chacune pour revue. Et la réserve honnête : les corruptions sont à pleine force, donc l'effondrement de la baseline est quasi total par construction. La thèse que je défendrai est la direction — qu'un modèle proprement validé s'effondre une fois que les entrées quittent son enveloppe — pas le pourcentage particulier. Ce sont des mesures sur un benchmark de recherche sous dérive synthétique. Ce ne sont pas des garanties en monde ouvert, et quiconque les cite comme performance de production les détourne, moi y compris.
La règle que j'ai failli supprimer
L'appel à l'honnêteté le plus dur que j'ai fait dans cette construction portait sur une règle qui fonctionne à peine. Tôt, j'ai ajouté une règle de zone géométrique : localiser l'anomalie sur une grille grossière 8 par 8, et traiter un défaut à l'intérieur de la zone fonctionnelle différemment d'une tache au bord cosmétique. Cela sonne comme de la vraie métrologie. Puis je l'ai mesurée, et les mesures étaient humiliantes. Le proxy de rugosité locale localise une anomalie sur 33 des 93 défauts réservés, environ 35 %. Il change le résultat de la porte sur exactement 1 sur 93. Et 0 des 18 rejets automatiques sont appuyés par une anomalie réellement localisée ; quand rien ne se localise, le centroïde retombe au centre de la grille, qui se lit par défaut comme dans la zone.
Je suis resté face à trois options. Supprimer la règle et prétendre que je n'avais jamais essayé. La garder et laisser l'interface laisser entendre une métrologie de précision que je n'ai pas. Ou la garder et faire avouer l'interface. J'ai choisi l'aveu. Quand le défaut phare de la démo est rejeté automatiquement (pièce test-flip-264, un vrai défaut structurel grossier de la classe flip MVTec), le drill-in géométrie déclare franchement que rien n'a été localisé sur cette pièce et que le rejet repose sur la seule confiance texture.
La règle gagne vraiment sa place exactement une fois, et j'ai fait en sorte que l'application le prouve plutôt que de le mettre en scène. Au démarrage, la démo cherche parmi les 93 défauts réservés une pièce avec une anomalie véritablement localisée hors de la zone fonctionnelle sur une pièce autrement confiante. Dans le split livré, cette recherche trouve test-flip-251, centroïde à la ligne 2, colonne 6, et la porte l'achemine vers HOLD au lieu de déclencher l'actionneur. Si les données changeaient et qu'aucune pièce ne qualifiait, ce temps fort n'apparaîtrait simplement pas. J'ai même testé en A/B le seuil sigma de la règle avec une validation croisée à 5 plis ; la valeur ajustée n'a montré aucune amélioration par rapport au 2,5 fixé à la main, donc j'ai gardé 2,5 et enregistré le résultat négatif dans le dépôt avec "shipped": false. Dans un engagement de production, cette règle est remplacée par une métrologie pixel-précise ancrée dans le CAD. Dans la démo, c'est un succédané honnête, et l'interface le dit sur chaque pièce.
Une couche de confiance qui se survend est une contradiction dans les termes.
Cette phrase est devenue une règle de conception. Si toute la promesse du produit est de savoir quand ne pas faire confiance à un modèle, il ne peut pas en même temps bluffer sur son propre composant le plus faible.
Les agents conseillent, le code décide
La décision que je refuse de déléguer est celle qui déplace du métal. La porte elle-même est du code déterministe simple, hors de tout LLM et hors du modèle de vision aussi. Ses seuils sont ajustés à partir des propres données de la démo, pas à la louche : auto-pass en dessous de 0,948 et auto-reject au-dessus de 1,30 sur l'échelle de confiance calibrée, avec tout ce qui est entre les deux, et tout ce qui est hors enveloppe, allant en HOLD. Elle tourne contre un budget dur de fenêtre de coup de 750 ms, et dans le journal d'audit livré les décisions atterrissent en dizaines de millisecondes : test-good-288 passé automatiquement en 37,7 ms, test-good-289 en 24,4 ms, et le journal d'actionneur de rejet pour test-flip-264 lit « REJECT actuated in 25ms (budget 750ms). »
Je dois être clair sur ce qui actionne : rien, pour l'instant. Le chemin EtherNet/IP vers un actionneur de rejet Allen-Bradley ControlLogix est un simulateur qui journalise exactement ce qu'il aurait fait, et le sink MES est un stub qui écrit la ligne de traçabilité qu'il aurait écrite. Les deux sont étiquetés comme stubs dans l'application. Ils sont formés comme les vrais adaptateurs parce que la réalité OT (usines mixtes Siemens et Allen-Bradley, une fenêtre de rejet mesurée en millisecondes) est la véritable surface produit, mais une démo qui laisserait entendre une ligne en direct échouerait à son propre test de confiance.
Il y a des agents dans le système, et je les ai volontairement bornés. Quand les pièces s'accumulent dans la file d'escalade, une paire Drift Triage se met au travail : un agent de diagnostic lit les écarts de signaux physiques classés sur les pièces mises en attente et propose une hypothèse de cause racine avec une action recommandée, puis un agent critique vérifie cette hypothèse contre les preuves numériques, la rétrogradant en « investigation manuelle » si le signal cité n'est pas réellement l'écart dominant. Ils sont construits sur Pydantic AI et le fournisseur est interchangeable, et sans clé API configurée le tout se dégrade en un triage déterministe fondé sur des gabarits, pour que la démo tourne entièrement hors ligne. Ce que les agents ne peuvent pas faire, par construction, c'est toucher l'actionneur. Au moment où ils parlent, la porte a déjà décidé.
Les agents conseillent, le code décide.
Chacune de ces décisions laisse un reçu. Chaque pièce écrit un enregistrement de lignée JSONL : id de pièce, station, model id metalnut-defect-knn version v7, hash de dataset ae95b5b533c8, confiance de défaut, score OOD, les signaux physiques, quelles règles de porte se sont déclenchées, latence par rapport au budget de 750 ms, les lignes de journal d'actionnement et MES, ce que la baseline naïve aurait fait, et le tag de risque high-risk:quality-gate (EU AI Act Annexe III, eff. 2026-08-02). Un clic exporte le poste en inspection_audit.jsonl.
L'horloge réglementaire compte ici. Les obligations à haut risque de l'EU AI Act deviennent pleinement applicables le 2 août 2026, les décisions de qualité critiques pour la sécurité figurent à l'annexe III, et les amendes maximales atteignent 35 M€ ou 7 % du chiffre d'affaires mondial pour les violations de pratiques interdites les plus graves. Je veux peser mes mots, parce que c'est exactement là que les mots soigneux comptent : la démo n'est pas certifiée EU AI Act, et aucune démo ne peut l'être. Ce qu'elle montre, c'est une lignée prête pour l'EU AI Act, un enregistrement par décision conçu pour être une preuve classable dans un dossier de conformité à haut risque, généré à la vitesse de la ligne au lieu d'être reconstruit après un incident.
Qu'est-ce qui survit à la prochaine mise à niveau du modèle ?
La question que je n'arrêtais pas de me poser en construisant cela était brutale pour un créateur de démo : si le prochain modèle de défauts du client est dramatiquement meilleur que mon succédané, est-ce que tout cela compte encore ? Je pense maintenant que c'est exactement à l'envers. Deloitte prédit que l'adoption de l'IA agentique dans l'industrie manufacturière passera de 6 % à 24 % en 2026 (Deloitte), ce qui signifie plus de modèles et plus d'autonomie arrivant à plus d'actionneurs. Chacun de ces modèles aura une enveloppe validée, et la physique d'une ligne de presse (éblouissement, matrices froides, équilibre thermique) continuera de faire sortir les entrées de celle-ci. Un modèle parfait ne change rien à cela, parce que la défaillance que la porte empêche est une défaillance d'entrée, et l'obligation d'audit qu'elle sert est juridique, pas de modélisation. Le filtrage de dérive, la provenance et l'actionnement gouverné tiennent à toute précision de modèle. C'est la propriété qui m'a convaincu que cette couche, et non un autre modèle, valait la peine d'être construite ; le poste scripté sur veriprajna.com/fr/demos/inspection-qualite-ia-en-edge-l-inspection-trust-gate est ma tentative de vous laisser la regarder prouver cette affirmation pièce par pièce.
Et si vous préférez la voir plutôt que de me lire la décrire, voici la version fondateur, de bout en bout.
Donc la question que je poserais à propos de tout modèle d'inspection sur votre ligne, y compris un à 97 %, n'est pas « quelle est sa précision ? » C'est : pour la pièce qui vient de passer devant la caméra, savez-vous si cette image était à l'intérieur de l'enveloppe sur laquelle le modèle a été validé ? Si vous ne pouvez pas répondre pièce par pièce, en millisecondes, avec un enregistrement que vous pourriez tendre à un auditeur, alors je ne pense pas que vous ayez un problème de précision. Je pense que vous avez un problème d'enveloppe, et j'aimerais vraiment savoir lequel de ces deux problèmes a votre ligne.
