Des experts fédéraux appellent à des tests rigoureux de l’IA avant son déploiement

Google News a remis en avant un avertissement fédéral qui met en évidence une tension forte : les agences déploient davantage d’IA, tandis que des tests fiables restent coûteux, longs et incomplets.

Le rapport sous-jacent décrit des experts fédéraux en technologie exhortant les agences à tester l’IA de manière répétée avant de l’utiliser dans des environnements aux conséquences importantes. Leur préoccupation ne se limite pas aux questions désormais familières de biais dans les données d’entraînement. Ils veulent également que les agences examinent le comportement des modèles face à de vrais utilisateurs, à des informations sensibles, à la pression opérationnelle et à des conditions que les développeurs n’avaient pas anticipées.

Cette position se heurte à la volonté parallèle du gouvernement fédéral d’accélérer l’adoption. Les agences ont reçu pour instruction de lever les obstacles inutiles, de moderniser les services et d’utiliser plus efficacement l’IA commerciale. Pourtant, ces mêmes institutions restent responsables lorsqu’une recommandation automatisée, un contrôle d’identité, un résumé ou une action logicielle porte préjudice au public.

Le titre de Google News met en évidence une lacune plus large en matière de tests

L’évolution importante n’est pas une nouvelle interdiction fédérale, mais une demande croissante de preuves avant que l’IA n’atteigne des flux de travail aux conséquences importantes.

La discussion sur les tests fédéraux a réuni des responsables et des spécialistes du Department of Homeland Security, de l’Idaho National Laboratory et de HP Federal. Leurs commentaires portaient sur les biais, la supervision humaine et la valeur de tests continus.

Arun Vemury, conseiller principal au sein de la Science and Technology Directorate du DHS, a décrit les tests comme une dépense essentielle mais fréquemment négligée. Les organisations les évitent souvent, car une évaluation significative exige du temps, des données adaptées, des spécialistes techniques et des environnements qui ressemblent aux opérations réelles.

Cet évitement crée un raccourci dangereux. Un modèle peut bien fonctionner lors d’une démonstration contrôlée et pourtant échouer lorsqu’il est déployé auprès de populations, d’appareils, de lieux ou de conditions de travail différents.

Un système de reconnaissance faciale en fournit un exemple clair. Sa précision moyenne renseigne peu les décideurs sur ses performances en faible luminosité, avec des justificatifs endommagés ou selon les groupes démographiques. Un score global impressionnant peut masquer des erreurs concentrées qui touchent certaines personnes.

Les modèles de langage posent un problème de mesure différent. Leurs réponses varient selon les prompts, les documents récupérés, les versions du modèle et les instructions système. Une équipe ne peut pas établir leur fiabilité en soumettant plusieurs questions favorables et en enregistrant les meilleures réponses.

Les experts fédéraux considèrent donc le biais comme un élément qui doit être géré tout au long de la vie d’un système. Ce cadre est important, car il rejette l’idée que les développeurs peuvent éliminer toute tendance indésirable lors de l’entraînement.

Le comportement d’un modèle résulte de la sélection des données, de la conception du système, de l’interaction avec les utilisateurs et du contexte de déploiement. Même un modèle techniquement compétent peut produire un résultat préjudiciable lorsque la tâche qui lui est confiée est mal définie.

La présentation de Google News réduit cet argument à un appel direct en faveur de tests rigoureux. Le problème complet est plus difficile : les agences ont besoin de programmes de test qui reflètent chaque mission, la population concernée et le niveau de défaillance acceptable.

Cette exigence modifie les personnes qui participent à un projet d’IA. Les responsables des achats doivent demander des preuves, les responsables de programme doivent définir la tâche visée et les experts du domaine doivent identifier les résultats inacceptables. Les équipes de sécurité doivent tester les limites d’accès, tandis que les utilisateurs doivent évaluer si les résultats sont utiles en pratique.

Les développeurs ne peuvent pas répondre seuls à ces questions. Ils comprennent le système, mais ils ne représentent pas toutes les personnes affectées par ses décisions.

La distinction entre une démonstration et un déploiement est particulièrement importante. Une démonstration demande si un outil d’IA peut produire le résultat souhaité. Les tests de déploiement demandent à quelle fréquence il échoue, quels utilisateurs rencontrent ces échecs et si les contrôles existants les détectent.

Les agences fédérales fonctionnent aussi sous des contraintes que les entreprises de logiciels grand public ne partagent pas toujours. Leurs systèmes peuvent traiter des dossiers médicaux, des informations sur les prestations, des données des forces de l’ordre, des dossiers du personnel et des informations liées à la sécurité nationale.

