PandoraBox est une borne libre de décontamination de clés USB, une « station blanche » : on insère une clé, la borne analyse chaque fichier avec plusieurs moteurs de détection, affiche les fichiers dangereux sur son écran tactile, puis les supprime quand l'utilisateur touche l'écran. La nouvelle version est une réécriture complète. Elle ne dépend plus du projet Pandora du CIRCL et elle est distribuée sous forme d'image système durcie, construite à partir de Debian 13. Le code est sous licence GPL-3.0 et le boîtier imprimable en 3D sous licence CERN-OHL-S v2.

Pourquoi une borne de décontamination

Les clés USB restent une porte d'entrée courante dans des systèmes d'information par ailleurs bien protégés. Les personnes changent d'organisation, utilisent des ordinateurs qui ne sont pas surveillés et vont sur des réseaux isolés. La borne de décontamination vérifie les objets avant qu’ils arrivent au poste de travail.

PandoraBox propose une solution ouverte, que tout le monde peut vérifier, pour remplacer les bornes du commerce. PandoraBox s’adresse aux lieux qui demandent plus de sécurité, comme les hôpitaux, les usines ou les bureaux de l’État. Elle tourne sur un petit ordinateur reconditionné avec un écran tactile, et fonctionne sans réseau.

Plus de détail sur cette nouvelle version dans la seconde partie de la dépêche.

Sommaire

• • Une version entièrement réécrite.
  • Plusieurs moteurs de détection
  • Une image système durcie
  • Mises à jour signées et maintenance sans session
• Matériel et interface
  • État du projet
  • Essayer et contribuer

Une version entièrement réécrite.

La première version de PandoraBox s'appuyait sur Pandora du CIRCL pour analyser les fichiers. La nouvelle version repart d'une base propre et ne garde que ce qui fonctionnait : la machine à états, la détection USB avec pyudev, la quarantaine et l'interface curses du mode administrateur.

Les principaux changements :

• les appels à pypandora sont remplacés par une chaîne de moteurs de détection intégrée ;
• le moteur Comodo, qui n'est plus maintenu sous Linux, disparaît ;
• le diaporama d'images (fim) laisse la place à une vraie interface graphique tactile ;
• les clés sont montées en lecture seule par la borne elle-même, avec des options de montage durcies ;
• les journaux passent au JSON structuré ;
• la borne n'est plus un logiciel à installer sur un système existant, mais une image système complète.

Plusieurs moteurs de détection

Chaque fichier passe par plusieurs moteurs complémentaires :

