Une route, un hôpital et un modèle partagent un même

Les systèmes critiques échouent différemment, mais exigent la même rigueur: une revendication liée à un contexte, des preuves inspectables, des intervenants...

Une route, un hôpital et un modèle partagent un même problème : les preuves.

The evidence has to survive the handover

A road designer, a hospital team and a model provider can all produce a convincing demonstration. The junction can look orderly on a plan. The clinical screen can look calm in a workshop. The model can return a sensible answer on a carefully selected set of examples. None of that settles the question that matters when the system enters ordinary life: what evidence supports this particular action, for these people, in these conditions, and who is entitled to change course when the evidence no longer holds?

That question is more useful than a debate about whether a road, a hospital or an AI system is “safe”. Safety is not a property that arrives in a cardboard box with the device. It is a continuing relationship between a purpose, a setting, a set of people, a system's limits and the work that happens when a limit is reached. A road needs to accommodate people who make mistakes and conditions that change. A clinical service needs to preserve judgement when information is incomplete, urgent or contested. An AI system needs to remain understandable enough that a person can see when its output has stopped being a useful contribution to a decision.

Europe already has parts of this discipline in different places. Road-infrastructure rules require procedures such as impact assessment, audits, safety inspections and network-wide assessment. The Artificial Intelligence Act asks high-risk systems to work with lifecycle risk management, technical documentation, logs, human oversight, appropriate accuracy, robustness and cybersecurity. European health institutions are discussing safety, equity, governance, workforce readiness and accountability together, rather than treating a clinical model as a piece of software that becomes harmless because its interface has a stethoscope on it.

The common thread is evidence. Not evidence as a thick folder assembled once, and not evidence as a scoreboard with a flattering average. Evidence as something attached to a claim, a context and a decision. A useful evidence record says what the system was meant to do, where the claim applies, which observations support it, which assumptions sit underneath it, what is still uncertain, who can intervene and which change means the argument must be reconsidered.

This is a less glamorous idea than autonomy. It is also more durable. It gives engineers a way to state their limits without pretending that a test set is a complete world. It gives managers a way to ask what they are actually accepting. It gives operators something better than a dashboard that lights up after the decision has already become difficult. Most importantly, it gives people affected by a system a route from an outcome back to the reasons and conditions that produced it.

Three domains, one awkward question

The road, the hospital and the model are not the same system. Their harms, legal duties, evidence bases and professional cultures differ. Nobody should copy a road audit into a clinical workflow, or paste a medical-device checklist onto a language model and call the job finished. The point is not to flatten the differences. The point is to notice a shared engineering problem: an automated or semi-automated system acts through a larger arrangement of people, procedures, interfaces, environments and assumptions.

Une route est un rappel particulièrement clair, car elle ne prend pas de décisions au sens humain du terme. Elle les façonne. La géométrie, les lignes de visibilité, la séparation, les croisements, les marquages, la gestion de la vitesse, l'entretien et le réseau environnant influencent ce que les personnes peuvent voir, ce dont elles peuvent se remettre et la gravité qu'une erreur peut atteindre. Une bonne pratique de sécurité routière ne repose pas sur l'idée d'un usager de la route en permanence vigilant et parfaitement informé. Elle cherche à rendre les erreurs prévisibles moins probables et moins lourdes de conséquences. Le cadre européen pour la gestion de la sécurité des infrastructures routières reflète cette vision systémique à travers des processus d'évaluation et d'inspection répétables, plutôt qu'une simple déclaration selon laquelle un itinéraire a été approuvé.

Un hôpital est différent, mais il vit lui aussi avec l'écart entre une description propre et une réalité changeante. Un parcours clinique comprend des rôles du personnel, des transmissions, des dossiers, des équipements, des priorités, des interruptions et une personne dont l'état peut ne pas ressembler au cas moyen qui a façonné un protocole. Une recommandation peut être utile et néanmoins insuffisante. Un avertissement peut être techniquement correct et arriver à un moment où il ne peut pas être suivi en toute sécurité. Un système peut améliorer une partie d'un flux de travail tout en créant une nouvelle charge ailleurs. C'est pourquoi la discussion sur l'IA dans le domaine de la santé ne peut pas s'arrêter à la performance apparente d'un modèle. Elle doit inclure la gouvernance, la responsabilité clinique, la qualité des données, la formation, la confiance du public et les moyens d'identifier et de corriger les préjudices.

