Le système d'IA le plus important pourrait être celui que personne ne voit

Le modèle n'est que la partie visible. La véritable capacité IA de l'Europe repose sur les puces, la puissance de calcul, les réseaux, les données, les...

Le système d'IA le plus important pourrait être celui que personne ne voit

La machine derrière la réponse

Le premier supercalculateur exascale d'Europe n'est pas une métaphore. JUPITER est un système réel au Forschungszentrum Jülich, exploité par le Jülich Supercomputing Centre. L'entreprise commune EuroHPC décrit son architecture BullSequana à refroidissement liquide direct, une partition flash ultra-rapide de 20 pétaoctets, et une conception destinée à des simulations exigeantes et à une intelligence artificielle à forte intensité de calcul. La description regorge de détails qui rendent un système possible : une architecture de processeur, un niveau de stockage, une méthode de refroidissement, une institution d'exploitation et un chemin d'accès. Le modèle qui pourrait éventuellement s'exécuter par-dessus n'est qu'une partie de la phrase.

Cette distinction est facile à perdre de vue, car la partie visible de l'IA est une réponse. Une personne pose une question, un modèle renvoie du texte, et l'écran donne l'impression que l'intelligence est arrivée en un seul colis. Le travail caché est moins cinématographique. L'électricité doit atteindre le bâtiment. Les composants doivent arriver en bon état. Une image de firmware doit être digne de confiance. Les réseaux doivent transporter les données entre les processeurs et le stockage. L'identité doit établir quelle personne ou quel service peut utiliser quelle ressource. Un ordonnanceur doit trouver de la capacité. Un registre doit indiquer à un opérateur quel modèle, quel conteneur et quelle version de données sont en cours d'utilisation. La surveillance doit remarquer que le système a changé. Quelqu'un doit encore savoir comment le réparer un mardi pluvieux, lorsque la documentation du fournisseur a acquis un nouveau numéro de version et que la seule personne qui comprenait l'ancienne est en congé.

Le système d'IA important peut donc être celui que personne ne voit. C'est la chaîne d'approvisionnement, le contrat d'électricité, le tissu réseau, le plan de maintenance, l'arbre des dépendances logicielles, la décision d'achat et la mémoire institutionnelle qui permettent d'utiliser un modèle sans prétendre que le modèle est l'intégralité du service. Lorsque ce système caché est faible, un modèle plus performant ne rend pas le service plus solide. Il donne au système faible une manière plus impressionnante d'échouer.

Ce n'est pas un argument contre les modèles ou les grands programmes publics de calcul. C'est un argument pour les décrire honnêtement. L'Europe renforce ses capacités grâce au Chips Act, à EuroHPC et au programme AI Factories. Les pages politiques de la Commission parlent de dépendances stratégiques, de résilience de la chaîne d'approvisionnement, d'accès pour les petites entreprises et de l'infrastructure requise pour une IA digne de confiance. Ce sont des questions d'infrastructure, pas des questions de marque. Si le continent veut une capacité utile plutôt qu'une collection de démonstrations impressionnantes, il doit traiter les couches silencieuses comme faisant partie de la capacité.

La réponse est la couche supérieure. Le service dépend de chaque couche située en dessous.

Un modèle est un composant, pas un pays

Dans le débat public, on utilise souvent un modèle comme raccourci pour désigner une capacité entière. Un pays a un modèle, une entreprise a un modèle, un département a un modèle, et l'on traite ce modèle comme s'il portait sa propre chaîne d'approvisionnement. Ce n'est pas le cas. Un modèle a un fichier, des paramètres, un environnement d'exécution et un ensemble d'hypothèses sur le travail qu'il est censé accomplir. Le service qui l'entoure assume le reste des obligations.

Prenons un système modeste qui classe les documents entrants avant qu'une équipe humaine ne les examine. Il lui faut un canal de réception, une file d'attente, un analyseur, un stockage, un contrôle d'accès, un environnement d'exécution pour le modèle, un stockage des résultats, un chemin de notification, un moyen de revenir en arrière sur une version et un journal de ce qui s'est passé. Le classifieur peut être précis sur son jeu de test et rester inutilisable si l'analyseur omet un champ, si le système d'identité accorde le mauvais rôle, si le conteneur du modèle ne peut pas être récupéré, ou si l'opérateur ne peut pas dire quelle version a fait une recommandation. Aucune de ces défaillances n'est une hallucination du modèle. Ce sont des défaillances du service qui a rendu le modèle utile.

L'erreur inverse est tout aussi courante. Des équipes décrivent un service entier comme résilient parce que le modèle a été évalué, tout en laissant les dépendances en dehors du périmètre d'évaluation. Un test de modèle peut vérifier les sorties pour une charge de travail sélectionnée. Il vérifie rarement si un certificat expire au moment où un dépôt de logiciels change sa clé de signature, si un niveau de stockage a assez de capacité pour un document plus long que d'habitude, ou si une personne peut retrouver l'enregistrement source après qu'un fournisseur a modifié une interface de programmation d'application. Ces préoccupations relèvent du système opérationnel. Elles font toujours partie de ce qu'un utilisateur vit comme de l'IA.

La question utile n'est pas de savoir si un modèle est bon isolément. C'est de savoir quelles autres choses doivent être vraies avant que la sortie du modèle puisse être fiable, et qui a l'autorité pour réparer ces choses. Cette question déplace la conversation d'un catalogue de modèles vers une frontière de système. Elle crée aussi un inventaire moins flatteur mais plus utile.

  • Quelles ressources physiques doivent rester disponibles ?
  • Quels composants logiciels et micrologiciels doivent arriver intacts et rester pris en charge ?
  • Quels services d'identité, de réseau, de stockage et de registre doivent répondre ?
  • Quelle organisation est responsable lorsque la dépendance change ?
  • Quelles preuves permettent à une autre personne de vérifier la réponse plus tard ?
  • Proposal for the Chips Act 2.0, Commission européenne, 3 juin 2026.

