La gouvernance de l'IA a un calendrier de maintenance.

Governance n’est pas l’approbation qui intervient avant la mise en service d’un système d’IA. C’est le travail ordinaire qui consiste à observer, décider,...

La gouvernance de l'IA a un calendrier de maintenance.

Le calendrier derrière la politique

La plupart des documents de gouvernance sont rédigés comme si le travail intéressant se déroulait avant que le système ne soit utilisé. Quelqu'un identifie un objectif. Une équipe évalue un risque. Un responsable signe une ligne. Un fournisseur fournit un PDF dont le nom de fichier contient le mot final, ce qui constitue généralement un petit avertissement. Puis le système entre dans la vie ordinaire, où une source de données est remplacée, une personne apprend une solution de contournement, une politique change, un prestataire met à jour un composant, ou un cas auparavant inhabituel devient courant. L'approbation reste dans son dossier. Le monde, lui, ne reste pas en place.

C'est pourquoi la gouvernance de l'IA a besoin d'un calendrier de maintenance. Pas une réunion annuelle de pure forme avec une diapositive montrant sept points verts. Un calendrier d'actes de soin ordinaires : vérifier si l'objectif déclaré est toujours vrai, lire les signaux qui pourraient modifier le jugement de risque, décider qui peut modifier le système, répéter ce qui se passe lorsqu'il doit être arrêté, consigner pourquoi une modification a été faite, et retirer les preuves lorsque leurs conditions ont expiré. C'est moins prestigieux qu'une annonce de lancement. C'est aussi là que la responsabilité devient réelle ou s'évapore silencieusement.

Cette distinction importe parce que les systèmes d'IA ne restent pas là où leur évaluation initiale les a placés. Un modèle peut rester inchangé tandis que ses entrées, ses utilisateurs, son interface, sa voie de déploiement, ses outils connectés, son processus métier ou son contexte juridique changent. Un modèle peut changer tandis que l'utilisation semble stable. Un système peut rester techniquement disponible mais devenir opérationnellement inadapté parce que les personnes qui pourraient le contester ont changé de poste, parce que la file d'examen est pleine, parce qu'un nouvel usage en aval a donné à sa sortie une conséquence différente. Une gouvernance qui traite la date de sortie comme la ligne d'arrivée gouverne une photographie.

Les règles européennes contiennent déjà une idée plus exigeante. Pour les systèmes d'IA à haut risque, l'article 9 du règlement sur l'IA qualifie la gestion des risques de processus itératif continu, planifié et exécuté sur l'ensemble du cycle de vie, avec un examen et une mise à jour systématiques et réguliers. L'article 72 exige un système de surveillance après mise sur le marché proportionné et documenté qui collecte, documente et analyse activement et systématiquement les informations de performance pertinentes tout au long de la durée de vie d'un système. Le propos n'est pas que chaque petit logiciel ait besoin du même appareillage. C'est qu'une technologie conséquente a besoin d'un rythme de fonctionnement, et pas seulement d'un fichier de départ.

La question utile n'est donc pas : « Avons-nous un cadre de gouvernance de l'IA ? » C'est : « Que se passe-t-il mardi prochain lorsque les preuves ne correspondent plus au service ? » Qui voit cela en premier. Quelles informations ont-ils. Qui peut décider s'il s'agit d'une correction ordinaire, d'un changement substantiel, d'un incident ou d'une raison de faire une pause. Comment la décision initiale est-elle préservée sans devenir une excuse. Et lorsque le système fonctionne encore techniquement, mais que l'institution a cessé de comprendre les conditions de son utilisation, qui est autorisé à dire que fonctionner ne suffit plus ?

Un calendrier de maintenance ne répond pas à ces questions avec un tableau de bord générique. Il les assigne à des personnes et à des moments. Il donne à chaque enregistrement une raison d'être réexaminé. Il rend l'utilisation continue d'un système conditionnelle à une relation vivante entre les preuves, l'autorité et le travail réel qui l'entoure.

Ce qui se dégrade après le lancement

Un logiciel n'a pas besoin d'échouer pour devenir moins gouvernable. La dégradation la plus courante est plus discrète. Une équipe a une bonne description de l'utilisation prévue, mais le service s'étend de côté. Un assistant conçu pour la rédaction interne est copié dans un parcours client. Un classificateur construit pour trier un ensemble fixe de documents reçoit un nouveau type de soumission. Un système initialement examiné par un petit groupe devient partie d'un processus plus large où personne ne connaît la limite qui comptait au début. Rien dans ce récit n'exige un désastre inventé. C'est simplement ce qui se produit lorsqu'une institution change plus vite que ses enregistrements.

L’objectif se dégrade en premier, car il est souvent formulé comme un nom, alors qu’il s’agit en réalité d’une limite. « Aide à la décision » n’est pas un objectif suffisant si le dossier ne peut pas préciser quelle décision, pour qui, avec quelles données, avec quelle autorité, et ce que le résultat ne doit pas déclencher. Un énoncé d’objectif doit être revu lorsqu’une nouvelle équipe commence à utiliser le système, lorsqu’un résultat commence à ouvrir ou à fermer une voie importante, lorsqu’une nouvelle population est concernée, ou lorsque la transmission humaine devient moins significative. Les mots peuvent rester les mêmes tandis que la conséquence pratique augmente considérablement.

