Une IA n’est pas qu’un modèle : pourquoi inventorier toute sa chaîne technique ?

Une entreprise peut utiliser une intelligence artificielle sans avoir construit elle-même le modèle. Elle peut néanmoins faire circuler des données dans une application, appeler plusieurs API, s’appuyer sur une base documentaire et dépendre de dizaines de bibliothèques logicielles. En cas de vulnérabilité, de changement de fournisseur ou d’incident, la première question devient alors simple : savons-nous exactement comment ce système fonctionne et de quoi il dépend ?

C’est l’objectif du SBOM for AI, ou inventaire des composants logiciels d’un système d’IA. Le G7 et l’ANSSI encouragent cette approche pour améliorer la transparence et la cybersécurité de la chaîne d’approvisionnement. Pour une PME, il ne s’agit pas nécessairement de produire un dossier complexe. Il s’agit d’abord de rendre visibles les composants, les flux et les responsabilités.

Un système d’IA ne se résume pas à son modèle

Dans le langage courant, on parle souvent de « l’IA » comme s’il s’agissait d’un seul logiciel ou d’un seul modèle. En pratique, un service d’IA peut réunir plusieurs briques :

• un modèle fourni par un éditeur ou téléchargé depuis un dépôt ;
• des bibliothèques et des frameworks qui exécutent ce modèle ;
• une application Web, un agent ou une interface métier ;
• des API externes et des services d’hébergement ;
• des bases de données, parfois une base vectorielle utilisée pour rechercher des documents ;
• des extensions, plugins, connecteurs ou outils capables d’agir dans le système d’information ;
• des journaux, des filtres et des mécanismes de supervision.

Le guide de l’ANSSI sur les systèmes d’IA générative définit justement le système comme l’ensemble des composants techniques autour du modèle : services frontaux, bases de données, journalisation et autres éléments nécessaires à l’application. Le modèle n’est donc qu’une partie de la chaîne.

Que signifie SBOM for AI ?

Une SBOM classique est une liste structurée des composants qui constituent un logiciel et de leurs dépendances. Elle permet par exemple de retrouver les applications qui utilisent une bibliothèque vulnérable. La CISA la présente comme un inventaire imbriqué des « ingrédients » d’un logiciel.

Le SBOM for AI reprend cette logique en l’élargissant aux spécificités de l’intelligence artificielle. Le document publié dans le cadre du G7 le décrit comme un enregistrement structuré des composants utilisés pour construire un système d’IA et de leurs relations dans la chaîne d’approvisionnement.

Il ne s’agit pas encore d’une certification universelle ni d’une obligation générale applicable à toutes les PME. Les documents du G7 et de l’ANSSI constituent des orientations et des éléments minimaux appelés à évoluer. Leur intérêt est surtout pratique : ils fournissent une méthode pour ne plus traiter un système d’IA comme une boîte noire.

Les trois inventaires à ne pas confondre

Demander « le SBOM de l’IA » peut conduire à une réponse trop limitée. Une organisation a intérêt à distinguer trois documents complémentaires.

1. La SBOM logicielle

Elle recense les paquets, bibliothèques, versions, dépendances directes et transitives, conteneurs et systèmes utilisés pour construire ou exécuter l’application. Elle doit permettre d’identifier rapidement les composants concernés par une vulnérabilité et de suivre les licences.

2. L’inventaire du système d’IA

Il décrit le modèle, sa version, son fournisseur, son mode d’accès, son usage prévu, les évaluations réalisées, ses limites connues et les personnes responsables. Il précise aussi quelles données sont envoyées au modèle et quelle place l’IA occupe dans le processus métier.

3. Le registre des fournisseurs et des flux

Il identifie les API, hébergeurs, sous-traitants et services qui reçoivent des données ou participent au fonctionnement. Il doit préciser où les informations circulent, combien de temps elles sont conservées, qui peut y accéder et ce qui se passe si un fournisseur change son modèle ou cesse son service.

Une SBOM logicielle ne décrit pas forcément la provenance d’un jeu de données. Une fiche de modèle ne révèle pas les bibliothèques utilisées par l’application. Un registre fournisseur ne remplace pas les deux autres. Ces documents doivent être reliés, mais pas confondus.

Pourquoi cet inventaire est utile à une PME

Réagir plus vite à une vulnérabilité

Lorsqu’une faille touche une bibliothèque, une image de conteneur ou un composant d’authentification, l’entreprise doit savoir si elle est concernée. Sans inventaire, la recherche repose sur des souvenirs, des tickets anciens ou des échanges avec plusieurs prestataires. Avec une liste versionnée, il devient possible d’identifier les systèmes exposés et de prioriser les corrections.

Comprendre quelles données circulent

Un outil d’IA peut recevoir des messages, des documents, des données clients ou des informations confidentielles. Le registre doit indiquer la source des données, leur sensibilité, le fournisseur appelé, le lieu de traitement, les journaux conservés et la durée de rétention.

Cette cartographie est utile pour la sécurité, mais aussi pour les données personnelles, les secrets d’affaires et les droits de réutilisation des contenus. Les recommandations de la CNIL sur l’IA et le RGPD rappellent que les données personnelles doivent être protégées dans les bases d’entraînement, les modèles et les prompts.

