L'horloge de décision de 90 jours pour un pilote d'IA physique : mécanique semaine par semaine, critères de sortie et responsabilités

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 pilote d'IA physique ne devrait pas devenir un programme de recherche sans fin. Fixez une horloge de décision. Quatre-vingt-dix jours constituent une valeur par défaut utile pour obliger les hypothèses à se révéler, désigner des responsables et recueillir les preuves nécessaires à une recommandation claire.

Ce n'est pas une garantie de livraison. Le périmètre du produit, le matériel, l'accès au terrain, les obligations de sécurité et la trajectoire réglementaire peuvent exiger un autre calendrier. L'horloge régit le processus de décision ; les preuves régissent le plan produit.

Ce livre blanc développe cette méthode en une mécanique semaine par semaine, des critères de sortie, une mesure et des responsabilités organisationnelles. Il s'agit d'une méthode publique, et non du récit d'une mission client d'Hyperion. Les exemples sont illustratifs et ne revendiquent aucun résultat.

Synthèse

• L'horloge décide, elle ne livre pas. Quatre-vingt-dix jours constituent une valeur par défaut de gouvernance pour aboutir à l'un de quatre verdicts écrits (poursuivre, réorienter, séquencer ou arrêter), et non la promesse qu'un pilote atteigne la production.
• Le modèle est la petite partie. Des travaux d'ingénierie publiés décrivent le code de ML comme une petite fraction d'un système de ML réel ; un pilote qui ne teste que le modèle n'a donc pas testé le produit.
• C'est en conditions de terrain que les preuves cèdent. Les recherches sur les décalages de distribution en conditions réelles font état de performances hors distribution nettement inférieures ; l'horloge réserve donc ses semaines centrales au site réel, aux capteurs et aux opérateurs.
• Zéro défaillance est une preuve faible, sauf si les essais sont nombreux. Zéro défaillance sur N essais indépendants borne le taux de défaillance à environ 3/N avec une confiance de 95% ; la fiabilité qu'un pilote de quatre-vingt-dix jours peut démontrer doit donc être calculée dès la semaine 1.
• La maturité est une propriété du maillon le plus faible. Une grille de maturité pour la production publiée par Google note un système selon le minimum des notes de ses sections ; l'horloge applique cette règle, de sorte qu'un modèle solide ne peut pas compenser l'absence de chemin de rollback.
• Quelqu'un doit pouvoir arrêter le travail. Le NIST AI RMF appelle à des rôles documentés et à des mécanismes permettant de désactiver les systèmes incompatibles avec l'usage prévu ; l'horloge confie cette autorité à un sponsor nommément désigné dès le jour 1.
• La réglementation façonne le calendrier. Le règlement européen sur les machines s'applique à partir du 20 janvier 2027 ; lorsque des modules fondés sur l'apprentissage assurent des fonctions de sécurité, les preuves de conformité constituent une hypothèse décisive, et non une phase ultérieure.

Le problème, et pourquoi il compte maintenant

Un pilote qui ne se termine jamais n'est pas neutre. Il consomme du temps d'ingénierie, de l'accès au terrain et l'attention du sponsor, tout en reportant le seul livrable qui compte : une décision sur la question de savoir si le dossier produit résiste à l'épreuve de la réalité. Le schéma à éviter est celui de l'activité qui se substitue aux preuves : davantage de démos, un backlog plus long, un nouveau sprint d'intégration, et aucune réponse écrite.

Trois ensembles de travaux publiés expliquent pourquoi cela se produit, et pourquoi cela se produit de manière plus aiguë dans l'IA physique.

Premièrement, le modèle est minoritaire dans le système. Dans leur article NeurIPS Hidden Technical Debt in Machine Learning Systems, Sculley et ses collègues affirment que « seule une petite fraction des systèmes de ML réels est constituée du code de ML » et que « l'infrastructure environnante requise est vaste et complexe ». Leur principe CACE, « Changing Anything Changes Everything » (changer quoi que ce soit change tout), décrit comment des entrées enchevêtrées empêchent les améliorations isolées. Un pilote qui mesure la précision du modèle a mesuré la plus petite case de cette figure.

Deuxièmement, les problèmes de déploiement apparaissent à chaque étape. Une revue d'études de cas de déploiement publiées, menée par Paleyes, Urma et Lawrence, conclut que « les praticiens rencontrent des problèmes à chaque étape du processus de déploiement ».