Un modèle se trouve dans le même type d'agencement. Il est entraîné ou configuré quelque part, connecté à des données ailleurs, recevant une invite ou une tâche d'une personne, placé derrière une interface, surveillé par certaines personnes et pas par d'autres. Il produit une sortie, mais cette sortie ne devient conséquente que lorsque quelqu'un la traite comme une raison d'agir. Entre la sortie et l'action se trouvent des seuils, l'autorité, la pression du temps, l'accès aux sources, la formation, les incitations et la possibilité de dissension. Ce ne sont pas des détails opérationnels décoratifs. Ils déterminent si un composant techniquement compétent reste un composant sûr du système plus large.

Considérez ce qui suit comme un composite explicitement hypothétique, et non comme le récit d'une route, d'un hôpital, d'un patient, d'un employé ou d'un incident réels. Une autorité locale envisage un système qui signale des emplacements pour un examen de la sécurité routière. Un hôpital envisage un outil qui aide à trier des documents administratifs avant que le personnel clinique ne les voie. Une troisième organisation envisage un modèle qui rédige un résumé des risques pour un gestionnaire d'infrastructures. Dans chaque contexte, une démonstration précoce montre que le système peut trouver des schémas dans les dossiers existants. La démonstration ne répond pas encore à la question de savoir si les dossiers représentent les conditions que le service verra le mois prochain, si un cas inhabituel peut être reconnu, si les personnes qui reçoivent une recommandation ont suffisamment de temps et d'autorité pour la remettre en question, ou si l'organisation remarquera un schéma préjudiciable avant qu'il ne devienne un travail normal. Le problème de la preuve commence exactement là.

L'erreur facile est de demander un seul chiffre. Quelle est la précision ? Combien de temps cela fera-t-il gagner ? Combien de risques cela détectera-t-il ? Ces questions sont légitimes mais incomplètes. Un chiffre a besoin d'un dénominateur, d'un échantillon, d'une définition, d'une date, d'une utilisation prévue et d'une déclaration de ce qui a été exclu. Il a également besoin d'un lien avec la décision suivante. Un score élevé sur une tâche étroite et stable peut étayer une affirmation étroite et stable. Il ne peut pas autoriser silencieusement un flux de travail différent, une population différente ou une décision ayant une conséquence différente.

La preuve n'est pas un accessoire décoratif

La preuve devient utile lorsqu'elle peut faire changer d'avis quelqu'un. Cela semble évident, mais de nombreux dossiers de preuves sont conçus pour paraître complets plutôt que pour rendre une décision contestable. Ils contiennent des captures d'écran, des déclarations de politique, des résumés de tests et des signatures, mais ne montrent pas quelle affirmation chaque élément étaye, quelle condition limite l'affirmation, ni ce qui devrait se passer si la condition change. Le résultat est de la paperasse au rôle cérémoniel. Elle peut prouver qu'une réunion a eu lieu. Elle ne peut pas nécessairement dire à un opérateur quoi faire à 07:40 lorsque le service est occupé, que les données sont en retard et qu'une recommandation ne correspond pas au cas qui se présente à lui.

Un meilleur point de départ est une décision nommée. Pas « déployer l'IA de manière responsable » ni « améliorer la sécurité routière », mais une proposition avec une limite. Par exemple : ce système peut prioriser une classe définie de travaux de révision, dans un contexte opérationnel spécifié, tandis qu'un rôle nommé reste responsable d'accepter ou de rejeter la recommandation. Ou encore : cette conception peut être ouverte à la circulation après que les dangers identifiés ont été évalués selon le processus requis et que les contrôles identifiés sont en place. La formulation est délibérément moins enthousiasmante qu'une annonce de produit. C'est un contrat avec la réalité.

