Quand le système d'IA change, la preuve doit garder la mémoire. Par Mohand Ouidja
Un système d'IA évolue : modèle remplacé, seuil ajusté, données modifiées, fournisseur externe mis à jour. Or un contentieux peut porter sur une décision prise plusieurs mois auparavant.
L’AI Act est un règlement européen qui impose aux systèmes d’intelligence artificielle (IA) à haut risque une documentation technique mise à jour avant leur mise sur le marché ou leur utilisation. Cette documentation doit couvrir deux aspects : l’état actuel du système et son état historique. Par exemple, une décision prise en janvier 2025 avec un modèle d’IA en version V3 pourrait être contestée en septembre 2025, alors que le système a évolué vers la version V4 entre-temps. La documentation de septembre 2025 ne suffira pas pour expliquer le fonctionnement du système en janvier 2025. Le règlement (UE) 2026/1744 prévoit que ces exigences s’appliquent progressivement entre le 2 décembre 2027 et le 2 août 2028 selon les catégories de systèmes concernés.
L’Annexe IV de l’AI Act impose une gestion des versions pour les systèmes d’IA. Elle exige de décrire la version actuelle du système, ses relations avec les versions antérieures, les changements prédéterminés (comme les mises à jour de logiciels ou de firmwares), et les procédures de validation associées. Par exemple, un système utilisé pour analyser des demandes de crédit peut voir son seuil de décision ajusté en mars 2025, puis déployer une nouvelle version du modèle en mai 2025. La documentation doit permettre de retracer ces évolutions pour comprendre le fonctionnement du système à une date précise. Cependant, une mise à jour trop fréquente du dossier peut rendre difficile la reconstruction de l’état antérieur si aucun jalon historique n’est conservé.
L’article 3, point 23 de l’AI Act définit une modification substantielle comme un changement non prévu lors de l’évaluation initiale de conformité, qui affecte la conformité du système ou modifie sa finalité initiale. Par exemple, ajuster un seuil de décision ou changer la finalité d’un système peut nécessiter une nouvelle évaluation de conformité. En revanche, les changements prédéterminés lors de l’évaluation initiale, comme des mises à jour logicielles mineures, ne sont pas considérés comme substantiels. L’article 43, paragraphe 4 impose une nouvelle procédure d’évaluation en cas de modification substantielle. La traçabilité des changements est essentielle pour déterminer si une modification est substantielle ou non.
Les systèmes d’IA dépendent souvent de composants externes, comme des API (interfaces de programmation) ou des bibliothèques logicielles fournies par des tiers. Une mise à jour chez un fournisseur tiers peut modifier le comportement du système sans que son code interne ne change. Par exemple, une mise à jour d’une API peut affecter les résultats d’un système utilisé pour analyser des demandes de crédit. L’article 25 de l’AI Act souligne que certains acteurs, comme les distributeurs ou les déployeurs, peuvent être considérés comme des fournisseurs si ils apportent une modification substantielle. Il est donc crucial de documenter les versions des composants externes et les changements communiqués par les fournisseurs.
L’article 12 de l’AI Act impose des capacités de journalisation pour enregistrer les événements pertinents, comme les modifications substantielles ou les situations à risque. Un log d’exécution (journal des événements) et un dossier de version ne remplissent pas la même fonction : le log décrit un événement, tandis que le dossier de version explique l’état du système à ce moment-là. Par exemple, un log peut indiquer qu’un seuil a été modifié le 10 mars 2025, mais le dossier de version doit préciser quel était ce seuil et pourquoi il a été ajusté. Ces deux types de traces sont nécessaires pour reconstruire une chronologie compréhensible en cas de contestation.
Des mécanismes techniques peuvent renforcer la fiabilité de l’historique documentaire. Une empreinte cryptographique (comme une somme de contrôle) peut prouver qu’un fichier n’a pas été modifié. Un horodatage (date certifiée) peut rattacher un document à un moment précis. Une signature électronique peut identifier l’auteur d’une validation et garantir le lien entre cette personne et le document. Cependant, ces mécanismes ne prouvent pas à eux seuls la conformité du système. Par exemple, un document peut être intègre mais incomplet, ou une décision juridiquement discutable peut être parfaitement horodatée. Une architecture documentaire efficace combine automatisation (versioning, horodatage) et contrôle humain (analyse des changements, validation juridique).
La documentation technique d’un système d’IA ne doit pas seulement répondre à la question : *« Comment fonctionne-t-il aujourd’hui ? »* Elle doit aussi permettre de répondre à : *« Comment fonctionnait-il au moment où le fait contesté s’est produit ? »* Par exemple, si une décision prise en janvier 2025 est contestée en septembre 2025, la documentation doit permettre de reconstituer l’état du système en janvier 2025, y compris ses paramètres, ses versions et ses composants. Cette mémoire documentaire est essentielle pour l’auditabilité des systèmes, surtout lorsqu’ils deviennent plus évolutifs et dépendants de composants tiers. Le dossier vivant (documentation actuelle) et l’historique des versions ne s’opposent pas : ils se complètent pour garantir la transparence et la conformité.
