La gouvernance humaine doit précéder le déploiement de l’IA dans la simulation de crise

Partir de l’usage, non de la technologie

La première question n’est pas « quelle IA utiliser ? », mais « pour quelle tâche, dans quel contexte et avec quelle conséquence ? ». Dans un simulateur de crise, plusieurs fonctions peuvent coexister : génération de personnages fictifs, préparation d’injects, synthèse de la main courante, regroupement de traces, formulation de questions de débriefing ou production d’un projet de compte rendu. Elles n’ont ni le même niveau d’exposition ni les mêmes effets.

Cette décomposition évite d’attribuer une nature unique à l’ensemble du système. Un module qui reformule un message pédagogique n’appelle pas le même encadrement qu’une fonction qui produirait une appréciation individuelle. Le règlement européen sur l’intelligence artificielle retient une approche fondée sur le risque et rattache les obligations à la destination du système¹. La qualification juridique doit donc être conduite pour chaque usage réel, avec les compétences appropriées, plutôt que déduite du seul fait que le logiciel concerne la gestion de crise.

Cette prudence est d’autant plus nécessaire qu’un outil de simulation est pédagogique. Ses sorties ne constituent ni une doctrine opérationnelle, ni une instruction, ni une garantie sur la conduite d’une situation réelle. Cette limite doit apparaître dans la documentation, dans l’interface et dans la formation des utilisateurs. Elle protège le décideur autant que le concepteur.

Le Conseil d’État a proposé dès 2022 une doctrine de l’IA publique fondée notamment sur la primauté humaine, la performance, l’équité, la transparence, la sûreté, la soutenabilité et l’autonomie stratégique². Ces principes donnent une grille adaptée aux métiers de crise, à condition de les traduire en règles concrètes.

Organiser une supervision humaine effective

Dire que l’humain reste responsable ne suffit pas. Il faut lui donner les moyens de comprendre, de vérifier et d’interrompre. Le règlement européen prévoit, pour les systèmes à haut risque, une supervision permettant aux personnes de connaître les capacités et limites du système, de détecter les anomalies, d’interpréter les sorties et d’écarter une proposition¹. Même lorsqu’un simulateur ne relève pas de cette catégorie, ces exigences constituent un repère de conception pertinent.

Dans la pratique, la supervision repose d’abord sur des rôles. L’administrateur technique veille au fonctionnement et aux habilitations. Le concepteur pédagogique fixe les objectifs et les limites du scénario. Le directeur d’exercice valide les injects et conduit la session. Le responsable du RETEX garantit l’analyse. Le responsable de traitement, lorsqu’il existe des données personnelles, assume les obligations correspondantes. Une même personne peut tenir plusieurs rôles dans une petite structure, mais les responsabilités doivent rester identifiables.

Elle repose ensuite sur des interfaces. Une proposition générée doit être reconnaissable. Sa source documentaire, lorsqu’elle existe, doit pouvoir être consultée. Le directeur d’exercice doit pouvoir corriger, différer, refuser ou interrompre. Une synthèse doit renvoyer aux éléments qui la fondent. Un indicateur doit afficher sa définition et ses limites.

Enfin, elle suppose une compétence. Le guide interministériel destiné aux agents de l’État rappelle que l’agent reste responsable de ses décisions, que les données sensibles ne peuvent être traitées qu’avec les outils autorisés, que les usages substantiels doivent être transparents et que la formation est indispensable³. Une formation à l’outil ne doit donc pas se limiter à ses commandes. Elle doit inclure ses erreurs possibles, les vérifications attendues et la conduite à tenir en cas de résultat incohérent.

Maîtriser les données et les accès

Une simulation peut contenir des informations de sensibilité très différente : données ouvertes sur les risques, documents internes, annuaires, comptes utilisateurs, échanges entre participants, enregistrements, appréciations pédagogiques ou données relatives à des organisations. Le premier travail de gouvernance consiste à les classifier et à déterminer lesquelles sont réellement nécessaires.

La CNIL rappelle qu’un traitement mobilisant des données personnelles doit répondre à une finalité déterminée, légitime et explicite, disposer d’une base légale et respecter la minimisation⁴. Dans un contexte d’exercice, cette finalité doit distinguer au moins la conduite de la session, le débriefing, la production du RETEX et l’éventuelle recherche. Une donnée collectée pour animer une session ne peut pas être librement réemployée pour évaluer durablement une personne ou alimenter un travail scientifique.

Les mesures techniques suivent cette cartographie : habilitations par rôle, authentification adaptée, chiffrement des communications et des sauvegardes, journalisation des accès, durée de conservation, procédure d’effacement et cloisonnement des espaces clients. La CNIL recommande également de documenter les composants, les jeux de données, les performances, les limites d’usage et les mesures de protection⁵. Cette documentation doit pouvoir être comprise par l’acheteur public et par l’utilisateur métier, pas uniquement par l’équipe technique.

L’hébergement en France constitue un élément de maîtrise, mais il ne résume pas la sécurité. L’ANSSI recommande de choisir une offre cloud en fonction de la sensibilité du système d’information et du niveau de menace, et rappelle que tous les systèmes n’ont pas vocation à être hébergés de la même manière⁶. La localisation, la qualification de l’offre, les conditions d’administration, la chaîne de sous-traitance, la réversibilité et le plan de continuité doivent être examinés ensemble.

Contractualiser la maîtrise plutôt que la supposer

La commande d’un simulateur intégrant de l’IA doit porter sur des capacités vérifiables. Une présentation commerciale peut montrer la fluidité d’une génération ; elle ne dit rien, à elle seule, de la traçabilité, de la sécurité ou de la continuité du service.