Ces questions ne sont pas théoriques. Elles font la différence entre une capacité qui peut être exploitée et une capacité qui peut être démontrée une fois. Les démonstrations sont agréables. Les services essentiels doivent survivre à la prochaine fenêtre de maintenance.

Les chaînes d'approvisionnement sont à l'intérieur de la frontière du système

Le travail de l'ENISA sur l'intégrité des chaînes d'approvisionnement commence par une observation sans éclat : les gouvernements, les organisations, les entreprises et les consommateurs dépendent de plus en plus des produits et services TIC, et donc des chaînes d'approvisionnement qui les livrent. Son rapport nomme des menaces qui vont de l'altération pendant le développement, la distribution ou l'exploitation à la substitution par des composants contrefaits ou clonés. Le point est plus large qu'une liste de contrôle de sécurité. La chose fournie n'est pas seulement une boîte. C'est une séquence de personnes, de code, de composants, de contrats et de décisions grâce à laquelle la boîte devient suffisamment digne de confiance pour être utilisée.

Un service d'IA hérite de cette séquence. Une exécution d'entraînement dépend d'une image de base, d'un compilateur, d'un pilote, d'un noyau, d'un planificateur et d'un jeu de données source. Un service d'inférence dépend des mêmes couches plus un environnement d'exécution de service, un index, une passerelle de politique et une interface qui peut continuer à fonctionner lorsque le trafic ne ressemble pas au jeu de test. Une institution publique peut acheter un service plutôt que l'une de ces parties, mais la chaîne cachée ne disparaît pas parce que le contrat l'appelle une plateforme.

La mise à jour prospective 2024 de l'ENISA place la compromission de la chaîne d'approvisionnement logicielle en tête de sa liste des menaces de cybersécurité pour 2030. Elle classe également parmi les principales préoccupations les pénuries de compétences, l'erreur humaine dans les écosystèmes cyber-physiques, les fournisseurs de services TIC transfrontaliers comme point de défaillance unique et l'impact physique des perturbations environnementales sur les infrastructures numériques critiques. Il ne s'agit pas d'affirmer que chaque projet d'IA rencontrera toutes ces menaces. Il s'agit d'un rappel que la surface d'attaque est faite de relations. Un correctif, un fournisseur, une personne et une inondation peuvent tous affecter le même service, même s'ils figurent dans des registres de risques différents.

Le langage de ce même rapport est utile car il résiste à la fantaisie selon laquelle le risque cyber n'appartiendrait qu'à l'équipe de sécurité. Une dépendance peut être compromise dans le logiciel, mais ses conséquences peuvent arriver par un processus physique, un choix d'approvisionnement ou une compétence manquante. Un service peut devenir un point de défaillance unique parce que son fournisseur est techniquement excellent et largement utilisé. La concentration n'est pas la même chose que l'incompétence. C'est une propriété du réseau autour d'un service.

Cela crée un problème pratique de périmètre. Si une organisation n'évalue que le modèle et son environnement d'exécution immédiat, le résultat peut être exact pour le périmètre choisi et trompeur pour le service qu'elle exploite. Si elle évalue chaque fournisseur avec la même intensité, elle produira un tableur que personne ne pourra maintenir. La réponse est une cartographie des dépendances qui suit les conséquences. Identifiez ce qui peut modifier une sortie, interrompre un service, effacer des preuves, élargir l'autorité ou empêcher la récupération. Demandez ensuite si la dépendance est suffisamment visible pour être surveillée et si une autre voie existe.

Cette cartographie devrait inclure les matériaux ordinaires. Un serveur nécessite de la mémoire, des dispositifs de stockage, de la conversion de puissance, des équipements de refroidissement et des pièces de rechange. Un réseau nécessite des composants optiques, des commutateurs, des logiciels de routage et des personnes qui connaissent la topologie. Une chaîne d'approvisionnement logicielle nécessite des mainteneurs, une infrastructure de construction, des registres de paquets, des clés de signature et des procédures de publication. Aucun de ces éléments ne devient moins important parce que la brochure du produit dit intelligence artificielle.

Il est tentant de répondre par un questionnaire fournisseur plus long. Un questionnaire peut être utile, mais ce n'est pas une cartographie des dépendances. Il enregistre ce qu'un fournisseur dit à un moment donné. La question opérationnelle est de savoir si l'acheteur peut remarquer un changement, l'interpréter et prendre une mesure proportionnée. Une liste de certificats ne remplace pas la connaissance du composant qui arrêterait le service s'il disparaissait demain matin. Les organisations européennes sont admirablement douées pour collecter des documents. Le métier le plus difficile consiste à faire en sorte que les documents pointent vers une décision.

Les puces rendent l'invisible physique

La loi européenne sur les puces énonce un fait qui devrait être évident et qui doit encore être énoncé : les semi-conducteurs sont des éléments constitutifs des produits électroniques et sont essentiels à des secteurs allant des communications et du traitement des données à la santé, à l'énergie, aux transports et à l'automatisation industrielle. La loi est entrée en vigueur en septembre 2023 et fixe des objectifs qui incluent le renforcement de la recherche et du leadership technologique, le renforcement des capacités de conception, de fabrication et de conditionnement, la résolution des pénuries de compétences et le développement d'une compréhension plus approfondie de la chaîne d'approvisionnement mondiale des semi-conducteurs.

Cette liste importe pour l'IA car la capacité de calcul n'est pas créée par un logo de cloud. Elle est créée par une chaîne de conceptions, de tranches, d'équipements, de conditionnement, de tests, de distribution d'énergie, de refroidissement, de mise en réseau et de maintenance. Une pénurie ou un retard dans une partie peut changer ce qu'un centre de données peut fournir, même lorsque les fichiers du modèle sont prêts. Si un composant a un délai de livraison long, un opérateur ne peut pas résoudre le problème avec une invite astucieuse. Si une dépendance au micrologiciel ne peut pas être mise à jour en toute sécurité, le choix peut être entre une réduction contrôlée du service et une tentative dangereuse de tout maintenir en fonctionnement.