Une erreur inoffensive dans un assistant de rédaction n’est pas équivalente à une erreur dans un flux de travail d’identité, médical ou d’admissibilité. Les tests doivent suivre les conséquences, et non l’enthousiasme suscité par le modèle.

C’est pourquoi ce titre mérite l’attention même en l’absence de nouvelle règle. Il illustre un passage concret de la discussion sur les principes de l’IA à l’exigence de performances observables en conditions réelles.

L’accélération de l’adoption fédérale augmente les enjeux

Les agences fédérales subissent une pression dans les deux sens : avancer trop lentement et perdre des capacités utiles, ou avancer trop vite et exposer le public à des systèmes mal compris.

L’ampleur de l’adoption explique pourquoi les tests sont devenus urgents. Une étude fédérale sur l’IA du Government Accountability Office a examiné les inventaires de 11 agences.

Ces inventaires comptaient 571 cas d’usage de l’IA déclarés en 2023 et 1 110 en 2024. Les cas d’usage déclarés de l’IA générative sont passés de 32 à 282 sur la même période, soit une multiplication d’environ neuf.

Ces chiffres ne prouvent pas que tous les systèmes recensés ont été mis en production. Les inventaires peuvent inclure des usages planifiés, exploratoires et opérationnels. Ils montrent néanmoins que les équipes fédérales évaluent l’IA pour bien davantage de tâches qu’auparavant.

Les cas d’usage vont au-delà des chatbots destinés au public. Le GAO a identifié des applications possibles dans la communication écrite, l’accès à l’information, le suivi des programmes, l’imagerie médicale et l’extraction d’informations de santé publique à partir de documents.

Chaque catégorie crée une définition différente de performances acceptables. Un assistant de rédaction peut tolérer une phrase maladroite si une personne la relit. Un système soutenant un travail médical ou de sécurité publique nécessite des preuves beaucoup plus solides.

Les dirigeants d’agence doivent donc classer les risques avant de choisir un plan d’évaluation. La question essentielle n’est pas de savoir si un modèle utilise l’IA générative. Elle est de savoir ce qui se passe lorsque le modèle se trompe.

Prenons un outil qui résume une politique interne. Son risque le plus évident est un résumé inexact. Cependant, il peut aussi omettre une exception, exposer un texte restreint, citer une règle remplacée ou produire des réponses différentes pour des utilisateurs similaires.

Un projet pilote peut passer à côté de ces défaillances, car les participants comprennent déjà les documents sources. De nouveaux employés pourraient faire confiance au même résultat sans reconnaître ce qui a disparu.

Les achats ajoutent une autre couche. Les agences acquièrent souvent des modèles, des services cloud et des applications auprès de fournisseurs au lieu de tout développer en interne. Les acheteurs dépendent alors de documents et de preuves d’évaluation qui peuvent ne pas correspondre à l’environnement du gouvernement.

Un benchmark d’un fournisseur peut établir qu’un modèle fonctionne bien lors d’un test standard. Il ne peut pas établir que l’ensemble du système de l’agence se comportera de manière sûre avec des données locales, des outils de récupération, des autorisations et des utilisateurs.

La distinction devient plus sérieuse avec l’IA agentique. Un agent d’IA est un système capable de choisir et d’exécuter des actions par l’intermédiaire de logiciels connectés, plutôt que de seulement renvoyer du texte.

Un chatbot ordinaire peut générer une recommandation erronée. Un agent connecté peut agir sur cette recommandation en modifiant un dossier, en envoyant un message, en appelant un service externe ou en lançant un autre flux de travail.

Les tests doivent alors couvrir à la fois le modèle et son autorité. Les évaluateurs doivent déterminer quelles actions sont autorisées, comment fonctionnent les validations et si le système s’arrête lorsque les instructions entrent en conflit.

Tamara Lilly, assistante inspectrice générale au Department of Health and Human Services, a averti que les systèmes automatisés peuvent fonctionner plus vite que les contrôles traditionnels. Ses orientations sur la gouvernance opérationnelle ont mis l’accent sur des limites claires, des règles d’accès et des preuves continues que les contrôles fonctionnent.

C’est l’objectif sous pression derrière l’article de Google News. Les directeurs des systèmes d’information et les responsables de l’IA doivent produire des résultats utiles tout en empêchant l’expérimentation de se transformer en déploiement incontrôlé.

