SAFE RFC : l'échange d'incidents d'IA de style aéronautique d'OSAA est un brouillon ouvert, pas encore un système

Le 4 août 2026, alors que Black Hat USA ouvrait ses portes à Las Vegas, la Linux Foundation a publié une demande de commentaires pour le groupe de travail Shared AI Findings Exchange (SAFE) — une proposition visant à ce que les organisations signalent les incidents de sécurité liés à l’IA et les quasi-incidents dans un canal partagé confidentiel, en tirent collectivement des enseignements et publient des contrôles défensifs dérivés de ce qui a échoué. Le projet initial a été élaboré par des contributeurs de Cisco, CrowdStrike, Hugging Face, NVIDIA et Red Hat, entre autres membres de l’alliance, a indiqué la Linux Foundation dans son annonce. Il a été ouvert à l’examen de la communauté via le dépôt GitHub de l’Open Secure AI Alliance le jour même. L’entrée ne décrit aucun préjudice : il s’agit d’un enregistrement de politique, classé dans l’archive avec une note de gravité de niveau info et une note de confiance A, et son objet est un processus plutôt qu’un événement. La note de gravité, la note de confiance et la liste des sources de l’enregistrement figurent dans l’archive des incidents d’IA, aux côtés des entrées classées autour d’elle.

Le projet demande aux membres de signaler quatre choses, et d’ignorer pourquoi.

Le texte d’août est avare de rhétorique et précis sur les déclencheurs. Sous un intitulé appelé Reporting Compact, il demande aux membres d’accepter — comme condition d’adhésion — de signaler un incident lorsqu’ils prennent connaissance ou soupçonnent raisonnablement qu’un système d’IA qu’ils exploitent a fait l’une des quatre choses suivantes : accédé sans autorisation à un système tiers, l’a exploité, perturbé, détourné de son usage ou modifié ; causé un impact sur un tiers en s’échappant ou en contournant une limite de bac à sable, de réseau, d’identité, de politique ou d’outil ; accédé à des informations confidentielles d’un tiers sans le consentement de leur propriétaire ; ou continué à sonder, accéder à ou modifier une cible de production après que l’opérateur a su, ou soupçonné raisonnablement, que l’activité était non autorisée ou hors du périmètre approuvé.

Vient ensuite la phrase qui fait l’essentiel du travail : « L’intention ne détermine pas si un événement est déclarable. Croire qu’un environnement était simulé peut expliquer un incident, mais cela ne supprime pas l’obligation de le déclarer. » Cette clause semble viser le cas où un système fonctionne dans ce que son opérateur croit être un environnement de test isolé et traite l’infrastructure en production comme faisant partie de l’exercice : la croyance de l’opérateur concernant l’environnement peut expliquer l’événement, mais elle ne supprime pas l’obligation de déclaration. Le projet demande également aux membres de signaler les quasi-incidents, et pas seulement les événements ayant causé un préjudice confirmé, ainsi que de fournir une analyse préliminaire de défaillance des contrôles dans les 30 jours.

Le délai : immédiat, 72 heures, quatre jours ouvrables, quatre-vingt-dix jours

Le tableau des notifications du projet est l'élément le plus concret qu'il contient, et sa première ligne n'est pas du tout un délai : l'organisation directement affectée doit être informée immédiatement. Chaque délai court à compter du moment où le membre prend connaissance de faits donnant des motifs raisonnables de soupçonner un événement déclarable — et non du moment où une enquête est conclue. Le tableau ci-dessous est reproduit à partir du projet du 4 août ; la révision d'octobre conserve les mêmes intervalles.

Trois de ces lignes concernent le fait d’informer d’autres personnes, et quatre concernent le fait d’informer SAFE lui-même. La distinction est importante car le cadre n’est explicitement pas un régime de divulgation : le projet indique « Ces délais ne remplacent aucune obligation incombant à un fournisseur de notifier les parties affectées, les clients selon les bonnes pratiques existantes en matière de divulgation coordonnée des vulnérabilités, ni aucune obligation contractuelle ou autre obligation légale de notifier les régulateurs ou les forces de l’ordre. » Ce que SAFE ajoute, c’est une obligation parallèle envers un organe qui n’est pas un régulateur — et un modèle de divulgation à trois niveaux dans lequel seul le dernier niveau, le rapport de sécurité publique, est censé être largement diffusable.

Huit couches de contrôle en août, onze en octobre

Les revues sont structurées autour de la pile opérationnelle plutôt qu’autour du modèle seul. Le projet d’août énumérait huit couches et posait une question à chacune — le modèle reconnaissait-il l’incertitude et les conditions d’arrêt ; les hypothèses relatives à l’autorisation et à l’environnement étaient-elles explicites ; les classificateurs, les approbations et les limites d’action fonctionnaient-ils ; les identifiants, les permissions et l’exécution étaient-ils contraints ; l’isolation et les frontières de données étaient-elles vérifiées de manière indépendante ; les opérateurs pouvaient-ils détecter et interrompre en temps réel ; les voies d’escalade et les procédures d’arrêt d’urgence étaient-elles claires ; un partenaire cloud, d’évaluation, de données ou d’outillage invalidait-il les contrôles présumés.