• MalwareBazaar propose des empreintes SHA-256 de logiciels malveillants connus.
• Le service CIRCL Hashlookup aide à repérer les fichiers connus grâce à un filtre de Bloom.
• ClamAV : antivirus, y compris dans les archives
• YARA-X : YARA Forge
• Heuristiques : programmes déguisés en documents (double extension, type réel différent de l'extension), PDF avec JavaScript ou actions de lancement

La borne a un mode « fail closed » : si la borne ne peut pas analyser tout le fichier, comme pour une archive protégée par mot de passe, un fichier trop gros ou une erreur dans un moteur, la borne ne dit jamais que le fichier est sûr. Chaque partition de la clé est analysée, et une partition illisible (chiffrée, système de fichiers inconnu) rend la clé « non vérifiée ».

Rien n'est supprimé sans l'utilisateur : les fichiers dangereux sont listés à l'écran, copiés dans la quarantaine de la borne, puis retirés de la clé seulement après un appui sur l'écran. Chaque analyse donne un rapport JSON.

Une image système durcie

La clé USB pose un risque car la clé USB est vue comme un objet dangereux. Les moteurs d'analyse risquent d'être piratés. L'image est construite avec mkosi à partir des paquets Debian 13, et ne contient que ce qui sert à analyser :

• chaîne de démarrage vérifiée : Secure Boot avec la clé de l'image enrôlée à la place de celles de Microsoft, image noyau unifiée (UKI) signée, système de fichiers racine EROFS en lecture seule protégé par dm-verity, noyau en mode lockdown ;
• périphériques USB filtrés : USBGuard n'autorise que le stockage de masse, ce qui bloque les clés qui se font passer pour un clavier (BadUSB), et les pilotes réseau USB, Wi-Fi et Bluetooth sont retirés de l'image ;
• aucune session : pas de compte, pas de programme login, pas de menu de démarrage ;
• un bac à sable par moteur : chaque moteur tourne dans son propre processus, avec bubblewrap, un utilisateur dédié sans privilèges, un filtre seccomp et aucun accès réseau. Un moteur compromis par un fichier piégé ne peut pas falsifier le résultat d'un autre ;
• pare-feu et réglages du noyau inspirés des recommandations de l'ANSSI pour les systèmes GNU/Linux. Lynis donne un indice de durcissement de 73, sans avertissement.

L'interface graphique est dessinée avec Pillow directement dans le framebuffer, sans serveur d'affichage ni navigateur.

Mises à jour signées et maintenance sans session

La borne fonctionne hors ligne par défaut. Tout ce qui la modifie arrive signé :

• Les signatures : le logiciel vérifie un jeu de signatures signé Ed25519 à chaque démarrage. Il s'installe depuis une clé USB de mise à jour, qui n'est jamais analysée, ou en ligne avec le profil online de l'image. Sans jeu valide, la borne n'analyse rien. Un jeu plus ancien est refusé ;
• Le système accepte les mises à jour A/B avec systemd-sysupdate, par clé USB ou en ligne. La nouvelle version est écrite dans l'emplacement libre, et après 3 démarrages ratés, systemd-boot revient à la version précédente ;
• journaux : une clé de maintenance signée récupère les journaux de la borne (journal systemd, noyau, USBGuard, matériel) sans ouvrir de session et sans rien modifier.

Une borne en ligne peut aussi envoyer ses journaux à un SIEM (Wazuh, Elastic, Graylog, Splunk) en syslog RFC 5424 ou en JSON, sur TLS. En ligne, seuls le service de mise à jour, l'export SIEM et NTP peuvent sortir à travers le pare-feu. La borne elle-même n'a toujours pas accès au réseau.

Matériel et interface

La borne de référence est un Lenovo ThinkCentre M720q Tiny reconditionné (Core i5-9400T, 6 cœurs), avec un écran tactile Waveshare de 7 pouces (1024x600). L'image fonctionne sur tout ordinateur x86_64 UEFI, avec 2 Go de mémoire au minimum. Le boîtier de bureau s'imprime en 3D en une seule pièce.

L'interface est pensée pour le tactile, sans bouton : attente d'une clé, progression de l'analyse, liste des fichiers dangereux, appui n'importe où sur l'écran pour nettoyer, puis résultat. Chaque organisation peut y mettre son logo, ses couleurs, ses textes et sa langue (français et anglais fournis).

L'image est testée de bout en bout dans une machine virtuelle QEMU/KVM. Le test démarre l'image avec Secure Boot, insère des clés USB émulées (vfat, exFAT, NTFS, ext4), vérifie le verdict de chaque moteur, le nettoyage, les mises à jour et le retour à la version précédente.

État du projet

Le projet est en développement actif. L'analyse marche bien. L'image durcie fonctionne comme attendu. L'interface tactile répond comme il faut. Les mises à jour passent sans souci. L'export SIEM est validé. Le matériel de référence a permis de tout vérifier.

Une limite importante reste à lever : l'image et les jeux de signatures ne sont signés pour l'instant qu'avec des clés de développement, générées sur la machine qui construit l'image. Les clés de publication du projet et leur stockage ne sont pas encore définis.

Les prochaines étapes de la feuille de route :

• analyse des macros Office avec oletools et des exécutables avec capa ;
• désarmement et reconstruction de contenu (CDR) avec Dangerzone ;
• serveur central facultatif : inventaire des bornes, rapports, état des signatures ;
• modèle de menace documenté, fuzzing des points d'entrée et audit de sécurité externe ;
• correspondance avec les exigences NIS2 et ISO 27001 (mesure 7.10 « Supports de stockage »).

Essayer et contribuer

Il suffit de Docker pour construire l'image et la tester dans une machine virtuelle :

git clone https://github.com/sourcentis/pandora-box.git
cd pandora-box
image/build.sh                            # construit l'image
image/build-test.sh && image/vm.sh test   # la teste dans une machine virtuelle

Les contributions sont les bienvenues : retours d'expérience sur d'autres matériels, règles de détection, traductions de l'interface, revue de sécurité. Les vulnérabilités se signalent selon la politique de sécurité.

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

• [clubic.com] Open source: le code vient d'Europe, mais les décisions se prennent ailleurs
• [Next] Dix ans après la loi République numérique, à «encourager» le logiciel libre n’a pas suffi
• [01net.] Submergé par l'IA, Google prend une décision radicale en matière de cybersécurité

[clubic.com] Open source: le code vient d'Europe, mais les décisions se prennent ailleurs

✍ Guillaume Belfiore, le vendredi 9 octobre 2026.

Selon la Linux Foundation, 94% des organisations européennes jugent la souveraineté numérique importante, mais seules 37% participent à la gouvernance des projets open source dont elles dépendent.

[Next] Dix ans après la loi République numérique, à «encourager» le logiciel libre n’a pas suffi

✍ Alexandre Laurent, le mercredi 7 octobre 2026.

Dix ans après la promulgation de la loi du 7 octobre 2016 pour une République numérique, les dépenses en logiciels libres de l’administration sont toujours réduites à la portion congrue, regrette l’association représentative des entreprises du secteur. Elle appelle l’État à passer de l’encouragement à la règle, et à porter le message à l’échelle européenne.

[01net.] Submergé par l'IA, Google prend une décision radicale en matière de cybersécurité

✍ Florian Bayard, le lundi 5 octobre 2026.

Google a mis en pause son programme de récompenses pour les failles dans les logiciels open source. L’entreprise est en effet victime d’une explosion de rapports générés automatiquement par intelligence artificielle. Les primes sont suspendues jusqu’à nouvel ordre. Le groupe s’engage à annoncer des changements début 2027.

Et aussi:

• [Courrier international] IA: Mistral et Reflection misent tout sur les modèles open source (€)
• [Next] AI Slop: Google met en pause son programme de bug bounty pour le logiciel libre
• [ZDNET] Google suspend son programme de chasse aux bugs dans des logiciels open source

Le règlement (UE) 2024/2847, aussi appelé Cyber Resilience Act ou CRA, impose des exigences de cybersécurité à tout « produit comportant des éléments numériques » mis sur le marché de l’Union (logiciels compris, mais pas les services web). Son article 14 est entré en application le 11 septembre 2026. Tout fabricant doit signaler sous 24 heures toute vulnérabilité activement exploitée dans son produit et tout incident grave de sécurité, y compris pour les produits déjà sur le marché, puis compléter ce signalement sous 72 heures et le clore par un rapport final. Le reste du règlement s’applique à partir du 11 décembre 2027.

L’écosystème du libre s’était alarmé dès la proposition de 2022, et LinuxFr.org s’en était fait l’écho : le CRA menace l’avenir du logiciel libre, puis le texte du CRA a été finalisé. Le point d’achoppement était la notion d’« activité commerciale », dont dépend l’application du règlement. Le texte adopté en 2024, puis l'orientation de la Commission publiée le 27 juillet 2026, document interprétatif non contraignant, l’ont précisée dans un sens qui épargne les contributeurs individuels et les projets non monétisés.

Restent des chantiers ouverts : aucune norme harmonisée publiée à ce jour au Journal officiel, pas encore de mécanisme d’attestation de sécurité pour le logiciel libre, une plateforme de signalement sans API, et la question de qui paie les mainteneurs.

Sommaire

• Deux définitions du règlement
• Ce que l’écosystème a obtenu depuis 2023
• Les obligations vis-à-vis des mainteneurs
• Ce qui n’est pas prêt
• Qui paie les mainteneurs ?
• Prochaine manche : le règlement sur l’IA

Ce qui s’applique aujourd’hui

L’article 14 comporte deux déclencheurs : une vulnérabilité activement exploitée présente dans le produit, et un incident grave « ayant des répercussions sur la sécurité du produit », par exemple l’exécution d’un code malveillant dans le produit ou chez ses utilisateurs, qu’une faille ait été identifiée ou non. Chacun suffit. Les deux suivent la même cadence, au rapport final près :

• 24 heures : alerte précoce à l’ENISA (l’agence européenne de cybersécurité) et au CSIRT de son État membre (l’équipe publique de réponse aux incidents, CERT-FR pour la France), via la plateforme de signalement unique ;
• 72 heures : notification complémentaire, avec les éléments techniques et les mesures engagées ;
• rapport final : quatorze jours après la mise à disposition d’un correctif pour une vulnérabilité exploitée, un mois après la notification à 72 heures pour un incident grave.

Le texte apporte deux nuances. L’obligation de signaler s’impose à tous les fabricants, mais l’amende n’est pas la même pour tous (article 64(10)). Une microentreprise ou une petite entreprise qui dépasse les 24 heures n’est pas sanctionnée pour ce retard. Un intendant de logiciels ouverts (défini plus bas) n’encourt, lui, aucune amende, quel que soit le manquement. Enfin, l’article 14 vise les vulnérabilités « contenues dans » le produit : une faille exploitée dans une dépendance n’est à signaler que si le produit embarque le code vulnérable et que ce code y est effectivement atteignable. Une bibliothèque vulnérable dont le code fautif n’est jamais exécuté par le produit n’a pas à être signalée.

Côté outillage, la plateforme de l’ENISA ouvre aujourd’hui sans API : les signalements se saisissent à la main, en texte, dans une vingtaine de champs, et aucune pièce jointe n’est acceptée.

Deux définitions du règlement

Le texte français des articles et des annexes n’emploie pas une seule fois l’expression « open source ». Voici l’article 3, point 48) :