Les preuves se dégradent ensuite. Un résultat d’évaluation est une observation dans des conditions définies. Il peut être utile longtemps, mais il n’est pas immortel. L’état mesuré du modèle peut avoir changé. La distribution des données peut avoir évolué. Les personnes qui utilisent le système peuvent désormais interpréter son résultat différemment. Un benchmark peut couvrir un sous-ensemble qui était initialement représentatif et ne l’est plus. Le test lui-même peut rester reproductible alors que l’argument justifiant de s’y fier s’est affaibli. Conserver le rapport est une bonne pratique d’archivage. Le traiter comme une preuve actuelle sans vérifier ses conditions est autre chose.

Les interfaces se dégradent aussi. Cela est souvent négligé, car un changement d’interface peut sembler anodin. Une nouvelle valeur par défaut, un bouton plus visible, une explication raccourcie, un appel d’outil ajouté ou un parcours d’escalade modifié peuvent changer ce que les utilisateurs font réellement. Le modèle est le même, alors l’équipe affirme qu’aucun changement de modèle n’a eu lieu. Cela peut être techniquement exact et opérationnellement hors de propos. Si l’interface rend une recommandation contraignante, si elle supprime le contexte nécessaire pour contester un résultat, ou si elle permet à un résultat d’aller plus loin qu’auparavant, la question de gouvernance a changé, même si les poids n’ont pas changé.

L’autorité se dégrade lorsque la responsabilité existe sur le papier mais plus en pratique. Un propriétaire désigné peut être parti. Un rôle de relecture peut subsister dans un organigramme alors que la personne qui l’occupe n’a ni le temps ni les informations pour exercer son jugement. Une autorité d’arrêt peut être confiée à un groupe senior qui ne sait pas qu’elle lui a été confiée. Un contrat de fournisseur peut renvoyer à un contact d’escalade qui peut recevoir un avis mais ne peut pas apporter de changement. La gouvernance devient alors un vieil annuaire téléphonique avec une typographie légèrement plus assurée.

Les dépendances se dégradent par accumulation. Un service peut ajouter une source de récupération, un fournisseur d’identité, un produit de surveillance, une voie d’inférence, une file d’attente, une couche de stockage ou un autre modèle. Chaque ajout peut être judicieux. Ensemble, ils modifient le système qui fonctionne réellement. DORA souligne ce point dans un contexte financier en exigeant des entités qu’elles identifient, classifient et documentent les fonctions métier soutenues par les TIC, les actifs, les rôles, les responsabilités et les dépendances, et qu’elles examinent la documentation pertinente au moins une fois par an et lors de tout changement majeur. Ce n’est pas une règle sur l’IA. C’est un rappel utile que l’objet nécessitant une maintenance est le système dans son environnement de travail, et non le composant au nom le plus à la mode.

Enfin, la mémoire se dégrade. Une organisation peut conserver des milliers de lignes de journal et perdre quand même la raison d’une décision. Les journaux peuvent indiquer qu’un événement s’est produit. Ils ne disent pas automatiquement pourquoi un seuil a été fixé, qui a accepté une limitation, quels cas ont été exclus d’un essai, ou ce qu’une équipe prévoyait de vérifier après une publication. Ces informations ont tendance à partir avec les personnes, à moins d’être consignées dans un dossier avec un propriétaire et un point de révision. Une piste d’audit qui ne peut pas expliquer le jugement autour de l’événement est utile, mais incomplète.

Rien de tout cela ne plaide pour une suspicion permanente ni pour une réunion de comité à chaque changement de menu. La proportionnalité compte. L'AI Act lui-même décrit la surveillance après mise sur le marché comme proportionnée à la nature de la technologie et au risque du système à haut risque. L'objectif de la maintenance n'est pas de rendre impossible l'amélioration ordinaire. Il est de rendre l'organisation apte à remarquer quelles améliorations ne sont pas ordinaires.

La loi pense déjà par cycles

Les règles technologiques européennes sont souvent présentées comme des obligations de conformité, comme si le travail se résumait à une seule soumission suivie d'un tampon. En les lisant de plus près, leur logique opérationnelle est cyclique. Elles demandent aux organisations d'identifier, de surveiller, de documenter, de signaler, de réviser, de tester et d'améliorer. Le vocabulaire varie selon les secteurs parce que les risques diffèrent. L'instinct de maintenance est remarquablement constant.

Pour les systèmes d'IA à haut risque, l'AI Act place la réflexion sur le cycle de vie en tête des exigences. L'article 9 exige qu'un système de gestion des risques soit établi, mis en œuvre, documenté et maintenu. Il le décrit comme continu et itératif, planifié et exécuté sur l'ensemble du cycle de vie, avec une révision et une mise à jour systématiques et régulières. Le système doit identifier et analyser les risques connus et raisonnablement prévisibles, y compris les risques liés à l'utilisation prévue et à un mésusage raisonnablement prévisible. Il doit également utiliser les informations recueillies dans le cadre de la surveillance après mise sur le marché. C'est une instruction pour rendre l'évaluation initiale révisable. Elle ne permet pas que l'évaluation initiale devienne une pièce de musée.