Troisièmement, les problèmes de données s'aggravent tardivement. Après avoir interrogé 53 praticiens, Sambasivan et ses collègues décrivent les « cascades de données » comme des « événements cumulatifs entraînant des effets négatifs en aval à partir de problèmes de données » et les qualifient d'« omniprésentes (prévalence de 92%) » dans cet échantillon. Le chiffre de 92% décrit leurs personnes interrogées, et non le secteur ; c'est le mécanisme qui importe ici. Dans un pilote, ce mécanisme pourrait signifier qu'un choix d'étiquetage fait en semaine 2 ressurgisse sous forme de défaillance sur le terrain en semaine 9 (une illustration, et non un cas rapporté).

L'IA physique ajoute le matériel, la sécurité et l'accès au site à ces trois facteurs. Le déploiement des robots progresse : l'International Federation of Robotics fait état de « 542 000 robots installés en 2024 - plus du double du nombre d'il y a 10 ans ». La réglementation s'intéresse également aux comportements fondés sur l'apprentissage dans les fonctions de sécurité. La synthèse de l'EU-OSHA consacrée au règlement européen sur les machines indique que « le règlement s'applique à partir du 20 janvier 2027 » et qu'il « vise à mieux couvrir les nouvelles technologies telles que les machines mobiles autonomes (robots) » et « l'intelligence artificielle (IA), lorsque des modules spécifiques d'IA utilisant des techniques d'apprentissage assurent des fonctions de sécurité ». La même page indique que « les machines et produits connexes (“produits machines à haut risque”) sont soumis à des procédures d'évaluation de la conformité par un tiers ». Un pilote qui ignore la trajectoire réglementaire de son produit peut être en train de tester un produit qui ne pourra pas être livré tel qu'il est conçu.

Le véritable livrable du pilote est donc une décision prise dans l'incertitude. Le NIST AI RMF Core le rend explicite au point MANAGE 1.1 : « Il est déterminé si le système d'IA atteint les finalités prévues et les objectifs déclarés, et si son développement ou son déploiement doit se poursuivre. » L'horloge existe pour que cette détermination soit faite à temps et sur la base de preuves.

Analyse technique approfondie : ce que l'horloge teste réellement

Les quatre couches d'un candidat produit d'IA physique

Un candidat produit comporte au moins quatre couches, et chacune défaille différemment. L'horloge teste les quatre, car une défaillance dans l'une d'elles peut inverser la recommandation.

Le tableau est un outil de raisonnement, et non une taxonomie standard ; il empêche le pilote de se réduire à la première ligne.

Pourquoi les conditions de terrain dominent le milieu de l'horloge

Le benchmark WILDS de Koh et ses collègues affirme que les décalages de distribution « peuvent dégrader substantiellement la précision des systèmes d'apprentissage automatique (ML) déployés en conditions réelles », que « l'entraînement standard produit des performances hors distribution nettement inférieures aux performances en distribution », et que « cet écart subsiste même avec des modèles entraînés par les méthodes existantes destinées à traiter les décalages de distribution ». Pour un pilote d'IA physique, le décalage de distribution est concret : une autre unité de caméra, une nouvelle condition d'éclairage, une ligne plus rapide, une pince usée, un nouvel opérateur.

La simulation aide, mais ne tranche pas la question. Tobin et ses collègues formulent le problème comme celui de « combler le “reality gap” qui sépare la robotique simulée des expériences sur matériel » et font état d'un détecteur d'objets en conditions réelles « précis à 1.5 cm » entraîné « en utilisant uniquement des données issues d'un simulateur avec des textures aléatoires non réalistes ». Dans le cadre expérimental décrit, c'est un résultat significatif. Il fait de la simulation un intrant crédible, et non une validation sur le terrain ; le transfert doit encore être testé sur le matériel réel.

Les niveaux de maturité technologique de la NASA tracent la même frontière dans un autre domaine : « Une technologie TRL 6 dispose d'un prototype pleinement fonctionnel ou d'un modèle représentatif », tandis qu'« une technologie TRL 7 exige que le modèle fonctionnel ou le prototype soit démontré dans un environnement spatial ». Par analogie (les TRL ont été rédigés pour les systèmes spatiaux), un pilote qui n'a fonctionné qu'en laboratoire ou en simulateur n'a pas encore été démontré dans son environnement opérationnel, aussi bonne que paraisse la démo.