« logiciel libre et ouvert » : un logiciel dont le code source est partagé de manière ouverte et qui est mis à disposition sous licence libre et ouverte prévoyant tous les droits pour qu’il soit librement accessible, utilisable, modifiable et redistribuable ;

La définition pose deux conditions : une licence libre, et le partage ouvert du code source. Du code sous licence libre remis au seul client qui l’a commandé, sans publication, remplit la première condition et pas la seconde : il n’est pas « logiciel libre et ouvert » au sens du règlement. La FAQ officielle de la Commission le confirme pour le développement sur mesure : livrer à un client un logiciel écrit pour lui est une mise sur le marché, le prestataire qui le livre sous son propre nom en est le fabricant, sans aucun des allègements réservés au libre. Il peut seulement aménager par contrat deux des exigences essentielles de sécurité (question 4.2.5). La FAQ de l’ORC WG, le groupe de travail de la Fondation Eclipse qui suit le règlement pour l’écosystème du libre, ajoute, sur la base de l’orientation, qu’installer, configurer ou intégrer un logiciel existant pour un client reste une prestation de service.

L’article 3, point 14), crée une catégorie juridique inédite :

« intendant de logiciels ouverts » : une personne morale, autre que le fabricant, qui a pour objectif ou finalité de fournir un soutien systématique et continu au développement de produits spécifiques comportant des éléments numériques qui répondent aux critères de logiciels libres et ouverts et sont destinés à des activités commerciales, et qui assure la viabilité de ces produits ;

