Une modification du calendrier ne dira pas si une approbation assistée par l’IA s’est appuyée sur des preuves périmées, a sollicité la mauvaise personne ou a dépassé son autorité. Ce type de défaillance peut déjà affecter les décisions de production.
Le 7 mai, la présidence du Conseil et les négociateurs du Parlement européen ont conclu un accord provisoire visant à modifier les dates d’application de certaines parties du règlement européen sur l’IA. Les nouvelles dates proposées sont le 2 décembre 2027 pour les systèmes d’IA à haut risque autonomes et le 2 août 2028 pour ceux qui sont intégrés à des produits réglementés. À la date de publication de cet article, le 12 mai, l’accord doit encore être approuvé et formellement adopté. Les dates d’application actuelles restent en vigueur. (Parlement européen, 7 mai 2026)
La planification juridique devient donc plus incertaine. Pour les responsables de l’ingénierie, la question immédiate est la suivante : chaque flux de production peut-il prendre une décision à fort enjeu dans des limites définies de preuves, de politique et d’autorité ?
L’Accord Modifie Le Calendrier, Pas L’Exposition
Les échéances réglementaires et l’exposition opérationnelle n’avancent pas au même rythme. Dès que la sortie d’un système éclaire ou déclenche une action, ses conséquences n’attendent pas la date de mise en conformité.
Le texte initial du règlement reflète cette dimension opérationnelle. Pour les systèmes à haut risque, il exige notamment un processus de gestion des risques sur tout le cycle de vie, l’enregistrement automatique des événements, une supervision humaine ainsi que des normes d’exactitude et de cybersécurité. (Règlement (UE) 2024/1689, articles 9 à 15) Les obligations varient selon le rôle de l’organisation et la classification du système ; un conseil juridique doit donc confirmer leur application. La valeur technique de ces contrôles ne se limite toutefois pas aux systèmes réglementés.
Prenons un flux assisté par l’IA qui recommande d’accorder ou non un accès privilégié à un service de production. La recommandation peut être raisonnable alors que le flux échoue parce qu’il utilise des preuves périmées, transmet l’approbation à une personne sans l’autorité requise ou appelle un outil doté de permissions trop larges. Un changement de date ne modifie aucun de ces modes de défaillance.
Un Document De Politique Ne Peut Pas Piloter Le Flux
Les inventaires, les classifications de risque et les documents de politique sont nécessaires. Ils ne font pas respecter une décision au moment de l’exécution. Lorsqu’une politique exige une revue humaine, le flux actif doit encore identifier la personne habilitée, lui présenter les preuves, consigner son approbation et s’arrêter si elle ne répond pas.
Un contrôle opérationnel relie cinq éléments :
- Preuves : Quelles sources étayent cette décision, et sont-elles assez fiables, actuelles et complètes au regard de ses conséquences ?
- Politique : Quelle règle, quel seuil ou quelle contrainte autorise l’étape suivante ?
- Autorité : Qui ou quel système peut recommander, approuver, exécuter ou arrêter l’action ?
- Action : Qu’a fait le système, dans quel environnement et sous quelle identité ?
- Résultat : Que s’est-il passé ensuite, et l’action peut-elle être contenue, annulée ou corrigée ?
Evodant appelle l’ingénierie de ce chemin l’Ingénierie Décisionnelle. Cette discipline prend la décision opérationnelle comme unité de conception. Un tel système réunit le modèle, l’identité, les données sources, l’évaluation des politiques, les permissions des outils, l’approbation humaine, l’observabilité et la reprise.
Une fiche de modèle peut décrire le comportement attendu, et une matrice de contrôle peut attribuer les responsabilités. Aucune ne prouve qu’une décision de production précise a utilisé la bonne source, respecté la politique en vigueur, obtenu une approbation valide et conservé les limites d’action prévues. Le flux doit pour cela créer un dossier de décision pendant son exécution.
Commencer Par Un Périmètre De Décision
Un programme de contrôle à l’échelle de l’entreprise peut consacrer des mois à inventorier les systèmes sans modifier le comportement d’un seul flux actif. Mieux vaut choisir une décision à fort enjeu, avec un responsable nommé et un résultat mesurable, puis en définir le périmètre.
Nommer La Décision Et Sa Conséquence
Formulez la décision comme une action, pas comme une capacité. « Approuver une exception de service » est plus clair que « utiliser l’IA pour les opérations de service ». Identifiez la personne qui supporte les conséquences si la décision est erronée, tardive ou insuffisamment étayée.
Définir Les Exigences De Preuve
Dressez la liste des sources que le flux peut utiliser. Définissez les exigences de provenance, d’actualité, de qualité et de traitement des contradictions. Si une preuve requise manque ou n’est plus actuelle, le flux doit s’arrêter ou transmettre le cas plutôt que d’improviser.
Séparer La Recommandation De L’Autorité
Précisez si le système assiste une personne, formule une recommandation limitée ou exécute une action. L’accès à un outil ne donne pas l’autorité de l’utiliser dans tous les cas. Liez les permissions à la décision, à l’état de la politique, à l’identité de l’utilisateur ou du service et au périmètre approuvé.
Définir Les Conditions D’Arrêt Et De Reprise
Précisez ce qui se passe lorsque la confiance est faible, que les sources se contredisent, qu’un approbateur est indisponible, qu’une dépendance échoue ou qu’une action produit un résultat inattendu. La reprise ne se résume pas à une instruction générique d’annulation. Elle exige un responsable, une procédure testée et assez de télémétrie pour déterminer ce qui a changé.
Créer Un Dossier De Décision
Consignez les références des preuves, la version de la politique, le modèle et sa configuration, l’identité, l’approbation, l’action et le résultat observé. Adaptez le dossier à la décision et aux règles de conservation applicables. L’objectif consiste à reconstituer les raisons de l’action, pas à accumuler des données sans limite.
Tester Les Contrôles Dans Des Conditions Représentatives
Une revue de contrôle ne doit pas s’arrêter lorsque chaque contrôle requis figure sur un schéma d’architecture. Les équipes doivent tester le comportement du chemin de décision complet dans des conditions proches de la production.
Constituez un jeu d’évaluation à partir de cas courants, de cas difficiles et d’exceptions connues. Injectez des preuves périmées et contradictoires. Modifiez la version du modèle ou de l’invite. Supprimez une intégration, rendez un approbateur indisponible et tentez une action hors du périmètre autorisé. Observez ensuite si le flux poursuit, demande, transmet, refuse ou récupère comme prévu.
Mesurez le résultat opérationnel autant que la qualité du modèle. Parmi les mesures utiles peuvent figurer le taux de décisions non étayées, le taux de transmission, le délai d’approbation, le coût par dossier traité, le volume d’exceptions à la politique et le temps de reprise. Choisissez des mesures qui rendent visibles les conséquences et les contraintes de la décision. Une moyenne d’exactitude ne permet pas de savoir si le flux a respecté son autorité.
L’évaluation représentative aide aussi à fixer le bon niveau d’automatisation. Conservez l’aide à la décision lorsqu’une personne doit interpréter des preuves contestées. Utilisez l’augmentation de la décision lorsque le système peut formuler une recommandation limitée, mais qu’une personne habilitée doit décider. N’autorisez l’automatisation limitée que si l’action, le seuil de preuve, la permission, la surveillance et le chemin de reprise sont explicites.
Mettre Le Temps Supplémentaire À Profit Pour Produire Des Preuves Opérationnelles
Si l’accord provisoire devient loi, le temps supplémentaire doit servir à produire des preuves opérationnelles, pas un inventaire de contrôles de plus. Choisissez un flux à fort enjeu et testez ses règles de preuve, ses limites d’autorité, ses conditions d’arrêt et sa procédure de reprise dans des conditions représentatives.
Les dossiers de décision ainsi obtenus peuvent contribuer à la préparation juridique tout en répondant à une question de gestion plus immédiate : l’organisation peut-elle expliquer, défendre et améliorer la manière dont ce système prend des décisions aujourd’hui ?
Le report proposé ne justifie pas non plus d’accélérer tous les cas d’usage de l’IA. Il laisse le temps de réduire le périmètre, de corriger les limites faibles et de tester les situations dans lesquelles le flux ne peut pas poursuivre normalement. Un flux gouverné de moindre ampleur vaut mieux qu’un déploiement étendu dont les décisions ne peuvent pas être reconstituées.
Ces questions deviennent un travail d’ingénierie lorsque leurs réponses se trouvent dans plusieurs systèmes et équipes. L’actualité des preuves, l’autorité d’approbation, les permissions des outils et les conditions de reprise doivent concorder pendant l’exécution du flux ; une liste de contrôle ne peut pas imposer cette concordance.
Vous cherchez à convertir les contrôles du règlement sur l’IA en contrôles opérationnels ? Planifiez une consultation.