L'article 72 précise ce qui se passe après la mise en service d'un système à haut risque. Les fournisseurs doivent établir et documenter un système de surveillance proportionné à la technologie et au risque. Ce système doit collecter, documenter et analyser activement et systématiquement les données pertinentes sur les performances tout au long de la durée de vie du système, afin que le respect continu des exigences applicables puisse être évalué. Le cas échéant, il inclut l'analyse de l'interaction avec d'autres systèmes d'IA. Cela importe pour les déploiements réels, car le comportement significatif d'un système peut surgir à la frontière : une sortie entre dans un autre outil, un moteur de politique transforme un score en action, un humain voit une interface qui modifie le poids d'une recommandation, ou un flux de travail en aval crée une nouvelle conséquence.

L'Acte ne demande pas que la surveillance devienne une surveillance passive de tous ceux qui utilisent un service. Il demande des informations pertinentes, et l'environnement juridique environnant continue de s'appliquer. Une conception de maintenance doit donc commencer par un objectif pour chaque signal. À quelle question le signal répond-il. L'information agrégée suffit-elle. L'examen nécessite-t-il le contenu, l'identité ou seulement un fait opérationnel versionné. Qui peut y accéder. Combien de temps est-il conservé. Comment peut-il être contesté. Collecter davantage parce qu'un tableau de bord accepte plus de champs n'est pas une stratégie de maintenance. C'est du stockage avec des ambitions.

Le même chapitre relie la surveillance au traitement des incidents graves. L'article 73 exige que les fournisseurs de systèmes à haut risque mis sur le marché de l'Union signalent les incidents graves aux autorités de surveillance du marché compétentes après qu'un lien de causalité, ou une probabilité raisonnable d'un tel lien, a été établi. Il fixe des délais qui varient selon la gravité, notamment deux jours pour une infraction généralisée ou un incident grave du type spécifié. Il exige une enquête, une évaluation des risques et une action corrective après le signalement. L'enseignement opérationnel important n'est pas le nombre de jours. C'est que la réponse aux incidents n'est pas un processus distinct de relations publiques. Elle fait partie de la boucle de preuves qui doit modifier la gestion des risques, la documentation et le fonctionnement futur.

NIS2 clarifie la question de la propriété en cybersécurité. Son article 20 dispose que les organes de direction des entités essentielles et importantes approuvent les mesures de gestion des risques de cybersécurité, supervisent leur mise en œuvre et peuvent être tenus responsables en cas de manquement. L'article 21 exige ensuite des mesures techniques, opérationnelles et organisationnelles appropriées et proportionnées, notamment la gestion des incidents, la continuité d'activité, la sécurité de la chaîne d'approvisionnement, ainsi que la sécurité lors de l'acquisition, du développement et de la maintenance. Cette approche est utile bien au-delà des entités soumises à NIS2. La gouvernance n'est pas une consigne descendante issue d'un dossier de conseil d'administration. Si les personnes investies de l'autorité formelle ne revoient pas les mesures ni ne comprennent les conséquences de leurs choix, l'organisation a créé un titre sans contrôle.

NIS2 traite également le signalement comme une obligation de service. Les incidents significatifs doivent être notifiés sans délai indu et, le cas échéant, les destinataires de services doivent être informés lorsqu'un incident significatif est susceptible de nuire à la fourniture du service. Un incident est significatif non seulement lorsqu'il perturbe l'organisation elle-même, mais aussi lorsqu'il affecte d'autres personnes en causant des dommages matériels ou immatériels considérables. Cette limite est utile pour la gouvernance de l'IA. Une équipe ne doit pas se contenter de vérifier que le graphique de disponibilité du système reste vert. Un système peut être disponible et créer néanmoins un problème opérationnel ou lié aux droits important.

DORA offre un autre modèle pratique. Les entités financières doivent identifier et documenter les fonctions d'activité soutenues par les TIC, les rôles, les responsabilités, les informations et les actifs TIC, ainsi que leurs dépendances. Elles revoient le caractère adéquat des classifications et de la documentation selon les besoins et au moins une fois par an, et réalisent une évaluation des risques lors de chaque changement majeur de l'infrastructure, des processus ou des procédures affectant les fonctions ou les actifs soutenus. Là encore, il ne s'agit pas de prétendre que toute organisation est une entité financière. C'est un exemple de règle mature qui traite l'inventaire, le changement et la revue comme un travail lié. Un système en exploitation a besoin d'une carte, et une carte a besoin d'une date.

Le langage de DORA sur la gestion des changements est particulièrement sobre. Elle exige des politiques, procédures et contrôles documentés pour les modifications des logiciels, du matériel, des microprogrammes, des systèmes et des paramètres de sécurité. Les changements doivent être enregistrés, testés, évalués, approuvés, mis en œuvre et vérifiés de manière contrôlée. Cette séquence ne prétend pas qu'un modèle d'IA peut toujours être testé jusqu'à la sécurité. C'est une façon de refuser l'idée qu'une mise à jour de production se justifie d'elle-même. Un changement doit avoir une raison, une évaluation, une voie d'approbation, un enregistrement de mise en œuvre et une vérification du résultat.

ISO/IEC 42001 n'est pas une législation et une page produit publique ne remplace pas la norme elle-même. Néanmoins, ISO décrit la norme comme un système de management de l'IA fondé sur le cycle Planifier-Déployer-Vérifier-Agir, destiné à aider une organisation à gérer les risques et opportunités liés à l'IA dans l'ensemble de l'organisation plutôt que d'examiner uniquement des applications individuelles. Le cycle est l'idée utile. Planifier établit une intention délimitée. Déployer la met en œuvre. Vérifier demande si les preuves soutiennent la poursuite de la confiance. Agir modifie le système de travail. Répéter ce cycle n'est pas de la bureaucratie pour elle-même. C'est la reconnaissance minimale que les systèmes et les institutions ne restent pas immobiles.