La synthèse de la Commission présente les trois piliers de la loi sur les puces. Le premier soutient le renforcement des capacités et l'innovation, notamment les lignes pilotes et les centres de compétences. Le deuxième porte sur la sécurité d'approvisionnement et la résilience, à travers la fabrication, l'assemblage avancé, les tests et l'assemblage final. Le troisième crée des mécanismes de surveillance et de réponse aux crises, dont un Conseil européen des semiconducteurs qui cartographie et surveille la chaîne de valeur et coordonne les réponses aux crises dans ce secteur. Cette architecture institutionnelle corrige utilement l'idée selon laquelle la souveraineté consisterait à produire chaque composant sur le territoire national. La résilience tient en partie à la capacité, en partie à la visibilité, et en partie à la capacité de réagir lorsqu'une dépendance se déplace.

La page donne également des exemples concrets de premières installations d'un genre nouveau approuvées à Catane, Crolles, Dresde, Novare, Premstätten, Milan et dans d'autres sites européens. Ces entrées ne prouvent pas que l'Europe a résolu le problème des semiconducteurs. Elles prouvent que la chaîne de valeur a des lieux physiques, des technologies et des décisions d'investissement que l'on peut nommer. Les nommer change la conversation. Cela permet de se demander quelle capacité chaque installation apporte, sur quels intrants elle repose encore, de quelles compétences elle a besoin et comment elle serait soutenue en cas de perturbation.

La proposition de la Commission pour une loi sur les puces 2.0, publiée en juin 2026, indique que l'Union reste dépendante de pays tiers dans des domaines clés tels que la fabrication avancée de puces et la conception de semiconducteurs. Pour un article du 31 juillet, il s'agit d'une déclaration de politique actuelle, et non d'une prédiction sur un futur texte législatif. Son implication pratique est simple : un service européen peut être hébergé en Europe et dépendre néanmoins d'une chaîne mondiale dont les décisions les plus importantes se prennent ailleurs. La localisation physique a de la valeur. Elle n'équivaut pas au contrôle.

La politique de l'IA peut gagner en sérieux en empruntant ce vocabulaire physique. Au lieu de se demander si un modèle est européen, il faut se demander quelles parties du service peuvent être réparées, remplacées, inspectées et suspendues au sein des institutions européennes. Au lieu de se demander si un fournisseur dispose d'une région européenne, il faut se demander comment le matériel, le firmware, les dépendances logicielles et l'autorité d'exploitation circulent à travers le service. La réponse sera désordonnée. Tant mieux. Les cartes désordonnées sont souvent les premières à être honnêtes.

Le calcul est une capacité publique

EuroHPC offre un cas utile parce qu'il rend l'infrastructure de calcul visible sans la transformer en produit de consommation. Sa liste publique indique que l'entreprise commune a acquis douze supercalculateurs de pointe à travers l'Europe. La liste nomme les systèmes et leurs hôtes : JUPITER à Jülich en Allemagne, LUMI à Kajaani, Leonardo à Bologne, MareNostrum 5 à Barcelone, Karolina à Ostrava et Arrhenius à l'université de Linköping, entre autres. Les lieux importent moins comme tableau de classement que comme rappel que le calcul est ancré dans des institutions, des bâtiments, du personnel, des systèmes électriques, du stockage et des programmes de recherche.

JUPITER est décrit comme le premier supercalculateur exascale d'Europe, avec une architecture à refroidissement liquide direct, une partition flash de 20 pétaoctets et un module cluster utilisant le processeur SiPearl Rhea1 ainsi qu'un booster accéléré par GPU. La page de LUMI décrit des partitions distinctes CPU, GPU, analyse de données et cloud de conteneurs, avec un système de stockage combinant flash, système de fichiers parallèle et service de gestion des données. Ces détails ne sont pas de simples curiosités réservées aux ingénieurs. Ils indiquent au lecteur de politique publique qu'un supercalculateur est un ensemble de ressources aux formes différentes. Une charge de travail adaptée à une partition peut ne pas convenir à une autre. L'accès, l'ordonnancement et le déplacement des données font partie de la capacité.

MareNostrum 5, hébergé par le Barcelona Supercomputing Center, et Arrhenius, en cours d'installation à l'université de Linköping et exploité par l'Infrastructure académique nationale pour le calcul intensif en Suède, illustrent le même point de différentes manières. Une capacité européenne distribuée n'est pas une machine géante unique. C'est un ensemble de systèmes dotés de processeurs, d'organisations de stockage, d'opérateurs, de règles d'accès et de communautés scientifiques différents. Le réseau qui les relie importe, mais les jonctions aussi.

La politique des usines d'IA de la Commission décrit un programme fondé sur cette réalité. Les usines d'IA utilisent la capacité de calcul intensif d'EuroHPC pour développer une IA générative avancée et relier les centres de calcul, les universités, les petites et moyennes entreprises, l'industrie et les acteurs financiers. La page indique qu'au moment de sa mise à jour d'avril 2026, dix-neuf usines d'IA et treize antennes étaient opérationnelles, avec au moins neuf nouveaux supercalculateurs optimisés pour l'IA prévus. Elle décrit également un investissement à long terme de dix milliards d'euros via EuroHPC entre 2021 et 2027. Ce sont des arrangements institutionnels, pas une garantie que chaque projet recevra la capacité souhaitée ni que chaque modèle sera fiable.

La valeur de tels arrangements ne tient pas seulement à la vitesse. Le calcul public peut créer un espace où les chercheurs et les entreprises européennes peuvent exécuter des charges de travail selon des règles et des modalités d'accès visibles par les institutions publiques. Il peut soutenir des expérimentations qui seraient autrement exclues par le coût, et rendre certaines connaissances reproductibles entre les sites. Il peut aussi introduire de nouvelles dépendances si un programme repose sur un petit nombre de fournisseurs, une pile logicielle unique ou une main-d'œuvre irremplaçable. La propriété publique d'une installation ne supprime pas le travail d'exploitation. Elle rend la responsabilité plus difficile à dissimuler, ce qui est plus sain.