Une fois la décision nommée, le reste du dossier a un point d'attache. L'objectif visé indique au lecteur ce qu'il ne faut pas déduire. Le contexte lui indique quel site, quel flux de travail, quels utilisateurs, quelles données, quels équipements et quel processus environnant importent. Les preuves consignent les tests, les observations, le matériel source, les examens et les exercices. Les hypothèses rendent les dépendances visibles : peut-être qu'un opérateur a reçu une formation, peut-être qu'un registre source est à jour, peut-être qu'une alerte particulière atteint un rôle particulier à temps. Le propriétaire identifie qui peut interpréter le matériel et intervenir. Les déclencheurs de révision indiquent quel signal, quel changement ou quelle défaillance d'une hypothèse nécessite un nouvel examen.

La preuve devient opérationnelle lorsqu'un lecteur peut retracer une affirmation jusqu'à ses conditions, son autorité et son parcours de révision.

Cette structure a une conséquence importante. Elle empêche la preuve de s'éloigner de son usage. Un test n'est pas simplement classé sous « validation ». Il est relié à une affirmation concernant un comportement particulier dans des conditions énoncées. Un audit n'est pas seulement la preuve qu'un auditeur a effectué une visite. Il devient un enregistrement de ce qui a été examiné, de ce qui a été constaté, de ce qui est resté incertain et de quelle autorité a décidé de la suite. Une évaluation de modèle n'est pas un badge général. C'est une observation limitée dont la pertinence dépend de la version du modèle, de la tâche, des données, de la configuration et des conditions de déploiement.

The same record should make absence visible. If nobody has tested a system with an uncommon but consequential input, that is not a small embarrassment to hide beneath an average. It is an evidence boundary. If a human can technically override a recommendation but has no time, access or authority to do so in the real workflow, that is not meaningful oversight. It is a design gap. If a road safety inspection notices a recurring condition but no organisation owns the remedial work, the observation has not yet become a control. In serious systems, missing evidence is a result. It tells the organisation where it cannot yet make a claim.

Road safety offers a practical lesson in humility

Road safety has spent decades learning that harm is rarely explained by a single bad actor or a single bad component. The person driving too quickly, the crossing that is hard to read, the vehicle, weather, lighting, maintenance state, traffic mix and emergency response may all matter. That does not dissolve individual responsibility. It does prevent the shallow conclusion that every failure can be fixed by telling people to pay more attention. A system that only works when nobody makes a foreseeable mistake is not an impressively strict system. It is a fragile one.

The EU's road-infrastructure safety-management rules provide a useful counterweight to the idea that approval is a one-off event. They organise safety work around procedures that look at prospective consequences, design, operation and the existing network. The exact legal scope matters, and the rules should be read as road-infrastructure law rather than a general template for every technology. Still, their underlying habit is broadly valuable: inspect the system in the conditions in which it will operate, look for patterns rather than waiting for a dramatic event, and treat knowledge as a reason to adjust the arrangement.

That habit is not simply “collect more data”. Data without a question is a very efficient way of storing confusion. The road-safety question might concern where a crossing creates a conflict, which people are exposed to it, how often the conditions occur, what kind of mistake is foreseeable, which physical or operational measures reduce the risk, and how the organisation will know whether the measure has changed the situation. The evidence that matters is therefore mixed. It includes traffic conditions, design records, inspection observations, maintenance information, reports of harm and professional judgement. A map alone cannot carry the claim. Neither can a single collision statistic.

There is a useful human-factors point here. The system has to be designed for people as they are, not for a fictional user who reads every sign, judges every speed perfectly and never arrives distracted, tired, inexperienced, rushed, ill or simply surprised. That is not an excuse for careless behaviour. It is an acknowledgement that safety engineering has to work in the space between intention and actual human capability. When a system relies on a person to notice, understand and act, those three steps need evidence of their own. Can the signal be seen? Can its meaning be understood? Can the person act in time and with enough authority?