La révision d’octobre, datée du 21 octobre 2026 et intégrée au dépôt le lendemain, ajoute trois couches : le chemin de service, l’autorisation au moment de l’engagement et la composition de workflows sur une séquence d’actions. Elle transforme aussi l’examen en une évaluation graduée comportant quatre réponses autorisées — réussite, échec, preuves insuffisantes, non applicable — et indique dans son journal des modifications que ces constatations n’établissent ni la sécurité générale du système ni sa conformité juridique. La progression vaut la peine d’être lue comme une description de ce que les auteurs ont appris à surveiller : non pas si le modèle s’est bien comporté, mais si le modèle qui a répondu était bien celui qui avait été configuré, si l’autorisation existait encore au moment où l’action a abouti, et si la séquence dans son ensemble est restée dans le périmètre qui l’avait initiée.

L’aviation, mais quelle partie de l’aviation ?

La présentation du dossier elle-même — un système calqué sur l’Aviation Safety Reporting System de la NASA — suit l’annonce de la Linux Foundation plutôt que le projet de texte. L’annonce décrit l’ASRS comme « un système de signalement volontaire et confidentiel, conçu pour analyser les accidents de vol et y répondre d’une manière qui permette au secteur d’apprendre et de s’améliorer ». Ni le projet d’août ni la révision d’octobre ne nomme l’ASRS nulle part ; le projet indique seulement que SAFE « devrait adopter les caractéristiques les plus solides des systèmes confidentiels de signalement de sécurité ». C’est une petite différence aux conséquences pratiques : l’annonce crée une attente à laquelle le texte ne s’engage pas encore.

L’analogie a suscité des commentaires au sein même du processus RFC. Une demande de fusion précoce ouverte le 5 août, par un contributeur s’exprimant à titre personnel, soutient que « l’analogie avec l’ASRS comporte un élément institutionnel manquant » — que l’ASRS fonctionne en grande partie parce que les rapports sont reçus, traités et anonymisés par la NASA, « une tierce partie publique, non régulatrice et non commerciale — et non par la FAA en tant qu’autorité de régulation, ni par les compagnies aériennes dont les opérations sont signalées ». La demande de fusion, qui s’appuie aussi sur le processus de gouvernance d’Internet de 1998, restait ouverte au 30 octobre. La question de savoir si l’opérateur de SAFE peut jouer le rôle de la NASA est une question de conception non résolue plutôt qu’une caractéristique établie : le texte d’octobre place le groupe de travail sous la gouvernance propre de l’Alliance, avec déclaration des conflits d’intérêts, récusation et voie de recours auprès du comité directeur de l’Alliance.

Une couverture indépendante a établi une seconde distinction, plus étroite. Infosecurity Magazine, dans un article du 6 août, a noté que la publication de la Linux Foundation ne mentionne pas spécifiquement les agents IA — le cadrage agentique relève de l’article complémentaire de NVIDIA, qui soutient qu’« un agent IA n’est pas seulement un modèle. C’est un système », et énumère les harnais de test, les environnements sandbox, les garde-fous et les outils d’évaluation fournis par les membres de l’alliance. Les critères de déclenchement du projet de texte, lus littéralement, concernent des systèmes agissant en dehors de toute autorisation ; l’argumentaire de l’annonce, lu littéralement, porte sur les agents.

Ce que les commentateurs ont dit sur qui supporte le coût

L’une des objections publiées les plus précises au projet tel qu’il est rédigé émanait d’un membre fondateur de l’alliance plutôt que d’un critique externe. Stephen Sargent, fondateur et directeur de la technologie d’Avondale.AI, a soumis une déclaration de position par courriel le 7 août — un jour où, selon le document, l’équipe juridique de la Linux Foundation en a accusé réception — et l’a publiée le 9 août. Il commence par soutenir la mission, puis soutient que le pacte ne s’adapte pas à la taille de l’organisation : « Le RFC ne fait pas de distinction entre une organisation de 50 000 employés et une petite équipe. » Selon son évaluation, un rapport de quatre jours ouvrables accompagné d’un ensemble de preuves numériques préservé pourrait mobiliser plus de temps du personnel qu’un petit opérateur ne peut en accorder ; sa recommandation est un cadre à plusieurs niveaux, avec des rapports confidentiels et une publication retardée ou anonymisée par défaut en dessous d’un seuil de taille.