Lorsque le calcul devient une capacité publique, son succès devrait être mesuré au-delà de la performance de pointe. Un petit groupe de recherche peut-il obtenir un accès ? Une charge de travail sensible peut-elle être séparée d'une charge générale ? Un opérateur peut-il montrer quels logiciels et quels matériels ont été utilisés ? Une équipe peut-elle déplacer une charge de travail lorsqu'une partition est pleine ou qu'une dépendance est retirée ? Une autorité publique peut-elle expliquer les conditions dans lesquelles un modèle a été entraîné ? Une machine rapide qui ne peut pas répondre à ces questions reste utile pour certaines sciences, mais elle ne constitue pas encore une base complète pour une IA publique.

Les réseaux, le stockage et l'identité font le travail discret

Les couches les plus importantes sont souvent celles qui n'apparaissent pas dans un schéma d'IA. Un schéma dessine un modèle entre une entrée et une sortie. Un opérateur voit une chaîne de chemins réseau, de classes de stockage, d'assertions d'identité, de files d'attente, de certificats, de registres, de secrets, de pipelines d'observabilité et de contrôles des changements. Le schéma n'est pas faux. Il est incomplet exactement de la manière qui produit des surprises coûteuses.

Commençons par le réseau. Un service de modèles de grande taille peut déplacer des données entre accélérateurs, mémoire, stockage et autres services. Une charge de travail de recherche publique peut déplacer des ensembles de données vers un supercalculateur et renvoyer les résultats vers une université. Un flux de travail de production peut franchir une frontière politique avant d'atteindre un modèle et une autre frontière avant de renvoyer une décision. La latence, la perte de paquets, les changements de routage et la maintenance peuvent modifier le comportement de l'ensemble du service sans changer un seul paramètre du modèle. Un délai d'attente peut devenir une nouvelle tentative, une nouvelle tentative peut devenir un travail en double, et un travail en double peut devenir un enregistrement incorrect. Le modèle n'a pas décidé de réessayer. C'est le système environnant qui l'a fait.

Le stockage a sa propre grammaire cachée. Il y a l'enregistrement source, l'enregistrement transformé, l'index, le cache, le journal, la sauvegarde, le marqueur de suppression et la preuve qui indique quelle version a été utilisée. Un service peut être capable de répondre à une question tout en étant incapable de prouver quelles données ont rendu la réponse possible. La conservation et la récupération ne sont pas des images miroir. Tout conserver indéfiniment peut violer une limitation de finalité ; supprimer la source tout en laissant un dérivé ou un cache peut produire un problème différent. Une frontière de données sérieuse nomme ce qui est stocké, pour combien de temps, par qui, et comment un examinateur ultérieur peut déterminer que la frontière a été respectée.

L'identité n'est pas un écran de connexion. C'est le mécanisme qui donne à une personne, un service ou un agent l'autorité d'effectuer une action. Si un point de terminaison d'inférence peut appeler un outil, le système doit savoir quel principal a fait la demande, quelle politique a permis l'appel, et ce que l'outil était autorisé à toucher. Si un registre permet de promouvoir un conteneur, il doit savoir qui peut approuver la promotion et quelles preuves sont requises. Si un certificat est renouvelé automatiquement, le service doit encore avoir un moyen de remarquer que la relation d'identité a changé. Un secret qui reste valide après le départ de la personne qui l'a demandé est un problème de maintenance avec une conséquence de sécurité.

Les registres sont la mémoire d'un système en mouvement. Un registre de modèles peut contenir des versions et des métadonnées. Un registre d'artefacts peut contenir des conteneurs, des paquets ou des versions signées. Un registre de données peut décrire des schémas et la propriété. Un inventaire matériel peut identifier une carte, une version de firmware et l'état de remplacement. Le but n'est pas de créer un registre pour tout. Le but est de rendre explicite la source faisant autorité pour chaque affirmation. Si aucun système ne peut répondre à la question de savoir quel modèle, quel pilote, quelle version de données et quelle version de politique étaient actifs, alors un examen ultérieur est contraint de déduire l'historique à partir des journaux qui ont survécu.

L'observabilité boucle la boucle. Les métriques indiquent à un opérateur qu'une file d'attente a grandi ou qu'un appareil chauffe. Les traces montrent le chemin emprunté par une requête. Les journaux portent le contexte, bien qu'ils restent faciles à mal interpréter. Les événements et les attestations peuvent préserver les décisions et les changements. Ces objets ont des fonctions différentes. Les traiter comme interchangeables produit soit du bruit, soit une fausse impression de preuve. La question de conception est de savoir ce qu'une personne doit savoir lorsque le service est en retard, erroné, indisponible ou contesté, et quel enregistrement peut répondre à cette question sans exercice de reconstruction.

On peut décrire cela comme de l'ingénierie ennuyeuse. Ce n'est pas une insulte. L'ingénierie ennuyeuse est la partie qui continue de fonctionner après que l'annonce de lancement a quitté la page d'accueil. C'est aussi la partie qui détermine si un nouveau modèle peut être adopté sans réécrire l'institution autour de lui.

La maintenance est une capacité, pas une ligne de dépenses

Les récits d'infrastructure aiment se terminer au déploiement. C'est à ce moment que le travail devient un service. Un modèle est publié, un cluster est mis en service, une usine ouvre, un contrat est signé, et le récit passe à l'annonce suivante. Le système lui-même continue à travers les correctifs, le remplacement du matériel, la formation, les examens des accès, les mises à niveau, les abandons, la réponse aux incidents et la disparition progressive des personnes qui se souviennent pourquoi un paramètre a été choisi.

Le rapport de menaces de l'ENISA place les pénuries de compétences en tête de ses préoccupations à long terme. Ce n'est pas seulement une question de marché du travail. C'est une question de résilience. Un service dont les dépendances ne peuvent être comprises que par une seule personne a un point de défaillance unique caché. Une organisation peut avoir des machines de rechange et manquer tout de même de la capacité de les utiliser en toute sécurité parce que le manuel d'exploitation, le processus de construction ou le contrat de données vit dans la mémoire d'un seul ingénieur. Acheter du support peut réduire le risque, mais l'acheteur a toujours besoin d'assez de compréhension pour contester le fournisseur et décider quand s'arrêter.