Le mot « steward » s’est imposé dans l’usage, y compris en français. Le statut est réservé aux personnes morales, sans condition de forme ni de but : une association loi de 1901, une fondation ou une société commerciale peuvent y prétendre. Le considérant 19 (les considérants forment l’exposé des motifs qui ouvre le règlement) vise expressément les entités qui développent et publient du logiciel libre dans un cadre professionnel. La FAQ de l’ORC WG répond sans détour qu’une société peut être intendante.

Reste le cas de la société qui est aussi fabricant, le plus courant chez les éditeurs. Les versions linguistiques y divergent. L’anglaise dit « a legal person, other than a manufacturer » : une personne morale qui n’est pas un fabricant, ce qui interdit d’être fabricant d’un produit et intendant d’un autre. La française dit « une personne morale, autre que le fabricant » : autre que le fabricant des produits soutenus, ce qui autorise le cumul en général mais l’interdit pour un même produit, précisément le cas courant de l’éditeur qui vend une édition de son logiciel et publie l’autre. Les vingt-quatre versions linguistiques ont la même valeur juridique. Sur ce point, elles ne disent pas la même chose. L’orientation de juillet 2026 va plus loin que l’une et l’autre : la même entité peut être fabricant de l’édition qu’elle monétise et intendante de l’édition communautaire du même logiciel. Tant mieux pour les éditeurs. Mais un document sans valeur contraignante accorde ainsi ce qu’aucune version du règlement ne dit. Sur le point le plus disputé du texte, le législateur a laissé deux versions qui se contredisent. L’édifice tient par une orientation que la Commission peut réviser.