AI teams often miss this because the human is represented as a box at the end of a flow diagram. The box says “reviewer”, “operator” or “human in the loop” and therefore appears to solve the problem. But a role name does not describe an interaction. A useful review design needs to say what the person sees, what they do not see, what evidence they can inspect, whether they can request another route, when they are expected to disagree, what happens after disagreement and how the organisation learns from it. These questions are as ordinary as checking whether a crossing can be used safely in rain or darkness. They are also much more informative than a promise that a person remains involved.

Un hôpital ne peut pas faire disparaître l'incertitude

Les soins de santé rendent le problème des données particulièrement visible, car les conséquences sont personnelles et le contexte est complexe. Un système clinique ou administratif utile peut aider le personnel à trouver des informations, réduire le travail répétitif, repérer un schéma possible ou préparer des documents en vue d'un examen. Cela n'en fait pas pour autant une autorité clinique. Le passage de l'information au traitement, à la priorisation ou au refus de soins comporte des obligations qui ne peuvent pas être déléguées à une interface. La personne responsable des soins doit savoir ce que le système a fait, ce qu'il n'a pas fait, et comment réagir lorsque le résultat entre en conflit avec les faits disponibles dans le dossier.

Les travaux de l'OMS/Europe sur l'IA dans la santé formulent la question avec le vocabulaire qu'elle mérite : sécurité, efficacité, équité, droits humains, transparence, responsabilité, gouvernance et préparation du personnel. Il ne s'agit pas d'exiger que chaque professionnel clinique devienne un spécialiste de l'apprentissage automatique. Il s'agit de reconnaître qu'un système ne peut pas être utilisé de manière responsable si les personnes censées s'y fier, le superviser ou le contester ne disposent pas d'un compte rendu utilisable de ses limites. La formation fait partie de l'environnement de contrôle. Il en va de même des voies d'escalade, des dispositifs de responsabilité, des preuves de performance dans le monde réel et d'un moyen pour les patients et les professionnels de soulever des préoccupations sans devenir d'abord des experts de la technologie.

La Commission européenne place également l'IA dans la santé dans un cadre réglementaire et opérationnel plus large. Ses documents de santé publique notent que les logiciels d'IA à usage médical peuvent relever des exigences à haut risque de la loi sur l'IA, notamment l'atténuation des risques, la qualité des données, l'information des utilisateurs et la surveillance humaine. Il ne s'agit pas d'affirmer que chaque outil utilisé dans un hôpital reçoit la même classification juridique. Il s'agit d'un rappel que le mot « santé » n'atténue pas la nécessité d'une analyse minutieuse de l'usage prévu. Plus l'utilisation est lourde de conséquences, moins il est crédible de s'appuyer sur des assurances générales.

La pratique clinique montre également pourquoi les seuils d'intervention doivent être explicites. Un système peut être autorisé à récupérer une source, à préparer un résumé, à signaler un champ manquant ou à suggérer qu'un cas mérite une attention particulière. Ce sont des actes différents. Chacun s'éloigne un peu plus de l'information pour se rapprocher de l'influence. À un moment donné, un système peut être autorisé à prendre une mesure opérationnelle limitée, peut-être avec des règles qui restreignent la portée et un enregistrement qui rend la mesure réversible. Au-delà de ce point, il pourrait être appelé à agir sans décision humaine simultanée. Les preuves, l'autorité et la conception de récupération nécessaires à ces niveaux ne sont pas interchangeables.

Cela ne rend pas l'automatisation impossible. Cela rend les affirmations proportionnées. Une organisation peut choisir une tâche modeste et bien délimitée et la rendre fiable avant d'en imaginer une plus vaste. Elle peut conserver le matériel source disponible plutôt que de transformer un résumé en seul enregistrement. Elle peut donner à un clinicien ou à un autre travailleur responsable un moyen réel de mettre le système en pause, et non un bouton théorique caché dans un manuel de politique. Elle peut surveiller ce qui se passe après le déploiement et traiter un comportement inattendu comme une preuve que l'argument initial doit être révisé. C'est plus lent que de déclarer que le modèle a pris le dessus. C'est généralement plus rapide que d'essayer de reconstruire une décision après que la confiance a déjà été perdue.

