L’infrastructure est une carte de gouvernance, pas une liste de cibles
L’IA de pointe dépend de puces avancées, d’équipements de fabrication de semi-conducteurs, de grands centres de données, de services cloud, d’électricité, de réseaux, et de personnel formé. Cette concentration donne aux gouvernements, aux opérateurs, aux clients, et aux développeurs des moyens légaux d’imposer des exigences de sécurité. Elle ne justifie pas l’intrusion, le sabotage, la violence, ou l’interférence avec l’énergie et les communications. Des attaques physiques mettraient en danger les travailleurs et les communautés, perturberaient des services sans rapport, détruiraient des preuves, et réduiraient probablement la capacité de la société à gérer un incident.
La question utile est institutionnelle : quel acteur autorisé peut limiter une activité risquée, en vertu de quelle règle, avec quelles preuves, et comment la décision peut-elle être annulée en toute sécurité ? La réponse change tout au long du cycle de vie de l’IA.
Quatre surfaces de contrôle à ne pas confondre
Les contrôles d’entraînement régissent la création ou l’amélioration majeure d’un modèle. Un entraînement de pointe peut utiliser une grappe grande et géographiquement identifiable pendant des semaines ou des mois. Les mesures pertinentes incluent la diligence raisonnable envers le client, les normes de sécurité, la comptabilité du calcul, les évaluations préalables au déploiement, et les conditions contractuelles ou réglementaires sur les entraînements exceptionnellement grands. Les contrôles d’entraînement agissent avant qu’un modèle n’existe sous sa forme finale ; arrêter un entraînement ne rappelle pas des poids antérieurs.
Les contrôles des poids de modèle protègent les fichiers de paramètres appris. Les poids peuvent être copiés, volés, ajustés, et exécutés ailleurs. La sécurité peut inclure un accès garanti par le matériel, la séparation des tâches, le chiffrement, la surveillance, des procédures de risque interne, et la réponse aux incidents. Une fois que des poids capables sont diffusés largement, une révocation centrale peut devenir impossible. La diffusion ouverte peut soutenir la recherche et la concurrence, si bien que les restrictions devraient se fonder sur un risque démontré et s’accompagner d’un accès indépendant lorsque c’est possible.
Les contrôles de déploiement régissent un modèle ou une application hébergés. Un opérateur peut révoquer des identifiants, désactiver un outil, revenir à une version antérieure du modèle, limiter le débit ou la géographie, placer un utilisateur dans un niveau de garantie supérieur, et surveiller les abus. Ces contrôles sont comparativement précis et réversibles. Ils échouent cependant si des copies en aval, des sorties mises en cache, ou des poids hébergés de façon indépendante restent disponibles.
Les contrôles d’inférence régissent le calcul utilisé lorsqu’un système produit des sorties ou entreprend des actions. L’inférence peut se produire dans un cloud central, un environnement d’entreprise, un téléphone, ou une grappe distribuée. Un fournisseur peut restreindre sa propre inférence hébergée mais ne peut pas arrêter automatiquement les copies locales. Le calcul au moment de l’inférence, les permissions d’outils, l’accès aux données, et le volume d’actions peuvent compter davantage que le coût d’entraînement d’origine pour le risque d’un système déployé.
Appeler ces quatre éléments un seul « goulot d’étranglement de calcul » masque ces différences. Une intervention légale devrait nommer la surface pertinente et l’effet attendu.
Le contrôle opérationnel à l’intérieur d’une organisation
Les organisations ont besoin de plus qu’un dramatique « interrupteur d’arrêt ». Elles ont besoin d’une procédure d’état sûr rodée. Mettre fin abruptement à un système peut corrompre des données, interrompre des processus cliniques ou industriels, bloquer des utilisateurs, ou déclencher des paramètres par défaut dangereux. La bonne réponse pourrait être la révocation de privilèges, la réduction du trafic, l’isolation, le retour en arrière, ou le transfert vers un contrôle manuel, plutôt que de tout éteindre.
Un plan de production devrait inclure :
- Inventaire : identifier chaque modèle, version, outil, identifiant, ensemble de données, fournisseur, et dépendance en aval.
- Autorité : nommer les personnes qui peuvent restreindre le service et définir quand elles peuvent agir sans attendre l’approbation normale.
- Moindre privilège : ne donner au système que les données et actions requises pour sa tâche ; utiliser des identifiants à durée limitée lorsque c’est possible.
- Surveillance : enregistrer les versions de modèle, les invites ou résumés d’événements sûrs, les appels d’outils, les approbations, les sorties, et les changements de configuration tout en respectant la vie privée.
- Confinement : soutenir l’isolation rapide des réseaux, outils, mouvements d’argent, déploiements de code, ou contrôles physiques.
- Retour en arrière : maintenir une version connue et fonctionnelle, un format de données compatible, et un processus de restauration testé.
- Repli humain : conserver du personnel formé, des instructions, un accès, et la capacité de fournir un service essentiel dégradé.
- Exercice : mener des simulations sur table et techniques, enregistrer les échecs, et les corriger.
Le cadre de gestion des risques de l’IA du NIST appelle à une gouvernance du cycle de vie, une reddition de comptes, une surveillance continue, des processus de contingence pour les défaillances de tiers, et un retrait sûr de service (noyau du NIST AI RMF). C’est une directive volontaire, pas une certification qu’une organisation particulière a mis en œuvre ces pratiques.
La révocation de privilèges est souvent le frein le plus rapide
Un système d’IA devient plus lourd de conséquences lorsqu’il est connecté au courrier électronique, au code de production, aux comptes financiers, aux outils de laboratoire, aux systèmes d’identité, ou à la technologie opérationnelle. Révoquer ces privilèges peut réduire le préjudice tout en conservant le modèle pour l’enquête. L’accès devrait être segmenté de sorte qu’une seule décision puisse désactiver une capacité risquée sans effondrer des services sans rapport.
Les identifiants ne doivent pas être intégrés de façon permanente dans les invites ou les fichiers de modèle. Les opérateurs devraient utiliser des identités de service délimitées, une expiration courte, des portes d’approbation pour les actions à fort impact, et des contrôles indépendants que le modèle ne peut pas modifier. L’accès d’urgence (« break-glass ») a besoin de son propre journal et de sa propre révision. Un système ne devrait pas pouvoir s’accorder à lui-même des permissions plus larges.
Pour un fournisseur externe, les contrats devraient garantir une suspension rapide, la préservation des preuves, l’exportation des données, et un soutien à la migration. Sinon, le client peut découvrir pendant un incident qu’il ne peut ni inspecter les journaux ni annuler une mise à jour automatique.
Le repli humain est une infrastructure
Les services essentiels ont besoin d’un mode dégradé qui fonctionne. Cela ne signifie pas que chaque processus peut instantanément revenir au papier. Cela signifie que les opérateurs décident à l’avance quelles fonctions doivent se poursuivre, à quelle capacité minimale, avec quel personnel et quelles communications. L’énergie, l’eau, la santé, la finance, le transport, et les prestations publiques ont des contraintes de sécurité différentes.
Une procédure manuelle qu’aucun employé n’a pratiquée n’est pas un repli. Les organisations devraient former le personnel, conserver les interfaces non-IA nécessaires, tester la restauration à partir de sauvegardes hors ligne, et mesurer combien de temps le mode dégradé peut fonctionner. Les fournisseurs et les agences publiques devraient coordonner leurs dépendances : le plan d’un hôpital peut échouer si son fournisseur d’identité, son service cloud, et son réseau de pharmacie supposent tous que les autres resteront en ligne.
La Cybersecurity and Infrastructure Security Agency recommande la planification de la réponse aux incidents, la compréhension des actifs, la segmentation, et les pratiques de récupération pour l’infrastructure critique (objectifs de performance en cybersécurité de la CISA). La réponse spécifique à l’IA appartient à l’intérieur des programmes établis de sécurité et de cybersécurité, pas en dehors.
Le levier des gouvernements et des clients
Les gouvernements peuvent assortir de conditions les marchés publics, les licences, les subventions, l’accès aux ressources publiques, et les services critiques réglementés. Les fournisseurs de cloud et de centres de données peuvent mener une diligence raisonnable conforme à la loi. Les services publics et les autorités locales peuvent appliquer les règles ordinaires de fiabilité, d’environnement, d’aménagement du territoire, et de planification des urgences, sans transformer la politique d’infrastructure en une interdiction déguisée de toute l’IA.
Les clients ont un levier par les contrats. Avant l’achat, exigez la documentation du système, les résultats d’évaluation pertinents pour le cas d’usage, la notification de sécurité, le contrôle des versions, des droits d’audit, la coopération en cas d’incident, la portabilité des données, et un plan de sortie. Un client devrait savoir si le fournisseur peut substituer un nouveau modèle silencieusement et si le service reste disponible pendant un retour en arrière.
Ces mesures ont besoin d’une procédure régulière. Une restriction devrait avoir une base légale définie, une norme de preuve, un décideur responsable, une durée, et une voie de révision. L’autorité d’urgence peut être nécessaire, mais un contrôle secret indéfini invite à l’abus.
La concentration crée à la fois du levier et de la fragilité
Des chaînes d’approvisionnement concentrées en puces et en cloud peuvent rendre la supervision pratique, mais elles créent aussi des points uniques de défaillance, du pouvoir de marché, et une vulnérabilité géopolitique. La décentralisation peut améliorer la résilience et la concurrence tout en rendant plus difficiles le rappel de produits et des garde-fous cohérents. Ni la concentration ni l’ouverture ne sont intrinsèquement sûres.
La politique devrait distinguer la rareté qui reflète une véritable ingénierie de la rareté créée par des contrats exclusifs ou une dépendance imposée envers un fournisseur. L’interopérabilité, la planification multi-cloud, des formats communs d’incident, et des journaux portables peuvent réduire la dépendance sans prétendre que toute charge de travail peut se déplacer instantanément.
La conclusion pratique
La société conserve un levier significatif sur l’IA par le droit, les marchés publics, l’autorité d’entreprise, le contrôle d’accès technique, et une conception de services résiliente. La bonne action est rarement un arrêt théâtral. C’est une intervention spécifique et autorisée au niveau de l’entraînement, des poids, du déploiement, ou de l’inférence — combinée au confinement, à la préservation des preuves, au retour en arrière, et à la continuité.
L’infrastructure devient protectrice lorsque les gens savent qui peut agir et ont répété ce qui se passe ensuite. Le contrôle légal est le plus solide lorsqu’il est assez précis pour réduire le risque sans créer une seconde urgence.