Une boucle de gouvernance doit ramener les preuves à une décision. Sinon, elle n'est qu'un enregistrement des choses qui ont été remarquées.

La surveillance doit pouvoir avoir un impact

Le monitoring est souvent présenté comme une activité technique, ce qui se comprend. Les systèmes produisent de la télémétrie. Les équipes choisissent des métriques. Les tableaux de bord affichent des courbes qui montent, descendent et, à l'occasion, déclenchent des réunions alarmantes. Mais la difficulté ne réside pas dans la collecte d'un signal. Elle réside dans l'accord sur ce que ce signal est autorisé à faire varier.

Un plan de monitoring commence par une question de décision. Une réclamation peut indiquer qu'une explication n'est pas claire, qu'une saisie est erronée, qu'un utilisateur a rencontré une limitation, ou que l'organisation a mal conçu son parcours de recours. Une hausse des dérogations humaines peut indiquer une baisse de l'adéquation du modèle, une meilleure confiance des équipes, un changement de politique, des données sources obsolètes, une nouvelle catégorie de cas, ou une interface qui induit les relecteurs en erreur. Une augmentation des refus peut indiquer qu'un contrôle de sécurité fonctionne, qu'une dépendance est devenue peu fiable, ou qu'un produit est utilisé en dehors de son usage déclaré. Le chiffre brut n'est pas la conclusion. C'est une invitation à examiner une relation.

C'est pourquoi un plan utile sépare l'observation de l'interprétation. L'observation indique ce qui a été enregistré, avec quelle version, quel parcours, quel moment, quel contexte et quel niveau de confiance. L'interprétation indique ce que l'organisation pense que le signal pourrait signifier et quelles explications alternatives subsistent. La décision indique qui peut choisir une réponse. L'enregistrement indique ce qui a changé et pourquoi. Cette approche est plus lente que de traiter chaque alerte comme une preuve de défaillance du modèle. Elle est plus rapide que d'envoyer un problème mal compris dans un cycle de réentraînement pour découvrir que le véritable défaut relevait de la politique, de la qualité des sources, des droits d'accès ou des effectifs.

Les métriques doivent également correspondre aux conséquences du système. Un score de qualité du modèle peut être pertinent, mais il sera rarement suffisant. Si un résultat affecte une file d'attente, une équipe peut avoir besoin de connaître les délais, les exceptions non gérées, les annulations et les cas envoyés en relecture manuelle. Si un assistant recommande des sources, une équipe peut avoir besoin de connaître la disponibilité des sources, les corrections de citations, les réponses contestées et la question de savoir si les utilisateurs agissent sur des éléments hors du périmètre déclaré. Si un système filtre du contenu, la relecture peut nécessiter des schémas de réclamation, des résultats de recours, la couverture linguistique et les raisons des dérogations. Le monitoring doit suivre le chemin sur lequel le système a des effets, et non s'arrêter au point où le modèle a produit un jeton ou un score.

Le parcours vers un humain doit également être suivi. Il est facile d'écrire « supervision humaine » dans une politique et difficile de montrer si la personne peut réellement l'exercer. À quelle fréquence les personnes dérogent-elles. Ont-elles accès aux saisies et aux raisons nécessaires pour le faire. Une dérogation atteint-elle le processus qui a produit le résultat, ou se contente-t-elle d'ajouter une note à la fin. Combien de temps prend une escalade. Certains cas n'atteignent-ils jamais le parcours de relecture parce que l'interface masque cette possibilité. Ce sont des questions opérationnelles. Ce sont aussi des questions de gouvernance, car la réponse détermine si la supervision humaine est réelle ou décorative.

Tous les signaux n'ont pas besoin d'être publics. Certains seront sensibles d'un point de vue commercial. Certains concerneront la sécurité. Certains peuvent contenir des données personnelles et n'auraient pas dû être collectés en premier lieu. La discipline de maintenance consiste à rendre ces limites explicites. Une relecture peut nécessiter des schémas agrégés plutôt qu'une archive complète du contenu. Elle peut nécessiter un état capturé plutôt qu'un enregistrement de chaque interaction. Elle peut nécessiter un accès protégé pour un enquêteur d'incident et une explication publique distincte de la méthode. La transparence ne signifie pas publier des éléments opérationnels bruts. Elle signifie rendre intelligibles l'existence, la finalité, les limites et la propriété d'un contrôle.

Il existe une différence petite mais importante entre un plan de surveillance et une liste de souhaits. Un plan précise quels signaux sont collectés, comment ils sont protégés, ce qui déclenche un examen, qui est responsable de cet examen, quels sont les résultats possibles et comment la décision entre dans le dossier de modification. Une liste de souhaits indique que l'organisation surveillera la qualité, la sécurité, l'équité et la satisfaction des utilisateurs. La première peut être testée. La seconde s'intègre très bien dans une présentation de stratégie et nulle part ailleurs.

Une bonne surveillance rend également visibles les non-événements. Si aucun rapport n'arrive, est-ce parce que le système n'a causé aucun problème, parce que la voie de signalement est inaccessible, parce que les personnes ignorent son existence, ou parce que le processus ne conserve pas les rapports ? Si un seuil d'incident n'est pas franchi, est-ce parce que le système est stable ou parce que le seuil n'est pas lié au préjudice réel ? L'absence d'un signal peut constituer une preuve, mais seulement après examen du parcours de collecte. Le silence n'est pas automatiquement une source de réassurance. Parfois, ce n'est qu'un formulaire mal signalé.