La tension budgétaire est inévitable. Les environnements d’évaluation, les jeux de données représentatifs, les red teams, les examens d’accessibilité, les tests de sécurité et la surveillance après déploiement consomment tous des ressources.

Ces dépenses peuvent sembler retarder les bénéfices pour la mission. Pourtant, des tests insuffisants n’éliminent pas le coût. Ils le transfèrent aux utilisateurs, aux équipes de réponse aux incidents, aux auditeurs et aux futurs travaux de remédiation.

Le gouvernement doit aussi composer avec un problème de confiance auquel les organisations privées peuvent parfois échapper. Les personnes ne peuvent pas toujours choisir un autre système de prestations, processus frontalier ou organisme public après une défaillance automatisée.

Cette absence de choix relève le niveau d’exigence. Les agences ont besoin de preuves qu’un outil remplit son objectif défini, et non d’une affirmation générale selon laquelle le modèle sous-jacent est avancé.

Un programme d’adoption utile séparera donc l’assistance à faible risque de l’aide à la décision aux conséquences importantes. Il peut avancer rapidement sur des tâches de rédaction réversibles tout en appliquant des critères plus stricts aux systèmes qui affectent les droits, l’accès, la sécurité ou les services essentiels.

Cette approche ne nécessite pas de considérer chaque fonctionnalité d’IA comme tout aussi dangereuse. Elle exige d’adapter l’intensité des preuves et des contrôles aux conséquences d’une défaillance.

La vitesse face à l’assurance constitue le véritable conflit de l’IA fédérale

Le conflit central n’oppose pas l’innovation à la réglementation ; il oppose le déploiement rapide à une assurance adaptée à chaque mission.

La Maison-Blanche a renforcé l’adoption fédérale accélérée en avril 2025, au moyen de politiques révisées sur l’utilisation et l’acquisition de l’IA par les agences. La politique fédérale sur l’IA mettait l’accent sur la réduction des obstacles inutiles tout en maintenant des protections pour la vie privée, les droits civils et les libertés civiles.

Cette combinaison semble compatible sur le papier. En pratique, la vitesse et l’assurance se disputent les mêmes effectifs, les mêmes budgets et la même attention des dirigeants.

Une équipe peut acquérir rapidement un assistant commercial. Elle ne peut pas déterminer instantanément comment cet assistant gère chaque document restreint, instruction trompeuse, affirmation non étayée ou demande inhabituelle d’un utilisateur.

Le compromis qui en résulte est souvent présenté de manière erronée. On demande aux dirigeants s’ils soutiennent l’adoption de l’IA ou s’ils préfèrent la prudence. Ce cadre transforme un travail d’ingénierie essentiel en préférence politique.

Les tests font partie du déploiement, ils ne constituent pas un argument contre lui. L’aviation, les technologies médicales, la cybersécurité et d’autres domaines aux conséquences importantes reposent sur l’évaluation, car des systèmes utiles peuvent tout de même échouer.

L’IA complique ce principe, car son comportement est probabiliste. Un système probabiliste peut produire des résultats différents à partir d’entrées similaires, surtout après qu’un fournisseur a mis à jour le modèle.

Les tests de logiciels traditionnels restent nécessaires, mais ils ne suffisent pas. Un développeur peut vérifier qu’une API renvoie une réponse sans établir que cette réponse est exacte, équitable, sûre ou utile.

Les équipes fédérales ont besoin de plusieurs niveaux d’assurance. Les tests de capacité demandent si le système accomplit la tâche qui lui est attribuée. Les tests adversariaux demandent comment il réagit aux tentatives de manipulation.

Les tests sur le terrain examinent les performances avec de vrais utilisateurs et dans des conditions de fonctionnement réalistes. La surveillance vérifie si les résultats changent après le déploiement, l’arrivée de nouvelles données ou une mise à jour du modèle.

La supervision humaine relie ces niveaux. Une personne ne peut pas superviser de manière significative un système d’IA sans disposer de suffisamment de temps, d’autorité et de connaissances du domaine pour remettre en question ses résultats.

Un bouton d’approbation nominal ne crée pas de supervision. Si les employés traitent des centaines de recommandations sous la pression des délais, ils peuvent accepter automatiquement les résultats.

Les agences doivent tester le flux de travail humain en parallèle du modèle. Elles devraient mesurer si les réviseurs détectent les erreurs, comprennent l’incertitude et savent quand faire remonter un résultat.

