Haut risque : ce qui doit exister avant l'échéance

Les obligations applicables aux systèmes à haut risque portent sur des pièces datées, et une pièce datée ne se produit pas rétroactivement. C'est ce qui les rend différentes des obligations déjà en vigueur.

Une politique interne se rédige en une journée, quelle que soit la date. Une analyse de risque menée avant la mise en service ne se rédige pas après : elle porte sur une décision passée, et son antidatage n'est ni possible ni souhaitable.

Les journaux posent le même problème sous une forme plus nette. Un système qui n'a rien journalisé pendant dix-huit mois ne peut pas produire ces traces, quelle que soit la bonne volonté de l'équipe.

D'où une règle pratique : les pièces qui se datent doivent être mises en place maintenant, les autres peuvent attendre.

La grande majorité des systèmes déployés en entreprise ne relèvent pas du haut risque, et le vérifier évite un travail considérable. C'est la première chose à établir, en une demi-journée.

Les catégories concernées sont énumérées, pas laissées à l'appréciation. Elles portent notamment sur le recrutement et la gestion des travailleurs, l'accès à l'éducation, l'accès aux services essentiels, et certains usages en matière de sécurité.

Un système qui aide un gestionnaire à retrouver une procédure n'en relève pas. Un système qui trie des candidatures en relève. Entre les deux, il existe des cas limites qui méritent un avis.

Le critère qui oriente correctement dans la plupart des cas : le système intervient-il dans une décision qui affecte les droits ou les perspectives d'une personne identifiée. Voir pratiques interdites : ce qu'aucun garde-fou ne rattrape.

Activer la journalisation coûte une journée et sa valeur croît chaque jour où elle tourne : c'est le seul chantier dont le report a un coût irréversible. Il doit passer avant tout le reste.

Ce qu'il faut tracer est court : la question posée, les documents fournis au modèle, la réponse produite, la décision humaine qui a suivi, et l'horodatage. Cinq champs.

Cette trace sert la conformité et, bien avant elle, l'exploitation quotidienne : sans elle, aucune réponse fausse n'est diagnosticable, et chaque incident produit une enquête sans conclusion, le mécanisme décrit dans l'observabilité des systèmes IA.

Deux précautions accompagnent la mise en place. La durée de conservation doit être décidée explicitement, en tenant compte de la protection des données. Et les journaux doivent être exploitables : un fichier que personne ne sait interroger ne sert ni au diagnostic ni au contrôle.

Une analyse de risque utile tient en trois pages et se construit autour d'une seule question : que se passe-t-il si le système se trompe. Elle n'exige aucun formalisme particulier.

La méthode que j'applique tient en quatre temps. Lister les façons dont le système peut se tromper, pas les pannes, les erreurs de contenu. Pour chacune, décrire la conséquence pour la personne concernée. Évaluer la probabilité à partir du jeu de tests, qui donne un taux d'erreur réel. Et décrire la mesure qui limite la conséquence.

Ce dernier point est celui qui compte. Une erreur détectable et rattrapable par un contrôle humain n'a pas le même statut qu'une erreur qui produit une décision définitive sans qu'on s'en aperçoive.

Cette analyse a une valeur d'ingénierie qui dépasse la conformité : elle désigne précisément où placer les contrôles, et elle révèle souvent qu'une erreur considérée comme mineure a une conséquence disproportionnée.

Une personne par système, une fiche d'une page, et un rendez-vous trimestriel suffisent à tenir l'ensemble. La lourdeur vient de l'organisation choisie, pas de l'obligation.

Le schéma qui échoue est le dossier central confié à un service unique, qui doit interroger toutes les équipes et produire une documentation pour des systèmes qu'il ne connaît pas. Ce dossier n'aboutit jamais.

Le schéma qui fonctionne répartit : chaque équipe rédige la fiche du système qu'elle a construit, en une heure, sur un modèle commun. Un rôle central consolide et relit, sans rédiger.

Le rendez-vous trimestriel sert à relire les fiches et à repérer les systèmes qui ont dérivé de leur finalité initiale, dérive qui est la règle et non l'exception, comme expliqué dans écrire la fiche d'un système d'IA.