La maintenance change aussi ce que signifie une performance annoncée. Un benchmark exécuté sur une version donnée renseigne sur cette version dans les conditions indiquées. Il ne dit pas que le système aura le même comportement après une mise à jour de pilote, un changement de compilateur, un nouvel ordonnanceur, un chemin de stockage différent ou une nouvelle charge de travail. Un service utile maintient les conditions de ses annonces. Il consigne les versions, les entrées, le matériel, les politiques et les changements afin que quelqu'un puisse reproduire un test ou expliquer pourquoi la reproduction n'est plus possible.

Prétendre que la maintenance est une préoccupation secondaire a un coût humain. Les opérateurs retardent les mises à niveau parce que le graphe de dépendances n'est pas clair. Les équipes de sécurité peinent à dire quel paquet est réellement en production. Les achats renouvellent un contrat parce que personne n'a répété une sortie. Les chercheurs ne peuvent pas reproduire un résultat parce que l'environnement a dérivé. Les utilisateurs rencontrent des erreurs intermittentes attribuées au modèle parce que le service n'a pas de langage commun pour les couches qui le sous-tendent. Le résultat n'est pas une défaillance unique et spectaculaire. C'est une lente érosion de la confiance.

Un calendrier de maintenance doit donc inclure plus que des dates de correctifs. Il doit inclure des revues de propriété, l'expiration des accès, la rotation des certificats et des clés, des tests de restauration de sauvegarde, la revue des dépendances, le cycle de vie du matériel, les avis de changement de fournisseur, le retrait des modèles et les preuves nécessaires pour chacun. Certaines de ces tâches peuvent être automatisées. La responsabilité ne peut pas être automatisée. Quelqu'un doit décider ce qui constitue un changement matériel, qui reçoit le signal et quelle autorité peut suspendre le service.

L'instinct européen de créer un comité pour un problème difficile est parfois moqué, souvent à tort. Un comité qui possède une carte des dépendances, une règle de changement et un chemin d'escalade est plus utile qu'un tableau de bord qui n'appartient à personne. Le problème n'est pas la gouvernance. Le problème est une gouvernance qui ne peut pas atteindre la machine.

Les achats sont le moment où les dépendances deviennent des engagements

Les contrats transforment une dépendance en engagement. Un acheteur choisit un fournisseur, un composant, un arrangement de support, un emplacement des données, une période de renouvellement et une condition de sortie. La décision peut être décrite comme l'achat d'un service d'IA, mais l'acheteur achète aussi le processus de mise à jour du fournisseur, sa réponse aux incidents, son modèle d'identité, la stabilité de son interface, sa documentation et sa capacité à rester en activité. Ce ne sont pas des caractéristiques secondaires. Elles déterminent le degré d'autorité que l'acheteur conserve.

Le document de 2025 du groupe consultatif de l'ENISA sur la mise en œuvre de NIS2 est remarquablement direct à ce sujet. Il note que les petites entreprises peuvent tomber dans le champ de la conformité NIS2 parce qu'elles fournissent des entités qui sont dans le périmètre. Il plaide pour un cadre européen de sécurité et d'achats de la chaîne d'approvisionnement avec une base de mesures et une méthode commune de diligence raisonnable. Il appelle aussi à une base d'achats avec des exigences contractuelles minimales, des clauses types, des approches de test de sécurité et un moyen simple pour un client d'évaluer les fournisseurs. Le document est un avis consultatif, pas un règlement. Sa valeur ici est qu'il nomme la friction opérationnelle produite lorsque chaque acheteur invente une version différente de la diligence.

Les équipes d'achats n'ont pas besoin d'exiger que chaque fournisseur divulgue chaque détail interne. Elles doivent poser des questions qui se rattachent aux conséquences. Quels composants sont essentiels au service ? Comment les changements sont-ils communiqués ? Comment l'acheteur peut-il vérifier le logiciel et le micrologiciel utilisés ? Que se passe-t-il si un fournisseur ou un sous-fournisseur ne peut pas fournir un composant ? Quelles données et quelles preuves peuvent être exportées ? Combien de temps le support continue-t-il après le retrait d'une version ? Qui peut suspendre une opération, et qu'advient-il du travail déjà en cours ?

Ces questions sont moins spectaculaires qu’une démonstration. Elles sont aussi plus difficiles à simuler. Un fournisseur peut présenter une réponse fluide en dix minutes. Il est plus difficile de montrer un inventaire complet des dépendances, une restauration testée, un chemin de migration et une personne habilitée à dire non au bon moment. L’acheteur ne doit pas considérer cette difficulté comme une raison d’éviter les questions. C’est la raison de les poser avant que le service ne devienne difficile à remplacer.

Le risque de concentration mérite un langage précis. Un fournisseur largement utilisé n’est pas automatiquement dangereux, et un petit fournisseur n’est pas automatiquement résilient. La concentration devient un risque lorsqu’un fournisseur, un dépôt de logiciels, une route géographique, une autorité d’identité ou une équipe de maintenance porte plus de conséquences que l’organisation ne peut en absorber. Le rapport de prospective de l’ENISA décrit les fournisseurs de services TIC transfrontaliers comme un point de défaillance unique potentiel. La réponse appropriée n’est pas de prétendre que la concentration peut être éliminée. Il s’agit d’identifier où elle existe, de fixer une dépendance acceptable et de répéter ce qui se passe si la route est indisponible.

Les clauses de sortie sont souvent rédigées comme du mobilier juridique. Une véritable clause de sortie a une forme technique. Elle nomme les formats, les interfaces, les droits de récupération, les clés, les journaux, les preuves, le support pendant la transition, la confirmation de suppression et les informations minimales nécessaires pour reconstruire un service ailleurs. Elle est plus solide lorsqu’elle a été testée sur une charge de travail réduite. Le test n’a pas besoin d’être théâtral. Une exportation contrôlée, une restauration dans un environnement indépendant et une comparaison du comportement résultant peuvent révéler plus que plusieurs pages d’assurances.