Cela crée un renversement inconfortable. L’IA est souvent achetée pour réduire le travail humain, alors qu’une mise en œuvre sûre peut initialement exiger davantage de travail spécialisé.

Les équipes de programme ont besoin d’experts métier pour élaborer des cas de test. Les spécialistes de la sécurité doivent examiner les flux de données, les juristes doivent évaluer les obligations légales et les experts en accessibilité doivent analyser l’impact sur les utilisateurs.

L’investissement peut néanmoins être rentable. Un système testé peut réduire les tâches répétitives tout en maintenant l’attention des personnes sur les exceptions et le jugement. Toutefois, les dirigeants ne devraient pas prétendre que la supervision apparaît automatiquement.

Le même conflit concerne les fournisseurs. Les acheteurs publics souhaitent accéder rapidement à des modèles plus récents, mais des mises à jour fréquentes peuvent invalider les résultats d’évaluations antérieures.

Un fournisseur peut améliorer le raisonnement général tout en modifiant le comportement de refus, le formatage ou les performances sur une tâche spécialisée. Les agences ont besoin de contrôles de version et de déclencheurs de révalidation avant d’accepter de telles mises à jour.

Les fournisseurs de modèles ne peuvent pas non plus tester eux-mêmes tous les contextes fédéraux. Un système généraliste rencontre des risques différents lorsqu’il est connecté à des dossiers d’immigration, des données scientifiques, des documents d’approvisionnement ou des flux de travail cliniques.

La responsabilité est donc partagée, mais non interchangeable. Les fournisseurs devraient divulguer les limites et modifications pertinentes. Les agences doivent toujours tester le système assemblé dans son environnement prévu.

Google News offre un moyen simple de découvrir le sujet, mais le conflit de politique publique va bien au-delà d’un seul titre. Les responsables fédéraux sont invités à accélérer l’adoption sans abaisser les normes associées à l’autorité publique.

La réponse praticable est un déploiement par étapes. Les équipes commencent par une tâche ciblée, des données limitées, des autorisations restreintes et des critères de réussite mesurables.

Elles ne s’étendent ensuite que lorsque les preuves justifient cette extension. Cette méthode maintient l’élan tout en créant un dossier que les auditeurs, les responsables et les utilisateurs concernés peuvent examiner.

Le déploiement par étapes rend aussi les échecs plus instructifs. Un pilote circonscrit peut révéler qu’un modèle est inadapté sans créer un problème de service à l’échelle nationale.

L’alternative est le déploiement par enthousiasme. Cette voie considère la fluidité initiale comme une preuve, confond les benchmarks des fournisseurs avec les performances opérationnelles et découvre les limites à travers des incidents publics.

Des tests rigoureux de l’IA doivent suivre le système jusqu’en production

Un test avant déploiement n’est qu’un point de départ, car le comportement de l’IA peut changer lorsque les modèles, les données, les utilisateurs et les outils connectés évoluent.

Le National Institute of Standards and Technology décrit les tests dans le cadre plus large des processus de test, d’évaluation, de vérification et de validation. Ce processus est souvent abrégé en TEVV.

Le cadre de risque du NIST indique que les systèmes d’IA devraient être testés avant leur déploiement puis régulièrement pendant leur exploitation. Il appelle également à des méthodes documentées, des critères mesurables, des conditions réalistes et la participation d’experts indépendants ou internes extérieurs à l’équipe de développement.

Ces orientations montrent pourquoi le mot « rigoureux » compte. Faire passer une fois un modèle à travers une liste fixe de prompts n’établit pas des performances fiables.

Une évaluation significative commence par une tâche définie. Les agences devraient préciser les utilisateurs visés, les données disponibles, les conditions d’exploitation, les actions interdites et les conséquences d’un échec.

Les évaluateurs peuvent ensuite concevoir des tests autour de cas réalistes. Ils devraient inclure des exemples ordinaires, des cas rares, des entrées adversariales, des informations incomplètes et des situations dans lesquelles le système devrait refuser d’agir.

Les métriques doivent également refléter la mission. L’exactitude peut compter, mais elle ne permet pas forcément de déterminer si les erreurs se concentrent chez certains groupes.

Une équipe évaluant des résumés pourrait mesurer les affirmations non étayées, les exigences omises, les citations incorrectes et la divulgation d’informations restreintes. Une équipe évaluant une technologie d’identité aurait besoin de mesures différentes.

Les seuils devraient être définis avant que les dirigeants ne voient des résultats favorables. Sinon, les équipes de projet peuvent redéfinir la réussite après avoir observé les faiblesses du système.