L'horloge classe donc chaque élément de preuve selon l'endroit où il a été produit, et limite ce que chaque niveau peut étayer. La classification ci-dessous est un outil de raisonnement pour le registre des preuves, et non un standard.

flowchart TD
    E1["Estimation ou affirmation du fournisseur"] --> U1["Peut étayer : le test à mener en premier"]
    E2["Simulation"] --> U2["Peut étayer : les choix de conception et la conception des tests"]
    E3["Test en laboratoire ou test terrain borné"] --> U3["Peut étayer : des hypothèses d'enveloppe"]
    E4["Essai terrain sur le site et le matériel réels"] --> U4["Peut étayer : des affirmations terrain dans les conditions consignées"]
    E5["Exploitation terrain répétée sous surveillance"] --> U5["Peut étayer : des bornes de fiabilité et l'acceptation du risque résiduel"]
    E1 -.->|"jamais promue par la répétition"| E4

Mesure : quatre familles de métriques

Le point MEASURE 2.3 du NIST AI RMF demande que les critères de performance ou d'assurance soient « mesurés qualitativement ou quantitativement et démontrés pour des conditions similaires au(x) contexte(s) de déploiement. Les mesures sont documentées. » L'horloge traduit cela en quatre familles de métriques, chacune journalisée avec ses conditions de test.

1. Métriques de tâche en conditions de terrain. Taux de réussite de détection ou de préhension, taux de fausses acceptations et de faux rejets, ventilés selon les conditions qui varient sur site (éclairage, vitesse, variante de pièce, opérateur).
2. Métriques d'autonomie. Interventions par heure de fonctionnement, entrées en état sûr, temps de reprise après une intervention. Elles décrivent la manière dont le produit se comporte en tant que système, et non le score du modèle.
3. Métriques de livraison. Les métriques DORA définissent le délai de mise en œuvre des changements comme « le temps nécessaire pour qu'un changement passe de la validation dans le contrôle de version au déploiement en production » et le temps de rétablissement après un déploiement en échec comme « le temps nécessaire pour se rétablir d'un déploiement qui échoue et requiert une intervention immédiate ». Pour une cellule robotisée, la « production » est l'unité physique ; ces métriques révèlent donc si une mise à jour peut atteindre une deuxième unité et faire l'objet d'un rollback.
4. Facteurs opérationnels et économiques en unités physiques. Heures d'installation, heures de formation des opérateurs, minutes de traitement des exceptions par poste, heures d'arrêt, puissance consommée par le calcul en watts. Le pilote fournit des grandeurs physiques et des fourchettes ; le modèle financier du sponsor les convertit.

Le ML Test Score de Breck et ses collègues propose une discipline de notation qu'il vaut la peine d'emprunter. Les auteurs « présentent 28 tests et besoins de surveillance spécifiques » répartis en quatre sections. « Pour chaque test, un demi-point est attribué pour l'exécution manuelle du test, avec des résultats documentés et diffusés », et « un point entier est attribué s'il existe un système permettant d'exécuter ce test automatiquement de manière répétée ». Point crucial, « le ML Test Score final est calculé en prenant le minimum des scores agrégés pour chacune des 4 sections ».

Les statistiques d'une horloge courte

Un pilote de quatre-vingt-dix jours dispose d'un nombre fini d'essais. Ce nombre borne ce que le pilote peut affirmer.

Lorsqu'aucune défaillance n'est observée, la règle de trois s'applique. Comme le résume Newman dans JAMA à propos de Hanley et Lippman-Hand, « si 0 événement est observé sur N essais, la limite supérieure de l'intervalle de confiance (IC) à 95% pour la fréquence des événements est d'environ 3/N ». Pour des essais indépendants, avec C le niveau de confiance, p le taux de défaillance réel et N le nombre d'essais sans défaillance, la borne exacte et son approximation sont :

En l'inversant, on obtient le nombre d'essais indépendants sans défaillance nécessaires pour affirmer un taux de défaillance inférieur à une cible p :

Ce sont des conséquences arithmétiques de la formule, et non des résultats de terrain. L'hypothèse à surveiller est l'indépendance : cinquante préhensions au cours d'un même poste, sous une même condition d'éclairage, avec un même opérateur, peuvent être corrélées et n'offrir qu'une couverture limitée de l'enveloppe opérationnelle ; justifiez l'indépendance et la population à laquelle s'applique la borne du taux de défaillance. Des essais corrélés peuvent surestimer la confiance.