Les infrastructures critiques sont un réseau de dépendances

La directive sur la résilience des entités critiques fait un mouvement similaire au niveau des services essentiels. Elle définit la résilience comme la capacité d’une entité à prévenir, protéger contre, répondre à, résister à, atténuer, absorber, accommoder et se remettre d’un incident. Elle décrit les infrastructures critiques comme un actif, une installation, un équipement, un réseau ou un système nécessaire à un service essentiel. La formulation est délibérément plus large qu’un bâtiment. Elle traite un service comme une relation entre actifs, personnes et fonctions.

La directive indique que les États membres devraient prendre en compte les risques transsectoriels et transfrontaliers, et elle souligne les interdépendances croissantes entre les infrastructures et les secteurs. Elle indique également que les effets sur la chaîne d’approvisionnement devraient être pris en compte lors de l’évaluation de l’importance d’un incident perturbateur. Cela importe pour les infrastructures d’IA, car le service concerné peut ne pas être étiqueté intelligence artificielle du tout. Une liaison de données, un système électrique, un service d’identité, un système de dossiers hospitaliers ou un réseau de recherche peut être la couche qui rend possible un service basé sur l’IA.

La directive n’est pas un manuel d’exploitation de l’IA. Elle ne classe pas chaque service de modèle comme critique et ne remplace pas les règles spécifiques au secteur. Elle fournit une manière de penser les conséquences. Si un système soutient un service essentiel, la question n’est pas seulement de savoir si le modèle a réussi une évaluation. Il s’agit de savoir si l’entité peut continuer à fournir le service essentiel lorsqu’un composant, une installation, un fournisseur, un réseau ou une condition externe change.

NIS2 s’inscrit à côté de cette vision physique et organisationnelle avec des obligations de gestion des risques de cybersécurité et de notification des incidents pour les entités concernées. L’interaction juridique est spécifique et dépend de l’entité et du secteur. La leçon générale n’est pas qu’une seule directive résout la résilience. C’est que les dépendances cybernétiques et physiques doivent être coordonnées. Un réseau peut être sécurisé contre un type d’attaque et échouer encore lorsque le refroidissement est indisponible. Une installation peut avoir une alimentation redondante et être encore incapable d’authentifier les opérateurs. Un fournisseur peut notifier un incident logiciel tandis que l’acheteur manque des enregistrements nécessaires pour comprendre son effet.

La résilience a donc besoin d’un vocabulaire pour le service dégradé, et pas seulement pour la panne totale. Le système peut-il accepter moins de requêtes ? Peut-il désactiver une fonction à haut risque tout en préservant une fonction à faible risque ? Peut-il basculer vers un modèle plus petit ou un parcours manuel ? Peut-il continuer pendant qu’une file d’attente est vidée et qu’une source est vérifiée ? Peut-il prouver quels travaux ont été retardés ou retraités ? Ce sont des décisions opérationnelles. Elles déterminent aussi si les citoyens, les chercheurs et les entreprises vivent une limitation maîtrisée ou une réponse mystérieuse qui arrive après que l’institution a perdu le contexte nécessaire pour l’examiner.

L’image utile est celle d’un réseau dont les nœuds ont des propriétaires et dont les arêtes ont des conditions. Une arête peut être une connexion électrique, une dépendance logicielle, un contrat, un transfert de données ou une relation d’autorité. Une conception résiliente ne suppose pas que chaque arête restera disponible. Elle enregistre l’arête, surveille la condition qui compte et définit une réponse avant l’arrivée de la pression.

Un composite illustratif, pas un rapport d’incident

Il est utile de rendre le problème des dépendances concret sans inventer une panne réelle. Ce qui suit est un composite illustratif. Il ne décrit aucune organisation, aucun fournisseur, aucune installation, aucune personne, aucune date ni aucun événement nommés. C’est une expérience de pensée assemblée à partir de relations d’infrastructure ordinaires.

Imaginez un service de recherche public qui permet à des équipes autorisées de soumettre un document, d’exécuter un flux de classification et de recevoir un résultat pour examen humain. Le service est hébergé sur une infrastructure européenne. Son modèle est stocké dans un registre d’artefacts. Les documents sources vivent dans un niveau de stockage et l’index dans un autre. Une passerelle vérifie l’identité et transmet le travail à une file d’attente. Les travailleurs utilisent une image de conteneur et un pilote matériel. Les résultats sont écrits dans un magasin d’enregistrements et un flux de preuves. Un tableau de bord indique à l’équipe opérationnelle si le système est sain.

Rien ici n’est inhabituel. C’est précisément le propos. Maintenant, changez une condition à la fois. Le registre modifie sa politique de signature. La mise à jour du pilote exige un nouveau runtime de conteneur. Un certificat expire pour le service qui écrit les preuves, tandis que le magasin de résultats continue d’accepter les écritures. Un quota de stockage est atteint pour un index dérivé, mais pas pour les documents sources. Un fournisseur change une interface et le consommateur de la file d’attente réessaie une opération qui n’a pas été conçue pour être répétée. Un opérateur expérimenté part et le runbook décrit encore le déploiement précédent. Aucun de ces changements n’exige qu’un modèle produise une phrase fausse. Chacun peut modifier la fiabilité du service ou sa capacité à s’expliquer.

Une organisation qui ne surveille que la précision du modèle peut ne voir aucun avertissement. Le jeu de test passe toujours. Une organisation qui surveille l’ensemble du service verra des signaux différents : un échec de vérification, un nombre croissant de nouvelles tentatives, une lacune dans le flux de preuves, un seuil de stockage, un changement non examiné ou une alerte de propriété. Les signaux ne sont pas équivalents, et ils n’exigent pas tous une panne. Ils exigent une règle sur qui décide de la suite.

