Préparer un contrôle de conformité en deux semaines

Préparer un contrôle de conformité exige d’identifier les systèmes et les obligations réellement applicables, puis d’assembler des preuves traçables plutôt que de produire seulement une documentation rassurante. Cette hiérarchie détermine l’ordre de préparation.

Par contrôle de conformité, j’entends ici toute vérification, interne ou externe, qui demande à une organisation de démontrer qu’elle sait quels systèmes d’IA elle exploite, à quoi ils servent, qui les supervise et quelles traces ils laissent. C’est la logique des obligations de l’AI Act, décrites dans ce que l’ingénieur doit livrer, mais aussi celle d’un audit interne ou d’une demande d’un client.

Une organisation qui produit un inventaire complet, même assorti de fiches imparfaites, démontre qu’elle sait ce qu’elle exploite. Une organisation qui produit trois dossiers excellents en ignorant l’existence de dix autres systèmes démontre l’inverse.

L’inventaire structure le travail, mais sa durée dépend des équipes et des systèmes. Les délais du schéma sont indicatifs. Deux semaines permettent d’organiser une préparation, pas de déclarer toute l’organisation conforme.

Un dossier de conformité IA peut être préparé selon un ordre de travail explicite : l’inventaire, puis une fiche par système, puis les preuves de supervision, puis les journaux. Chaque étape s’appuie sur la précédente, et l’inverser fait perdre du temps.

Une répartition raisonnable consiste à boucler l’inventaire et à lancer les fiches la première semaine, puis à consacrer la seconde à la collecte des preuves de supervision, à l’état des journaux et à la relecture d’ensemble. Le détail des obligations propres aux systèmes classés à haut risque est traité dans ce qui doit exister avant l’échéance.

1. Délimiter le contrôle. Identifier les exigences à justifier, les interlocuteurs et le périmètre demandé.
2. Inventorier les systèmes. Croiser équipes, fournisseurs et configurations sans recopier les secrets.
3. Relier fiches et preuves. Associer chaque décision et contrôle aux pièces effectivement disponibles.
4. Tester la supervision. Vérifier une correction et un arrêt dans des conditions maîtrisées.
5. Documenter les lacunes. Dater les pièces manquantes et désigner les responsables des corrections.

Un inventaire fiable rapproche équipes, fournisseurs et configurations pour repérer les systèmes d’IA exploités, y compris ceux qui ne sont pas identifiés comme des projets. C’est l’étape la plus rapide et la plus révélatrice.

La méthode est directe : regarder les factures des fournisseurs, les clés d’API émises, et interroger chaque équipe sur ce qu’elle a branché. Cette dernière question fait apparaître, parfois, des systèmes dont la direction ignorait l’existence.

Les découvertes habituelles sont d’un genre précis : un assistant créé par une équipe métier et devenu quotidien, un script d’enrichissement branché sur une base, une automatisation ajoutée dans un outil de gestion.

Aucun de ces systèmes n’a été caché ; ils n’ont simplement jamais été qualifiés de projets. Ils comptent pourtant, et c’est ce que révèle le rapprochement avec ce qu’un assistant sans code ne couvre pas. L’inventaire est aussi l’occasion de vérifier qu’aucun usage ne relève des pratiques interdites.

La fiche d’un système d’IA doit décrire sa finalité, ses données, les décisions servies, la supervision et la revue, avec un responsable identifié et des références aux preuves.

• Une rédaction avec l’équipe responsable, relue avec les fonctions juridiques, sécurité ou métiers concernées.
• Cinq rubriques : finalité, données, décision servie, supervision, date de revue. Voir écrire la fiche d’un système d’IA.
• Un modèle commun, pour que les fiches se comparent et se consolident.
• Signée et datée : une fiche anonyme ne démontre pas qu’une personne en répond.