La même logique prend une ampleur brutale à plus grande échelle. Dans Driving to Safety, Kalra et Paddock calculent que « les véhicules entièrement autonomes devraient parcourir des centaines de millions de miles, et parfois des centaines de milliards » pour démontrer leur fiabilité en matière de décès et de blessures, et concluent que les développeurs « ne peuvent pas simplement rouler jusqu'à la sécurité ». Une enveloppe d'usine diffère de la voie publique, et ces chiffres relatifs aux véhicules ne se transposent pas directement. Comparez le nombre d'essais indépendants disponibles à la borne de taux de défaillance requise ; lorsque les essais sont insuffisants, le pilote a besoin de preuves supplémentaires (architecture de sécurité, injection de fautes, bornes déterministes) et d'un énoncé explicite de l'incertitude résiduelle.

Mécanique de déploiement : des canaris pour les unités physiques

Le workbook SRE de Google définit le canarying comme « un déploiement partiel et limité dans le temps d'un changement dans un service, et son évaluation », recommande qu'un canari « soit de taille significative et dure suffisamment longtemps pour être représentatif de l'ensemble du déploiement », et note que « le canarying est une comparaison A/B ». Dans un pilote d'IA physique, le canari est une unité, une cellule ou un poste, comparé à une unité témoin ou au processus existant sur la même période. La recommandation SRE de ne mener « qu'un seul déploiement canari à la fois » se transpose directement : un seul changement par fenêtre d'évaluation, faute de quoi les preuves ne peuvent pas être attribuées.

Autorité humaine et confiance des opérateurs

L'opérateur fait partie du produit. Lee et See, dans leur revue de la confiance dans l'automatisation publiée dans Human Factors, écrivent que l'automatisation peut poser problème lorsque « les personnes ne s'y fient pas de manière appropriée », et que « la confiance guide le recours à l'automatisation lorsque la complexité et les situations imprévues rendent peu praticable une compréhension complète de celle-ci ». Le pilote doit donc observer si les opérateurs accordent une confiance excessive à des sorties incertaines ou s'ils passent outre à tout. Les deux sont des défaillances du produit, invisibles pour les métriques du modèle.

Preuves de la recherche : ce que les sources étayent, et ce qu'elles n'étayent pas

Les sources ci-dessus sont de natures différentes et étayent des choses différentes.

La base de preuves propre aux pilotes d'IA physique est mince. Aucune de ces sources ne mesure la durée des pilotes d'IA physique, la part d'entre eux qui atteint la production, ni si une horloge fixe améliore les résultats. La valeur par défaut de quatre-vingt-dix jours est un choix de gouvernance, et non un résultat de recherche.

Analyse métier et décisionnelle

Critères de décision

Le guide d'analyse de décision de la NASA fournit trois règles que l'horloge adopte directement : « Les critères devraient être objectifs et mesurables », « Les critères devraient également permettre de différencier les options ou alternatives » et « Une option qui ne satisfait pas aux critères obligatoires devrait être écartée ». Il indique aussi : « L'incertitude ne compte dans une analyse donnée que s'il existe une probabilité non nulle que la réduction de l'incertitude modifie le classement des alternatives. » Cette phrase est la règle de sélection des hypothèses à tester en premier.

Le tableau de décision

Un partenaire est une manière d'exécuter un verdict, et non un verdict en soi : il est consigné dans la recommandation Poursuivre ou Réorienter, avec ses conditions. Une décision d'arrêt peut être une issue réussie de l'horloge. Elle évite de dépenser davantage pour une thèse non étayée.

Facteurs de coût, sans devise

Le pilote devrait présenter les facteurs de coût sous forme de grandeurs physiques et de fourchettes. La fonction finance du sponsor les convertit.

Responsabilités organisationnelles

Le point GOVERN 2.1 du NIST AI RMF indique que « les rôles et responsabilités ainsi que les lignes de communication liés à la cartographie, à la mesure et à la gestion des risques d'IA sont documentés », et le point MANAGE 2.4 appelle à des mécanismes, avec des responsabilités « attribuées et comprises », pour « remplacer, désengager ou désactiver les systèmes d'IA dont les performances ou les résultats sont incompatibles avec l'usage prévu ». L'horloge transpose cela en six rôles nommés. Une même personne peut en cumuler plusieurs, mais le responsable des preuves ne devrait pas être la personne dont le travail est évalué.