Une évaluation indépendante contribue à réduire ce risque. Les développeurs comprennent naturellement comment obtenir de bons résultats de leur système. Les utilisateurs et les évaluateurs externes sont plus susceptibles de découvrir des instructions confuses et des comportements inattendus.

Le red teaming apporte une autre perspective. Le red teaming est un test adversarial structuré qui recherche des faiblesses, des résultats nuisibles ou des moyens de contourner les contrôles.

Il ne devrait pas devenir du théâtre. Quelques prompts spectaculaires peuvent créer de la publicité sans mesurer les risques qui comptent pour une agence donnée.

De bonnes équipes de red teaming travaillent à partir d’un modèle de menace, qui identifie les attaquants potentiels, les actifs protégés, les méthodes probables et les conséquences opérationnelles. Leurs conclusions devraient mener à des corrections, à de nouveaux tests et à des décisions documentées.

Les tests sur le terrain sont tout aussi importants, car les laboratoires ne peuvent pas reproduire tous les comportements humains. Les employés peuvent copier des documents plus volumineux que prévu, poser des questions ambiguës ou combiner les résultats avec des informations non officielles.

Un système peut également modifier le milieu de travail qui l’entoure. Le personnel peut cesser de vérifier les sources primaires, modifier sa manière de documenter les décisions ou s’appuyer sur un langage généré qui masque la responsabilité.

Ces effets apparaissent rarement dans un benchmark. Ils se révèlent par l’observation, les entretiens avec les utilisateurs, le signalement d’incidents et des mesures répétées.

La surveillance en production doit ensuite détecter la dérive. La dérive signifie que la relation entre les entrées, le comportement du modèle et les résultats attendus évolue avec le temps.

La cause peut être une nouvelle version de modèle, une population d’utilisateurs différente, une collection de récupération modifiée ou l’évolution des conditions réelles. Chacun de ces facteurs peut affaiblir une évaluation antérieure.

La surveillance devrait enregistrer davantage que la disponibilité du système. Les équipes ont besoin de signaux concernant les résultats inhabituels, les contrôles défaillants, les dérogations des utilisateurs, les plaintes et la qualité propre à la tâche.

Elles ont également besoin d’un processus de gestion des incidents. Les employés doivent savoir où signaler un résultat suspect, et les responsables de programme doivent avoir l’autorité nécessaire pour restreindre ou suspendre le système.

Cette capacité compte particulièrement pour les agents connectés. L’accès selon le principe du moindre privilège consiste à n’accorder à un système que les autorisations requises pour la tâche qui lui est attribuée.

Un assistant de rédaction n’a pas besoin de l’autorisation de publier. Un agent de planification n’a pas besoin d’un accès illimité aux dossiers du personnel.

Les équipes devraient tester ce qui se passe lorsque le modèle demande une action hors de ses autorisations. Le résultat attendu doit être un échec contrôlé, non une solution de contournement improvisée.

L’évaluation des données mérite la même attention. Les agences doivent comprendre quelles informations entrent dans un modèle, où elles sont traitées, ce qui est conservé et qui peut les récupérer.

La génération augmentée par récupération, une méthode qui fournit des documents sélectionnés à un modèle, peut améliorer la pertinence. Elle peut aussi reproduire des contenus obsolètes, non autorisés ou contradictoires.

La gouvernance documentaire devient donc une partie des tests de l’IA. Une base de connaissances consultable fiable nécessite une responsabilité claire, des contrôles d’accès, des documents sources à jour et des mises à jour traçables.

Le point sceptique est qu’aucun programme d’évaluation ne peut prouver qu’un modèle généraliste est sûr dans toutes les conditions. Les entrées et interactions possibles sont trop vastes.

Les agences devraient éviter les affirmations absolues telles que non biaisé, sécurisé ou sans hallucinations. Ces descriptions dépassent ce qu’un test circonscrit peut établir.

Une conclusion défendable est plus étroite. Les preuves peuvent montrer qu’un système particulier a atteint des seuils définis pour une tâche, une version, une population et un environnement précis.

Cette réserve n’est pas une faiblesse. Elle constitue le fondement d’une assurance honnête.

Les équipes fédérales doivent également publier suffisamment d’informations pour permettre la supervision sans exposer les systèmes sensibles. Elles peuvent décrire l’usage prévu, les catégories d’évaluation, les limites et les processus de surveillance tout en protégeant les détails opérationnels.