Supposons que l’équipe choisisse de réduire la capacité pendant qu’elle vérifie la dépendance. Ce n’est pas un signe que le service a manqué à sa mission. C’est peut-être un signe que le service a une mission plus large que le débit. Si le système peut préserver l’enregistrement source, marquer le travail retardé, empêcher les nouvelles tentatives non autorisées et offrir à un humain un parcours clair pour inspecter les cas concernés, il s’est dégradé de manière maîtrisée. S’il continue à produire des réponses soignées alors que son chemin de preuves est rompu, il a préservé l’apparence du service au détriment de la confiance.

Le composite est délibérément ordinaire, car les incidents spectaculaires rendent la leçon trop facile. Tout le monde comprend qu'une inondation peut interrompre une installation. Le travail le plus difficile consiste à reconnaître qu'un certificat expiré, un registre sans propriétaire, un contrat de fournisseur modifié ou un test de récupération manquant peuvent également faire sortir un service de son périmètre de fonctionnement sûr. Les dépendances banales ne sont pas moins causales parce qu'elles ne fournissent pas de photographie dramatique.

La défaillance se propage à travers les relations

Une carte de propagation des défaillances doit suivre les relations plutôt que les étiquettes technologiques. Commencez par la promesse du service. Que l'utilisateur attend-il qu'il se produise, et que doit-il rester vrai pour que cette attente soit satisfaite ? Puis remontez à travers le modèle, l'exécution, la passerelle de politique, l'identité, le réseau, le stockage, le matériel, l'énergie, le fournisseur et l'institution. À chaque étape, demandez-vous à quoi ressemble une défaillance, comment elle est détectée, qui est responsable de la réponse et quelles preuves subsistent.

Cela semble linéaire, mais les systèmes réels se ramifient. Un modèle peut être disponible alors qu'un service de politique est indisponible. Une politique peut autoriser un appel alors qu'un enregistrement d'identité est obsolète. Une requête peut être acceptée alors qu'une file d'attente ne peut pas se vider. Un résultat peut être renvoyé alors que l'enregistrement nécessaire pour le contester manque. Une équipe d'infrastructure peut restaurer le service alors qu'un propriétaire de données doit encore décider si le travail affecté peut être approuvé. La carte de propagation doit montrer ces branches, car un seul voyant de statut vert ne le peut pas.

Une façon utile de dessiner la carte est de séparer quatre types de conséquences. La disponibilité demande si le travail peut avoir lieu. L'intégrité demande si le travail et ses enregistrements sont inchangés et complets. L'autorité demande si l'acteur était autorisé à effectuer le travail. La récupérabilité demande si le service peut revenir à un état connu et expliquer ce qui s'est produit. Une dépendance peut être acceptable pour une dimension et inacceptable pour une autre. Un cache peut améliorer la disponibilité tout en étant inadapté comme enregistrement faisant autorité. Un service d'identité tiers peut être pratique tout en rendant l'autorité difficile à inspecter pendant une perturbation.

La carte doit également montrer le temps. Certaines dépendances échouent immédiatement. D'autres dérivent. Un modèle peut rester disponible alors que ses données de support deviennent obsolètes. Un composant matériel peut fonctionner alors que le stock de remplacement devient impossible à obtenir. Un contrat peut rester valide alors que la politique de changement d'un fournisseur supprime lentement l'interface sur laquelle l'acheteur comptait. Plus un signal arrive tard, plus il est coûteux à interpréter. Le temps fait partie de la dépendance, et non une note dans le rapport d'incident.

Les équipes d'exploitation appellent souvent cela l'observabilité. Ce mot n'est utile que lorsqu'il pointe vers une action. Un graphe qui semble sain ne dit à personne quelle autorité il détient, quel changement a fait bouger le graphe ou quelles preuves doivent être conservées. Le but d'une carte des défaillances est de rendre une décision possible. Si le flux de preuves est incomplet, suspendez l'action affectée. Si le registre de modèles ne peut pas vérifier un artefact, ne le promouvez pas. Si un fournisseur modifie un composant en dehors du périmètre testé, répétez l'évaluation pertinente. Si un test de récupération ne peut pas restaurer l'enregistrement, n'appelez pas la sauvegarde un plan de récupération.

Il n'existe pas de seuil universel pour ces décisions. Une expérience de recherche, un service destiné au public et un flux de travail critique pour la sécurité ont des tolérances différentes. L'important est que le seuil appartienne au propriétaire du service, soit visible pour les opérateurs et puisse être révisé lorsque les preuves changent. Sinon, le seuil sera fixé par la première personne qui remarque la défaillance, ce qui est une manière remarquablement démocratique de faire fonctionner un système et une mauvaise manière de le gouverner.

Une dépendance n’a pas besoin de détruire le modèle pour modifier ce que le service peut affirmer en toute sécurité.

Mesurer la capacité sans masquer le dénominateur

L’infrastructure encourage les chiffres impressionnants. Exaflops, pétaoctets, nombre de processeurs, totaux d’investissement et nombre d’installations dans un programme décrivent tous quelque chose de réel. Aucun d’eux n’est le service en soi. Un chiffre devient utile lorsque son dénominateur et ses conditions sont visibles.

La performance de calcul de pointe ne dit pas à un chercheur à quelle vitesse une charge de travail particulière obtiendra une partition, déplacera ses données, terminera une exécution ou récupérera le résultat. Le nombre d’usines d’IA ne dit pas à une petite entreprise si son application recevra l’accès dans les conditions dont elle a besoin. Un total d’investissement dans les semi-conducteurs ne dit pas à un opérateur quel composant sera disponible en cas de pénurie. Un pourcentage de haute disponibilité ne dit pas à une institution publique si elle peut récupérer les preuves d’une décision contestée.

Une description responsable de la capacité associe donc le titre à la voie qui le sous-tend. Nommez la frontière matérielle et logicielle. Indiquez si le chiffre est de pointe, soutenu, planifié ou observé. Décrivez la charge de travail, le modèle d’accès et les exclusions. Dites quelles dépendances sont hors du périmètre de mesure. Maintenez l’affirmation liée à la version, au matériel, à l’ensemble de données et à la politique dans lesquels elle a été faite. L’objectif n’est pas de rendre chaque page illisible. C’est de rendre les pages importantes vérifiables.