La méthode : l'horloge de décision de 90 jours, semaine par semaine

Jours 1–15 — Cadrer la décision (environ semaines 1–2)

Commencez par la décision que le sponsor doit réellement prendre. Il peut s'agir par exemple d'autoriser l'industrialisation, de restreindre l'enveloppe opérationnelle, de changer de fournisseur, de recueillir d'autres preuves de terrain, ou d'arrêter.

Rédigez :

• le résultat pour l'acheteur et pour le produit ;
• le comportement du prototype déjà observé ;
• les conditions dans lesquelles il a été observé ;
• les hypothèses non résolues relatives au client, à la technique, à la sécurité, à l'exploitation et à l'économie ;
• les options de décision ;
• les preuves qui permettraient de départager ces options.

Ne commencez pas par étendre le backlog. Un long backlog peut masquer une décision non définie.

Deux autres tâches de la semaine 1 garantissent l'honnêteté de l'horloge. D'abord, organisez un premortem. Klein le décrit dans la Harvard Business Review : « les membres de l'équipe supposent que le projet qu'ils planifient vient d'échouer », ce qui permet aux dissidents bien informés de nommer sans risque les faiblesses. Ensuite, calculez le budget d'essais (défini plus loin) et déterminez si quatre-vingt-dix jours peuvent produire l'affirmation de fiabilité dont le produit a besoin. Si ce n'est pas le cas, modifiez l'affirmation maintenant, et non au jour 85.

Critère de sortie : une charte de décision et un registre des preuves signés. Signé signifie une responsabilité assumée, et non l'adhésion à une réponse prédéterminée.

Jours 16–45 — S'attaquer aux hypothèses décisives (environ semaines 3–6)

Donnez la priorité aux hypothèses susceptibles d'inverser la recommandation. Un produit peut dépendre de l'acceptation par les opérateurs, d'une borne de latence, d'une interface fournisseur, de l'accès aux données de terrain, du temps d'installation ou d'un mode dégradé sûr.

Concevez le plus petit test crédible pour chacune. Séparez les résultats observés des estimations. Consignez les conditions de test, les défaillances et les preuves manquantes.

Un test illustratif pour un produit de vision pourrait comparer le comportement avec la caméra réelle, sous des variations d'éclairage et de vitesse de ligne, tout en observant comment un opérateur traite un résultat incertain. Le but n'est pas de produire une démo convaincante. Il est de découvrir si la promesse du produit résiste à l'épreuve du terrain.

Chaque hypothèse passe par un petit nombre d'états. L'état est consigné dans le registre des preuves, avec son responsable et la date de la dernière modification.

stateDiagram-v2
    state "Ouverte" as Open
    state "Test conçu" as Designed
    state "En cours de test" as Testing
    state "Étayée dans les conditions énoncées" as Supported
    state "Réfutée" as Refuted
    state "Bloquée faute d'accès" as Blocked
    state "Escaladée au sponsor de la décision" as Escalated
    [*] --> Open
    Open --> Designed
    Designed --> Testing
    Testing --> Supported
    Testing --> Refuted
    Testing --> Blocked
    Blocked --> Testing
    Blocked --> Escalated
    Refuted --> Escalated
    Supported --> [*]
    Escalated --> [*]

Une hypothèse décisive réfutée est transmise immédiatement au sponsor, et non au jour 90. C'est le mécanisme qui permet à l'horloge de s'arrêter tôt.

Critère de sortie : un dossier de preuves versionné, avec méthodes, observations, limites et responsables, et chaque hypothèse décisive dans un état terminal ou escaladé.

Jours 46–75 — Tester le candidat produit dans son ensemble (environ semaines 7–11)

Un test de modèle ne peut pas prouver un produit. Connectez le candidat au système et au flux de travail environnants.

Passez en revue :

• capteurs, calcul, connectivité et variabilité matérielle ;
• commandes déterministes, autorité humaine et état sûr ;
• déploiement, identité, observabilité et rollback ;
• installation, formation, réception et support ;
• traçabilité des données, accès, conservation et approbation des changements ;
• responsabilités des fournisseurs et sortie ;
• économie du produit sous forme de fourchettes.