La supervision humaine se vérifie par des décisions, corrections et arrêts traçables, ainsi que par des essais contrôlés montrant qu’une personne peut réellement intervenir sur le système. Décrire un dispositif de supervision ne suffit pas, et c’est l’étape la plus souvent manquée.

Ce qui constitue une preuve est concret : des cas où un humain a effectivement refusé une proposition du système, avec la trace de ce refus. L’absence de refus ne prouve, à elle seule, ni perfection ni supervision de façade.

S’ils manquent, examinez la nature des dossiers et la conservation des traces. Un essai contrôlé, présenté comme tel, peut éprouver le pouvoir d’intervention. C’est la configuration décrite dans supervision humaine : la concevoir, pas la promettre.

Dans les deux cas, le constat est plus utile que le document qu’on aurait rédigé. Il pose aussi la question de la formation des superviseurs, qui relève de l’obligation de littératie IA.

Si les journaux d’un système d’IA n’existent pas, il faut les activer immédiatement et documenter la date de début : un journal absent ne se reconstitue pas. Cela décrit une correction réelle, sans garantir son acceptation par l’autorité de contrôle.

Une organisation qui déclare avoir activé la journalisation à telle date, et qui produit les traces depuis, est dans une situation très différente d’une organisation qui n’a rien et n’a rien prévu.

Ce qu’il ne faut pas faire est plus important : ne pas produire de traces reconstituées. Un journal fabriqué après coup est une fausse pièce, et son coût potentiel dépasse largement le manquement qu’il prétend couvrir.

La règle qui en découle vaut au-delà du contrôle : activer la journalisation dès qu’un système est mis en service, même si personne ne l’exige encore. C’est le seul chantier dont le report se paie définitivement. Ce que doivent contenir ces journaux est détaillé dans l’observabilité des systèmes IA.

Un dossier incomplet doit exposer le périmètre connu, les preuves disponibles et les lacunes datées, sans transformer un plan de correction en preuve de conformité acquise.

L’exhaustivité de l’inventaire. Un dossier qui liste douze systèmes avec des fiches sommaires vaut mieux qu’un dossier qui en documente trois parfaitement et ignore les neuf autres.

Pour éviter de refaire la préparation à chaque échéance, une revue périodique des fiches, des nouveaux systèmes et des changements de finalité permet de maintenir un dossier dont la fraîcheur reste vérifiable. Sans ce rituel, la préparation est à refaire à chaque échéance.

L’ordre du jour tient en trois points. Les nouveaux systèmes mis en service depuis le dernier rendez-vous, avec leur fiche. Les fiches existantes dont la finalité a dérivé. Et les systèmes arrêtés, à identifier avec leur statut.

Ce troisième point est régulièrement oublié et il compte : un registre qui présente comme actifs des systèmes arrêtés fausse l’état des lieux.

La cadence dépend des changements et du risque. Conservez les systèmes arrêtés avec leur statut, selon les règles de conservation applicables, plutôt que d’effacer leur historique. Pour mettre ce rituel en place à partir d’un état des lieux, un audit IA fournit l’inventaire initial et le modèle de fiche.

Les erreurs fréquentes en préparant un contrôle de conformité IA sont de commencer par la documentation, de centraliser la rédaction, de décrire la supervision sans la prouver et de reconstituer des journaux. Ne présentez jamais une trace fabriquée comme un événement historique.

• Commencer par un dossier parfait. Trois systèmes impeccablement documentés ne compensent pas dix systèmes ignorés.
• Faire rédiger les fiches par un service central. Elles décrivent alors ce qui devrait être, pas ce qui est.
• Décrire la supervision. Un schéma de processus ne prouve pas qu’un humain a déjà refusé une proposition.
• Fabriquer des traces. Une fausse pièce expose bien davantage qu’un journal manquant assumé.
• Oublier les systèmes arrêtés. Le registre doit les identifier comme arrêtés et distinguer activité présente et historique.

Les risques liés à un dossier défaillant sont rappelés dans ce qui devient exigible avec les sanctions de l’AI Act.