Cette discipline améliore aussi le débat public. L’Europe n’a pas besoin de choisir entre ambition et prudence. Elle peut construire de grandes installations, financer une recherche ambitieuse et toujours dire où s’arrêtent les preuves. Un système public qui nomme ses contraintes est plus crédible que celui qui présente un chiffre propre sans aucun moyen de l’inspecter. La contrainte peut être une file d’attente, une interface, un fournisseur, un manque de compétences, une limite de puissance ou une frontière juridique. La nommer ne réduit pas la capacité. Elle dit aux gens de quel type de capacité il s’agit.

L’incertitude n’est pas un aveu de défaite. C’est un signal de maintenance. Si personne ne sait comment un changement de fournisseur affectera une charge de travail, la prochaine étape est un test ou une hypothèse explicite, pas un adjectif plus fort. Si un registre ne peut pas distinguer une version de modèle d’une configuration de service, la prochaine étape est un meilleur enregistrement. Si une institution ne peut pas dire quelle personne peut arrêter une opération, la prochaine étape est une carte des autorités. La précision est un moyen de décider quoi réparer.

Les couches silencieuses sont là où la souveraineté devient concrète

La souveraineté européenne est parfois évoquée comme s'il s'agissait d'un drapeau planté sur un centre de données. Un service peut être situé à l'intérieur de l'Union et dépendre néanmoins de composants externes, de la portée juridique de pays tiers, d'interfaces propriétaires, de compétences rares ou d'un fournisseur dont les décisions de modification ne peuvent pas être contestées. La localisation n'est qu'un des éléments d'une évaluation de la souveraineté. Le contrôle effectif dépend de la chaîne complète.

L'accent mis par le Chips Act sur la compréhension de la chaîne d'approvisionnement mondiale des semi-conducteurs, l'attention portée par la directive CER aux interdépendances intersectorielles et les avertissements de l'ENISA concernant les dépendances logicielles et les points de défaillance uniques convergent tous dans la même direction. La souveraineté n'est pas un simple interrupteur. C'est la capacité à comprendre de quoi dépend un service, à décider quelle dépendance est acceptable, à la remplacer ou à la contraindre si nécessaire et à conserver suffisamment d'éléments pour défendre cette décision.

Cette capacité peut se construire par petites étapes. Un groupe de recherche public peut tenir un inventaire de l'environnement d'exécution, du pilote et de la version des données utilisés pour un résultat. Une équipe d'achat peut exiger un chemin d'exportation testé plutôt qu'une promesse de portabilité. Une équipe d'exploitation peut définir un mode dégradé et le répéter. Un régulateur peut demander quels enregistrements seraient disponibles après un changement de fournisseur. Un fournisseur peut publier le périmètre de son support et les conditions dans lesquelles une mise à jour modifie le comportement. Aucune de ces actions ne rend un système autonome. Elles le rendent moins mystérieux.

Chez Dweve, c'est la raison précise pour laquelle nous nous intéressons aux fondations ouvertes et aux éléments discrets qui les entourent. Des projets tels que Core et Mesh ne sont utiles que lorsqu'ils s'inscrivent dans un périmètre opérationnel honnête, avec des enregistrements clairs, une autorité et des limites définies. Ils ne remplacent pas les infrastructures européennes, les institutions publiques ou la politique de chaîne d'approvisionnement, et cet article ne prétend pas qu'ils résolvent ces problèmes. La position est plus modeste : un composant ouvert est plus facile à inspecter, à remplacer et à enseigner lorsque ses contrats sont explicites. C'est une brique, pas tout le bâtiment.

Le bâtiment compte parce que les gens voient le dernier étage et vivent avec les fondations. La réponse à l'écran peut être fluide, mais le caractère réel du service est déterminé par les couches qui décident d'où vient la réponse, qui pourrait la modifier, ce qui se passe lorsqu'une dépendance évolue et si quelqu'un peut expliquer le résultat plus tard.

Construire le système que l'on peut encore voir

Le système d'IA le plus important est peut-être celui que personne ne voit, parce qu'il est réparti entre des lieux qui n'ont jamais été qualifiés d'IA. C'est l'usine de puces et la boucle de refroidissement. C'est le supercalculateur et l'ordonnanceur. C'est le registre de paquets, le fournisseur d'identité, la politique de stockage, la route réseau et le tableau de maintenance. C'est le contrat qui précise ce qui se passe lorsqu'un fournisseur modifie un composant. C'est l'institution qui peut suspendre un flux de travail avant qu'un signal faible ne devienne une défaillance publique.

Rien de tout cela ne réduit l'importance de la qualité des modèles. Cela donne à la qualité des modèles un endroit où elle compte. Un modèle ne peut servir une personne qu'à travers un système capable de recevoir l'entrée, d'effectuer le travail, de conserver l'enregistrement pertinent et de renvoyer le résultat avec suffisamment de contexte pour que quelqu'un puisse lui faire confiance ou le contester. Le modèle est un composant important de ce système. Ce n'est pas un pays, une chaîne d'approvisionnement, un plan de reprise ou une personne ayant l'autorité de réparer les parties qu'il ne peut pas voir.

Les programmes d'infrastructure européens sont une occasion de rendre ces dépendances visibles pendant que la capacité se construit. L'occasion est concrète. Publiez les interfaces et les périmètres d'exploitation. Financez la maintenance et les compétences en même temps que les équipements. Traitez les achats comme une décision de conception. Reliez la cybersécurité à la résilience physique. Donnez aux petites organisations un moyen d'utiliser les infrastructures publiques sans les obliger à devenir spécialistes de chaque couche. Mesurez l'accès, la reprise et les preuves avec autant de soin que les performances de pointe.

Il y a un certain plaisir européen à découvrir que la réponse à une grande question technologique est un inventaire, un manuel d'exploitation et une personne autorisée à arrêter la machine. Ce n'est pas glamour, mais cela a l'avantage de survivre au contact avec le mardi. Lorsque le système caché est suffisamment visible pour être inspecté, le modèle peut faire son travail sans porter un mythe qu'il n'a jamais été conçu pour porter.

Sources