La gestion des incidents est une forme de mémoire institutionnelle

Un processus d'incident doit commencer avant l'incident, car les premières minutes d'un événement inhabituel sont un mauvais moment pour inventer une autorité. Le processus doit permettre de recevoir une préoccupation, de préserver suffisamment de preuves pour la comprendre, de protéger les personnes contre une exposition continue, de décider si l'événement atteint un seuil défini et de communiquer avec les personnes qui doivent agir. Il doit également offrir un chemin de retour vers le système de gouvernance. Sans ce chemin final, l'organisation gère l'épisode puis recrée ses conditions préalables avec une efficacité admirable.

DORA exprime clairement cela pour les incidents liés aux TIC. Elle exige que les entités financières définissent, établissent et mettent en œuvre un processus de gestion des incidents pour détecter, gérer et notifier les incidents. Elles enregistrent les incidents et les menaces cybernétiques significatives, et maintiennent des procédures pour une surveillance, un traitement et un suivi cohérents et intégrés, afin que les causes profondes soient identifiées, documentées et traitées. Le processus doit établir des indicateurs d'alerte précoce, attribuer des rôles et des responsabilités pour différents scénarios, et définir des modalités de communication et d'escalade. Ce sont des exigences spécifiques au secteur financier. Leur logique de base est largement utile : un incident devrait laisser à l'organisation de meilleures connaissances qu'auparavant.

Pour l'IA, la question des preuves mérite une attention particulière. Une équipe peut vouloir modifier un modèle ou un service immédiatement après avoir pris connaissance d'un résultat préjudiciable. Parfois, un confinement urgent est exactement ce qu'il faut. Mais un changement non contrôlé peut aussi détruire la capacité de comprendre ce qui s'est passé. Le règlement sur l'IA dispose qu'un fournisseur enquêtant sur un incident grave ne doit pas modifier le système d'IA d'une manière qui pourrait affecter l'évaluation ultérieure des causes avant d'avoir informé les autorités compétentes de cette action. Cela ne crée pas une licence pour laisser les personnes exposées tout en préservant une expérience intacte. Cela rend le compromis visible. Contenez le risque, préservez l'état pertinent, enregistrez l'intervention et évitez de transformer l'enquête en une reconstruction effectuée de mémoire.

Un dossier d'incident utile comporte plusieurs couches. Il y a l'observation signalée, qui peut être incomplète ou contestée. Il y a le contexte technique et opérationnel, y compris la version, le parcours, l'état et les systèmes liés qui sont pertinents. Il y a l'évaluation de l'impact et de l'incertitude. Il y a les mesures de confinement, y compris qui les a prises et ce qu'elles ont changé. Il y a l'enquête, qui doit distinguer les preuves des hypothèses. Puis il y a la décision concernant les mesures correctives et le suivi qui vérifie si elles ont fonctionné. Confondre toutes ces couches donne à un rapport précoce l'apparence d'une conclusion finale, ou à une conclusion ultérieure la même certitude qu'une première alerte.

La communication fait partie de la maintenance, ce n'est pas un épilogue décoratif. Les personnes touchées par une interruption ou une menace importante peuvent avoir besoin d'un recours pratique. Les opérateurs doivent savoir s'il faut arrêter, continuer avec des limites ou utiliser une solution de repli. La direction a besoin d'un compte rendu clair de l'impact, de l'incertitude et des droits de décision. Un régulateur peut exiger un rapport défini. Les fournisseurs peuvent avoir besoin d'enquêter sur une interface ou une dépendance. Les messages n'ont pas besoin d'être identiques, mais ils doivent partager le même socle factuel. Une organisation qui donne à ses équipes des versions incompatibles des faits ne fait pas preuve de prudence. Elle prépare l'incident suivant.

Il n'est pas nécessaire d'inventer une panne spectaculaire pour comprendre cela. Prenons une hypothèse clairement étiquetée : une équipe de relecture observe un ensemble de corrections inattendues après l'introduction d'un nouveau format de source dans un flux de travail par ailleurs familier. La première question n'est pas de savoir si le modèle a « déraillé », une expression qu'il vaut mieux laisser de côté avec plusieurs autres. La question est de savoir ce qui a changé. Le format de source modifie-t-il l'entrée. La voie de récupération expose-t-elle des éléments inappropriés. Une condition de politique a-t-elle bougé. L'interface fait-elle manquer du contexte aux relecteurs. Les cas concernés sont-ils corrigés assez rapidement. La réponse peut être de suspendre une voie, de revenir sur une configuration, d'ajouter une validation, de réviser les consignes, ou de constater que la source n'aurait jamais dû être admise. L'intérêt de l'hypothèse n'est pas l'intrigue. C'est qu'un processus préparé évite à l'organisation de tâtonner pendant la première heure.

Après un incident, le calendrier de maintenance doit poser plus de questions que celle de savoir si le défaut visible est réparé. Le signal de détection a-t-il fonctionné. La bonne personne l'a-t-elle reçu. Avait-elle l'autorité nécessaire. Le journal a-t-il préservé le contexte pertinent. La voie d'escalade était-elle utilisable. Le message destiné au public ou aux clients correspondait-il à ce qui était connu. Une décision a-t-elle créé une nouvelle exigence de surveillance. Une lacune de formation ou de documentation a-t-elle aggravé l'événement. Les réponses transforment un incident d'une interruption isolée en un changement du modèle d'exploitation.

