Un nouveau système d'IA entre dans le périmètre : le parcours, étape par étape
Un système de management se juge moins à son état le jour de la certification qu'à la façon dont il absorbe ce qui arrive ensuite. Le premier test est presque toujours un nouveau système d'IA.
Un nouveau système d’IA arrive rarement par la grande porte. Il entre par un achat décidé dans un métier, par une fonction activée dans un logiciel déjà en place, par un projet interne qui a grandi. La première difficulté n’est pas de savoir quoi faire : c’est de savoir qu’il est arrivé.
Ce que la norme demande à ce moment-là
Aucune clause ne s’intitule « nouveau système ». Plusieurs exigences s’appliquent pourtant ensemble :
- la maîtrise opérationnelle (8.1) : un système qui entre en exploitation est un changement. Décidé, il se maîtrise comme tel ; découvert après coup — une fonction activée dans un abonnement —, il oblige à en examiner les conséquences et à agir contre ses effets indésirables. Et lorsqu’il vient d’un tiers, 8.1 demande en plus de maîtriser ce que l’extérieur fournit ;
- le périmètre (4.3) : si l’arrivée déplace les limites retenues, ou touche le système de management lui-même — politique, rôles, méthode —, la clause 6.3 demande que cette modification-là soit menée de façon planifiée. Un système qui entre dans des limites inchangées ne l’appelle pas ;
- l’appréciation des risques (8.2), à rejouer à intervalles planifiés et lorsqu’un changement significatif est envisagé ou déjà survenu, et l’évaluation d’impact (8.4), à rejouer à intervalles planifiés et lorsqu’un tel changement est envisagé — la refaire après un changement subi est une précaution que nous recommandons, sans que la lettre de 8.4 l’impose. La norme ne dit nulle part ce qui est significatif : c’est à votre méthode de le fixer, et y inscrire l’arrivée d’un système est un choix prudent ;
- le traitement des risques (8.3, selon le processus de 6.1.3), qui conduit à revoir les mesures retenues et, s’il y a lieu, la déclaration d’applicabilité ;
- deux contrôles de l’Annexe A, lorsque la déclaration d’applicabilité les retient : A.6.2.2, qui fait consigner ce que l’on attend d’un nouveau système, et A.6.2.5, qui fait établir un plan de déploiement et vérifier que les conditions requises sont réunies avant la mise en service.
Le parcours, en sept étapes
Un ordre qui évite les allers-retours. Il s’applique pleinement à un système qui peut affecter des personnes, et se raccourcit pour un outil anodin — la grille est plus bas.
1. Inscrire le système à l’inventaire. Avant tout le reste, et avant la mise en service. Le point d’entrée unique — achats, DSI, instance de gouvernance — n’a de valeur que s’il est franchi au moment de l’arrivée, et non découvert lors de l’audit.
2. Qualifier l’usage prévu et votre rôle. À quoi sert le système, qui il affecte, qui l’a développé, sous quel nom il est mis en service. Le rôle au sens de la norme (4.1) et le rôle au sens de l’AI Act se qualifient séparément ; le second décide d’obligations légales.
3. Décider de l’entrée dans le périmètre. Le système entre, ou il reste hors périmètre pour un motif écrit, que la prochaine revue de direction pourra réexaminer.
4. Apprécier les risques et évaluer les impacts, avant la mise en service. Selon la méthode déjà en place : ajouter le système au registre des risques, conduire son évaluation d’impact. C’est l’étape la plus coûteuse, et celle qu’on est tenté de reporter après le lancement.
5. Décider des mesures, et relire la déclaration d’applicabilité. Les mesures retenues pour ce système s’ajoutent au plan de traitement. Un contrôle exclu jusqu’ici peut devenir nécessaire : un premier système qui décide pour des personnes, ou un premier modèle hébergé en interne, remet en cause des exclusions justifiées pour les systèmes précédents.
6. S’il est acheté, évaluer le fournisseur. Usage des données, politique de version, préavis de dépréciation, répartition des responsabilités : les questions propres à l’IA.
7. Préparer l’exploitation. Critères d’acceptation vérifiés avant la mise en service, plan de surveillance, journaux, information des utilisateurs, sensibilisation des équipes concernées — pour les contrôles que la déclaration d’applicabilité a retenus.
Viennent ensuite deux suites, souvent oubliées. Le programme d’audit interne gagne à être revu : 9.2.2 le fait établir en tenant compte de l’importance des processus concernés, qu’un système nouveau peut déplacer — sans exiger pour autant de le rouvrir à chaque arrivée. Et la revue de direction en est informée, parce que les évolutions des enjeux font partie de ce qu’elle examine.
Un parcours proportionné
Tout nouvel usage d’IA ne mérite pas le même traitement. La norme ne fixe aucun seuil ; le vôtre doit être écrit, pour que le tri ne dépende pas de l’humeur du moment. Une grille simple fonctionne :
| Le système… | Parcours |
|---|---|
| produit ou oriente des décisions sur des personnes, traite des données sensibles, ou agit sans validation humaine | Complet, avec validation par l’instance de gouvernance avant la mise en service |
| sert un usage interne, sans effet sur des tiers ni données sensibles | Allégé : inventaire, appréciation des risques simplifiée, fournisseur, règles d’usage |
| est une fonction d’IA ajoutée à un outil dont les risques et les impacts ont déjà été appréciés | Mise à jour de l’inventaire et de l’évaluation du fournisseur, et vérification écrite que l’appréciation des risques et l’évaluation d’impact existantes couvrent la nouvelle fonction ; les rejouer si elle modifie l’usage ou son contexte, la technologie ou le degré d’automatisation, ou les données traitées |
La grille est elle-même une décision de l’organisation : écrite dans la politique ou dans la procédure d’entrée, et relue quand un cas la met en défaut.
Ce qu’il faut retenir
Le système doit être vu avant d’être en service : tout le reste en dépend. Viennent ensuite sept étapes dans l’ordre, d’une intensité proportionnée à ce que le système peut abîmer — et la trace, datée, que les évaluations ont précédé la mise en service.