Ce que l’écosystème a obtenu depuis 2023

Les contributions et les dons. Le considérant 18 exclut du règlement ceux qui contribuent à un logiciel qui « ne relève pas de leur responsabilité ». Un logiciel relève de la responsabilité de celui qui le publie et contrôle son développement, ses versions et sa distribution ; un accès en écriture au dépôt ne suffit pas. Un salarié qui envoie un correctif à un projet tiers pour le compte de son employeur reste un contributeur hors champ. Qui est payé pour le logiciel est fabricant ; qui est payé pour travailler sur le logiciel est prestataire, ou contributeur. Afficher un lien de don ne vaut pas intention de faire du profit ; les dons ne deviennent suspects que si l’ensemble des revenus du projet dépasse de loin ses coûts, dans lesquels entrent les frais de subsistance raisonnables du mainteneur.

L’intendant. L’article 24 lui impose trois choses : une politique de cybersécurité documentée et vérifiable, la coopération avec les autorités de surveillance du marché, et le signalement de l’article 14 dans la mesure où il participe au développement, si bien qu’un intendant purement financier ou juridique ne signale rien. Il le dispense de tout le reste : ni exigences essentielles de sécurité de l’annexe I, ni marquage CE, ni documentation technique, ni SBOM (l’inventaire des composants d’un produit), ni obligation de corriger. L’article 64(10)(b) l’exempte de toute amende.

Les modèles économiques. Le cas du bénévole isolé était pour l’essentiel acquis dès la proposition initiale de septembre 2022. La difficulté la plus sérieuse portait sur les éditeurs qui vendent de la maintenance sur ce qu’ils publient librement. C’est pour eux, plus que pour les bénévoles, que les associations professionnelles comme le CNLL ont bataillé. La réponse figure dans l’orientation, avec la fragilité relevée plus haut : les rôles s’apprécient logiciel par logiciel et activité par activité, y compris en open core (cas où l’édition payante étend la base de code de l’édition libre et ouverte). La condition est que les deux éditions soient réellement séparées : dépôts, artefacts et canaux distincts.

Les obligations vis-à-vis des mainteneurs

L’article 13(6) impose aux fabricants une obligation envers les mainteneurs des composants qu’ils intègrent. Le voici, deux renvois en moins :

Lorsqu’ils identifient une vulnérabilité dans un composant, y compris un composant logiciel ouvert, qui est intégré au produit comportant des éléments numériques, les fabricants signalent la vulnérabilité à la personne ou à l’entité qui assure la maintenance du composant […]. Lorsque les fabricants ont mis au point une modification logicielle ou matérielle pour remédier à la vulnérabilité de ce composant, ils partagent le code ou la documentation correspondants […], dans un format lisible par machine s’il y a lieu.

Le signalement est dû dans tous les cas. Le partage, lui, suppose que le fabricant ait effectivement développé une modification : s’il n’a rien écrit, il n’a rien à remettre. Et ce qu’il remet correspond à ce qu’il a fait, les deux « ou » de la phrase se répondant : le code pour une modification logicielle, la documentation pour une modification matérielle. L’orientation y ajoute des bornes : l’obligation ne porte que sur la version intégrée du composant et sur ses propres failles, elle s’exerce dans le respect de la politique de divulgation du projet, et elle tombe si le composant n’a plus de mainteneur. L’obligation ne dépend d’aucun lien contractuel entre le fabricant et le projet. Rien dans le règlement ne donne pour autant au mainteneur d’action propre pour l’exiger : la faire respecter revient aux autorités de surveillance du marché.

Ce qui n’est pas prêt