Le changement a besoin d'une seconde horloge

Chaque système a une horloge technique. Les versions sont construites, déployées, annulées et remplacées. La gouvernance a besoin d'une seconde horloge : le calendrier pour réexaminer si les preuves, l'objectif et l'autorité sont toujours adéquats. Ces horloges avancent parfois ensemble, et parfois non. Les traiter comme une seule est un moyen fiable de manquer des changements importants.

Un changement technique peut être petit et avoir tout de même de l'importance. Une nouvelle collection de récupération peut modifier les sources utilisées dans les réponses. Une consigne ou une règle de politique modifiée peut changer l'ensemble des cas qu'un système refuse. Une mise à jour de configuration peut changer le lieu de circulation des données. Une nouvelle version d'une dépendance peut modifier la latence, la journalisation ou les contrôles de sécurité disponibles. La réponse appropriée dépend du système et de ses conséquences. Le calendrier de maintenance ne doit pas déclarer à l'avance que chaque changement est important. Il doit fournir un moyen de décider ce qui nécessite des tests, une nouvelle approbation, un avis public, une réévaluation des risques, un nouvel état capturé ou simplement un enregistrement.

À l'inverse, un changement de gouvernance peut survenir sans aucun déploiement de code. Un service peut être utilisé par un nouveau département. Un contrat d'approvisionnement peut ajouter un sous-traitant. Une interprétation juridique peut modifier les conditions d'un flux de travail. Une voie peut passer de l'expérimentation interne à l'accès externe. Une sortie existante peut commencer à influencer une décision plus en aval. L'équipe technique peut ne voir aucune version. Les personnes concernées peuvent voir un système très différent. Un calendrier de maintenance doit remarquer les deux horloges.

DORA applique une règle de classification pratique : mener une évaluation des risques pour chaque changement majeur apporté à l'infrastructure des réseaux et des systèmes d'information, aux processus ou aux procédures qui touchent les fonctions ou les actifs pris en charge. Elle exige également que les inventaires soient mis à jour périodiquement et à chaque changement majeur. Pour les travaux liés à l'IA, l'expression « changement majeur » ne doit pas être considérée comme allant de soi. Les équipes doivent définir leurs critères à l'avance. Cela inclut-il un changement d'objectif prévu, une nouvelle source de données, un nouvel état de modèle, une nouvelle autorisation d'outil, une nouvelle population, une voie de contournement humain modifiée, une explication altérée ou une nouvelle dépendance externe ? La réponse variera. L'absence de réponse constitue en soi un risque.

Un registre des changements n'est pas un journal de modifications rédigé pour être applaudi publiquement. C'est un argumentaire qui relie un état antérieur, une raison, une évaluation, une décision, une mise en œuvre et une vérification. Pour certains changements, la version publique peut être brève : une politique pertinente ou une limite visible par les utilisateurs a changé, avec prise d'effet à une date indiquée et un lien vers ce qui est différent. Pour les preuves internes, le registre peut inclure davantage de détails sur l'évaluation, les contrôles d'accès, le contexte d'incident ou les informations sur les fournisseurs. L'important est que les deux niveaux renvoient à la même décision plutôt que de devenir des récits distincts.

L'identité de version est particulièrement importante lorsqu'un système évolue au fil du temps. Un nom de produit stable ne permet pas toujours d'identifier l'état qui a produit une sortie donnée. Mais tenter d'attribuer un numéro de version permanent à chaque état transitoire peut produire un autre type de fiction. Une meilleure approche consiste à distinguer l'identité durable du modèle ou du service de l'état capturé, de la configuration et des preuves nécessaires pour un examen ou une relecture définis. Le registre indique alors ce qui a été inspecté sans prétendre que tout a été figé pour toujours.

La vérification des changements est l'endroit où de nombreux registres deviennent optimistes. Une organisation a approuvé un correctif, donc l'incident est clos. Mais la mise en œuvre n'est pas la vérification. Le nouveau contrôle a-t-il fonctionné dans des conditions réalistes ? A-t-il créé un problème différent ? Le mécanisme de secours a-t-il fonctionné ? Les examinateurs humains ont-ils reçu les consignes modifiées ? La métrique pertinente a-t-elle évolué dans la direction souhaitée ? L'explication correspond-elle toujours au service ? La vérification peut montrer qu'un changement doit être annulé, affiné ou maintenu avec une nouvelle limite. Elle a le droit d'être gênante. Cela fait partie de son rôle.

Un calendrier donne à ce travail une cadence ordinaire. Certains registres sont examinés après un déclencheur. D'autres nécessitent une date fixe, car attendre un déclencheur suppose que l'organisation le reconnaîtra toujours. Un énoncé d'objectif peut nécessiter un examen lorsque l'utilisation change et à un intervalle planifié. Une évaluation peut expirer après un changement de version, de voie de données ou de contexte. Un plan d'incident peut nécessiter une date de répétition, car un plan jamais utilisé peut être parfaitement rédigé et pratiquement imaginaire. Une voie de sortie peut nécessiter un test avant d'être requise en urgence. La date ne garantit pas le soin apporté. Elle rend la négligence plus facile à voir.