Utilisez un environnement de test réaliste, sur le terrain ou délimité. Étiquetez les preuves simulées comme simulées. Étiquetez un dossier illustratif comme illustratif. Ni l'un ni l'autre ne devient une preuve de production client par la répétition.

Trois exercices comptent davantage que des essais supplémentaires : installer le candidat sur une deuxième unité à partir d'étapes documentées ; faire passer un changement par une unité canari puis l'annuler par rollback ; et forcer l'état sûr à partir de chaque défaut nommé par le concept de sécurité. Chaque exercice produit une grandeur mesurée (heures d'ingénieur, temps de rétablissement, temps d'entrée en état sûr) pour le tableau de décision.

Critère de sortie : un dossier d'industrialisation et une liste de risques résiduels avec des responsables nommés. Le guide de la NASA sur les risques s'applique ici : « L'état des risques devra être surveillé périodiquement, à une fréquence définie dans le plan de gestion des risques » (NASA SE Handbook 6.4). Un risque résiduel sans responsable ni fréquence de revue n'est pas un risque résiduel ; c'est une hypothèse non résolue.

Jours 76–90 — Prendre la décision (environ semaines 12–13)

Rassemblez les preuves autour des options initiales. Ne notez pas le pilote selon les activités réalisées ou la qualité de la démo. Demandez-vous quelle option les preuves étayent.

La recommandation devrait être l'une des suivantes :

• Poursuivre vers le prochain jalon du Product System, avec des critères d'acceptation.
• Réorienter le périmètre du produit, l'enveloppe opérationnelle ou la proposition de valeur, y compris en confiant une capacité à un partenaire lorsque la responsabilité devrait relever d'un autre acteur.
• Séquencer dans l'attente d'un élément nommé de preuve indisponible, avec son responsable et sa date attendue.
• Arrêter parce que l'opportunité ou le dossier produit ne justifie plus l'investissement.

Le guide de la NASA demande un rapport « qui documente entièrement la décision requise, les évaluations réalisées, les recommandations et la décision finalement prise ». La version de l'horloge est courte.

Critère de sortie : une note de décision de deux pages, une annexe de preuves, les responsables des risques résiduels et la date de la prochaine revue.

flowchart LR
    A["Jours 1-15 Cadrer"] --> G1{"Charte signée et budget d'essais réaliste"}
    G1 -- "oui" --> B["Jours 16-45 Hypothèses décisives"]
    G1 -- "non" --> R["Reformuler l'affirmation ou arrêter"]
    B --> G2{"Une hypothèse décisive réfutée"}
    G2 -- "oui" --> S["Escalader immédiatement au sponsor"]
    G2 -- "non" --> C["Jours 46-75 Candidat produit dans son ensemble"]
    C --> G3{"Exercices réalisés et risques attribués"}
    G3 -- "non" --> P["Séquencer : différer dans l'attente de preuves nommées"]
    G3 -- "oui" --> D["Jours 76-90 Revue de décision"]
    D --> M["Note de décision et date de la prochaine revue"]

La revue du jour 90

La revue confronte la recommandation à la charte ; ce n'est pas une présentation de projet.

sequenceDiagram
    participant EO as Responsable des preuves
    participant PO as Product owner
    participant SL as Responsable sécurité
    participant OP as Opérations du site
    participant DS as Sponsor de la décision
    EO->>DS: Registre des preuves par rapport à la charte initiale
    PO->>DS: Option recommandée et enveloppe
    SL->>DS: État du concept de sécurité et constats ouverts
    OP->>DS: Mesures d'installation, de formation et de gestion des exceptions
    DS->>EO: Contester toute estimation présentée comme observée
    DS->>PO: Décision et critères d'acceptation de la prochaine étape
    DS->>SL: Risques de sécurité résiduels avec responsables et dates

Deux outils originaux pour l'horloge

Les éléments suivants sont des outils de raisonnement Hyperion dérivés des sources ci-dessus. Ce ne sont pas des preuves de terrain, et aucune revendication de résultat ne s'y rattache.

Outil 1 : la borne de fiabilité démontrable

Avant tout essai, calculez la meilleure affirmation de fiabilité que l'horloge pourrait étayer si tout se passait parfaitement. Soit r le nombre d'essais indépendants par jour de terrain que le site peut supporter, et d le nombre de jours de terrain disponibles dans l'horloge. Appliquer la règle de trois au nombre total d'essais donne la borne dans le meilleur des cas, notée B_best :