Préparer un changement de modèle ou de fournisseur

Un service peut modifier son modèle, ses conditions tarifaires, sa localisation d’hébergement ou ses sous-traitants. Si personne ne sait quelles applications dépendent de ce service, le changement devient urgent et coûteux.

L’inventaire permet de poser une question de réversibilité : quelles données pouvons-nous récupérer, quel composant devons-nous remplacer, quel processus manuel peut prendre le relais et combien de temps l’opération demande-t-elle ?

Clarifier les responsabilités

Dans un projet réalisé avec une agence ou plusieurs fournisseurs, chacun peut supposer que l’autre suit les composants. L’entreprise reste pourtant responsable de ses choix d’usage et de la protection de ses données.

Le registre permet de répartir les tâches : l’éditeur documente son service, l’intégrateur maintient la configuration et les dépendances qu’il contrôle, l’hébergeur sécurise son infrastructure, et l’entreprise valide les usages, les données et le niveau de risque acceptable.

Que faut-il inventorier concrètement ?

Une première version peut tenir dans un tableau. Pour chaque système d’IA, indiquez au minimum :

• le nom du service et l’usage métier ;
• le propriétaire interne et la personne qui peut suspendre le système ;
• le modèle utilisé, sa version ou sa date d’accès, et son fournisseur ;
• les applications, bibliothèques et connecteurs qui l’intègrent ;
• les API, hébergeurs et sous-traitants connus ;
• les types de données envoyés, stockés ou retournés ;
• la localisation des traitements et des journaux lorsqu’elle est connue ;
• les limites, tests, incidents et mesures de contrôle ;
• la date de dernière revue et la procédure d’arrêt ou de remplacement.

Pour les données utilisées à l’entraînement, au réglage ou dans une base documentaire, ajoutez leur origine, leur finalité, leur nettoyage, leurs droits d’utilisation et leur durée de conservation. Si le fournisseur ne communique pas une information, notez-le comme une inconnue plutôt que de la remplacer par une hypothèse.

Comment commencer sans créer une usine documentaire ?

1. Recenser les usages réels : interrogez les équipes et recherchez aussi les abonnements, extensions et scripts utilisés sans projet informatique formalisé.
2. Classer les usages par impact : distinguez une aide à la rédaction sans donnée sensible d’un système connecté au CRM ou traitant des informations personnelles.
3. Documenter les flux : dessinez simplement le trajet d’une donnée, de sa source jusqu’au modèle, aux journaux et aux destinataires de la réponse.
4. Demander des éléments aux fournisseurs : modèle et version, données conservées, sous-traitants, lieu de traitement, notifications d’incident et modalités de suppression.
5. Générer la SBOM au bon moment : pour les logiciels maîtrisés, associez l’inventaire à la construction ou au déploiement, et conservez-le avec la version correspondante.
6. Prévoir une revue : mettez à jour le registre lors d’un changement de modèle, d’API, de fournisseur, de données ou après un incident.

Des formats comme SPDX ou CycloneDX peuvent faciliter l’échange automatique des composants logiciels. Ils ne résolvent toutefois pas la qualité des informations reçues. Un fichier standardisé mais incomplet ne donne pas une visibilité réelle.

Ce qu’un inventaire ne garantit pas

Une SBOM ne prouve pas qu’un système est sécurisé, conforme, performant ou adapté à son usage. Elle ne vérifie pas la qualité des données, les biais d’un modèle, la pertinence des réponses ni la résistance d’un agent face à une instruction malveillante.

Elle peut aussi être incomplète. Un fournisseur de logiciel fermé ne donnera pas nécessairement toutes ses dépendances. Un service cloud peut documenter ses composants sans révéler la totalité de ses sous-traitants ou de ses données d’entraînement. Il faut donc distinguer ce qui est fourni, ce qui est vérifié et ce qui reste inconnu.

L’inventaire doit compléter l’analyse de risques, les tests, la gestion des vulnérabilités, les contrôles d’accès, la supervision humaine et les clauses contractuelles. Pour un usage critique, prévoyez également un arrêt manuel, une procédure de secours et une solution de remplacement évaluée.

Une question de visibilité avant d’être une question d’outil

Le SBOM for AI ne demande pas à une PME de tout maîtriser comme un éditeur de modèles. Il lui demande de savoir ce qu’elle utilise, ce qui dépend de quoi, quelles données circulent et qui doit agir en cas de problème.

Cette visibilité change la discussion avec un prestataire. Elle permet de demander des informations précises, de comparer deux solutions, de négocier des engagements et de préparer une réversibilité. Elle aide aussi à décider où un service d’IA est acceptable et où un traitement manuel ou un environnement mieux contrôlé reste préférable.

L’objectif n’est donc pas de produire un document pour cocher une case. C’est de conserver une capacité de décision lorsque le modèle, la bibliothèque, l’API ou le fournisseur change. Une IA mieux inventoriée n’est pas automatiquement sûre, mais une IA dont personne ne connaît la chaîne technique est difficile à sécuriser durablement.