Le modèle n'est pas l'ensemble du système

The AI Act is valuable here because it refuses, in its high-risk provisions, to treat the model as the only relevant object. Article 9 sets out a documented, maintained and continuous iterative risk-management process. Article 10 concerns data and data governance. Article 11 and Annex IV address technical documentation. Article 12 addresses automatic recording of relevant events. Article 14 addresses effective human oversight, including the ability to understand relevant limits, override or reverse output where appropriate, and stop the system safely. Article 15 concerns accuracy, robustness and cybersecurity. These are not interchangeable paperwork categories. Together they point at a system that has to be understood across its lifecycle.

The law does not make a technical judgement for every organisation. It does not announce that a given performance measure is enough, nor does it make an operator competent by naming them in a document. It does something more demanding. It requires a way of connecting intended purpose, risk, documentation, records, human oversight and ongoing monitoring. That connection is precisely what gets lost when an AI project is described as a model acquisition rather than an operational change.

Take the commonplace claim that a human can override the model. Override what, exactly? A probability, a ranking, a generated paragraph, a routing decision, an automatic notification, a resource allocation or a physical action? Before or after it takes effect? With which information? Under which time constraint? Does the human see why the system reached the output, or merely that it did? Are there consequences for disagreeing? Is the disagreement recorded? Is it reviewed as a possible model, data or workflow problem? A truthful answer to these questions is more reassuring than a glossy assurance because it describes a control that can actually be exercised.

Human oversight is sometimes treated as a moral accessory: add a person to the process and the system becomes humane. It is better understood as an engineering relationship. The person needs a meaningful opportunity to detect a limitation, the authority to intervene, an action that changes the outcome, and a system state that remains safe when the intervention happens. A powerless reviewer is a witness. A reviewer who only sees an output after it has become irreversible is an auditor of a decision already made. Neither arrangement is equivalent to oversight.

Evidence should therefore grow as discretion and irreversibility grow. A retrieval tool that helps a professional find source material has one kind of evidence burden. A system that ranks work for attention has another, because ranking shapes what may be seen late or not at all. A constrained system that automatically performs an operational task needs clear boundaries, monitoring and a recovery route. A system that acts without a live decision needs the strictest case: a narrow purpose, evidence for the operating context, fail-safe behaviour, independent challenge where appropriate, clear ownership and continuing review. The designation is less important than the principle. More autonomy is a larger claim, not a marketing upgrade.

Lorsqu'un système automatisé passe du rôle d'information à l'action autonome, les exigences en matière de preuve, d'intervention et de rétablissement doivent se renforcer, et non s'amenuiser.

Les seuils empêchent un outil utile de devenir une décision sans propriétaire

Un seuil d'intervention est une réponse pratique à une question pratique : quand le système est-il autorisé à agir, et quand doit-il rendre la main ? Il doit être visible avant le déploiement, et non découvert à la suite d'une réclamation. Un seuil peut dépendre de la confiance, mais la confiance seule ne suffit pas. Il peut dépendre du type de décision, des conséquences d'une erreur, de la qualité et de la fraîcheur des données, de la présence de preuves contradictoires, de la disponibilité d'une personne qualifiée, de la capacité à récupérer et du degré auquel le cas relève de l'objectif déclaré.

Les seuils ne prouvent pas qu'un système est sûr. Ils empêchent un système de revendiquer plus d'autorité que ses preuves ne peuvent en soutenir. Un modèle peut résumer un dossier sans pouvoir en évaluer l'exhaustivité. Il peut identifier un terme sans en déterminer la portée juridique. Il peut produire une explication plausible sans en établir la véracité. Il peut reconnaître un schéma courant et rester inadapté aux cas inhabituels, aux sources contradictoires ou aux situations où une petite erreur serait difficile à inverser. Le seuil est le point où l'organisation transforme ces distinctions en comportement.