B_best est la borne de taux de défaillance la plus basse, avec une confiance de 95%, que zéro défaillance sur tous les essais disponibles pourrait justifier. Si le dossier de valeur exige un taux de défaillance inférieur à B_best, aucune exécution de ce pilote ne peut le prouver par les seuls essais. Les options honnêtes sont de restreindre l'affirmation, de prolonger l'horloge en consignant la raison, d'ajouter des preuves d'une autre nature (architecture, injection de fautes, bornes déterministes), ou de consigner l'affirmation de fiabilité comme un risque résiduel doté d'un responsable.

Outil 2 : la maturité de jalon selon le maillon le plus faible

En empruntant au ML Test Score la règle du minimum des sections, notez chacune des quatre couches produit de l'analyse technique approfondie sur la même échelle (0 pour non testé, 0.5 pour testé manuellement avec résultats documentés, 1 pour testé de manière répétable), additionnez au sein de chaque couche, normalisez par le nombre de vérifications de cette couche, et prenez le minimum :

Breck et ses collègues ont choisi le minimum au motif déclaré que « les quatre sections sont toutes importantes ». Pour un pilote d'IA physique, l'argument est plus fort : un excellent score de perception ne compense pas une couche de livraison incapable d'effectuer un rollback, car la défaillance de l'une ou de l'autre arrête le produit. La note de décision présente les quatre scores de couche et le minimum. Une recommandation Poursuivre assortie d'un minimum faible est une contradiction que le sponsor devrait rejeter.

Exemple hypothétique détaillé

Cet exemple est hypothétique. Il ne décrit aucune entreprise, aucun site ni aucun résultat réels.

Une équipe pilote un poste d'inspection de surface par caméra sur une ligne de production. En semaine 1, le responsable des opérations du site propose 20 jours de terrain d'essais observés, et le responsable des preuves décide que, pour que les essais restent raisonnablement indépendants, seules 30 pièces par jour de terrain seront comptabilisées, réparties entre postes, conditions d'éclairage et variantes de pièces. Supposons que les 600 essais comptabilisés soient des inspections indépendantes de pièces dont le défaut est connu, tirées de la population de défauts ciblée. Avec zéro défaut manqué, la borne supérieure approximative à 95% de la probabilité de défaut manqué, B_best, est d'environ 3/600, soit 0.5%.

Le dossier de valeur, rédigé par le product owner, suppose un taux de défauts manqués inférieur à 0.1%. L'horloge ne peut pas le démontrer par des essais. En semaine 2, la charte est amendée : le pilote démontrera une borne proche de 0.5% dans l'enveloppe déclarée, testera si un contrôle humain de second niveau détecte le résidu, et consignera les minutes opérateur par poste consacrées à ce contrôle. Le taux plus exigeant devient un risque résiduel porté par le product owner, avec un plan de collecte de données post-pilote.