La transparence renforce la responsabilité, car elle permet au public de distinguer un assistant contrôlé d’un système automatisé de prise de décision. Elle donne aussi aux inspecteurs et aux législateurs une base pour poser des questions précises.

Le principal risque de mise en œuvre est de transformer les tests en liste de contrôle. Un formulaire rempli ne peut pas remplacer des preuves réalistes.

Les documents de conformité comptent, mais ils devraient renvoyer aux résultats de tests, aux dossiers d’incidents, aux versions de modèles et aux responsables identifiables. Sinon, les agences risquent de produire une documentation abondante autour d’un système incertain.

Ce que les acheteurs fédéraux d’IA devraient surveiller ensuite

La prochaine phase sera mesurée par la capacité des agences fédérales à convertir les principes de test en étapes de déploiement contraignantes et en preuves continues.

Le premier signal concerne la manière dont les agences mettent en œuvre une approbation fondée sur les risques pour l’IA à forts enjeux. Les inventaires à eux seuls ne peuvent pas montrer si les dirigeants ont interrompu, limité ou repensé des systèmes ayant échoué à l’évaluation.

Surveillez la documentation publique qui distingue l’assistance à faible risque de l’IA affectant les droits, la sécurité, l’accès ou les services essentiels. Des catégories claires renforceraient l’argument selon lequel une adoption plus rapide peut coexister avec une assurance plus stricte.

L’absence de ces catégories l’affaiblirait. Les agences pourraient revendiquer la conformité tout en appliquant des examens similaires à des risques fondamentalement différents.

Le deuxième signal est de savoir si les contrats d’approvisionnement préservent les droits d’évaluation après l’achat. Les acheteurs publics ont besoin d’accéder aux avis de changement de modèle, à la documentation pertinente, au soutien aux tests et aux contrôles sur les mises à jour.

Le langage contractuel devrait également clarifier les responsabilités en matière d’incidents et de traitement des données. Sans ces conditions, les agences peuvent devenir dépendantes d’assurances fournisseurs qui ne reflètent pas leur environnement déployé.

Des preuves d’exigences contractuelles reproductibles montreraient que les tests ont été intégrés plus en amont, dans l’acquisition. Le recours continu à des affirmations génériques sur les performances indiquerait que l’écart de déploiement persiste.

Le troisième signal concerne ce que les agences rapportent une fois les systèmes en production. Les preuves utiles incluraient les pratiques de surveillance, les incidents significatifs, les actions correctives et des exemples d’usages restreints ou abandonnés.

L’absence d’incidents signalés n’établit pas nécessairement la sécurité. Elle peut indiquer que les employés ne disposent pas de canaux de signalement ou que les agences définissent les incidents de manière trop restrictive.

Les lecteurs devraient prêter une attention particulière aux systèmes qui obtiennent l’autorisation d’agir. Le passage du texte généré à l’action autonome augmente à la fois le bénéfice potentiel et le coût d’une erreur.

C’est là que Google News et des plateformes de découverte similaires ont un rôle utile. Elles peuvent faire émerger des auditions d’agences, des entretiens avec des spécialistes, des rapports d’organismes de surveillance et des changements de politique publique qui resteraient autrement dispersés.

L’agrégation n’est toutefois pas une vérification. Les lecteurs devraient suivre un titre jusqu’au reportage original, puis comparer ses affirmations avec les politiques, les audits et les orientations techniques.

Les preuves actuelles appuient une conclusion mesurée. Le déploiement fédéral de l’IA s’étend, tandis que les experts élaborent encore les méthodes nécessaires pour évaluer les systèmes dans des conditions réalistes.

Cela ne justifie pas le gel de chaque projet. Cela justifie des cas d’usage ciblés, des seuils mesurables, une autorité humaine, des autorisations restreintes et une surveillance après le lancement.

La question décisive n’est plus de savoir si les agences fédérales utiliseront l’IA. Elles le font déjà, et leurs cas d’usage déclarés ont considérablement augmenté.

La question est de savoir si chaque agence peut montrer pourquoi un système spécifique mérite l’autorité qui lui est attribuée. Cette preuve devrait inclure la tâche, les conditions testées, les seuils d’échec, le responsable désigné et la réponse lorsque le comportement change.

Lorsque le prochain titre de Google News annoncera un déploiement fédéral de l’IA, regardez au-delà du nom du modèle. Demandez-vous ce qui a été testé, qui l’a évalué, quels échecs subsistent et si l’agence peut arrêter le système en toute sécurité.