Pour une autorité routière, un seuil pourrait stipuler qu'une combinaison de constats d'inspection et d'indicateurs de risque définis mène à un examen formel, tandis qu'une combinaison différente exige une mesure temporaire urgente. Les critères exacts relèvent du cadre juridique et professionnel applicable. L'idée transférable est que le chemin de l'observation à l'intervention ne devrait pas dépendre entièrement de qui se trouve de service ou de la préoccupation la plus vivement évoquée en réunion. Les preuves ne remplacent pas le jugement professionnel. Elles donnent au jugement un dossier partagé et un chemin reproductible.

Pour un hôpital, un seuil pourrait distinguer un outil qui prépare des documents pour examen d'un système capable d'effectuer une action administrative contrainte. Ce dernier nécessite un enregistrement clair de sa portée, un moyen de détecter une exception, un propriétaire désigné pour cette exception et un moyen de restaurer l'état antérieur si l'action était erronée. Si le système touche à une décision cliniquement significative, le seuil doit tenir compte des obligations cliniques, juridiques et professionnelles applicables. La personne responsable ne doit pas être contrainte de réparer un résultat d'automatisation opaque, sans traçabilité et sans temps pour l'examiner.

Pour un système d'IA dans les infrastructures, un seuil peut distinguer une prévision d'une action de contrôle. Une prévision peut alerter un opérateur sur une condition qui mérite d'être vérifiée. Une action de contrôle peut modifier un état physique ou opérationnel. La deuxième affirmation exige une justification bien plus solide de la qualité des données d'entrée, des limites du système, des conditions environnementales, de la surveillance, de l'autorité, des solutions de repli et de la récupération. Il ne s'agit pas d'une bureaucratie imposée pour contrarier les ingénieurs. C'est la description technique de ce qui se produit lorsque le coût d'une erreur n'est pas une réponse décevante dans une fenêtre de discussion.

Le seuil le plus utile est souvent un seuil de refus. Qu'est-ce qui devrait amener le système à refuser d'agir ? Quelle donnée manquante, quel conflit, quel enregistrement tardif, quelle condition hors distribution, quel réviseur indisponible ou quel changement non testé devrait déclencher une pause de sécurité ? Les organisations ont tendance à décrire ce qu'elles espèrent que leur système fera. Elles sont moins enclines à écrire quand il doit s'arrêter. Pourtant, le comportement d'arrêt d'un système révèle souvent plus sur sa maturité que son comportement de vitrine. La capacité de dire « ce cas est en dehors des preuves » n'est pas un défaut. C'est la preuve que la limite existe.

Les facteurs humains font partie des preuves, pas une note de bas de page

Les facteurs humains sont parfois réduits à la constatation que les gens sont faillibles. C'est vrai, mais pas très utile en soi. La question technique est de savoir comment le travail est organisé autour de l'attention, de la mémoire, de la perception, de la charge de travail, de la communication et de l'autorité humaines réelles. Un avertissement qui ne peut pas être remarqué n'est pas un avertissement. Une explication complexe qui ne peut pas être comprise sous pression de temps n'est pas une transparence significative. Une commande d'arrêt qui nécessite l'approbation de quelqu'un qui est indisponible n'est pas une commande d'arrêt. Un écran de révision qui masque l'enregistrement sous-jacent n'est pas une surface de preuve.

La conception des routes rend cela concret. Les gens se déplacent dans un environnement physique avec un temps limité pour voir, interpréter et agir. Le système ne peut pas être évalué uniquement en décrivant ses signaux prévus. Il doit être évalué en considérant si les personnes concernées peuvent les utiliser dans l'environnement réel. Les soins de santé font le même point dans un registre différent. Le lecteur d'une alerte ou d'une recommandation peut être interrompu, confronté à des priorités concurrentes, couvrant un collègue ou confronté à un cas qui ne correspond pas parfaitement au processus. L'IA ajoute une autre couche, car une sortie fluide peut créer une fausse impression que le système a pesé des preuves qu'il a simplement reformulées.