• Les normes harmonisées. Appliquer l’une d’elles vaut présomption de conformité : le fabricant est réputé satisfaire aux exigences qu’elle couvre, sans avoir à le démontrer autrement. Sur les 41 commandées aux trois organismes européens de normalisation (CEN, CENELEC, ETSI), aucune n’a encore été publiée au Journal officiel. Or l’article 27 ne fait naître la présomption qu’à cette publication. Trois projets sont en approbation (prEN 40000-1-1, -1-2, -1-3) ; le lot du catalogue d’exigences génériques a été mis en attente faute de contributeurs.
• Les attestations de sécurité du logiciel libre (article 25). Le règlement habilite la Commission à créer, par acte délégué (un texte d’application que la Commission adopte seule), des programmes volontaires d’attestation de sécurité pour le logiciel libre, afin de faciliter la vérification que les fabricants doivent faire des composants qu’ils intègrent, la « diligence raisonnable » de l’article 13, paragraphe 5. Le texte ne dit pas qui les financerait. L’ORC WG propose d’en faire le canal par lequel les fabricants paieraient les projets dont ils dépendent ; pour les projets libres, c’est l’absence la plus coûteuse. Aucun acte délégué n’a été publié ni planifié. En attendant, les référentiels de l’OpenSSF, la fondation de la Linux Foundation consacrée à la sécurité du logiciel libre, servent de justificatifs : Scorecard, Best Practices Badge, OSPS Baseline et SLSA.
• L’orientation elle-même. Elle n’existe qu’en anglais, n’a pas de valeur contraignante, et n’est pas encore formellement adoptée, faute des autres versions linguistiques. Tout ce que la section précédente lui attribue a la solidité d’une interprétation, que la Commission peut réviser et qu’un juge n’est pas tenu de suivre.
• Très peu de projets auront un intendant. Le rapport OSSRA 2025 de l’éditeur d’outils d’audit Black Duck, sur 965 bases de code commerciales auditées en 2024, y a dénombré 282 521 paquets JavaScript distincts. L’OpenJS Foundation héberge environ 35 projets. Un projet publie souvent plusieurs paquets, mais l’écart reste de plusieurs ordres de grandeur : la plupart des dépendances d’un produit n’auront ni fabricant ni intendant, et leur sécurité restera à la charge de qui les intègre.
• Le matériel libre. L’article 24 vise les logiciels : RISC-V International, l’OSHWA (Open Source Hardware Association) ou l’OpenHW Group ne peuvent pas prétendre au statut d’intendant.
• Les sanctions nationales. L’article 64 laisse aux États membres le soin de fixer le régime de sanctions, d’où des lois d’application nationales. Le règlement exempte les intendants de toute amende. Le projet de loi finlandais en prévoyait pourtant : le Parlement finlandais ne les a retirées qu’au printemps 2026.

Qui paie les mainteneurs ?

L'étude d’impact qui accompagnait la proposition de 2022 estimait qu’un cycle de développement sécurisé ajoute en moyenne 30,5 % au coût de développement d’un produit, pour un fabricant qui part de zéro : 42 700 € sur un produit moyen à 140 000 €. S’y ajoutent 9 % de coûts administratifs, documentation et signalement compris. C’est le « 30 % » que citait le CNLL en 2023. Aucune actualisation n’a été publiée depuis.

Le fabricant répercute ce surcoût sur son client, ou l’absorbe et cesse d’investir ailleurs. Le mainteneur n’a pas de client à qui le répercuter. Le travail lui arrive quand même. L’article 13(5) oblige le fabricant qui intègre un composant à en vérifier la sécurité ; beaucoup s’en acquittent en envoyant leurs questions au projet, sous forme de questionnaires de sécurité, de demandes de SBOM ou de délais de correction à confirmer. Hors champ du règlement, le mainteneur ne doit rien de tout cela. Rien n’oblige pour autant les fabricants à cesser : l’ORC WG en est réduit à plaider pour une « diligence respectueuse », qui ne traite pas un projet libre comme un fournisseur.

Le mécanisme d’attestation de l’article 25, seul canal de financement esquissé par le règlement, n’existe pas. La stratégie européenne pour l’open source du 3 juin 2026 annonce un « instrument de maintenance de l’open source », que l’écosystème réclamait sur le modèle du Sovereign Tech Fund allemand, sans budget ni calendrier.