Les registres peuvent rester dans une archive tout en perdant leur autorité à appuyer une décision actuelle. La date d'examen rend cette distinction visible.

L'expiration n'est pas un échec

Les équipes résistent souvent aux dates d’expiration parce que le mot expiration sonne comme une accusation. Ce n’en est pas une. C’est une déclaration sur le périmètre. Un résultat de calibration peut être valable pour l’état du modèle et les conditions d’entrée qui ont été testés. Une évaluation de protection des données peut être rigoureuse pour le parcours de traitement qu’elle décrit. Une assurance fournisseur peut être pertinente pour une version de service et un contrat spécifiques. Un programme de formation peut être adapté au travail que les personnes effectuaient lorsqu’elles y ont participé. Aucun de ces documents ne devient mauvais lorsque ses conditions changent. Il devient incomplet pour une nouvelle décision.

C’est l’une des raisons pour lesquelles la revue annuelle est à la fois utile et insuffisante. Une date annuelle établit un rythme minimal et empêche les documents de disparaître indéfiniment dans un lecteur partagé. Mais un changement majeur peut survenir demain. DORA combine ces deux idées en exigeant une revue régulière au moins annuelle et une évaluation des risques à chaque changement majeur. Les deux horloges fonctionnent ensemble : la revue périodique détecte les dérives lentes ; la revue déclenchée détecte une condition qui a déjà modifié la décision.

L’expiration devrait être rattachée aux affirmations, pas seulement aux documents. Un document peut contenir plusieurs affirmations ayant des durées de vie différentes. Un diagramme d’architecture peut rester en grande partie exact tandis qu’une description de contrôle de sécurité a changé. Une évaluation peut encore établir une capacité étroite tout en ne soutenant plus une déclaration de performance plus large. Une politique peut être à jour alors que le propriétaire nommé ne l’est pas. Lorsqu’une équipe marque l’ensemble du fichier comme à jour ou obsolète, elle perd ces distinctions. La maintenance au niveau des affirmations demande plus de travail. Elle donne aussi aux réviseurs la possibilité de mettre à jour ce qui a bougé sans réécrire l’historique.

Il y a ici un bénéfice humain. Les personnes qui héritent d’un système doivent savoir sur quoi elles peuvent compter. Un document qui dit « à jour » sans date, sans périmètre ni propriétaire leur transmet un problème de confiance déguisé en documentation. Un document qui dit « évalué pour cet objectif, avec cet état capturé, dans ces conditions, revu à cette date, prochaine revue à cette échéance » leur donne quelque chose qu’elles peuvent inspecter et contester. Il ne rend pas le système sûr par déclaration. Il rend visible la frontière des connaissances existantes.

L’expiration rend aussi le retrait moins dramatique. Un système n’a pas besoin d’être un scandale pour être retiré ou remplacé. Un fournisseur peut mettre fin à son support. Un modèle peut ne plus convenir à un nouveau contexte linguistique ou politique. La charge de preuve peut dépasser la valeur du maintien d’une ancienne voie. Une alternative plus sûre peut exister. L’organisation peut décider que la tâche doit revenir à une personne ou à un mécanisme non-AI plus simple. Un calendrier de maintenance devrait inclure une voie de sortie avant que le service ne devienne difficile à retirer. Le retrait est une action de gouvernance, pas une preuve que la gouvernance a échoué.

Ce qui ne doit pas expirer, c’est l’historique. L’organisation devrait préserver ce qui a été évalué, décidé, modifié et observé, sous réserve des règles applicables en matière de conservation, de confidentialité et de protection des données. Préserver l’historique est différent de traiter d’anciennes preuves comme actuelles. L’un soutient l’apprentissage et la responsabilité. L’autre peut transformer un ancien document en une assurance trompeuse. De bonnes archives se souviennent de la différence.

Un calendrier est une répartition de l’autorité

L’artefact de gouvernance le plus utile peut être moins impressionnant qu’une matrice de risques : un calendrier avec des noms à côté. Qui révise l’objectif. Qui lit le signal de surveillance. Qui peut déclarer qu’un seuil est atteint. Qui peut suspendre une voie. Qui approuve un changement majeur. Qui vérifie les preuves de vérification. Qui communique avec un fournisseur. Qui décide qu’une ancienne évaluation ne soutient plus une utilisation continue. Si la réponse à toutes ces questions est « l’équipe AI », l’organisation n’a pas réparti l’autorité. Elle a nommé une pièce.

L’autorité a besoin d’assez d’indépendance pour être significative, et d’assez de proximité pour agir. Un conseil d’administration ou un organe de direction peut détenir la supervision et les ressources. Un responsable opérationnel peut comprendre le travail réel. Un responsable technique peut connaître les limites du système. Un spécialiste de la sécurité ou de la vie privée peut identifier une limite que d’autres ne voient pas. Une équipe en contact avec les clients ou le public peut voir un préjudice avant qu’un tableau de bord ne le montre. Ces rôles n’ont pas besoin d’être réunis en une seule personne héroïque. Ils ont besoin de transferts définis et d’un moyen de résoudre les désaccords. L’accent mis par NIS2 sur l’approbation et la supervision de la direction est utile ici, car il refuse la fiction commode selon laquelle la gouvernance peut être entièrement déléguée tandis que la responsabilité reste au sommet.