La réponse n'est pas d'exiger une concentration surhumaine. C'est de concevoir et de tester le transfert. Qu'est-ce que le système montre en premier ? Quelle source la personne peut-elle inspecter ? Comment exprime-t-il l'incertitude ? La personne peut-elle demander un itinéraire différent ? L'interface distingue-t-elle un enregistrement confirmé d'une inférence ? Peut-elle dire si le modèle, la source de données, la règle ou la configuration a changé ? Qu'advient-il des commentaires ? Ce sont des questions empiriques et organisationnelles. Elles méritent des exercices, de l'observation, des recherches utilisateurs et un examen post-déploiement, pas seulement une déclaration selon laquelle l'interface a été conçue en pensant à l'utilisateur.

Un dossier de preuves responsable devrait capturer l'arrangement humain sans devenir un dossier sur les travailleurs individuels. Il peut enregistrer le rôle, l'autorité, l'exigence de formation, l'intervention attendue, le temps disponible, la surface d'information, la voie d'escalade et le résultat de l'exercice. Il peut enregistrer qu'un processus a été testé dans un scénario déclaré sans prétendre que le scénario prouve chaque condition future. Il peut préserver une trace de décision sans utiliser la surveillance comme excuse pour une surveillance inutile. Ces équilibres sont difficiles. Ils sont toujours mieux gérés ouvertement que laissés à une instruction vague selon laquelle les gens devraient « faire preuve de jugement ».

L’instinct néerlandais qui consiste à rendre lisibles des systèmes complexes a ici toute son utilité. Un carrefour cyclable, un registre public ou un processus bien étiqueté ne devient pas bon simplement parce qu’il est clair, mais la clarté permet de voir où se situe la responsabilité. Une bonne gouvernance fait preuve d’une modestie semblable. Elle ne promet pas qu’aucun jugement difficile ne surviendra. Elle rend visible le chemin du jugement difficile avant le jour où il sera nécessaire. Il n’y a pas de cérémonie d’inauguration pour un chemin d’escalade bien défini, ce qui explique peut-être pourquoi on le laisse si souvent à plus tard.

La preuve a une durée de vie

La partie la plus difficile du travail fondé sur les preuves est d’accepter que les preuves d’hier puissent être exactes et néanmoins ne plus suffire. Un modèle change. Une source de données change. Un fournisseur change un composant. Un flux de travail est réorganisé. Un nouveau groupe de personnes utilise le service. Une route est modifiée, entretenue différemment ou exposée à un schéma de circulation différent. Un hôpital change ses effectifs, ses logiciels, ses modalités de triage ou ses dossiers. Le test initial peut rester valable en tant qu’observation historique, mais l’affirmation qui en découle peut nécessiter une limite différente.

C’est pourquoi l’historique des versions n’est pas une simple formalité administrative. Un lecteur qui ne peut pas identifier quelle version d’un modèle, d’une configuration, d’une source de données, d’une politique ou d’une interface a produit un résultat ne peut pas reconstituer les conditions de la décision. Une équipe qui ne consigne pas les changements importants ne peut pas distinguer un nouveau problème d’un ancien. Une organisation qui considère la publication comme la fin de l’assurance devra tôt ou tard redécouvrir pourquoi sa confiance était justifiée, précisément au moment où la réponse importe le plus.

La surveillance après mise sur le marché au titre de l’AI Act reconnaît cette réalité du cycle de vie pour les systèmes à haut risque. L’exigence n’est pas une promesse que la surveillance élimine l’incertitude. C’est une reconnaissance du fait que les informations arrivent après le déploiement et doivent avoir un chemin de retour vers la gestion des risques. La leçon équivalente en matière de sécurité routière est bien connue : les systèmes doivent être inspectés et évalués pendant leur fonctionnement, plutôt que d’être présumés sûrs parce qu’ils ont un jour satisfait à une exigence de conception. Dans le domaine de la santé, l’utilisation réelle, l’expérience du personnel, l’impact sur les patients et les modalités de gouvernance comptent autant que toute évaluation préalable au déploiement.