Trois ans de mobilisation ont produit un règlement vivable pour le libre. Qui paie les mainteneurs dont il fait dépendre tout l’édifice, le texte ne le dit pas, et personne d’autre non plus, à ce stade.

Prochaine manche : le règlement sur l’IA

Le règlement sur l’intelligence artificielle exempte lui aussi les systèmes publiés sous licence libre (article 2, paragraphe 12), sauf s’ils sont mis sur le marché comme systèmes à haut risque. Or un système est classé à haut risque d’après l’usage auquel son fournisseur le destine. Le projet d’orientations publié par la Commission le 19 mai 2026 retient qu’un système présenté comme largement applicable, dont le fournisseur n’exclut pas de façon constante les usages à haut risque, est réputé les couvrir. Une simple déclaration, ajoute-t-il, ne suffit pas. Un composant d’IA publié en libre est mal armé pour ce test : son auteur ne maîtrise ni les usages ni les utilisateurs, et une licence qui restreindrait les champs d’application cesserait d’être libre (liberté 0 de la FSF, critère 6 de l'Open Source Definition). L’exemption s’évanouirait donc là où elle compte. Reste à savoir quel poids une autorité accordera aux limitations inscrites dans un README ou une fiche de modèle.

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

• [Courrier international] DJ, cocktails et open source: aux États-Unis, des ateliers de cybersécurité se tiennent dans des bars (€)
• [L'usine Nouvelle] Nvidia confirme acquérir la plateforme de modèles d’IA Hugging Face: un rachat pour défendre l’open source… et servir ses intérêts commerciaux
• [Silicon.fr] Open source et secteur public: pourquoi ce n'est pas si facile
• [Le Monde.fr] ChatGPT va être la première IA soumise à des règles renforcées au sein de l’Union européenne, Roblox et Reddit également concernés

[Courrier international] DJ, cocktails et open source: aux États-Unis, des ateliers de cybersécurité se tiennent dans des bars (€)

✍ Ellen Ioanes, le samedi 5 septembre 2026.

Après plus d’une décennie de scandales ayant mis en lumière la surveillance numérique de masse à laquelle ils sont exposés, de plus en plus d’Américains se disent inquiets pour leur cybersécurité. Pour apprendre à “reprendre le contrôle de leur vie numérique”, des ateliers, conférences et soirées festives se multiplient dans les grandes villes, raconte le journal britannique “The Guardian”.

[L'usine Nouvelle] Nvidia confirme acquérir la plateforme de modèles d’IA Hugging Face: un rachat pour défendre l’open source… et servir ses intérêts commerciaux

✍ Marion Garreau, le jeudi 3 septembre 2026.

Nvidia, le leader mondial des puces pour l’IA, a confirmé jeudi 3 septembre l’acquisition du franco-américain Hugging Face, une plateforme de distribution de modèles d’IA, pour 12,9 milliards de dollars. Un rachat qui renforce la stratégie dans l’open-source du mastodonte américain, et qui vient aussi servir ses intérêts commerciaux.

Et aussi:

• [Les Echos] Hugging Face: Clément Delangue, le Ch'ti qui a mis le monde de l'IA à ses pieds
• [InformatiqueNews.fr] Nvidia confirme l'acquisition de Hugging Face, le carrefour de l'IA open source [MAJ]
• [Le Monde.fr] Hugging Face, start-up d’intelligence artificielle fondée par des Français, défend son rachat par l’américain Nvidia, au nom de l’«open source» (€)

[Silicon.fr] Open source et secteur public: pourquoi ce n'est pas si facile

✍ Clément Bohic, le mercredi 2 septembre 2026.

Les auditions de la commission parlementaire sur les dépendances numériques ont témoigné des défis que pose, dans la sphère publique, le déploiement de l’open source.

[Le Monde.fr] ChatGPT va être la première IA soumise à des règles renforcées au sein de l’Union européenne, Roblox et Reddit également concernés

Le lundi 31 août 2026.

Les trois services disposent de quatre mois, soit jusqu’à la fin décembre, pour se ‌conformer aux obligations ‌supplémentaires prévues par le Digital Services Act.