Le seuil d’escalade doit être rédigé dans un langage qui correspond à une décision. « Escalader si le score d’anomalie dépasse 0,8 » peut être techniquement nécessaire, mais cela ne dit pas à une institution ce qui est en jeu. Un meilleur seuil peut combiner signal et conséquence : escalader lorsque le système commence à affecter un usage hors du périmètre déclaré ; lorsqu’une défaillance de contrôle pourrait priver une personne concernée d’un examen ; lorsqu’une source ou une dépendance importante change ; lorsque des corrections montrent un schéma que l’évaluation existante ne couvrait pas ; lorsqu’un problème grave de sécurité, de sûreté ou de droits est signalé ; lorsqu’un responsable requis ou un mécanisme de secours n’est plus disponible. Les seuils exacts varieront. Le langage de décision ne devrait pas varier.

La maintenance a aussi besoin d’un budget. C’est banal et décisif. La surveillance consomme du temps. L’examen d’un changement consomme des capacités techniques, juridiques et opérationnelles. La répétition d’un plan d’incident interrompt le travail ordinaire. Mettre à jour une explication, un dossier ou un programme de formation est un travail. Lorsque la gouvernance n’a pas de modèle opérationnel doté de personnel, elle devient une taxe d’urgence imposée à quiconque remarque le problème en premier. Cet arrangement semble économique jusqu’au premier événement difficile, lorsque l’organisation découvre qu’elle a économisé le coût de la préparation et acheté le coût de l’improvisation.

Il y a une place pour la proportionnalité. Un outil interne étroit avec un usage clair et sans conséquence peut nécessiter un calendrier plus léger qu’un système affectant l’accès au travail, aux services, aux droits ou à la sécurité. Mais plus léger ne signifie pas absent. Il peut encore nécessiter un responsable, une limite d’usage, un registre des changements, un circuit d’incident de base et une condition de sortie. La complexité devrait suivre la conséquence et l’incertitude, et non le degré d’enthousiasme disponible au lancement du projet.

Un calendrier de maintenance utile peut être énoncé en langage clair. Examinez l’usage lorsque l’utilisation, les utilisateurs ou les conséquences changent. Examinez les dépendances lorsqu’un fournisseur, un circuit de données ou un service connecté change. Examinez les preuves d’évaluation lorsque le modèle, la configuration ou les conditions d’exploitation pertinentes changent. Répétez le circuit d’incident et d’arrêt à un intervalle défini. Examinez les attributions de rôles lorsque l’organisation change. Publiez ou conservez un registre des changements lorsqu’une décision a un effet important. Testez le circuit de sortie avant que le service n’en dépende. Rien de tout cela ne promet que les erreurs ne se produiront pas. Cela promet que l’organisation a un moyen de remarquer, de décider et d’apprendre lorsqu’elles se produisent.

Une petite note de notre part

Chez Dweve, notre Trust Centre décrit la surveillance comme un registre public distinct plutôt que comme une promesse qu’un produit a atteint un état permanent d’achèvement. Son matériel de surveillance publié indique que les signaux sont liés aux limites de collecte déclarées, que les examens identifient le modèle, le circuit, l’état et les preuves pertinents, et que les changements importants peuvent ouvrir un examen d’évaluation, de risque, d’incident ou de publication. Le registre public des changements distingue également les faits actuels des contrôles préparés et des événements futurs. Ce sont des descriptions de notre conception opérationnelle déclarée, et non une assurance indépendante, un résultat client ou une affirmation selon laquelle une page publique règle toutes les questions de gouvernance.

Cette limite est volontaire. Nous estimons qu'un registre de surveillance est utile lorsqu'il indique aux lecteurs ce qui peut être observé, ce qui reste protégé, ce qui peut déclencher une action et où une décision importante sera consignée. Le registre ne peut pas juger à la place des personnes qui exploitent un système. Il peut rendre le jugement plus facile à examiner lorsqu'il est rendu.

La maintenance est la partie honnête

Le lancement est un moment utile. Il crée une raison de définir l'objectif, d'évaluer les risques et de prendre des engagements. Ce n'est pas le moment où la technologie cesse de rencontrer le monde. La gouvernance devient crédible ensuite, dans le travail répété qui consiste à déterminer si l'ancienne décision mérite encore d'être maintenue.

Ce travail nécessite un calendrier, car les bonnes intentions ont une demi-vie courte lorsqu'elles n'ont ni date, ni responsable, ni voie d'action. Il nécessite des preuves, car la couleur d'un tableau de bord n'est pas une explication. Il nécessite une autorité, car surveiller sans le droit de changer quoi que ce soit, c'est observer avec un bon habillage. Il nécessite un historique, car une correction qui ne peut pas être retracée ne peut pas améliorer de manière fiable la décision suivante. Et il nécessite une sortie, car la poursuite de l'exploitation doit rester un choix, et non un fait hérité.

La question mature n'est pas de savoir si une organisation peut produire un cadre de gouvernance. Beaucoup le peuvent. La question est de savoir si, des mois après l'approbation du document, l'organisation peut encore dire à quoi sert le système, ce qui a changé, quelles preuves le soutiennent aujourd'hui, qui peut l'arrêter, et ce qui se passe lorsque la réponse n'est plus claire. Si elle le peut, la gouvernance est maintenue. Si elle ne le peut pas, l'organisation a peut-être encore une politique. Elle a simplement cessé d'en avoir une vivante.

Sources