Une deuxième objection porte sur la divulgation plutôt que sur les délais : il soutient que « la divulgation publique EST une forme de mise en application » pour les petits opérateurs, car le rapport d'une grande entreprise est une note de bas de page et celui d'une petite entreprise devient le titre principal, et demande que les rapports anonymisés soient la valeur par défaut en dessous d'un seuil de taille. Une troisième concerne le cadre d'examen plutôt que le calendrier : le modèle à huit couches suppose des équipes d'entreprise cloisonnées, de sorte que, dans un déploiement assuré par une seule personne, « l'opérateur fait tout » et une couche manquante est interprétée comme une défaillance de contrôle alors qu'il s'agit simplement d'un modèle opérationnel différent. Sa quatrième porte sur l'expression « pratiques minimales d'interopérabilité et d'assurance », qu'il lit comme une voie allant de la déclaration volontaire à des outils de facto obligatoires. La déclaration de position est le point de vue d'un membre, publiée par ce membre. L'annonce de la Linux Foundation du 4 août la précède et n'aborde pas la question. Une pull request ultérieure, ouverte le 5 octobre et toujours ouverte le 30 octobre, propose un modèle de preuves pour les opérateurs dépourvus de centre des opérations de sécurité — une reconnaissance que la préoccupation a été prise en compte, et une solution candidate plutôt qu'une correction adoptée, son auteur précisant qu'elle « n'établit pas l'adoption de SAFE ni sa suffisance juridique ».

Qu'est-ce qui a changé entre le 4 août et le 30 octobre ?

L'historique du dépôt est la meilleure trace disponible de ce que le RFC a réellement produit, et il est plus lisible que ne le laisse entendre la couverture médiatique. Les premiers commits ont été poussés le 3 août ; le brouillon et un readme étoffé ont été commités à 00:14 et 00:19 UTC le 4 août. Puis le dépôt est resté silencieux pendant dix semaines. Le 14 octobre, l'alliance a ajouté une charte et un fichier des membres et réécrit le readme pour faire du dépôt le foyer du groupe de travail SAFE ; les présidents intérimaires y ont été consignés ce jour-là comme étant Paul DiOrio de NVIDIA et Josh Boyer de Red Hat. Le 21 octobre, le groupe de travail a publié SAFE v1, avec un journal des modifications dont la première entrée indique que le texte « retire "proposed" de la description de SAFE » et le présente comme un groupe de travail établi de l'Alliance.

Deux aspects de cette situation méritent d’être distingués. Le fichier readme du dépôt comporte désormais la ligne « Statut : Approuvé — Approuvé par le comité de pilotage », qui est ce qui ressemble le plus à une déclaration de ratification dans les documents publics ; la charte, dans le même dépôt, indique encore « En cours d’élaboration. La charte SAFE sera publiée ici une fois approuvée par le comité de pilotage. » Le journal des modifications désigne le texte d’octobre sous le nom « SAFE v1 » et décrit ce qu’il modifie, mais ne précise pas qui l’a ratifié, lors de quel vote, ni à quelle date. Un lecteur qui veut savoir si SAFE est désormais une spécification approuvée, ou un groupe de travail dont la charte de gouvernance reste à écrire, n’obtiendra pas de réponse claire des documents.

Ce qui est établi, et ce qui ne l’est pas

• Établi : une Request for Comments pour le Shared AI Findings Exchange a été publiée le 4 août 2026 — la Linux Foundation a daté son annonce à ce jour-là — et les organisations citées comme contributeurs dans ce document sont Cisco, CrowdStrike, Hugging Face, NVIDIA et Red Hat, aux côtés d’« autres membres de l’Open Secure AI Alliance ».

• Établi : le projet contient un accord de reporting avec quatre déclencheurs, un tableau de notification allant de l’immédiat à 90 jours, une liste de préservation des preuves, un cadre d’examen à plusieurs niveaux et un modèle de divulgation à trois niveaux. Le texte intégral est public dans le dépôt et son historique l’est également.

• Établi, avec attribution uniquement : la taille de l'alliance — « plus de 120 organisations » — est le chiffre avancé par NVIDIA lui-même, repris dans le rapport d'Infosecurity Magazine du 6 août. Aucune des sources examinées ne fait état d'un audit indépendant des adhésions, et le fichier des membres du dépôt liste deux contributeurs et deux présidents par intérim, et non 120 organisations.

• Non établi :que quiconque ait déposé un rapport en vertu du pacte. Le registre public du 30 octobre montre des commits, des pull requests et des issues ; il ne montre pas de rapport d’incident, de projet pilote, de premier cas, de date limite de commentaires, de règle de vote ni de date de ratification. Le cadre décrit une obligation que les membres « acceptent » comme condition d’adhésion, ce qui n’est pas la même chose qu’une obligation dont quiconque se serait déjà acquitté.

• Contesté : la question de savoir si la comparaison avec l’ASRS tient sans opérateur public neutre, point contesté dans une pull request ouverte ; si la charge de déclaration est proportionnée pour les petits opérateurs, point contesté dans la déclaration de position d’un membre fondateur ; et dans quelle mesure le cadre est spécifique aux agents plutôt que de relever de la sécurité générale de l’IA, une distinction que le texte de la Linux Foundation et celui de NVIDIA établissent différemment.

Rien de tout cela ne rend la fiche erronée, et la note A de l’archive est défendable selon ses propres critères : les documents primaires concordent entre eux sur ce qui a été publié, quand et par qui, et le brouillon est lisible dans son intégralité. Ce que la note ne peut pas porter, c’est ce qu’un lecteur souhaite le plus savoir — si le mécanisme fonctionne. Sur ce point, il n’existe aucune preuve dans un sens ou dans l’autre, car le mécanisme n’a pas encore eu de cas à traiter.