Au jour 90, les scores de couche (sur l'échelle normalisée de 0 à 1) sont : perception 0.8, contrôle 0.6, livraison 0.3, produit 0.7. Le minimum est 0.3, dû à un exercice de rollback qui a pris beaucoup plus de temps que le changement qu'il annulait. La recommandation est Réorienter : poursuivre uniquement dans l'enveloppe plus étroite, avec la couche de livraison comme critère d'acceptation nommé pour le prochain jalon.

Liste de contrôle de mise en œuvre

Ce qui invalide l'horloge

Le processus échoue lorsque :

• la décision est réécrite après l'arrivée des preuves ;
• une échéance est traitée comme une autorisation de se passer des preuves de sécurité ou de terrain ;
• la simulation est présentée comme une validation sur le terrain ;
• une estimation optimiste est recopiée comme un résultat observé ;
• personne ne peut arrêter le travail ;
• l'équipe dissimule une hypothèse non résolue dans une phase future ;
• le livrable est automatiquement qualifié de « prêt pour la production ».

Le remède est la gouvernance, et non davantage de vélocité. Maintenez la charte de décision stable, tenez à jour le registre des preuves et rendez les changements visibles.

Ajuster le calendrier honnêtement

Ne raccourcissez l'horloge que lorsque la décision est étroite et que l'environnement de preuve existe déjà. Prolongez-la lorsque les preuves dépendent d'une exploitation saisonnière, de délais d'approvisionnement matériel, d'un examen réglementaire, d'une validation de sécurité ou d'un accès qui ne peut pas être compressé de manière responsable.

Si l'horloge change, consignez pourquoi, quelles preuves sont bloquées et qui est responsable de la prochaine date. Une prolongation sans cette trace est une dérive.

Où elle s'inscrit

L'horloge de décision peut être utilisée à n'importe quel jalon du Physical AI Product System. Elle est particulièrement utile entre Discovery et Productisation, là où la faisabilité technique doit rencontrer les preuves relatives au client, au terrain, à la sécurité, à l'exploitation et à l'économie. Voir aussi : la porte de décision du prototype au produit, le modèle de preuves pour le dossier de sécurité et, sur les métriques d'intervention, Reliable Autonomy: From Robot Demonstration to Sustained Duty.

La Physical AI Product Decision Review repose sur le même principe : produire une recommandation écrite et étayée par des preuves avant qu'un autre investissement produit conséquent ne soit autorisé.

Limites et questions ouvertes

• Aucune preuve de résultat pour l'horloge elle-même. Aucune source citée ici ne mesure si une horloge fixe de quatre-vingt-dix jours améliore les résultats des pilotes d'IA physique. La valeur par défaut est un choix de gouvernance.
• L'indépendance est difficile à établir. L'outil de budget d'essais suppose des essais indépendants. Sur une ligne réelle, les essais peuvent partager des opérateurs, un éclairage, une usure et des versions logicielles. La manière de pondérer à la baisse les essais corrélés relève d'un jugement que le responsable des preuves doit documenter.
• La sécurité face aux événements rares exige plus que des nombres d'essais. La règle de trois comme Kalra et Paddock montrent que de faibles taux de défaillance nécessitent de très grands nombres d'essais. Lorsque les essais disponibles ne peuvent pas étayer la borne requise, l'acceptation de la sécurité doit reposer sur des éléments supplémentaires d'architecture, d'analyse et de conformité, que ce document ne détaille pas.
• Le détail réglementaire est résumé, non analysé. Les énoncés relatifs au règlement sur les machines proviennent de la synthèse de l'EU-OSHA ; les obligations spécifiques exigent le texte du Journal officiel.
• Les scores des quatre couches sont ordinaux. Le minimum est une aide à la décision, et non une mesure physique ; deux équipes peuvent noter différemment les mêmes preuves.
• L'autorité d'arrêt peut être partagée. Les six rôles supposent un sponsor unique capable d'arrêter le travail. Lorsque cette autorité s'étend sur plusieurs organisations, examinez dès le jour 1 si une partie du travail devrait être exécutée par un partenaire.

FAQ

Quatre-vingt-dix jours suffisent-ils pour atteindre la production ?

Pas nécessairement, et l'horloge ne le prétend pas. Quatre-vingt-dix jours constituent une valeur par défaut pour parvenir à une décision étayée par des preuves. La production peut suivre plus tard, ou jamais, selon ce que les preuves étayent.

Et si les preuves nécessitent plus de quatre-vingt-dix jours ?

Prolongez l'horloge en consignant la raison, les preuves bloquées et le responsable de la prochaine date. S'il manque un seul élément nommé, le verdict correct est Séquencer, et non une prolongation sans fin.

Les résultats de simulation peuvent-ils compter dans la décision ?

Oui, à condition d'être étiquetés comme simulés. Des travaux comme ceux de Tobin et ses collègues montrent que la perception entraînée en simulation peut se transférer dans des cadres expérimentaux décrits, mais le transfert vers le matériel et le site réels doit encore être testé avant que les preuves n'étayent une affirmation de terrain.

Combien d'essais suffisent ?

Cela dépend du taux de défaillance dont le dossier produit a besoin. Avec zéro défaillance, N essais indépendants étayent une borne supérieure à 95% d'environ 3/N. Calculez-la en semaine 1 et amendez l'affirmation si l'horloge ne peut pas l'atteindre.

Qui devrait être responsable de la décision d'arrêt ?

Un sponsor de la décision nommément désigné, disposant de l'autorité pour mettre fin au travail. Le NIST AI RMF appelle à des rôles documentés et à des mécanismes permettant de remplacer, désengager ou désactiver les systèmes incompatibles avec l'usage prévu ; l'horloge rend cette autorité explicite avant l'arrivée de toute preuve.