Un déclencheur d’examen doit être suffisamment précis pour être utilisé. « Examiner périodiquement » est une manière polie de demander à de futurs collègues de deviner. Un meilleur déclencheur nomme l’événement important : une nouvelle version du modèle, une modification d’une source d’entrée, un nouveau lieu de déploiement, un groupe d’utilisateurs modifié, un écart non résolu, un schéma de réclamations, un signal de sécurité, une incapacité à exécuter une étape de surveillance, ou un changement dans l’autorité qui est propriétaire de la décision. La liste sera différente pour chaque système. Ce qui importe, c’est que l’argument initial nomme les conditions qui pourraient le rendre obsolète.

Cela change également le sens d’une piste d’audit. Une piste d’audit ne devrait pas être un entrepôt rempli d’événements que personne ne peut interpréter. Elle devrait être un chemin à travers l’histoire du système. Quelle affirmation était en vigueur ? Quelles preuves la soutenaient à l’époque ? Quelle version a produit le résultat ? Quelle personne ou quel rôle a pris la mesure décisive ? Que s’est-il passé lorsque le système a été contesté ? Quel problème a été résolu, et lequel est resté ouvert ? Le dossier doit être proportionné. Il doit également être capable de répondre à une question réelle sans exiger une expédition archéologique héroïque à travers les journaux d’application.

À quoi ressemble une question de preuve sérieuse

Lorsqu’une organisation évalue un système critique pour la sécurité, la question utile est rarement « est-ce que ça marche ? ». Pour qui, dans quel but, dans quelles conditions, par rapport à quoi, et avec quelle conséquence en cas d’échec ? Ces questions peuvent sembler lentes parce qu’elles empêchent un « oui » facile. Ce sont aussi les questions qui donnent de la valeur à un « oui » ultérieur.

Une bonne revue demande donc une chaîne plutôt qu'une collection. Elle demande à l'équipe de nommer l'objectif visé et la décision qui en découle. Elle demande quels préjudices et modes de défaillance sont pertinents. Elle demande quelles preuves étayent chaque affirmation importante, et ce que ces preuves ne montrent pas. Elle demande quelles hypothèses doivent rester vraies. Elle demande qui a l'autorité de superviser, d'outrepasser, de suspendre et de réparer. Elle demande comment le système se comporte lorsque les preuves manquent ou que le cas sort du cadre. Elle demande ce qui sera surveillé après la mise en service, et quel changement déclenche une réévaluation.

Il n'existe pas de score universel qui conclut cet exercice. La route a son contexte, l'hôpital le sien, le modèle encore un autre. Un petit système bien conçu peut présenter un dossier de preuves plus solide qu'un système vaste décrit avec plus d'assurance. Une affirmation étroite avec une limite claire n'est pas une affirmation faible. C'est le début d'une affirmation honnête.

C'est aussi pourquoi nos pages de recherche décrivent des questions explicites, des limites de preuves et un état d'accès, plutôt que de présenter par défaut la recherche comme une capacité aboutie. La méthode est modeste : identifier la question, rendre visible la limite des preuves et maintenir l'état de publication lisible. Elle ne prouve pas qu'un produit convient à un déploiement particulier, et elle ne remplace pas une assurance spécifique au secteur. C'est néanmoins une habitude utile. Si une organisation ne peut pas dire ce que ses preuves soutiennent, ce qu'elles ne soutiennent pas et qui peut les contester, elle n'a pas encore mérité une affirmation plus forte.

Une route, un hôpital et un modèle partagent un même problème. Chacun a besoin d'un moyen de transformer la connaissance en action sans cacher les conditions dans lesquelles cette action est justifiée. La réponse n'est pas un document de cérémonie, un score moyen ou un bouton marqué « supervision humaine ». C'est une pratique de preuves qui reste reliée à l'objectif, aux personnes, à l'autorité et au changement. Ce travail n'est pas glamour. C'est ainsi qu'un système devient responsable avant de devoir devenir explicable.

Une route, un hôpital et un modèle partagent un même problème : les preuves.