Le cahier des charges devrait définir la finalité pédagogique, les catégories de données admises, les lieux de traitement et d’hébergement, les sous-traitants, les mécanismes d’authentification, la journalisation, les durées de conservation, l’export, la réversibilité, la gestion des incidents et les conditions de suppression. Il devrait préciser comment les évolutions du système sont testées et annoncées, ainsi que les modalités de retour à une version antérieure.

Les performances doivent être formulées en critères contrôlables : disponibilité attendue, capacité de session, délai de récupération, qualité de l’export, accessibilité des sources, comportement en cas d’indisponibilité d’une composante et maintien d’un mode manuel. Une clause générale indiquant que l’outil « utilise une IA souveraine » ne suffit pas. La souveraineté se démontre par la maîtrise des données, des dépendances, de l’exploitation et de la sortie du contrat.

Il convient aussi de définir la propriété et la réutilisation des contenus. Les scénarios, documents locaux, traces de session et productions pédagogiques ne doivent pas être intégrés à un apprentissage ultérieur sans fondement, information et accord correspondant au cadre applicable. L’acheteur doit savoir si les données quittent son espace, si elles sont conservées après la session et si un administrateur externe peut y accéder.

Tester le système comme on teste une organisation

Un simulateur de crise doit être éprouvé avant un déploiement large. Le test ne porte pas seulement sur l’absence de panne. Il doit couvrir les erreurs plausibles : source absente, donnée contradictoire, génération inadaptée, indisponibilité d’un service, montée en charge, perte de connexion, erreur d’habilitation ou export incomplet.

La CNIL recommande une analyse de risques, des environnements contrôlés, des tests robustes, des audits et un plan de retour en arrière⁵. Pour un outil pédagogique, ces mesures peuvent être complétées par des tests métiers. Un directeur d’exercice expérimenté doit chercher les incohérences du scénario. Un utilisateur peu familier du numérique doit vérifier la compréhension de l’interface. Un responsable de la sécurité doit examiner les accès et les traces. Un délégué à la protection des données doit apprécier les traitements concernés.

Le mode dégradé constitue un test majeur. La session peut-elle continuer si la génération devient indisponible ? Les injects validés restent-ils accessibles ? La main courante peut-elle être exportée ? L’animation peut-elle reprendre la main sans perdre la chronologie ? Un système qui soutient la préparation à la crise doit lui-même être conçu pour l’incertitude.

Les incidents et les erreurs doivent alimenter une boucle d’amélioration. Cela suppose une procédure de signalement, une qualification, une correction et une information des utilisateurs lorsque la modification affecte leur pratique. La transparence sur une limite identifiée renforce davantage la confiance qu’une promesse générale de fiabilité.

Installer une gouvernance durable

La gouvernance ne s’arrête pas à la réception du logiciel. Les usages évoluent, les équipes changent, les sources de données sont mises à jour et le cadre juridique se précise. Une instance de suivi, même légère, doit périodiquement examiner les finalités, les incidents, les demandes d’évolution, les durées de conservation, les habilitations et les résultats des tests.

Cette instance doit réunir les compétences métier, pédagogique, technique, juridique et de sécurité. Son rôle n’est pas d’alourdir chaque décision. Il est d’éviter qu’une fonctionnalité conçue comme une aide limitée ne prenne progressivement une place qui n’a jamais été discutée.

La doctrine peut tenir en une phrase : la machine éclaire, propose, renforce et soutient ; l’humain décide, explique et répond de l’action. Pour qu’elle ne reste pas un principe abstrait, elle doit être visible dans les rôles, les écrans, les contrats, les tests et la formation.

Dans la simulation de crise, cette exigence est cohérente avec la finalité même de l’outil. On entraîne des femmes et des hommes à construire une représentation, à arbitrer et à coordonner sous contrainte. La technologie a de la valeur lorsqu’elle augmente leur capacité d’apprentissage sans brouiller la responsabilité. La gouvernance n’en limite pas l’usage : elle lui donne un cadre crédible et durable.

Sources et références

1. Parlement européen et Conseil de l’Union européenne, Règlement (UE) 2024/1689 établissant des règles harmonisées concernant l’intelligence artificielle, 2024, notamment articles 4, 6, 14 et 15, https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=fr ↩ ↩²

2. Conseil d’État, Intelligence artificielle et action publique : construire la confiance, servir la performance, 2022, https://www.conseil-etat.fr/media/le-conseil-d-etat/publications-colloques/etudes/etudes-a-la-demande-du-gouvernement/intelligence-artificielle-et-action-publique-construire-la-confiance-servir-la-performance ↩

3. Direction interministérielle du numérique, Direction interministérielle de la transformation publique et Direction générale de l’administration et de la fonction publique, Guide d’usage de l’intelligence artificielle, 2026, https://www.numerique.gouv.fr/offre-accompagnement/guide-usage-intelligence-artificielle/ ↩

4. CNIL, IA : comment être en conformité avec le RGPD ?, 2022, https://www.cnil.fr/fr/intelligence-artificielle/ia-comment-etre-en-conformite-avec-le-rgpd ↩

5. CNIL, IA : garantir la sécurité du développement d’un système d’IA, 2025, https://www.cnil.fr/fr/ia-garantir-la-securite-du-developpement ↩ ↩²

6. ANSSI, Recommandations pour l’hébergement dans le cloud des systèmes d’information sensibles, 2024, https://cyber.gouv.fr/actualites/lanssi-publie-ses-recommandations-pour-lh%C3%A9bergement-des-syst%C3%A8mes-dinformation-sensibles-dans-le-cloud/ ↩